User equipment

Abstract

To provide user equipment (UE) that enables an improved multicast broadcast service (MBS).SOLUTION: In a mobile communication system, user equipment UE includes a receiving unit that receives an MBS session from a first cell C1 when the user equipment UE is in a radio resource control (RRC) connected state with respect to the first cell, and the user equipment receives from the first cell an RRC reconfiguration message instructing a handover to a second cell C2, and receives the MBS session from the second cell after the handover. The RRC reconfiguration message includes an MBS reception setting for receiving the MBS session provided by the second cell.SELECTED DRAWING: Figure 17

Description

[Technical Field]

[0001] The present disclosure relates to user equipment for use in mobile communication systems. [Background technology]

[0002] The 3GPP (3rd Generation Partnership Project) (registered trademark; hereinafter the same) standard defines the technical specifications for NR (New Radio), a fifth-generation (5G) radio access technology. Compared to LTE (Long Term Evolution), a fourth-generation (4G) radio access technology, NR features high speed, large capacity, high reliability, and low latency. Discussions are underway within 3GPP to formulate technical specifications for 5G / NR multicast broadcast services (MBS) (see, for example, Non-Patent Document 1). [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] 3GPP contribution: RP-201038, “WID revision: NR Multicast and Broadcast Services” Summary of the Invention

[0004] It is expected that 5G / NR multicast broadcast services will provide improved services compared to 4G / LTE multicast broadcast services.

[0005] Therefore, an object of the present disclosure is to provide a communication method that enables an improved multicast broadcast service to be realized.

[0006] A communication method according to a first aspect is a communication method used in a mobile communication system supporting a multicast broadcast service (MBS), and includes the steps of: a base station managing a first cell setting up a multicast radio bearer (MRB) having a PTM (Point-to-Multipoint) communication path for a user equipment in a radio resource control (RRC) connected state; the base station switching from the PTM communication path to a PTP (Point-to-Point) communication path in response to a decision to hand over the user equipment from the first cell to a second cell; and the base station executing the handover after switching to the PTP communication path.

[0007] A communication method according to a second aspect is a communication method used in a mobile communication system supporting a multicast broadcast service (MBS), and includes the steps of: a user equipment in a radio resource control (RRC) connected state in a first cell receiving an MBS session provided by the first cell in a point-to-multipoint (PTM) manner; the user equipment receiving, from the first cell, SFN-related information regarding a single frequency network (SFN) that the first cell forms with a second cell; and the user equipment continuing to receive the MBS session provided by the SFN in a PTM manner based on the SFN-related information, even if the user equipment receives from the first cell a handover command instructing a handover to the second cell.

[0008] A communication method according to a third aspect is a communication method used in a mobile communication system that supports a multicast broadcast service (MBS), and includes the steps of: a user equipment in a radio resource control (RRC) connected state in a first cell receiving an MBS session provided by the first cell in a point-to-multipoint (PTM) manner; and a step of the user equipment simultaneously receiving both the MBS session provided by the first cell and the MBS session provided by the second cell within a predetermined time before and / or within a predetermined time after a handover to a second cell that provides the MBS session in a PTM manner.

[0009] A communication method according to a fourth aspect is a communication method used in a mobile communication system supporting a multicast broadcast service (MBS), and includes the steps of: a user equipment (UE) in a radio resource control (RRC) connected state in a first cell receiving an MBS session provided by the first cell via PTM (Point-to-Multipoint), the user equipment receiving a handover command from the first cell instructing a handover to a second cell, and the user equipment receiving the MBS session provided by the second cell after the handover, wherein the handover command includes multicast traffic channel (MTCH) configuration information for receiving the MBS session provided by the second cell.

[0010] A communication method according to a fifth aspect is a communication method used in a mobile communication system supporting a Multicast Broadcast Service (MBS), comprising the steps of: a user equipment (UE) in a Radio Resource Control (RRC) Connected state in a first cell receiving an MBS session provided by the first cell via Point-to-Multipoint (PTM) communication; and, after handover to a second cell providing the MBS session, receiving, by the user equipment (UE), two MBS data streams belonging to the MBS session from the second cell, where the two MBS data streams have different sequence numbers at the same time.

[0011] A communication method according to a sixth aspect is a communication method used in a mobile communication system that supports a multicast broadcast service (MBS), and includes the steps of: a first base station providing an MBS session transmitting sequence number information indicating a sequence number of MBS data being transmitted in the MBS session to a second base station; and the second base station controlling the provision of the MBS session at the second base station based on the sequence number information from the first base station. [Brief explanation of the drawings]

[0012] [Figure 1] 1 is a diagram illustrating a configuration of a mobile communication system according to an embodiment. [Figure 2] 1 is a diagram illustrating a configuration of a UE (user equipment) according to an embodiment. [Figure 3] A diagram showing the configuration of a gNB (base station) according to an embodiment. [Figure 4] FIG. 10 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data. [Figure 5] FIG. 1 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals). [Figure 6] FIG. 1 is a diagram illustrating an overview of MBS traffic distribution according to an embodiment. [Figure 7] FIG. 10 is a diagram illustrating a distribution mode according to the embodiment. [Figure 8] FIG. 1 is a diagram illustrating a split multicast radio bearer (MRB) according to an embodiment. [Figure 9] FIG. 2 is a diagram showing the operation of a PDCP layer in the mobile communication system according to the embodiment. [Figure 10] FIG. 10 is a diagram showing COUNT values. [Figure 11] FIG. 1 is a diagram illustrating a PDCP data PDU. [Figure 12] FIG. 10 is a diagram illustrating an operation for identifying an RCVD_COUNT. [Figure 13] A diagram showing the operation of a receiving PDCP entity of a UE. [Figure 14] FIG. 2 is a diagram showing a first operation scenario of the mobile communication system according to the embodiment. [Figure 15] FIG. 10 is a diagram showing a second operation scenario of the mobile communication system according to the embodiment. [Figure 16] A diagram showing the operation of a gNB according to the first embodiment. [Figure 17] FIG. 2 is a diagram illustrating an example of an operation of the mobile communication system according to the first embodiment. [Figure 18] FIG. 10 is a diagram showing another example of the operation of the mobile communication system according to the first embodiment. [Figure 19] FIG. 10 is a diagram illustrating the operation of the UE according to the second embodiment. [Figure 20] FIG. 10 is a diagram illustrating an example of the operation of the mobile communication system according to the second embodiment. [Figure 21] FIG. 10 is a diagram showing another example of the operation of the mobile communication system according to the second embodiment. [Figure 22] FIG. 10 is a diagram illustrating the operation of a UE according to the third embodiment. [Figure 23] FIG. 10 is a diagram illustrating an example of the operation of the mobile communication system according to the third embodiment. [Figure 24] FIG. 10 is a diagram showing another example of the operation of the mobile communication system according to the third embodiment. [Figure 25] FIG. 10 is a diagram illustrating the operation of the UE according to the fourth embodiment. [Figure 26] FIG. 10 is a diagram illustrating an example of the operation of the mobile communication system according to the fourth embodiment. [Figure 27] FIG. 11 is a diagram illustrating the operation of the UE according to the fifth embodiment. [Figure 28] FIG. 11 is a diagram illustrating an example of the operation of the mobile communication system according to the fifth embodiment. [Figure 29] FIG. 13 is a diagram showing the operation of the mobile communication system according to the sixth embodiment. [Figure 30] A diagram showing PDCP-fixed PTM / PTP switching based on the current agreement. DETAILED DESCRIPTION OF THE INVENTION

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

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

[0015] The mobile communication system 1 includes a user equipment (UE) 100, a 5G radio access network (NG-RAN) 10, and a 5G core network (5GC) 20. Hereinafter, the NG-RAN 10 may be simply referred to as the RAN 10. The 5GC 20 may be simply referred to as the core network (CN) 20.

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

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

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

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

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

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

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

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

[0024] 3 is a diagram showing the configuration of the gNB200 (base station) according to the first embodiment. The gNB200 includes a transmitter 210, a receiver 220, a controller 230, and a backhaul communication unit 240. The transmitter 210 and the receiver 220 constitute a wireless communication unit that performs wireless communication with the UE 100. The backhaul communication unit 240 constitutes a network communication unit that performs communication with the CN20.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0040] (MBS Overview) An overview of the MBS according to the first embodiment will be described. The MBS is a service that enables broadcast or multicast, i.e., point-to-multipoint (PTM) data transmission from the NG-RAN 10 to the UE 100. Possible use cases (service types) of the MBS include public safety communications, mission-critical communications, V2X (Vehicle to Everything) communications, IPv4 or IPv6 multicast distribution, IPTV (Internet protocol television), group communications, and software distribution.

[0041] The broadcast service is for applications that do not require highly reliable QoS, and provides service to all UEs 100 within a specific service area. An MBS session used for the broadcast service is called a broadcast session.

[0042] A multicast service provides a service not to all UEs 100 but to a group of UEs 100 participating in the multicast service (multicast session). An MBS session used for a multicast service is called a multicast session. A multicast service can provide the same content to a group of UEs 100 in a more wirelessly efficient manner than a broadcast service.

[0043] FIG. 6 is a diagram showing an outline of MBS traffic distribution according to the first embodiment.

[0044] MBS traffic (MBS data) is distributed from a single data source (application service provider) to multiple UEs. A 5G core network (5GC) 20 receives the MBS data from the application service provider, creates a copy of the MBS data (replication), and distributes it.

[0045] From the 5GC20 perspective, two multicast delivery methods are possible: 5GC Shared MBS Traffic delivery and 5GC Individual MBS Traffic delivery.

[0046] In the 5GC individual MBS traffic delivery method, the 5GC 20 receives a single copy of MBS data packets and delivers individual copies of those MBS data packets to individual UEs 100 via a PDU session for each UE 100. Therefore, one PDU session for each UE 100 needs to be associated with the multicast session.

[0047] In the 5GC shared MBS traffic delivery method, the 5GC 20 receives a single copy of MBS data packets and delivers the single copy of those MBS packets to a RAN node (i.e., the gNB 200). The gNB 200 receives the MBS data packets via an MBS tunnel connection and delivers them to one or more UEs 100.

