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

By employing MBS session IDs to manage multicast radio bearers across RRC states, the solution addresses the challenge of maintaining continuous multicast reception in mobile communication systems, ensuring seamless transitions and reducing packet loss.

JP7868270B2Active Publication Date: 2026-06-01KYOCERA CORP

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
KYOCERA CORP
Filing Date
2024-09-27
Publication Date
2026-06-01

AI Technical Summary

Technical Problem

Existing mobile communication systems face challenges in maintaining continuous multicast reception for user devices transitioning between RRC connected and inactive states, particularly due to the lack of MRB ID assignment for multicast MRBs in RRC inactive states, leading to difficulties in managing and maintaining multicast sessions.

Method used

The solution involves using the MBS session ID as a key to associate and transfer multicast radio bearers (MRBs) between RRC connected and inactive states, allowing seamless configuration changes and maintaining PDCP entities without resetting, thus ensuring continuous multicast service.

Benefits of technology

This approach enables uninterrupted multicast data reception by allowing user devices to maintain multicast MRBs across state transitions, reducing packet loss and ensuring service continuity.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007868270000001
    Figure 0007868270000001
  • Figure 0007868270000002
    Figure 0007868270000002
  • Figure 0007868270000003
    Figure 0007868270000003
Patent Text Reader

Abstract

This communication method, executed by a user device in a mobile communication system that provides an MBS, includes: establishing a multicast MRB on the basis of a first MRB configuration configured from a network in an RRC connected state; receiving, from the network, a multicast session corresponding to a first MBS session ID included in the first MRB configuration by using the established multicast MRB; receiving, from the network, a second MRB configuration including a second MBS session ID, the second MRB configuration being information for configuring a multicast MRB for an RRC inactive state; and performing a configuration change related to the established multicast MRB on the basis of the second MRB configuration if the second MBS session ID matches the first MBS session ID.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

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

Background Art

[0002] In 3GPP (3rd Generation Partnership Project) (registered trademark; the same shall apply hereinafter), 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 the 5G / NR multicast / broadcast service (MBS) are defined.

[0003] In 3GPP Release 17, reception of MBS multicast (i.e., multicast reception) is only possible for user devices in the radio resource control (RRC) connected state (see, for example, Non-Patent Document 1). On the other hand, in 3GPP Release 18, the technical specifications are planned to be extended so that user devices in the RRC inactive state can perform multicast 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 performed by a user device in a mobile communication system that provides a multicast broadcast service (MBS), comprising: establishing a multicast MRB based on a multicast radio bearer (MRB) setting configured from the network in an RRC connected state; receiving a multicast session from the network corresponding to a first MBS session ID included in the MRB setting using the established multicast MRB; receiving a multicast setting from the network that includes a second MBS session ID, which is information for configuring multicast reception for an RRC inactive state; and applying the multicast setting when receiving a multicast session corresponding to the second MBS session ID in an RRC inactive state in the same cell that received the multicast session corresponding to the first MBS session ID in the RRC connected state.

[0006] The second aspect of the communication method is a communication method performed by a user device in a mobile communication system that provides a multicast broadcast service (MBS), comprising: establishing a multicast MRB based on a first multicast radio bearer (MRB) setting configured from the network in an RRC connected state; receiving a multicast session from the network corresponding to a first MBS session ID included in the first MRB setting using the established multicast MRB; receiving a second MRB setting from the network, which is information for configuring a multicast MRB for an RRC inactive state and includes a second MBS session ID; and, if the second MBS session ID matches the first MBS session ID, making a setting change to the established multicast MRB based on the second MRB setting.

[0007] The user device according to the third embodiment is a user device used in a mobile communication system that provides a multicast broadcast service (MBS), and includes a control unit that performs the following: establishing a multicast MRB based on a first multicast radio bearer (MRB) setting configured from the network in an RRC connected state; receiving a multicast session from the network corresponding to a first MBS session ID included in the first MRB setting using the established multicast MRB; receiving a second MRB setting from the network, which is information for configuring a multicast MRB for an RRC inactive state and includes a second MBS session ID; and, if the second MBS session ID matches the first MBS session ID, performing a setting change regarding the established multicast MRB based on the second MRB setting. [Brief explanation of the drawing]

