COMMUNICATION METHOD, USER EQUIPMENT, CHIPSET, PROGRAM, AND COMMUNICATION SYSTEM

Abstract

A communication method for use in a mobile communication system that provides a multicast / broadcast service (MBS), the method comprising: a step of user equipment in a wireless resource control (RRC)-connected state receiving a multicast session from a network; and a step of the user equipment transmitting, to the network, a message including first information indicating a request to transition to an RRC inactive state, and second information concerning continuation of reception of the multicast session.

Description

Communication Method

[0001] The present disclosure relates to a communication method for use in a mobile communication system.

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

[0003] 3GPP Technical Specification: TS 38.300 V17.1.0

[0004] A communication method according to a first aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of: a user equipment in a radio resource control (RRC) connected state receiving a multicast session from a network; and the user equipment transmitting a message to the network, the message including first information indicating that the user equipment wishes to transition to an RRC inactive state, and second information regarding continued reception of the multicast session.

[0005] A communication method according to a second aspect is a communication method for use in a mobile communication system providing a multicast / broadcast service (MBS), the method comprising the steps of: a user equipment (UE) in a radio resource control (RRC) connected state receiving one or more multicast sessions from a network using MBS configurations for each of the one or more multicast sessions; and receiving, by the user equipment, an RRC release message from the network for transitioning the user equipment to an RRC inactive state, the RRC release message including information indicating multicast sessions to which the MBS configurations are to be continuously applied.

[0006] A communication method according to a third aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of: a user equipment in a radio resource control (RRC) inactive state receiving a multicast session from a network using an MBS setting for the multicast session; and discarding the MBS setting in response to the user equipment performing cell reselection in the RRC inactive state or transitioning from the RRC inactive state to an RRC idle state.

[0007] A communication method according to a fourth aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of a user equipment in a radio resource control (RRC) inactive state receiving a multicast session from a network using an MBS setting for the multicast session, the user equipment discarding the MBS setting, and the user equipment initiating an RRC connection resume procedure based on the user equipment discarding the MBS setting.

[0008] A communication method according to a fifth aspect is a communication method for use in a mobile communication system providing a multicast / broadcast service (MBS), the method comprising the steps of: a user equipment (UE) in a radio resource control (RRC) inactive state receiving a multicast session from a network using an MBS configuration for the multicast session; initiating an RRC connection resume procedure by the user equipment; and transmitting an RRC resume request message to the network during the RRC connection resume procedure by the user equipment, the RRC resume request message including information for requesting an update of the MBS configuration or information for requesting a handover of the user equipment.

[0009] A communication method according to a sixth aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of: a user equipment in a radio resource control (RRC) inactive state receiving a multicast session from a network using an MBS setting for the multicast session; the user equipment managing a timer that determines the validity period of the MBS setting; the user equipment receiving a notification from the network indicating an extension of the validity period; and the user equipment operating the timer to extend the validity period.

[0010] 1 is a diagram illustrating a configuration of a mobile communication system according to an embodiment. A diagram illustrating a configuration of a UE (user equipment) according to an embodiment. A diagram illustrating a configuration of a gNB (base station) according to an embodiment. A diagram illustrating a protocol stack configuration of a radio interface of a user plane that handles data. A diagram illustrating a protocol stack configuration of a radio interface of a control plane that handles signaling (control signals). A diagram for explaining MRB setting (MRB-ToAddMod) defined in the RRC technical specification (TS38.331). A diagram for explaining an overview of operations according to an embodiment. A diagram for explaining preferredRRC-State defined in the RRC technical specification (TS38.331). A diagram illustrating operation pattern 1 according to an embodiment. A diagram illustrating operation pattern 2 according to an embodiment. A diagram for explaining operation pattern 3 according to an embodiment. A diagram illustrating an example of operation pattern 3 according to an embodiment. A diagram illustrating another example of operation pattern 3 according to an embodiment. A diagram illustrating operation pattern 4 according to an embodiment. A diagram illustrating operation pattern 5 according to an embodiment. A diagram illustrating operation pattern 6 according to an embodiment. A diagram illustrating operation pattern 7 according to an embodiment.

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

[0012] (1) Configuration of a Mobile Communication System FIG. 1 is a diagram showing the configuration of a mobile communication system according to an embodiment. The mobile communication system 1 conforms to the 3GPP standard 5th Generation System (5GS). While the following description uses 5GS as an example, the mobile communication system may also be at least partially based on an LTE (Long Term Evolution) system. The mobile communication system may also be at least partially based on a 6th Generation (6G) system.

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

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

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

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

[0017] The 5GC20 includes an AMF (Access and Mobility Management Function) and a UPF (User Plane Function) 300. The AMF performs various mobility controls for the UE 100. The AMF manages the mobility of the UE 100 by communicating with the UE 100 using NAS (Non-Access Stratum) signaling. The UPF controls data forwarding. The AMF and the UPF are connected to the gNB 200 via an NG interface, which is an interface between a base station and a core network.

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

[0019] The receiving unit 110 performs various types of reception under the control of the control unit 130. The receiving unit 110 includes an antenna and a receiver. The receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 130.

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

[0021] The control unit 130 performs various controls and processes in the UE 100. Such processes include processes of each layer described below. The control unit 130 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in the processes by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes.

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

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

[0024] The receiving unit 220 performs various types of reception under the control of the control unit 230. The receiving unit 220 includes an antenna and a receiver. The receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 230.

[0025] The control unit 230 performs various controls and processes in the gNB 200. Such processes include processes for each layer, which will be described later. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in the processes by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0039] In the case of a broadcast communication service (also referred to as "MBS broadcast"), the same service and the same specific content data are simultaneously provided to all UEs 100 in a geographical area. That is, all UEs 100 within the broadcast service area are permitted to receive the data. The broadcast communication service is delivered to the UEs 100 using a broadcast session, which is a type of MBS session. The UEs 100 can receive the broadcast communication service in any of the RRC idle state, RRC inactive state, and RRC connected state. Such a delivery mode is sometimes referred to as Delivery Mode 1.

