Terminal device, method of terminal device, and base station device

Abstract

The terminal device (10) receives a Radio Resource Control (RRC) message from the base station device (20). The RRC message includes information for configuring whether to send a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU). The PDCP Control PDU is used to report the gap of the PDCP Sequence Number (SN) and includes a field indicating whether the PDCP Service Data Unit (SDU) has been dropped. The terminal device determines the bit length of the aforementioned field based on the number of counts from the first dropped PDCP SDU to the last dropped PDCP SDU.

Description

Cross-references of related applications

[0001] This application is based on and claims priority to Japanese Patent Application No. 2024-022186, filed on February 16, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to a terminal device, a method for using a terminal device, and a base station device. Background Technology

[0003] In recent years, technological development related to extended reality (XR) has been progressing. XR is a concept that integrates multimedia technologies such as virtual reality (VR), augmented reality (AR), mixed reality (MR), and substitutional reality (SR). In XR, three-dimensional time-series image data from real and / or virtual spaces, multi-channel (stereo, 5.1ch, etc.) audio data, other data presented to the user, and control data are transmitted and received in parallel. XR requires low latency and high reliability to maintain and improve the user experience quality.

[0004] Non-patent document 1 and non-patent document 2 contain technical specifications stipulated by the Third Generation Partnership Project (3GPP (registered trademark)), including technical specifications for dealing with XR. Existing technical documents Non-patent literature

[0005] Non-patent document 1: 3GPP TS 38.323 V18.0.0 (2023-12) Non-patent document 2: 3GPP TS 38.331 V18.0.0 (2023-12) Non-patent document 3: 3GPP TS 26.522 V0.1.0 (2023-05) Summary of the Invention

[0006] Non-Patent Document 1 describes a transmission process in which data received from a lower layer is transmitted to a higher layer within the Packet Data Convergence Protocol (PDCP) layer. However, in XR services, data loss may frequently occur within the PDCP layer. In view of this, a proposal has been made for a transmitting entity in the PDCP layer to send a report related to data lost due to loss to a receiving entity. However, prior art specifications, including Non-Patent Document 1, do not describe under what conditions the aforementioned report is triggered or transmitted. The inventors have discovered the problem that the aforementioned report may not be properly triggered or transmitted. Furthermore, the aforementioned problem also occurs in conventional terminal devices and base station devices outside of XR implementations.

[0007] This disclosure provides a technique for appropriately triggering or sending reports related to data lost due to discarding processes in the PDCP layer.

[0008] The terminal device of this disclosure includes: a receiving unit that receives a Radio Resource Control (RRC) message from a base station device, the RRC message including information for configuring whether to transmit a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU), the PDCP control PDU being used to report gaps in PDCP Sequence Numbers (SNs), and including a field indicating whether a PDCP Service Data Unit (SDU) has been discarded; and a control unit including a PDCP entity. When the PDCP control PDU for reporting the aforementioned gaps in the aforementioned PDCP SN is configured to be transmitted based on the aforementioned information, and at least one PDCP SDU is discarded, the PDCP entity triggers the aforementioned PDCP control PDU for reporting the aforementioned gaps in the aforementioned PDCP SN. When the aforementioned PDCP control PDU for reporting the aforementioned gaps in the aforementioned PDCP SN is triggered, the PDCP entity compiles the aforementioned PDCP control PDU for reporting the aforementioned gaps in the aforementioned PDCP SN. In the aforementioned compilation process, the PDCP entity determines the bit length of the aforementioned field indicating whether the aforementioned PDCP SDU has been discarded based on the count value from the count value corresponding to the first discarded PDCP SDU to the count value corresponding to the last discarded PDCP SDU.

[0009] Further, the method of the terminal device in this disclosure includes: receiving a Radio Resource Control (RRC) message from a base station device, the RRC message including information for configuring whether to send a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU), the PDCP control PDU being used to report gaps in PDCP Sequence Numbers (SNs), and including a field indicating whether a PDCP Service Data Unit (SDU) has been discarded; if, based on the aforementioned information, the aforementioned PDCP control PDU for reporting the aforementioned gaps in the aforementioned PDCP SN is configured to be sent, and at least one PDCP SDU is discarded, triggering the aforementioned PDCP control PDU for reporting the aforementioned gaps in the aforementioned PDCP SN through a PDCP entity; if the aforementioned PDCP control PDU for reporting the aforementioned gaps in the aforementioned PDCP SN is triggered, compiling a method for reporting the aforementioned PDCP through the aforementioned PDCP entity. The aforementioned PDCP control PDU of the aforementioned gap of SN; and in the aforementioned compilation process, by the aforementioned PDCP entity, the bit length of the aforementioned field indicating whether the aforementioned PDCP SDU has been discarded is determined based on the number of counts from the count value corresponding to the first discarded PDCP SDU to the count value corresponding to the last discarded PDCP SDU.

[0010] Further, the base station apparatus of this disclosure includes: a transmitting unit that transmits a Radio Resource Control (RRC) message to a terminal device, the RRC message including information for configuring whether to transmit a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU), the PDCP control PDU being used to report gaps in the PDCP Sequence Number (SN), and including a field indicating whether a PDCP Service Data Unit (SDU) has been discarded; and a receiving unit that receives the aforementioned PDCP control PDU from the aforementioned terminal device. If the aforementioned terminal device is configured to transmit the aforementioned PDCP control PDU for reporting the aforementioned gaps in the aforementioned PDCP SN based on the aforementioned information, and at least one PDCP control PDU in the aforementioned terminal device is discarded, the aforementioned PDCP control PDU for reporting the aforementioned gaps in the aforementioned PDCP SN is triggered in the aforementioned terminal device. The aforementioned receiving unit receives the aforementioned PDCP control PDU from the aforementioned terminal device. The aforementioned PDCP control PDU includes the aforementioned field indicating whether the aforementioned PDCP SDU has been discarded. The aforementioned field has a bit length determined based on the number of counts from the count value corresponding to the first discarded PDCP SDU to the count value corresponding to the last discarded PDCP SDU.

[0011] Based on the above configuration, reports related to data lost due to discarding can be appropriately triggered or sent in the PDCP layer. Furthermore, this configuration can be used to replace or in conjunction with other effects. Attached Figure Description

[0012] The foregoing and other objects, features, and advantages of this disclosure will become clearer from the following detailed description, taken in conjunction with the accompanying drawings. The drawings are as follows: Figure 1 This is a diagram illustrating the communication system S. Figure 2 This is a diagram showing the protocol stack of the U-side. Figure 3 This is a diagram showing the protocol stack on side C. Figure 4 This is a block diagram showing a general hardware configuration of the terminal device 10. Figure 5 This is a block diagram showing a general functional configuration of the terminal device 10. Figure 6 This is a block diagram showing a general hardware configuration of the base station device 20. Figure 7 This is a block diagram showing a general functional configuration of the base station device 20. Figure 8 This is a diagram showing the wireless frame configuration. Figure 9 This is a block diagram showing a general functional configuration of the PDCP layer of the terminal device 10 and the PDCP layer of the base station device 20. Figure 10 This is a diagram illustrating an example of the PDCP PDU (Protocol Data Unit) format. Figure 11 This is a diagram illustrating an example of the PDCP PDU format. Figure 12 This is a diagram illustrating an example of the PDCP PDU format. Figure 13 This diagram illustrates the processing of the second PDCP transmission unit 921 in the base station device 20. Figure 14 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 15 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 16 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 17 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 18 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 19 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 20 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 21 This is a diagram illustrating an example of the format of a PDCP control PDU used for PDCP status reporting. Figure 22 This is a diagram illustrating the configuration of a PSI-based SDU DiscardActivation / Deactivation MAC CE. Figure 23 This is a diagram used to illustrate an example of PSI-based discard processing. Figure 24This is a diagram illustrating an example of the format of a Missing Control PDU. Figure 25 This is a diagram illustrating an example of the format of a missing control PDU. Figure 26 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 27 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 28 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 29 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 30 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 31 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 32 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 33 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 34 This diagram illustrates the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 35 This is an example of the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 36 This is an example of the processing of the first PDCP receiving unit 912 of the terminal device 10. Figure 37 This is a diagram illustrating the processing of the first PDCP transmitting unit 911 of the terminal device 10. Detailed Implementation

[0013] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. Furthermore, in this specification and the accompanying drawings, elements that can be described in the same way are labeled with the same reference numerals, and repeated descriptions can be omitted.

[0014] The embodiments described below are merely examples of configurations that can implement this disclosure. These embodiments can be appropriately modified or changed depending on the configuration of the apparatus to which this disclosure is applied and various conditions. Not all combinations of elements included in the following embodiments are necessary to implement this disclosure, and some elements can be appropriately omitted. Therefore, the scope of this disclosure is not limited to the configurations described in the following embodiments. Configurations combining multiple configurations described in the following embodiments can also be used, provided they do not contradict each other.

[0015] 1. First Implementation Method 1.1. Communication System like Figure 1 As shown, the communication system S includes one or more terminal apps 10, one or more base station apps 20, and a core network 30. The communication system S is configured according to predetermined technical specifications. For example, the communication system S may comply with the technical specifications specified by 3GPP (e.g., 5G, 5G evolution, 6G, etc.).

[0016] In the communication system S, there are independently configured user planes for sending and receiving user data and control planes for sending and receiving control data. That is, the communication system S supports C / U separation. The user plane is simply referred to as the U plane, and the control plane as the C plane.

[0017] Terminal device 10 is a device that communicates wirelessly with base station device 20. For example, it may be user equipment (UE) operating in accordance with the 3GPP 5G NR technical specifications. Alternatively, terminal device 10 may also be a device that complies with other older or newer 3GPP technical specifications.

[0018] Terminal device 10 may be, for example, a mobile phone terminal such as a smartphone, a tablet terminal, a laptop PC (personal computer), a communication module, a communication card, or an IoT (Internet of Things) device such as a surveillance camera and a robot. Terminal device 10 may also be a vehicle (e.g., a car, a tram, etc.) or a device mounted thereon. Terminal device 10 may also be a transport vehicle other than a vehicle (e.g., a ship, an airplane, etc.) or a device mounted thereon. Terminal device 10 may also be a sensor or a device mounted thereon. Furthermore, terminal device 10 may also be referred to as a terminal, mobile station, mobile terminal, mobile device, mobile unit, subscriber station, subscriber terminal, subscriber device, subscriber unit, wireless station, wireless terminal, wireless device, wireless unit, remote station, remote terminal, remote device, remote unit, and other names. Terminal device 10 may also be a device adapted to one or more of enhanced mobile broadband (eMBB), ultra-reliable and low-latency communications (URLLC), and massive machine-type communications (mMTC).

[0019] Base station device 20 manages at least one cell. A cell is the smallest unit constituting a communication area. For example, a cell belongs to a frequency (e.g., a carrier frequency) and consists of a component carrier. The term "cell" sometimes refers to a wireless communication resource and sometimes to a communication target of terminal device 10. Base station device 20 wirelessly communicates with terminal device 10 located in the cell in both the U-plane and C-plane. In other words, base station device 20 terminates U-plane and C-plane protocols for terminal device 10.

[0020] The base station device 20 communicates with the core network 30 in both the U-plane and the C-plane. More specifically, the core network 30 includes multiple logical nodes, including an Access and Mobility Management Function (AMF) and a User Plane Function (UPF). The base station device 20 is connected to the AMF in the C-plane and to the UPF in the U-plane.

[0021] Base station device 20 may be, for example, a gNB that provides terminal device 10 with U-plane and C-plane conforming to the 3GPP 5G NR technical specifications and connects to the 3GPP 5GC (5G Core Network). Alternatively, base station device 20 may also be a device conforming to other older or newer 3GPP technical specifications.

[0022] The base station device 20 may be composed of multiple unit devices. For example, the base station device 20 may be composed of a central unit (CU), a distributed unit (DU), and a radio unit (RU).

[0023] Multiple base station devices 20 are interconnected to form a Radio Access Network (RAN). The radio access network formed by the base station devices 20 acting as gNBs can also be referred to as NG-RAN. The base station devices 20 acting as gNBs can also be referred to as NG-RAN nodes.

[0024] Multiple base station devices 20 are interconnected via a predetermined interface (e.g., an Xn interface). More specifically, for example, multiple base station devices 20 are interconnected via an Xn-U interface in the U-plane and via an Xn-C interface in the C-plane. Furthermore, multiple base station devices 20 may also be interconnected via other interfaces with different functions or names.

[0025] Each base station device 20 is connected to the core network 30 via a predetermined interface (e.g., an NG interface). More specifically, for example, each base station device 20 is connected to the UPF of the core network 30 via an NG-U interface in the U-plane and to the AMF of the core network 30 via an NG-C interface in the C-plane. Furthermore, each base station device 20 may also be connected to the core network 30 via other interfaces with different functions or names.

[0026] Reference Figure 2 The wireless protocol architecture between terminal device 10 and base station device 20 is explained. Additionally, refer to... Figure 3 The wireless protocol architecture between terminal device 10 and base station device 20, and between terminal device 10 and core network 30, is described.

[0027] like Figure 2 As shown, in the protocol stack on the U-side, the layers arranged sequentially from the lowest level are: Physical (PHY) layer, Media Access Control (MAC) layer, Radio Link Control (RLC) layer, Packet Data Convergence Protocol (PDCP) layer, and Service Data Adaptation Protocol (SDAP) layer. Each of these layers terminates at the base station device 20 on the network side. Furthermore, the aforementioned MAC layer is also referred to as the "Medium Access Control layer."