[0008] [Figure 1] This is a diagram showing an example configuration of a mobile communication system according to the embodiment. [Figure 2] This figure shows an example configuration of a UE (User Equipment) according to the embodiment. [Figure 3] This figure shows an example configuration of a gNB (Network Node) 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 is a diagram illustrating a hypothetical scenario according to the embodiment. [Figure 7] This is a diagram illustrating a hypothetical scenario according to the embodiment. [Figure 8] This figure shows a first example of operation of the UE according to the embodiment. [Figure 9] This figure shows a second example of operation of the UE according to the embodiment. [Modes for carrying out the invention]

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

[0010] (1) Example of system configuration Figure 1 shows an example 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.

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

[0012] 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 a smartphone) or 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).

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

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

[0015] The 5GC20 includes the AMF (Access and Mobility Management Function) and the UPF (User Plane Function) 300. The AMF performs various mobility controls for the UE100. The AMF manages the mobility of the UE100 by communicating with it using NAS (Non-Access Stratum) signaling. The UPF controls data transfer. The AMF and UPF are connected to the gNB200 via the NG interface, which is the base station-core network interface.

[0016] Figure 2 shows an example configuration of UE100 (user device) according to an embodiment. UE100 includes a receiving unit 110, a transmitting unit 120, and a control unit 130. The receiving unit 110 and the transmitting unit 120 constitute a wireless communication unit that performs wireless communication with gNB200.

[0017] The receiving unit 110 performs various receptions 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.

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

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

[0020] FIG. 3 is a diagram showing a configuration example of a gNB 200 (network node) according to an embodiment. The gNB 200 has a transmitting unit 210, a receiving unit 220, a control unit 230, and a backhaul communication unit 240. The transmitting unit 210 and the receiving unit 220 constitute a radio communication unit that performs radio communication with the UE 100. The backhaul communication unit 240 constitutes a network communication unit that communicates with the CN 20.

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

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

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

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

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

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

[0027] 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 (Cyclic Redundancy Code) parity bit added, which is scrambled by the RNTI.

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

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

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

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

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

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

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

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

[0036] (2) Overview of MBS Mobile communication system 1 can perform resource-efficient distribution through multicast / broadcast services (MBS).

[0037] (2.1) MBS Broadcast 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. Broadcast communication services are delivered to the UE100s using broadcast sessions, which are a type of MBS session. UE100s can receive broadcast sessions regardless of whether they are in the RRC idle, RRC inactive, or RRC connected state.

[0038] Broadcast communication services utilize Point-to-Multipoint (PTM) distribution. In PTM transmission, the gNB200 distributes a single copy of an MBS packet to a set (group) of multiple UE100s. For example, the gNB200 schedules a group-common PDSCH, which has a CRC scrambled by a group-common RNTI (G-RNTI), using a group-common PDCCH with a CRC scrambled by a group-common RNTI.

[0039] For broadcast communication services, UE100 receives a broadcast session in the following steps: First, UE100 receives a System Information Block Type 20 (SIB20) from gNB200. SIB20 contains the settings for a Multicast Control Channel (MCCH), which is a type of logical channel. Second, based on SIB20, UE100 receives the MCCH from gNB200. The MCCH contains the PTM settings. The PTM settings transmit settings for a Multicast Traffic Channel (MTCH), which is a type of logical channel (MTCH settings), and settings for a Broadcast MRB, which is a Multicast Radio Bearer (MRB) for the broadcast session. The information transmitted by the MCCH is sometimes referred to as MBS broadcast control information. Third, based on the MCCH, UE100 receives the MTCH. The MTCH transmits the broadcast session (specifically, the MBS data belonging to the broadcast session).

[0040] MCCH is a PTM downlink channel for transmitting MBS broadcast control information associated with one or more MTCHs from network 5 to UE100. MTCH is a PTM downlink channel for transmitting MBS data for either a multicast session or a broadcast session from network 5 to UE100.

