COMMUNICATION METHOD, USER EQUIPMENT, PROGRAM, AND PROCESSOR

Abstract

To enable an improved multicast broadcast service.SOLUTION: A communication method used in a mobile communication system supporting a Multicast Broadcast Service (MBS) includes the steps of managing a first PDCP variable which is updated according to reception of PDCP packet in an MBS session in a Packet Data Convergence Protocol (PDCP) layer by a user device that has started receiving the MBS session from a base station, and performing control to synchronize the first PDCP variable with a second PDCP variable managed by the base station in response to the user device determining that reception of the MBS session has been interrupted for a predetermined period of time.SELECTED DRAWING: Figure 14

Description

[Technical field]

[0001] The present disclosure relates to a communication method, a user device, a program, and a processor for use in a mobile communication system. [Background technology]

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

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

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

[0005] Therefore, an object of the present disclosure is to provide a communication method, a user device, and a base station that enable an improved multicast broadcast service.

[0006] A communication method according to a first aspect is a method for use in a mobile communication system supporting a multicast broadcast service (MBS), comprising a step of receiving, by a user equipment, a radio resource control (RRC) Reconfiguration message from a base station, the message including an MBS session identifier of an MBS session, an identifier for an MRB to which the MBS session is mapped, and a hyperframe number (HFN) corresponding to the MBS session.

[0007] A user equipment according to a second aspect is a user equipment for use in a mobile communication system supporting a multicast broadcast service (MBS). The user equipment includes a receiver for receiving a radio resource control (RRC) Reconfiguration message from a base station, the message including an MBS session identifier of an MBS session, an identifier for an MRB to which the MBS session is mapped, and a hyperframe number (HFN) corresponding to the MBS session.

[0008] A base station according to a third aspect is a base station used in a mobile communication system supporting a multicast broadcast service (MBS). The base station includes a transmitter that transmits a radio resource control (RRC) Reconfiguration message to a user device, the message including an MBS session identifier of an MBS session, an identifier for an MRB to which the MBS session is mapped, and a hyperframe number (HFN) corresponding to the MBS session.

[0009] A communication method according to a fourth aspect is a communication method used in a mobile communication system supporting a multicast broadcast service (MBS), and includes the steps of: a user device that has started receiving an MBS session from a base station managing a first PDCP variable in a Packet Data Convergence Protocol (PDCP) layer, the first PDCP variable being updated in response to reception of a PDCP packet in the MBS session; and, in response to the user device determining that reception of the MBS session has been interrupted for a predetermined period of time, performing control to synchronize the first PDCP variable with a second PDCP variable managed by the base station.

[0010] A user equipment according to a fifth aspect is a user equipment used in a mobile communication system supporting a multicast broadcast service (MBS), and includes a control unit that manages a first PDCP variable in a Packet Data Convergence Protocol (PDCP) layer, which is updated in response to reception of a PDCP packet in the MBS session, when the user equipment starts receiving an MBS session from a base station. In response to determining that reception of the MBS session has been interrupted for a predetermined period of time, the control unit performs control to synchronize the first PDCP variable with a second PDCP variable managed by the base station.

[0011] A base station according to a sixth aspect is a base station used in a mobile communication system supporting a multicast broadcast service (MBS), and includes: a control unit that manages PDCP variables in a Packet Data Convergence Protocol (PDCP) layer that are updated in response to transmission of PDCP packets in the MBS session when transmission of an MBS session is started; a receiving unit that receives a request from a user device to check the PDCP variables; and a transmitting unit that transmits the PDCP variables to the user device in response to the request. [Brief description of the drawings]