[0028] like Figure 3 As shown, in the protocol stack on plane C, the layers arranged sequentially from the lowest level are: Physical (PHY) layer, Media Access Control (MAC) layer, Radio Link Control (RLC) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Resource Control (RRC) layer, and Non-Access Stratum (NAS). Furthermore, the MAC layer is also referred to as the "Medium Access Control layer." All layers except the NAS terminate at the base station device 20 for the network side. The NAS terminates at the AMF of the core network 30 for the network side.

[0029] like Figure 4 As shown, the terminal device 10 includes a processor 101, a memory 102, an input / output interface 103, a wireless interface 104, and an antenna 105 as hardware elements. These elements in the terminal device 10 are interconnected via an internal bus. Furthermore, the terminal device 10 may also have… Figure 4 Hardware elements other than those shown.

[0030] The processor 101 is a computing element that implements various functions of the terminal device 10. The processor 101 may be a SoC (System-on-a-Chip) that includes elements such as a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), and a memory controller.

[0031] The memory 102 is composed of at least one storage medium such as RAM (Random Access Memory) or eMMC (embedded Multimedia Card). The memory 102 is an element that temporarily or permanently stores programs and data used to perform various processes in the terminal device 10. The programs include one or more commands for the actions of the terminal device 10. The processor 101 implements the functions of the terminal device 10 by expanding the programs stored in the memory 102 into the memory 102 and / or system memory (not shown) and executing them.

[0032] The input / output interface 103 is an interface that receives operations from the terminal device 10 and provides them to the processor 101, and presents various information to the user. The input / output interface 103 is, for example, a touch panel.

[0033] The wireless interface 104 is a circuit that performs various signal processing functions to enable wireless communication, including a baseband processor and RF circuitry. The wireless interface 104 transmits and receives radio signals with the base station device 20 via the antenna 105.

[0034] like Figure 5 As shown, the terminal device 10 has a control unit 110 and a communication unit 120 as functional blocks. The communication unit 120 has at least one transmitting unit 121 and at least one receiving unit 122.

[0035] The control unit 110 may include at least one processor 101 and at least one memory 102. In other words, the control unit 110 may be implemented by the processor 101 and the memory 102. The control unit 110 performs various control processes in the terminal device 10. For example, the control unit 110 controls wireless communication with the base station device 20 via the communication unit 120. That is, the control unit 110 transmits and receives data / information / messages via the communication unit 120.

[0036] The communication unit 120 includes a wireless interface 104 and an antenna 105. In other words, the communication unit 120 is implemented by the wireless interface 104 and the antenna 105. The communication unit 120 communicates wirelessly with the base station device 20 by transmitting and receiving radio signals. The communication unit 120 may include two or more wireless interfaces 104 and two or more antennas 105.

[0037] By operating the control unit 110, various processes of the terminal device 10 are executed.

[0038] like Figure 6 As shown, the base station device 20 includes a processor 201, a memory 202, a network interface 203, a wireless interface 204, and an antenna 205 as hardware elements. These elements in the base station device 20 are interconnected via an internal bus. Furthermore, the base station device 20 may also have… Figure 6 Hardware elements other than those shown.

[0039] The processor 201 is a computing element that implements various functions of the base station device 20. The processor 201 can be a CPU, or it can include other processors such as a GPU.

[0040] The memory 202 is composed of at least one storage medium selected from ROM (Read Only Memory), RAM, HDD (Hard Disk Drive), SSD (Solid State Drive), etc. The memory 202 is an element that temporarily or permanently stores programs and data used to perform various processes in the base station device 20. The programs include one or more commands for the operation of the base station device 20. The processor 201 implements the functions of the base station device 20 by expanding the programs stored in the memory 202 into the memory 202 and / or system memory (not shown) and executing them.

[0041] Network interface 203 is an interface for sending and receiving signals with other base station devices 20 and core network 30.

[0042] The wireless interface 204 is a circuit that performs various signal processing functions to enable wireless communication, including a baseband processor and RF circuitry. The wireless interface 204 transmits and receives radio signals with the terminal device 10 via the antenna 205.

[0043] like Figure 7 As shown, the base station device 20 has a control unit 210, a communication unit 220, and a network communication unit 230 as functional blocks. The communication unit 220 has at least one transmitting unit 221 and at least one receiving unit 222.

[0044] The control unit 210 may include at least one processor 201 and at least one memory 202. In other words, the control unit 210 may be implemented by the processor 201 and the memory 202. The control unit 210 performs various control processes in the base station device 20. For example, the control unit 210 controls wireless communication with the base station device 10 via the communication unit 220. That is, the control unit 210 transmits and receives data / information / messages via the communication unit 220. In addition, for example, the control unit 210 controls communication with other nodes (e.g., other base station devices 20, nodes of the core network 30) via the network communication unit 230.

[0045] The communication unit 220 includes a wireless interface 204 and an antenna 205. In other words, the communication unit 220 is implemented by the wireless interface 204 and the antenna 205. The communication unit 220 communicates wirelessly with the terminal device 10 by transmitting and receiving radio signals. The communication unit 220 may include two or more wireless interfaces 204 and two or more antennas 205.

[0046] The network communication unit 230 includes a network interface 203. In other words, the network communication unit 230 is implemented by the network interface 203. The network interface 203 sends and receives signals with the network (and consequently, the other nodes mentioned above).

[0047] By operating the control unit 210, various processes of the base station device 20 are executed.

[0048] 1.2. Wireless Resources Terminal device 10 and base station device 20 communicate wirelessly with each other using wireless resources in the frequency and time domains. The wireless resources will be described below.

[0049] The downlink communication transmission method from base station device 20 to terminal device 10 is, for example, orthogonal frequency division multiplexing (OFDM) using a cyclic prefix (CP), i.e., CP-OFDM. The uplink communication transmission method from terminal device 10 to base station device 20 is, for example, the aforementioned CP-OFDM, or DFTS-OFDM applying CP-OFDM after perform transform precoding of Discrete Fourier Transform (DFT) spreading.

[0050] A cyclic prefix is ​​a redundant signal that functions as a guard period (GP) to prevent inter-symbol interference and inter-carrier interference, and it is inserted at the beginning of an OFDM symbol. As categories of cyclic prefixes, there are normal cyclic prefixes and extended cyclic prefixes.

[0051] Multiple mutually orthogonal subcarriers are used as frequency-domain radio resources in OFDM. These subcarriers are arranged in the frequency domain with a predetermined subcarrier spacing (SCS) Δf. Multiple subcarrier spacings Δf can be applied in the communication system S. The subcarrier spacing Δf is expressed, for example, by the following formula. Δf=2 μ 15 [kHz]

[0052] Here, μ is an integer greater than or equal to 0, and can take at least any of the values ​​0, 1, 2, 3, 4, 5, and 6. Therefore, the subcarrier spacing Δf [kHz] can take at least any of the values ​​15, 30, 60, 120, 240, 480, and 960. In addition, μ can also take values ​​greater than or equal to 7.

[0053] In the time domain of OFDM, such as Figure 8As shown, a hierarchical radio frame configuration is used. A radio frame consists of 10 subframes. Subframes are assigned subframe numbers that are counted upwards from 0 to 9. A radio frame is divided into two half-frames. The duration of a radio frame is 10 ms, the duration of a half-frame is 5 ms, and the duration of a subframe is 1 ms. These durations are independent of the subcarrier spacing Δf.

[0054] A subframe comprises one or more slots. The number of slots Ns in a subframe depends on the value of μ mentioned above, and consequently on the subcarrier spacing Δf. The number of slots Ns can be represented, for example, by the following formula. Ns=2 μ

[0055] A time slot includes multiple symbols. The number of symbols in a time slot depends on the type of cyclic prefix. For example, with a regular cyclic prefix, a time slot includes 14 symbols. With an extended cyclic prefix, a time slot includes 12 symbols.

[0056] As described above, the number of time slots and symbols contained in each of a radio frame, half-frame, and subframe with a fixed duration is variable. Therefore, the duration of the time slots and the duration of the symbols are also variable.

[0057] A resource element (RE) is a time-frequency domain radio resource unit consisting of one subcarrier and one symbol. A resource block (RB) is a time-frequency domain radio resource unit consisting of 12 subcarriers and multiple symbols.

[0058] Radio frames are assigned a System Frame Number (SFN) that increments by 1 from 0 to 1023. SFN "0" represents the initial SFN value, and SFN "1023" represents the maximum SFN value. Therefore, the next radio frame to a radio frame assigned SFN 1023 is assigned SFN 0. Since the duration of a radio frame is 10ms, the duration of one cycle of the System Frame Number is 10240ms (=10.24 seconds).

[0059] Here, the base station device 20 can configure one or more serving cells for the terminal device 10. A serving cell may correspond to a component carrier in the downlink and / or a component carrier in the uplink. The technique of configuring one or more serving cells and performing wireless communication between the base station device 20 and the terminal device 10 can also be referred to as carrier aggregation.

[0060] Additionally, the base station device 20 can configure one or more bandwidth portions (BWPs) for the terminal device 10 for each of one or more serving cells. For example, a downlink bandwidth portion (DL-BWP) can be configured in the downlink of a serving cell. Additionally, an uplink bandwidth portion (UL-BWP) can be configured in the uplink of a serving cell. Here, the DL-BWP can include an initial DL-BWP and / or a dedicated DL-BWP. Similarly, the UL-BWP can include an initial UL-BWP and / or a dedicated UL-BWP. Hereinafter, BWPs can include DL-BWPs and / or UL-BWPs.

[0061] 1.3. Channel and Control Information Terminal device 10 and base station device 20 send and receive user data and control information to each other. The following examples illustrate the sending and receiving of control information in the downlink and uplink.

[0062] Terminal device 10 and base station device 20 use multiple hierarchical channels to send and receive user data and control information. Physical channels are channels used for physical communication between terminal device 10 and base station device 20. Examples of physical channels include the Physical Downlink Control Channel (PDCCH), Physical Broadcast Channel (PBCH), and Physical Uplink Control Channel (PUCCH).

[0063] A transport channel is a high-order channel within the physical channel hierarchy, mapped to the physical channel in the PHY layer. Multiple transport channels can be mapped to a single physical channel. Examples of transport channels include the Downlink Shared Channel (DL-SCH) and the Uplink Shared Channel (UL-SCH). For instance, data in the downlink is also referred to as DL-SCH data. Similarly, data in the uplink can also be referred to as UL-SCH data. Here, DL-SCH data includes user data from the downlink. UL-SCH data includes user data from the uplink.

[0064] A logical channel is a channel that sits above a transport channel and is mapped to a transport channel in the MAC layer. Multiple logical channels can be mapped to one transport channel, and one logical channel can be mapped to multiple transport channels. Logical channels are classified according to the characteristics of the information they transmit. Examples of logical channels include Broadcast Control Channel (BCCH), Common Control Channel (CCCH), and Dedicated Control Channel (DCCH).

[0065] Base station device 20 uses the PDCCH as the physical channel to send downlink control information (DCI) to terminal device 10. The DCI includes information related to the resource allocation for the downlink and uplink of terminal device 10, as well as control information for terminal device 10. The DCI is mapped to the PDCCH, which is equivalent to Layer 1 signaling.

[0066] Here, one or more formats can be specified for DCI transmissions in the PDCCH. The format specified for DCI transmissions in the PDCCH can be referred to as a DCI format. For example, a DCI format may include a DCI format for scheduling the Physical Downlink Shared Channel (PDSCH) (e.g., formats referred to as DCI format 1_0, DCI format 1_1, and / or DCI format 1_2). Additionally, for example, a DCI format may include a DCI format for scheduling the Physical Uplink Shared Channel (PUSCH) (e.g., formats referred to as DCI format 0_0, DCI format 0_1, and / or DCI format 0_2). Furthermore, a DCI format may include a DCI format not used for scheduling the PDSCH and / or PUSCH. A DCI format used for scheduling the PDSCH and / or PUSCH can be referred to as a scheduled DCI format. A DCI format not used for scheduling the PDSCH and / or PUSCH can be referred to as a non-scheduled DCI format. For ease of explanation, "DCI format" will sometimes be simply referred to as "PDCCH". Additionally, "DCI generated according to the DCI format" will sometimes be simply referred to as "DCI format".

[0067] For example, base station device 20 can be configured to monitor (i.e., supervise) the frequency domain resources and / or time domain resources of the PDCCH candidate set. For example, the frequency domain resources monitored by terminal device 10 for the PDCCH candidate set can be referred to as a control resource set (CORESET). Additionally, the time domain resources monitored by terminal device 10 for the PDCCH candidate set can be referred to as a search space set (SSS). Terminal device 10 can monitor the PDCCH candidate set in one or more CORESETs within the DL-BWP of the serving cell configured with PDCCH monitoring, according to the corresponding search space set. Here, monitoring can mean attempting to decode each of the PDCCH candidates according to the monitored DCI format. This configuration can be referred to as blind decoding.

[0068] Here, a CRC (Cyclic Redundancy Check) scrambled with an RNTI (Radio Network Temporary Identifier) ​​can be added to the DCI (or DCI format) transmitted on the PDCCH. CRC can also be called a CRC parity check bit. Several types of RNTIs are defined. For example, the base station device 20 can configure each RNTI by sending an RRC message, which includes information indicating a C-RNTI (Cell-RNTI), information indicating an MCS-C-RNTI (Modulation and Coding Scheme Cell-RNTI), and information indicating a CS-RNTI (Configured Scheduling-RNTI). That is, a CRC scrambled with at least one of C-RNTI, MCS-C-RNTI, and CS-RNTI can be added to the DCI (or DCI format) transmitted on the PDCCH.