[0041] (2.2) MBS Multicast In the case of multicast communication services (also known 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 a 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.

[0042] UE100 can only receive multicast sessions after it has joined the multicast session. Joining a multicast session may mean that UE100 is registered with network 5 (CN20) as a device capable of receiving the multicast session.

[0043] For multicast communication services, 3GPP Release 17 allows only UE100s in the RRC Connected state to receive multicast sessions. However, 3GPP Release 18 extends this to allow UE100s in the RRC Inactive state to also receive multicast sessions.

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

[0045] In the case of a multicast communication service, a UE100 in the RRC connected state receives a multicast session in the following procedure. First, the UE100 receives an RRC Reconfiguration message from the gNB200. The RRC Reconfiguration message is transmitted on the Dedicated Control Channel (DCCH). The RRC Reconfiguration message transmits the settings for the MTCH for receiving the multicast session (MTCH settings) and the settings for the multicast MRB, which is the MRB for that multicast session. Second, the UE100 receives the MTCH based on the RRC Reconfiguration message. The MTCH transmits the multicast session (specifically, the MBS data belonging to the multicast session).

[0046] (2.2.2) Multicast reception in RRC inactive state A UE100 in an RRC inactive state can receive multicast sessions (specifically, MBS data belonging to multicast sessions) using the PTM distribution mechanism.

[0047] In the case of a multicast communication service, a UE100 in an RRC inactive state can receive a multicast session in the following manner: First, the UE100 in an RRC inactive state receives a newly introduced system information block (also called "SIBx") from the gNB200. The SIBx includes the configuration of a newly introduced MCCH (also called "multicast MCCH"). Second, the UE100 in an RRC inactive state receives the multicast MCCH from the gNB200 based on the SIBx. The multicast MCCH includes the PTM configuration. The PTM configuration transmits the configuration for the MTCH for multicast session reception (MTCH configuration) and the configuration for the inactive MRB, which is the MRB for multicast session reception in an RRC inactive state (inactive MRB configuration). The MTCH configuration may also be included in the multicast MRB configuration. Third, the UE100 in an RRC inactive state receives the MTCH based on the multicast MCCH. MTCH transmits multicast sessions, specifically MBS data (i.e., multicast data) belonging to multicast sessions.

[0048] If the gNB200 configures the UE100 to receive multicast sessions in an RRC inactive state, it can send PTM settings (multicast MRB settings) to the UE100 using an RRC Release message that includes suspend settings. In this case, when the UE100 receives the RRC Release message containing PTM settings from the gNB200, it transitions to an RRC inactive state and receives multicast sessions (multicast reception) in an RRC inactive state.

[0049] (2.2.3) Group Notifications If there is temporarily no data to send to UE100 in an active multicast session, gNB200 may transition UE100 to the RRC inactive state. When the multicast session is deactivated, gNB200 may transition UE100 to the RRC idle state or the RRC inactive state.

[0050] A gNB200 that supports MBS will use the group notification mechanism to notify UE100s that are in an RRC idle or RRC inactive state when a multicast session is activated by CN20. For example, a gNB200 that supports MBS may use the group notification mechanism to notify UE100s that are in an RRC inactive state if a multicast session has been activated and there is multicast session data to be distributed on the gNB200.

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

[0052] The group notification paging message includes a session identifier (MBS session ID) used to page all UE100s in the RRC idle and RRC inactive states that are participating in the associated MBS multicast session. In other words, UE100s are not paged individually.

[0053] When UE100 transitions to the RRC Connected state, UE100 may stop monitoring group notifications associated with a particular multicast session. In other words, UE100 stops checking for the MBS session ID in paging messages. UE100 does not monitor group notifications if UE100 leaves the multicast session, network 5 requests UE100 to leave, or network 5 releases the multicast session.

[0054] Group notifications may be made via MCCH or via MCCH Change Notification. When using MCCH, the determination may be made based on whether or not the MCCH setting for the MBS session of interest exists in MCCH. When using MCCH Change Notification, the group notification may be notified in a predetermined bit of DCI.

[0055] (3) Operation of the mobile communication system The operation of the mobile communication system 1 according to this embodiment will be described.

[0056] (3.1) Operation overview In MBS multicast as defined in 3GPP Release 17, the MRB ID of the multicast MRB is set from gNB200 to UE100, and the multicast MRB is managed by its MRB ID. The MRB ID is cell-specific. Such multicast MRBs are dedicated to the RRC connected state, and when the UE100 is handed over, the multicast MRB is reconfigured by gNB200 along with its MRB ID.

[0057] In MBS broadcasts as defined in 3GPP Release 17, the MRB ID of a broadcast MRB is not set from gNB200 to UE100. The assignment of an MRB ID to a broadcast MRB is UE implementation dependent, and broadcast MRBs do not have an MRB ID. Therefore, UE100, which receives broadcasts in an RRC idle or RRC inactive state, can perform cell reselection without considering the MRB ID.

[0058] On the other hand, in the 3GPP Release 18 scenario, that is, the scenario in which UE100 in an RRC inactive state performs multicast reception, the UE100 performing multicast reception can perform cell reselection. Therefore, it is thought that the MRB ID will not be set from gNB200 to UE100 for multicast MRBs in the RRC inactive state, similar to broadcast MRBs. If the MRB ID is not set from gNB200 to UE100, there is a problem in that multicast MRBs cannot be managed by MRB ID.

[0059] Figures 6 and 7 illustrate a hypothetical scenario according to the embodiment. In this hypothetical scenario, a UE100 that has already joined a multicast session transitions from the RRC connected state to the RRC inactive state in cell a. Then, in the RRC inactive state, the UE100 performs cell reselection, re-selecting the serving cell from cell a to cell b, and the UE100 transitions to the RRC connected state in cell b. In the illustrated example, cells a and b are shown as belonging to separate gNB200s (gNB200a and gNB200b), but cells a and b may belong to a single gNB200.

[0060] In STEP 1 shown in Figure 6, UE100 in the RRC Connected state at cell a has a multicast MRB for the RRC Connected state configured by gNB200a. Specifically, gNB200a sends an RRC Reconfiguration message to UE100 that includes the first MRB configuration for setting up the multicast MRB. Upon receiving the RRC Reconfiguration message, UE100 establishes the multicast MRB and uses the multicast MRB to receive multicast sessions (multicast data) on the MTCH. Here, let's assume that gNB200a has set "A" as the MRB ID for the multicast MRB.

[0061] In STEP 2 shown in Figure 6, UE100 transitions from the RRC Connected state to the RRC Inactive state in cell a. Specifically, gNB200a sends an RRC Release message (i.e., an RRC Release message including a suspend setting) to UE100 to transition it to the RRC Inactive state. The suspend setting may include information indicating which multicast services (multicast sessions) are receivable in the RRC Inactive state. Upon receiving the RRC Release message, UE100 transitions to the RRC Inactive state. The RRC Release message may include a second MRB setting to configure a multicast MRB for the RRC Inactive state. gNB200 may send (broadcast) the second MRB setting for configuring a multicast MRB for the RRC Inactive state via multicast MCCH. The second MRB setting does not include the MRB ID of the multicast MRB.

[0062] Here, UE100 can suppress interruptions in multicast data reception (i.e., packet loss) by continuously using a multicast MRB (and the PDCP entity associated with the multicast MRB) established in an RRC-connected state while the RRC is inactive. By associating the multicast MRB configured in the first MRB setting with the multicast MRB configured in the second MRB setting, UE100 can change (reconfigure) the multicast MRB established based on the first MRB setting based on the second MRB setting and continue to use the multicast MRB.

[0063] However, if the second MRB configuration transmitted in the RRC Release message or multicast MCCH does not include the MRB ID, the UE100 cannot associate the multicast MRB configured in the first MRB configuration with the multicast MRB configured in the second MRB configuration using the MRB ID as the key. Therefore, there is a problem in that it is difficult for the UE100 to continuously use a multicast MRB established in the RRC connected state when the RRC is inactive. To solve this problem, in this embodiment, the UE100 associates the multicast MRB configured in the first MRB configuration with the multicast MRB configured in the second MRB configuration using the MBS session ID (TMGI: Temporary Mobile Group Identity) as the key, rather than the MRB ID. As a result, the UE100 can continuously use a multicast MRB (and the PDCP entity associated with the multicast MRB) established in the RRC connected state when the RRC is inactive.

[0064] In STEP 3 shown in Figure 7, UE100, in the RRC inactive state, performs cell reselection from cell a to cell b. Here, it is assumed that UE100 continues to use the multicast MRB established in STEP 1 in the RRC inactive state after the configuration change in STEP 2, and continues to receive multicast sessions in the RRC inactive state.

[0065] In STEP 4 shown in Figure 7, UE100 initiates the RRC connection resume procedure in cell b and transitions to the RRC connected state. Specifically, UE100 sends an RRC Resume Request message to gNB200b, gNB200b sends an RRC Resume message to UE100, and UE100 sends an RRC Resume Complete message to gNB200b, completing the RRC connection resume procedure and causing UE100 to transition to the RRC connected state. gNB200b then sends an RRC Reconfiguration message to UE100, which includes a third MRB setting to configure the multicast MRB for the RRC connected state. Here, let's assume that gNB200a has set "B" as the MRB ID for the multicast MRB.

[0066] Here, UE100 can suppress interruptions in multicast data reception (i.e., packet loss) by continuously using the multicast MRB (and the PDCP entity associated with the multicast MRB) that was being used in the RRC inactive state in the RRC connected state. By associating the multicast MRB configured in the second MRB setting with the multicast MRB configured in the third MRB setting, UE100 can change (reconfigure) the multicast MRB currently in use based on the third MRB setting and continue to use that multicast MRB.

[0067] However, if the multicast MRB used in the RRC inactive state does not have an MRB ID, UE100 cannot associate the multicast MRB used in the RRC inactive state with the multicast MRB configured in the third MRB setting using the MRB ID as the key. Therefore, there is a problem in that it is difficult for UE100 to continue using the multicast MRB used in the RRC inactive state in the RRC connected state. To solve this problem, in this embodiment, UE100 associates the multicast MRB used in the RRC inactive state with the multicast MRB configured in the third MRB setting using the MBS session ID instead of the MRB ID as the key. As a result, UE100 can continue to use the multicast MRB (and the PDCP entity associated with the multicast MRB) used in the RRC inactive state in the RRC connected state. In addition, UE100 can apply the MRB ID "B" configured in the third MRB setting to the multicast MRB.

[0068] Thus, in this embodiment, UE100 uses the MBS session ID instead of the MRB ID to determine the multicast status for the RRC connected state. to This implements configuration transfer (partial transfer) between the MRB and the MRB used for the RRC inactive state. This allows for MRB configuration transfer even if the gNB200 does not set the MRB ID on the UE100 for the multicast MRB used for the RRC inactive state. Furthermore, it improves the continuity of multicast services by maintaining the PDCP entity associated with the multicast MRB without resetting it.

[0069] (3.2) Example of operation when transitioning from RRC connected state to RRC inactive state Figure 8 shows a first example of operation of UE100 according to the embodiment. Specifically, the first example of operation is an example of operation when transitioning from the RRC connected state to the RRC inactive state.

[0070] In step S11, UE100 establishes a multicast MRB in the RRC connected state based on the first MRB configuration set from network 5 (gNB200). Specifically, UE100 sets the first MRB configuration, which includes the first MBS session ID and MRB ID (e.g., MRB ID=A), which is information for setting up a multicast MRB for the RRC connected state. 、R Upon receiving an RC Reconfiguration message from network 5 (gNB200), the multicast MRB and the corresponding PDCP and RLC entities are established. 。R The RC Reconfiguration message may contain multiple primary MRB configurations corresponding to multiple multicast MRBs.

[0071] In step S12, UE100 uses the multicast MRB established in step S11 to receive a multicast session from network 5 (gNB200) corresponding to the first MBS session ID included in the first MRB configuration. Here, UE100 receives the data (multicast data) of the multicast session on the MTCH.

[0072] In step S13, UE100 receives from network 5 (gNB200) a second MRB configuration, which includes the second MBS session ID, and is information for configuring a multicast MRB for the RRC inactive state. Specifically, UE100 receives a second MRB configuration, which includes the second MBS session ID but does not include the MRB ID, in a multicast MCCH or RRC Release message. The multicast MCCH or RRC Release message may contain multiple second MRB configurations corresponding to multiple multicast MRBs.

[0073] In step S14, if the second MBS session ID included in the second MRB configuration matches the first MBS session ID included in the first MRB configuration, the UE100 makes configuration changes to the multicast MRB established in the first MRB configuration based on the second MRB configuration. Here, if the MBS session ID corresponding to the multicast MRB for the RRC connected state matches the MBS session ID corresponding to the multicast MRB for the RRC inactive state, the UE100 identifies the multicast MRB configuration (specifically, the first and second MRB configurations having the same MBS session ID). Then, the UE100 uses the two identified MRB configurations to make configuration changes to the multicast MRB for the RRC connected state. The UE100 makes configuration changes while maintaining the PDCP entity associated with the multicast MRB.

[0074] For example, UE100 compares the two identified MRB settings (the first and second MRB settings having the same MBS session ID) and performs at least one of the following processes 1) to 5).