[0012] [Figure 1] 1 is a diagram showing a configuration of a mobile communication system according to an embodiment. [Diagram 2] FIG. 2 is a diagram showing a configuration of a UE (user equipment) according to an embodiment. [Diagram 3] A diagram showing the configuration of a gNB (base station) according to an embodiment. [Figure 4] A diagram showing the configuration of a protocol stack of a wireless interface of a user plane that handles data. [Diagram 5] FIG. 2 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals). [Figure 6] FIG. 2 is a diagram showing an overview of MBS traffic distribution according to an embodiment. [Figure 7] FIG. 13 is a diagram illustrating a distribution mode according to the embodiment. [Figure 8] FIG. 2 is a diagram showing a split multicast radio bearer (MRB) according to an embodiment. [Figure 9] FIG. 2 is a diagram showing an operation scenario of the mobile communication system according to the embodiment. [Figure 10] FIG. 13 is a diagram illustrating an example of a PDCP variable according to an embodiment. [Figure 11] FIG. 13 is a diagram showing a PDCP data PDU according to an embodiment. [Figure 12] A diagram showing the operation of identifying RCVD_COUNT, which is the COUNT value of a received PDCP data PDU, in a UE (receiving side PDCP entity) according to an embodiment. [Figure 13] A diagram showing the operation of a receiving PDCP entity of a UE according to an embodiment. [Figure 14] FIG. 1 is a diagram illustrating the operation of a UE according to an embodiment. [Figure 15] FIG. 2 is a diagram illustrating an example of an operation of the mobile communication system according to the embodiment. [Figure 16] FIG. 11 is a diagram showing another example of the operation of the mobile communication system according to the embodiment. [Figure 17] A diagram showing PDCP-fixed PTM / PTP switching based on the current agreement. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0033] The RLC layer transmits 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 the UE 100 and the RLC layer of the gNB 200 via a logical channel.

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

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

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

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

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

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

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

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

[0042] The multicast service provides services not to all UEs 100 but to a group of UEs 100 participating in the multicast service (multicast session). The MBS session used in the multicast service is called a multicast session. The multicast service allows the same content to be provided to a group of UEs 100 in a more wirelessly efficient manner than the broadcast service.

[0043] FIG. 6 is a diagram showing an overview of MBS traffic delivery according to this embodiment.

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

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

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

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

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

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

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

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

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

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

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

[0055] The MBS traffic channel is a type of logical channel and may be referred to as an MTCH. The MBS traffic channel is mapped to a downlink shared channel (DL-SCH), which is a type of transport channel.

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

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

[0058] In the second distribution mode, UE 100 may receive MBS data in the following three procedures. First, UE 100 receives MCCH setting information by SIB (MBS-SIB) transmitted on BCCH from gNB 200. Second, UE 100 receives MCCH from gNB 200 based on MCCH setting information. MCCH transmits MTCH setting information. Third, UE 100 receives MTCH (MBS data) based on MTCH setting information. Hereinafter, MTCH setting information and / or MCCH setting information may be referred to as MBS reception setting.

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

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

[0061] 8 is a diagram 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 delivery mode described above.

[0062] The gNB200 can set an MRB separated into a PTP communication path and a PTM communication path to the UE100. This allows the gNB200 to dynamically switch the transmission of MBS data to the UE100 between PTP (PTP communication path) and PTM (PTM communication path). Alternatively, the gNB200 can improve reliability by dually transmitting the same MBS data using both PTP (PTP communication path) and PTM (PTM communication path). In the following, the PTP communication path is called a PTP leg, and the PTM communication path is called a PTM leg. In addition, the functional units corresponding to each layer are called entities.

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

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

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

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

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

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

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

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

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

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

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

[0074] (Mobile communication system operation) FIG. 9 is a diagram showing an operation scenario of the mobile communication system 1 according to this embodiment.

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

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

[0077] Each UE 100 has a PDCP entity 101 associated with the MBS session (specifically, a receiving PDCP entity associated with the MRB belonging to the MBS session) in the PDCP layer. When each PDCP entity 101 (PDCP entities 101a and 101b in the example of FIG. 10) starts transmission of an MBS session, it manages PDCP variables that are updated in response to reception of a PDCP packet in the MBS session.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0092] As described above, the receiving - side PDCP entity 101 of the UE100 updates PDCP variables in response to the reception of PDCP packets (PDCP data PDUs) from the gNB200. Specifically, the receiving - side PDCP entity 101 of the UE100 sets the initial value of the PDCP variable to zero and updates (increments, counts up) the PDCP variable in response to the reception of packets from the gNB200.

[0093] Also, for a PDCP packet (PDCP data PDU), the receiving - side PDCP entity 101 of the UE100 discards the PDCP packet when the Integrity verification fails, or when RCVD_COUNT < RX_DELIV (such as when it has already been received), or when RCVD_COUNT has already been received.

[0094] For example, the receiving PDCP entity 101 of the UE 100 may not be able to receive packets for a certain period of time due to poor wireless conditions or other reasons, and may not be able to receive packets normally when it starts receiving packets thereafter. Specifically, when RCVD_SN>>SN(RX_DELIV), the packets may be regarded as past packets.

