COMMUNICATION METHOD, USER EQUIPMENT, PROCESSOR, PROGRAM, AND MOBILE COMMUNICATION SYSTEM

Abstract

This communication method used in a mobile communication system providing a multicast / broadcast service (MBS) includes: a step of a user device, in a radio resource control (RRC)-connected state having established a network with a first multicast radio bearer (MRB) and thereafter transitioning from the RRC connected state to an RRC inactive state, thereby suspending the first MRB; a step of the user device in the RRC inactive state receiving a multicast session from the network via a second MRB; and, in a case of performing RRC connection recovery for transitioning from the RRC inactive state to the RRC connected state, a step of the user device performing predetermined processing relating to switching from reception of the multicast session via the second MRB to reception of the multicast session via the first MRB.

Description

[Technical Field]

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

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

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

[0004] [Non-Patent Document 1] 3GPP Technical Specification: TS 38.300 V17.3.0 Summary of the Invention

[0005] 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 establishing a first multicast radio bearer (MRB) with a network, and then suspending the first MRB in response to transitioning from the RRC connected state to an RRC inactive state; a user equipment in the RRC inactive state receiving a multicast session from the network via a second MRB; and, when the user equipment performs RRC connection recovery, transitioning from the RRC inactive state to the RRC connected state, performing a predetermined process related to switching from receiving the multicast session via the second MRB to receiving the multicast session via the first MRB.

[0006] According to the second aspect User Device A user equipment (UE) used in a mobile communication system that provides a multicast / broadcast service (MBS) includes: a control unit that, in a radio resource control (RRC) connected state, establishes a first multicast radio bearer (MRB) with a network and then suspends the first MRB in response to transition from the RRC connected state to an RRC inactive state; and a receiving unit that, in the RRC inactive state, receives a multicast session from the network via a second MRB. When performing RRC connection recovery to transition from the RRC inactive state to the RRC connected state, the control unit performs a predetermined process related to switching from receiving the multicast session via the second MRB to receiving the multicast session via the first MRB. [Brief explanation of the drawings]

[0007] [Figure 1] 1 is a diagram illustrating a configuration of a mobile communication system according to an embodiment. [Figure 2] 1 is a diagram illustrating a configuration of a UE (user equipment) according to an embodiment. [Figure 3] A diagram showing the configuration of a gNB (base station) according to an embodiment. [Figure 4] FIG. 10 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data. [Figure 5] FIG. 1 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals). [Figure 6] FIG. 10 is a diagram showing an overview of an operation that enables a UE 100 in an RRC inactive state to perform multicast reception. [Figure 7] FIG. 2 is a diagram illustrating a first operation scenario according to the embodiment. [Figure 8] FIG. 10 is a diagram illustrating a second operation scenario according to the embodiment. [Figure 9] FIG. 1 is a diagram illustrating an outline of an operation according to an embodiment. [Figure 10] FIG. 10 is a diagram for explaining a PDCP count value. [Figure 11] FIG. 4 is a diagram illustrating an example of a first operation pattern according to the embodiment. [Figure 12] FIG. 10 is a diagram illustrating an example of the configuration of a PDCP status report. [Figure 13] FIG. 10 is a diagram illustrating an example of a second operation pattern according to the embodiment. [Figure 14] FIG. 10 is a diagram showing another example of the second operation pattern according to the embodiment. [Figure 15] FIG. 10 is a diagram illustrating an example of a third operation pattern according to the embodiment. [Figure 16] FIG. 10 is a diagram illustrating an example of a fourth operation pattern according to the embodiment. [Figure 17] FIG. 10 is a diagram illustrating an example of a fifth operation pattern according to the embodiment. [Figure 18] A diagram showing a PTM configuration distribution procedure for an activated multicast session. DETAILED DESCRIPTION OF THE INVENTION

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

[0009] (1) System configuration FIG. 1 is a diagram showing the configuration of a mobile communication system 1 according to an embodiment. The mobile communication system 1 conforms to the 3GPP standard 5th Generation System (5GS). In the following description, 5GS is used as an example, but the mobile communication system may also be at least partially applied to an LTE (Long Term Evolution) system. The mobile communication system may also be at least partially applied to a sixth generation (6G) system.

[0010] 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. The 5GC 20 may be simply referred to as the core network (CN) 20. The RAN 10 and the CN 20 constitute a network 5 of the mobile communication system 1.

[0011] The UE 100 is a mobile wireless communication device. The UE 100 may be any device used by a user. For example, the UE 100 may be a mobile phone terminal (including a smartphone) and / or a tablet terminal, a laptop 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).

