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

Abstract

The present invention provides a device and method that enables a user device in an RRC inactive state to receive multicast sessions. [Solution] In a mobile communication system, the user device 100 in a radio resource control (RRC) connected state establishes a network with a base station gNB via a first multicast radio bearer (MRB), and then suspends the first MRB in response to the transition from the RRC connected state to the RRC inactive state; the user device in the RRC inactive state receives a multicast session from the network via a second MRB; and when the user device performs RRC connection recovery, transitioning from the RRC inactive state to the RRC connected state, it performs predetermined processing related to switching from receiving a multicast session via the second MRB to receiving a multicast session via the first MRB.

Description

Technical Field

[0001] The present disclosure relates to a communication method, a user device, a mobile communication system, a program, and a chipset.

Background Art

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

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

Prior Art Documents

Non-Patent Documents

[0004]

Non-Patent Document 1

Summary of the Invention

[0005] The first aspect of the communication method is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of: suspending the first multicast radio bearer (MRB) in response to a transition from the RRC connected state to the RRC inactive state after a user device in the radio resource control (RRC) connected state has established a first multicast radio bearer (MRB) with the network; receiving a multicast session from the network via a second MRB while the user device in the RRC inactive state is receiving a multicast session via a second MRB; and, when the user device performs RRC connection recovery, transitioning from the RRC inactive state to the RRC connected state, performing predetermined processing related to switching from receiving the multicast session via the second MRB to receiving the multicast session via the first MRB.

[0006] The user device according to the second embodiment is a user device used in a mobile communication system that provides multicast / broadcast services (MBS), and comprises a control unit that, in a radio resource control (RRC) connected state, establishes a first multicast radio bearer (MRB) with the network and then suspends the first MRB in response to a transition from the RRC connected state to an RRC inactive state, and a receiving unit that, in the RRC inactive state, receives multicast sessions from the network via a second MRB. When the control unit performs RRC connection recovery, which involves a transition from the RRC inactive state to the RRC connected state, it performs predetermined processing related to switching from receiving multicast sessions via the second MRB to receiving multicast sessions via the first MRB. [Brief explanation of the drawing]

[0007] [Figure 1] This diagram shows the configuration of a mobile communication system according to an embodiment. [Figure 2] This diagram shows the configuration of the UE (User Equipment) according to the embodiment. [Figure 3] This diagram shows the configuration of the gNB (base station) according to the embodiment. [Figure 4] This diagram shows the protocol stack configuration of the user plane wireless interface that handles data. [Figure 5] This diagram shows the protocol stack configuration of the wireless interface of the control plane that handles signaling (control signals). [Figure 6] This diagram shows an overview of the operation that enables UE100, which is in an RRC inactive state, to perform multicast reception. [Figure 7] This is a diagram showing the first operation scenario according to the embodiment. [Figure 8] This figure shows a second operation scenario according to the embodiment. [Figure 9] This diagram shows an overview of the operation according to the embodiment. [Figure 10] This is a diagram to explain the PDCP count value. [Figure 11] This figure shows an example of a first operation pattern according to the embodiment. [Figure 12] This figure shows an example of the configuration of a PDCP status report. [Figure 13] This figure shows an example of a second operation pattern according to the embodiment. [Figure 14] This figure shows another example of the second operation pattern according to the embodiment. [Figure 15] This figure shows an example of a third operation pattern according to the embodiment. [Figure 16] This figure shows an example of a fourth operation pattern according to the embodiment. [Figure 17] This figure shows an example of a fifth operation pattern according to the embodiment. [Figure 18] This diagram shows the PTM configuration distribution procedure for an activated multicast session. [Modes for carrying out the invention]

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

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

[0010] The mobile communication system 1 comprises User Equipment (UE) 100, a 5G radio access network (NG-RAN) 10, and a 5G core network (5GC) 20. Hereinafter, NG-RAN 10 may be simply referred to as RAN 10, and 5GC 20 may be simply referred to as the core network (CN) 20. RAN 10 and CN 20 constitute the network 5 of the mobile communication system 1.

[0011] UE100 is a mobile wireless communication device. UE100 can be any device used by a user. For example, UE100 can be a mobile phone terminal (including smartphones) and / or a tablet terminal, a notebook PC, a communication module (including a communication card or chipset), a sensor or device attached to a sensor, a vehicle or device attached to a vehicle (Vehicle UE), or an aircraft or device attached to an aircraft (Aerial UE).

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

[0013] Note that the gNB can also be connected to the EPC (Evolved Packet Core), which is the core network of LTE. The base station of LTE can also be connected to the 5GC. The base station of LTE and the gNB can also be connected via an interface between base stations.

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

[0015] Figure 2 is a diagram showing the configuration of the 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 the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 130.

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

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

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

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

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

[0022] The control unit 230 performs various control and processing operations in the gNB200. Such processing includes processing in each layer described later. The operation of the gNB200 described above and below may also be controlled by the control unit 230. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing operations.

[0023] The backhaul communication unit 240 is connected to an adjacent base station via the Xn interface, which is an inter-base station interface. The backhaul communication unit 240 is connected to the AMF / UPF300 via the NG interface, which is an inter-base station-core network interface. The gNB200 may consist of a CU (Central Unit) and a DU (Distributed Unit) (i.e., functionally separated), and the two units may be connected by the F1 interface, which is a fronthaul interface.

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

[0025] The user plane radio interface protocol consists of a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, and an SDAP (Service Data Adaptation Protocol) layer.

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

