Communication method and user equipment

Abstract

A communication method performed by a user equipment in a mobile communication system providing a multicast / broadcast service (MBS) includes receiving a first PTM configuration from a network and saving the first PTM configuration, the first PTM configuration for receiving a multicast session in a radio resource control (RRC) inactive state; in the RRC inactive state, in response to receiving a paging message from the network, determining whether the first PTM configuration needs to be updated, the paging message including a session identifier of the multicast session; and in response to determining that the first PTM configuration needs to be updated in the RRC inactive state, acquiring a second PTM configuration for receiving a multicast session by receiving a multicast control channel (MCCH) for multicast communication.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a communication method and a user equipment used in a mobile communication system. BACKGROUND

[0002] The Third Generation Partnership Project (3GPP) has defined a technical specification of New Radio (NR) as a fifth generation (5G) radio access technology. NR has features such as high speed, large capacity, high reliability, and low latency compared to Long Term Evolution (LTE) as a fourth generation (4G) radio access technology. The 3GPP has defined a technical specification of a multicast / broadcast service (MBS) for 5G / NR.

[0003] In 3GPP Release 17, MBS multicast reception (i.e., multicast reception) is possible only for a user equipment in a radio resource control (RRC) connected state (see, for example, Non-Patent Literature 1). On the other hand, in 3GPP Release 18, it is planned to extend the technical specification so that a user equipment in an RRC inactive state can perform multicast reception.

[0004] LIST OF REFERENCES

[0005] NON-PATENT LITERATURE

[0006] Non-Patent Literature 1: 3GPP Technical Specification: TS 38.300 V17.3.0 SUMMARY

[0007] The communication method according to the first aspect is a communication method executed by a user equipment in a mobile communication system that provides a multicast broadcast service (MBS). The communication method includes: in a radio resource control (RRC) inactive state, determining whether a predetermined condition is satisfied in response to receiving a paging message from a network, the paging message including a session identifier of a multicast session; and in the RRC inactive state, acquiring configuration information for receiving the multicast session in the RRC inactive state by receiving a multicast control channel (MCCH) for multicast communication in response to the predetermined condition being satisfied.

[0008] The communication method according to the second aspect is a method performed by a user equipment in a mobile communication system providing a multicast / broadcast service (MBS). The communication method includes: receiving a first PTM configuration from a network and saving the first PTM configuration, the first PTM configuration being used for receiving a multicast session in a radio resource control (RRC) inactive state; in the RRC inactive state, determining whether the first PTM configuration needs to be updated in response to receiving a paging message from the network, the paging message including a session identifier of the multicast session; and in the RRC inactive state, acquiring a second PTM configuration used for receiving the multicast session by receiving a multicast control channel (MCCH) for multicast communication in response to determining that the first PTM configuration needs to be updated.

[0009] The user equipment according to the third aspect is a device used in a mobile communication system providing a multicast / broadcast service (MBS). The user equipment includes a controller configured to perform the following processing: receiving a first PTM configuration from a network and saving the first PTM configuration, the first PTM configuration being used for receiving a multicast session in a radio resource control (RRC) inactive state; in the RRC inactive state, determining whether the first PTM configuration needs to be updated in response to receiving a paging message from the network, the paging message including a session identifier of the multicast session; and in the RRC inactive state, acquiring a second PTM configuration used for receiving the multicast session by receiving a multicast control channel (MCCH) for multicast communication in response to determining that the first PTM configuration needs to be updated. BRIEF DESCRIPTION OF DRAWINGS

[0010] Figure 1 is a diagram illustrating a configuration example of a mobile communication system according to an embodiment.

[0011] Figure 2 is a diagram illustrating a configuration example of a user equipment (UE) according to an embodiment.

[0012] Figure 3 is a diagram illustrating a configuration example of a base station (gNB) according to an embodiment.

[0013] Figure 4 is a diagram illustrating a configuration of a protocol stack of a radio interface handling a user plane of data.

[0014] Figure 5 is a diagram illustrating a configuration of a protocol stack of a radio interface handling a control plane of signaling (control signals).

[0015] Figure 6 is a diagram illustrating an overview of operations of a UE related to a first operation mode according to an embodiment.

[0016] Figure 7is a diagram showing an example of an operation sequence of a mobile communication system related to a first operation mode according to an embodiment.

[0017] Figure 8 is a diagram showing an overview of an operation of a UE related to a second operation mode according to an embodiment.

[0018] Figure 9 is a diagram showing an example of an operation sequence of a mobile communication system related to a second operation mode according to an embodiment.

[0019] Figure 10 is a diagram showing an overview of an operation of a UE related to a third operation mode according to an embodiment.

[0020] Figure 11 is a diagram showing an example of a first operation example of the third operation mode according to an embodiment.

[0021] Figure 12 is a diagram showing another example of the first operation example of the third operation mode according to an embodiment.

[0022] Figure 13 is a diagram showing an example of a second operation example of the third operation mode according to an embodiment.

[0023] Figure 14 is a diagram showing another example of the second operation example of the third operation mode according to an embodiment. DETAILED DESCRIPTION

[0024] A mobile communication system according to an embodiment is described with reference to the accompanying drawings. In the description of the drawings, like or similar elements are denoted by like or similar reference numbers.

[0025] (1) System configuration example

[0026] Figure 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 a fifth generation system (5GS) of the 3GPP standard. The following description takes the 5GS as an example, but a long term evolution (LTE) system can be applied at least in part to the mobile communication system. Alternatively, a sixth generation (6G) system can be applied at least in part to the mobile communication system.

[0027] The mobile communication system includes a user equipment (UE) 100, a 5G radio access network (next generation radio access network (NG-RAN)) 10, and a 5G core network (5GC) 20. Hereinafter, the NG-RAN 10 can be simply referred to as the RAN 10. The 5GC 20 can be simply referred to as a core network (CN) 20. The RAN 10 and the CN 20 constitute a network of the mobile communication system 1.

[0028] The UE 100 is a mobile wireless communication device. The UE 100 can be any device as long as the UE 100 is used by a user. Examples of the UE 100 include 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 on a sensor, a vehicle or a device provided on a vehicle (vehicle UE), or an aerial object and a device provided on an aerial object (aerial UE).

[0029] The NG-RAN 10 includes base stations (referred to as “gNBs” in 5G systems) 200. The gNBs 200 are interconnected via an Xn interface that is an inter-base station interface. Each gNB 200 manages one or more cells. The gNB 200 performs wireless communication with the UE 100 that has established a connection with a cell of the gNB 200. The gNB 200 has a radio resource management (RRM) function, a function of routing user data (hereinafter, simply referred to as “data”), a measurement control function for mobility control and scheduling, and the like. The “cell” is used as a term representing the smallest unit of a wireless communication area. The “cell” is also used as a term representing a function or a resource for performing wireless communication with the UE 100. One cell belongs to one carrier frequency (hereinafter, simply referred to as “frequency”).

[0030] Note that the gNB can be connected to an evolved packet core (EPC) corresponding to a core network of LTE. An LTE base station can also be connected to the 5GC. The LTE base station and the gNB can be connected via an inter-base station interface.

[0031] The 5GC 20 includes an access and mobility management function (AMF) and a user plane function (UPF) 300. The AMF performs various types of mobility control and the like for the UE 100. The AMF manages the mobility of the UE 100 by communicating with the UE 100 using non-access stratum (NAS) signaling. The UPF controls transmission of data. The AMF and the UPF are connected to the gNB 200 via an NG interface that is an interface between a base station and a core network.

[0032] Figure 2 is a diagram illustrating a configuration example of a user equipment (UE) 100 according to an embodiment. The UE 100 includes a receiver 110, a transmitter 120, and a controller 130. The receiver 110 and the transmitter 120 constitute a wireless communicator that performs wireless communication with the gNB 200.

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

[0034] The transmitter 120 performs various types of transmission under the control of the controller 130. The transmitter 120 includes an antenna and a transmitting device. The transmitting device converts a baseband signal (a transmission signal) output by the controller 130 into a radio signal, and transmits the resulting signal from the antenna.

[0035] The controller 130 performs various types of control and processing in the UE 100. Such processing includes processing of each layer to be described below. The operations of the above and below UE 100 can be operations under the control of the controller 230. The controller 130 includes at least one processor and at least one memory. The memory stores programs to be executed by the processor and information to be used for processing by the processor. The processor can include a baseband processor and a central processing unit (CPU). The baseband processor performs modulation and demodulation, encoding and decoding, and the like of a baseband signal. The CPU executes programs stored in the memory, thereby performing various types of processing.

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

[0037] The transmitter 210 performs various types of transmission under the control of the controller 230. The transmitter 210 includes an antenna and a transmitting device. The transmitting device converts a baseband signal (a transmission signal) output by the controller 230 into a radio signal, and transmits the resulting signal from the antenna.

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

[0039] The controller 230 performs various types of control and processing in the gNB 200. This processing includes the processing of each layer to be described below. The operations of the above and below-described gNB 200 can also be operations performed under the control of the controller 230. The controller 230 includes at least one processor and at least one memory. The memory stores programs to be executed by the processor and information to be used for the processing by the processor. The processor can include a baseband processor and a CPU. The baseband processor performs modulation and demodulation, encoding and decoding, and the like of a baseband signal. The CPU executes the programs stored in the memory, thereby performing various types of processing.

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

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

[0042] The radio interface protocol of the user plane 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.

[0043] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted and received between the PHY layer of the UE 100 and the PHY layer of the gNB 200 via a physical channel. Note that the PHY layer of the UE 100 receives downlink control information (DCI) transmitted from the gNB 200 through a physical downlink control channel (PDCCH). Specifically, the UE 100 performs blind decoding on the PDCCH by using a radio network temporary identifier (RNTI) and acquires successfully decoded DCI as DCI addressed to the UE. CRC parity bits scrambled by the RNTI are added to the DCI transmitted from the gNB 200.

[0044] The MAC layer performs priority control of data, retransmission processing through hybrid automatic repeat request (HARQ), a random access procedure, and the like. Data and control information are transmitted and received between the MAC layers of the UE 100 and the gNB 200 via transport channels. The MAC layer of the gNB 200 includes a scheduler. The scheduler decides the transport format (transport block size, modulation and coding scheme (MCS)) in the uplink and the resource blocks to be allocated to the UE 100.

[0045] The RLC layer sends data to the RLC layer of the receiving side by using the functions of the MAC layer and the PHY layer. Data and control information are transmitted and received between the RLC layers of the UE 100 and the gNB 200 via logical channels.

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

[0047] The SDAP layer performs mapping between an IP flow (as a unit of QoS (quality of service) control performed by a core network) and a radio bearer (as a unit of QoS control performed by an access stratum (AS)). Note that when the RAN is connected to an EPC, the SDAP does not need to be provided.

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

[0049] The protocol stack of the radio interface of the control plane includes a radio resource control (RRC) layer and a non-access stratum (NAS) layer, instead of Figure 4 the SDAP layer illustrated.

[0050] RRC signaling for various configurations is transmitted and received between the RRC layer of the UE 100 and the RRC layer of the gNB 200. The RRC layer controls logical channels, transport channels, and physical channels according to establishment, reestablishment, and release of radio bearers. When the connection (RRC connection) between the RRC of the UE 100 and the RRC of the gNB 200 is established, the UE 100 is in an RRC connected state. When the connection (RRC connection) between the RRC of the UE 100 and the RRC of the gNB 200 is not established, the UE 100 is in an RRC idle state. When the connection between the RRC of the UE 100 and the RRC of the gNB 200 is suspended, the UE 100 is in an RRC inactive state.