[0012] The NG-RAN 10 includes a base station (referred to as "gNB" in the 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, etc. The term "cell" is used to indicate the smallest unit of a wireless communication area. The term "cell" is also used to indicate a function or resource that performs wireless communication with a UE 100. One cell belongs to one carrier frequency (hereinafter simply referred to as "frequency").

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

[0014] The 5GC20 includes an Access and Mobility Management Function (AMF) and a User Plane Function (UPF) 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 UPF are connected to the gNB 200 via an NG interface, which is an interface between a base station and a core network.

[0015] 2 is a diagram showing the configuration of a UE 100 (user equipment) according to the embodiment. The UE 100 has 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.

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

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

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

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

[0020] The transmission unit 210 performs various transmissions under the control of the control unit 230. The transmission 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.

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

[0022] 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 operations of the gNB 200 described above and below may be operations under the control of the control unit 230. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals, etc. The CPU executes programs stored in the memory to perform various processes.

[0023] The backhaul communication unit 240 is connected to neighboring 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 may be configured (i.e., functionally divided) with a CU (Central Unit) and a DU (Distributed Unit), and both units may be connected via an F1 interface, which is a fronthaul interface.

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

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

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

[0027] 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 UE100 and the MAC layer of gNB200 via transport channels. The MAC layer of gNB200 includes a scheduler, which determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to UE100.

[0028] The RLC layer transmits data to the RLC layer on the receiving side 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 logical channels.

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

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

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

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

[0033] 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 in accordance with 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.

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

[0035] (2) MBS The mobile communication system 1 can perform resource-efficient delivery using a multicast / broadcast service (MBS). Note that a session refers to a series of communications (from start to finish) for a service (application), and an MBS session refers to a session used in MBS.

[0036] 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. This delivery mode is also referred to as "Delivery Mode 1." Note that the UEs 100 can receive the multicast session only after joining the multicast session. Here, joining a multicast session may mean being registered in the network 5 (CN 20) as a UE 100 capable of receiving the multicast session.

[0037] 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 authorized 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 also referred to as "delivery mode 2".

[0038] The main logical channels used for MBS distribution are a multicast traffic channel (MTCH), a dedicated traffic channel (DTCH), and a multicast control channel (MCCH). The MTCH is a PTM downlink channel for transmitting MBS data of either a multicast session or a 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. Note that in distribution mode 1, MBS configuration for the UE 100 is performed using a dedicated control channel (DCCH).

[0039] In MBS multicast, the transmission of MBS data packets (also referred to as "MBS packets") can be either point-to-point (PTP) transmission, which is equivalent to unicast, or point-to-multipoint (PTM) transmission. In contrast, in MBS broadcast, only PTM transmission can be applied. In the case of PTP transmission, the gNB 200 can independently deliver individual copies of the MBS packet to each UE 100. For example, the gNB 200 schedules a UE-specific PDSCH scrambled with a UE-specific RNTI (e.g., C-RNTI) using a UE-specific PDCCH with a CRC (Cyclic Redundancy Code) scrambled with the UE-specific RNTI. On the other hand, in the case of PTM transmission, the gNB 200 delivers a single copy of the MBS packet to a set (group) of multiple UEs 100. For example, gNB200 schedules a group-common PDSCH scrambled by a group-common RNTI using a group-common PDCCH having a CRC scrambled by a group-common RNTI (e.g., G-RNTI).

[0040] Regarding the configuration for MBS broadcast, a UE 100 in an RRC idle state, an RRC inactive state, or an RRC connected state receives PTM configuration for a 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, System Information Block Type 20 (SIB20) includes the MCCH configuration. 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 an MBS session identifier (e.g., a Temporary Mobile Group Identity (TMGI)), associated MTCH scheduling information, and information on neighboring cells providing specific services on the MTCH.

[0041] On the other hand, with regard to MBS multicast, in the current 3GPP technical specifications, the UE 100 can receive multicast session data only in the RRC connected state. When the UE 100 that has joined a multicast session is in the RRC connected state and the multicast session is activated, the gNB 200 transmits an RRC Reconfiguration message including a PTM configuration for the multicast session to the UE 100. Such a PTM configuration is also referred to as a multicast radio bearer (MRB) configuration, MTCH configuration, or PTM configuration. The MRB configuration (MRB-ToAddMod) includes other parameters such as an MBS session identifier (mbs-SessionId), an MRB identifier (mrb-Identity), and a PDCP configuration (pdcp-Config) for the MRB (multicast MRB) to be configured for the UE 100.

[0042] 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. 6 is a diagram showing an overview of the operation.

[0043] Possible solutions for the UE 100 in the RRC inactive state to perform multicast reception include a solution based on delivery mode 1 shown in Fig. 6(a) and a solution based on delivery mode 2 shown in Fig. 6(b). It is assumed that the UE 100 supports multicast reception in the RRC inactive state and has already joined the multicast session.

[0044] In the delivery mode 1-based solution shown in Figure 6(a), in step S1, the gNB 200 transmits an RRC Reconfiguration message including MBS configuration (PTM configuration) for a multicast session to the UE 100 in the RRC connected state. The UE 100 receives multicast data on the MTCH via the multicast session (multicast MRB) based on the PTM configuration received in the RRC Reconfiguration message.

[0045] In step S2, the gNB 200 transmits an RRC 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 configuration (Suspend Config.) for the RRC Inactive state.

[0046] In step S3, in response to the reception of the RRC Release message in step S2, the UE 100 transitions from the RRC connected state to the RRC inactive (INACTIVE) state.

[0047] In step S4, the UE 100 in the RRC inactive state continues to use the PTM configuration of step S1 to receive multicast data on the MTCH via the multicast session.

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

[0049] Both the RRC Reconfiguration message and the RRC Release message are RRC messages transmitted individually to a UE on a Dedicated Control Channel (DCCH), and are hereinafter also referred to as dedicated RRC messages or dedicated signaling.

[0050] On the other hand, in the delivery mode 2-based solution shown in Fig. 6(b), in step S11, the gNB 200 transmits an RRC 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 configuration for the RRC Inactive state (Suspend Config.).

[0051] In step S12, in response to the reception of the RRC Release message in step S11, the UE 100 transitions to an RRC inactive (INACTIVE) state.

[0052] In step S13, the gNB 200 transmits an MCCH including an MBS setting (PTM setting) for the multicast session. The UE 100 receives the MCCH. Note that the UE 100 receives the SIB 20 prior to receiving the MCCH, and receives the MCCH based on the SIB 20. Note that the MCCH transmission (and reception) may be performed before step S11 or simultaneously with step S11.

[0053] In step S14, the UE 100 in the RRC inactive state receives multicast data on the MTCH via the multicast session based on the PTM configuration received on the MCCH in step S13. This enables the UE 100 in the RRC inactive state to perform multicast reception.

[0054] A solution that combines a solution based on distribution mode 1 and a solution based on distribution mode 2 can also be considered. For example, a mixed setting method is possible in which the initial setting of the MBS setting (PTM setting) is performed by dedicated signaling and the update of the MBS setting (PTM setting) is performed by MCCH.

[0055] (3) Operation according to the embodiment FIG. 7 is a diagram showing a first operation scenario according to the embodiment.

[0056] In the first operation scenario, first, the UE 100 in the RRC connected state in the cell of the gNB 200 establishes a multicast MRB with the gNB 200. The UE 100 in the RRC connected state receives a multicast session from the gNB 200 via the multicast MRB.

[0057] Second, the UE 100 transitions from the RRC connected state to the RRC inactive state. Here, the UE 100 suspends the multicast MRB (and PTM setting). Suspending the multicast MRB may mean stopping (deactivating) the use of the multicast MRB while maintaining the setting of the multicast MRB.

[0058] Furthermore, the UE 100 establishes a broadcast MRB for multicast with the gNB 200 before transitioning to the RRC inactive state, when transitioning to the RRC inactive state, or after transitioning to the RRC inactive state. The UE 100 in the RRC inactive state receives a multicast session from the gNB 200 via the broadcast MRB for multicast.

[0059] The UE 100 in the RRC connected state or the RRC inactive state may receive the PTM configuration on the MCCH from the gNB 200 and establish a broadcast MRB for multicast based on the PTM configuration. Alternatively, the UE 100 in the RRC connected state may receive the PTM configuration similar to the PTM configuration transmitted on the MCCH from the gNB 200 on the DCCH and establish a broadcast MRB for multicast based on the PTM configuration.

[0060] In addition, the UE 100 may establish a multicast MRB or a new type of MRB for multicast reception in an RRC inactive state instead of a broadcast MRB for multicast. Hereinafter, an MRB established by an MCCH or information equivalent thereto (MCCH content) is also referred to as a "first MRB."

[0061] Third, the UE 100 transitions from the RRC inactive state to the RRC connected state by the RRC connection recovery procedure. Here, the UE 100 resumes the suspended multicast MRB. The UE 100 in the RRC connected state receives a multicast session from the gNB 200 using the recovered multicast MRB (and the recovered PTM setting). Hereinafter, the multicast MRB recovered by the RRC connection recovery procedure is also referred to as a "second MRB."

[0062] In such a first operation scenario, UE 100, which is receiving multicast in the RRC inactive state, restores the multicast MRB (second MRB) when transitioning to the RRC connected state. Here, UE 100 uses the first MRB established based on the MCCH for multicast reception in the RRC inactive state. Therefore, it is necessary to switch the multicast reception of the same multicast session from the first MRB to the second MRB. For example, even for the same multicast session, it is necessary to change from the broadcast MRB established based on the MCCH to the multicast MRB.

[0063] A normal bearer type change is performed by reconfiguring a different bearer type for the same MRB setting using ToAddModList in the RRC Reconfiguration message, i.e., changing the MRB type (Modify). However, since the first MRB established based on the MCCH is not configured using ToAddModList, there is a problem in that the MRB type cannot be changed.

[0064] In addition, UE100 retains the multicast MRB setting due to RRC suspension, and if the multicast MRB is also restored by RRC connection recovery, it is necessary to clarify the relationship between the first MRB currently being received and the restored second MRB.

[0065] FIG. 8 is a diagram showing a second operation scenario according to the embodiment.

[0066] In the second operation scenario, first, the UE 100 in the RRC inactive state in the cell of the gNB 200 establishes a broadcast MRB (first MRB) for multicast with the gNB 200. The first MRB may be a new type of MRB. The UE 100 in the RRC inactive state starts receiving the multicast session via the first MRB.

[0067] Second, the UE 100 transitions from the RRC inactive state to the RRC connected state by the RRC connection recovery procedure. Here, the UE 100 establishes a second MRB (multicast MRB) based on, for example, the PTM setting in the RRC Reconfiguration message received from the gNB 200. The UE 100 in the RRC connected state receives a multicast session from the gNB 200 using the established second MRB.

[0068] Thus, in the second operation scenario, before UE 100 transitions to the RRC inactive state, i.e., when it is in the RRC connected state, the multicast MRB is not configured and the multicast session has not yet started. Then, when UE 100 is in the RRC inactive state, the multicast session is started and the first MRB is established based on the MCCH. Then, when UE 100 transitions from the RRC inactive state to the RRC connected state, it newly establishes the second MRB.

[0069] Here, the UE 100 uses the first MRB established based on the MCCH for multicast reception in the RRC inactive state, and therefore needs to switch the multicast reception of the same multicast session from the first MRB to the second MRB.

[0070] A typical bearer type change is performed by reconfiguring a different bearer type for the same MRB configuration using ToAddModList in the RRC Reconfiguration message, i.e., modifying the MRB type. However, since the first MRB established based on the MCCH is not configured using ToAddModList, there is a problem in that the MRB type cannot be changed. In addition, it is necessary to clarify the relationship between the currently received first MRB and the established second MRB.

[0071] FIG. 9 is a diagram showing an outline of the operation according to the embodiment.

[0072] In step S51, the UE 100 in the RRC inactive state receives a multicast session from the network 5 via the first MRB.

[0073] In step S52, when UE100 performs RRC connection recovery, transitioning from an RRC inactive state to an RRC connected state, it performs a predetermined process to switch from receiving a multicast session via a first MRB to receiving a multicast session via a second MRB different from the first MRB.

[0074] The following describes first to fifth operation patterns according to the embodiment. The first to fifth operation patterns differ in the content of the predetermined processing. Note that the first to fifth operation patterns assume the first operation scenario described above. That is, the second MRB is an MRB that was suspended when the UE 100 transitioned to the RRC inactive state. The predetermined processing includes processing to restore the suspended second MRB.

[0075] Alternatively, the first to fifth operation patterns may assume the second operation scenario described above. When the second operation scenario is assumed, the predetermined process includes a process of establishing a second MRB. In the following description of the embodiment, the term "recovery" of the second MRB may be read as "establishment."

[0076] (3.1) First operation pattern In the first operation pattern, the network 5 (gNB 200) is assumed to transmit the same multicast session for the multicast MRB (second MRB) and the broadcast MRB (first MRB) using the same resource (for example, the same PDSCH) when viewed from a lower layer (for example, a physical layer). Therefore, the UE 100 receives the same MTCH, and the PDCP count value, which is a variable (PDCP variable) used in the PDCP layer, is the same regardless of whether the MRB is a multicast MRB or a broadcast MRB.

[0077] As shown in Fig. 10, the PDCP count value is a variable consisting of a hyperframe number (HFN), which is incremented each time the PDCP sequence number goes around, and a PDCP sequence number (PDCP SN). Each of the network 5 (gNB 200) and the UE 100 manages the PDCP count value and updates the PDCP count value in response to the transmission and reception of PDCP packets. For example, the PDCP count value has a bit length of 32 bits, the PDCP SN has a bit length (SN_length) of 12 or 18 bits, and the HFN has a bit length obtained by subtracting the bit length of the PDCP SN from the bit length of the PDCP count value. In the following, the PDCP variable refers to the PDCP count value, but the PDCP variable may be only either the HFN or the SN.

[0078] In the current 3GPP technical specifications, the initial value of the PDCP count value of the multicast MRB is set from the gNB 200 to the UE 100 by an RRC Reconfiguration message. Therefore, the UE 100 may not be able to recover the multicast MRB (second MRB) unless it receives an RRC Reconfiguration message. In the first operation pattern, an operation for facilitating recovery of the multicast MRB (second MRB) will be described.

[0079] In the first operation pattern, the UE 100 in the RRC inactive state updates the PDCP variables (e.g., PDCP count value) of the first MRB (e.g., broadcast MRB) in response to packet reception of a multicast session via the first MRB. The predetermined processing includes a process of determining the PDCP variables (e.g., initial values ​​of the PDCP count value) of the second MRB (multicast MRB) based on the PDCP variables of the first MRB. For example, the UE 100 takes over the PDCP count value of the broadcast MRB when the multicast MRB is restored. This can facilitate the restoration of the multicast MRB (second MRB).

[0080] In the first operation pattern, the UE 100 may receive information from the network 5, at the time of transition to the RRC inactive state or before the time of the transition, that specifies a process of determining a PDCP parameter (e.g., an initial value of the PDCP count value) of the second MRB (multicast MRB) based on the PDCP parameter of the first MRB. That is, the network 5 (gNB 200) may configure the UE 100 as to whether or not to inherit the PDCP count value. This allows the network 5 to control the behavior of the UE 100 when the RRC connection is restored.

[0081] FIG. 11 is a diagram illustrating an example of a first operation pattern according to the embodiment.

[0082] In step S101, the UE 100 in the RRC connected state has already participated in a multicast session (hereinafter also referred to as a "particular multicast session").

[0083] In step S102, the gNB 200 transmits a message including a PTM setting for a specific multicast session to the UE 100 in the RRC connected state on the DCCH. The message may be an RRC Reconfiguration message or an RRC Release message. The message may include an instruction as to whether to take over the PDCP count value from the broadcast MRB when the multicast MRB is restored. In step S103, the UE 100 establishes a multicast MRB with the gNB 200 based on the PTM setting in step S102. The UE 100 may start receiving the specific multicast session on the MTCH using the established multicast MRB.

[0084] In step S104, the gNB 200 transmits a message including a PTM setting similar to the PTM setting transmitted on the MCCH to the UE 100 in the RRC connected state on the DCCH. The message may be an RRC Reconfiguration message or an RRC Release message. The message may include an instruction as to whether to inherit the PDCP count value from the broadcast MRB when the multicast MRB is restored. In step S105, the UE 100 establishes a broadcast MRB with the gNB 200 based on the PTM setting in step S104 and associates the broadcast MRB with the multicast MRB. The UE 100 may start receiving a specific multicast session on the MTCH using the established broadcast MRB. Note that steps S104 and S105 are optional operations. When the operations of steps S108 and S109 described below are performed, steps S104 and S105 can be omitted.

[0085] In step S106, the gNB 200 transmits an RRC Release message to the UE 100, causing the UE 100 to transition to an RRC inactive state. In response to receiving the RRC Release message, the UE 100 transitions from an RRC connected state to an RRC inactive state. When the RRC Release message is used in steps S102 and / or S104, the UE 100 may transition to the RRC inactive state in steps S102 and / or S104. In step S107, the UE 100 suspends the multicast MRB.

[0086] In step S108, gNB200 may transmit the PTM setting of the specific multicast session on the MCCH. In step S109, UE100 establishes a broadcast MRB with gNB200 based on the PTM setting of step S108, and UE100 associates the broadcast MRB with the multicast MRB. UE100 may start receiving the specific multicast session on the MTCH using the established broadcast MRB. Note that, when the above-mentioned steps S104 and S105 are optional operations, steps S108 and S109 can be omitted.

[0087] In step S110, the UE 100 in the RRC inactive state receives a specific multicast session via a broadcast MRB. In step S111, the UE 100 in the RRC inactive state updates (specifically, counts up) the PDCP count value in response to reception of the multicast session (specifically, reception of a PDCP packet).

[0088] Then, in step S112, the UE 100 receiving the multicast session in the RRC inactive state triggers the recovery of the RRC connection. For example, the UE 100 may trigger the recovery of the RRC connection by the occurrence of a RAN paging message or a Mobile Originated (MO) call.

[0089] In step S113, the UE 100 performs an RRC connection recovery procedure with the gNB 200. The RRC connection recovery procedure includes transmitting an RRC recovery request message from the UE 100 to the gNB 200 and transmitting an RRC recovery message from the gNB 200 to the UE 100. In step S114, the UE 100 transitions from the RRC inactive state to the RRC connected state.

[0090] In step S115, the UE 100 restores the multicast MRB in response to the restoration of the RRC connection. Here, the UE 100 transfers the current PDCP count value of the broadcast MRB to the multicast MRB. That is, the UE 100 sets the initial PDCP variable value of the multicast MRB based on the current PDCP count value.

[0091] In step S116, the UE 100 restores the multicast MRB and receives the specific multicast session on the MTCH via the restored multicast MRB.

[0092] (3.2) Second operation pattern In the second operation pattern, UE100 in the RRC inactive state updates the PDCP variables (e.g., PDCP count value) of the first MRB in response to receiving packets of a specific multicast session via the first MRB (e.g., broadcast MRB). The predetermined processing includes a process of transmitting a notification based on the PDCP count value of the first MRB to the network 5 (gNB200). This allows the network 5 (gNB200) to grasp the status of the PDCP variables of UE100 in the RRC inactive state and, for example, to transmit PDCP packets not yet received by UE100 for the first MRB to UE100 via the second MRB. Alternatively, the network 5 (gNB200) may transmit a switching setting or a switching instruction from the broadcast MRB to the multicast MRB to UE100 based on the grasped status of the PDCP variables.

[0093] In the second operation pattern, the second MRB (multicast MRB) may be an AM (Acknowledged Mode) MRB. The UE 100 may transmit a PDCP status report as a notification to the network 5 (gNB 200). FIG. 12 is a diagram showing an example of the configuration of a PDCP status report. The PDCP status report mainly includes a 1-bit "D / C" field, a 3-bit "PDU (Protocol Data Unit) Type" field, a 32-bit "FMC (First Missing COUNT)" field, and a variable-bit "Bitmap" field. The "D / C" field indicates whether this PDCP PDU is a PDCP Data PDU or a PDCP Control PDU. The PDCP status report corresponds to a PDCP Control PDU. The "PDU Type" field indicates whether this PDCP Control PDU is a "PDCP status report," "Interspersed ROHC feedback," or "EHC feedback." The "FMC (First Missing COUNT)" field indicates the count value (COUNT) of the first missing PDCP SDU within the reordering window. The count value (COUNT) consists of the HFN and PDCP SN. The "Bitmap" field indicates the missing PDCP SDUs and the PDCP SDUs that were correctly received by the receiving PDCP entity. Specifically, the "Bitmap" field indicates the reception status of the PDCP SDUs after the FMC as "0" (missing) or "1" (correctly received).

[0094] In the second operation pattern, the UE 100 may send a notification to the network 5 (gNB 200) including the latest PDCP count value of the first MRB (multicast MRB).

[0095] (3.2.1) Example of the second operation pattern In an example of a second operation pattern according to the embodiment, when the UE 100 recovers the AM MRB, the UE 100 transmits a PDCP status report to the gNB 200.

[0096] FIG. 13 is a diagram illustrating an example of a second operation pattern according to the embodiment.

[0097] The operations of steps S201 to S214 are the same as the operations of steps S101 to S114 in Fig. 11. However, in this operation example, the multicast MRB is an AM MRB. In step S202, S204, or S208, the gNB 200 may configure the UE 100 in advance as to whether or not to transmit a PDCP status report when the AM MRB is recovered.

[0098] In step S216, UE 100 in the RRC connected state transmits a PDCP status report to gNB 200. UE 100 may identify the SN of an unreceived packet (or may identify the SN of the most recent successfully received packet) based on the PDCP count value of the broadcast MRB used to receive a specific multicast session, and transmit the PDCP status report from (the PTP leg of) the multicast MRB to gNB 200. gNB 200 receives the PDCP status report.

[0099] In step S217, gNB200 retransmits the unreceived packets to UE100 using the PTP leg (or PTM leg) of the restored multicast MRB.

[0100] (3.2.2) Other examples of the second operation pattern In another example of the second operation pattern according to the embodiment, when the multicast MRB (second MRB) is restored, the UE 100 notifies the gNB 200 of the (latest) PDCP count value already received in the broadcast MRB (first MRB).

[0101] In this operation example, the PDCP count value may be different between the multicast MRB and the broadcast MRB. By transmitting information from the UE 100 to the gNB 200 about which packets the UE 100 has successfully received via the broadcast MRB (i.e., which initial packet the gNB 200 will use for the multicast MRB), the MRB switching can be smoothed.

[0102] FIG. 14 is a diagram showing another example of the second operation pattern according to the embodiment.

[0103] The operations of steps S251 to S264 are the same as the operations of steps S101 to S114 in Fig. 11. However, in this operation example, the PDCP count values ​​of the broadcast MRB (first MRB) and the multicast MRB (second MRB) may not be synchronized. For example, the gNB 200 may transmit the broadcast MRB (first MRB) and the multicast MRB (second MRB) on physically separate MTCHs (PDSCHs).

[0104] In step S265, when the UE 100 restores the RRC connection, the UE 100 restores the multicast MRB for the specific multicast session being received.

[0105] In step S266, the UE 100 notifies the gNB 200 of the (last or latest) PDCP count value (sequence value) successfully received in the broadcast MRB. The notification may be made in a PDCP status report, which is a type of PDCP control PDU. The notification may be made in a UE Assistance Information message, which is a type of RRC message. The notified PDCP count value does not correspond to a multicast MRB, but corresponds to a broadcast MRB (i.e., a different bearer). The gNB 200 receives the notification. The gNB 200 identifies the initial packet of data via the multicast MRB, taking the notification into consideration.

[0106] In step S267, the gNB 200 transmits the multicast session on the MTCH via the multicast MRB to the UE 100 in the RRC connected state. The UE 100 receives the multicast session.

[0107] (3.3) Third movement pattern When UE 100 receiving a specific multicast session in the RRC inactive state transitions to the RRC connected state, a multicast MRB may be configured for the specific multicast session by an RRC Reconfiguration message. In this case, there is a problem that it is not clear at what timing the reception operation of UE 100 is switched from the broadcast MRB (first MRB) to the multicast MRB (second MRB).

[0108] In the third operation pattern, the predetermined process stops multicast reception via the first MRB when the second MRB is restored. That is, when the multicast MRB used to receive a specific multicast session is restored, the UE 100 stops reception of the broadcast MRB that is receiving the specific multicast session. Here, the stop of reception of the broadcast MRB may be stop of MTCH reception and / or MCCH reception.

[0109] FIG. 15 is a diagram illustrating an example of a third operation pattern according to the embodiment.

[0110] The operations in steps S301 to S314 are the same as the operations in steps S101 to S114 in FIG.

[0111] In step S315, when the UE 100 restores the RRC connection, the UE 100 restores the multicast MRB for the specific multicast session being received in the broadcast MRB (first MRB).

[0112] In step S316, the UE 100 in the RRC connected state detects that multiple MRBs (broadcast MRB and multicast MRB) have been established for the specific multicast session, and prioritizes reception via the multicast MRB. For example, the UE 100 may discard the broadcast MRB. Alternatively, the UE 100 may stop the reception operation via the broadcast MRB without discarding the broadcast MRB. The UE 100 may perform such an operation after reception via the multicast MRB has started (for example, if reception has been successful without any problems or if reception has started successfully).

[0113] In step S317, the UE 100 receives a specific multicast session on the MTCH via the multicast MRB (second MRB).

[0114] (3.4) Fourth movement pattern If the PDCP count values ​​of the broadcast MRB (first MRB) and the multicast MRB (second MRB) are not synchronized, for example, if they are transmitted on physically different MTCHs (PDSCHs), the PDCP count value of the multicast MRB becomes indefinite from the perspective of UE 100 when the RRC connection is restored.

[0115] The technical specifications of 3GPP Release 17 introduce a mechanism in which the initial variable values ​​(HFN and SN) of the PDCP entity associated with a multicast MRB are explicitly notified from the gNB 200 to the UE 100 in an RRC Reconfiguration message. In the third operation pattern, the UE 100 switches reception from a broadcast MRB (first MRB) to a multicast MRB (second MRB) when the initial value of the PDCP variable is notified from the gNB 200 to the UE 100.

[0116] In the third operation pattern, the predetermined processing includes processing to start multicast reception via the second MRB and / or stop multicast reception via the first MRB when initial value information indicating the initial values ​​of PDCP variables used in the second MRB is notified from the network 5 (gNB200) to the UE 100. In other words, when the multicast MRB is restored and the initial values ​​of the PDCP variables are notified from the gNB200, the UE 100 starts reception via the multicast MRB and / or stops reception via the broadcast MRB.

[0117] FIG. 16 is a diagram illustrating an example of a fourth operation pattern according to the embodiment.

[0118] The operations in steps S401 to S414 are the same as the operations in steps S101 to S114 in FIG.

[0119] In step S415, when the UE 100 restores the RRC connection, the multicast MRB is restored for the specific multicast session being received via the broadcast MRB (first MRB). However, the UE 100 in the RRC connected state continues to receive the specific multicast session via the broadcast MRB.

[0120] In step S416, the gNB 200 transmits the initial values ​​of the PDCP variables (PDCP count value, HFN, and / or PDCP SN) for the restored multicast MRB to the UE 100 on the DCCH (for example, in an RRC Reconfiguration message). The gNB 200 may further notify the UE 100 of information on the MRB to which the PDCP variable initial values ​​apply, for example, an MRB ID and / or information that the PDCP variable initial values ​​apply to a multicast MRB.

[0121] In step S417, the UE 100 in the RRC connected state sets the initial value. , B The multicast reception via the Broadcast MRB may be stopped (and discarded).

[0122] In step S418, the UE 100 receives the specific multicast session on the MTCH via the multicast MRB (second MRB).

[0123] In step S416, the gNB 200 may notify the UE 100 of a difference (offset) between the PDCP count value of the multicast MRB (second MRB) and the PDCP count value of the broadcast MRB (first MRB). That is, the initial value information transmitted from the gNB 200 to the UE 100 in step S416 may be offset information relating to the difference between the initial value of the PDCP variable of the first MRB and the initial value of the PDCP variable used in the second MRB. This may reduce the number of bits of the initial value information compared to notifying the initial value of the PDCP variable used in the second MRB as the initial value information. In this case, in step S417, the UE 100 may determine the PDCP count value of the multicast MRB (second MRB) by adding the notified difference value to the PDCP count value of the broadcast MRB (first MRB).

[0124] (3.5) Fifth movement pattern In the fifth operation pattern, the predetermined processing includes a processing of receiving a switching instruction from the network 5 to instruct switching from the first MRB (broadcast MRB) to the second MRB (multicast MRB). That is, the gNB 200 explicitly instructs the UE 100 to switch the MRB from the broadcast MRB to the multicast MRB.

[0125] FIG. 17 is a diagram illustrating an example of a fifth operation pattern according to the embodiment.

[0126] The operations in steps S501 to S514 are the same as the operations in steps S101 to S114 in FIG.

[0127] In step S515, when the UE 100 restores the RRC connection, the UE 100 restores the multicast MRB for the specific multicast session being received in the broadcast MRB.

[0128] In step S516, the gNB 200 transmits an instruction to switch the MRB used to receive the specific multicast session (switch to the multicast MRB) to the UE 100 on the DCCH (for example, in an RRC Reconfiguration message). The instruction may include the MBS session ID of the specific multicast session and / or the MRB ID of the multicast MRB.

[0129] Here, it is assumed that the gNB 200 wants to continue receiving via the broadcast MRB, for example, when the PTM transmission for the multicast MRB is not yet ready (when only PTP transmission is being performed). In such a case, the gNB 200 instructs to switch to receiving via the multicast MRB when the PTM transmission of the multicast MRB starts.

[0130] In step S517, the UE 100 in the RRC connected state changes the reception path of the specific multicast session to the multicast MRB in response to the instruction in step S516. Here, the UE 100 may stop receiving the broadcast MRB (and discard the broadcast MRB).

[0131] In step S518, the UE 100 receives a specific multicast session on the MTCH via the multicast MRB (second MRB).

[0132] (4) 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 case of the RRC idle state, the above-described RRC Resume is replaced with RRC Establishment. For example, in 3GPP Release 19 and later, when the UE 100 in the RRC idle state becomes able to receive a multicast session, a multicast MRB is established after the RRC connection (set by an RRC Reconfiguration message).

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

[0134] In the above-described embodiment and example, 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.

[0135] Furthermore, the term "network node" primarily refers to a base station, but may also refer to a core network device or part of a base station (CU, DU, or RU). A network node may also be configured by a combination of at least part of a core network device and at least part of a base station.

[0136] A program may be provided that causes a computer to execute each process performed by UE100 or gNB200. The program may be recorded on a computer-readable medium. The computer-readable medium can be used to install the program 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 UE100 or gNB200 may be integrated, and at least a part of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).

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

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

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

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