[0027] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat request (HARQ), and random access procedures. Data and control information are transmitted between the MAC layer of the UE100 and the MAC layer of the gNB200 via the transport channel. The MAC layer of the gNB200 includes a scheduler. The scheduler determines the transport format for the up and down links (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to the UE100.

[0028] The RLC layer transmits data to the receiving RLC layer using the functions of the MAC layer and PHY layer. Data and control information are transmitted between the UE100's RLC layer and the gNB200's RLC layer via a logical channel.

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

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

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

[0032] The control plane's wireless interface protocol stack includes an RRC (Radio Resource Control) layer and a NAS (Non-Access Stratum) layer, instead of the SDAP layer shown in Figure 4.

[0033] RRC signaling for various settings is transmitted between the RRC layer of the UE100 and the RRC layer of the gNB200. The RRC layer controls the logical channel, transport channel, and physical channel in response to the establishment, re-establishment, and release of the radio bearer. If there is a connection (RRC connection) between the RRC of the UE100 and the RRC of the gNB200, the UE100 is in the RRC connected state. If there is no connection (RRC connection) between the RRC of the UE100 and the RRC of the gNB200, the UE100 is in the RRC idle state. If the connection between the RRC of the UE100 and the RRC of the gNB200 is suspended, the UE100 is in the RRC inactive state.

[0034] The NAS layer (also simply referred to as "NAS"), located above the RRC layer, handles session management and mobility management, among other things. NAS signaling is transmitted between the UE100's NAS layer and the AMF300A's NAS layer. The UE100 also has application layers and other components in addition to its wireless interface protocol. Furthermore, the layer below the NAS layer is called the AS layer (also simply referred to as "AS").

[0035] (2) MBS Mobile communication system 1 can perform resource-efficient distribution through multicast / broadcast services (MBS). 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 multicast communication services (also referred to as "MBS multicast"), the same service and the same specific content data are provided simultaneously to a specific set of UEs. That is, not all UE100s within the multicast service area are permitted to receive the data. Multicast communication services are delivered to UE100s using multicast sessions, which are a type of MBS session. UE100s can receive multicast communication services in an RRC connected state using mechanisms such as PTP (Point-to-Point) and / or PTM (Point-to-Multipoint) delivery. UE100s may also receive multicast communication services in an RRC inactive (or RRC idle) state. This delivery mode is also referred to as "delivery mode 1". Note that UE100s can only receive multicast sessions after joining the multicast session. Here, joining a multicast session may mean registering with network 5 (CN20) as a UE100 capable of receiving the multicast session.

[0037] In the case of broadcast communication services (also known as "MBS broadcast"), the same service and the same specific content data are provided simultaneously to all UE100s within a geographical area. That is, all UE100s within the broadcast service area are permitted to receive the data. The broadcast communication service is delivered to the UE100s using a broadcast session, which is a type of MBS session. The UE100s can receive the broadcast communication service in any of the following states: RRC idle, RRC inactive, and RRC connected. This delivery mode is also known as "delivery mode 2".

[0038] The main logical channels used for MBS distribution are the Multicast Traffic Channel (MTCH), the Dedicated Traffic Channel (DTCH), and the Multicast Control Channel (MCCH). The MTCH is a PTM downlink channel for transmitting MBS data for either a multicast session or a broadcast session from network 10 to UE100. The DTCH is a PTP channel for transmitting MBS data for a multicast session from network 10 to UE100. The MCCH is a PTM downlink channel for transmitting MBS broadcast control information associated with one or more MTCHs from network 10 to UE100. In distribution mode 1, MBS settings for UE100 are configured using the Dedicated Control Channel (DCCH).

[0039] In MBS multicast, the transmission of MBS data packets (also called "MBS packets") can be either point-to-point (PTP) transmission, which is equivalent to unicast, or point-to-multipoint (PTM) transmission. In contrast, MBS broadcast can only use PTM transmission. In the case of PTP transmission, the gNB200 can independently distribute individual copies of the MBS packet to each UE100. For example, the gNB200 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 a UE-specific RNTI. On the other hand, in the case of PTM transmission, the gNB200 distributes a single copy of the MBS packet to a set (group) of multiple UE100s. For example, gNB200 uses a group-common PDCCH with a group-common RNTI (e.g., G-RNTI) that scrambles the CRC, to schedule a group-common PDSCH scrambled by a group-common RNTI.

[0040] Regarding the settings for MBS broadcasts, UE100 in the RRC idle, RRC inactive, or RRC connected state receives PTM settings for the broadcast session (e.g., parameters required for MTCH reception) via MCCH. The parameters required for MCCH reception (MCCH settings) are provided via system information. Specifically, system information block type 20 (SIB20) contains the MCCH settings. SIB type 21 (SIB21) contains information regarding the continuity of service for MBS broadcast reception. The MCCH provides a list of all broadcast services, including ongoing sessions transmitted via MTCH. The broadcast session information includes the MBS session identifier (e.g., TMGI (Temporary Mobile Group Identity)), relevant MTCH scheduling information, and information about neighboring cells providing specific services via MTCH.

[0041] On the other hand, with regard to MBS multicast, the current 3GPP technical specifications stipulate that the UE100 can only receive multicast session data when it is in the RRC Connected state. If a UE100 participating in a multicast session is in the RRC Connected state and the multicast session is activated, the gNB200 sends an RRC Reconfiguration message to the UE100 that includes the PTM settings for that multicast session. Such PTM settings are also referred to as multicast radio bearer (MRB) settings, MTCH settings, or PTM settings. The MRB setting (MRB-ToAddMod) includes the MBS session identifier (mbs-SessionId), the MRB identifier (mrb-Identity), and other parameters such as the PDCP setting (pdcp-Config) for the MRB (multicast MRB) to be configured on the UE100.

[0042] The following embodiment primarily describes an operation that enables a UE100 in an RRC inactive state to perform multicast reception. Figure 6 is a diagram illustrating an overview of this operation.

[0043] Two solutions are possible for a UE100 in an RRC inactive state to perform multicast reception: a distribution mode 1-based solution shown in Figure 6(a) and a distribution mode 2-based solution shown in Figure 6(b). It is assumed that the UE100 supports multicast reception in an RRC inactive state and is already participating in a multicast session.

[0044] In the distribution mode 1-based solution shown in Figure 6(a), in step S1, the gNB200 sends an RRC Reconfiguration message to the RRC-connected UE100, which includes the MBS settings (PTM settings) for the multicast session. Based on the PTM settings received in the RRC Reconfiguration message, the UE100 receives multicast data on the MTCH via the multicast session (multicast MRB).

[0045] In step S2, gNB200 sends an RRC Release message to UE100, which is in the RRC Connected state, to transition UE100 to the RRC Inactive state. This RRC Release message includes the settings for the RRC Inactive state (Suspend Config.).

[0046] In step S3, UE100 transitions from the RRC connected state to the RRC inactive state in response to receiving the RRC Release message in step S2.

[0047] In step S4, the UE100, which is in an RRC inactive state, continues to use the PTM settings from step S1 to receive multicast data on the MTCH via the multicast session.

[0048] This allows the UE100, which is in an RRC inactive state, to receive multicast traffic. While this example demonstrates using the RRC Reconfiguration message to configure PTM settings, you can also use the RRC Release message.

[0049] Both RRC Reconfiguration messages and RRC Release messages are RRC messages transmitted individually to each UE over the Dedicated Control Channel (DCCH), and are hereafter referred to as dedicated RRC messages or dedicated signaling.

[0050] On the other hand, in the delivery mode 2-based solution shown in Figure 6(b), in step S11, the gNB200 sends an RRC Release message to the UE100 in the RRC connected state to transition the UE100 to the RRC inactive state. This RRC Release message includes a setting for the RRC inactive state (Suspend Config.).

[0051] In step S12, UE100 transitions to the RRC inactive state in response to receiving the RRC Release message in step S11.

[0052] In step S13, gNB200 transmits an MCCH containing MBS settings (PTM settings) for the multicast session. UE100 receives the MCCH. Prior to receiving the MCCH, UE100 receives an SIB20 and receives the MCCH based on the SIB20. The transmission (and reception) of the MCCH may occur before step S11 or simultaneously with step S11.

[0053] In step S14, the UE100, which is in an RRC inactive state, receives multicast data on the MTCH via the multicast session based on the PTM settings received on the MCCH in step S13. This enables the UE100, which is in an RRC inactive state, to perform multicast reception.

[0054] A hybrid solution combining delivery mode 1-based and delivery mode 2-based solutions is also conceivable. For example, a hybrid configuration method is possible where the initial MBS (PTM) settings are set using dedicated signaling, and the MBS (PTM) settings are updated using MCCH.

[0055] (3) Operation according to the embodiment Figure 7 shows a first operation scenario according to this embodiment.

[0056] In the first operating scenario, firstly, UE100, which is in the RRC connected state in the gNB200 cell, establishes a multicast MRB with gNB200. UE100, in the RRC connected state, receives a multicast session from gNB200 via the multicast MRB.

[0057] Secondly, UE100 transitions from the RRC Connected state to the RRC Inactive state. At this point, UE100 suspends the multicast MRB (and PTM settings). Suspending the multicast MRB may also mean stopping (deactivating) the use of the multicast MRB while retaining the multicast MRB settings.

[0058] Furthermore, UE100 establishes a broadcast MRB for multicast with gNB200 before transitioning to the RRC inactive state, when transitioning to the RRC inactive state, or after transitioning to the RRC inactive state. In the RRC inactive state, UE100 receives multicast sessions from gNB200 via the broadcast MRB for multicast.

[0059] A UE100 in RRC connected or RRC inactive state may receive a PTM configuration from gNB200 on the MCCH and establish a broadcast MRB for multicast based on that PTM configuration. Alternatively, a UE100 in RRC connected state may receive a PTM configuration on the DCCH similar to the PTM configuration transmitted on the MCCH from gNB200 and establish a broadcast MRB for multicast based on that PTM configuration.

[0060] Furthermore, UE100 may establish a multicast MRB or a new type of MRB for multicast reception in an RRC inactive state, instead of the broadcast MRB for multicast. In the following, the MRB established by MCCH or equivalent information (MCCH content) will also be referred to as the "first MRB".

[0061] Thirdly, UE100 transitions from the RRC inactive state to the RRC connected state via the RRC connection recovery procedure. Here, UE100 resumes the suspended multicast MRB. In the RRC connected state, UE100 receives multicast sessions from gNB200 using the recovered multicast MRB (and recovered PTM settings). Hereafter, the multicast MRB recovered by the RRC connection recovery procedure will also be referred to as the "second MRB".

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

[0063] Normally, bearer type changes are performed by re-setting a different bearer type for the same MRB configuration using ToAddModList in the RRC Reconfiguration message; in other words, the MRB type is changed (modified). However, the first MRB established based on MCCH is not configured with ToAddModList, so there is a problem in that the MRB type cannot be changed.

[0064] Furthermore, the UE100 retains multicast MRB settings through RRC suspension, and if the multicast MRB is restored when the RRC connection is restored, it is necessary to clarify the relationship between the currently receiving first MRB and the restored second MRB.

[0065] Figure 8 shows a second operation scenario according to this embodiment.

[0066] In the second operating scenario, firstly, UE100, which is in an RRC inactive state in the gNB200 cell, establishes a broadcast MRB (first MRB) for multicast with gNB200. The first MRB may be a new type of MRB. UE100, in the RRC inactive state, begins receiving multicast sessions via the first MRB.

[0067] Secondly, UE100 transitions from the RRC inactive state to the RRC connected state through the RRC connection recovery procedure. Here, UE100 establishes a second MRB (multicast MRB) based on the PTM settings in the RRC Reconfiguration message received from gNB200, for example. In the RRC connected state, UE100 receives multicast sessions from gNB200 using the established second MRB.

[0068] Thus, in the second operating scenario, before UE100 transitions to the RRC inactive state, i.e., while in the RRC connected state, the multicast MRB is not configured and the multicast session has not yet started. Subsequently, while UE100 is in the RRC inactive state, the multicast session is started and the first MRB is established based on MCCH. Then, when UE100 transitions from the RRC inactive state to the RRC connected state, a new second MRB is established.

[0069] Here, UE100 uses the first MRB, established based on MCCH, for multicast reception while RRC is inactive. Therefore, it is necessary to switch multicast reception for the same multicast session from the first MRB to the second MRB.

[0070] Normally, bearer type changes are performed by re-assigning a different bearer type to the same MRB configuration using the ToAddModList in the RRC Reconfiguration message; in other words, the MRB type is modified. However, there is a problem in that the first MRB established based on MCCH cannot have its MRB type changed because it was not configured with ToAddModList. Furthermore, it is necessary to clarify the relationship between the currently received first MRB and the established second MRB.

[0071] Figure 9 is a diagram illustrating the overview of the operation according to this embodiment.

[0072] In step S51, the UE100, which is in an RRC inactive state, receives a multicast session from 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 predetermined processing to switch from receiving multicast sessions via the first MRB to receiving multicast sessions via a second MRB, which is different from the first MRB.

[0074] The first to fifth operation patterns according to the embodiment will be described below. The content of the predetermined processing differs in the first to fifth operation patterns. The first to fifth operation patterns assume the first operation scenario described above. That is, the second MRB is the MRB that was suspended when UE100 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 the process of establishing the second MRB. In the following description of embodiments, "recovery" of the second MRB may be read as "establishment".

[0076] (3.1) First operation pattern In the first operating pattern, network 5 (gNB200) is assumed to be transmitting the same multicast session using the same resource (e.g., the same PDSCH) for both multicast MRB (second MRB) and broadcast MRB (first MRB) from a lower layer (e.g., physical layer) perspective. Therefore, UE100 will receive the same MTCH, and the PDCP count value, which is a variable used in the PDCP layer (PDCP variable), will also be the same regardless of whether it is multicast MRB or broadcast MRB.

[0077] As shown in Figure 10, the PDCP count value is a variable consisting of a hyperframe number (HFN), which is incremented each time the PDCP sequence number completes a cycle, and a PDCP sequence number (PDCP SN). Network 5 (gNB200) and UE100 each manage the PDCP count value and update it 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 of 12 bits or 18 bits (SN_length), 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 consist of only either the HFN or the SN.

[0078] Under the current 3GPP technical specifications, the initial value of the multicast MRB's PDCP count is set from gNB200 to UE100 in the RRC Reconfiguration message. Therefore, UE100 may not be able to recover the multicast MRB (second MRB) if it does not receive the RRC Reconfiguration message. The first operating pattern describes the actions taken to facilitate the recovery of the multicast MRB (second MRB).

[0079] In the first operating pattern, the UE100, in an RRC inactive state, updates the PDCP variable (e.g., PDCP count value) of the first MRB (e.g., broadcast MRB) in response to receiving a multicast session packet via the first MRB. The predetermined process includes determining the PDCP variable (e.g., initial value of the PDCP count value) of the second MRB (multicast MRB) based on the PDCP variable of the first MRB. For example, when the multicast MRB is restored, the UE100 takes over the PDCP count value of the broadcast MRB. This facilitates the restoration of the multicast MRB (second MRB).

[0080] In the first operation pattern, UE100 may receive information from network 5 specifying that it should perform a process to determine the PDCP variables of the second MRB (multicast MRB) (e.g., the initial value of the PDCP count) based on the PDCP variables of the first MRB, either when transitioning to the RRC inactive state or before such transition. In other words, network 5 (gNB200) may instruct UE100 whether or not to inherit the PDCP count value. This allows network 5 to control the behavior of UE100 when the RRC connection is restored.

[0081] Figure 11 shows an example of a first operation pattern according to the embodiment.

[0082] In step S101, the UE100, which is in the RRC connected state, has already joined a multicast session (hereinafter also referred to as the "specific multicast session").

[0083] In step S102, gNB200 sends a message to UE100 on DCCH containing the PTM settings for a specific multicast session to UE100, which is in the RRC connected state. This message may be an RRC Reconfiguration message or an RRC Release message. This message may also include an instruction on whether or not to take over the PDCP count value from the broadcast MRB when the multicast MRB is restored. In step S103, UE100 establishes a multicast MRB with gNB200 based on the PTM settings in step S102. UE100 may use the established multicast MRB to start receiving a specific multicast session on MTCH.

[0084] In step S104, gNB200 sends a message to UE100 on DCCH containing PTM settings similar to those sent on MCCH to UE100 in the RRC connected state. This message may be an RRC Reconfiguration message or an RRC Release message. This message may also include an instruction on whether or not to take over the PDCP count value from the broadcast MRB when the multicast MRB is restored. In step S105, UE100 establishes a broadcast MRB with gNB200 based on the PTM settings in step S104 and associates the broadcast MRB with the multicast MRB. UE100 may use the established broadcast MRB to start receiving a specific multicast session on MTCH. Steps S104 and S105 are optional operations. If the operations in steps S108 and S109 described below are performed, steps S104 and S105 can be omitted.

[0085] In step S106, gNB200 sends an RRC Release message to UE100, causing UE100 to transition to the RRC inactive state. Upon receiving the RRC Release message, UE100 transitions from the RRC connected state to the RRC inactive state. If the RRC Release message is used in steps S102 and / or S104, UE100 may also transition to the RRC inactive state in steps S102 and / or S104. In step S107, UE100 suspends the multicast MRB.

[0086] In step S108, gNB200 may transmit the PTM settings for a specific multicast session on the MCCH. In step S109, UE100 establishes a broadcast MRB with gNB200 based on the PTM settings in step S108, and associates the broadcast MRB with the multicast MRB. UE100 may then use the established broadcast MRB to begin receiving the specific multicast session on the MTCH. Note that if optional operations are performed in steps S104 and S105, steps S108 and S109 can be omitted.

[0087] In step S110, the UE100, in the RRC inactive state, receives a specific multicast session via the broadcast MRB. In step S111, the UE100, in the RRC inactive state, updates the PDCP count value (specifically, increments it) in response to the reception of the multicast session (specifically, the reception of PDCP packets).

[0088] Subsequently, in step S112, UE100, which receives a multicast session in an RRC inactive state, triggers the recovery of the RRC connection. For example, UE100 may trigger the recovery of the RRC connection by the occurrence of a RAN paging message or an MO (Mobile Originated) call.

[0089] In step S113, UE100 performs an RRC connection recovery procedure with gNB200. The RRC connection recovery procedure includes sending an RRC recovery request message from UE100 to gNB200 and sending an RRC recovery message from gNB200 to UE100. In step S114, UE100 transitions from the RRC inactive state to the RRC connected state.

[0090] In step S115, UE100 restores the multicast MRB upon restoration of the RRC connection. Here, UE100 transfers the current PDCP count value of the broadcast MRB to the multicast MRB. That is, UE100 sets the initial value of the multicast MRB's PDCP variable based on the current PDCP count value.

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

[0092] (3.2) Second operation pattern In the second operating pattern, UE100 in an RRC inactive state updates the PDCP variable (e.g., PDCP count value) of the first MRB (e.g., broadcast MRB) in response to receiving packets for a specific multicast session via the first MRB. The predetermined process includes sending a notification to network 5 (gNB200) based on the PDCP count value of the first MRB. This allows network 5 (gNB200) to understand the status of the PDCP variable of UE100 in an RRC inactive state and, for example, send unreceived PDCP packets from UE100 regarding the first MRB to UE100 via the second MRB. Alternatively, network 5 (gNB200) may send a switching setting or switching instruction to UE100 from broadcast MRB to multicast MRB based on the understood status of the PDCP variable.

[0093] In the second operating pattern, the second MRB (multicast MRB) may be an AM (Acknowledged Mode) MRB. UE100 may send a PDCP status report as notification to network 5 (gNB200). Figure 12 shows an example of the configuration of a PDCP status report. The PDCP status report has as its main components 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 SDU and the PDCP SDU that was correctly received by the receiving PDCP entity. Specifically, the "Bitmap" field indicates the reception status of PDCP SDUs after the FMC as "0" (missing) or "1" (correctly received).

[0094] In the second operating pattern, UE100 may send a notification to network 5 (gNB200) that includes the latest PDCP count value of the first MRB (multicast MRB).

[0095] (3.2.1) An example of the second operation pattern In an example of the second operation pattern according to the embodiment, when the AM MRB is restored, the UE100 sends a PDCP status report to the gNB200.

[0096] Figure 13 shows an example of a second operation pattern according to the embodiment.

[0097] The operation in steps S201 to S214 is the same as the operation in steps S101 to S114 in Figure 11. However, in this example, the multicast MRB is AM MRB. In steps S202, S204, or S208, gNB200 may pre-configure UE100 whether or not to send a PDCP status report when AM MRB is restored.

[0098] In step S216, the UE100 in RRC connected state sends a PDCP status report to the gNB200. The UE100 may identify the SN of unreceived packets (or the SN of the most recently received packet) based on the PDCP count value of the broadcast MRB used to receive a particular multicast session, and send the PDCP status report from the multicast MRB (or its PTP leg) to the gNB200. The gNB200 receives the PDCP status report.

[0099] In step S217, gNB200 uses the recovered multicast MRB's PTP leg (or PTM leg) to retransmit unreceived packets to UE100.

[0100] (3.2.2) Other examples of the second action pattern In another example of the second operation pattern according to the embodiment, when the multicast MRB (second MRB) is restored, the UE100 notifies the gNB200 of the (latest) PDCP count value received by the broadcast MRB (first MRB).

[0101] In this example, the PDCP count values ​​may differ between multicast MRB and broadcast MRB. By having UE100 communicate to gNB200 information about which packets were successfully received via broadcast MRB (i.e., which packet gNB200 will use as the initial packet for multicast MRB), MRB switching can be streamlined.

[0102] Figure 14 shows another example of the second operation pattern according to the embodiment.

[0103] The operation in steps S251 to S264 is the same as the operation in steps S101 to S114 in Figure 11. However, in this example, the PDCP count values ​​of the broadcast MRB (first MRB) and the multicast MRB (second MRB) do not need to be synchronized. For example, the gNB200 may transmit the broadcast MRB (first MRB) and the multicast MRB (second MRB) using physically separate MTCHs (PDSCHs).

[0104] In step S265, if the UE100 restores the RRC connection, it restores multicast MRB for the specific multicast session that is currently receiving.

[0105] In step S266, UE100 notifies gNB200 of the (last / latest) PDCP count value (sequence value) that was successfully received via broadcast MRB. This notification may be made in a PDCP status report, which is a type of PDCP control PDU. This notification may also be made in a UE Assistance Information message, which is a type of RRC message. The notified PDCP count value corresponds to broadcast MRB (i.e., a different bearer), not multicast MRB. gNB200 receives this notification. Taking this notification into consideration, gNB200 identifies the initial packet of data transmitted via multicast MRB.

[0106] In step S267, gNB200 sends a multicast session over the MTCH via multicast MRB to UE100, which is in the RRC connected state. UE100 receives the multicast session.

[0107] (3.3) Third Operation Pattern If UE100, which is receiving a specific multicast session while RRC is inactive, transitions to the RRC connected state, a multicast MRB may be configured for that specific multicast session via an RRC Reconfiguration message. In this case, there is a problem in that it is not clear when the UE100's receiving operation switches from broadcast MRB (first MRB) to 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 UE100 stops receiving the broadcast MRB that is receiving that specific multicast session. Here, stopping broadcast MRB reception may also mean stopping MTCH reception and / or MCCH reception.

[0109] Figure 15 shows an example of a third operation pattern according to this embodiment.

[0110] The operation of steps S301 to S314 is the same as the operation of steps S101 to S114 in Figure 11.

[0111] In step S315, if the UE100 restores the RRC connection, it restores the multicast MRB for a specific multicast session that is being received by the broadcast MRB (first MRB).

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

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

[0114] (3.4) Fourth Operation Pattern If the PDCP count values ​​for the broadcast MRB (first MRB) and the multicast MRB (second MRB) are not synchronized, for example, if they are transmitted from physically different MTCHs (PDSCHs), the PDCP count value of the multicast MRB will appear undefined to the UE100 when the RRC connection is restored.

[0115] The 3GPP Release 17 technical specification introduces a mechanism in which the initial values ​​of the variables (HFN and SN) of PDCP entities associated with multicast MRBs are explicitly notified from the gNB200 to the UE100 via an RRC Reconfiguration message. In the third operating pattern, the UE100 switches its reception from broadcast MRB (first MRB) to multicast MRB (second MRB) upon receiving notification of the initial values ​​of the PDCP variables from the gNB200 to the UE100.

[0116] In the third operation pattern, the predetermined processing includes starting multicast reception via the second MRB and / or stopping multicast reception via the first MRB when initial value information indicating the initial value of the PDCP variable used in the second MRB is notified to the UE100 from network 5 (gNB200). That is, when the multicast MRB is restored and the initial value of the PDCP variable is notified from gNB200, the UE100 starts reception via the multicast MRB and / or stops reception via the broadcast MRB.

[0117] Figure 16 shows an example of a fourth operation pattern according to the embodiment.

[0118] The operation of steps S401 to S414 is the same as the operation of steps S101 to S114 in Figure 11.

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

[0120] In step S416, gNB200 sends the initial values ​​of the PDCP variables (PDCP count value, HFN, and / or PDCP SN) for the recovered multicast MRB to UE100 on the DCCH (for example, in an RRC Reconfiguration message). gNB200 may further notify UE100 of the MRB to which these initial PDCP variable values ​​apply, for example, the MRB ID, and / or information indicating that they apply to a multicast MRB.

[0121] In step S417, the UE100 in the RRC connected state sets the initial value. The UE100 may stop (and discard) multicast reception via broadcast MRB.

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

[0123] In step S416, gNB200 may also notify the 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 sent from gNB200 to UE100 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 reduces the number of bits in the initial value information compared to notifying the initial value of the PDCP variable used in the second MRB as is. In this case, in step S417, UE100 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 Operation Pattern In the fifth operation pattern, the predetermined process includes receiving a switching instruction from network 5 that instructs a switch from the first MRB (broadcast MRB) to the second MRB (multicast MRB). In other words, gNB200 explicitly instructs UE100 to switch from broadcast MRB to multicast MRB.

[0125] Figure 17 shows an example of a fifth operation pattern according to this embodiment.

[0126] The operation of steps S501 to S514 is the same as the operation of steps S101 to S114 in Figure 11.

[0127] In step S515, if the UE100 restores the RRC connection, it restores multicast MRB for specific multicast sessions that are being received by broadcast MRB.

[0128] In step S516, the gNB200 sends an instruction to the UE100 on the DCCH (for example, in an RRC Reconfiguration message) to switch the MRB used to receive a particular multicast session (switch to a multicast MRB). This instruction may include the MBS session ID of the particular multicast session and / or the MRB ID of the multicast MRB.

[0129] Here, the gNB200 might want to continue receiving via broadcast MRB, for example, if PTM transmission for multicast MRB is not yet ready (i.e., only PTP transmission is being performed). In such a case, the gNB200 will instruct the system to switch to receiving via multicast MRB when multicast MRB PTM transmission begins.

[0130] In step S517, the UE100 in the RRC connected state changes the receive path for a specific multicast session to a multicast MRB in accordance with the instructions in step S516. At this point, the UE100 may stop receiving broadcast MRBs (and discard broadcast MRBs).

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

[0132] (4) Other embodiments The above embodiments mainly described multicast reception in an RRC inactive state, but the operation according to the above embodiments may also be applied to multicast reception in an RRC idle state. In the case of an RRC idle state, the above-described RRC Resume is read as RRC Establishment. For example, in 3GPP Release 19 and later, when a UE100 in an RRC idle state becomes able to receive a multicast session, a multicast MRB is established after the RRC connection (configured by the RRC Reconfiguration message).

[0133] Each of the above-described operation flows can be performed not only independently, but also in combination of two or more operation flows. For example, some steps of one operation flow may be added to another operation flow, or some steps of one operation flow may be replaced with some steps of another operation flow. It is not necessary to execute all steps in each flow; only some steps may be executed.

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

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

[0136] A program may be provided that causes a computer to execute each process performed by the UE100 or gNB200. The program may be recorded on a computer-readable medium. Using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, but may be a recording medium such as a CD-ROM or DVD-ROM. Alternatively, the circuits that execute each process performed by the UE100 or gNB200 may be integrated, and at least a part of the UE100 or gNB200 may be configured as a semiconductor integrated circuit (chipset, SoC: System on a chip).

[0137] The functions realized by UE100 or gNB200 (network node) may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (a Central Processing Unit), conventional circuits, and / or combinations thereof, programmed to realize the described functions. A processor, including transistors and other circuits, is considered circuitry or processing circuitry. A processor may be a programmed processor that executes a program stored in memory. In this specification, circuitry, unit, and means are hardware programmed to realize or perform the described functions. Such hardware may be any hardware disclosed herein, or any hardware known to be programmed to realize or perform the described functions. If such hardware is a processor that is considered to be a type of circuitry, then such circuitry, means, or unit is a combination of hardware and software used to constitute such hardware and / or processor.

[0138] The phrases “based on” and “depending on / in response to” used in this disclosure do not mean “based solely on” or “depending solely on” unless otherwise specified. “Based on” means both “based solely on” and “at least partially on.” Similarly, “depending on” means both “at least partially on” and “at least partially on.” The terms “include,” “comprise,” and variations thereof do not mean that only the listed items are included; they mean that only the listed items may be included, or that additional items may be included in addition to the listed items. Furthermore, the term “or” used in this disclosure is not intended to mean exclusive OR. Additionally, any reference to elements using designations such as “first,” “second,” etc., used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used herein as a convenient way to distinguish between two or more elements. Therefore, references to the first and second elements do not imply that only two elements may be adopted therein, or that the first element must precede the second element in any way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall be plural unless it is clearly indicated by the context that they are not.

[0139] Although the embodiments have been described in detail above with reference to the drawings, the specific configuration is not limited to those described above, and various design changes can be made without departing from the gist of the invention.

[0140] This application claims priority to U.S. Provisional Application No. 63 / 443085 (filed February 3, 2023), the entirety of which is incorporated into the specification of this application.

[0141] (5) Note

[0142] (Note 1) A communication method used in a mobile communication system that provides multicast / broadcast services (MBS), The steps include: a user device in a Radio Resource Control (RRC) inactive state receiving a multicast session from the network via a first multicast radio bearer (MRB); When the user device performs RRC connection recovery, transitioning from the RRC inactive state to the RRC connected state, it includes the step of performing predetermined processing 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] (Note 2) The second MRB is an MRB that is suspended when the user device transitions to the RRC inactive state. The step of performing the predetermined processing includes the step of restoring the suspended second MRB. The communication method described in Appendix 1.

