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 the Chinese patent application "Communication Method, User Equipment, and Base Station" with an application date of August 3, 2022 and an application number of 202280067089.6. Technical Field

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

[0003] In the 3rd Generation Partnership Project (3GPP) standard, technical specifications of New Radio (NR) as the 5th Generation (5G) radio access technology have been defined. Compared with Long-Term Evolution (LTE) as the 4th Generation (4G) radio access technology, NR has characteristics such as high speed, large capacity, high reliability, and low latency. In 3GPP, technical specifications for establishing Multicast and Broadcast Services (MBS) of 5G / NR have been discussed (for example, see Non-Patent Document 1).

[0004] Citation List

[0005] Non-Patent Document

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

[0007] It is desired that the 5G / NR multicast and broadcast service provides enhanced services compared to the 4G / LTE multicast and broadcast service.

[0008] In view of this, the present 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 of an MBS session, an identifier related to an MRB mapped to the MBS session, and a Hyperframe Number (HFN) corresponding to the MBS session.

[0010] In a second aspect, a 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 including an MBS session identifier of an MBS session, an identifier related to an MRB mapped to the MBS session, and a hyperframe number (HFN) corresponding to the MBS session.

[0011] In a third aspect, a base station is used in a mobile communication system for 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 of an MBS session, an identifier related to an MRB mapped to the MBS session, and a hyperframe number (HFN) corresponding to the MBS session.

[0012] In a fourth aspect, a communication method is used in a mobile communication system for supporting multicast and broadcast services (MBS). The communication method includes: a user equipment that has started receiving an MBS session manages a first PDCP variable updated in response to reception of a packet data convergence protocol (PDCP) packet 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 performs control to synchronize the first PDCP variable with a second PDCP variable managed by the base station.

[0013] In a fifth aspect, a user equipment is used in a mobile communication system for supporting multicast and broadcast services (MBS). The user equipment includes a controller configured to: when starting to receive an MBS session from a base station, manage a first PDCP variable updated in response to reception of a packet data convergence protocol (PDCP) packet in the MBS session, the first PDCP variable being managed at the PDCP layer. The controller performs 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 time.

[0014] In a sixth aspect, a 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 transmission of a packet data convergence protocol (PDCP) packet in the MBS session when starting to send the MBS session, the first PDCP variable being managed at the PDCP layer; a receiver configured to receive a request for checking a PDCP variable from a user equipment; and a transmitter configured to send the PDCP variable to the user equipment in response to the request. Description of the Drawings

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

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

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

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

[0019] Figure 5 It 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 It is a diagram showing an overview of MBS service transmission according to an embodiment.

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

[0022] Figure 8 It is a diagram showing the split multicast radio bearer (MRB) according to an embodiment.

[0023] Figure 9 It is a diagram showing the operation scenario of a mobile communication system according to an embodiment.

[0024] Figure 10 It is a diagram showing an example of PDCP variables according to an embodiment.

[0025] Figure 11 It is a diagram showing the PDCP data PDU according to an embodiment.

[0026] Figure 12 It is a diagram showing the operation of identifying RCVD_COUNT, where RCVD_COUNT is the COUNT value of the PDCP data PDU received in the UE (receive-side PDCP entity).

[0027] Figure 13 It is a diagram showing the operation of the receive-side PDCP entity of the UE according to an embodiment.

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

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

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

[0031] Figure 17 This is a diagram showing PDCP fixed type PTM / PTP handover based on the current protocol. Detailed implementation

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

[0033] Configuration of the mobile communication system

[0034] Figure 1 This is a diagram showing the configuration of a mobile communication system 1 according to the present embodiment. The mobile communication system 1 complies with the fifth-generation system (5GS) of the 3GPP standard. The following description takes 5GS as an example, but the Long-Term Evolution (LTE) system can be at least partially applied to the mobile communication system. The sixth-generation (6G) system can be at least partially applied 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. Hereinafter, the NG-RAN 10 may be abbreviated as the RAN 10. The 5GC 20 may be abbreviated as the core network (CN) 20.

[0036] The UE 100 is a mobile radio communication device. The UE 100 can be any device as long as it is used by a user. Examples of the UE 100 include a mobile phone terminal (including a smart phone) or a tablet terminal, a notebook PC, a communication module (including a communication card or a chipset), a sensor or a device provided on the sensor, a vehicle or a device provided on the vehicle (vehicle UE), and a flying object or a device provided on the flying object (air UE).

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

[0038] Note that the gNB can be connected to the evolved packet core (EPC) corresponding to the core network of LTE. The LTE base station can also be connected to the 5GC. The LTE base station and the gNB can be connected via an interface between base stations.

[0039] The 5GC 20 includes an access and mobility management function (AMF) and a user plane function (UPF) 300. The AMF performs various types of mobility control, etc. for the UE 100. The AMF manages the mobility of the UE 100 by communicating with the UE 100 using non-access stratum (NAS) signaling. The UPF controls data transmission. The AMF and the UPF are connected to the gNB 200 via the NG interface, which is an interface between the base station and the core network.