[0141] (5) Supplementary notes

[0142] (Appendix 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) inactive state receiving a multicast session from a network via a first multicast radio bearer (MRB); When the user equipment performs an RRC connection recovery in which the user equipment transitions from the RRC inactive state to an RRC connected state, performing a predetermined process to switch from receiving the multicast session via the first MRB to receiving the multicast session via a second MRB different from the first MRB. Communication method.

[0143] (Appendix 2) The second MRB is an MRB that is suspended when the user equipment transitions to the RRC inactive state, The step of performing the predetermined process includes a step of restoring the suspended second MRB. 1. A communication method as described in Appendix 1.

[0144] (Appendix 3) The method further comprises a step of updating PDCP variables of the first MRB by the user equipment in the RRC inactive state in response to receiving packets of the multicast session via the first MRB; The step of performing the predetermined processing includes a step of performing a process of determining a PDCP variable of the second MRB based on a PDCP variable of the first MRB. 3. A communication method according to claim 1 or 2.

[0145] (Appendix 4) The method further comprises receiving information from the network specifying that the user equipment should perform the determining process at or before the transition to the RRC inactive state. 3. A communication method as described in Appendix 3.

[0146] (Appendix 5) The method further comprises a step of updating PDCP variables of the first MRB by the user equipment in the RRC inactive state in response to receiving packets of the multicast session via the first MRB; The step of performing the predetermined process includes a step of transmitting a notification based on the PDCP count value of the first MRB to the network. 5. A communication method according to any one of claims 1 to 4.