[0144] (Note 3) The user device in the RRC inactive state further has the step of updating the PDCP variable of the first MRB in response to receiving a packet of the multicast session via the first MRB. The step of performing the predetermined processing includes the step of performing a process to determine the PDCP variable of the second MRB based on the PDCP variable of the first MRB. The communication method described in Appendix 1 or 2.

[0145] (Note 4) The user device further includes the step of receiving information from the network specifying that it should perform the determination process when transitioning to the RRC inactive state or before such transition. The communication method described in Appendix 3.

[0146] (Note 5) The user device in the RRC inactive state further has the step of updating the PDCP variable of the first MRB in response to receiving a packet of the multicast session via the first MRB. The step of performing the predetermined processing includes the step of sending a notification to the network based on the PDCP count value of the first MRB. The communication method described in any of the appendices 1 to 4.

[0147] (Note 6) The aforementioned 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. The communication method described in Appendix 5.

[0148] (Note 7) The step of sending the notification includes sending the notification, which includes the latest PDCP count value of the first MRB, to the network. The communication method described in Appendix 5 or 6.

[0149] (Note 8) The step of performing the predetermined processing includes stopping multicast reception via the first MRB when the second MRB is restored or established. The communication method described in any of the appendices 1 through 7.

[0150] (Note 9) The step of performing the predetermined processing includes the step of starting multicast reception via the second MRB and / or stopping multicast reception via the first MRB when initial value information indicating the initial value of the PDCP variable used in the second MRB is notified to the user device from the network. The communication method described in any of the appendices 1 through 8.

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