[0075] 1) UE100 does not need to retain the MRB ID set in the RRC Reconfiguration message (first MRB setting). UE100 may discard the MRB ID set in the RRC Reconfiguration message (first MRB setting). Alternatively, UE100 may retain the MRB ID set in the RRC Reconfiguration message (first MRB setting).

[0076] 2) UE100 replaces the PDCP settings configured in the RRC Reconfiguration message (first MRB setting) with the second MRB setting. However, UE100 maintains the PDCP entity and PDCP COUNT without resetting them. The PDCP COUNT value is composed of the hyperframe number (HFN) and the PDCP-sequence number (SN). The PDCP-SN is incremented in response to the reception of a PDCP packet. The HFN is incremented each time the PDCP-SN circulates. Meanwhile, the receiving PDCP entity uses the PDCP COUNT to perform PDCP layer processing. Maintaining the PDCP entity and PDCP COUNT improves the continuity of multicast reception.

[0077] 3) If a point-to-point (PTP) leg is configured for the multicast MRB in the RRC Reconfiguration message (first MRB configuration), UE100 will discard or suspend the configuration of that PTP leg.

[0078] 4) If the UE100 has a point-to-multipoint (PTM) leg configured for the multicast MRB in the RRC Reconfiguration message (first MRB configuration), it changes the setting of that PTM leg to the multicast MRB configuration for the RRC inactive state (second MRB configuration). At this point, the UE100 also changes the group DRX setting to the multicast MRB configuration for the RRC inactive state. In addition, the UE100 may reset the RLC entity when changing the RLC configuration.