[0147] (Appendix 6) The second MRB is an AM (Acknowledged Mode) MRB, The step of sending the notification includes the step of sending a PDCP status report to the network as the notification. 1. A communication method as described in Appendix 5.

[0148] (Appendix 7) The step of sending the notification includes the step of sending the notification to the network, the notification including the latest PDCP count value of the first MRB. 7. A communication method according to claim 5 or 6.

[0149] (Appendix 8) The step of performing the predetermined process includes a step of stopping multicast reception via the first MRB when the second MRB is restored or established. 8. A communication method according to any one of claims 1 to 7.

[0150] (Appendix 9) The step of performing the predetermined processing includes a step of starting multicast reception via the second MRB and / or stopping multicast reception via the first MRB when initial value information indicating initial values ​​of PDCP variables used in the second MRB is notified from the network to the user device. 9. A communication method according to any one of appendices 1 to 8.

[0151] (Appendix 10) The initial value information is offset information regarding a difference between the initial value of the PDCP variable of the first MRB and the initial value of the PDCP variable used in the second MRB. 9. A communication method as described in Appendix 9.

[0152] (Appendix 11) The step of performing the predetermined process includes a step of receiving a switching instruction from the network instructing switching from the first MRB to the second MRB. A communication method according to any one of Supplementary Notes 1 to 10.

