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

Abstract

A terminal device (10) according to the present invention is a packet data convergence protocol (PDCP) control protocol data unit (PDU) for reporting a gap in a PDCP sequence number (SN), wherein: a radio resource control (RRC) message including information for setting whether or not to transmit the PDCP control PDU which includes a field indicating whether or not a PDCP service data unit (SDU) has been discarded is received from a base station device (20); and the bit length of the field is determined on the basis of the number from the count value corresponding to the first discarded PDCP SDU to the count value corresponding to the last discarded PDCP SDU.

Description

Terminal device, terminal device method, and base station device CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The present disclosure relates to a terminal device, a terminal device method, and a base station device.

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

[0004] Non-Patent Documents 1 and 2 describe technical specifications defined by the Third Generation Partnership Project (3GPP (registered trademark)), and include technical specifications for supporting XR.

[0005] 3GPP TS 38.323 V18.0.0 (2023-12)3GPP TS 38.331 V18.0.0 (2023-12)3GPP TS 26.522 V0.1.0 (2023-05)

[0006] Non-Patent Document 1 describes a transmission process in which a Packet Data Convergence Protocol (PDCP) layer transmits data received from a lower layer to a higher layer. However, in XR services, data discarding may occur frequently in the PDCP layer. Taking this into consideration, it has been proposed that a transmitting entity in the PDCP layer transmits a report regarding data lost due to the discarding process to a receiving entity. However, existing technical specifications, including Non-Patent Document 1, do not describe the conditions under which the above-mentioned report should be triggered or transmitted. The inventors have discovered a problem in that the above-mentioned report may not be properly triggered or transmitted. Note that the above-mentioned problem also occurs in ordinary terminal devices and base station devices other than those implementing XR.

[0007] The present disclosure provides a technique that can appropriately trigger or send a report on data lost due to discard processing at the PDCP layer.

[0008] A terminal device in the present disclosure includes: a receiver that receives, from a base station device, a Radio Resource Control (RRC) message including information for setting whether to transmit a PDCP control Protocol Data Unit (PDU) for reporting a gap in a Packet Data Convergence Protocol (PDCP) sequence number (SN), the PDCP control PDU including a field indicating whether a PDCP service data unit (SDU) has been discarded; and a controller that includes a PDCP entity. The PDCP entity is configured to transmit the PDCP control PDU for reporting the gap in the PDCP SN based on the information, and triggers the PDCP control PDU for reporting the gap in the PDCP SN when at least one PDCP SDU is discarded. The PDCP entity compiles the PDCP control PDU for reporting the gap in PDCP SN when the PDCP control PDU for reporting the gap in PDCP SN is triggered, and in the compilation process, the PDCP entity determines a bit length of the field indicating whether the PDCP SDU has been discarded based on the number from a count value corresponding to the first discarded PDCP SDU to a count value corresponding to the last discarded PDCP SDU.

[0009] Furthermore, the method of the terminal device in the present disclosure includes receiving, from a base station device, a Radio Resource Control (RRC) message including a PDCP control Protocol Data Unit (PDU) for reporting a gap in a Packet Data Convergence Protocol (PDCP) Sequence Number (SN), the PDCP control PDU including a field indicating whether a PDCP Service Data Unit (SDU) has been discarded; being configured to transmit the PDCP control PDU for reporting the gap in the PDCP SN based on the information, and when at least one PDCP SDU is discarded, triggering the PDCP control PDU for reporting the gap in the PDCP SN by a PDCP entity; and when the PDCP control PDU for reporting the gap in the PDCP SN has been triggered, compiling, by the PDCP entity, the PDCP control PDU for reporting the gap in SN; and determining, in the compiling process, by the PDCP entity, a bit length of the field indicating whether the PDCP SDU has been discarded based on a count value from a first discarded PDCP SDU to a last discarded PDCP SDU.

[0010] Furthermore, the base station apparatus in the present disclosure includes: a transmitter configured to transmit, to a terminal device, a Radio Resource Control (RRC) message including a PDCP control Protocol Data Unit (PDU) for reporting a gap in a Packet Data Convergence Protocol (PDCP) Sequence Number (SN), the PDCP control PDU including a field indicating whether a PDCP Service Data Unit (SDU) has been discarded; and a receiver configured to receive the PDCP control PDU from the terminal device. The terminal device is configured to transmit the PDCP control PDU for reporting the gap in the PDCP SN based on the information, and when at least one PDCP SDU is discarded in the terminal device, the PDCP control PDU for reporting the gap in the PDCP SN is triggered in the terminal device. The receiving unit receives from the terminal device the PDCP control PDU, which includes the field indicating whether the PDCP SDU has been discarded, and which has a bit length determined based on the number of count values ​​from a count value corresponding to a first discarded PDCP SDU to a count value corresponding to a last discarded PDCP SDU.

[0011] According to the above configuration, it is possible to appropriately trigger or transmit a report on data lost due to a discard process in the PDCP layer. Note that the above configuration may achieve other effects instead of or in addition to the above effect.

[0012] The above and other objects, features, and advantages of the present disclosure will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which Fig. 1 illustrates a communication system S, Fig. 2 illustrates a U-plane protocol stack, Fig. 3 illustrates a C-plane protocol stack, Fig. 4 illustrates a block diagram of a schematic hardware configuration of a terminal device 10, Fig. 5 illustrates a block diagram of a schematic functional configuration of the terminal device 10, Fig. 6 illustrates a block diagram of a base station device 20, Fig. 7 illustrates a schematic functional configuration of the base station device 20, Fig. 8 illustrates a radio frame configuration, Fig. 9 illustrates a block diagram of a schematic functional configuration of the PDCP layer of the terminal device 10 and the PDCP layer of the base station device 20, Fig. 10 illustrates an example format of a PDCP PDU (Protocol Data Unit), Fig. 11 illustrates an example format of a PDCP PDU, and Fig. 12 illustrates a PDCP PDU. 13 is a diagram illustrating an example of a format of a PDCP control PDU for PDCP status reporting. FIG. 14 is a diagram illustrating processing by a first PDCP receiver 912 of the terminal apparatus 10. FIG. 15 is a diagram illustrating processing by the first PDCP receiver 912 of the terminal apparatus 10. FIG. 16 is a diagram illustrating processing by the first PDCP receiver 912 of the terminal apparatus 10. FIG. 17 is a diagram illustrating processing by the first PDCP receiver 912 of the terminal apparatus 10. FIG. 18 is a diagram illustrating processing by the first PDCP receiver 912 of the terminal apparatus 10. FIG. 19 is a diagram illustrating processing by the first PDCP receiver 912 of the terminal apparatus 10. FIG. 20 is a diagram illustrating processing by the first PDCP receiver 912 of the terminal apparatus 10. FIG. 21 is a diagram illustrating an example of a format of a PDCP control PDU for PDCP status reporting. 2 shows the configuration of a Discard Activation / Deactivation MAC CE, FIG. 23 is a diagram for explaining an example of a PSI-based discard process, and FIG. 24 shows a Missing Control PDU (Missing Control PDU).26 is a diagram illustrating the processing of the first PDCP receiving unit 912 of the terminal device 10, FIG. 27 is a diagram illustrating the processing of the first PDCP receiving unit 912 of the terminal device 10, FIG. 28 is a diagram illustrating the processing of the first PDCP receiving unit 912 of the terminal device 10, FIG. 29 is a diagram illustrating the processing of the first PDCP receiving unit 912 of the terminal device 10, FIG. 30 is a diagram illustrating the processing of the first PDCP receiving unit 912 of the terminal device 10, and FIG. 31 is a diagram illustrating the processing of the first PDCP receiving unit 912 of the terminal device 10. 32 is a diagram for explaining the processing of the first PDCP receiving unit 912 of the terminal device 10, FIG. 33 is a diagram for explaining the processing of the first PDCP receiving unit 912 of the terminal device 10, FIG. 34 is a diagram for explaining the processing of the first PDCP receiving unit 912 of the terminal device 10, FIG. 35 is an example of the processing of the first PDCP receiving unit 912 of the terminal device 10, FIG. 36 is an example of the processing of the first PDCP receiving unit 912 of the terminal device 10, and FIG. 37 is a diagram for explaining the processing of the first PDCP transmitting unit 911 of the terminal device 10.

[0013] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. In this specification and drawings, elements that can be similarly described will be designated by the same reference numerals, and redundant description may be omitted.

[0014] The embodiments described below are merely examples of configurations that can realize the present disclosure. Each of the following embodiments can be modified or changed as appropriate depending on the configuration of the device to which the present disclosure is applied and various conditions. Not all of the combinations of elements included in each of the following embodiments are necessarily essential for realizing the present disclosure, and some of the elements can be omitted as appropriate. Therefore, the scope of the present disclosure is not limited to the configurations described in each of the following embodiments. As long as there are no mutual contradictions, configurations that combine multiple configurations described in the following embodiments can also be adopted.

[0015] 1. First Embodiment 1.1. Communication System As shown in Fig. 1, a communication system S includes one or more terminal apparatuses (Terminal Apparatus) 10, one or more base station apparatuses (Base Station Apparatus) 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 technical specifications (e.g., 5G, 5G Advanced, 6G, etc.) defined by 3GPP.

[0016] In the communication system S, a user plane where user data is transmitted and received and a control plane where control data is transmitted and received are configured separately. That is, the communication system S supports C / U separation. The user plane is abbreviated as U-plane, and the control plane is abbreviated as C-plane.

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

[0018] The terminal device 10 may be, for example, a mobile phone terminal such as a smartphone, a tablet terminal, a laptop PC, a communication module, a communication card, or an IoT device such as a surveillance camera or a robot. The terminal device 10 may be a vehicle (e.g., a car, a train, etc.) or a device provided therein. The terminal device 10 may be a transport vehicle other than a vehicle (e.g., a ship, an airplane, etc.) or a device provided therein. The terminal device 10 may be a sensor or a device provided therein. Note that the terminal device 10 may be called by other names such as a terminal, a mobile station, a mobile terminal, a mobile device, a mobile unit, a subscriber station, a subscriber terminal, a subscriber device, a subscriber unit, a wireless station, a wireless terminal, a wireless device, a wireless unit, a remote station, a remote terminal, a remote device, or a remote unit. The terminal device 10 may 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] The base station device 20 manages at least one cell. A cell constitutes the smallest unit of a communication area. For example, one cell belongs to one frequency (e.g., carrier frequency) and is composed of one component carrier. The term "cell" can refer to wireless communication resources and can also refer to a communication target of the terminal device 10. The base station device 20 wirelessly communicates with the terminal device 10 located in its own cell in the U-plane and C-plane. In other words, the base station device 20 terminates the U-plane protocol and C-plane protocol for the terminal device 10.

[0020] The base station device 20 communicates with the core network 30 in 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 connects to the AMF in the C-plane and connects to the UPF in the U-plane.

[0021] The base station device 20 may be, for example, a gNB that provides the terminal device 10 with a U-plane and a C-plane conforming to the 3GPP 5G NR technical specifications and connects to the 3GPP 5GC (5G Core Network). The 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 configured by a plurality of unit devices. For example, the base station device 20 may be configured by a central unit (CU), a distributed unit (DU), and a radio unit (RU).

[0023] A radio access network (RAN) is formed by interconnecting multiple base station devices 20. The radio access network formed by the base station devices 20 that are gNBs may be referred to as an NG-RAN. The base station devices 20 that are gNBs may be referred to as NG-RAN nodes.