[0040] In the case of a multicast communication service (also referred to as "MBS multicast"), the same service and the same specific content data are simultaneously provided to a specific set of UEs. That is, not all UEs 100 within a multicast service area are permitted to receive the data. The multicast communication service is delivered to the UEs 100 using a multicast session, which is a type of MBS session. The UEs 100 can receive the multicast communication service in an RRC connected state using mechanisms such as Point-to-Point (PTP) and / or Point-to-Multipoint (PTM) delivery. The UEs 100 may also receive the multicast communication service in an RRC inactive (or RRC idle) state. Such a delivery mode is sometimes referred to as Delivery Mode 2.

[0041] The main logical channels used for MBS delivery are the Multicast Traffic Channel (MTCH), the Dedicated Traffic Channel (DTCH), and the Multicast Control Channel (MCCH). The MTCH is a PTM downlink channel for transmitting MBS data of either a multicast or broadcast session from the network 10 to the UE 100. The DTCH is a PTP channel for transmitting MBS data of a multicast session from the network 10 to the UE 100. The MCCH is a PTM downlink channel for transmitting MBS broadcast control information associated with one or more MTCHs from the network 10 to the UE 100.

[0042] Regarding the configuration for MBS broadcast, the UE 100 in the RRC idle state, the RRC inactive state, or the RRC connected state receives the MBS configuration for the broadcast session (e.g., parameters required for MTCH reception) via the MCCH. The parameters required for MCCH reception (MCCH configuration) are provided via system information. Specifically, the system information block type 20 (SIB20) includes the MCCH configuration. Note that the SIB type 21 (SIB21) includes information on service continuity for MBS broadcast reception. The MCCH provides a list of all broadcast services, including ongoing sessions, transmitted on the MTCH. The broadcast session-related information includes the MBS session ID (e.g., TMGI (Temporary Mobile Group Identity)), associated G-RNTI scheduling information, and information on neighboring cells providing a specific service on the MTCH.

[0043] On the other hand, with regard to MBS multicast, in the current 3GPP technical specifications, UE 100 can only receive multicast session data in the RRC connected state. When UE 100 that has joined a multicast session is in the RRC connected state and the multicast session is activated, gNB 200 transmits an RRC reconfiguration message including MBS configuration for the multicast session to UE 100. Such MBS configuration is also referred to as multicast radio bearer (MRB) configuration, MTCH configuration, or multicast configuration. Figure 6 is a diagram for explaining MRB configuration (MRB-ToAddMod) specified in the RRC technical specification (TS38.331). The MRB setting (MRB-ToAddMod) includes other parameters such as an MBS session ID (mbs-SessionId), an MRB ID (mrb-Identity), and a PDCP setting (pdcp-Config) for the MRB (multicast MRB) to be set in UE 100.

[0044] In the following embodiment, an operation that enables the UE 100 in the RRC inactive state to perform multicast reception will be mainly described. Fig. 7 is a diagram showing an overview of the operation.

[0045] Possible solutions for the UE 100 in the RRC inactive state to perform multicast reception include a distribution mode 1 based solution shown in FIG. 6( a) and a distribution mode 2 based solution shown in FIG. 7( b).

[0046] In the distribution mode 1-based solution shown in Figure 7 (a), in step S1, gNB200 transmits an RRC reconfiguration message including an MBS setting for the multicast session to UE100 in the RRC connected state. UE100 receives multicast data of the multicast MRB (multicast session) on the MTCH based on the RRC reconfiguration message.

[0047] In step S2, the gNB 200 transmits an RRC release (Release) message to the UE 100 in the RRC connected state to transition the UE 100 to the RRC inactive state. The RRC release message includes a setting (Suspend Config.) for the RRC inactive state.

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

[0049] In step S4, the UE 100 in the RRC inactive state continues to use the MBS setting in step S1 and receives multicast data of the multicast MRB (multicast session) on the MTCH.

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

[0051] On the other hand, in the distribution mode 2-based solution shown in FIG. 7(b), in step S11, the gNB 200 transmits an RRC release (Release) message to the UE 100 in the RRC connected state to transition the UE 100 to the RRC inactive state. The RRC release message includes a setting (Suspend Config.) for the RRC inactive state.

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

[0053] In step S13, the gNB 200 transmits an MCCH including an MBS setting for the multicast session. The UE 100 receives the MCCH.

[0054] In step S14, the UE 100 in the RRC inactive state receives multicast data of the multicast MRB (multicast session) on the MTCH based on the MCCH (MBS setting) in step S13. This enables the UE 100 in the RRC inactive state to perform multicast reception.

[0055] The operation patterns of the following embodiments describe improvements to the distribution mode 1 based solution as described above.

[0056] (3) Operation Pattern 1 The UE 100 in the RRC connected state can notify the network of its desired RRC state using a UE assistance information (Assistance Information) message. Figure 8 is a diagram for explaining preferredRRC-State defined in the RRC technical specification (TS38.331).

[0057] The UE assistance information message transmitted from the UE 100 to the network 10 can include preferredRRC-State as an information element. The UE 100 notifies the gNB 200 of its preferred RRC state, specifically, any of the RRC connected state, RRC inactive state, RRC idle state, and non-RRC connected state (outOfConnected), depending on, for example, the unicast communication status.

[0058] Here, when the UE 100 performing multicast reception transmits preferredRRC-State indicating that it wishes to transition to the RRC inactive state to the network 10 (gNB 200), it is assumed that the gNB 200 transitions the UE 100 to the RRC inactive state. However, if the UE 100 is simply transitioned to the RRC inactive state, there is a concern that the UE 100 may not be able to continue multicast reception.

[0059] Therefore, in this operation pattern, UE 100, which receives a multicast session from network 10 in the RRC connected state, transmits a message to network 10 including first information indicating a desire to transition to the RRC inactive state and second information regarding continued reception of the multicast session. For example, when UE 100 transmits a UE assistance information message to gNB 200 including preferredRRC-State (first information) indicating a desire to transition to the RRC inactive state, UE 100 includes second information regarding continued reception of the multicast session in the UE assistance information message. This enables gNB 200 to appropriately configure UE 100 to perform multicast reception in the RRC inactive state.