[0152] (Note 11) The step of performing the predetermined processing includes receiving a switching instruction from the network that instructs switching from the first MRB to the second MRB. The communication method described in any of the appendices 1 to 10.

[0153] (Note 12) User equipment used in a mobile communication system that provides multicast / broadcast services (MBS), In a Radio Resource Control (RRC) inactive state, the receiving unit receives a multicast session from the network via the first multicast radio bearer (MRB), When performing RRC connection recovery, which transitions from the RRC inactive state to the RRC connected state, the system includes a control unit that performs predetermined processing 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. User device.

[0154] (6) Addendum 1. Introduction The work items related to enhancing MBS (eMBS) aim to support multicast reception by the UE when inactive, as follows: [RAN2, RAN3] specifies support for multicast reception by the UE when the RRC is inactive. PTM settings for a UE receiving multicast in RRC inactive state [RAN2] Investigation of the impact of mobility and state transitions on UEs receiving multicast in RRC inactive (seamless / lossless mobility is not required) [RAN2, RAN3]

[0155] RAN2 has discussed this objective and reached a series of agreements. Based on these agreements, the PTM settings and mobility configurations for multicast reception in inactive mode will be discussed in this appendix.

[0156] 2. Discussion 2.1. PTM Configuration Distribution Rel-17 defines two distribution modes: a mode called "Distribution Mode 1" for multicast sessions and a mode called "Distribution Mode 2" for broadcast sessions. In Distribution Mode 1, MTCH reception is configured only for connected UEs by RRC reconfiguration, while in Distribution Mode 2, MTCH reception is configured via MCCH for all RRC-state UEs.