[0051] The NAS layer (also simply referred to as "NAS") located above the RRC layer performs session management, mobility management, and the like. 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 includes an application layer in addition to the protocol of the radio interface. Layers lower than the NAS layer are referred to as AS layers (also simply referred to as "AS").

[0052] (2) Overview of MBS

[0053] The mobile communication system 1 can perform transmission with high resource efficiency by using a multicast / broadcast service (MBS).

[0054] (2.1) MBS Broadcast

[0055] In a broadcast communication service (also referred to as "MBS broadcast"), the same service and the same specific content data are simultaneously provided to each UE 100 within a geographical area. That is, each UE 100 in the broadcast service area is allowed to receive data. The broadcast communication service is transmitted to the UE 100 using a broadcast session, which is a type of MBS session. The UE 100 can receive the broadcast session in any of the RRC idle state, the RRC inactive state, and the RRC connected state.

[0056] Point-to-multipoint (PTM) transmission is applicable to the broadcast communication service. On the other hand, for PTM transmission, the gNB 200 transmits a single copy of an MBS packet to a set (group) consisting of multiple UEs 100. For example, the gNB 200 schedules a group common PDSCH scrambled by a group RNTI (G-RNTI), which is a group common RNTI, using a group common PDCCH with a cyclic redundancy code (CRC) scrambled by the G-RNTI.

[0057] For the broadcast communication service, the UE 100 receives the broadcast session in the following procedures. First, the UE 100 receives a system information block type 20 (SIB 20) from the gNB 200. The SIB 20 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 SIB 20. The MCCH includes a PTM configuration. The PTM configuration transmits a configuration of a multicast traffic channel (MTCH), which is a type of logical channel (MTCH configuration), and a configuration of a broadcast multicast radio bearer (MRB), which is a multicast MRB for the broadcast session. The information transmitted by the MCCH can be 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).

[0058] Note that the MCCH is a PTM downlink channel used to transmit MBS broadcast control information associated with one or more MTCHs from the network 10 to the UEs 100. The MTCH is a PTM downlink channel used to transmit MBS data of a multicast session and / or a broadcast session from the network 10 to the UEs 100.

[0059] The MCCH information transmitted on the MCCH is generated at the boundary of a modification period and the same MCCH information is repeatedly transmitted within the modification period according to the MCCH configuration (MCCH scheduling). When the network 5 changes (part of) the MCCH information, it informs the UEs 100 of the change starting from the beginning of the MCCH modification period in the PDCCH (DCI) of the MCCH in all the repeated transmissions within the scheduling modification period.

[0060] When a UE 100 that is receiving or interested in receiving an MBS service transmitted using MBS broadcast receives such a change notification (MCCH change notification), it acquires the new MCCH information starting from the same slot. The UE 100 applies the previously acquired MCCH information until it acquires the new MCCH information.

[0061] The MCCH change notification is transmitted in the form of a 2-bit bitmap. If the most significant bit (MSB) of the 2-bit bitmap is set to “1”, it indicates the start of a new MBS service. If the least significant bit (LSB) of the 2-bit bitmap is set to “1”, it indicates a modification of the MCCH information, other than a modification caused by the initiation of a new MBS service (e.g., activation of an MBS session), such as a modification of the configuration of an ongoing MBS session, a stop of an MBS session (specifically, a broadcast session), or a modification of the neighboring cell information.

[0062] However, although there is one MCCH in a cell, the MCCH information is transmitted for all MBS services (all broadcast sessions) in the cell. Therefore, the UE 100 cannot identify which broadcast session’s MCCH information has been modified based on the MCCH change notification. Therefore, the UE 100 needs to acquire the MCCH information in response to receiving the MCCH change notification even if the MCCH information of a broadcast session that the UE 100 itself does not receive or is not interested in receiving is modified.

[0063] (2.2) MBS Multicast

[0064] In a multicast communication service (also referred to as “MBS Multicast”), the same service and the same specific content data are provided to a specific group of UEs at the same time. That is, not every UE 100 in the multicast service area is allowed 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.

[0065] The UE 100 can receive the corresponding multicast session only after joining the multicast session (session join). Joining the multicast session can mean that the UE 100 is registered in the network 5 (CN 20) as capable of receiving the multicast session.

[0066] For the multicast communication service, in 3GPP Release 17, only the UE 100 in the RRC connected state can receive the multicast session. On the other hand, it is planned to extend 3GPP Release 18 so that the UE 100 in the RRC inactive state can also receive the multicast session.

[0067] (2.2.1) Multicast reception in the RRC connected state

[0068] The UE 100 in the RRC connected state can receive the multicast session (specifically, the MBS data belonging to the multicast session) using a mechanism such as point-to-point (PTP) and / or point-to-multipoint (PTM) delivery.

[0069] For the multicast communication service, the UE 100 in the RRC connected state receives the 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 configuration (MTCH configuration) related to the MTCH for receiving the multicast session and a configuration of a multicast MRB as the MRB of the multicast session. Second, the UE 100 receives the MTCH based on the RRC reconfiguration message. The MTCH transmits the multicast session (specifically, the MBS data belonging to the multicast session).

[0070] (2.2.2) Multicast reception in the RRC inactive state

[0071] The UE 100 in the RRC inactive state can receive the multicast session (specifically, the MBS data belonging to the multicast session) by using a mechanism for PTM delivery.

[0072] For 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 "new SIB") from the gNB 200. The new SIB includes a configuration of a newly-introduced MCCH (also referred to as "multicast MCCH"). Second, the UE 100 in the RRC inactive state receives the multicast MCCH from the gNB 200 based on the new SIB. The multicast MCCH includes a PTM configuration. The PTM configuration sends a configuration related to an MTCH for receiving a multicast session (MTCH configuration) and a configuration of a multicast MRB which is an MRB of the multicast session. Third, the UE 100 in the RRC inactive state receives the MTCH based on the multicast MCCH. The MTCH sends a multicast session (specifically, MBS data belonging to the multicast session).

[0073] When the gNB 200 configures the UE 100 to receive a multicast in the RRC inactive state, the gNB can send the PTM configuration to the UE 100 using an RRC release message including a suspend configuration. In this case, when the RRC release message including the PTM configuration is received from the gNB 200, the UE 100 transitions to the RRC inactive state and receives a multicast session in the RRC inactive state.

[0074] (2.2.3) Group Notification

[0075] When there is no data to be transmitted to the UE 100 in a multicast session in the active state for a while, the gNB 200 can transition the UE 100 to the RRC inactive state. When the multicast session is deactivated, the gNB 200 can transition the UE 100 to the RRC idle state or the RRC inactive state.

[0076] When the CN 20 activates a multicast session, the gNB 200 supporting MBS performs notification to the UE 100 in the RRC idle state or the RRC inactive state using a group notification mechanism. When a multicast session has been activated and the gNB 200 has multicast session data to be delivered, the gNB 200 supporting MBS can perform notification to the UE 100 in the RRC inactive state using the group notification mechanism.

[0077] After receiving the group notification, the UE 100 reconnects to the network 5 or resumes connection to transition to the RRC connected state. The group notification is processed using a paging RNTI (P-RNTI) on the PDCCH, and the UE 100 monitors a paging channel.

[0078] The paging message for group notification includes a session identifier (MBS session ID) for paging all UEs 100 in RRC idle state and RRC inactive state and having joined the associated MBS multicast session. That is, the UEs 100 are not individually paged.

[0079] When the UE 100 transitions to the RRC connected state, the UE 100 can stop monitoring the group notification associated with a certain multicast session. That is, the UE 100 stops checking the MBS session ID in the paging message. In the case where the UE 100 leaves the multicast session, the network 5 requests the UE 100 to leave, or the network 5 releases the multicast session, the UE 100 does not monitor the group notification.

[0080] Note that the group notification can be performed on the MCCH or can be performed by the MCCH change notification. When the MCCH is used, it can be determined whether the MCCH has the MTCH configuration of the MBS session of interest. When the MCCH change notification is used, the group notification can be notified in a predetermined bit of the DCI.

[0081] (3) First operation mode

[0082] The first operation mode related to multicast reception in the RRC inactive state will be described below.

[0083] When the multicast session is activated, that is, when the multicast session is ongoing, the multicast MRB for multicast reception is configured to the UE 100 in the RRC connected state by the RRC reconfiguration message, and the UE 100 can start receiving the MTCH.

[0084] In the multicast reception in the RRC inactive state, the RRC release message can be used to configure the MRB (also referred to as "multicast inactive MRB") for multicast reception to the UE 100 in the RRC connected state.

[0085] When the UE 100 in the RRC connected state receives the RRC release message including the suspend configuration, the UE suspends the multicast MRB for the RRC connected state. If the RRC release message includes the PTM configuration for the RRC inactive state, the UE 100 continues to receive the same multicast session.

[0086] During / after the transition of the RRC state, service continuity of the multicast session needs to be ensured. Therefore, the UE 100 needs to apply the PTM configuration of the multicast inactive MRB before temporarily suspending the multicast MRB. As long as the PTM configuration is applied, the UE 100 starts receiving the multicast inactive MRB. This can prevent the multicast reception from being interrupted when the UE transitions from the RRC connected state to the RRC inactive state.

[0087] (3.1) Overview of the operation of the UE

[0088] Figure 6 is a diagram illustrating an overview of the operation of the UE 100 related to the first operation mode according to the embodiment. In Figure 6 In steps S1 to S5 of FIG. 10, it is assumed that the UE 100 is in the RRC connected state.

[0089] In step S1, the UE 100 receives a multicast session (referred to as "multicast session #1") from the network 5 (gNB 200) using a first MRB (multicast MRB) for the RRC connected state.

[0090] In step S2, the UE 100 receives an RRC release message (i.e., an RRC release message including a suspend configuration) from the network 5 (gNB 200) for transitioning the UE 100 to the RRC inactive state. The RRC release message includes configuration information (PTM configuration) indicating a configuration of a second MRB (multicast inactive MRB) for receiving the multicast session #1 in the RRC inactive state. Note that the suspend configuration is an information element indicating a configuration for the RRC inactive state.

[0091] In step S3, the UE 100 establishes the second MRB by applying the configuration information (PTM configuration) of step S2 before suspending the first MRB in response to receiving the RRC release message. Step S3 can be performed before the suspend configuration is applied. Step S3 can be performed when the suspend configuration is applied.

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

[0093] In step S5, the UE 100 suspends the first MRB. Specifically, the UE 100 stops using the first MRB while keeping the configuration of the first MRB. In this way, by suspending the first MRB after the establishment of the second MRB, it is possible to prevent the multicast reception from being interrupted. Note that the UE 100 can suspend the first MRB after confirming that reception of the multicast session #1 has started via the second MRB, that is, reception of the MBS data. Such confirmation of reception start (success of reception start) can be performed in a lower layer (e.g., PDCP layer), and the confirmation result can be notified to the RRC layer. If the reception start is not confirmed within a certain period of time, the UE 100 can determine that a reception error has occurred in the multicast session #1, or can subsequently suspend the first MRB. Upon detecting a reception error, the UE 100 can attempt to transition to the RRC connected state again (specifically, transmit an RRC resume request).

[0094] In step S6, the UE 100 transitions from the RRC connected state to the RRC inactive state. The UE 100 in the RRC inactive state can continue to receive the multicast session #1 using the second MRB.

