COMMUNICATION METHOD, USER EQUIPMENT, PROCESSOR, PROGRAM, AND MOBILE COMMUNICATION SYSTEM

Abstract

A communication method according to a first embodiment is a method implemented in user equipment that receives, from a base station, a series of PDCP data PDUs constituting multicast / broadcast service (MBS) data. The communication method comprises: a step of receiving, from the base station, a hyper-frame number that is counted up each time a sequence number included in a PDCP data PDU transmitted by the base station makes one cycle; and a step of determining, from the hyper-frame number and a PDCP sequence number included in the PDCP data PDU received by the user equipment from the base station, an initial value of a PDCP state variable managed by the user equipment.

Description

[Technical field]

[0001] The present disclosure relates to a communication method, a user equipment, and a base station for use in a mobile communication system. [Background technology]

[0002] The 3GPP (3rd Generation Partnership Project) standard defines the technical specifications of NR (New Radio), which is a fifth-generation (5G) wireless access technology. Compared with LTE (Long Term Evolution), which is 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 communication method executed by a user equipment receiving a series of PDCP (Packet Data Convergence Protocol) data PDUs (Protocol Data Units) constituting Multicast Broadcast Service (MBS) data from a base station, and includes receiving a Radio Resource Control (RRC) Reconfiguration message from the base station, the hyperframe number being counted up each time a sequence number included in the PDCP data PDU transmitted by the base station goes around once, and determining an initial value of a PDCP state variable managed by the user equipment based on the hyperframe number included in the RRC Reconfiguration message.

[0007] A user equipment according to a second aspect is a user equipment that receives a series of PDCP (Packet Data Convergence Protocol) data PDUs (Protocol Data Units) constituting Multicast Broadcast Service (MBS) data from a base station, and is equipped with a receiving unit that receives from the base station a Radio Resource Control (RRC) Reconfiguration message that includes a hyperframe number that is counted up each time a sequence number included in the PDCP data PDU transmitted by the base station completes one cycle, and a control unit that determines initial values ​​of PDCP state variables managed by the user equipment based on the hyperframe number included in the RRC Reconfiguration message.

[0008] A base station according to a third aspect is a base station that transmits a series of PDCP (Packet Data Convergence Protocol) data PDUs (Protocol Data Units) constituting Multicast Broadcast Service (MBS) data to a user device, and is equipped with a transmission unit that transmits to the user device a Radio Resource Control (RRC) Reconfiguration message including a hyperframe number that is counted up each time a sequence number included in the PDCP data PDU transmitted by the base station goes around once. [Brief description of the drawings]

[0009] [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] 2 is a diagram showing an example of internal processing related to MBS reception of the UE 100 according to the embodiment. FIG. [Figure 9] FIG. 11 is a diagram showing another example of the internal processing related to MBS reception of the UE 100 according to the embodiment. [Figure 10] FIG. 2 is a diagram showing the operation of a PDCP layer in the mobile communication system according to the embodiment. [Figure 11] FIG. 11 is a diagram illustrating an example of a PDCP state variable according to an embodiment. [Figure 12]1 is a diagram showing an example of a PDCP data PDU constituting MBS data according to an embodiment. FIG. [Figure 13] A figure showing the operation of identifying RCVD_COUNT, which is the COUNT value of a received PDCP data PDU, in a receiving PDCP entity of a UE according to an embodiment. [Figure 14] A figure showing an example of the operation of a receiving PDCP entity of a UE according to an embodiment. [Figure 15] FIG. 1 is a diagram illustrating the operation of a UE according to an embodiment. [Figure 16] FIG. 4 is a diagram illustrating an operation according to the first embodiment. [Figure 17] FIG. 11 is a diagram illustrating an operation according to the second embodiment. [Figure 18] FIG. 13 is a diagram illustrating an operation according to the third embodiment. [Figure 19] FIG. 13 is a diagram showing a PDCP data PDU according to a third embodiment. [Figure 20] FIG. 13 is a diagram illustrating an operation according to the fourth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] 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.

[0011] (Configuration of a mobile communication system) FIG. 1 is a diagram showing a configuration of a mobile communication system according to an 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.

[0012] 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.

[0013] 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).

[0014] 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").

[0015] 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.

[0016] 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.

[0017] 2 is a diagram showing a configuration of a UE 100 (user equipment) according to an 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 configure a wireless communication unit that performs wireless communication with the gNB 200.

[0018] 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.

[0019] 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.

[0020] 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.

[0021] 3 is a diagram showing a configuration of a gNB 200 (base station) according to an embodiment. The gNB 200 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 CN 20.

[0022] 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.

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

[0024] 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.

[0025] 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.

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

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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.

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

[0032] 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.

[0033] 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).

[0034] 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.

[0035] 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 in response to 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.

[0036] 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.

[0037] (Overview of MBS) An overview of the MBS according to the 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.

[0038] 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.

[0039] 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.

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

[0041] 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.

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

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] FIG. 7 is a diagram showing a distribution mode according to the embodiment.

[0049] 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.

[0050] 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.

[0051] The MBS reception configuration includes MBS traffic channel configuration information (hereinafter referred to as "MTCH configuration information") regarding the configuration of an MBS traffic channel that transmits MBS data. The MTCH configuration information includes MBS session information (including an MBS session identifier described below) regarding an MBS session, and scheduling information of the MBS traffic channel corresponding to this MBS session. The MBS traffic channel scheduling information may include discontinuous reception (DRX) configuration for the MBS traffic channel. The discontinuous reception configuration includes a timer value (On Duration Timer) that defines the on-duration (On Duration: reception period), a timer value (Inactivity Timer) that extends the on-duration, a scheduling interval or DRX cycle (Scheduling Period, DRX Cycle), and 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 defining the maximum time until retransmission (Retransmission Timer), and a timer value defining the minimum interval until DL allocation for HARQ retransmission (HARQ RTT Timer).

[0052] 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 Down Link-Shared CHannel (DL-SCH), which is a type of transport channel.

[0053] 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.

[0054] 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.

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

[0056] 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).

[0057] 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, the source-specific IP multicast address, and the session identifier is called an MBS session identifier. The TMGI, the source-specific IP multicast address, the session identifier, and the G-RNTI are collectively called MBS session information.

[0058] Fig. 8 is a diagram showing an example of an internal process related to MBS reception of the UE 100 according to the embodiment. Fig. 9 is a diagram showing another example of an internal process related to MBS reception of the UE 100 according to the embodiment.

[0059] One MBS Radio Bearer (MRB) is one radio bearer that transmits a multicast session or a broadcast session. That is, there are cases where a multicast session is associated with an MRB and cases where a broadcast session is associated with an MRB.

[0060] The MRB and corresponding logical channels (e.g., MTCH) are configured in the UE 100 from the gNB 200 by RRC signaling. The MRB configuration procedure may be separated from the data radio bearer (DRB) configuration procedure. In the RRC signaling, one MRB can be configured with "PTM only", "PTP only", or "both PTM and PTP". The type of such an MRB can be changed by RRC signaling.