[0095] Such a problem is mainly caused by the HFN being out of synchronization between the gNB 200 and the UE 100. If the UE 100 is unable to receive MBS (PTM reception) for a certain period of time, such out-of-synchronization may occur. In particular, such a situation is likely to occur with PTM, since it is received by multiple UEs and there is no layer 2 feedback. As a result, the UE 100 may not be able to properly perform reception window control and packet reordering in the PDCP layer, and there is a concern that it may not be able to properly continue MBS reception. This embodiment is an embodiment that attempts to solve such a problem.

[0096] 14 is a diagram showing the operation of the UE 100 according to the present embodiment. It is assumed that the UE 100 is any one of the UE 100a to UE 100c shown in FIG.

[0097] In step S1, the UE 100 starts receiving (PTM reception) an MBS session from the gNB 200. The MBS session may be a multicast session or a broadcast session.

[0098] In step S2, the receiving side PDCP entity 101 of the UE 100 manages PDCP variables (hereinafter referred to as "first PDCP variables") that are updated in response to reception of a PDCP packet in the MBS session.

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

[0100] If it is determined that reception of the MBS session has been interrupted for a predetermined period of time (step S3: Yes), in step S4, UE100 performs control to synchronize the first PDCP variable with the PDCP variable managed by gNB200 (hereinafter referred to as the "second PDCP variable").

[0101] In this way, in a situation where gNB200 and UE100 can determine that the HFN has become out of synchronization, UE100 can continue receiving MBS appropriately by performing control to synchronize the first PDCP variable that it manages with the second PDCP variable that gNB200 manages.

[0102] Step S4 may include a step of transmitting a request to the gNB 200 to confirm the second PDCP variables, and a step of receiving the second PDCP variables transmitted from the gNB 200 in response to the request. The UE 100 may apply the second PDCP variables received from the gNB 200 to the first PDCP variables. This enables the UE 100 to synchronize the first PDCP variables managed by the UE 100 with the second PDCP variables managed by the gNB 200.

[0103] Here, the UE 100 may transmit an RRC message including a request for checking the second PDCP variable and an identifier associated with the request to the gNB 200. The identifier may include at least one of an MBS session identifier of the MBS session and an identifier related to the MRB to which the MBS session is mapped (e.g., an MRB identifier, an MTCH identifier, or a QoS flow identifier, etc.). The RRC message may be, for example, an MBS Interest Indication message or a UE Assistance Information message.

[0104] The UE 100 may receive a message including the second PDCP variable and an identifier associated with the second PDCP variable from the gNB 200. The identifier is the same as the identifier included in the above-mentioned RRC message. However, the message may not include the identifier associated with the second PDCP variable. The message may be UE-dedicated signaling (e.g., an RRC Reconfiguration message or a MAC Control Element (MAC CE)). The message may also be broadcast signaling (e.g., an MBS-SIB or an MCCH).

[0105] Alternatively, the receiving PDCP entity 101 of the UE 100 may transmit a PDCP control PDU including a request to check the second PDCP variable to the gNB 200. In response to receiving the PDCP control PDU, the transmitting PDCP entity 201 of the gNB 200 may transmit a PDCP control PDU including the second PDCP variable to the receiving PDCP entity 101 of the UE 100.

[0106] Step S4 may include a step of re-establishing a PDCP entity (receiving PDCP entity 101) for receiving the MBS session. This allows the first PDCP variable managed by the UE 100 to be initialized (reset) in a situation in which the HFN can be considered to be out of synchronization between the gNB 200 and the UE 100.

[0107] Step S4 may include a step of setting an initial value to the first PDCP variable. The step of setting the initial value may include a step of using a PDCP SN included in a PDCP packet (PDCP data PDU) received from the gNB 200 via the MBS session as at least a part of the initial value. This makes it possible to apply the latest PDCP SN as at least a part of the first PDCP variable.

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

[0109] In step S101, the gNB 200 may transmit a setting value of a timer for timing a predetermined time to the UE 100. The UE 100 receives the timer setting value. The timer setting value may be notified to the UE 100 by UE dedicated signaling (e.g., an RRC Reconfiguration message). The timer setting value may also be notified to the UE 100 by broadcast signaling (e.g., an MBS-SIB or an MCCH). However, the timer setting value may be determined depending on the implementation of the UE 100. The timer setting value may be set for each MBS session, each QoS flow, or each G-RNTI.