[0069] Terminal device 10 can monitor (and / or receive) PDCCH and detect (and / or receive) DCI format.

[0070] Terminal device 10 uses PUCCH, which serves as the physical channel, to send uplink control information (UCI) to base station device 20. UCI includes control information such as scheduling requests (SR), Ack / Nack for Hybrid Automatic Repeat reQuest (HARQ), and channel state information (CSI). UCI is mapped to PUCCH or PUSCH, equivalent to Layer 1 signaling.

[0071] The base station device 20 uses the DL-SCH as a transmission channel to send the MAC layer control element (CE) to the terminal device 10. The downlink MAC CE is mapped to the PDSCH via the DL-SCH, which is equivalent to layer 2 signaling.

[0072] Terminal device 10 uses UL-SCH as the transmission channel to send MAC layer control element (CE) to base station device 20. The uplink MAC CE includes control information such as buffer status report (BSR). The uplink MAC CE is mapped to PUSCH via UL-SCH, which is equivalent to layer 2 signaling.

[0073] Base station device 20 uses the BCCH (Broadcast Channel) as a logical channel to send (or broadcast) system information (SI) to terminal device 10. SI includes Minimum System Information (MSI) and Other System Information (OSI). MSI includes the Master Information Block (MIB) and System Information Block 1 (SIB 1). SIB 1 can be referred to as Remaining Minimum System Information (RMSI). OSI includes system information blocks other than SIB 1 (SIB 2 onwards). In the BCCH, MIB is mapped to PBCH via BCH (Broadcast Channel), and SIB is mapped to PDSCH via DL-SCH.

[0074] Base station device 20 uses the Signaling Radio Bearer (SRB) established between terminal device 10 and base station device 20 in the RRC layer to send control information in the RRC layer to terminal device 10. Hereinafter, messages exchanged between base station device 20 and terminal device 10 in the RRC layer can be referred to as RRC messages. There are several types of SRBs (e.g., SRB 0, SRB 1, SRB 2, SRB 3, SRB 4). In addition to RRC messages, SRBs are also used for sending and receiving NAS messages, which include control information in the NAS layer. CCCH or DCCH is used to send RRC messages from base station device 20 to terminal device 10. CCCH and DCCH are mapped to PDSCH via DL-SCH, respectively. RRC messages are equivalent to Layer 3 signaling.

[0075] As an example of a downlink RRC message, the RRC Reconfiguration message will be explained. The RRC Reconfiguration message is an RRC message sent from base station device 20 to terminal device 10 using SRB 1 or SRB 3. The DCCH is used to send the RRC Reconfiguration message. The RRC Reconfiguration message is used to perform reconfiguration or modification related to the connection between base station device 20 and terminal device 10.

[0076] Terminal device 10 uses the aforementioned SRB to send an RRC message to base station device 20. CCCH or DCCH is used to send the RRC message from terminal device 10 to base station device 20. CCCH and DCCH are mapped to PUSCH via UL-SCH, respectively. The RRC message is equivalent to Layer 3 signaling.

[0077] As an example of an uplink RRC message, the User Equipment Capability Information (UECapabilityInformation) message will be explained. The UECapability Information message is an RRC message sent from terminal device 10 to base station device 20 using SRB 1. The DCCH is used to send the UECapability Information message. The UECapability Information message is used to notify base station device 20 of information related to the radio access capability of terminal device 10.

[0078] As an example of an uplink RRC message, the User Equipment Assistance Information (UAI) message will be explained. The UAI message is an RRC message sent from terminal device 10 to base station device 20 using SRB 1 or SRB 3. The DCCH is used to send the UAI message. The UAI message is used to notify base station device 20 of various information related to terminal device 10 (e.g., UE assistance information).

[0079] 1.4. Uplink Scheduling 1.4.1. Scheduling Request (SR) The SR (Request for Radio Resources) is used by terminal device 10 to request radio resource allocation for PUSCH from base station device 20. The SR can also be used to request UL-SCH resources for initial transmission. Base station device 20 allocates PUSCH resources for sending the SR to terminal device 10. Base station device 20 sends an RRC (Resource Control Message) message to terminal device 10, including the parameters of the SR. The parameters of the SR are included in the SchedulingRequestResourceConfig IE, which is an example of an Information Element (IE) in RRC.

[0080] Terminal device 10 uses configured PUCCH resources to send a UCI including a SR to base station device 20. Terminal device 10 can send UCIs on demand. Terminal device 10 can also send UCIs at a configured periodicity. For example, terminal device 10 can send an SR set to "0" (negative SR) and / or an SR set to "1" (positive SR). Base station device 20 allocates PUSCH radio resources to terminal device 10 based on the SR.

[0081] 1.4.2. Dynamic Grant (DG) DG is a scheduling method for allocating PUSCH radio resources according to the uplink granting process. Base station device 20 sends an uplink grant to terminal device 10 on the PDCCH. Terminal device 10 performs PUSCH transmission according to the uplink grant. For example, base station device 20 may allocate PUSCH radio resources using a DCI format accompanied by a CRC scrambled with C-RNTI and / or MCS-C-RNTI (i.e., a DCI format for scheduling PUSCH), and terminal device 10 may use the allocated PUSCH radio resources to perform uplink transmission. Here, the New Data Indicator included in the DCI format with a CRC scrambled with C-RNTI and / or MCS-C-RNTI can be set to 0 or 1. Alternatively, base station device 20 may allocate PUSCH radio resources using a DCI format accompanied by a CRC scrambled with CS-RNTI (i.e., a DCI format for scheduling PUSCH), and terminal device 10 may use the allocated PUSCH radio resources to perform uplink transmission. Here, the new data indicator included in the DCI format, which is accompanied by CRC scrambling using CS-RNTI, can be set to 1.

[0082] 1.4.3. Configured Grant (CG) CG is a scheduling method for allocating PUSCH radio resources without the aforementioned dynamic uplink granting process. CG includes two types: Type 1 and Type 2. The base station device 20 sends an RRC message including the parameters of the CG to the terminal device 10. The parameters of the CG are included in the ConfiguredGrantConfig IE, which is an example of an Information Element (IE) of RRC. The ConfiguredGrantConfig IE includes the parameter periodicity related to the period of transmission using PUSCH. Furthermore, the periodicity parameter is configured in units of time slots or symbols. Alternatively, the periodicity parameter can also be configured in units of frames per second (FPS). In Type 1, the terminal device 10 begins transmitting signals at the configured period without triggering by DCI. On the other hand, in Type 2, the base station device 20 sends a DCI scrambled by CS-RNTI to the terminal device 10. CS-RNTI is used to activate periodic transmissions. Terminal device 10 activates the DCI scrambled by CS-RNTI and begins transmission using PUSCH at a configured period.

[0083] 1.5. Extended Reality (XR) The characteristics of services occurring in XR are explained. In XR, various types of data (video data, audio data, user data, control data, etc.) are sent and received in parallel. Each of these data streams has different service characteristics and QoS requirements.

[0084] During the timing of sending and receiving the aforementioned data, due to factors such as video or audio encoding and network latency, time shifts may sometimes occur, manifesting as jitter, variability, or fluctuation.

[0085] Reference 1 describes the sending and receiving in XR, and the following definitions can be introduced. [Reference 1] 3GPP TR 23.700-60 V1.1.0 (2022-09)

[0086] A Protocol Data Unit Set (PDU) is a collection of one or more PDUs that carry a single payload of information generated at the application level. This application level might correspond, for example, to a frame or video slice in an XR service. A data burst is a set of multiple data PDUs generated and sent by an application within a short period of time. Each PDU in the set can correspond to a PDCP SDU (Service Data Unit).

[0087] Furthermore, in XR, as part of the aforementioned QoS requirements, the requirements for Packet Delay Budget (PDB) are discussed. PDB is the upper bound of the allowed packet delay time between the terminal device 10 and the UPF. Additionally, Reference 1 describes the introduction of the following new QoS parameters. PDU-Set Delay Budget (PSDB): is the upper bound of the allowed delay time of the PDU set between terminal device 10 and UPF. PDU-Set Error Rate (PSER): is the upper bound of the error rate calculated between the PDU set processed by the sender and the PDU set of the higher layer that was not successfully delivered to the corresponding receiver.

[0088] 1.6. Processing in the PDCP layer Next, the PDCP entities in each of the terminal device 10 and the base station device 20 will be described. Furthermore, the processing in the PDCP entity of the terminal device 10 can be implemented by the control unit 110 described above. The processing in the PDCP entity of the base station device 20 can be implemented by the control unit 210 described above.

[0089] like Figure 9 As shown, the PDCP entity 910 in terminal device 10 is connected to a higher layer (e.g., the SDAP layer) and a lower layer (e.g., the RLC layer). The PDCP entity 910 may include one or more PDCP transmitting units 911 and one or more PDCP receiving units 912. Hereinafter, to distinguish it from the PDCP entity of base station device 20, the PDCP transmitting unit 911 in terminal device 10 is referred to as "first PDCP transmitting unit 911," and the PDCP receiving unit 912 in terminal device 10 is referred to as "first PDCP receiving unit 912." Furthermore, the PDCP transmitting unit may be referred to as a "transmitting PDCP entity," and the PDCP receiving unit may be referred to as a "receiving PDCP entity."

[0090] The PDCP entity 920 in the base station apparatus 20 is connected to a higher layer (e.g., the SDAP layer) and a lower layer (e.g., the RLC layer). The PDCP entity 920 may include one or more PDCP transmitting units 921 and one or more PDCP receiving units 922. Hereinafter, the PDCP transmitting unit 921 in the base station apparatus 20 is referred to as the "second PDCP transmitting unit 921", and the PDCP receiving unit 922 in the base station apparatus 20 is referred to as the "second PDCP receiving unit 922".

[0091] PDCP PDUs include PDCP PDUs for data and PDCP PDUs for control. PDCP PDUs for data are called "PDCP Data PDUs". PDCP PDUs for control are called "PDCP Control PDUs".

[0092] A Sequence Number (SN) is assigned to a PDCP data PDU. The range of SNs can be configured in both the downlink and uplink. The range of SNs for both the downlink and uplink can be configured based on parameters associated with the PDCP layer.

[0093] The base station device 20 can send an RRC message to the terminal device 10, including parameters associated with the PDCP layer. For example, the parameters associated with the PDCP layer can be included in a PDCP-Config IE, which is an example of an information element (IE) for RRC. Information associated with the downlink SN range and the uplink SN range can be included in the PDCP-Config IE. For example, the PDCP-Config IE can include pdcp-SN-SizeDL and pdcp-SN-SizeUL.

[0094] pdcp-SN-SizeDL is information associated with the range of the downlink SN. pdcp-SN-SizeDL can be configured for Signaling Radio Bearer (SRB), Multicast / broadcast service Radio Bearer (MRB), or Data Radio Bearer (DRB). pdcp-SN-SizeDL indicates the size or length of the downlink SN. pdcp-SN-SizeDL can be configured as 12 bits or 18 bits. Furthermore, in the case of SRB, only 12 bits can be applied as the SN size. For example, the range of the downlink SN can be configured from "0" to "2". [pdcp-SN-SizeDL] The range of "-1".

[0095] pdcp-SN-SizeUL is information associated with the range of the uplink SN. pdcp-SN-SizeUL can be configured for SRB, MRB, or DRB. pdcp-SN-SizeUL indicates the size or length of the uplink SN. pdcp-SN-SizeUL can be configured to be 12 bits or 18 bits. Furthermore, in the case of SRB, only 12 bits can be applied as the SN size. For example, the range of the uplink SN can be configured from "0" to "2". [pdcp-SN-SizeUL] The range of "-1".

[0096] For example, the SN is 12 bits in size and the format of the PDCP PDU used for SRB can be... Figure 10 The format shown is as follows. The SN is 12 bits in size and the format of the PDCP PDU used for MRB or DRB can be... Figure 11The format shown. The SN is 18 bits in size and the format of the PDCP PDU used for MRB or DRB can be... Figure 12 The format shown.

[0097] In the above format, the "D / C" field can be a value indicating whether it is a PDCP data PDU or a PDCP control PDU. For example, if "D / C" = 0, it can indicate that the PDCP PDU is a PDCP control PDU. If "D / C" = 1, it can indicate that the PDCP PDU is a PDCP data PDU.

[0098] In the above format, the "Data" field includes either an uncompressed or compressed PDCP SDU. The "MAC-I" field is used to notify the message authentication code.

[0099] An example of processing using SN will be explained. For instance, in the downlink, the second PDCP transmitter 921 of the base station device 20 may send a PDCP data PDU with SN assigned to it to the terminal device 10, and the first PDCP receiver 912 of the terminal device 10 may use the SN to detect missing data units. In the uplink, the first PDCP transmitter 911 of the terminal device 10 may send a PDCP data PDU with SN assigned to it to the base station device 20, and the second PDCP receiver 922 of the base station device 20 may use the SN to detect missing data units.

[0100] In the following, the term "data unit" or "packet" can refer to both a PDU and / or an SDU. For example, on the transmitting side, a data unit or packet received from a higher layer is called an SDU, and the data unit including the SDU and its header is sent to the lower layer as a PDU. Therefore, on the transmitting side, the term "data unit" or "packet" can refer to an SDU received from a higher layer and / or a PDU including the SDU and its header. On the receiving side, a data unit or packet received from a lower layer is called a PDU, and the data unit with its header removed is sent to the higher layer as an SDU. Therefore, on the receiving side, the term "data unit" or "packet" can refer to a PDU received from a lower layer and / or an SDU obtained by removing the header from the PDU.