[0157] RAN2#119e defines these distribution modes, namely Option 1, Option 2, and a "mix" of these options, as candidates for multicast reception in an inactive state.

[0158] Regarding the distribution of PTM settings, RAN2 is also considering the following solutions. Option 1: Dedicated signaling Option 2: Solution based on SIB+MCCH This does not exclude the option of "mixing".

[0159] RAN2#120 has reached an agreement to move forward with a "mixed approach". We have a mixed approach and begin as follows: 1. If the network configures a UE to continue receiving multicast while in an inactive state, the network will provide PTM configuration for the activated multicast session via RRC-dedicated signaling, at least for the serving cell (further consideration is needed for other cases). 2. MCCH is used when the PTM settings need to be changed or when the PTM settings need to be indicated during a transition beyond the serving cell / gNB. Further consideration is needed regarding session state changes and other instructions. 3. Assume that the UE can receive multicast services after joining the session. 4. Further consideration is needed regarding whether MCCH settings are initially provided to the UE via dedicated signaling.

[0160] In accordance with Agreement #1 above, the network configures the PTM setting for the activated multicast session on the UE via dedicated signaling. Since the multicast session is activated, the connected UE is already receiving the multicast session, and this PTM setting is assumed to allow it to continue receiving the multicast session even after the UE transitions to inactive.