[0048] From the perspective of the RAN (5G RAN) 10, there are two possible delivery methods for transmitting MBS data over the air in the 5GC shared MBS traffic delivery method: PTP (Point-to-Point) and PTM (Point-to-Multipoint). PTP stands for unicast, and PTM stands for multicast and broadcast.

[0049] In the PTP distribution method, the gNB 200 distributes individual copies of the MBS data packet wirelessly to each UE 100. On the other hand, in the PTM distribution method, the gNB 200 distributes a single copy of the MBS data packet wirelessly to a group of UEs 100. The gNB 200 can dynamically determine whether to use PTM or PTP as the distribution method for MBS data for one UE 100.

[0050] The PTP distribution method and the PTM distribution method are mainly related to the user plane. There are two control modes for MBS data distribution: a first distribution mode and a second distribution mode.

[0051] FIG. 7 is a diagram showing distribution modes according to the first embodiment.

[0052] The first delivery mode (Delivery mode 1: DM1) is a delivery mode that can be used by the UE 100 in the RRC connected state and is a delivery mode for high QoS requirements. The first delivery mode is used for a multicast session among MBS sessions. However, the first delivery mode may also be used for a broadcast session. The first delivery mode may also be available to the UE 100 in the RRC idle state or the RRC inactive state.

[0053] The setting of MBS reception in the first distribution mode is performed by UE-dedicated signaling. For example, the setting of MBS reception in the first distribution mode is performed by an RRC Reconfiguration message (or an RRC Release message), which is an RRC message transmitted by unicast from the gNB 200 to the UE 100.

[0054] The MBS reception configuration includes MBS traffic channel configuration information (hereinafter referred to as "MTCH configuration information") related to the configuration of an MBS traffic channel carrying MBS data. The MTCH configuration information includes MBS session information related to an MBS session and scheduling information for the MBS traffic channel corresponding to this MBS session. The scheduling information for the MBS traffic channel may include a discontinuous reception (DRX) configuration for the MBS traffic channel. The discontinuous reception configuration may include one or more parameters: a timer value (On Duration Timer) defining an on-duration (on duration), a timer value (Inactivity Timer) extending the on-duration, a scheduling interval or DRX cycle (Scheduling Period, DRX Cycle), a start subframe offset value (Start Offset, DRX Cycle Offset) for the scheduling or DRX cycle, a start delay slot value (Slot Offset) for the on-duration timer, a timer value (Retransmission Timer) defining the maximum time until retransmission, and a timer value (HARQ RTT Timer) defining the minimum interval until DL allocation for HARQ retransmission.

[0055] The MBS traffic channel is a type of logical channel and is sometimes referred to as an MTCH. The MBS traffic channel is mapped to a Down Link Shared Channel (DL-SCH), which is a type of transport channel.

[0056] The second delivery mode (Delivery mode 2: DM2) is a delivery mode that can be used not only by the UE 100 in the RRC connected state but also by the UE 100 in the RRC idle state or the RRC inactive state, and is a delivery mode for low QoS requirements. The second delivery mode is used for a broadcast session among MBS sessions. However, the second delivery mode may also be applicable to a multicast session.

[0057] The setting of MBS reception in the second distribution mode is performed by broadcast signaling. For example, the setting of MBS reception in the second distribution mode is performed by a logical channel broadcast from the gNB 200 to the UE 100, such as a broadcast control channel (BCCH) and / or a multicast control channel (MCCH). The UE 100 can receive the BCCH and the MCCH using, for example, a dedicated RNTI predefined in a technical specification. The RNTI for BCCH reception may be SI-RNTI, and the RNTI for MCCH reception may be MCCH-RNTI.

[0058] In the second distribution mode, UE100 may receive MBS data in the following three procedures. First, UE100 receives MCCH configuration information from gNB200 via a SIB (MBS-SIB) transmitted on a BCCH. Second, UE100 receives an MCCH from gNB200 based on the MCCH configuration information. The MCCH transmits the MTCH configuration information. Third, UE100 receives an MTCH (MBS data) based on the MTCH configuration information. Hereinafter, MTCH configuration information and / or MCCH configuration information may be referred to as MBS reception configuration.

[0059] In the first distribution mode and the second distribution mode, the UE 100 may receive the MTCH using a group RNTI (G-RNTI) assigned by the gNB 200. The G-RNTI corresponds to an RNTI for MTCH reception. The G-RNTI may be included in the MBS reception configuration (MTCH configuration information).

[0060] The network can provide different MBS services for each MBS session. An MBS session is identified by at least one of a Temporary Mobile Group Identity (TMGI), a source-specific IP multicast address (consisting of a source unicast IP address of an application function, application server, etc., and an IP multicast address indicating the destination address), a session identifier, and a G-RNTI. At least one of the TMGI, G-RNTI, source-specific IP multicast address, and session identifier is called an MBS session identifier. The TMGI, source-specific IP multicast address, session identifier, and G-RNTI are collectively called MBS session information.

[0061] 8 is a diagram illustrating a split multicast radio bearer (MRB) according to the first embodiment. The MRB may be a type of data radio bearer (DRB). The split MRB may be used in the first delivery mode described above.

[0062] The gNB200 can configure the UE100 with an MRB separated into a PTP communication path and a PTM communication path. This allows the gNB200 to dynamically switch the transmission of MBS data to the UE100 between PTP (PTP communication path) and PTM (PTM communication path). Alternatively, the gNB200 can improve reliability by dual-transmitting the same MBS data using both PTP (PTP communication path) and PTM (PTM communication path). Hereinafter, the PTP communication path will be referred to as a PTP leg, and the PTM communication path will be referred to as a PTM leg. Furthermore, the functional units corresponding to each layer will be referred to as entities.

[0063] The predetermined layer that terminates splitting is the MAC layer (HARQ), the RLC layer, the PDCP layer, or the SDAP layer. In the following, an example in which the predetermined layer that terminates splitting is the PDCP layer will be mainly described, but the predetermined layer may be the MAC layer (HARQ), the RLC layer, or the SDAP layer.

[0064] The PDCP entity of the gNB 200 and the PDCP entity of the UE 100 each separate an MRB, which is a bearer (data radio bearer) used for MBS, into a PTP leg and a PTM leg. Note that a PDCP entity is provided for each bearer.

[0065] Each of the gNB 200 and the UE 100 has two RLC entities, one MAC entity, and one PHY entity, each of which is provided for each leg. A PHY entity may be provided for each leg. In the case of dual connectivity in which the UE 100 communicates with two gNBs 200, the UE 100 may have two MAC entities.

[0066] The PHY entity transmits and receives data of the PTP leg using a Cell Radio Network Temporary Identifier (C-RNTI) that is assigned one-to-one to the UE 100. The PHY entity transmits and receives data of the PTM leg using a G-RNTI that is assigned one-to-one to the MBS session. The C-RNTI is different for each UE 100, but the G-RNTI is a common RNTI for multiple UEs 100 receiving one MBS session.

[0067] In order to perform PTM transmission (multicast or broadcast) of MBS data from the gNB 200 to the UE 100 using a PTM leg, a split MRB must be configured from the gNB 200 to the UE 100, and the PTM leg must be activated. In other words, even if a split MRB is configured in the UE 100, the gNB 200 cannot perform PTM transmission of MBS data using this PTM leg if the PTM leg is in a deactivation state.

[0068] Furthermore, in order for the gNB200 and the UE100 to perform PTP transmission (unicast) of MBS data using a PTP leg, a split MRB must be configured from the gNB200 to the UE100, and the PTP leg must be activated. In other words, even if a split MRB is configured in the UE100, the gNB200 cannot perform PTP transmission of MBS data using this PTP leg if the PTP leg is in an inactive state.

[0069] In a state in which the PTM leg is activated, the UE 100 monitors a PDCCH to which a G-RNTI associated with an MBS session is applied (i.e., performs blind decoding of the PDCCH using the G-RNTI). The UE 100 may monitor the PDCCH only at scheduling opportunities for the MBS session.

[0070] When the PTM leg is deactivated, UE 100 does not monitor the PDCCH to which the G-RNTI associated with the MBS session is applied (i.e., does not perform blind decoding of the PDCCH using the G-RNTI).

[0071] UE 100 monitors a PDCCH to which a C-RNTI is applied when a PTP leg is activated. When discontinuous reception (DRX) is configured in a PTP leg, UE 100 monitors the PDCCH during a configured on validity period (OnDuration). When a cell (frequency) associated with an MBS session is specified, UE 100 may monitor the PDCCH of the cell even if the cell is deactivated.

[0072] In a state in which the PTP leg is deactivated, the UE 100 may monitor a PDCCH to which a C-RNTI is applied in preparation for normal unicast downlink transmission other than MBS data. However, when a cell (frequency) associated with an MBS session is specified, the UE 100 may not monitor the PDCCH for the MBS session.

[0073] It is assumed that the split MRB as described above is configured by an RRC message (e.g., an RRC Reconfiguration message) sent by the RRC entity of gNB200 to the RRC entity of UE100.

[0074] (PDCP layer operation) FIG. 9 is a diagram showing the operation of the PDCP layer in the mobile communication system 1 according to the first embodiment.

[0075] The gNB 200 transmits MBS data of a certain MBS session to multiple UEs 100 (UEs 100a to 100c in the example of FIG. 9) by PTM (multicast or broadcast). The RRC state of each UE 100 may be any state (RRC connected state, RRC idle state, RRC inactive state). The MBS delivery mode may be a first delivery mode or a second delivery mode. The MBS delivery in the first delivery mode may use a PTM leg.

[0076] In the PDCP layer, the gNB 200 has a PDCP entity 201 associated with the MBS session (specifically, a transmitting PDCP entity associated with a multicast radio bearer (MRB) belonging to the MBS session). When the PDCP entity 201 starts transmission for the MBS session, it manages PDCP variables that are updated in response to the transmission of PDCP packets in the MBS session.

[0077] Each UE 100 has, in the PDCP layer, a PDCP entity 101 associated with the MBS session (specifically, a receiving-side PDCP entity associated with the MRB belonging to the MBS session). Each PDCP entity 101 (PDCP entities 101a and 101b in the example of FIG. 9) manages PDCP variables that are updated in response to reception of PDCP packets in the MBS session upon starting transmission of the MBS session.