[0061] In FIG. 8, an example is shown in which a multicast session and a dedicated traffic channel (DTCH) are associated with MRB#1, a multicast session and MTCH#1 are associated with MRB#2, and a broadcast session and MTCH#2 are associated with MRB#3. That is, MRB#1 is an MRB with PTP only, MRB#2 is an MRB with PTM only, and MRB#3 is an MRB with PTM only. Note that DTCH is scheduled using the cell RNTI (C-RNTI). MTCH is scheduled using the G-RNTI.

[0062] The PHY layer of the UE 100 processes user data (received data) received on a PDSCH, which is one of the physical channels, and transmits the data to a downlink shared channel (DL-SCH), which is one of the transport channels. The MAC layer (MAC entity) of the UE 100 processes data received on the DL-SCH, and transmits the received data to a corresponding logical channel (corresponding RLC entity) based on a logical channel identifier (LCID) included in a header (MAC header) included in the received data.

[0063] In FIG. 9, an example is shown in which a DTCH and an MTCH are associated with an MRB associated with a multicast session. Specifically, one MRB is split into two legs, one leg is associated with a DTCH, and the other leg is associated with an MTCH. The two legs are combined in the PDCP layer (PDCP entity). That is, the MRB is an MRB for both PTM and PTP. Such an MRB is sometimes called a split MRB.

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

[0065] The gNB 200 transmits MBS data of a certain MBS session to multiple UEs 100 (UEs 100a to 100c in the example of FIG. 10) 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 distribution mode may be a first distribution mode or a second distribution mode.

[0066] The gNB 200 has a transmitting 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 transmitting PDCP entity 201 starts transmission of the MBS session, it manages PDCP state variables that are updated in response to transmission of PDCP data PDUs (Protocol Data Units) in the MBS session.

[0067] Each UE 100 has a receiving PDCP entity 101 associated with the MBS session (specifically, a receiving PDCP entity associated with an MRB belonging to the MBS session) in the PDCP layer. When starting reception of an MBS session, each receiving PDCP entity 101 (receiving PDCP entities 101a to 101c in the example of FIG. 10) manages PDCP state variables that are updated in response to reception of a PDCP data PDU in the MBS session.

[0068] As shown in Fig. 11, the PDCP state 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. The bit length of the PDCP SN may be a default value (a predetermined fixed value). Note that the term "PDCP state variable" is not limited to referring to the COUNT value, but is also used as a term to refer to various variables (HFN or PDCP SN, or TX_NEXT, RX_NEXT, RX_DELIV, RX_REORD, etc.) handled in the PDCP layer.

[0069] Fig. 12 is a diagram showing an example of a PDCP data PDU constituting MBS data. As shown in Fig. 12, the PDCP data PDU has a PDCP SN, data, and a MAC-I. The PDCP SN is a sequence number that is sequentially assigned to the PDCP data PDU. The data corresponds to a PDCP SDU (Service Data Unit). The MAC-I corresponds to a message authentication code. The PDCP data PDU may not have a MAC-I. 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, to count up the HFN every time the PDCP sequence number goes around once.

[0070] 13 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.

[0071] 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. In PTM reception, the initial value of RX_DELIV may be set using the SN of the first received packet. Window_Size is a constant that indicates the size of the reordering window.

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

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

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

[0075] FIG. 14 is a diagram showing an example of the operation of the receiving PDCP entity 101 of the UE 100.

[0076] First, when the receiving PDCP entity 101 receives a PDCP PDU (PDCP data 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).

[0077] 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).

[0078] 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 SDUs expected to be received next. The initial value of RX_NEXT is zero. In PTM reception, the initial value of RX_NEXT may be set using the SN of the first received packet. 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 step S21 when "outOfOrderDelivery" is configured in 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.

[0079] 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).

[0080] 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.

[0081] 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 (step S28).

[0082] (Operation of the mobile communication system) Generally, the initial value of the PDCP state variable is zero. When data transmission from the gNB 200 (transmitting - side PDCP entity 201) to the UE 100 (receiving - side PDCP entity 101) starts, the PDCP state variables are updated synchronously at the gNB 200 (transmitting - side PDCP entity 201) and the UE 100 (receiving - side PDCP entity 101).

[0083] However, in the scenario shown in Fig. 10, the UE 100 (any of the UEs 100a to 100c) cannot necessarily start MBS reception from the time when the gNB 200 starts providing an MBS session (multicast session or broadcast session), and the PDCP state variables in the gNB 200 (transmitting PDCP entity 201) and the UE 100 (receiving PDCP entity 101) become asynchronous, which causes a problem that the PDCP layer operation as described above cannot be performed appropriately. For example, any of the UEs 100 may start MBS reception in the middle of an MBS session provided by the gNB 200. Such a UE 100 may be a UE 100 that has changed cells (e.g., cell reselection or handover) from another gNB 200 (another cell).

[0084] 15 is a diagram showing an operation of the UE 100 according to the embodiment. In the embodiment, the receiving PDCP entity 101 of the UE 100 receives, from the gNB 200, a series of PDCP data PDUs constituting MBS data transmitted in PTM from the gNB 200. The PDCP data PDUs may be referred to as PDCP MRB data PDUs.

[0085] In step S1, UE100 receiving a specific MRB receives from gNB200 an HFN (specifically, the current (latest) HFN for the specific MRB) that is counted up each time the sequence number (PDCP SN) included in the PDCP data PDU transmitted by gNB200 goes around once.

[0086] Prior to step S1, the UE 100 may request the gNB 200 to provide an HFN. The UE 100 may request the gNB 200 to provide an HFN in response to a condition related to failure to receive MBS data (PDCP data PDU) normally being satisfied. For example, the UE 100 may request the gNB 200 to provide an HFN in response to a condition related to failure to receive MBS data (PDCP data PDU) normally being satisfied. Number of timesIn response to at least one of the first and second conditions indicating that the UE 100 has exceeded the threshold, the UE 100 may request the gNB 200 to provide the HFN in response to the satisfaction of a third condition indicating that the UE 100 does not have information on the current (latest) HFN. For example, when the UE 100 does not have a current HFN because it has become interested in receiving a broadcast session midway or has started receiving a broadcast session midway, the UE 100 may request the gNB 200 to provide the HFN. An example of the configuration of such a request signal will be described in the fourth embodiment.

[0087] In step S1, the receiving PDCP entity 101 of the UE 100 may receive a PDCP control PDU including an HFN or a PDCP data PDU including an HFN in its header from the transmitting PDCP entity 201 of the gNB 200. In the PHY layer, an RNTI for multiple UEs (e.g., G-RNTI, MCCH-RNTI, SI-RNTI, etc.) may be used to transmit the PDCP control PDU. Also, an RNTI for a single UE (e.g., C-RNTI) may be used to transmit the PDCP control PDU. The UE 100 applies the HFN only in the receiving PDCP entity 101 associated with the specific MRB.

[0088] In step S1, the RRC entity of the UE 100 may receive a message including an HFN (e.g., an RRC Reconfiguration message, an SIB, or an MCCH) from the RRC entity of the gNB 200. The message may include an HFN, and an MRB identifier, an MBS service identifier (e.g., TMGI), and / or a logical channel identifier (LCID) associated with the HFN. The UE 100 applies the HFN only in the receiving PDCP entity 101 associated with the MRB indicated by the MRB identifier and / or MBS service identifier included in the message. Note that, when the SIB includes the HFN, it is not necessary to increment the Value Tag due to the change in the HFN.