[0024] The plurality of base station devices 20 are connected to each other via a predetermined interface (for example, an Xn interface). More specifically, for example, the plurality of base station devices 20 are connected to each other via an Xn-U interface in the U-plane and via an Xn-C interface in the C-plane. Note that the plurality of base station devices 20 may also be connected to each other 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 (for example, 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 is connected to the AMF of the core network 30 via an NG-C interface in the C-plane. Note that each base station device 20 may be connected to the core network 30 via another interface with a different function or name.

[0026] The radio protocol architecture between the terminal device 10 and the base station device 20 will be described with reference to Fig. 2. The radio protocol architecture between the terminal device 10 and the base station device 20 and between the terminal device 10 and the core network 30 will be described with reference to Fig. 3.

[0027] As shown in Fig. 2, the U-plane protocol stack includes, from the bottom up, a physical (PHY) layer, a media access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, and a service data adaptation protocol (SDAP) layer. Each of the above layers is terminated at the base station device 20 on the network side. The MAC layer is also referred to as a "medium access control layer."

[0028] As shown in FIG. 3 , the C-plane protocol stack includes, from the bottom up, a physical (PHY) layer, a media access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, a radio resource control (RRC) layer, and a non-access stratum (NAS). The MAC layer is also referred to as a "medium access control layer." The above-mentioned layers, except for the non-access stratum, are terminated at the base station device 20 on the network side. The non-access stratum is terminated at the AMF of the core network 30 on the network side.

[0029] 4, the terminal device 10 has, as hardware elements, a processor 101, a memory 102, an input / output interface 103, a wireless interface 104, and an antenna 105. The above elements provided in the terminal device 10 are connected to each other by an internal bus. Note that the terminal device 10 may have hardware elements other than the elements shown in FIG. 4.

[0030] The processor 101 is a computing element that realizes various functions of the terminal device 10. The processor 101 may be a system-on-a-chip (SoC) that includes elements such as a central processing unit (CPU), a graphics processing unit (GPU), and a memory controller.

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

[0032] The input / output interface 103 is an interface that receives operations on the terminal device 10 and supplies the operations 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 to realize wireless communication, and includes a baseband processor and an RF circuit. The wireless interface 104 transmits and receives wireless signals to and from the base station device 20 via an antenna 105.

[0034] 5, the terminal device 10 has, as functional blocks, a control unit 110 and a communication unit 120. The communication unit 120 has at least one transmission unit 121 and at least one reception 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 realized by the processor 101 and the memory 102. The control unit 110 executes 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 the wireless interface 104 and the antenna 105. In other words, the communication unit 120 is realized by the wireless interface 104 and the antenna 105. The communication unit 120 wirelessly communicates with the base station device 20 by transmitting and receiving wireless signals to and from the base station device 20. Two or more wireless interfaces 104 and two or more antennas 105 may be included in the communication unit 120.

[0037] The control unit 110 operates to execute various processes of the terminal device 10 .

[0038] 6, the base station device 20 has, as hardware elements, a processor 201, a memory 202, a network interface 203, a wireless interface 204, and an antenna 205. The above elements provided in the base station device 20 are connected to each other by an internal bus. Note that the base station device 20 may have hardware elements other than the elements shown in FIG. 6.

[0039] The processor 201 is a computing element that realizes various functions of the base station device 20. The processor 201 may be a CPU, and may further include other processors such as a GPU.

[0040] The memory 202 is configured by at least one storage medium such as a read-only memory (ROM), a RAM, a hard disk drive (HDD), or a solid state drive (SSD). The memory 202 is an element that temporarily or permanently stores programs and data used to execute various processes in the base station device 20. The programs include one or more instructions for operating the base station device 20. The processor 201 implements the functions of the base station device 20 by expanding and executing the programs stored in the memory 202 in the memory 202 and / or a system memory (not shown).

[0041] The network interface 203 is an interface used to transmit and receive signals to and from other base station devices 20 and the core network 30 .

[0042] The wireless interface 204 is a circuit that performs various signal processing to realize wireless communication, and includes a baseband processor and an RF circuit. The wireless interface 204 transmits and receives wireless signals to and from the terminal device 10 via an antenna 205.

[0043] 7, the base station device 20 has, as functional blocks, a control unit 210, a communication unit 220, and a network communication unit 230. The communication unit 220 has at least one transmission unit 221 and at least one reception 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 realized by the processor 201 and the memory 202. The control unit 210 executes various control processes in the base station device 20. For example, the control unit 210 controls wireless communication with the terminal device 10 via the communication unit 220. That is, the control unit 210 transmits and receives data / information / messages via the communication unit 220. Furthermore, 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 realized by the wireless interface 204 and the antenna 205. The communication unit 220 wirelessly communicates with the terminal device 10 by transmitting and receiving wireless signals to and from the terminal device 10. Two or more wireless interfaces 204 and two or more antennas 205 may be included in the communication unit 220.

[0046] The network communication unit 230 includes the network interface 203. In other words, the network communication unit 230 is realized by the network interface 203. The network interface 203 transmits and receives signals to and from the network (and thus to the other nodes described above).

[0047] The control unit 210 operates to execute various processes in the base station device 20 .

[0048] 1.2 Radio Resources The terminal device 10 and the base station device 20 communicate with each other wirelessly using radio resources in the frequency domain and the time domain. Radio resources will be described below.

[0049] The transmission method for downlink communication from the base station device 20 to the terminal device 10 is, for example, Orthogonal Frequency Division Multiplexing (OFDM) using a cyclic prefix (CP), i.e., CP-OFDM. The transmission method for uplink communication from the terminal device 10 to the base station device 20 is, for example, the above-mentioned CP-OFDM or DFTS-OFDM in which CP-OFDM is applied after transform precoding that performs 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 is inserted at the beginning of an OFDM symbol. There are two types of cyclic prefixes: a normal cyclic prefix and an extended cyclic prefix.

[0051] As radio resources in the frequency domain of OFDM, multiple subcarriers that are orthogonal to each other are used. The multiple subcarriers are arranged in the frequency domain at a predetermined subcarrier spacing (sub-carrier spacing, SCS) Δf. Multiple subcarrier spacings Δf can be applied in a communication system S. The subcarrier spacing Δf can be expressed, for example, by the following equation: Δf=2 μ ・15 [kHz]

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

[0053] In the time domain of OFDM, a layered radio frame structure is used as shown in Figure 8. One radio frame includes 10 subframes. Subframes are assigned subframe numbers that count up by one from 0 to 9. One radio frame is divided into two half frames. The time length of a radio frame is 10 ms, the time length of a half frame is 5 ms, and the time length of a subframe is 1 ms. These time lengths do not depend on the subcarrier spacing Δf.

[0054] One subframe includes one or more slots (slot(s)). The number Ns of slots included in one subframe depends on the value of μ described above, and further depends on the subcarrier spacing Δf. The number Ns of slots is expressed by the following formula, for example: Ns=2 μ

[0055] One slot contains multiple symbols. The number of symbols in one slot depends on the type of cyclic prefix. For example, if a normal cyclic prefix is ​​used, one slot contains 14 symbols. For example, if an extended cyclic prefix is ​​used, one slot contains 12 symbols.

[0056] As described above, the number of slots and the number of symbols included in each of a radio frame, half frame, and subframe, each of which has a fixed time length, are variable. Therefore, the time length of a slot and the time length of a symbol are also variable.

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

[0058] Each radio frame is assigned a system frame number (SFN), which counts up by one from 0 to 1023. SFN "0" corresponds to the initial value of the SFN, and SFN "1023" corresponds to the maximum value of the SFN. Therefore, the radio frame following a radio frame assigned SFN 1023 is assigned SFN 0. Since the time length of a radio frame is 10 ms, the time length of one cycle of the system frame number is 10,240 ms (= 10.24 seconds).

[0059] Here, the base station device 20 may configure one or more serving cells for the terminal device 10. The serving cell may correspond to a component carrier in the downlink and / or a component carrier in the uplink. The technology in which one or more serving cells are configured and the base station device 20 and the terminal device 10 perform wireless communication may also be referred to as carrier aggregation.

[0060] Furthermore, the base station device 20 may configure one or more bandwidth parts (Bandwidth Parts, BWPs) for the terminal device 10 with respect to each of one or more serving cells. For example, a Downlink Bandwidth Part (DL-BWP) may be configured in the downlink of one serving cell. Furthermore, an Uplink Bandwidth Part (UL-BWP) may be configured in the uplink of one serving cell. Herein, the DL-BWP may include an initial DL-BWP and / or a dedicated DL-BWP. Furthermore, the UL-BWP may include an initial UL-BWP and / or a dedicated UL-BWP. Hereinafter, the BWP may include a DL-BWP and / or a UL-BWP.

[0061] 1.3 Channels and Control Information The terminal device 10 and the base station device 20 transmit and receive user data and control information to and from each other. The transmission and reception of control information in the downlink and uplink will be exemplified below.

[0062] The terminal device 10 and the base station device 20 transmit and receive user data and control information using a plurality of hierarchical channels. The physical channel is a channel used for physical communication between the terminal device 10 and the base station device 20. Examples of the physical channel include a physical downlink control channel (PDCCH), a physical broadcast channel (PBCH), and a physical uplink control channel (PUCCH).

[0063] A transport channel is a channel located above a physical channel and is mapped to a physical channel in the PHY layer. Multiple transport channels may be mapped to one physical channel. Examples of transport channels include a Downlink Shared Channel (DL-SCH) and an Uplink Shared Channel (UL-SCH). For example, data in the downlink may also be referred to as DL-SCH data. Furthermore, for example, data in the uplink may also be referred to as UL-SCH data. Here, DL-SCH data includes user data in the downlink. Furthermore, UL-SCH data includes user data in the uplink.

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

[0065] The base station device 20 transmits downlink control information (DCI) to the terminal device 10 using the PDCCH, which is a physical channel. The DCI includes information on downlink and uplink resource allocation for the terminal device 10, and control information for the terminal device 10. The DCI is mapped to the PDCCH and corresponds to Layer 1 signaling.

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

[0067] For example, the base station device 20 may configure frequency domain resources and / or time domain resources that the terminal device 10 monitors (i.e., monitors) a PDCCH candidate set. For example, the frequency domain resources that the terminal device 10 monitors the PDCCH candidate set may be referred to as a control resource set (CORESET). Furthermore, the time domain resources that the terminal device 10 monitors the PDCCH candidate set may be referred to as a search space set (SSS). The terminal device 10 may monitor the PDCCH candidate set in one or more CORESETs in the DL-BWP of a serving cell for which PDCCH monitoring is configured, according to the corresponding search space set. Here, monitoring may imply attempting to decode each PDCCH candidate according to the monitored DCI format. The above configuration may be referred to as blind decoding.

[0068] Here, a Cyclic Redundancy Check (CRC) scrambled with a Radio Network Temporary Identifier (RNTI) may be added to the DCI (or DCI format) transmitted on the PDCCH. The CRC may also be referred to as a CRC parity bit. Multiple types of RNTI are defined. For example, the base station device 20 may set each RNTI by transmitting an RRC message including at least one of information indicating a C-RNTI (Cell-RNTI), information indicating a Modulation and Coding Scheme Cell-RNTI (MCS-C-RNTI), and information indicating a Configured Scheduling-RNTI (CS-RNTI). That is, a CRC scrambled with at least one of the C-RNTI, MCS-C-RNTI, and CS-RNTI may be added to the DCI (or DCI format) transmitted on the PDCCH.

[0069] The terminal device 10 may monitor (and / or receive) the PDCCH and detect (and / or receive) the DCI format.

[0070] The terminal device 10 transmits uplink control information (UCI) to the base station device 20 using the PUCCH, which is a physical channel. The UCI includes control information such as a scheduling request (SR), a hybrid automatic repeat reQuest (HARQ) ACK / NACK, and channel state information (CSI). The UCI is mapped to the PUCCH or PUSCH and corresponds to layer 1 signaling.

[0071] The base station device 20 uses the DL-SCH, which is a transport channel, to transmit a control element (CE) of the MAC layer to the terminal device 10. The downlink MAC CE is mapped to the PDSCH via the DL-SCH and corresponds to Layer 2 signaling.

[0072] The terminal device 10 transmits a control element (CE) of the MAC layer to the base station device 20 using the UL-SCH, which is a transport channel. The uplink MAC CE includes control information such as a buffer status report (BSR). The uplink MAC CE is mapped to a PUSCH via the UL-SCH and corresponds to Layer 2 signaling.

[0073] The base station device 20 transmits (or broadcasts) system information (SI) to the terminal device 10 using the BCCH, which is a logical channel. The SI includes minimum system information (MSI) and other system information (OSI). The MSI includes a master information block (MIB) and system information block 1 (SIB1). SIB1 may be referred to as remaining minimum system information (RMSI). The OSI includes system information blocks (SIB2 onward) other than SIB1. Of the BCCH, the MIB is mapped to the PBCH via the BCH (Broadcast CHannel), and the SIB is mapped to the PDSCH via the DL-SCH.

[0074] The base station device 20 transmits control information in the RRC layer to the terminal device 10 using a signaling radio bearer (SRB) established between the terminal device 10 and the base station device 20 in the RRC layer. Hereinafter, messages exchanged between the base station device 20 and the terminal device 10 in the RRC layer may be referred to as RRC messages. There are multiple types of SRBs (e.g., SRB0, SRB1, SRB2, SRB3, SRB4). The SRBs are used to transmit and receive RRC messages as well as NAS messages containing control information in the NAS layer. The CCCH or DCCH is used to transmit RRC messages from the base station device 20 to the terminal device 10. The CCCH and DCCH are each mapped to the PDSCH via the DL-SCH. The RRC message corresponds to Layer 3 signaling.

[0075] As an example of a downlink RRC message, an RRC reconfiguration message will be described. The RRC reconfiguration message is an RRC message transmitted from the base station device 20 to the terminal device 10 using SRB1 or SRB3. The DCCH is used to transmit the RRC reconfiguration message. The RRC reconfiguration message is used to reconfigure or modify the connection between the base station device 20 and the terminal device 10.

[0076] The terminal device 10 transmits an RRC message to the base station device 20 using the above-mentioned SRB. The CCCH or DCCH is used to transmit the RRC message from the terminal device 10 to the base station device 20. The CCCH and DCCH are each mapped to the PUSCH via the UL-SCH. The RRC message corresponds to Layer 3 signaling.

[0077] As an example of an uplink RRC message, a user equipment capability information (UECapabilityInformation) message will be described. The user equipment capability information message is an RRC message transmitted from the terminal device 10 to the base station device 20 using SRB1. The DCCH is used to transmit the user equipment capability information message. The user equipment capability information message is used to notify the base station device 20 of information related to the radio access capability of the terminal device 10.

[0078] As an example of an uplink RRC message, a user equipment assistance information (UE Assistance Information, UAI) message will be described. The UAI message is an RRC message transmitted from the terminal device 10 to the base station device 20 using SRB1 or SRB3. The DCCH is used to transmit the UAI message. The UAI message is used to notify the base station device 20 of various information related to the terminal device 10 (e.g., UE assistance information).

[0079] 1.4. Uplink Scheduling 1.4.1. Scheduling Request (SR) The SR is used by the terminal device 10 to request PUSCH radio resource allocation from the base station device 20. The SR may also be used to request UL-SCH resources for initial transmission. The base station device 20 allocates PUCCH resources for transmitting the SR to the terminal device 10. The base station device 20 transmits an RRC message including SR parameters to the terminal device 10. The SR parameters are included in a SchedulingRequestResourceConfig IE, which is an example of an RRC information element (IE).

[0080] The terminal device 10 transmits UCI including SR to the base station device 20 using the configured PUCCH resource. The terminal device 10 may transmit UCI on demand. The terminal device 10 may transmit UCI at a configured periodicity. For example, the terminal device 10 may transmit an SR set to "0" (negative SR) and / or an SR set to "1" (positive SR). The base station device 20 allocates PUSCH radio resources to the terminal device 10 according to the SR.

[0081] 1.4.2 Dynamic Grant (DG) DG is a scheduling method for allocating radio resources for the PUSCH in accordance with the uplink grant procedure. The base station device 20 transmits an uplink grant to the terminal device 10 via the PDCCH. The terminal device 10 transmits the PUSCH in accordance with the uplink grant. For example, the base station device 20 may allocate radio resources for the PUSCH using a DCI format with a CRC scrambled by the C-RNTI and / or MCS-C-RNTI (i.e., a DCI format used for PUSCH scheduling), and the terminal device 10 may perform uplink transmission using the allocated radio resources for the PUSCH. Here, a new data indicator (New Data Indicator) included in the DCI format to which the CRC scrambled by the C-RNTI and / or MCS-C-RNTI is added may be set to 0 or 1. Furthermore, the base station device 20 may allocate radio resources for the PUSCH using a DCI format with a CRC scrambled by the CS-RNTI (i.e., a DCI format used for scheduling the PUSCH), and the terminal device 10 may perform uplink transmission using the allocated radio resources for the PUSCH. Here, a new data indicator included in the DCI format with a CRC scrambled by the CS-RNTI may be set to 1.

[0082] 1.4.3. Configured Grant (CG) CG is a scheduling method for allocating radio resources for the PUSCH without the above-described dynamic uplink grant procedure. CG includes two types: Type 1 and Type 2. The base station device 20 transmits an RRC message including CG parameters to the terminal device 10. The CG parameters are included in a ConfiguredGrantConfig IE, which is an example of an RRC information element (IE). The ConfiguredGrantConfig IE includes a parameter periodicity related to the periodicity of transmission using the PUSCH. Note that the parameter periodicity is set in units of the number of slots or the number of symbols. Alternatively, the parameter periodicity may be set in units of frames per second (FPS). In Type 1, the terminal device 10 starts transmitting signals at the set periodicity without being triggered by DCI. On the other hand, in Type 2, the base station device 20 transmits DCI scrambled with CS-RNTI to the terminal device 10. The CS-RNTI is used to activate periodic transmission. In response to activation by DCI scrambled with the CS-RNTI, the terminal device 10 starts transmission using the PUSCH at a set period.

[0083] 1.5. Extended Reality (XR) This section describes the characteristics of traffic generated in XR. In XR, multiple types of data (video data, audio data, user data, control data, etc.) are transmitted and received in parallel. The multiple data streams corresponding to the above data each have different traffic characteristics and QoS requirements.

[0084] The timing of sending and receiving the above data can sometimes experience time shifts, which can be expressed as jitter, variability, or fluctuation, due to factors such as video and audio encoding and network delays.

[0085] Reference 1 states that the following definitions may be introduced for transmission and reception in XR: [Reference 1] 3GPP TR 23.700-60 V1.1.0 (2022-09)

[0086] Protocol Data Unit Set (PDU Set): A set of one or more PDUs that carry a payload of one unit of information generated at the application level. The application level corresponds, for example, to a frame or a video slice in an XR service. Data Burst: A set of data multiple PDUs generated and transmitted by an application in a short period of time. A PDU in a PDU set may correspond to a PDCP Service Data Unit (SDU).

[0087] Furthermore, in XR, the packet delay budget (PDB) requirement is considered as one of the above QoS requirements. PDB is the upper bound of the allowable packet delay time between the terminal device 10 and the UPF. Reference 1 also describes that the following new QoS parameters may be introduced: PDU-Set Delay Budget (PSDB): This is the upper bound of the allowable PDU set delay time between the terminal device 10 and the UPF. PDU-Set Error Rate (PSER): This is the upper bound of the error rate calculated between a PDU set processed by the sender and all PDUs in the PDU set that are not successfully delivered to the upper layer of the corresponding receiver.

[0088] 1.6 Processing in the PDCP Layer Next, a description will be given of the PDCP entities in the terminal device 10 and the base station device 20. Note that the processing in the PDCP entity in the terminal device 10 may be implemented by the above-described control unit 110. The processing in the PDCP entity in the base station device 20 may be implemented by the above-described control unit 210.

[0089] As shown in FIG. 9 , a PDCP entity 910 in the terminal device 10 is connected to an upper layer (e.g., an SDAP layer) and a lower layer (e.g., an RLC layer). The PDCP entity 910 may include one or more PDCP transmitters 911 and one or more PDCP receivers 912. Hereinafter, to distinguish it from the PDCP entity of the base station device 20, the PDCP transmitter 911 in the terminal device 10 will be referred to as a "first PDCP transmitter 911," and the PDCP receiver 912 in the terminal device 10 will be referred to as a "first PDCP receiver 912." Note that the PDCP transmitter may be referred to as a "transmitting PDCP entity." The PDCP receiver may be referred to as a "receiving PDCP entity."

[0090] The PDCP entity 920 in the base station device 20 is connected to an upper layer (e.g., an SDAP layer) and a lower layer (e.g., an RLC layer). The PDCP entity 920 may include one or more PDCP transmitters 921 and one or more PDCP receivers 922. Hereinafter, the PDCP transmitter 921 in the base station device 20 will be referred to as a "second PDCP transmitter 921," and the PDCP receiver 922 in the base station device 20 will be referred to as a "second PDCP receiver 922."

[0091] PDCP PDUs include a data PDCP PDU and a control PDCP PDU. The data PDCP PDU is called a "PDCP Data PDU" and the control PDCP PDU is called a "PDCP Control PDU."

[0092] A sequence number (SN) is assigned to each PDCP data PDU. The range of SNs may be configured for each of the downlink and uplink. The range of SNs for the downlink and the uplink may be configured based on parameters related to the PDCP layer.

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

[0094] pdcp-SN-SizeDL is information related to the range of SNs for the downlink. pdcp-SN-SizeDL may be configured for each 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 SN for the downlink. pdcp-SN-SizeDL may be configured to be 12 bits or 18 bits. Note that, in the case of an SRB, only 12 bits may be applied as the SN size. For example, the range of SNs for the downlink may be configured to be from "0" to "2[pdcp-SN-SizeDL]-1."

[0095] pdcp-SN-SizeUL is information related to the range of SN for uplink. pdcp-SN-SizeUL may be set for each SRB, MRB, or DRB. pdcp-SN-SizeUL indicates the size or length of SN for uplink. pdcp-SN-SizeUL may be set to 12 bits or 18 bits. Note that in the case of SRB, only 12 bits may be applied as the SN size. For example, the range of SN for uplink may be set to the range from "0" to "2[pdcp-SN-SizeUL]-1".

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

[0097] In the above format, the 'D / C' field may have a value indicating whether the PDCP PDU is a PDCP data PDU or a PDCP control PDU. For example, 'D / C' = 0 may indicate that the PDCP PDU is a PDCP control PDU. 'D / C' = 1 may indicate that the PDCP PDU is a PDCP data PDU.

[0098] In the above format, the "Data" field contains an uncompressed PDCP SDU or a compressed PDCP SDU, and the "MAC-I" field is used to signal a message authentication code.

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

[0100] Hereinafter, the terms "data unit" or "packet" may correspond to a PDU and / or an SDU. For example, on the transmitting side, a data unit or packet received from a higher layer is referred to as an SDU, and a data unit including the SDU and a header is transmitted to a lower layer as a PDU. Therefore, on the transmitting side, the terms "data unit" or "packet" may correspond to an SDU received from a higher layer and / or a PDU including the SDU and a header. On the receiving side, a data unit or packet received from a lower layer is referred to as a PDU, and a data unit with the header of the PDU removed is transmitted to a higher layer as an SDU. Therefore, on the receiving side, the terms "data unit" or "packet" may correspond 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 may use a COUNT value. The COUNT value may be composed of a Hyper Frame Number (HFN) and an SN. The size or length of the COUNT value may be 32 bits. That is, the bit size of the HFN portion in the COUNT value may be equal to 32 minus the size of the SN.

[0102] In the following sections 1.6.1 to 1.6.3, the processing in the downlink is described as an example, and the contents described in these sections may also be applied to the processing in the uplink.

[0103] 1.6.1 Processing in the PDCP Transmitter The second PDCP transmitter 921 of the base station device 20 performs a transmission process to transmit a data unit (i.e., an SDU) received from a higher layer to a lower layer. The second PDCP transmitter 921 may perform the above transmission process by associating a COUNT value with the data unit.

[0104] The second PDCP transmitter 921 may hold the following state variables for the above transmission process: TX_NEXT: Indicates the COUNT value of the next PDCP SDU to be transmitted.

[0105] As shown in Fig. 13, the second PDCP transmitter 921 receives a PDCP SDU 1301 from an upper layer. The second PDCP transmitter 921 associates a COUNT value corresponding to TX_NEXT with the PDCP SDU 1301. Next, the second PDCP transmitter 921 sets 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 transmits the PDCP data PDU to a lower layer. Then, the second PDCP transmitter 921 increments TX_NEXT by one.

[0106] 1.6.2 Processing in the PDCP Receiving Unit The first PDCP receiving unit 912 of the terminal device 10 performs a transmission process to transmit a data unit (i.e., a PDU) received from a lower layer to a higher layer. The first PDCP receiving unit 912 may perform the above transmission process by associating a COUNT value with the data unit.

[0107] The first PDCP receiver 912 may perform a re-ordering process in the above transmission process. The re-ordering may be a process of storing PDCP SDUs in a reception buffer and transmitting or delivering the PDCP SDUs to an upper layer in the order of the COUNT values ​​obtained from the PDCP PDUs.

[0108] For example, the above-mentioned parameters related to the PDCP layer may include parameters related to reordering. The parameters related to reordering may be included in a PDCP-Config IE. The PDCP-Config IE may include outOfOrderDelivery and t-Reordering.

[0109] OutOfOrderDelivery may be information indicating that the first PDCP receiver 912 performs the above-described transmission process without waiting for a data unit (i.e., a PDU) that has not yet arrived at the PDCP layer. That is, when OutOfOrderDelivery is set and the first PDCP receiver 912 receives a data unit and detects that a data unit that should have been received before the received data unit is missing, the first PDCP receiver 912 may transmit the received data unit to a higher layer without waiting for the missing data unit. Therefore, when OutOfOrderDelivery is not set and the first PDCP receiver 912 detects that a data unit is missing, the first PDCP receiver 912 may perform the reordering process described below.

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

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

[0112] As shown in FIG. 14 , the first PDCP receiver 912 receives a packet (e.g., PDCP PDU 1401) from a lower layer. The first PDCP receiver 912 stores a PDCP SDU corresponding to the received PDCP PDU 1401 in a receive buffer. The first PDCP receiver 912 updates RX_NEXT. RX_NEXT is updated to the value next to the COUNT value (i.e., RCVD_COUNT) corresponding to the PDCP PDU 1401. Here, the COUNT value (i.e., RCVD_COUNT) based on the PDCP PDU 1401 is equal to RX_DELIV. This means that the first PDCP receiver 912 received the PDCP PDU in the expected order. Therefore, the first PDCP receiver 912 determines that no packets are missing. 15, the first PDCP receiver 912 transmits the PDCP SDU corresponding to the received PDCP PDU 1401 to the upper layer and updates RX_DELIV.

[0113] In response to this, as shown in FIG. 16 , the first PDCP receiver 912 receives a packet (e.g., PDCP PDU 1601) from a lower layer. The first PDCP receiver 912 stores a PDCP SDU corresponding to the received PDCP PDU 1601 in a receive buffer. The first PDCP receiver 912 updates RX_NEXT. RX_NEXT is updated to the value next to the COUNT value (i.e., RCVD_COUNT) corresponding to PDCP PDU 1601. RCVD_COUNT is not equal to RX_DELIV. This means that the first PDCP receiver 912 did not receive the PDCP PDU in the expected order, i.e., a packet that should have been received was lost. 17, the first PDCP receiver 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, RX_DELIV<RX_NEXT, so the first PDCP receiver 912 starts t-Reordering and updates RX_REORD. RX_REORD is updated to RX_NEXT.

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

[0115] On the other hand, as shown in FIG. 20 , assume that t-Reordering expires without the first PDCP receiver 912 receiving a PDCP PDU whose RCVD_COUNT=RX_DELIV. In this case, the first PDCP receiver 912 transmits all stored PDCP SDUs associated with COUNT values ​​smaller than RX_REORD to the upper layer. In this example, the first PDCP receiver 912 transmits the PDCP SDU (corresponding to PDCP PDU 1601) stored in the receive buffer to the upper layer. Furthermore, the first PDCP receiver 912 updates RX_DELIV.

[0116] More specifically, the first PDCP receiver 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 receiver 912 may perform the following process: If RCVD_COUNT<RX_DELIV or if the PDCP data PDU with a COUNT value equal to RCVD_COUNT has been previously received, the first PDCP receiver 912 discards the PDCP data PDU. That is, the first PDCP receiver 912 may discard the PDCP data PDU that is deemed to have already been received.

[0118] If the received PDCP data PDU with a COUNT value=RCVD_COUNT is not discarded, the first PDCP receiver 912 may perform the following processes (a1) to (a6).

[0119] (a1) The first PDCP receiver 912 stores the resulting PDCP SDU in a receive buffer.

[0120] (a2) If RCVD_COUNT≧RX_NEXT: The first PDCP receiver 912 updates RX_NEXT to RCVD_COUNT+1.

[0121] (a3) When out-of-order delivery is set: The first PDCP receiver 912 performs header decompression using EHC (Ethernet Header Compression) and then delivers the resulting PDCP SDU to the upper layer.

[0122] (a4) If RCVD_COUNT = RX_DELIV: The first PDCP receiver 912 performs header decompression if no header decompression has been performed before, and then delivers the PDCP SDUs to the upper layer in ascending order of the associated COUNT values. Here, all stored PDCP SDUs associated with consecutive COUNT values, starting with the COUNT value equal to RX_DELIV, are delivered. The first PDCP receiver 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 upper layer.

[0123] (a5) If t-Reordering is running and RX_DELIV≧RX_REORD: The first PDCP receiver 912 stops and resets t-Reordering.

[0124] (a6) If t-Reordering is not running (including when t-Reordering is stopped due to the above-mentioned operation) and RX_DELIV<RX_NEXT: The first PDCP receiver 912 updates RX_REORD to RX_NEXT. The first PDCP receiver 912 starts t-Reordering.

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

[0126] (b1) The first PDCP receiver 912 performs header decompression, if no header decompression has been performed before, and then delivers the PDCP SDUs to upper layers in ascending order of associated COUNT values, where all stored PDCP SDUs associated with COUNT values ​​less 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 receiver 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 an upper layer.

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

[0129] 1.6.3 PDCP Status Report The first PDCP receiver 912 of the terminal device 10 may notify the second PDCP transmitter 921 of the base station device 20 of a PDCP status report. The PDCP status report may include the status of the SDU. For example, the PDCP status report may include information indicating whether the SDU is missing or has been successfully received. For example, the first PDCP receiver 912 may trigger a PDCP status report when a higher layer requests re-establishment of a PDCP entity for a DRB or MRB configured to transmit a PDCP status report in the uplink.

[0130] The first PDCP receiver 912 may use the format of the PDCP control PDU for the PDCP status report shown in FIG. 21 . Here, the 'PDU Type' field may indicate the type of control information included in the PDCP control PDU. In the case of a PDCP status report, the 'PDU Type' may be '000'. The 'FMC (First Missing Count)' field may indicate the COUNT value (i.e., RX_DELIV) of the first missing PDCP SDU. The 'Bitmap' field may indicate which SDUs are missing and which SDUs are successfully received for PDCP SDUs having a COUNT value greater than the FMC in the first PDCP receiver 912. For example, a '0' in a bit may indicate that the SDU corresponding to the bit is missing. A '1' in a bit may indicate that the SDU corresponding to the bit is successfully received.

[0131] 1.6.4 Data Discarding Process When the first PDCP transmitter 911 of the terminal device 10 receives a PDCP status report from the second PDCP receiver 922 of the base station device 20 via downlink, the first PDCP transmitter 911 may perform a data unit discarding process. For example, when the first PDCP transmitter 911 confirms normal delivery of a PDCP SDU based on the PDCP status report, the first PDCP transmitter 911 may discard the PDCP SDU together with the corresponding PDCP data PDU. For example, the first PDCP transmitter 911 may consider a PDCP SDU having a COUNT value smaller than the value of the FMC field included in the PDCP status report to be normally received. Furthermore, for example, the first PDCP transmitter 911 may consider a PDCP SDU having a corresponding bit set to "1" in the Bitmap field included in the PDCP status report to be normally received.

[0132] Furthermore, the first PDCP transmitter 911 may perform discard processing of data units using a PDCP discard timer and DiscardTimerForLowImportance. DiscardTimerForLowImportance is used for discard processing of data based on PSI (PDU Set Importance). Hereinafter, for simplicity of notation, such discard processing is referred to as "PSI-based discard processing."

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

[0134] Hereinafter, the normally used PDCP discard timer will be referred to as the "first discard timer," and the DiscardTimerForLowImportance used instead of the first discard timer in the PSI-based discard process will be referred to as the "second discard timer." The second discard timer is used for data with relatively low importance (i.e., data with a relatively large PSI value). The second discard timer is started instead of the first discard timer when the PSI-based discard process is activated. The second discard timer is always set to be shorter than the first discard timer.

[0135] For example, the parameters related to the discard process may be included in a PDCP-Config IE, which may include information about the first discard timer, information about the second discard timer, and pdu-SetDiscard.

[0136] The first discard timer may be set for each DRB. The second discard timer may be set for each DRB. Based on receiving a PDCP SDU from the upper layer, the first PDCP transmitter 911 may start the second discard timer associated with the PDCP SDU if PSI-based discard processing is enabled, the second discard timer is set, and the PDCP SDU belongs to a PDU set with low importance (i.e., a high PSI value). Otherwise, based on receiving a PDCP SDU from the upper layer, the first PDCP transmitter 911 may start the first discard timer associated with the PDCP SDU.

[0137] The pdu-SetDiscard may be a parameter indicating whether the first PDCP transmitter 911 performs discard processing based on a PDU set. For example, when the first discard timer or the second discard timer for a PDCP SDU expires and pdu-SetDiscard is set, the first PDCP transmitter 911 may discard all PDCP SDUs belonging to the PDU set to which the PDCP SDU belongs, along with the corresponding PDCP data PDUs. For example, when the first discard timer or the second discard timer for a PDCP SDU expires and pdu-SetDiscard is not set, the first PDCP transmitter 911 may discard the PDCP SDU along with the corresponding PDCP data PDUs.

[0138] The base station device 20 may transmit a MAC CE to the terminal device 10 to indicate whether the PSI-based discard process is enabled or disabled. This MAC CE may be referred to as a "PSI-Based SDU Discard Activation / Deactivation MAC CE." As shown in FIG. 22 , the MAC CE includes an 8-bit field 2200. In the field 2200, Di may indicate the enabled or disabled state of the PSI-based discard process for the DRBs for which the PSI-based discard process is configured, in ascending order of DRB ID. Here, i is an integer from 0 to 7. The definition of i will remain the same in the following description. When the value of Di is 1, this may indicate that the PSI-based discard process is enabled for the DRB corresponding to Di. When the value of Di is 0, this may indicate that the PSI-based discard process is disabled for the DRB corresponding to Di.

[0139] An example of the PSI-based discard process will be described below. As shown in Fig. 23 , the first PDCP transmitter 911 receives a packet 2301 from an upper 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 the packet 2301.

[0140] At time t1, the terminal device 10 receives the MAC CE shown in FIG. 22 from the base station device 20. Assume that the PSI-based discard process is enabled for the corresponding DRB in the MAC CE. Thereafter, at time t2, the first PDCP transmitter 911 receives a packet 2302 from an upper layer. Assume that a second discard timer is set and that the packet 2302 belongs to a PDU set with low importance. In this case, the first PDCP transmitter 911 starts the second discard timer instead of the first discard timer. When the second discard timer expires, the first PDCP transmitter 911 discards the packet 2302. According to the above configuration, packets with low importance can be discarded early.

[0141] 1.6.5 Reporting of Data Unit Loss For example, in the XR service, the above-mentioned discard process using the first discard timer or the second discard timer may frequently cause packets to be discarded. If a packet associated with an SN is discarded, the SN is lost. In other words, if some of multiple packets associated with consecutive SNs are discarded, the continuity of the SNs is lost. Some SNs become missing, resulting in a gap in the SNs. Such an event will be referred to hereinafter as an "SN gap."

[0142] When an SN gap occurs, an additional delay time occurs due to the reordering process. For example, an already discarded packet triggers the start of t-Reordering. A waiting packet is not transmitted to a higher layer until the t-Reordering expires, resulting in a delay time. To prevent such a delay time from occurring, the first PDCP transmitter 911 may transmit a report to the second PDCP receiver 922 of the base station device 20 regarding data units (e.g., PDCP SDUs) that are missing or discarded due to the discard process.

[0143] For example, the first PDCP transmitter 911 may use a PDCP control PDU to notify the second PDCP receiver 922 of a missing data unit. Hereinafter, a PDCP control PDU for reporting or notifying a missing data unit is referred to as a "missing control PDU."

[0144] The first PDCP transmitter 911 may use the format shown in FIG. 24. The missing control PDU may include a "D / C" field. The "D / C" field may be the same as described above. The missing control PDU may include a "PDU Type" field. The "PDU Type" may indicate the type of control information included in the PDCP control PDU. The "PDU Type" may be set to a predetermined value for the missing control PDU. The missing 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 may indicate the SN or COUNT value of the first missing data unit. The missing control PDU may include a "Bitmap" field. The "Bitmap" field may indicate whether the corresponding data unit is missing. For example, if a bit is "0", this may indicate that the data unit corresponding to that bit is not missing. If a bit is "1", this may indicate that the data unit corresponding to that bit is missing. Note that the relationship between "0" and "1" above may be reversed.

[0145] The first PDCP transmitter 911 may use the format shown in FIG. 25 . The missing control PDU may include a "D / C" field. The "D / C" field may be the same as described above. The missing control PDU may include a "PDU Type" field. The "PDU Type" field may be the same as described above. The missing 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 may indicate the SN or COUNT value of the first missing data unit. The missing control PDU may include information indicating the range of missing data units. The missing control PDU may include a "Missing PDUs" field. The "Missing PDUs" field may indicate the number of missing data units from the first missing data unit. Thus, the missing control PDU may indicate a range of missing data units based on a combination of the SN or COUNT value of the first missing data unit and the number of missing data units from the first missing data unit. In another example, the missing control PDU may indicate a range of missing data units based on a combination of the SN or COUNT value of the first missing data unit and the SN or COUNT value of the last missing data unit.

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

[0147] (c1) If all of the COUNT values ​​of the missing PDUs are outside the reordering window: the second PDCP receiver 922 ignores the missing control PDUs.

[0148] (c2) If RX_NEXT is within a missing PDU indicated by a missing control PDU: The second PDCP receiver 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 PDU indicated by the missing control PDU.

[0149] (c3) If RX_DELIV is included in a missing PDU: The second PDCP receiver 922, after performing header decompression if any, delivers to upper layers all stored PDCP SDUs associated with consecutive COUNT values, starting with the COUNT value equal to RX_DELIV, in ascending order of the associated COUNT values. The second PDCP receiver 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 upper layers, and is not included in a missing PDU indicated by a missing control PDU.

[0150] (c4) If t-Reordering is running and RX_DELIV≧RX_REORD: The second PDCP receiver 922 stops and resets t-Reordering.

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

[0152] The above processes (c1) to (c5) may not effectively eliminate the additional delay time, for example, the second PDCP receiver 922 may wait to receive a data unit even though the data unit is indicated as missing by the missing control PDU.

[0153] Note that, although the above description is of an example in which the first PDCP transmitter 911 of the terminal device 1 transmits the missing control PDU and the second PDCP receiver 922 of the base station device 20 receives the missing control PDU, the second PDCP transmitter 921 of the base station device 20 may transmit the missing control PDU and the first PDCP receiver 912 of the terminal device 10 may receive the missing control PDU. In this case, a similar problem may arise. For example, as shown in FIG. 26 , assume that the second PDCP transmitter 921 of the base station device 20 transmits the missing control PDU to the first PDCP receiver 912 of the terminal device 10. In this case, the first PDCP receiver 912 increments RX_NEXT and RX_DELIV by 1.

[0154] Next, as shown in FIG. 27 , the first PDCP receiver 912 receives a PDCP PDU 2701. The first PDCP receiver 912 transmits a PDCP SDU corresponding to the received PDCP PDU 2701 to an upper layer. The first PDCP receiver 912 then 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 already indicated as missing by the missing control PDU. Next, when the first PDCP receiver 912 receives a PDCP PDU 2702, RX_NEXT is updated (see the process (a2) above). As a result, RX_DELIV<RX_NEXT, and t-Reordering is initiated (see the process (a6) above). This causes an additional delay time.

[0155] Another example will be described. For example, as shown in Fig. 28, the first PDCP receiver 912 receives a missing control PDU from the second PDCP transmitter 921. At this point, RX_NEXT is outside the range of the COUNT value of the data unit indicated by the missing control PDU. In this case, the first PDCP receiver 912 performs processing for when a missing control PDU is not received.

[0156] As shown in Figure 29, the first PDCP receiver 912 receives a PDCP PDU 2901. The first PDCP receiver 912 transmits a PDCP SDU corresponding to the received PDCP PDU 2901 to an upper layer. The first PDCP receiver 912 then increments RX_NEXT and RX_DELIV by 1. In this case, RX_NEXT and RX_DELIV are updated to values ​​corresponding to a data unit that has already been indicated as missing by the missing control PDU. Therefore, an additional delay occurs, as described above.

[0157] 1.7. State Variable Update Process The second PDCP transmitter 921 of the base station device 20 executes a data unit discard process. The second PDCP transmitter 921 uses a missing control PDU to transmit a report (e.g., a missing control PDU) regarding data units that have been dropped or discarded by the discard process to the first PDCP receiver 912 of the terminal device 10. The first PDCP receiver 912 updates state variables used for a transmission process of transmitting data units received from a lower layer to a higher layer based on the missing control PDU. Below, aspects 1-1 to 1-7 of the state variable update process are described. Aspects 1-1 to 1-4 include the process for the case described in FIGS. 26 and 27 (hereinafter referred to as "Case 1"). Aspects 1-5 to 1-6 include the process for the case described in FIGS. 28 and 29 (hereinafter referred to as "Case 2"). Aspect 1-7 includes both the process for Case 1 and the process for Case 2.

[0158] (Aspect 1-1) When a missing control PDU is received, the first PDCP receiver 912 may update RX_NEXT to a value that has a COUNT value greater than RX_NEXT and is obtained by adding one to the COUNT value of the last missing data unit among the missing data units indicated by the missing control PDU. That is, when a missing control PDU is received, the first PDCP receiver 912 may update RX_NEXT based on the COUNT value of the last missing data unit among the missing data units indicated by the missing control PDU. Note that the condition of having a COUNT value greater than RX_NEXT may be removed from the conditions for determining the updated RX_NEXT. That is, when a missing control PDU is received, the first PDCP receiver 912 may update RX_NEXT to a value that is obtained by adding one to the COUNT value of the last missing data unit among the missing data units indicated by the missing control PDU.

[0159] For example, if RX_NEXT is within a missing PDU indicated by the missing control PDU, the first PDCP receiver 912 may update RX_NEXT to a value that has a COUNT value greater than RX_NEXT and is the COUNT value of the last missing data unit among the missing data units indicated by the missing control PDU plus 1. Also, for example, the first PDCP receiver 912 may update RX_DELIV by the process of (c3) above.

[0160] According to the above configuration, RX_NEXT and RX_DELIV are updated from the state shown in FIG. 26 to the state shown in FIG. 30. This prevents RX_NEXT from being updated to a value corresponding to a packet that has already been indicated as missing by a missing control PDU. As shown in FIG. 31, the first PDCP receiver 912 receives a PDCP PDU 2701. The first PDCP receiver 912 transmits a PDCP SDU corresponding to the received PDCP PDU 2701 to the upper layer. The first PDCP receiver 912 performs the process of (a4) above. Therefore, the first PDCP receiver 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 upper layer. RX_DELIV becomes equal to RX_NEXT. RX_DELIV<RX_NEXT is not satisfied. In other words, the above condition (a6) is not satisfied, so t-Reordering is not started. Therefore, it is possible to prevent the occurrence of additional delay time.

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

[0162] For example, the first PDCP receiver 912 may consider 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 updated from the state shown in FIG. 27 to the state shown in FIG. 32. That is, after updating RX_NEXT and RX_DELIV to the state shown in FIG. 27, the first PDCP receiver 912 regards the COUNT value of the missing data unit indicated by the missing control PDU as RCVD_COUNT. Therefore, the first PDCP receiver 912 performs the process (a2) above to update RX_NEXT to RCVD_COUNT+1. Furthermore, the first PDCP receiver 912 performs the process (a4) above to update 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 upper layer. RX_DELIV<RX_NEXT is not true. Since t-Reordering is not initiated, additional delay time can be prevented.

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

[0165] According to the above configuration, RX_NEXT and RX_DELIV are not updated to values ​​corresponding to data units already indicated as missing by a missing control PDU. As shown in Figure 33, RX_NEXT and RX_DELIV are updated to values ​​next to the values ​​corresponding to data units already indicated as missing by a missing control PDU. RX_DELIV does not become less than RX_NEXT. Since t-Reordering is not initiated, additional delay time can be prevented.

[0166] In addition, in the above-mentioned aspects 1-1 to 1-3, if out-of-order delivery is set, the first PDCP receiver 912 may ignore the missing control PDU.

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

[0168] (d1) If all of the COUNT values ​​of the missing PDUs are outside the reordering window or outOfOrderDelivery is set: the first PDCP receiver 912 ignores the missing control PDUs.

[0169] (d2) If RX_NEXT is within a missing PDU indicated by a missing control PDU: The first PDCP receiver 912 updates RX_NEXT to a value that has a COUNT value greater than RX_NEXT and is equal to the COUNT value of the last missing PDCP SDU among the missing PDUs indicated by the missing control PDU plus 1.

[0170] (d3) If RX_DELIV is included in a missing PDU: The first PDCP receiver 912, after performing header decompression if any, delivers to upper layers all stored PDCP SDUs associated with consecutive COUNT values, starting with the COUNT value equal to RX_DELIV, in ascending order of the associated COUNT values. The first PDCP receiver 912 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 upper layers, and is not included in a missing PDU indicated by a missing control PDU.

[0171] (d4) If t-Reordering is running and RX_DELIV≧RX_REORD: The first PDCP receiver 912 stops and resets t-Reordering.

[0172] (d5) If t-Reordering is not running (including when t-Reordering is stopped due to the above-described operation) and RX_DELIV<RX_NEXT: The first PDCP receiver 912 updates RX_REORD to RX_NEXT. The first PDCP receiver 912 starts t-Reordering.

[0173] Furthermore, among the above processes (a1) to (a6), the process (a4) may be replaced with the following process (a4-alt).

[0174] (a4-alt) If RCVD_COUNT = RX_DELIV: After performing header decompression if no header decompression has been performed previously, the first PDCP receiver 912 delivers PDCP SDUs to upper layers in ascending order of associated COUNT values, where all stored PDCP SDUs associated with consecutive COUNT values ​​starting with the COUNT value equal to RX_DELIV are delivered. The first PDCP receiver 912 updates RX_DELIV to the COUNT value of the first PDCP SDU that has a COUNT value greater than RX_DELIV, is not included in a missing PDU indicated by a missing control PDU, and has not been delivered to upper layers.

[0175] (Aspect 1-5) When a dropped control PDU is received, the first PDCP receiver 912 may regard a data unit having a COUNT value (i.e., FMC) smaller than that of the first data unit among the dropped data units indicated by the dropped control PDU as a correctly received data unit or a data unit that has already been discarded. Then, the first PDCP receiver 912 may update at least one of RX_NEXT and RX_DELIV.

[0176] Specifically, when receiving a missing control PDU, the first PDCP receiver 912 may regard the COUNT value of a data unit having a smaller value than the COUNT value (e.g., FMC) of the first data unit among the missing data units indicated by the missing control PDU as the RCVD_COUNT, and then may perform the above processes (a1) to (a6).

[0177] In another example, the first PDCP receiver 912 may update the values ​​of RX_NEXT and RX_DELIV when at least one of RX_NEXT and RX_DELIV is smaller than the COUNT value (e.g., FMC) of the first data unit among the missing data units indicated by the dropped control PDU. For example, the first PDCP receiver 912 may update RX_NEXT to a value that is greater than RX_NEXT and equal to the COUNT value of the last missing data unit among the missing data units indicated by the dropped control PDU plus one.

[0178] Additionally, the first PDCP receiver 912 may update RX_DELIV to the COUNT value of the first data unit that has a COUNT value greater than RX_DELIV and / or FMC, that has not been delivered to the upper layer, and that is not included in the missing data units indicated by the missing control PDU.

[0179] According to the above configuration, RX_NEXT and RX_DELIV are not updated to values ​​corresponding to data units already indicated as missing by a missing control PDU. As shown in Figure 34, RX_NEXT and RX_DELIV are updated to values ​​next to the values ​​corresponding to data units already indicated as missing by a missing control PDU.

[0180] In addition, in aspect 1-5, if out-of-order delivery is set, the first PDCP receiver 912 may ignore the missing control PDU.

[0181] (Aspect 1-6) When a missing control PDU is received, the first PDCP receiver 912 may perform at least one of the following processes (e1) to (e5).

[0182] (e1) If all of the COUNT values ​​of the missing PDUs are outside the reordering window or outOfOrderDelivery is set: the first PDCP receiver 912 ignores the missing control PDUs.

[0183] (e2) If RX_NEXT is within a missing PDU indicated by a missing control PDU, or if RX_NEXT is less than the COUNT value of the first missing PDCP SDU indicated by a missing control PDU: the first PDCP receiver 912 updates RX_NEXT to a value that has a COUNT value greater than RX_NEXT and is equal to the COUNT value of the last missing PDCP SDU among the missing PDUs indicated by the missing control PDU plus 1.

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

[0185] (e4) If t-Reordering is running and RX_DELIV≧RX_REORD: The first PDCP receiver 912 stops and resets t-Reordering.

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

[0187] (Aspect 1-7) When a missing control PDU is received, the first PDCP receiver 912 may execute the process shown in Fig. 35. For example, the first PDCP receiver 912 may execute at least one of the following processes (f1) to (f5).

[0188] (f1) If all of the COUNT values ​​of the missing PDUs are outside the reordering window or outOfOrderDelivery is set: the first PDCP receiver 912 ignores the missing control PDUs.

[0189] (f2) If RX_NEXT is within a missing PDU indicated by a missing control PDU, or if RX_NEXT is less than the COUNT value of the first missing PDCP SDU indicated by a missing control PDU: the first PDCP receiver 912 updates RX_NEXT to a value that has a COUNT value greater than RX_NEXT and is equal to the COUNT value of the last missing PDCP SDU among the missing PDUs indicated by the missing control PDU plus 1.

[0190] (f3) If RX_DELIV is included in a missing PDU or RX_DELIV < the COUNT value of the first missing PDCP SDU indicated by the missing control PDU: The first PDCP receiver 912 delivers all stored PDCP SDUs associated with consecutive COUNT values, starting with the COUNT value equal to RX_DELIV, in ascending order of the associated COUNT values, after performing header decompression, if any. The first PDCP receiver 912 updates RX_DELIV to the COUNT value of the first PDCP SDU that has a COUNT value greater than RX_DELIV and 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 a missing PDU indicated by the missing control PDU.

[0191] (f4) If t-Reordering is running and RX_DELIV≧RX_REORD: The first PDCP receiver 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-mentioned operation) and RX_DELIV<RX_NEXT: The first PDCP receiver 912 updates RX_REORD to RX_NEXT. The first PDCP receiver 912 starts t-Reordering.