[0060] 9 is a diagram showing operation pattern 1 according to the embodiment. In the description of this operation pattern, the overlapping description with FIG. 7, particularly with FIG. 7(a), will be omitted. In this operation pattern and the operation patterns described later, it is assumed that the UE 100 participating in the multicast session has received the MBS setting (multicast setting) related to the multicast session from the network 10 (gNB 200).

[0061] In step S101, the UE 100 performs multicast reception in the RRC connected state. Here, the UE 100 determines whether or not it can transition to the RRC inactive state. For example, the UE 100 determines that it can transition to the RRC inactive state when at least one of the following conditions is met: there is no unicast communication (for the foreseeable future), the UE 100 has the ability to continue multicast reception in the RRC inactive state, and there is no data transmission related to multicast (for the foreseeable future).

[0062] In step S102, the UE 100 transmits to the gNB 200 a UE assistance information message including preferredRRC-State (first information) indicating a desire to transition to the RRC inactive state. The gNB 200 receives the UE assistance information message. Here, the UE 100 includes, in the UE assistance information message, information indicating the need for multicast reception setting as second information regarding continued reception of the multicast session. The second information may be an information element included in ReleasePreference. For example, the second information may be information indicating a desire to continue multicast reception. The second information may be an MBS session ID (TMGI) for which continued multicast reception is desired and / or an MBS bearer ID (MRB ID) for which continued multicast reception is desired.

[0063] In step S103, based on the message of step S102, gNB200 transmits dedicated signaling to UE100 including multicast settings (MRB / MTCH settings) related to multicast reception for the RRC inactive state. For example, gNB200 transmits an RRC reconfiguration message including the MBS settings to UE100, and then transmits an RRC release message to UE100 to transition UE100 to the RRC inactive state. Alternatively, gNB200 may transmit an RRC release message including the MBS settings to UE100. Here, the multicast settings for the RRC inactive state may be different from the multicast settings for the RRC connected state. The multicast settings may be the same as the multicast settings for the RRC connected state. If they are the same, gNB200 may instruct UE100 to continue applying the current multicast settings for the RRC connected state in the RRC inactive state.

[0064] In this operation pattern, a solution based on distribution mode 1 has been described, but in the case of a solution based on distribution mode 2, gNB200 updates the MCCH, sets up an MRB, and transitions UE100 to an RRC inactive state.

[0065] In addition, in this operation pattern, an example of using a UE assistance information message has been described, but other messages, such as an MBS Interest Indication message, may be used instead of the UE assistance information message. Alternatively, a response message to an inquiry from the gNB 200 may be used instead of the UE assistance information message. For example, when the gNB 200 detects network congestion, it may inquire of the UE 100 whether it is possible to transition to the RRC inactive state.

[0066] (4) Operation Pattern 2 The differences from the above-described operations will be mainly described for operation pattern 2. This operation pattern can be implemented in combination with the above-described operations.

[0067] In this operation pattern, UE 100 in the RRC connected state receives one or more multicast sessions from network 10 (gNB 200) using the MBS settings of each of the one or more multicast sessions. Also, UE 100 receives an RRC release message from network 10 to transition UE 100 to the RRC inactive state. The RRC release message includes information indicating the multicast session to which the MBS setting (multicast setting) is continuously applied. Based on this information, UE 100 can apply new multicast settings to other multicast sessions (MRBs) while using the configured multicast settings as they are for some multicast sessions (MRBs).

[0068] 10 is a diagram showing operation pattern 2 according to the embodiment. In the description of this operation pattern, the description of operations that overlap with the operations described above will be omitted.

[0069] In step S201, UE100 is receiving multiple multicast sessions in the RRC connected state. Here, gNB200 decides to transition UE100 receiving multicast to the RRC inactive state. At that time, gNB200 confirms the MRB setting (multicast setting) for the multiple multicast sessions being received by UE100.

[0070] In step S202, the gNB 200 transmits to the UE 100 an RRC release message including information (e.g., a list) indicating whether the configured multicast settings are applicable for each MRB ID or each MBS session ID. The RRC release message may include information indicating that the multicast settings for the RRC connected state already configured, linked to the MRB ID or MBS session ID, will be reused (i.e., continued application even after transition to the RRC inactive state). The RRC release message may include new multicast settings (i.e., multicast settings to be applied after transition to the RRC inactive state) linked to the MRB ID or MBS session ID. If there is no new multicast setting (NULL value), it may implicitly indicate that the application of the configured multicast setting will continue.

[0071] In step S203, in response to receiving the RRC release message in step S202, the UE 100 transitions to an RRC inactive state.

[0072] In step S204, UE100 selectively applies the multicast setting for the RRC connected state that has already been set or a new multicast setting for each multicast session (MRB) according to the above information contained in the RRC release message, and continues receiving the multicast session (MRB).

[0073] (5) Operation Pattern 3 Operation Pattern 3 will be described, focusing on differences from the above-described operations. This operation pattern can be implemented in combination with the above-described operations. This operation pattern focuses on cell reselection performed after the UE 100 transitions to the RRC inactive state.

[0074] 11 is a diagram for explaining operation pattern 3 according to the embodiment. In the illustrated example, cell a is managed by gNB200a, and cell b is managed by gNB200b. UE100 performs multicast reception in cell a (gNB200a) in an RRC inactive state using the multicast configuration received in cell a (gNB200a). The multicast configuration received in cell a (gNB200a) may be valid only in cell a. Alternatively, the multicast configuration received in cell a (gNB200a) may be valid only in a predetermined area range including cell a.

[0075] In the illustrated example, it is assumed that the multicast setting received in cell a (gNB 200a) is not valid in cell b. Under such an assumption, UE 100 discards the multicast setting in response to cell reselection from cell a to cell b in the RRC inactive state.

[0076] Alternatively, when the UE 100 moves out of the cell a and out of the coverage area, the UE 100 transitions from the RRC inactive state to the RRC idle state. Under such an assumption, the UE 100 may discard the multicast configuration in response to the transition from the RRC inactive state to the RRC idle state.