[0089] In step S1, the MAC entity of the UE 100 may receive a MAC control element (MAC CE) including an HFN from the MAC entity of the gNB 200. In the PHY layer, an RNTI (e.g., G-RNTI, MCCH-RNTI, SI-RNTI, etc.) for multiple UEs may be used for transmitting the PDCP control PDU. Also, an RNTI (e.g., C-RNTI) for a single UE may be used for transmitting the PDCP control PDU. The MAC CE may include an HFN, an MRB identifier, an MBS service identifier (e.g., TMGI), and / or a logical channel identifier (LCID) associated with the HFN. The UE 100 applies the HFN only in the receiving PDCP entity 101 associated with the MRB indicated by the MRB identifier and / or MBS service identifier included in the message.

[0090] In step S2, the receiving PDCP entity 101 of UE 100 determines initial values ​​of PDCP state variables managed by UE 100 (receiving PDCP entity 101) from the HFN received from gNB 200 in step S1 and the PDCP SN included in the PDCP data PDU received by UE 100 from gNB 200. For example, UE 100 (receiving PDCP entity 101) determines initial values ​​of PDCP state variables (e.g., RX_NEXT, RX_DELIV) according to the result of combining the HFN received from gNB 200 in step S1 and the PDCP SN included in the PDCP data PDU received by UE 100 from gNB 200. Here, UE 100 sets the initial value of RX_NEXT to (x +1) modulo (2 [sl-PDCP-SN-Size] ) The initial value of RX_DELIV is determined by (x - 0.5 × 2 [sl-PDCP-SN-Size-1] ) modulo (2 [sl-PDCP-SN-Size] ) where x is the SN of the first received packet.

[0091] In step S3, the receiving PDCP entity 101 of the UE 100 initializes the PDCP state variables with the initial values ​​determined in step S2. That is, the receiving PDCP entity 101 of the UE 100 sets the initial values ​​determined in step S2 as the PDCP state variables.

[0092] In addition, the UE 100 may execute the operation according to the embodiment in response to a condition (for example, any one of the above-mentioned first to third conditions) related to the inability to normally receive the MBS data (PDCP data PDU) being satisfied. That is, the UE 100 may execute the operation according to the embodiment in a situation in which it can be determined that there is a possibility that the PDCP state variables are out of synchronization. If none of the first to third conditions is satisfied, the UE 100 may ignore or discard the HFN received from the gNB 200 in step S1.

[0093] According to the operation of the embodiment, even if UE100 cannot start MBS reception from the point when gNB200 starts providing an MBS session, PDCP state variables can be synchronized in gNB200 (transmitting PDCP entity 201) and UE100 (receiving PDCP entity 101), making it possible to properly execute the PDCP layer operation described above.

[0094] The operation according to the embodiment is not limited to the case where it is executed by UE100 that starts receiving MBS in the middle of an MBS session, but may be executed by UE100 that has changed cells (e.g., cell reselection or handover) from another gNB200 (another cell). The other gNB200 (another cell) that is the source of the cell change is called the source, and the gNB200 (cell) that is the destination of the cell change is called the target. When the HFN is not synchronized between cells (between the source and the target), the UE100 that receives MBS data transmitted by PTM may execute the operation according to the above-mentioned embodiment.

[0095] In this case, the source and / or target may notify the UE 100 that the HFNs are not synchronized between the cells. For example, the source and / or target may notify the UE 100 of the cell identifiers of the neighboring cells whose HFNs are not synchronized. Alternatively, the source and / or target may notify the UE 100 of the cell identifiers of the neighboring cells whose HFNs are synchronized. Based on the notification, the UE 100 may determine whether or not to perform the operation according to the above-described embodiment when moving to the target (for example, when starting to receive MBS data from the target). Based on the notification, the UE 100 may determine to perform the operation according to the above-described embodiment only when it is determined that the HFNs are not synchronized between the cells (between the source and the target).

[0096] (Example) Based on the operations according to the above-described embodiment, a first embodiment to a fourth embodiment will be described. Two or more of these embodiments may be combined for implementation.

[0097] (1) First Example In the first embodiment, UE100 is assumed to receive an HFN from gNB200 before receiving the first PDCP data PDU from gNB200.

[0098] First, UE 100 stores the HFN received from gNB 200. Second, UE 100 receives the first PDCP data PDU from gNB 200 after receiving the HFN from gNB 200. Third, UE 100 determines the initial value of the PDCP state variable from the stored HFN and the PDCP SN included in the first PDCP data PDU.

[0099] FIG. 16 is a diagram showing the operation according to the first embodiment.

[0100] In step S101, the gNB 200 notifies the UE 100 of the current HFN of the MBS data. The UE 100 receives the HFN.

[0101] In step S102, the receiving PDCP entity 101 of the UE 100 stores (in memory) the HFN received in step S101.

[0102] In step S103, the UE 100 starts receiving the MBS data. Note that the gNB 200 starts transmitting the MBS data before step S103.

[0103] In step S104, the transmitting PDCP entity 201 of the gNB 200 transmits a first PDCP data PDU to the UE 100. The receiving PDCP entity 101 of the UE 100 receives the first PDCP data PDU.

[0104] In step S105, the receiving PDCP entity 101 of the UE 100 checks the PDCP SN included in the header of the first PDCP data PDU received in step S104.

[0105] In step S106, receiving side PDCP entity 101 of UE 100 reads (from memory) the HFN stored in step S102. Then, receiving side PDCP entity 101 of UE 100 determines initial values ​​of PDCP state variables from the read HFN and the PDCP SN confirmed in step S105, and initializes the PDCP state variables. After completing the initialization of the PDCP state variables, UE 100 may delete (discard) the stored HFN from memory.

[0106] In step S107, the transmitting PDCP entity 201 of the gNB 200 transmits the second and subsequent PDCP data PDUs to the UE 100. The receiving PDCP entity 101 of the UE 100 receives the second and subsequent PDCP data PDUs.

[0107] In step S108, the receiving PDCP entity 101 of the UE 100 updates the PDCP state variables according to the PDCP data PDU received in step S107.

[0108] (2) Second Example In the second embodiment, the UE 100 receives the HFN from the gNB 200 after receiving at least one PDCP data PDU from the gNB 200. For example, if the UE 100 joins the session late (starts reception) in a situation where PTM data transmission is already being performed for another UE 100, data reception may precede HFN reception.

[0109] First, before receiving the HFN from the gNB 200, the UE 100 receives at least one PDCP data PDU from the gNB 200. Second, the UE 100 stores the at least one PDCP data PDU. Third, after receiving the HFN from the gNB 200, the UE 100 determines an initial value of a PDCP state variable from the HFN and a PDCP SN included in a first PDCP data PDU among the stored PDCP data PDUs.

[0110] That is, UE 100 suspends processing of MBS data received before the HFN is provided (stores the data), initializes PDCP state variables when the HFN is provided, and starts data reception processing (PDCP processing).

