Communication method and user equipment
By using the multicast session ID as a key in the RRC_connected and RRC_inactive states to switch the multicast MRB configuration, the problem of multicast data reception interruption when the user equipment changes state is solved, and the continuity and stability of multicast service are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- KYOCERA CORP
- Filing Date
- 2024-09-27
- Publication Date
- 2026-06-16
AI Technical Summary
In 3GPP Release 18, user equipment in the RRC_inactive state has difficulty continuing to use the multicast radio bearer (MRB) established in the RRC_connected state, resulting in interruption of multicast data reception and packet loss.
By using the Multicast Session ID (TMGI) as a key instead of the MRB ID, the multicast MRB configuration can be switched between the RRC_connected and RRC_inactive states, maintaining the continuity of the multicast MRB, including its association with PDCP entities.
It ensures the continuity of multicast service and the stability of data reception when the user equipment state changes, avoiding multicast data interruption and packet loss.
Smart Images

Figure CN122228670A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to a communication method and user equipment used in a mobile communication system. Background Technology
[0002] The 3rd Generation Partnership Project (3GPP) defines the technical specifications for New Radio (NR) as a fifth-generation (5G) radio access technology. Compared to Long Term Evolution (LTE) as a fourth-generation (4G) radio access technology, NR offers features such as high speed, high capacity, high reliability, and low latency. 3GPP has also defined the technical specifications for 5G / NR multicast / broadcast services (MBS).
[0003] In 3GPP Release 17, MBS multicast reception (i.e., multicast reception) could only be supported by user equipment 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 were planned to be extended so that user equipment in the RRC_inactive state could perform multicast reception.
[0004] Reference List
[0005] Non-patent literature
[0006] Non-patent document 1: 3GPP technical specification: TS 38.300 V17.5.0 Summary of the Invention
[0007] According to a first aspect, a communication method performed by a user equipment in a mobile communication system for providing multicast broadcast service (MBS) includes: establishing a multicast MRB based on a multicast radio bearer (MRB) configuration configured from the network in an RRC_connected state; receiving a multicast session corresponding to a first MBS session ID included in the MRB configuration from the network using the established multicast MRB; receiving a multicast configuration from the network, the multicast configuration being information for configuring multicast reception in an RRC_inactive state and including a second MBS session ID; and applying the multicast configuration when a multicast session corresponding to the second MBS session ID is received in the RRC_inactive state in the same cell as the cell in the RRC_connected state where a multicast session corresponding to the first MBS session ID has already been received.
[0008] The communication method according to the second aspect is a communication method performed by a user equipment in a mobile communication system for providing multicast broadcast service (MBS), the communication method comprising: in an RRC_connected state, establishing a multicast MRB based on a first multicast radio bearer (MRB) configuration configured from the network; receiving a multicast session from the network using the established multicast MRB corresponding to a first MBS session ID included in the first MRB configuration; receiving a second MRB configuration from the network, the second MRB configuration being information for configuring a multicast MRB for an RRC_inactive state and including a second MBS session ID; and when the second MBS session ID matches the first MBS session ID, performing configuration changes related to the established multicast MRB based on the second MRB configuration.
[0009] According to the third aspect, the user equipment is a user equipment used in a mobile communication system for providing multicast broadcast service (MBS), the user equipment including a controller configured to perform the following processes: in the RRC_connected state, establishing a multicast radio bearer (MRB) based on a first MRB configuration configured from the network; receiving a multicast session from the network using the established multicast MRB corresponding to a first MBS session ID included in the first MRB configuration; receiving a second MRB configuration from the network, the second MRB configuration being information for configuring a multicast MRB for the RRC_inactive state and including a second MBS session ID; and when the second MBS session ID matches the first MBS session ID, performing configuration changes related to the established multicast MRB based on the second MRB configuration. Attached Figure Description
[0010] Figure 1 This is a diagram illustrating a configuration example of a mobile communication system according to an embodiment.
[0011] Figure 2 This is a diagram illustrating a configuration example of a user equipment (UE) according to an embodiment.
[0012] Figure 3 This is a diagram illustrating a configuration example of a gNB (network node) according to an embodiment.
[0013] Figure 4 This is a diagram illustrating the configuration of the protocol stack for the user plane radio interface that processes data.
[0014] Figure 5 This is a diagram showing the configuration of the protocol stack of the radio interface of the control plane that processes signaling (control signals).
[0015] Figure 6This is a diagram illustrating a hypothetical scenario according to an embodiment.
[0016] Figure 7 This is a diagram illustrating a hypothetical scenario according to an embodiment.
[0017] Figure 8 This is a diagram illustrating a first operational example of the UE according to an embodiment.
[0018] Figure 9 This is a flowchart illustrating a second operational example of a UE according to an embodiment. Detailed Implementation
[0019] According to an embodiment, a mobile communication system is described herein with reference to the accompanying drawings. In the description of the drawings, the same or similar reference numerals denote the same or similar parts.
[0020] (1) System configuration example
[0021] Figure 1 This is a diagram illustrating a configuration example of a mobile communication system 1 according to an embodiment. The mobile communication system 1 conforms to the 3GPP standard for a fifth-generation system (5GS). The following description uses 5GS as an example, but a Long Term Evolution (LTE) system can be applied at least partially to the mobile communication system. Alternatively, a sixth-generation (6G) system can be applied at least partially to the mobile communication system.
[0022] The mobile communication system includes User Equipment (UE) 100, a 5G radio access network (Next Generation Radio Access Network (NG-RAN)) 10, and a 5G core network (5GC) 20. In the following text, NG-RAN 10 may be simply referred to as RAN 10. 5GC 20 may be simply referred to as the core network (CN) 20. RAN 10 and CN 20 constitute network 5 of the mobile communication system 1.
[0023] UE 100 is a mobile wireless communication device. UE 100 can be any device as long as it is used by a user. Examples of UE 100 include mobile phone terminals (including smartphones) or tablet terminals, laptop PCs, communication modules (including communication cards or chipsets), sensors or devices mounted on sensors, vehicles or devices mounted on vehicles (vehicle UE), or flying objects and devices mounted on flying objects (airborne UE).
[0024] NG-RAN 10 includes base stations 200 (referred to as "gNBs" in 5G systems) as network nodes. gNBs 200 are interconnected via an Xn interface, which serves as an inter-base station interface. Each gNB 200 manages one or more cells. gNBs 200 perform wireless communication with UE 100, which has established a connection with a cell of the gNB 200. gNBs 200 have radio resource management (RRM) functions, functions for routing user data (hereinafter referred to as "data"), measurement and control functions for mobility control and scheduling, etc. "Cell" is used as a term to represent the smallest unit of a wireless communication area. "Cell" is also used as a term to represent the functions or resources used to perform wireless communication with UE 100. A cell belongs to a carrier frequency (hereinafter referred to as "frequency").
[0025] Note that a gNB can connect to the Evolved Packet Core (EPC) corresponding to the LTE core network. LTE base stations can also connect to the 5GC. LTE base stations and gNBs can connect via an inter-base station interface.
[0026] The 5GC 20 includes Access and Mobility Management Functions (AMF) and User Plane Functions (UPF) 300. The AMF performs various types of mobility control for the UE 100. The AMF manages the mobility of the UE 100 by communicating with it using Non-Access Stratum (NAS) signaling. The UPF controls data transmission. The AMF and UPF are connected to the gNB 200 via the NG interface, which serves as the interface between the base station and the core network.
[0027] Figure 2 This is a diagram illustrating a configuration example of a UE 100 (User Equipment) according to an embodiment. UE 100 includes a receiver 110, a transmitter 120, and a controller 130. The receiver 110 and transmitter 120 constitute a wireless communication device that performs wireless communication with the gNB 200.
[0028] Receiver 110 performs various reception functions under the control of controller 130. Receiver 110 includes an antenna and receiving equipment. The receiving equipment converts the radio signals or terahertz wave signals received through the antenna into baseband signals (received signals) and outputs the resulting signals to controller 130.
[0029] Transmitter 120 performs various transmissions under the control of controller 130. Transmitter 120 includes an antenna and a transmitting device. The transmitting device converts the baseband signal (transmit signal) output by controller 130 into a radio signal or a terahertz wave signal, and transmits the obtained signal through the antenna.
[0030] Controller 130 performs various control and processing operations within UE 100. This processing includes the processing of various layers, which will be described later. The operation of UE 100 described above and below can be under the control of controller 230. Controller 130 includes at least one processor and at least one memory. The memory stores programs to be executed by the processor and information to be processed in the processor. The processor may include a baseband processor and a central processing unit (CPU). The baseband processor performs modulation and demodulation, encoding and decoding of baseband signals, etc. The CPU executes programs stored in the memory, thereby performing various types of processing.
[0031] Figure 3 This diagram illustrates a configuration example of gNB 200 (network node) according to an embodiment. gNB 200 includes a transmitter 210, a receiver 220, a controller 230, and a backhaul communicator 240. Transmitter 210 and receiver 220 constitute a wireless communication device for performing wireless communication with UE 100. Backhaul communicator 240 constitutes a network communicator for performing communication with CN 20.
[0032] Transmitter 210 performs various transmissions under the control of controller 230. Transmitter 210 includes an antenna and a transmitting device. The transmitting device converts the baseband signal (transmit signal) output by controller 230 into a radio signal or a terahertz wave signal, and transmits the obtained signal through the antenna.
[0033] Receiver 220 performs various types of reception under the control of controller 230. Receiver 220 includes an antenna and receiving equipment. The receiving equipment converts the radio signals or terahertz wave signals received through the antenna into baseband signals (received signals) and outputs the resulting signals to controller 230.
[0034] Controller 230 performs various types of control and processing within gNB 200. This processing includes the processing of the various layers described later. The operations of gNB 200 described above and below can also be performed under the control of controller 230. Controller 230 includes at least one processor and at least one memory. The memory stores programs to be executed by the processor and information to be used for processing within the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation and demodulation, encoding and decoding of baseband signals, etc. The CPU executes programs stored in the memory, thereby performing various types of processing.
[0035] The backhaul communicator 240 is connected to an adjacent base station via the Xn interface, which serves as an inter-base station interface. The backhaul communicator 240 is connected to the AMF / UPF 300 via the NG interface, which is the interface between the base station and the core network. Note that the gNB 200 may include a central unit (CU) and a distributed unit (DU) (i.e., functions are divided), and these two units can be connected via the F1 interface, which serves as a fronthaul interface.
[0036] Figure 4 This is a diagram illustrating the configuration of the protocol stack for the user plane radio interface that processes data.
[0037] The user plane radio interface protocol includes the physical (PHY) layer, media access control (MAC) layer, radio link control (RLC) layer, packet data convergence protocol (PDCP) layer, and service data adaptation protocol (SDAP) layer.
[0038] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the PHY layer of UE 100 and the PHY layer of gNB 200 via the physical channel. Note that the PHY layer of UE 100 receives downlink control information (DCI) transmitted from gNB 200 via the physical downlink control channel (PDCCH). Specifically, UE 100 performs blind decoding of the PDCCH using the radio network temporary identifier (RNTI) and obtains the successfully decoded DCI as the DCI addressing the UE. The DCI transmitted from gNB 200 is appended with cyclic redundancy check (CRC) bits scrambled by the RNTI.
[0039] The MAC layer performs data priority control, retransmission processing via Hybrid ARQ (HARQ: Hybrid Automatic Repeat Request), and random access procedures. Data and control information are transmitted between the MAC layer of UE 100 and the MAC layer of gNB 200 via the transport channel. The MAC layer of gNB 200 includes a scheduler. The scheduler determines the transmission format (transmission block size, modulation and coding scheme (MCS)) in the uplink and downlink, as well as the resource blocks to be assigned to UE 100.
[0040] The RLC layer transmits data to the receiving RLC layer using the functions of the MAC layer and PHY layer. Data and control information are transmitted between the RLC layer of UE 100 and the RLC layer of gNB 200 via logical channels.
[0041] The PDCP layer performs header compression / decompression, encryption / decryption, etc.
[0042] The SDAP layer performs the mapping between IP flows (acting as the Quality of Service (QoS) control unit performed by the core network) and radio bearers (acting as the QoS control unit performed by the access layer (AS)). Note that SDAP is not required when the RAN is connected to the EPC.
[0043] Figure 5 This is a diagram showing the configuration of the protocol stack of the radio interface of the control plane that processes signaling (control signals).
[0044] The protocol stack for the control plane's radio interface includes a Radio Resource Control (RRC) layer and a Non-Access Stratum (NAS) layer, rather than... Figure 4 The SDAP layer is shown.
[0045] RRC signaling for various configurations is transmitted between the RRC layer of UE 100 and the RRC layer of gNB 200. The RRC layer controls logical channels, transport channels, and physical channels based on the establishment, reconstruction, and release of radio bearers. When a connection (RRC connection) is established between the RRC of UE 100 and the RRC of gNB 200, UE 100 is in the RRC_connected state. When no connection (RRC connection) is established between the RRC of UE 100 and the RRC of gNB 200, UE 100 is in the RRC_idle state. When the connection between the RRC of UE 100 and the RRC of gNB 200 is suspended, UE 100 is in the RRC_inactive state.
[0046] The NAS layer (also simply "NAS"), located above the RRC layer, performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of UE100 and the NAS layer of AMF 300A. UE100 includes the application layer, excluding the radio interface protocol. Layers lower than the NAS layer are called AS layers (also simply "AS").
[0047] (2) Overview of MBS
[0048] Mobile communication system 1 can perform transmission with high resource efficiency by using multicast / broadcast service (MBS).
[0049] (2.1) MBS broadcasting
[0050] In the case of broadcast communication service (also known as "MBS broadcast"), the same service and the same specific content data are provided to every UE100 in the geographical area simultaneously. That is, every UE100 in the broadcast service area is allowed to receive data. The broadcast communication service is delivered to UE100 using a broadcast session (which is a type of MBS session). UE100 can receive broadcast sessions in any of the following states: RRC_idle, RRC_inactive, and RRC_connected.
[0051] Point-to-multipoint (PTM) transmission is applicable to broadcast communication services. For PTM transmission, the gNB 200 transmits a single copy of MBS packets to a group(s) of UE100. For example, the gNB 200 uses a group common PDCCH scrambled by a G-RNTI to schedule a group common PDSCH.
[0052] For broadcast communication services, UE 100 receives broadcast sessions in the following process: First, UE 100 receives System Information Block Type 20 (SIB20) from gNB 200. SIB20 includes the configuration of the Multicast Control Channel (MCCH), which is a logical channel. Second, UE 100 receives the MCCH from gNB 200 based on SIB20. The MCCH includes PTM configuration. The PTM configuration sends the configuration for the Multicast Traffic Channel (MTCH) (MTCH configuration) and the configuration for the Broadcast Multicast Radio Bearer (MRB), which is a logical channel. The broadcast MRB is the MRB used for broadcast sessions. The information sent by the MCCH can be referred to as MBS broadcast control information. Third, UE 100 receives the MTCH based on the MCCH. The MTCH sends the broadcast session (specifically, MBS data belonging to the broadcast session).
[0053] MCCH is the PTM downlink channel used to send MBS broadcast control information associated with one or more MTCHs from network 5 to UE 100. MTCH is the PTM downlink channel used to send MBS data of multicast or broadcast sessions from network 5 to UE 100.
[0054] (2.2) MBS multicast
[0055] For multicast communication services (also known as "MBS multicast"), the same service and the same specific content data are provided to a specific group of UEs simultaneously. That is, not every UE 100 in the multicast service area is allowed to receive data. Multicast communication services are delivered to UE 100 using a multicast session (which is a type of MBS session).
[0056] UE 100 can only receive multicast sessions after joining a multicast session (session joining). Joining a multicast session means that UE 100 is registered in network 5 (core network 20) to be able to receive multicast sessions.
[0057] For multicast communication services, in 3GPP Release 17, only UE 100 in the RRC_connected state could receive multicast sessions. On the other hand, in 3GPP Release 18, the specification was extended to allow UE 100 in the RRC_inactive state to also receive multicast sessions.
[0058] (2.2.1) Multicast reception in RRC_connected state
[0059] A UE 100 in the RRC_connected state can use mechanisms such as point-to-point (PTP) and / or point-to-multipoint (PTM) transmission to receive multicast sessions (specifically, MBS data belonging to the multicast session).
[0060] For multicast communication services, UE 100 in the RRC_connected state receives multicast sessions in the following process: First, UE 100 receives an RRC reconfiguration message from gNB 200. The RRC reconfiguration message is a message sent on the dedicated control channel (DCCH). The RRC reconfiguration message sends the configuration of the MTCH for multicast session reception (MTCH configuration) and the configuration of the multicast MRB as the MRB for the multicast session. Second, UE 100 receives the MTCH based on the RRC reconfiguration message. The MTCH sends the multicast session (specifically, the MBS data belonging to the multicast session).
[0061] (2.2.2) Multicast reception in RRC_inactive state
[0062] UE 100 in the RRC_inactive state can receive multicast sessions (specifically, MBS data belonging to the multicast session) by using the PTM transmission mechanism.
[0063] For multicast communication services, UE 100 in the RRC_inactive state can receive multicast sessions in the following manner: First, UE 100 in the RRC_inactive state receives the newly introduced System Information Block (also referred to as "SIBx") from gNB 200. SIBx includes the configuration of the newly introduced MCCH (also referred to as "multicast MCCH"). Second, UE 100 in the RRC_inactive state receives the multicast MCCH from gNB 200 based on SIBx. The multicast MCCH includes PTM configuration. PTM configuration sends MTCH configuration and inactive MRB configuration. The MTCH configuration is the configuration associated with the MTCH used for multicast session reception, and the inactive MRB configuration is the configuration of the inactive MRB, which is the MRB used for multicast session reception in the RRC_inactive state. The MTCH configuration can be included in the multicast MRB configuration. Third, UE 100 in the RRC_inactive state receives the MTCH based on the multicast MCCH. MTCH sends multicast sessions, specifically MBS data (i.e., multicast data) belonging to the multicast session.
[0064] When gNB 200 configures UE 100 to receive multicast sessions in RRC_inactive state, gNB 200 can send PTM configuration (multicast MRB configuration) to UE 100 using an RRC release message that includes the suspend configuration. In this case, when UE 100 receives the RRC release message including the PTM configuration from gNB 200, UE 100 transitions to RRC_inactive state and performs multicast session reception (multicast reception) in RRC_inactive state.
[0065] (2.2.3) Group notification
[0066] When there is no data to be sent to UE 100 in the active multicast session, gNB 200 can cause UE 100 to switch to the RRC_inactive state. When the multicast session is deactivated, gNB 200 can cause UE 100 to switch to the RRC_idle state or the RRC_inactive state.
[0067] When a multicast MBS session is activated by the core network (CN) 20, the MBS-enabled gNB 200 notifies the UE 100, which is in the RRC_idle or RRC_inactive state, using a group notification mechanism. When a multicast session has already been activated and the gNB 200 has multicast session data to transmit, the MBS-enabled gNB 200 can use the group notification mechanism to notify the UE 100, which is in the RRC_inactive state.
[0068] Upon receiving the group notification, UE 100 either reconnects to network 5 or restores the connection to transition to the RRC_connected state. The group notification is processed via the paging RNTI (P-RNTI) on the PDCCH, and UE 100 monitors the paging channel.
[0069] The paging message used for group notification includes a session identifier (MBS session ID) and is used to page all UE 100s that are in the RRC_idle or RRC_inactive state and have joined the associated MBS multicast session. That is, UE 100 is not paged individually.
[0070] When UE 100 transitions to the RRC_connected state, UE 100 can stop monitoring group notifications associated with a specific multicast session. That is, UE 100 stops checking the MBS session ID in paging messages. UE 100 does not monitor group notifications when UE 100 leaves the multicast session, when Network 5 requests UE 100 to leave the multicast session, or when Network 5 releases the multicast session.
[0071] Note that group notifications can be executed on the MCCH or via MCCH change notifications. When using the MCCH, this can be determined by whether an MTCH configuration for the interested MBS session exists within the MCCH. When using MCCH change notifications, the group notification can be sent in a predefined bit of the DCI.
[0072] (3) Operation of mobile communication systems
[0073] The operation of the mobile communication system 1 according to an embodiment will be described.
[0074] (3.1) Operation Overview
[0075] In MBS multicast as defined in 3GPP Release 17, the gNB 200 configures the MRB ID of the multicast MRB for UE 100, and the MRB ID manages the multicast MRB. The MRB ID is cell-specific. This multicast MRB is dedicated to the RRC_connected state, and when UE 100 is switched over, the multicast MRB, along with the MRB ID, is reconfigured by the gNB 200.
[0076] In MBS broadcasts as defined in 3GPP Release 17, gNB 200 does not configure the MRB ID for the broadcast MRB for UE 100. Assigning an MRB ID to the broadcast MRB depends on the UE implementation, and there is no MRB ID for the broadcast MRB. Therefore, UE 100 performing broadcast reception in RRC_idle or RRC_inactive state can perform cell reselection without considering the MRB ID.
[0077] On the other hand, in 3GPP Release 18 scenarios (i.e., scenarios where UE 100 in RRC_inactive state performs multicast reception), UE 100 performing multicast reception can perform cell reselection. Therefore, it can be assumed that, similar to broadcast MRBs, gNB 200 does not configure an MRB ID for UE 100 for multicast MRBs in the RRC_inactive state. When gNB 200 does not configure an MRB ID for UE 100, there is a problem that multicast MRBs cannot be managed using the MRB ID.
[0078] Figure 6 and Figure 7 This diagram illustrates a hypothetical scenario according to an embodiment. In this hypothetical scenario, after UE 100, which is already involved in a multicast session, transitions from an RRC_connected state to an RRC_inactive state in cell a, UE 100 performs cell reselection, wherein the serving cell is reselected from cell a to cell b in the RRC_inactive state, and UE 100 transitions to an RRC_connected state in cell b. In the example shown, cells a and cell b belong to different gNB 200s (gNB 200a and gNB 200b); however, cells a and cell b may belong to the same gNB 200.
[0079] exist Figure 6 In step 1 shown, UE 100 in cell a, in the RRC_connected state, has a multicast MRB configured by gNB 200a for the RRC_connected state. Specifically, gNB 200a sends an RRC reconfiguration message to UE 100, including a first MRB configuration for configuring the multicast MRB. Upon receiving the RRC reconfiguration message, UE 100 establishes the multicast MRB and receives multicast sessions (multicast data) on the MTCH using the multicast MRB. Here, it is assumed that gNB 200a configures "A" as the MRB ID of the multicast MRB.
[0080] exist Figure 6In step 2 shown, UE 100 transitions from the RRC_connected state to the RRC_inactive state in cell a. Specifically, gNB 200a sends an RRC release message (i.e., an RRC release message including a suspend configuration) to UE 100 to transition UE 100 to the RRC_inactive state. The suspend configuration may include information indicating which multicast services (multicast sessions) are available in the RRC_inactive state. Upon receiving the RRC release message, UE 100 transitions to the RRC_inactive state. The RRC release message may include a second MRB configuration for configuring the multicast MRB for the RRC_inactive state. gNB 200 can send (broadcast) the second MRB configuration for configuring the multicast MRB for the RRC_inactive state via the multicast MCCH. The second MRB configuration does not include the MRB ID of the multicast MRB.
[0081] Here, by continuing to use the multicast MRB (and the PDCP entity associated with the multicast MRB) established in the RRC_connected state in the RRC_inactive state, UE 100 can suppress multicast data reception interruptions (i.e., packet loss). By associating the multicast MRB configured in the first MRB configuration with the multicast MRB configured in the second MRB configuration, UE 100 can perform configuration changes (reconfiguration) on the multicast MRB established based on the first MRB configuration based on the second MRB configuration, and can continue to use the multicast MRB.
[0082] However, when the second MRB configuration sent in the RRC release message or multicast MCCH does not include an MRB ID, UE 100 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 a key. Therefore, there is a problem that UE 100 cannot continuously use the multicast MRB established in the RRC_connected state while in the RRC_inactive state. To solve this problem, in this embodiment, UE 100 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 (Temporary Mobile Group Identifier: TMGI) instead of the MRB ID as a key. Therefore, UE 100 can continuously use the multicast MRB established in the RRC_connected state (and the PDCP entity associated with the multicast MRB) while in the RRC_inactive state.
[0083] exist Figure 7In step 3 shown, UE 100, which is in the RRC_inactive state, performs cell reselection from cell a to cell b. Here, it is assumed that after the configuration change in step 2, UE 100 continues to use the multicast MRB established in step 1 in the RRC_inactive state and continues to receive multicast sessions in the RRC_inactive state.
[0084] exist Figure 7 In step 4, UE 100 initiates the RRC connection recovery process in cell b and transitions to the RRC_connected state. Specifically, the RRC connection recovery process is completed by UE 100 sending an RRC recovery request message to gNB 200b, gNB 200b sending an RRC recovery message to UE 100, and UE 100 sending an RRC recovery completion message to gNB 200b, and UE 100 transitions to the RRC_connected state. gNB 200b then sends an RRC reconfiguration message to UE 100, including a third MRB configuration for configuring the multicast MRB for the RRC_connected state. Here, it is assumed that gNB 200a configures "B" as the MRB ID of the multicast MRB.
[0085] Here, by continuing to use the multicast MRB (and the PDCP entity associated with the multicast MRB) that UE 100 has already used in the RRC_inactive state in the RRC_connected state, UE 100 can suppress multicast data reception interruptions (i.e., packet loss). By associating the multicast MRB configured in the second MRB configuration with the multicast MRB configured in the third MRB configuration, UE 100 can perform configuration changes (reconfiguration) on the multicast MRB that is currently in use based on the third MRB configuration, and can continue to use the multicast MRB.
[0086] However, when there is no MRB ID for the multicast MRB already used by UE 100 in the RRC_inactive state, UE 100 cannot associate the multicast MRB used in the RRC_inactive state with the multicast MRB configured in the third MRB configuration by using the MRB ID as a key. Therefore, there is a problem that UE 100 cannot continuously use the multicast MRB used in the RRC_inactive state in the RRC_connected state. To solve this problem, in this embodiment, UE 100 associates the multicast MRB used in the RRC_inactive state with the multicast MRB configured in the third MRB configuration by using the MBS session ID instead of the MRB ID as a key. Therefore, UE 100 can continuously use the multicast MRB used in the RRC_inactive state (and the PDCP entity associated with the multicast MRB) in the RRC_connected state. Additionally, UE 100 can apply the MRB ID "B" configured in the third MRB configuration to the multicast MRB.
[0087] As described above, in this embodiment, UE 100 performs a configuration handover (partial handover) between the multicast MRB for the RRC_connected state and the MRB for the RRC_inactive state by using the MBS session ID instead of the MRB ID. This allows for MRB configuration handover even if gNB 200 does not configure an MRB ID for the multicast MRB for the RRC_inactive state for UE 100. Furthermore, since the PDCP entity associated with the multicast MRB can be maintained without resetting it, the continuity of multicast services can be improved.
[0088] (3.2) Example of operation when transitioning from RRC_connected state to RRC_inactive state
[0089] Figure 8 This is a diagram illustrating a first operational example of UE 100 according to an embodiment. Specifically, the first operational example is an operational example when transitioning from the RRC_connected state to the RRC_inactive state.
[0090] In step S11, UE 100 establishes a multicast MRB based on the first MRB configuration configured by network 5 (gNB 200) in the RRC_connected state. Specifically, UE 100 establishes the multicast MRB and the corresponding PDCP entity and RLC entity by receiving the first MRB configuration from network 5 (gNB 200) in the RRC reconfiguration message. The first MRB configuration is used to configure information for the multicast MRB in the RRC_connected state and includes a first MBS session ID and an MRB ID (e.g., MRB ID=A). The RRC reconfiguration message may include multiple first MRB configurations corresponding to multiple multicast MRBs.
[0091] In step S12, UE 100 receives a multicast session from network 5 (gNB 200) corresponding to the first MBS session ID included in the first MRB configuration by using the multicast MRB established in step S11. UE 100 receives the multicast session data (multicast data) on the MTCH.
[0092] In step S13, UE 100 receives a second MRB configuration from network 5 (gNB 200). This second MRB configuration is used to configure information for multicast MRBs in the RRC_inactive state and includes a second MBS session ID. Specifically, UE 100 receives the second MRB configuration, which includes the second MBS session ID but not the MRB ID, via a multicast MCCH or RRC release message. The multicast MCCH or RRC release message may include multiple second MRB configurations corresponding to multiple multicast MRBs.
[0093] In step S14, when the second MBS session ID included in the second MRB configuration matches the first MBS session ID included in the first MRB configuration, UE 100 performs configuration changes on the multicast MRB established by the first MRB configuration based on the second MRB configuration. When 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, UE 100 identifies the configuration for the multicast MRB (specifically, the first MRB configuration and the second MRB configuration with the same MBS session ID). By using these two identified MRB configurations, UE 100 performs configuration changes on the multicast MRB for the RRC_connected state. UE 100 performs configuration changes while maintaining the PDCP entity associated with the multicast MRB.
[0094] For example, UE 100 performs at least one of the following operations 1) to 5) by comparing the two identified MRB configurations (the first MRB configuration and the second MRB configuration with the same MBS session ID).
[0095] 1) UE 100 may choose not to retain the MRB ID configured by the RRC reconfiguration message (first MRB configuration). UE 100 may discard the MRB ID configured by the RRC reconfiguration message (first MRB configuration). Alternatively, UE 100 may retain the MRB ID configured by the RRC reconfiguration message (first MRB configuration).
[0096] 2) UE 100 replaces the PDCP configuration configured by the RRC reconfiguration message (first MRB configuration) with the second MRB configuration. However, UE 100 maintains the PDCP entity and PDCP count without resetting them. The PDCP count value consists of the superframe number (HFN) and the PDCP sequence number (SN). The PDCP-SN increments in response to received PDCP packets. The HFN increments each time the PDCP-SN is cycled. On the other hand, the receiving-side PDCP entity performs processing in the PDCP layer using the PDCP count. By maintaining the PDCP entity and PDCP count, the continuity of multicast reception can be improved.
[0097] 3) When a point-to-point (PTP) tributary of the multicast MRB has been configured for the RRC reconfiguration message (first MRB configuration), the UE 100 discards or suspends the configuration of that PTP tributary.
[0098] 4) When the multicast MRB configuration point-to-multipoint (PTM) tributary has already been configured for the RRC reconfiguration message (first MRB configuration), UE 100 changes the configuration of that PTM tributary to the multicast MRB configuration for the RRC_inactive state (second MRB configuration). UE 100 also changes the group DRX configuration to the multicast MRB configuration for the RRC_inactive state. When UE 100 changes the RLC configuration, it can perform an RLC entity reset.
[0099] 5) When the PTM tributary has not been configured in the RRC reconfiguration message (first MRB configuration), UE 100 applies PTM reception (multicast reception) by using the multicast MRB configuration for the RRC_inactive state.
[0100] In step S15, after transitioning to the RRC_inactive state, UE 100 continues to receive multicast sessions by using the multicast MRB after the configuration change in step S14.
[0101] (3.3) Example of operation when transitioning from RRC_inactive state to RRC_connected state
[0102] Figure 9 This diagram illustrates a second operation example of UE 100 according to an embodiment. Specifically, the second operation example is an operation example when transitioning from the RRC_inactive state to the RRC_connected state. The second operation example may be an operation performed after the operation of the first operation example.
[0103] In step S21, UE 100, which is in the RRC_inactive state, receives a multicast session from network 5 (gNB 200) using a multicast MRB configured based on the second MRB for the RRC_inactive state (specifically, a multicast MRB for the RRC_inactive state). UE 100 receives multicast session data (multicast data) on the MTCH.
[0104] In step S22, after UE 100 transitions from the RRC_inactive state to the RRC_connected state via RRC connection recovery, UE 100 receives a third MRB configuration from network 5 (gNB 200). This third MRB configuration is used to configure multicast MRBs for the RRC_connected state and includes a third MBS session ID. UE 100 in the RRC_connected state receives the multicast MRB configuration for the RRC_connected state via an RRC reconfiguration message. Specifically, in the RRC_connected state, UE 100 receives a third MRB configuration from network 5 (gNB 200) in an RRC reconfiguration message, including the third MBS session ID and MRB ID (e.g., MRB ID=B). The RRC reconfiguration message may include multiple third MRB configurations corresponding to multiple multicast MRBs.
[0105] In step S23, when the third MBS session ID received by the RRC reconfiguration message matches the second MBS session ID corresponding to the multicast MRB in use, the UE 100 in the RRC_connected state performs configuration changes related to the multicast MRB based on the third MRB configuration. When 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 UE 100 identifies the configuration for the multicast MRB (specifically, the second MRB configuration and the third MRB configuration with the same MBS session ID). By using these two identified MRB configurations, the UE 100 performs configuration changes for the multicast MRB for the RRC_inactive state. The UE 100 performs configuration changes while maintaining the PDCP entity associated with the multicast MRB. The UE 100 assigns the MRB ID included in the identified third MRB configuration to the multicast MRB.
[0106] For example, UE 100 performs at least one of the following operations 1) to 4) by comparing the two identified MRB configurations.
[0107] 1) UE 100 identifies the MRB ID configured in the RRC reconfiguration message (third MRB configuration) and applies (maintains) the identified MRB ID as the configuration for multicast MRB.
[0108] 2) UE 100 replaces the PDCP configuration configured by the second MRB configuration for the RRC_inactive state with the PDCP configuration configured by the RRC reconfiguration message (third MRB configuration). However, UE 100 retains the PDCP entity and PDCP count corresponding to the multicast MRB without resetting them.
[0109] 3) When a PTP tributary has been configured in the RRC reconfiguration message (third MRB configuration), UE 100 applies or restores the configuration of that PTP tributary.
[0110] 4) When a PTM tributary is already configured in the RRC reconfiguration message (third MRB configuration), UE 100 changes the configuration of that PTM tributary to the multicast MRB configuration (third MRB configuration) for the RRC_connected state. UE 100 also changes the group DRX configuration to the multicast MRB configuration for the RRC_connected state. When the RLC configuration is changed, UE 100 can perform an RLC entity reset.
[0111] In step S24, UE 100 in the RRC_connected state continues to receive multicast sessions using the multicast MRB after the configuration change in step S23.
[0112] (4) Other embodiments
[0113] Although the above embodiments primarily describe multicast reception in the RRC_inactive state, the operations described in the above embodiments also apply to multicast reception in the RRC_idle state. For the RRC_idle state, the aforementioned RRC Resume can be read as RRC Establishment.
[0114] The above operational procedures can be implemented separately and independently, or they can be implemented as a combination of two or more operational procedures. For example, some steps in one operational procedure can be added to another, or some steps in one operational procedure can be replaced by some steps in another. In each procedure, not all steps are required to be executed; only some steps may be executed. The order of steps in each procedure can be modified appropriately.
[0115] Although an example of an NR base station (gNB) has been described in the above embodiments and examples, the base station can be an LTE base station (eNB) or a 6G base station. The base station can be a relay node, such as an Integrated Access and Backhaul (IAB) node. The base station can be a DU of an IAB node. UE 100 can be a mobile terminal (MT) of an IAB node.
[0116] That is, UE 100 can be a terminal functional unit (a type of communication module) used by the base station to control repeaters that perform signal relay. Such a terminal functional unit is called MT. In addition to IAB-MT, examples of MT include Network Control Repeater (NCR)-MT and Reconfigurable Smart Surface (RIS)-MT.
[0117] The term "network node" primarily refers to a base station, but can also refer to core network equipment or a portion of a base station (CU, DU, or RU). A network node can include a combination of at least a portion of core network equipment and at least a portion of a base station.
[0118] A program may be provided that enables a computer to perform each process executed by UE 100 or gNB 200. The program may be recorded on a computer-readable medium. The computer-readable medium allows the program to be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not specifically limited and may, for example, be a recording medium such as a CD-ROM or DVD-ROM. Circuitry for performing the processes to be executed by UE 100 or gNB 200 may be integrated, and at least a portion of UE 100 or gNB 200 may be implemented as a semiconductor integrated circuit (chipset, system-on-chip (SoC)).
[0119] The functions implemented by UE 100 and gNB 200 (network nodes) can be implemented in circuitry or processing circuitry programmed to perform the functions, including general-purpose processors, application-specific processors, integrated circuits, application-specific integrated circuits (ASICs), central processing units (CPUs), conventional circuitry, and / or combinations thereof. A processor may include transistors and other circuitry and may be considered as a circuit or processing circuitry. A processor may be a programmed processor that executes a program stored in memory. As used herein, a circuit, unit, or device is hardware programmed to implement the functions or hardware that performs the functions. The hardware may be any hardware disclosed herein or any hardware programmed to implement the functions or any hardware known to perform the functions. When the hardware is a processor considered as a type of circuit, the circuit, device, or unit is a combination of the hardware and software used to configure the hardware and / or the processor.
[0120] Unless otherwise expressly stated, the phrases “based on” and “depending on / in response to” as used in this disclosure do not mean “based on only” and “depending on only / in response to”. The phrase “based on” means “based on only” and “at least partially based on” both. The phrase “depending on” means “depending on only” and “at least partially dependent on” both. The terms “comprising,” “including,” and variations thereof do not mean that only the listed items are included, but rather that only the listed items may be included, or additional items may be included in addition to the listed items. The term “or” as used in this disclosure is not intended to be “exclusive or.” Any reference to elements in this disclosure using names such as “first” and “second” does not generally limit the number or order of those elements. These names may be used herein as a convenient way to distinguish two or more elements. Therefore, a reference to a first element and a second element does not imply that only the two elements may be used there or that the first element needs to precede the second element in some way. For example, when English articles such as “a,” “one,” and “the” are added in this disclosure by translation, these articles include plural unless the context clearly indicates otherwise.
[0121] The embodiments have been described in detail above with reference to the accompanying drawings, but the specific configurations are not limited to those described above, and various design changes can be made without departing from the spirit of this disclosure.
[0122] This application claims priority to Japanese Patent Application No. 2023-164162 (filed on September 27, 2023), the entire contents of which are incorporated herein by reference.
[0123] (5) Supplement
[0124] The features related to the above embodiments are described below as supplementary notes.
[0125] (Supplementary Note 1)
[0126] A communication method performed by a user equipment in a mobile communication system for providing multicast broadcast service (MBS), the communication method comprising the following steps:
[0127] In RRC connection state, a multicast MRB is established based on the first multicast radio bearer MRB configuration configured from the network;
[0128] By 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.
[0129] Receive a second MRB configuration from the network, the second MRB configuration being information for configuring a multicast MRB for the RRC_inactive state and including a second MBS session ID; and
[0130] When the second MBS session ID matches the first MBS session ID, configuration changes related to the established multicast MRB are performed based on the second MRB configuration.
[0131] (Supplementary Note 2)
[0132] According to the communication method described in Supplementary Note 1, performing the configuration change includes performing the configuration change while maintaining the PDCP entity associated with the multicast MRB.
[0133] (Supplementary Note 3)
[0134] The communication method according to Supplementary Note 1 or 2 further includes: in the RRC_connected state, receiving the first MRB configuration from the network in an RRC reconfiguration message, the first MRB configuration being information for configuring a multicast MRB for the RRC_connected state and including the first MBS session ID and MRB ID.
[0135] (Supplementary Note 4)
[0136] According to any one of Supplementary Notes 1 to 3, the communication method wherein receiving the second MRB configuration includes: receiving a second MRB configuration including the second MBS session ID but not the MRB ID in a multicast MCCH or RRC release message.
[0137] (Supplementary Note 5)
[0138] The communication method according to any one of Supplementary Notes 1 to 4 further includes: after transitioning to the RRC_inactive state, continuing to receive the multicast session by using the multicast MRB after the configuration change.
[0139] (Supplementary Note 6)
[0140] The communication method according to any one of Supplementary Notes 1 to 5 further includes the following steps:
[0141] After transitioning from the RRC_inactive state to the RRC_connected state, a third MRB configuration is received from the network. This third MRB configuration is information for configuring a multicast MRB for the RRC_connected state and includes a third MBS session ID; and
[0142] When the third MBS session ID matches the second MBS session ID, configuration changes related to the multicast MRB are performed based on the third MRB configuration.
[0143] (Supplementary Note 7)
[0144] The communication method described in Supplementary Note 6 further includes: after transitioning to the RRC_connected state, continuing to receive the multicast session by using the multicast MRB after the configuration change.
[0145] (Supplementary Note 8)
[0146] According to the communication method described in Supplementary Note 6 or 7, performing the configuration change based on the third MRB configuration includes performing the configuration change while maintaining the PDCP entity associated with the multicast MRB.
[0147] (Supplementary Note 9)
[0148] The communication method according to any one of Supplementary Notes 6 to 8 further includes: in the RRC_connected state, receiving a third MRB configuration including the third MBS session ID and MRB ID from the network in an RRC reconfiguration message.
[0149] (Supplementary Note 10)
[0150] According to the communication method described in Supplementary Note 9, performing the configuration change based on the third MRB configuration includes: assigning an MRB ID included in the third MRB configuration to the multicast MRB.
[0151] (Supplementary Note 11)
[0152] A user equipment for use in a mobile communication system for providing multicast broadcast service (MBS), the user equipment comprising:
[0153] The controller is configured to perform the following processing:
[0154] In RRC connection state, a multicast MRB is established based on the first multicast radio bearer MRB configuration configured from the network;
[0155] By 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.
[0156] Receive a second MRB configuration from the network, the second MRB configuration being information for configuring a multicast MRB for the RRC_inactive state and including a second MBS session ID; and
[0157] When the second MBS session ID matches the first MBS session ID, configuration changes related to the established multicast MRB are performed based on the second MRB configuration.
[0158] Figure Labels
[0159] 1: Mobile communication system
[0160] 5: Network
[0161] 10: RAN
[0162] 20:CN
[0163] 100: User Equipment (UE)
[0164] 110: Receiver
[0165] 120: Transmitter
[0166] 130: Controller
[0167] 200: gNB (base station)
[0168] 210: Transmitter
[0169] 220: Receiver
[0170] 230: Controller
[0171] 240: Backhaul communicator.
Claims
1. A communication method performed by a user equipment in a mobile communication system for providing multicast broadcast service (MBS), the communication method comprising the following steps: In the RRC_connected state, a multicast MRB is established based on the multicast radio bearer MRB configuration configured from the network. By 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. Receive multicast configuration from the network, the multicast configuration being information for configuring multicast reception for the RRC_inactive state and including a second MBS session ID; as well as When a multicast session corresponding to the second MBS session ID is received in the RRC_inactive state in the same cell as the cell that has already received a multicast session corresponding to the first MBS session ID in the RRC_connected state, the multicast configuration is applied.
2. The communication method according to claim 1 further includes the following steps: The multicast MRB and the PDCP entity associated with the multicast MRB are maintained in the RRC_inactive state; as well as The multicast session is received using the multicast MRB in the RRC_inactive state.
3. The communication method according to claim 1 further includes: In the RRC_connected state, the MRB configuration is received from the network in the RRC reconfiguration message. The MRB configuration is information for configuring the multicast MRB for the RRC_connected state and includes the first MBS session ID and the MRB ID.
4. The communication method according to claim 1, wherein, Receiving the multicast configuration includes receiving a multicast configuration in an RRC release message that includes the second MBS session ID but does not include the MRB ID.
5. A communication method performed by a user equipment in a mobile communication system for providing multicast broadcast service (MBS), the communication method comprising the following steps: In the RRC_connected state, a multicast MRB is established based on the first multicast radio bearer MRB configuration from the network configuration; By 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. Receive a second MRB configuration from the network, the second MRB configuration being used to configure information for a multicast MRB for the RRC_inactive state and including a second MBS session ID; as well as When the second MBS session ID matches the first MBS session ID, configuration changes related to the established multicast MRB are performed based on the second MRB configuration.
6. The communication method according to claim 5, wherein, Performing the configuration change includes performing the configuration change while maintaining the PDCP entity associated with the multicast MRB.
7. The communication method according to claim 5 further includes: In the RRC_connected state, the first MRB configuration is received from the network in the RRC reconfiguration message. The first MRB configuration is information for configuring the multicast MRB for the RRC_connected state and includes the first MBS session ID and MRB ID.
8. The communication method according to claim 5, wherein, Receiving the second MRB configuration includes receiving a second MRB configuration that includes the second MBS session ID but does not include the MRB ID in a multicast MCCH or RRC release message.
9. The communication method according to claim 5, further comprising: After transitioning to the RRC_inactive state, the multicast session continues to be received by using the multicast MRB following the configuration change.
10. The communication method according to claim 5 further includes the following steps: After transitioning from the RRC_inactive state to the RRC_connected state, a third MRB configuration is received from the network. The third MRB configuration is used to configure information for the multicast MRB for the RRC_connected state and includes a third MBS session ID. as well as When the third MBS session ID matches the second MBS session ID, configuration changes related to the multicast MRB are performed based on the third MRB configuration.
11. The communication method according to claim 10, further comprising: After transitioning to the RRC_connected state, the multicast session continues to be received by using the multicast MRB following the configuration change.
12. The communication method according to claim 10, wherein, Performing the configuration change based on the third MRB configuration includes performing the configuration change while maintaining the PDCP entity associated with the multicast MRB.
13. The communication method according to claim 10, further comprising: In the RRC_connected state, a third MRB configuration, including the third MBS session ID and MRB ID, is received from the network in the RRC reconfiguration message.
14. The communication method according to claim 13, wherein, Performing the configuration change based on the third MRB configuration includes: assigning the MRB ID included in the third MRB configuration to the multicast MRB.
15. A user equipment for use in a mobile communication system for providing multicast broadcast service (MBS), the user equipment comprising: The controller is configured to perform the following processing: In the RRC_connected state, a multicast MRB is established based on the first multicast radio bearer MRB configuration from the network configuration; By 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. Receive a second MRB configuration from the network, the second MRB configuration being used to configure information for a multicast MRB for the RRC_inactive state and including a second MBS session ID; as well as When the second MBS session ID matches the first MBS session ID, configuration changes related to the established multicast MRB are performed based on the second MRB configuration.