[0095] According to this operation, when the UE 100 that is performing multicast reception in the RRC connected state transitions from the RRC connected state to the RRC inactive state, it is possible to prevent the multicast reception from being interrupted.

[0096] (3.2) Example of operation sequence

[0097] Figure 7 is a diagram illustrating an example of an operation sequence of the mobile communication system 1 related to the first operation mode according to the embodiment.

[0098] In step S11, the UE 100 is in the RRC connected state in the cell of the gNB 200.

[0099] In step S12, the network 5 activates the multicast session #1. Note that step S12 can be performed after step S13, after step S14, or after step S15.

[0100] In step S13, the UE 100 in the RRC connected state joins the multicast session #1.

[0101] In step S14, the gNB 200 transmits an RRC reconfiguration message including a PTM configuration for the RRC connected state to the UE 100. The UE 100 in the RRC connected state receives the RRC reconfiguration message.

[0102] In step S15, the UE 100 in the RRC connected state applies the PTM configuration for the RRC connected state of step S14 to establish a first MRB (multicast MRB) with the gNB 200.

[0103] In step S16, the gNB 200 transmits MBS data (multicast data) of the multicast session #1 to the UE 100 on the MTCH using the first MRB. The UE 100 in the RRC connected state receives the multicast data.

[0104] Then, in step S17, the gNB 200 transmits an RRC release message including a suspend configuration to the UE 100. The UE 100 in the RRC connected state receives the RRC release message. The RRC release message further includes a PTM configuration for the RRC inactive state. The PTM configuration for the RRC inactive state can be included in the suspend configuration. The PTM configuration can be a different information element from the suspend configuration.

[0105] In step S18, the UE 100 in the RRC connected state applies the PTM configuration for the RRC inactive state of step S17 to establish a second MRB (multicast inactive MRB) with the gNB 200.

[0106] In step S19, the gNB 200 transmits MBS data (multicast data) of the multicast session #1 to the UE 100 on the MTCH using the second MRB. The UE 100 in the RRC connected state receives the multicast data. At this time, the UE 100 can perform both multicast reception using the first MRB and multicast reception using the second MRB. When the same multicast data is received in both the first MRB and the second MRB, the UE 100 can discard the multicast data of one of them.

[0107] In step S20, the UE 100 in the RRC connected state suspends the first MRB.

[0108] In step S21, the UE 100 transitions from the RRC connected state to the RRC inactive state.

[0109] Thereafter, when the PTM configuration for the RRC-Inactive state can be updated, the UE 100 can receive a new SIB from the gNB 200 (step S22), and receive a multicast MCCH from the gNB 200 (step S23). Note that although an example in which the RRC release message includes the PTM configuration for the RRC-Inactive state has been described in step S17, it is not limited thereto. In step S17, the UE 100 can receive the PTM configuration for the RRC-Inactive state on the MCCH. The UE 100 can receive the RRC release message which can not include the PTM configuration for the RRC-Inactive state.

[0110] (4) Second operation mode

[0111] Hereinafter, a second operation mode related to multicast reception in the RRC-Inactive state will be described focusing on the difference from the above-described first operation mode. Note that the repetitive description of the similar operation to the above-described first operation mode will be omitted.

[0112] The above-described first operation mode is based on the assumption of the scenario in which the multicast session has been activated when the UE 100 receives the RRC release message. In contrast, in the second operation mode, the scenario in which the multicast session has not been activated when the UE 100 receives the RRC release message is mainly assumed.

[0113] For the deactivated multicast session, the PTM configuration (MBSMulticastInactiveConfiguration) can be configured for the UE 100 by the RRC release message. In the above-described first operation mode, the UE 100 which has received the RRC release message applies the PTM configuration and immediately starts receiving the MTCH. If the multicast session is deactivated, since the MTCH is not transmitted at this time, the UE 100 does not start the process of receiving the MTCH. In this case, even if the UE 100 attempts multicast reception (MTCH reception), the UE 100 cannot receive the MTCH and waste power.

[0114] Therefore, in the second operation mode, the network 5 informs the UE 100 that the multicast session (specifically, the multicast session that the UE 100 is joining) is still in the deactivated state. For example, the gNB 200 informs the UE 100 of whether the multicast session is activated by the RRC release message, so that the UE 100 does not receive the corresponding MTCH. This allows the UE 100 to wait for, for example, a multicast session activation notification (group notification) without starting to receive the MTCH.

[0115] That is, in the second operation mode, first, the UE 100 in the RRC connected state receives, from the gNB 200, an RRC release message including configuration information for receiving a multicast session in an RRC inactive state (PTM configuration for the RRC inactive state) to cause the UE 100 to transition to the RRC inactive state. Second, the UE 100 checks whether the multicast session has been activated. Third, when the multicast session has not been activated, the UE 100 suspends execution of a predetermined process for starting reception of the multicast session.

[0116] (4.1) Overview of the operation of the UE

[0117] Figure 8 is a diagram illustrating an overview of the operation of the UE 100 related to the second operation mode according to the embodiment. Here, it is assumed that the UE 100 has joined the multicast session #1.

[0118] In step S201, the UE 100 in the RRC connected state receives, from the gNB 200, an RRC release message including configuration information for receiving a multicast session in an RRC inactive state (PTM configuration for the RRC inactive state) to cause the UE 100 to transition to the RRC inactive state. In the second operation mode, the RRC release message includes session state information indicating whether the multicast session #1 has been activated.

[0119] The session state information can indicate that the multicast session #1 has been activated (i.e., not deactivated). The session state information can indicate that the multicast session #1 has not been activated (i.e., in a deactivated state). The session state information can be a message indicating whether to immediately apply the following information (which can be the PTM configuration for the RRC inactive state) (i.e., whether the predetermined process is applied or only reserved). Alternatively, the session state information can be information indicating whether to immediately start MTCH reception.

[0120] The configuration information (PTM configuration for the RRC inactive state) in the RRC release message can include at least one selected from the group consisting of a session identifier (TMGI) associated with the multicast session #1, an MRB identifier associated with the multicast session #1, and an MTCH configuration associated with the multicast session #1, as predetermined information associated with the multicast session #1. The MTCH configuration is a configuration related to MTCH reception, and includes, for example, at least one selected from the group consisting of a group identifier (G-RNTI), a discontinuous reception configuration (DRX configuration or scheduling information: MTCH transmission on duration, MTCH transmission periodicity, reference time and time offset, HARQ retransmission configuration), a layer 2 configuration (PDCP configuration or RLC configuration), and a physical channel configuration (PDCCH configuration, PDSCH configuration, SSB mapping configuration).

[0121] In the RRC release message, the session status information is associated with the predetermined information. This allows the UE 100 to identify which multicast session has been activated based on the predetermined information and the session status information.

[0122] In step S202, the UE 100 in the RRC connected state checks whether the multicast session #1 has been activated based on the session status information in the RRC release message. Alternatively, when the UE 100 has acquired information about whether the multicast session #1 has been activated from the CN 20, the UE 100 can check whether the multicast session #1 has been activated based on the information from the CN 20.

[0123] When the multicast session #1 has been activated (step S202: Yes), in step S203, the UE 100 in the RRC connected state performs the same operation as the operation in the above-described first operation mode. Specifically, the UE 100 performs predetermined processing for starting reception of the multicast session #1. The predetermined processing includes at least one selected from the group consisting of the processing of acquiring the configuration information (PTM configuration for the RRC inactive state) (including the processing for establishing the second MRB) and the processing of starting reception of the MTCH (i.e., the processing of starting multicast reception using the second MRB). The predetermined processing can include the processing of receiving the multicast MCCH and / or the processing of receiving a new SIB for transmitting configuration information (multicast MCCH configuration) for receiving the multicast MCCH.

[0124] After performing the predetermined processing, in step S204, the UE 100 transitions from the RRC connected state to the RRC inactive state. In step S205, the UE 100 in the RRC inactive state continues to receive the multicast session #1.

[0125] On the other hand, when the multicast session #1 has not been activated (step S202: No), in step S206, the UE 100 suspends the execution of the predetermined processing for starting reception of the multicast session #1. For example, the UE 100 in the RRC connected state does not perform the processing of acquiring the configuration information (PTM configuration for the RRC inactive state) (including the processing for establishing the second MRB) and / or the processing of starting reception of the MTCH (i.e., the processing of starting multicast reception using the second MRB). Note that the UE 100 can perform the processing of storing (saving) the configuration information in its own memory.

[0126] After suspending the execution of the predetermined processing, in step S207, the UE 100 transitions from the RRC connected state to the RRC inactive state. In step S208, the UE 100 in the RRC inactive state waits for a paging message (i.e., a group notification) for notifying the activation of the multicast session #1 and receives the group notification.

[0127] Upon reception of the group notification, in step S209, the UE 100 in the RRC inactive state performs monitoring and receives the processing of the predetermined logical channel. The predetermined logical channel is: the multicast MCCH for transmitting configuration information for receiving the multicast session #1 in the RRC inactive state; and / or the MTCH for transmitting the multicast session #1. Here, the UE 100 can read the configuration information from the memory and apply the configuration information. In step S210, the UE 100 in the RRC inactive state receives the multicast session #1 transmitted on the MTCH.

[0128] (4.2) Example of operation sequence

[0129] Figure 9 is a diagram illustrating an example of an operation sequence of the mobile communication system 1 related to the second operation mode according to the embodiment.

[0130] In step S251, the UE 100 is in the RRC connected state in the cell of the gNB 200.

[0131] In step S252, the UE 100 in the RRC connected state joins the multicast session #1. Here, the UE 100 joins the multicast session #1 through communication (e.g., NAS signaling) with the CN 20. At this time, the UE 100 can acquire information on whether the multicast session #1 has been activated from the CN 20 (e.g., the AMF 300A).

[0132] In step S253, the gNB 200 transmits the RRC release message including the suspend configuration to the UE 100. The UE 100 in the RRC connected state receives the RRC release message. The RRC release message further includes the PTM configuration for the RRC inactive state of the multicast session #1. The PTM configuration for the RRC inactive state can be included in the suspend configuration. The PTM configuration can be a different information element from the suspend configuration.

[0133] In the second operation mode, the RRC release message can include session state information indicating whether the multicast session #1 has been activated. That is, when the PTM configuration is set for the UE 100 using the RRC release message, the gNB 200 notifies whether the multicast session #1 corresponding to the PTM configuration is in the activated state (i.e., ongoing state) or in the deactivated state (i.e., activation pending state). This notification can be performed per TMGI, per MRB, or per PTM configuration (MTCH configuration). Here, it will be assumed that the multicast session #1 has not been activated for description.

[0134] In step S254, the UE 100 identifies that the multicast session #1 is in the deactivated state based on the information from the CN 20 and / or the session status information in the RRC release message.

[0135] In step S255, the UE 100 suspends performing the predetermined process for starting receiving the multicast session #1. For example, the UE 100 does not apply but saves the PTM configuration for the RRC inactive state. Alternatively, the UE 100 can apply the PTM configuration but can not perform the MTCH reception. The UE 100 can not perform the process of receiving the multicast MCCH and the new SIB.

[0136] In step S256, the UE 100 transitions from the RRC connected state to the RRC inactive state.

[0137] In step S257, the UE 100 in the RRC inactive state starts monitoring the paging message for notifying the activation of the multicast session #1 (i.e., group notification).

[0138] Then, in step S258, the network 5 activates the multicast session #1.