[0077] 12 is a diagram showing an example of operation pattern 3 according to the embodiment. In the description of this operation pattern, the description of operations that overlap with the operations described above will be omitted.

[0078] In step S301, the UE 100 in the RRC connected state receives multicast settings for the RRC inactive state from the network 10 (gNB 200) by dedicated signaling (RRC reconfiguration message or RRC release message) and starts receiving the multicast session. The gNB 200 may transmit information setting the validity area of ​​the multicast setting to the UE 100. The information may be a list consisting of the IDs of each cell constituting the validity area. The information may be information specifying an RA (Registration Area), a TA (Tracking Area), or an RNA (RAN Notification Area) as the validity area. Alternatively, if the multicast setting is valid only in the current serving cell, the information is unnecessary.

[0079] Then, in step S302, the UE 100 transitions to an RRC inactive state.

[0080] In step S303, the UE 100 in the RRC inactive state performs multicast reception using the multicast setting in step S351.

[0081] In step S304, the UE 100 in the RRC inactive state determines whether or not it has left the valid area (serving cell, RA, TA, or RNA) of the multicast setting in step S301. Specifically, the UE 100 may determine whether or not it has performed cell reselection to a cell outside the valid area.

[0082] When the cell reselection to the cell outside the effective area is performed (step S304: YES), in step S305, the UE 100 discards the currently applied multicast setting. Note that an example of the operation after discarding the multicast setting will be described later.

[0083] FIG. 13 is a diagram showing another example of operation pattern 3 according to the embodiment.

[0084] In step S351, UE100 in the RRC connected state receives multicast settings for the RRC inactive state from network 10 (gNB200) by dedicated signaling (RRC reconfiguration message or RRC release message) and starts receiving the multicast session.

[0085] Then, in step S352, the UE 100 transitions to the RRC inactive state.

[0086] In step S353, the UE 100 in the RRC inactive state performs multicast reception using the multicast setting in step S351.

[0087] In step S354, the UE 100 in the RRC inactive state transitions to the RRC idle state. For example, the UE 100 transitions to the RRC idle state due to moving out of the service area.

[0088] In step S355, in response to transition to the RRC idle state, the UE 100 discards the applied multicast setting and stops multicast reception (MTCH reception). Alternatively, the UE 100 may deactivate (suspend) the multicast setting without discarding the multicast setting and stop multicast reception (MTCH reception).

[0089] (6) Operation Pattern 4 The differences from the above-described operations will be mainly described for operation pattern 4. This operation pattern can be implemented in combination with the above-described operations.

[0090] As described above, the UE 100 discards the multicast setting for a reason such as leaving the valid area of ​​the multicast setting, etc. When a validity period is set for the multicast setting, the UE 100 may discard the multicast setting as the validity period elapses.

[0091] In this operation pattern, UE 100 in an RRC inactive state receives a multicast session from network 10 using the MBS setting (multicast setting) of the multicast session. UE 100 starts an RRC connection resume procedure based on discarding the multicast setting. This allows UE 100 to acquire new multicast setting from network 10, and therefore, to resume multicast reception.

[0092] 14 is a diagram showing operation pattern 4 according to the embodiment. In the description of this operation pattern, the description of operations that overlap with the operations described above will be omitted.

[0093] In step S401, UE100 in the RRC connected state receives multicast settings for the RRC inactive state from network 10 (gNB200) by dedicated signaling (RRC reconfiguration message or RRC release message) and starts receiving the multicast session.

[0094] Then, in step S402, the UE 100 transitions to an RRC inactive state.

[0095] In step S403, the UE 100 in the RRC inactive state performs multicast reception using the multicast setting in step S401.

[0096] In step S404, UE 100 discards the multicast configuration. As described above, UE 100 may discard the multicast configuration in response to performing cell reselection and leaving the coverage area (cell). Alternatively, if a timer value (i.e., the validity period of the multicast configuration) is set in the RRC release message and the timer is started when UE 100 transitions to the RRC inactive state, UE 100 may discard the multicast configuration in response to the expiration of the timer (i.e., the validity period has elapsed).

[0097] In step S405, the UE 100 initiates an RRC connection resume. Here, the AS (e.g., RRC) of the UE 100 may notify its upper layer (NAS) that it has discarded the multicast configuration or that multicast reception can no longer be continued. The notification may include an MBS session ID (TMGI) or an MRB ID. In response to the notification, the upper layer of the UE 100 may request the AS to perform an RRC connection resume procedure. Alternatively, the AS may voluntarily initiate the RRC connection resume procedure to obtain new multicast configuration.

[0098] In step S406, the UE 100 performs an RRC connection resume procedure with the network 10 (gNB 200). This procedure includes a random access procedure, and in this procedure, the UE 100 may send an RRC resume request message to the network 10 (gNB 200). As a result, in step S407, the UE 100 may acquire a new multicast setting from the network 10 (gNB 200). Details of such an operation will be described later.

[0099] (7) Operation Pattern 5 The following mainly describes the differences from the above-mentioned operations for operation pattern 5. This operation pattern can be implemented in combination with the above-mentioned operations.

[0100] As described above, the UE 100 can transition to the RRC connected state by the RRC connection resume procedure and acquire a new multicast setting from the network 10 (gNB 200). Here, by returning to the RRC inactive state immediately after the UE 100 acquires the new multicast setting, the power consumption of the UE 100 and the increase in the network load can be suppressed.

[0101] In this operation pattern, when UE100 transmits an RRC Resume Request message to network 10 (gNB200) in the RRC connection resume procedure, information for requesting an update of the MBS setting (multicast setting) is included in the RRC resume request message. This enables the network 10 (gNB200) to provide the UE100 with a new multicast setting early based on the RRC resume request message.

[0102] 15 is a diagram showing an operation pattern 5 according to the embodiment. In the description of this operation pattern, the description of operations that overlap with the operations described above will be omitted. In the illustrated example, in the scenario shown in FIG. 11, a case is assumed in which UE 100 in the RRC inactive state performs cell reselection from cell a within a multicast-configured effective area to cell b outside the effective area.

