Communication method, user equipment and base station

Abstract

A communication method according to a first aspect of the present invention is used in a mobile communication system supporting multicast and broadcast services (MBS), and has the steps of: a first PDCP variable updated according to reception of a PDCP packet during an MBS session in a user equipment management packet data convergence protocol (PDCP) layer that has started receiving the MBS session from a base station, and the user equipment performing control to synchronize the first PDCP variable with a second PDCP variable managed by the base station, in response to determining that reception of the MBS session has been interrupted for a predetermined period of time, to synchronize the first PDCP variable with the second PDCP variable.

Description

[0001] This application is a divisional application of Chinese invention patent application No. 202280067089.6, filed on August 3, 2022, entitled "Communication Method, User Equipment and Base Station". Technical Field

[0002] This disclosure relates to a communication method, user equipment, and base station used in a mobile communication system. Background Technology

[0003] The 3rd Generation Partnership Project (3GPP) standards have defined the technical specifications for New Radio (NR) as a fifth-generation (5G) radio access technology. Compared to Long Term Evolution (LTE) as a fourth-generation (4G) radio access technology, NR has features such as high speed, high capacity, high reliability, and low latency. The technical specifications for establishing 5G / NR multicast and broadcast services (MBS) have been discussed in 3GPP (see, for example, Non-Patent Literature 1).

[0004] Reference List

[0005] Non-patent literature

[0006] Non-patent document 1: 3GPP document: RP-201038, "WID revision: NR Multicast and Broadcast Services" Summary of the Invention

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

[0008] In view of this, this disclosure provides a communication method, user equipment, and base station capable of implementing enhanced multicast and broadcast services.

[0009] In a first aspect, the communication method is used in a mobile communication system for supporting multicast and broadcast services (MBS). The communication method includes: a user equipment receiving a radio resource control (RRC) reconfiguration message from a base station, the RRC reconfiguration message including an MBS session identifier for the MBS session, an identifier associated with the MRB to which the MBS session is mapped, and a superframe number (HFN) corresponding to the MBS session.

[0010] In a second aspect, the user equipment is used in a mobile communication system for supporting multicast and broadcast services (MBS). The user equipment includes a receiver configured to receive a Radio Resource Control (RRC) reconfiguration message from a base station. The RRC reconfiguration message includes an MBS session identifier for the MBS session, an identifier associated with the MRB to which the MBS session is mapped, and a superframe number (HFN) corresponding to the MBS session.

[0011] In a third aspect, the base station is used in a mobile communication system supporting multicast and broadcast services (MBS). The base station includes a transmitter configured to send a Radio Resource Control (RRC) reconfiguration message to a user equipment, the RRC reconfiguration message including an MBS session identifier for the MBS session, an identifier associated with the MRB to which the MBS session is mapped, and a superframe number (HFN) corresponding to the MBS session.

[0012] In a fourth aspect, the communication method is used in a mobile communication system supporting multicast and broadcast services (MBS). The communication method includes: a user equipment that has begun receiving an MBS session from a base station managing a first PDCP variable updated in response to the reception of Packet Data Convergence Protocol (PDCP) packets in the MBS session, the first PDCP variable being managed at the PDCP layer; and, in response to determining that reception of the MBS session has been interrupted for a predetermined time, the user equipment performing control to synchronize the first PDCP variable with a second PDCP variable managed by the base station.

[0013] In a fifth aspect, the user equipment is used in a mobile communication system for supporting multicast and broadcast services (MBS). The user equipment includes a controller configured to: upon initiating reception of an MBS session from a base station, manage a first PDCP variable updated in response to the reception of Packet Data Convergence Protocol (PDCP) packets in the MBS session, the first PDCP variable being managed at the PDCP layer. The controller, in response to determining that reception of the MBS session has been interrupted for a predetermined time, performs control to synchronize the first PDCP variable with a second PDCP variable managed by the base station.

[0014] In a sixth aspect, the base station is used in a mobile communication system for supporting multicast and broadcast services (MBS). The base station includes: a controller configured to manage a first PDCP variable updated in response to the transmission of Packet Data Convergence Protocol (PDCP) packets in the MBS session upon commencement of an MBS session, the first PDCP variable being managed at the PDCP layer; a receiver configured to receive a request from a user equipment for checking the PDCP variable; and a transmitter configured to transmit the PDCP variable to the user equipment in response to the request. Attached Figure Description

[0015] Figure 1 This is a diagram illustrating the configuration of a mobile communication system according to an embodiment.

[0016] Figure 2 This is a diagram illustrating the configuration of a user equipment (UE) according to an embodiment.

[0017] Figure 3 This is a diagram illustrating the configuration of a gNB (base station) according to an embodiment.

[0018] Figure 4 This is a diagram illustrating the configuration of the protocol stack for the user plane radio interface that processes data.

[0019] Figure 5 This is a diagram showing the configuration of the protocol stack of the radio interface of the control plane that processes signaling (control signals).

[0020] Figure 6 This is a diagram illustrating an overview of MBS service transmission according to an embodiment.

[0021] Figure 7 This is a diagram illustrating the transmission mode according to an embodiment.

[0022] Figure 8 This is a diagram illustrating a segmented multicast radio bearer (MRB) according to an embodiment.

[0023] Figure 9 This is a diagram illustrating an operational scenario of a mobile communication system according to an embodiment.

[0024] Figure 10 This is a diagram illustrating an example of a PDCP variable according to an embodiment.

[0025] Figure 11 This is a diagram illustrating PDCP data PDU according to an embodiment.

[0026] Figure 12 This is a diagram illustrating the operation of identifying RCVD_COUNT according to an embodiment, where RCVD_COUNT is the COUNT value of the PDCP data PDU received in the UE (receiving-side PDCP entity).

[0027] Figure 13 This is a diagram illustrating the operation of the receiving-side PDCP entity of the UE according to an embodiment.

[0028] Figure 14 This is a diagram illustrating the operation of the UE according to an embodiment.

[0029] Figure 15 This is a diagram illustrating an example of the operation of a mobile communication system according to an embodiment.

[0030] Figure 16 This is a diagram illustrating another example of the operation of a mobile communication system according to an embodiment.

[0031] Figure 17 This diagram illustrates the PDCP fixed-type PTM / PTP handover based on the current protocol. Detailed Implementation

[0032] A mobile communication system according to an embodiment is described with reference to the accompanying drawings. In the description of the drawings, the same or similar reference numerals denote the same or similar parts.

[0033] Configuration of mobile communication system

[0034] Figure 1 This diagram illustrates the configuration of a mobile communication system 1 according to this embodiment. The mobile communication system 1 conforms to the 3GPP standard for a fifth-generation system (5GS). The following description uses 5GS as an example, but a Long Term Evolution (LTE) system can be applied at least partially to the mobile communication system. A sixth-generation (6G) system can also be applied at least partially to the mobile communication system.

[0035] The mobile communication system 1 includes a user equipment (UE) 100, a 5G radio access network (Next Generation Radio Access Network (NG-RAN)) 10, and a 5G core network (5GC) 20. In the following text, NG-RAN 10 may be simply referred to as RAN 10. 5GC 20 may be simply referred to as the core network (CN) 20.

[0036] UE 100 is a mobile wireless communication device. UE 100 can be any device, as long as it is used by a user. Examples of UE 100 include mobile phone terminals (including smartphones) or tablet terminals, laptop PCs, communication modules (including communication cards or chipsets), sensors or devices mounted on sensors, vehicles or devices mounted on vehicles (vehicle UE), and flying objects or devices mounted on flying objects (airborne UE).

[0037] NG-RAN 10 includes base stations (referred to as "gNBs" in 5G systems) 200. gNBs 200 are interconnected via an Xn interface, which serves as an inter-base station interface. Each gNB 200 manages one or more cells. gNBs 200 perform wireless communication with UE 100, which has established a connection to a cell of the gNB 200. gNBs 200 have radio resource management (RRM) functions, functions for routing user data (hereinafter referred to as "data"), measurement and control functions for mobility control and scheduling, etc. "Cell" is used as a term to represent the smallest unit of a wireless communication area. "Cell" is also used as a term to represent the functions or resources used to perform wireless communication with UE 100. A cell belongs to a carrier frequency (hereinafter referred to as "frequency").