[0111] FIG. 17 is a diagram showing the operation according to the second embodiment.

[0112] In step S201, the UE 100 starts receiving MBS data in a situation where the PDCP state variables have not yet been initialized.

[0113] In step S202, the transmitting PDCP entity 201 of the gNB 200 transmits at least one PDCP data PDU constituting MBS data to the UE 100. The receiving PDCP entity 101 of the UE 100 receives the at least one PDCP data PDU.

[0114] In step S203, the receiving PDCP entity 101 of UE 100 stores the PDCP data PDU received in step S202 in a buffer at a stage before performing PDCP processing. For example, the receiving PDCP entity 101 has a buffer at a stage before performing PDCP processing (specifically, at a stage immediately after input to the PDCP entity and before performing the above-mentioned PDCP reception processing). When the receiving PDCP entity 101 of UE 100 receives a plurality of PDCP data PDUs in step S202, it may store them in the buffer in the order in which they were received. Also, when the receiving PDCP entity 101 of UE 100 receives a plurality of PDCP data PDUs in step S202, it may rearrange the PDCP data PDUs in ascending (or descending) order and store them in the buffer.

[0115] Then, in step S204, the gNB 200 notifies the UE 100 of the current HFN. The UE 100 receives the HFN.

[0116] In step S205, the receiving PDCP entity 101 of the UE 100 checks the HFN received in step S204 and the PDCP SN included in the first PDCP data PDU stored in step S203. Here, if the receiving PDCP entity 101 of the UE 100 has stored a plurality of PDCP data PDUs in step S203, the receiving PDCP entity 101 of the UE 100 may obtain the PDCP SN from the PDCP data PDU with the smallest PDCP SN or the PDCP data PDU with the largest PDCP SN. Alternatively, the receiving PDCP entity 101 of the UE 100 may obtain the PDCP SN from the first received PDCP data PDU.

[0117] In step S206, the receiving side PDCP entity 101 of the UE 100 determines the initial values ​​of the PDCP state variables from the HFN and PDCP SN confirmed in step S205, and initializes the PDCP state variables.

[0118] In step S207, the receiving PDCP entity 101 of the UE 100 sequentially performs PDCP processing on at least one PDCP data PDU stored in the buffer in step S203.

[0119] In step S208, the transmitting PDCP entity 201 of the gNB 200 transmits the PDCP data PDU to the UE 100. The receiving PDCP entity 101 of the UE 100 receives the PDCP data PDU.

[0120] In step S209, the receiving PDCP entity 101 of the UE 100 updates the PDCP state variables according to the PDCP data PDU received in step S208.

[0121] (3) Third Example In the above-mentioned first and second embodiments, it is mainly assumed that the PDCP data PDU and the HFN are provided separately from the gNB 200, and a gap in the timing of the provision occurs between the provided HFN and the PDCP data PDU. Therefore, if the gNB 200 transmits the HFN at a timing close to when the PDCP SN wraps around, the gNB 200 and the UE 1 00 and There is a possibility that HFN desync may occur between them.

[0122] Such a problem can be solved by transmitting the HFN in the header of the PDCP data PDU. In the third embodiment, the UE 100 receives the HFN at the same time as receiving the PDCP data PDU from the gNB 200. Specifically, the UE 100 receives a PDCP data PDU having a header including an HFN from the gNB 200. However, if the HFN is always included in the header, overhead becomes large. In the third embodiment, a variable format (e.g., a variable header) is introduced that allows the HFN to be dynamically inserted. For example, the header of the PDCP data PDU is configured to be able to include a flag indicating that the header includes an HFN.

[0123] 18 is a diagram showing the operation according to Example 3. It is assumed that the UE 100 is receiving or is interested in receiving MBS data transmitted in PTM.

[0124] In step S301, the transmitting PDCP entity 201 of the gNB 200 transmits a PDCP data PDU including the current HFN in the header to the UE 100. The receiving PDCP entity 101 of the UE 100 receives the PDCP data PDU.

[0125] Prior to step S301, the receiving PDCP entity 101 of the UE 100 may wait for reception of a PDCP data PDU including an HFN in a header. The receiving PDCP entity 101 of the UE 100 may wait for the PDCP data PDU only when the receiving PDCP entity 101 of the UE 100 is configured to use the PDCP data PDU from the gNB 200. Such a configuration may be performed by RRC signaling.

[0126] A PDCP data PDU that includes an HFN in its header may be defined as a PDCP data PDU in a format different from that of a PDCP data PDU that does not include an HFN. For example, a PDCP data PDU without an HFN may be defined as an existing PDCP data PDU, and a PDCP MRB data PDU with an HFN may be defined.

[0127] In step S302, the receiving PDCP entity 101 of the UE 100 checks the HFN and SN included in the PDCP data PDU received in step S301.

[0128] In step S303, the receiving side PDCP entity 101 of the UE 100 determines the initial values ​​of the PDCP state variables from the HFN and PDCP SN confirmed in step S302, and initializes the PDCP state variables.

[0129] In step S304, the transmitting PDCP entity 201 of the gNB 200 transmits the PDCP data PDU to the UE 100. This PDCP data PDU may not include an HFN. The receiving PDCP entity 101 of the UE 100 receives the PDCP data PDU.

[0130] In step S305, the receiving PDCP entity 101 of the UE 100 updates the PDCP state variables according to the PDCP data PDU received in step S304.

[0131] Fig. 19 is a diagram showing a PDCP data PDU according to the third embodiment. The PDCP data PDU with HFN shown in Fig. 19 may be defined as a PDCP MRB data PDU. Note that an example in which the bit length of the PDCP SN is 12 bits is shown.

[0132] The "Oct 1" of the PDCP data PDU shown in Fig. 19 has a 1-bit "H" field in addition to a 1-bit "D / C" field indicating whether the PDU is a control PDU or a data PDU. When the "H" field is set to "1", it indicates a format with HFN, and when the "H" field is set to "0", it indicates a format without HFN, that is, an existing PDCP data PDU format. In the existing PDCP data PDU, the "H" field is a reserved field "R", so "0" is usually set. The HFN is set in the first half of "Oct 2" to "Oct 4" of the PDCP data PDU shown in Fig. 19. The PDCP SN is set in the second half of "Oct 4" to "Oct 5" of the PDCP data PDU shown in Fig. 19. Then, data is stored from "Oct 6".

[0133] In the format example shown in Figure 19, the HFN field is located before the PDCP SN field, but the HFN field may be located after the PDCP SN field. Also, in Figure 19, an example of a format in which the HFN field is provided in the header is shown, but the HFN field may be provided after the data or after the MAC-I field. In this case, whether or not the HFN field is provided may be notified by the "H" field, as in the format shown in Figure 19.

[0134] (4) Fourth Example If the UE 100 fails to receive PTM for a certain period of time due to a coverage hole or interference, or if the UE 100 enters another cell (handover, cell reselection), the UE 100 may not be able to receive PDCP data PDUs normally. In these cases, the PDCP state variables may become out of sync, and the current HFN and / or PDCP SN values ​​may become unknown.