[0078] As shown in Fig. 10, the PDCP variable may be a count value (COUNT value) consisting of a hyperframe number (HFN) that is counted up each time the PDCP sequence number goes around, and a PDCP sequence number (PDCP SN). For example, the COUNT value has a bit length of 32 bits, the PDCP SN has a bit length (SN_length) of 12 or 18 bits, and the HFN has a bit length obtained by subtracting the bit length of the PDCP SN from the bit length of the COUNT value. The bit length of the PDCP SN may be set by RRC signaling. Note that the term "PDCP variable" is not limited to referring to the COUNT value, but is also used to refer to various variables (HFN, PDCP SN, etc.) handled in the PDCP layer.

[0079] FIG. 11 is a diagram showing a PDCP packet constituting MBS data, specifically a PDCP data PDU (Protocol Data Unit). As shown in FIG. 11, the PDCP data PDU has a PDCP SN, data, and a MAC-I. The PDCP SN is a sequence number that is sequentially assigned to the PDCP data PDU. The data corresponds to a PDCP SDU (Service Data Unit). The MAC-I corresponds to a message authentication code. The PDCP data PDU may not have a MAC-I. As such, the PDCP data PDU has a PDCP SN but does not have an HFN. Therefore, the gNB 200 and the UE 100 each need to update the HFN in response to transmission and reception of the PDCP data PDU; specifically, they need to count up the HFN each time the PDCP sequence number goes around once.

[0080] 12 is a diagram showing the operation of identifying RCVD_COUNT, which is the COUNT value of a received PDCP data PDU, in the UE 100 (receiving side PDCP entity 101). Here, the PDCP SN included in the received PDCP data PDU is called RCVD_SN.

[0081] First, RCVD_SN <SN(RX_DELIV)-Window_Size If RCVD_HFN=HFN(RX_DELIV)+1 Here, RX_DELIV is a variable that indicates the oldest PDCP SDU that is waiting to be received but has not yet been provided to an upper layer. The initial value of RX_DELIV is zero. Window_Size is a constant that indicates the size of the reordering window.

[0082] Second, RCVD_SN≧SN(RX_DELIV)+Window_Size If RCVD_HFN=HFN(RX_DELIV)-1 is.

[0083] Third, if none of the above conditions are met, RCVD_HFN=HFN(RX_DELIV) is.

[0084] and, RCVD_COUNT=[RCVD_HFN,RCVD_SN] is set to

[0085] FIG. 13 is a diagram showing the operation of the receiving side PDCP entity 101 of the UE 100.

[0086] First, upon receiving a PDCP PDU, the receiving PDCP entity 101 performs security processing (specifically, deciphering / integrity verification) on the PDCP PDU using a count value (RCVD_COUNT) (step S11). If the integrity verification fails (step S12: Yes), the receiving PDCP entity 101 notifies the upper layer of the failure of the integrity verification and discards the PDCP PDU (step S13).

[0087] If the integrity verification is successful (step S12: No), if the count value (RCVD_COUNT) is smaller than RX_DELIV (step S14: Yes), or if RCVD_COUNT has already been received (step S16: Yes), the receiving PDCP entity 101 discards the PDCP PDU (step S15).

[0088] Next, the receiving PDCP entity 101 stores the PDCP PDUs that were not discarded in the receive buffer (step S17), and if "RCVD_COUNT≧RX_NEXT" is true (step S18: Yes), it updates RX_NEXT to RCVD_COUNT+1 (step S19). Here, RX_NEXT is a variable indicating the count value (RCVD_COUNT) of the PDCP SDU that is expected to be received next. The initial value of RX_NEXT is zero. If out-of-order delivery is configured (step S20: Configured), the receiving PDCP entity 101 decompresses the header of the PDCP PDU and passes it to an upper layer (step S21). Specifically, the receiving PDCP entity 101 performs the operation of S21 when "outOfOrderDelivery" is set in the RRC. Out-of-order delivery is an operation in which packets are passed to an upper layer without performing order control. Therefore, as in step S21, once a packet is received and stored in a buffer, the packet is immediately passed to the upper layer. If step S20 is "No," sequence control is performed.

[0089] If "RCVD_COUNT=RX_DELIV" (step S22: Yes), the receiving PDCP entity 101 decompresses the headers of all PDCP SDUs with consecutive COUNTs starting from COUNT=RX_DELIV, passes them to the upper layer (step S23), and updates RX_DELIV to the first (lowest) COUNT value that has not been passed to the upper layer (step S24).

[0090] When the receiving - side PDCP entity 101 has T - Reordering in operation and "RX_DELIV≧RX_REORD" (step S25: Yes), it stops and resets T - Reordering (step S26). Here, T - Reordering is a timer used to detect the loss of PDCP data PDUs. RX_REORD is a variable indicating the COUNT value following the COUNT value associated with the PDCP data PDU that triggered T - Reordering.

[0091] When the receiving - side PDCP entity 101 has T - Reordering stopped and "RX_DELIV < RX_REORD" (step S27: Yes), it updates RX_REORD = RX_NEXT and starts T - Reordering.

[0092] (Operation of the mobile communication system) FIG. 14 is a diagram showing the first operation scenario of the mobile communication system 1 according to the first embodiment.

[0093] gNB200A manages cell C1 (the first cell), and gNB200B adjacent to gNB200A manages cell C2 (the second cell). Cells C1 and C2 have at least partially overlapping coverage. gNB200A and gNB200B are interconnected via the Xn interface, which is an interface between base stations. In the following, it is assumed that the inter - base - station communication between gNB200A and gNB200B is carried out on the Xn interface.

[0094] The gNB 200A provides an MBS session in the cell C1. Specifically, the gNB 200A receives MBS data belonging to the MBS session from the UPF 300B and transmits the MBS data in the cell C1 by PTM (multicast / broadcast). The UE 100 in the RRC connected state receives the MBS data transmitted in the cell C1 by PTM (MBS reception). Hereinafter, the reception of the MBS data transmitted in the PTM (MBS reception) is also referred to as PTM reception.

[0095] The gNB200B provides an MBS session in cell C2. Specifically, the gNB200B receives MBS data belonging to the MBS session from the UPF300B and transmits the MBS data in cell C2 using PTM. The gNB200B can provide the same MBS session in cell C2 as the MBS session provided in cell C1.

[0096] FIG. 15 is a diagram showing a second operation scenario of the mobile communication system 1 according to the first embodiment.

[0097] The second operation scenario differs from the first operation scenario in that cell C1 (first cell) and cell C2 (second cell) are managed by one gNB 200. The gNB 200 provides an MBS session in each of cell C1 and cell C2. Specifically, the gNB 200 transmits MBS data in each of cell C1 and cell C2 by PTM (multicast / broadcast).

[0098] In the first and second operation scenarios, UE 100 in the RRC connected state moves from cell C1 toward cell C2. gNB 200 (gNB 200A) determines handover of UE 100 to cell C2, for example, based on a measurement report from UE 100, and transmits a handover command to UE 100. UE 100 accesses cell C2 (gNB 200B) in response to receiving the handover command.

[0099] Here, UE 100 performs PTM reception in cell C1, but it is difficult to perform PTM reception from cell C1 or cell C2 during the period from when it receives a handover command from cell C1 until it completes access to cell C2 (specifically, a random access procedure). Therefore, PTM reception by UE 100 is interrupted during handover execution, and loss of MBS data received by UE 100 may occur.

[0100] Hereinafter, a handover that is unlikely to cause loss of MBS data due to handover (hereinafter referred to as "lossless handover") will be described. Note that, under the assumption that UE 100 is handed over from cell C1 to cell C2, cell C1 is referred to as source cell C1, and cell C2 is referred to as target cell C2.

[0101] Fig. 16 is a diagram showing the operation of the gNB 200 according to the first embodiment. The gNB 200 may be a base station that manages the source cell C1, and may be the gNB 200A shown in Fig. 14 or the gNB 200 shown in Fig. 15.

[0102] In step S11, gNB200 configures an MRB having a PTM communication path used for PTM transmission and reception for UE100 in an RRC connected state in source cell C1.

[0103] In step S12, gNB200 decides to handover UE100 from source cell C1 to target cell C2.

[0104] In step S13, gNB200 instructs UE100 to switch from the PTM communication path to a PTP communication path used for PTP transmission and reception.

[0105] In step S14, gNB200 performs handover of UE100 to target cell C2.

[0106] As described above, in the first embodiment, the gNB 200 that has decided to hand over the UE 100 to the target cell C2 switches from the PTM communication path to the PTP communication path and then executes the handover. That is, the gNB 200 can realize a lossless handover by executing the handover after switching the transmission of MBS data to the UE 100 from PTM transmission (multicast / broadcast) to PTP transmission (unicast).

[0107] In step S11, the gNB 200 may configure a split MRB having a PTP leg that is a PTP communication path and a PTM leg that is a PTM communication path for the UE 100. In step S13, the gNB 200 may deactivate the PTM leg while keeping the PTP leg activated. Alternatively, in step S13, the gNB 200 may reconfigure the split MRB to a PTP-only MRB that is a PTP communication path.

[0108] Alternatively, in step S11, the gNB 200 may set a PTM-only MRB, which is a PTM communication path, to the UE 100. In step S13, the gNB 200 may re-set the PTM-only MRB to a PTP-only MRB, which is a PTP communication path.

[0109] 17 is a diagram showing an example of the operation of the mobile communication system 1 according to the first embodiment. In each of the following operation examples, the first operation scenario (see FIG. 14) is mainly assumed, but the second operation scenario (see FIG. 15) may also be assumed. That is, the gNB200A and the gNB200B may be the same gNB200.

[0110] In step S101, the gNB 200A transmits configuration information for configuring a split MRB in the UE 100 to the UE 100 by UE-dedicated RRC signaling (for example, an RRC Reconfiguration message). The UE 100 receives the configuration information for the split MRB from the gNB 200A (source cell C1) and establishes the split MRB (and the corresponding PDCP entity 101).

[0111] In step S102, the gNB 200A starts PTM transmission of the MBS data using the PTM leg. The UE 100 receives the MBS data on the PTM leg.

[0112] In step S103, gNB200A decides to handover UE100, for example, based on a measurement report from UE100.