[0193] Furthermore, when receiving a PDCP data PDU from a lower layer, the first PDCP receiving unit 912 may execute the process shown in Fig. 36. That is, the process (a4) above may be replaced with the process (a4-alt) above.

[0194] 1.8. Triggering of Missing Control PDUs The above-mentioned Non-Patent Documents 1 and 2 do not describe the conditions for triggering a missing control PDU. The above-mentioned first discard timer or second discard timer is not stopped in existing technical specifications (including, for example, Non-Patent Documents 1 and 2). A discard process is performed for all data units, and a missing control PDU may be triggered each time a discard process is performed. On the other hand, for successfully transmitted data units, the first PDCP transmitter 911 of the terminal device 10 does not need to notify the second PDCP receiver 922 of the base station device 20 of the missing control PDU. Furthermore, the PDCP layer cannot determine whether a data unit was successfully transmitted.

[0195] In the following, in order to solve the above problem, the first PDCP transmitter 911 may trigger or transmit a missing control PDU based on a predetermined condition. For example, the first PDCP transmitter 911 may transmit a missing control PDU to the second PDCP receiver 922 based on a predetermined condition. In the following, details of aspects 2-1 and 2-2 of the triggering process of a missing control PDU will be described.

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

[0197] The base station device 20 may transmit an RRC message including parameters related to the missing control PDU to the terminal device 10. For example, the parameters related to the missing control PDU may be included in a PDCP-Config IE, which is an example of an RRC information element (IE).