[0135] However, if the period during which reception failed is not too long, it may be possible to simply initialize the PDCP SN section since the HFN is still synchronized with the gNB 200. For example, by applying the HFN used when reception failed as is, and applying an HFN of "+1" if PDCP processing fails, the COUNT value may be synchronized with the gNB 200 and normal reception may be resumed.

[0136] However, this is not the case in a situation where the reception failure continues for a long period of time, etc. In the fourth embodiment, in a situation where the UE 100 cannot normally receive the PDCP data PDU, the UE 100 initializes the PDCP state variables.

[0137] In the fourth embodiment, the UE 100 detects a first condition indicating that the time during which the MBS reception failure continues exceeds a predetermined time, and a second condition indicating that the number of consecutive MBS reception failures exceeds a predetermined number. Number of timesIn response to at least one of the first and second conditions indicating that the HFN has exceeded the threshold, the UE 100 may transmit a request signal to the gNB 200 to request the provision of the HFN. The UE 100 receives the HFN transmitted from the gNB 200 in response to the request signal.

[0138] Furthermore, in the fourth embodiment, the UE 100 may initialize the PDCP state variables with the initial values ​​in response to at least one of the first condition and the second condition being satisfied.

[0139] FIG. 20 is a diagram showing the operation according to the fourth embodiment.

[0140] In step S401, UE100 receives MBS data from gNB200 (PTM reception).

[0141] In step S402, the UE 100 determines whether a condition related to the inability to normally receive the MBS data (PDCP data PDU) is satisfied. For example, the UE 100 determines whether a first condition indicating that the time during which the MBS reception failure continues exceeds a predetermined time and a second condition indicating that the number of consecutive times the MBS reception fails exceeds a predetermined time. Number of times Here, the UE 100 may perform the determination with respect to only reception failure in the PTM(-leg).

[0142] In determining whether the first condition is satisfied, the UE 100 may use a timer to detect that reception has failed for a certain period of time. For example, the UE 100 measures the time during which the reception failure continues. When the reception fails, the UE 100 sets a certain period (a set value) in the timer and starts the timer. The set value of the timer may be set in the UE 100 by the gNB 200. The UE 100 may manage the timer separately, for example, for each G-RNTI or each MTCH. When the reception is successful, the UE 100 stops the timer. On the other hand, when the timer expires, the UE 100 may decide to perform an initialization process for the PDCP state variables.

[0143] In determining whether the second condition is satisfied, the UE 100 may use a counter to detect that reception has failed a certain number of times in succession. For example, the UE 100 operates a counter for each MTCH reception opportunity to measure the number of consecutive reception failures. The UE 100 increments the counter by 1 when reception has failed. The UE 100 may manage the counter separately for each G-RNTI or each MTCH, for example. The UE 100 initializes the counter value to zero when reception has been successful. On the other hand, when the counter value exceeds a threshold, the UE 100 may determine to perform initialization processing of the PDCP state variables. The threshold may be set in the UE 100 by the gNB 200.

[0144] The UE 100 may perform a determination using a combination of a timer and a counter. When the number of reception failures occurring within a certain period of time exceeds a threshold, the UE 100 performs an initialization process of the PDCP state variables. For example, the UE 100 starts a timer at a certain point in time and sets the counter to zero. While the timer is running, the UE 100 increments the counter by 1 for each reception failure. When the timer expires, the UE 100 restarts the timer and sets the counter to zero. On the other hand, when the counter exceeds the threshold, the UE 100 may decide to perform an initialization process of the PDCP state variables.

[0145] In step S402, UE 100 may detect the possibility of out-of-synchronization of the PDCP state variables (HFN, PDCP SN). For example, UE 100 may determine to perform initialization processing of the PDCP state variables when the COUNT value stored in receiving PDCP entity 101 and the COUNT value derived from the PDCP SN included in the received PDCP data PDU are different (the two COUNT values ​​are different by a certain amount or more). Here, when security processing (deciphering / integrity verification) using the COUNT value composed of the HFN stored in receiving PDCP entity 101 and the PDCP SN of the received packet fails, UE 100 may determine to perform initialization processing of the PDCP state variables.

[0146] In step S402, the UE 100 may determine to perform an initialization process of the PDCP state variables (HFN, PDCP SN) when starting reception at a target where the PDCP state variables are not synchronized with the source.

[0147] The condition determination in step S402 may be performed in any one of the PDCP / RLC / MAC layers, and the determination result may be notified to the RRC.

[0148] In step S403, the UE 100 transmits a request signal to the gNB 200 to request the provision of the current HFN. The request signal may be RRC signaling such as a UE Assistance Information message or an MBS Interest Indication message. The request signal may also be a PDCP control PDU, a PDCP data PDU, or a MAC CE. The request signal may also be a random access preamble transmitted using a special PRACH resource (a special time-frequency resource or a special preamble sequence). The method of using the random access preamble as the request signal is suitable for the UE 100 in the RRC idle state or the RRC inactive state.

[0149] When RRC signaling or MAC CE is used as the request signal, the request signal may include an MRB identifier for identifying an MRB for which HFN is desired to be provided. The request signal may also include an MBS session identifier (e.g., TMGI) for identifying an MBS session for which HFN is desired to be provided. The request signal may also include a logical channel identifier (LCID) for identifying a logical channel for which HFN is desired to be provided. When a PDCP data PDU is used as the request signal, the request signal may be a PDCP data PDU having a header with a flag bit set to "1" indicating that HFN is requested to be provided.

[0150] In step S404, the gNB 200 notifies the UE 100 of the current HFN in response to the request signal received from the UE 100 in step S403. The UE 100 receives the HFN.

[0151] Here, when the HFN is notified by broadcast using the SIB or MCCH, etc., other UEs (i.e., UEs that do not need to initialize the PDCP state variables) other than the UE 100 that transmitted the request signal may also receive the HFN. Even if the other UEs are able to normally receive the MBS, they may ignore or discard the received HFN and may not need to initialize the PDCP state variables using the HFN.

[0152] In step S405, the UE 100 determines the initial values ​​of the PDCP state variables from the HFN received in step S404 and the PDCP SN included in the received PDCP data PDU, and initializes the PDCP state variables. The subsequent operations are the same as those in the above-mentioned embodiment.

[0153] (Other embodiments) 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.

[0154] 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.

[0155] 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).

[0156] 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.

[0157] 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.

[0158] This application claims priority to U.S. Provisional Application No. 63 / 255,573 (filed October 14, 2021), the entire contents of which are incorporated herein by reference.

[0159] (Additional Note) 1. Introduction In RAN2#115e, the NR Multicast and Broadcast Services (MBS) work item achieved the following agreements on continuity of multicast services:

[0160] In RRC signaling, one MRB can be set to PTM only, PTP only, or both PTM and PTP. Either PTM, PTM+PTP, or PTP only can be changed by RRC signaling.

[0161] In RRC signaling, DL with only UM RLC setting for PTM, DL and UL AM RLC setting for PTP, and DL with only UM RLC setting for PTP are supported. Further study is required regarding DL and UL UM RLC setting for PTP.

[0162] Further study is required as to whether a PDCP SR occurs when a bearer type change in an RRC signal occurs, and if so, how the PDCP SR occurs.

[0163] PTM deactivation / activation beyond the RRC reconfiguration compliant with the first agreement above is not supported.