[0101] For the above processing, each of the PDCP entities 910 and 920 can use a COUNT value. The COUNT value can consist of the HFN (Hyper Frame Number) and SN. The size or length of the COUNT value can be 32 bits. That is, the bit size of the HFN portion of the COUNT value can be equal to the value obtained by subtracting the size of the SN from 32.

[0102] The following sections 1.6.1 through 1.6.3 illustrate downlink processing as examples. Furthermore, the concepts described in these sections can be applied to uplink processing.

[0103] 1.6.1 Processing in the PDCP Transmitter The second PDCP transmission unit 921 of the base station device 20 performs transmission processing to send data units (i.e., SDUs) received from higher layers to lower layers. The second PDCP transmission unit 921 can associate the COUNT value with the data unit to perform the above transmission processing.

[0104] The second PDCP transmitting unit 921 can maintain the following state variables for the above-described transmitting process. TX_NEXT: Indicates the COUNT value of the next PDCP SDU to be sent.

[0105] like Figure 13 As shown, the second PDCP transmitter 921 receives the PDCP SDU 1301 from the higher layer. The second PDCP transmitter 921 associates the COUNT value corresponding to TX_NEXT with the PDCP SDU 1301. Next, the second PDCP transmitter 921 configures the SN of the PDCP data PDU including the PDCP SDU 1301 based on the COUNT value corresponding to TX_NEXT. The second PDCP transmitter 921 sends the PDCP data PDU to the lower layer. Then, the second PDCP transmitter 921 increments TX_NEXT by 1.

[0106] 1.6.2 Processing in the PDCP receiver The first PDCP receiving unit 912 of the terminal device 10 performs transmission processing to send data units (i.e., PDUs) received from the lower layer to the higher layer. The first PDCP receiving unit 912 can associate the COUNT value with the data unit to perform the above transmission processing.

[0107] The first PDCP receiving unit 912 can perform re-ordering processing in the above-described transmission process. Re-ordering can be a process of storing PDCP SDUs in the receive buffer and transmitting or delivering PDCP SDUs to higher layers according to the order of the COUNT values ​​obtained from the PDCP SDUs.

[0108] For example, parameters associated with the aforementioned PDCP layer may include parameters associated with reordering. Parameters associated with reordering may be included in the PDCP-Config IE. The PDCP-Config IE may include outOfOrderDelivery and t-Reordering.

[0109] `outOfOrderDelivery` can be information instructing the first PDCP receiving unit 912 to perform the aforementioned transmission process without waiting for data units (i.e., PDUs) that have not yet arrived at the PDCP layer. That is, if `outOfOrderDelivery` is configured, and the first PDCP receiving unit 912 receives a data unit and detects that a data unit that should have been received before that data unit is missing, the first PDCP receiving unit 912 can send the received data unit to a higher layer without waiting for the missing data unit. Therefore, if `outOfOrderDelivery` is not configured, and the first PDCP receiving unit 912 detects a missing data unit, the first PDCP receiving unit 912 can perform the reordering process described below.

[0110] t-Reordering can be a timer used for reordering processing. t-Reordering can be initiated when the first PDCP receiver 912 detects a missing data unit. When t-Reordering expires, the first PDCP receiver 912 can send the data unit (i.e., SDU) stored in the receive buffer to a higher layer. Therefore, t-Reordering can be a timer that defines an upper limit to the period of waiting for a missing data unit. Furthermore, for each first PDCP receiver 912 (i.e., the receiving PDCP entity), only one t-Reordering can be initiated (or operated) at a given timing.

[0111] The first PDCP receiving unit 912 may maintain at least one of the following state variables for the above-described transmission process. RX_NEXT: Indicates the COUNT value of the PDCP SDU that is expected to be received next. RX_DELIV: Indicates the COUNT value of the initial PDCP SDU that has not yet been sent (delivered) to the higher layer and is still waiting. RX_REORD: indicates the next COUNT value associated with the COUNT value of the PDCP data PDU that triggers t-Reordering. RCVD_COUNT: indicates the COUNT value based on the received PDCP data PDU.

[0112] As Figure 14 shows, the first PDCP receiving unit 912 receives packets from a lower layer (e.g., PDCP PDU 1401). The first PDCP receiving unit 912 stores the PDCP SDU corresponding to the received PDCP PDU 1401 in a receive buffer. The first PDCP receiving unit 912 updates RX_NEXT. RX_NEXT is updated to be the next value after the COUNT value corresponding to PDCP PDU 1401 (i.e., RCVD_COUNT). Here, the COUNT value based on PDCP PDU 1401 (i.e., RCVD_COUNT) is equal to RX_DELIV. This means that the first PDCP receiving unit 912 receives the PDCP PDU in the expected order. Therefore, the first PDCP receiving unit 912 determines that no packet is missing. Since no packet is missing, t-Reordering does not operate. As Figure 15 shows, the first PDCP receiving unit 912 transmits the PDCP SDU corresponding to the received PDCP PDU 1401 to an upper layer, and updates RX_DELIV.

[0113] In contrast, as Figure 16 shows, the first PDCP receiving unit 912 receives a packet from a lower layer (e.g., PDCP PDU 1601). The first PDCP receiving unit 912 stores the PDCP SDU corresponding to the received PDCP PDU 1601 in the receive buffer. The first PDCP receiving unit 912 updates RX_NEXT. RX_NEXT is updated to be the next value after the COUNT value corresponding to PDCP PDU 1601 (i.e., RCVD_COUNT). RCVD_COUNT is not equal to RX_DELIV. This means that the first PDCP receiving unit 912 does not receive the PDCP PDU in the expected order, that is, a packet that should have been received is missing. As Figure 17 shows, the first PDCP receiving unit 912 does not transmit the PDCP SDU corresponding to PDCP PDU 1601 to the upper layer, and does not update RX_DELIV. At this time, since RX_DELIV < RX_NEXT, the first PDCP receiving unit 912 starts t-Reordering and updates RX_REORD. RX_REORD is updated to RX_NEXT.

[0114] As Figure 18 As shown, while t-Reordering is in operation, the first PDCP receiving unit 912 receives a packet (e.g., a PDCP PDU 1801) from a lower layer. The first PDCP receiving unit 912 stores the PDCP SDU corresponding to the received PDCP PDU 1801 in a reception buffer. The COUNT value corresponding to the PDCP PDU 1801 (i.e., RCVD_COUNT) is equal to RX_DELIV. In this case, as Figure 19 shown, the first PDCP receiving unit 912 transmits the PDCP SDU stored in the reception buffer (corresponding to PDCP PDU 1601) and the PDCP SDU corresponding to PDCP PDU 1801 to a higher layer. That is, the first PDCP receiving unit 912 transmits all PDCP SDUs stored in the reception buffer together with the PDCP SDU corresponding to the received PDCP PDU 1801 to the higher layer. Further, the first PDCP receiving unit 912 updates RX_DELIV. RX_DELIV is greater than or equal to RX_REORD. Accordingly, the first PDCP receiving unit 912 stops and resets t-Reordering.

[0115] On the other hand, as Figure 20 shown, assume that the first PDCP receiving unit 912 does not receive a PDCP PDU satisfying RCVD_COUNT=RX_DELIV, and t-Reordering expires. In this case, the first PDCP receiving unit 912 transmits all PDCP SDUs stored in association with COUNT values less than RX_REORD to the higher layer. In this example, the first PDCP receiving unit 912 transmits the PDCP SDU (corresponding to PDCP PDU 1601) stored in the reception buffer to the higher layer. Further, the first PDCP receiving unit 912 updates RX_DELIV.

[0116] More specifically, the first PDCP receiving unit 912 may perform processing in accordance with Section 5.2.2 of Non-Patent Document 1.

[0117] After determining that the COUNT value of the received PDCP data PDU is equal to RCVD_COUNT, the first PDCP receiving unit 912 may perform the following processing. If the PDCP data PDU with RCVD_COUNT < RX_DELIV or with a COUNT value equal to RCVD_COUNT has been received previously, the first PDCP receiving unit 912 discards the PDCP data PDU. That is, the first PDCP receiving unit 912 may discard the PDCP data PDU that is considered to have already been received.

[0118] In a case where the above-received PDCP data PDU with a COUNT value equal to RCVD_COUNT is not discarded, the first PDCP receiving unit 912 may perform the following processes from (a1) to (a6).

[0119] (a1) The first PDCP receiving unit 912 stores the resulting PDCP SDU in a reception buffer.

[0120] (a2) In a case where RCVD_COUNT ≥ RX_NEXT: The first PDCP receiving unit 912 updates RX_NEXT to RCVD_COUNT + 1.

[0121] (a3) In a case where outOfOrderDelivery is configured: After performing header decompression using EHC (Ethernet Header Compression), the first PDCP receiving unit 912 delivers the resulting PDCP SDU to a higher layer.

[0122] (a4) In a case where RCVD_COUNT = RX_DELIV: If header decompression has not been performed previously, after performing header decompression, the first PDCP receiving unit 912 delivers the PDCP SDUs to the higher layer in ascending order of associated COUNT values. Herein, all stored PDCP SDUs associated with consecutive COUNT values starting from the COUNT value equal to RX_DELIV are delivered. The first PDCP receiving unit 912 updates RX_DELIV to the COUNT value of the first PDCP SDU that has a COUNT value greater than RX_DELIV and has not been delivered to the higher layer.

[0123] (a5) In a case where t-Reordering is running and RX_DELIV ≥ RX_REORD: The first PDCP receiving unit 912 stops and resets t-Reordering.

[0124] (a6) In a case where t-Reordering is not running (including the situation where t-Reordering is stopped due to the foregoing operation) and RX_DELIV < RX_NEXT: The first PDCP receiving unit 912 updates RX_REORD to RX_NEXT. The first PDCP receiving unit 912 starts t-Reordering.

[0125] When t-Reordering expires, the first PDCP receiving unit 912 may perform the following processes from (b1) to (b3).

[0126] (b1) If header decompression has not been performed before, after performing header decompression, the first PDCP receiving unit 912 delivers PDCP SDUs to a higher layer in ascending order of the associated COUNT values. Here, all stored PDCP SDUs associated with COUNT values smaller than RX_REORD are delivered. Furthermore, all stored PDCP SDUs associated with consecutive COUNT values starting from RX_REORD are delivered.

[0127] (b2) The first PDCP receiving unit 912 updates RX_DELIV to the COUNT value of the first PDCP SDU that has a COUNT value equal to or greater than RX_REORD and has not been delivered to the higher layer.

[0128] (b3) When RX_DELIV < RX_NEXT: The first PDCP receiving unit 912 updates RX_REORD to RX_NEXT. The first PDCP receiving unit 912 starts t-Reordering.

[0129] 1.6.3 PDCP status report The first PDCP receiving unit 912 of the terminal device 10 may notify a second PDCP transmitting unit 921 of the base station device 20 of a PDCP status report. The PDCP status report may include the status of SDUs. For example, the PDCP status report may include information indicating whether an SDU is missing or has been received normally. For example, when re-establishment of a PDCP entity is requested by a higher layer, the first PDCP receiving unit 912 may trigger a PDCP status report for a DRB or MRB configured to transmit a PDCP status report on an uplink.

[0130] The first PDCP receiving unit 912 may use Figure 21The format of the PDCP control PDU used for PDCP status reporting is shown. Here, the "PDU Type" field indicates the type of control information included in the PDCP control PDU. In the case of PDCP status reporting, "PDU Type" can be "000". The "FMC (First Missing Count)" field indicates the COUNT value (i.e., RX_DELIV) of the initially missing PDCP SDU. The "Bitmap" field indicates, in the first PDCP receiving unit 912, which SDU is missing and which SDU was received normally for PDCP SDUs with a COUNT value greater than FMC. For example, if the bit is "0", this indicates that the SDU corresponding to that bit is missing. If the bit is "1", this indicates that the SDU corresponding to that bit was received normally.

[0131] 1.6.4 Data Discarding Process When the first PDCP transmitting unit 911 of the terminal device 10 receives a PDCP status report from the second PDCP receiving unit 922 of the base station device 20 on the downlink, the first PDCP transmitting unit 911 can perform data unit discarding processing. For example, when the normal delivery of a PDCP SDU is confirmed based on the PDCP status report, the first PDCP transmitting unit 911 can discard the PDCP SDU together with the corresponding PDCP data PDU. For example, the first PDCP transmitting unit 911 can consider it as having normally received a PDCP SDU with a COUNT value that is less than the value of the FMC field included in the PDCP status report. In addition, for example, the first PDCP transmitting unit 911 can consider it as having normally received a PDCP SDU in which the corresponding bit in the bitmap field included in the PDCP status report is configured as "1".

[0132] Furthermore, the first PDCP transmitter 911 can use a PDCP discard timer and a DiscardTimerForLowImportance (for low-priority discarding) to perform data unit discarding processing. DiscardTimerForLowImportance is used for data discarding based on PSI (PDU Set Importance). For simplicity, this discarding process will be referred to below as "PSI-based discard processing."

[0133] Non-Patent Document 3 describes PSI. PSI represents the importance of a PDU set, indicating its importance when compared to other PDU sets within the same QoS flow. For example, PSI is represented by 4 bits. PSI can be a value from 0 to 15. The lower the PSI value, the higher the importance of the PDU set associated with that PSI. For example, the PDU set associated with PSI "0" has the highest importance. The PDU set associated with PSI "15" has the lowest importance. Therefore, in the following description, the statement "the PSI value is relatively small" can be replaced with the statement "the corresponding data (i.e., the PDU set) has relatively high importance." The statement "the PSI value is relatively large" can be replaced with the statement "the corresponding data (i.e., the PDU set) has relatively low importance."