[0198] The parameters related to the missing control PDU may include information that explicitly or implicitly indicates whether to trigger or transmit the missing control PDU. Hereinafter, this information is referred to as "first information." The first information may indicate "triggering or transmitting the missing control PDU" or "not triggering or transmitting the missing control PDU." The first information may also be a flag indicating "triggering or transmitting the missing control PDU" or "not triggering or transmitting the missing control PDU."

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

[0200] For example, in a situation where the first PDCP transmitter 911 receives from the base station device 20 first information indicating that a missing control PDU is to be triggered or transmitted and / or second information indicating that a PDU set-based discard process is to be performed, the first PDCP transmitter 911 may trigger or transmit a missing control PDU when a PDCP SDU is discarded and a PDCP PDU corresponding to the SDU has already been transmitted to a lower layer. The 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 may trigger or transmit a missing control PDU based on an instruction from a lower layer (for example, an RLC layer).

[0202] The first PDCP transmitter 911 may notify the lower layer that the data unit has been discarded by the discard process. The lower layer entity may instruct the upper layer to trigger or transmit a missing control PDU based on the notification from the upper layer (i.e., the PDCP layer).

[0203] For example, in a situation where the first PDCP transmitter 911 receives from the base station device 20 first information indicating that a missing control PDU will be triggered or transmitted, and / or second information indicating that a PDU set-based discard process will be performed, the first PDCP transmitter 911 may trigger or transmit the missing control PDU based on an instruction from a lower layer.