[0110] In step S102, the gNB 200 starts transmitting MBS data of a certain MBS session to multiple UEs 100 (UEs 100a to 100c in the example of FIG. 9) by PTM (multicast or broadcast). The UE 100 starts receiving the MBS data and updates its own PDCP variables (first PDCP variables).

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

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

[0113] 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 set by the timer setting 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 performs at least one process among steps S108 to S112.

[0114] In step S108, UE 100 may re-establish a PDCP entity (receiving PDCP entity 101) for MBS reception. It is assumed that UE 100 automatically assigns an initial value to a first PDCP variable (for example, RX_DELIV) as a result of such PDCP re-establishment. Here, in UE 100, the RRC layer may instruct the PDCP layer (receiving PDCP entity 101) to re-establish PDCP. Alternatively, the PDCP layer (receiving PDCP entity 101) may automatically re-establish PDCP. When the PDCP layer (receiving PDCP entity 101) automatically re-establishes PDCP, it may notify the RRC layer of this.

[0115] In step S109, the UE 100 makes a confirmation request (inquiry) to the gNB 200 regarding the current COUNT value (second PDCP variable) managed by the gNB 200. The gNB 200 receives the confirmation request (inquiry).

[0116] In step S110, in response to receiving a confirmation request (inquiry) from the UE 100, the gNB 200 transmits a 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.

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

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

[0119] As a modification of the above timer, the following timer operation may be used. Specifically, UE 100 starts the timer in step S104, but the timer may be started (or reset and restarted) when MBS data is normally received in S102. When the timer expires, UE 100 can detect that MBS reception has been interrupted for a predetermined time, as in S107. That is, UE 100 may start (or reset and restart) the timer every time MBS data is normally received, and determine that MBS reception has been interrupted for a predetermined time when the timer expires.

[0120] Fig. 16 is a diagram showing another example of the operation of the mobile communication system 1 according to this embodiment. Here, differences from the operation example shown in Fig. 15 will be described.

[0121] The operations in steps S201 to S208 are similar to the operations in steps S101 to S108 in FIG.

[0122] In step S209, the UE 100 may make a confirmation request (inquiry) to the gNB 200 for the current HFN (second PDCP variable) managed by the gNB 200. The gNB 200 receives the confirmation request (inquiry).

[0123] In step S210, in response to receiving a confirmation request (inquiry) from the UE 100, the gNB 200 may transmit 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.

[0124] Alternatively, the UE 100 may infer the HFN (second PDCP variable) managed by the gNB 200. For example, the UE 100 may generate HFN candidates, attempt integrity verification using each HFN candidate, and determine an HFN candidate that has been successfully verified as the HFN (second PDCP variable) managed by the gNB 200.

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

[0126] In step S212, UE100 receives an MBS session (data) from gNB200.

[0127] In step S213, UE 100 acquires the PDCP SN of the PDCP packet (PDCP data PDU) first received from gNB 200 in step S212. Then, UE 100 sets the PDCP SN acquired from the first received PDCP packet in the PDCP SN section of the COUNT value (first PDCP variable) managed by itself, for example, in the PDCP SN section of RX_DELIV. After RRC re-establishment (step S208), UE 100 may set the PDCP SN acquired from the first received PDCP packet as the initial value of the PDCP SN section of the COUNT value (first PDCP variable) managed by itself.

[0128] (Other embodiments) In the above-described embodiment, a scenario in which the UE 100 cannot receive the PTM for a certain period of time due to deterioration of the radio condition is mainly assumed. However, it is also assumed that the gNB 200 intentionally stops transmission for a certain period of time (because there is no data to transmit, etc.). Therefore, in an example in which the timer is used to detect that the MBS reception has been interrupted for a certain period of time as in the above-described embodiment, even if the gNB 200 intentionally interrupts the MBS transmission for a certain period of time (because there is no data to transmit, etc.), the UE 100 may determine that the MBS reception has been interrupted, and therefore, there is a risk of executing unnecessary processing. Therefore, when the gNB 200 intentionally stops the MBS transmission, it may transmit an instruction to stop the timer to the UE 100. When the UE 100 receives the instruction to stop, the UE 100 stops the timer. When the gNB 200 resumes the MBS transmission, the gNB 200 may transmit an instruction to resume the timer to the UE 100. When the UE 100 receives the instruction to resume, the UE 100 resumes the timer. When resuming, the timer may be reset (i.e., set to 0) or may not be reset (i.e., may be resumed from the value at the time of stopping). Alternatively, when resuming MBS transmission, the gNB 200 may resume transmission of MBS data without transmitting the resume instruction. When the UE 100 receives MBS data, the UE 100 assumes that the gNB 200 has resumed MBS transmission, and resumes the timer.