[0113] In step S104, the gNB 200A deactivates the PTM leg. For example, the gNB 200A deactivates the PTM leg by transmitting a MAC control element (CE) or DCI to the UE 100 to deactivate the PTM leg. Note that even if the PTM leg is deactivated, the PTP leg remains activated. Therefore, for example, a received error packet in the PTM leg can be retransmitted and repaired using the PTP leg by recovery in the PDCP layer (step S105).

[0114] In step S106, gNB200A sends a handover request (HO Request) message to gNB200B requesting handover of UE100.

[0115] In step S107, in response to receiving the handover request (HO Request) message, the gNB200B transmits to the gNB200A a handover request acknowledge (HO Request Ack) message that acknowledges the handover of the UE 100. The handover request acknowledge (HO Request Ack) message includes a handover command (RRC container) that is transmitted to the UE 100 via the gNB200A. Note that the operations of steps S103 to S107 are included in the handover preparation phase.

[0116] In step S108, in response to receiving the handover request acknowledgement (HO Request Ack) message, gNB200A transmits a handover command (RRC Reconfiguration message with sync) to UE100.

[0117] In step S107, the gNB 200B may include configuration information for configuring a split MRB in the handover command (handover request accept message). In step S108, the UE 100 may be configured with the PTM leg deactivated if the split MRB is configured according to the configuration information included in the handover command.

[0118] In step S109, in response to receiving the handover command from the source cell C1 (gNB200A), the UE 100 accesses the target cell C2 (gNB200B), specifically, performs a random access procedure. Here, the UE 100 transmits an RRC Reconfiguration Complete message to the target cell C2 (gNB200B). Note that the operations of steps S108 and S109 are included in the handover execution phase.

[0119] In step S110, the gNB 200B may activate the PTM leg of the split MRB after the handover is performed. For example, the gNB 200B activates the PTM leg by transmitting a MAC CE or DCI to the UE 100 to activate the PTM leg.

[0120] 18 is a diagram showing another example of the operation of the mobile communication system 1 according to the first embodiment. Here, differences from the example of operation shown in FIG. 17 will be mainly described.

[0121] In step S111, the gNB 200A transmits configuration information for configuring a split MRB or a PTM-only MRB to the UE 100 by UE-dedicated RRC signaling (for example, an RRC Reconfiguration message). The UE 100 receives the configuration information from the gNB 200A (source cell C1) and establishes the split MRB or the PTM-only MRB.

[0122] In step S112, the gNB 200A starts PTM transmission of the MBS data using the PTM leg or the PTM-dedicated MRB. The UE 100 receives the MBS data on the PTM leg or the PTM-dedicated MRB.

[0123] In step S113, gNB200A decides to handover UE100, for example, based on a measurement report from UE100.

[0124] In step S114, the gNB 200A resets the PTM leg or PTM-dedicated MRB set in the UE 100 to a PTP-dedicated MRB (PTP-only MRB). For example, the gNB 200A transmits to the UE 100 an RRC Reconfiguration message for resetting the PTM leg or PTM-dedicated MRB set in the UE 100 to a PTP-dedicated MRB. After resetting to a PTP-dedicated MRB, the gNB 200A may transmit MBS data to the UE 100 by the PTP-dedicated MRB (step S115).

[0125] The operations from step S116 to step S120 are the same as the operation example shown in FIG.

[0126] [Second embodiment] The second embodiment will be described mainly focusing on the differences from the first embodiment described above.

[0127] In the second embodiment, multiple cells including a source cell C1 and a target cell C2 may form a single frequency network (SFN) for a certain MBS session. Each cell constituting the SFN simultaneously transmits the same MBS transmission signal at the same frequency. By performing handover of the UE 100 within such an SFN, lossless handover can be performed while maintaining PTM.

[0128] FIG. 19 is a diagram showing the operation of the UE 100 according to the second embodiment.

[0129] In step S21, the UE 100 in the RRC connected state in the source cell C1 receives the MBS session provided by the source cell C1 in the PTM.

[0130] In step S22, the UE 100 receives, from the source cell C1, SFN-related information regarding the SFN that the source cell C1 configures with the target cell C2.

[0131] In step S23, even if the UE 100 receives a handover command from the source cell C1 instructing handover to the target cell C2, the UE 100 continues to receive the MBS session provided by the SFN in the PTM based on the SFN-related information.

[0132] In step S22, the UE 100 may receive a handover command including SFN-related information. The SFN-related information may include at least one of an identifier for an MBS session provided by the SFN and information indicating that an MRB associated with the MBS session is maintained.

[0133] In step S22, the UE 100 may receive SFN-related information from the source cell C1 before receiving the handover command. The SFN-related information may include at least one of an identifier for an MBS session provided by the SFN and information indicating each cell and / or frequency constituting the SFN.

[0134] FIG. 20 is a diagram showing an example of the operation of the mobile communication system 1 according to the second embodiment.

[0135] In step S201, the source cell C1 establishes an SFN with the target cell C2 for a certain MBS session. Each gNB 200 is assumed to know which neighboring gNBs (neighboring cells) have established an SFN with itself.

[0136] In step S202, the gNB 200A provides an MBS session to the UE 100. Specifically, the gNB 200A performs PTM transmission of MBS data. Note that the gNB 200A is aware that the UE 100 is receiving the MBS session.

[0137] In step S203, gNB200A decides to hand over UE100.

[0138] In step S204, the gNB 200A transmits a handover request message to the gNB 200B. The message includes, as a UE context, information about the MBS session that the UE 100 is receiving.

[0139] Upon receiving the handover request message, the gNB 200B decides to accept the handover. The gNB 200B recognizes that the MBS session being received by the UE 100 configures an SFN with the source cell C1.

[0140] In step S205, the gNB 200B transmits a handover request accept message to the gNB 200A. The message includes an RRC Reconfiguration message (handover command) transmitted to the UE 100 via the gNB 200A. The RRC Reconfiguration message includes SFN-related information (SFN-related settings).

[0141] For example, the RRC Reconfiguration message may include at least one of an MBS session identifier of an MBS session constituting an SFN and a bearer / channel identifier (e.g., a bearer ID, a QoS flow ID, an RLC channel ID, and / or a logical channel (LC) ID) associated with the MBS session. The RRC Reconfiguration message may include at least one of an MBS session identifier of an MBS session for which re-establishment / resetting of a user plane protocol stack such as a PDCP entity and an RLC entity is not required (i.e., continued use) and a bearer / channel identifier (e.g., a bearer ID, a QoS flow ID, an RLC channel ID, and / or an LC ID) for which re-establishment / resetting of the user plane protocol stack is not required (i.e., continued use).

[0142] In step S206, gNB200A transmits the RRC Reconfiguration message to UE100 (handover command).

[0143] In step S207, UE 100, which has received the RRC Reconfiguration message, continues the PTM reception operation of the MRB associated with the MBS session provided by the SFN based on the SFN-related information included in the RRC Reconfiguration message. Specifically, UE 100 continues the PTM reception operation even during the reconfiguration of other bearers without performing processes such as re-establishment / reconfiguration of PDCP entities and RLC entities. Other bearers include, for example, unicast bearers and multicast / broadcast bearers that do not constitute an SFN. In this way, when performing a handover based on the SFN, UE 100 leaves the MBS-related user plane as it is and transfers the remaining user planes (unicast bearers, etc.) and control planes to target cell C2. Here, UE 100 can control so that the MRBs are not released by the handover.

[0144] In step S208, UE100 performs a random access procedure to target cell C2 (gNB200B).

[0145] In step S209, UE100 performs PTM reception from target cell C2 (gNB200B).

[0146] 21 is a diagram showing another example of the operation of the mobile communication system 1 according to the second embodiment. In this operation example, the source cell C1 (gNB 200A) provides SFN-related information to the UE 100 in advance before transmitting a handover command.

[0147] In step S211, the source cell C1 configures an SFN with the target cell C2 for an MBS session.

[0148] In step S212, the gNB 200A provides an MBS session to the UE 100. Specifically, the gNB 200A performs PTM transmission of the MBS data.

[0149] In step S213, the gNB200A (source cell C1) transmits SFN-related information (SFN-related settings) to the UE 100. The gNB200A may transmit the SFN-related information by UE-dedicated signaling (e.g., an RRC Reconfiguration message) or broadcast signaling (e.g., an SIB or an MCCH).

[0150] Here, the SFN-related information may include information indicating whether or not an SFN is configured for each MBS session identifier. If an SFN is configured, the SFN-related information may include a list of cells (cell IDs) that configure the SFN. However, if cells uniformly configure an SFN on a certain frequency, the SFN-related information may include a frequency identifier instead of the list. Also, instead of the MBS session identifier, a QoS flow ID, a bearer ID, an RLC channel ID, and / or an LC ID may be used. UE 100 recognizes MBS sessions provided by the SFN based on the SFN-related information. Alternatively, UE 100 identifies SDAP / PDCP / RLC / MAC entities that do not perform re-establishment / reset processing during handover.

[0151] In step S214, gNB200A decides to handover UE100.

[0152] In step S215, the gNB200A transmits a handover request message to the gNB200B. The gNB200B decides to accept the handover of the UE100.

[0153] In step S216, the gNB 200B transmits a handover request accept message to the gNB 200A. This message includes an RRC Reconfiguration message (handover command). This RRC Reconfiguration message does not need to include AS settings (bearer settings, etc.) for receiving an MBS session provided by the SFN. Specifically, since the UE 100 is already receiving the SFN and continues to use the settings, AS settings for receiving an MBS session provided by the SFN are not required. However, the RRC Reconfiguration message may include an MBS session identifier or bearer ID, etc., of the MBS session provided by the SFN.

[0154] In step S217, the gNB200A, which has received the handover request acceptance message, sends an RRC Reconfiguration message to the UE100 (handover command).

[0155] In step S218, the UE 100 continues receiving operations of the bearers associated with the MBS session provided by the SFN. The UE 100 may reconfigure, for example, unicast bearers and multicast / broadcast bearers that do not constitute the SFN in accordance with the RRC Reconfiguration message.

[0156] In step S219, UE100 performs a random access procedure to target cell C2 (gNB200B).

[0157] In step S220, UE100 performs PTM reception from target cell C2 (gNB200B).