[0204] 1.9 Setting Process of Fields of Missing Control PDU When a missing control PDU is triggered, the first PDCP transmitter 911 may compile the missing control PDU as follows: The following describes aspect 3 for setting fields of the missing control PDU.

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

[0206] The first PDCP transmitter 911 may determine the size of the Bitmap field based on a count from the COUNT value of the first discarded or dropped PDCP SDU to the COUNT value of the last discarded or dropped PDCP SDU. For example, as shown in FIG. 37 , if the COUNT value of the first discarded or dropped PDCP SDU is 2 and the COUNT value of the last discarded or dropped PDCP SDU is 4, the first PDCP transmitter 911 may determine the size of the Bitmap field based on a count from 2 to 4 (=3). Furthermore, the count does not need to include the COUNT value of the first discarded or dropped PDCP SDU. That is, the first PDCP transmitter 911 may determine the size of the Bitmap field based on a count from 3 to 4 (=2).

[0207] In another example, the first PDCP transmitter 911 may determine the size of the Bitmap field based on a count from the COUNT value of the first discarded or dropped PDCP SDU to TX_NEXT. As shown in FIG. 37 , the first PDCP transmitter 911 may determine the size of the Bitmap field based on a count (=4) from the COUNT value (=2) of the first discarded or dropped PDCP SDU to TX_NEXT. Furthermore, this count does not need to include the COUNT value of the first discarded or dropped PDCP SDU. That is, the first PDCP transmitter 911 may determine the size of the Bitmap field based on a count (=3) from the value next to the COUNT value of the first discarded or dropped PDCP SDU (=3) to TX_NEXT.