[0161] In this disclosure, the "mixed approach" agreed upon by RAN2 means using MCCH for updating PTM settings, etc., and is therefore similar to Rel-17's delivery mode 2. In this sense, dedicated signaling will only provide MCCH content (such as MBS Broadcast Configuration) and not Rel-17-specific multicast settings (such as mrb-ToAddModList). Such dedicated signaling is useful in avoiding the UE monitoring MCCH in Connected mode and minimizing service interruptions due to delays in MCCH acquisition after transitioning to inactive mode.

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

[0163] On the other hand, RAN2 has agreed that an inactive UE can start receiving multicast sessions, i.e., scenario 2 of the agreement below, so it is unclear what can be configured for an inactive 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 mode, and continues to receive multicast. -Scenario 2: The UE joins a multicast session, is redirected to inactive, and then begins receiving the multicast session. Further consideration is needed regarding state changes, such as state changes caused by services not being provided in an inactive state.

[0165] It is believed that the actual PTM configuration cannot be provided to an inactive multicast session, but once the multicast session is activated, it is provided. In Rel-17, an inactive UE transitions to connected when it receives group paging for the activation of a multicast session. Therefore, some kind of instruction may be provided in advance via dedicated signaling so that the UE can use the PTM configuration obtained from the MCCH for the multicast session while remaining inactive. Another approach is that such instruction is provided by group paging, as discussed in the following section.

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

[0167] Agreement #2 above states that MCCH is used when the PTM settings need to be changed or when the PTM settings need to be displayed during a transition beyond a serving cell / gNB. The use of MCCH for session status changes and other instructions is somewhat ambiguous. That is, it's unclear whether MCCH is used for instructions or for providing PTM settings. If it's just instructions, it could mean MCCH Change Notification. However, MCCH does provide PTM settings, for example, updating the PTM settings configuration of an inactive UE.

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

[0169] RAN2 leaves as a matter to consider whether the MCCH configuration is initially provided to the UE via dedicated signaling. The MCCH configuration refers to SIB20. As agreed by RAN2, since dedicated signaling is inactive and provides the PTM configuration for multicast reception, the UE does not need to read the MCCH immediately, and therefore does not need to know what SIB20, i.e., the MCCH configuration, is. Naturally, the UE will later retrieve the SIB20 and MCCH and check whether the PTM configuration has been updated.

[0170] Proposal 4: RAN2 should agree that the 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 would be used during UE transitions. This disclosure has a mixed approach and begins as follows: 1. If the network configures the UE to continue receiving multicast in an inactive state, the network provides PTM settings for the activated multicast session via RRC-dedicated signaling to at least the serving cell (other cases require further consideration). 2. MCCH is used when PTM settings need to be changed or when PTM settings need to be instructed during transitions beyond the serving cell / gNB. Further consideration is needed regarding session state changes and other instructions. 3. Assume that the UE can receive multicast services after joining the session. 4. Further consideration is needed regarding whether MCCH settings are initially provided to the UE via dedicated signaling.

[0172] WID states that seamless / lossless mobility is not necessary. [RAN2, RAN3] specifies support for multicast reception by the UE when the RRC is inactive. PTM settings for a UE receiving multicast in RRC inactive state [RAN2] Investigate the impact of UE mobility and state transitions on multicast receiving in RRC inactive (seamless / lossless mobility is not required) [RAN2, RAN3]

[0173] As described in Section 2.1, the distribution method for the new PTM configuration is similar to distribution mode 2 of Rel-17. Therefore, it is natural to base it on the Rel-17 MBS broadcast continuity mechanism. In this case, the multicast session must first be provided with neighbor cell information from the MCCH and ensure that the UE is allowed to prioritize the MBS frequency when reselecting a cell.

[0174] As is expected with LTE SC-PTM and NR MBS broadcast, how service continuity is ensured depends on the UE implementation. For example, how adjacent cell information is used, whether MBS frequencies are prioritized, and how / when MCCH is obtained from adjacent cells are all at the discretion of the UE implementation.

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

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

[0177] Some companies propose enabling PTM settings across multiple cells to improve service continuity during UE transitions. Within a gNB, it's easy to synchronize PTM settings for each cell (if necessary), but this is more difficult between gNBs and requires negotiation involving Xn-AP. This small enhancement is unlikely to cause any harm even if it's limited to within a gNB. Therefore, RAN2 needs to discuss whether PTM settings can be applied to multiple cells within a gNB.

[0178] Proposal 7: RAN2 should consider whether the PTM configuration is applicable to multiple cells within a gNB. In this case, the gNB scenario would be the basic assumption.