[0134] In the following, the commonly used PDCP discard timer is referred to as the "first discard timer," and the DiscardTimerForLowImportance used in the PSI-based discard process described above, instead of the first discard timer, is referred to as the "second discard timer." The second discard timer is used for data with relatively low importance (i.e., data with relatively large PSI values). When the PSI-based discard process is activated, the second discard timer is started instead of the first discard timer. Furthermore, the second discard timer is configured to always be shorter than the first discard timer.

[0135] For example, parameters associated with the aforementioned discarding process can be included in the PDCP-Config IE. The PDCP-Config IE can include information related to the first discarding timer, information related to the second discarding timer, and pdu-SetDiscard.

[0136] The first discard timer can be configured according to DRB. The second discard timer can also be configured according to DRB. The first PDCP transmitter 911 can start the second discard timer associated with the PDCP SDU when it receives the PDCP SDU from a higher layer, and the PSI-based discard processing is activated, the second discard timer is configured, and the PDCP SDU belongs to a set of PDUs with low importance (i.e., large PSI value). Otherwise, the first PDCP transmitter 911 can start the first discard timer associated with the PDCP SDU when it receives the PDCP SDU from a higher layer.

[0137] pdu-SetDiscard can be a parameter indicating whether the first PDCP transmitting unit 911 performs PDU set-based discarding processing. For example, if a first or second discard timer expires for a certain PDCP SDU and pdu-SetDiscard is configured, the first PDCP transmitting unit 911 can discard all PDCPSDUs belonging to the PDU set to which the PDCP SDU belongs, along with the corresponding PDCP data PDU. Alternatively, if a first or second discard timer expires for a certain PDCP SDU and pdu-SetDiscard is not configured, the first PDCP transmitting unit 911 can discard the PDCP SDU along with the corresponding PDCP data PDU.

[0138] The base station device 20 can send a MAC CE to the terminal device 10 to indicate activation or deactivation of PSI-based SDU discard processing. This MAC CE can be referred to as a "PSI-Based SDU Discard Activation / Deactivation MAC CE". Figure 22 As shown, the MAC CE includes an 8-bit field 2200. In field 2200, Di indicates the activation or deactivation status of the PSI-based drop handling, ordered by the DRB ID in the DRB configured with PSI-based drop handling. Here, i is an integer from 0 to 7. The definition of i is the same in the following description. A value of 1 for Di indicates that the PSI-based drop handling is activated for the DRB corresponding to Di. A value of 0 for Di indicates that the PSI-based drop handling is deactivated for the DRB corresponding to Di.

[0139] The following illustrates an example of PSI-based discard processing. Figure 23 As shown, the first PDCP transmitter 911 receives packet 2301 from the higher layer at time t0. The first PDCP transmitter 911 starts a first discard timer from time t0. When the first discard timer expires, the first PDCP transmitter 911 discards packet 2301.

[0140] Terminal device 10 receives data from base station device 20 at time t1. Figure 22The MAC CE is shown. Assume that in the MAC CE, PSI-based discarding is activated for the corresponding DRB. Subsequently, the first PDCP transmitter 911 receives packet 2302 from the higher layer at time t2. Assume a second discard timer is configured, and packet 2302 belongs to a low-importance PDU set. In this case, the first PDCP transmitter 911 starts the second discard timer instead of the first. When the second discard timer expires, the first PDCP transmitter 911 discards packet 2302. With the above configuration, low-importance packets can be discarded as early as possible.

[0141] 1.6.5 Reports related to missing data units For example, in XR services, due to the aforementioned discarding process using a first or second discard timer, packet discarding is likely to occur frequently. When a packet associated with a serial number (SN) is discarded, the SN is missing. That is, when a portion of multiple packets associated with consecutive SNs is discarded, the continuity of the SNs is disrupted. Partial SNs are missing numbers, creating gaps within the SNs. This phenomenon is referred to below as "SN gaps".

[0142] When a SN gap occurs, an additional delay time is generated for processing the aforementioned reordering. For example, t-Reordering is initiated as a trigger when a packet that has already been dropped. Before the t-Reordering expires, waiting packets will not be sent to higher layers, thus generating a delay time. To prevent such a delay time, the first PDCP transmitting unit 911 may send a report to the second PDCP receiving unit 922 of the base station device 20 regarding data units (e.g., PDCP SDUs) that are missing or dropped due to the dropping process.

[0143] For example, the first PDCP transmitter 911 can use a PDCP control PDU to notify the second PDCP receiver 922 of a missing data unit. Hereinafter, the PDCP control PDU used to report or notify of a missing data unit is referred to as a "Missing control PDU".

[0144] The first PDCP transmitter 911 can be used Figure 24The format shown is correct. A missing data control PDU may include a "D / C" field. The "D / C" field can be the same as described above. A missing data control PDU may include a "PDU Type" field. "PDU Type" can indicate the type of control information included in the PDCP control PDU. "PDU Type" can be configured with a predetermined value for the missing data control PDU. A missing data control PDU may include the SN or COUNT value of the first missing data unit and / or the SN or COUNT value of the last missing data unit. For example, the "FMC" field can indicate the SN or COUNT value of the first missing data unit. A missing data control PDU may include a "Bitmap" field. The "Bitmap" field can indicate whether a corresponding data unit is missing. For example, in the case of a bit "0", this can indicate that the data unit corresponding to that bit is not missing. In the case of a bit "1", this can indicate that the data unit corresponding to that bit is missing. Furthermore, the relationship between "0" and "1" can also be reversed.

[0145] The first PDCP transmitter 911 can be used Figure 25 The format shown is correct. A missing data control PDU may include a "D / C" field. The "D / C" field may be the same as described above. A missing data control PDU may include a "PDU Type" field. The "PDU Type" field may be the same as described above. A missing data control PDU may include the SN or COUNT value of the initial missing data unit and / or the SN or COUNT value of the last missing data unit. For example, the "FMC" field may indicate the SN or COUNT value of the initial missing data unit. A missing data control PDU may include information indicating the range of missing data units. A missing data control PDU may include a "Missing PDUs" field. The "Missing PDUs" field may indicate the number of missing data units from the initial missing data unit. Therefore, a missing data control PDU may indicate the range of missing data units based on a combination of the SN or COUNT value of the initial missing data unit and the number of missing data units from the initial missing data unit. In another example, the missing control PDU can indicate the range of missing data units based on a combination of the SN or COUNT value of the initial missing data unit and the SN or COUNT value of the last missing data unit.

[0146] In the event of receiving a missing control PDU, the second PDCP receiving unit 922 of the base station device 20 may perform at least one of the following processes (c1) to (c5).

[0147] (c1) When the COUNT values ​​for all missing PDUs are outside the reordering window: The second PDCP receiving unit 922 ignores the missing control PDU.

[0148] (c2) if RX_NEXT is within the missing PDU indicated by the missing control PDU: The second PDCP receiving unit 922 updates RX_NEXT to the COUNT value of the first PDCP SDU that has a COUNT value greater than RX_NEXT and is not included in the missing PDUs indicated by the missing control PDU.

[0149] (c3) if RX_DELIV is included in the missing PDU: If any, after performing header decompression, the second PDCP receiving unit 922 delivers all stored PDCP SDUs associated with consecutive COUNT values starting from the COUNT value equal to RX_DELIV to the upper layer in ascending order of the associated COUNT values. The second PDCP receiving unit 922 updates RX_DELIV to the COUNT value of the first PDCP SDU that has a COUNT value greater than RX_DELIV, has not been delivered to the upper layer, and is not included in the missing PDU indicated by the missing control PDU.

[0150] (c4) when t-Reordering is running and RX_DELIV ≥ RX_REORD: The second PDCP receiving unit 922 stops and resets t-Reordering.

[0151] (c5) when t-Reordering is not running (including the case where t-Reordering is stopped due to the above operation) and RX_DELIV < RX_NEXT: The second PDCP receiving unit 922 updates RX_REORD to RX_NEXT. The second PDCP receiving unit 922 starts t-Reordering.

[0152] In the above processing from (c1) to (c5), there is a possibility that additional delay cannot be well eliminated. For example, there is a possibility that although a certain data unit is indicated as missing by the missing control PDU, the second PDCP receiving unit 922 still waits for the reception of the data unit.

[0153] Furthermore, although the above describes an example where the first PDCP transmitting unit 911 of the terminal device 1 transmits a discard control PDU and the second PDCP receiving unit 922 of the base station device 20 receives the discard control PDU, it may also be the case that the second PDCP transmitting unit 921 of the base station device 20 transmits the discard control PDU and the first PDCP receiving unit 912 of the terminal device 10 receives the discard control PDU. The same problem may also arise in this case. For example, as Figure 26 shows, assume that the second PDCP transmitting unit 921 of the base station device 20 transmits a discard control PDU to the first PDCP receiving unit 912 of the terminal device 10. In this case, the first PDCP receiving unit 912 increments RX_NEXT and RX_DELIV by 1.