[0139] In step S259, the gNB 200 transmits the paging message for notifying the activation of the multicast session #1 (i.e., group notification). The group notification includes the session identifier (TMGI) of the multicast session #1. The UE 100 in the RRC connected state receives the group notification and confirms that the group notification includes the session identifier of the multicast session #1 that the UE has joined.

[0140] In step S260, the gNB 200 can transmit a new SIB including the configuration of the multicast MCCH. The UE 100 in the RRC inactive state can acquire (receive) the new SIB in response to receiving the group notification in step S259.

[0141] In step S261, the gNB 200 can transmit the multicast MCCH including the PTM configuration for the RRC inactive state of the multicast session #1. The UE 100 in the RRC inactive state can acquire (receive) the multicast MCCH based on the new SIB of step S260.

[0142] In step S262, the gNB 200 transmits the MBS data (multicast data) of the multicast session #1 on the MTCH to the UE 100. The UE 100 in the RRC inactive state receives the multicast data (MTCH) based on the PTM configuration for the RRC inactive state of step S253 and / or the PTM configuration for the RRC inactive state of step S261.

[0143] (5) Third operation mode

[0144] Hereinafter, a third operation mode related to multicast reception in the RRC inactive state will be described focusing on the difference from the above-described operation modes. The third operation mode can be implemented in combination with the above-described operation modes. Note that the repetitive description of the similar operation to the above-described operation modes will be omitted.

[0145] As described in the operation mode 2, when the UE 100 in the RRC connected state and joined in the multicast session #1 sets the PTM configuration for the RRC inactive state in the RRC release message, the multicast session #1 can be deactivated. In this scenario (hereinafter also referred to as "scenario 1"), when the multicast session #1 is activated after the UE 100 transitions to the RRC inactive state, the PTM configuration for the RRC inactive state can be modified. In this case, the UE 100 needs to update the saved PTM configuration for the RRC inactive state to the new PTM configuration for the RRC inactive state. In this case, the UE 100 acquires the new PTM configuration for the RRC inactive state by receiving the multicast MCCH, and receives the activated multicast session #1 on the MTCH based on the new PTM configuration for the RRC inactive state.

[0146] Alternatively, as described in the above-described operation mode 1, a scenario is assumed in which the UE 100 that has transitioned to the RRC inactive state is receiving the activated (i.e., ongoing) multicast session #1 on the MTCH. In this scenario (hereinafter also referred to as "scenario 2"), the network 5 can modify the PTM configuration for the RRC inactive state of the ongoing multicast session #1. In this case, the UE 100 acquires the new PTM configuration for the RRC inactive state by receiving the multicast MCCH, and receives the ongoing multicast session #1 on the MTCH based on the new PTM configuration for the RRC inactive state.

[0147] In scenarios 1 and 2, as with the MBS broadcast, it can be envisaged that the UE 100 in the RRC inactive state is notified of the update of the multicast MCCH information (the PTM configuration for the RRC inactive state) by using the MCCH change notification for the MBS multicast. The UE 100 cannot identify whether the MBS session is the target of the update of the PTM configuration for the RRC inactive state only by using the MCCH change notification.

[0148] Thus, in scenario 1, even if the UE 100 in the RRC inactive state receives the multicast MCCH in response to receiving the MCCH change notification, the PTM configuration for the RRC inactive state of the multicast session #1 that the UE is interested in receiving can not be included in the received multicast MCCH. Similarly, in scenario 2, even if the UE 100 in the RRC inactive state receives the multicast MCCH in response to receiving the MCCH change notification, in the received multicast MCCH, the PTM configuration for the RRC inactive state of the multicast session #1 that the UE is receiving can not be changed. Thus, since the reception of the multicast MCCH can be wasted, there is a problem in terms of reducing the power consumption of the UE 100.

[0149] The UE 100 that is receiving or interested in receiving the multicast session #1 needs to receive and decode the PDCCH at least once in each MCCH modification period in order to receive the MCCH change notification in the RRC inactive state. Thus, there is a problem in terms of reducing the power consumption of the UE 100.

[0150] To solve the above problem, a group notification (i.e., a paging message including a session identifier) is used in the operation mode 3. The UE 100 in the RRC inactive state receives (monitors) the paging message in its paging occasion, regardless of whether it is receiving (or interested in receiving) the multicast session. Thus, by using the group notification to notify the UE 100 of the change of the multicast MCCH (PTM configuration for the RRC inactive state), the UE 100 can receive (monitor) the multicast MCCH more efficiently than when the MCCH change notification is used.

[0151] (5.1) Overview of the operation of the UE

[0152] Figure 10 is a diagram illustrating an overview of the operation of the UE 100 related to the third operation mode according to the embodiment. In Figure 10 In steps S31 and S32 of, it is assumed that the UE 100 is in the RRC connected state or the RRC inactive state. In Figure 10 In steps S33 to S37 of, it is assumed that the UE 100 is in the RRC inactive state.

[0153] In step S31, the UE 100 receives a first PTM configuration for receiving the multicast session #1 in the RRC inactive state (hereinafter also referred to as "first PTM configuration for RRC inactive state") from the network 5. For example, the UE 100 in the RRC connected state receives an RRC release message including the first PTM configuration for RRC inactive state from the gNB 200. Alternatively, the UE 100 in the RRC inactive state receives a multicast MCCH including the first PTM configuration for RRC inactive state from the gNB 200. Although details will be described below, in the first operation example of the third operation mode, the first PTM configuration for RRC inactive state of the multicast session #1 is associated with version information (hereinafter also referred to as "value tag").

[0154] In step S32, the UE 100 saves the first PTM configuration for RRC inactive state received in step S31. Here, when the multicast session #1 has not been activated, the UE 100 saves the first PTM configuration for RRC inactive state received in step S31 without applying the PTM configuration, similarly to the second operation mode described above. On the other hand, when the multicast session #1 has been activated, the UE 100 saves the first PTM configuration for RRC inactive state received in step S31 while applying the PTM configuration, similarly to the first operation mode described above. In this case, the UE 100 receives the multicast session #1 on the MTCH based on the first PTM configuration for RRC inactive state.

[0155] In step S33, the UE 100 in the RRC inactive state receives a paging message (i.e., group notification) including a session identifier (TMGI) of the multicast session #1 from the network 5 (gNB 200). Note that in the technical specification of 3GPP Release 17, since only the UE 100 in the RRC connected state can receive MBS multicast, when the UE 100 in the RRC inactive state receives a paging message (group notification) including a session identifier of the multicast session #1 to which the UE has joined, the UE transitions to the RRC connected state to perform multicast reception. In contrast, in the present embodiment (third operation mode), when the UE 100 in the RRC inactive state receives a paging message (group notification) including a session identifier of the multicast session #1 to which the UE has joined, the UE remains in the RRC inactive state without transitioning to the RRC connected state.

[0156] In step S34, in response to receiving the group notification of step S33, the UE 100 in the RRC inactive state determines whether the first PTM configuration for RRC inactive state saved in step S32 needs to be updated.

[0157] In step S35, in response to determining that the first PTM configuration for the RRC inactive state needs to be updated, the UE 100 in the RRC inactive state performs a reception process of the multicast MCCH. The reception process of the multicast MCCH can include reception of a new SIB and reception of the multicast MCCH.

[0158] In step S36, the UE 100 in the RRC inactive state receives (acquires) the second PTM configuration for receiving the multicast session #1 (hereinafter also referred to as "the second PTM configuration for the RRC inactive state") on the multicast MCCH and updates the first PTM configuration for the RRC inactive state using the second PTM configuration for the RRC inactive state.

[0159] In step S37, the UE 100 in the RRC inactive state receives the multicast session #1 on the MTCH based on the second PTM configuration for the RRC inactive state.

[0160] In the first operating example of the third operating mode, step S32 includes a step of saving the first PTM configuration for the RRC inactive state in association with a value tag as version information. Step S34 includes steps of receiving, from the network 5 (gNB 200), signaling including a latest value tag of the PTM configuration for the RRC inactive state for receiving the multicast session #1 and determining whether the first PTM configuration for the RRC inactive state needs to be updated by comparing the saved value tag with the latest value tag. Here, the signaling including the latest value tag is the paging message (group notification) of step S33, a system information block type 1 (SIB1) transmitted from the network 5 (gNB 200), or a new SIB indicating a configuration of the multicast MCCH.

[0161] In the first operating example of the third operating mode, step S34 can include a step of determining that the first PTM configuration for the RRC inactive state needs to be updated when the latest value tag is not included in the signaling. Step S34 can include a step of determining that the first PTM configuration for the RRC inactive state needs to be updated based on the fact that the RRC release message in step S31 does not include the first PTM configuration for the RRC inactive state.

[0162] In the second operation example of the third operation mode, step S34 can include the following step: in response to the paging message (group notification) or the new SIB including the PTM configuration update information for the RRC inactive state, determining that the first PTM configuration for the RRC inactive state needs to be updated. The update information can be 1-bit flag information. For example, in step S34, in response to the group notification or the new SIB including the PTM configuration update information for the RRC inactive state, the UE 100 in the RRC inactive state can determine that the first PTM configuration for the RRC inactive state needs to be updated.

[0163] In the second operation example of the third operation mode, the paging message (group notification) including the session identifier can include a UE identifier associated with the session identifier. In the group notification, the PTM configuration update information can be associated with the UE identifier. In the group notification, the PTM configuration update information can be associated with the session identifier. Alternatively, the new SIB can include the session identifier, and the PTM configuration update information can be associated with the session identifier in the new SIB.

[0164] (5.2) First operation example

[0165] Figure 11 is a diagram illustrating an example of the first operation example of the third operation mode according to the embodiment. Figure 11 The operation example of assumes Scenario 1 using the above-described second operation mode. However, in the above-described second operation mode, it is assumed that the PTM configuration for the RRC inactive state configured by the RRC release message is not changed at the time of session activation for the deactivated multicast session #1. In contrast, in the operation example of Figure 11 In the operation example of, it is assumed that the PTM configuration for the RRC inactive state configured by the RRC release message is changed at the time of session activation (i.e., in the case of update being required). Note that the repeated description of the similar operation to the above-described second operation mode will be omitted.

[0166] In step S301, the UE 100 is in the RRC connected state in the cell of the gNB 200.

[0167] In step S302, the UE 100 in the RRC connected state joins the multicast session #1. Here, the UE 100 joins the multicast session #1 through communication (e.g., NAS signaling) with the CN 20. However, the network 5 has not activated the multicast session #1.

[0168] In step S303, the gNB 200 sends an RRC release message including the suspend configuration to the UE 100 in the RRC connected state. The UE 100 in the RRC connected state receives the RRC release message. The RRC release message further includes the PTM configuration for the RRC inactive state for the multicast session #1 (first PTM configuration). The PTM configuration for the RRC inactive state can be included in the suspend configuration. The RRC release message can be a different information element from the suspend configuration. In this operational example, a value tag is set in the PTM configuration for the RRC inactive state. The value tag can be included in the PTM configuration for the RRC inactive state. The value tag can be a different information element from the PTM configuration for the RRC inactive state.

[0169] In step S304, the UE 100 in the RRC connected state saves the PTM configuration for the RRC inactive state received in step S303 in association with the value tag.

[0170] In step S305, the UE 100 transitions from the RRC connected state to the RRC inactive state.

[0171] In step S306, the UE 100 in the RRC inactive state starts monitoring paging. Specifically, the UE 100 in the RRC inactive state wakes up and monitors the paging channel (paging message) within its own paging occasion.