[0153] (Appendix 12) A user device for use in a mobile communication system that provides a multicast / broadcast service (MBS), a receiving unit configured to receive a multicast session from a network via a first multicast radio bearer (MRB) in a radio resource control (RRC) inactive state; and a control unit that performs a predetermined process to switch from receiving the multicast session via the first MRB to receiving the multicast session via a second MRB different from the first MRB when performing RRC connection recovery to transition from the RRC inactive state to an RRC connected state. User equipment.

[0154] (6) Supplementary notes 1. Introduction The work item on Enhancements to MBS (eMBS) aims to support multicast reception by UEs during inactivity as follows: Specifies support for multicast reception by UE in RRC inactive state [RAN2, RAN3] PTM configuration for UE receiving multicast in RRC inactive state [RAN2] Investigating the impact of mobility and state transitions on UEs receiving multicast in RRC inactive mode (seamless / lossless mobility is not required) [RAN2, RAN3]

[0155] RAN2 has been discussing this objective and has reached a series of agreements. Based on these agreements, the PTM configuration and mobility aspects of multicast reception in inactive mode are discussed in this appendix.

[0156] 2. Discussion 2.1.PTM setting distribution Rel-17 specifies two distribution modes: one called "Distribution Mode 1" for multicast sessions and the other called "Distribution Mode 2" for broadcast sessions. In Distribution Mode 1, MTCH reception is configured by RRC reconfiguration only for UEs in the connected state, while in Distribution Mode 2, MTCH reception is configured by MCCH for UEs in all RRC states.

[0157] RAN2#119e specifies these delivery modes, namely, option 1, option 2, and a "mix" of these options, as candidates for multicast reception in inactive mode.

[0158] Regarding the distribution of PTM settings, RAN2 is further considering the following solutions: Option 1: Dedicated Signaling Option 2: Solution based on SIB+MCCH This does not preclude a "mix" of options.