[0164] For the set of PTM PDCP state variables being configured, the SN portion of the COUNT values ​​of these variables is set according to the SN of the first received packet (by the UE) and, if necessary, the HFN indicated by the gNB.

[0165] The PTM RLC entity of the MRB configuration is initialized and the values ​​of RX_Next_Highest and RX_Next_Reassembly are set according to the SN of the first received packet containing the SN.

[0166] The MRB configuration allows the 0RLC state variable of the PTP RLC receive window to be set to its initial value (0).

[0167] This appendix discusses remaining issues regarding multicast service continuity.

[0168] 2. Discussion 2.1. PDCP Status Reporting on Bearer Type Change At RAN2#115e, the following open issues were agreed upon:

[0169] In the RRC signal, DL with only PTM UM RLC configuration, DL with PTP and AM RLC with UL, and DL with PTP UM RLC configuration are supported. Further study is required to support DL and UL UM RLC configuration with PTP.

[0170] Further study is required as to whether a PDCP SR occurs when a bearer type change in an RRC signal occurs, and if so, how the PDCP SR occurs.

[0171] According to the current PDCP specification, PDCP status reports are triggered by the RRC upon the occurrence of the following events, primarily for AM DRBs (and possibly UM DRBs):

[0172] For an AM DRB configured by higher layers to transmit PDCP status reports in the uplink (statusReportRequired in TS 38.331), the receiving PDCP entity must trigger a PDCP status report in the following cases: - The higher layers request re-establishment of the PDCP entity. - Higher layer requests PDCP data recovery. -Higher layers request uplink data switching. - Higher layers reconfigure the PDCP entity to release DAPS, daps-SourceRelease is configured in TS 38.331.

[0173] For a UM DRB configured by higher layers to transmit PDCP status reports in the uplink (statusReportRequired in TS 38.331), the receiving PDCP entity must trigger a PDCP status report in the following cases: The higher layers request an uplink data switch.

[0174] In MBS, a PTM-only MRB consists of only RLC UM, while a PTP-only MRB and the PTP legs of a split MRB consist of RLC UM or RLC AM. These are called UM MRB and AM MRB, respectively.

[0175] According to the current RRC specification, the UE performance requirement for RRC reconfiguration processing delay is specified as 10 ms. Therefore, the UE may miss MBS transmissions during RRC reconfiguration for bearer type change, and the missed packets need to be compensated after bearer type change. In this sense, PDCP status reporting should be supported at least to meet the higher reliability required by certain MBS services.

[0176] It is also worth considering when PDCP status reports are needed: in the case of an AM MRB, "high QoS" MBS service is typically assumed, so reliability is obviously required even when changing bearer types, including when changing bearer types between AM MRBs and when changing from a UM MRB to an AM MRB.

[0177] Proposal 1: RAN2 should agree that PDCP status reporting is supported at least for lossless bearer type changes between AM MRBs and from UM MRB to AM MRB.

[0178] In general, it is considered that UM MRB does not require reliability when bearer type is changed, i.e. lossless. However, whether to use UM MRB for "high QoS" MBS service can be actually left to NW implementation. By using PTM-only MRB for UE with good radio condition and reconfiguring to PTP-only MRB (or split MRB) when radio condition deteriorates more than a certain level, NW can operate resources efficiently. Considering that the current specification allows UM DRB to trigger PDCP status report in some cases, it is easily clear that NW can configure UM MRB whether PDCP status report is required. In this case, PTP-only MRB and PTP leg of split MRB need to be configured with DL / UL bidirectional UM, i.e. DL RLC entity for MBS data reception and UL RLC entity for PDCP status report transmission.

[0179] Proposal 2: RAN2 should agree that it is up to the NW implementation whether to use PDCP status reports when changing the bearer type of UM MRB. To do so, a specification that allows PTP to be configured in DL / UL bidirectional RLC UM is required.

[0180] 2.2. PDCP / RLC State Variables in PTM Initial Value In RAN2#115e, the following statement was agreed upon:

[0181] For the set of PTM PDCP state variables being configured, the SN portion of the COUNT values ​​of these variables is set according to the SN of the first received packet (by the UE) and, if necessary, the HFN indicated by the gNB.

[0182] The PTM RLC entity of the MRB configuration is initialized, and the values ​​of RX_Next_Highest and RX_Next_Reassembly are set according to the SN of the first received packet containing the SN.

[0183] The word "according to" in the two agreements contemplates three options:

[0184] Option 1: The initial value of each state variable is simply set to the SN of the first received packet.

[0185] Option 2: Rel-16 V2X solution is reused.

[0186] In the case of PDCP “RX_NEXT”, 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 the case of PDCP "RX_DELIV", 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. For RLC UM "RX_Next_Reassembly", "it is initially set to the SN of the first received UMD PDU that contains the SN". Regarding RLC UM "RX_Next_Highest", "it is initially set to the SN of the first received UMD PDU that contains the SN".

[0187] Option 3: A new mechanism for RLC UM is introduced.

[0188] For the PDCP state variables, either option 1 or option 2 can be applied. The RLC UM "RX_Next_Reassembly" is initially set to a value earlier than "RX_Next_Highest". For RLC UM "RX_Next_Highest", as with option 2 above, "it is initially set to the SN of the first received UMD PDU that contains the SN".

[0189] In the PDCP state variables, in option 2, RX_NEXT, the next packet to be received, is set to ([SN of the first received packet] + 1). RX_DELIV, the first packet not delivered to the upper layer, is set to ([SN of the first received packet] - [1 / 4 of SN length]). This means that even if an older packet is received after the first received packet, it can still be reordered. Therefore, option 2 is considered more reliable than option 1.

[0190] Proposal 3: RAN2 should agree with PDCP that the initial value of RX_NEXT should be ([SN of first received packet] + 1) modulo (2^[PDCP SN length]), similar to Rel-16 V2X.

[0191] Proposal 4: RAN2 should agree on PDCP that the initial value of RX_DELIV should be {[SN of first received packet]-2^([PDCP SN length]-2)} modulo(2^[PDCP SN length]), similar to Rel-16 V2X.

[0192] Regarding the RLC state variables, option 1 and option 2 are exactly the same. Also, option 2 and option 3 are the same in terms of RX_Next_Highest. Therefore, RAN2 needs to confirm that there is no other solution for the initial value of RX_Next_Highest.

[0193] Proposal 5: RAN2 should agree to RLC UM that the initial value of RX_Next_Highest is the SN of the first received packet, similar to Rel-16 V2X.

[0194] Regarding RX_Next_Reassembly, options 2 and 3 are different. The advantage of option 3 is similar to option 2 for PDCP state variables: it avoids discarding old packets received after the first received packet. It has also been pointed out that this issue only occurs if RLC segmentation is performed, but it is always good to minimize packet loss.

[0195] Proposal 6: RAN2 should discuss for RLC UM whether the initial value of RX_Next_Reassembly is the SN of the first received packet (same as Rel-16 V2X) or the previous value of RX_Next_Highest.