[0103] In step S501, the UE 100 performing multicast reception in the RRC inactive state may discard the multicast configuration (or may detect that the multicast configuration will be discarded in the near future) as described above.

[0104] In step S502, the UE 100 starts an RRC connection resume procedure.

[0105] In step S503, the UE 100 transmits an RRC resume request message to cell b (gNB 200b). The gNB 200b receives the RRC resume request message. The RRC resume request message includes an information element "Resume Cause" indicating the reason for the RRC resume, and an I-RNTI (Inactive RNTI). Here, the UE 100 sets the Resume Cause to "multicast configuration update", for example, "multicast-configuration-update". The UE 100 may set information indicating a desire to continue multicast reception in the RRC inactive state as the Resume Cause. The UE 100 may include, in the RRC resume request message, an identifier (such as a TMGI and / or an MRB ID) indicating which multicast session the configuration update is for.

[0106] In step S504, the gNB200b may identify the gNB200a that holds the context of the UE100 based on the I-RNTI included in the RRC resume request message of step S503, and request the context of the UE100 over the Xn interface. As a result, the gNB200b acquires the context of the UE100 from the gNB200a. The gNB200b may request and acquire only the MBS-related context from the UE context. The gNB200b may identify the multicast session (TMGI) that the UE100 is receiving from the UE context. The gNB200b derives new multicast settings to be set for the UE100 from the UE context. The gNB200b may notify the gNB200a of the new multicast settings (MBS-related context). The gNB200a may update the context of the UE100 in response to the notification.

[0107] In step S506, gNB200b transmits new multicast configuration to UE100. UE100 receives the new multicast configuration. gNB200b may transmit an RRC release message including the new multicast configuration in response to the RRC resume request message. In this case, UE100 can acquire the new multicast configuration without transitioning to the RRC connected state. Alternatively, gNB200b may transition UE100 to the RRC connected state, perform multicast configuration using an RRC reconfiguration message, and then transmit an RRC release message to UE100. As a result, UE100 transitions to the RRC inactive state.

[0108] (8) Operation Pattern 6 The following mainly describes the differences from the above-mentioned operations for operation pattern 6. This operation pattern can be implemented in combination with the above-mentioned operations.

[0109] As described above, when a UE 100 in an RRC inactive state performs cell reselection, if the multicast setting is valid in the valid area (e.g., only in the cell in which the multicast setting is made), the multicast setting becomes unavailable. Therefore, multicast reception cannot be continued. In the above-described operation pattern 5, a new multicast setting is acquired when the UE 100 leaves the valid area (i.e., after cell reselection). In contrast, this operation pattern assumes a case in which the UE 100 transitions to an RRC connected state before leaving the valid area (i.e., before cell reselection) to hand over the UE 100 to a target cell.

[0110] In this operation pattern, when UE100 transmits an RRC Resume Request message to network 10 (gNB200) during the RRC connection resume procedure, the UE100 includes information for requesting handover in the RRC resume request message. This enables the network 10 (gNB200) to appropriately hand over UE100 based on the RRC resume request message. It is also possible to provide new multicast settings to UE100 during the handover procedure.

[0111] 16 is a diagram showing an operation pattern 6 according to the embodiment. In the description of this operation pattern, the description of operations that overlap with the operations described above will be omitted. In the illustrated example, in the scenario shown in FIG. 11, a case is assumed in which UE 100 in the RRC inactive state performs an RRC connection resume procedure with cell a before performing cell reselection from cell a within a multicast-enabled area to cell b outside the enabled area.

[0112] In step S601, the gNB 200a may configure the UE 100 to transition to the RRC connected state before leaving the multicast configuration effective area (e.g., before cell reselection). For example, the gNB 200a may perform this configuration for a multicast session with strict service requirements for multicast reception interruption. This configuration may be performed while the UE 100 is in the RRC connected state.

[0113] Thereafter, in step S602, the UE 100 transitions to an RRC inactive state and continues multicast reception.

[0114] In step S603, when UE100 recognizes that it is leaving the multicast configuration effective area (e.g., cell a), it initiates an RRC connection resume procedure for cell a (gNB200a).

[0115] In step S604, the UE 100 transmits an RRC Resume request message to the gNB 200a. The gNB 200a receives the RRC Resume request message. The message includes, as a Resume Cause, information indicating that a handover is requested to continue multicast reception. The information may be information indicating that only a handover is desired. Since the gNB 200a has little impact on the load for access only for performing a handover, it is desirable that the gNB 200a accepts the access based on the Resume Cause.

[0116] In step S605, gNB200a transmits an RRC resume message to UE100. UE100 receives the RRC resume message and transitions to an RRC connected state (step S606).

[0117] In step S607, the UE 100 may transmit to the gNB 200a a measurement report message including measurement results (e.g., RSRP / RSRQ for each cell) during the RRC inactive state and / or the cell ID of the cell b that is the target cell (candidate cell). The UE 100 may include this information in the RRC resume request message of step S604.

[0118] In step S608, the gNB 200a transmits a handover request message to the gNB 200b over the Xn interface. The handover request message may include the context of the UE 100.

[0119] In step S609, the gNB 200b transmits a handover response message to the gNB 200a on the Xn interface. The handover response message may include new multicast settings to be configured for the UE 100.

[0120] In step S610, gNB200a sends a handover command (RRC reconfiguration message) including new multicast settings to UE100.

[0121] In step S611, UE100 applies the new multicast setting, accesses cell b (gNB200b), which is the target cell, and starts (resumes) multicast reception.

[0122] (9) Operation Pattern 7 The following mainly describes the differences from the above-mentioned operations for Operation Pattern 7. This operation pattern can be implemented in combination with the above-mentioned operations.

[0123] As described above, the network 10 (gNB 200) can set the validity period (timer) of the multicast setting for the RRC inactive state to the UE 100. The UE 100 discards the multicast setting when the timer expires. However, if there is no need to change the multicast setting, it is efficient to continue using the multicast setting even if the timer is set. In this operation example, the validity period can be extended by signaling from the network 10 (gNB 200).