[0129] The above-mentioned operational flows are not limited to being implemented separately and independently, but can be implemented by combining two or more operational flows. For example, some steps of one operational flow may be added to another operational flow. Also, some steps of one operational flow may be replaced with some steps of another operational flow.

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

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

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

[0133] The above describes the embodiments in detail with reference to the drawings, but the specific configuration is not limited to that described above, and various design changes, etc. are possible without departing from the spirit of the invention.

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

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

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

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

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

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

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

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

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

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

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

[0145] When a split MRB with PTM leg / PTP leg is configured, the UE needs to monitor both the G-RNTI of the PTM leg and the C-RNTI of the PTP leg. In LTE SC-PTM, the SC-PTM reception opportunity is independent of the unicast DRX scheme, i.e., the DRX is separate. This concept could be the basis for NR MBS, since the G-RNTI is received by multiple UEs, whereas the C-RNTI is UE-specific, and the alignment of the two DRXs is very difficult. This means that if the UE has to constantly monitor the G-RNTI, it will need to wake up frequently, which will cause additional power consumption. On the other hand, a connected UE needs to monitor the C-RNTI, i.e., the C-DRX, for unicast reception, but this is not an additional burden for the UE.

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

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

[0148] Option 1: Activation / Deactivation-Based Switching The gNB instructs the UE to activate / deactivate the PTM leg by DCI, MAC CE, or RRC signaling, etc. This option can be more flexible when MBS data is received over two legs, such as split bearer or PDCP packet duplication, in addition to MBS data reception over either PTM or PTP. The UE can reduce power consumption from the deactivated PTM leg. Note that the NW implementation may decide to keep two legs active at all times, which can cover the intent of option 4 below.

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

[0150] Option 3: RRC reconfiguration based switching The gNB reconfigures the UE as either PTM or PTP MRB via RRC reconfiguration, i.e. it does not associate PTM and PTP legs with one MRB, i.e. it is like a "bearer type change" and is inconsistent with the split MRB architecture. Also, this option involves L3, so it is questionable how "dynamic" the switch between PTM and PTP can be.

[0151] Option 4: No signaling based switching The UE must attempt to receive from both the PTM leg and the PTP leg whenever a split MRB has two legs configured. This option ensures maximum scheduling flexibility from the gNB's point of view, but does not provide any power saving opportunities for the UE.

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

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

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

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

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

[0157] 6. PDCP Actions 7. Initial values ​​of state variables In addition to RLC UM mode, RAN2 agreed to support RLC AM mode for the PTP leg of split MRB. It is also commonly understood that L2 reliability depends only on dynamic PTM / PTP switching because "RLC-AM does not support PTM (for MBS R17 WI)". Therefore, it is worth considering how to reduce packet loss when starting to receive MBS data or when switching dynamically between PTM / PTP for service continuity.

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

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

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

[0161] Option A: The gNB notifies the UE of the initial value of COUNT, or RX_NEXT and RX_DELIV. This option simply modifies the initial value for the reception window based on information from the gNB so that the UE can receive the first transmission of MBS data with existing mechanisms. However, from the PDCP layer point of view, it is questionable whether the UE can always successfully receive the first transmission intended by the gNB due to switching delays, poor radio conditions, being outside the RLC reconstruction window, etc. It is unclear how this option works in this case.

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

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

[0164] For the above reasons, further discussion should be carried out based on option B. According to Rel-16 sidelink communication of broadcast and groupcast, and taking into account the progress of SA3 on security of NR MBS, RAN2 should at least agree that the UE sets the initial value of the state variables from the first received PDCP PDU of MBS data.

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

[0166] 8. Simultaneous reception and UE assistance information In particular, PTP (legs) are configured in RLC AM for services that require reliability, and lossless switching is important for service continuity as well as lossless mobility. If proposal 1 is agreed upon, the UE needs to support simultaneous reception from both PTM and PTP legs, i.e., two legs can be activated at the same time, similar to the existing PDCP packet duplication. This is because the PTM leg is received by multiple UEs and can easily not be the optimal MCS for a particular UE. Therefore, RAN2 should agree to adopt the use of simultaneous reception at least for a certain period of time during dynamic PTM / PTP switching.

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

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

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

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

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

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