[0154] Next, as Figure 27 shows, the first PDCP receiving unit 912 receives PDCP PDU 2701. The first PDCP receiving unit 912 transmits the PDCP SDU corresponding to the received PDCP PDU 2701 to a higher layer. Then, the first PDCP receiving unit 912 increments RX_NEXT and RX_DELIV by 1. In this case, RX_NEXT and RX_DELIV are updated to values corresponding to the data unit that has been indicated as discarded by the discard control PDU. Next, when the first PDCP receiving unit 912 receives PDCP PDU 2702, RX_NEXT is updated (refer to the processing of (a2) above). As a result, RX_DELIV < RX_NEXT, so t-Reordering is started (refer to the processing of (a6) above. This results in additional delay time.

[0155] Another example will be described. For example, as Figure 28 shows, the first PDCP receiving unit 912 receives a discard control PDU from the second PDCP transmitting unit 921. At this point in time, RX_NEXT is outside the range of the COUNT value of the data unit indicated by the discard control PDU. In this case, the first PDCP receiving unit 912 performs processing according to a situation where no discard control PDU has been received.

[0156] As Figure 29 shows, the first PDCP receiving unit 912 receives PDCP PDU 2901. The first PDCP receiving unit 912 transmits the PDCP SDU corresponding to the received PDCP PDU 2901 to a higher layer. Then, the first PDCP receiving unit 912 increments RX_NEXT and RX_DELIV by 1. In this case, RX_NEXT and RX_DELIV are updated to values corresponding to the data unit that has been indicated as discarded by the discard control PDU. Therefore, as in the above case, additional delay time occurs.

[0157] 1.7. State Variable Update Processing The second PDCP transmitting unit 921 of the base station device 20 performs data unit discarding processing. The second PDCP transmitting unit 921 uses a missing control PDU to send a report (e.g., a missing control PDU) related to data units missing or discarded due to the discarding processing to the first PDCP receiving unit 912 of the terminal device 10. Based on the missing control PDU, the first PDCP receiving unit 912 updates the state variables used for transmission processing, which transmits data units received from lower layers to higher layers. Hereinafter, aspects 1-1 to 1-7 of the state variable update processing will be described. Aspects 1-1 to 1-4 include those related to... Figure 26 as well as Figure 27 The handling of the situation described in the document (hereinafter referred to as "Situation 1"). Aspects 1-5 to 1-6 include the handling of the situation in Figure 28 as well as Figure 29 The handling of the situation described in section 1 (hereinafter referred to as "Situation 2"). Aspects 1-7 include both the handling of Situation 1 and the handling of Situation 2.

[0158] (Aspect 1-1) Upon receiving a missing data control PDU, the first PDCP receiving unit 912 can update RX_NEXT to the value of the last missing data unit in the missing data units indicated by the missing data control PDU plus 1, where the last missing data unit has a COUNT value greater than RX_NEXT. That is, upon receiving a missing data control PDU, the first PDCP receiving unit 912 can update RX_NEXT based on the COUNT value of the last missing data unit in the missing data units indicated by the missing data control PDU. Furthermore, the condition of having a COUNT value greater than RX_NEXT can be removed from the conditions for determining the updated RX_NEXT. In other words, upon receiving a missing data control PDU, the first PDCP receiving unit 912 can update RX_NEXT to the value of the last missing data unit in the missing data units indicated by the missing data control PDU plus 1.

[0159] For example, if RX_NEXT is within a missing PDU indicated by the missing control PDU, the first PDCP receiving unit 912 can update RX_NEXT to the value of the last missing data unit in the missing data units indicated by the missing control PDU plus 1, where the last missing data unit has a COUNT value greater than RX_NEXT. Alternatively, for example, the first PDCP receiving unit 912 can update RX_DELIV through the process described in (c3) above.

[0160] According to the above configuration, RX_NEXT and RX_DELIV are changed from Figure 26 state to Figure 30 state. This can prevent RX_NEXT from being updated to a value corresponding to a packet that has been indicated as already missing by a missing control PDU. As shown in Figure 31 , the first PDCP receiving unit 912 receives the PDCP PDU 2701. The first PDCP receiving unit 912 transmits the PDCP SDU corresponding to the received PDCP PDU 2701 to a higher layer. The first PDCP receiving unit 912 performs the above process (a4). Therefore, the first PDCP receiving unit 912 updates RX_DELIV to the COUNT value of the first PDCP SDU that has a COUNT value greater than RX_DELIV and has not been delivered to the higher layer. RX_DELIV has a value equal to RX_NEXT. RX_DELIV < RX_NEXT does not hold. That is, since the condition in (a6) above is not satisfied, t-Reordering is not started. Therefore, additional delay can be prevented.

[0161] (Aspect 1-2) When receiving a missing control PDU, the first PDCP receiving unit 912 may treat each of the missing data units indicated by the missing control PDU, or the last missing data unit among the missing data units, as normally received or already discarded, and perform the above processes (a1) to (a6).

[0162] For example, the first PDCP receiving unit 912 may treat the COUNT value of each missing data unit indicated by the missing control PDU, or the COUNT value of the last missing data unit among the missing data units, as RCVD_COUNT, and update at least one of RX_NEXT and RX_DELIV.

[0163] According to the above configuration, RX_NEXT and RX_DELIV are changed from Figure 27 state to Figure 32 state. That is, RX_NEXT and RX_DELIV are updated to Figure 27After the state shown, the first PDCP receiving unit 912 regards the COUNT value of the missing data unit indicated by the missing control PDU as RCVD_COUNT. Therefore, the first PDCP receiving unit 912 performs the process of (a2) above, and updates RX_NEXT to RCVD_COUNT+1. Further, the first PDCP receiving unit 912 performs the process of (a4) above, and updates RX_DELIV to the COUNT value of the first PDCP SDU that has a COUNT value greater than RX_DELIV and has not been delivered to a higher layer. The relation RX_DELIV<RX_NEXT is not satisfied. Since t-Reordering is not started, additional delay time can be prevented from being generated.

[0164] (Aspect 1-3) When the missing control PDU is received, the first PDCP receiving unit 912 may not select the COUNT value of the missing data unit indicated by the missing control PDU as the value of RX_NEXT and / or the value of RX_DELIV in the processes of (a1) to (a6) above. That is, in the processes of (a1) to (a6) above, the first PDCP receiving unit 912 does not update the value of RX_NEXT and / or the value of RX_DELIV to the COUNT value of the missing data unit indicated by the missing control PDU. At this time, when the first PDCP receiving unit 912 receives the missing control PDU, it may perform the processes of (c1) to (c5) above.

[0165] According to the above configuration, RX_NEXT and RX_DELIV are not updated to the values corresponding to the data unit indicated as already missing by the missing control PDU. As Figure 33 shown, RX_NEXT and RX_DELIV are updated to the next value after the value corresponding to the data unit indicated as already missing by the missing control PDU. The relation RX_DELIV<RX_NEXT is not satisfied. Since t-Reordering is not started, additional delay time can be prevented from being generated.

[0166] Furthermore, in Aspects 1-1 to 1-3 above, when outOfOrderDelivery is configured, the first PDCP receiving unit 912 may ignore the missing control PDU.

[0167] (Aspect 1-4) When the missing control PDU is received, the first PDCP receiving unit 912 may perform at least one of the following processes (d1) to (d5).

[0168] (d1) In case all COUNT values of missing PDUs are outside the reordering window, or outOfOrderDelivery is configured: The first PDCP receiving unit 912 ignores the missing control PDU.

[0169] (d2) In case RX_NEXT is within the missing PDU indicated by the missing control PDU: The first PDCP receiving unit 912 updates RX_NEXT to a value obtained by adding 1 to the COUNT value of the last missing PDCP SDU in the missing PDU indicated by the missing control PDU, wherein the last missing PDCP SDU has a COUNT value greater than RX_NEXT.

[0170] (d3) In case RX_DELIV is included in the missing PDU: If any, after performing header decompression, the first PDCP receiving unit 912 delivers all stored PDCP SDUs associated with consecutive COUNT values starting from the COUNT value equal to RX_DELIV to a higher layer in ascending order of the associated COUNT values. The first PDCP receiving unit 912 updates RX_DELIV to the COUNT value of the first PDCP SDU which has a COUNT value greater than RX_DELIV, has not been delivered to the higher layer, and is not included in the missing PDU indicated by the missing control PDU.

[0171] (d4) In case t-Reordering is running, and RX_DELIV ≥ RX_REORD: The first PDCP receiving unit 912 stops and resets t-Reordering.

[0172] (d5) In case t-Reordering is not running (including the situation where t-Reordering is stopped due to the above operation), and RX_DELIV < RX_NEXT: The first PDCP receiving unit 912 updates RX_REORD to RX_NEXT. The first PDCP receiving unit 912 starts t-Reordering.

[0173] Further, the process of (a4) in the above processes (a1) to (a6) can be replaced with the following process of (a4-alt).

[0174] (a4-alt) In case RCVD_COUNT = RX_DELIV: If header decompression was not performed previously, the first PDCP receiving unit 912 delivers the PDCP SDUs to the higher layer in ascending order of the associated COUNT values ​​after performing header decompression. Here, all stored PDCP SDUs associated with consecutive COUNT values ​​starting from the COUNT value equal to RX_DELIV are delivered. The first PDCP receiving unit 912 updates RX_DELIV to the COUNT value of the original PDCP SDU, which has a COUNT value greater than RX_DELIV, is not included in the missing PDU indicated by the missing control PDU, and has not been delivered to the higher layer.

[0175] (Aspects 1-5) Upon receiving a missing control PDU, the first PDCP receiving unit 912 can consider a data unit with a value less than the COUNT value (i.e., FMC) of the first data unit in the missing data unit indicated by the missing control PDU as either a normally received data unit or a data unit that has been discarded. Then, the first PDCP receiving unit 912 can update at least one of RX_NEXT and RX_DELIV.

[0176] Specifically, upon receiving a missing control PDU, the first PDCP receiving unit 912 can regard the COUNT value of the data unit having a value less than the COUNT value (e.g., FMC) of the first data unit in the missing data unit indicated by the missing control PDU as RCVD_COUNT. Then, the first PDCP receiving unit 912 can perform the processing described in (a1) to (a6) above.

[0177] In another example, if at least one of RX_NEXT and RX_DELIV is less than the COUNT value (e.g., FMC) of the first data unit in the missing data unit indicated by the missing data control PDU, the first PDCP receiving unit 912 can update the respective values ​​of RX_NEXT and RX_DELIV. For example, the first PDCP receiving unit 912 can update RX_NEXT to the COUNT value of the last missing data unit in the missing data unit indicated by the missing data control PDU plus 1, wherein the last missing data unit has a COUNT value greater than RX_NEXT.

[0178] Furthermore, the first PDCP receiving unit 912 can update RX_DELIV to the COUNT value of the original data unit that has a COUNT value greater than RX_DELIV and / or FMC, and has not been distributed to higher layers and is not included in the missing data unit indicated by the missing control PDU.

[0179] Based on the above configuration, RX_NEXT and RX_DELIV are not updated to the values ​​corresponding to data units that are indicated as missing by the missing control PDU. For example... Figure 34 As shown, RX_NEXT and RX_DELIV are updated to the next value corresponding to the data unit that is indicated as missing by the missing control PDU.

[0180] Furthermore, in aspects 1-5, when outOfOrderDelivery is configured, the first PDCP receiving unit 912 can ignore the missing control PDU.

[0181] (Aspects 1-6) In the event of receiving a missing control PDU, the first PDCP receiving unit 912 may perform at least one of the following processes (e1) to (e5).

[0182] (e1) When the COUNT values ​​for all missing PDUs are outside the reordering window, or when outOfOrderDelivery is configured: The first PDCP receiver 912 ignores missing control PDUs.

[0183] (e2) In the case where RX_NEXT is within the missing PDU indicated by the missing control PDU, or RX_NEXT < the COUNT value of the initial PDCP SDU indicated by the missing control PDU: The first PDCP receiving unit 912 updates RX_NEXT to the value of the last missing PDCP SDU in the missing PDU indicated by the missing control PDU plus 1, wherein the last missing PDCP SDU has a COUNT value greater than RX_NEXT.

[0184] (e3) In the case where RX_DELIV is included in the missing PDU, or RX_DELIV < COUNT value of the original PDCP SDU indicated by the missing control PDU: If any, the first PDCP receiving unit 912, after performing header decompression, delivers all stored PDCP SDUs associated with consecutive COUNT values ​​starting from the COUNT value equal to RX_DELIV, in ascending order of the associated COUNT values. The first PDCP receiving unit 912 updates RX_DELIV to the COUNT value of the first PDCP SDU, wherein the COUNT value is greater than RX_DELIV, greater than the COUNT value of the first PDCP SDU missing indicated by the missing control PDU, has not been delivered to a higher layer, and is not included in the missing PDUs indicated by the missing control PDU.

[0185] (e4) When t-Reordering is running, and RX_DELIV ≥ RX_REORD: The first PDCP receiving unit 912 stops and resets t-Reordering.

[0186] (e5) When t-Reordering is not running (including the condition that t-Reordering is stopped due to the above-mentioned action), and RX_DELIV < RX_NEXT: The first PDCP receiving unit 912 updates RX_REORD to RX_NEXT. The first PDCP receiving unit 912 starts t-Reordering.

[0187] (Aspect 1-7) In the case where a missing control PDU is received, the first PDCP receiving unit 912 may perform Figure 35 the processing shown. For example, the first PDCP receiving unit 912 may perform at least one of the following processes from (f1) to (f5).

[0188] (f1) When the COUNT values of all missing PDUs are outside the reordering window, or outOfOrderDelivery is configured: The first PDCP receiving unit 912 ignores the missing control PDU.

[0189] (f2) When RX_NEXT is within the missing PDUs indicated by the missing control PDU, or RX_NEXT is smaller than the COUNT value of the first missing PDCP SDU indicated by the missing control PDU: The first PDCP receiving unit 912 updates RX_NEXT to a value obtained by adding 1 to the COUNT value of the last missing PDCP SDU, among the missing PDUs indicated by the missing control PDU, wherein the last missing PDCP SDU has a COUNT value greater than RX_NEXT.

[0190] (f3) If RX_DELIV is included in the missing PDUs, or RX_DELIV < the COUNT value of the first missing PDCP SDU indicated by the missing control PDU: If applicable (if any), after performing header decompression, the first PDCP receiving unit 912 delivers all stored PDCP SDUs associated with consecutive COUNT values starting from the COUNT value equal to RX_DELIV, in ascending order of the associated COUNT values. The first PDCP receiving unit 912 updates RX_DELIV to the COUNT value of the first PDCP SDU that has a COUNT value greater than RX_DELIV, has a COUNT value greater than the COUNT value of the first missing PDCP SDU indicated by the missing control PDU, has not been delivered to upper layers, and is not included in the missing PDUs indicated by the missing control PDU.

[0191] (f4) If t-Reordering is running and RX_DELIV ≥ RX_REORD: The first PDCP receiving unit 912 stops and resets t-Reordering.

[0192] (f5) If t-Reordering is not running (including the case where t-Reordering is stopped due to the above operation) and RX_DELIV < RX_NEXT: The first PDCP receiving unit 912 updates RX_REORD to RX_NEXT. The first PDCP receiving unit 912 starts t-Reordering.

[0193] In addition, when a PDCP data PDU is received from a lower layer, the first PDCP receiving unit 912 may perform Figure 36 the processing shown. That is, the above processing of (a4) may be replaced with the above processing of (a4-alt).

[0194] 1.8. Triggering processing of missing control PDUs Non-patent documents 1 and 2 do not describe the conditions for triggering the missing control PDU. The first or second discard timer mentioned above will not stop in existing technical specifications (e.g., including non-patent documents 1 and 2). The discarding process is performed on all data units, and the missing control PDU has the potential to be triggered each time the discarding process is performed. On the other hand, regarding normally transmitted data units, the first PDCP transmitting unit 911 of the terminal device 10 does not need to notify the second PDCP receiving unit 922 of the base station device 20 of the missing control PDU. Therefore, the PDCP layer cannot know whether the data unit has been successfully transmitted.

[0195] In order to solve the above problems, the first PDCP transmitting unit 911 may trigger or transmit a missing control PDU based on predetermined conditions. For example, the first PDCP transmitting unit 911 may transmit a missing control PDU to the second PDCP receiving unit 922 based on predetermined conditions. The details of aspects 2-1 and 2-2 regarding the triggering process of the missing control PDU will be explained below.

[0196] (Aspect 2-1) When a data unit (e.g., a PDCP SDU) is discarded, and the corresponding data unit (e.g., a PDCP PDU) has already been sent to a lower layer, the first PDCP transmitting unit 911 may trigger or transmit a missing control PDU. This data unit may be a data unit that has not yet been indicated as missing by the missing control PDU. That is, when a data unit (e.g., a PDCP SDU) that has not yet been indicated as missing by the missing control PDU is discarded, and the corresponding data unit (e.g., a PDCP PDU) has already been sent to a lower layer, the first PDCP transmitting unit 911 may trigger or transmit a missing control PDU.

[0197] The base station device 20 can send an RRC message to the terminal device 10, which includes parameters associated with the missing control PDU. For example, the parameters associated with the missing control PDU can be included in PDCP-ConfigIE, which is an example of an information element (IE) for RRC.

[0198] Parameters associated with a missing control PDU may include information that explicitly or implicitly indicates whether a missing control PDU is triggered or sent. Hereinafter, this information is referred to as "first information." First information may indicate "trigger or send missing control PDU" or "do not trigger or send missing control PDU." First information may also be a flag indicating "trigger or send missing control PDU" or "do not trigger or send missing control PDU."

[0199] The parameters associated with the missing control PDU may include information indicating whether the first PDCP transmitter 911 should perform a PDU set-based discard process. Hereinafter, this information is referred to as "second information." The second information may be the aforementioned pdu-SetDiscard.

[0200] For example, when the base station device 20 receives first information indicating the triggering or transmission of a missing control PDU and / or second information indicating the performance of a PDU-based discarding process, if a PDCP SDU is discarded and the corresponding PDCP PDU has already been transmitted to a lower layer, the first PDCP transmitting unit 911 may trigger or transmit the missing control PDU. This PDCP SDU may be a PDU whose corresponding PDCP PDU has not yet been indicated as missing by the missing control PDU.

[0201] (Aspect 2-2) The first PDCP transmitter 911 can trigger or transmit a missing control PDU based on an instruction from a lower layer (e.g., the RLC layer).

[0202] The first PDCP transmitting unit 911 can send a notification to the lower layer indicating that a data unit has been discarded through a discard process. The lower-layer entity can, based on the aforementioned notification from the higher layer (i.e., the PDCP layer), instruct the higher layer to trigger or send a missing control PDU.

[0203] For example, when the base station device 20 receives first information indicating to trigger or send a missing control PDU and / or second information indicating to perform a PDU set-based discarding process, the first PDCP sending unit 911 can trigger or send a missing control PDU based on the instruction from the lower layer.

[0204] 1.9. Configuration processing for missing control PDU fields When a missing control PDU is triggered, the first PDCP transmitting unit 911 can compile the missing control PDU as follows. The following section explains aspect 3 of the fields used to configure the missing control PDU.

[0205] (Aspect 3) The first PDCP transmitting unit 911 can configure the FMC field to the COUNT value of the initial data unit (e.g., PDCP SDU) that was discarded or missing. In this case, the first PDCP transmitting unit 911 can determine the size or length (i.e., bit length) of the bitmap field as follows.

[0206] The first PDCP transmitting unit 911 can determine the size of the bitmap field based on a count from the COUNT value of the initial PDCP SDU that was dropped or missing to the COUNT value of the last PDCP SDU that was dropped or missing. For example, as Figure 37 As shown, when the COUNT value of the initial PDCP SDU that was discarded or missing is 2, and the COUNT value of the last PDCP SDU that was discarded or missing is 4, the first PDCP transmitting unit 911 can determine the size of the bitmap field based on a count of 2 to 4 (=3). Alternatively, this count may not include the COUNT value of the initial PDCP SDU that was discarded or missing. That is, the first PDCP transmitting unit 911 can determine the size of the bitmap field based on a count of 3 to 4 (=2).

[0207] In another example, the first PDCP transmitter 911 can determine the size of the bitmap field based on a count from the COUNT value of the initial PDCP SDU that was discarded or missing to TX_NEXT. For example... Figure 37 As shown, the first PDCP transmitting unit 911 can determine the size of the bitmap field based on a count from the COUNT value (=2) of the initial PDCP SDU that was discarded or missing to TX_NEXT (=4). Alternatively, this count may not include the COUNT value of the initial PDCP SDU that was discarded or missing. That is, the first PDCP transmitting unit 911 can determine the size of the bitmap field based on a count from the next value (=3) of the COUNT value of the initial PDCP SDU that was discarded or missing to TX_NEXT (=3).

[0208] In another example, the first PDCP transmitter 911 can configure the FMC field to a value based on TX_NEXT (e.g., TX_NEXT). In this case, as... Figure 37 As shown, the first PDCP transmitting unit 911 can determine the size of the bitmap field based on a count from the COUNT value (=2) of the initial PDCP SDU that was discarded or missing to TX_NEXT (=4). Alternatively, this count may exclude TX_NEXT. That is, the first PDCP transmitting unit 911 can determine the size of the bitmap field based on a count from the COUNT value (=2) of the initial PDCP SDU that was discarded or missing to TX_NEXT-1 (=3).

[0209] In addition, the COUNT value of the initial PDCP SDU that was discarded or missing can be the COUNT value of the initial PDCP SDU that triggered the missing control PDU.

[0210] The COUNT value of the initial PDCP SDU that is discarded or missing can be the COUNT value of the PDCP SDU indicated from a lower layer. That is, the first PDCP transmitting unit 911 can configure the FMC field included in the missing control PDU to be the COUNT value of the PDCP SDU indicated from a lower layer (e.g., the RLC layer). In addition, the first PDCP transmitting unit 911 can determine the size of the bitmap field included in the missing control PDU based on the COUNT value of the PDCP SDU indicated from a lower layer.

[0211] The initial PDCP SDU that is discarded or missing may be a PDCP SDU whose information has not yet been reported as missing or discarded by a missing control PDU. That is, the first PDCP sending unit 911 may configure the FMC field included in the missing control PDU to be the COUNT value of the initial PDCP SDU that has not yet been reported as missing by a previously triggered or sent missing control PDU. Additionally, the first PDCP sending unit 911 may determine the size of the bitmap field included in the missing control PDU based on the COUNT value of the initial PDCP SDU that has not yet been reported as missing by a previously triggered or sent missing control PDU.

[0212] The process of determining the size of the bitmap field based on the above count can be performed based on at least one of the following processes (g1) and conditions (g2). For example, the first PDCP transmitting unit 911 can determine the size of the bitmap field based on either the earlier arrival of the process (g1) or the condition (g2). (g1) The process of rounding the count up to a predetermined multiple (e.g., a multiple of 8). For example, the size of a bitmap field can be rounded up to a multiple of 8 after the count. Figure 37 In the example, the multiples of 8 after counting are 8. Therefore, the size of the bitmap field can be determined to be 8. (g2) The PDCP controls the PDU size to be equal to the predetermined maximum size. For example, this condition could be that the PDCP controls the PDU size to be equal to 9000 bytes.

[0213] Based on the above configuration, it is possible to appropriately trigger or send a missing control PDU. Furthermore, based on the above configuration, it is possible to appropriately configure more than one field included in the missing control PDU.

[0214] 1.10. Combinations and variations of aspects 1, 2, and 3 above. The aforementioned aspects 1 (i.e., aspects 1-1 to 1-7), 2 (i.e., aspects 2-1 to 2-2), and 3 can be combined. That is, at least a portion of aspect 1, at least a portion of aspect 2, and at least a portion of aspect 3 can be combined, provided they do not contradict each other. Furthermore, although aspects 1 (i.e., aspects 1-1 to 1-7) are described as processing of the first PDCP receiving unit 912, aspect 1 can also be applied to the second PDCP receiving unit 922. Although aspects 2 (i.e., aspects 2-1 to 2-2) and 3 are described as processing of the first PDCP transmitting unit 911, aspects 2 and 3 can also be applied to the processing of the second PDCP transmitting unit 921.

[0215] 2. Variant Examples It is understood that although this disclosure is described according to the above embodiments, this disclosure is not limited to these embodiments or structures. This disclosure also includes various variations or equivalent modifications. Other combinations including one or more elements included in the above embodiments also fall within the scope or concept of this disclosure.

[0216] The words, phrases, etc., used in the above embodiments are merely examples and can be replaced with substantially the same or similar expressions. In particular, since the technologies involved in the above embodiments are related to technical specifications, the expressions in the above embodiments can be replaced with substantially the same or similar expressions in technical specifications (e.g., the technical specifications cited in this application specification).

[0217] In the above embodiments, the information sent and received may include the same or different messages or elements already described in the technical specifications, or it may include newly defined messages or elements. In the above embodiments, the information sent and received may use different layers and / or different channels than those described in the above embodiments.

[0218] The manner and / or function provided by the apparatus described in the above embodiments can be provided by software recorded in a physical memory device and a computer executing the software, by software alone, by hardware alone, or by a combination thereof. For example, in the case where any of the above-described apparatuses is provided by electronic circuitry as hardware, it can be provided by digital circuitry or analog circuitry including multiple logic circuits.

[0219] The apparatus described in the above embodiments executes a program stored in a non-transitory tangible storage medium. By executing this program, the method corresponding to the program is performed.

[0220] 3. Postscript The above-described embodiments and variations may be described in whole or in part as in the following notes, but are not limited to the content of the following notes. Hereinafter, the relationship of a note belonging to a note belonging to a note belonging to a note belonging to a note belonging to a note is expressed. All the subordinate relationships of notes expressed below are included in the above-described embodiments.

[0221] (Note A1) A terminal device (10) includes a transmitting unit (911) and a receiving unit (912) in the Packet Data Convergence Protocol (PDCP) layer. The aforementioned transmitting unit is configured as follows: Perform data unit discarding processing. Based on predetermined conditions, trigger reports related to missing data units.

[0222] (Note A2) According to the terminal device described in Appendix A1, the aforementioned transmitting unit is configured to, If a data unit is discarded through the aforementioned discarding process, and the data unit corresponding to the discarded data unit is sent to a lower layer, This triggered the aforementioned report.

[0223] (Note A3) According to the terminal device described in Appendix A2, the aforementioned transmitting unit is configured to, In the event that at least one of the following is received from the base station device (20): a first message instructing the triggering or sending of the aforementioned report and a second message instructing the execution of the aforementioned discarding process based on the Protocol Data Unit Set, In the case where a data unit is discarded through the aforementioned discarding process, and the data unit corresponding to the aforementioned data unit is sent to the aforementioned lower layer, This triggered the aforementioned report.

[0224] (Note A4) According to the terminal device described in Appendix A1, the aforementioned transmitting unit is configured to trigger the aforementioned report based on an instruction from a lower layer.

[0225] (Note A5) According to the terminal device described in Appendix A4, the aforementioned transmitting unit is configured to, The notification to the aforementioned lower layer that the data unit has been discarded through the aforementioned discarding process is sent. The aforementioned report is triggered based on the aforementioned instructions sent from the aforementioned lower level in accordance with the aforementioned notification.

[0226] (Note A6) According to the terminal device described in appendices A4 or A5, the aforementioned transmitting unit is configured to, In the event that at least one of the following is received from the base station device (20): a first message instructing the triggering or sending of the aforementioned report and a second message instructing the execution of the aforementioned discarding process based on the Protocol Data Unit Set, The aforementioned instructions were used to trigger the aforementioned report.

[0227] (Note A7) According to any one of the appendices A1 to A6, the aforementioned report includes a field indicating whether the corresponding data unit is missing. The aforementioned sending unit is configured to determine the size of the aforementioned field based on the count (COUNT) value of the first missing data unit and the COUNT value of the last missing data unit.

[0228] (Note A8) According to the terminal device described in Appendix A7, the aforementioned transmitting unit is configured to determine the size of the aforementioned field based on at least one of the following: The process of rounding up the value obtained based on the COUNT values ​​of the first and last missing data units to a predetermined multiple; and This includes the condition that the PDCP control protocol data unit (PDU) mentioned in the aforementioned report is equal to the predetermined maximum size.

[0229] (Note A9) According to the terminal device described in Notes A7 or A8, the COUNT value of the aforementioned missing initial data unit is the COUNT value of the initial data unit that triggered the aforementioned report.

[0230] (Note A10) According to the terminal device described in Appendix A7 or A8, the COUNT value of the aforementioned missing initial data unit is the COUNT value of the data unit indicated from the lower layer.

[0231] (Note A11) According to any one of the appendices A1 to A6, the aforementioned report includes a field indicating whether the corresponding data unit is missing. The sending unit is configured to determine the size of the aforementioned field based on the COUNT value of the missing initial data unit and the COUNT value of the next data unit sent to the lower layer.

[0232] (Note A12) According to the terminal device described in Appendix A11, the aforementioned transmitting unit is configured to determine the size of the aforementioned field based on at least one of the following: The process of rounding up the value obtained based on the COUNT value of the missing initial data unit and the COUNT value of the next data unit sent to the lower level to a predetermined multiple; and This includes the condition that the PDCP control protocol data unit (PDU) mentioned in the aforementioned report is equal to the predetermined maximum size.

[0233] (Note A13) According to the terminal device described in appendix A11 or A12, the COUNT value of the aforementioned missing initial data unit is the COUNT value of the initial data unit that triggered the aforementioned report.

[0234] (Note A14) According to the terminal device described in Appendix A11 or A12, the COUNT value of the aforementioned missing initial data unit is the COUNT value of the data unit indicated from the lower layer.

[0235] (Note A15) A method for a terminal device, comprising a transmitting unit (911) and a receiving unit (912) in a Packet Data Convergence Protocol (PDCP) layer, the method comprising: The aforementioned transmitting unit performs data unit discarding processing; and The aforementioned sending unit triggers a report related to missing data units based on predetermined conditions.

[0236] (Note A16) A program that causes the processor (101) in the terminal device (10) to execute: Implement the transmitting unit (911) and receiving unit (912) in the Packet Data Convergence Protocol (PDCP) layer. The aforementioned program causes the aforementioned processor to execute: The aforementioned transmitting unit performs data unit discarding processing; and The aforementioned sending unit triggers a report related to missing data units based on predetermined conditions.

[0237] (Note A17) A non-transient tangible recording medium containing a program that causes the processor (101) in the terminal device (10) to execute: Implement the transmitting unit (911) and receiving unit (912) in the Packet Data Convergence Protocol (PDCP) layer. The aforementioned program causes the aforementioned processor to execute: The aforementioned transmitting unit performs data unit discarding processing; and The aforementioned sending unit triggers a report related to missing data units based on predetermined conditions.

[0238] (Note B1) A terminal device (10) includes: The receiving unit (122) receives a Radio Resource Control (RRC) message from the base station device (20). The RRC message includes information for configuring whether to send Packet Data Convergence Protocol (PDCP) control Protocol Data Units (PDUs). The PDCP control PDU is used to report gaps in PDCP sequence numbers (SNs) and includes a field indicating whether a PDCP Service Data Unit (SDU) has been discarded. The control unit (110) includes a PDCP entity (910). In the event that the aforementioned PDCP control PDU is configured to send the aforementioned gap for reporting the aforementioned PDCP SN based on the aforementioned information, and at least one PDCP SDU is discarded, the aforementioned PDCP entity triggers the aforementioned PDCP control PDU for reporting the aforementioned gap of the aforementioned PDCP SN. When the aforementioned PDCP control PDU used to report the aforementioned gap of the aforementioned PDCP SN is triggered, the aforementioned PDCP entity compiles the aforementioned PDCP control PDU used to report the aforementioned gap of the aforementioned PDCP SN. In the aforementioned compilation process, the aforementioned PDCP entity determines the bit length of the aforementioned field indicating whether the aforementioned PDCP SDU has been discarded based on the number of counts from the count value corresponding to the first discarded PDCP SDU to the count value corresponding to the last discarded PDCP SDU.

[0239] (Note B2) According to the terminal device described in Appendix B1, the PDCP entity discards the PDCP SDU if at least one of the following conditions is met: the expiration of the discard timer for the aforementioned PDCP SDU or the confirmation of normal delivery of the aforementioned PDCP SDU based on the PDCP status report.

[0240] (Note B3) According to the terminal device described in Appendix B1 or B2, the aforementioned PDCP control PDU for reporting the aforementioned gap of the aforementioned PDCP SN includes at least one of the following: A field indicating the minimum count value corresponding to the discarded PDCP SDU; The field indicating the corresponding PDCP PDU is either a PDCP data PDU or a field of the aforementioned PDCP control PDU; and A field indicating the type of control information included in the aforementioned PDCP control PDU.

[0241] (Note B4) According to any one of the appendices B1 to B3, the aforementioned field indicating whether the PDCP SDU has been discarded is a bitmap field that indicates whether the corresponding PDCP SDU has been discarded based on the value of the bit.

[0242] (Note B5) According to any one of the appendices B1 to B4, at least one of the count value corresponding to the aforementioned initial PDCP SDU and the count value corresponding to the aforementioned final PDCP SDU is configured based on HFN (Hyper Frame Number) and the aforementioned PDCP SN.

[0243] (Note B6) The terminal device according to any one of appendices B1 to B5 further includes a transmitting unit (121) that transmits the aforementioned PDCP control PDU for reporting the aforementioned gap of the aforementioned PDCP SN to the aforementioned base station device.

[0244] (Note B7) One method is a method of the terminal device (10), the aforementioned method comprising: The radio resource control (RRC) message is received from the base station device (20). The RRC message includes information for configuring whether to send a Packet Data Convergence Protocol (PDCP) control protocol data unit (PDU). The PDCP control PDU is used to report the gap of PDCP sequence number (SN) and includes a field indicating whether a PDCP service data unit (SDU) has been dropped. In the case where the aforementioned PDCP control PDU is configured to send the aforementioned gap for reporting the aforementioned PDCP SN based on the aforementioned information, and at least one PDCP SDU is discarded, the aforementioned PDCP control PDU for reporting the aforementioned gap for reporting the aforementioned PDCP SN is triggered by the PDCP entity; When the aforementioned PDCP control PDU used to report the aforementioned gap of the aforementioned PDCP SN is triggered, the aforementioned PDCP control PDU used to report the aforementioned gap of the aforementioned PDCP SN is compiled by the aforementioned PDCP entity; and In the aforementioned compilation process, the bit length of the aforementioned field indicating whether the aforementioned PDCP SDU has been discarded is determined by the aforementioned PDCP entity based on the number of counts from the count value corresponding to the first discarded PDCP SDU to the count value corresponding to the last discarded PDCP SDU.

[0245] (Note B8) The method described according to Appendix B7 further includes: discarding the aforementioned PDCP SDU by the aforementioned PDCP entity when at least one of the following conditions is met: the expiration of the discard timer for the aforementioned PDCP SDU and the confirmation of normal delivery of the aforementioned PDCP SDU based on the PDCP status report.

[0246] (Note B9) According to the method described in Appendix B7 or B8, the aforementioned PDCP control PDU for reporting the aforementioned gap of the aforementioned PDCP SN includes at least one of the following: A field indicating the minimum count value corresponding to the discarded PDCP SDU; The field indicating the corresponding PDCP PDU is either a PDCP data PDU or a field of the aforementioned PDCP control PDU; and A field indicating the type of control information included in the aforementioned PDCP control PDU.

[0247] (Note B10) According to any one of the appendices B7 to B9, the aforementioned field indicating whether the PDCP SDU has been discarded is a bitmap field that indicates whether the corresponding PDCP SDU has been discarded based on the value of the bit.

[0248] (Note B11) According to any one of the appendices B7 to B10, at least one of the count value corresponding to the aforementioned initial PDCP SDU and the count value corresponding to the aforementioned final PDCP SDU is configured based on the HFN (Hyper Frame Number) and the aforementioned PDCP SN.

[0249] (Note B12) The method according to any one of appendices B7 to B11 further includes: sending the aforementioned PDCP control PDU to the aforementioned base station device for reporting the aforementioned gap of the aforementioned PDCP SN.

[0250] (Note B13) A base station device (20) includes: The transmitting unit (221) sends a Radio Resource Control (RRC) message to the terminal device (10). The RRC message includes information for configuring whether to send Packet Data Convergence Protocol (PDCP) control Protocol Data Units (PDUs). The PDCP control PDU is used to report gaps in PDCP sequence numbers (SNs) and includes a field indicating whether a PDCP Service Data Unit (SDU) has been discarded. The receiving unit (222) receives the aforementioned PDCP control PDU from the aforementioned terminal device. When the aforementioned terminal device is configured to send the aforementioned PDCP control PDU for reporting the aforementioned gap of the aforementioned PDCP SN based on the aforementioned information, and at least one PDCP SDU is discarded in the aforementioned terminal device, the aforementioned PDCP control PDU for reporting the aforementioned gap of the aforementioned PDCP SN is triggered in the aforementioned terminal device. The aforementioned receiving unit receives the aforementioned PDCP control PDU from the aforementioned terminal device. The aforementioned PDCP control PDU includes the aforementioned field indicating whether the aforementioned PDCP SDU has been discarded. The aforementioned field has a bit length determined based on the number of counts from the count value corresponding to the first discarded PDCP SDU to the count value corresponding to the last discarded PDCP SDU.

[0251] (Note B14) According to the base station apparatus described in Appendix B13, the aforementioned PDCP control PDU for reporting the aforementioned gap of the aforementioned PDCP SN includes at least one of the following: A field indicating the minimum count value corresponding to the discarded PDCP SDU; The field indicating the corresponding PDCP PDU is either a PDCP data PDU or a field of the aforementioned PDCP control PDU; and A field indicating the type of control information included in the aforementioned PDCP control PDU.

[0252] (Note B15) According to the base station apparatus described in Appendix B13 or B14, the aforementioned field indicating whether the PDCP SDU has been discarded is a bitmap field that indicates whether the corresponding PDCP SDU has been discarded based on the value of the bits.

[0253] (Note B16) According to any one of the appendices B13 to B15, at least one of the count value corresponding to the aforementioned initial PDCP SDU and the count value corresponding to the aforementioned final PDCP SDU is configured based on the HFN (Hyper Frame Number) and the aforementioned PDCP SN.

[0254] Furthermore, the disclosures in the aforementioned prior art documents and references are incorporated herein by reference.

Claims

1. A terminal device (10), comprising: The receiving unit (122) receives a Radio Resource Control (RRC) message from the base station device (20). The RRC message includes information for configuring whether to send Packet Data Convergence Protocol (PDCP) Control Protocol Data Units (PDUs). The PDCP Control PDUs are used to report PDCP Sequence Number (SN) gaps and include a field indicating whether a PDCP Service Data Unit (SDU) has been discarded. The control unit (110) includes a PDCP entity (910). When the PDCP entity is configured to send the PDCP control PDU for reporting the gap in the PDCP SN based on the information, and at least one PDCP SDU is discarded, the PDCP entity triggers the PDCP control PDU for reporting the gap in the PDCP SN. When the PDCP control PDU for reporting the gap of the PDCP SN is triggered, the PDCP entity compiles the PDCP control PDU for reporting the gap of the PDCP SN. In the compilation process, the PDCP entity determines the bit length of the field indicating whether the PDCP SDU has been discarded based on the count value from the count value corresponding to the first discarded PDCP SDU to the count value corresponding to the last discarded PDCP SDU.

2. The terminal device according to claim 1, wherein the PDCP entity discards the PDCP SDU if at least one of the following conditions is met: the expiration of the discard timer for the PDCP SDU and confirmation of normal delivery of the PDCP SDU based on a PDCP status report.

3. The terminal device according to claim 1 or 2, The PDCP control PDU used to report the gap of the PDCP SN includes at least one of the following: A field indicating the minimum count value corresponding to the discarded PDCP SDU; The field indicating the corresponding PDCP PDU is either a PDCP data PDU or a PDCP control PDU; and The field indicates the type of control information included in the PDCP control PDU.

4. The terminal device according to any one of claims 1 to 3, wherein the field indicating whether the PDCP SDU has been discarded is a bitmap field that indicates whether the corresponding PDCP SDU has been discarded based on the value of the bits.

5. The terminal device according to any one of claims 1 to 4, wherein at least one of the count value corresponding to the initial PDCP SDU and the count value corresponding to the final PDCP SDU is configured based on the superframe number (HFN) and the PDCP SN.

6. The terminal device according to any one of claims 1 to 5 further includes a transmitting unit (121) for transmitting the PDCP control PDU for reporting the gap of the PDCP SN to the base station device.

7. A method, a method of a terminal device (10), the method comprising: The base station device (20) receives a Radio Resource Control (RRC) message, the RRC message including information for configuring whether to send a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU), the PDCP Control PDU being used to report gaps in PDCP Sequence Numbers (SNs) and including a field indicating whether a PDCP Service Data Unit (SDU) has been dropped; In the event that the PDCP control PDU for reporting the gap of the PDCP SN is sent based on the information, and at least one PDCP SDU is discarded, the PDCP control PDU for reporting the gap of the PDCP SN is triggered by the PDCP entity. When the PDCP control PDU for reporting the gap of the PDCP SN is triggered, the PDCP control PDU for reporting the gap of the PDCP SN is compiled by the PDCP entity; as well as In the compilation process, the PDCP entity determines the bit length of the field indicating whether the PDCP SDU has been discarded, based on the count value from the count value corresponding to the first discarded PDCP SDU to the count value corresponding to the last discarded PDCP SDU.