[0208] In another example, the first PDCP transmitter 911 may set the FMC field to a value based on TX_NEXT (e.g., TX_NEXT). In this case, as shown in FIG. 37 , the first PDCP transmitter 911 may determine the size of the Bitmap field based on a count (=4) from the COUNT value (=2) of the first discarded or missing PDCP SDU to TX_NEXT. Furthermore, this count may not include TX_NEXT. That is, the first PDCP transmitter 911 may determine the size of the Bitmap field based on a count (=3) from the COUNT value (=2) of the first discarded or missing PDCP SDU to TX_NEXT-1.

[0209] Note that the COUNT value of the first discarded or missing PDCP SDU may be the COUNT value of the first PDCP SDU that triggered the missing control PDU.

[0210] The COUNT value of the discarded or missing first PDCP SDU may be the COUNT value of the PDCP SDU indicated by a lower layer. That is, the first PDCP transmitter 911 may set the FMC field included in the missing control PDU to the COUNT value of the PDCP SDU indicated by a lower layer (e.g., the RLC layer). Also, the first PDCP transmitter 911 may determine the size of the Bitmap field included in the missing control PDU based on the COUNT value of the PDCP SDU indicated by the lower layer.

[0211] The first discarded or missing PDCP SDU may be a PDCP SDU for which information on missing or discarded PDCP SDUs has not yet been reported by a missing control PDU. That is, the first PDCP transmitter 911 may set the FMC field included in the missing control PDU to the COUNT value of the first discarded or missing PDCP SDU among the PDCP SDUs that have not yet been reported as missing by a previously triggered or transmitted missing control PDU. Furthermore, the first PDCP transmitter 911 may determine the size of the Bitmap field included in the missing control PDU based on the COUNT value of the first discarded or missing PDCP SDU among the PDCP SDUs that have not yet been reported as missing by a previously triggered or transmitted missing control PDU.