[0040] Figure 2 FIG. is a diagram showing the configuration of the UE 100 (user equipment) according to the present embodiment. The UE 100 includes a receiver 110, a transmitter 120, and a controller 130. The receiver 110 and the transmitter 120 constitute a wireless communicator that performs wireless communication with the gNB 200.

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

[0042] The transmitter 120 performs various types of transmission under the control of the controller 130. The transmitter 120 includes an antenna and transmitting equipment. The transmitting equipment converts a baseband signal (transmitted signal) output by the controller 130 into a radio signal, and transmits the resulting signal through the antenna.

[0043] The controller 130 performs various types of control and processing in the UE 100. Such processing includes the processing of each layer to be described later. The controller 130 includes at least one processor and at least one memory. The memory stores programs to be executed by the processor and information to be used 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, etc. of baseband signals. The CPU executes the programs stored in the memory, thereby performing various types of processing.

[0044] Figure 3 FIG. is a diagram showing the configuration of the gNB 200 (base station) according to the present embodiment. The gNB 200 includes a transmitter 210, a receiver 220, a controller 230, and a backhaul communicator 240. The transmitter 210 and the receiver 220 constitute a wireless communicator that performs wireless communication with the UE 100. The backhaul communicator 240 constitutes a network communicator that communicates with the CN 20.

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

[0046] The receiver 220 performs various types of receptions under the control of the controller 230. The receiver 220 includes an antenna and a reception device. The reception device converts the radio signal received through the antenna into a baseband signal (reception signal) and outputs the resulting signal to the controller 230.

[0047] The controller 230 performs various types of control and processing in the gNB 200. Such processing includes the processing of each layer to be described later. The controller 230 includes at least one processor and at least one memory. The memory stores programs to be executed by the processor and information to be used for 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, etc. of baseband signals. The CPU executes the 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., the functions are divided), and the two units may be connected via the F1 interface as a fronthaul interface.

[0049] Figure 4It is a diagram showing the configuration of the protocol stack of the radio interface in the user plane for processing data.

[0050] The radio interface protocol in the user plane includes a Physical (PHY) layer, a Media 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.