[0172] In step S307, the gNB 200 can determine to change the PTM configuration for the RRC inactive state for the multicast session #1 depending on the radio conditions of its own cell. The gNB 200 increments (i.e., adds 1 to) the value tag of the changed PTM configuration for the RRC inactive state.

[0173] In step S308, the network 5 activates the multicast session #1.

[0174] In step S309, the gNB 200 sends a paging message (group notification) including the session identifier of the multicast session #1. The UE 100 in the RRC inactive state receives the group notification from the gNB 200. The group notification can include the value tag associated with the current (latest) PTM configuration for the RRC inactive state. Note that there can be a value tag per session identifier (TMGI), per MRB identifier, or per PTM configuration.

[0175] The UE 100 in the RRC inactive state identifies that the multicast session #1 to which the UE joins has been activated based on the session identifier included in the group notification. When the group notification includes the value tag associated with the session identifier, the UE 100 in the RRC inactive state acquires the value tag from the group notification. When the value tag is not included in the group notification, the UE 100 in the RRC inactive state can receive the SIB1 or the new SIB, and acquire the value tag from the received SIB1 or the new SIB. In this case, the SIB1 or the new SIB can include the set of the session identifier and the value tag.

[0176] In step S310, the UE 100 in the RRC inactive state compares the value tag for the PTM configuration in the RRC inactive state saved by the UE (set by the RRC release message) with the value tag acquired in step S309.

[0177] Here, when the value tags match, the UE 100 applies the saved PTM configuration in the RRC inactive state (if not applied), and starts receiving the MTCH of the multicast session #1. In this case, the UE 100 starts receiving the MTCH without receiving the multicast MCCH and / or the new SIB.

[0178] On the other hand, when the value tags do not match or when the value tag cannot be acquired (not provided), the UE 100 identifies that the PTM configuration in the RRC inactive state has been updated, and receives the multicast MCCH (and the new SIB (as needed)) (step S311 and step S312). Here, the UE 100 can acquire the new SIB for receiving the multicast MCCH (step S311). The UE 100 receives the multicast MCCH (step S312), acquires and applies the latest PTM configuration in the RRC inactive state (second PTM configuration) provided on the multicast MCCH, and starts receiving the MTCH of the multicast session #1 (step S313).

[0179] Note that when the PTM configuration in the RRC inactive state is not provided in the RRC release message of step S303, the UE 100 can consider that the value tags do not match (the PTM configuration in the RRC inactive state is updated) in step S310.

[0180] In step S313, the UE 100 in the RRC inactive state continues to receive the multicast session #1.

[0181] Note that in the present operation example, the method for notifying the value tag of the latest multicast MCCH has been described by exemplifying three methods including the method using the group notification, the method using the new SIB, and the method using the SIB1.

[0182] In the method using group notification, the UE 100 waiting for session activation monitors paging, so it can confirm whether the PTM configuration for the RRC inactive state has been updated with the minimum delay without additional power consumption.

[0183] The specification of the method using new SIB is easy to extend, but since the UE 100 needs to monitor the new SIB, additional power consumption is required to check whether the PTM configuration for the RRC inactive state has been updated, and there is also a delay before the new SIB is acquired. When the value tag of the multicast MCCH is changed, a certain degree of improvement can be achieved by adopting a rule to update the value tag of the new SIB (the value tag notified in SIB1). The UE 100 can check SIB1, and if the value tag of the new SIB has not been changed, determine that the value tag of the multicast MCCH has not been changed.

[0184] In the method using SIB1, the UE 100 always checks SIB1, so it can confirm whether the PTM configuration for the RRC inactive state has been updated without additional power consumption. Increasing the message size of SIB1 is generally undesirable.

[0185] Figure 12 is a diagram illustrating another example of the first operation example of the third operation mode according to the embodiment. The present operation example is premised on the above-described scenario 2. Note that a repeated description of operations similar to those in Figure 11 will be omitted.

[0186] In step S331, the network 5 activates the multicast session #1.

[0187] In step S332, the UE 100 transitions from the RRC connected state to the RRC inactive state.

[0188] In step S333, the gNB 200 transmits a new SIB including the configuration of the multicast MCCH. The UE 100 in the RRC inactive state receives the new SIB.

[0189] In step S334, the gNB 200 transmits the PTM configuration for the RRC inactive state of the multicast session #1 on the multicast MCCH. The UE 100 in the RRC inactive state receives the PTM configuration for the RRC inactive state based on the new SIB, and saves the received PTM configuration for the RRC inactive state as the first PTM configuration. Here, the PTM configuration for the RRC inactive state is associated with the value tag.

[0190] In step S335, the gNB 200 transmits the MBS data of the multicast session #1 on the MTCH. The UE 100 in the RRC inactive state receives the MBS data of the multicast session #1 on the MTCH based on the PTM configuration for the RRC inactive state.

[0191] In step S336, the gNB 200 can determine to change the PTM configuration for the RRC inactive state of the multicast session #1 depending on the radio conditions of its own cell. The gNB 200 increments (i.e., adds 1 to) the value tag of the changed PTM configuration for the RRC inactive state.

[0192] In step S337, the gNB 200 transmits a paging message (group notification) including the session identifier of the multicast session #1. The UE 100 in the RRC inactive state receives the group notification from the gNB 200. The group notification can include the value tag associated with the current (latest) PTM configuration for the RRC inactive state. Note that there can be a value tag per session identifier (TMGI), per MRB identifier, or per PTM configuration.

[0193] When the group notification includes the value tag associated with the session identifier, the UE 100 in the RRC inactive state acquires the value tag from the group notification. When the value tag is not included in the group notification, the UE 100 in the RRC inactive state can receive the SIB1 or a new SIB and acquire the value tag from the received SIB1 or new SIB. In this case, the SIB1 or new SIB can include a set of session identifiers and value tags.

[0194] In step S338, the UE 100 in the RRC inactive state compares the value tag of the PTM configuration for the RRC inactive state saved by the UE (set in step S334) with the value tag acquired in step S337.

[0195] Here, when the value tags match, the UE 100 keeps the saved PTM configuration for the RRC inactive state and continues to receive the MTCH of the multicast session #1 (step S341).

[0196] On the other hand, when the value tag does not match or when the value tag cannot be acquired (not provided), the UE 100 recognizes that the PTM configuration for the RRC inactive state has been updated, and receives the multicast MCCH (and the new SIB (as needed)) (step S339 and step S340). Here, the UE 100 can acquire the new SIB for receiving the multicast MCCH (step S339). The UE 100 receives the multicast MCCH (step S340), acquires and applies the latest PTM configuration (second PTM configuration) for the RRC inactive state provided on the multicast MCCH, and continues to receive the MTCH of the multicast session #1 (step S341).

[0197] (5.3) Second operation example

[0198] In the second operation example of the third operation mode, the PTM configuration update information as 1-bit flag information is used instead of the above-described value tag. The gNB 200 that changes the PTM configuration for the RRC inactive state can notify the UE 100 of the change in the PTM configuration for the RRC inactive state corresponding to the session identifier by transmitting the session identifier and the PTM configuration update information associated with the session identifier in the group notification or the new SIB. Alternatively, the gNB 200 that changes the PTM configuration for the RRC inactive state can notify the UE 100 indicated by the UE identifier of the change in the PTM configuration for the RRC inactive state by transmitting the UE identifier and the PTM configuration update information associated with the UE identifier in the group notification.

[0199] Figure 13 is a diagram illustrating an example of the second operation example of the third operation mode according to the embodiment. Figure 13 The operation example of assumes Scenario 1 using the above-described second operation mode. However, in the above-described second operation mode, it is assumed that the PTM configuration for the RRC inactive state configured by the RRC release message is not changed at the time of session activation for the deactivated multicast session #1. In contrast, Figure 13 The operation example of assumes that the PTM configuration for the RRC inactive state configured by the RRC release message is changed at the time of session activation (i.e., in the case of update being required). Note that the repetitive description of the similar operation to the above-described second operation mode will be omitted.

[0200] In step S351, the UE 100 is in the RRC connected state in the cell of the gNB 200.

[0201] In step S352, the UE 100 in the RRC connected state joins the multicast session #1. Here, the UE 100 joins the multicast session #1 through communication with the CN 20 (e.g., NAS signaling). However, the network 5 has not activated the multicast session #1 yet.

[0202] In step S353, the gNB 200 transmits an RRC release message including a suspend configuration to the UE 100 in the RRC connected state. The UE 100 in the RRC connected state receives the RRC release message. The RRC release message further includes a PTM configuration for the RRC inactive state (first PTM configuration) of the multicast session #1. The PTM configuration for the RRC inactive state can be included in the suspend configuration. The PTM configuration can be a different information element from the suspend configuration.

[0203] In step S354, the UE 100 in the RRC connected state saves the PTM configuration for the RRC inactive state received in step S353.

[0204] In step S355, the UE 100 transitions from the RRC connected state to the RRC inactive state.

[0205] In step S356, the UE 100 in the RRC inactive state starts monitoring paging.

[0206] In step S357, the gNB 200 can determine to change the PTM configuration for the RRC inactive state of the multicast session #1 depending on the radio conditions of its own cell.

[0207] In step S358, the network 5 activates the multicast session #1.

[0208] In step S359, the gNB 200 transmits a paging message (group notification) including the session identifier of the multicast session #1.

[0209] To change the PTM configuration, the gNB 200 includes 1-bit PTM configuration update information with the session identifier (and the UE identifier) in the group notification. The PTM configuration update information can be information indicating whether the PTM configuration for the RRC-Inactive state has been updated. The PTM configuration update information can be information indicating whether the multicast MCCH acquisition is needed. In the group notification, the PTM configuration update information can be associated with the session identifier (or the UE identifier). For example, the group notification can include the PTM configuration update information in units of entries of the paging group list (which is the session identifier list). The group notification can include the PTM configuration update information in units of entries of the aging record list (which is the UE identifier list). Note that the PTM configuration update information can be configured by a bitmap, and each bit of the bitmap can take the form of referencing (pointing to) each entry (i.e., each UE identifier or each session identifier) in the paging record list or the paging group list.

[0210] In step S360, the UE 100 in the RRC-Inactive state can identify that the multicast session #1 to which the UE joins has been activated based on the session identifier included in the group notification. When the group notification includes the PTM configuration update information associated with the session identifier, the UE 100 can determine that the PTM configuration of the multicast session #1 needs to be updated. When the group notification includes the UE identifier identical to the UE identifier of the UE 100 and the PTM configuration update information associated with the UE identifier, the UE 100 can determine that the PTM configuration (the PTM configuration of the multicast session #1) held by itself needs to be updated.

[0211] Here, when the group notification does not include the PTM configuration update information, if the PTM configuration for the RRC-Inactive state is not applied, the UE 100 in the RRC-Inactive state applies the held PTM configuration for the RRC-Inactive state and starts receiving the MTCH of the multicast session #1 (step S363). In this case, the UE 100 starts receiving the MTCH without receiving the multicast MCCH and / or the new SIB.

[0212] On the other hand, when the group notification includes the PTM configuration update information, the UE 100 in the RRC-Inactive state identifies that the PTM configuration for the RRC-Inactive state has been updated and receives the multicast MCCH (and the new SIB (as needed)) (steps S361 and S362). The UE 100 acquires and applies the latest PTM configuration for the RRC-Inactive state from the received multicast MCCH and starts receiving the MTCH of the multicast session #1 (step S363).