[0158] [Third embodiment] The third embodiment will be described mainly focusing on the differences from the first and second embodiments.

[0159] The following embodiments are embodiments in which handover is performed between cells in which SFN is not configured, allowing continuation of PTM reception. When SFN is not configured, this refers to a case in which each cell is performing single-cell transmission or a case in which handover is performed to an SFN of a different frequency (for example, when an SFN is disconnected from another SFN due to deployment reasons).

[0160] In the following embodiments, it is assumed that the source cell C1 and the target cell C2 perform PTM transmission for the same MBS session. The two cells may perform different frequencies and / or different MTCH scheduling (including MCS).

[0161] It is also assumed that the MBS data transmission timing of the source cell C1 and the target cell C2 is "roughly" synchronized. "Roughly" means that the transmission timing of the same MBS packet (PDCP data PDU with the same PDCP SN) between the two cells is not significantly different. However, it is not necessary for both cells to transmit MBS packets with the same PDCP SN at a given time. Therefore, the radio frames of the two cells do not need to be synchronized.

[0162] It is also assumed that the same sequence number (PDCP SN) is assigned to the same MBS packet (IP packet) in both cells. Since one PDCP PDU is generated per IP packet, as long as the PDCP SN of the first IP packet matches in both cells, the correspondence between each subsequent MBS packet and each PDCP SN will match regardless of the cell.

[0163] FIG. 22 is a diagram showing the operation of the UE 100 according to the third embodiment.

[0164] In step S31, the UE 100 in an RRC connected state in the source cell C1 receives an MBS session provided by the source cell C1 in PTM.

[0165] In step S32, UE100 simultaneously receives both the MBS session provided by the source cell C1 and the MBS session provided by the target cell C2 within a predetermined time before and / or within a predetermined time after handover to the target cell C2, which provides the MBS session in PTM.

[0166] Such simultaneous reception from both cells (simultaneous PTM reception) makes it possible to realize lossless handover between cells in which an SFN is not configured. It is assumed that the UE 100 has a plurality of receivers.

[0167] In step S32, the UE 100 may start simultaneous reception before handover (before handover is executed). For example, the UE 100 that performs PTM reception from the cell C1 may start PTM reception from the cell C2 before receiving the handover command from the source cell C1.

[0168] In step S32, after the handover (after the execution of the handover), the UE 100 may start the PTM reception (MBS reception) from the target cell C2 and may continue the PTM reception from the source cell C1.

[0169] In step S32, if the second sequence number of the MBS data (PDCP data PDU) first received from the target cell C2 is greater than the first sequence number of the MBS data (each PDCP data PDU) received from the source cell C1, UE100 may continue receiving MBS data from the source cell C1 until the gap between the first sequence number and the second sequence number disappears, i.e., until the first sequence number catches up with the second sequence number.

[0170] In step S32, if the second sequence number of the MBS data (PDCP data PDU) first received from the target cell C2 is smaller than the first sequence number of the MBS data (each PDCP data PDU) received from the source cell C1, UE100 may determine that there is no gap between the first sequence number and the second sequence number and stop receiving the MBS from the source cell C1.

[0171] When data loss occurs even when simultaneous reception is performed, the UE 100 may request the target cell C2 to retransmit the lost data.

[0172] FIG. 23 is a diagram showing an example of the operation of the mobile communication system 1 according to the third embodiment.

[0173] In step S301, the UE 100 performs PTM reception in the source cell C1.

[0174] In step S302, the gNB 200A provides the MBS reception configuration of the target cell C2 to the UE 100. The gNB 200A may transmit the MBS reception configuration of the target cell C2 by UE-dedicated signaling (e.g., an RRC Reconfiguration message) or broadcast signaling (e.g., an SIB or an MCCH). The gNB 200A may provide the MBS reception configuration of the target cell C2 by a handover command (RRC Reconfiguration message with sync) in step S306.

[0175] In step S303, gNB200A decides to hand over UE100.

[0176] In step S304, the gNB200A transmits a handover request message to the gNB200B. Upon receiving the handover request message, the gNB200B decides to accept the handover.

[0177] In step S305, the gNB 200B transmits a handover request accept message to the gNB 200A. The message includes an RRC Reconfiguration message (handover command) transmitted to the UE 100 via the gNB 200A.

[0178] In step S306, the gNB 200A transmits a handover command to the UE 100. Note that the handover command may be a handover command that instructs (sets) a conditional handover. In the case of a conditional handover, the UE 100 may start receiving PTM from the target cell C2 in step S307 when the conditional handover is set, triggered, or executed.

[0179] In step S307, UE 100 starts PTM reception from target cell C2 in accordance with the MBS reception setting received from source cell C1 in step S302 (or step S306). At this point, UE 100 is receiving data of the same MBS session from both source cell C1 and target cell C2. Note that if UE 100 receives a duplicate packet (a packet that has already been received), it may discard the packet (at the PDCP layer).

[0180] In step S308, the UE 100 starts accessing the target cell C2, and completes the handover process.

[0181] In step S309, the UE 100 ends the reception of the MBS from the source cell C1.

[0182] Here, UE 100 may terminate MBS reception from source cell C1 when there is no PDCP SN gap between source cell C1 and target cell C2. Specifically, if the PDCP SN of source cell C1 is later than the PDCP SN of target cell C2, for example, if the MBS data currently received by UE 100 is SN#5 for source cell C1 and SN#10 for target cell C2, UE 100 receives PDCP data PDUs with SN#10 and on from target cell C2, and also receives PDCP data PDUs with SN#5 to SN#9 from source cell C1. Since there is no SN gap when PDCP data PDUs with SN#5 to SN#9 are received from source cell C1, UE 100 terminates PTM reception from source cell C1. As a result, UE 100 can successfully receive each PDCP data PDU with SN#5 and on.

[0183] If the PDCP SN of the source cell C1 is earlier than the PDCP SN of the target cell C2, for example, if the MBS data currently received by UE 100 is SN#10 for the source cell C1 and SN#5 for the target cell C2, UE 100 may terminate PTM reception from source cell C1, assuming that there is no SN gap. UE 100 may discard each of the PDCP data PDUs with SN#5 to SN#10 that have been received in duplicate (because they have already been received from source cell C1). As a result, UE 100 can successfully receive each of the PDCP data PDUs with SN#5 and onward.

[0184] In step S310, if data loss occurs despite simultaneous reception (simultaneous PTM reception), for example, if the PDCP data PDU of SN#6 is lost due to deterioration of the radio environment, UE 100 may request target cell C2 to retransmit the PDCP data PDU of SN#6. The request may be notified by a PDCP Status Report (or a new PDCP Control PDU). Alternatively, the request may be a request to set up a PTP leg. In this case, the absence of a PTP leg is assumed to mean a PTM-only MRB, so the PDCP Status Report cannot be used as a PTP leg setup request. Therefore, the PTP leg setup request may be transmitted to target cell C2 using RRC signaling (for example, an MBS Interest Indication (MII) message or a UE Assistance Information message).

[0185] 24 is a diagram showing another example of the operation of the mobile communication system 1 according to the third embodiment. In this example of operation, the UE 100 continues to receive MBS data from the source cell C1 even after accessing the target cell C2, and stops receiving MBS data from the source cell C1 when the PDCP SN gap disappears.

[0186] In step S331, the UE 100 performs PTM reception in the source cell C1.

[0187] In step S332, gNB200A decides to hand over UE100.

[0188] In step S333, the gNB200A transmits a handover request message to the gNB200B. The gNB200B, which has received the handover request message, decides to accept the handover.

[0189] In step S334, the gNB 200B transmits a handover request accept message to the gNB 200A. The message includes an RRC Reconfiguration message (handover command) transmitted to the UE 100 via the gNB 200A.

[0190] In step S335, the gNB 200A transmits a handover command to the UE 100. The gNB 200A may include, in the handover command, information permitting continuous reception of an MBS from the source cell C1, such as an MBS session identifier, QFI, bearer ID, etc. permitting continuous reception of the MBS. The handover command may also include an MBS reception setting for the target cell C2.

[0191] In step S336, the UE 100 accesses the target cell C2 (random access procedure).

[0192] In step S337, when the UE 100 completes the access, it starts PTM reception from the target cell C2. Here, the UE 100 continues receiving MBS from the source cell C1, and is in a state of receiving data of the same MBS session from both the source cell C1 and the target cell C2. If the UE 100 receives a duplicate packet (a packet that has already been received), it may discard the packet.

[0193] In step S338, the UE 100 ends the MBS reception from the source cell C1. This process is similar to the above-described step S309.

[0194] In step S339, if data loss occurs despite simultaneous reception (simultaneous PTM reception), the UE 100 may make a retransmission request to the target cell C2. This process is the same as that of step S310 described above.

[0195] [Fourth embodiment] The fourth embodiment will be described mainly focusing on the differences from the first to third embodiments.

[0196] In the fourth embodiment, it is assumed that the target cell C2 (and the source cell C1) performs MBS delivery in the second delivery mode (DM2: Delivery Mode 2) described above. The fourth embodiment may be implemented in combination with the third embodiment described above.

[0197] FIG. 25 is a diagram showing the operation of the UE 100 according to the fourth embodiment.

[0198] In step S41, the UE 100 in the RRC connected state in the source cell C1 receives the MBS session provided by the source cell C1 in the PTM.

[0199] The UE 100 receives a handover command from the source cell C1 instructing handover to the target cell C2. The handover command includes MTCH configuration information for receiving the MBS session provided by the target cell C2. Specifically, the handover command includes MTCH configuration information of an MTCH that provides, in the target cell C2, the same MBS session as the MBS session that the UE 100 is receiving in the source cell C1, but does not include MTCH configuration information of other MTCHs of the target cell C2.

[0200] In step S43, after the handover (after the handover is executed), the UE 100 receives the MBS session provided by the target cell C2 based on the MTCH setting information received in step S42.

[0201] In the fourth embodiment, the source cell C1 provides, to the UE 100, by a handover command, only MTCH configuration information corresponding to the MBS session that the UE 100 is receiving in the source cell C1, among multiple pieces of MTCH configuration information that the target cell C2 provides on the MCCH. This allows the UE 100 to smoothly start receiving the MBS session in the target cell C2.