[0196] 2.2.2. HFN Provisioning 1) Whether SA3 uses HFN for security, 2) Whether PDCP status reporting is supported since COUNT has HFN part as explained in RAN2#115e. PDCP status reporting is already agreed to be supported in case of handover and is expected to be supported in case of bearer type change as per section 2.1. Therefore, HFN needs to be indicated by gNB as agreed by RAN2.

[0197] Then, we should discuss how gNB provides HFN to UE. The following options are available for providing HFN: Alt.1:RRC reconfiguration Alt.2: PDCP Control PDU Alt.3:MCCH Alt.4: SIB Alt.5: PDCP Data PDU Header

[0198] Alt.1 is considered simple because the gNB needs to configure the MRB for multicast to the UE by RRC reconfiguration, i.e., the HFN is configured together with the MRB. However, the RRC reconfiguration is a dedicated signaling for a specific UE, and is basically only used in the first delivery mode (Delivery mode 1: DM1), which has the disadvantage of being a bit heavier in processing compared to Alt.2. In addition, there is a certain timing gap between the reception of the RRC reconfiguration and the first received packet, which may cause HFN desynchronization. In addition, additional information may be required to indicate which MRB the HFN applies to.

[0199] Alt.2 is considered to be a lighter and more efficient signaling because the gNB can indicate the HFN on the PTM. Since the PDCP entity is associated with the MRB, no additional information, HFN to MRB mapping, is required. That is, the PDCP entity receiving this PDCP control PDU can apply the HFN as the initial value. This is commonly used in the first and second delivery modes (Delivery mode 2: DM2). Also, since the same PDCP entity processes these PDCP PDUs, it will minimize the timing gap between the PDCP control PDU and the first received packet. However, there is a concern that the PDCP control PDU is not secure.

[0200] Alt.3 is another possibility, but since MCCH is only applicable to the second delivery mode, it is not desirable to impose an additional burden of acquiring MCCH on UEs receiving the first delivery mode. Also, there may be a certain timing gap between receiving MCCH and the first received packet. Furthermore, as with Alt.1, additional information may be required, such as the mapping between HFN and MRB, so it is not desirable to impose an additional burden of acquiring MCCH.

[0201] Alt.4 is considered as the normal provisioning method. SIB is basically applied to both the first and second distribution modes, but it is still unclear whether UEs connected for multicast reception are required to monitor SIB. Concerns include that SIB is not secured as in Alt.2, additional information is required, namely mapping between HFN and MRB as in Alt.1, and a certain timing gap occurs between SIB reception and the first received packet. In addition, when applying on-demand SI, UE needs to send on-demand SI request message before acquiring SIB, which may cause delay in HFN initialization.

[0202] Alt.5 has similar advantages to Alt.2, i.e. it can be delivered in a PTM manner, no additional information is required, and it is a common solution for the first and second delivery modes. The most important advantage is, in theory, the timing gap, since the first received packet of Alt.5 carries the HFN together. However, assuming that the HFN is included in the header of the first received packet, it is questionable how the gNB would know the first received packet of the UE, given that packets have already started being sent to other UEs via PTM. Otherwise, the gNB would always have to include the HFN in each data packet. The concern is that the PDCP header is not secured as in Alt.2. HFN provisioning is a bit odd from a concept / principle point of view, since it is considered a C-plane signaling like other alternatives, including Alt.2. Alt.5, on the other hand, uses U-plane data.

[0203] From another angle, we can see that there is a difference in the way the HFN is provided between the first distribution mode (DM1) and the second distribution mode (DM2). In general, DM1 (or multicast) is more secure than DM2 (or broadcast), since the configuration is provided by dedicated signaling (and the session join procedure is available in the NAS). In this sense, the HFN also needs to be provided securely in DM1. In this case, the simplest solution is Alt.1, but it is not suitable to achieve commonality between DM1 and DM2. It is assumed that Alt.2 can provide a certain degree of security compared to Alt.3, Alt.4, and Alt.5, when PDCP control PDUs are transmitted in C-RNTI. On the other hand, DM2 should not oblige the UE to transition to CONNECTED, but is only intended to obtain the HFN. To support DM2, the HFN is provided periodically in a broadcast manner (i.e., using G-RNTI, MCCH-RNTI, or SI-RNTI).

[0204] As mentioned above (and summarized in the table below), HFN is slightly preferred to be delivered via PDCP control PDUs (i.e. Alt.2) as this provides a good balance between performance and security and is a common solution for both delivery modes (i.e. DM1 and DM2).

[0205] Proposal 7: RAN2 should agree that the initial value of HFN is provided via PDCP control PDU.

[0206] Proposal 8: If Proposal 7 is agreeable, it should be further agreed that RAN2 can send PDCP control PDUs (for HFN provisioning) with G-RNTI and C-RNTI.

[0207] [Table 1]

[0208] 2.2.3. Data reception before HFN initialization The UE may receive the data before receiving the HFN because the timing of reception of the HFN and the first received packet may differ due to out-of-order delivery (e.g., retransmissions in poor radio conditions and / or retransmissions during handover) and / or depending on which option in section 2.2.2 is selected. Furthermore, the UE may receive the data as soon as it sets the MRB because the PTM transmission has already started to be transmitted to other UEs.

[0209] place View 1: The UE may receive MBS data via PTM prior to HFN initialization.

[0210] In the current PDCP specification, when RRC requests the establishment of a PDCP entity, the re-establishment of a PDCP entity, or the suspension of a PDCP entity, RX_NEXT and RX_DELIV are (re)set to their initial values. Naturally, the initialization of the COUNT value is performed before data reception. Therefore, from the PDCP point of view, even if the lower layers are ready to receive data, data may not be received. That is, even if the RLC layer sends RLC SDUs (PDCP PDUs) to the PDCP layer, data may not be received. Even if PDCP accepts these PDCP PDUs, these PDUs are discarded due to integrity verification failure because the HFN is still aoristic.

[0211] place View 2: Prior to HFN initialization, according to the current specification, PDCP PDUs from lower layers may not be accepted or may be discarded by the PDCP layer.

[0212] Therefore, all of the enhancements to the initialization of state variables in the SN described in Section 2.2.1 and, as described in Section 2.2.2, aim to minimize packet loss. One simple way is for the PDCP to temporarily buffer these PDUs before PDCP processing and to start processing these PDUs after the HFN is initialized.

[0213] Proposal 9: RAN2 should discuss how to process data packets received by the UE before the initialization of the HFN.

[0214] 2.2.4. HFN Provisioning Request Another possible issue is whether the UE is allowed to query the gNB for the current HFN. Especially in the case of PTM-only MRBs, the HFN may become unsynchronized if the UE fails to receive packets for a certain period of time, e.g. due to coverage holes or interference. Another case is that if the HFN is only provided at the time of MBS session activation (as briefly discussed in Section 2.2.2), the UE requires the HFN when later joining an already activated MBS session.

[0215] Therefore, when the UE notices the need for HFN provisioning, it would be useful to allow the UE to request the gNB to provide the current HFN. How to send the request, for example via RRC signaling or PDCP control PDU, needs further study. In the same condition, the UE may not receive the next packet that is outside the reception window. In this case, the UE may reset all state variables to their initial values.

