Method and apparatus for performing feedback-based Ethernet header compression or decompression in a wireless communication system

Abstract

The present disclosure relates to a communication technology and a system thereof for integrating Internet of Things technology with a 5G communication system for supporting higher data transfer rates beyond 4G systems. The present disclosure can be applied to intelligent services (e.g., smart home, smart building, smart city, smart vehicle or connected car, healthcare, digital education, retail business, security and safety-related services, etc.) based on 5G communication technology and IoT-related technologies. The present disclosure provides a method and apparatus for configuring an unordered transfer function of protocol layer devices.

Description

Technical Field

[0001] The present disclosure relates to a method or apparatus for performing Ethernet header compression or decompression in a next-generation mobile communication system or a wireless communication system. Background Art

[0002] To meet the increasing demand for wireless data services since the deployment of 4G communication systems, efforts have been made to develop improved 5G or pre-5G communication systems. Therefore, 5G or pre-5G communication systems are also referred to as "super 4G network" communication systems or "post-LTE" systems. The 5G communication system defined by 3GPP is referred to as a "New Radio (NR) system".

[0003] The 5G communication system is considered to be implemented in a super high frequency (millimeter wave) band (e.g., 60 GHz band) in order to achieve higher data rates. To reduce the propagation loss of radio waves in the super high frequency band and increase the transmission distance, beamforming, massive multiple-input multiple-output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive antenna technologies have been discussed in the 5G communication system and applied to the NR system.

[0004] In addition, in the 5G communication system, system network improvement development is being carried out based on advanced small cells, cloud radio access network (RAN), ultra-dense network, device-to-device (D2D) communication, wireless backhaul, mobile network, cooperative communication, coordinated multipoint (CoMP), receiver interference cancellation, etc. In the 5G system, hybrid FSK and QAM modulation (FQAM) and sliding window superimposed coding (SWSC) as advanced coding modulation (ACM), and filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA), and sparse code multiple access (SCMA) as advanced access technologies have also been developed.

[0005] The Internet, as a human - centered connection network in which humans generate and consume information, is now evolving towards the Internet of Things (IoT) where distributed entities such as things exchange and process information without human intervention. The Internet of Everything (IoE) has emerged as a combination of IoT technologies and big - data processing technologies connected to cloud servers. As IoT implementation requires technical elements such as "sensing technology", "wired / wireless communication and network infrastructure", "service interface technology", and "security technology", sensor networks, machine - to - machine (M2M) communication, machine - type communication (MTC), etc. have been studied recently. Such an IoT environment can provide intelligent Internet technology services that create new value for human life by collecting and analyzing data generated between connected things. Through the integration and combination of existing information technology (IT) and various industrial applications, IoT can be applied to various fields, including smart homes, smart buildings, smart cities, smart cars or connected vehicles, smart grids, healthcare, smart appliances, and advanced medical services.

[0006] In line with this, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, machine - type communication (MTC), and machine - to - machine (M2M) communication can be implemented through beamforming, MIMO, and array antennas. Cloud radio access network (RAN), as an application of the above - mentioned big - data processing technology, can also be considered an example of the integration of 5G technology and IoT technology.

[0007] Meanwhile, with the development of communication systems, diverse functions have been proposed to meet various requests, and improvements are needed in the operation of the radio link control (RLC) layer and packet data convergence protocol (PDCP) layer to execute these functions. SUMMARY OF THE INVENTION

[0008] TECHNICAL PROBLEM

[0009] In the next - generation mobile communication system, it is necessary to effectively use transmission resources to support services that require low transmission latency and high reliability (e.g., ultra - reliable low - latency communication (URLLC) or industrial IoT (IIoT) services).

[0010] In a wireless communication system, to support services with low transmission latency and no data interruption, an effective data - processing method or transmission method in a specific protocol - layer device is required. Therefore, the present disclosure can propose a scheme for improving the operation of protocol - layer devices.

[0011] SOLUTION TO THE PROBLEM

[0012] According to an embodiment for solving the above technical problem, a method for a terminal includes: receiving, from a base station, first information for configuring unordered delivery of a radio link control (RLC) entity and second information indicating a reordering timer value for a packet data convergence protocol (PDCP) entity associated with the RLC entity; based on the first information, delivering, by the RLC entity, data to the PDCP entity based on unordered delivery; and based on the second information, performing, by the PDCP entity, a reordering function on the data.

[0013] According to an embodiment for solving the above technical problem, a method for a base station includes: sending, to a terminal, first information for configuring unordered delivery of a radio link control (RLC) entity and second information indicating a reordering timer value for a packet data convergence protocol (PDCP) entity associated with the RLC entity, wherein, based on the first information, the RLC entity delivers data to the PDCP entity based on unordered delivery, and wherein, based on the second information, the PDCP entity performs a reordering function on the data.

[0014] According to an embodiment for solving the above technical problem, a terminal includes: a transceiver configured to send or receive signals; and a controller, wherein the controller is configured to: receive, from a base station, first information for configuring unordered delivery of a radio link control (RLC) entity and second information indicating a reordering timer value for a packet data convergence protocol (PDCP) entity associated with the RLC entity, based on the first information, deliver, by the RLC entity, data to the PDCP entity based on unordered delivery, and based on the second information, perform, by the PDCP entity, a reordering function on the data.

[0015] According to an embodiment for solving the above technical problem, a base station includes: a transceiver configured to send or receive signals; and a controller, wherein the controller is configured to: send, to a terminal, first information for configuring unordered delivery of a radio link control (RLC) entity and second information indicating a reordering timer value for a packet data convergence protocol (PDCP) entity associated with the RLC entity, based on the first information, deliver, by the RLC entity, data to the PDCP entity based on unordered delivery, and based on the second information, perform, by the PDCP entity, a reordering function on the data.

[0016] Advantageous effects of the invention

[0017] According to an embodiment of the present disclosure, a method for compressing or decompressing an Ethernet header in a next-generation mobile communication system using an Ethernet protocol is proposed, so as to be able to effectively use transmission resources. Therefore, a large amount of data can be transmitted via a small amount of transmission resources, and a more reliable modulation method can be used, thereby ensuring high reliability and low latency.

[0018] According to the embodiments proposed through the present disclosure, a method for processing transmitted / received data by applying an unordered transmission scheme in a wireless communication system can reduce transmission latency during the operation of a protocol layer device. Therefore, the operation of the protocol layer device can be effectively improved.

[0019] In addition, according to another embodiment of the present disclosure, the operations of each layer including the RLC layer can be effectively performed to support the unordered transmission function of the RLC layer. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1a Illustrates the structure of an LTE system according to an embodiment of the present disclosure;

[0021] Figure 1b Illustrates the radio protocol structure in an LTE system according to an embodiment of the present disclosure;

[0022] Figure 1c Illustrates the structure of a next-generation mobile communication system according to an embodiment of the present disclosure;

[0023] Figure 1d Illustrates the radio protocol structure of a next-generation mobile communication system according to an embodiment of the present disclosure;

[0024] Figure 1e Illustrates the process in which, according to an embodiment of the present disclosure, when a UE establishes a connection with a network, a base station configures configuration information related to an Ethernet header protocol for the UE;

[0025] Figure 1f Illustrates an Ethernet header compression method according to an embodiment of the present disclosure;

[0026] Figure 1g Illustrates an Ethernet header compression method proposed when configuring an SDAP header or a layer device according to an embodiment of the present disclosure;

[0027] Figure 1h Illustrates another Ethernet header compression method proposed when configuring an SDAP header or a layer device according to an embodiment of the present disclosure;

[0028] Figure 1i Illustrates a first specific embodiment of an Ethernet header compression method according to an embodiment of the present disclosure;

[0029] Figure 1j Illustrates a second specific embodiment of an Ethernet header compression method according to an embodiment of the present disclosure;

[0030] Figure 1k Illustrates an embodiment of a feedback structure that can be used in a high-layer header compression method according to an embodiment of the present disclosure;

[0031] Figure 1lIllustrates the operation of a transmitting PDCP layer device or a receiving PDCP layer device of a UE or a base station according to an embodiment of the present disclosure;

[0032] Figure 1m Illustrates the structure of a UE according to an embodiment of the present disclosure;

[0033] Figure 1n Illustrates the block diagram configuration of a transmission and reception point (TRP) in a wireless communication system according to an embodiment of the present disclosure;

[0034] Figure 1o Illustrates the detailed stages of an effective handover method (e.g., dual active protocol stack (DAPS) handover method) for minimizing data interruption time due to handover in an embodiment of the present disclosure;

[0035] Figure 2a Illustrates the process by which a UE in the present disclosure switches from radio resource control (RRC) idle mode to RRC connected mode to establish a connection with the network;

[0036] Figure 2b Illustrates an effective data processing method of a PDCP layer device proposed by the present disclosure;

[0037] Figure 2c Illustrates the operations that may occur when an out-of-order delivery function is configured in an RLC layer device proposed by the present disclosure;

[0038] Figure 2d Illustrates the operations of a UE proposed by the present disclosure;

[0039] Figure 2e Illustrates the operations of a base station proposed by the present disclosure;

[0040] Figure 2f Illustrates the structure of a UE to which an embodiment of the present disclosure can be applied;

[0041] Figure 2g Illustrates the block diagram configuration of a TRP in a wireless communication system to which an embodiment of the present disclosure can be applied; and

[0042] Figure 2h Illustrates the Ethernet header compression method proposed by the present disclosure. Detailed Description of the Embodiments

[0043] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. When describing the embodiments of the present disclosure, descriptions related to well-known technical content in the art and not directly related to the present disclosure will be omitted. Such omission of unnecessary descriptions is to prevent obscuring the main idea of the present disclosure and to more clearly convey the main idea.

[0044] For the same reason, in the drawings, some elements may be exaggerated, omitted, or shown schematically. In addition, the size of each element does not exactly reflect the actual size. In the drawings, the same or corresponding elements have the same reference numerals.

[0045] Advantages and features of the present disclosure, and ways to implement them, will become apparent by referring to embodiments described in detail below in conjunction with the drawings. However, the present disclosure is not limited to the embodiments set forth below, but may be implemented in various different forms. The following embodiments are provided only to fully disclose the present disclosure and to inform those skilled in the art of the scope of the present disclosure, and the present disclosure is defined only by the scope of the appended claims. Throughout the specification, the same or similar reference numerals denote the same or similar elements.

[0046] In this document, it will be understood that each block of the flowchart illustration and combinations of blocks in the flowchart illustration can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions executed via the processor of the computer or other programmable data processing apparatus create a means for implementing the functions specified in the (one or more) flowchart blocks. These computer program instructions can also be stored in a computer-usable or computer-readable memory, which can direct a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-usable or computer-readable memory produce a manufacture including an instruction means for implementing the functions specified in the (one or more) flowchart blocks. The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus, so that a series of operation steps are executed on the computer or other programmable apparatus, thereby producing a computer-implemented process, such that the instructions executed on the computer or other programmable apparatus provide steps for implementing the functions specified in the (one or more) flowchart blocks.

[0047] In addition, each block of the flowchart illustration may represent a module, a code segment, or a code portion that includes one or more executable instructions for implementing the (one or more) specified logical functions. It should also be noted that in some alternative embodiments, the functions recited in the blocks may occur out of order. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functions involved.

[0048] As used herein, a "unit" refers to a software element or a hardware element that performs a predetermined function, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC). However, the meaning of a "unit" is not always limited to software or hardware. A "unit" can be configured to be stored in an addressable storage medium or to execute on one or more processors. Thus, a "unit" includes, for example, software elements, object-oriented software elements, class elements or task elements, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and parameters. The elements and functions provided by a "unit" can be combined into a smaller number of elements or "units", or can be divided into a larger number of elements or "units". In addition, the elements and "units" can be implemented to reproduce one or more CPUs within a device or a secure multimedia card. In addition, a "unit" in an embodiment can include one or more processors.

[0049] In the following description, for convenience, terms for identifying access nodes, terms related to network entities, terms related to messages, terms related to interfaces between network entities, terms related to various identification information, etc. are illustratively used. Therefore, the present disclosure is not limited to the terms used below, and other terms related to a subject having an equivalent technical meaning can be used.

[0050] In the following description of the present disclosure, for ease of description, terms or names defined in the 3rd Generation Partnership Project Long Term Evolution (3GPP LTE) standard will be used. However, the present disclosure is not limited by these terms and names, and can be applied to systems conforming to other standards in the same manner. In the present disclosure, for ease of description, the term "eNB" can be used interchangeably with the term "gNB". That is, a base station described as an "eNB" can indicate a "gNB". In the present disclosure, the term "terminal" can refer to a mobile phone, an NB-IoT device, a sensor, and various wireless communication devices.

[0051] In a next-generation mobile communication system, in order to support services that require low latency and high reliability (e.g., ultra-reliable low-latency communication (URLLC) or industrial IoT (IIoT) services), it is necessary to effectively use transmission resources.

[0052] According to an embodiment of the present disclosure, a method for compressing or decompressing an Ethernet header in a next-generation mobile communication system using an Ethernet protocol is proposed so that transmission resources can be effectively used. Thus, a large amount of data can be transmitted via a small amount of transmission resources, and a more reliable modulation method can be used, thereby ensuring high reliability and low latency.

[0053] <Embodiment 1>

[0054] Figure 1a Shows the structure of an LTE system according to an embodiment of the present disclosure.

[0055] Reference Figure 1a , the radio access network of the LTE system may include next-generation base stations (referred to as evolved Node B, hereinafter referred to as eNB, Node B, or base station) 1a-05, 1a-10, 1a-15, and 1a-20, a mobility management entity (MME) 1a-25, or a serving gateway (S-GW) 1a-30. A user equipment (hereinafter referred to as UE or terminal) 1a-35 may access an external network through the eNBs 1a-05 to 1a-20 or the S-GW 1a-30.

[0056] In Figure 1a , the eNBs 1a-05 to 1a-20 may correspond to existing Node Bs of a Universal Mobile Telecommunications System (UMTS). The eNB is connected to the UE 1a-35 through a radio channel and performs a more complex role than the existing Node B. In the LTE system, since all user services related to real-time services (such as Voice over Internet Protocol (VoIP) via the Internet Protocol) are served through a shared channel, a device for performing scheduling by collecting status information (such as the buffer state, available transmission power state, and channel state of the UE) is required, and the eNBs 1a-05 to 1a-20 may be responsible for this function of the device. Generally, one eNB may control multiple cells. For example, in order to implement a transmission rate of 100 Mbps, the LTE system may use Orthogonal Frequency Division Multiplexing (OFDM) as a radio access technology in a 20 MHz bandwidth. In addition, the LTE system adopts an Adaptive Modulation and Coding (hereinafter referred to as AMC) scheme for determining a modulation scheme and a channel coding rate based on the channel state of the UE. The S-GW 1a-30 is a device for providing a data bearer and may generate or remove a data bearer under the control of the MME 1a-25. In addition to being responsible for the mobility management function of the UE, the MME 1a-25 may be responsible for various control functions and may be connected to multiple base stations.

[0057] Figure 1b Shows the radio protocol structure in an LTE system according to an embodiment of the present disclosure.

[0058] Reference Figure 1b, the radio protocols of the LTE system include the Packet Data Convergence Protocol (PDCP) 1b-05 and 1b-40, the Radio Link Control (RLC) 1b-10 and 1b-35, and the Medium Access Control (MAC) 1b-15 and 1b-30 in the UE and eNB respectively. The Packet Data Convergence Protocol (PDCP) 1b-05 and 1b-40 are used to perform operations such as IP header compression / recovery. The main functions of PDCP are outlined below. PDCP can perform various functions, not limited to the following examples.

[0059] - Header compression and decompression: only Robust Header Compression (ROHC)

[0060] - Transmission of user data

[0061] - Sequential transfer of upper layer PDUs during the PDCP reconstruction process in RLC acknowledged mode (AM)

[0062] - Sequence reordering (for split bearers in DC (only RLC AM supported): routing of PDCP PDUs for transmission and reordering of PDCP PDUs for reception)

[0063] - Duplicate detection of lower layer SDUs during the PDCP reconstruction process in RLC AM

[0064] - Retransmission of PDCP SDUs at handover for RLC AM, and retransmission of PDCP PDUs during the PDCP data recovery process for split bearers in DC)

[0065] - Encryption and decryption

[0066] - Timer-based service data unit (SDU) discard in the uplink

[0067] The Radio Link Control (hereinafter referred to as RLC) 1b-10 and 1b-35 can perform automatic repeat request (ARQ) operations, etc. by reconfiguring the PDCP protocol data unit (PDU) to an appropriate size. The main functions of RLC are outlined below. RLC can perform various functions, not limited to the following examples.

[0068] - Transmission of upper layer PDUs

[0069] - ARQ function (error correction by ARQ (only for AM data transmission))

[0070] - Concatenation, segmentation and reassembly of RLC SDUs (only for UM and AM data transmission)

[0071] - Re-segmentation of RLC data PDUs (only for AM data transmission)

[0072] - Reordering of RLC data PDUs (for UM and AM data transfer only)

[0073] - Duplicate detection (for UM and AM data transfer only)

[0074] - Protocol error detection (for AM data transfer only)

[0075] - RLC SDU discard (for UM and AM data transfer only)

[0076] - RLC re-establishment

[0077] MAC 1b-15 and 1b-30 are connected to multiple RLC layer devices configured in a UE, and can perform operations of multiplexing RLC packet data units (PDUs) into MAC PDUs and demultiplexing RLC PDUs from MAC PDUs. The main functions of MAC are outlined as follows. MAC can perform various functions, not limited to the following examples.

[0078] - Mapping between logical channels and transport channels

[0079] - Multiplexing MAC SDUs belonging to one or different logical channels into transport blocks (TBs) passed to the physical layer on the transport channel / Demultiplexing MAC SDUs belonging to one or different logical channels from transport blocks (TBs) passed from the physical layer on the transport channel

[0080] - Scheduling information reporting

[0081] - Error correction by HARQ

[0082] - Priority handling between logical channels of a UE

[0083] - Priority handling between UEs by dynamic scheduling

[0084] – Multimedia broadcast multicast service (MBMS) identification

[0085] - Transport format selection

[0086] - Padding

[0087] The physical layers 1b-20 and 1b-25 can perform operations such as channel encoding and modulation of upper-layer data, forming the upper-layer data into OFDM symbols, transmitting the OFDM symbols through a radio channel, or demodulating the OFDM symbols received through a radio channel, channel decoding the OFDM symbols, and transmitting the OFDM symbols to the upper layer. The PHY can perform various functions and is not limited to the following examples.

[0088] Figure 1c Shows the structure of a next-generation mobile communication system according to an embodiment of the present disclosure.

[0089] Reference Figure 1c , the radio access network of a next-generation mobile communication system (hereinafter referred to as NR or 5G) may include a new radio node B (hereinafter referred to as NR gNB or NR base station) 1c-10 and a new radio core network (NR CN) 1c-05. A user equipment (new radio user equipment, hereinafter referred to as NR UE or terminal) 1c-15 can access an external network via the NR gNB 1c-10 and the NR CN 1c-05.

[0090] In Figure 1c , the NR gNB 1c-10 corresponds to the evolved node B (eNB) of an existing LTE system. The NR gNB 1c-10 is connected to the NR UE 1c-15 via a radio channel and can provide excellent services compared to an existing node B. In a next-generation mobile communication system, since all types of user services are served through a shared channel, a device for performing scheduling by collecting status information (such as the buffer status, available transmission power status, and channel status of the UE) is required. In addition, the NR gNB 1c-10 is responsible for this function of the device. Generally, one NR gNB 1c-10 usually controls multiple cells. To implement ultra-high-speed data transmission compared to existing LTE, the NR gNB can have the existing maximum bandwidth or a larger bandwidth and can additionally adopt beamforming technology using orthogonal frequency division multiplexing (hereinafter referred to as OFDM) as a radio access technology. In addition, the NR gNB adopts an adaptive modulation and coding (AMC) scheme that determines the modulation scheme and channel coding rate based on the channel state of the UE. The NR CN 1c-05 performs functions such as mobility support, bearer configuration, quality of service (QoS) configuration, etc. The NR CN 1c-10 is a device that is responsible for various control functions in addition to the mobility management function of the UE and can be connected to multiple base stations. In addition, a next-generation mobile communication system can also operate in combination with an existing LTE system, and the NR CN1c-10 can be connected to the MME 1c-25 via a network interface. The MME 1c-25 can be connected to the eNB 1c-30, that is, connected to an existing base station.

[0091] Figure 1d Shows the radio protocol structure of a next-generation mobile communication system according to an embodiment of the present disclosure.

[0092] Refer to Figure 1d , the radio protocol of the next-generation mobile communication system includes NR Service Data Adaptation Protocol (SDAP) 1d-01 and 1d-45, NR PDCP 1d-05 and 1d-40, NR RLC 1d-10 and 1d-35, and NR MAC 1d-15 and 1d-30 in the UE and the NR base station, respectively.

[0093] The main functions of NR SDAP 1d-01 and 1d-45 may include some of the following functions. PDCP can perform various functions, not limited to the following examples.

[0094] - Transmission of user plane data

[0095] - Mapping between QoS flows and data bearers (DRBs) for both downlink (DL) and uplink (UL)

[0096] - Marking QoS flow IDs in both DL and UL packets

[0097] - Mapping the reflected QoS flow to a data bearer (DRB) for UL SDAP PDUs

[0098] Regarding the SDAP layer device, the UE can be configured via RRC messages whether to use the header of the SDAP layer device or the function of the SDAP layer device for each PDCP layer device, each bearer, and each logical channel. When the SDAP header is configured, the non-access stratum quality of service (NAS reflected QoS) reflection configuration 1-bit indicator (NAS reflected QoS) and the access stratum quality of service (AS QoS) reflection configuration 1-bit indicator (AS reflected QoS) of the SDAP header are used to indicate that the UE enables the update or reconfiguration of mapping information related to QoS flows and data bearers for the uplink and downlink. The SDAP header may include QoS flow ID information indicating QoS. The QoS information can be used as data processing priority, scheduling information, etc. to support smooth services.

[0099] The main functions of NR PDCP 1d-05 and 1d-40 may include some of the following functions. NR PDCP can perform various functions, not limited to the following examples.

[0100] - Header compression and decompression: Only ROHC

[0101] - Transmission of user data

[0102] - Sequential delivery of upper layer PDUs

[0103] -Out-of-order transfer of upper-layer PDUs

[0104] -PDCP PDU reordering for reception

[0105] -Duplicate detection of lower-layer SDUs

[0106] -Retransmission of PDCP SDUs

[0107] -Encryption and decryption

[0108] -Timer-based SDU discard in the uplink

[0109] The reordering function of the NR PDCP device may include the function of sequentially reordering the PDCP PDUs received from the lower layer based on the PDCP sequence number (SN), and the function of sending the data to the upper layer in the reordered sequence. Alternatively, the reordering function of the NR PDCP device may include the function of directly sending the data to the upper layer without considering the sequence, the function of reordering the sequence and recording the lost PDCP PDUs, the function of providing a status report on the lost PDCP PDUs to the sending side, and the function of requesting retransmission of the lost PDCP PDUs.

[0110] The main functions of NR RLC 1d-10 and 1d-35 may include some of the following functions. NR RLC may perform various functions, not limited to the following examples.

[0111] -Transfer of upper-layer PDUs

[0112] -Ordered transfer of upper-layer PDUs

[0113] -Out-of-order transfer of upper-layer PDUs

[0114] -Error correction by ARQ

[0115] -Concatenation, segmentation, and reassembly of RLC SDUs

[0116] -Re-segmentation of RLC data PDUs

[0117] -Reordering of RLC data PDUs

[0118] -Duplicate detection

[0119] -Protocol error detection

[0120] -RLC SDU discard

[0121] -RLC reconstruction

[0122] The sequential transfer (or ID) function of the NR RLC device refers to the function of sequentially sending the RLC SDUs received from the lower layer to the upper layer. The sequential transfer function of the NR RLC device may include: when an RLC SDU is initially segmented into multiple RLC SDUs and received, the function of recombining and sending the multiple RLC SDUs, the function of reordering the received RLC PDUs based on the RLC sequence number (SN) or PDCP sequence number (SN), the function of reordering the sequence and recording the lost RLC PDUs, the function of providing a status report on the lost RLC PDUs to the sending side, the function of requesting retransmission of the lost RLC PDUs, the function of sequentially sending only the RLC SDUs before the lost RLC SDU to the upper layer when there are lost RLC SDUs, the function of sequentially sending all the RLC SDUs received before the start of a predetermined timer to the upper layer when the predetermined timer has expired even if there are lost RLC SDUs, or the function of sequentially sending all the RLC SDUs received so far to the upper layer when the predetermined timer has expired even if there are lost RLC SDUs.

[0123] In addition, according to the unsequential transfer function of the NR RLC device, the RLC PDUs can be processed in the order in which they are received (in the order of arrival, regardless of the order of the serial number or sequence number), and can be sent to the PDCP device in an unsequential transfer (or OOD) manner. The unsequential transfer function may include the functions of receiving segments stored in the buffer or segments to be received later, reconfiguring the segments into a complete RLC PDU, processing the RLC PDU, and sending the RLC PDU to the PDCP device. The NR RLC layer may not include the concatenation function, and the concatenation function may be performed by the NR MAC layer, or may be replaced by the multiplexing function of the NR MAC layer.

[0124] The unsequential transfer function of the NR RLC device may include the function of directly sending the RLC SDUs received from the lower layer to the upper layer regardless of their order. The unsequential transfer function of the RLC device may include: when an RLC SDU is initially segmented into multiple RLC SDUs and received, the function of recombining and sending the multiple RLC SDUs, and the function of storing the RLC SN or PDCP SN of the received RLC PDUs, reordering the sequence and recording the lost RLC PDUs.

[0125] NR MAC 1d-15 and 1d-30 can be connected to multiple NR RLC layer devices configured in a UE, and the main functions of NR MAC can include some of the following functions. NR MAC can perform various functions, not limited to the following examples.

[0126] - Mapping between logical channels and transport channels

[0127] - Multiplexing / demultiplexing of MAC SDUs

[0128] - Scheduling information reporting

[0129] - Error correction via HARQ

[0130] - Priority handling between logical channels of a UE

[0131] - Priority handling between UEs via dynamic scheduling

[0132] - MBMS service identification

[0133] - Transmission format selection

[0134] - Padding

[0135] NR PHY layers 1d-20 and 1d-25 can perform operations of channel encoding and modulation on upper layer data, forming the upper layer data into OFDM symbols, transmitting the OFDM symbols via a radio channel, or demodulating and channel decoding the OFDM symbols received via the radio channel, and delivering the OFDM symbols to the upper layer.

[0136] The present disclosure proposes a method for compressing and decompressing an Ethernet header when using an Ethernet protocol in a next-generation mobile communication system.

[0137] Figure 1e Illustrates a process in which a base station configures configuration information related to an Ethernet header protocol for a UE when the UE establishes a connection with a network, according to an embodiment of the present disclosure.