[0079] 5) If the PTM leg is not configured in the RRC Reconfiguration message (first MRB configuration), UE100 will apply PTM reception (multicast reception) using the multicast MRB configuration for the RRC inactive state.

[0080] In step S15, UE100 transitions to the RRC inactive state and then continues to receive multicast sessions using the multicast MRB configured in step S14.

[0081] (3.3) Example of operation when transitioning from RRC inactive state to RRC connected state Figure 9 shows a second example of operation of UE100 according to the embodiment. Specifically, the second example of operation is an example of operation when transitioning from the RRC inactive state to the RRC connected state. The second example of operation may be an operation that takes place after the operation of the first example of operation.

[0082] In step S21, UE100, in the RRC inactive state, receives a multicast session from network 5 (gNB200) using a multicast MRB based on the second MRB configuration for the RRC inactive state (specifically, a multicast MRB for the RRC inactive state). Here, UE100 receives the data (multicast data) of the multicast session on the MTCH.

[0083] In step S22, UE100 transitions from the RRC inactive state to the RRC connected state via RRC connection resume, and then receives information for configuring the multicast MRB for the RRC connected state, including the third MRB configuration and the third MBS session ID, from network 5 (gNB200). Here, UE100 in the RRC connected state receives the multicast MRB configuration for the RRC connected state in an RRC Reconfiguration message. Specifically, in the RRC connected state, UE100 receives the third MRB configuration, including the third MBS session ID and MRB ID (for example, MRB ID=B), from network 5 (gNB200) in an RRC reconfiguration message. 。R The RC Reconfiguration message may contain multiple third-party MRB configurations to accommodate multiple multicast MRBs.