[0216] Proposal 10: RAN2 should discuss whether a UE is allowed to request the gNB to provide the current HFN of an MBS session.

[0217] Proposal 11: RAN2 should discuss whether the UE can reset the state variables if it fails to receive an MBS session for a certain period of time.

[0218] 2.3. Lossless Mobility Operation 「 RAN2 is ,child It aims to support lossless handover for MBS-MBS mobility for services that require it (scenario details are yet to be determined, but at least PTP-PTP) and "from the UE side, PDCP status reports may also be supported." These agreements imply a mechanism very similar to the existing handover for unicast when the MRB is configured with PTP only.

[0219] Observation 3: To support lossless handover, it is possible to reuse the existing handover mechanisms for unicast to MRBs configured with PTP only.

[0220] Therefore, it is necessary to consider the case of handover including PTM(-leg), that is, an MRB consisting of only PTM and a split MRB including a PTP leg and a PTM leg.

[0221] A split MRB can be considered as a PTP-only MRB if it does not use the PTM leg. Therefore, it can easily support lossless handover based on the conventional unicast handover. The basic procedure of a split MRB can be considered as follows:

[0222] Step 1: The PTP legs of the split MRB are used by lossless dynamic switching in the source cell, if necessary. Step 2: The UE performs a PTP-PTP handover (or a unicast handover), a lossless handover. Step 3: The PTM leg of the split MRB is used in the target cell by lossless dynamic switching, if necessary.

[0223] At this time, lossless dynamic switching ensured by the implementation of the network will play an important role.

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

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

[0226] Step 1: In the source cell, the MRB for PTM is reconfigured to the MRB for PTP (or a split MRB) by a lossless bearer type change. Step 2: The UE performs a lossless handover as a PTP-PTP handover (or as a unicast handover). Step 3: A lossless bearer type change can reconfigure a PTP-only MRB (or split MRB) to a PTM-only MRB in the target cell, if necessary.

[0227] In this case, the change of lossless bearer type described in section 2.1 is also important for lossless handover.

[0228] Observation 5: Lossless bearer type change is mandatory for lossless handover of PTM-only MRB.

[0229] From the above, the key points of the basic procedure of lossless handover are to use a PTP leg or to reconfigure a PTM-only MRB (=step 1), and the handover execution is the same as the existing unicast handover, with no extensions.

[0230] Proposal 12: RAN2 should agree that the basic lossless handover of MRB should always include PTP(-leg), i.e., the PTP leg of the split MRB is used or the PTM-only MRB is reconfigured to a PTP-only MRB (or split MRB) before performing the handover.

[0231] Proposal 13: RAN2 should agree that the implementation of MRB handover is the same as unicast handover, i.e. no extensions for basic lossless handover are required.

[0232] Secondly, the most interesting advanced procedure is the direct PTM-PTM handover, i.e. the UE receiving the MBS via PTM(-leg) performs a lossless handover. It reduces the signaling overhead and complexity of the basic handover procedure above, i.e. steps 1 and 3 can be skipped. Moreover, such a direct PTM-PTM lossless handover is expected especially for split MRBs with PTP legs, i.e. for services that require higher reliability. However, it is already past the midpoint of the Release 17 timeframe and the WID only states that it "specifies support for basic mobility with service continuity". Therefore, advanced lossless handover has to be postponed until a future release.

[0233] Observation 6: Advanced lossless handover for UEs receiving MBS services via PTM(-leg), i.e., “direct PTM-PTM handover”, may be useful for certain services, but may need to be postponed to a future release given the time remaining in the Rel17 timeframe.

[0234] 2.4. Multicast MBS Interest Indication RAN2 currently assumes that MBS Interest Indication is supported for broadcast sessions, but not for multicast sessions. RAN2#115e has agreed on the basic content of MBS Interest Indication as follows:

[0235] CONNECTED The UE reports the following MBS Interest information (as LTE SC-PTM): MBS Frequency List Priority between receiving all listed MBMS frequencies and receiving any unicast bearers TMGI List If reporting of MBS frequencies is allowed, the MBS frequencies reported by the UE are sorted in order of most-interesting in the same way as in LTE SC-PTM.

[0236] For multicast sessions, the general understanding seems to be that the core network informs the gNB of the UE's interest, since multicast sessions have a session join procedure at higher layers. This is true for MBS services of interest to the UE. It is also possible that the gNB knows the MBS frequencies and the cells that provide the MBS services of interest to the UE. However, the priority between MBS reception and unicast may not be provided by the core network, since this is purely AS-related information.

[0237] Observation 7: In a multicast session, the core network provides the MBS service of interest to the UE to the gNB, and the gNB may know the MBS frequency / cell. However, the core network and the gNB may not know the UE's AS priority between the MBS and unicast.

[0238] The priority information is also useful for the gNB for scheduling and handover decisions, as well as for LTE eMBMS, and is considered relevant for service continuity. Therefore, the UE needs to inform the gNB of its priority information also for multicast sessions. In this sense, RAN2 should agree that MBS Interest Indication should be supported also for multicast services / distribution mode 1.

[0239] Proposal 14: RAN2 should agree that MBS Interest Indication is also supported in multicast sessions / first delivery mode, at least for the UE to inform the gNB of the priority between MBS reception and unicast reception. [Explanation of symbols]

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

Claims

1. A method for receiving a Radio Resource Control (RRC) Reconfiguration message from a network node, the method comprising: receiving, by a user equipment in an RRC connected state, a Radio Resource Control (RRC) Reconfiguration message for configuring a Multicast and Broadcast Service (MBS) Radio Bearer (MRB) associated with a multicast session of the MBS; The RRC reconfiguration message includes a hyperframe number (HFN) associated with the MRB, a multicast radio bearer (MRB) identifier associated with the HFN, and a temporary mobile group identity (TMGI) associated with the HFN; The user equipment determines a Packet Data Convergence Protocol (PDCP) state variable managed for the MRB based on the HFN included in the RRC Reconfiguration message. Communication methods.

2. The determining step includes determining an initial value of RX_DELIV indicating the oldest COUNT value among PDCP SDUs (Service Data Units) waiting to be received and not yet provided to a higher layer, based on the HFN included in the RRC Reconfiguration message. The communication method according to claim 1 .

3. The RX_DELIV includes a COUNT value consisting of the HFN and a PDCP sequence number (PDCP SN). The communication method according to claim 2 .

4. A receiver that receives a Radio Resource Control (RRC) Reconfiguration message from a network node in an RRC connected state for configuring a Multicast and Broadcast Service (MBS) Radio Bearer (MRB) associated with a multicast session of the MBS, the RRC reconfiguration message including a Hyperframe Number (HFN) associated with the MRB, a Multicast Radio Bearer (MRB) identifier associated with the HFN, and a Temporary Mobile Group Identity (TMGI) associated with the HFN; A control unit that determines a Packet Data Convergence Protocol (PDCP) state variable that manages the MRB based on the HFN included in the RRC Reconfiguration message. User equipment.

5. A device for use in a user device, which executes the communication method according to claim 1. Processor.

6. A method for causing a user device to execute the communication method according to claim 1. program.

7. A user device comprising the user equipment according to claim 4 and a network node. Mobile communication system.

Images