[0213] Note that in the present operation example, the UE 100 can consider that the PTM configuration for the RRC inactive state has been updated even if the group notification does not include the PTM configuration update information, when the RRC release message of step S353 does not include the PTM configuration for the RRC inactive state.

[0214] Figure 14 is a diagram illustrating another example of a second operation example of the third operation mode according to the embodiment. The present operation example is premised on the above-described scenario 2. Note that a repetitive description of operations similar to those in Figure 13 will be omitted.

[0215] In step S371, the network 5 activates the multicast session #1.

[0216] In step S372, the UE 100 transitions from the RRC connected state to the RRC inactive state.

[0217] In step S373, the gNB 200 transmits a new SIB including the multicast MCCH configuration. The UE 100 in the RRC inactive state receives the new SIB.

[0218] In step S374, the gNB 200 transmits the PTM configuration for the RRC inactive state of the multicast session #1 on the multicast MCCH. The UE 100 in the RRC inactive state receives the PTM configuration for the RRC inactive state based on the new SIB, and saves the received PTM configuration for the RRC inactive state as the first PTM configuration.

[0219] In step S375, the gNB 200 transmits the MBS data of the multicast session #1 on the MTCH. The UE 100 in the RRC inactive state receives the MBS data of the multicast session #1 on the MTCH based on the PTM configuration for the RRC inactive state.

[0220] In step S376, the gNB 200 can determine to change the PTM configuration for the RRC inactive state of the multicast session #1 depending on the radio conditions of its own cell. The gNB 200 increments (i.e., adds 1 to) the value tag of the changed PTM configuration for the RRC inactive state.

[0221] In step S377, the gNB 200 transmits a paging message (group notification) including the session identifier of the multicast session #1. To change the PTM configuration, the gNB 200 includes the 1-bit PTM configuration update information in the group notification together with the session identifier (and the UE identifier). The description about the PTM configuration update information is the same as that of Figure 13 .

[0222] In step S378, when the group notification includes the PTM configuration update information associated with the session identifier of the multicast session #1, the UE 100 can determine that the PTM configuration of the multicast session #1 needs to be updated. When the group notification includes the UE identifier identical to the UE identifier of the UE 100 and the PTM configuration update information associated with the UE identifier, the UE 100 can determine that the PTM configuration (the PTM configuration of the multicast session #1) held by itself needs to be updated.

[0223] When the PTM configuration update information is not included in the group notification, the UE 100 keeps the held PTM configuration for the RRC inactive state, and continues to receive the MTCH of the multicast session #1 (step S381).

[0224] On the other hand, when the group notification includes the PTM configuration update information, the UE 100 recognizes that the PTM configuration for the RRC inactive state has been updated, and receives the multicast MCCH (and the new SIB (as necessary)) (steps S379 and S380). Here, the UE 100 can acquire the new SIB for receiving the multicast MCCH (step S379). The UE 100 receives the multicast MCCH (step S380), acquires and applies the latest PTM configuration (second PTM configuration) for the RRC inactive state provided on the multicast MCCH, and continues to receive the MTCH of the multicast session #1 (step S381).

[0225] (6) Other Embodiments

[0226] Although the multicast reception in the RRC inactive state has been mainly described in the above-described embodiments, the operation according to the above-described embodiments is also applicable to the multicast reception in the RRC idle state. For the RRC idle state, the above-described RRC resume can be read as RRC establishment.

[0227] The above-described operation flows can be implemented separately and independently, and can also be implemented by a combination of two or more operation flows. For example, some steps in one operation flow can be added to another operation flow, or some steps in one operation flow can be replaced with some steps in another operation flow. In each flow, not all steps are necessarily executed, but only some steps can be executed.

[0228] Although the example in which the base station is an NR base station (gNB) has been described in the above-described embodiments and examples, the base station can be an LTE base station (eNB) or a 6G base station. The base station can be a relay node, such as an integrated access and backhaul (IAB) node. The base station can be a DU of an IAB node. The UE 100 can be a mobile terminal (MT) of an IAB node.

[0229] That is, the UE 100 can be a terminal function unit (a kind of communication module) with which the base station controls a repeater that performs signal relaying. Such a terminal function unit is referred to as an MT. Examples of the MT include, in addition to the IAB-MT, a network-controlled repeater (NCR)-MT, a reconfigurable intelligent surface (RIS)-MT.

[0230] The term "network node" mainly refers to a base station, but can also refer to a core network device or to a part of a base station (CU, DU, or RU). The network node can include a combination of at least part of a device of a core network and at least part of a base station.

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

[0232] The functions implemented by the UE 100, the gNB 200 (network node) can be implemented in circuitry or processing circuitry programmed or configured to implement the functions, including general-purpose processors, special-purpose processors, integrated circuits, application-specific integrated circuits (ASIC, central processing unit (CPU)), conventional circuitry, and / or combinations thereof. The processor can include transistors and other circuitry and can be considered a circuit or processing circuitry. The processor can be a programmed processor that executes programs stored in memory. As used herein, circuitry, unit, or device is hardware programmed to implement the stated functions or hardware that implements the stated functions. The hardware can be any hardware disclosed herein or any hardware programmed to implement the stated functions or known to implement the stated functions. When the hardware is a processor considered to be a certain type of circuitry, the circuitry, device, or unit is a combination of the hardware and software for configuring the hardware and / or the processor.

[0233] The phrase "based on" and "in response to" as used herein, unless specifically stated to the contrary, are not meant to limit the subject application to "only based on" and "only in response to" but rather, are to be taken using the ordinary and accepted meanings. The phrase "based on" indicates both "based only on" and "based at least in part on". The phrase "in response to" indicates both "in response only to" and "in response at least in part to". The term "comprises", "comprising", and variations thereof do not have a limiting meaning and indicate the possibility of a more limited number of steps or items or a possibility of a more expansive number of steps or items. The term "or" as used herein is not meant to be exclusive, unless specifically stated to the contrary. Any reference herein to names of elements using terminology such as "first" and "second" is generally not limiting of the number or order of such elements, unless specifically stated to be so. Such names are merely used herein as a convenient method of distinguishing between two or more elements. Thus, use of the term "first" and "second" in referring to an element does not necessarily imply that there can be only two of such elements, nor does it imply a particular order of such elements. For example, when English articles such as "a", "an" and "the" are added to the present disclosure by way of translation, these articles include the plural unless the context clearly indicates otherwise.

[0234] Embodiments have been described above with reference to the accompanying drawings, but the specific configurations are not limited to the above-described configurations, and various design changes can be made without departing from the gist of the present disclosure.

[0235] This application claims priority to U.S. Provisional Patent Application No. 63 / 494316 (filed on April 5, 2023), the entire contents of which are incorporated herein by reference.

[0236] (7) Supplement A

[0237] Features related to the above-described embodiments are described below as supplements.

[0238] (Supplement 1)

[0239] A communication method performed by a user equipment in a mobile communication system providing a multicast / broadcast service (MBS), the communication method comprising:

[0240] receiving a first PTM configuration from a network, the first PTM configuration being for receiving a multicast session in a radio resource control, RRC, inactive state, and saving the first PTM configuration;

[0241] in the RRC inactive state, in response to receiving a paging message from the network, the paging message including a session identifier of the multicast session, determining whether the first PTM configuration needs to be updated; and

[0242] In the RRC inactive state, in response to determining that the first PTM configuration needs to be updated, a second PTM configuration for receiving the multicast session is acquired by receiving a multicast control channel, MCCH, for the multicast communication.

[0243] (Supplement 2)

[0244] The communication method according to Supplement 1, further comprising:

[0245] In the RRC connected state, an RRC release message is received, which causes the user equipment to transition to the RRC inactive state; and

[0246] In response to receiving the RRC release message, transitioning from the RRC connected state to the RRC inactive state,

[0247] The RRC release message includes a first PTM configuration.

[0248] (Supplement 3)

[0249] The communication method according to Supplement 1 or 2, wherein:

[0250] The saving comprises saving the first PTM configuration in association with version information, and

[0251] The determining comprises:

[0252] Receiving signaling from the network, the signaling including latest version information of a PTM configuration for receiving the multicast session; and

[0253] Determining whether the first PTM configuration needs to be updated by comparing the saved version information with the latest version information.

[0254] (Supplement 4)

[0255] The communication method according to Supplement 3, wherein the signaling is the paging message.

[0256] (Supplement 5)

[0257] The communication method according to Supplement 3, wherein the signaling is a system information block type 1 sent from the network.

[0258] (Supplement 6)

[0259] The communication method according to Supplement 3, wherein the signaling is a system information block (SIB) indicating a configuration of a MCCH for the multicast communication.

[0260] (Supplement 7)

[0261] The communication method according to any one of Supplements 3 to 6, wherein the determining comprises determining that the first PTM configuration needs to be updated when the signaling does not comprise the latest version information.

[0262] (Supplement 8)

[0263] The communication method according to any one of Supplements 1 to 7, further comprising:

[0264] receiving, in the RRC connected state, an RRC release message causing the user equipment to transition to the RRC inactive state; and

[0265] in response to receiving the RRC release message, transitioning from the RRC connected state to the RRC inactive state,

[0266] wherein the determining comprises determining that the first PTM configuration needs to be updated based on the RRC release message not comprising the first PTM configuration.

[0267] (Supplement 9)

[0268] The communication method according to Supplement 1 or 2, wherein the determining comprises determining that the first PTM configuration needs to be updated in response to the paging message or the system information block comprising PTM configuration update information.

[0269] (Supplement 10)

[0270] The communication method according to Supplement 9, wherein:

[0271] the paging message comprises a user equipment identifier associated with the session identifier, and

[0272] in the paging message, the PTM configuration update information is associated with the user equipment identifier.

[0273] (Supplement 11)

[0274] The communication method according to Supplement 9, wherein, in the paging message, the PTM configuration update information is associated with the session identifier.

[0275] (Supplement 12)

[0276] The communication method according to Supplement 9, wherein:

[0277] the system information block comprises the session identifier, and

[0278] in the system information block, the PTM configuration update information is associated with the session identifier.

[0279] (Supplement 13)

[0280] A user equipment for use in a mobile communication system providing a multicast / broadcast service (MBS), the user equipment comprising a controller configured to perform the following processing:

[0281] receiving a first PTM configuration from a network and saving the first PTM configuration, the first PTM configuration being for receiving a multicast session in a radio resource control, RRC, inactive state;

[0282] in the RRC inactive state, in response to receiving a paging message from the network, the paging message including a session identifier of the multicast session, determining whether the first PTM configuration needs to be updated; and

[0283] in the RRC inactive state, in response to determining that the first PTM configuration needs to be updated, acquiring a second PTM configuration for receiving the multicast session by receiving a multicast control channel, MCCH, for multicast communication.

[0284] (8) Supplement B

[0285] 1. Introduction

[0286] The work item on enhancements for MBS (eMBS) aims to support multicast reception by UEs in an inactive state, and is described as follows.

[0287] • Define support for multicast reception by UEs in RRC inactive state [RAN 2, RAN 3]

[0288] • PTM configuration of UEs receiving multicast in RRC inactive state [RAN2]

[0289] • Investigate the impact of mobility and state transitions for UEs receiving multicast in RRC inactive state (no seamless / non-lossy mobility required) [RAN 2, RAN 3]

[0290] RAN2 has discussed this purpose and reached a series of agreements. Based on these agreements, the issues of multicast reception in the inactive state and notification of RRC state transition have been discussed in the supplement.