[0084] In step S23, if the UE100 in the RRC Connected state finds that the third MBS session ID received in the RRC Reconfiguration message matches the second MBS session ID corresponding to the multicast MRB currently in use, the UE100 makes configuration changes to the multicast MRB based on the third MRB configuration. Here, if the MBS session ID corresponding to the multicast MRB for the RRC Connected state matches the MBS session ID corresponding to the multicast MRB for the RRC Inactive state, the UE100 identifies the multicast MRB configuration (specifically, the second and third MRB configurations having the same MBS session ID). The UE100 then uses the two identified MRB configurations to make configuration changes to the multicast MRB for the RRC Inactive state. The UE100 makes configuration changes while maintaining the PDCP entity associated with the multicast MRB. The UE100 also assigns the MRB ID included in the identified third MRB configuration to the multicast MRB.

[0085] For example, UE100 compares the two MRB settings identified above and performs at least one of the following processes 1) through 4).

[0086] 1) The UE100 identifies the MRB ID set in the RRC Reconfiguration message (3rd MRB setting) and applies (retains) the identified MRB ID as the setting for that multicast MRB.

[0087] 2) UE100 replaces the PDCP settings for the RRC inactive state that were set in the second MRB settings with the PDCP settings set in the RRC Reconfiguration message (third MRB settings). However, UE100 does not reset the PDCP entity and PDCP COUNT corresponding to the multicast MRB.

[0088] 3) If a PTP leg is configured in the RRC Reconfiguration message (3rd MRB configuration), the configuration of that PTP leg will be applied or resumed.