[0138] Figure 1e Illustrates a process in which a UE switches from RRC idle mode or RRC inactive mode (or light connection mode) to RRC connected mode and establishes a connection with a network. In addition, Figure 1e Illustrates a process in which a base station configures configuration information related to an Ethernet header protocol for a UE. Specifically, Figure 1eA process is shown that indicates whether to perform Ethernet header compression or decompression in a PDCP layer device, and whether to use Ethernet header compression or decompression in the downlink only, in the uplink only, or in both the uplink and downlink. The Ethernet header protocol-related configuration information can be configured only for UEs with UE capabilities that can use the Ethernet protocol, or only for UEs with UE capabilities that can use the Ethernet header compression and decompression process. When a UE reports its UE capabilities to the base station, the UE can define a new indicator and report to the base station whether the UE can use the Ethernet protocol or whether it can use the Ethernet header compression and decompression process. In addition, the base station can configure which type of Ethernet frame or Ethernet header will be used for each bearer or logical channel to determine which types of fields are configured in the Ethernet header, how many bytes the Ethernet header size is, how many bits the size of each field of the Ethernet header is, or how the fields of the Ethernet header are configured. In addition, in the case where padding is added to the Ethernet frame, the UE can indicate whether to configure the function of preventing the padding from being transmitted through the actual radio link by removing the padding at the sending end and adding the padding at the receiving end. In addition, when the base station sends an RRC message (e.g., a handover command message, an RRCReconfiguration message, an RRCSetup message, or an RRCResume message) to the UE to perform a handover process, the base station can define and configure an indicator (drb-ContinueEHC) to indicate whether to initialize the context for Ethernet header compression or decompression or whether to continue using the context, and thus can indicate whether to continue using the context for Ethernet header compression or decompression when the UE performs a handover process or a PDCP re-establishment process. In addition, the base station can configure the indicator (drb-ContinueEHC) to indicate whether to initialize or continue using the context for Ethernet header compression or decompression for each bearer, or the indicator can be configured for each PDCP layer device through the PDCP layer device configuration information (PDCP-config).

[0139] Reference Figure 1eWhen a UE that is used to perform data transmission or reception in the RRC connected mode does not perform data transmission or reception due to a predetermined reason or within a predetermined time, the base station may send an RRC connection release (RRCConnectionRelease) message to the UE to allow the UE to switch to the RRC idle mode or the RRC inactive mode (represented by reference numeral 1e-01). Subsequently, when data to be transmitted is generated, a UE that does not currently have a connection established with it (hereinafter referred to as an idle mode UE or an inactive UE) may perform an RRC connection establishment procedure or an RRC connection resume procedure with the base station. The UE establishes reverse transmission synchronization with the base station through a random access procedure and sends an RRC connection request (RRCConnectionRequest) message (in the case of a resume procedure, an RRCResumeRequest message) (represented by reference numeral 1e-05). The RRCConnectionRequest message may include a reason (establishmentCause) for establishing a connection with the identifier of the UE. The base station sends an RRC connection setup (RRCConnectionSetup) message, enabling the UE to establish an RRC connection (represented by reference numeral 1e-10).

[0140] The RRCConnectionSetup message (in the case of a resume procedure, the RRCResumeRequest message) may include information indicating whether to use the Ethernet protocol or the header compression and decompression process for each logical channel (i.e., logical channel configuration (channelconfig)), each bearer, each PDCP device (i.e., PDCP configuration (PDCP-config)), or each SDAP layer device. Additionally, more specifically, the RRCConnectionSetup message (in the case of a resume procedure, the RRCResumeRequest message) may indicate whether to use the Ethernet protocol or the Ethernet header compression and decompression process in each logical channel, bearer, or each PDCP device (or SDAP device), or only for a specific IP flow or a specific QoS flow. As another approach, the base station may configure the SDAP device with information about whether to apply the Ethernet protocol or whether to use the Ethernet header compression method for an IP flow or a QoS flow, such that the SDAP device can indicate to the PDCP device for each QoS flow whether to apply the Ethernet protocol or whether to use the Ethernet header compression method. According to another method, the SDAP layer device or the PDCP device may identify each QoS flow for itself and determine whether to apply the Ethernet protocol or the Ethernet header compression method. Additionally, when the RRCConnectionSetup message indicates whether to apply the Ethernet protocol or whether to use the Ethernet header compression method, the SDAP device may indicate predefined library or dictionary information to be used in whether to apply the Ethernet protocol or whether to use the Ethernet header compression method, an identifier for whether to apply the Ethernet protocol or whether to use the Ethernet header compression method, or the buffer size to be used. Additionally, the RRCConnectionSetup message may include a command for setting or releasing whether to apply the Ethernet protocol or for performing the Ethernet header compression method. Additionally, the base station may always configure whether to apply the Ethernet protocol or whether to use the Ethernet header compression method via an RLC acknowledged mode (AM) bearer (ARQ function, lossless mode with retransmission function) or via an RLC unacknowledged mode (UM) bearer, or may configure it together with a header compression protocol (e.g., ROHC). Additionally, the RRCConnectionSetup message may indicate whether to use the function of the SDAP layer device or the SDAP header for each logical channel (logicalchannelconfig), each bearer, or each PDCP device (PDCP configuration), or may indicate whether to use the function of the SDAP layer device or the SDAP header for each uplink or downlink configuration.The RRCConnectionSetup message may indicate whether ROHC (or IP packet header compression) is applied to each logical channel (i.e., via logical channel configuration), each bearer, or each PDCP device (i.e., PDCP configuration), and may configure via an indicator whether ROHC is applied separately to the uplink and downlink.

[0141] In addition, it may be configured separately for the uplink and downlink whether to use a user data compression method (UDC) for each logical channel, each bearer, or each PDCP device. That is, the user data compression method (UDC) may be configured for the uplink but not for the downlink. Conversely, the UDC may be configured not to be used for the uplink but to be used for the downlink. In addition, the UDC may be configured to be used in both directions. In addition, the base station may configure an Ethernet header compression process and a ROHC header compression process simultaneously via the RRCConnectionSetup message. In addition, the base station may define an indicator (drbEthHCContinue) via the RRCConnectionSetup message to indicate to continue using context or Ethernet header compression protocol-related configuration information without initializing it in the case of a handover (e.g., handover in the base station) or in the case of a handover from RRC Inactive mode to RRC Connected mode. In the case of reconstructing an SDAP layer device or a PDCP layer device, by considering this indicator, a UE that has received this indicator may continue to use Ethernet header compression protocol-related configuration information or context without initializing it. Therefore, the overhead caused by reconfiguration of the Ethernet header compression protocol can be reduced.

[0142] In addition, the RRCConnectionSetup message may define a new indicator and indicate the configuration information or context related to initializing the Ethernet header compression protocol. In addition, the RRCConnectionSetup message may configure whether to configure the SDAP protocol or the SDAP header. In addition, the RRCConnectionSetup message may configure which type of Ethernet frame or Ethernet header will be used for each bearer or logical channel to determine which types of fields are configured in the Ethernet header, how many bytes the Ethernet header size is, how many bits the size of each field of the Ethernet header is, or the method of configuring the fields of the Ethernet header. In addition, in the case where padding is added to the Ethernet frame, the base station may indicate whether to configure the function of preventing the padding from being transmitted through the actual radio link by removing the padding at the transmitting end and adding the padding at the receiving end. In addition, the base station may configure whether to use feedback when performing the Ethernet header compression or decompression process, and when it is configured to use feedback by defining a new indicator (or whether to use feedback can be performed by defining an indicator for each bearer or each PDCP layer device), the transmitting PDCP layer device at the transmitting end (UE or base station) may send data with a complete header (field values of the uncompressed complete header, context identifier, or an indicator indicating whether compression is performed) to the receiving PDCP layer device at the receiving end (base station or UE). When receiving data with a complete header from the transmitting PDCP layer device, the receiving PDCP layer device may configure feedback (context identifier or an indicator indicating successful reception) (e.g., an indicator of PDCP control data or the PDCP header) indicating that the complete header has been successfully received and send it to the transmitting PDCP layer device. The transmitting PDCP layer device may continue to send data segments with a complete header until it receives the feedback from the receiving PDCP layer device. Upon receiving the feedback, the transmitting PDCP layer device may perform a compression process on the Ethernet header of the data to be transmitted and may start sending data segments with a compressed Ethernet header. In addition, whenever the receiving PDCP layer device receives data with a complete header, the receiving PDCP layer device may send feedback. When receiving data with a complete header, the receiving PDCP layer device may store information about the complete header (e.g., a header including all field values of the Ethernet header or a header including information for separate Ethernet header compression (context identifier or whether compression is performed)), field values, or context identifier values in a buffer. In addition, when receiving a compressed data segment including an indicator indicating that the Ethernet header is compressed in a separate header (EHC header) for the Ethernet header compression process, the stored complete header information may be used to perform the Ethernet header decompression process.In addition, after configuring the feedback, when transmission occurs, the receiving PDCP layer device does not apply the integrity protection process to the feedback (e.g., PDCP control data (PDCP control PDU)), or may not apply the encryption process to it.

[0143] As another method, in the case of configuring the integrity protection process, the integrity protection process can be applied to the feedback to enhance security. In addition, when reading the received feedback, the transmitting PDCP layer device can allow the decoding process or the integrity verification process not to be applied, so that the feedback can be processed quickly. As another method, in the case of configuring the integrity protection process, the integrity verification process can be performed on the feedback to enhance security. When configured not to use the feedback by defining a new indicator, the transmitting PDCP layer device at the transmitting end (UE or base station) can send data with a complete header (field values of the uncompressed complete header, context identifier, or an indicator indicating whether compression is performed) to the receiving PDCP layer device at the receiving end (base station or terminal) a predetermined number of times (the number of transmissions can be configured by an RRC message or can be determined by the implementation). In addition, the transmitting PDCP layer device at the transmitting end (UE or base station) can send data with a complete header a predetermined number of times (once, twice, or more), and can immediately apply the Ethernet header compression process to the data to be transmitted thereafter, and send a data segment with a compressed header. In addition, when receiving data with a complete header, the receiving PDCP layer device can store information about the complete header (e.g., a header including all field values of the Ethernet header or a header including information for compressing a separate Ethernet header (context identifier or whether compression has occurred)), field values, or context identifier values in a buffer. In addition, when receiving a compressed data segment including an indicator indicating that the Ethernet header is compressed in a separate header (EHC header) for the Ethernet header compression process, the receiving PDCP layer device can perform the Ethernet header decompression process by using the stored complete header information.

[0144] As another method, when configuring the Ethernet header compression or decompression process, the RRCConnectionSetup message can configure the timer value for each bearer or for each PDCP layer device, and drive the timer to prevent a large amount of feedback from being generated in the receiving PDCP layer device, thereby preventing the generation of unnecessary feedback. For example, when the timer value is configured, when data with a complete header is received, the receiving PDCP layer device can generate and send feedback, and start the timer when the timer is not running. When data with an Ethernet header compression (EHC) header including an indicator indicating that the Ethernet header compression process has been performed is received, the receiving PDCP layer device can stop the corresponding timer. In addition, when the corresponding timer expires, the receiving PDCP layer device can generate feedback and send the generated feedback to the sending PDCP layer device, and can restart the timer again. In the above, the timer can be driven for each context identifier.

[0145] In addition, when receiving the RRCConnectionSetup message (in the case of a resume process, the RRCResume message), the RRCConnectionSetup message can indicate the following configuration information to the UE.

[0146] 1> It can be indicated for each bearer or in the PDCP layer device configuration information (PDCP configuration) whether to use the configuration information or the Ethernet header compression or decompression function for Ethernet header compression or decompression.

[0147] * When using a dedicated traffic channel (DTCH), a UM bearer (a PDCP layer device connected to the RLC layer device using the UM mode) can be configured to use the Ethernet header compression or decompression function.

[0148] * Only when using a dedicated traffic channel (DTCH) and / or not using a dedicated control channel (DCCH), an AM bearer (a PDCP layer device connected to the RLC layer device using the AM mode) can be configured to use the Ethernet header compression or decompression function.

[0149] In addition, the RRCConnectionSetup message (in the case of a resume procedure, the RRCResume message) may include RRC connection configuration information. The RRC connection is also referred to as a signaling radio bearer (SRB) and is used to send or receive RRC messages, where the RRC messages are control messages between the UE and the base station. The UE that has established the RRC connection may send an RRC connection setup complete (RRCConnetionSetupComplete) message (denoted by reference numeral 1e-15) to the base station. When the base station does not know the UE capabilities of the UE that is currently establishing the connection, or when the base station wishes to identify the UE capabilities, the base station may send a message asking for the UE capabilities. In addition, the UE may send a message reporting its own capabilities. The message reporting its own capabilities may indicate whether the UE is able to use the Ethernet protocol or is able to use the Ethernet header compression or decompression process, and may include an indicator indicating whether the UE is able to use the Ethernet protocol or is able to use the Ethernet header compression or decompression process. The RRCConnetionSetupComplete message may include a control message referred to as a service request (SERVICE REQUEST), where this control message is requested by the UE from the MME for bearer establishment for a predetermined service. The base station may send the service request message stored in the RRCConnetionSetupComplete message (denoted by reference numeral 1e-20) to the MME, and the MME may determine whether to provide the service requested by the UE. As a result of the determination, when the UE determines that the requested service is provided, the MME may send an initial context setup request (INITIAL CONTEXT SETUP REQUEST) message (denoted by reference numeral 1e-25) to the base station. The initial context setup request message may include information such as QoS information to be applied in the case of configuring a data radio bearer (DRB) and security-related information to be applied to the DRB (e.g., security keys and security algorithms). The base station may exchange a security mode command (SecurityModeCommand) message 1e-30 and a security mode complete (SecurityModeComplete) message 1e-35 in order to establish security with the UE. When the security configuration is complete, the base station may send an RRC connection reconfiguration (RRCConnectionReconfiguration) message (denoted by reference numeral 1e-40) to the UE.

[0150] The RRCConnectionReconfiguration message may include information indicating whether to use the Ethernet protocol or whether to use the header compression and decompression process for each logical channel (i.e., via logical channel configuration), each bearer, each PDCP device (i.e., via PDCP configuration), or each SDAP layer device. Additionally, more specifically, the base station may indicate whether to use the Ethernet protocol or the Ethernet header compression and decompression process in each logical channel, bearer, or each PDCP device (or SDAP device), or only for a specific IP flow or a specific QoS flow. As another method, the base station may configure the SDAP device with information about whether to apply the Ethernet protocol or whether to use the Ethernet header compression method for an IP flow or a QoS flow, such that the SDAP device may indicate to the PDCP device about whether to apply the Ethernet protocol or whether to use the Ethernet header compression method for each QoS flow. As another method, the SDAP layer device or the PDCP device may identify each QoS flow for itself and determine whether to apply the Ethernet protocol or the Ethernet header compression method. Additionally, when the RRCConnectionReconfiguration message indicates whether to apply the Ethernet protocol or whether to use the Ethernet header compression method, the base station may indicate the predefined library or dictionary information to be used in whether to apply the Ethernet protocol or whether to use the Ethernet header compression method, the identifier for whether to apply the Ethernet protocol or whether to use the Ethernet header compression method, or the buffer size to be used. Additionally, the RRCConnectionReconfiguration message may include a command for setting or releasing whether to apply the Ethernet protocol or to perform the Ethernet header compression method. Additionally, whether to apply the Ethernet protocol or to use the Ethernet header compression method may always be configured via the RLC AM bearer or the RLC UM bearer, or may be configured together with the header compression protocol (ROHC). Additionally, the RRCConnectionReconfiguration message may indicate whether to use the function of the SDAP layer device or the SDAP header for each logical channel (i.e., via logicalchannelconfig), each bearer, or each PDCP device (i.e., via PDCP configuration), or this indication may be configured separately via the uplink and the downlink. The RRCConnectionReconfiguration message may indicate whether to apply ROHC (IP packet header compression) for each logical channel (i.e., via logical channel configuration), each bearer, or each PDCP device (i.e., via PDCP configuration), and whether to apply ROHC separately for the uplink and the downlink may be configured via an indicator. Additionally, the base station may configure whether to use the user data compression method (UDC) for each logical channel, each bearer, or each PDCP device separately via the uplink and the downlink.That is to say, the base station can configure the User Data Compression method (UDC) for the uplink but not for the downlink. Conversely, the base station can configure the UDC not for the uplink but for the downlink. In addition, the UDC can be configured to be used in both directions. In addition, the RRCConnectionReconfiguration message can configure the Ethernet header compression process and the ROHC header compression process simultaneously. In addition, the RRCConnectionReconfiguration message can define an indicator (drbEthHCContinue) to indicate that in the case of a handover (e.g., handover in the base station) or in the case of a handover from the RRC inactive mode to the RRC connected mode, the context or the configuration information related to the Ethernet header compression protocol is continued to be used without initializing it. In the case of reconstructing the SDAP layer device or the PDCP layer device, by considering this indicator, the UE that has received this indicator can continue to use the configuration information or context related to the Ethernet header compression protocol without initializing it. Therefore, the overhead caused by the reconfiguration of the Ethernet header compression protocol can be reduced.

[0151] In addition, the RRCConnectionReconfiguration message can define a new indicator and indicate to initialize the context or the configuration information related to the Ethernet header compression protocol. In addition, the RRCConnectionReconfiguration RRC message can configure whether to configure the SDAP protocol or the SDAP header. In addition, the RRCConnectionReconfiguration message can configure which type of Ethernet frame or Ethernet header will be used for each bearer or logical channel to configure which type of field is configured in the Ethernet header, how many bytes the Ethernet header size is, how many bits the size of each field of the Ethernet header is, or the method of configuring the fields of the Ethernet header. In addition, in the case where padding is added to the Ethernet frame, the UE can indicate whether to configure the function of preventing the padding from being sent through the actual radio link by removing the padding at the sending end and adding the padding at the receiving end.

[0152] When receiving the RRCConnectionReconfiguration message, the RRCConnectionReconfiguration message can indicate the following configuration information to the UE.

[0153] 1> It can be indicated for each bearer or in the PDCP layer device configuration information (PDCP configuration) whether to use the configuration information or the Ethernet header compression or decompression function for Ethernet header compression or decompression.

[0154] *When using a dedicated traffic channel (DTCH), a UM bearer (a PDCP layer device connected to an RLC layer device using the UM mode) can be configured to use the Ethernet header compression or decompression function.

[0155] *Only when using a dedicated traffic channel (DTCH) and / or not using a dedicated control channel (DCCH), an AM bearer (a PDCP layer device connected to an RLC layer device using the AM mode) can be configured to use the Ethernet header compression or decompression function.

[0156] When the Ethernet header compression method (or the ROHC header compression method) and the uplink data compression (UDC) method are simultaneously configured by an RRC message (e.g., an RRCSetup message, an RRCResume message, or an RRCReconfiguration message), the data processing burden and complexity may increase, while the data compression rate does not increase significantly. Therefore, in an embodiment of the present invention, it is characterized in that the UDC compression method and the Ethernet header compression method (or the ROHC header compression method) are not configured simultaneously. That is, the Ethernet header compression method (or the ROHC header compression method) can be configured for each uplink or downlink of the PDCP layer device, and can be configured when the UDC compression method is not configured. In addition, the UDC compression method can also be configured for each uplink or downlink of the PDCP layer device, and can be configured when the Ethernet header compression method (or the ROHC header compression method) is not configured. However, in the above description, the Ethernet header compression method and the ROHC header compression method can be simultaneously configured by an RRC message to allow the header compression process to be independently performed for the Ethernet header or the Transmission Control Protocol / Internet Protocol (TCP / IP) header, thereby greatly improving the compression rate. In addition, since the Ethernet header compression method by an RRC message is a feedback-based method, the Ethernet header compression method cannot be applied via a one-way or unidirectional link (e.g., the bearer RLC UM layer device is applied, and data transmission is only possible in one direction), and therefore the Ethernet header compression method cannot be configured by an RRC message for a one-way or unidirectional link, and can only be configured via a bidirectional link. In addition, when the UDC compression method is configured via the downlink or uplink by an RRC message, the out-of-order delivery function cannot be configured in the LTE RLC layer device connected to the LTE or NR PDCP layer device configured with the UDC compression method. In addition, the UDC compression method or the UDC decompression method described in the present disclosure can be extended to the RLC UM mode, and thus can be configured for the uplink or downlink.

[0157] In addition, the RRC Connection Reconfiguration message includes configuration information of the DRB in which user data will be processed, and the UE can configure the DRB by applying this information and send an RRC Connection Reconfiguration Complete message (indicated by reference numeral 1e-45) to the base station. This message can be an RRC Connection Reconfiguration Complete message. The base station that has completed the DRB configuration of the UE can send an INITIAL CONTEXT SETUP COMPLETE message (indicated by reference numeral 1e-50) to the MME, and the MME that has received the initial context setup complete message can exchange an S1 BEARER SETUP message and an S1 BEARER SETUP RESPONSE message to establish an S1 bearer (indicated by reference numerals 1e-55 and 1e-60) with the S-GW. The S1 bearer can be a connection established between the S-GW and the base station for data transmission and can correspond one-to-one with the DRB. When the above process is completed, the UE sends data to the base station or receives data from the base station through the S-GW (indicated by reference numerals 1e-65 and 1e-70). In this way, the general data transmission process can largely include three operations: RRC connection configuration, security configuration, and DRB configuration. In addition, the base station can send an RRC Connection Reconfiguration message to the UE to perform configuration updates, additions, or changes (indicated by reference numeral 1e-75).

[0158] Figure 1f Discloses an Ethernet header compression (EthHC) method according to an embodiment of the present disclosure.

[0159] In Figure 1f , the high-layer data 1f-05 can be generated as data corresponding to services such as video transmission, photo transmission, web search, and LTE voice (VoLTE). The data segments generated by the application layer device can be processed through TCP / IP or User Datagram Protocol (UDP) corresponding to the network data transmission layer, or can be processed through the Ethernet protocol, and the corresponding headers 1f-10, 1f-15, and 1f-20 (high-layer headers or Ethernet headers) are configured and can be transmitted to the PDCP layer. When the PDCP layer receives data (PDCP SDU) from the high layer, the PDCP layer can perform the following process.

[0160] When a header compression (ROHC) or Ethernet header compression process is performed through an RRC message such as Figure 1eWhen 1e-10, 1e-40, or 1e-75) in is configured to be used in the PDCP layer, the transmitting end can compress the TCP / IP header via ROHC as shown by reference numeral 1f-21, and can perform an Ethernet header compression process on the Ethernet header 1f-20 in the PDCP layer device as shown by reference numeral 1f-22. In addition, the transmitting end can configure a separate Ethernet header compression (EHC) header 1f-40, which includes a field for indicating whether to compress the Ethernet header, a field for indicating which fields of the Ethernet header are compressed (omitted) or not compressed (not omitted), or a context identifier, and can configure the separate EHC header before the compressed header. When integrity protection or verification is configured, the transmitting end can perform integrity protection on the PDCP header, EHC header, compressed header, and data. In addition, the transmitting end can perform an encryption process on the EHC header, compressed header, and data, and can configure the PDCP PDU by configuring the PDCP header 1f-30. Here, the PDCP layer device can include a header compressor / decompressor, can determine whether to perform header compression on each data as configured via an RRC message, and can use the header compressor / decompressor. The transmitting end can use the header compressor in the transmitting PDCP layer device to compress the Ethernet header or the higher-layer header (e.g., TCP / IP header), and when integrity verification is configured, the transmitting end can perform integrity protection on the PDCP header, EHC header, compressed header, and data. In addition, the transmitting end can perform an encryption process on the EHC header, compressed header, and data, and can include the PDCP header 1f-30 to configure the PDCP PDU.

[0161] The receiving end can perform a decryption process on the EHC header, compressed header, and data in the receiving PDCP layer device. In addition, when an integrity protection or verification process is configured, the receiving end can perform integrity verification on the PDCP header, EHC header, compressed header, and data. In addition, the receiving end can perform header decompression on the Ethernet header or the higher-layer header (e.g., TCP / IP header) by using the header decompressor.

[0162] Figure 1f The process can be applied to the case where the UE performs downlink data header compression and uplink header compression. In addition, the description of the uplink data can equally apply to the downlink data.

[0163] A method for performing Ethernet header compression on an Ethernet header according to an embodiment of the present disclosure is a method of reducing the header size by omitting fields indicating or having fixed information and only indicating changed or to-be-changed information. Thus, initially, the transmitting end can send information by including complete header information and configuration information for compression (e.g., service (or service)-specific identifiers (types) of the Ethernet protocol, service (or service)-specific sequence numbers, information related to the compression ratio, or an indicator indicating whether compression has occurred). In addition, the transmitting end can omit or not send fields corresponding to information that has not changed compared to the complete information or fixed information initially sent (e.g., the transmitting address field or receiving address field (MAC address), preamble field, start of frame delimiter (SFD), or frame checksum (FCS), or Ethernet type field, etc.), and can configure the header by only including fields corresponding to changed information or information that can change, thereby reducing the size of the header. As another method, since compressible fields and non-compressible fields are distinguished, and the values of the compressible fields can be assumed to include the same values as the field values of the complete header initially sent, the transmitting end can only compress (or omit) and send the compressible fields, and can always send the non-compressible fields without being compressed (or omitted). In addition, when the value of even one of the compressible fields has changed from the field value of the complete header previously sent, the transmitting end can send the complete header again. In addition, each time a complete header is received, the receiving PDCP layer device can always send feedback indicating that the complete header has been received well to the transmitting PDCP layer device.

[0164] Figure 1g Illustrates the Ethernet header compression (EthHC) method proposed when configuring the SDAP header or layer device according to an embodiment of the present disclosure.

[0165] In Figure 1g High-layer data 1g-05 can be generated as data corresponding to services such as video transmission, photo transmission, web search, and VoLTE. The data segments generated by the application layer device can be processed by TCP / IP or UDP corresponding to the network data transmission layer, or can be processed by the Ethernet protocol and the SDAP layer device. The corresponding headers 1g-10, 1g-15, and 1g-20 (high-layer header, Ethernet header, or SDAP header) can be configured and can be transmitted to the PDCP layer. When the PDCP layer receives data (PDCP SDU) from the high layer, the PDCP layer can perform the following process.

[0166] When the header compression (ROHC) or Ethernet header compression process is through an RRC message (such as Figure 1eWhen 1e-10, 1e-40, or 1e-75) in [is] is configured to be used in the PDCP layer, the sender can compress the TCP / IP header via ROHC as shown by reference numeral 1g-21, and can perform an Ethernet header compression process on the Ethernet header except for the SDAP header in the PDCP layer device as shown by reference numeral 1g-22. In addition, the sender can configure a separate EHC header, which includes a field for indicating whether the Ethernet header is compressed, a field for indicating which fields of the Ethernet header are compressed (omitted) or not compressed (not omitted), or a context identifier, and can configure the separate EHC header before the compressed header. When integrity verification is configured, the sender can perform integrity protection on the SDAP header, PDCP header, EHC header, compressed header, and data. In addition, the sender can perform an encryption process on the compressed header, data, and EHC header except for the SDAP header, and can configure the PDCP PDU by configuring the PDCP header 1g-30.

[0167] The receiver can perform a decryption process on the compressed header, data, and EHC header except for the SDAP header in the receiving PDCP layer device. In addition, when the integrity protection or verification process is configured, the receiver can perform integrity verification on the PDCP header, EHC header, compressed header, and data. Here, the PDCP layer device includes a header compressor / decompressor, determines whether to perform header compression on each data as configured by an RRC message, and uses the header compressor / decompressor. The sender uses the header compressor in the sending PDCP layer device to compress the Ethernet header or the high-layer header (e.g., TCP / IP header), and the receiver uses the header decompressor in the receiving PDCP layer device to perform header decompression on the Ethernet header or the high-layer header (e.g., TCP / IP header).