8. The method according to claim 7, further comprising: The PDCP SDU is discarded by the PDCP entity if at least one of the following conditions is met: the expiration of the discard timer for the PDCP SDU or the confirmation of normal delivery of the PDCP SDU based on the PDCP status report.

9. The method according to claim 7 or 8, The PDCP control PDU used to report the gap of the PDCP SN includes at least one of the following: A field indicating the minimum count value corresponding to the discarded PDCP SDU; The field indicating the corresponding PDCP PDU is either a PDCP data PDU or a PDCP control PDU; and The field indicates the type of control information included in the PDCP control PDU.

10. The method according to any one of claims 7 to 9, wherein the field indicating whether the PDCP SDU has been discarded is a bitmap field that indicates whether the corresponding PDCP SDU has been discarded based on the value of the bits.

11. The method according to any one of claims 7 to 10, wherein at least one of the count value corresponding to the initial PDCP SDU and the count value corresponding to the final PDCP SDU is configured based on the superframe number (HFN) and the PDCP SN.

12. The method according to any one of claims 7 to 11, further comprising: The PDCP control PDU is sent to the base station device to report the gap of the PDCP SN.

13. A base station apparatus (20), comprising: The transmitting unit (221) sends a Radio Resource Control (RRC) message to the terminal device (10). The RRC message includes information for configuring whether to send Packet Data Convergence Protocol (PDCP) Control Protocol Data Units (PDUs). The PDCP Control PDU is used to report gaps in PDCP Sequence Numbers (SNs) and includes a field indicating whether a PDCP Service Data Unit (SDU) has been discarded. The receiving unit (222) receives the PDCP control PDU from the terminal device. When the terminal device is configured to send a PDCP control PDU for reporting the gap of the PDCP SN based on the information, and at least one PDCP SDU is discarded in the terminal device, the PDCP control PDU for reporting the gap of the PDCP SN is triggered in the terminal device. The receiving unit receives the PDCP control PDU from the terminal device. The PDCP control PDU includes a field indicating whether the PDCP SDU has been discarded. The field has a bit length determined based on the number of counts from the first discarded PDCP SDU to the last discarded PDCP SDU.

14. The base station apparatus according to claim 13, The PDCP control PDU used to report the gap of the PDCP SN includes at least one of the following: A field indicating the minimum count value corresponding to the discarded PDCP SDU; The field indicating the corresponding PDCP PDU is either a PDCP data PDU or a PDCP control PDU; and The field indicates the type of control information included in the PDCP control PDU.

15. The base station apparatus according to claim 13 or 14, wherein the field indicating whether the PDCP SDU has been discarded is a bitmap field that indicates whether the corresponding PDCP SDU has been discarded based on the value of the bits.

16. The base station apparatus according to any one of claims 13 to 15, wherein at least one of the count value corresponding to the initial PDCP SDU and the count value corresponding to the final PDCP SDU is configured based on the superframe number (HFN) and the PDCPSN.

Images