[0179] Another consideration is network-based QoS control. While WID does not require seamless / lossless mobility, this does not mean that all multicast sessions that a UE can receive while inactive do not require seamless / lossless mobility. For example, congestion may necessitate the network transitioning the UE to inactive, but QoS requirements may necessitate the UE transitioning after being connected. For seamless / lossless mobility, Rel-17MBS multicast supports handover in RRC connections. Therefore, the network may need an option to control whether to have the UE perform cell reselection or to resume the RRC connection before cell reselection (in the case of connected handover).

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

[0181] (7) Note 1. Introduction The work items related to strengthening MBS (eMBS) are as follows: Identify support for multicast reception by UE in RRC inactive state [RAN2, RAN3] PTM configuration for UE receiving multicast in RRC inactive state [RAN2] This study investigates the impact of mobility and state transitions on UEs receiving multicast in RRC inactive states (seamless / lossless mobility is not required) [RAN2, RAN3].

[0182] Based on these agreements, the notification and RRC state transition behaviors in multicast reception in an inactive state are discussed in this appendix.

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

[0184] From a network and UE perspective, several cases related to RRC state changes are possible. Some of these cases also relate to notifications sent from the network to the UE. Therefore, the following cases should be considered:

[0185] 2.1. Case 1: Inactive / Released Multicast Session When a multicast session is inactive, the agreed-upon RAN2#119bis-e is notified to the UE, and the Rel-17 mechanism can be applied when the multicast session is released. If a UE is in RRC inactive and configured to receive multicast sessions in RRC inactive, the UE may be notified when the multicast session is deactivated. Further consideration is needed regarding notification via, for example, group paging, MCCH, or other methods. The Rel-17 mechanism (NAS-based instruction) is applicable for multicast session release. Further consideration will be given as needed.

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

[0187] Finding 1: It is inefficient from a power consumption standpoint for the UE to continue monitoring PTM / MTCH after a multicast session has been stopped or released.

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

[0189] Proposal 1: RAN2 should agree that when it receives a multicast session termination notice, the UE should be allowed to stop monitoring the MTCH.

[0190] Regarding the termination of multicast sessions, RAN2 states that further consideration is needed for methods of notifying the UE, such as group paging, MCCH, or other methods.

[0191] In LTE SC-PTM, the SC-PTM Stop Indication MAC CE is introduced to notify the UE that it is stopping monitoring the PDCCH of a G-RNTI, and the MAC CE is multiplexed to the SC-MTCH associated with the G-RNTI. This lightweight signaling may work under the constraint of a one-to-one mapping between TMGI and G-RNTI. On the other hand, NR MBS allows a many-to-one mapping between TMGI and G-RNTI, so if the MAC CE is introduced, it will need to indicate an inactive TMGI. Since the MAC CE is transmitted 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. Group paging is used to page multiple UEs within a group simultaneously, using TMGI instead of UE-ID. Since the existing paging group list (i.e., the list of TMGIs) can also be applied to legacy UEs, group paging requires adding a new TMGI list for deactivation notifications to avoid impacting legacy UEs. This means there will be a delay between the last multicast data reception and the cessation of MTCH monitoring, based on the I-DRX cycle.

[0193] A third option is to reuse the MCCH. There are two possible ways to notify of multicast session inactivation: either remove the PTM setting for the inactivated TMGI, or add a new indicator to notify of the inactivated TMGI. In either case, the MCCH needs to be updated, so an MCCH change notification must be sent to the UE in advance. This requires a longer delay between receiving the last multicast data and stopping the MCCH monitor.

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

[0195] In summary, the delay between receiving the last multicast data and stopping the MTCH monitor can directly impact the unnecessary increase in UE power consumption. From a UE power saving perspective, notifications need to be sent as quickly as possible, making MAC CE the preferred first choice and solution.

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

[0197] For multicast session release, the Rel-17 NAS-based representation agreed upon by RAN2 applies, which may be "release of multicast session 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 the AMF. This procedure assumes that existing group paging (or traditional individual paging) can be reused.

[0198] However, if a new MAC CE is introduced for multicast session invalidation notifications as in Proposal 2 for optimization purposes, this procedure can be used free of charge. That is, the gNB sends a MAC CE to allow the UE to stop monitoring the MTCH, and then the gNB can distribute the page timing to the UE, i.e., use legacy individual paging, to avoid the signaling storm caused by simultaneously transitioning to the RRC state.

[0199] Proposal 3: RAN2 should agree that no functional enhancements specifically for multicast session release are necessary; in other words, UEs should transition to RRC Connected via existing (group) paging.

[0200] 2.2. Case 2: Selective transitions when a multicast session is active RAN2#119e reached the following agreement regarding Case 2: The gNB is responsible for determining whether a multicast session can be received in an inactive state by the UE. Further consideration is needed regarding what information should be provided to the gNB to make such a decision (related to the SA2 discussion). gNB supports sending a single multicast session to both connected and inactive UEs within the same cell. Further investigation is needed to determine how gNB configures this. The network assumes that UEs can choose which UEs receive in RRC inactive and which receive in RRC connected, and that UEs can transition between states to receive multicast services.

[0201] When releasing a UE inactively, gNB can select which UE to release based on the UE's capabilities, UE assistance information, and / or CN assistance information (if specified), as it does now, i.e., via RRC Release with Suspend Config. Therefore, no enhancements regarding selective UE transitions are anticipated for RRC release messages.

[0202] Finding 2: Existing RRC releases are used by gNB to select which UE to release.

[0203] Regarding the activation of multicast sessions, RAN2#119bis-e agreed on the following: When a Rel-18 session becomes active, it can notify inactive UEs (further investigation is needed for details). As a baseline, group paging can be used to notify the Rel-18 UE of session activation (further investigation is needed regarding details, such as how the UE behaves when it receives such a group notification). When a session is activated, the method for determining whether the UE can trust a multicast session with RRC inactive will be decided after further consideration, taking into account the following solutions (the description may be further updated as needed, 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 for the session in RRC Inactive is available to the UE and the UE is already participating in the session (e.g., configuration provided to the UE via dedicated RRC signaling or MCCH), but otherwise it will return to RRC Connected to receive the multicast session. 2. When a multicast session becomes active, the UE will be indicated by group paging whether it can receive the multicast session with RRC inactive (further consideration is needed regarding detailed signaling). 3. Before the UE is released, it is configured via dedicated signaling to determine whether it can receive multicast sessions while RRC is inactive. When a multicast session becomes active, the UE either remains RRC inactive or reactivates RRC Connected accordingly (further consideration is needed regarding the detailed signaling).

[0204] In Rel-17, multicast session activation is notified by group paging. In Rel-18, there is no need to differ from the legacy mechanism, so RAN2 needs to use group paging to ensure that multicast session activation is notified to the UE.

[0205] Proposal 4: RAN2 should be able to use group paging to notify the Rel-18 UE of session activation.

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

[0207] In Option 1, a UE can receive multicast sessions even in an inactive state if it has a valid PTM configuration. Since an inactive UE cannot receive multicast sessions without a PTM configuration, this can be considered the baseline behavior for all other UEs. Therefore, we should agree on Option 1.

[0208] Proposal 5: RAN2 allows the UE to receive multicast sessions in RRC inactive when a multicast session is activated in UE operation option 1, provided that the PTM configuration used for the session in RRC inactive is available to the UE and the UE is already participating in the session (e.g., configuration provided to the UE via dedicated RRC signaling or MCCH).

[0209] In option 2, when the UE receives group paging, it is indicated whether it should receive the multicast session inactive.

[0210] In option 3, the UE is given prior indication as to whether it should receive the multicast session inactive by reconfiguring or releasing the RRC.

[0211] The mechanisms of these two options are very similar, except for the message that instructs the UE to do so. Therefore, these options can be analyzed in terms of the motivation for inactive multicast reception, namely network congestion and UE power saving.