[0173] In both of the above cases (i.e., switching from PTP to PTM and switching from PTM to PTP), upon dynamic switching (e.g., activation / deactivation of MAC CE), a PDCP control PDU containing PDCP SN information for service continuity needs to be triggered.

[0174] Proposal 5: RAN2 should consider whether UE should send PDCP control PDU including PDCP SN information during dynamic switching for service continuity. Whether PDCP information report can be reused needs further study.

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

[0176] Proposal 6: RAN2 should discuss whether lossless bearer type change with RRC reconfiguration, i.e. the same solution as lossless dynamic switching by PDCP control PDU as in Proposal 5, is applicable. [Explanation of symbols]

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

Claims

1. A communication method for use in a mobile communication system supporting a Multicast Broadcast Service (MBS), comprising: A user equipment that has started receiving an MBS session from a network node manages, in a Packet Data Convergence Protocol (PDCP) layer, a first PDCP variable that is updated in response to receiving a PDCP packet in the MBS session; In response to the user equipment determining that reception of the MBS session has been interrupted for a predetermined period of time, control is performed to synchronize the first PDCP variable with a second PDCP variable managed by the network node. Communication methods.

2. The control includes: sending a request to the network node to validate the second PDCP variable; receiving the second PDCP variable transmitted from the network node in response to the request. The communication method according to claim 1 .

3. sending the request includes sending an RRC message to the network node including the request and an identifier associated with the request; The identifier includes at least one of an MBS session identifier of the MBS session and an identifier for a Multicast Radio Bearer (MRB) to which the MBS session is mapped. The communication method according to claim 2 .

4. Transmitting the request includes transmitting a PDCP control PDU including the request to the network node. The communication method according to claim 2 .

5. The controlling further includes applying the second PDCP variables received from the network node to the first PDCP variables. The communication method according to claim 2 .

6. The controlling includes re-establishing a PDCP entity for receiving the MBS session. The communication method according to claim 1 .

7. Each of the first PDCP variable and the second PDCP variable is a count value consisting of a hyperframe number (HFN) that is counted up every time the PDCP sequence number goes around, and the PDCP sequence number. The communication method according to claim 1 .

8. Each of the first PDCP variable and the second PDCP variable is a hyperframe number (HFN) that is incremented every time the PDCP sequence number wraps around. The communication method according to claim 1 .

9. The controlling includes setting an initial value to the first PDCP variable; Setting the initial value includes using a PDCP sequence number included in a PDCP packet received from the network node via the MBS session as at least a part of the initial value. The communication method according to claim 1 .

10. The method further comprises receiving, by the user equipment, a setting value of a timer for timing the predetermined time from the network node. The communication method according to claim 1 .

11. A user equipment for use in a mobile communication system supporting a Multicast Broadcast Service (MBS), comprising: When starting to receive an MBS session from a network node, a PDCP (Packet Data Convergence Protocol) layer is configured to manage a first PDCP variable that is updated in response to receiving a PDCP packet in the MBS session; and a control means for controlling synchronization of the first PDCP variable with a second PDCP variable managed by the network node in response to determining that reception of the MBS session has been interrupted for a predetermined period of time. User equipment.

12. A user equipment for use in a mobile communication system supporting a multicast broadcast service (MBS), When starting to receive an MBS session from a network node, managing a first PDCP variable in a Packet Data Convergence Protocol (PDCP) layer, the first PDCP variable being updated in response to receiving a PDCP packet in the MBS session; and in response to determining that reception of the MBS session has been interrupted for a predetermined period of time, performing control to synchronize the first PDCP variable with a second PDCP variable managed by the network node. program.

13. 1. A processor for use in a mobile communication system supporting a Multicast Broadcast Service (MBS), comprising: When starting to receive an MBS session from a network node, managing a first PDCP variable in a Packet Data Convergence Protocol (PDCP) layer, the first PDCP variable being updated in response to receiving a PDCP packet in the MBS session; In response to determining that reception of the MBS session has been interrupted for a predetermined period of time, control is performed to synchronize the first PDCP variable with a second PDCP variable managed by the network node. Processor.

Images