[0202] In the fourth embodiment, the gNB200A (first base station) managing the source cell C1 may transmit a handover request message including MBS interest information indicating an MBS session that the UE100 is receiving or is interested in receiving to the gNB200B managing the target cell C2. The gNB200B that receives the handover request message may identify MTCH configuration information corresponding to the MBS session indicated by the MBS interest information and transmit a response message (handover request accept message) including the identified MTCH configuration information to the gNB200A. The gNB200A that receives the response message may transmit a handover command including the MTCH configuration information from the gNB200B to the UE100.

[0203] FIG. 26 is a diagram showing an example of the operation of the mobile communication system 1 according to the fourth embodiment.

[0204] In step S401, UE 100 may be performing PTM reception in source cell C1. The gNB 200A grasps information (MBS interest information) of MBS sessions that UE 100 is receiving or is interested in receiving. For example, the gNB 200A may grasp the MBS sessions based on an MII message transmitted from UE 100 to the gNB 200A. The gNB 200A may also grasp the MBS sessions based on UE context information notified to the gNB 200A from the CN 20. The gNB 200A holds the MBS interest information as a UE context.

[0205] In step S402, gNB200A decides to hand over UE100.

[0206] In step S403, the gNB 200A transmits a handover request message to the gNB 200B. The handover request message includes MBS interest information of the UE 100. The gNB 200B, which has received the handover request message, decides to accept the handover.

[0207] Based on the MBS interest information of the UE 100, the gNB 200B identifies MBS sessions that the UE 100 is receiving or is interested in receiving, and identifies MTCH configuration information (particularly, MTCH scheduling information) of the MTCH corresponding to the identified MBS session. The gNB 200B includes the identified MTCH configuration information in a handover request accept message (specifically, a handover command / RRC Reconfiguration message). Here, the gNB 200B may include MTCH configuration information for multiple MTCHs in the handover command, but includes only the MTCH configuration information related to the MBS session of interest to the UE 100 in the handover command, rather than the entire content of the MCCH in the target cell C2.

[0208] In step S404, the gNB 200B transmits a handover request accept message to the gNB 200A. The message includes an RRC Reconfiguration message (handover command) transmitted to the UE 100 via the gNB 200A.

[0209] In step S405, upon receiving the handover request acceptance message, gNB200A extracts the handover command stored in the message and transmits the handover command (RRC Reconfiguration message) to UE100.

[0210] In step S406, the UE 100 applies the handover command (RRC Reconfiguration message) received in step S405, and starts access to the target cell C2 (random access procedure).

[0211] In step S407, upon completion of the access, the UE 100 starts receiving the MTCH of the target cell C2 from the MTCH scheduling information provided in the RRC Reconfiguration message received in step S405. This allows the UE 100 to continue receiving the MBS session without causing a service interruption during handover.

[0212] [Fifth embodiment] The fifth embodiment will be described mainly focusing on the differences from the first to fourth embodiments.

[0213] Under the assumption that the source cell C1 and the target cell C2 provide the same MBS session, if the PDCP SN in the target cell C2 is later than the PDCP SN in the source cell C1, MBS data loss due to handover is unlikely to occur. Therefore, in the fifth embodiment, each cell performs dual-stream transmission, transmitting with a PDCP SN roughly synchronized with other cells and transmitting with a PDCP SN later than the PDCP SN in question.

[0214] FIG. 27 is a diagram showing the operation of the UE 100 according to the fifth embodiment.

[0215] In step S51, the UE 100 in the RRC connected state in the source cell C1 receives the MBS session provided by the source cell C1 in the PTM.

[0216] In step S52, after handover to target cell C2 that provides the MBS session, UE 100 receives two MBS data streams belonging to the MBS session from target cell C2. The two MBS data streams have different sequence numbers (specifically, PDCP SNs) at the same time. Note that in the fifth embodiment, UE 100 only needs to be configured to be able to receive multiple data streams, and the number of receivers may be one or more.

[0217] The two MBS data streams may have different modulation and coding schemes (MCS). For example, target cell C2 applies a first MCS to a transmission stream with a PDCP SN roughly synchronized with that of source cell C1, and applies a second MCS to a transmission stream with a PDCP SN delayed from that of source cell C1. The second MCS may have a higher data rate (i.e., lower error resilience) than the first MCS.

[0218] The two MBS data streams may be configured as sub-MBS sessions or QoS flows within a single MBS session and transmitted on different MTCHs. The two MBS data streams may be multiplexed using spatial division multiplexing (SDM), frequency division multiplexing (FDM), and / or time division multiplexing (TDM).

[0219] FIG. 28 is a diagram showing an example of the operation of the mobile communication system 1 according to the fifth embodiment.

[0220] In step S501, the UE 100 performs PTM reception in the source cell C1.

[0221] In step S502, gNB200A decides to hand over UE100.

[0222] In step S503, gNB200A transmits a handover request message to gNB200B. Upon receiving the handover request message, gNB200B decides to accept the handover.

[0223] In step S504, the gNB 200B transmits a handover request accept message to the gNB 200A. The message includes an RRC Reconfiguration message (handover command) transmitted to the UE 100 via the gNB 200A.

[0224] In step S505, the gNB 200A that has received the handover request accept message extracts the handover command stored in the message and transmits the handover command (RRC Reconfiguration message) to the UE 100. The UE 100 that has received the handover command terminates PTM reception from the source cell C1.

[0225] In step S506, the UE 100 applies the handover command (RRC Reconfiguration message) received in step S505, and starts access to the target cell C2 (random access procedure).

[0226] In steps S507 and S508, gNB200B (target cell C2) transmits two MBS data streams (two PTM streams) A and B for the same MBS session. gNB200B (target cell C2) may start transmitting the two MBS data streams A and B at this point, or may have transmitted them in advance. The two MBS data streams A and B transmit packets with different SNs at a certain point in time.

[0227] Here, assume that the MBS session identifier of the MBS session provided by the source cell C1 is "TMGI-1", the MBS session identifier of the MBS data stream A provided by the target cell C2 is "TMGI-1A", and the MBS session identifier of the MBS data stream B provided by the target cell C2 is "TMGI-1B". For example, TMGI-1A and TMGI-1B are transmitting data from the same MBS session, but at a certain point in time, TMGI-1B is transmitting later (older) data. The correspondence relationship between the SNs of each PTM transmission at this point in time is, for example, as follows:

[0228] Source cell C1:TMGI-1:SN#5 Target cell C2: TMGI-1A: SN#10 Target cell C2: TMGI-1B: SN#3

[0229] UE100 starts PTM reception of TMGI-1A and TMGI-1B in target cell C2. In the case of the correspondence relationship described above, UE100 has already received SN#5 from source cell C1. For example, UE100 receives SN#3 to SN#9 from TMGI-1B of target cell C2, but SN#3 to SN#5 are duplicates and may be discarded. UE100 simultaneously receives SN#10 and on from TMGI-1A of target cell C2. UE100 ends reception of TMGI-1B when the SN gap disappears.

[0230] As a modification of this operation, different MCSs may be applied to the two MBS data streams A and B. In this modification, UE 100 may be configured to receive only one stream. For example, the correspondence between the SN and MCS of each PTM transmission at the time of steps S507 and S508 is as follows:

[0231] Source cell C1:TMGI-1:SN#5 Target cell C2: TMGI-1A: SN#10: MCS10 (low data rate) Target cell C2: TMGI-1B: SN#3: MCS16 (high data rate)

[0232] The MCS applied to each stream may be defined in advance. The target cell C2 may provide the UE 100 with information indicating which stream has a higher data rate (a stream for recovery).

[0233] In the target cell C2, UE 100 first starts PTM reception of TMGI-1B. In the case of the correspondence relationship described above, UE 100 has already received SN#5 from the source cell C1. UE 100 receives SN#3 to SN#9(+α) from TMGI-1B of the target cell C2. When it is considered that the SN gap has disappeared, UE 100 stops receiving TMGI1-B and starts receiving TMGI-1A. Then, UE 100 receives SN#9(+α) to from TMGI-1A of the target cell C2.

[0234] In addition, gNB200B may provide information on the SN gap and MCS difference (i.e., when the SN gap will disappear) to UE100. For example, gNB200B may provide UE100 with information such as that the gap will disappear if the TMGI-1B stream is received 10 times.

[0235] [Sixth embodiment] The sixth embodiment will be described mainly focusing on the differences from the first to fifth embodiments.

[0236] The sixth embodiment is an embodiment in which information is shared between gNB200A and gNB200B, assuming that the operations of the first to fifth embodiments described above are performed.

[0237] FIG. 29 is a diagram showing the operation of the mobile communication system according to the sixth embodiment.

[0238] In step S601, the gNB200B providing the MBS session transmits sequence number information indicating the sequence number (PDCP SN) of the MBS data being transmitted in the MBS session to the gNB200A. Prior to step S601, the gNB200A may request the gNB200B to provide information regarding the SN currently being transmitted in the MBS session being currently provided.

[0239] The sequence number information transmitted from the gNB200B to the gNB200A may be included in, for example, an NG-RAN node Configuration Update message or a new Xn message. The sequence number information may be provided for each cell (for each cell ID) managed by the gNB200B. Furthermore, the sequence number information may be provided for each MBS session (for each MBS session identifier) ​​provided by the gNB200B. The sequence number information may include information on the MBS session currently being provided by the gNB200B and PDCP SN information of the data currently being transmitted. The PDCP SN information may be the transmission PDCP SN (previously transmitted SN or next transmitted SN) at the reference time. Here, the reference time may be a time determined using GPS or a radio frame number (SFN, etc.).

[0240] In step S602, gNB200A performs the above-described PTM control (control of MBS session provision) based on the sequence number information from gNB200B.

[0241] For example, gNB200A may compare the transmission SN information of the MBS session being provided by gNB200B with the transmission SN of its own MBS session, determine the SN gap (including which is earlier / later), and perform lossless handover control as follows.

[0242] · gNB200A notifies UE100 of information on whether data recovery processing (simultaneous reception processing) is required after handover.

[0243] · gNB200A provides UE100 with MTCH configuration information for target cell C2 and / or instructs UE100 to immediately start receiving MTCH from target cell C2.