[0168] Figure 1g The process can be applied to the case where the UE performs downlink data header compression as well as uplink header compression. In addition, the description of the uplink data can equally apply to the downlink data.

[0169] A method for performing Ethernet header compression on an Ethernet header according to an embodiment of the present disclosure is a method of reducing the header size by omitting fields indicating or having fixed information and only indicating changed or to-be-changed information. Therefore, only some information changes or will change. Thus, initially, the sending end can send information by including complete header information and configuration information for compression (e.g., a service (or service)-specific identifier (type) of the Ethernet protocol, a service (or service)-specific sequence number, information related to the compression ratio, or an indicator indicating whether compression has occurred). In addition, the sending end can omit or not send fields corresponding to information that has not changed compared to the complete information or fixed information initially sent (e.g., a sending address field or a receiving address field (MAC address), a preamble field, a frame start delimiter (SFD), or a frame checksum (FCS), or an Ethernet type field, etc.), and can configure the header by only including fields corresponding to changed information or information that can change, thereby reducing the size of the header. Alternatively, when receiving feedback indicating successful reception of data with a complete header, the sending end can compress the header fields, or can omit or not send fields corresponding to information that has not changed compared to the complete information or fixed information initially sent (e.g., a sending address field or a receiving address field (MAC address), a preamble field, a frame start delimiter (SFD), or a frame checksum (FCS), or an Ethernet type field, etc.), and can configure the header by only including fields corresponding to changed information or information that can change, thereby reducing the size of the header. As another method, since compressible fields and non-compressible fields are distinguished, and the values of the compressible fields can be assumed to include the same values as the field values of the complete header initially sent, the sending end can only compress (or omit) and send the compressible fields, and can always send the non-compressible fields without being compressed (or omitted). In addition, when the value of even one of the compressible fields has changed from the field value of the complete header previously sent, the sending end can send the complete header again. In addition, each time a complete header is received, the receiving PDCP layer device can always send feedback indicating that the complete header has been received well to the sending PDCP layer device.

[0170] The Ethernet header compression method according to an embodiment of the present disclosure may not be applicable to the SDAP control data (SDAP control PDU) and SDAP header of a high-layer device. Therefore, in a network implementation, the QoS information of the uncompressed SDAP control data or SDAP header can be read, and the transmission resources can be quickly scheduled. In addition, in a UE implementation, since the QoS information can be read from the SDAP control data or SDAP header before decompression at the receiving end, the implementation can be simplified. In addition, since the sending end can generate the SDAP control data or SDAP header in parallel with the header, data compression process, or encryption process of the PDCP layer device, the data processing time can be reduced. In addition, the sending PDCP layer device or the receiving PDCP layer device can identify the 1-bit indicator of the SDAP header of the data received from the high-layer device or the low-layer device to distinguish whether it is SDAP control data (SDAP control PDU) or SDAP user data (SDAP data PDU) with an SDAP header, and can perform the data processing as described above. In another method, the sending PDCP layer device or the receiving PDCP layer device can identify the size of the data received from the high-layer device or the low-layer device (for example, whether the data size exceeds 1 byte. When the data size is 1 byte, it can be determined as SDAP control data, and when the data size exceeds 1 byte, it can be determined as SDAP user data) to distinguish whether it is SDAP control data (SDAP control PDU) or SDAP user data (SDAP data PDU) with an SDAP header, and can perform the data processing as described above.

[0171] Figure 1h Fig. shows yet another Ethernet header compression (EthHC) method proposed when configuring an SDAP header or layer device according to an embodiment of the present disclosure.

[0172] In Figure 1h , the high-layer data 1h-05 can be generated as data corresponding to services such as video transmission, photo transmission, web search, and VoLTE. The data segment generated by the application layer device can be processed by TCP / IP or UDP corresponding to the network data transmission layer, or can be processed by the Ethernet protocol and the SDAP layer device. The corresponding headers 1h-10, 1h-15, and 1h-20 (high-layer header, Ethernet header, or SDAP header) can be configured and transmitted to the PDCP layer. When the PDCP layer receives data (PDCP SDU) from the high layer, the PDCP layer can perform the following process.