[0089] 4) If a PTM leg is configured in the RRC Reconfiguration message (3rd MRB setting), the setting of that PTM leg is changed to the RRC Connected state multicast MRB setting (3rd MRB setting). UE100 also changes the group DRX setting to the RRC Connected state multicast MRB setting. UE100 may reset the RLC entity when changing the RLC setting.

[0090] In step S24, the UE100 in the RRC connected state continues to receive multicast sessions using the multicast MRB configured in step S23.

[0091] (4) Other embodiments In the embodiments described above, multicast reception in the RRC inactive state was mainly explained, but the operation according to the embodiments described above may also be applied to multicast reception in the RRC idle state. In the case of the RRC idle state, the above-described RRC resume is read as RRC establishment.

[0092] 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. Furthermore, the order of steps in each flow may be changed as appropriate.

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

[0094] In other words, UE100 may be a terminal function unit (a type of communication module) for a base station to control a repeater that performs signal relay. Such a terminal function unit is called an MT. Examples of MTs other than IAB-MT include NCR (Network Controlled Repeater)-MT and RIS (Reconfigurable Intelligent Surface)-MT.

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

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

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

[0098] The terms "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 their variations do not mean to include only the listed items, but may include only the listed items or may include additional items 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.

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

[0100] This application claims priority to Japanese Patent Application No. 2023-164162 (filed September 27, 2023), and all of its contents are incorporated into the specification of this application.

[0101] (5) Note The features of the above-described embodiment are noted below.

[0102] (Note 1) A communication method performed by user equipment in a mobile communication system that provides multicast broadcast services (MBS), In the RRC connected state, establish a multicast MRB based on the first multicast radio bearer (MRB) configuration set from the network, Using the established multicast MRB, a multicast session corresponding to the first MBS session ID included in the first MRB configuration is received from the network. Information for configuring a multicast MRB for an RRC inactive state, which includes receiving a second MRB configuration from the network, including a second MBS session ID. If the second MBS session ID matches the first MBS session ID, the configuration changes for the established multicast MRB are made based on the second MRB configuration. Communication method.

[0103] (Note 2) Making the aforementioned configuration change includes making the configuration change while maintaining the PDCP entity associated with the multicast MRB. The communication method described in Appendix 1.

[0104] (Note 3) In the RRC connected state, the system further includes receiving from the network in an RRC reconfiguration message the first MRB configuration, which includes the first MBS session ID and the MRB ID, for configuring a multicast MRB for the RRC connected state. The communication method described in Appendix 1 or 2.

[0105] (Note 4) Receiving the second MRB configuration includes receiving the second MRB configuration, which includes the second MBS session ID but does not include the MRB ID, in a multicast MCCH or RRC release message. The communication method described in any of the appendices 1 to 3.

[0106] (Note 5) The system further includes continuing to receive the multicast session using the multicast MRB after the configuration change, following the transition to the RRC inactive state. The communication method described in any of the appendices 1 to 4.

[0107] (Note 6) After transitioning from the RRC inactive state to the RRC connected state, information for configuring the multicast MRB for the RRC connected state, including the third MRB configuration including the third MBS session ID, is received from the network. If the third MBS session ID matches the second MBS session ID, the multicast MRB configuration is changed based on the third MRB configuration, further comprising The communication method described in any of the appendices 1 to 5.

[0108] (Note 7) The system further includes continuing to receive the multicast session using the multicast MRB after transitioning to the RRC connected state. The communication method described in Appendix 6.

[0109] (Note 8) Making the configuration change based on the third MRB configuration includes making the configuration change while maintaining the PDCP entity associated with the multicast MRB. The communication method described in Appendix 6 or 7.

[0110] (Note 9) In the RRC connected state, the third MRB settings, including the third MBS session ID and MRB ID, are further received from the network in an RRC reconfiguration message. The communication method described in any of the appendices 6 to 8.

[0111] (Note 10) Making the configuration changes based on the third MRB configuration includes assigning the MRB ID included in the third MRB configuration to the multicast MRB. The communication method described in Appendix 9.

[0112] (Note 11) A user device used in a mobile communication system that provides multicast broadcast services (MBS), In the RRC connected state, the process involves establishing a multicast MRB based on the first multicast radio bearer (MRB) configuration set from the network, Using the established multicast MRB, the process of receiving a multicast session from the network corresponding to the first MBS session ID included in the first MRB configuration, Information for configuring a multicast MRB for an RRC inactive state, comprising the process of receiving a second MRB configuration, including a second MBS session ID, from the network, The control unit includes, if the second MBS session ID matches the first MBS session ID, a process to change the settings related to the established multicast MRB based on the second MRB settings. User device. [Explanation of Symbols]