[0212] In the case of network congestion, it can be assumed that the cell load changes moment by moment. In option 2, since instructions are sent within group paging, the gNB can consider the latest load state when deciding whether the UE should remain inactive. 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. Therefore, there is a risk that congestion will worsen and more UEs will transition to connected, or that even if the congestion is resolved, more UEs will remain inactive. For this reason, option 2 is preferable for efficiently controlling the RRC state of UEs.

[0213] From the perspective of UE power saving, it is expected that some kind of "power saving preference" will be introduced into the UE assistance information. Such preference indications can only be sent from a connected UE. Therefore, the gNB can indicate to the UE whether it was allowed to receive multicast sessions in "inactive" 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 and can display it to the UE at any time. Thus, there is no difference between option 2 and option 3.

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

[0215] Proposal 6: RAN2 should agree to UE operation option 2: "When a multicast session becomes active, the UE will be indicated by group paging whether it can receive the multicast session with RRC inactive (further consideration is needed regarding detailed signaling)."

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

[0217] Finding 3: In other words, if the paging message contains a TMGI of interest, all UEs will transition to RRC Connected.

[0218] Assuming the current paging group list is set for group paging messages and paging at least Rel-17 UEs, Rel-18 UEs will also be paged by any TMGI of interest. Therefore, one might consider defining a new list of UE-IDs, the "paging cancellation list" (or "inactive permission list"), to prevent selected UEs from transitioning to connected, and ensuring that UEs listed on this list remain inactive in order to receive multicast sessions.

[0219] Therefore, RAN2 should discuss ways 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, by 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 relating to Case 3: HARQ feedback and PTP are not supported for multicast reception with RRC inactive.

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

[0223] On the other hand, ensuring QoS / reliability is a critical issue for multicast sessions. SA2 also inquired whether there is a difference in multicast reception quality / reliability between connected and inactive states, and RAN2#119bis-e agreed to the following answer. RAN2 Q1-a When there is a significant 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 UEs in RRC-connected and RRC-inactive states may differ because HARQ feedback and PTP transmission are not supported, and seamless / lossless mobility is not required for multicast reception in RRC-inactive states.

[0224] RAN2#119e proposes introducing receive quality thresholds such as RSRP and BLER, which are expected to be used to ensure a certain level of QoS requirements for multicast reception. It is also useful for the network to manage QoS requests. If inactive multicast reception fails to meet the corresponding QoS requirements, the UE must transition to connected mode and guarantee receive quality using HARQ feedback / retransmission and / or PTP (or split MRB).

[0225] Finding 4: Multicast sessions should maintain certain QoS requirements even when the UE is inactive.

[0226] Regarding RSRP thresholds, since NR MBS is assumed to be a single-cell transmission method, it is thought that the system must always transition to connected mode whenever the UE moves to the cell edge or performs cell reselection. This may not be optimal operation depending on the deployment, considering network congestion and UE power saving.

[0227] Regarding the BLER threshold, it is considered simpler in order to ensure QoS requirements. Therefore, if RRC state transitions based on receive quality are to be introduced, these options should be discussed.

[0228] Proposal 8: RAN2 should agree that if the reception quality falls below a threshold (e.g., RSRP or BLER), an inactive UE should transition to connected.

[0229] 2.4. Case 4: Updating PTM settings RAN2 agreed to the following as prerequisites for its work: This disclosure has a mixed approach and begins as follows: 1. If the network configures the UE to continue receiving multicast in an inactive state, the network provides PTM settings for the activated multicast session via RRC-dedicated signaling to at least the serving cell (other cases require further consideration). 2. MCCH is used when the PTM settings need to be changed or when the PTM settings need to be displayed during transitions beyond the serving cell / gNB. Further consideration is needed for changes to the session status and other displays. 3. Assume that the UE can receive multicast services after joining the session. 4. Further consideration is needed regarding whether MCCH settings are initially provided to the UE via dedicated signaling.

[0230] In other words, the UE can remain inactive in order to retrieve the updated PTM settings. Therefore, from the perspective of an inactive UE, the method of delivering new PTM settings is similar to Rel-17's delivery mode 2. In this case, it is very easy to reuse existing MCCH change notifications to notify of PTM setting updates. Therefore, no additional notifications are needed for PTM setting updates in an inactive UE.

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

[0232] 2.5. Case 5: Service continuity upon RRC resumption It is conceivable that a UE already receiving a multicast session via an inactive method (such as a broadcast MRB) may be paged, initiating the RRC resume procedure. After transitioning to Connected, the UE would naturally want to continue receiving the multicast session. However, in this case, the UE would have both a broadcast MRB and a resumed multicast MRB for the same multicast session. In Rel-17, multicast sessions are only permitted to be received via the multicast MRB configured during RRC reconfiguration. On the other hand, in Rel-18, receiving multicast sessions via the broadcast MRB configured in MCCH may be permitted. 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 the UE's behavior during RRC resumption from the perspective of MRB processing and the continuity of multicast session service.

[0233] Proposal 10: RAN2 should discuss the behavior of the UE when RRC is resumed during continuous reception of a multicast session (such as the handling of broadcast MRB and multicast MRB). [Explanation of symbols]

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

Claims

1. A communication method performed by user equipment in a mobile communication system that provides multicast / broadcast services (MBS), Receiving a multicast session via a multicast radio bearer (MRB) while Radio Resource Control (RRC) is inactive, When performing RRC connection recovery, which transitions from the RRC inactive state to the RRC connected state, the suspended multicast MRB is restored. The restored multicast MRB includes receiving the initial value of the PDCP (Packet Data Convergence Protocol) variable from the network node. Communication method.

2. The user device receives the initial value of the PDCP variable via an RRC message. The communication method according to claim 1.

3. A user device used in a mobile communication system that provides multicast / broadcast services (MBS), A receiving unit that receives multicast sessions via a multicast radio bearer (MRB) in a Wireless Resource Control (RRC) inactive state, When performing RRC connection recovery, which transitions from the RRC inactive state to the RRC connected state, the system includes a control unit that recovers the suspended multicast MRB, The receiving unit receives the initial value of the PDCP (Packet Data Convergence Protocol) variable from the network node for the multicast MRB to be restored. User device.

4. A mobile communication system that provides multicast / broadcast services (MBS), The system comprises user equipment and network nodes. The User device is In a Radio Resource Control (RRC) inactive state, when a multicast session is received via a multicast radio bearer (MRB), When performing RRC connection recovery, which transitions from the RRC inactive state to the RRC connected state, the suspended multicast MRB is restored. The aforementioned network node is For the multicast MRB to be restored, the initial value of the PDCP (Packet Data Convergence Protocol) variable is sent to the user device. Mobile communication system.

5. User equipment used in mobile communication systems that provide multicast / broadcast services (MBS), The process of receiving a multicast session via a multicast radio bearer (MRB) while Radio Resource Control (RRC) is inactive, When performing RRC connection recovery, which transitions from the RRC inactive state to the RRC connected state, the process includes restoring the suspended multicast MRB, For the multicast MRB to be restored, the following process is performed: receiving the initial value of the PDCP (Packet Data Convergence Protocol) variable from the network node. program.

6. A chipset for user equipment used in a mobile communication system that provides multicast / broadcast services (MBS), Receiving a multicast session via a multicast radio bearer (MRB) while Radio Resource Control (RRC) is inactive, When performing RRC connection recovery, which transitions from the RRC inactive state to the RRC connected state, other suspended multicast MRBs are restored. For the multicast MRB to be restored, the initial values ​​of the PDCP (Packet Data Convergence Protocol) variables are received from the network node, and the following is performed: Chipset.

Images