[0038] Note that a gNB can connect to the Evolved Packet Core (EPC) corresponding to the LTE core network. LTE base stations can also connect to the 5GC. LTE base stations and gNBs can connect via an inter-base station interface.

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

[0040] Figure 2 This diagram illustrates the configuration of a UE 100 (User Equipment) according to this embodiment. UE 100 includes a receiver 110, a transmitter 120, and a controller 130. The receiver 110 and transmitter 120 constitute a wireless communication device that performs wireless communication with the gNB 200.

[0041] Receiver 110 performs various types of reception under the control of controller 130. Receiver 110 includes an antenna and receiving equipment. The receiving equipment converts the radio signals received through the antenna into baseband signals (received signals) and outputs the obtained signals to controller 130.

[0042] Transmitter 120 performs various types of transmissions under the control of controller 130. Transmitter 120 includes an antenna and a transmitting device. The transmitting device converts the baseband signal (transmit signal) output by controller 130 into a radio signal and transmits the obtained signal through the antenna.

[0043] Controller 130 performs various types of control and processing within UE 100. This processing includes the processing of various layers, which will be described later. Controller 130 includes at least one processor and at least one memory. The memory stores programs to be executed by the processor and information for the processing performed by the processor. The processor may include a baseband processor and a central processing unit (CPU). The baseband processor performs modulation and demodulation, encoding and decoding of baseband signals, etc. The CPU executes programs stored in the memory, thereby performing various types of processing.

[0044] Figure 3 This diagram illustrates the configuration of the gNB 200 (base station) according to this embodiment. The gNB 200 includes a transmitter 210, a receiver 220, a controller 230, and a backhaul communicator 240. The transmitter 210 and receiver 220 constitute a wireless communication device for performing wireless communication with the UE 100. The backhaul communicator 240 constitutes a network communicator for performing communication with the CN 20.

[0045] Transmitter 210 performs various types of transmissions under the control of controller 230. Transmitter 210 includes an antenna and a transmitting device. The transmitting device converts the baseband signal (transmit signal) output by controller 230 into a radio signal and transmits the obtained signal through the antenna.

[0046] Receiver 220 performs various types of reception under the control of controller 230. Receiver 220 includes an antenna and receiving equipment. The receiving equipment converts the radio signals received through the antenna into baseband signals (received signals) and outputs the resulting signals to controller 230.

[0047] Controller 230 performs various types of control and processing within gNB 200. This processing includes the processing of various layers, which will be described later. Controller 230 includes at least one processor and at least one memory. The memory stores programs to be executed by the processor and information for the processing performed by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation and demodulation, encoding and decoding of baseband signals, etc. The CPU executes programs stored in the memory, thereby performing various types of processing.

[0048] The backhaul communicator 240 is connected to an adjacent base station via the Xn interface between base stations. The backhaul communicator 240 is connected to the AMF / UPF 300 via the NG interface between the base station and the core network. Note that the gNB 200 may include a central unit (CU) and a distributed unit (DU) (i.e., functions are divided), and these two units may be connected via the F1 interface, which serves as the fronthaul interface.

[0049] Figure 4This is a diagram illustrating the configuration of the protocol stack for the user plane radio interface that processes data.

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

[0051] The PHY layer performs encoding and decoding, modulation and demodulation, antenna mapping and demapping, and resource mapping and demapping. Data and control information are transmitted between the PHY layer of UE 100 and the PHY layer of gNB 200 via the physical channel. Note that the PHY layer of UE 100 receives downlink control information (DCI) transmitted from gNB 200 via the physical downlink control channel (PDCCH). Specifically, UE 100 blindly decodes the PDCCH using the Radio Network Temporary Identifier (RNTI) and obtains the successfully decoded DCI as the DCI addressed to UE 100. The DCI transmitted from gNB 200 is appended with CRC parity bits scrambled by the RNTI.

[0052] The MAC layer performs data priority control, retransmission processing via Hybrid ARQ (HARQ: Hybrid Automatic Repeat Request), random access procedures, etc. Data and control information are transmitted between the MAC layer of UE 100 and the MAC layer of gNB 200 via the transport channel. The MAC layer of gNB 200 includes a scheduler. The scheduler determines the transport format (transport block size, modulation and coding scheme (MCS)) in the uplink and downlink and the resource blocks to be allocated to UE 100.

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

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

[0055] The SDAP layer performs the mapping between IP flows (as a unit of QoS (Quality of Service) control performed by the core network) and radio bearers (as a unit of QoS control performed by the access layer (AS)). Note that SDAP is not required when the RAN is connected to the EPC.

[0056] Figure 5 This is a diagram showing the configuration of the protocol stack of the radio interface of the control plane that processes signaling (control signals).

[0057] The protocol stack for the control plane's radio interface includes a Radio Resource Control (RRC) layer and a Non-Access Stratum (NAS) layer, rather than... Figure 4 The SDAP layer is shown in the figure.

[0058] RRC signaling for various configurations is transmitted between the RRC layer of UE 100 and the RRC layer of gNB 200. The RRC layer controls logical channels, transport channels, and physical channels based on the establishment, re-establishment, and release of radio bearers. UE 100 is in an RRC connected state when a connection exists between the RRC of UE 100 and the RRC of gNB 200 (RRC connected). UE 100 is in an RRC idle state when no connection exists between the RRC of UE 100 and the RRC of gNB 200. UE 100 is in an RRC inactive state when the connection between the RRC of UE 100 and the RRC of gNB 200 is suspended.

[0059] The NAS layer, located above the RRC layer, performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of UE 100 and the NAS layer of AMF 300A. Note that UE 100 includes an application layer in addition to the radio interface protocol. Layers lower than the NAS layer are called AS layers.

[0060] Overview of MBS

[0061] An overview of MBS according to this embodiment will be described. MBS is a service in which NG-RAN 10 can provide broadcast or multicast, i.e., point-to-multipoint (PTM) data transmission to UE100. It is assumed that use cases (service types) for MBS include public safety communications, mission-critical communications, vehicle-to-everything (V2X) communications, IPv4 or IPv6 multicast delivery, Internet Protocol Television (IPTV), group communications, and software delivery.

[0062] Broadcast service provides services to every UE 100 within a specific service area for applications that do not require high-reliability QoS. The MBS session used for broadcast service is called a broadcast session.

[0063] Multicast service is not provided to each individual UE 100, but rather to a group of UE 100 participating in the multicast service (multicast session). The MBS session used for multicast service is called a multicast session. Multicast service can provide the same content to this group of UE 100 using methods that are more radio efficient than broadcast service.

[0064] Figure 6 This is a diagram illustrating an overview of MBS service transmission according to this embodiment.

[0065] MBS services (MBS data) are transmitted from a single data source (application service provider) to multiple UEs. The 5G CN (5GC) 20, which is the core network of the 5G network, receives MBS data from the application service provider and performs replication of the MBS data to transmit the replication artifacts.

[0066] From the perspective of 5GC 20, two multicast transmission methods are possible: 5GC shared MBS service transmission, and 5GC individual MBS service transmission.

[0067] In the 5GC's respective MBS service transmission method, the 5GC 20 receives a single copy of the MBS data packets and transmits these MBS data packets to each UE 100 via the PDU session of each UE 100. Therefore, one PDU session for each UE 100 needs to be associated with a multicast session.

[0068] In the 5GC shared MBS service transmission method, 5GC 20 receives a single copy of the MBS data packet and transmits this single copy of the MBS data packet to the RAN node (i.e., gNB 200). gNB 200 receives the MBS data packet via the MBS tunnel connection and transmits the MBS data packet to one or more UEs 100.

[0069] From the perspective of RAN (5G RAN)10, for the radio transmission of MBS data in the 5GC shared MBS service transmission method, two transmission methods are possible: point-to-point (PTP) transmission method and point-to-multipoint (PTM) transmission method. PTP stands for unicast, and PTM stands for multicast and broadcast.