[0124] That is, in this operation example, the UE 100 that receives a multicast session using the MBS setting (multicast setting) in the RRC inactive state manages a timer (hereinafter also referred to as a "discard timer") that determines the validity period of the multicast setting. When the UE 100 receives a notification indicating an extension of the validity period from the network 10, the UE 100 operates the timer to extend the validity period.

[0125] 17 is a diagram showing operation pattern 7 according to the embodiment. In the description of this operation pattern, the description of operations that overlap with the operations described above will be omitted.

[0126] In step S701, the UE 100 receives a multicast configuration in dedicated signaling (an RRC reconfiguration message or an RRC release message) from the network 10 (gNB 200). The configuration may include a setting value for the discard timer. When the UE 100 receives multiple multicast sessions, the discard timer may be set individually for each multicast session.

[0127] Then, in step S702, the UE 100 transitions to an RRC inactive state.

[0128] In step S703, the UE 100 starts a discard timer when transitioning to the RRC inactive state. The UE 100 may start the timer when receiving an RRC release message or an RRC reconfiguration message.

[0129] In step S704, while the discard timer is operating, the UE 100 performs multicast reception using the multicast setting in step S701.

[0130] In step S705, if there is no change in the multicast setting, the gNB 200 notifies the UE 100 of an instruction to extend the application of the setting. The gNB 200 may periodically transmit the instruction while there is no change in the multicast setting. The UE 100 receives the notification (instruction). For example, the instruction is transmitted in broadcast signaling transmitted by the gNB 200, for example, in a MAC CE multiplexed on an SIB, an MCCH, or an MTCH. The instruction may include an identifier (TMGI, MRB ID, etc.) indicating the multicast session to which the instruction applies. The UE 100 may apply the instruction only to the discard timer associated with the multicast session. If the identifier is not included, the UE 100 may apply the instruction to the timers of all multicast sessions.

[0131] The instruction may be an instruction to restart the discard timer. The UE 100 may restart the discard timer immediately upon receiving the instruction. Alternatively, if the UE 100 has received the instruction, the UE 100 may restart the timer when the discard timer expires. The notification (instruction) may be an instruction to update or re-set the timer value, for example, an instruction to change the timer value set to 1 minute to 10 minutes.

[0132] In step S706, the UE 100 restarts the discard timer in response to receiving the instruction in step S705. The UE 100 may update or reset the timer value of the discard timer.

[0133] If a change is required to the multicast settings, gNB200 stops notifying the instruction.

[0134] In step S707, the UE 100 detects that the discard timer has expired.

[0135] In step S708, the UE 100 discards the multicast configuration received in step S701 in response to expiration of the discard timer. Note that the operation after discarding the multicast configuration is the same as the operation pattern described above.

[0136] (10) Other Embodiments In the above-described embodiment, multicast reception in the RRC inactive state has been mainly described, but the operation according to the above-described embodiment may be applied to multicast reception in the RRC idle state. In the RRC idle state, the above-described RRC resume (Resume) is replaced with RRC establishment (Establishment).

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

[0138] In the above-described embodiments and examples, an example in which the base station is an NR base station (gNB) has been described, but the base station may be an LTE base station (eNB) or a 6G base station. The base station may also be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may also be a DU of the IAB node. The UE 100 may also be an MT (Mobile Termination) of the IAB node.

[0139] A program may be provided that causes a computer to execute each process performed by the UE 100 or the gNB 200. The program may be recorded on a computer-readable medium. Using a computer-readable medium, the program can be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM. Furthermore, circuits that execute each process performed by the UE 100 or the gNB 200 may be integrated, and at least a portion of the UE 100 or the gNB 200 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).

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

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

[0142] This application claims priority to U.S. Provisional Application No. 63 / 396,349 (filed August 9, 2022), the entire contents of which are incorporated herein by reference.

[0143] (12) First Supplementary Note The following is a supplementary note regarding the features of the above-described embodiment.

[0144] (Supplementary Note 1) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a user equipment in a radio resource control (RRC) connected state receiving a multicast session from a network; and the user equipment transmitting to the network a message including first information indicating that the user equipment wishes to transition to an RRC inactive state and second information regarding continued reception of the multicast session.

[0145] (Supplementary Note 2) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a user equipment in a radio resource control (RRC) connected state receiving one or more multicast sessions from a network using MBS settings for each of the one or more multicast sessions; and the user equipment receiving an RRC release message from the network for transitioning the user equipment to an RRC inactive state, wherein the RRC release message includes information indicating a multicast session to which the MBS settings are to be continuously applied.

[0146] (Supplementary Note 3) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a user equipment in a radio resource control (RRC) inactive state receiving a multicast session from a network using an MBS setting for the multicast session; and discarding the MBS setting in response to the user equipment performing cell reselection in the RRC inactive state or transitioning from the RRC inactive state to an RRC idle state.

[0147] (Supplementary Note 4) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a user equipment in a radio resource control (RRC) inactive state receiving a multicast session from a network using an MBS configuration for the multicast session; the user equipment discarding the MBS configuration; and the user equipment initiating an RRC connection resume procedure based on the discarding of the MBS configuration.

[0148] (Supplementary Note 5) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a user equipment in a radio resource control (RRC) inactive state receiving a multicast session from a network using an MBS setting for the multicast session; the user equipment initiating an RRC connection resume procedure; and the user equipment transmitting an RRC resume request message to the network in the RRC connection resume procedure, wherein the RRC resume request message includes information for requesting an update of the MBS setting or information for requesting a handover of the user equipment.

[0149] (Supplementary Note 6) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a user equipment in a radio resource control (RRC) inactive state receives a multicast session from a network using an MBS setting for the multicast session; the user equipment manages a timer that determines a validity period of the MBS setting; the user equipment receives a notification from the network indicating an extension of the validity period; and the user equipment operates the timer to extend the validity period.

[0150] (13) Second Supplement

[0151] Introduction In RAN#94e, a new work item on Enhanced MBS (eMBS) was approved with a revised WID in RAN#96. One of the objectives of Rel-18 is to enable UEs in RRC inactive state to receive multicast sessions.