[0212] The process of determining the size of the Bitmap field based on the count number may be performed based on at least one of the following process (g1) and the condition (g2). For example, the first PDCP transmitter unit 911 may determine the size of the Bitmap field based on either the process (g1) or the condition (g2), whichever is reached first. (g1) A process of rounding up the count number to a multiple of a predetermined number (e.g., a multiple of 8). For example, the size of the Bitmap field may be rounded up to the next multiple of 8 of the count number. In the example of FIG. 37 , the next multiple of 8 of the count number is 8. Therefore, the size of the Bitmap field may be determined to be 8. (g2) A condition that the size of the PDCP control PDU is equal to a predetermined maximum size. For example, this condition may be that the size of the PDCP control PDU is equal to 9000 bytes.

[0213] The above arrangement allows for the appropriate triggering or transmission of a missing control PDU, and further allows for the appropriate setting of one or more fields included in the missing control PDU.

[0214] 1.10. Combinations and Modifications of Aspect 1, Aspect 2, and Aspect 3 Above Aspect 1 (i.e., Aspect 1-1 to Aspect 1-7), Aspect 2 (i.e., Aspect 2-1 to Aspect 2-2), and Aspect 3 above may be combined. That is, as long as there is no mutual contradiction, at least a part of Aspect 1 above, at least a part of Aspect 2 above, and at least a part of Aspect 3 above may be combined. Note that, although Aspect 1 above (i.e., Aspect 1-1 to Aspect 1-7) has been described as processing by the first PDCP receiver 912, Aspect 1 may also be applied to the second PDCP receiver 922. Although Aspect 2 above (i.e., Aspect 2-1 to Aspect 2-2) and Aspect 3 have been described as processing by the first PDCP transmitter 911, Aspects 2 and 3 may also be applied to processing by the second PDCP transmitter 921.

[0215] 2. Modifications Although the present disclosure has been described based on the above embodiment, it is understood that the present disclosure is not limited to the embodiment or structure. The present disclosure also encompasses various modifications and modifications within the equivalent range. Other combinations including one or more elements included in the above embodiment are also within the scope and spirit of the present disclosure.

[0216] The words, phrases, and other expressions used in the above embodiments are merely examples and may be replaced with substantially identical or similar expressions. In particular, since the technology according to the above embodiments relates to technical specifications, the expressions in the above embodiments may be replaced with substantially identical or similar expressions in technical specifications (e.g., technical specifications cited in this specification).

[0217] The information transmitted and received in the above embodiment may be contained in the same or a different message or element already described in the technical specifications, or may be contained in a newly defined message or element. The information transmitted and received in the above embodiment may be transmitted and received using a different layer and / or a different channel than those in the above embodiment.

[0218] The means and / or functions provided by the devices described in the above embodiments can be provided by software recorded in a tangible memory device and a computer that executes the software, software alone, hardware alone, or a combination thereof. For example, if any of the above devices is provided by an electronic circuit that is hardware, it can be provided by a digital circuit including a large number of logic circuits, or an analog circuit.

[0219] The device described in the above embodiment executes a program stored in a non-transitory tangible storage medium, and the execution of the program executes a method corresponding to the program.

[0220] 3. Supplementary Notes Some or all of the above embodiments and modified examples may also be described as, but are not limited to, the following supplementary notes. Below, relationships are expressed in which a supplementary note that is subordinate to multiple supplementary notes is subordinate to another supplementary note that is subordinate to multiple supplementary notes. All of the following subordinate relationships of supplementary notes are included in the above embodiments.

[0221] (Appendix A1) A terminal device (10) comprising a transmitter (911) and a receiver (912) in a Packet Data Convergence Protocol (PDCP) layer, the transmitter being configured to: perform a discard process for a data unit; and trigger a report on a missing data unit based on a predetermined condition.

[0222] (Supplementary Note A2) The terminal device according to Supplementary Note A1, wherein the transmitting unit is configured to trigger the report when a data unit is discarded by the discarding process and a data unit corresponding to the discarded data unit is transmitted to a lower layer.

[0223] (Supplementary Note A3) The terminal device according to Supplementary Note A2, wherein the transmitting unit is configured to trigger the report when, in a situation where the transmitting unit receives from a base station device (20) at least one of first information indicating that the report will be triggered or transmitted and second information indicating that the discard process based on a Protocol Data Unit Set will be executed, a certain data unit is discarded by the discard process and a data unit corresponding to the certain data unit is transmitted to the lower layer.

[0224] (Supplementary Note A4) The terminal device according to Supplementary Note A1, wherein the sending unit is configured to trigger the report based on an instruction from a lower layer.

[0225] (Supplementary Note A5) The terminal device according to Supplementary Note A4, wherein the transmitting unit is configured to notify the lower layer of the fact that the data unit has been discarded by the discarding process, and to trigger the report based on the instruction transmitted from the lower layer in response to the notification.

[0226] (Supplementary Note A6) The terminal device according to Supplementary Note A4 or A5, wherein the transmitting unit is configured to trigger the report based on the instruction in a situation where the transmitting unit receives at least one of first information indicating that the report will be triggered or transmitted and second information indicating that the discard process based on a Protocol Data Unit Set will be performed from a base station device (20).

[0227] (Supplementary Note A7) The terminal device according to any one of Supplementary Notes A1 to A6, wherein the report includes a field indicating whether a corresponding data unit is missing, and the transmitter is configured to determine a size of the field based on a COUNT value of a first missing data unit and a COUNT value of a last missing data unit.

[0228] (Supplementary Note A8) The terminal device according to Supplementary Note A7, wherein the transmitter is configured to determine the size of the field based on at least one of the following conditions: rounding up a value obtained based on the COUNT value of the first missing data unit and the COUNT value of the last missing data unit to a multiple of a predetermined number; and a PDCP control protocol data unit (PDU) including the report is equal to a predetermined maximum size.

[0229] (Supplementary Note A9) The terminal device according to Supplementary Note A7 or A8, wherein the COUNT value of the missing first data unit is the COUNT value of the first data unit that triggered the report.

[0230] (Supplementary Note A10) The terminal device according to Supplementary Note A7 or A8, wherein the COUNT value of the missing first data unit is a COUNT value of a data unit instructed from a lower layer.

[0231] (Supplementary Note A11) The terminal device according to any one of Supplementary Notes A1 to A6, wherein the report includes a field indicating whether a corresponding data unit is missing, and the transmitter is configured to determine a size of the field based on a COUNT value of a first missing data unit and a COUNT value of a data unit to be transmitted to a lower layer next.

[0232] (Supplementary Note A12) The terminal device according to Supplementary Note A11, wherein the transmitting unit is configured to determine the size of the field based on at least one of the following conditions: rounding up a value obtained based on the COUNT value of the first missing data unit and the COUNT value of the data unit to be transmitted to the next lower layer to a multiple of a predetermined number; and a PDCP control protocol data unit (PDU) including the report must be equal to a predetermined maximum size.

[0233] (Supplementary Note A13) The terminal device according to Supplementary Note A11 or A12, wherein the COUNT value of the missing first data unit is the COUNT value of the first data unit that triggered the report.

[0234] (Supplementary Note A14) The terminal device according to Supplementary Note A11 or A12, wherein the COUNT value of the missing first data unit is a COUNT value of a data unit instructed from a lower layer.

[0235] (Supplementary Note A15) A method for a terminal device (10) having a transmitting unit (911) and a receiving unit (912) in a Packet Data Convergence Protocol (PDCP) layer, the method comprising: executing, by the transmitting unit, a discarding process for a data unit; and triggering, by the transmitting unit, a report on a missing data unit based on a predetermined condition.

[0236] (Appendix A16) A program that causes a processor (101) in a terminal device (10) to implement a transmitting unit (911) and a receiving unit (912) in a Packet Data Convergence Protocol (PDCP) layer, the program causing the processor to: execute a discard process for a data unit, by the transmitting unit; and trigger a report on a missing data unit based on a predetermined condition, by the transmitting unit.

[0237] (Appendix A17) A non-transient tangible recording medium having recorded thereon a program that causes a processor (101) in a terminal device (10) to implement a transmitting unit (911) and a receiving unit (912) in a Packet Data Convergence Protocol (PDCP) layer, wherein the program causes the processor to: execute a discard process for a data unit by the transmitting unit; and trigger a report on a missing data unit by the transmitting unit based on a predetermined condition.

[0238] (Supplementary Note B1) A terminal device (10) includes: a receiver (122) that receives, from a base station device (20), a Radio Resource Control (RRC) message including a PDCP control Protocol Data Unit (PDU) for reporting a gap in a Packet Data Convergence Protocol (PDCP) Sequence Number (SN), the PDCP control PDU including a field indicating whether a PDCP Service Data Unit (SDU) has been discarded; and a controller (110) that includes a PDCP entity (910), wherein the PDCP entity is configured to transmit the PDCP control PDU for reporting the gap in the PDCP SN based on the information, and triggers the PDCP control PDU for reporting the gap in the PDCP SN when at least one PDCP SDU is discarded; compiles the PDCP control PDU for reporting the gap in PDCP SN when the PDCP control PDU for reporting the gap in SN is triggered, and in the compiling process, determines a bit length of the field indicating whether the PDCP SDU has been discarded based on a count value from a first discarded PDCP SDU to a last discarded PDCP SDU.

[0239] (Supplementary Note B2) The terminal device according to Supplementary Note B1, wherein the PDCP entity discards the PDCP SDU when at least one of the following conditions is satisfied: a discard timer for the PDCP SDU has expired; and normal delivery of the PDCP SDU has been confirmed based on a PDCP status report.