[0070] In the PTP transmission method, the gNB 200 wirelessly transmits individual copies 100 of MBS data packets to each UE. Conversely, in the PTM transmission method, the gNB 200 wirelessly transmits a single copy of the MBS data packets to a group of UEs 100. The gNB 200 can dynamically determine whether to use the PTM or PTP transmission method for transmitting MBS data to a single UE 100.

[0071] PTP and PTM transmission methods are primarily related to the user plane. The modes used to control MBS data transmission include two transmission methods: a first transmission method and a second transmission method.

[0072] Figure 7 This is a diagram illustrating the transmission mode according to this embodiment.

[0073] The first transport mode (transport mode 1 (DM1)) is a transport mode that can be used by UE 100 in RRC connected state and is a transport mode for high QoS requirements. The first transport mode is used for multicast sessions within MBS sessions. Note that the first transport mode can also be used for broadcast sessions. The first transport mode is available to UE 100 in RRC idle state or RRC inactive state.

[0074] MBS receive configuration in the first transmission mode is performed using UE-specific signaling. For example, MBS receive configuration in the first transmission mode is performed via an RRC reconfiguration message (or an RRC release message), which is an RRC message unicast from gNB200 to UE 100.

[0075] MBS receive configuration includes MBS service channel configuration information (hereinafter referred to as "MTCH configuration information") regarding the configuration of MBS service channels carrying MBS data. MTCH configuration information includes MBS session information related to the MBS session and scheduling information of the MBS service channels corresponding to the MBS session. The scheduling information of the MBS service channels may include discontinuous reception (DRX) configuration of the MBS service channels. Discontinuous reception configuration may include at least one of the following parameters: a timer value for defining the start period (start duration: receive period) (start duration timer), a timer value for extending the start period (inactive timer), a scheduling interval or DRX period (scheduling period, DRX period), an offset value for the starting subframe of the scheduling period or DRX period (start offset, DRX period offset), a start delay slot value for the start period timer (slot offset), a timer value for defining the maximum time before retransmission (retransmission timer), and a timer value for defining the minimum interval before the DL assignment of HARQ retransmission (HARQ RTT timer).

[0076] Note that the MBS traffic channel is a logical channel and can be referred to as the MTCH. The MBS traffic channel is mapped to the downlink shared channel (DL-SCH), which serves as a transport channel.

[0077] The second transport mode (transport mode 2 (DM2)) is a transport mode that can be used not only by UE 100 in RRC connected state but also by UE 100 in RRC idle state or RRC inactive state, and is a transport mode for low QoS requirements. The second transport mode is used for broadcast sessions within MBS sessions. However, the second transport mode can also be used for multicast sessions.

[0078] MBS reception configuration in the second transport mode is performed via broadcast signaling. For example, MBS reception configuration in the second transport mode is performed using logical channels (e.g., Broadcast Control Channel (BCCH) and / or Multicast Control Channel (MCCH)) broadcast from gNB200 to UE 100. For example, UE 100 can use dedicated RNTIs predefined in the technical specifications to receive the BCCH and MCCH. The RNTI for BCCH reception can be an SI-RNTI, and the RNTI for MCCH reception can be an MCCH-RNTI.

[0079] In the second transmission mode, UE 100 can receive MBS data in the following three processes. First, UE 100 receives MCCH configuration information about the SIB (MBS-SIB) sent from gNB 200 on the BCCH. Second, UE 100 receives the MCCH from gNB 200 based on the MCCH configuration information. On the MCCH, MTCH configuration information is sent. Third, UE 100 receives the MTCH (MBS data) based on the MTCH configuration information. In the following text, the MTCH configuration information and / or MCCH configuration information may be referred to as the MBS receive configuration.

[0080] In both the first and second transmission modes, UE 100 can use the group RNTI (G-RNTI) assigned from gNB 200 to receive MTCH. The G-RNTI corresponds to the RNTI used for MTCH reception. The G-RNTI can be included in the MBS reception configuration (MTCH configuration information).

[0081] The network can provide different MBS services for different MBS sessions. An MBS session is identified by at least one of the following: Temporary Mobility Group Identifier (TMGI), source-specific IP multicast address (which includes source unicast IP addresses such as application functions and application servers, as well as IP multicast addresses indicating the destination address), session identifier, and G-RNTI. At least one of the following is called the MBS session identifier: TMGI, G-RNTI, source-specific IP multicast address, and session identifier. TMGI, source-specific IP multicast address, session identifier, and G-RNTI are collectively referred to as MBS session information.

[0082] Figure 8 This diagram illustrates a segmented multicast radio bearer (MRB) according to this embodiment. The MRB can be a type of data radio bearer (DRB). The segmented MRB can be used in the first transmission mode described above.

[0083] The gNB 200 can configure MRB segmentation into the PTP and PTM communication paths for UE 100. This allows the gNB 200 to dynamically switch the transmission of MBS data to UE 100 between PTP and PTM. The gNB 200 can use both PTP and PTM to perform duplicate transmissions of the same MBS data to enhance reliability. In the following text, the PTP communication path is referred to as the PTP tributary, and the PTM communication path is referred to as the PTM tributary. The functional unit corresponding to each layer is referred to as an entity.

[0084] The predetermined layer for terminating the segmentation is the MAC layer (HARQ), RLC layer, PDCP layer, or SDAP layer. Although the following description will primarily focus on an example where the predetermined layer for terminating the segmentation is the PDCP layer, the predetermined layer can be the MAC layer (HARQ), RLC layer, or SDAP layer.

[0085] Each entity in the PDCP entity of gNB 200 and UE 100 divides the MRB (which is the bearer for MBS (data radio bearer)) into PTP tributaries and PTM tributaries. Note that a PDCP entity is provided for each bearer.

[0086] Each of the gNB 200 and UE 100 includes two RLC entities for the corresponding tributary: a MAC entity and a PHY entity. A PHY entity may be provided for each tributary. Note that in dual connectivity where UE 100 communicates with two gNB 200s, UE 100 may include two MAC entities.

[0087] The PHY entity uses a cell RNTI (Cell Radio Network Temporary Identifier (C-RNTI)) assigned one-to-one to UE 100 to transmit and receive data in the PTP tributary. The PHY entity uses a G-RNTI assigned one-to-one to the MBS session to transmit and receive data in the PTM tributary. The C-RNTI is different for each UE 100, but the G-RNTI is a common RNTI for multiple UE 100s receiving data in an MBS session.

[0088] To perform PTM transmission (multicast or broadcast) of MBS data from gNB 200 to UE 100 using the PTM tributary, a segmented MRB needs to be configured from gNB 200 to UE 100, and the PTM tributary needs to be activated (activated). In other words, even if a segmented MRB is configured for UE 100, gNB 200 cannot use the PTM tributary to perform PTM transmission of MBS data when the PTM tributary is in an inactive state.

[0089] For gNB 200 and UE 100 to use the PTP tributary for PTP (unicast) transmission of MBS data, a segmented MRB needs to be configured from gNB 200 to UE 100, and the PTP tributary needs to be activated. In other words, even if a segmented MRB is configured for UE 100, gNB 200 cannot use the PTP tributary for PTP transmission of MBS data when the PTP tributary is deactivated.

[0090] When the PTM tributary is active, UE 100 monitors the PDCCH that uses the G-RNTI associated with the MBS session (i.e., uses G-RNTI to perform blind decoding of the PDCCH). UE 100 can monitor the PDCCH only at the scheduling time of the MBS session.

[0091] When the PTM tributary is in a deactivated state, the UE 100 does not monitor the PDCCH that uses G-RNTI associated with the MBS session (i.e., it does not perform blind decoding of the PDCCH using G-RNTI).

[0092] When the PTP tributary is active, UE 100 monitors the PDCCH with C-RNTI applied. When Discontinuous Receiver Optimization (DRX) is configured in the PTP tributary, UE 100 monitors the PDCCH for the configured OnDuration period. When a cell (frequency) associated with an MBS session is specified, UE 100 can monitor the PDCCH for that cell even when the cell is deactivated.