[0152] - Specify support for multicast reception by UEs in RRC inactive state. - Configure PTM for UEs receiving multicast in RRC inactive state. - Investigate the impact of mobility and state transitions for UEs receiving multicast in RRC inactive (seamless / lossless mobility is not mandatory).

[0153] In this appendix, we provide an initial consideration of support for multicast reception in RRC inactive, taking into account the relevant discussions that took place in Rel-17.

[0154] Discussion Discussions in Rel-17 and solution direction in Rel-18 Multicast reception in RRC inactive was briefly discussed in Rel-17, but RAN2 decided to prioritize multicast reception only in RRC connected as follows: Although RAN2 did not specify this feature in Rel-17, there are already some candidate solutions, which still provide a good starting point for discussions in Rel-18.

[0155] Chair: RAN2 will prioritize RRC Connected Mode active multicast support in Rel-17. If time permits, RRC Inactive multicast support can be considered later (when connected mode multicast and broadcast solutions become more mature).

[0156] In some cases, such as when the network is congested due to the presence of a large number of UEs in a cell, the network may release a UE receiving a multicast session to inactivity. Therefore, in this scenario, it is assumed that the UE is initially connected when it starts receiving the multicast session (including the procedure for joining the multicast session). The UE is then released to inactivity while continuing to receive the multicast session.

[0157] Observation 1: This scenario is where a UE receiving a multicast session in RRC Connected is released to RRC Inactive, allowing the UE to continue receiving the multicast session.

[0158] Rel-17 specifies two delivery modes, called "Delivery Mode 1" for multicast sessions and "Delivery Mode 2" for broadcast sessions. In Delivery Mode 1, MTCH reception configuration is provided by RRC reconfiguration for UEs in Connected state, while in Delivery Mode 2, it is done by MCCH for UEs in all RRC states.

[0159] To support multicast reception in the inactive state, we first need to consider whether the solution is based on "Delivery Mode 1" or "Delivery Mode 2".

[0160] Delivery mode 1 is easy to provide multicast sessions, but is currently limited to UEs in connected state. To support inactive UEs, many features and assumptions may need to be restricted / modified, such as handling of MTCH configuration, deactivation of PTP legs, HARQ feedback, CFR, etc. These modifications may require the involvement of RAN1, but it should be noted that RAN1 is not mentioned in Rel-18e MBSWI.

[0161] Observation 2: To provide a multicast session, it is straightforward to provide MTCH reception configuration via dedicated signaling (i.e., based on distribution mode 1). However, it should be noted that the involvement of RAN1 may be required, which is not included in the supported WGs in the WID.

[0162] Although distribution mode 2 already supports inactive broadcast reception, it has less network controllability compared to multicast sessions. Furthermore, the MCCH may be receivable by all UEs, and the reception settings of the MTCH related to the multicast session are also visible to all UEs, which raises potential security concerns.

[0163] Observation 3: MCCH can already provide broadcast sessions to RRC-inactive UEs (i.e., based on delivery mode 2), but Rel-17 has the problem of less network controllability.

[0164] Based on the above observations, RAN2 should discuss the solution direction for supporting multicast reception in RRC inactive, whether the MTCH reception configuration is provided by dedicated signaling (i.e., a distribution mode 1 based solution) or by MCCH (i.e., a distribution mode 2 based solution).

[0165] Proposal 1: To support multicast reception in RRC inactive, RAN2 should discuss the solution direction on whether the MTCH reception configuration is provided by dedicated signaling (i.e., a distribution mode 1 based solution) or by MCCH (i.e., a distribution mode 2 based solution).

[0166] Delivery Mode 1 Based Solution If the MTCH reception configuration is provided by dedicated signaling, it needs to be discussed whether the configuration is provided by RRC reconfiguration (as in Rel-17) or by RRC release.

[0167] With RRC reconfiguration, a UE transitions from Connected to Inactive and continues to apply the same configuration to receive the MTCH of interest. The advantage is that the current RRC reconfiguration can be reused, since the MRB configuration is already specified in Rel-17. On the other hand, since the UE needs to continue applying the MRB configuration even after transitioning to Inactive, additional UE behavior needs to be specified in the RRC reconfiguration procedure. In this case, the question remains as to whether a UE interested in a multicast session that transitions to Inactive can always continue to apply the configuration, or whether the network needs to explicitly indicate whether the MRB configuration should be applied, for example, via RRC release. Furthermore, RAN2 needs to discuss whether the UE can verify the MRB configuration, i.e., whether a validity timer such as T320 for dedicated priority is required. With RRC release, when the UE transitions to Inactive, if the configuration is provided in the RRC release message, it can continue receiving the MTCH of interest by simply applying the new configuration. Generally, it is very easy to provide a specific configuration to a UE using RRC release when the UE transitions to RRC inactive. Furthermore, it is highly compatible with the RNA update procedure. If the MRB used in inactive mode can also be reconfigured in RNA update (i.e., RRC release), the UE can be reconfigured without transitioning to connected mode. On the other hand, the disadvantage is that signaling overhead always occurs, even if the MRB configuration is the same as that already provided by a previous RRC reconfiguration. It is also worth discussing whether a validity timer is necessary.

[0168] Therefore, RAN2 should discuss whether the configuration of the received MTCH is provided by dedicated signaling, whether the configuration is provided by RRC reconfiguration or by RRC release. Furthermore, RAN2 should also discuss whether a validity timer is required for such dedicated configuration.

[0169] Proposal 2: For delivery mode 1 based solutions, RAN2 should discuss whether the configuration of the received MTCH is provided by RRC reconfiguration or by RRC release.

[0170] Proposal 3: For delivery mode 1 based solutions, RAN2 needs to discuss whether the UE's configuration for receiving MTCH can be considered valid all the time or only for a certain period of time (e.g. using a validity timer).