[0240] (Supplementary Note B3) The terminal device according to Supplementary Note B1 or B2, wherein the PDCP control PDU for reporting the gap in PDCP SN includes at least one of: a field indicating a minimum count value corresponding to discarded PDCP SDUs; a field indicating that the corresponding PDCP PDU is a PDCP data PDU or the PDCP control PDU; and a field indicating a type of control information included in the PDCP control PDU.

[0241] (Supplementary Note B4) The terminal device according to any one of Supplementary Notes B1 to B3, wherein the field indicating whether the PDCP SDU has been discarded is a bitmap field indicating whether the corresponding PDCP SDU has been discarded based on a value of a bit.

[0242] (Supplementary Note B5) The terminal device according to any one of Supplementary Notes B1 to B4, wherein at least one of the count value corresponding to the first PDCP SDU and the count value corresponding to the last PDCP SDU is configured based on a Hyper Frame Number (HFN) and the PDCP SN.

[0243] (Supplementary Note B6) The terminal device according to any one of Supplementary Notes B1 to B5, further comprising: a transmitter (121) configured to transmit the PDCP control PDU for reporting the gap in the PDCP SN to the base station device.

[0244] (Supplementary Note B7) A method for a terminal device (10), comprising: receiving, from a base station device (20), a Radio Resource Control (RRC) message including information for setting whether to transmit a PDCP control Protocol Data Unit (PDU) for reporting a gap in a Packet Data Convergence Protocol (PDCP) Sequence Number (SN), the PDCP control PDU including a field indicating whether a PDCP Service Data Unit (SDU) has been discarded; being configured to transmit the PDCP control PDU for reporting the gap in the PDCP SN based on the information, and when at least one PDCP SDU is discarded, triggering the PDCP control PDU for reporting the gap in the PDCP SN by a PDCP entity; and when the PDCP control PDU for reporting the gap in the PDCP SN has been triggered, triggering the PDCP control PDU for reporting the gap in the PDCP SN by a PDCP entity. compiling, by the PDCP entity, the PDCP control PDU for reporting the gap in SN; and determining, in the compiling process, by the PDCP entity, a bit length of the field indicating whether the PDCP SDU has been discarded based on a count value from a first discarded PDCP SDU to a last discarded PDCP SDU.

[0245] (Supplementary Note B8) The method of Supplementary Note B7, further comprising: discarding, by the PDCP entity, the PDCP SDU when at least one of the following conditions is satisfied: a discard timer for the PDCP SDU has expired; and successful delivery of the PDCP SDU has been confirmed based on a PDCP status report.

[0246] (Supplementary Note B9) The method according to Supplementary Note B7 or B8, wherein the PDCP control PDU for reporting the gap in PDCP SN includes at least one of: a field indicating a minimum count value corresponding to discarded PDCP SDUs; a field indicating that the corresponding PDCP PDU is a PDCP data PDU or the PDCP control PDU; and a field indicating a type of control information included in the PDCP control PDU.

[0247] (Supplementary Note B10) The method according to any one of Supplementary Notes B7 to B9, wherein the field indicating whether the PDCP SDU has been discarded is a bitmap field indicating whether the corresponding PDCP SDU has been discarded based on a value of a bit.

[0248] (Supplementary Note B11) The method according to any one of Supplementary Notes B7 to B10, wherein at least one of the count value corresponding to the first PDCP SDU and the count value corresponding to the last PDCP SDU is configured based on a Hyper Frame Number (HFN) and the PDCP SN.

[0249] (Supplementary Note B12) The method according to any one of Supplementary Notes B7 to B11, further comprising transmitting the PDCP control PDU for reporting the gap in the PDCP SN to the base station device.

[0250] (Supplementary Note B13) A base station device (20) comprising: a transmitter (221) that transmits, to a terminal device (10), a Radio Resource Control (RRC) message including a PDCP control Protocol Data Unit (PDU) for reporting a gap in a Packet Data Convergence Protocol (PDCP) Sequence Number (SN), the PDCP control PDU including information for setting whether to transmit the PDCP control PDU including a field indicating whether a PDCP Service Data Unit (SDU) has been discarded; and a receiver (222) that receives the PDCP control PDU from the terminal device, wherein the terminal device is configured to transmit the PDCP control PDU for reporting the gap in the PDCP SN based on the information, and when at least one PDCP SDU is discarded in the terminal device, the PDCP control PDU for reporting the gap in the PDCP SN is triggered in the terminal device, the receiving unit receives from the terminal device the PDCP control PDU, the PDCP control PDU including the field indicating whether the PDCP SDU has been discarded, the field having a bit length determined based on the number of count values ​​from a count value corresponding to a first discarded PDCP SDU to a count value corresponding to a last discarded PDCP SDU.

[0251] (Supplementary Note B14) The base station apparatus according to Supplementary Note B13, wherein the PDCP control PDU for reporting the gap in the PDCP SN includes at least one of: a field indicating a minimum count value corresponding to discarded PDCP SDUs; a field indicating that the corresponding PDCP PDU is a PDCP data PDU or the PDCP control PDU; and a field indicating a type of control information included in the PDCP control PDU.

[0252] (Supplementary Note B15) The base station apparatus according to Supplementary Note B13 or B14, wherein the field indicating whether the PDCP SDU has been discarded is a bitmap field indicating whether the corresponding PDCP SDU has been discarded based on a value of a bit.

[0253] (Supplementary Note B16) The base station device according to any one of Supplementary Notes B13 to B15, wherein at least one of the count value corresponding to the first PDCP SDU and the count value corresponding to the last PDCP SDU is configured based on a Hyper Frame Number (HFN) and the PDCP SN.

[0254] The disclosures of the above prior art documents and references are incorporated herein by reference.

Claims

1. A terminal device (10) comprising: a receiver (122) that receives, from a base station device (20), a Radio Resource Control (RRC) message including a PDCP control Protocol Data Unit (PDU) for reporting a gap in a Packet Data Convergence Protocol (PDCP) Sequence Number (SN), the PDCP control PDU including a field indicating whether a PDCP Service Data Unit (SDU) has been discarded; and a controller (110) including a PDCP entity (910), wherein the PDCP entity is configured to transmit the PDCP control PDU for reporting the gap in the PDCP SN based on the information, and triggers the PDCP control PDU for reporting the gap in the PDCP SN when at least one PDCP SDU is discarded; compiles the PDCP control PDU for reporting the gap in PDCP SN when the PDCP control PDU for reporting the gap in SN is triggered, and in the compiling process, determines a bit length of the field indicating whether the PDCP SDU has been discarded based on a count value from a first discarded PDCP SDU to a last discarded PDCP SDU.

2. The terminal device according to claim 1, wherein the PDCP entity discards the PDCP SDU when at least one of the following conditions is satisfied: a discard timer for the PDCP SDU has expired; and normal delivery of the PDCP SDU has been confirmed based on a PDCP status report.

3. The terminal device according to claim 1 or 2, wherein the PDCP control PDU for reporting the gap in PDCP SN includes at least one of: a field indicating a minimum count value corresponding to discarded PDCP SDUs; a field indicating that the corresponding PDCP PDU is a PDCP data PDU or the PDCP control PDU; and a field indicating a type of control information included in the PDCP control PDU.

4. The terminal device according to claim 1, wherein the field indicating whether the PDCP SDU has been discarded is a bitmap field indicating whether the corresponding PDCP SDU has been discarded based on a value of a bit.

5. The terminal device according to claim 1, wherein at least one of the count value corresponding to the first PDCP SDU and the count value corresponding to the last PDCP SDU is configured based on a Hyper Frame Number (HFN) and the PDCP SN.

6. The terminal device according to claim 1, further comprising: a transmitter (121) configured to transmit the PDCP control PDU for reporting the gap in the PDCP SN to the base station device.

7. A method for a terminal device (10), comprising: receiving, from a base station device (20), a Radio Resource Control (RRC) message including information for setting whether to transmit a PDCP control Protocol Data Unit (PDU) for reporting a gap in a Packet Data Convergence Protocol (PDCP) Sequence Number (SN), the PDCP control PDU including a field indicating whether a PDCP Service Data Unit (SDU) has been discarded; being configured to transmit the PDCP control PDU for reporting the gap in the PDCP SN based on the information, and if at least one PDCP SDU is discarded, triggering the PDCP control PDU for reporting the gap in the PDCP SN by a PDCP entity; and when the PDCP control PDU for reporting the gap in the PDCP SN is triggered, triggering the PDCP control PDU for reporting the gap in the PDCP SN by a PDCP entity. compiling, by the PDCP entity, the PDCP control PDU for reporting the gap in SN; and determining, in the compiling process, by the PDCP entity, a bit length of the field indicating whether the PDCP SDU has been discarded based on a count value from a first discarded PDCP SDU to a last discarded PDCP SDU.

8. The method of claim 7, further comprising: discarding the PDCP SDU by the PDCP entity when at least one of the following conditions is met: a discard timer for the PDCP SDU has expired; and successful delivery of the PDCP SDU has been confirmed based on a PDCP status report.

9. The method according to claim 7 or 8, wherein the PDCP control PDU for reporting the gap in the PDCP SN includes at least one of: a field indicating a minimum count value corresponding to discarded PDCP SDUs; a field indicating that the corresponding PDCP PDU is a PDCP data PDU or the PDCP control PDU; and a field indicating a 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 indicating whether the corresponding PDCP SDU has been discarded based on a value of a bit.

11. The method according to any one of claims 7 to 10, wherein at least one of the count value corresponding to the first PDCP SDU and the count value corresponding to the last PDCP SDU is configured based on a Hyper Frame Number (HFN) and the PDCP SN.

12. The method according to claim 7, further comprising transmitting the PDCP control PDU for reporting the gap in the PDCP SN to the base station device.

13. A base station device (20) comprising: a transmitter (221) that transmits to a terminal device (10) a Radio Resource Control (RRC) message including a PDCP control Protocol Data Unit (PDU) for reporting a gap in a Packet Data Convergence Protocol (PDCP) Sequence Number (SN), the PDCP control PDU including information for setting whether to transmit the PDCP control PDU including a field indicating whether a PDCP Service Data Unit (SDU) has been discarded; and a receiver (222) that receives the PDCP control PDU from the terminal device, wherein the terminal device is configured to transmit the PDCP control PDU for reporting the gap in the PDCP SN based on the information, and when at least one PDCP SDU is discarded in the terminal device, the PDCP control PDU for reporting the gap in the PDCP SN is triggered in the terminal device; the receiving unit receives from the terminal device the PDCP control PDU, the PDCP control PDU including the field indicating whether the PDCP SDU has been discarded, the field having a bit length determined based on the number of count values ​​from a count value corresponding to a first discarded PDCP SDU to a count value corresponding to a last discarded PDCP SDU.

14. The base station apparatus according to claim 13, wherein the PDCP control PDU for reporting the gap in PDCP SN includes at least one of: a field indicating a minimum count value corresponding to discarded PDCP SDUs; a field indicating that the corresponding PDCP PDU is a PDCP data PDU or the PDCP control PDU; and a field indicating a 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 indicating whether the corresponding PDCP SDU has been discarded based on a value of a bit.

16. The base station device according to claim 13, wherein at least one of the count value corresponding to the first PDCP SDU and the count value corresponding to the last PDCP SDU is configured based on a Hyper Frame Number (HFN) and the PDCP SN.

Images