[0291] 2. Discussion

[0292] In RAN2#119e, further study of RRC state changes is needed.

[0293] In Release 18, multicast reception by UEs in an inactive state supports at least the following scenarios based on the premise that the UE already has a valid PTM configuration.

[0294] • Scenario 1: The UE receives the multicast while in connected state, but it enters inactive state and continues to receive the multicast.

[0295] • Scenario 2: The UE has joined the multicast session and has been induced to the inactive state.

[0296] Further study is needed for the case of state change, such as the case of ending the service provision in the inactive state.

[0297] Various cases related to RRC state change are considered from the network and UE perspectives. Some of these cases also involve the notification sent by the network to the UE. Therefore, each case will be discussed below.

[0298] 2.1. Scenario 1: Deactivation / release of multicast session

[0299] RAN2#119bis-e has agreed that the UE is informed of the deactivation of the multicast session when the multicast session is deactivated, and the Rel-17 mechanism is applied when the multicast session is released.

[0300] • When the UE is in RRC inactive state and is configured to receive the multicast session in RRC inactive state, the UE is informed of the deactivation if the multicast session is deactivated. The details need further study. For example, the method (e.g., notification via group paging, MCCH or other method) needs further study.

[0301] The Rel-17 mechanism (NAS-based indication) is applicable to multicast session release. Further study is needed when the functionality extension is needed.

[0302] It can be considered that when the UE in inactive state is receiving the MBS service, the multicast session is stopped or released, and the gNB stops the transmission of PTM / MTCH accordingly. In this case, the UE has no reason to continue monitoring the MTCH; however, the UE needs to monitor the MTCH as long as the PTM configuration is not deleted. From the power saving perspective of the UE, it is desirable to stop monitoring the MTCH as soon as possible.

[0303] Observation 1: The UE continues to monitor the PTM / MTCH even after the multicast session is stopped or released, which is inefficient from the power consumption perspective of the UE.

[0304] That is, regardless of which notification method is used, the UE is entitled to be allowed to stop monitoring the MTCH when receiving the notification of the deactivation of the multicast session. The UE needs to remain in RRC inactive state when receiving such notification.

[0305] Proposal 1: RAN2 needs to agree that the UE can stop monitoring the MTCH when receiving the notification of the deactivation of the multicast session.

[0306] For deactivation of a multicast session, RAN2 needs to further study the method for notifying the UE of the deactivation, e.g., by group paging, MCCH, or other methods.

[0307] According to LTE SC-PTM, in order to perform the notification that the UE stops monitoring the PDCCH for G-RNTI, the SC-PTM stop indication MAC CE is introduced and multiplexed onto the SC-MTCH associated with the G-RNTI. This lightweight signaling can work under the restriction of one-to-one mapping between TMGI and G-RNTI. On the other hand, since NR MBS allows many-to-one mapping between TMGI and G-RNTI, the indication of the deactivated TMGI is needed when introducing this MAC CE. Since the MAC CE is sent together with the MTCH, the delay from receiving the last multicast data to stopping MTCH monitoring is expected to be minimized.

[0308] Another option is to reuse group paging. Group paging is used to page multiple UEs in a group simultaneously using TMGI instead of UE-ID. Since the existing paging group list (i.e., TMGI list) can be applied to legacy UEs, group paging needs to add a new TMGI list for deactivation notification to avoid impact on legacy UEs. Since group paging is sent within the paging occasion, there is a certain degree of delay from receiving the last multicast data to stopping MTCH monitoring based on the I-DRX cycle.

[0309] A third option is to reuse MCCH. There are two methods to perform the notification of the stop of the multicast session: deleting the PTM configuration of the stopped TMGI, and adding a new indication for performing the notification of the stopped TMGI. Since the MCCH needs to be updated in any case, the MCCH change notification needs to be sent to the UE in advance. Therefore, a longer delay is required from when the last multicast data is received until when MTCH monitoring is stopped.

[0310] According to the RAN2 agreement, “MCCH is used when PTM configuration needs to be changed” can be interpreted as the need to wake up the UE in the inactive state in the MCCH, and the stop of the multicast session is considered as a type of “change of PTM configuration”. Therefore, when the corresponding PTM configuration is deleted from the MCCH, the UE can know that the multicast session has been deactivated. However, it takes time for the UE to stop monitoring the MTCH. Therefore, notification by MAC CE is desirable.

[0311] In summary, the delay between receiving the last multicast data and stopping the MTCH monitoring can directly impact the unnecessary power consumption increase of the UE. From the UE power saving perspective, it is desirable to send the notification as soon as possible, and the first option of using MAC CE is the desired solution.

[0312] Proposal 2: RAN2 needs to agree that a new MAC CE (e.g. existing SC-PTM stop indication) should be informed to the UE in inactive state when the multicast session is deactivated.

[0313] For the release of the multicast session, the RAN2 agreed NAS based indication in Rel-17 applies, which can indicate that the multicast session has been requested by releasing the network or MBS session. The procedure assumes that the UE is paged by the gNB and transitions to RRC connected state to communicate with the AMF. In this procedure, it is assumed that the existing group paging (or legacy individual paging) can be reused.

[0314] That is, the gNB sends the MAC CE to allow the UE to stop monitoring the MTCH, and then the gNB can distribute the timing of the paging to the UE (i.e. using legacy individual paging), thus being able to avoid the signaling storm caused by simultaneous transition to RRC state.

[0315] Proposal 3: RAN 2 needs to agree that dedicated functionality extension in multicast session release is not necessary, i.e. the UE transitions to RRC connected state by using the existing (group) paging.

[0316] 2.2. Case 2: Selective transition case during the active multicast session

[0317] RAN2#119e has reached the following agreements for Case 2.

[0318] • Whether the UE (or UEs) can receive the multicast session in inactive state is up to the gNB. Further study is needed on what information to be provided to the gNB to make the decision (related to SA2 discussion).

[0319] • The gNB supports one multicast session for UEs in connected state and UEs in inactive state in the same cell. How the gNB configures the support needs further study.

[0320] • It is assumed that the network can choose the UEs to receive the multicast session in RRC inactive state and in RRC connected state and can make the UEs switch between the states of receiving the multicast service.

[0321] When a gNB releases a UE to be in inactive state, based on UE capability, UE assistance information and / or CN assistance information (when defined), the gNB can choose the UE to be released in the same way as current (i.e. in RRC release with suspend configuration). Therefore, no functional extension is expected for the selective conversion of the UE with respect to the RRC release message.

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

[0323] Regarding the activation of a multicast session, RAN2#119bis-e has agreed on the following.

[0324] • When a Rel-18 session is activated, the UEs in inactive state can be informed (details need further study).

[0325] • As a baseline, group paging can be used to inform Rel-18 UEs of the activation of a session (e.g. further study is needed on the details of the operation when a UE receives such a group notification, etc.).

[0326] • The following solutions are considered (the description can be further updated as needed; several solutions can be needed; and there are also solutions that only apply to specific configuration options), the method for a UE to determine whether the UE can receive a multicast session in RRC inactive state when the session has been activated needs further study.

[0327] 1. When a multicast session is activated, if the UE can use the PTM configuration for the session in RRC inactive state and the UE has joined the session (such as the configuration provided to the UE via dedicated RRC signaling or MCCH), the UE can receive the multicast session in RRC inactive state, otherwise, the UE returns to RRC connected state and receives the multicast session.

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

[0329] 3. Before the UE is released, configure the UE with "whether the UE can receive the multicast session in RRC inactive state" through dedicated signaling. Once the multicast session is activated, the UE remains in RRC inactive state, or resumes to RRC connected in response to the activation (detailed signaling needs further study).

[0330] In Rel-17, the activation of a multicast session is provided as a notification through group paging. Since there is no need to be different from the legacy mechanism in Rel-18, RAN2 needs to check whether group paging is used to notify the multicast session activation.

[0331] Proposal 4: RAN2 needs to check whether group paging can be used to inform the version 18 UE about the activation of a session.

[0332] In addition to the check, RAN2 has specified three options for the operation of the UE upon reception of the multicast activation notification, as mentioned above.

[0333] In Option 1, if the UE has a valid PTM configuration, the UE can receive the multicast session in inactive state. A UE in inactive state cannot receive the multicast session without PTM configuration, which can be considered as the baseline for all other operations of the UE. Therefore, it is needed to agree on Option 1.

[0334] Proposal 5: RAN2 needs to agree on Option 1 for the operation of the UE: “When a multicast session is activated, if the UE can use the PTM configuration for that session in RRC inactive state and the UE has joined the session (such as provided to the UE via dedicated RRC signaling or configuration on MCCH), the UE can receive the multicast session in RRC inactive state, otherwise, the UE goes back to RRC connected state and receives the multicast session”.

[0335] For Option 2, the UE is indicated whether to receive the multicast session in inactive state upon reception of the group paging.

[0336] For Option 3, the UE is indicated whether to receive the multicast session in inactive state in advance by using RRC reconfiguration or RRC release.

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

[0338] For network congestion, it is assumed that the cell load changes over time. According to Option 2, since the indication is sent in the group paging, the gNB can consider the latest load situation when determining whether the UE needs to stay in inactive state. On the other hand, according to Option 3, since the gNB needs to predict the future load when providing the indication to the UE, there is a possibility that the cell load changes when the gNB actually sends the group paging. Therefore, there is a risk that the number of UEs switching to connected state increases even if the congestion is aggravated, or the number of UEs staying in inactive state increases even if the congestion is resolved. Therefore, in order to effectively control the RRC state of the UE, Option 2 is desirable.

[0339] From the power saving perspective of the UE, it is assumed that some kind of "power saving preference" is introduced in the UE assistance information. This preference indicates that it can only be sent from the UE in the connected state and cannot be sent to the UE in the inactive state. Therefore, the gNB can indicate to the UE whether it is allowed to receive the multicast session in the inactive state for the UE previously in the connected state. When this preference indication is not introduced, since the gNB does not know whether the UE prefers power saving or not, the gNB can indicate this to the UE at any time. That is, it can be said that there is no difference between Option 2 and Option 3.

[0340] Based on the above analysis, Option 2 is considered more efficient and can cover the use range of Option 3. Therefore, RAN2 needs to agree on Option 2 at least.

[0341] Proposal 6: For the operation of the UE, RAN2 needs to agree on Option 2: "When the multicast session is activated, indicate to the UE through group paging whether it can receive the multicast session in the RRC inactive state (the detailed signaling needs to be further studied)".

[0342] Specifically, when the paging message includes the TMGI of interest, all UEs start the RRC resume procedure, so when it is necessary to use selective paging for Option 2, the gNB cannot include the TMGI in the paging message. When the gNB only includes the UE-ID for selective paging (i.e., the traditional individual paging for paging the selected version 18 UE and not including the TMGI), the version 17 UE waiting for activation of the multicast in the inactive state cannot be paged. This is also inefficient in terms of signaling overhead.

[0343] That is, when the paging message includes the TMGI of interest, all UEs are converted to the RRC connected state.

[0344] Assuming that the current paging group list is configured in the group paging message for paging at least the version 17 UE, the version 18 UE is also paged by the TMGI of interest. In order for the selected UE not to be converted to the C-connected state, it can be considered to define a "paging cancellation list" (or "inactive permission list") (which is a new UE-ID list) to make the UEs listed in this list remain in the inactive state to receive the multicast session.

[0345] Therefore, RAN2 needs to discuss the method of enhancing group paging to page the subset of UEs.