[0171] Another issue to consider is the impact of UE mobility under the assumption that "seamless / lossless mobility is not required," as stated in WID. In Rel-17, it is clear that the configuration for receiving MTCH in delivery mode 1 is valid only in the cell where the UE is configured. When a handover is performed, the target cell reconfigures the UE with the new configuration. On the other hand, when an inactive UE performs idle mode mobility, it can be considered as a starting point when the existing configuration for receiving MTCH is no longer valid in the reselected cell (i.e., the new cell).

[0172] The simplest solution with minimal impact on the specifications may be to always require an inactive UE to transition to Connected (e.g., before or after performing cell reselection) so that the UE can be handed over from the serving cell to the target cell or reconfigured by the reselected cell.

[0173] Since the configuration for MTCH reception is valid in the RNA, the gNB needs to be able to apply the same configuration in the RNA of each UE. The advantage of this method is that inactive UEs do not need to be reconfigured and can continue to receive MTCH in the RNA. On the other hand, since the RNA is UE-specific, it makes the network more complex.

[0174] A more flexible and less complicated method is for the gNB to provide a cell list in the configuration, so that the configuration is considered valid in the cells included in the list. The cell list can be cell-specific, UE-specific, RNA-related, MRB area-specific, or MBS service area-specific, depending on the implementation of the network.

[0175] Therefore, RAN2 should discuss whether to introduce area scope for such configurations.

[0176] Proposal 4: For distribution mode 1 based solutions, RAN2 should discuss whether the MTCH reception configuration is valid for the serving cell or for the area (RNA, cell list, etc.).

[0177] Delivery Mode 2 Based Solution As mentioned above, if the configuration for receiving the MTCH is provided over the MTCH, all the configuration, i.e., the MBS session information, is visible to all UEs, even if some of them are not participating in the multicast session. Therefore, these UEs that are not participating in the multicast session should not be able to receive the multicast MTCH.

[0178] It is assumed that due to higher layer procedures, UEs cannot receive the MTCH for the TMGI of a multicast session in the USD, but it is up to the gNB to decide whether to use distribution mode 1 or distribution mode 2 for the distribution of the multicast session. Therefore, an AS layer solution is desirable. One of the simplest solutions is to set an indicator in each MBS session information of the MCCH that distinguishes between multicast and broadcast sessions. UEs that do not participate in a multicast session are prohibited from using the corresponding MTCH. RAN2 should discuss whether this is an issue that needs to be resolved when the MCCH is inactive and used for multicast reception.

[0179] Proposal 5: For a delivery mode 2 based solution, RAN2 should consider whether to prevent a UE from using a multicast MTCH if the UE is not participating in the corresponding multicast session.

[0180] Another issue worth considering is the process of switching from delivery mode 1 to delivery mode 2 while receiving a multicast session. Although WID states that "seamless / lossless mobility is not required," some degree of service continuity should be ensured as part of the service requirements and expectations for multicast sessions.

[0181] If the UE starts acquiring MCCH and MTCH after an RRC state transition shortly after being released to inactivity, the service interruption during the delivery mode switch may be excessive, so such service interruption should be minimized, if not seamless / lossless.

[0182] A possible solution is for the gNB to provide the MCCH to the UE via dedicated signaling while the UE is still connected. In this way, the UE can start receiving the MTCH before transitioning to inactivity, thereby reducing service interruptions. One question is whether the dedicated signaling is an RRC reconfiguration or an RRC release; if it is an RRC reconfiguration, the UE may be able to start receiving the MTCH earlier.

[0183] Proposal 6: For a delivery mode 2 based solution, RAN2 should discuss whether to minimize service interruption when switching from delivery mode 1 to delivery mode 2.

[0184] Proposal 7: If Proposal 6 is agreed upon, RAN2 should further discuss whether to provide MCCH by dedicated signaling. Further consideration is needed on whether to use RRC reconfiguration or RRC release.

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

Claims

1. A communication method for use in a mobile communication system providing a multicast / broadcast service (MBS), comprising: receiving, by a user equipment in a Radio Resource Control (RRC) Connected state, one or more multicast sessions from a network using respective MBS configurations of the one or more multicast sessions; receiving, by the user equipment, an RRC release message from the network for transitioning the user equipment to an RRC inactive state; The RRC release message includes information indicating a multicast session to which the MBS configuration is continuously applied. Communication methods.

2. The RRC release message includes a list of MBS session IDs of multicast sessions to which the MBS configuration is continuously applied. The communication method according to claim 1 .

3. A user equipment in communication with a network providing a multicast / broadcast service (MBS), comprising: a receiving unit configured to receive one or more multicast sessions from the network using respective MBS configurations of the one or more multicast sessions when the user equipment is in a Radio Resource Control (RRC) connected state; The receiving unit receives an RRC release message from the network for transitioning the user equipment to an RRC inactive state; The RRC release message includes information indicating a multicast session to which the MBS configuration is continuously applied. User equipment.

4. A chipset for controlling a user device communicating with a network providing multicast / broadcast services (MBS), comprising: receiving one or more multicast sessions from the network using respective MBS configurations of the one or more multicast sessions when the user equipment is in a Radio Resource Control (RRC) Connected state; The receiving unit executes a process of receiving an RRC release message from the network for transitioning the user equipment to an RRC inactive state; The RRC release message includes information indicating a multicast session to which the MBS configuration is continuously applied. Chipset.

5. A program for controlling a user device communicating with a network providing a multicast / broadcast service (MBS), comprising: receiving one or more multicast sessions from the network using respective MBS configurations of the one or more multicast sessions when the user equipment is in a Radio Resource Control (RRC) Connected state; The receiving unit causes the user equipment to execute a process of receiving an RRC release message from the network for transitioning the user equipment to an RRC inactive state; The RRC release message includes information indicating a multicast session to which the MBS configuration is continuously applied. program.

6. A communication system including a network providing a multicast / broadcast service (MBS) and a user device communicating with the network, receiving one or more multicast sessions from the network using a respective MBS configuration of the one or more multicast sessions when the user equipment is in a Radio Resource Control (RRC) Connected state; The user equipment receives an RRC release message from the network for transitioning the user equipment to an RRC inactive state; The RRC release message includes information indicating a multicast session to which the MBS configuration is continuously applied. Communication systems.