[0159] RAN2#120 has reached a consensus to move forward with a "mixed approach." We have a mixed approach and start as follows: 1. If the NW configures the UE to continue multicast reception in an inactive state, the NW provides PTM configuration for activated multicast sessions via RRC dedicated signaling, at least to the serving cell (other cases require further consideration). 2. MCCH is used when the PTM setting needs to be changed or when the PTM setting needs to be indicated during transition across serving cells / gNBs. Session state changes and other indications require further study. 3. It is assumed that the UE can receive the multicast service after joining the session. 4. Whether the MCCH configuration is initially provided to the UE via dedicated signaling needs further consideration.

[0160] According to the above agreement #1, the network sets the PTM configuration of the activated multicast session to the UE via dedicated signaling. It is assumed that since the multicast session is activated, the connected UE is already receiving the multicast session and this PTM configuration allows the UE to continue receiving the multicast session even after transitioning to inactive.

[0161] In this disclosure, the "mixed approach" agreed upon by RAN2 means using the MCCH for updating PTM configuration, etc., and is therefore closer to Rel-17 Delivery Mode 2. In this sense, dedicated signaling only provides MCCH content (e.g., MBS Broadcast Configuration) rather than Rel-17-specific multicast configuration (e.g., mrb-ToAddModList). Such dedicated signaling is useful for avoiding UEs monitoring the MCCH in the Connected state and minimizing service interruptions due to delays in MCCH acquisition after transitioning to Inactive.

[0162] Proposal 1: RAN2 should agree to provide the content of MCCH (i.e., MBS Broadcast Configuration) for multicast reception when dedicated signaling is inactive.

[0163] On the other hand, since RAN2 has agreed that an inactive UE can start receiving a multicast session, i.e., Scenario 2 of the following agreement, it is unclear what can be configured for an inactivated multicast session.

[0164] In Rel-18, multicast reception for an inactive UE supports at least the following scenarios, assuming the UE already has a valid PTM configuration: Scenario 1: The UE is connected and receiving multicast, enters inactive, and continues receiving multicast. Scenario 2: The UE joins a multicast session and is induced to be inactive, and the UE starts receiving the multicast session. Further consideration is needed regarding state changes, such as changes due to services that are not provided in an inactive state.

[0165] It is assumed that the actual PTM configuration cannot be provided for an inactivated multicast session, but will be provided once the multicast session is activated. In Rel-17, an inactive UE transitions to connected upon receiving a group paging for multicast session activation. Therefore, some kind of indication may be provided in advance via dedicated signaling to allow the UE to remain inactive and use the PTM configuration obtained from the MCCH for the multicast session. Another approach is for such an indication to be provided by group paging as discussed in the following section.

[0166] Proposal 2: RAN2 should discuss whether any configuration should be provided via dedicated signaling if the UE transitions to inactive before the multicast session is activated.

[0167] As per agreement #2 above, MCCH is used when the PTM setting needs to be changed or when the PTM setting needs to be indicated during transition across serving cells / gNBs. The session status change and other indications are a bit ambiguous. That is, it is unclear whether MCCH is used for indication or to provide PTM settings. If it were only an indication, it could mean MCCH Change Notification. However, MCCH provides PTM settings, e.g., updates the PTM setting configuration of inactive UEs.

[0168] Proposal 3: RAN2 should clarify whether MCCH provides PTM configuration for multicast sessions of inactive UEs, for example, when the PTM configuration is updated.

[0169] RAN2 leaves open the question of whether the MCCH configuration is initially provided to the UE via dedicated signaling. MCCH configuration means SIB20. As RAN2 agreed, dedicated signaling is inactive and provides PTM configuration for multicast reception, so the UE does not need to read the MCCH immediately, and does not need to know what SIB20, i.e., the MCCH configuration, is. Naturally, the UE will later obtain SIB20 and MCCH to check whether the PTM configuration has been updated.

[0170] Proposal 4: RAN2 should agree that MCCH configuration (i.e., SIB20) does not need to be provided via dedicated signaling.

[0171] 2.2. UE Mobility and Service Continuity RAN2#120 agreed that MCCH will be used during UE transition. This disclosure has a mixed approach and begins as follows. 1. If the NW configures the UE to continue multicast reception in an inactive state, the NW provides the PTM configuration of the activated multicast session via RRC dedicated signaling, at least to the serving cell (other cases require further consideration). 2. MCCH is used when the PTM setting needs to be changed or when the PTM setting needs to be indicated during transition across the serving cell / gNB. Session state changes and other indications require further study. 3. It is assumed that the UE can receive the multicast service after joining the session. 4. Whether the MCCH configuration is initially provided to the UE via dedicated signaling needs further consideration.

[0172] WID states that seamless / lossless mobility is not required. Specifies support for multicast reception by UE in RRC inactive state [RAN2, RAN3] PTM configuration for UE receiving multicast in RRC inactive state [RAN2] Investigate the impact of mobility and state transitions of UEs receiving multicast in RRC inactive mode (seamless / lossless mobility is not required) [RAN2, RAN3]

[0173] As explained in Section 2.1, the new PTM configuration distribution method is similar to Rel-17 distribution mode 2. Therefore, it is natural to use the Rel-17 MBS broadcast service continuity mechanism as a baseline. In this case, the multicast session must first provide neighbor cell information from the MCCH to ensure that the UE is allowed to prioritize MBS frequencies during cell reselection.

[0174] As expected for LTE SC-PTM and NR MBS broadcast, it is up to the UE implementation to ensure service continuity, including how to use neighboring cell information, whether to prioritize MBS frequencies, and how / when to acquire MCCH from neighboring cells.

[0175] Proposal 5: RAN2 should agree that neighbor cell information for multicast sessions will be provided by MCCH, similar to MBS broadcasts.

[0176] Proposal 6: RAN2 should agree that UEs are allowed to prioritize MBS multicast frequencies during cell reselection, similar to MBS broadcast.

[0177] Some companies have proposed enabling PTM settings in multiple cells to improve service continuity during UE transitions. While intra-gNB PTM settings can be easily aligned (if necessary) for each cell, inter-gNB PTM settings are difficult and require negotiation involving the Xn-AP. For this small enhancement, there is no harm in limiting it to the intra-gNB case. Therefore, RAN2 needs to discuss whether PTM settings can be applied to multiple cells within a gNB.

[0178] Proposal 7: RAN2 should consider whether PTM configuration can be applied to multiple cells within a gNB, where the intra-gNB scenario is the basic assumption.

[0179] Another consideration is QoS control by the network. Although WID states that seamless / lossless mobility is not required, this does not mean that all multicast sessions that a UE can receive inactively do not require seamless / lossless mobility. For example, the network may need to transition the UE to inactive due to congestion, but due to QoS requirements, the UE may need to transition after connecting. For seamless / lossless mobility, Rel-17 MBS multicast supports handover in the RRC connection. Therefore, the network may need to have the option to control whether the UE performs cell reselection or resumes the RRC connection before cell reselection (in the case of handover in connected mode).

[0180] Proposal 8: RAN2 should discuss whether the gNB can indicate whether the UE is allowed to perform inactive mode mobility or whether the RRC connection should be resumed before cell reselection for better QoS control.

[0181] (7) Supplementary Notes 1. Introduction The work items related to enhancing MBS (eMBS) are as follows: Specify support for multicast reception by UE in RRC inactive state [RAN2, R AN3] PTM configuration for UE receiving multicast in RRC inactive state [RAN2] Study the impact of mobility and state transitions for UEs receiving multicast in RRC inactive (seamless / lossless mobility is not required) [RAN2, RAN3]

[0182] Based on these agreements, notification and RRC state transition aspects for multicast reception in inactive mode are discussed in this appendix.

[0183] 2. Discussion In RAN2#119e, aspects related to RRC state changes remain an issue for further study. In Rel-18, multicast reception for UEs in inactive mode supports at least the following scenarios, assuming the UE already has a valid PTM configuration: Scenario 1: The UE is connected and receiving multicast, enters inactive and continues receiving multicast. Scenario 2: The UE joins a multicast session and is directed to inactivity, and the UE starts receiving the multicast session. Further consideration is needed regarding changes due to state changes, such as services that are not provided when inactive.

[0184] From the network and UE perspective, there are several possible cases related to RRC state changes, some of which are also related to notifications sent from the network to the UE. Therefore, the following cases are considered:

[0185] 2.1. Case 1: Multicast Session Inactivity / Release The UE is informed of the agreed RAN2#119bis-e when the multicast session is deactivated and Rel-17 mechanisms are applicable when the multicast session is released. If the UE is in RRC inactive and configured to receive a multicast session in RRC inactive, the UE may be notified when the multicast session is deactivated, for example via group paging, MCCH, or other methods that require further discussion. The Rel-17 mechanism (NAS-based indication) is applicable for multicast session release. If necessary, further consideration will be given.

[0186] If an inactive UE receives an MBS service and the gNB can stop transmitting PTM / MTCH accordingly, the multicast session is considered to be inactivated or released. In this case, there is no reason for the UE to continue monitoring the MTCH, but the UE shall do so unless the PTM configuration is removed. From a UE power saving point of view, it is desirable to stop monitoring the MTCH as soon as possible.

[0187] Observation 1: It is inefficient in terms of UE power consumption for the UE to continue monitoring the PTM / MTCH even after the multicast session has been stopped or released.

[0188] Therefore, the UE behavior upon multicast session inactivation should be clarified, i.e., the UE should be allowed to stop the monitoring MTCH when it receives a notification for multicast session inactivation, regardless of how it is notified, and should remain in RRC inactive upon receiving such a notification.

[0189] Proposal 1: RAN2 should agree that upon receiving the multicast session release notification, the UE is allowed to stop the monitor MTCH.

[0190] Regarding the termination of a multicast session, RAN2 considers that the method of notifying the UE, such as group paging, MCCH, or other methods, is an issue that requires further study.

[0191] In LTE SC-PTM, the SC-PTM Stop Indication MAC CE is introduced to notify the UE that it will stop monitoring the PDCCH for G-RNTI. The MAC CE is multiplexed onto the SC-MTCH associated with the G-RNTI. This lightweight signaling can work under the constraint of a one-to-one mapping between TMGI and G-RNTI. On the other hand, NR MBS allows many-to-one mapping between TMGI and G-RNTI, so when a MAC CE is introduced, it is necessary to indicate the deactivated TMGI. Since the MAC CE is transmitted together with the MTCH, it is expected to minimize the delay between receiving the last multicast data and stopping monitoring the MTCH.

[0192] Another option is to reuse group paging, which is used to simultaneously page multiple UEs in a group using TMGI instead of UE-ID. Since the existing paging group list (i.e., the list of TMGI) is applicable to legacy UEs as well, a new TMGI list needs to be added for group paging to avoid impacting legacy UEs. This means that there is a delay between receiving the last multicast data and stopping MTCH monitoring based on the I-DRX period.

[0193] The third option is to reuse the MCCH. There are two possibilities for notifying the deactivation of a multicast session: either remove the PTM configuration for the deactivated TMGI or add a new indication to notify the deactivated TMGI. In either case, the MCCH needs to be updated, so an MCCH change notification needs to be sent to the UE in advance. This requires a longer delay between the reception of the last multicast data and the stopping of MTCH monitoring.

[0194] According to the RAN2 agreement that "MCCH is used when the PTM setting needs to be changed," inactive UEs need to wake up at the timing of MCCH, and deactivation of a multicast session can be interpreted as a kind of "change in PTM setting." Therefore, if the corresponding PTM setting is deleted from MCCH, the UE can notice that the multicast session has been deactivated. However, it takes time for the UE to stop monitoring MTCH. Therefore, notification by the MAC CE is preferable.

[0195] In summary, the delay between receiving the last multicast data and stopping MTCH monitoring can directly affect unnecessary UE power consumption. From the UE power saving point of view, the notification should be sent as soon as possible, so the first option using MAC CE is the preferred solution.

[0196] Proposal 2: RAN2 should agree that when a multicast session becomes inactive, a new MAC CE (similar to the existing SC-PTM Stop Indication) is notified to the inactive UE.

[0197] For multicast session release, the NAS-based indication in Rel-17 agreed by RAN2 applies, which may be "Multicast session release requested by network or MBS session release." This procedure assumes that the UE is paged by the gNB and transitions to RRC Connected to communicate with AMF. This procedure can reuse existing group paging (or traditional individual paging).

[0198] However, for optimization purposes, if a new MAC CE is introduced for multicast session invalidation notification as in Proposal 2, this procedure can be freely used: the gNB sends a MAC CE to allow the UE to stop monitoring the MTCH, and then the gNB distributes the timing of pages to the UE, i.e., using legacy dedicated paging, to avoid signaling storms caused by simultaneous RRC state transitions.

[0199] Proposal 3: RAN2 should agree that no enhancements specific to multicast session release are required, i.e. UEs will transition to RRC Connected via existing (group) paging.

[0200] 2.2. Case 2: Selective Transition When a Multicast Session is Active RAN2#119e reached the following agreement regarding Case 2: It is up to the gNB to decide whether a UE can receive a multicast session inactively, and further consideration is needed as to what information should be provided to the gNB to make such a decision (related to the discussion in SA2). A gNB is supported to send one multicast session to both connected and inactive UEs in the same cell, but how a gNB configures this requires further study. It is assumed that the network can select which UEs receive in RRC Inactive and which UEs receive in RRC Connected, and can transition UEs between states for multicast service reception.

[0201] When releasing a UE to inactivity, the gNB can select the UE to release in the same way as it does now, i.e., by RRC Release with Suspend Config, based on the UE capabilities, the UE assistance information, and / or the CN assistance information (if specified). Therefore, no enhancements are foreseen for the RRC release message regarding selective transition of UEs.

[0202] Observation 2: The existing RRC release is used by the gNB to select which UEs to release.

[0203] Regarding multicast session activation, RAN2#119bis-e agreed to the following: When a Rel-18 session becomes active, it can be notified to UEs in an inactive state (details need to be further explored). As a baseline, group paging can be used to notify Rel-18 UEs of session activation (details, e.g., UE behavior upon receiving such a group notification, require further study). How to determine whether the UE can trust the multicast session in RRC inactive when the session is activated will be determined through further consideration, taking into account the following solutions (the description can be further updated if necessary, and multiple solutions may be required): 1. When a multicast session is activated, the UE can receive the multicast session in RRC Inactive if the PTM configuration used in RRC Inactive for the session is available to the UE and the UE is already joined to the session (e.g., configuration provided to the UE via dedicated RRC signaling or MCCH), otherwise it returns to RRC Connected to receive the multicast session. 2. When a multicast session is activated, the UE is informed by group paging whether it can receive the multicast session in RRC inactive (detailed signaling needs further study). 3. Before the UE is released, the UE is configured by dedicated signaling whether it can receive the multicast session in RRC inactive. When the multicast session becomes active, the UE will either stay in RRC inactive or resume RRC connected accordingly (detailed signaling needs further study).

[0204] In Rel-17, multicast session activation is signaled by group paging. In Rel-18, this does not need to be different from the legacy mechanism, so RAN2 must ensure that UEs are notified of multicast session activation using group paging.

[0205] Proposal 4: RAN2 should ensure that group paging can be used to notify Rel-18 UEs of session activation.

[0206] In addition to the confirmation, RAN2, as mentioned above, specifies three options for UE behavior upon receiving a multicast activation notification.

[0207] In option 1, a UE can receive a multicast session even in an inactive state if it has a valid PTM configuration. Since an inactive UE cannot receive a multicast session without a PTM configuration, this can be considered the baseline for all other UE behavior. Therefore, option 1 should be agreed upon.

[0208] Proposal 5: RAN2 UE Behavior Option 1 If, when a multicast session is activated, the PTM configuration used in RRC inactive for the session is available to the UE and the UE is already joined to the session (e.g., configuration provided to the UE via dedicated RRC signaling or MCCH), then the UE can receive the multicast session in RRC inactive.

[0209] In option 2, the UE is informed at the time of receiving the group paging whether it should receive the multicast session inactively.

[0210] In the case of option 3, the UE is informed in advance by an RRC reconfiguration or an RRC release whether it should receive the multicast session inactively.

[0211] The mechanisms for these two options are very similar, except for the messages that instruct the UE to do so. Therefore, these options can be analyzed from the perspective of the motivations for inactive multicast reception: network congestion and UE power saving.

