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

Abstract

To provide a communication method in which user equipment receives a series of PDCP data PDUs constituting Multicast Broadcast Service (MBS) data from a base station, user equipment, and a mobile communication system.SOLUTION: User equipment receives a radio resource control (RRC) Reconfiguration message including a hyperframe number (HFN) that is counted up each time a sequence number included in a Packet Data Convergence Protocol (PDCP) data Protocol Data Unit (PDU) transmitted by a base station gNB goes around, and determines the initial values of the PDCP state variables managed by the user equipment on the basis of the hyperframe number.SELECTED DRAWING: Figure 15

Description

[Technical Field]

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

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

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

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

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

[0006] A communication method according to a first aspect is a communication method executed by 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 includes the steps of receiving from the base station a Radio Resource Control (RRC) Reconfiguration message including a hyperframe number that is incremented each time a sequence number included in the PDCP data PDU transmitted by the base station completes a cycle, and determining initial values ​​of PDCP state variables managed by the user equipment based on the hyperframe number included in the RRC Reconfiguration message.

[0007] A user device according to a second aspect is a user device 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 incremented each time a sequence number included in the PDCP data PDU transmitted by the base station completes a cycle; and a control unit that determines initial values ​​of PDCP state variables managed by the user device 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 includes a transmitter that transmits to the user device a Radio Resource Control (RRC) Reconfiguration message that includes a hyperframe number that is incremented each time a sequence number included in the PDCP data PDU transmitted by the base station completes a cycle. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a diagram illustrating a configuration of a mobile communication system according to an embodiment. [Figure 2] 1 is a diagram illustrating a configuration of a UE (user equipment) according to an embodiment. [Figure 3] A diagram showing the configuration of a gNB (base station) according to an embodiment. [Figure 4] FIG. 10 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data. [Figure 5] FIG. 1 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals). [Figure 6] FIG. 1 is a diagram illustrating an overview of MBS traffic distribution according to an embodiment. [Figure 7] FIG. 10 is a diagram illustrating a distribution mode according to the embodiment. [Figure 8] FIG. 2 is a diagram illustrating an example of internal processing related to MBS reception of the UE 100 according to the embodiment. [Figure 9] FIG. 10 is a diagram showing another example of 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. 10 is a diagram illustrating an example of PDCP state variables according to an embodiment. [Figure 12]10 is a diagram showing an example of a PDCP data PDU constituting MBS data according to an embodiment. FIG. [Figure 13] 10 is a diagram 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. FIG. [Figure 14] FIG. 10 is a diagram illustrating an example of the operation of a receiving PDCP entity of a UE according to an embodiment. [Figure 15] FIG. 10 is a diagram illustrating the operation of a UE according to the embodiment. [Figure 16] FIG. 10 is a diagram illustrating an operation according to the first embodiment. [Figure 17] FIG. 10 is a diagram illustrating an operation according to the second embodiment. [Figure 18] FIG. 10 is a diagram illustrating an operation according to the third embodiment. [Figure 19] FIG. 10 is a diagram showing a PDCP data PDU according to a third embodiment. [Figure 20] FIG. 10 is a diagram illustrating an operation according to the fourth embodiment. DETAILED DESCRIPTION OF THE INVENTION