[0173] When the header compression (ROHC) or Ethernet header compression process is through an RRC message (such as Figure 1eWhen 1e-10, 1e-40, or 1e-75 in [description] is configured to be used in the PDCP layer, the sender can compress the TCP / IP header via ROHC as shown in 1h-21, and can perform an Ethernet header compression process on the SDAP header and the Ethernet header 1h-20 in the PDCP layer device as shown in 1h-22. In addition, the sender can configure a separate EHC header, which includes a field for indicating whether to compress the SDAP header and the Ethernet header, or a field for indicating which fields of the SDAP header or the Ethernet header are compressed (omitted) or not compressed (not omitted), and can configure the separate EHC header before compressing the header. When integrity verification is configured, the sender can perform integrity protection on the PDCP header, the EHC header, the compressed header (compressed SDAP header, compressed Ethernet header, or compressed TCP / IP header), and the data, can perform an encryption process on the EHC header, the compressed header (compressed SDAP header, compressed Ethernet header, or compressed TCP / IP header), and the data, or the compressed header and the data excluding the EHC header (compressed SDAP header, compressed Ethernet header, or compressed TCP / IP header), and can configure the PDCP PDU by configuring the PDCP header 1h-30. Here, the PDCP layer device can include a header compressor / decompressor, can determine whether to perform header compression on each data as configured through the RRC message, and can use the header compressor / decompressor. The sender can use the header compressor in the sending PDCP layer device to compress the Ethernet header or the high-layer header (e.g., the TCP / IP header), and the receiver can use the header decompressor in the receiving PDCP layer device to perform header decompression of the Ethernet header or the high-layer header (e.g., the TCP / IP header).

[0174] Figure 1h The process can be applied to the case where the UE performs downlink data header compression and uplink header compression. In addition, the description of the uplink data can equally apply to the downlink data.

[0175] The method for performing Ethernet header compression on an Ethernet header according to an embodiment of the present disclosure is a method of reducing the header size by omitting fields indicating fixed information and only indicating changed information. Thus, initially, the transmitting end can send information by including complete header information and configuration information for compression (e.g., service (or service)-specific identifiers (types) of the Ethernet protocol, service (or service)-specific sequence numbers, information related to the compression ratio, etc.). In addition, the transmitting end can omit or not send fields corresponding to information that has not changed compared to the complete information initially sent (e.g., the transmitting address field or the receiving address field (MAC address), the preamble field, the start frame delimiter (SFD) or the frame checksum (FCS), or the Ethernet type field, etc.), and can configure the header by only including fields corresponding to the changed information, thereby reducing the size of the header. As another method, the transmitting end can distinguish compressible fields and non-compressible fields, and when the value of a compressible field has not changed compared to the value of the field in the initially sent complete header, the transmitting end can only compress (or omit) the compressible field and send it, and can always send the non-compressible field without being compressed (or omitted). In addition, when the value of even one of the compressible fields has changed from the value of the field in the previously sent complete header, the transmitting end can send the complete header again. In addition, each time a complete header is received, the receiving PDCP layer device can always send feedback indicating that the complete header has been received well to the transmitting PDCP layer device.

[0176] The Ethernet header compression method as described above can be equivalently applied to the SDAP header as well as the Ethernet header to compress the SDAP header. This is because the data / control (D / C) field, the QoS flow identifier (QFI) field, the reflective QoS indicator (RQI) field, and the reflective QoS flow to DRB mapping indication (RDI) field configured in the SDAP header (uplink or downlink) usually have fixed values. Specifically, the QFI field has an almost fixed value, and the RQI field or the RDI field is not used except when the base station indicates that a QoS mapping update is required. Therefore, by applying the method for compressing the Ethernet header to the SDAP header, the SDAP header is compressed together with the Ethernet header. When header compression is applied to the SDAP header as described above, the SDAP header can be encrypted, and the same compression method can be provided to the LTE system and the NR system that can configure the SDAP header for easy implementation.

[0177] In addition, the header compression algorithm according to an embodiment of the present disclosure may be applied only to PDCP user data (PDCP data PDU) received from a higher layer, and may not be applied to PDCP control data (PDCP control PDU) generated by a PDCP layer device.

[0178] In the Ethernet header compression protocol 1h-22 according to an embodiment of the present disclosure, in the case of receiving data from a higher layer device, the PDCP layer device may identify an Ethernet header, compress the Ethernet header by using a protocol for compressing the Ethernet header, and define and use a new header 1h-30 before the compressed Ethernet header. Here, encryption of the new header 1h-30 is performed. This is because the new header is considered as data generated by the PDCP layer device, and data processing is performed together with the data, so that the data processing process can be simplified and security can be enhanced.

[0179] In the case of applying the header compression method according to an embodiment of the present disclosure, in order to decompress the compressed Ethernet header on the receiving end side, it is necessary to know which fields are compressed, omitted, or not sent. Therefore, when the transmitter side compresses the Ethernet header, a new header (for example, an EHC header) may be defined and placed in front of the compressed Ethernet header and then sent. The transmitter side may define a new first field in the new EthHC header to indicate which field among a plurality of fields of the Ethernet header is compressed, omitted, or not sent (for example, a context identifier). According to another method, each bit in a bitmap format may be used for the new field to indicate whether a specific field has been compressed (or omitted or not sent) or not compressed (or included or sent). In addition, since the first field may indicate which field in the Ethernet header has been compressed (or omitted) or not compressed (or included), the receiving end side may use the first field to calculate the size of the received compressed Ethernet header. That is, by subtracting the size of the omitted header fields from the size of the original Ethernet header, the size of the compressed Ethernet header can be known.

[0180] In addition, the first field may include a mapping for indicating whether compression (or omission) is performed on all fields of the Ethernet header. However, by only allowing the compressible (or omissible) fields among the fields of the Ethernet header to have a mapping indicating whether to compress (or omit), the overhead of the new EthHC header can be reduced. For example, the information about the compressible fields may be known or committed by the transmitting PDCP layer device or the receiving PDCP layer device, or may be configured through an RRC message, and the first field is a 1-bit indicator, and can indicate whether all compressible fields are compressed or uncompressed. That is, a 1-bit indicator can be defined in the new EHC header to indicate whether the Ethernet header (or SDAP header) is compressed or no compression is applied. The 1-bit indicator can be defined and used in the PDCP header.

[0181] In addition, when the Ethernet header includes multiple size types, or when multiple QoS flows are mapped to one PDCP layer device, a second field is defined, and the type of field, different QoS flows, or different services can be distinguished by an identifier. For example, a context identifier is defined and can be used during the Ethernet header compression or decompression process. In addition, the EHC header can indicate the size or length of the compressed Ethernet header in the third field, so as to accurately indicate the size of the compressed Ethernet header (for example, for ease of implementation).

[0182] According to another method, identifiers indicating multiple Ethernet header compression methods can be defined and used separately in the EHC header. In addition, the identifier can indicate the Ethernet header type or the QoS flow identifier. Since multiple higher-layer headers with different header structures (for example, various types of Ethernet headers) are configured by different fields, it is necessary to change the methods of compressing and non-compressing fields according to the field type. Therefore, for example, the first identifier indicating the header type or content can indicate the application of the first Ethernet header compression method, while the second identifier can indicate the application of the second Ethernet header compression method. Therefore, when multiple data streams or QoS flows are mapped to one PDCP layer device, different header compression methods can be applied by applying new identifiers, and the receiving end can distinguish the compression methods and perform different decompression methods.

[0183] The Ethernet header compression method according to the embodiments of the present disclosure can be applied not only to the Ethernet header, but also to general higher-layer device headers. For convenience, in the present disclosure, the header compression method is referred to as the Ethernet header compression method.

[0184] In addition, the configuration of the Ethernet header fields according to the Ethernet header type can be configured for each bearer through an RRC message, such that Figure 1eConfigure which type of Ethernet header or header fields. For example, header compression or decompression methods can be adopted by configuring information in the higher-layer header types (e.g., Ethernet header types) that can be configured in each bearer's higher-layer device and configuring the identifiers mapped to each header type. That is, an identifier or indicator indicating the Ethernet header type can be defined and used in the new header. In addition, the receiving end of the new header can include a checksum field, and in this checksum field, it is determined whether the Ethernet header is successfully decompressed. Alternatively, a field indicating the initialization of the buffer for compression of the PDCP layer device for transmission and the buffer for decompression of the PDCP layer device for reception can be defined and used. The fields defined in the new header can be defined and used in the PDCP header or the SDAP header.

[0185] In addition, when the receiving PDCP layer device successfully receives data, the new EHC header can define and use a field indicating a feedback request. That is, instead of always sending feedback every time the receiving-end PDCP layer device receives a complete header, feedback transmission can be performed only when the sending-end PDCP layer device requests feedback via an indicator, so as to reduce overhead.

[0186] Based on the new EHC header, another Ethernet header compression method can be used. For example, when the sending end compresses the Ethernet header, compression is performed sequentially. During compression, when the value of the header field has not changed compared to the value of the field in the previously transmitted Ethernet header, the Ethernet header is compressed (omitted), and the first field (e.g., an indicator indicating whether compression is performed or a context identifier) is configured accordingly. When the Ethernet header field value is different from the value of the previously transmitted Ethernet header field, the Ethernet header is decompressed (included) and the first field can be configured accordingly, so that the Ethernet header compression can be completed. Here, the Ethernet header compression can be performed in ascending order based on the PDCP sequence number or count (COUNT) value, and the previous Ethernet header can indicate the Ethernet header corresponding to the data, which has a value that is 1 less than the PDCP sequence number or count value.

[0187] Upon receiving a compressed Ethernet header, the receiving end can identify the first field, and when the compressed (omitted) field in the Ethernet header has the same value as the field of the previously received Ethernet header or the field of the stored complete header, the receiving end can reconstruct the compressed (omitted) field in the Ethernet header accordingly and can newly update the field value stored in the buffer to the uncompressed (included) field. The sending end and the receiving end can have separate buffers for compressing the Ethernet header, can update the buffer each time the Ethernet header is compressed, and can update the buffer each time the Ethernet header is decompressed. When the compressed Ethernet header is reconstructed, the receiving end can remove the new EthHC header and send the reconstructed data to the upper layer. In addition, when initially sending the Ethernet header, the sending end can send the complete Ethernet header information. That is, initially, the receiving end can send the Ethernet header without performing Ethernet header compression so that the receiving end can identify the complete Ethernet header information.

[0188] In the following, specific embodiments of an Ethernet header compression method according to embodiments of the present disclosure are presented.

[0189] Figure 1i A specific first embodiment of an Ethernet header compression method according to embodiments of the present disclosure is shown.

[0190] The method of compressing an Ethernet header by a transmitting end according to a first embodiment of the present disclosure is a method for omitting fields in the Ethernet header that have unchanged field values among a plurality of header fields 1i-31, 1i-32, 1i-33, 1i-34, 1i-35, 1i-36, 1i-37, fields that have unchanged field values compared to a previously transmitted Ethernet header, fields that have Ethernet header field values that do not need to be transmitted, or fields that have fixed values, and selectively transmitting necessary fields, valid fields, fields with changed field values, or fields with changed values instead of fields with fixed values by the transmitting end. Therefore, among the plurality of fields included in the Ethernet header, for example, among the first field 1i-31, the second field 1i-32, the third field 1i-33, the fourth field 1i-34, the fifth field 1i-35, the sixth field 1i-36, or the seventh field 1i-37, when the first field 1i-31, the second field 1i-32, the fourth field 1i-34, the fifth field 1i-35, or the seventh field 1i-37 has a fixed value, is omissible, or does not need to be transmitted, or their field values are the same as the field values of the previously transmitted Ethernet header fields, the method of compressing the Ethernet header is a method in which the transmitting end only transmits the third field 1i-33 and the sixth field 1i-36. Here, information about fields with fixed values or compressible fields may be known or committed by the transmitting PDCP layer device or the receiving PDCP layer device, or may be configured through an RRC message, and whether a field is compressed can be indicated by a 1-bit indicator by introducing a first field indicating whether all compressible fields are compressed.

[0191] In addition, a description will be given of separately configuring a new EHC header to perform compression and decompression at a receiving end by applying the method according to an embodiment of the present disclosure. In a first embodiment of the present disclosure, the new EHC header may have a bitmap structure 1i-11 and 1i-12. That is, the bitmap structure may include as many bits as the number of fields of the header structure to which compression is applied, and may indicate whether the header field corresponding to each bit is compressed or not as a value of 0 or 1. According to another method, the bitmap structure may include as many bits as the number of compressible fields of the header structure to which compression is applied, and may indicate whether the header field corresponding to each bit is compressed or not as a value of 0 or 1. According to another embodiment, the bitmap field may be configured by 1 bit, information about fields with fixed values or compressible fields may be known or committed by the transmitting PDCP layer device or the receiving PDCP layer device, or may be configured through an RRC message, and the 1-bit indicator may indicate whether the corresponding field is compressed, and may indicate whether all compressible fields are compressed or not.

[0192] For example, as Figure 1iAs shown, when the PDCP layer device at the transmitting end receives Ethernet frame 1i-05 from a higher-layer device and when the Ethernet header compression process is configured, the PDCP layer device may store the respective field values of the Ethernet header of the first received Ethernet frame in buffer 1i-15 for transmitting Ethernet compression. The PDCP layer device may transmit the complete header of the first Ethernet frame without Ethernet header compression. When feedback indicating the normal reception of the complete header is received from the receiving PDCP layer device, the application of the Ethernet compression process may be started. Here, multiple complete headers may be transmitted. For example, multiple complete headers and data (first data, second data, and subsequent data) may be transmitted until feedback indicating the normal reception of the complete header is received from the receiving PDCP layer device.

[0193] Here, when the Ethernet compression process starts and when the next Ethernet frame is received, the transmitting end may compare each field value of the Ethernet header with the field values stored in the transmitting buffer for Ethernet compression. When the Ethernet header has a field with the same value as the field value stored in the transmitting buffer, the transmitting end may omit the corresponding field, may configure the bits corresponding to or mapped to the omitted field as 1 (or 0), and may indicate that the corresponding field is omitted. When comparing each field value of the Ethernet header of the second Ethernet frame with the field values stored in the transmitting buffer for Ethernet compression and when the Ethernet header has a field with a different value from the field value stored in the transmitting buffer, the transmitting end may not omit the corresponding field, may configure the bits corresponding to or mapped to the non-omitted field as 0 (or 1), and may indicate that the field is not omitted.

[0194] In addition, when integrity protection is configured, the transmitting end may perform integrity protection, may perform an encryption process, may configure new header 1i-10, and configure the PDCP header to splice the new header and the PDCP header and transmit it to the lower-layer device.

[0195] Here, new header 1i-10 may allow each bit to indicate which field of the Ethernet header is present (not compressed) or missing (compressed), such as a bitmap. According to another method, the bitmap field may be configured by 1 bit, information about fields with fixed values or compressible fields may be known or committed by the transmitting PDCP layer device or the receiving PDCP layer device, or may be configured through an RRC message, and the 1-bit indicator may indicate whether the corresponding field is compressed and may indicate whether all compressible fields are compressed or not compressed.

[0196] Here, the transmitting end can define new fields (e.g., a 1-bit indicator) in the new header 1i-10 to indicate whether the Ethernet header compression process has been performed. The transmitting end can allow the 1-bit indicator to directly indicate the case where the Ethernet header compression has not been performed, so that the receiving end can avoid processing the new header or the uncompressed upper-layer header. The 1-bit indicator can be defined at the forefront of the new EHC header (which always exists when the Ethernet header compression algorithm is configured), so that the receiving end can directly identify whether the compression has been performed. In addition, here, a 1-bit indicator indicating whether the Ethernet header compression process has been performed can be defined and used in the SDAP header or the PDCP header. When the 1-bit indicator is defined in the SDAP header or the PDCP header and the Ethernet header compression process has not been performed, the overhead can be reduced because the transmitting end can omit the new header 1i-10 for Ethernet header compression. In addition, the case where all bit values in the bitmap field are configured as 0 (or 1) can be defined and used as a special value indicating the uncompressed complete header (represented by the reference numeral 1i-26), or can indicate the initialization of the buffer for compression of the PDCP layer device for transmission and the buffer for decompression of the PDCP layer device for reception.

[0197] At Figure 1iIn this case, the PDCP layer device or the SDAP layer device at the receiving end can receive the compressed Ethernet frame 1i-25 from the lower layer device and perform decryption on it. When integrity protection is configured, integrity verification can be performed, and when the Ethernet header compression process is configured, the respective field values of the Ethernet header of the Ethernet frame with the first received uncompressed complete header can be identified and the field values can be stored in the receive buffer 1i-30 for Ethernet decompression at the receiving end. In addition, when a complete header (e.g., an SDAP header or an Ethernet header) is successfully received, the receiving end can send feedback indicating the successful reception of the complete header to the transmitting PDCP layer device so that the application of Ethernet header compression can be started. In an embodiment, the receiving end can send the first Ethernet frame to the higher layer device without decompressing the Ethernet header. Then, when the next Ethernet frame is received, the receiving end can decrypt the next Ethernet frame, identify the new EHC header to check whether the new EHC header is compressed or uncompressed, and when the new EHC header is uncompressed and integrity protection is configured, the receiving end can perform integrity verification, can remove the EHC header, and can send the data to the higher layer. When the new EHC header indicates that the Ethernet header (or SDAP header) is compressed, the receiving end checks the field values of the new header 1i-10 for Ethernet compression to determine which fields are omitted (compressed) and which fields are not omitted (uncompressed). In addition, the receiving end can reconstruct the values of the fields indicated as omitted (compressed) into the field values stored in the receive buffer 1i-30 for Ethernet decompression so as to reconstruct (decompress) the Ethernet header before compression. Since the values of the fields indicated as not omitted (uncompressed) are new or changed values, the receiving end can store the new or changed values as field values according to the fields in the receive buffer for decompression. In addition, the receiving end can configure the Ethernet frame together with the reconstructed Ethernet header and send it to the higher layer device.

[0198] In the case where the field values of the Ethernet header are changed while the PDCP layer device at the transmitting side applies the Ethernet header compression method, the PDCP layer device at the transmitting side indicates to the new EHC header that the Ethernet header is not compressed, and transmits the complete header to initialize the buffer at the receiving end, and configures the buffer to again have the value of the complete header. When receiving the uncompressed complete header, the receiving PDCP layer device may send feedback to the transmitting PDCP layer device indicating successful reception of the uncompressed complete header. In the present disclosure, each time the receiving PDCP layer device receives an uncompressed complete header, the receiving PDCP layer device may always send feedback to the transmitting PDCP layer device indicating successful reception of the uncompressed complete header. In addition, in the present disclosure, when receiving an uncompressed complete high-layer header, the receiving PDCP layer device always sends feedback to the transmitting PDCP layer device indicating successful reception of the uncompressed complete high-layer header, but does not send feedback in the case of receiving an uncompressed high-layer header. The receiving PDCP layer device performs different operations according to whether high-layer compression of the received data is performed.

[0199] A separate new EHC header may have a fixed size (e.g., 1 byte or 2 bytes).

[0200] In addition, in an embodiment, the transmitting end and the receiving end may perform compression or decompression of the length field of the Ethernet header by applying the above method. According to another method, the transmitting end and the receiving end may always transmit the length field of the Ethernet header without being compressed.

[0201] According to another method, the transmitting end always transmits the length field of the Ethernet header without being compressed. The receiving PDCP layer device may calculate the length of the Ethernet frame by decompressing the remaining fields except the length field and then adding the length of the length field (since the length of the length field is a fixed value), and then the PDCP layer device may reconstruct the length value and add the reconstructed length value to the length field of the Ethernet frame. Therefore, the indication of the length field may be omitted in the new EHC header, and even when the length field value is different for each data, the PDCP layer device at the transmitting side may always omit (compress) the length field and perform transmission, and the receiving PDCP layer device may calculate and deduce the length field value according to the above description, so as to always reconstruct the length field value of the Ethernet header.

[0202] In addition, when the receiving-end PDCP layer device successfully receives data, the new EHC header may define and use a field indicating a feedback request. That is, instead of always sending feedback each time the receiving-end PDCP layer device receives a complete header, the feedback transmission may occur only when the transmitting-end PDCP layer device requests feedback via an indicator, so as to reduce overhead.

[0203] In addition, the sender and the receiver can define identifiers indicating multiple Ethernet header compression methods and bitmap fields in the new EHC header, and can use them. The identifiers can also indicate the Ethernet header type or the QoS flow identifier. This is because multiple upper-layer headers with different header structures (e.g., various types of Ethernet headers) are configured with different fields, and the method of whether to compress the fields needs to be changed according to the field type, and the bitmap field corresponding to the fields of the upper-layer header type needs to be applied accordingly. Therefore, for example, the first identifier indicating the header type or content can indicate the application of the first bitmap field or bitmap mapping, while the second identifier can indicate the application of the second bitmap field or bitmap mapping. Therefore, when multiple data streams or QoS streams are mapped to one PDCP layer device, different header compression methods can be applied by applying the new identifiers, and the receiver can distinguish the compression methods and perform different decompression methods. Here, in order to apply different header compression and decompression methods to data streams with different upper-layer header structures, for each upper-layer header structure, the upper-layer header field values are independently stored in the buffer of the sending PDCP layer device or the buffer of the receiving PDCP layer device.

[0204] Figure 1j Shows a specific second embodiment of the Ethernet header compression method according to an embodiment of the present disclosure.

[0205] In the second embodiment of the present disclosure, when multiple data streams or QoS streams are mapped to one bearer or one PDCP layer device, a method of applying different header compression and decompression methods according to the data streams with the header structures of different upper-layer devices or QoS streams is applied.

[0206] The second embodiment is characterized in that a fixed and unique header compression and decompression method is applied to each header structure of different upper-layer devices (e.g., Ethernet header structure or SDAP header structure). For example, the second embodiment can define compressible (or omissible) fields and non-compressible (or non-omissible) fields in the first upper-layer header structure 1j-01. In addition, the second embodiment can define compressible (or omissible) fields and non-compressible (or non-omissible) fields in the second upper-layer header structure 1j-02. In addition, the new EHC header can be configured with an identifier (compressed type identifier (CTI) field) indicating different upper-layer header structures, and can indicate the method of compressing the upper-layer device header structure to the receiving PDCP layer device.

[0207] For example, the transmitting PDCP layer device may store the high-layer header field value of the data received from the high layer with the first high-layer header structure in the transmission buffer 1j-15, may transmit the data including the complete header (without performing compression on it during the first transmission), and may apply the header compression method when receiving feedback indicating successful reception of the complete header information from the receiving PDCP layer device. That is, when all the field values of the compressible fields among the high-layer header field values of the next received data are the same as the field values stored in the transmission buffer, the transmitting end may compress all the compressible fields, configure the non-compressible fields as they are, and may configure an identifier indicating the first high-layer header structure and an indicator indicating that compression has been performed (compressed field (C field)), and transmit it to the new EHC header 1j-10.

[0208] When the new EHC header of the received data indicates that the high-layer header is not compressed, the receiving PDCP layer device regards the new EHC header of the received data as the complete high-layer header (when the field value of one or more fields among the compressible fields is changed, the transmitting PDCP layer device may transmit the complete high-layer header without performing compression on the high-layer header to indicate that the field value stored in the buffer of the receiving PDCP layer device will be updated), and the receiving end may update the field value stored in the buffer 1j-30 with the field value of the received field value of the complete high-layer header, and send feedback indicating successful reception to the transmitting PDCP layer device.

[0209] When the new EHC header of the received data indicates that the high-layer header is compressed, the receiving PDCP layer device may identify the identifier indicating the type of the high-layer header included in the new EHC header, and may reconstruct the fields defined as compressible in the high-layer header structure indicated by the identifier based on the field values stored in the receiving buffer. For example, the identifier indicating the type of the high-layer header may indicate the first high-layer header structure (the fields that can be compressed and decompressed in the first high-layer header structure), and may indicate the second high-layer header structure (the fields that can be compressed and decompressed in the second high-layer header structure).

[0210] In the second embodiment of the present disclosure, each time the receiving PDCP layer device receives an uncompressed complete header, it may always send feedback indicating successful reception of the complete header to the transmitting PDCP layer device. In addition, in the present disclosure, each time the receiving PDCP layer device receives an uncompressed complete high-layer header, it may always send feedback indicating successful reception of the uncompressed complete high-layer header to the transmitting PDCP layer device. However, when receiving an uncompressed high-layer header, the receiving PDCP layer device may not send feedback. The receiving PDCP layer device performs different operations according to whether high-layer compression of the received data is performed.

[0211] In addition, in the second embodiment, in order to apply different header compression and decompression methods to data streams with different higher-layer header structures, for each higher-layer header structure, the higher-layer header field values are independently stored in the buffer of the transmitting PDCP layer device or the buffer of the receiving PDCP layer device.

[0212] The transmitter and receiver can define in the new EHC header an identifier indicating each of a plurality of Ethernet header compression methods and an indicator field indicating whether compression has been performed, and can use them. The identifier can also indicate the Ethernet header type or the QoS flow identifier. This is because multiple higher-layer headers with different header structures (e.g., various types of Ethernet headers) are configured with different fields, and the methods for compressing or not compressing specific fields are applied differently according to them. Thus, for example, a first identifier indicating the header type or content can indicate the application of a first Ethernet header compression method, while a second identifier can indicate the application of a second Ethernet header compression method. Therefore, when multiple data streams or QoS flows are mapped to one PDCP layer device, different header compression methods can be applied by applying the new identifier, and the receiver can distinguish the header compression methods and perform different decompression methods.

[0213] When receiving feedback from the receiving PDCP layer device indicating the normal reception of a complete header, the transmitting PDCP device can start applying the Ethernet compression process. Here, multiple complete headers can be sent. For example, multiple complete headers and data (first data, second data, and subsequent data) can be sent until feedback indicating the successful reception of a complete header is received from the receiving PDCP layer device.

[0214] In an embodiment of the present disclosure, in the new header 1j-10, a new field (e.g., a 1-bit indicator) may be defined to indicate whether an Ethernet header compression process has been performed. The 1-bit indicator may directly indicate the case where the Ethernet header compression has not been performed, so that the receiving end can avoid processing the new header and the uncompressed upper-layer header. The 1-bit indicator may be defined to be at the front of the new EHC header (which always exists when the Ethernet header compression algorithm is configured), so that the receiving end can directly identify whether the compression has been performed. In addition, a 1-bit indicator indicating whether the Ethernet header compression process has been performed may be defined and used in the SDAP header or the PDCP header. When the 1-bit indicator is defined in the SDAP header or the PDCP header, the overhead can be reduced in the case where the Ethernet header compression process has not been performed, because the new header 1j-10 for Ethernet header compression can be omitted. In addition, the case where the bitmap field is configured to have an all-zero (or one) value may be defined and used as a special value indicating the uncompressed complete header, or may also indicate initializing the buffer for compression of the PDCP layer device for transmission and the buffer for decompression of the PDCP layer device for reception.

[0215] In Figure 1jIn this case, the PDCP layer device or the SDAP layer device in the receiving end can receive a compressed Ethernet frame from the lower layer device. When the Ethernet header compression process is configured, the PDCP layer device or the SDAP layer device can identify the respective field values of the Ethernet header of the Ethernet frame with the uncompressed complete header received for the first time, and store the field values in buffer 1j-30 for decompressing the received Ethernet. In addition, when a complete header (e.g., an SDAP header or an Ethernet header) is successfully received, the receiving end can send feedback related thereto to the transmitting PDCP layer device to start applying Ethernet header compression. In an embodiment, the receiving end can send the first Ethernet frame to the higher layer device without decompressing the Ethernet header. Then, when receiving the next Ethernet frame, the receiving end can decrypt the next Ethernet frame and identify the new EHC header to check whether the header is compressed. When the new EHC header is not compressed, the receiving end can perform its integrity verification, remove the EHC header, and can send the data to the higher layer. When the new EHC header indicates that the Ethernet header (or SDAP header) is compressed, the receiving end can identify the field values of the new header 1j-10 for Ethernet compression to determine which fields are omitted (compressed) and which fields are not omitted (uncompressed). In addition, the receiving end can reconstruct the values of the fields indicated as omitted (compressed) in the above description into the field values stored in the receiving buffer for decompression, so as to reconstruct (decompress) the Ethernet header before compression. Since the values of the fields indicated as not omitted (uncompressed) are new or changed values, the receiving end can store the new or changed values as field values according to the fields in the receiving buffer for decompression. In addition, the receiving end performs decryption, and when integrity protection is configured, the receiving end performs integrity verification. When there is no error, the receiving end can configure the Ethernet frame together with the reconstructed Ethernet header and send it to the higher layer device.

[0216] When the field value of the Ethernet header is changed while the Ethernet header compression method is applied in the transmitting PDCP layer device, the transmitting PDCP layer device indicates to the new EHC header that the field value is not compressed, and transmits the complete header to initialize the buffer at the receiving end, and the buffer can be reconfigured to have the value of the complete header again. Then, upon receiving the uncompressed complete header, the receiving PDCP layer device can send feedback to the transmitting PDCP layer device indicating successful reception of the uncompressed complete header. In the present disclosure, each time the receiving PDCP layer device receives an uncompressed complete header, the receiving PDCP layer device can always send feedback to the transmitting PDCP layer device indicating successful reception of the uncompressed complete header. In addition, in the present disclosure, upon receiving an uncompressed complete higher layer header, the receiving PDCP layer device can always send feedback to the transmitting PDCP layer device indicating successful reception of the uncompressed complete higher layer header. However, upon receiving an uncompressed higher layer header, the receiving PDCP layer device may not send feedback and can perform different operations according to whether the received data is compressed at the higher layer.

[0217] A separate new EHC header can have a fixed size (e.g., 1 byte or 2 bytes).

[0218] In addition, in an embodiment, the transmitting end and the receiving end can also compress and decompress the length field of the Ethernet header by applying the above method. According to another method, the length field of the Ethernet header can be transmitted without always compressing it.

[0219] According to another method, the transmitting end can always transmit the length field of the Ethernet header without being compressed. After the receiving PDCP layer device decompresses the remaining fields except the length field, the PDCP layer device can calculate the length of the Ethernet frame by adding the length of the length field (since the length of the length field is known as a fixed value) to it, then reconstruct the length value and add the reconstructed length value to the length field of the Ethernet header. Therefore, the indication of the length field can be omitted in the new EHC header, and even when the length field value is different for each data, the transmitting PDCP layer device can always omit (compress) the length field and perform transmission, and the receiving PDCP layer device can calculate and derive the length field value according to the above description, and can always reconstruct the length field value of the Ethernet header.

[0220] In addition, when the receiving PDCP layer device successfully receives data, the new EHC header can define and use a field indicating a feedback request. That is, instead of always sending feedback each time the receiving PDCP layer device receives a complete header, the feedback transmission can occur only when the transmitting PDCP layer device requests feedback via an indicator, so as to reduce overhead.

[0221] Therefore, in the Ethernet header compression method according to an embodiment of the present disclosure, as described above, by applying the first embodiment, the transmitting PDCP layer device can transmit an indicator indicating a compression method, a header type, or a data stream type, a bitmap field, and data having an uncompressed Ethernet header, and the receiving PDCP layer device can know, from the bitmap field, the header compression method of the Ethernet header type applied to each data. In addition, the receiving end can store the field values of the uncompressed Ethernet header and can use the field values when reconstructing the field values of the compressed Ethernet header later. Here, the bitmap field can be used as a field indicating the header compression method via the jointly indicated identifier. For example, as the compression method of the indicated identifier, the bitmap field can indicate which fields are to be compressed or which fields are not to be compressed.

[0222] In the present disclosure, the complete header transmitted by the transmitting PDCP layer device can indicate an EHC header including a bitmap field, an identifier indicating a compression method, a header type, or a data stream type, or an indicator indicating whether compression has been performed, and an uncompressed Ethernet header. For example, the complete header can indicate the initial complete header transmitted by the transmitting PDCP layer device before applying the Ethernet header compression method, so as to indicate the Ethernet header compression method to the receiving PDCP layer device using the bitmap field, the identifier of the corresponding data stream, and the field values of the uncompressed Ethernet header. In addition, when the receiving PDCP layer device receives the complete header, the receiving PDCP layer device uses the bitmap field to understand the Ethernet header compression method, the identifier of the corresponding data stream, and the field values of the uncompressed Ethernet header, and the receiving PDCP layer device can perform a decompression process on the compressed Ethernet header to be received later.

[0223] The transmitting PDCP layer device can send data having a plurality of complete headers to the receiving PDCP layer device, and then can immediately apply an Ethernet header compression process to the data and send the data. Therefore, since there is no need to identify feedback from the receiving end, the header compression process can start quickly. According to another method, when the transmitting PDCP layer device sends data having one or more complete headers and then receives feedback from the receiving PDCP layer device indicating successful reception of the complete headers, the transmitting PDCP layer device can then apply an Ethernet header compression method to the data. Therefore, the decompression error rate at the receiving end (which may occur when the complete headers are lost) can be reduced.

[0224] As described above, in the second embodiment of the present disclosure, when synchronizing the complete header and applying the identifier and header compression method of the application data stream between the transmitting PDCP layer device and the receiving PDCP layer device, a new EHC header including an identifier of the data stream, an identifier indicating the header compression method, or an indicator indicating whether header compression occurs, and an Ethernet header that has applied the Ethernet header compression method and has been compressed are transmitted together with the data. In addition, the receiving end can decompress the compressed Ethernet header by applying the new EHC header information and the Ethernet header decompression method. Therefore, when applying the method of the second embodiment of the present disclosure, even when multiple data streams are mapped to one bearer, different header compression or decompression methods can be applied to each data stream, thereby improving the ease of implementation.

[0225] The embodiments described in the present disclosure can be applied together to improve the convenience of implementation. For example, as described above, in the initial stage of the header compression method, the first embodiment of the present disclosure can be applied to identify the data stream or type and define the header compression method, and in order to synchronize the transmitting PDCP layer device and the receiving PDCP layer device with each other, thereafter, the second embodiment of the present disclosure can be applied to apply the header compression process. In addition, the first embodiment can be applied again during data transmission / reception, so as to update the transmitting PDCP layer device and the receiving PDCP layer device with a new identifier or header compression method.

[0226] In the first and second embodiments of the present disclosure, a method has been described in which the transmitting PDCP layer device can dynamically indicate an identifier or a header compression method using user layer data (e.g., a complete header). Below, a method will be described in which an identifier indicating a predefined header compression method is configured together with an identifier for each Ethernet header structure or for each data stream through an RRC message, and different compression methods can be applied to each Ethernet header structure or data stream in the transmitting PDCP layer device and the receiving PDCP layer device. A specific third embodiment of the Ethernet header compression method described in the present disclosure is as follows.

[0227] In the third embodiment of the present disclosure, the header compression or decompression method described in the second embodiment can be applied in the same manner. However, when the base station maps only one data stream or QoS flow to one bearer or one PDCP layer device through an RRC message, it is not necessary to distinguish data streams or QoS flows with different header structures of higher layer devices. That is, the new EHC header does not need to indicate an identifier of different higher layer header structures or different higher layer compression methods. This is because one higher layer header structure or header compression method can be configured in one PDCP layer device.

[0228] Thus, in the third embodiment of the present disclosure, the sending end can define and configure a field indicating whether the higher-layer header is compressed only in the new EHC header or the PDCP header, and can apply the method proposed in the second embodiment as it is, so that the PDCP layer device on the sending side can perform compression on the higher-layer device header, and the PDCP layer device on the receiving side can perform decompression on it.

[0229] The present disclosure proposes a specific structure of feedback, which can be used in the embodiments of the above-mentioned method for compressing the higher-layer header (Ethernet header).

[0230] Figure 1k An embodiment showing a feedback structure that can be used in the higher-layer header compression method according to an embodiment of the present disclosure.

[0231] According to one embodiment, in combination with feedback, when a transmission occurs from the PDCP layer device at the sending end, the PDCP layer device at the receiving end does not apply the integrity protection or encryption process, so that the PDCP layer device at the sending end can quickly read the feedback information.

[0232] Figure 1k A new PDCP control data (PDCP control PDU) is shown, which is defined by determining the value of the new PDU type field via the first feedback structure 1k-01. When the higher-layer compression and decompression method (or protocol) is configured in the receiving PDCP layer device, whenever the higher-layer header of the received data is not compressed and the complete higher-layer header is received (or when the sending PDCP layer device indicates feedback), the new PDCP control data is triggered and configured, and is sent to the sending PDCP layer device. The new PDCP control data can define an indicator or a new field (CTI field or context identifier), and through this indicator, it is indicated whether the complete higher-layer header sent by the sending PDCP layer device without compression is successfully received or the reception fails. According to another method, the new PDCP control data itself can indicate that the complete higher-layer header sent by the sending PDCP layer device without compression has been successfully received. In this way, through feedback, the sending PDCP layer device can determine the time point for applying the compression method of the higher-layer device.

[0233] When the Ethernet decompression fails (for example, when a checksum error occurs), the new PDCP control data can also be used to provide feedback to the Ethernet compression protocol at the sending end. That is, the newly defined PDCP control data can indicate that the Ethernet decompression has failed (or a checksum error has occurred), and can indicate that the initialization of the sending buffer for Ethernet header compression at the sending end needs to be performed.

[0234] In Figure 1kIn it, new PDCP control data (PDCP control PDU) is shown, which is defined by determining a new PDU type field value via a second feedback structure 1k-02. When a high-layer compression and decompression method (or protocol) is configured in the receiving PDCP layer device, whenever the high-layer header of the received data is not compressed and the complete high-layer header is received (or when the sending PDCP layer device indicates feedback), the new PDCP control data is triggered and configured and sent to the sending PDCP layer device. The new PDCP control data can define an indicator, and through this indicator, it is indicated whether the complete high-layer header sent by the sending PDCP layer device without compression is successfully received or the reception fails. According to another method, the new PDCP control data itself can indicate that the complete high-layer header sent by the sending PDCP layer device without compression has been successfully received.

[0235] In addition, by defining and indicating a new field (CTI or context identifier) that indicates the type of the high-layer header or the type of the high-layer header compression method with respect to the high-layer header or the high-layer header compression method, the new PDCP control data can define an indicator, and through this indicator, it is indicated whether the complete high-layer header sent by the sending PDCP layer device without compression is successfully received or the reception fails. According to another method, with respect to the high-layer header or the high-layer header compression method indicated by the new CTI field, the new PDCP control data itself can indicate that the complete high-layer header sent by the sending PDCP layer device without compression has been successfully received.

[0236] Through the above feedback, the sending PDCP layer device can determine the time point for applying the compression method of the high-layer device.

[0237] In addition, when the Ethernet decompression fails (for example, when a checksum error occurs), the new PDCP control data can also be used to provide feedback to the sending-end Ethernet compression protocol. That is, the newly defined PDCP control data can indicate that the Ethernet decompression for a specific high-layer header or high-layer header compression method has failed (or a checksum error has occurred), and can indicate that the initialization of the sending buffer for the sending-end Ethernet header compression needs to be performed.

[0238] In Figure 1kIn it, new PDCP control data (PDCP control PDU) is shown, which is defined by determining a new PDU type field value via a third feedback structure 1k-03. When a high-layer compression and decompression method (or protocol) is configured in the receiving PDCP layer device, whenever the high-layer header of the received data is not compressed and the complete high-layer header is received (or when the sending PDCP layer device indicates feedback), the new PDCP control data is triggered and configured and sent to the sending PDCP layer device. The new PDCP control data can define an indicator, and through this indicator, it is indicated whether the complete high-layer header sent by the sending PDCP layer device without compression is successfully received or the reception fails. According to another method, the new PDCP control data itself can indicate that the complete high-layer header sent by the sending PDCP layer device without compression has been successfully received.

[0239] In addition, a new field (PDCP sequence number (SN)) indicating the PDCP sequence number is defined and indicated, and regarding a specific PDCP sequence number, the new PDCP control data can define an indicator, and through this indicator, it is indicated whether the complete high-layer header sent by the sending PDCP layer device without compression is successfully received or the reception fails. According to another method, regarding the data indicated by the new PDCP sequence number field, the new PDCP control data itself can indicate that the complete high-layer header sent by the sending PDCP layer device without compression has been successfully received.

[0240] Through the above feedback, the sending PDCP layer device can determine the time point for applying the compression method of the high-layer device.

[0241] In addition, when the Ethernet decompression fails (for example, when a checksum error occurs), the new PDCP control data can also be used to provide feedback to the sending-end Ethernet compression protocol. That is, the newly defined PDCP control data can indicate that the Ethernet decompression regarding a specific PDCP sequence number has failed (or a checksum error has occurred), and can indicate that the initialization of the sending buffer for the sending-end Ethernet header compression needs to be performed.

[0242] In Figure 1kIn the embodiment, new PDCP control data (PDCP control PDU) is proposed, which is defined by determining a new PDU type field value via a fourth feedback structure 1k-04. When a high-layer compression and decompression method (or protocol) is configured in the receiving PDCP layer device, whenever the high-layer header of the received data is not compressed and the complete high-layer header is received (or when the transmitting PDCP layer device indicates feedback), the new PDCP control data is triggered and configured and sent to the transmitting PDCP layer device. The new PDCP control data can define an indicator, and through this indicator, it is indicated whether the complete high-layer header sent by the transmitting PDCP layer device without compression is successfully received or received unsuccessfully. According to another method, the new PDCP control data itself can indicate that the complete high-layer header sent by the transmitting PDCP layer device without compression has been successfully received.

[0243] In addition, a new field (COUNT) defining and indicating a count value is defined, and for a specific count value, the new PDCP control data can define an indicator, and through this indicator, it is indicated whether the complete high-layer header sent by the transmitting PDCP layer device without compression is successfully received or received unsuccessfully. According to another method, for the data indicated by the new count value field, the new PDCP control data itself can indicate that the complete high-layer header sent by the transmitting PDCP layer device without compression has been successfully received.

[0244] Through the above feedback, the transmitting PDCP layer device can determine the time point for applying the compression method of the high-layer device.

[0245] In addition, when Ethernet decompression fails (for example, when a checksum error occurs), the new PDCP control data can also be used to provide feedback to the transmitting-end Ethernet compression protocol. That is, the newly defined PDCP control data can indicate that the Ethernet decompression of the data for a specific count value has failed (or a checksum error has occurred), and can indicate that the initialization of the transmit buffer for transmitting-end Ethernet header compression needs to be performed.

[0246] Figure 1kAspects are shown in which a PDCP status report among PDCP control data (PDCP control PDU) is used as feedback via a fifth feedback structure 1k-05. In a case where a high-layer compression and decompression method (or protocol) is configured in a receiving PDCP layer device, whenever a high-layer header of received data is not compressed and a complete high-layer header is received (or when the transmitting PDCP layer device indicates feedback), the PDCP status report is triggered and configured and is sent to the transmitting PDCP layer device. The PDCP status report may define an indicator, and through this indicator, it is indicated whether the complete high-layer header transmitted by the transmitting PDCP layer device without compression is successfully received or received with failure.

[0247] In addition, the PDCP status report may indicate, with respect to a specific count value, whether the complete high-layer header transmitted by the transmitting PDCP layer device without compression has been successfully received or received with failure. That is, the FMC field may indicate a first count value that has not been sent from the receiving PDCP layer device to the high layer, and by using one bit mapped to each count value greater than the first count value, subsequent bitmap fields may indicate whether the value "0" or "1" has been successfully received.

[0248] In addition, when an Ethernet decompression failure occurs (e.g., when a checksum error occurs), the PDCP status report may also be used to provide feedback to the transmitting-end Ethernet compression protocol. That is, newly defined PDCP control data may indicate that the Ethernet decompression of data with respect to a specific count value has failed (or a checksum error has occurred), and may indicate that initialization of a transmission buffer for transmitting-end Ethernet header compression needs to be performed. That is, the FMC field may indicate a first count value that the receiving PDCP layer device has not sent to the high layer, and subsequent bitmap fields may use one bit to indicate count values greater than the first count value.

[0249] The present disclosure shows a sixth feedback structure, through which a new field is defined in a new EHC header or PDCP header of data transmitted from a receiving PDCP layer device to a transmitting PDCP layer device and is used as feedback. In a case where a high-layer compression and decompression method (or protocol) is configured in the receiving PDCP layer device, whenever a high-layer header of received data is not compressed and a complete high-layer header is received (or when the transmitting PDCP layer device indicates feedback), the new field of the PDCP header or EHC header is configured and is sent to the transmitting PDCP layer device. The new field may indicate whether the complete high-layer header transmitted by the transmitting PDCP layer device without compression is successfully received or received with failure.

[0250] In the following, when the high-layer compression or decompression method (Ethernet header compression method) or ROHC (high-layer compression or decompression method such as TCP / IP or UDP) described in the embodiments of the present disclosure is configured, the operations of the transmitting PDCP layer device and the receiving PDCP layer device are described as follows.

[0251] The operation of the transmitting PDCP layer device of the UE or the base station according to the embodiments of the present disclosure is as follows.

[0252] The transmitting PDCP layer device uses a first COUNT variable that maintains the count value to be assigned to the next data to be transmitted when processing data, and this first COUNT variable may be referred to as TX_NEXT.

[0253] The operation of the transmitting PDCP layer device according to the embodiments of the present disclosure is as follows.

[0254] - The transmitting PDCP layer device activates the PDCP data discard timer when receiving data (e.g., PDCP SDU) from the high layer, and discards the data when the timer expires.

[0255] - In addition, the transmitting PDCP layer device assigns a count value corresponding to TX_NEXT to the data received from the high layer. TX_NEXT may be configured with 0 as the initial value, and TX_NEXT maintains the count value of the data (PDCP SDU) to be transmitted next.

[0256] - When the header compression protocol (ROHC) is configured for the transmitting PDCP layer device, header compression of the data can be performed.

[0257] - When the high-layer header compression protocol (Ethernet header compression method, EthHC) is configured for the transmitting PDCP layer device,

[0258] * When the data received from the high layer is the first data received after the Ethernet header compression method is configured,

[0259] * Alternatively, when even one of the field values of the compressible fields among the fields of the Ethernet header of the data received from the high layer is different from the field value stored in the buffer of the transmitting PDCP layer device (or different from the previously transmitted Ethernet header field value),

[0260] * Alternatively, when no feedback indicating successful reception of the data with the previously transmitted uncompressed complete high-layer header (Ethernet header) is received from the receiving PDCP layer device,

[0261] The transmitting PDCP layer device does not perform Ethernet header compression until it receives feedback from the receiving PDCP layer device indicating successful reception of an uncompressed complete higher layer header (Ethernet header). That is, the transmitting PDCP layer device transmits data with a complete header, and the processing and transmission of data and the context identifier are configured without compression through the 1-bit indicator of the EHC header.

[0262] *When the transmitting PDCP layer device receives feedback indicating successful reception of data with a previously transmitted uncompressed complete higher layer header (Ethernet header),

[0263] **The transmitting PDCP layer device can perform compression by applying the Ethernet header compression method to the data received from the higher layer. That is, the transmitting PDCP layer device compresses the Ethernet header and transmits the data, and the processing and transmission of data and the context identifier are configured with compression through the 1-bit indicator of the EHC header.

[0264] -When integrity protection is configured for the transmitting PDCP layer device, a PDCP header can be generated, and integrity protection of the PDCP header and data can be performed using the security key assigned to the data and the count value of TX_NEXT.

[0265] -In addition, the encryption process of the data can be performed using the security key assigned to the data and the count value of TX_NEXT. In addition, the count value of the TX_NEXT variable configures the PDCP sequence number to as many low LSBs as the PDCP sequence number length.

[0266] -In addition, the count value of the TX_NEXT variable can be incremented by 1, and the processed data above can be concatenated with the PDCP header and sent to the lower layer.

[0267] According to another method of the present disclosure, when receiving a complete header transmitted by the transmitting PDCP layer device, the operation of the receiving PDCP layer device generating and sending feedback, or the time point or method of the transmitting PDCP layer device applying the header compression process is performed differently according to the mode of the RLC layer device to which the transmitting / receiving PDCP layer device is connected. For example, in the case where the transmitting / receiving PDCP layer device is connected to an RLC layer device operating in the RLC AM mode, since there is no data loss, the transmitting PDCP layer device transmits a complete header, and when receiving a complete header, the receiving PDCP layer device configures the corresponding feedback and sends the feedback to the transmitting PDCP layer device. In addition, when receiving the feedback for the first time, the transmitting PDCP layer device applies the header compression process to subsequent data and transmits the data.

[0268] According to another method, in the case where the transmitting / receiving PDCP layer device is connected to an RLC layer device operating in RLC UM mode, data loss may occur. Therefore, the transmitting PDCP layer device sends multiple complete headers, and each time the receiving PDCP layer device receives multiple complete headers, the receiving PDCP layer device configures the corresponding feedback and sends the feedback to the transmitting PDCP layer device. In addition, when the feedback is received for the first time, the transmitting PDCP layer device applies the header compression process to subsequent data and sends the data.

[0269] According to another method, in the case where the transmitting / receiving PDCP layer device is connected to an RLC layer device operating in RLC UM mode, data loss may occur. Therefore, the transmitting PDCP layer device can continue to send complete headers until it receives feedback (feedback indicating successful reception of the complete headers) from the receiving PDCP layer device. In addition, each time the receiving PDCP layer device receives a complete header, the receiving PDCP layer device configures the corresponding feedback and sends it to the transmitting PDCP layer device. In addition, when the feedback is received for the first time, the transmitting PDCP layer device can stop sending complete headers and apply the header compression process to subsequent data and send the data.

[0270] According to another method, in the case where the transmitting / receiving PDCP layer device is connected to an RLC layer device operating in RLC AM mode, the transmitting PDCP layer device can continue to send complete headers until it receives feedback (feedback indicating successful reception of the complete headers) from the receiving PDCP layer device. In addition, each time the receiving PDCP layer device receives a complete header, the receiving PDCP layer device configures the corresponding feedback and sends it to the transmitting PDCP layer device. In addition, when the feedback is received for the first time, the transmitting PDCP layer device can stop sending complete headers and apply the header compression process to subsequent data and send the data.

[0271] According to another method, in the case where the transmitting / receiving PDCP layer device is connected to an RLC layer device operating in RLC AM mode, there is no data loss. Therefore, the transmitting PDCP layer device can configure and transmit a complete header, and can apply a header compression process to the data that follows, in order to process the data and perform its transmission. That is to say, the data compression process can be directly applied without receiving feedback (feedback indicating successful reception of the complete header) from the receiving PDCP layer device. Additionally, here, the receiving PDCP layer device can arrange the received data in ascending order of PDCP sequence number or count value, and since there is no data loss in RLC AM, the receiving PDCP layer device can first receive and process the complete header, and can determine the identifier value of the data stream and the header compression method. Thereafter, data processing can be performed by applying a header decompression process to the data in ascending order, and the data can be transmitted to a higher layer device.

[0272] According to another method, in the case where the transmitting / receiving PDCP layer device is connected to an RLC layer device operating in RLC UM mode, there is no data loss. Therefore, the transmitting PDCP layer device can transmit multiple complete headers, and can apply a header compression process to the data that follows, in order to process the data and perform its transmission. That is to say, the data compression process can be directly applied without receiving feedback (feedback indicating successful reception of the complete header) from the receiving PDCP layer device. Here, the receiving PDCP layer device can arrange the received data in ascending order of PDCP sequence number or count value, and even when data loss occurs in RLC AM, the receiving PDCP layer device can assume that at least one complete header among multiple complete headers is received with a high probability. Here, the receiving PDCP layer device can first receive and process the complete header, and can determine the identifier value of the data stream and the header compression method. Thereafter, data processing can be performed by applying a header decompression process to the data in ascending order, and the data can be transmitted to a higher layer device.

[0273] In addition, a receiving PDCP layer device connected to an RLC layer device driven in RLC UM or AM can configure a new timer value via an RRC message, and upon receiving a complete header, can send feedback and start the timer. In addition, even when a complete header is received, the receiving PDCP layer device can perform an operation of not sending additional feedback until the timer expires, so as to prevent generation of unnecessary feedback. In addition, a transmitting PDCP layer device connected to an RLC layer device driven by RLC UM or AM can consider that the receiving PDCP layer device has successfully received the complete header when the first feedback is received, and can apply a header compression process to subsequent data and perform its transmission. Thereafter, the transmitting PDCP layer device can ignore feedback received additionally within a predetermined period of time (e.g., configure a new timer value via an RRC message, start a new timer when the first feedback is received, and until the timer expires).

[0274] The above feedback structure can be applied together with the Figure 1k feedback structure described in this disclosure.

[0275] As described above, the Ethernet header compression algorithm according to an embodiment of this disclosure can be driven without feedback. That is, the transmitting PDCP layer device can send a data segment that is not compressed using the Ethernet header compression algorithm and includes a complete header (where the complete header includes configuration information or context of the Ethernet header compression algorithm), and then can send a data segment that includes an Ethernet header compressed by immediately applying the Ethernet header compression algorithm to the next data. Here, the complete header can indicate a new EHC header that includes an uncompressed high-layer header or configuration information of the Ethernet header compression algorithm in the PDCP layer device. In addition, when sending data segments with multiple complete headers, the new EHC headers included in the complete headers can indicate the same information, and each data segment can include different high-layer data. In addition, the base station can configure the number of data to be sent for each bearer via an RRC message as Figure 1e shown (e.g., an RRCSetup, RRCResume, or RRCReconfiguaration message), where the data includes a complete header sent when starting to apply the Ethernet header compression method or attempting to change the Ethernet header compression method in the transmitting PDCP layer device.

[0276] Hereinafter, when the Ethernet header compression algorithm is configured in the PDCP layer device, a method of driving the Ethernet header compression algorithm without feedback according to an embodiment of this disclosure will be described.

[0277] - Method 1: The base station can configure the number of data segments including the complete header to be sent when starting to apply the Ethernet header compression method or attempting to change the Ethernet header compression method for each bearer as a first number. For example, the base station can configure the number of data segments to be sent through an RRC message for each bearer (e.g., RRCSetup or RRCResume or RRCReconfiguration message) as shown in Figure 1e . That is, in order to configure the Ethernet header compression method when attempting to apply the Ethernet header compression method or change the Ethernet header compression method, the transmitting PDCP layer device can send data segments with a complete header including configuration information or context of the Ethernet header compression algorithm through the first number configured via the RRC message, and then can send data segments including an Ethernet header compressed by immediately applying the Ethernet header compression algorithm to subsequent data. According to another method, the number of data segments including the complete header to be sent can be determined according to the implementation. According to another method, since multiple QoS flows (or multiple different Ethernet header types) can be mapped to one bearer, the base station can configure the number of data segments including the complete header to be sent when starting to apply the Ethernet header compression method or attempting to change the Ethernet header compression method for each bearer or for each QoS flow of one bearer as a second number. According to another method, the base station can configure the number of data segments including the complete header to be sent when starting to apply the Ethernet header compression method or attempting to change the Ethernet header compression method for each bearer as a first number. Since multiple QoS flows (or multiple QoS flows respectively mapped to multiple context identifiers (indicating the Ethernet header compression method)) (or multiple different Ethernet header types) can be mapped to one bearer, each transmitting PDCP layer device can send each data segment with a complete header corresponding to each context identifier (or for each Ethernet header compression method) or each QoS flow the first number, and then can start compression or can compress the Ethernet header by applying the Ethernet header compression method corresponding to each context identifier to subsequent data corresponding to each context identifier or each QoS flow (or each Ethernet header type), and transmit the data to the lower layer for transmission. The transmitting PDCP layer device can assign different context identifiers to different QoS flows (or Ethernet header types), and can configure and apply different Ethernet header compression methods. Method 1 can be applied to a bearer corresponding to a PDCP layer device connected to RLC UM or a bearer corresponding to a PDCP layer device connected to RLC AM.

[0278] - Method 2: According to Method 2, different methods can be applied to the bearers corresponding to the PDCP layer devices connected to RLC UM and the bearers corresponding to the PDCP layer devices connected to RLC AM. The base station can configure the number of data segments including the complete header to be sent when starting to apply the Ethernet header compression method or attempting to change the Ethernet header compression method in the transmitting PDCP layer device for each bearer as a first number. For example, the base station can configure it through, such as Figure 1eConfigure the number of data segments to be sent for each bearer's RRC message (e.g., RRCSetup or RRCResume or RRCReconfiguration message) as shown. That is, in order to configure the Ethernet header compression method when attempting to apply or change the Ethernet header compression method, the transmitting PDCP layer device can send data segments with complete headers including configuration information or context of the Ethernet header compression algorithm by the first number configured via the RRC message, and then can send data segments including Ethernet headers compressed by immediately applying the Ethernet header compression algorithm to subsequent data. According to another method, the number of data segments including complete headers to be sent can be determined according to the implementation. According to another method, since multiple QoS flows can be mapped to one bearer, the base station can configure the number of data segments including complete headers to be sent when starting to apply the Ethernet header compression method or attempting to change the Ethernet header compression method in the transmitting PDCP layer device as the second number for each bearer or for each QoS flow of one bearer. According to another method, the base station can configure the number of data segments including complete headers to be sent when starting to apply the Ethernet header compression method or attempting to change the Ethernet header compression method in the transmitting PDCP layer device as the first number for each bearer. Since multiple QoS flows (or multiple QoS flows mapped to multiple context identifiers (indicating the Ethernet header compression method) respectively) (or multiple different Ethernet header types) can be mapped to one bearer, each transmitting PDCP layer device can send each data segment with a complete header corresponding to each context identifier (or for each Ethernet header compression method) or each QoS flow by the first number, and then can start compressing or can compress the Ethernet header by applying the Ethernet header compression method corresponding to each context identifier to the subsequent data corresponding to each context identifier or each QoS flow (or each Ethernet header type), and transmit the data to the lower layer for transmission. The transmitting PDCP layer device can assign different context identifiers to different QoS flows and can configure and apply different Ethernet header compression methods. Method 2 can be applied to the bearers corresponding to the PDCP layer devices connected to RLC UM. However, when Method 2 is applied to the bearers corresponding to the PDCP layer devices connected to RLC AM, the first number or the second number can always be configured as 1. Because there is no data loss in the RLC AM mode and the receiving PDCP layer device always performs data sequence sorting and then header decompression, it is sufficient to send only one complete header instead of multiple complete headers.Therefore, the transmitting PDCP layer device connected to the RLC AM mode configures and transmits a first number of data segments including a complete header corresponding to each context identifier (or for each Ethernet header compression method) or each QoS flow, and then may start compressing the Ethernet header, or may compress the Ethernet header by applying the Ethernet header compression method corresponding to each context identifier to subsequent data corresponding to each context identifier or each QoS flow, and transmit the data segment to the lower layer to perform transmission.

[0279] - Method 3: According to Method 3, different methods may be applied to the bearers corresponding to the PDCP layer device connected to the RLC UM and the bearers corresponding to the PDCP layer device connected to the RLC AM. The base station may configure, for each bearer corresponding to the bearer connected to the RLC UM, the number of data segments including the complete header to be transmitted when starting to apply the Ethernet header compression method or attempting to change the Ethernet header compression method in the transmitting PDCP layer device as the first number. For example, the base station may, as Figure 1eFor each bearer, the RRC message shown (e.g., RRCSetup or RRCResume or RRCReconfiguration message) configures the number of data segments to be sent for the bearer connected to RLC UM. That is, in order to configure the Ethernet header compression method when attempting to apply or change the Ethernet header compression method, the transmitting PDCP layer device connected to RLC UM can send data segments with complete headers including configuration information or context of the Ethernet header compression algorithm by the first number configured via the RRC message, and then can send data segments including Ethernet headers compressed by immediately applying the Ethernet header compression algorithm to subsequent data. According to another method, the number of data segments including complete headers to be sent can be determined according to the implementation. According to another method, since multiple QoS flows (or multiple Ethernet header types) can be mapped to one bearer, the base station can configure the number of data segments including complete headers to be sent when starting to apply the Ethernet header compression method or attempting to change the Ethernet header compression method in the transmitting PDCP layer device for the bearer connected to RLC UM, respectively for each bearer or for each QoS flow of one bearer as the second number. According to another method, the base station can configure the number of data segments including complete headers to be sent when starting to apply the Ethernet header compression method or attempting to change the Ethernet header compression method in the transmitting PDCP layer device for the bearer connected to RLC UM for each bearer as the first number. Since multiple QoS flows (or multiple QoS flows respectively mapped to multiple context identifiers (indicating Ethernet header compression methods)) (or multiple different Ethernet header types) can be mapped to one bearer, each transmitting PDCP layer device connected to RLC UM can send each data segment including complete headers corresponding to each context identifier (or for each Ethernet header compression method) or each QoS flow (or each Ethernet header type) the first number of times, and then can start compressing or can compress the Ethernet header by applying the Ethernet header compression method corresponding to each context identifier to subsequent data corresponding to each context identifier or each QoS flow and transmit the data to the lower layer for transmission. The transmitting PDCP layer device can assign different context identifiers to different QoS flows and can configure and apply different Ethernet header compression methods. However, in Method 3, when the Ethernet header compression algorithm is configured, the PDCP layer device (or bearer) connected to RLC AM can configure and send one data segment including complete headers corresponding to each context identifier (or for each Ethernet header compression method) or each QoS flow (or each Ethernet header type) when applying.Thereafter, the PDCP layer device may start compressing the Ethernet header, or may compress the Ethernet header by applying the Ethernet header compression method corresponding to each context identifier to the subsequent data corresponding to each context identifier or each QoS flow, and transmit the data segment to the lower layer for transmission. Since there is no data loss in the RLC AM mode and the receiving PDCP layer device always performs data sequence sorting and then header decompression, it is sufficient to send only one complete header without having to send multiple complete headers. Therefore, for the transmitting PDCP layer device or bearer connected to the RLC AM mode, the first number or the second number is not configured through the RRC message.

[0280] In addition, when the transmitting PDCP layer device according to an embodiment of the present disclosure applies the Ethernet header compression method, the transmitting PDCP layer device and the receiving PDCP layer device should share the configuration information related to the Ethernet header compression method, such as which fields are compressed or compressible for each context identifier (or each QoS flow or each Ethernet header type), and should synchronize between them. In the embodiment, it has been described that when the Ethernet header compression method is configured for each context identifier, the transmitting PDCP layer device includes the configuration information related to the Ethernet header compression method (e.g., context identifier or bitmap field, etc.) in the complete header when applying it, and transmits it when performing data transmission. However, according to another method, in Figure 1e the RRC message, the configuration information about the Ethernet header compression method indicating which fields are compressed or compressible for each context identifier (or for each QoS flow or each Ethernet header type) applicable to each bearer or each PDCP layer device, etc. can be pre-configured through the RRC message, and according to the configuration information, the transmitting PDCP layer device can apply the Ethernet header compression process for each context. In addition, regarding the data with multiple complete headers sent when the transmitting PDCP layer device starts applying the Ethernet header compression method or attempts to change the Ethernet header compression method, the complete header may include the context identifier or the uncompressed Ethernet header without including the configuration information about the Ethernet header compression method, such as the bitmap field. In addition, regarding how many complete headers are to be sent, the above Method 1, Method 2, or Method 3 can be applied. Since the configuration information about the Ethernet header compression method, such as which fields are compressed or compressible for each context identifier (or each QoS flow or each Ethernet header type), is pre-configured in the RRC message, the transmitting PDCP layer device can reduce the overhead by not including the configuration information about the Ethernet header compression method in the complete header.

[0281] Hereinafter, the process of compressing the padding of the Ethernet frame by the transmitting end and reconstructing the padding by the receiving end will be described in detail.

[0282] The Ethernet protocol is designed such that data (e.g., an Ethernet frame) smaller than a predetermined first size (e.g., the data can be 64 bytes, which can be predetermined and can be configured by an RRC message as shown in Figure 1e is discarded by the receiving end. Therefore, when the size of the Ethernet frame is smaller than the determined first size, the sending end adds padding to it to send the data according to the first size. Thus, when the sending PDCP layer device receives data from a higher-layer device (e.g., an Ethernet protocol layer device) and sends the data as it is, when serving small data, the padding is included in the transmission resource and is sent continuously, so the transmission resource is wasted. This may cause a delay in data transmission. Therefore, hereinafter, when the Ethernet header compression method is configured for each bearer, the sending PDCP layer device identifies the size of the data received from the higher-layer device, and for data (e.g., an Ethernet frame) whose size is equal to or smaller than a second size (e.g., 64 bytes, which can be predetermined and can be configured by an RRC message as shown in Figure 1e or for data whose size is equal to or larger than the second size, the sending PDCP layer device identifies its padding and sends the data after removing the padding. In addition, the receiving PDCP layer device in which the Ethernet header compression method is configured can identify the size of the data received from the lower-layer device (e.g., an RLC layer device), and for data whose size is equal to or smaller than a third size (e.g., 64 bytes, which can be predetermined and can be configured by an RRC message as shown in Figure 1e , adds padding to it to configure the data size to fit the first size (or the third size), and then the data can be transmitted to the higher-layer device, thereby reducing the waste of transmission resources.

[0283] The PDCP layer device can configure one of the Ethernet header compression method and the ROHC header compression method, and can also configure both methods simultaneously.

[0284] When the data received by a transmitting PDCP layer device in which an Ethernet header compression method is configured from a higher layer device has a fourth size, the data can be reduced to the (5 - 1)th size by applying the Ethernet header compression method to the data. Further, when both the Ethernet header compression method and the ROHC header compression method are configured, the ROHC header method can be applied to the data having the (5 - 1)th size to reduce the size to data having the (6 - 1)th size. According to another method, when the data received by a transmitting PDCP layer device in which the ROHC header compression method is configured from a higher layer device has a fourth size, the data can be reduced to the (5 - 2)th size by applying the ROHC header compression method to the data. Further, when both the Ethernet header compression method and the ROHC header compression method are configured, the Ethernet header method can be applied to the data having the (5 - 2)th size to be reduced to data having the (6 - 2)th size. Further, the transmitting PDCP layer device in which the Ethernet header compression method is configured identifies the size of the data received from the higher layer device, and for data (e.g., Ethernet frame) having a size equal to or less than a second size (e.g., 64 bytes, which may be predetermined and may be configured by an RRC message as shown in Figure 1e ), or for data having a size equal to or greater than the second size, the transmitting PDCP layer device identifies its padding and transmits the data after removing the padding. The transmitting PDCP layer device can identify the size of the data received from the higher layer device or identify the field information of the Ethernet header to determine whether there is padding and perform a padding removal process, and the padding removal process can be performed before the Ethernet header compression process or the ROHC header compression process. Since after performing the Ethernet header compression process or the ROHC header compression process, the data becomes smaller than the original fourth size, it may be difficult to accurately remove the padding. According to another method, data is received from the higher layer device, the fourth size is stored, and the padding removal process can be performed after the Ethernet header compression process or the ROHC header compression process. That is, its implementation can occur regardless of the order.

[0285] The receiving PDCP layer device in which the Ethernet header compression method is configured identifies the size of the data received from the lower layer device, and for data having a size equal to or less than a third size (e.g., 64 bytes, which may be predetermined and may be configured by an RRC message as shown in Figure 1eData (e.g., Ethernet frames) configured by the RRC message shown below. The receiving PDCP layer device determines that padding has been removed to prevent waste of transmission resources, performs a padding recovery process by adding padding to the data or configuring it in the data according to the third size or the first size, and transmits it to the higher layer device. However, when identifying the size of the data received from the lower layer device, when the Ethernet header compression method or the ROHC header compression method is configured, the receiving PDCP layer device identifies the size of the data received from the lower layer device after the Ethernet header decompression or the ROHC header decompression is completed. Since the data to which the Ethernet header compression method or the ROHC header compression method is applied has a reduced data size, it is necessary to restore the original data size, then compare the data with the third size data or the first size data, or identify the Ethernet header field information, and apply the padding recovery process. That is, the receiving PDCP layer device applies a decryption process, an integrity protection process, an Ethernet header decompression or a ROHC header decompression process to the received data before identifying the size of the data received from the lower layer device, and restores the original data size. Thereafter, the restored data is compared with the third size data or the first size data, and for a size equal to or less than the third size (e.g., 64 bytes, which can be predetermined and can be configured by the RRC message shown below Figure 1e ), or when padding removal (or compression) is identified as a result of identifying the Ethernet header (or an indicator of the PDCP header or an indicator of the EHC header) field information, it can be determined that padding removal is performed to prevent waste of transmission resources. Thereafter, padding is added to or configured in the data according to the third size or the first size to perform the padding recovery process, and is sent to the higher layer device. That is, the padding recovery (or decompression) process of the Ethernet frame of the receiving PDCP layer device in which the Ethernet header compression method or the ROHC header compression method is configured is performed by identifying the data size or the header field information after the Ethernet header decompression or the ROHC header decompression process is completed.

[0286] In addition, when the Ethernet header compression method and the ROHC header compression method according to embodiments of the present disclosure are configured simultaneously, the receiving PDCP layer device may perform a decryption or integrity verification process on the data received from the lower layer device, and then may first identify the size of the compressed Ethernet header by applying the Ethernet header decompression method, and then identify the ROHC compressed header and apply the ROHC header decompression process thereto. Here, the Ethernet header decompression or the ROHC header decompression may be performed independently, that is, regardless of the order, but the receiving PDCP layer device may first identify the size of the compressed Ethernet header after the PDCP header, and identify the size of the ROHC compressed header, and then may perform the Ethernet header decompression or the ROHC header decompression independently. According to another method, for ease of implementation, an indicator indicating whether the Ethernet header compression or the ROHC header compression has been performed is defined in the PDCP header or the EHC header, and the sending PDCP layer device performs the indication, and the receiving PDCP layer device may identify the indicator and apply the Ethernet header decompression or the ROHC header decompression. This method is required because when both the Ethernet header compression and the ROHC header compression methods are configured, the receiving PDCP layer device cannot know the position of the compressed ROHC header in the received data.

[0287] In addition, in the present disclosure Figure 1e After the sending PDCP layer device sends the complete header for each bearer or each PDCP layer device through the RRC message, a feedback indicating successful reception of the complete header may be received from the receiving PDCP layer device. Thereafter, it may be configured by an indicator whether to start the Ethernet header compression process or to start the Ethernet header compression process immediately after sending a plurality of data segments with complete headers. For example, when the Ethernet header compression method is configured for each bearer or for each PDCP layer device configuration information, the RRC message (for example, RRCSetup, RRCResume, and RRCReconfiguration messages) may indicate whether to use the feedback, and when the transmission of a plurality of data segments with complete headers is configured, the RRC message may configure the corresponding number of transmissions. In addition, different Ethernet header compression configuration information (for example, whether feedback appears, whether a plurality of complete headers are sent, the number of transmissions, etc.) may be configured for the PDCP layer device in which RLC UM or RLC AM is configured.

[0288] The operation of the receiving PDCP layer device of the UE or the base station according to embodiments of the present disclosure is as follows.

[0289] The receiving PDCP layer device receives the PDCP sequence number length configured by the base station through RRC (e.g., 12 bits or 18 bits), identifies the PDCP sequence number of the received data (e.g., PDCP PDU), and drives the receive window. Here, the receive window is configured to be half the size of the PDCP sequence number space (e.g., 2^(PDCP SN length - 1)), and is used to distinguish valid data. That is, data received outside the receive window can be determined to be invalid data and discarded. The reason data arrives outside the receive window is that due to retransmission by the RLC layer device in the lower layer device or HARQ retransmission by the MAC layer device, the data arrives late. In addition, the receiving PDCP layer device can drive a PDCP reordering timer (t-Reordering) together with the receive window.

[0290] Here, when a PDCP sequence number gap appears based on the PDCP sequence number in the receiving PDCP layer device, the PDCP reordering timer is triggered, and when the data corresponding to the PDCP sequence number gap has not arrived until the PDCP reordering timer expires, the data is sent to the upper layer device in ascending order of the PDCP sequence number or count value, and the receive window is moved. Therefore, when the data corresponding to the PDCP sequence number gap arrives after the PDCP reordering timer expires, the data is not in the receive window and is thus discarded.

[0291] The receiving PDCP layer device of the UE or the base station according to an embodiment of the present disclosure operates as follows.

[0292] The receiving PDCP layer device can maintain and manage three count variables when processing the received data. The receiving PDCP layer device can use a second count variable that maintains the count value of the next expected received data (e.g., PDCP SDU) when processing the received data, and this second count variable can be referred to as RX_NEXT. In addition, the receiving PDCP layer device uses a third count variable and a third count that maintain the count value of the first data (e.g., PDCP SDU) that has not been sent to the upper layer when processing the received data. This variable can be referred to as RX_DELIV. In addition, when processing the received data, the receiving PDCP layer device uses a fourth count variable that maintains the count value of the data (e.g., PDCP SDU) that triggers the PDCP reordering timer (t-Reordering), and the fourth count variable can be referred to as RX_REORD. In addition, when processing the received data, the receiving PDCP layer device uses a fifth count variable that maintains the count value of the currently received data (e.g., PDCP SDU), and the fifth count variable is referred to as RCVD_COUNT. The PDCP reordering timer uses the count value obtained through Figure 1eThe timer value or interval configured by the RRC message in the shown upper layer (RRC layer), which is used to detect lost PDCP PDUs, and only one timer can run at a time.

[0293] In addition, the UE can define and use the following variables in the operation of receiving the PDCP layer device.

[0294] - HFN: HFN indicates the hyper frame number (HFN) part of the window status variable.

[0295] - SN: SN indicates the sequence number (SN) part of the window status variable.

[0296] - RCVD SN: RCVD SN indicates the PDCP sequence number included in the header of the received PDCP PDU

[0297] - RCVD_HFN: RCVD_HFN indicates the HFN value of the received PDCP PDU, calculated by the receiving PDCP layer device.

[0298] The operation of the receiving PDCP layer device of the UE or the base station according to the embodiment of the present disclosure is as follows.

[0299] When receiving a PDCP PDU from the lower layer, the receiving PDCP layer device determines the count value of the received PDCP PDU as follows.

[0300] - When the received RCVD_SN is RCVD_SN <= SN(RX_DELIV) - Window_Size,

[0301] * Update to RCVD_HFN = HFN(RX_DELIV) + 1.

[0302] - Otherwise, when RCVD_SN is RCVD_SN > SN(RX_DELIV) + Window_Size,

[0303] * Update to RCVD_HFN = HFN(RX_DELIV) - 1.

[0304] - Otherwise,

[0305] * Update to RCVD_HFN = HFN(RX_DELIV).

[0306] - RCVD_COUNT is determined as RCVD_COUNT = [RCVD_HFN, RCVD_SN].

[0307] After determining the count value of the received PDCP PDU, the receiving PDCP layer device may update the window state variable and process the PDCP PDU as follows.

[0308] - Decode the PDCP PDU using the RCVD_COUNT value and perform integrity verification.

[0309] * When the integrity verification fails,

[0310] * Provide an indication of the integrity verification failure to the upper layer and discard the received PDCP data PDU (the data part of the PDCP PDU).

[0311] - When in the state of RCVD_COUNT < RX_DELIV or when a PDCP PDU with the value of RCVD_COUNT has been previously received (in the case of expired, obsolete, out-of-window packets, or duplicate packets)

[0312] * Discard the received PDCP data PDU (the data part of the PDCP PDU).

[0313] When the received PDCP PDU is not discarded, the receiving PDCP layer device operates as follows.

[0314] - Store the PDCP SDU processed above in the receive buffer.

[0315] - When RCVD_COUNT >= RX_NEXT

[0316] * Update RX_NEXT to RCVD_COUNT + 1.

[0317] - When the out-of-order delivery indicator is configured (when out-of-order delivery operation is indicated),

[0318] * Deliver the PDCP SDU to the upper layer.

[0319] - When RCVD_COUNT is equal to RX_DELIV,

[0320] * When the header decompression process has not been previously applied (even when the Ethernet header compression protocol or ROHC is configured) (i.e., no data processing of the upper layer header has been performed),

[0321] ** When the Ethernet header compression protocol is configured and the Ethernet header is compressed (when the indicator of the new EHC header is recognized and the indicator indicates that the Ethernet header is compressed),

[0322] *** Perform decompression of the Ethernet header of the data.

[0323] **Otherwise, when the Ethernet header compression protocol is configured and the Ethernet header is not compressed (when the indicator of the new EHC header is recognized and the indicator indicates that the Ethernet header is compressed),

[0324] ***the Ethernet header of the data is regarded as an uncompressed header, and its decompression is not performed.

[0325] ***Since the uncompressed Ethernet header has been successfully received, feedback is triggered to indicate successful reception to the transmitting PDCP layer device, and the feedback is configured to be sent to the transmitting PDC layer device.

[0326] **Otherwise, when the ROHC is configured while the Ethernet header compression protocol is not configured,

[0327] ***Decompression of the high-layer header (such as TCP / IP or UDP header, etc.) of the data is performed.

[0328] *The above data is sent to the high layer in the order of the count value.

[0329] **Starting from COUNT = RX_DELIV value, all consecutive PDCP SDUs are sent to the high layer.

[0330] *Update the RX_DELIV value to the count value of the first PDCP SDU that has a count value equal to or greater than the current RX_DELIV value and is not sent to the high layer.

[0331] -When the t-reordering timer is running and the RX_DELIV value is equal to or greater than RX_REORD,

[0332] *The t-reordering timer stops and resets.

[0333] -When the t-reordering timer is not running (including the stopped situation under the above conditions) and RX_DELIV is less than RX_NEXT,

[0334] *Update the RX_REORD value to RX_NEXT.

[0335] *Start the t-reordering timer.

[0336] When the PDCP reordering timer (t-reordering) has expired, the receiving PDCP layer device operates as follows.

[0337] -When the header decompression process has not been applied before (even when the Ethernet header compression protocol or ROHC is configured) (that is, the data processing of the high-layer header has not been performed),

[0338] *When the Ethernet header compression protocol is configured and the Ethernet header is compressed (when the indicator of the new EHC header is recognized and the indicator indicates that the Ethernet header is compressed),

[0339] **Decompress the Ethernet header of the data.

[0340] *Otherwise, when the Ethernet header compression protocol is configured and the Ethernet header is not compressed (when the indicator of the new EHC header is recognized and the indicator indicates that the Ethernet header is compressed),

[0341] **The Ethernet header of the data is regarded as an uncompressed header, and its decompression is not performed.

[0342] **Since the uncompressed Ethernet header has been successfully received, feedback is triggered to indicate its successful reception to the transmitting PDCP layer device, and the feedback is configured to be sent to the transmitting PDC layer device.

[0343] *Otherwise, when the ROHC is configured while the Ethernet header compression protocol is not configured,

[0344] **Decompress the upper-layer header (such as TCP / IP or UDP header, etc.) of the data.

[0345] - The above data is sent to the upper layer in the order of the count value.

[0346] *Send all PDCP SDUs whose count value is less than the RX_REORD value.

[0347] *Starting from the RX_REORD value, send all PDCP SDUs with consecutive count values.

[0348] - Update the RX_DELIV value to the count value of the first PDCP SDU that has a count value equal to or greater than the RX_REORD value and is not sent to the upper layer.

[0349] - When the RX_DELIV value is less than the RX_NEXT value,

[0350] *Update the RX_REORD value to the RX_NEXT value.

[0351] *Start the t-reordering timer.

[0352] The Ethernet header compression or decompression process according to the embodiments of the present disclosure can perform the following detailed operations.

[0353] When the UE receives an RRCReconfiguration message or an RRCConnectionSetup message (or an RRCResume message in the case of a resume procedure), the RRC message can indicate configuration information to the UE as follows.

[0354] -1> For each bearer or in the PDCP layer device configuration information (PDCP configuration), it can be indicated whether to use the configuration information for Ethernet header compression or decompression or the Ethernet header compression or decompression function.

[0355] **2> When using a dedicated traffic channel (DTCH), the Ethernet header compression or decompression function can be configured for a UM bearer (a PDCP layer device connected to an RLC layer device using the UM mode).

[0356] **2> The Ethernet header compression or decompression function can be configured for an AM carrier (a PDCP layer device connected to an RLC layer device using the AM mode) only when using a dedicated traffic channel (DTCH) and / or not using a dedicated control channel (DCCH).

[0357] -1> For each bearer or in the PDCP layer device configuration information (PDCP configuration), an indicator can be configured to indicate whether to continue using or initialize the context for Ethernet header compression or decompression. According to another method, when performing the reconstruction procedure of the PDCP layer device for each bearer or in the PDCP layer device configuration information (PDCP configuration), an indicator can be configured to indicate whether to continue using or initialize the context for Ethernet header compression or decompression. According to another method, when performing the reconstruction procedure for each bearer or the PDCP layer device in the PDCP layer, the context for Ethernet header compression or decompression can always be initialized.

[0358] -1> When the Ethernet header compression or decompression procedure is configured, one or more of the following methods can be applied to perform the Ethernet header compression or decompression procedure.

[0359] **2> First method: For UM or AM bearers, when data for a specific context identifier is sent for the first time, when no feedback is received for the complete Ethernet header (or uncompressed Ethernet header) sent for the specific context identifier, or when the context for Ethernet header compression or decompression is initialized, the transmitting PDCP layer device may generate an EHC header and a complete uncompressed Ethernet header, configure the context identifier or an indicator indicating that compression has not occurred in the EHC header, perform integrity protection or encryption on the corresponding data, and send the data. In addition, the transmitting PDCP layer device may include the uncompressed Ethernet header, the complete Ethernet header, or the EHC header in the data, and perform the transmission of the data until feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header is received. When feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header is received, the transmitting PDCP layer device may start performing Ethernet header compression on the data to be sent. Specifically, the transmitting PDCP layer device may compress or omit the compressible or fields with fixed values among the fields of the Ethernet header, include the non-compressible or fields with non-fixed values, may generate an EHC header, and include an indicator indicating that the Ethernet header has been compressed or the corresponding context identifier in the EHC header, and may perform integrity protection or encryption on the data with the compressed Ethernet header, and send the data. Here, when data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header including an indicator indicating that compression has not occurred is received, by performing decryption or integrity verification on it, the receiving PDCP layer device at the receiving end may store the field values of the complete Ethernet header fields, store the corresponding context identifier, generate feedback, include the context identifier corresponding to the data or an indicator indicating successful reception in the feedback, and send the feedback. In addition, the receiving PDCP layer device may allow the corresponding feedback to be sent without applying the integrity protection or encryption process in order to achieve fast processing. Here, when the receiving PDCP layer device at the receiving end receives data including a compressed Ethernet header or an EHC header including an indicator indicating that compression has been performed, by performing decryption or integrity verification on it, the receiving PDCP layer device may, without generating feedback, recover or reconstruct the compressed or omitted header fields or field values in the compressed Ethernet header from the buffer or context of the context identifier corresponding to the data, and configure the complete Ethernet header fields or perform decompression on them to send them to the higher layer device. Here, when the ROHC header compression process is also configured, the ROHC header compression or decompression process may be performed independently for the higher layer device headers other than the Ethernet header.

[0360] **2>Second method: For UM or AM bearers, when data for a specific context identifier is sent for the first time, when no feedback for the complete Ethernet header (or uncompressed Ethernet header) sent for the specific context identifier is received, or when the context for Ethernet header compression or decompression is initialized, the transmitting PDCP layer device may generate an EHC header and a complete uncompressed Ethernet header, configure the context identifier or an indicator indicating that compression has not occurred in the EHC header, perform integrity protection or encryption on the corresponding data, and send the data. In addition, the transmitting PDCP layer device may include the uncompressed Ethernet header, the complete Ethernet header, or the EHC header in the data, and perform the transmission of the data until feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header is received. When feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header is received, the transmitting PDCP layer device may start to perform Ethernet header compression on the data to be sent. Specifically, the transmitting PDCP layer device may compress or omit the compressible or fields with fixed values among the fields of the Ethernet header, and include the non-compressible or fields with non-fixed values, may generate an EHC header, and include an indicator indicating that the Ethernet header has been compressed or the corresponding context identifier in the EHC header, and may perform integrity protection or encryption on the data with the compressed Ethernet header, and send the data. Here, the receiving PDCP layer device at the receiving end may introduce a separate timer (through the RRC message, the timer value may be configured for each bearer or each PDCP layer device, or may be configured together with the Ethernet header compression or decompression function) to perform the process of preventing frequent feedback as follows.

[0361] ***3>When the receiving PDCP layer device drives the timer, the timer value configured above may be applied, and the timer may be driven for each context identifier.

[0362] ***3>In the above, when the receiving PDCP layer device at the receiving end receives data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header including an indicator indicating that compression has not occurred by performing decryption or integrity verification on it

[0363] ****4>When the timer for the context identifier corresponding to the received data is not running

[0364] *****5>The receiving PDCP layer device may store the field values of the complete Ethernet header fields, store the corresponding context identifier, generate feedback, include the context identifier corresponding to the data or an indicator indicating successful reception in the feedback, and send the feedback. In addition, the receiving PDCP layer device may allow the feedback to be sent without applying integrity protection or encryption procedures in order to enable fast processing.

[0365] *****5>The receiving PDCP layer device may start a timer for the context identifier corresponding to the received data.

[0366] ***3>When the receiving PDCP layer device at the receiving end receives data including a compressed Ethernet header or an EHC header including an indicator indicating that compression has occurred, by performing decryption or integrity verification on it

[0367] ****4>The receiving PDCP layer device may, without generating feedback, recover or reconstruct the compressed or omitted header fields or field values in the compressed Ethernet header from the buffer or context corresponding to the context identifier of the data, and configure the complete Ethernet header fields for decompression. Here, when the ROHC header compression process is also configured, the ROHC header compression or decompression process may be performed independently for higher layer device headers other than the Ethernet header.

[0368] ****4>When the timer for the context identifier corresponding to the received data is running, the timer may be interrupted.

[0369] ***3>When the timer for the context identifier expires

[0370] ****4>The receiving PDCP layer device may generate feedback corresponding to the context identifier, include the context identifier or an indicator indicating successful reception in the feedback, and send the feedback. In addition, the receiving PDCP layer device may allow the feedback to be sent without applying integrity protection or encryption procedures in order to enable fast processing.

[0371] ****4>The timer corresponding to the context identifier may be restarted.

[0372] **2>Third method: For UM bearers, when data for a specific context identifier is sent for the first time, when no feedback is received for the complete Ethernet header (or uncompressed Ethernet header) sent for the specific context identifier, or when the context for Ethernet header compression or decompression is initialized, the transmitting PDCP layer device may generate an EHC header and a complete uncompressed Ethernet header, configure the context identifier or an indicator indicating that compression has not occurred in the EHC header, perform integrity protection or encryption on the corresponding data, and send the data. In addition, the transmitting PDCP layer device may include the uncompressed Ethernet header, the complete Ethernet header, or the EHC header in the data, and perform the transmission of the data until a feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header is received. When a feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header is received, the transmitting PDCP layer device may start Ethernet header compression on the data to be sent. Specifically, the transmitting PDCP layer device may compress or omit the compressible or fields with fixed values among the fields of the Ethernet header, and include the non-compressible or fields with non-fixed values, may generate an EHC header, and include an indicator indicating that the Ethernet header has been compressed or the corresponding context identifier in the EHC header, and may perform integrity protection or encryption on the data with the compressed Ethernet header, and send the data. Here, when data including the complete Ethernet header, the uncompressed Ethernet header, or an EHC header including an indicator indicating that compression has not occurred is received, by performing decryption or integrity verification on it, the receiving PDCP layer device at the receiving end may store the field values of the complete Ethernet header fields, store the corresponding context identifier, generate a feedback, include the context identifier corresponding to the data or an indicator indicating successful reception in the feedback, and send the feedback. In addition, the receiving PDCP layer device may allow the feedback to be sent without applying the integrity protection or encryption process in order to achieve fast processing. When the receiving PDCP layer device at the receiving end receives data including a compressed Ethernet header or an EHC header including an indicator indicating that compression has been performed, by performing decryption or integrity verification on it, the receiving PDCP layer device may, without generating a feedback, recover or reconstruct the compressed or omitted header fields or field values in the compressed Ethernet header from the buffer or context of the context identifier corresponding to the data, and configure the complete Ethernet header fields or perform decompression on them to send them to the higher layer device. Here, when the ROHC header compression process is also configured, the ROHC header compression or decompression process may be performed independently for the higher layer device headers other than the Ethernet header.For an AM bearer, when data for a specific context identifier is sent for the first time, when no feedback is received for the complete Ethernet header (or uncompressed Ethernet header) sent for the specific context identifier, or when the context for Ethernet header compression or decompression is initialized, the transmitting PDCP layer device may generate an EHC header and a complete uncompressed Ethernet header, configure the context identifier or an indicator indicating that compression has not occurred in the EHC header, perform integrity protection or encryption on the corresponding data, and send the data once. For subsequent data, the transmitting PDCP layer device may start to perform Ethernet header compression on the data to be sent. Specifically, the transmitting PDCP layer device may compress or omit the compressible or fields with fixed values among the fields of the Ethernet header, include the non-compressible or fields with non-fixed values, may generate an EHC header, and include an indicator indicating that the Ethernet header has been compressed or the corresponding context identifier in the EHC header, and may perform integrity protection or encryption on the data with the compressed Ethernet header, and send the data. Here, since there is no data loss for the AM bearer, and the receiving PDCP layer device performs reordering and data processing in ascending order of the sequence number, when data including a complete Ethernet header, an uncompressed Ethernet header or an EHC header including an indicator indicating that compression has not occurred is received, by performing decryption or integrity verification on it, the receiving PDCP layer device at the receiving end may store the field values of the complete Ethernet header fields, and store the corresponding context identifier, and may not generate feedback, and may not use the feedback for the AM bearer (according to another method, generate one feedback and send it together with the UM bearer). When the receiving PDCP layer device at the receiving end receives data including a compressed Ethernet header or an EHC header including an indicator indicating that compression has been performed, by performing decryption or integrity verification on it, the receiving PDCP layer device may recover or reconstruct the compressed or omitted header fields or field values in the compressed Ethernet header from the buffer or context of the context identifier corresponding to the data, and configure the complete Ethernet header fields or perform decompression on it to send it to the upper layer device. Here, when the ROHC header compression process is also configured, the ROHC header compression or decompression process may be performed independently for the upper layer device headers other than the Ethernet header.

[0373] **2> Fourth Method: For AM bearers, when sending data for a specific context identifier for the first time, when no feedback is received for the complete Ethernet header (or uncompressed Ethernet header) sent for the specific context identifier, or when the context for Ethernet header compression or decompression is initialized, the transmitting PDCP layer device may generate an EHC header and a complete uncompressed Ethernet header, configure the context identifier or an indicator indicating that compression has not occurred in the EHC header, perform integrity protection or encryption on the corresponding data, and send the data once. For subsequent data, the transmitting PDCP layer device may start performing Ethernet header compression on the data to be sent. Specifically, the transmitting PDCP layer device may compress or omit the compressible or fields with fixed values among the fields of the Ethernet header, and include the non-compressible or fields with non-fixed values, may generate an EHC header, and include an indicator indicating that the Ethernet header has been compressed or the corresponding context identifier in the EHC header, and may perform integrity protection or encryption on the data with the compressed Ethernet header, and send the data. Here, since there is no data loss for AM bearers, and the receiving PDCP layer device performs reordering and data processing in ascending order of the sequence numbers, when receiving data including a complete Ethernet header, an uncompressed Ethernet header, or an EHC header including an indicator indicating that compression has not occurred, by performing decryption or integrity verification on it, the receiving PDCP layer device at the receiving end may store the field values of the complete Ethernet header fields and store the corresponding context identifier, and may not generate feedback and may not use the feedback for AM bearers (according to another method, generate one feedback and send it together with UM bearers). When the receiving PDCP layer device at the receiving end receives data including a compressed Ethernet header or an EHC header including an indicator indicating that compression has been performed, by performing decryption or integrity verification on it, the receiving PDCP layer device may recover or reconstruct the compressed or omitted header fields or field values in the compressed Ethernet header from the buffer or context of the context identifier corresponding to the data, and configure the complete Ethernet header fields or perform decompression on it to send it to the upper layer device. Here, when the ROHC header compression process is also configured, the ROHC header compression or decompression process may be performed independently for upper layer device headers other than the Ethernet header. For UM bearers, when sending data for a specific context identifier for the first time, when no feedback is received for the complete Ethernet header (or uncompressed Ethernet header) sent for the specific context identifier, or when the context for Ethernet header compression or decompression is initialized, the transmitting PDCP layer device may generate an EHC header and a complete uncompressed Ethernet header, configure the context identifier or an indicator indicating that compression has not occurred in the EHC header, perform integrity protection or encryption on the corresponding data, and send the data.In addition, the transmitting PDCP layer device may include an uncompressed Ethernet header, a complete Ethernet header, or an EHC header in the data, and perform the transmission of the data until it receives feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header. When receiving the feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header, the transmitting PDCP layer device may start to perform Ethernet header compression on the data to be transmitted. Specifically, the transmitting PDCP layer device may compress or omit the compressible or fixed-value fields among the fields of the Ethernet header, and include the non-compressible or non-fixed-value fields, may generate an EHC header, and include an indicator indicating that the Ethernet header has been compressed or its corresponding context identifier in the EHC header, and may perform integrity protection or encryption on the data with the compressed Ethernet header, and transmit the data. Here, the receiving PDCP layer device at the receiving end may introduce a separate timer (the timer value may be configured for each bearer or each PDCP layer device through an RRC message, or may be configured together with the Ethernet header compression or decompression function) to perform a process to prevent frequent feedback, as follows.

[0374] ***3>When the receiving PDCP layer device drives the timer, the configured timer value above may be applied, and the timer may be driven for each context identifier.

[0375] ***3>In the above, when the receiving PDCP layer device at the receiving end receives the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header including an indicator indicating that compression has not occurred by performing decryption or integrity verification on it

[0376] ****4>When the timer for the context identifier corresponding to the received data is not running

[0377] *****5>The receiving PDCP layer device may store the field values of the complete Ethernet header fields, store the corresponding context identifier, generate feedback, include the context identifier corresponding to the data or an indicator indicating successful reception in the feedback, and transmit the feedback. In addition, the receiving PDCP layer device may allow the feedback to be transmitted without applying the integrity protection or encryption process in order to achieve fast processing.

[0378] *****5>The receiving PDCP layer device may start a timer for the context identifier corresponding to the received data.

[0379] ***3>When the receiving PDCP layer device at the receiving end receives the data including the compressed Ethernet header or the EHC header including an indicator indicating that compression has occurred, by performing decryption or integrity verification on it

[0380] ****4>The receiving PDCP layer device can recover or reconstruct the compressed or omitted header fields or field values in the compressed Ethernet header from the buffer or context corresponding to the context identifier of the data without generating feedback, and configure the complete Ethernet header fields for decompression. Here, when the ROHC header compression process is also configured, the ROHC header compression or decompression process can be independently executed for the higher layer device headers other than the Ethernet header.

[0381] ****4>When the timer corresponding to the context identifier for the received data is running, the timer can be interrupted.

[0382] ***3>When the timer for the context identifier expires

[0383] ****4>The receiving PDCP layer device can generate feedback corresponding to the context identifier, include the context identifier or an indicator indicating successful reception in the feedback, and send the feedback. In addition, the receiving PDCP layer device can allow the feedback to be sent without applying the integrity protection or encryption process to achieve fast processing.

[0384] ****4>The timer corresponding to the context identifier can be restarted.

[0385] -1>In the above, when the UE receives an RRC message (e.g., RRCReconfiguration message) or an RRCReconfiguration message including ReconfigurationWithSync information, when an indicator indicating to continue using the context for Ethernet header compression or decompression is configured for each bearer or in the PDCP layer device configuration information.

[0386] **2>When the PDCP reconstruction process is indicated or executed for a bearer or the PDCP layer device

[0387] ***3>For an AM bearer, when an indicator indicating to continue using the context for Ethernet header compression or decompression is not configured in the PDCP layer device configuration information, the Ethernet header decompression process can be executed by applying the context for Ethernet header compression or decompression to the data (PDCP SDU or PDCP PDU) stored for the AM bearer or all the stored data (PDCP SDU).

[0388] ***3>For an AM bearer or a UM bearer, when an indicator indicating to continue using the context for Ethernet header compression or decompression is not configured in the PDCP layer device configuration information, the context for Ethernet header compression or decompression for the uplink can be initialized or released. In addition, the transmitting PDCP layer device can send data including an uncompressed Ethernet header or a complete Ethernet header.

[0389] ***3>For an AM bearer or a UM bearer, when an indicator indicating to continue using the context for Ethernet header compression or decompression is configured in the PDCP layer device configuration information, the transmitting PDCP layer device can continue to apply the Ethernet header compression process to the data to be transmitted and send data including a compressed Ethernet header without initializing or releasing the context for Ethernet header compression or decompression for the uplink.

[0390] ***3>For an AM bearer or a UM bearer, when an indicator indicating to continue using the context for Ethernet header compression or decompression is not configured in the PDCP layer device configuration information, the context for Ethernet header compression or decompression for the downlink can be initialized or released. In addition, the transmitting PDCP layer device can send data including an uncompressed Ethernet header or a complete Ethernet header.

[0391] ***3>For an AM bearer or a UM bearer, when an indicator indicating to continue using the context for Ethernet header compression or decompression is configured in the PDCP layer device configuration information, the transmitting PDCP layer device can continue to apply the Ethernet header compression process to the data to be transmitted and send data including a compressed Ethernet header without initializing or releasing the context for Ethernet header compression or decompression for the downlink.

[0392] -1>In the above, when the UE receives an RRC message (e.g., an RRCReconfiguration message) or an RRCReconfiguration message including ReconfigurationWithSync information (when an indicator indicating to continue using the context for Ethernet header compression or decompression is configured for each bearer or in the PDCP layer device configuration information),

[0393] **2>When the PDCP re - establishment process is indicated or executed for a bearer or a PDCP layer device

[0394] ***3>The Ethernet header decompression process can be performed by applying the context for Ethernet header compression or decompression to the data (PDCP SDU or PDCP PDU) stored for the AM bearer or all the stored data (PDCP SDU).

[0395] ***3>For an AM bearer or a UM bearer, when it is possible to initialize or release a context for Ethernet header compression or decompression regarding the uplink. In addition, the transmitting PDCP layer device may transmit data including an uncompressed Ethernet header or a complete Ethernet header.

[0396] ***3>For an AM bearer or a UM bearer, when it is possible to initialize or release a context for Ethernet header compression or decompression regarding the downlink. In addition, the transmitting PDCP layer device may transmit data including an uncompressed Ethernet header or a complete Ethernet header.

[0397] In Figure 1o In the second embodiment of the effective handover method, when UE 1o-20 receives a handover command message from source base station 1o-05 while performing data transmission or reception to or from the source base station in the first stage 1o-01, in the case where the second embodiment of the effective handover method described in the present disclosure (e.g., DAPS handover method) is indicated by the received handover command message, or when the second embodiment of the effective handover method described in the present disclosure (e.g., DAPS handover method) is indicated for each bearer, even when the handover command message is received, data transmission or reception can be continuously performed by the source base station and the protocol layer device 1o-22 of the first bearer, so as to minimize the data interruption time occurring during handover.

[0398] In addition, when the RRC layer device recognizes an indication of the second embodiment of the effective handover method described in the present disclosure (e.g., DAPS handover method) through the handover command message, or confirms an indicator of the DAPS handover method for each bearer, the RRC layer device transmits the indicator to each bearer or the PDCP layer device corresponding to the bearer for which the DAPS handover method is indicated, and when the PDCP layer device receives the indicator, the PDCP layer device switches from the structure of the first PDCP layer device to the structure of the second PDCP layer device. Here, the first PDCP layer device structure may indicate a general PDCP layer device structure, in which a compression process or an encryption, decryption, integrity protection, or verification process may be performed on data to be transmitted to the base station or received from the base station based on one compression context or security key. In addition, the second PDCP layer device structure may indicate a structure in which one PDCP layer device may store a header (or data) compression context or security key of the source base station, and may perform a compression process or an encryption, decryption, integrity protection, or verification process on data to be transmitted to the base station or received from the base station based on the stored header compression context or security key.

[0399] In addition, the second PDCP layer device structure may indicate a structure in which the header (or data) compression context or security key of the target base station is stored separately, and based on the stored header compression context or security key, a compression process or encryption, decryption, integrity protection, or verification process may be performed on the data to be sent to the target base station or the data received from the target base station. Here, the first stage may include the stage where the UE receives a handover command message (RRCReconfiguration message) from the base station. In addition, when switching to the second PDCP layer device structure according to the configuration included in the received handover command message, the protocol layer devices (PHY layer device, MAC layer device, RLC layer device, or PDCP layer device, 1o-21) for the second bearer of the target base station may be pre-configured or established. In addition, the security key of the target base station may be derived and updated, and the header (or data) compression context of the target base station may be configured.

[0400] In addition, in the case where the UE receives a handover command message, the DAPS handover method described in the present disclosure is indicated by the handover command message, the DAPS handover method is indicated for a specific bearer, or the PDCP reordering timer value is newly configured, the UE may update the variable for reordering to the expected next received PDCP sequence number or count value, and for each bearer or for the bearer for which the DAPS handover method is indicated, when switching from the first PDCP layer device structure or its function described in the present disclosure to the second PDCP layer device structure or its function, stop and restart the reordering timer. In addition, when receiving a handover command message (e.g., RRC reconfiguration message), the RRC layer device of the UE may start a first timer (e.g., T304). In addition, when the random access procedure to the target base station is performed and the random access procedure is successfully completed (e.g., when the first condition described in the present disclosure is satisfied), the first timer may be interrupted. When the first timer expires due to a handover failure, in the case where the connection to the source base station is valid, fallback is performed, the handover failure is reported to the source base station, and connection recovery is attempted. When the connection to the source base station is invalid, an RRC connection reconstruction procedure may be performed.

[0401] In an embodiment, the handover command message is configured and established such that the second bearer has the same bearer identifier as the first bearer to prevent data interruption time for each bearer. In addition, in a second embodiment, the PDCP layer device of the first bearer and the PDCP layer device of the second bearer may operate logically like one PDCP layer device, and a more detailed operation method will be described in Figure 1iAs described. Further, in the second embodiment, when the UE is capable of transmitting uplink data to both the source base station and the target base station, the uplink data transmission in the second embodiment can be performed only to one of the source base station and the target base station, so as to prevent a problem of reduced coverage due to insufficient transmission power of the UE, or a problem of requesting transmission resources from the base station and determining whether to transmit uplink data to the base station when performing uplink data transmission (i.e., link selection).

[0402] Specifically, in the second embodiment, when the UE does not have the ability to transmit uplink data to different base stations simultaneously at different frequencies or the same frequency (dual uplink transmission), the UE can perform uplink data transmission only to one of the source base station and the target base station in a single time unit. Therefore, the UE can request scheduling from only one of the source base station and the target base station, and can send a report of the size of the data to be transmitted from the PDCP layer device (e.g., buffer status report transmission) to only one of the source base station and the target base station, and receive uplink transmission resources, thereby transmitting uplink data to only one of the base stations.

[0403] Further, even when the UE receives a handover command message from the source base station, the UE does not initialize the MAC layer device of the first bearer to prevent data loss caused by continued data transmission or reception due to HARQ retransmission. In addition, the RLC layer device in the AM mode can continue RLC retransmission. According to another method, when the second embodiment (DAPS handover method) of the effective handover method described in the present disclosure is indicated for each bearer by the handover command message, data transmission or reception to or from the source base station can be performed only on the PDCP layer device, RLC layer device, or MAC layer device corresponding to the bearer or logical channel identifier for which the second embodiment (DAPS handover method) is indicated by the handover command message, or only on the data corresponding to the bearer or logical channel identifier.

[0404] In addition, even when the first condition described in the present disclosure is satisfied (when the uplink data transmission is switched to the target base station), the RLC control data (RLC status report), PDCP control data (ROHC feedback, PDCP status report, EHC feedback (feedback of the Ethernet header compression method), or HARQ retransmission) may be continuously transmitted or received only for the PDCP layer device, RLC layer device, or MAC layer device corresponding to the bearer or logical channel identifier for which the second embodiment (DAPS handover method) is indicated by the handover command message to the source base station. In addition, when the second embodiment (DAPS handover method) of the effective handover method described in the present disclosure is indicated or has been indicated for each bearer by the handover command message, the data transmission or reception to or from the source base station may be interrupted for the PDCP layer device, RLC layer device, or MAC layer device corresponding to the bearer or logical channel identifier for which the second embodiment (DAPS handover method) is not indicated by the handover command message.

[0405] In Figure 1o the second embodiment of the effective handover method, even when the UE 1o-20 performs the random access procedure to the target base station 1o-10 indicated by the handover command message through the protocol layer device of the second bearer in the second phase 1o-02, the UE may continue to perform the data transmission or reception (uplink data transmission or downlink data reception) to or from the source base station through the protocol layer device of the first bearer. The second phase may include the UE performing a cell selection or reselection procedure and performing the random access procedure to the target cell indicated by the handover command message (RRCReconfiguration message) received from the source base station.

[0406] According to Figure 1oSecond Embodiment of the Effective Handoff Method. When UE 1o-20 satisfies the first condition in the third stage 1o-03, for a bearer configured with the DAPS handoff method, UE 1o-20 may stop sending uplink data to the source base station through the protocol layer device 1o-22 of the first bearer and may send uplink data to the target base station through the protocol layer device 1o-21 of the second bearer. In addition, the UE may continue to receive downlink data from the source base station and the target base station through the protocol layer devices of the first bearer and the second bearer. Here, the third stage includes that when the first condition is satisfied, the UE switches the uplink transmission from the source base station to the target base station. Specifically, the third stage includes that the UE sends uplink data to the source base station until the first condition is satisfied, and when the first condition is satisfied, stops sending uplink data to the source base station through the first bearer and starts sending uplink data to the target base station through the second bearer. Specifically, for a bearer configured with the DAPS handoff method, the PDCP layer device in the second PDCP layer device structure of the present disclosure satisfies the first condition when sending uplink data through the first bearer and receives an indicator from a lower layer device (when the random access procedure to the target base station is successful from the MAC layer device) or a higher layer device (when the first timer in the RRC layer device expires), and the PDCP layer device may stop and switch the uplink data transmission through the first bearer, thereby starting the uplink data transmission through the second bearer. In addition, as shown in the structure of the PDCP layer device described in Figure 1i , the receiving PDCP layer device 1o-21 of the second bearer may be driven as if together with the receiving PDCP layer device 1o-22 of the first bearer and may continuously perform data reception from the source base station or the target base station by using stored transmission / reception data, sequence number information, or information such as header compression and decompression context. Here, the first condition may be one of the following conditions. The first condition described below describes the uplink data transmission handoff time at which the transmission resources are most effectively used and the data interruption time can be minimized as much as possible.

[0407] - When the UE successfully completes the process of random access to the target base station through the layer device (e.g., MAC layer device) of the second bearer, when the UE successfully completes the process of random access to the target base station through the layer device (e.g., MAC layer device) of the second bearer and receives the allocation of the first uplink transmission resource from the target base station, or when the uplink transmission resource is first indicated to the UE, it may be determined that the first condition is satisfied.

[0408] *For example, more specifically, when the UE receives a handover command message from the source base station and receives an indication of random access to the target base station, when the indicated random access is a contention-free random access process (CFRA) (for example, when a pre-specified preamble or UE cell identifier (e.g., C-RNTI) is allocated)

[0409] **Since it can be considered that the random access process is successfully completed when the UE sends a predetermined preamble to the cell of the target base station and receives a random access response (RAR) message, when the first uplink transmission resource allocated, included, or indicated in the random access response message is received, it can be determined that the first condition is satisfied. According to another method, when the uplink transmission resource is received for the first time after the RAR reception, it can be determined that the first condition is satisfied.

[0410] *When the UE receives a handover command message from the source base station and receives an indication of random access to the target base station, when the indicated random access is a contention-based random access process (CBRA) (for example, when a pre-specified preamble or UE cell identifier (e.g., C-RNTI) is not allocated)

[0411] **When the UE sends a preamble (e.g., a random preamble) to the cell of the target base station, receives a random access response (RAR) message, sends message 3 (e.g., a handover completion message) by using the uplink transmission resource allocated, included, or indicated by the random access response message, receives a MAC CE (contention resolution MAC CE) indicating that the contention has been resolved by message 4 from the target base station, or receives an uplink transmission resource by means of a PDCCH corresponding to the UE's C-RNTI, the UE may consider that the process of random access to the target base station has been successfully completed. Thereafter, the UE may monitor the PDCCH, and when the uplink transmission resource is received for the first time or when an indication is received for the first time by means of a PDCCH corresponding to the UE's C-RNTI, it is determined that the first condition is satisfied. According to another method, when the size of the uplink transmission resource allocated by the random access response message is sufficient to send message 3 and the UE is able to additionally send uplink data, it can be determined that the uplink transmission resource has been received for the first time and the first condition is satisfied. That is to say, when the RAR is received, it can be determined that the uplink transmission resource has been received for the first time, and it can be determined that the first condition is satisfied.

[0412] -When a handover method that does not require a random access process (handover without RACH) is also indicated in the handover command message received by the UE,

[0413] *When the uplink transmission resources of the target base station are included in the handover command message,

[0414] **When the UE sends Message 3 (e.g., handover completion message or RRCReconfigurationComplete message) via the uplink transmission resources of the target base station and receives the UE identity confirmation MAC CE from the base station via Message 4, or when the UE receives the uplink transmission resources via the PDCCH corresponding to the UE's C-RNTI, it can be determined that the random access procedure has been successfully completed and the first condition is satisfied. According to another method, when, after the random access procedure has been successfully completed, the first uplink transmission resources are received via the PDCCH corresponding to the UE's C-RNTI by monitoring the PDCCH, it can be determined that the first condition is satisfied.

[0415] *When the uplink transmission resources for the target base station are not included in the handover command message

[0416] **When the UE performs PDCCH monitoring on the target base station (or cell), receives the uplink transmission resources via the PDCCH corresponding to the UE's C-RNTI, sends Message 3 (e.g., handover completion message or RRCReconfigurationComplete message) via the uplink transmission resources and receives the UE identity confirmation MAC CE from the base station, or receives the uplink transmission resources via the PDCCH corresponding to the UE's C-RNTI, it can be determined that the random access procedure has been successfully completed and the first condition is satisfied. According to another method, when, after the random access procedure has been successfully completed, the first uplink transmission resources are received via the PDCCH corresponding to the UE's C-RNTI by monitoring the PDCCH, it can be determined that the first condition is satisfied.

[0417] Hereinafter, an effective method for switching uplink data from a source base station to a target base station in the DAPS handover method described in the present disclosure will be described. Whether the first condition is satisfied can be confirmed or detected by the MAC layer device or RRC layer device of the target base station corresponding to the second bearer by one of the following methods, and the following methods can be combined to be extended into a new method.

[0418] - The first method: For example, when the RRCReconfiguration message received by the UE indicates a DAPS handover, the UE may configure the MAC layer device for the target base station corresponding to the second bearer, and the MAC layer device may perform a random access procedure and identify whether the first condition is met. Additionally, when the first condition is met, the MAC layer device may send an indicator to the higher layer device (e.g., the PDCP layer device) of the bearer for which the DAPS handover method is configured, where the indicator indicates the handover of the uplink data transmission from the source base station through the first bearer to the target base station in the DAPS handover method described in the present disclosure.

[0419] - The second method: According to another method, for example, when the RRCReconfiguration message received by the UE indicates a DAPS handover, the UE may configure the MAC layer device for the target base station corresponding to the second bearer, and the MAC layer device may perform a random access procedure and identify whether the first condition is met. Additionally, when the first condition is met, the MAC layer device may send an indicator indicating that the first condition is met to the higher layer device (e.g., the RRC layer device). Furthermore, the higher layer device (e.g., the RRC layer device) may send an indicator to the lower layer device (e.g., the PDCP layer device) of the bearer for which the DAPS handover method is configured, where the indicator indicates the handover of the uplink data transmission from the source base station through the first bearer to the target base station in the DAPS handover method described in the present disclosure. Here, when the first condition described in the present disclosure is met, or when the procedure for performing a random access to the target base station is successfully executed, the higher layer device (e.g., the RRC layer device) stops the first timer. Therefore, when the first timer expires, the RRC layer device may send an indicator indicating the handover of the uplink data transmission to the PDCP layer device of the bearer for which the DAPS handover method is configured.

[0420] - The third method: When the RRCReconfiguration message received by the UE indicates a DAPS handover, the UE may configure the MAC layer device for the target base station corresponding to the second bearer, and when the RRC layer device of the UE sends an indicator indicating the execution of the DAPS handover to the lower layer device (e.g., the MAC layer device), the MAC layer device may perform a random access procedure and identify whether the first condition is met. Additionally, when the first condition is met, the MAC layer device may send an indicator to the higher layer device (e.g., the PDCP layer device) of the bearer for which the DAPS handover method is configured, where the indicator indicates the handover of the uplink data transmission from the source base station through the first bearer to the target base station in the DAPS handover method described in the present disclosure.

[0421] Fourth method: According to another method, when the RRCReconfiguration message received by the UE indicates a DAPS handover, the UE may configure the MAC layer device for the target base station corresponding to the second bearer, and when the RRC layer device of the UE sends an indicator indicating that the RRC layer device performs a DAPS handover to a lower layer device (e.g., the MAC layer device), the MAC layer device may perform a random access procedure and identify whether the first condition is satisfied. In addition, when the first condition is satisfied, the MAC layer device may indicate to a higher layer device (e.g., the RRC layer device) that the first condition is satisfied. When this indicator is confirmed, since the first timer is stopped when the first condition described in the present disclosure is satisfied or when the process of performing a random access to the target base station is successfully executed, the first timer may be interrupted. In addition, the higher layer device (e.g., the RRC layer device) may send an indicator to a lower layer device (e.g., the PDCP layer device) of the bearer for which the DAPS handover method is configured, where the indicator indicates the handover of the uplink data transmission from the source base station to the target base station in the DAPS handover method described in the present disclosure.

[0422] According to the first method, the second method, the third method, or the fourth method, when the PDCP layer device receives an indicator indicating that the first condition is satisfied or an indicator indicating a handover of the uplink data transmission from the source base station to the target base station from a higher layer device (e.g., the RRC layer device) or a lower layer device (e.g., the MAC layer device) (e.g., when the DAPS handover method is indicated), the PDCP layer device may perform the protocol layer device operations described below to effectively perform the handover of the uplink data transmission, and may perform one or more of the following operations to prevent data loss due to the uplink data transmission. The following operations may be applied to the PDCP layer device connected to the AM DRB or UM DRB (the RLC layer device operating in the AM mode or the RLC layer device operating in the UM mode). Here, before the first condition is satisfied or before an indicator indicating that the first condition is satisfied is received, when there is data to be sent in the buffer, the PDCP layer device may indicate the size or amount of the data to be sent (e.g., the PDCP data volume) to the MAC layer device of the first bearer for the source base station, and notify that there is data to be sent, and may perform the uplink data transmission to the source base station. Then, the MAC layer device of the first bearer for the source base station may perform a scheduling request or a buffer status report process to the source base station in order to receive an allocation of uplink transmission resources. However, when the first condition is satisfied or an indicator indicating that the first condition is satisfied is received, the handover of the uplink data transmission to the target base station may be performed as follows for the bearer for which the DAPS handover method is configured.

[0423] The uplink or downlink ROHC context of the source base station is not initialized and used as it is, while the uplink or downlink ROHC context of the target base station can be initialized and start in an initial state (e.g., the IR state in U mode).

[0424] Regarding the first data (e.g., PDCP SDU) for which successful transmission from the lower layer (e.g., the RLC layer device corresponding to the first bearer of the source base station) has not been confirmed, to the data segments (PDCP SDUs in the buffer) in ascending order of the count value (or PDCP sequence number) assigned before the first condition is met or before an indicator indicating that the first condition is met is received, the PDCP layer device (which is connected to the AM DRB (the RLC layer device operating in the AM mode) (all previously stored PDCP PDUs are discarded (e.g., the PDCP SDUs are not discarded to prevent loss of the original data))) performs a new header compression process based on the header context for the target base station, performs the integrity process or encryption process again by applying the security key for the target base station, configures the PDCP header, and sends it to the lower layer device (the RLC layer device for the second bearer of the target base station) to perform retransmission or transmission. That is, the sender performs cumulative retransmission starting from the first data for which successful transmission has not been confirmed.

[0425] According to another method, when performing the retransmission described above, the retransmission can be performed only on the data for which successful transmission from the lower layer (e.g., the RLC layer device for the first bearer of the source base station) has not been confirmed. More specifically, only regarding the data segments (e.g., PDCP SDUs) for which successful transmission from the lower layer (e.g., the RLC layer device), which is the first protocol layer device for the source base station, has not been confirmed, the PDCP layer device connected to the AM DRB (or the RLC layer device operating in the AM mode) (all previously stored PDCP PDUs for transmission to the source base station through the first protocol layer device connected to the PDCP layer device are discarded (e.g., the PDCP SDUs are not discarded to prevent loss of the original data)) performs a new header or data compression process by applying the security key or header compression (or data compression) protocol context corresponding to the target base station based on the count value (or PDCP sequence number) assigned before the first condition is met or before an indicator indicating that the first condition is met is received, performs the integrity process or encryption process again by applying the security key to configure the PDCP header, and sends it to the lower layer device, where the lower layer device is the second protocol layer device for transmission to the target base station, to perform retransmission or transmission. That is, to prevent waste of transmission resources, selective retransmission can be performed only on the data for which successful transmission has not been confirmed.

[0426] According to another method, after releasing the lower layer (e.g., a transmitting or receiving RLC layer device or MAC layer device) that is the first protocol layer device for sending data to the source base station, a transmitting or retransmitting operation can be performed. When the transmitting or retransmitting process is extended to UM DRB, the PDCP layer device connected to the RLC layer device operating in UM mode can consider the data that has not been sent to the lower layer device, the data for which the PDCP discard timer has not expired, or the data for which a PDCP sequence number (or count value) has already been assigned as data received from a higher layer device or newly received data, can not restart the PDCP discard timer for each data, can perform header (or data) compression for the data by using the header (or data) compression context or security key for the target base station, or perform its encryption or integrity protection process, and can generate and conjugate the PDCH header to perform the transmission or retransmission. Before the process is triggered, the data can be processed in ascending order of the assigned count values, and the transmission or retransmission can be performed. In addition, the window state variable of the PDCP layer device connected to UM DRB or AM DRB is not initialized, but is maintained and used as it is.

[0427] When there is data to be transmitted in the buffer, the PDCP layer device can send an indication (e.g., PDCP data volume) indicating the size or amount of the data to be transmitted to the MAC layer device of the second bearer for the target base station to notify that there is data to be transmitted, and can perform a handover of the uplink data transmission to the target base station. Then, the MAC layer device of the second bearer for the target base station can perform a scheduling request or buffer status report process to the target base station in order to receive an allocation of uplink transmission resources.

[0428] In a second embodiment of the efficient handover method described in the present disclosure (e.g., DAPS handover method), even after the UE receives a handover command message (e.g., RRCReconfiguration message), the UE can continue to receive downlink data from the source base station or the target base station through the protocol layer device for the first bearer for the source base station or the second bearer for the target base station, and the UE can continue to receive downlink data from the source base station (or the target base station). Further, for the AM bearer, the UE can allow RLC status reports other than data to be continuously transmitted to the source base station (or the target base station) via the protocol layer device of the first bearer (or the second bearer) via the uplink, so that the UE can smoothly receive downlink data from the source base station (or the target base station), or so that the source base station (or the target base station) can smoothly transmit downlink data. That is, even when the first condition is satisfied and thus the UE switches the uplink data transmission to the target base station, when it is necessary to send an RLC status report, HARQ ACK or NACK, or PDCP control data (PDCP ROHC feedback, PDCP status report, or EHC feedback (feedback of the Ethernet header compression method)) to the source base station, data transmission can be allowed to be performed through the first bearer for the source base station. This is because, in the case of the AM bearer, after sending data to the sending end, when the RLC status report does not indicate successful transmission (i.e., when the RLC status report is not received), data cannot be continuously sent thereafter.

[0429] Specifically, in Figure 1o the second embodiment of the efficient handover method, even when the first condition is satisfied in the third phase 1o-03 and thus the UE 1o-20 stops sending uplink data to the source base station through the protocol layer device 1o-22 of the first bearer and switches to start uplink data transmission to the target base station through the protocol layer device 1o-21 of the second bearer, the UE can continue to send HARQ ACK or HARQ NACK information, RLC status reports (ACK or NACK information), PDCP control data (e.g., PDCP status reports, ROHC feedback information, or EHC feedback (feedback of the Ethernet header compression method)) through the protocol layer device of the first bearer (or the second bearer), so that the UE can smoothly receive downlink data from the source base station (or the target base station), or so that the source base station (or the target base station) can smoothly transmit downlink data. In addition, in Figure 1oIn the second embodiment of the effective handover method, even when the first condition is satisfied in the third stage 1o-03 and thus the UE stops sending uplink data to the source base station through the protocol layer device 1o-22 of the first bearer and switches to start sending uplink data to the target base station through the protocol layer device 1o-21 of the second bearer, the UE can continue to perform data transmission due to HARQ retransmission by the MAC layer device or retransmission by the AM mode RLC layer device to prevent data loss to the source base station. Here, in the third stage 1o-03, when the first condition is satisfied and thus the UE 1o-20 stops sending uplink data to the source base station through the protocol layer device 1o-22 of the first bearer and switches to start sending uplink data to the target base station through the protocol layer device 1o-21 of the second bearer, the source base station or the target base station can divide the time and accordingly allocate transmission resources to the UE so that the uplink transmission resources to the target base station and the uplink transmission resources to the source base station do not conflict. When the uplink transmission resources to the target base station and the uplink transmission resources to the source base station conflict and overlap, the UE can give priority to the uplink transmission resources to the source base station and perform data transmission to the source base station in order to maintain or continuously receive downlink data transmission from the source base station without any problems. According to another method, when the uplink transmission resources to the target base station and the uplink transmission resources to the source base station conflict and overlap, the UE can give priority to the uplink transmission resources to the target base station and perform data transmission to the target base station in order to maintain the downlink data transmission from the target base station.

[0430] Specifically, when the UE receives a handover command message, when a handover corresponding to the second embodiment of the present disclosure is indicated (for example, DAPS handover), or when a handover is indicated for each bearer, the UE or the bearer for which the DAPS handover is indicated can perform a scheduling request through the first protocol layer device and send a buffer status report to the source base station before the first condition is satisfied to receive uplink transmission resources, can send uplink data, and receive downlink data from the source base station. However, when the first condition is satisfied, the UE no longer sends data to the source base station and switches the uplink to perform a scheduling request through the second protocol layer device, and can send a buffer status report to the target base station to receive uplink transmission resources and send uplink data to the target base station. However, the UE can continue to receive downlink data from the source base station, and even after switching the uplink transmission, the UE can continue to send HARQ ACK or HARQ NACK, RLC status report, or PDCP control data (for example, PDCP status report or ROHC feedback information) corresponding to the downlink data. In addition, even when the first condition is satisfied, the UE can continue to receive downlink data from the source base station or the target base station.

[0431] In Figure 1o In the second embodiment of the effective handover method, in the fourth stage 1o-04, when the UE 1o-20 satisfies the second condition, the UE may stop receiving downlink data from the source base station 1o-05 through the protocol layer device 1o-22 of the first bearer, or release the connection to the source base station. The second condition may be one of the following conditions. In addition, the PDCP layer device 1o-21 of the second bearer may continuously perform data transmission to the target base station or data reception from the target base station by using the data transmitted or received, sequence number information, or information such as header compression and decompression context stored in the PDCP layer device 1o-22 of the first bearer.

[0432] When the UE receives a message (e.g., an RRC message (e.g., an RRCReconfiguration message)) including an indicator for releasing the connection to the source base station, or a MAC CE, an RLC control PDU, or a PDCP control PDU from the target base station, it may be determined that the second condition is satisfied.

[0433] When the UE executes the second embodiment of the effective handover method described in the present disclosure (e.g., the DAPS handover method), when it is recognized that the RRC layer device, the MAC layer device, or the RLC layer device of the first bearer for the source base station of the UE, or the RRC layer device, the MAC layer device, or the RLC layer device of the second bearer for the target base station satisfies the second condition described in the present disclosure, an indicator indicating that the second condition is satisfied may be sent to the UE or the PDCP layer device of the bearer to execute the DAPS handover method. When the PDCP layer device of the UE receives an indicator indicating that the second condition is satisfied from a lower layer device or a higher layer device, or when the second condition is satisfied, one or more processes described below may be performed on the bearer or the UE configured with the DAPS handover method to successfully complete the second embodiment of the effective handover method of the present disclosure.

[0434] - The UE may release the first bearer for the source base station and release the connection to the source base station.

[0435] - When the UE disconnects from the source base station, the UE may trigger a PDCP status reporting process and configure the PDCP status reporting to send a PDCP status report to the target base station in order to report the reception status of the downlink data received from the source base station to the target base station.

[0436] - When the second condition is satisfied, the UE may switch the structure or function of the second PDCP layer device (represented by reference numeral 1i-20) to the structure or function of the first PDCP layer device (represented by reference numeral 1i-11 or 1i-12) described in the present disclosure for each bearer or for the bearers for which the DAPS handover method is indicated, may initialize the variables for reordering, and may interrupt and initialize the reordering timer. In addition, the UE may perform a decryption process or header (or data) decompression on the data segments stored in the buffer for realignment (e.g., for the data segments received from the source base station) by applying the security key or header decompression context for the source base station, and may then discard the security key or header decompression (e.g., ROCH, EHC, or UDC) context (e.g., ROCH context, EHC context, or UDC context) for the source base station. In addition, the UE may send the processed data to the higher layer in ascending order. That is, in the above case, when the second condition is satisfied, the UE may perform a decryption process or header (or data) decompression on the data segments stored in the buffer for realignment (e.g., for the data segments received from the source base station) by applying the security key or header decompression context for the source base station, and may then discard the security key or header decompression context (e.g., ROCH context, EHC context, or UDC context) (or may initialize the buffer for the UDC method). In another method, when the second condition is satisfied, the UE may switch the structure or function of the second PDCP layer device (represented by reference numeral 1i-20) to the structure or function of the third PDCP layer device (represented by reference numeral 1i-30) described in the present disclosure for each bearer or for the bearers for which the DAPS handover method is indicated, and may use the variables and reordering timer for realignment as they are without stopping and initializing. However, the UE may perform a decryption process or header (or data) decompression on the data segments stored in the buffer for realignment (e.g., for the data segments received from the source base station) by applying the security key or header decompression context (e.g., ROCH context, EHC context, or UDC context) for the source base station, and may then discard the security key or header decompression context (e.g., ROCH context, EHC context, or UDC context) for the source base station. In addition, the UE may send the processed data to the higher layer in ascending order.That is to say, in the above case, when the second condition is satisfied and a security key or header decompression context (e.g., ROCH method, EHC method, or UDC method) for the source base station is configured, the UE can perform a decryption process or header (or data) decompression on the data segment stored in the buffer for realignment (e.g., for the data segment received from the source base station) by applying the ROCH context, EHC context, or UDC context, and then can discard the security key or header decompression context for the source base station. The UE can release the QoS mapping information of the SDAP layer device for the source base station, the security key information of the source base station of the PDCP layer device, the header (or data) compression context information for the source base station, or the RLC layer device or MAC layer device for the source base station.

[0437] - When the MAC layer device for the source base station is initialized and the second PDCP layer device structure of the bearer configured with the DAPS handover method is switched to the first PDCP layer device structure, an RLC layer device reconstruction process or release process can be performed on the RLC layer device for the source base station in the second PDCP layer device structure.

[0438] - The receiving PDCP layer device can process the data received due to the reconstruction process of the lower layer device, and for UM DRB, can perform a header decompression process on the stored data (received from the source base station) or all the stored data based on the header compression context (ROHC, Ethernet header compression (EHC), or UDC) (for the source base station).

[0439] - The receiving PDCP layer device can process the data received due to the reconstruction process of the lower layer device, and for AM DRB, can perform a header decompression process on the stored data (received from the source base station) or all the stored data based on the header compression context (ROHC, Ethernet header compression (EHC), or UDC) (for the source base station).

[0440] - As another method, the receiving PDCP layer device can process the data received due to the reconstruction process of the lower layer device, and for UM DRB or AM DRB, when an indicator (drb-Continue ROHC or drb-Continue Ethernet header compression (EHC)) indicating that continuing to use the header compression context is not configured, can perform a header decompression process on the stored data (received from the source base station) or all the stored data based on the header compression context (ROHC or Ethernet header compression (EHC)).

[0441] - After performing the above process, the transmitting or receiving PDCP layer device can discard or release the security key or header compression context for the source base station.

[0442] When the DAPS handover method is indicated by an RRC message (e.g., RRCReconfiguration message), or when the DAPS handover method is indicated and a first condition is satisfied, regarding the Ethernet header compression or decompression method for the target base station, the above Ethernet header compression or decompression process can be performed and applied as detailed below.

[0443] When the UE receives an RRCReconfiguration message or an RRCConnectionSetup message (or an RRCResume message in the case of a resume procedure), the RRC message can indicate configuration information to the UE as follows.

[0444] -1> It can be indicated for each bearer or in the PDCP layer device configuration information (PDCP configuration) whether to use the configuration information or the Ethernet header compression or decompression function for Ethernet header compression or decompression.

[0445] **2> When using a dedicated traffic channel (DTCH), the Ethernet header compression or decompression function can be configured for a UM bearer (the PDCP layer device connected to the RLC layer device using the UM mode).

[0446] **2> The Ethernet header compression or decompression function can be configured for an AM carrier (the PDCP layer device connected to the RLC layer device using the AM mode) only when using a dedicated traffic channel (DTCH) and / or not using a dedicated control channel (DCCH).

[0447] -1> It can be configured for each bearer or in the PDCP layer device configuration information (PDCP configuration) an indicator indicating whether to continue using or initialize the context for Ethernet header compression or decompression. According to another method, when performing the reconstruction process of the PDCP layer device for each bearer or in the PDCP layer device configuration information (PDCP configuration), an indicator indicating whether to continue using or initialize the context for Ethernet header compression or decompression can be configured. According to another method, when performing the reconstruction process for each bearer or the PDCP layer device in the PDCP layer, the context for Ethernet header compression or decompression can always be initialized.

[0448] -1> When the Ethernet header compression or decompression process is configured, one or more of the following methods can be applied to perform the Ethernet header compression or decompression process.

[0449] **2> First method: For UM or AM bearers, when data for a specific context identifier is sent for the first time, when no feedback is received for the complete Ethernet header (or uncompressed Ethernet header) sent for the specific context identifier, or when the context for Ethernet header compression or decompression is initialized, the transmitting PDCP layer device may generate an EHC header as well as the complete uncompressed Ethernet header, configure the context identifier or an indicator indicating that compression has not occurred in the EHC header, perform integrity protection or encryption on the corresponding data, and send the data. In addition, the transmitting PDCP layer device may include the uncompressed Ethernet header, the complete Ethernet header, or the EHC header in the data, and perform the transmission of the data until feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header is received. When feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header is received, the transmitting PDCP layer device may start performing Ethernet header compression on the data to be sent. Specifically, the transmitting PDCP layer device may compress or omit the compressible or fields with fixed values among the fields of the Ethernet header, include the non-compressible or fields with non-fixed values, generate an EHC header, and include an indicator indicating that the Ethernet header has been compressed or the corresponding context identifier in the EHC header, and may perform integrity protection or encryption on the data with the compressed Ethernet header, and send the data. Here, when data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header including an indicator indicating that compression has not occurred is received, by performing decryption or integrity verification on it, the receiving PDCP layer device at the receiving end may store the field values of the complete Ethernet header fields, store the corresponding context identifier, generate feedback, include the context identifier corresponding to the data or an indicator indicating successful reception in the feedback, and send the feedback. In addition, the receiving PDCP layer device may allow the corresponding feedback to be sent without applying the integrity protection or encryption process in order to achieve fast processing. When the receiving PDCP layer device at the receiving end receives data including a compressed Ethernet header or an EHC header including an indicator indicating that compression has been performed, by performing decryption or integrity verification, the receiving PDCP layer device may, without generating feedback, recover or reconstruct the compressed or omitted header fields or field values in the compressed Ethernet header from the buffer or context of the context identifier corresponding to the data, and configure the complete Ethernet header fields or perform decompression on them to send them to the higher layer device. Here, when the ROHC header compression process is also configured, the ROHC header compression or decompression process may be performed independently for the higher layer device headers other than the Ethernet header.

[0450] **2>Second method: For UM or AM bearers, when data for a specific context identifier is sent for the first time, when no feedback for the complete Ethernet header (or uncompressed Ethernet header) sent for the specific context identifier is received, or when the context for Ethernet header compression or decompression is initialized, the transmitting PDCP layer device may generate an EHC header and a complete uncompressed Ethernet header, configure the context identifier or an indicator indicating that compression has not occurred in the EHC header, perform integrity protection or encryption on the corresponding data, and send the data. In addition, the transmitting PDCP layer device may include the uncompressed Ethernet header, the complete Ethernet header, or the EHC header in the data, and perform the transmission of the data until feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header is received. When feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header is received, the transmitting PDCP layer device may start performing Ethernet header compression on the data to be sent. Specifically, the transmitting PDCP layer device may compress or omit the compressible or fields with fixed values among the fields of the Ethernet header, and include the non-compressible or fields with non-fixed values, may generate an EHC header, and include an indicator indicating that the Ethernet header has been compressed or the corresponding context identifier in the EHC header, and may perform integrity protection or encryption on the data with the compressed Ethernet header, and send the data. The receiving PDCP layer device at the receiving end may introduce a separate timer (through an RRC message, the timer value may be configured for each bearer or each PDCP layer device, or may be configured together with the Ethernet header compression or decompression function) to perform a process to prevent frequent feedback, as follows.

[0451] ***3>When the receiving PDCP layer device drives the timer, the configured timer value may be applied, and the timer may be driven for each context identifier.

[0452] ***3>When the receiving PDCP layer device at the receiving end receives data including the complete Ethernet header, the uncompressed Ethernet header, or an EHC header including an indicator indicating that compression has not occurred by performing decryption or integrity verification on it

[0453] ****4>When the timer for the context identifier corresponding to the received data is not running

[0454] *****5>The receiving PDCP layer device may store the field values of the complete Ethernet header fields, store the corresponding context identifier, generate a feedback, include the context identifier corresponding to the data or an indicator indicating successful reception in the feedback, and send the feedback. In addition, the receiving PDCP layer device may allow the feedback to be sent without applying integrity protection or encryption processes in order to enable fast processing.

[0455] *****5>The receiving PDCP layer device may start a timer for the context identifier corresponding to the received data.

[0456] ***3>When the receiving PDCP layer device at the receiving end receives data including a compressed Ethernet header or an EHC header including an indicator indicating that compression has occurred, by performing decryption or integrity verification

[0457] ****4>The receiving PDCP layer device may, without generating a feedback, recover or reconstruct the compressed or omitted header fields or field values in the compressed Ethernet header from the buffer or context of the context identifier corresponding to the data, and configure the complete Ethernet header fields for decompression. When the ROHC header compression process is also configured, the ROHC header compression or decompression process may be performed independently for higher layer device headers other than the Ethernet header.

[0458] ****4>When the timer for the context identifier corresponding to the received data is running, the timer may be interrupted.

[0459] ***3>When the timer for the context identifier expires

[0460] ****4>The receiving PDCP layer device may generate a feedback corresponding to the context identifier, include the context identifier or an indicator indicating successful reception in the feedback, and send the feedback. In addition, the receiving PDCP layer device may allow the feedback to be sent without applying integrity protection or encryption processes in order to enable fast processing.

[0461] ****4>The timer corresponding to the context identifier may be restarted.

[0462] **2>Third method: For a UM bearer, when data for a specific context identifier is sent for the first time, when no feedback for the complete Ethernet header (or uncompressed Ethernet header) sent for the specific context identifier is received, or when the context for Ethernet header compression or decompression is initialized, the transmitting PDCP layer device may generate an EHC header and a complete uncompressed Ethernet header, configure the context identifier or an indicator indicating that compression has not occurred in the EHC header, perform integrity protection or encryption on the corresponding data, and send the data. In addition, the transmitting PDCP layer device may include the uncompressed Ethernet header, the complete Ethernet header, or the EHC header in the data and perform the transmission of the data until feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header is received. When feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header is received, the transmitting PDCP layer device may start performing Ethernet header compression on the data to be sent. Specifically, the transmitting PDCP layer device may compress or omit the compressible or fields with fixed values among the fields of the Ethernet header, include the non-compressible or fields with non-fixed values, generate an EHC header, include an indicator indicating that the Ethernet header has been compressed or the corresponding context identifier in the EHC header, perform integrity protection or encryption on the data with the compressed Ethernet header, and send the data. Here, when data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header including an indicator indicating that compression has not occurred is received, by performing decryption or integrity verification on it, the receiving PDCP layer device at the receiving end may store the field values of the complete Ethernet header fields, store the corresponding context identifier, generate feedback, include the context identifier corresponding to the data or an indicator indicating successful reception in the feedback, and send the feedback. In addition, the receiving PDCP layer device may allow the feedback to be sent without applying the integrity protection or encryption process in order to achieve fast processing. When the receiving PDCP layer device at the receiving end receives data including the compressed Ethernet header or the EHC header including an indicator indicating that compression has been performed, by performing decryption or integrity verification on it, the receiving PDCP layer device may, without generating feedback, recover or reconstruct the compressed or omitted header fields or field values in the compressed Ethernet header from the buffer or context of the context identifier corresponding to the data, configure the complete Ethernet header fields or perform decompression on them to send them to the higher layer device. Here, when the ROHC header compression process is also configured, the ROHC header compression or decompression process may be performed independently for the higher layer device headers other than the Ethernet header.For an AM bearer, when data for a specific context identifier is sent for the first time, when no feedback is received for the complete Ethernet header (or uncompressed Ethernet header) sent for the specific context identifier, or when the context for Ethernet header compression or decompression is initialized, the transmitting PDCP layer device may generate an EHC header as well as a complete uncompressed Ethernet header, configure the context identifier or an indicator indicating that compression has not occurred in the EHC header, perform integrity protection or encryption on the corresponding data, and send the data once. For subsequent data, the transmitting PDCP layer device may start performing Ethernet header compression on the data to be sent. Specifically, the transmitting PDCP layer device may compress or omit compressible or fields with fixed values among the fields of the Ethernet header, include non-compressible or fields with non-fixed values, may generate an EHC header, and include an indicator indicating that the Ethernet header has been compressed or the corresponding context identifier in the EHC header, and may perform integrity protection or encryption on the data with the compressed Ethernet header, and send the data. Since there is no data loss for an AM bearer, and the receiving PDCP layer device performs reordering and data processing in ascending order of the sequence number, when data including a complete Ethernet header, an uncompressed Ethernet header, or an EHC header including an indicator indicating that compression has not occurred is received, by performing decryption or integrity verification on it, the receiving PDCP layer device at the receiving end may store the field values of the complete Ethernet header fields and store the corresponding context identifier, and may not generate feedback and may not use the feedback for the AM bearer (according to another method, generate one feedback and send it together with the UM bearer). When the receiving PDCP layer device at the receiving end receives data including a compressed Ethernet header or an EHC header including an indicator indicating that compression has been performed, by performing decryption or integrity verification on it, the receiving PDCP layer device may recover or reconstruct the compressed or omitted header fields or field values in the compressed Ethernet header from the buffer or context of the context identifier corresponding to the data, and configure the complete Ethernet header fields or perform decompression on them to send them to the upper layer device. When the ROHC header compression process is also configured, the ROHC header compression or decompression process may be performed independently for upper layer device headers other than the Ethernet header.

[0463] **2>Fourth method: For AM bearers, when data for a specific context identifier is sent for the first time, when no feedback for the complete Ethernet header (or uncompressed Ethernet header) sent for the specific context identifier is received, or when the context for Ethernet header compression or decompression is initialized, the transmitting PDCP layer device may generate an EHC header and a complete uncompressed Ethernet header, configure the context identifier or an indicator indicating that compression has not occurred in the EHC header, perform integrity protection or encryption on the corresponding data, and send the data once. For subsequent data, the transmitting PDCP layer device may start to perform Ethernet header compression on the data to be sent. Specifically, the transmitting PDCP layer device may compress or omit the compressible or fields with fixed values among the fields of the Ethernet header, and include the non-compressible or fields with non-fixed values, may generate an EHC header, and include an indicator indicating that the Ethernet header has been compressed or the corresponding context identifier in the EHC header, and may perform integrity protection or encryption on the data with the compressed Ethernet header, and send the data. Since there is no data loss for AM bearers, and the receiving PDCP layer device performs reordering and data processing in ascending order of the sequence numbers, when data including a complete Ethernet header, an uncompressed Ethernet header, or an EHC header including an indicator indicating that compression has not occurred is received, by performing decryption or integrity verification on it, the receiving PDCP layer device at the receiving end may store the field values of the complete Ethernet header fields and store the corresponding context identifier, and may not generate feedback and may not use the feedback for AM bearers (according to another method, generate one feedback and send it together with the UM bearer). When the receiving PDCP layer device at the receiving end receives data including a compressed Ethernet header or an EHC header including an indicator indicating that compression has been performed, by performing decryption or integrity verification on it, the receiving PDCP layer device may recover or reconstruct the compressed or omitted header fields or field values in the compressed Ethernet header from the buffer or context of the context identifier corresponding to the data, and configure the complete Ethernet header fields or perform decompression on them to send them to the upper layer device. When the ROHC header compression process is also configured, the ROHC header compression or decompression process may be performed independently for upper layer device headers other than the Ethernet header. For UM bearers, when data for a specific context identifier is sent for the first time, when no feedback for the complete Ethernet header (or uncompressed Ethernet header) sent for the specific context identifier is received, or when the context for Ethernet header compression or decompression is initialized, the transmitting PDCP layer device may generate an EHC header and a complete uncompressed Ethernet header, configure the context identifier or an indicator indicating that compression has not occurred in the EHC header, perform integrity protection or encryption on the corresponding data, and send the data.In addition, the transmitting PDCP layer device may include an uncompressed Ethernet header, a complete Ethernet header, or an EHC header in the data, and perform the transmission of the data until a feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header is received. When the feedback indicating successful reception of the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header is received, the transmitting PDCP layer device may start to perform Ethernet header compression on the data to be transmitted. Specifically, the transmitting PDCP layer device may compress or omit the compressible or fixed-value fields among the fields of the Ethernet header, and include the non-compressible or non-fixed-value fields, may generate an EHC header, and include an indicator indicating that the Ethernet header has been compressed or its corresponding context identifier in the EHC header, and may perform integrity protection or encryption on the data with the compressed Ethernet header, and transmit the data. Here, the receiving PDCP layer device at the receiving end may introduce a separate timer (the timer value may be configured for each bearer or each PDCP layer device through an RRC message, or may be configured together with the Ethernet header compression or decompression function) to perform a process to prevent frequent feedback, as follows.

[0464] ***3>When the receiving PDCP layer device drives the timer, the configured timer value may be applied, and the timer may be driven for each context identifier.

[0465] ***3>When the receiving PDCP layer device at the receiving end receives the data including the complete Ethernet header, the uncompressed Ethernet header, or the EHC header including an indicator indicating that compression has not occurred by performing decryption or integrity verification on it

[0466] ****4>When the timer for the context identifier corresponding to the received data is not running

[0467] *****5>The receiving PDCP layer device may store the field values of the complete Ethernet header fields, store the corresponding context identifier, generate a feedback, include the context identifier corresponding to the data or an indicator indicating successful reception in the feedback, and transmit the feedback. In addition, the receiving PDCP layer device may allow the feedback to be transmitted without applying the integrity protection or encryption process in order to achieve fast processing.

[0468] *****5>The receiving PDCP layer device may start a timer for the context identifier corresponding to the received data.

[0469] ***3>When the receiving PDCP layer device at the receiving end receives the data including the compressed Ethernet header or the EHC header including an indicator indicating that compression has occurred, by performing decryption or integrity verification on it

[0470] ****4>The receiving PDCP layer device can recover or reconstruct the compressed or omitted header fields or field values in the compressed Ethernet header from the buffer or context corresponding to the context identifier of the data without generating feedback, and configure the complete Ethernet header fields to perform decompression. When the ROHC header compression process is also configured, the ROHC header compression or decompression process can be performed independently for the higher layer device headers other than the Ethernet header.

[0471] ****4>When the timer corresponding to the context identifier for the received data is running, the timer can be interrupted.

[0472] ***3>When the timer for the context identifier expires

[0473] ****4>The receiving PDCP layer device can generate feedback corresponding to the context identifier, include the context identifier or an indicator indicating successful reception in the feedback, and send the feedback. In addition, the receiving PDCP layer device can allow the feedback to be sent without applying integrity protection or encryption processes in order to achieve fast processing.

[0474] ****4>The timer corresponding to the context identifier can be restarted.

[0475] -1>When the UE receives an RRC message (e.g., RRCReconfiguration message) or an RRCReconfiguration message including ReconfigurationWithSync information, when an indicator indicating continued use of the context for Ethernet header compression or decompression is configured for each bearer or in the PDCP layer device configuration information.

[0476] *2>When the PDCP re-establishment process is indicated or performed for a bearer or the PDCP layer device

[0477] ***3>For an AM bearer, when an indicator indicating continued use of the context for Ethernet header compression or decompression is not configured in the PDCP layer device configuration information, the Ethernet header decompression process can be performed by applying the context for Ethernet header compression or decompression to the data (PDCP SDU or PDCP PDU) stored for the AM bearer or all the stored data (PDCP SDU).

[0478] ***3>For an AM bearer or a UM bearer, when an indicator indicating to continue using the context for Ethernet header compression or decompression is not configured in the PDCP layer device configuration information, the context for Ethernet header compression or decompression for the uplink can be initialized or released. In addition, the transmitting PDCP layer device can send data including an uncompressed Ethernet header or a complete Ethernet header.

[0479] ***3>For an AM bearer or a UM bearer, when an indicator indicating to continue using the context for Ethernet header compression or decompression is configured in the PDCP layer device configuration information, the transmitting PDCP layer device can continue to apply the Ethernet header compression process to the data to be transmitted and send data including a compressed Ethernet header without initializing or releasing the context for Ethernet header compression or decompression for the uplink.

[0480] ***3>For an AM bearer or a UM bearer, when an indicator indicating to continue using the context for Ethernet header compression or decompression is not configured in the PDCP layer device configuration information, the context for Ethernet header compression or decompression for the downlink can be initialized or released. In addition, the transmitting PDCP layer device can send data including an uncompressed Ethernet header or a complete Ethernet header.

[0481] ***3>For an AM bearer or a UM bearer, when an indicator indicating to continue using the context for Ethernet header compression or decompression is configured in the PDCP layer device configuration information, the transmitting PDCP layer device can continue to apply the Ethernet header compression process to the data to be transmitted and send data including a compressed Ethernet header without initializing or releasing the context for Ethernet header compression or decompression for the downlink.

[0482] -1>When the UE receives an RRC message (e.g., an RRCReconfiguration message) or an RRCReconfiguration message including ReconfigurationWithSync information (when an indicator indicating to continue using the context for Ethernet header compression or decompression is configured for each bearer or in the PDCP layer device configuration information),

[0483] **2>When a PDCP re-establishment process is indicated or executed for a bearer or a PDCP layer device

[0484] ***3>The Ethernet header decompression process can be performed by applying the context for Ethernet header compression or decompression to the data (PDCP SDU or PDCP PDU) stored for the AM bearer or all the stored data (PDCP SDU).

[0485] ***3>For an AM bearer or a UM bearer, a context for Ethernet header compression or decompression regarding the uplink can be initialized or released. In addition, the transmitting PDCP layer device can send data including an uncompressed Ethernet header or a complete Ethernet header.

[0486] ***3>For an AM bearer or a UM bearer, a context for Ethernet header compression or decompression regarding the downlink can be initialized or released. In addition, the transmitting PDCP layer device can send data including an uncompressed Ethernet header or a complete Ethernet header.

[0487] In the following, operations of the PDCP layer device of a UE that specifically implements the technologies described so far are presented.

[0488] In an embodiment, when performing the DAPS handover method described in the present disclosure, the PDCP layer device of a UE can process data according to the following procedure and transmit the processed data to a lower layer device, or can send an indication indicating the data size to the lower layer device.

[0489] When sending data (PDCP PDU) to a lower layer device, the transmitting PDCP layer device can perform the following procedure.

[0490] -1>When the transmitting PDCP layer device is connected to one RLC layer device,

[0491] **2>The transmitting PDCP layer device transmits the data (PDCP PDU) to the connected RLC layer device.

[0492] -1>Otherwise, when the transmitting PDCP layer device is connected to two RLC layer devices,

[0493] **2>When the PDCP duplication function (packet duplication technique or PDCP packet duplication) is activated,

[0494] ***3>When the data (PDCP PDU) to be transmitted to the lower layer is PDCP user data (PDCP data PDU)

[0495] ****4>The transmitting PDCP layer device performs duplication processing of the data (PDCP data PDU) and transmits the data (PDCP data PDU) to the connected RLC layer device.

[0496] ***3>Otherwise (i.e., when the data to be transmitted to the lower layer (PDCP PDU) is PDCP control data (PDCP control PDU, e.g., ROHC feedback when ROHC is configured in the PDCP layer device or bearer and ROHC feedback is generated, or EHC feedback when EHC is configured in the PDCP layer device or bearer and EHC feedback is generated),

[0497] ****4>The transmitting PDCP layer device transmits data (PDCP control PDU, e.g., ROHC feedback when ROHC is configured in the PDCP layer device or bearer and ROHC feedback is generated, or EHC feedback when EHC is configured in the PDCP layer device or bearer and EHC feedback is generated) to the connected primary RLC layer device (primary RLC entity). The primary RLC entity or secondary RLC entity can be configured by RRC messages received from the base station as shown in Figure 1e The primary RLC entity does not become inactive, and when packet duplication technology is configured, PDCP control data (PDCP control PDU) can be sent to the primary RLC entity without performing its duplication process.

[0498] **2>Otherwise (i.e., when the PDCP duplication function (packet duplication technology or PDCP packet duplication) is not activated),

[0499] ***3>When the total amount of PDCP data size and RLC data size waiting for initial transmission in the RLC layer device connected to the PDCP layer device is equal to or greater than the threshold for uplink data transmission (here, the threshold can be configured by RRC messages received from the base station as shown in Figure 1e and (or)

[0500] ***3>and (or) when the transmitting PDCP layer device is not connected to a bearer for which the DAPS handover method is configured (or when the DAPS handover method is not configured) and (or)

[0501] ***3>and (or) when the RLC layer device (or two RLC layer devices) connected to the transmitting PDCP layer device belong to different cell groups (or base stations)

[0502] ****4>Data (PDCP PDU, PDCP data PDU or PDCP control PDU, e.g., ROHC feedback when ROHC is configured in the PDCP layer device or bearer and ROHC feedback is generated, EHC feedback when EHC is configured in the PDCP layer device or bearer and EHC feedback is generated) can be sent to the primary RLC entity or secondary RLC entity. It can be done by Figure 1eConfigure the primary RLC entity or secondary RLC entity based on the RRC message received from the base station as shown.

[0503] ***3> Otherwise, when the transmitting PDCP layer device is connected to a bearer for which the DAPS handover method is configured (or when the DAPS handover method is configured),

[0504] ****4> When no indicator indicating that the first condition is met is received from a higher layer device or a lower layer device, or no indicator indicating a handover of uplink data transmission is received,

[0505] *****5> Data (PDCP PDU, PDCP data PDU, or PDCP control PDU, for example, ROHC feedback when ROHC is established in the PDCP layer device or bearer and ROHC feedback is generated, EHC feedback when EHC is established in the PDCP layer device or bearer and EHC feedback is generated) can be transferred to the source base station or the RLC layer device for the source base station for transmission.

[0506] ****4> Otherwise (i.e., when an indicator indicating that the first condition is met is received from a higher layer device or a lower layer device, or an indicator indicating a handover of uplink data transmission is received),

[0507] *****5> When the data is PDCP user data (PDCP data PDU),

[0508] *****6> The PDCP user data can be transferred to the target base station or the RLC layer device for the target base station for transmission.

[0509] *****5> Otherwise (i.e., when the data is PDCP control data (PDCP control PDU, for example, ROHC feedback when ROHC is established in the PDCP layer device or bearer and ROHC feedback is generated, EHC feedback when EHC is established in the PDCP layer device or bearer and EHC feedback is generated),

[0510] *****6> When the PDCP control data (for example, ROHC feedback when ROHC is established in the PDCP layer device or bearer and ROHC feedback is generated, EHC feedback when EHC is established in the PDCP layer device or bearer and EHC feedback is generated) is data for the source base station or is related to the source base station,

[0511] *********7>PDCP control data (e.g., ROHC feedback when ROHC is established in a PDCP layer device or bearer and ROHC feedback is generated, EHC feedback when EHC is established in a PDCP layer device or bearer and EHC feedback is generated) can be transferred to the source base station or the RLC layer device for the source base station to perform transmission.

[0512] *****6>Otherwise (i.e., when the PDCP control data (e.g., ROHC feedback when ROHC is established in a PDCP layer device or bearer and ROHC feedback is generated, EHC feedback when EHC is established in a PDCP layer device or bearer and EHC feedback is generated) is data for the target base station or is related to the target base station),

[0513] ******7>PDCP control data (e.g., ROHC feedback when ROHC is established in a PDCP layer device or bearer and ROHC feedback is generated, EHC feedback when EHC is established in a PDCP layer device or bearer and EHC feedback is generated) can be transferred to the target base station or the RLC layer device for the target base station to perform transmission.

[0514] ***3>Otherwise (i.e., when the total amount of PDCP data size and RLC data size waiting for initial transmission in the RLC layer device connected to the PDCP layer device is equal to or greater than the threshold of uplink data transmission, or when the sending PDCP layer device is not connected to the bearer configured with the DAPS handover method (or when the DAPS handover method is configured), or when the RLC layer device (or two RLC layer devices) connected to the sending PDCP layer device do not belong to different cell groups (or base stations) respectively,

[0515] ****4>Data (PDCP PDU, PDCP data PDU or PDCP control PDU, e.g., ROHC feedback when ROHC is established in a PDCP layer device or bearer and ROHC feedback is generated, EHC feedback when EHC is established in a PDCP layer device or bearer and EHC feedback is generated) can be transferred to the primary RLC entity to perform transmission.

[0516] When the sending PDCP layer device is connected to multiple RLC layer devices (or two RLC layer devices) and indicates the size of PDCP data to the MAC layer device for the source base station or the target base station to trigger a buffer status report or calculate the buffer size, the sending PDCP layer device can perform the following process.

[0517] -1>When the PDCP duplication function (packet duplication technology or PDCP packet duplication) is activated,

[0518] **2>The PDCP layer device on the transmitting side may indicate the size of PDCP data (PDCP data PDU, PDCP control PDU, for example, ROHC feedback when ROHC is established in the PDCP layer device or bearer and ROHC feedback is generated, EHC feedback when EHC is established in the PDCP layer device or bearer and EHC feedback is generated) to the MAC layer device connected to the first RLC entity.

[0519] **2>The PDCP layer device on the transmitting side may indicate the size of PDCP data (PDCP data PDU) other than the size of PDCP control PDU (PDCP control PDU, for example, ROHC feedback when ROHC is established in the PDCP layer device ...

Claims

1. A method performed by a terminal in a wireless communication system, the method comprising: Receiving, from a base station, a radio resource control (RRC) message including first information for configuring unordered delivery of a radio link control (RLC) entity, wherein second information indicating a value of a reordering timer of a packet data convergence protocol (PDCP) entity is further included in the RRC message in a case of reconfiguring to a data radio bearer (DRB) associated with the RLC entity configured with the first information; Delivering data from the RLC entity to the PDCP entity based on the unordered delivery configured by the first information; And Performing, at the PDCP entity, a reordering function for the data based on the second information.

2. The method according to claim 1, Among them, wherein the RLC entity and the PDCP entity are associated with the DRB, and wherein the DRB is a DRB connected to an acknowledged mode (AM) RLC entity or a DRB connected to an unacknowledged mode (UM) RLC entity.

3. The method according to claim 2, Among them, wherein the RLC entity associated with the DRB is one entity.

4. A method performed by a base station in a wireless communication system, the method comprising: Sending, to a terminal, a radio resource control (RRC) message including first information for configuring unordered delivery of a radio link control (RLC) entity of the terminal, wherein second information indicating a value of a reordering timer of a packet data convergence protocol (PDCP) entity of the terminal is further included in the RRC message, wherein, based on the unordered delivery configured by the first information, data is delivered from the RLC entity to the PDCP entity, and wherein, based on the second information, a reordering function for the data is performed at the PDCP entity.

5. The method according to claim 4, Among them, wherein the RLC entity and the PDCP entity are associated with the DRB, and wherein the DRB is a DRB connected to an acknowledged mode (AM) RLC entity or a DRB connected to an unacknowledged mode (UM) RLC entity.

6. The method according to claim 5, Among them, wherein the RLC entity associated with the DRB is one entity.

7. A terminal in a wireless communication system, the terminal comprising: A transceiver configured to transmit or receive signals; And A controller coupled to the transceiver, wherein the controller is configured to: Receive, from a base station, a radio resource control (RRC) message including first information for configuring unordered delivery of a radio link control (RLC) entity, wherein second information indicating a value of a reordering timer of a packet data convergence protocol (PDCP) entity is further included in the RRC message in a case of reconfiguring to a data radio bearer (DRB) associated with the RLC entity configured with the first information, Transfer data from the RLC entity to the PDCP entity based on the unordered transfer configured by the first information, and perform a reordering function for the data at the PDCP entity based on the second information.

8. The terminal according to claim 7, Among them, wherein the RLC entity and the PDCP entity are associated with the DRB, and wherein the DRB is a DRB connected to an acknowledged mode AM RLC entity or a DRB connected to an unacknowledged mode UM RLC entity.

9. The terminal according to claim 8, Among them, the RLC entity associated with the DRB is one entity.

10. A base station in a wireless communication system, the base station comprising: a transceiver configured to transmit or receive signals; and a controller coupled to the transceiver, wherein the controller is configured to: send a radio resource control RRC message to a terminal, the message including first information for configuring unordered transfer of a radio link control RLC entity of the terminal, wherein second information indicating a value of a reordering timer of a packet data convergence protocol PDCP entity of the terminal is further included in the RRC message in the case of reconfiguration to a data radio bearer DRB associated with the RLC entity configured with the first information, wherein, based on the unordered transfer configured by the first information, data is transferred from the RLC entity to the PDCP entity, and wherein, based on the second information, a reordering function for the data is performed at the PDCP entity.

11. The base station according to claim 10, Among them, wherein the RLC entity and the PDCP entity are associated with the DRB, and wherein the DRB is a DRB connected to an acknowledged mode AM RLC entity or a DRB connected to an unacknowledged mode UM RLC entity.

12. The base station according to claim 11, Among them, the RLC entity associated with the DRB is one entity.

Images