[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 physical channels. Note that the PHY layer of UE 100 receives downlink control information (DCI) sent from gNB 200 through the Physical Downlink Control Channel (PDCCH). Specifically, UE 100 blindly decodes the PDCCH using a Radio Network Temporary Identifier (RNTI) and obtains the successfully decoded DCI as the DCI addressed to UE 100. The DCI sent from gNB 200 is appended with CRC parity bits scrambled by the RNTI.

[0052] The MAC layer performs priority control of data, retransmission processing through 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 transport channels. The MAC layer of gNB 200 includes a scheduler. The scheduler determines the transmission 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 sends data to the RLC layer on the receiving side by using the functions of the MAC layer and the PHY layer. Data and control information are transmitted between the RLC layer of UE 100 and the RLC layer of gNB 200 via logical channels.

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

[0055] The SDAP layer performs the mapping between IP flows (as the unit of QoS (Quality of Service) control executed by the core network) and radio bearers (as the unit of QoS control executed by the Access Stratum (AS)). Note that when the RAN is connected to the EPC, it is not necessary to provide the SDAP.

[0056] Figure 5 It is a diagram showing the configuration of the protocol stack of the radio interface in the control plane for processing signaling (control signals).

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

[0058] RRC signaling for various configurations is sent 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. When there is a connection (RRC connection) between the RRC of UE 100 and the RRC of gNB 200, UE 100 is in the RRC connected state. When there is no connection (RRC connection) between the RRC of UE 100 and the RRC of gNB 200, UE 100 is in the RRC idle state. When the connection between the RRC of UE 100 and the RRC of gNB 200 is suspended, UE 100 is in the RRC inactive state.

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

[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 the use cases (service types) of MBS include public safety communication, mission-critical communication, vehicle-to-everything (V2X) communication, IPv4 or IPv6 multicast delivery, Internet Protocol Television (IPTV), group communication, and software delivery.

[0062] The broadcast service provides services to each UE 100 within a specific service area for applications that do not require highly reliable QoS. The MBS session for the broadcast service is called a broadcast session.

[0063] The multicast service does not provide services to each UE 100, but provides services to a group of UE100 participating in the multicast service (multicast session). The MBS session for the multicast service is called a multicast session. The multicast service can provide the same content to the group of UE 100 by a method with higher radio efficiency than the broadcast service.

[0064] Figure 6 is a diagram showing an overview of MBS service delivery according to this embodiment.

[0065] Transmit MBS services (MBS data) from a single data source (application service provider) to multiple UEs. The 5G CN (5GC) 20 of the 5G core network receives MBS data from the application service provider and performs replication of the MBS data to transmit the replicated products.

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

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

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

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

[0070] In the PTP transmission method, the gNB 200 wirelessly transmits respective copies of the MBS data packets to each UE 100. On the other hand, 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 transmission method or the PTP transmission method as the method for transmitting MBS data to a UE 100.

[0071] The PTP and PTM transmission methods are mainly related to the user plane. The modes for controlling MBS data transmission include two transmission modes: the first transmission mode and the second transmission mode.

[0072] Figure 7 It is a diagram showing the transmission mode according to the present embodiment.

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

[0074] The MBS reception configuration in the first transmission mode is performed through UE-specific signaling. For example, the MBS reception configuration in the first transmission mode is performed through an RRC reconfiguration message (or an RRC release message), which is an RRC message unicast from the gNB 200 to the UE 100.

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

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

[0077] The second transmission mode (Transmission Mode 2 (DM2)) is a transmission 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 transmission mode for low QoS requirements. The second transmission mode is used for broadcast sessions in an MBS session. However, the second transmission mode can also be applicable to multicast sessions.

[0078] The MBS reception configuration in the second transmission mode is performed via broadcast signaling. For example, the MBS reception configuration in the second transmission mode is performed using logical channels (e.g., Broadcast Control Channel (BCCH) and / or Multicast Control Channel (MCCH)) sent from gNB 200 to UE 100 via broadcast. For example, UE 100 may use a dedicated RNTI predefined in the technical specification to receive BCCH and MCCH. The RNTI for BCCH reception may be SI-RNTI, and the RNTI for MCCH reception may be MCCH-RNTI.

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

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

[0081] The network may provide different MBS services for different MBS sessions. The MBS session is identified by at least one selected from the group consisting of: Temporary Mobile Group Identity (TMGI), source-specific IP multicast address (which includes a source unicast IP address such as an application function and an application server and an IP multicast address indicating the destination address), session identifier, and G-RNTI. At least one selected from the group consisting of TMGI, G-RNTI, source-specific IP multicast address, and session identifier is referred to as the MBS session identifier. TMGI, source-specific IP multicast address, session identifier, and G-RNTI are collectively referred to as MBS session information.

[0082] Figure 8 FIG. is a diagram showing a split multicast radio bearer (MRB) according to the present embodiment. The MRB may be a type of data radio bearer (DRB). The split MRB may be used in the first transmission mode described above.

[0083] The gNB 200 may configure the MRB split into the PTP communication path and the PTM communication path for the UE 100. This allows the gNB 200 to dynamically switch the transmission of MBS data to the UE 100 between PTP (PTP communication path) and PTM (PTM communication path). The gNB 200 may use both PTP (PTP communication path) and PTM (PTM communication path) to perform the repeated transmission of the same MBS data to enhance reliability. Hereinafter, the PTP communication path is referred to as the PTP branch, and the PTM communication path is referred to as the PTM branch. The functional unit corresponding to each layer is called an entity.

[0084] The predetermined layer at which the split is terminated is the MAC layer (HARQ), the RLC layer, the PDCP layer, or the SDAP layer. Although an example where the predetermined layer at which the split is terminated is the PDCP layer will be mainly described below, the predetermined layer may be the MAC layer (HARQ), the RLC layer, or the SDAP layer.

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

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

[0087] The PHY entity uses the cell RNTI (cell radio network temporary identifier (C-RNTI)) assigned to the UE 100 one-to-one to transmit and receive data of the PTP branch. The PHY entity uses the G-RNTI assigned to the MBS session one-to-one to transmit and receive data of the PTM branch. The C-RNTI is different for each UE 100, but the G-RNTI is a RNTI common to multiple UEs 100 receiving one MBS session.

[0088] To perform PTM transmission (multicast or broadcast) of MBS data from the gNB 200 to the UE 100 using the PTM branch, it is necessary to configure the split MRB from the gNB 200 to the UE 100, and it is necessary to activate the PTM branch (activation). In other words, even if the split MRB is configured for the UE 100, when the PTM branch is in the deactivated state, the gNB 200 cannot use the PTM branch to perform PTM transmission of MBS data.

[0089] In order for the gNB 200 and the UE 100 to use the PTP branch to perform PTP transmission (unicast) of MBS data, it is necessary to configure split MRBs from the gNB 200 to the UE 100, and it is necessary to activate the PTP branch. In other words, even if split MRBs are configured for the UE 100, when the PTP branch is in the deactivated state, the gNB 200 cannot use the PTP branch to perform PTP transmission of MBS data.

[0090] When the PTM branch is in the activated state, the UE 100 monitors the PDCCH that applies the G-RNTI associated with the MBS session (i.e., performs blind decoding of the PDCCH using the G-RNTI). The UE 100 can monitor the PDCCH only at the scheduling occasion of the MBS session.

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

[0092] When the PTP branch is in the activated state, the UE 100 monitors the PDCCH that applies the C-RNTI. When discontinuous reception (DRX) is configured in the PTP branch, the UE 100 monitors the PDCCH within the configured OnDuration period. When specifying the cell (frequency) associated with the MBS session, even when the cell is deactivated, the UE 100 can monitor the PDCCH for that cell.

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

[0094] Note that it is assumed that the above split MRBs are configured through an RRC message (e.g., an RRC reconfiguration message) from the RRC entity of the gNB 200 to the RRC entity of the UE 100.

[0095] Operation of the mobile communication system

[0096] Figure 9 is a diagram showing an operation scenario of the mobile communication system 1 according to the present embodiment.

[0097] The gNB 200 multicasts or broadcasts to multiple UEs 100 via PTM (in Figure 9In the example, MBS data of a certain MBS session is sent to UEs 100a to 100c). The RRC state of each UE 100 can be any state (RRC connected state, RRC idle state, or RRC inactive state). The MBS transmission mode can be the first transmission mode or the second transmission mode. In the first transmission mode, MBS transmission can use the PTM branch.

[0098] In the PDCP layer, gNB 200 includes a PDCP entity 201 associated with the MBS session (specifically, a transmitting-side PDCP entity associated with a multicast radio bearer (MRB) belonging to the MBS session). When the PDCP entity 201 starts transmitting the MBS session, the 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 receiving-side PDCP entity associated with an MRB belonging to the MBS session). When each PDCP entity 101 (in Figure 10 the example, PDCP entities 101a to 101b) starts transmitting the MBS session, the PDCP entity 101 manages PDCP variables updated in response to the reception of PDCP packets in the MBS session.

[0100] As Figure 10 shown, the PDCP variable can be a count value (COUNT value), which includes a hyperframe number (HFN) that counts up whenever the PDCP sequence number goes through a round 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 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 indicate the COUNT value and can also be used as a term indicating various variables (HFN, PDCP SN, etc.) processed in the PDCP layer.

[0101] Figure 11 is a diagram showing PDCP packets (specifically, PDCP data protocol data units (PDUs)) constituting MBS data. As Figure 11As shown, the PDCP data PDU includes a PDCP SN, data, and a MAC-I. The PDCP SN is a sequence number assigned sequentially 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 a MAC-I. As described above, the PDCP data PDU includes a PDCP SN but does not include an 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 one round.

[0102] Figure 12 It is a diagram showing the operation for identifying RCVD_COUNT, where RCVD_COUNT is the COUNT value of the PDCP data PDU received in the UE 100 (the 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 It is a diagram showing the 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 the 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 upper layer of the integrity - verification failure and discards the PDCP PDU (step S13).

[0109] When the receiving - side PDCP entity 101 succeeds in the 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 - side 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 = RCVD_COUNT + 1 (step S19). Here, RX_NEXT is a variable indicating the count value (RCVD_COUNT) of the PDCP SDU expected to be received next. 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 delivers the result to the upper 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 an operation of delivering packets to the upper layer without performing sequence control. Therefore, as in step S21, immediately after the packet is received and stored in the buffer, the packet is delivered to the upper 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 delivers the result to the upper layer (step S23), and updates RX_DELIV to the first (lowest) COUNT value that has not been delivered to the upper 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 for detecting 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 that triggered 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 the UE 100 updates PDCP variables in response to receiving PDCP packets (PDCP data PDUs) from the gNB 200. Specifically, the receiving-side PDCP entity 101 of the UE 100 configures the initial value of the PDCP variable to zero and updates the PDCP variable (increments or counts up the PDCP variable) in response to receiving a packet from the gNB 200.

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

[0116] For example, when the receiving-side PDCP entity 101 of the UE 100 cannot receive packets for a certain period or longer due to a poor radio state or the like and then starts receiving packets, the receiving-side PDCP entity 10l may not be able to correctly receive the packet. Specifically, when RCVD_SN >> SN (RX_DELIV), the packet can be considered a previous packet.

[0117] This problem is mainly because the HFN is out of sync between the gNB 200 and the UE 100. This out-of-sync state may occur when the UE 100 cannot receive MBS reception (PTM reception) for a certain period. Especially in PTM, due to the reception of multiple UEs and the lack of layer 2 feedback, there is a tendency for this state to easily occur. Therefore, the UE 100 cannot appropriately perform receive window control, packet reordering, etc. at the PDCP layer and may not be able to appropriately continue MBS reception. This embodiment is an embodiment for solving such problems.

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

[0119] In step S1, UE 100 starts receiving a (PTM reception) 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 PDCP variables (hereinafter referred to as "first PDCP variables") updated in response to receiving 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. When 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 the predetermined time (step S3: Yes), in step S4, UE 100 performs control to synchronize the first PDCP variable with the PDCP variable (hereinafter referred to as "second PDCP variable") managed by gNB 200.

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

[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 can apply the second PDCP variable received from gNB 200 to the first PDCP variable. Thus, UE 100 can synchronize the first PDCP variable managed by UE 100 with the second PDCP variable managed by gNB 200.

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

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

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

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

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

[0130] Figure 15 FIG. is a diagram showing an example of the operation of the mobile communication system 1 according to the present embodiment.

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

[0132] In step S102, gNB 200 starts sending MBS data of a certain MBS session to a plurality of UEs 100 (UE 100a to UE 100c in the Figure 9 example) through PTM (multicast or broadcast). UE 100 starts receiving the MBS data and updates the PDCP variable (first PDCP variable) of UE 100.

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

[0134] In step S105, UE 100 determines whether the MBS reception (PTM reception) of UE 100 has been successful. For example, when UE 100 successfully decodes the MBS data in the lower layer, UE 100 determines that the MBS reception of UE 100 has been successful. When it is determined that the MBS reception of UE 100 has been successful (step S105: Yes), in step S106, UE 100 stops the timer. When the MBS reception of UE 100 is not successful (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 the MBS reception has been interrupted for a predetermined time (the time configured with the timer configuration value). When the timer has not expired (step S107: No), UE 100 returns the process to step S105. On the other hand, when the timer has expired (step S107: Yes), UE 100 performs at least one of the processes in steps S108 to S112.

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

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

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

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

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

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

[0142] Figure 16 FIG. is a diagram showing another example of the operation of the mobile communication system 1 according to the present embodiment. Here, the differences from the Figure 15 operation example shown will be described.

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

[0144] In step S209, the UE 100 can execute a check request (inquiry) to the gNB 200 for the current HFN (second PDCP variable) managed by the gNB 200. The gNB 200 receives the check request (inquiry).

[0145] In step S21, in response to receiving the check request (inquiry) from the UE 100, the gNB 200 can send the HFN (second PDCP variable) managed by the gNB 200 to the UE 100. The UE 100 receives the HFN (second PDCP variable) managed by the gNB 200.

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

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

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

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

[0150] Other embodiments

[0151] The above embodiments mainly assume a scenario where UE 100 cannot receive PTM for a certain period due to the deterioration of radio conditions. However, it is also assumed that gNB 200 intentionally stops transmitting for a certain period (due to reasons such as having no data to send, etc.). Thus, as in the above embodiments, in an example where a timer is used to detect an interruption in MBS reception for a predetermined time, when gNB 200 intentionally interrupts MBS transmission for a predetermined time (due to reasons such as having no data to send, etc.), UE 100 also determines an interruption in MBS reception, and thus UE 100 may perform processing that is originally unnecessary. In view of this, when gNB 200 intentionally stops MBS transmission, gNB 200 may send a stop indication of the timer to UE 100. When UE 100 receives the stop indication, UE 100 stops the timer. When gNB 200 resumes MBS transmission, gNB 200 may send a resume indication of the timer to UE 100. When UE 100 receives the resume indication, UE 100 resumes the timer. When resumed, the timer may be reset (i.e., set to 0), or does not need to be reset (i.e., may resume from the value when it was stopped). Alternatively, when gNB 200 resumes MBS transmission, gNB 200 may resume sending MBS data without sending a resume indication. When UE 100 receives the MBS data, UE 100 considers that gNB 200 has resumed MBS transmission and resumes the timer.

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

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

[0154] A program can be provided to cause a computer to execute each process performed by the UE 100 or the gNB 200. The program can be recorded in a computer-readable medium. Using the computer-readable medium enables the program to be installed on the computer. Here, the computer-readable medium on which the program is recorded can be a non-transitory recording medium. The non-transitory recording medium is not specifically limited and can be, for example, a recording medium such as a CD-ROM or a DVD-ROM. The circuits for performing the processing to be performed by the UE 100 or the gNB 200 can be integrated, and at least a part of the UE 100 or the gNB 200 can 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 solely on" and "depending solely on". The phrase "based on" means both "based solely on" and "based at least in part on". Similarly, the phrase "depending on" means both "depending solely on" and "depending at least in part on". "Obtain" or "acquire" can mean obtaining information from the information stored, can mean obtaining information from the information received from another node, or can mean obtaining information by generating information. The terms "include", "comprise" and their variants do not mean "include only the items", but mean "may include only the items" or "may include not only the items but also other items". The term "or" as used in this disclosure is not intended to be an "exclusive or". In addition, any reference in this disclosure to elements using names such as "first" and "second" generally does not limit the number or order of these elements. These names can be used herein as a convenient way to distinguish two or more elements. Thus, a reference to a first element and a second element does not mean that only two elements can be employed there or that the first element needs to be before the second element in some manner. For example, when adding English articles such as "a", "an" and "the" to this disclosure through translation, these articles include the plural unless otherwise expressly indicated 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 the above configurations, and various design changes can be made without departing from the gist of this disclosure.

[0157] This application claims the priority of U.S. Provisional Patent Application No. 63 / 229,155 (filed on August 4, 2021), the entire content of which is incorporated herein by reference.

[0158] Supplementary Notes

[0159] 1. Introduction

[0160] Revised work items related to NR multicast and broadcast services (MBS) were approved in RAN#88. The purpose is to define mobility, including dynamic PTM / PTP handover and service continuity as shown below.

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

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

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

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

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

[0166] Further study is needed on layer handling reliability (in general), the case of ordered transmission / duplicate handling, and how this layer functions in the handover between PTM and PTP.

[0167] In RAN2#113-e, the following agreements have been reached regarding the discussion related to L2 reliability in the architecture of dynamic PTM / PTP handover.

[0168] When both PTM and PTP are RLC UM, there is no L2 ARQ, and support for the configuration of handover with a fixed PDCP between PTM and PTP is provided (e.g., when services for unicast are usually configured in RLC UM).

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

[0170] Agreement

[0171] It should be noted that the following agreements are only based on the determination of the architecture so far. The discussion on reliability has not been completed. In other words, this is different from the case other than RLC UM + RLC UM. Further study is needed on the handover between PTM and PTP in another such case.

[0172] Support for dynamic PTM / PTP handover is provided using a split MRB bearer (type) including a common (single) PDCP entity.

[0173] Basically, new UE-based signaling for supporting gNB handover has not been introduced yet (e.g., PDCP SR for high reliability has not been determined).

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

[0175] Assuming a split MRB configured with PTM and PTP branches (agreed during an online session), further study is needed on whether the use of the PTM branch of the split MRB can be activated or deactivated and its details.

[0176] In terms of mobility, in RAN2, only the basic principles listed below are agreed.

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

[0178] To support lossless handover of 5G MBS services, at least it is not necessary to ensure the synchronization of DL PDCP SN and the continuity between the source cell and the target cell in the network. The specific method design for achieving this may be related to WG RAN3.

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

[0180] From the UE, PDCP status reporting can also be supported.

[0181] In the supplementary notes, the remaining issues of dynamic PTM / PTP handover and mobility with service continuity based on the agreed architecture (i.e., using a split MRB fixed to PDCP) will be described.

[0182] 2. Discussion

[0183] 3. Split MRB Configuration

[0184] Based on the current protocol, the architecture of PTM / PTP handover fixed to PDCP (i.e., split MRB) can be explained as Figure 17 shown.

[0185] Generally, it can be considered that the RRC reconfiguration is used to provide a bearer configuration including two logical channels (PTM branch and PTP branch) and to receive information of a multicast session. RAN2 describes "assuming a split MRB configured with PTM branch and PTP branch (agreed during an online session)"; however, it is a general understanding that providing a configuration where two logical channels are associated with one multicast radio bearer with RRC reconfiguration is already a preparation for dynamic PTM / PTP handover.

[0186] Observation 1: Before the dynamic PTM / PTP handover operation, it is a general understanding that providing a configuration where two logical channels are associated with one MRB with RRC reconfiguration.

[0187] 4. Dynamic PTM / PTP handover operation

[0188] 5. Signaling

[0189] It is necessary to further study whether the use of split MRB and PTM branch can be activated or deactivated and its details.

[0190] When a split MRB including PTM branch / PTP branch is configured, the UE needs to monitor both the G-RNTI of the PTM branch and the C-RNTI of the PTP branch. In LTE SC-PTM, "the reception timing of SC-PTM is independent of the unicast DRX scheme", that is, the DRX is different. The G-RNTI is received by multiple UEs, while the C-RNTI is UE-specific, and the two DRXs are significantly coordinated, so this concept can be the basis of NRMBS. This means that when the UE needs to continuously monitor the G-RNTI, the UE needs to wake up frequently, and this can lead to further power consumption. On the other hand, the UE in the connected state needs to monitor the 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 transmission timing of the PTP branch (i.e., C-RNTI) which is the same as C-DRX, the UE also needs to wake up for the transmission timing of the PTM branch (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 the handover operation), there are the following four options.

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

[0194] The gNB uses DCI, MAC CE, RRC signals, etc. to indicate to the UE to enable / disable the PTM branch. In addition to receiving MBS data via PTM or PTP, this option can also handle more flexibly the situation of receiving MBS data via two branches, such as in split bearers or PDCP packet redundancy. The UE can reduce the power consumption from the deactivated PTM branch. In the implementation of the NW, it should be noted that the continuous activation of the two branches can be determined, and the main idea of Option 4 below can be covered.

[0195] Option 2: Handover sequence / command-based handover

[0196] The gNB uses DCI, MAC CE, RRC signaling, etc. to indicate to the UE to hand over between the PTM branch and the PTP branch. This option is the same as and / or similar to Option 1 above, and is simple because power is saved by deactivating the PTM branch. However, this option is less flexible for operations related to split bearers including PDCP packet redundancy. It can be considered that this option only involves the handover between the PTM branch and the PTP branch, and both of them cannot be activated.

[0197] Option 3: Handover based on RRC reconfiguration

[0198] The gNB reconfigures PTM or PTP with RRC reconfiguration as an MRB for the UE. That is, the PTM branch and the PTP branch are not associated with one MRB. That is, it is similar to "bearer type change" and is inconsistent with the split MRB architecture. This option involves L3, so how to perform "dynamic" handover between PTM and PTP remains a problem.

[0199] Option 4: No handover-based signaling

[0200] When two branches are configured for split MRB, the UE needs to continuously attempt to receive from both the PTM branch and the PTP branch. With this option, from the perspective of the gNB, the maximum scheduling flexibility is ensured, but the UE has no opportunity to save energy.

[0201] In summary, it can be said that in terms of scheduling flexibility, UE power consumption, and consistency with the split MRB architecture, Solution 1 is the most suitable solution. When the PTM branch is continuously active, Option 4 can be regarded as a subset of Option 1. Regarding the signaling layer, MAC CE can be simple because activation / deactivation is mainly related to DRX operations. Therefore, RAN2 needs to agree that the PTM branch of the split MRB 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 "bearer type change" different from dynamic handover, it is considered that the bearer type change has the following situations.

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

[0205] Situation 2: Split MRB ←→ MRB for PTM only

[0206] Situation 3: Split MRB ←→ MRB for PTP only

[0207] In this case of bearer type change, using RRC reconfiguration (i.e., option 3) is simple.

[0208] Solution 2: For the bearer type change between MRB for PTM only, MRB for PTP only, and split MRB, RAN2 needs to agree to the use of RRC reconfiguration.

[0209] 6. Behavior of PDCP

[0210] 7. Initial values of state variables

[0211] Except for the RLC UM mode, RAN2 agrees to support the RLC AM mode for the PTP branch of the split MRB. It is generally understood that since "RLC-AM does not support PTM (for MBS R17 WI)", the L2 reliability only depends on the dynamic PTM / PTP handover. Therefore, for the sake of service continuity, it is worth studying how to greatly reduce the packet loss when starting MBS data reception and dynamic PTM / PTP handover.

[0212] As Figure 17 shown, by reusing the existing PDCP functional view, the PDCP SN is common for both the PTM branch and the PTP branch. The PTM branch is used by multiple UEs, so the PDCP SN may not be UE-specific, which will affect both the PTM branch and the PTP branch. This means that when a UE participates in a multicast session late, regardless of which branch (PTM branch or PTP branch) the first received 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. Since the state variables are configured with initial values, the PDCP re-establishment of a certain UE may affect all other UEs. This results in discarding the unexpected operations in the receive window, i.e., PDCP PDUs outside the window. The possibility of the same problem in the handover scenario is pointed out.

[0213] Observation 3: In the case where the UE participates in the multicast session late and is configured with split MRBs, for both the PTM branch and the PTP branch, it is confirmed that the SN of the first received PDCP PDU is not the initial value (i.e., "0").

[0214] To solve this problem, 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 related to the receive window based on the information from the gNB, so that the UE can receive the first transmission of MBS data in the existing mechanism. However, from the perspective of the PDCP layer, due to reasons such as the delay of handover, the deterioration of the radio state, and outside the RLC reconfiguration window, it is a problem whether the UE can continuously and correctly receive the first transmission intended by the gNB. In this case, it is not clear how this option works.

[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 an option that is the same as and / or similar to the V2X mechanism of Release 16, as follows. "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 sidelink communication for broadcast and multicast, 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.

[0219] Regarding the HFN part, in the Release 16 V2X mechanism, for safety reasons, the HFN is not used, so synchronization between the sending device and the receiving device is not required. That is, there is the following description: "Note: The selection of the HFN of RX_NEXT depends on the implementation of the UE so that the initial value of RX_DELIV is positive". Regarding NR MBS, "in RAN2, before discussing the security aspects in RAN2, the answer given is to wait until the research related to the security of MBS in SA3 is completed". Therefore, in RAN2, the discussion of the HFN part needs to be postponed until after the completion of the 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 for broadcast and multicast, considering the development of SA3 related to the security of NR MBS, RAN2 needs to at least agree that the UE configures the initial value of the status variable based on the first received PDCP PDU of the MBS data.

[0221] Solution 3: RAN2 needs to agree that for both the PTM branch and the PTP branch, the UE configures the initial value of the SN part of RX_NEXT and RX_DELIV based on the first received MBS data. Whether to notify the HFN part from the gNB depends on the progress of SA3 and further study is required.

[0222] 8. Simultaneous reception and UE assistance information

[0223] Specifically, in services that require reliability, PTP (branch) is configured in RLC AM, and for service continuity, it is important to perform lossless handover in the same and / or similar manner as lossless mobility. When agreeing to Proposal 1, the UE needs to support simultaneous reception from both the PTM branch and the PTP branch. That is, both branches can be activated simultaneously in the same and / or similar manner as the existing PDCP packet redundancy. This is for the following reason: Since the PTM branch is received by multiple UEs, this may easily lead to non-optimal MCS for a specific UE. Therefore, RAN2 needs to agree to adopt simultaneous reception for at least a certain period during dynamic PTM / PTP handover.

[0224] Solution 4: RAN2 needs to agree to support the UE to simultaneously receive from both the PTM branch and the PTP branch for a certain period after dynamic PTM / PTP handover.

[0225] When agreeing to Proposal 3 and Proposal 4, the gNB may not actually know which PDCP SN the UE has started to correctly receive via the PTM branch. In the case of switching from PTP to PTM, the gNB may not know when to use the PTP branch to send PDCP PDUs and when to stop sending on the PTP branch. To solve this problem, it is proposed that the UE notify the gNB of the successful reception of PTM and perform transmission via the PTP branch. Note that it is not clear whether the UE also needs to include 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 on the PTP branch, or from which PDCP PDU the UE starts to correctly receive using the PTM branch.

[0227] In a similar and / or identical manner, in the case of switching from PTM to PTP, the gNB may not know which PDCP SN the UE has correctly received via the PTM branch (especially when the UE's radio state is poor). This means that the gNB may not know which PDCP PDU to use when starting the PTP branch.

[0228] Observation 5: In the case of 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 correctly received via the PTM branch.

[0229] Therefore, the following is studied: When dynamically switching between PTM / PTP, the UE notifies the SN information to the gNB via the PTP branch. When reporting SN information when the UE dynamically switches between PTM and PTP, it is simple to reuse the PDCP control PDU, that is, the PDCP status report including FMC (First PDCP SDU not found) and optionally including a bitmap (indicating whether subsequent PDCP SDUs are not found or correctly received). On the other hand, another option is for the UE to report the SN via the PTM branch, in which the first / last PDCP PDU reception of the UE has been successful. Therefore, the details to be reported by the UE when dynamically switching between PTM and PTP need to be further discussed.

[0230] In any of the above cases (i.e., the case of switching from PTP to PTM and the case of switching from PTM to PTP), for the sake of 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] Solution 5: RAN2 needs to study whether the UE needs to send a PDCP control PDU including PDCP SN information during dynamic switching for the sake of service continuity. It needs to be further studied whether PDCP information reporting can be reused.

[0232] Another point that needs to be studied is whether a lossless bearer type change identical and / or similar to the lossless dynamic switching in Proposal 5 is required. From the perspectives of service continuity and lossless mobility, it is considered that the bearer type change including PTP (branch) with RLC AM requires the same and / or similar reliability as the dynamic switching. Therefore, RAN2 needs to study whether a lossless bearer type change needs to be supported. When this is supported, the PDCP control PDU needs to be reused as UE assistance information in the same and / or similar manner as in Proposal 5.

[0233] Suggestion 6: RAN2 needs to discuss whether the same solution as that for the lossless bearer type change with RRC reconfiguration (i.e., the lossless dynamic switching of PDCP control PDUs as used in Suggestion 5) can be applied.

[0234] Reference numerals

[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 used in a mobile communication system for supporting Multicast and Broadcast Services (MBS), the communication method comprising the following steps: A user equipment that has started receiving an MBS session manages a first PDCP variable updated in response to receiving a Packet Data Convergence Protocol (PDCP) packet in the MBS session, the first PDCP variable being managed at the PDCP layer; and In response to determining that the reception of the MBS session has been interrupted for a predetermined time, the user equipment performs control to synchronize the first PDCP variable with a second PDCP variable managed by the network node.

2. The communication method according to claim 1, wherein Performing the control comprises the following steps: Sending a request to the network node for checking the second PDCP variable; and Receiving the second PDCP variable sent from the network node in response to the request.

3. The communication method according to claim 2, wherein Sending the request comprises sending an RRC message to the network node, the RRC message comprising the request and an identifier associated with the request, and The identifier comprises an MBS session identifier of the MBS session and / or an identifier related to a Multicast Radio Bearer (MRB) to which the MBS session is mapped.

4. The communication method according to claim 2, wherein Sending the request comprises sending a PDCP control PDU comprising the request to the network node.

5. The communication method according to claim 2, wherein Performing the control further comprises applying the second PDCP variable received from the network node to the first PDCP variable.

6. The communication method according to claim 1, wherein Performing the control comprises re - establishing a PDCP entity for reception of the MBS session.

7. The communication method according to claim 1, wherein Each of the first PDCP variable and the second PDCP variable is a count value, the count value comprising a Hyper - Frame Number (HFN) that counts up whenever a PDCP sequence number makes a round and the PDCP sequence number.

8. The communication method according to claim 1, wherein Each of the first PDCP variable and the second PDCP variable is a Hyper - Frame Number (HFN) that counts up whenever a PDCP sequence number makes a round.

9. The communication method according to claim 1, wherein Performing the control comprises setting an initial value for the first PDCP variable, and Setting the initial value comprises: using the PDCP sequence number included in the PDCP packet received from the network node via the MBS session as at least a part of the initial value.

10. The communication method according to claim 1, further comprising: The user equipment receives a timer configuration value from the network node for measuring the predetermined time.

11. A user equipment used in a mobile communication system for supporting Multicast and Broadcast Services (MBS), the user equipment comprising the following units: A unit that manages a first PDCP variable updated in response to receiving a Packet Data Convergence Protocol (PDCP) packet in the MBS session after starting to receive the MBS session from a network node, where the first PDCP variable is managed at the PDCP layer; and A unit that performs control to synchronize the first PDCP variable with a second PDCP variable managed by the network node in response to determining that the reception of the MBS session has been interrupted for a predetermined time.

12. A computer program product comprising a computer program, which when executed by a processor causes a user equipment used in a mobile communication system for supporting Multicast and Broadcast Services (MBS) to perform the following operations: After starting to receive an MBS session from a network node, manage a first PDCP variable updated in response to receiving a Packet Data Convergence Protocol (PDCP) packet in the MBS session, where the first PDCP variable is managed at the PDCP layer; and In response to determining that the reception of the MBS session has been interrupted for a predetermined time, perform control to synchronize the first PDCP variable with a second PDCP variable managed by the network node.

13. A processor used in a mobile communication system for supporting Multicast and Broadcast Services (MBS), the processor performing the following operations: After starting to receive an MBS session from a network node, manage a first PDCP variable updated in response to receiving a Packet Data Convergence Protocol (PDCP) packet in the MBS session, where the first PDCP variable is managed at the PDCP layer; and In response to determining that the reception of the MBS session has been interrupted for a predetermined time, perform control to synchronize the first PDCP variable with a second PDCP variable managed by the network node.

Images