[0113] 1: Mobile communication systems 5: Network 10: RAN 20:CN 100: UE (User Device) 110: Receiver 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), In a Wireless Resource Control (RRC) connected state, establish a multicast MRB based on the multicast wireless bearer (MRB) settings configured from the network, Using the established multicast MRB, a multicast session corresponding to the first MBS session ID included in the MRB configuration is received from the network. Information for configuring multicast reception for RRC inactive state, which involves receiving multicast settings including a second MBS session ID from the network, The multicast setting is applied when, in the same cell that received the multicast session corresponding to the first MBS session ID in the RRC connected state, the multicast session corresponding to the second MBS session ID is received in the RRC inactive state. Communication method.

2. In the RRC inactive state, maintain the multicast MRB and the PDCP entity associated with the multicast MRB. The RRC inactive state further includes receiving the multicast session using the multicast MRB. The communication method according to claim 1.

3. In the RRC connected state, the system further includes receiving from the network in an RRC reconfiguration message the MRB configuration, which includes the first MBS session ID and the MRB ID, for configuring a multicast MRB for the RRC connected state. The communication method according to claim 1.

4. Receiving the multicast configuration includes receiving the multicast configuration, which includes the second MBS session ID but not the MRB ID, in an RRC release message. The communication method according to claim 1.

5. The system further includes continuing to receive the multicast session using the multicast MRB to which the multicast settings have been applied after transitioning to the RRC inactive state. The communication method according to claim 1.

6. A user device used in a mobile communication system that provides multicast broadcast services (MBS), In a Wireless Resource Control (RRC) connected state, the process involves establishing a multicast MRB based on the multicast wireless bearer (MRB) settings configured from the network, Using the established multicast MRB, the process of receiving a multicast session from the network corresponding to the first MBS session ID included in the MRB configuration, Information for configuring multicast reception for RRC inactive state, comprising the process of receiving multicast settings including a second MBS session ID from the network, The control unit includes a control unit that performs the following: when a multicast session corresponding to the first MBS session ID is received in the same cell that received the multicast session corresponding to the first MBS session ID in the RRC connected state, and a multicast session corresponding to the second MBS session ID is received in the RRC inactive state, the control unit performs the process of applying the multicast settings. User device.

7. A user device used in a mobile communication system that provides multicast broadcast service (MBS), In a Wireless Resource Control (RRC) connected state, the process involves establishing a multicast MRB based on the multicast wireless bearer (MRB) settings configured from the network, Using the established multicast MRB, the process of receiving a multicast session from the network corresponding to the first MBS session ID included in the MRB configuration, Information for configuring multicast reception for RRC inactive state, comprising the process of receiving multicast settings including a second MBS session ID from the network, When a multicast session corresponding to the second MBS session ID is received in the same cell that received the multicast session corresponding to the first MBS session ID in the RRC connected state, in the RRC inactive state, the process of applying the multicast settings is executed. program.

8. A chipset for user equipment used in a mobile communication system that provides multicast broadcast services (MBS), In a Wireless Resource Control (RRC) connected state, the process involves establishing a multicast MRB based on the multicast wireless bearer (MRB) settings configured from the network, Using the established multicast MRB, the process of receiving a multicast session from the network corresponding to the first MBS session ID included in the MRB configuration, Information for configuring multicast reception for RRC inactive state, comprising the process of receiving multicast settings including a second MBS session ID from the network, If the same cell that received the multicast session corresponding to the first MBS session ID in the RRC connected state receives the multicast session corresponding to the second MBS session ID in the RRC inactive state, the process of applying the multicast settings is executed. Chipset.

9. A mobile communication system that provides multicast broadcast service (MBS), The user device is In the Wireless Resource Control (RRC) connected state, a multicast MRB is established based on the multicast wireless bearer (MRB) settings configured from the network. Using the established multicast MRB, a multicast session corresponding to the first MBS session ID included in the MRB configuration is received from the network. Information for configuring multicast reception for RRC inactive state, wherein multicast settings including a second MBS session ID are received from the network, If the same cell that received the multicast session corresponding to the first MBS session ID in the RRC connected state receives the multicast session corresponding to the second MBS session ID in the RRC inactive state, the multicast setting will be applied. Mobile communication system.