[0346] Proposal 7: RAN2 needs to discuss the method of enhancing group paging to page the subset of UEs using, for example, a new UE-ID list for remaining in the inactive state to receive the multicast session.

[0347] 2.3. Case 3: Implementation of QoS

[0348] RAN2#119e has agreed the following for case 3.

[0349] • No HARQ feedback and PTP are supported in multicast reception in RRC inactive state.

[0350] According to this agreement, multicast reception in inactive state is the same and / or similar to MBS broadcast reception (so-called delivery mode 2) defined in Rel-17. MBS broadcast belongs to best effort type.

[0351] On the other hand, it is an important task for multicast session to ensure QoS / reliability. SA2 also questioned whether there is a difference in quality / reliability of multicast reception between connected state and inactive state, and RAN2#119bis-e has agreed the following reply.

[0352] RAN2 (Q1-a): In case there is a significant difference in quality and reliability of MBS data reception between UEs in RRC connected state and UEs in RRC inactive state:

[0353] Since no HARQ feedback and PTP transmission are supported and multicast reception in RRC inactive state does not require seamless / lossless mobility, there can be a difference in quality and reliability of MBS data reception between UEs in RRC connected state and UEs in RRC inactive state.

[0354] RAN2#119e has proposed to introduce reception quality thresholds (such as RSRP and BLER) which are considered to be used to ensure a certain level of QoS requirement for multicast reception. These thresholds are also useful for network to manage QoS requirement. When multicast reception in inactive state does not meet the corresponding QoS requirement, the UE needs to switch to connected state to ensure reception quality and use HARQ feedback / retransmission and / or PTP (or split MRB).

[0355] Observation 4: Even if the UE is in inactive state, the multicast session needs to ensure a certain level of QoS requirement.

[0356] Regarding RSRP threshold, since NR MBS assumes single cell transmission, it is considered that the UE needs to always switch to connected state every time the UE moves to cell edge or performs cell reselection. From network congestion and UE power saving point of view, this operation can not be the best operation depending on the deployment.

[0357] Threshold of BLER is considered to more simply ensure QoS requirement. Therefore, these options need to be discussed to introduce RRC state transition based on reception quality.

[0358] Proposal 8: RAN 2 needs to agree that a UE in inactive state needs to transition to connected state when the reception quality is below a threshold (such as RSRP or BLER).

[0359] 2.4. Case 4: Update of PTM configuration

[0360] In RAN2#120, it has been agreed to use MCCH in case the PTM configuration needs to be updated.

[0361] First, a "hybrid approach" is adopted to start the following operations:

[0362] 1. When the NW configures the UE to continue receiving multicast in inactive state, the NW provides the PTM configuration for the activated multicast session to at least one serving cell through RRC dedicated signaling (other cases need further study).

[0363] 2. When the PTM configuration needs to be changed or when the PTM configuration needs to be indicated during the transition outside the serving cell / gNB, MCCH is used. Changes in session status and other indications need further study.

[0364] 3. It is assumed that the UE can receive multicast service after joining the session.

[0365] 4. Whether to initially provide the MCCH configuration to the user equipment through dedicated signaling needs further study.

[0366] RAN2#121 agreed to use RRC release for PTM configuration (even before the activation of the session) and introduce a new MCCH (different from the Rel-17 MCCH).

[0367] • The UE needs to join the multicast session before receiving multicast in RRC inactive state.

[0368] • If the network is determined to be available, the UE is configured with the PTM configuration of the (single) serving cell before the activation of the session, and when the session that the UE can save the configuration is activated, the UE can apply the configuration to receive multicast in inactive state without returning to RRC connected state, unless the configuration is updated using MCCH afterwards.

[0369] • If the network configures the UE for multicast reception in inactive state, the PTM configuration can be delivered using the RRC release message containing suspendconfig. No other dedicated RRC message is used to provide the PTM configuration of MBS multicast in inactive state.

[0370] • A new MCCH logical channel for multicast in inactive state is introduced (different from the broadcast MCCH).

[0371] According to these agreements, there are two cases for PTM configuration update.

[0372] • Case 1: UE in inactive state receives a multicast session that has been activated;

[0373] • Case 2: UE in inactive state waits for the activation of a multicast session.

[0374] • Note: Case 2 can be further classified according to whether the PTM configuration is provided by RRC release or not.

[0375] In this case, the solution is expected to be as generic as possible.

[0376] Proposal 9: RAN2 needs to plan a generic solution for the notification of PTM configuration update, considering at least the two cases: a session that has been activated, and a session before activation.

[0377] That is, the UE cannot stay in inactive state to acquire the updated PTM configuration. Therefore, from the perspective of UE in inactive state, the new PTM configuration delivery method in Rel-18 is similar to delivery mode 2 in Rel-17. In this case, it can be considered to reuse the existing MCCH change notification to perform the notification of PTM configuration update.

[0378] MCCH change notification requires the UE to wake up once at each MCCH change boundary, which creates an additional burden on top of monitoring paging occasions. MCCH change notification is not efficient, especially in the above Case 2 (i.e. even if the UE only waits for the multicast session notification to see whether the PTM configuration provided by RRC release has been updated, the UE needs to monitor MCCH change notification).

[0379] To solve this problem, it is considered to enhance the group paging function to notify the PTM configuration update. Whether the UE is receiving a multicast session or not (i.e. Case 1 or Case 2 above), the UE only needs to monitor paging occasions to determine whether the PTM configuration update has been performed. Therefore, RAN2 needs to agree to use group paging for this notification. The details of the function extension need to be further studied.

[0380] Proposal 10: RAN2 needs to agree to use group paging instead of the existing MCCH change notification to update the PTM configuration.

[0381] 2.5. Case 5: Service continuity at RRC resume

[0382] The following possibility needs to be considered: a UE in inactive state that has received a multicast session (i.e., via a broadcast MRB or a new MRB for multicast reception in inactive state) is paged and initiates the RRC resume procedure. It can be considered that after transitioning to connected state, the UE would certainly want to continue receiving the same multicast session. However, in this case, the UE has two MRBs for the same multicast session, i.e., the broadcast MRB (or new MRB) configured for multicast reception in inactive state and the multicast MRB resumed for multicast reception in connected state.

[0383] According to Rel-17, only the multicast MRB configured via RRC reconfiguration can receive the multicast session. On the other hand, according to Rel-18, it is considered that the UE can receive the multicast session via the broadcast MRB (or new MRB) configured via RRC reconfiguration or new MCCH.

[0384] It can be considered that the UE uses the multicast MRB for reception after transitioning to connected state (similar to Rel-17). It is not clear how the UE switches these MRBs, when the UE discards the broadcast MRB (or new MRB), how the UE needs to operate (i.e., from the lossless principle point of view) when the multicast MRB is an AM MRB, etc. Therefore, RAN2 needs to discuss the UE operation during RRC resume from the handling of MRBs and service continuity of multicast session point of view.

[0385] Proposal 11: RAN2 needs to discuss the UE operation during RRC resume in case of continuous reception of multicast session (such as handling of broadcast MRB and multicast MRB).

[0386] REFERENCE NUMERALS

[0387] 1: Mobile communication system

[0388] 5: Network

[0389] 10: RAN

[0390] 20: CN

[0391] 100: User equipment (UE)

[0392] 110: Receiver

[0393] 120: Transmitter

[0394] 130: Controller

[0395] 200: gNB (base station)

[0396] 210: Transmitter

[0397] 220: Receiver

[0398] 230: controller

[0399] 240: backhaul communicator.

Claims

1. A communication method performed by a user equipment in a mobile communication system providing multicast / broadcast services (MBS), the communication method comprising: In the inactive state of Radio Resource Control (RRC), in response to receiving a paging message from the network, it is determined whether a predetermined condition is met, the paging message including a session identifier for a multicast session; as well as In the RRC inactive state, in response to the satisfaction of the predetermined conditions, configuration information for receiving the multicast session in the RRC inactive state is obtained by receiving the multicast control channel (MCCH) for multicast communication.

2. The communication method according to claim 1 further includes: In the RRC connection state, receive an RRC release message that causes the user equipment to switch to the RRC inactive state; as well as In response to receiving the RRC release message, the process transitions from the RRC connected state to the RRC inactive state. The predetermined conditions include conditions regarding the RRC release message not including the configuration information.

3. A communication method performed by a user equipment in a mobile communication system providing multicast / broadcast services (MBS), the communication method comprising: Receive and save the first PTM configuration from the network, the first PTM configuration being used to receive multicast sessions in the Radio Resource Control (RRC) inactive state. In the RRC inactive state, in response to receiving a paging message from the network, it is determined whether the first PTM configuration needs to be updated, the paging message including the session identifier of the multicast session; as well as In the RRC inactive state, in response to determining that the first PTM configuration needs to be updated, a second PTM configuration for receiving the multicast session is obtained by receiving the multicast control channel MCCH for multicast communication.

4. The communication method according to claim 3 further includes: In the RRC connection state, receive an RRC release message that causes the user equipment to switch to the RRC inactive state; as well as In response to receiving the RRC release message, the process transitions from the RRC connected state to the RRC inactive state. The RRC release message includes the first PTM configuration.

5. The communication method according to claim 3 or 4, in, The saving includes: saving the first PTM configuration in association with version information, and The determination includes: Receive signaling from the network, the signaling including information on receiving the latest version of the PTM configuration for the multicast session; and The need to update the first PTM configuration is determined by comparing the saved version information with the latest version information.

6. The communication method according to claim 5, wherein, The signaling is the paging message.

7. The communication method according to claim 5, wherein, The signaling is a system information block type 1 sent from the network.

8. The communication method according to claim 5, wherein, The signaling is a System Information Block (SIB) that indicates the configuration of the MCCH used for the multicast communication.

9. The communication method according to claim 5, wherein, The determination includes: when the signaling does not include the latest version information, determining that the first PTM configuration needs to be updated.

10. The communication method according to claim 3, further comprising: In the RRC connection state, receive an RRC release message that causes the user equipment to switch to the RRC inactive state; as well as In response to receiving the RRC release message, the process transitions from the RRC connected state to the RRC inactive state. The determination includes: determining that the first PTM configuration needs to be updated based on the fact that the RRC release message does not include the first PTM configuration.

11. The communication method according to claim 3 or 4, wherein, The determination includes: in response to the paging message or system information block including PTM configuration update information, determining that the first PTM configuration needs to be updated.

12. The communication method according to claim 11, in, The paging message includes a user equipment identifier associated with the session identifier, and In the paging message, the PTM configuration update information is associated with the user equipment identifier.

13. The communication method according to claim 11, wherein, In the paging message, the PTM configuration update information is associated with the session identifier.

14. The communication method according to claim 11, in, The system information block includes the session identifier, and In the system information block, the PTM configuration update information is associated with the session identifier.

15. A user equipment for use in a mobile communication system providing multicast / broadcast services (MBS), the user equipment comprising a controller configured to perform the following processes: Receive and save the first PTM configuration from the network, the first PTM configuration being used to receive multicast sessions in the Radio Resource Control (RRC) inactive state. In the RRC inactive state, in response to receiving a paging message from the network, it is determined whether the first PTM configuration needs to be updated, the paging message including the session identifier of the multicast session; as well as In the RRC inactive state, in response to determining that the first PTM configuration needs to be updated, a second PTM configuration for receiving the multicast session is obtained by receiving the multicast control channel MCCH for multicast communication.

Images