[0093] When the PTP tributary is in an inactive state, UE 100 can monitor the PDCCH with C-RNTI applied to prepare for normal unicast downlink transmissions other than MBS data. Note that when specifying a cell (frequency) associated with an MBS session, UE 100 does not need to monitor the PDCCH for that MBS session.

[0094] Note that the above-mentioned segmented MRB is configured via an RRC message (e.g., an RRC reconfiguration message) sent by the RRC entity of gNB 200 to the RRC entity of UE 100.

[0095] Operation of mobile communication systems

[0096] Figure 9 This is a diagram illustrating an operational scenario of the mobile communication system 1 according to this embodiment.

[0097] gNB 200 transmits data to multiple UEs 100 via PTM (multicast or broadcast). Figure 9In the example, UE 100a to UE 100c transmits MBS data for a specific MBS session. The RRC state of each UE 100 can be any state (RRC connected, RRC idle, or RRC inactive). The MBS transmission mode can be either the first transmission mode or the second transmission mode. MBS transmission in the first transmission mode can use PTM tributaries.

[0098] In the PDCP layer, gNB 200 includes a PDCP entity 201 associated with the MBS session (specifically, a transmit-side PDCP entity associated with a multicast radio bearer (MRB) belonging to the MBS session). When PDCP entity 201 initiates transmission of the MBS session, PDCP entity 201 manages PDCP variables updated in response to the transmission of PDCP packets in the MBS session.