[0244] · gNB200A allows UE100 to continue receiving MBS data from source cell C1 even after handover.

[0245] · gNB200A instructs gNB200B to transmit two streams with different SNs and / or MCSs after handover, and / or instructs UE100 to receive two streams with different SNs and / or MCSs after handover.

[0246] In the sixth embodiment, the gNB200B may transmit sequence number information to the gNB200A only when the SN of the source cell C1 is later than the SN of the target cell C2. The gNB200A may not need to perform the lossless handover control described above when the SN of the source cell C1 is earlier than the SN of the target cell C2. Specifically, when the SN of the source cell C1 is earlier than the SN of the target cell C2, packets received from the target cell C2 simply overlap with those from the source cell C1 and are not missed, so SN continuity can be ensured.

[0247] [Other embodiments] The above-described operational flows may be implemented not only separately but also by combining two or more operational flows. For example, some steps of one operational flow may be added to another operational flow. Also, some steps of one operational flow may be replaced with some steps of another operational flow. Furthermore, the order of steps in each of the above-described operational flows may be changed as appropriate.

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

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

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

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

[0252] This application claims priority to U.S. Provisional Application No. 63 / 229,619 (filed August 5, 2021), the entire contents of which are incorporated herein by reference.

[0253] [Note] 1. Introduction A revised work item on NR multicast and broadcast services (MBS) was approved in RAN#88, with the objective of specifying dynamic PTM / PTP switching and mobility with service continuity as follows: Specifies the RAN basic functions for broadcast / multicast for UE in RRC connected state. Specifies support for dynamic change of broadcast / multicast service delivery between multicast (PTM) and unicast (PTP) with service continuity for a particular UE. Provide support for basic mobility with service continuity.

[0254] Regarding dynamic PTM / PTP switching, RAN2 has already reached some agreements related to this topic. RAN2#111-e had the following agreements: For the UE, the gNB dynamically decides whether to deliver multicast data via PTM or PTP (shared delivery). Further study is needed on how the layer handles reliability (in general), in-order delivery / duplicate handling, and how it works with switching between PTM and PTP.

[0255] In RAN2#113-e, the dynamic PTM / PTP switching architecture was agreed upon in conjunction with discussions on L2 reliability as follows: Configuration with switching between PTM and PTP without L2 ARQ and with fixed PDCP is supported when both PTM and PTP are RLC UM (e.g. for services normally configured with RLC UM for unicast).

[0256] Further agreement was reached on architecture and signaling for RAN2#113bis-e as follows: agreement Please note that the following agreements are based only on architectural decisions so far. The reliability discussion is not over yet, i.e., cases other than RLC UM+RLC UM. The switch between PTM and PTP in these other cases requires further study. Dynamic PTM / PTP switching is supported for split MRB bearers (types) with a common (single) PDCP entity. Fundamentally, no new UE-based signaling is being introduced to support gNB switch decisions (e.g., PDCP SR for high reliability is pending). Assuming a split MRB configured on the PTM leg and the PTP leg (agreed during the online session), the use of the PTP leg cannot be deactivated after the required split MRB configuration (i.e. the UE must always monitor the C-RNTI). Considering a split MRB configured with a PTM leg and a PTP leg (agreed upon during an online session), whether and how the use of the PTM leg of the split MRB is subject to activation or deactivation is a matter for further consideration.

[0257] Regarding the mobility aspect, RAN2 only agreed on the basic principles listed below. R2 aims to support lossless handover for MBS-MBS mobility for services that require it (scenario details are yet to be determined, at least PTP-PTP). To support lossless handover for 5G MBS services, at least DL PDCP SN synchronization and continuity between source and target cells must be guaranteed on the network side. The design of specific approaches to achieve this may be relevant to WG RAN3. From the network side, the source gNB may forward data to the target gNB, and the target gNB delivers the forwarded data. Meanwhile, the SN STATUS TRANSFER needs to be extended to cover the PDCPSN of the MBS data. Then, the UE receives the MBS in the target cell by the target cell according to the target configuration. From the UE side, PDCP status reporting may also be supported.

[0258] This appendix describes the remaining issues of dynamic PTM / PTP switching and mobility with service continuity based on the agreed architecture, i.e., using split MRB anchored to PDCP.

[0259] 2. Discussion 3. Split MRB Settings The architecture of PTM / PTP switching anchored to PDCP, i.e., split MRB, can be interpreted as shown in Figure 30 based on the current agreement.

[0260] In general, RRC reconfiguration can be considered to be used to provide bearer configuration including two logical channels (PTM leg and PTP leg) along with information for receiving a multicast session. Although RAN2 states that "a split MRB (agreed in the online session) configured with a PTM leg and a PTP leg is assumed," it seems to be commonly understood that the configuration associating two logical channels with one multicast radio bearer is provided by RRC reconfiguration in preparation for dynamic PTM / PTP switching.

[0261] Observation 1: It appears to be a common understanding that the configuration to associate two logical channels with one MRB is provided by RRC reconfiguration prior to dynamic PTM / PTP switching operation.

[0262] 4. Dynamic PTM / PTP switching operation 5. Signaling Whether and how the use of the PTM leg of a split MRB can be subject to activation or deactivation requires further study.

[0263] When a split MRB with PTM / PTP legs is configured, the UE must monitor both the G-RNTI of the PTM leg and the C-RNTI of the PTP leg. In LTE SC-PTM, the SC-PTM reception opportunity is independent of the unicast DRX method, i.e., the DRX is separate. This concept may be the basis for NR MBS because G-RNTI is received by multiple UEs, while C-RNTI is UE-specific, making it very difficult to align the two DRXs. This means that if the UE had to constantly monitor the G-RNTI, it would need to wake up frequently, resulting in additional power consumption. On the other hand, a connected UE needs to monitor the C-RNTI, i.e., C-DRX, for unicast reception, but this does not impose an additional burden on the UE.

[0264] Observation 2: The UE should wake up on PTM leg transmission opportunities (i.e., G-RNTI) like SC-MTCH opportunities in LTE SC-PTM, in addition to PTP leg transmission opportunities (i.e., C-RNTI) like C-DRX.

[0265] When receiving an MRB with PTM / PTM, that is, when switching, there are four options:

[0266] Option 1: Activation / Deactivation Based Switching The gNB instructs the UE to enable / disable the PTM leg via DCI, MAC CE, or RRC signaling. This option provides more flexibility when receiving MBS data via two legs, such as split bearer or PDCP packet duplication, in addition to receiving MBS data via either PTM or PTP. The UE can reduce power consumption from the deactivated PTM leg. Note that the NW implementation may decide to keep two legs active at all times, which can cover the intent of option 4 below.

[0267] Option 2: Switch Order / Command Based Switching The gNB instructs the UE to switch between the PTM leg and the PTP leg by DCI, MAC CE, or RRC signaling. This option is similar to option 1 above and is simple in terms of power saving by deactivating the PTM leg. However, it lacks flexibility for split bearer-like operation including duplication of PDCP packets. This option only switches between the PTM leg and the PTP leg, and it seems that it cannot activate both.

[0268] Option 3: RRC reconfiguration based switching The gNB reconfigures the UE as either a PTM or PTP MRB via RRC reconfiguration, which means that the PTM leg and the PTP leg are not associated with one MRB. This is like a "bearer type change" and is inconsistent with the split MRB architecture. Also, this option involves L3, so it is questionable how "dynamic" the switching between PTM and PTP can be.

[0269] Option 4: No signaling based switchover The UE must always attempt to receive from both the PTM leg and the PTP leg when two legs are configured for a split MRB. This option ensures maximum scheduling flexibility from the gNB's perspective, but does not offer any power saving opportunities for the UE.

[0270] From the above, Option 1 is the most suitable option in terms of scheduling flexibility, UE power consumption, and compatibility with the split MRB architecture. Option 4 can be considered a subset of Option 1 if the PTM leg is always active. Regarding the signaling layer, MAC CE may be easy since activation / deactivation is mostly related to DRX operation. Therefore, RAN2 should agree that the PTM leg can be activated / deactivated via MAC CE.

[0271] Proposal 1: For dynamic PTM / PTP switching, RAN2 should agree to introduce a MAC CE to activate / deactivate the PTM leg of the split MRB.

[0272] Regarding "bearer type change," which is different from dynamic switching, the following cases are considered to be involved in bearer type change. Case 1: PTM only MRB ←→ PTP only MRB Case 2: Split MRB ←→ PTM-only MRB Case 3: Split MRB ←→ PTP-only MRB

[0273] In such a case of bearer type change, it is easier to use RRC reconfiguration, i.e. option 3.

[0274] Proposal 2: For bearer type changes between PTM-only MRB, PTP-only MRB, and split MRB, RAN2 should agree to use RRC reconfiguration.

[0275] 6. PDCP Actions 7. Initial values ​​of state variables RAN2 agreed to support RLC AM mode for the PTP leg of split MRB in addition to RLC UM mode. Furthermore, it is commonly understood that since RLC-AM does not support PTM (for MBS R17 WI), L2 reliability depends solely on dynamic PTM / PTP switching. Therefore, minimizing packet loss at the start of MBS data reception and during dynamic PTM / PTP switching is worth considering for service continuity.

[0276] As shown in Figure 30, if the existing PDCP functional view is reused, the PDCP SN is common to both the PTM leg and the PTP leg. Because the PTM leg is used by multiple UEs, the PDCP SN may not be UE-specific and affects both the PTM leg and the PTP leg. This means that if a UE joins a multicast session late, the initial values ​​of each state variable cannot always be "0," regardless of whether the first MBS data received comes from the PTM leg or the PTP leg. In other words, the PDCP SN initially received by the UE may be any value not expected for this unicast transmission. Furthermore, because the state variables are set to their initial values, PDCP re-establishment of one UE may affect all other UEs. This may result in unexpected behavior in the receive window, i.e., discarding PDCP PDUs outside the window. It has been pointed out that the same problem may also exist in handover scenarios.

[0277] Observation 3: For a UE that joins a multicast session late and has split MRB configured, it has been observed that the SN of the first received PDCP PDU is not the initial value (i.e., "0") regardless of whether it is on a PTM leg or a PTP leg.

[0278] To solve this problem, the following options are proposed:

[0279] Option A: The gNB notifies the UE of the initial value of COUNT or RX_NEXT and RX_DELIV. This option simply modifies the initial value of the receive window based on information from the gNB so that the UE can receive the first transmission of MBS data using existing mechanisms. However, from the PDCP layer perspective, it is questionable whether the UE can always successfully receive the first transmission intended by the gNB due to switching delays, poor radio conditions, being outside the RLC reestablishment window, etc. In this case, it is unclear how this option would work.

[0280] Option B: The gNB notifies the UE of the initial HFN, and the UE infers the initial HFN and SN from the first received PDCP PDU. For the SN part, the options are the same as those for the V2X mechanism in Rel-16, namely: "The initial value of the SN part of RX_NEXT is (x+1) modulo(2[sl-PDCP-SN-Size]), where x is the SN of the first received PDCP Data PDU" and "For NR sidelink communication for broadcast and groupcast, the initial value of the SN part of RX_DELIV is (x-0.5×2[sl-PDCP-SN-Size-1]) modulo(2[sl-PDCP-SN-Size]), where x is the SN of the first received PDCP Data PDU."

[0281] Regarding the HFN portion, the Rel-16 V2X mechanism does not require transmitter-receiver synchronization because it does not use the HFN for security purposes. That is, "Note: It is up to the UE implementation to select the HFN for RX_NEXT so that the initial value of RX_DELIV is a positive value." Regarding NR MBS, "RAN2 responds that it will wait for SA3 to complete the security study on MBS before discussing the security aspects in RAN2." Therefore, RAN2 should postpone the discussion of the HFN portion until SA3 completes the security study.

[0282] For the above reasons, further discussion should be based on Option B. According to Rel-16 sidelink communications for broadcast and groupcast, and taking into account the advances in SA3 regarding security for NR MBS, RAN2 should at least agree that the UE should set the initial values ​​of state variables from the first received PDCP PDU of MBS data.

[0283] Proposal 3: RAN2 should agree to set the initial value of the SN part of RX_NEXT and RX_DELIV from the first MBS data received by the UE, regardless of whether it is a PTM leg or a PTP leg. Whether the HFN part is notified by the gNB will depend on the progress of SA3 and requires further consideration.

[0284] 8. Simultaneous Reception and UE Assistance Information In particular, PTP (leg) is configured with RLC AM for services that require reliability, and lossless switching is important for service continuity, just as lossless mobility, as noted in Observation 7 in the next section. If Proposal 1 is agreed upon, the UE must support simultaneous reception from both the PTM leg and the PTP leg. That is, similar to the existing PDCP packet duplication, two legs can be activated simultaneously. This is because the PTM leg is received by multiple UEs, and it is easy for the MCS to be suboptimal for a particular UE. Therefore, RAN2 should agree to adopt the use of simultaneous reception for at least a certain period of time during dynamic PTM / PTP switching.

[0285] Proposal 4: RAN2 should agree that the UE supports simultaneous reception from both the PTM leg and the PTP leg for a certain period of time after dynamic PTM / PTP switching.

[0286] If Proposal 3 and Proposal 4 are agreed, the gNB may not actually know whether the UE has successfully started receiving which PDCP SN via the PTM leg. When switching from PTP to PTM, the gNB may not know which PDCP PDUs to send on the PTP leg and when it can stop sending on the PTP leg. To solve this problem, it is proposed that the UE notify the gNB of successful PTM reception and send it over the PTP leg. However, it is unclear whether the UE should also include the PDCP SN information in the same message.

[0287] Observation 4: When switching from PTP to PTM, the gNB may not know from which PDCP PDUs it needs to keep transmitting on the PTP leg, or from which PDCP PDUs the UE can successfully start receiving on the PTM leg.

[0288] Similarly, when switching from PTM to PTP, the gNB may not know which PDCP SN the UE successfully received over the PTM leg (especially if the UE is in poor radio conditions), which means that the gNB may not know which PDCP PDU to use at the start of the PTP leg.

[0289] Observation 5: When switching from PTM to PTP, the gNB may not know from which PDCP PDU the PTP leg should start transmitting, or which PDCP PDU the UE has successfully received via the PTM leg.

[0290] Therefore, it is considered that the UE notifies the gNB of the SN information via the PTP leg during dynamic PTM / PTP switching. When the UE reports the SN information during dynamic switching between PTM and PTP, it is easy to reuse the PDCP control PDU, i.e., the PDCP status report containing FMC (first PDCP SDU not found) and an optional bitmap (indicating whether subsequent PDCP SDUs are not found or are correctly received). On the other hand, it is also an option for the UE to report the SN of the first / last PDCP PDU successfully received via the PTM leg. Therefore, further discussion is needed on what the UE should report during dynamic switching between PTM and PTP.

[0291] In both of the above cases (i.e., when switching from PTP to PTM and when switching from PTM to PTP), when a dynamic switchover occurs (e.g., when activating / deactivating a MAC CE), a PDCP control PDU containing PDCP SN information for service continuity needs to be triggered.

[0292] Proposal 5: RAN2 should consider whether UEs should send PDCP control PDUs containing PDCP SN information during dynamic switching to ensure service continuity. Whether PDCP information reports can be reused needs further study.

[0293] Another issue is whether lossless bearer type change, similar to the lossless dynamic switching in Proposal 5, is necessary. Bearer type change, including PTP (leg) with RLC AM, is considered to require reliability similar to dynamic switching from the viewpoint of service continuity and lossless mobility, as stated in Observation 8 in the next section. Therefore, RAN2 should consider whether to support lossless bearer type change. If it does, PDCP control PDUs should be reused as UE assistance information, as in Proposal 5.

[0294] Proposal 6: RAN2 should discuss whether lossless bearer type change with RRC reconfiguration, i.e., the same solution as lossless dynamic switching via PDCP control PDUs as in Proposal 5, is applicable.

[0295] 9. Mobility Operations RAN2 aims to support services requiring lossless handover for MBS-MBS mobility (detailed scenarios are yet to be determined, but at least PTP-PTP) and agreed that PDCP status reporting from the UE side may also be supported. These agreements imply a mechanism very similar to the existing handover for unicast when the MRB is configured with PTP only.

[0296] Viewpoint 6: Even in an MRB configured with only PTP, it is possible to reuse the existing handover mechanism for unicast and support lossless handover.

[0297] Therefore, the case of handover including PTM (leg) should be considered, that is, an MRB configured with only PTM and a split MRB including a PTP leg and a PTM leg.

[0298] Regarding split MRB, if the PTM leg is deactivated, it can be considered as a PTP-only MRB. Therefore, lossless handover can be easily supported based on the existing unicast handover. Therefore, the basic procedure of split MRB can be considered as follows:

[0299] Step 1: The PTM leg of the split MRB is deactivated in the source cell by lossless dynamic switching. Step 2: The UE performs a lossless handover, like a PTP-PTP handover (or like a unicast handover). Step 3: The PTM legs of the split MRB are activated in the target cell as needed by lossless dynamic switching.

[0300] In this procedure, the lossless dynamic switching described in Proposal 5 plays an important role.

[0301] Observation 7: Lossless dynamic PTM / PTP switching is essential for lossless handover in split MRB.

[0302] For PTM-only MRBs, a very similar procedure can be applied as follows.

[0303] Step 1: A PTM-only MRB is reconfigured to a PTP-only MRB (or split MRB) in the source cell due to a change in lossless bearer type. Step 2: The UE performs a lossless handover, like a PTP-PTP handover (or like a unicast handover). Step 3: The PTP-only MRB (or split MRB) is reconfigured to a PTM-only MRB in the target cell as needed due to a lossless bearer type change.

[0304] In this case, the change of lossless bearer type described in proposal 6 is also important for lossless handover.

[0305] Observation 8: Lossless bearer type change is essential for lossless handover of split MRB.

[0306] From the above, the key points of the basic procedure for lossless handover are to deactivate the PTM leg or reconfigure the PTM-only MRB (i.e., step 1), and the execution of the handover is the same as the existing unicast handover, with no enhancements.

[0307] Proposal 7: RAN2 should agree that the basic lossless handover of MRB should always include PTP (leg), i.e., the PTM leg of a split MRB should be deactivated before the handover is performed, or a PTM-only MRB should be reconfigured to a PTP-only MRB (or split MRB).

[0308] Proposal 8: RAN2 should agree that the handover implementation for MBS is the same as for unicast, i.e. no extensions for basic lossless handover are required.

[0309] In other words, a UE receiving MBS via a PTM leg performs a lossless handover. This reduces the signaling overhead and complexity of the basic handover procedure described above. In other words, steps 1 and 3 can be omitted. Furthermore, this type of direct PTM-PTM lossless handover is expected to be used, particularly in split MRBs with PTP legs configured with RLC AM, i.e., services requiring higher reliability. However, we are already past the midpoint of Rel-17, and the WID only states that it "specifies support for basic mobility with service continuity." Therefore, advanced lossless handover should be postponed to a future release.

[0310] Observation 9: Advanced lossless handover for UEs receiving MBS services via PTM (leg), i.e., "direct PTM-PTM handover," may be useful for certain services, but should be postponed to a future release given the time remaining in the Rel-17 timeframe. [Explanation of symbols]

[0311] 1: Mobile communication system 10:RAN 20 :CN 100:UE 110: Receiving unit 120: Transmitter 130: Control unit 200 :gNB 210: Transmission unit 220: Receiving unit 230: Control unit 240: Backhaul communication unit

Claims

[Claim 1] A user equipment in a mobile communication system supporting a Multicast Broadcast Service (MBS), comprising: A receiving unit configured to receive an MBS session provided by the first cell in a Point-to-Multipoint (PTM) manner from the first cell when the user equipment is in a Radio Resource Control (RRC) connected state with respect to the first cell, the receiving unit receives, in response to a second network node that manages a second cell receiving a handover request message from a first network node that manages the first cell, an RRC Reconfiguration message that instructs a handover to the second cell from the first cell; The receiving unit receives the MBS session provided from the second cell after the handover, The RRC Reconfiguration message includes an MBS reception setting for receiving the MBS session provided by the second cell; The handover request message includes information indicating a broadcast session that the user equipment is receiving or is interested in receiving. User equipment.

Images