[0212] In the case of network congestion, it can be assumed that the cell load changes from moment to moment. In Option 2, the gNB can take the latest load status into account when deciding whether the UE should remain inactive because the instruction is sent within the group paging. On the other hand, in Option 3, the gNB needs to predict the future load when notifying the UE, and the cell load may have changed by the time the gNB actually sends the group paging. This poses a risk of worsening congestion, causing an increase in the number of UEs transitioning to connected, or an increase in the number of UEs remaining inactive even after the congestion is resolved. Therefore, Option 2 is preferable for efficiently controlling the UE's RRC state.

[0213] From the perspective of UE power saving, it is assumed that some kind of "power saving preference" is introduced into the UE assistance information. Such a preference indication can only be sent by a connected UE. Thus, the gNB can indicate to the UE whether the UE was "inactive" and allowed to receive the multicast session when the UE was previously "connected". If such a preference indication is not introduced, the gNB does not know whether the UE prefers power saving or not, and can therefore indicate it to the UE at any time. Therefore, there is no difference between option 2 and option 3.

[0214] Based on the above analysis, Option 2 is considered to be more efficient and can cover the usage volume of Option 3. Therefore, RAN2 should at least agree to Option 2.

[0215] Proposal 6: RAN2 should agree to UE behavior option 2: "When a multicast session becomes active, the UE is indicated by group paging whether it can receive the multicast session in RRC inactive (detailed signaling needs further study)."

[0216] Regarding group paging in option 2, the current specification prescribes the UE behavior upon receiving a group paging. This means that if the paging message contains the TMGI of interest, all UEs will initiate the RRC resume procedure. Therefore, if selective paging is required in option 2, the gNB cannot include the TMGI in the paging message. If the gNB includes only the UE-ID for selective paging (i.e., legacy dedicated paging without TMGI for paging selected Rel-18 UEs), it cannot page inactive Rel-17 UEs waiting for multicast activation. Furthermore, this is inefficient in terms of signaling overhead.

[0217] Observation 3: That is, if the paging message contains a TMGI of interest, all UEs transition to RRC Connected.

[0218] Assuming that the current paging group list is set in the group paging message to page at least Rel-17 UEs, Rel-18 UEs will also be paged by the interested TMGI. Therefore, to prevent selected UEs from transitioning to Connected, it is conceivable to define a new list of UE-IDs, the "Paging Cancellation List" (or "Inactive Allowed List"), so that the UEs listed in this list remain inactive to receive the multicast session.

[0219] Therefore, RAN2 should discuss how to enhance group paging to page a subset of UEs.

[0220] Proposal 7: RAN2 should discuss how to enhance group paging to page a subset of UEs, for example using a new UE-ID list that remains inactive for multicast session reception.

[0221] 2.3. Case 3: QoS Enforcement RAN2#119e reached the following agreement related to Case 3: RRC inactive multicast reception does not support HARQ feedback and PTP.

[0222] According to the agreement, inactive multicast reception is similar to MBS broadcast reception (so-called delivery mode 2) specified in Rel-17. MBS broadcast is best-effort.

[0223] On the other hand, guaranteeing QoS / reliability is an important issue for multicast sessions. SA2 also asked whether there is a difference in multicast reception quality / reliability between connected and inactive, and RAN2#119bis-e agreed on the following answer: RAN2 Q1-a When there is a large difference in the quality and reliability of MBS data reception between UEs in RRC connected state and UEs in RRC inactive state: The quality and reliability of MBS data reception between a UE in RRC connected state and a UE in RRC inactive state may differ since HARQ feedback and PTP transmission are not supported and seamless / lossless mobility is not required for multicast reception in RRC inactive.

[0224] In RAN2#119e, it is proposed to introduce reception quality thresholds such as RSRP and BLER, which are expected to be used to ensure a certain level of QoS requirements for multicast reception. They are also useful for the network to manage QoS requirements. If inactive multicast reception cannot meet the corresponding QoS requirements, the UE should transition to connected and use HARQ feedback / retransmissions and / or PTP (or split MRBs) to guarantee reception quality.

[0225] Observation 4: A multicast session should ensure certain QoS requirements even when the UE is inactive.

[0226] Regarding the RSRP threshold, because NR MBS is assumed to be a single-cell transmission method, it is considered that the UE must always transition to connected mode whenever it moves to the cell edge or performs cell reselection, which may not be optimal depending on the deployment in terms of network congestion and UE power saving.

[0227] The BLER threshold is considered to be easier to ensure QoS requirements, so if RRC state transitions based on reception quality are to be introduced, these options should be discussed.

[0228] Proposal 8: RAN2 should agree that a UE in inactive state should transition to connected if the reception quality becomes worse than a threshold (e.g., RSRP or BLER).

[0229] 2.4. Case 4: Updating PTM Settings RAN2 agreed on the following prerequisites for its work: This disclosure has a mixed approach and begins as follows. 1. If the NW configures the UE to continue multicast reception in an inactive state, the NW provides the PTM configuration of the activated multicast session via RRC dedicated signaling, at least to the serving cell (other cases require further consideration). 2. MCCH is used when the PTM setting needs to be changed or when the PTM setting needs to be indicated during transition across serving cells / gNBs. Session status changes and other indications require further study. 3. It is assumed that the UE can receive the multicast service after joining the session. 4. Whether the MCCH configuration is initially provided to the UE by dedicated signaling needs further consideration.

[0230] That is, the UE can remain inactive to obtain the updated PTM configuration. Therefore, from the perspective of an inactive UE, the distribution method of the new PTM configuration is similar to distribution mode 2 in Rel-17. In this case, it is very easy to reuse the existing MCCH change notification to notify the PTM configuration update. Therefore, no additional notification is required to update the PTM configuration of an inactive UE.

[0231] Proposal 9: RAN2 should agree that the existing MCCH change notification will be used to update the PTM configuration.

[0232] 2.5. Case 5: Service Continuity Upon RRC Restart A UE already receiving a multicast session inactively (e.g., via a broadcast MRB) may be paged and initiate an RRC resume procedure. After transitioning to Connected, the UE would of course like to continue receiving the multicast session. However, in this case, the UE has both a broadcast MRB and a resumed multicast MRB for the same multicast session. In Rel-17, multicast sessions are only allowed to be received via a multicast MRB configured in RRC reconfiguration. In Rel-18, however, multicast sessions may be allowed to be received via a broadcast MRB configured on the MCCH. The UE should use the multicast MRB for reception after transitioning to Connected. However, it is unclear (i.e., in terms of the lossless principle) how the UE switches between these MRBs, when the UE discards the broadcast MRB, and what the UE should do if the multicast MRB is an AM MRB. Therefore, RAN2 needs to discuss UE behavior upon RRC resume in terms of MRB handling and service continuity for multicast sessions.

[0233] Proposal 10: RAN2 should discuss the UE behavior upon RRC resumption during continuous reception of a multicast session (e.g., handling of broadcast MRBs and multicast MRBs). [Explanation of symbols]

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

Claims

1. A communication method for use in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: The user equipment suspends the multicast MRB in response to receiving an RRC Release message from the network; The user equipment transitions from an RRC connected state to an RRC inactive state; The user equipment in the RRC inactive state establishes another multicast MRB; The user equipment transitions from the RRC inactive state to the RRC connected state in response to receiving an RRC recovery message from the network; The user equipment recovers the suspended multicast MRB in response to receiving the RRC recovery message; and the user equipment discarding the other multicast MRB in response to the transition to the RRC connected state. Communication method.

2. The user device establishes the other multicast MRB based on an MCCH from the network. The communication method according to claim 1 .

3. A user equipment for use in a mobile communication system providing a multicast / broadcast service (MBS), comprising: A control unit that suspends a multicast MRB and transitions from an RRC connected state to an RRC inactive state in response to receiving an RRC Release message from the network, The control unit Establishing another multicast MRB when the user equipment is in the RRC inactive state; transitioning from the RRC inactive state to the RRC connected state in response to receiving an RRC recovery message from the network; Restoring the suspended multicast MRB in response to receiving the RRC restoration message; Discarding the other multicast MRB in response to the transition to the RRC connected state. User equipment.

4. A method for causing a user device to execute the communication method described in claim 1. Processor.

5. A method for causing a user device to execute the communication method described in claim 1. program.

6. A user device according to claim 3 and a network node. Mobile communication system.

Images