[0099] In the PDCP layer, each UE 100 includes a PDCP entity 101 associated with the MBS session (specifically, a receive-side PDCP entity associated with the MRB belonging to the MBS session). When each PDCP entity 101 (in Figure 10 In the example, when PDCP entities 101a to 101b begin transmitting an MBS session, PDCP entity 101 manages the PDCP variables updated in response to the reception of PDCP packets in the MBS session.

[0100] like Figure 10 As shown, a PDCP variable can be a count value (COUNT value), which includes the superframe number (HFN) that counts up each round of PDCP sequence numbering, and the PDCP sequence number (PDCP SN). For example, the COUNT value has a bit length of 32 bits, the PDCP SN has a bit length of 12 bits or 18 bits (SN_length), and the HFN has a bit length obtained by subtracting the bit length of the PDCP SN from the bit length of the COUNT value. The bit length of the PDCP SN can be configured using RRC signaling. Note that the term "PDCP variable" does not necessarily refer to the COUNT value and can also be used as a term to refer to various variables (HFN, PDCP SN, etc.) processed in the PDCP layer.

[0101] Figure 11 This is a diagram illustrating the PDCP packets (specifically, PDCP Data Protocol Data Units (PDUs)) that constitute MBS data. Figure 11As shown, the PDCP data PDU includes a PDCP SN, data, and a MAC-I. The PDCP SN is a sequence number sequentially assigned to the PDCP data PDU. The data corresponds to a PDCP service data unit (SDU). The MAC-I corresponds to a message authentication code. The PDCP data PDU may not include the MAC-I. As described above, the PDCP data PDU includes the PDCP SN but does not include the HFN. Therefore, each of the gNB 200 and the UE 100 needs to update the HFN in response to the transmission and reception of the PDCP data PDU. Specifically, the HFN is incremented whenever the PDCP sequence number goes through a cycle.

[0102] Figure 12 FIG. is a diagram illustrating an operation for identifying RCVD_COUNT, which is a COUNT value of a PDCP data PDU received in the UE 100 (receiving-side PDCP entity). Here, the PDCP SN included in the received PDCP data PDU is referred to as RCVD_SN.

[0103] First, when RCVD_SN < SN(RX_DELIV) - Window_Size, RCVD_HFN = HFN(RX_DELIV) + 1. Here, RX_DELIV is a variable indicating the oldest PDCP SDU to be received and not yet provided to the upper layer. The initial value of RX_DELIV is zero. Window_Size is a constant indicating the size of the reordering window.

[0104] Second, when RCVD_SN ≥ SN(RX_DELIV) + Window_Size, RCVD_HFN = HFN(RX_DELIV) - 1.

[0105] Third, when neither of the above conditions is met, RCVD_HFN = HFN(RX_DELIV).

[0106] Then, set RCVD_COUNT = [RCVD_HFN, RCVD_SN].

[0107] Figure 13 FIG. is a diagram illustrating an operation of the receiving-side PDCP entity 101 of the UE 100.

[0108] First, when the receiving-side PDCP entity 101 receives a PDCP PDU, the receiving-side PDCP entity 101 performs security processing (specifically, decryption / integrity verification) on the PDCP PDU using a count value (RCVD_COUNT) (step S11). And when the receiving-side PDCP entity 101 fails in the integrity verification (step S12: yes), the receiving-side PDCP entity 101 notifies the higher layer of the integrity verification failure and discards the PDCP PDU (step S13).

[0109] When the receiving PDCP entity 101 succeeds in integrity verification (step S12: No), and the count value (RCVD_COUNT) is less than RX_DELIV (step S14: Yes) or RCVD_COUNT has been received (step S16: Yes), the receiving PDCP entity 101 discards the PDCP PDU (step S15).

[0110] Next, the receiving-side PDCP entity 101 stores the undiscarded PDCP PDUs in the receive buffer (step S17), and when "RCVD_COUNT ≥ RX_NEXT" (step S18: Yes), the receiving-side PDCP entity 101 updates RX_NEXT to RCVD_COUNT + 1 (step S19). Here, RX_NEXT is a variable indicating the count value (RCVD_COUNT) of the expected next PDCP SDU to be received. The initial value of RX_NEXT is zero. When out-of-order delivery is configured (step S20: Yes), the receiving-side PDCP entity 101 decompresses the header of the PDCP PDU and then transmits the result to the higher layer (step S21). Specifically, when "outOfOrderDelivery" is configured in the RRC, the receiving-side PDCP entity 101 performs the operation of S21. Out-of-order delivery is the operation of transmitting packets to the higher layer without performing order control. Therefore, as in step S21, immediately after the packet is received and stored in the buffer, the packet is transmitted to the higher layer. Note that when step S20 is "No", sequence control is performed.

[0111] When “RCVD_COUNT = RX_DELIV” (step S22: Yes), the receiving-side PDCP entity 101 decompresses the headers of all COUNT consecutive PDCP SDUs starting from COUNT = RX_DELIV and then transmits the results to the higher layer (step S23), and updates RX_DELIV to the first (lowest) COUNT value that has not yet been transmitted to the higher layer (step S24).

[0112] When T-Reordering is running and "RX_DELIV≥RX_REORD" (step S25: Yes), the receiving-side PDCP entity 101 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 after the COUNT value associated with the PDCP data PDU used to trigger T-Reordering.

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

[0114] As described above, the receiving-side PDCP entity 101 of UE 100 updates the PDCP variables in response to receiving PDCP packets (PDCP data PDUs) from gNB 200. Specifically, the receiving-side PDCP entity 101 of UE 100 configures the initial value of the PDCP variables to zero and updates the PDCP variables (incrementing or counting up) in response to receiving packets from gNB 200.

[0115] Regarding PDCP packets (PDCP data PDUs), when integrity verification fails, when RCVD_COUNT < RX_DELIV (when it has already been received, etc.), when RCVD_COUNT has already been received, or in similar circumstances, the receiving PDCP entity 101 UE 100 discards the PDCP packet.

[0116] For example, if the receiving-side PDCP entity 101 of UE 100 is unable to receive packets for a period of time or longer due to poor radio conditions, and then resumes receiving packets, the receiving-side PDCP entity 101 may not be able to receive the packets correctly. Specifically, when RCVD_SN >> SN (RX_DELIV), the packet can be considered a previous packet.

[0117] This problem primarily stems from a lack of synchronization between the HFN and gNB 200 and UE 100. This asynchrony can occur when UE 100 is unable to receive MBS reception (PTM reception) for a certain period. This is particularly true in PTM, where the presence of multiple UEs and the lack of Layer 2 feedback increase the likelihood of this situation. Consequently, UE 100 cannot properly perform receive window control, packet reordering, etc., at the PDCP layer, and may be unable to continue MBS reception appropriately. This embodiment is an example used to address this problem.

[0118] Figure 14 This is a diagram illustrating the operation of UE 100 according to this embodiment. UE 100 is... Figure 9 One of UE 100a to UE 100c shown.

[0119] In step S1, UE 100 begins receiving (PTM receive) an MBS session from gNB 200. The MBS session can be a multicast session or a broadcast session.

[0120] In step S2, the receiving-side PDCP entity 101 of UE 100 manages the PDCP variables (hereinafter referred to as "first PDCP variables") updated in response to the receipt of PDCP packets in the MBS session.

[0121] In step S3, UE 100 determines whether the reception of the MBS session has been interrupted for a predetermined time. If the reception of the MBS session has not been interrupted for the predetermined time (step S3: No), the process returns to step S2.

[0122] When it is determined that the reception of the MBS session has been interrupted for a predetermined time (step S3: Yes), in step S4, UE 100 performs control to synchronize the first PDCP variable with the PDCP variable managed by gNB 200 (hereinafter referred to as the "second PDCP variable").

[0123] As described above, in a state where the HFN can be considered to be out of sync between gNB 200 and UE 100, UE 100 can continue MBS reception appropriately by executing control to synchronize the first PDCP variable managed by UE 100 with the second PDCP variable managed by gNB 200.

[0124] Step S4 may include the following steps: sending a request to gNB 200 to check the second PDCP variable, and receiving the second PDCP variable sent from gNB 200 in response to the request. UE 100 may apply the second PDCP variable received from gNB 200 to the first PDCP variable. Therefore, UE 100 may synchronize the first PDCP variable managed by UE 100 with the second PDCP variable managed by gNB 200.

[0125] Here, UE 100 can send an RRC message to gNB 200, which includes a request to check a second PDCP variable and an identifier associated with that request. This identifier may include the MBS session identifier of the MBS session and / or an identifier related to the MRB to which the MBS session is mapped (e.g., MRB identifier, MTCH identifier, QoS flow identifier, etc.). For example, the RRC message may be an MBS interest indication message or a UE auxiliary information message.

[0126] UE 100 can receive a message from gNB 200 that includes a second PDCP variable and an identifier associated with that second PDCP variable. This identifier is the same as and / or similar to the identifier included in the aforementioned RRC message. Note that this message does not need to include the identifier associated with the second PDCP variable. This message can be UE-specific signaling (e.g., an RRC reconfiguration message or a MAC control element (MAC CE)). This message can be broadcast signaling (e.g., MBS-SIB or MCCH).

[0127] Alternatively, the receiving-side PDCP entity 101 of UE 100 may send a PDCP control PDU to gNB 200, the PDCP control PDU including a request for checking a second PDCP variable. In response to receiving the PDCP control PDU, the transmitting-side PDCP entity 201 of gNB 200 may send a PDCP control PDU including the second PDCP variable to the receiving-side PDCP entity 101 of UE 100.

[0128] Step S4 may include re-establishing the PDCP entity (receiving-side PDCP entity 101) for the MBS session. Therefore, in a state where the HFN can be considered out of sync between gNB 200 and UE 100, the first PDCP variable managed by UE 100 can be initialized (reset).

[0129] Step S4 may include setting an initial value for a first PDCP variable. Setting the initial value may include using the PDCP SN included in a PDCP packet (PDCP data PDU) received from the gNB 200 via the MBS session as at least a portion of the initial value. Therefore, the most recent PDCP SN can be applied as at least a portion of the first PDCP variable.

[0130] Figure 15 This is a diagram illustrating an example of the operation of the mobile communication system 1 according to this embodiment.

[0131] In step S101, gNB 200 may send a timer configuration value to UE 100 for measuring a predetermined time. UE 100 receives the timer configuration value. The timer configuration value can be notified to UE 100 using UE-specific signaling (e.g., RRC reconfiguration message). The timer configuration value can also be notified to UE 100 using broadcast signaling (e.g., MBS-SIB or MCCH). Note that the timer configuration value may depend on the implementation of UE 100. The timer configuration value can be configured for each MBS session, each QoS flow, or each G-RNTI.

[0132] In step S102, gNB 200 begins to send PTM (multicast or broadcast) signals to multiple UEs 100 (in... Figure 9 In the example, UE 100a to UE 100c sends MBS data for a certain MBS session. UE 100 starts receiving MBS data and updates UE 100's PDCP variable (first PDCP variable).

[0133] In step S103, UE 100 determines whether UE 100's MBS reception (PTM reception) has failed. For example, when UE 100 fails to decode MBS data in the lower layer, UE 100 determines that UE 100's MBS reception has failed. When it is determined that UE 100's MBS reception has failed (step S103: Yes), in step S104, UE 100 starts the timer with the timer configuration value set above.

[0134] In step S105, UE 100 determines whether its MBS reception (PTM reception) has been successful. For example, when UE 100 successfully decodes the MBS data in the lower layer, UE 100 determines that its MBS reception has been successful. When it is determined that UE 100's MBS reception has been successful (step S105: Yes), in step S106, UE 100 stops the timer. When UE 100's MBS reception has failed (step S105: No), UE 100 does not stop the timer.

[0135] In step S107, UE 100 determines whether the timer has expired. That is, UE 100 determines whether MBS reception has been interrupted for a predetermined time (the time configured by the timer configuration value). If the timer has not expired (step S107: No), UE 100 returns the process to step S105. On the other hand, if the timer has expired (step S107: Yes), UE 100 executes at least one of the processes in steps S108 to S112.

[0136] In step S108, UE 100 can re-establish the PDCP entity (receiving-side PDCP entity 101) for MBS reception. Through this PDCP re-establishment, initial values ​​are automatically assigned to the first PDCP variable (e.g., RX_DELIV) for UE 100. Here, in UE 100, the RRC layer can instruct the PDCP layer (receiving-side PDCP entity 101) to perform PDCP re-establishment. The PDCP layer (receiving-side PDCP entity 101) can automatically perform PDCP re-establishment. When the PDCP layer (receiving-side PDCP entity 101) automatically performs PDCP re-establishment, it can notify the RRC layer of the PDCP re-establishment.

[0137] In step S109, UE 100 sends a check request (interrogation) to gNB 200 regarding the current COUNT value (second PDCP variable) managed by gNB 200. gNB 200 receives the check request (interrogation).

[0138] In step S110, in response to receiving an inspection request (interrogation) from UE 100, gNB 200 sends a COUNT value (second PDCP variable) managed by gNB 200 to UE 100. UE 100 receives the COUNT value (second PDCP variable) managed by gNB 200.

[0139] In step S111, UE 100 applies the COUNT value (second PDCP variable) received from gNB 200 as the COUNT value managed by UE 100. For example, UE 100 sets the COUNT value (second PDCP variable) received from gNB 200 as the first PDCP variable (e.g., RX_DELIV) of the PDCP entity (receiving-side PDCP entity 101) used for MBS reception.

[0140] In step S112, UE 100 uses the first PDCP variable set in step S111 to attempt to receive an MBS session.

[0141] As a variation of the aforementioned timer, the following timer operation can be employed. Specifically, although UE 100 starts the timer in step S104, when UE 100 correctly receives MBS data in S102, UE 100 can start (or reset and restart) the timer. When the timer expires, UE 100 can detect that MBS reception has been interrupted for a predetermined time in the same and / or similar manner as in S107. That is, whenever UE 100 correctly receives MBS data, UE 100 can start (or reset and restart) the timer, and when the timer expires, UE 100 can determine that MBS reception has been interrupted for a predetermined time.

[0142] Figure 16 This is a diagram illustrating another example of the operation of the mobile communication system 1 according to this embodiment. Here, a description will be given. Figure 15 The differences in the operation examples shown.

[0143] The operation of steps S201 to S208 and Figure 15 The operations of steps S101 to S108 are the same and / or similar.

[0144] In step S209, UE 100 may send an inquiry to gNB 200 to check the current HFN (second PDCP variable) managed by gNB 200. gNB 200 receives the inquiry.

[0145] In step S210, in response to receiving an inspection request (interrogation) from UE 100, gNB 200 may send an HFN (second PDCP variable) managed by gNB 200 to UE 100. UE 100 receives the HFN (second PDCP variable) managed by gNB 200.

[0146] Alternatively, UE 100 can infer the HFN managed by gNB 200 (second PDCP variable). For example, UE 100 can generate HFN candidates, use the HFN candidates to attempt integrity verification, and identify the HFN candidates that have succeeded in the integrity verification as the HFN managed by gNB 200 (second PDCP variable).

[0147] In step S211, UE 100 sets the HFN (second PDCP variable) received in step S210 or the HFN (second PDCP variable) determined by UE 100 to the HFN portion of the COUNT value (first PDCP variable) managed by UE 100 (e.g., the HFN portion of RX_DELIV). After RRC re-establishment (step S208), UE 100 can set the HFN (second PDCP variable) received in step S210 or the HFN (second PDCP variable) determined by UE 100 to the initial value of the HFN portion of the COUNT value (first PDCP variable) managed by UE 100.

[0148] In step S212, UE 100 receives MBS session (data) from gNB 200.

[0149] In step S213, UE 100 obtains the PDCP SN of the first PDCP packet (PDCP data PDU) received from gNB 200 in step S212. Then, UE 100 sets the PDCP SN obtained from the first received PDCP packet as the PDCP SN portion of the COUNT value (first PDCP variable) managed by UE 100 (e.g., the PDCP SN portion of RX_DELIV). After RRC re-establishment (step S208), UE 100 can set the PDCP SN obtained from the first received PDCP packet as the initial value of the PDCP SN portion of the COUNT value (first PDCP variable) managed by UE 100.

[0150] Other embodiments

[0151] The above embodiments primarily assume a scenario where UE 100 is unable to receive PTM for a certain period due to radio condition degradation. However, it also assumes that gNB 200 intentionally stops transmitting for a certain period (due to reasons such as lack of data to transmit). Therefore, as in the above embodiments, in the example where a timer detects a predetermined MBS reception interruption, when gNB 200 intentionally interrupts MBS transmission for a predetermined time (due to reasons such as lack of data to transmit), UE 100 also determines that MBS reception is interrupted, and thus UE 100 may perform unnecessary processing. Therefore, when gNB 200 intentionally stops MBS transmission, gNB 200 can send a timer stop indication to UE 100. When UE 100 receives the stop indication, UE 100 stops the timer. When gNB 200 resumes MBS transmission, gNB 200 can send a timer resume indication to UE 100. When UE 100 receives the resume indication, UE 100 resumes the timer. When resumed, the timer can be reset (i.e., set to 0), or it does not need to be reset (i.e., it can resume from the value when it was stopped). Alternatively, when gNB 200 resumes MBS transmission, gNB 200 can resume transmitting MBS data without sending a resumption indication. When UE 100 receives MBS data, UE 100 considers that gNB 200 has resumed MBS transmission and resumes the timer.

[0152] The above operational procedures can be implemented individually and independently, or they can be implemented through a combination of two or more operational procedures. For example, some steps in one operational procedure can be applied to another operational procedure. Some steps in one operational procedure can be replaced by some steps in another operational procedure.

[0153] In the above embodiments and examples, an example of a base station being an NR base station (i.e., gNB) is described; however, the base station could be an LTE base station (i.e., eNB) or a 6G base station. The base station could be a relay node, such as an Integrated Access and Backhaul (IAB) node. The base station could be a DU of an IAB node. The user equipment could be a mobile terminal (MT) of an IAB node.

[0154] A program may be provided that enables a computer to execute each process performed by UE 100 or gNB 200. This program may be recorded on a computer-readable medium. The computer-readable medium allows the program to be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not specifically limited and may, for example, be a recording medium such as a CD-ROM or DVD-ROM. Circuitry for performing the processes to be executed by UE 100 or gNB 200 may be integrated, and at least a portion of UE 100 or gNB 200 may be implemented as a semiconductor integrated circuit (chipset, system-on-chip (SoC)).

[0155] Unless otherwise expressly stated, the phrases “based on” and “depending on” as used in this disclosure do not mean “based on only” and “depending on only”. The phrase “based on” means “based on only” and “at least partially based on” both. Similarly, the phrase “depending on” means “depending on only” and “at least partially dependent on”. “Obtaining” or “getting” can mean obtaining information from stored information, can mean obtaining information from information received from another node, or can mean obtaining information by generating information. The terms “comprising,” “including,” and variations thereof do not mean “including only the said items,” but rather mean “may include only the said items” or “may include not only the said items but also other items.” The term “or” as used in this disclosure is not intended to be an “exclusive or.” Furthermore, any reference to elements in this disclosure using names such as “first” and “second” does not generally limit the number or order of such elements. These names may be used herein as a convenient way to distinguish two or more elements. Therefore, a reference to a first element and a second element does not mean that only the two elements can be used there or that the first element needs to precede the second element in some way. For example, when English articles such as “a,” “one,” and “the” are added in this disclosure by translation, these articles include plural forms unless otherwise explicitly stated in the context.

[0156] The embodiments have been described in detail above with reference to the accompanying drawings, but the specific configurations are not limited to those described above, and various design changes can be made without departing from the spirit of this disclosure.

[0157] This application claims priority to U.S. Provisional Patent Application No. 63 / 229155 (filed August 4, 2021), the entire contents of which are incorporated herein by reference.

[0158] Additional notes

[0159] 1. Introduction

[0160] RAN#88 approved a revision work item related to NR multicast and broadcast services (MBS). Its purpose is to define mobility, including dynamic PTM / PTP handover and service continuity, as shown below.

[0161] The basic RAN functions for broadcast / multicast of UEs in RRC connection state are defined.

[0162] Support for dynamic changes in broadcast / multicast service delivery between multicast (PTM) and unicast (PTP) that provide service continuity for specific UEs is defined.

[0163] Support for basic mobility with service continuity is defined.

[0164] Regarding dynamic PTM / PTP handover, several protocols related to this topic have been reached in RAN2. RAN2#111-e has the following protocols.

[0165] In the case of the UE, the gNB dynamically determines which of the PTM and PTP will be used to transmit multicast data (shared transmission).

[0166] Further research is needed on the reliability of layer processing (in general), the case of ordered delivery / overlapping processing, and how this layer plays a role in the switching between PTM and PTP.

[0167] In RAN2#113-e, the following agreement was reached regarding discussions related to L2 reliability in architectures with dynamic PTM / PTP switching.

[0168] When both PTM and PTP are RLC UMs, L2 ARQ is not available, and configurations with fixed PDCPs for switching between PTM and PTP are supported (e.g., when services typically configured for unicast in RLC UMs).

[0169] In RAN2#113bis-e, further agreements have been reached regarding the architecture and signaling, as shown below.

[0170] protocol

[0171] It should be noted that the following protocol is based solely on the architecture determined to date. Discussions regarding reliability have not yet been completed. In other words, this differs from the scenario outside of RLC UM+RLC UM. Further research is needed on the switching between PTM and PTP in this alternative scenario.

[0172] Dynamic PTM / PTP handover is supported by using segmented MRB bearers (types) that include a common (single) PDCP entity.

[0173] Basically, no new UE-based signaling has been introduced to support the determination of gNB handover (e.g., no PDCP SR for high reliability has been determined).

[0174] Assuming a split MRB with PTM and PTP tributaries configured (agreed during the online session), the use of the PTP tributary cannot be deactivated after the necessary split MRB configuration (i.e., the UE does not need to continuously monitor C-RNTI).

[0175] Assuming a segmented MRB is configured with PTM and PTP branches (agreed upon during the online session), further investigation is needed to determine whether the use of the PTM branch in the segmented MRB can be activated or deactivated, and the details thereof.

[0176] Regarding mobility, in RAN2, only the basic principles listed below are agreed upon.

[0177] R2 aims to support lossless handover of MBS-MBS mobility for services that require this (details of the scenario are undetermined; at least PTP-PTP).

[0178] To support lossless handover of 5G MBS services, it is not necessary to ensure the synchronization of DL PDCP SN and the continuity between the source and target cells in the network. The specific approach designed to achieve this is likely related to WG RAN3.

[0179] In the network, the source gNB can transmit data to the target gNB, and the target gNB transmits the transmitted data. On the other hand, the SN status transfer needs to be enhanced to cover the PDCP SN of the MBS data. Next, the UE receives the MBS in the target cell according to the target configuration.

[0180] The UE can also support PDCP status reporting.

[0181] The remaining issues regarding dynamic PTM / PTP handover and mobility that provide service continuity based on the agreed architecture (i.e., using a segmented MRB fixed to PDCP) will be described in the supplementary notes.

[0182] 2. Discussion

[0183] 3. Segmenting MRB Configuration

[0184] Based on the current protocol, the architecture for fixed-to-PDCP PTM / PTP handover (i.e., segmented MRB) can be as follows: Figure 17 The explanation is as shown.

[0185] Generally, RRC reconfiguration can be considered as providing a bearer configuration including two logical channels (PTM tributary and PTP tributary) and information for receiving multicast sessions. RAN2 describes "assuming a split MRB with PTM and PTP tributaries configured (agreed during online sessions)"; however, it is generally understood that providing a configuration for two of these logical channels associated with a multicast radio bearer with RRC reconfiguration is already a common understanding as preparation for dynamic PTM / PTP handover.

[0186] Observation 1: Prior to dynamic PTM / PTP handover operations, it was generally understood that providing a configuration that associates two logical channels with an MRB that has RRC reconfiguration was a common understanding.

[0187] 4. Dynamic PTM / PTP switching operation

[0188] 5. Signaling

[0189] Further research is needed on whether the use of split MRB and PTM branches can be activated or deactivated, and the details thereof.

[0190] When configuring a split MRB including PTM / PTP tributaries, the UE needs to monitor both the G-RNTI of the PTM tributary and the C-RNTI of the PTP tributary. In LTE SC-PTM, "SC-PTM reception timing is independent of the unicast DRX scheme," meaning the DRXs are different. G-RNTI is received by multiple UEs, while C-RNTI is UE-specific, and the two DRXs are significantly coordinated, thus this concept can be the basis for NRMBS. This means that when the UE needs to continuously monitor G-RNTI, the UE needs to be woken up frequently, which can lead to further power consumption. On the other hand, a connected UE needs to monitor C-RNTI (i.e., C-DRX) for unicast reception; however, this is not an additional burden on the UE.

[0191] Observation 2: In addition to the same PTP tributary transmission timing as C-DRX (i.e., C-RNTI), the UE also needs to be woken up for the PTM tributary transmission timing (i.e., G-RNTI), as in the SC-MTCH timing of LTE SC-PTM.

[0192] When receiving an MRB with PTM / PTM (i.e., during a handover operation), there are four options.

[0193] Option 1: Toggle based on activation / deactivation

[0194] The gNB uses DCI, MAC CE, and RRC signals to instruct the UE to enable / disable the PTM tributary. Besides receiving MBS data via PTM or PTP, this option provides greater flexibility in handling MBS data reception via two tributaries, as in split bearer or PDCP packet redundancy. The UE can reduce power consumption from the deactivated PTM tributary. In the NW implementation, it should be noted that the continuous activation of both tributaries can be determined, and the main points of Option 4 below can be covered.

[0195] Option 2: Switch order / Command-based switching

[0196] The gNB uses DCI, MAC CE, RRC signaling, etc., to instruct the UE to handover between the PTM tributary and the PTP tributary. This option is the same as and / or similar to Option 1 above, and is straightforward because it saves power by deactivating the PTM tributary. However, this option is less flexible for operations related to split bearers, including PDCP packet redundancy. It can be assumed that this option only involves handover between the PTM tributary and the PTP tributary, and neither can be activated.

[0197] Option 3: Switching based on RRC reconfiguration

[0198] The gNB uses RRC reconfiguration to reconfigure either the PTM or PTP as the MRB for the UE. That is, the PTM and PTP tributaries are not associated with a single MRB. This is similar to a "bearer type change" and is inconsistent with the segmented MRB architecture. This option involves L3, so how to perform a "dynamic" handover between PTM and PTP remains an issue.

[0199] Option 4: No handover-based signaling

[0200] When two branches are configured for a split MRB, the UE needs to continuously attempt to receive from both the PTM and PTP branches. From the gNB's perspective, this option ensures maximum scheduling flexibility, but the UE has no opportunity to save energy.

[0201] In summary, Option 1 is arguably the most suitable option in terms of scheduling flexibility, UE power consumption, and consistency with the segmented MRB architecture. Option 4 can be considered a subset of Option 1 when the PTM tributary remains active. Regarding the signaling layer, MAC CE can be straightforward, as activation / deactivation is primarily related to DRX operations. Therefore, RAN2 needs to agree that PTM tributaries can be activated / deactivated via MAC CE.

[0202] Recommendation 1: For dynamic PTM / PTP handover, RAN2 needs to agree to introduce MAC CE to activate / deactivate the PTM branch of the split MRB.

[0203] Regarding "change of bearer type" which differs from dynamic switching, the following situations are considered to be included.

[0204] Case 1: MRB for PTM only ←→ MRB for PTP only

[0205] Case 2: Segmenting MRB ←→ MRB with only PTM

[0206] Case 3: MRB segmentation ←→ MRB with only PTP

[0207] In the event of this bearer type change, reconfiguring using RRC (i.e., option 3) is straightforward.

[0208] Option 2: For changes in bearer type between PTM-only MRBs, PTP-only MRBs, and split MRBs, RAN2 needs to agree to the use of RRC reconfiguration.

[0209] 6. The behavior of PDCP

[0210] 7. Initial values ​​of state variables

[0211] In addition to the RLC UM mode, RAN2 agrees to support the RLC AM mode for PTP tributaries of the MRB. It is generally understood that, since "RLC-AM does not support PTM (for MBS R17 WI)," L2 reliability depends solely on dynamic PTM / PTP handover. Therefore, for service continuity, it is worthwhile to investigate how to significantly reduce packet loss at the start of MBS data reception and during dynamic PTM / PTP handover.

[0212] like Figure 17 As shown, by reusing existing PDCP functional views, the PDCP SN is common to both the PTM and PTP branches. The PTM branch is used by multiple UEs, so the PDCP SN may not be UE-specific, affecting both the PTM and PTP branches. This means that when a UE joins a multicast session later, regardless of which branch (PTM or PTP) the first MBS data arrives from, the initial value of each state variable cannot be continuously set to "0". That is, the first PDCP SN received by the UE can be any value not assumed in the current unicast transmission. Because the state variables are configured with initial values, a PDCP re-establishment for one UE may affect all other UEs. This leads to the discarding of unintended operations within the receive window, i.e., PDCP PDUs outside the window. The possibility of the same problem existing in handover scenarios is also pointed out.

[0213] Observation 3: When the UE joins the multicast session late and is configured with a segmented MRB, both the PTM and PTP branches confirm that the SN of the first received PDCP PDU is not the initial value (i.e., "0").

[0214] To address this issue, the following options are proposed.

[0215] Option A: The gNB notifies the UE of the initial value of COUNT, or RX_NEXT and RX_DELIV.

[0216] This option is used to simply change the initial values ​​associated with the receive window based on information from the gNB, allowing the UE to receive the first transmission of MBS data within the existing mechanism. However, from the perspective of the PDCP layer, it is questionable whether the UE can consistently and correctly receive the first transmission intended by the gNB due to handover delays, degradation in wireless states, and being outside the RLC reconfiguration window. In this context, it is unclear how this option will function.

[0217] Option B: The gNB notifies the UE of the initial HFN, and the UE infers the initial HFN and SN based on the first received PDCP PDU.

[0218] The SN part is the same as and / or similar to the V2X mechanism in version 16, as shown below. "The initial value of the SN part of RX_NEXT is (x+1)modulo(2 [sl-PDCP-SN-Size] "), and x is the SN of the first received PDCP data PDU", and "in NR secondary link communication used for broadcast and multicast, the initial value of the SN portion 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.

[0219] Regarding the HFN portion, in the version 16 V2X mechanism, HFN is not used for security reasons, therefore synchronization with the transmitting and receiving devices is not required. That is, the following description exists: "Note: The choice of HFN for RX_NEXT depends on the UE implementation to ensure that the initial value of RX_DELIV is positive." Regarding NR MBS, "In RAN2, before discussing security aspects in RAN2, the answer given is to wait for the completion of research related to the security of MBS in SA3." Therefore, in RAN2, the discussion of the HFN portion needs to be postponed until after the completion of research related to security in SA3.

[0220] In summary, further discussion is needed based on option B. According to the version 16 secondary link communication used for broadcast and multicast, and considering the development of SA3 related to the security of NR MBS, RAN2 must at least agree that the UE configures the initial values ​​of state variables based on the first received PDCP PDU of MBS data.

[0221] Option 3: RAN2 needs to agree that, regardless of whether it's a PTM or PTP tributary, the UE configures the initial values ​​of the SN portion of RX_NEXT and RX_DELIV based on the first received MBS data. Whether the HFN portion is notified from the gNB depends on the progress of SA3 and requires further investigation.

[0222] 8. Simultaneously receive UE auxiliary information

[0223] Specifically, in services requiring reliability, it is important to configure PTP (tributary) in RLC AM and, for service continuity, to perform lossless handover in the same and / or similar manner as lossless mobility. When agreeing to Recommendation 1, the UE needs to support simultaneous reception from both PTM and PTP tributaries. That is, both tributaries can be activated simultaneously in the same and / or similar manner as existing PDCP packet redundancy. This is because, since the PTM tributary is received by multiple UEs, this can easily lead to suboptimal MCS for a particular UE. Therefore, RAN2 needs to agree to simultaneous reception for at least a certain period during dynamic PTM / PTP handover.

[0224] Option 4: RAN2 needs to agree to support the UE receiving from both the PTM tributary and the PTP tributary simultaneously for a period of time after a dynamic PTM / PTP handover.

[0225] When agreeing to Recommendations 3 and 4, the gNB may not actually know which PDCP SN the UE has begun correctly receiving via the PTM tributary. In the case of a handover from PTP to PTM, the gNB may not know when to use the PTP tributary to send PDCPPDUs and when to stop sending via the PTP tributary. To address this issue, it is proposed that the UE notify the gNB of successful PTM reception and perform transmission via the PTP tributary. Note that it is unclear whether the UE still needs to include the PDCP SN information in the same message.

[0226] Observation 4: In the case of switching from PTP to PTM, the gNB may not know from which PDCP PDU to start maintaining the transmission of the PTP branch, or from which PDCP PDU the UE should correctly start receiving when using the PTM branch.

[0227] In the same and / or similar manner, during a handover from PTM to PTP, the gNB may not know which PDCP SN the UE is correctly receiving via the PTM tributary (especially when the UE's radio state is poor). This means the gNB may not know which PDCP PDU needs to be used when starting the PTP tributary.

[0228] Observation 5: When switching from PTM to PTP, the gNB may not know which PDCP PDU to start transmitting the PTP branch from or which PDCP PDU the UE has already correctly received via the PTM branch.

[0229] Therefore, the following is studied: During dynamic PTM / PTP handover, the UE notifies the gNB of SN information via the PTP tributary. When the UE reports SN information during dynamic handover between PTM and PTP, reusing the PDCP control PDU is straightforward, namely, including the FMC (First PDCP SDU Not Found) and optionally a bitmap (indicating whether subsequent PDCP SDUs were not found or were correctly received) PDCP status report. On the other hand, another option is for the UE to report the SN via the PTM tributary, in which the UE's first / last PDCP PDU reception has been successful. Therefore, further discussion is needed regarding the details that the UE should report during dynamic handover between PTM and PTP.

[0230] In any of the above scenarios (i.e., switching from PTP to PTM and switching from PTM to PTP), for service continuity, a PDCP control PDU including PDCP SN information needs to be triggered during dynamic switching (e.g., activation / deactivation of MAC CE).

[0231] Option 5: RAN2 requires further investigation to determine whether the UE needs to send a PDCP control PDU including PDCP SN information during dynamic handover for service continuity. Further research is needed to determine if PDCP information reports can be reused.

[0232] Another point that needs to be studied is whether lossless bearer type changes are required in the same and / or similar manner as lossless dynamic handover in Recommendation 5. From the perspective of service continuity and lossless mobility, it is considered that bearer type changes, including PTPs (tributes) with RLC AM, need to have the same and / or similar reliability as dynamic handover. Therefore, RAN2 needs to study whether lossless bearer type changes need to be supported. When this is supported, PDCP control PDUs need to be reused as UE auxiliary information in the same and / or similar manner as in Recommendation 5.

[0233] Recommendation 6: RAN2 needs to discuss whether the same approach can be applied as the approach with lossless bearer type change with RRC reconfiguration (i.e., lossless dynamic switching of PDUs controlled by PDCP as in Recommendation 5).

[0234] Figure Labels

[0235] 1: Mobile communication system

[0236] 10: RAN

[0237] 20:CN

[0238] 100:UE

[0239] 110: Receiver

[0240] 120: Transmitter

[0241] 130: Controller

[0242] 200: gNB

[0243] 210: Transmitter

[0244] 220: Receiver

[0245] 230: Controller

[0246] 240: Backhaul communicator.

Claims

1.A communication method for use in a mobile communication system for supporting multicast and broadcast service, MBS, the communication method comprising the steps of: a user equipment that has started receiving a MBS session from a network node managing a packet data convergence protocol, PDCP, variable that is updated in response to receiving a PDCP packet in the MBS session, the PDCP variable being managed in a PDCP layer; and in response to determining that the reception of the MBS session has been interrupted for a predetermined time, the user equipment re-establishing a PDCP entity to receive the MBS session. 2.The communication method according to claim 1, wherein the PDCP variable is a count value comprising a hyper frame number, HFN, that is counted up each time a PDCP sequence number is incremented by one, and the PDCP sequence number. 3.The communication method according to claim 1, wherein the PDCP variable is a hyper frame number, HFN, that is counted up each time a PDCP sequence number is incremented by one. 4.A user equipment for use in a mobile communication system for supporting multicast and broadcast service, MBS, the user equipment comprising: a receiver that receives a MBS session from a network node; and a controller that manages a PDCP variable that is updated in response to receiving a PDCP packet in the MBS session, wherein the PDCP variable is managed in a PDCP layer, the controller re-establishing a PDCP entity to receive the MBS session in response to determining that the reception of the MBS session has been interrupted for a predetermined time. 5.A mobile communication system for supporting multicast and broadcast service, MBS, comprising: a network node; and a user equipment, the user equipment comprising: a receiver that receives a MBS session from a network node; and a controller that manages a PDCP variable that is updated in response to receiving a PDCP packet in the MBS session, wherein the PDCP variable is managed in a PDCP layer, the controller re-establishing a PDCP entity to receive the MBS session in response to determining that the reception of the MBS session has been interrupted for a predetermined time. 6.A computer program product comprising a computer program that, when executed by a processor, causes a user equipment for use in a mobile communication system for supporting multicast and broadcast service, MBS, to perform the following processes: receiving a MBS session from a network node; managing a PDCP variable that is updated in response to receiving a PDCP packet in the MBS session, wherein the PDCP variable is managed in a PDCP layer; and re-establishing a PDCP entity to receive the MBS session in response to determining that the reception of the MBS session has been interrupted for a predetermined time. 7.A chipset of a user equipment for use in a mobile communication system for supporting multicast and broadcast service, MBS, the chipset performing the following operations: receiving a MBS session from a network node; managing PDCP variables updated in response to receiving packet data convergence protocol, PDCP, packets in the MBS session, wherein the PDCP variables are managed in a PDCP layer; and in response to determining that reception of the MBS session has been interrupted for a predetermined time, re-establishing a PDCP entity to receive the MBS session.

Images