[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 the configuration of a mobile communication system according to an embodiment. The mobile communication system 1 conforms to the 3GPP standard 5th Generation System (5GS). In the following description, 5GS is used as an example, but the mobile communication system may also be at least partially applied to an LTE (Long Term Evolution) system. Furthermore, the mobile communication system may also be at least partially applied to a 6th Generation (6G) system.

[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 a UE 100 that has established a connection with its own cell. The gNB 200 has a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), a measurement control function for mobility control and scheduling, etc. The term "cell" is used to indicate the smallest unit of a wireless communication area. The term "cell" is also used to indicate a function or resource that performs wireless communication with a UE 100. One cell belongs to one carrier frequency (hereinafter simply referred to as "frequency").

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

[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 NAS (Non-Access Stratum) signaling. The UPF controls data forwarding. The AMF and UPF are connected to the gNB 200 via an NG interface, which is an interface between a base station and a core network.

[0017] 2 is a diagram showing the configuration of a UE 100 (user equipment) according to the 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.

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

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

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

[0021] 3 is a diagram showing the 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 for each layer, which will be described later. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in the processes by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes.

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

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

[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 transport channels. The MAC layer of gNB200 includes a scheduler, which determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to UE100.

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

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

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

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

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

[0037] (MBS Overview) 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 communications, mission-critical communications, V2X (Vehicle to Everything) communications, IPv4 or IPv6 multicast distribution, IPTV (Internet protocol television), group communications, and software distribution.

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

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

[0040] FIG. 6 is a diagram illustrating an overview of MBS traffic distribution 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 (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 packet wirelessly to each UE 100. On the other hand, in the PTM distribution method, the gNB 200 distributes a single copy of the MBS data packet wirelessly to a group of UEs 100. The gNB 200 can dynamically determine whether to use PTM or PTP as the distribution method for MBS data for one UE 100.

[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 distribution modes 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") related to 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 later) related to an MBS session and scheduling information for 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 may include one or more parameters: 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), an offset value (Start Offset, DRX Cycle Offset) of the start subframe of the scheduling or DRX cycle, a start delay slot value (Slot Offset) for the on-duration timer, a timer value (Retransmission Timer) that defines the maximum time until retransmission, and a timer value (HARQ RTT Timer) that defines the minimum interval until DL allocation for HARQ retransmission.

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

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

[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 the MCCH using, for example, a dedicated RNTI predefined in a technical specification. The RNTI for BCCH reception may be SI-RNTI, and the RNTI for MCCH reception may be MCCH-RNTI.

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

[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 configuration (MTCH configuration 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, application server, etc., and an IP multicast address indicating the destination address), a session identifier, and a G-RNTI. At least one of the TMGI, 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 internal processing related to MBS reception of the UE 100 according to the embodiment. Fig. 9 is a diagram showing another example of internal processing related to MBS reception of the UE 100 according to the embodiment.

[0059] An MBS Radio Bearer (MRB) is a radio bearer that transmits a multicast session or a broadcast session. That is, an MRB may be associated with a multicast session or a broadcast session.

[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 RRC signaling, one MRB can be configured as "PTM only," "PTP only," or "both PTM and PTP." The type of such an MRB can be changed by RRC signaling.

[0061] 8 shows an example 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 a PTP-only MRB, MRB#2 is a PTM-only MRB, and MRB#3 is a PTM-only MRB. 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 the 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] 9 shows an example 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 associated with a DTCH and the other leg 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] In the PDCP layer, the gNB 200 has a transmitting PDCP entity 201 associated with the MBS session (specifically, a transmitting PDCP entity associated with a multicast radio bearer (MRB) belonging to the MBS session). When the transmitting PDCP entity 201 starts transmission of the MBS session, it manages PDCP state variables that are updated in response to the 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 each receiving PDCP entity 101 (receiving PDCP entities 101a to 101c in the example of FIG. 10) starts receiving an MBS session, it manages PDCP state variables that are updated in response to the reception of PDCP data PDUs 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 each time the PDCP sequence number goes around, and a PDCP sequence number (PDCP SN). For example, the COUNT value has a bit length of 32 bits, the PDCP SN has a bit length (SN_length) of 12 or 18 bits, and the HFN has a bit length obtained by subtracting the bit length of the PDCP SN from the bit length of the COUNT value. The bit length of the PDCP SN may be set by RRC signaling. The PDCP SN bit length 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 to refer to various variables handled in the PDCP layer (HFN or PDCP SN, or TX_NEXT, RX_NEXT, RX_DELIV, RX_REORD, etc.).

[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, the gNB 200 and the UE 100 each need to update the HFN in response to transmission and reception of the PDCP data PDU; specifically, they need to count up the HFN each time the PDCP sequence number goes around once.

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

[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 but has not yet been provided to an upper layer. The initial value of RX_DELIV is zero. Note that 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] Second, RCVD_SN≧SN(RX_DELIV)+Window_Size If RCVD_HFN=HFN(RX_DELIV)-1 is.

[0073] Third, if none of the above conditions are met, RCVD_HFN=HFN(RX_DELIV) 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 side PDCP entity 101 of the UE 100.

[0076] First, upon receiving a PDCP PDU (PDCP data PDU), the receiving PDCP entity 101 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), the receiving PDCP entity 101 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 receive buffer (step S17). If "RCVD_COUNT≧RX_NEXT" holds (step S18: Yes), the receiving PDCP entity 101 updates RX_NEXT to RCVD_COUNT+1 (step S19). Here, RX_NEXT is a variable indicating the count value (RCVD_COUNT) of the PDCP SDU expected to be received next. The initial value of RX_NEXT is zero. Note that 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 an upper layer (step S21). Specifically, the receiving PDCP entity 101 performs the operation of step S21 when "outOfOrderDelivery" is configured in the RRC. Out-of-order delivery is an operation in which packets are passed to an upper layer without performing reordering. Therefore, as in step S21, once a packet is received and stored in a buffer, the packet is immediately passed to the upper layer. If step S20 is "No," sequence control is performed.

[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 the upper layer (step S23), and updates RX_DELIV to the first (lowest) COUNT value that has not been passed to the upper layer (step S24).

[0080] When the receiving 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 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 PDCP entity 201) to the UE 100 (receiving PDCP entity 101) starts, the PDCP state variables are updated synchronously in the gNB 200 (transmitting PDCP entity 201) and the UE 100 (receiving PDCP entity 101).

[0083] However, in the scenario shown in Fig. 10, UE 100 (one of UEs 100a to 100c) is not necessarily able to start MBS reception from the time when gNB 200 starts providing an MBS session (multicast session or broadcast session). This causes a problem in that the PDCP state variables of gNB 200 (transmitting PDCP entity 201) and UE 100 (receiving PDCP entity 101) become asynchronous, making it impossible to properly perform the above-mentioned PDCP layer operation. For example, one of UEs 100 may start MBS reception in the middle of an MBS session provided by that gNB 200. Such a UE 100 may also be a UE 100 that has changed cells (e.g., performed cell reselection or handover) from another gNB 200 (another cell).

[0084] 15 is a diagram showing the 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, UE 100 may request gNB 200 to provide an HFN. UE 100 may request gNB 200 to provide an HFN in response to a condition related to failure to receive MBS data (PDCP data PDU) successfully being satisfied. For example, UE 100 may request gNB 200 to provide an HFN in response to a condition related to failure to receive MBS data successfully being satisfied, where at least one of a first condition indicating that a period of time during which MBS reception failures continues exceeds a predetermined period and a second condition indicating that the number of consecutive MBS reception failures exceeds a predetermined number is satisfied. Alternatively, UE 100 may request gNB 200 to provide an HFN in response to a condition related to a third condition indicating that UE 100 does not have information on the current (latest) HFN. For example, UE 100 may request gNB 200 to provide an HFN when UE 100 does not have a current HFN because UE 100 has become interested in receiving a broadcast session midway or has started receiving a broadcast session midway. An example of the configuration of such a request signal will be described in a 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, the PDCP control PDU may be transmitted using an RNTI (e.g., G-RNTI, MCCH-RNTI, SI-RNTI, etc.) intended for multiple UEs. Alternatively, the PDCP control PDU may be transmitted using an RNTI (e.g., C-RNTI) intended for a single UE. The UE 100 applies the HFN only to the receiving PDCP entity 101 associated with the specific MRB.

[0088] In step S1, the RRC entity of 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 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. UE 100 applies the HFN only to 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 if the SIB includes the HFN, the Value Tag does not need to be incremented due to the change of the HFN.

[0089] In step S1, the MAC entity of UE 100 may receive a MAC Control Element (MAC CE) including an HFN from the MAC entity of gNB 200. At the PHY layer, an RNTI (e.g., G-RNTI, MCCH-RNTI, SI-RNTI, etc.) for multiple UEs may be used to transmit the PDCP control PDU. Alternatively, an RNTI (e.g., C-RNTI) for a single UE may be used to transmit 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. UE 100 applies the HFN only to 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 the UE 100 determines the initial values ​​of the PDCP state variables managed by the UE 100 (receiving PDCP entity 101) from the HFN received from the gNB 200 in step S1 and the PDCP SN included in the PDCP data PDU received by the UE 100 from the gNB 200. For example, the UE 100 (receiving PDCP entity 101) determines the initial values ​​of the PDCP state variables (e.g., RX_NEXT, RX_DELIV) according to the result of combining the HFN received from the gNB 200 in step S1 and the PDCP SN included in the PDCP data PDU received by the UE 100 from the gNB 200. Here, the 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]) It may be determined by: where x is the SN of the first received packet.

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

[0092] The UE 100 may perform the operation according to the embodiment in response to a condition (for example, any one of the above-described first to third conditions) relating to the inability to receive the MBS data (PDCP data PDU) normally being satisfied. That is, the UE 100 may perform 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 have become 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 receiving MBS from the time gNB200 starts providing an MBS session, PDCP state variables can be synchronized between gNB200 (transmitting PDCP entity 201) and UE100 (receiving PDCP entity 101), making it possible to properly perform the PDCP layer operation described above.

[0094] The operation according to the embodiment is not limited to the case where it is performed by a UE 100 that starts receiving an MBS in the middle of an MBS session, but may also be performed by a UE 100 that has changed cells (for example, by cell reselection or handover) from another gNB 200 (another cell). The other gNB 200 (another cell) that is the source of the cell change is called the source, and the gNB 200 (cell) that is the destination of the cell change is called the target. When the HFNs are not synchronized between cells (between the source and the target), the UE 100 that receives MBS data transmitted by PTM may perform the operation according to the above-described embodiment.

[0095] In this case, the source and / or target may notify UE 100 that the HFNs are not synchronized between cells. For example, the source and / or target may notify UE 100 of the cell identifiers of neighboring cells whose HFNs are not synchronized. Alternatively, the source and / or target may notify UE 100 of the cell identifiers of neighboring cells whose HFNs are synchronized. Based on the notification, UE 100 may decide whether 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, UE 100 may decide to perform the operation according to the above-described embodiment only when it is determined that the HFNs are not synchronized between cells (between the source and the target).

[0096] (Example) Based on the operation according to the above-described embodiment, first to fourth examples will be described. Two or more of these examples may be combined and implemented.

[0097] (1) First Example In the first embodiment, UE100 receives 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 values ​​of the PDCP state variables 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 has started transmitting the MBS data before step S103.

[0103] In step S104, the transmitting PDCP entity 201 of the gNB 200 transmits the 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, UE 100 receives an HFN from gNB 200 after receiving at least one PDCP data PDU from gNB 200. For example, if 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 initial values ​​of PDCP state variables from the HFN and the PDCP SN included in the 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), and initializes the 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 state 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 before performing PDCP processing. For example, the receiving PDCP entity 101 has a buffer before performing PDCP processing (specifically, 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 multiple PDCP data PDUs in step S202, it may store them in the buffer in the order in which they were received. Furthermore, when the receiving PDCP entity 101 of UE 100 receives multiple PDCP data PDUs in step S202, it may sort 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. If the receiving PDCP entity 101 of the UE 100 has stored multiple 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 first and second embodiments described above, it is mainly assumed that the PDCP data PDU and the HFN are provided separately from the gNB 200, and a timing gap occurs between the provided HFN and the PDCP data PDU. Therefore, if the gNB 200 transmits the HFN around the time when the PDCP SN wraps around, there is a possibility that desynchronization of the HFN between the gNB 200 and the UE 100 occurs.

[0122] This 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 the HFN from the gNB 200. However, if the HFN is always included in the header, overhead will be 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 can be configured to include a flag indicating that the header includes the 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 its header. The receiving PDCP entity 101 of the UE 100 may wait for the PDCP data PDU only if the gNB 200 has configured the UE 100 to use the PDCP data PDU. Such 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 with a different format from a PDCP data PDU that does not include an HFN. For example, a PDCP data PDU without an HFN may be defined as a conventional PDCP data PDU, and a PDCP MRB data PDU with an HFN.

[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 is shown in which the bit length of the PDCP SN is 12 bits.

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

[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 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, as in the format shown in Figure 19, the "H" field may indicate whether or not the HFN field is provided.

[0134] (4) Fourth Example If the UE 100 fails to receive PTM data for a certain period of time due to a coverage hole or interference, or if the UE 100 moves to another cell (handover, cell reselection), the UE 100 may not be able to receive PDCP data PDUs correctly. 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 of unsuccessful reception is not too long, the HFN is still synchronized with the gNB200, so it may be possible to simply initialize the PDCP SN section. 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 gNB200, allowing normal reception to resume.

[0136] However, this is not the case in situations where 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 a fourth embodiment, the UE 100 may transmit a request signal to the gNB 200 requesting the provision of an HFN in response to the satisfaction of at least one of a first condition indicating that the time during which failure to receive an MBS continues exceeds a predetermined time, and a second condition indicating that the number of consecutive failures to receive an MBS exceeds a predetermined number. 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 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, UE 100 determines whether or not a condition related to failure to receive MBS data (PDCP data PDU) successfully is satisfied. For example, UE 100 determines whether or not at least one of a first condition indicating that the time during which 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, is satisfied. Here, UE 100 may make the determination based only on reception failures in 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 reception fails, the UE 100 sets a certain period (a set value) in the timer and then 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 reception is successful, the UE 100 stops the timer. On the other hand, when the timer expires, the UE 100 may decide to perform initialization processing of 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 fails. The UE 100 may manage the counter separately, for example, for each G-RNTI or each MTCH. When reception is successful, the UE 100 initializes the count value of the counter to zero. On the other hand, when the count value of the counter exceeds a threshold, the UE 100 may decide 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 that occur within a certain period of time exceeds a threshold, the UE 100 performs an initialization process for 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 one 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 for the PDCP state variables.

[0145] In step S402, UE 100 may detect the possibility of desynchronization of the PDCP state variables (HFN, PDCP SN). For example, if 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 diverge (the two COUNT values ​​differ by a certain amount or more), UE 100 may decide to perform initialization processing of the PDCP state variables. Here, if 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 decide to perform initialization processing of the PDCP state variables.

[0146] In step S402, the UE 100 may determine to perform initialization processing of the PDCP state variables when starting reception at a target whose PDCP state variables (HFN, PDCP SN) 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. Alternatively, the request signal may be a PDCP control PDU, a PDCP data PDU, or a MAC CE. Alternatively, the request signal may be a random access preamble transmitted using a special PRACH resource (special time-frequency resource or special preamble sequence). The method of using a random access preamble as a request signal is suitable for the UE 100 in an RRC idle state or an RRC inactive state.

[0149] When RRC signaling or MAC CE is used as the request signal, the request signal may include an MRB identifier that identifies an MRB for which HFN is desired to be provided. The request signal may also include an MBS session identifier (e.g., TMGI) that identifies an MBS session for which HFN is desired to be provided. The request signal may also include a logical channel identifier (LCID) that identifies 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 desired 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 via the SIB or MCCH, etc., other UEs other than the UE 100 that transmitted the request signal (i.e., UEs that do not need to initialize PDCP state variables) may also receive the HFN. Even if the other UEs are able to normally receive MBSs, they may ignore or discard the received HFN and not need to initialize 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-described embodiment.

[0153] (Other embodiments) The above-described operational flows are not limited to being implemented independently, but can also 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-described embodiment and example, an example in which the base station is an NR base station (gNB) has been described, but the base station may be an LTE base station (eNB) or a 6G base station. The base station may also be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may also be a DU of the IAB node. The user equipment may also be an MT (Mobile Termination) of the IAB node.

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

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

[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] (Addendum) 1. Introduction In RAN2#115e, the NR Multicast and Broadcast Services (MBS) work item achieved the following agreements on multicast service continuity:

[0160] RRC signaling can configure one MRB for only PTM, only PTP, or both PTM and PTP. RRC signaling can change between PTM, PTM+PTP, or PTP only.

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

[0162] Further study will be conducted to determine whether a PDCP SR occurs when a bearer type change occurs in an RRC signal, and if so, how the PDCP SR should be generated.

[0163] PTM deactivation / activation beyond 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] For RRC signaling, PTM UM RLC configuration only for DL, PTP DL and UL AM RLC configuration, and PTP UM RLC configuration only for DL ​​are supported. Supporting PTP DL and UL UM RLC configuration requires further study.

[0170] Further study will be conducted to determine whether a PDCP SR occurs when a bearer type change occurs in an RRC signal, and if so, how the PDCP SR should be generated.

[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 send 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 upper layer requests the re-establishment of the PDCP entity. - Upper layer requests PDCP data recovery. -Higher layers request uplink data switching. -The higher layer reconfigures the PDCP entity to release DAPS, and daps-SourceRelease is configured in TS 38.331.

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

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

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

[0176] It is also worth considering when PDCP status reports are required. Since AM MRBs are typically intended for "high QoS" MBS services, reliability is clearly required even when bearer types are changed. This includes 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 between AM MRBs and for lossless bearer type changes from UM MRB to AM MRB.

[0178] In general, UM MRBs are considered not to require reliability during bearer type changes, i.e., losslessness. However, whether to use UM MRBs for "high QoS" MBS services can be left to the network implementation. By using a PTM-only MRB for UEs with good radio conditions and reconfiguring it to a PTP-only MRB (or split MRB) when the radio conditions deteriorate beyond a certain level, the network can efficiently manage resources. Considering that the current specification allows a UM DRB to trigger a PDCP status report in certain cases, it is easy to see that the network can configure the UM MRB to determine whether a PDCP status report is required. In this case, the PTP legs of PTP-only MRBs and split MRBs must be configured with DL / UL bidirectional UM, i.e., a DL RLC entity for MBS data reception and a UL RLC entity for PDCP status report transmission.

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

[0180] 2.2.PDCP / RLC State Variables of PTM 2.2.1.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 contracts 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: The 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." For 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", "initialized to the SN of the first received UMD PDU containing an SN". Regarding RLC UM "RX_Next_Highest", "it is initially set to the SN of the first received UMD PDU containing the SN".

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

[0188] For 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 containing the SN".

[0189] In the PDCP state variables, for option 2, RX_NEXT, which is the next packet to be received, is set to ([SN of the first received packet] + 1). RX_DELIV, which is the first packet not delivered to the upper layer, is set to ([SN of the first received packet] - [1 / 4 of the SN length]). This means that even if an older packet is received after the first received packet, it can 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 only needs to confirm that there are no other solutions 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 differ. The advantage of option 3 is similar to option 2 for PDCP state variables: it avoids discarding older packets received after the first received packet. It has also been noted that this issue only occurs if RLC segmentation is performed, but minimizing packet loss is always a good thing.

[0195] Proposal 6: RAN2 should discuss whether for RLC UM, the initial value of RX_Next_Reassembly should be 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, and 2) Whether PDCP status reporting is supported since COUNT has an HFN part as explained in RAN2#115e. PDCP status reporting has already been agreed to be supported in the case of handover, and is also expected to be supported in the case of bearer type change as per Section 2.1. Therefore, as agreed in RAN2, HFN needs to be indicated by the gNB.

[0197] Then, how the gNB provides the HFN to the UE should be discussed. The following options are possible for providing the 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 UE with an MRB for multicasting via RRC reconfiguration, meaning the HFN is configured along with the MRB. However, RRC reconfiguration is a dedicated signaling for a specific UE and is generally only used in the first delivery mode (DM1). It has the disadvantage of being slightly heavier in processing compared to Alt.2. Also, there is a certain timing gap between receiving the RRC reconfiguration and the first received packet, which may cause HFN desynchronization. Furthermore, additional information may be required to indicate which MRB the HFN applies to.

[0199] Alt.2 is considered a lighter and more efficient signaling technique because it allows the gNB to indicate the HFN over the PTM. Because the PDCP entity is associated with the MRB, additional information, such as the HFN to MRB mapping, is not required. That is, the PDCP entity receiving this PDCP control PDU simply applies the HFN as the initial value. This is commonly used in both delivery mode 1 and delivery mode 2 (DM2). Furthermore, because the same PDCP entity processes these PDCP PDUs, it is likely to minimize the timing gap between the PDCP control PDU and the first received packet. However, there are concerns that PDCP control PDUs are not secure.

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

[0201] Alt.4 is considered the normal provisioning method. SIBs are essentially applied to both the first and second distribution modes, but it is unclear whether UEs connected for multicast reception are required to monitor SIBs. Concerns include the lack of security protection of SIBs, as in Alt.2; the need for additional information, such as the mapping between HFN and MRB, as in Alt.1; and the possibility of a timing gap between SIB reception and the first received packet. Furthermore, when on-demand SI is applied, the UE must send an on-demand SI request message before acquiring the SIB, which may cause a delay in HFN initialization.

[0202] Alt.5 offers similar advantages to Alt.2. It can be delivered via PTM, does not require additional information, and is a common solution for both the first and second delivery modes. The most significant advantage of Alt.5 is that it theoretically eliminates timing gaps, since the first received packet carries the HFN. However, assuming the HFN is included in the header of the first received packet, it is questionable how the gNB would know which packet a UE received first, given that packets are already being sent to other UEs via PTM. Otherwise, the gNB would need to include the HFN in each data packet. A concern is that the PDCP header is not secure, as with Alt.2. HFN provisioning is considered C-plane signaling, just like other alternatives, including Alt.2, so it is somewhat odd from a conceptual / principle standpoint. On the other hand, Alt.5 uses U-plane data.

[0203] From another perspective, 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) because 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, Alt.1 is the simplest solution, but it is not suitable for achieving commonality between DM1 and DM2. Alt.2 is expected to provide a certain degree of security compared to Alt.3, Alt.4, and Alt.5 when PDCP control PDUs are transmitted in the C-RNTI. On the other hand, DM2 should not require the UE to transition to CONNECTED, but is intended only for the purpose of obtaining the HFN. To support DM2, the HFN is provided periodically in a broadcast manner (i.e., using the G-RNTI, MCCH-RNTI, or SI-RNTI).

[0204] As mentioned above (and also 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 data before receiving the HFN because the timing of the 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, since the PTM transmission has already started to be transmitted to other UEs, the UE may receive the data as soon as it sets the MRB.

[0209] Observation 1: The UE may receive MBS data via PTM before 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)initialized. Naturally, the COUNT value is initialized before data reception. Therefore, from the PDCP point of view, even if the lower layer is ready to receive data, data may not be received. In other words, even if the RLC layer sends RLC SDUs (PDCP PDUs) to the PDCP layer, the data may not be received. Even if PDCP accepts these PDCP PDUs, they are discarded due to integrity verification failure because the HFN is still aoristic.

[0211] Observation 2: Before HFN initialization, according to the current specification, PDCP PDUs from lower layers may not be accepted or may be discarded at the PDCP layer.

[0212] Therefore, all of the enhancements to the initialization of state variables in the SN, as described in Section 2.2.1, and some of the enhancements described in Section 2.2.2, aim to minimize packet loss. One simple approach is for the PDCP to temporarily buffer these PDUs before PDCP processing and 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, for example due to coverage holes or interference. Another case is when the HFN is only provided at the time of MBS session activation (as briefly discussed in Section 2.2.2), and the UE needs the HFN when later joining an already activated MBS session.

[0215] Therefore, when the UE realizes 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, requires 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 can reset all state variables to their initial values.

[0216] Proposal 10: RAN2 should discuss whether a UE is allowed to request a 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 aims to support lossless handover for MBS-MBS mobility for services that require it (details of the scenarios are yet to be determined, but at least PTP-PTP)" and "PDCP status reports may also be supported from the UE side." 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 for PTP-only MRBs.

[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 a PTP-only MRB if it does not use the PTM leg. Therefore, it can easily support lossless handover based on conventional unicast handover. The basic procedure for 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 as needed. Step 2: The UE performs a lossless handover, such as a PTP-PTP handover (or a unicast handover). Step 3: The PTM leg of the split MRB is used in the target cell by lossless dynamic switching, if necessary.

[0223] In this case, 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 the 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 for lossless handover are to use a PTP leg or 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 a split MRB is used or a PTM-only MRB is reconfigured to a PTP-only MRB (or split MRB) before the handover is performed.

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

[0232] The next most interesting advanced procedure is the direct PTM-PTM handover. This means that the UE receiving the MBS via the PTM-leg performs a lossless handover. This reduces the signaling overhead and complexity of the basic handover procedure described above. In other words, steps 1 and 3 can be skipped. Furthermore, such a direct PTM-PTM lossless handover is expected, especially for split MRBs with PTP legs. This means it will be used for services that require higher reliability. However, we are 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 must 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 to least interesting, similar to LTE SC-PTM.

[0236] For multicast sessions, it seems common understanding that the core network notifies the gNB of the UE's interest, since multicast sessions have a session join procedure at higher layers. This applies to 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, as 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] Similar to LTE eMBMS, the priority information is also useful for the gNB for scheduling and handover decisions, and is considered relevant for service continuity. Therefore, the UE needs to notify the gNB of the priority information for multicast sessions as well. In this sense, RAN2 should agree that MBS Interest Indication should also be supported for multicast services / delivery 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 system 10:RAN 20 :CN 100:UE 101: Receiving PDCP entity 110: Receiving unit 120: Transmitter 130: Control unit 200 :gNB 201: Sending PDCP entity 210: Transmission unit 220: Receiving unit 230: Control unit 240: Backhaul communication unit

Claims

1. receiving, by a user equipment in an RRC connected state, a Radio Resource Control (RRC) Reconfiguration message from a network node for configuring a Multicast and Broadcast Service (MBS) Radio Bearer (MRB); The RRC reconfiguration message includes a hyperframe number (HFN) associated with the MRB; and 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 method.

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

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

4. a receiver configured to receive a Radio Resource Control (RRC) Reconfiguration message for configuring a Multicast Broadcast Service (MBS) Radio Bearer (MRB) from a network node in an RRC Connected state, the RRC reconfiguration message including a Hyperframe Number (HFN) associated with the MRB; 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 for carrying out the communication method according to claim 1. Processor.

6. The communication method according to claim 1 is executed by a user device. program.

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

Images