Method and apparatus for processing PDCP control data in a system supporting high reliability and low delay services

Abstract

The present disclosure relates to a method and system for integrating a fifth generation (5G) communication system for supporting a higher data rate than a fourth generation (4G) system with Internet of Things (IoT) technology. The present disclosure can be applied to smart services based on 5G communication technology and IoT-related technology, such as smart homes, smart buildings, smart cities, smart cars, connected cars, health care, digital education, smart retail, security and safety services. A method for efficiently processing PDCP control data of a PDCP layer device is provided in the case where a system supporting high reliability and low latency services adopts a packet replication transmission technology.

Description

Technical Field

[0001] The present disclosure relates to a method and apparatus for efficiently processing Packet Data Convergence Protocol (PDCP) control data of a PDCP layer device when a system supporting high-reliability low-delay services adopts a packet duplication transmission technology.

[0002] More particularly, the present disclosure relates to a method and apparatus for supporting Ethernet header compression and decompression in a next generation mobile communication system. Background Art

[0003] In order to meet the growing demand for wireless data traffic after the commercialization of the fourth generation (4G) communication system, efforts have been made to develop an improved fifth generation (5G) or quasi-5G communication system. For this reason, the 5G or quasi-5G communication system is called a "super 4G network communication system" or a "post-LTE system". The 5G communication system is considered to be implemented in a higher frequency (mmWave) band (e.g., a 60GHz band) in order to achieve higher data rates. In order to reduce the propagation loss of radio waves and increase the transmission distance, beamforming, massive multiple input multiple output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive antenna technology are discussed in the 5G communication system. In addition, in the 5G communication system, system network improvement development based on advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communications, wireless backhaul, mobile networks, collaborative communications, coordinated multipoints (CoMP), receiving-end interference elimination, etc. is underway. In 5G systems, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) have been developed as advanced coded modulation (ACM), as well as filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access technologies.

[0004] The Internet has evolved from a human-centered connected network where humans create and consume information to the Internet of Things (IoT) where distributed elements such as things exchange and process information with each other without human intervention. Internet of Everything (IoE) technology, which is a combination of IoT technology and big data processing technology through connection with cloud servers, has emerged. Since 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 and machine-type communication (MTC) have been studied recently. Such an IoT environment can provide intelligent Internet technology (IT) services to create new value for human life by collecting and analyzing data generated between connected things. IoT can be applied to various fields including smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, healthcare, smart appliances and advanced medical services through the integration and combination of existing information technology (IT) and various industries.

[0005] 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 communications (MTC), and machine-to-machine (M2M) communications can be implemented through beamforming, MIMO, and array antennas. Cloud radio access networks (RANs) as an application of the above-mentioned big data processing technologies can also be considered as an example of the fusion of 5G technology and IoT technology.

[0006] With the development of next-generation mobile communication systems, efficient use of transmission resources is required to support services requiring low latency and high reliability (e.g., ultra-reliable low-latency communication (URLLC) or Industrial Internet of Things (IIoT) services).

[0007] The above information is provided as background information only to assist in understanding the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above may be applied as prior art to the present disclosure. Summary of the invention

[0008] Technical issues

[0009] In the next generation mobile communication system, in order to enhance reliability and reduce latency, the same data can be transmitted through different independent paths in carrier aggregation technology or dual connection technology. In carrier aggregation technology or dual access technology, each radio link control (RLC) device that supports packet copy transmission technology can operate in RLC confirmed mode (AM) or RLC unconfirmed mode (UM), and can be activated or deactivated by MAC control information. However, in the case of applying the packet copy transmission method, it is necessary to consider a method for processing the control data of the PDCP layer so as to consider a method that is easy to implement and does not cause problems in the receiving PDCP layer device.

[0010] In addition, in the next generation mobile communication system, in order to support services requiring low latency and high reliability (e.g., ultra-reliable low latency communication (URLLC) or industrial Internet of Things (IIoT) services), it is necessary to use transmission resources efficiently. In addition, it is necessary to efficiently perform the encryption and decryption process that generates the largest processing burden in the data processing process of the terminal.

[0011] Solution to the problem

[0012] According to one aspect of the present disclosure, a method performed by a terminal in a wireless communication system is provided. The method includes: determining whether a service data adaptation protocol (SDAP) header is configured and whether Ethernet header compression (EHC) is configured; receiving data from an upper layer; and performing Ethernet header compression on the received data in a packet data convergence protocol (PDCP) layer when the SDAP header and the EHC are configured, wherein the execution of the Ethernet header compression is not applied to the SDAP header or the SDAP control packet data unit (PDU).

[0013] In an embodiment, the EHC header is located after the SDAP header.

[0014] In an embodiment, the EHC header generated in the PDCP layer is encrypted, but the PDCP header is not encrypted.

[0015] In an embodiment, no EHC header is generated for the SDAP Control PDU.

[0016] In an embodiment, when both EHC and Robust Header Compression (ROHC) are configured, the ROHC header is located after the EHC header.

[0017] According to another aspect of the present disclosure, a method performed by a base station in a wireless communication system is provided. The method includes: determining whether a service data adaptation protocol (SDAP) header is configured and whether Ethernet header compression (EHC) is configured; receiving data from an upper layer; and performing Ethernet header compression on the received data in a packet data convergence protocol (PDCP) layer when the SDAP header and the EHC are configured, wherein the execution of the Ethernet header compression is not applied to the SDAP header or the SDAP control packet data unit (PDU).

[0018] According to another aspect of the present disclosure, a terminal is provided, comprising: a transceiver capable of sending or receiving at least one signal; and a controller coupled to the transceiver, wherein the controller is configured to: determine whether a Service Data Adaptation Protocol (SDAP) header is configured and whether Ethernet Header Compression (EHC) is configured; receive data from an upper layer; and in a case where the SDAP header and the EHC are configured, perform Ethernet header compression on the received data in a Packet Data Convergence Protocol (PDCP) layer, wherein the performance of the Ethernet header compression is not applied to the SDAP header or the SDAP control packet data unit (PDU).

[0019] According to another aspect of the present disclosure, a base station is provided, comprising: a transceiver capable of sending or receiving at least one signal; and a controller coupled to the transceiver, wherein the controller is configured to: determine whether a Service Data Adaptation Protocol (SDAP) header is configured and whether Ethernet Header Compression (EHC) is configured; receive data from an upper layer; and in a case where the SDAP header and the EHC are configured, perform Ethernet header compression on the received data in a Packet Data Convergence Protocol (PDCP) layer, wherein the performance of the Ethernet header compression is not applied to the SDAP header or the SDAP control packet data unit (PDU).

[0020] For those skilled in the art, other aspects, advantages, and salient features of the present disclosure will become apparent from the following detailed description, which, taken in conjunction with the accompanying drawings, discloses various embodiments of the present disclosure.

[0021] Advantageous Effects of the Invention

[0022] Aspects of the present disclosure are intended to at least solve the above-mentioned problems and / or disadvantages and to provide at least the advantages described below. Therefore, one aspect of the present disclosure is to provide a PDCP layer control data processing method that takes into account easy implementation so that a packet copy transmission technology that can be applied in a next generation mobile communication system can be effectively used and does not cause problems in a receiving PDCP layer device, thereby enabling the effective use of the packet copy transmission technology.

[0023] Another aspect of the present disclosure is to provide a method for compressing and decompressing an Ethernet header in a next generation mobile communication system using an Ethernet protocol so that transmission resources can be used efficiently. Therefore, more 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. In addition, the present disclosure also proposes a method for efficiently encrypting and decrypting data to which an Ethernet header decompression process is applied, so as to reduce the implementation complexity and processing burden of a terminal.

[0024] Additional aspects will be set forth in part in the description which follows and, in part, will be apparent from the description, or may be learned by practice of the presented embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The above and other aspects, features and advantages of certain embodiments of the present disclosure will become more apparent through the following description in conjunction with the accompanying drawings, in which:

[0026] Figure 1A The structure of an LTE system according to an embodiment of the present disclosure is shown;

[0027] Figure 1B A radio protocol architecture in an LTE system according to an embodiment of the present disclosure is shown;

[0028] Figure 1C The structure of a next generation mobile communication system according to an embodiment of the present disclosure is shown;

[0029] Figure 1D The radio protocol architecture of the next generation mobile communication system according to an embodiment of the present disclosure is shown;

[0030] Figure 1E The process of processing data at each layer in the next generation mobile communication system according to an embodiment of the present disclosure is shown;

[0031] Figure 1F The present invention shows a process in which a base station configures a packet copy transmission function in a PDCP layer through an RRC message when a user equipment (UE) establishes a connection with a network according to an embodiment of the present disclosure;

[0032] Figure 1G A packet duplication transmission technology in which a PDCP layer performs packet transmission by duplicating packets based on a carrier aggregation technology in a next generation mobile communication system according to an embodiment of the present disclosure is shown;

[0033] Figure 1H A packet duplication transmission technology in which a PDCP layer performs packet transmission by duplicating packets based on a dual connectivity technology in a next generation mobile communication system according to an embodiment of the present disclosure is shown;

[0034] Fig. 1I The embodiment according to the present disclosure is shown Figure 1G or Figure 1H The packet replication transmission technology described in is extended to an embodiment of multiple RLC layer devices;

[0035] Figure 1J The embodiment (1-1) according to the embodiment of the present disclosure is shown, wherein the control data of the PDCP layer device is processed using a packet replication transmission technology based on a carrier aggregation technology or a packet replication transmission technology based on a dual access technology;

[0036] Figure 1K The embodiment (1-2) according to the embodiment of the present disclosure is shown, wherein the control data of the PDCP layer device is processed using a packet replication transmission technology based on a carrier aggregation technology or a packet replication transmission technology based on a dual access technology;

[0037] Figure 1L The UE operation in the next generation mobile communication system according to an embodiment of the present disclosure is shown, wherein the PDCP layer performs a packet copy transmission technology based on a carrier aggregation technology or a dual access technology;

[0038] Figure 1M The structure of a UE according to an embodiment of the present disclosure is shown;

[0039] Figure 1N shows a block configuration of a TRP in a wireless communication system according to an embodiment of the present disclosure;

[0040] Figure 2A The structure of an LTE system according to an embodiment of the present disclosure is shown;

[0041] Figure 2B A radio protocol architecture in an LTE system according to an embodiment of the present disclosure is shown;

[0042] Figure 2C The structure of a next generation mobile communication system according to an embodiment of the present disclosure is shown;

[0043] Figure 2D The radio protocol architecture of the next generation mobile communication system according to an embodiment of the present disclosure is shown;

[0044] Figure 2E The present invention shows a process in which, when the UE establishes a connection with a network, a base station configures Ethernet header protocol related configuration information for the UE according to an embodiment of the present disclosure;

[0045] Figure 2F An Ethernet Header Compression (EthHC) method according to an embodiment of the present disclosure is shown;

[0046] Figure 2G The present invention shows a proposed Ethernet Header Compression (EthHC) method in the case where an SDAP header or layer device is configured according to an embodiment of the present disclosure;

[0047] Figure 2H Another Ethernet header compression (EthHC) method proposed in the case where an SDAP header or layer device is configured according to an embodiment of the present disclosure is shown;

[0048] Fig.2I A first specific embodiment of the Ethernet header compression method according to an embodiment of the present disclosure is shown;

[0049] Figure 2J A second specific embodiment of the Ethernet header compression method according to an embodiment of the present disclosure is shown;

[0050] Figure 2K An embodiment of a feedback structure that can be used in an upper layer header compression method according to an embodiment of the present disclosure is shown;

[0051] Figure 2L The (2-1) embodiment according to the embodiment of the present disclosure is shown, wherein, in a case where an SDAP layer device or an SDAP header is configured, an Ethernet header compression protocol (or method) is configured, and an ROHC protocol is configured, a PDCP layer device effectively performs encryption and decryption;

[0052] Figure 2M The (2-2) embodiment according to the embodiment of the present disclosure is shown, wherein, in a case where an SDAP layer device or an SDAP header is configured, an Ethernet header compression protocol (or method) is configured, and an ROHC protocol is configured, the PDCP layer device effectively performs encryption and decryption;

[0053] Figure 2N The (2-3) embodiment according to the embodiment of the present disclosure is shown, wherein, in the case where the SDAP layer device or the SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured, the PDCP layer device effectively performs encryption and decryption;

[0054] Fig.2O The (2-4) embodiment according to the embodiment of the present disclosure is shown, wherein, in the case where the SDAP layer device or the SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured, the PDCP layer device effectively performs encryption and decryption;

[0055] Figure 2PThe (2-5) embodiment according to the embodiment of the present disclosure is shown, wherein, in the case where the SDAP layer device or the SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured, the PDCP layer device effectively performs encryption and decryption;

[0056] Figure 2Q The (2-6) embodiment according to the embodiment of the present disclosure is shown, wherein, in the case where the SDAP layer device or the SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured, the PDCP layer device effectively performs encryption and decryption;

[0057] Figure 2R The (2-7) embodiment according to the embodiment of the present disclosure is shown, wherein, in the case where the SDAP layer device or the SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured, the PDCP layer device effectively performs encryption and decryption;

[0058] Figure 2S The (2-8) embodiment according to the embodiment of the present disclosure is shown, wherein, in the case where the SDAP layer device or the SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured, the PDCP layer device effectively performs encryption and decryption;

[0059] Figure 2T The (2-9) embodiment according to the embodiment of the present disclosure is shown, wherein, in the case where the SDAP layer device or the SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured, the PDCP layer device effectively performs encryption and decryption;

[0060] Figure 2U The (2-10) embodiment according to the embodiment of the present disclosure is shown, wherein, in a case where an SDAP layer device or an SDAP header is configured, an Ethernet header compression protocol (or method) is configured, and an ROHC protocol is configured, the PDCP layer device effectively performs encryption and decryption;

[0061] Figure 2V The (2-11) embodiment according to the embodiment of the present disclosure is shown, wherein, in a case where an SDAP layer device or an SDAP header is configured, an Ethernet header compression protocol (or method) is configured, and an ROHC protocol is configured, the PDCP layer device effectively performs encryption and decryption;

[0062] Figure 2W The operation of a sending PDCP layer device or the operation of a receiving PDCP layer device of a UE or a base station according to an embodiment of the present disclosure is shown;

[0063] Figure 2X shows the structure of a UE according to an embodiment of the present disclosure; and

[0064] Figure 2Y A block configuration of a TRP in a wireless communication system according to an embodiment of the present disclosure is shown.

[0065] Throughout the drawings, like reference numerals will be understood to refer to like parts, components and structures. DETAILED DESCRIPTION

[0066] The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of the various embodiments of the present disclosure as defined by the claims and their equivalents. The following description includes various specific details to assist in understanding, but these specific details are considered to be exemplary only. Therefore, it will be appreciated by those of ordinary skill in the art that various changes and modifications may be made to the various embodiments described herein without departing from the scope and spirit of the present disclosure. In addition, descriptions of well-known functions and configurations may be omitted for clarity and brevity.

[0067] The terms and words used in the following description and claims are not limited to the bibliographical meanings, but are merely used by the discloser to enable a clear and consistent understanding of the present disclosure. Therefore, it is apparent to those skilled in the art that the following description of various embodiments of the present disclosure is provided for illustrative purposes only and not for the purpose of limiting the present disclosure as defined by the appended claims and their equivalents.

[0068] It should be understood that the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to "a component surface" includes reference to one or more of such surfaces.

[0069] In the following description, for the sake of convenience, terms used to identify 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 the subject matter having equivalent technical meanings may be used.

[0070] In the following description, for ease of description, the present disclosure uses terms and names defined in the 3rd Generation Partnership Project Long Term Evolution (3GPP LTE) standard. However, the present disclosure is not limited to these terms and names and can be applied to systems conforming to other standards in the same manner. In the present disclosure, the term "eNB" can be used interchangeably with the term "gNB". That is, a base station described as an "eNB" can refer to a "gNB".

[0071] Figure 1A The structure of an LTE system according to an embodiment of the present disclosure is shown.

[0072] refer to Figure 1A , the radio access network of the LTE system includes next-generation base stations (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, and a serving gateway (S-GW) 1a-30. User equipment (hereinafter referred to as UE or terminal) 1a-35 is connected to an external network through eNB 1a-05, 1a-10, 1a-15 and 1a-20 and S-GW 1a-30.

[0073] exist Figure 1A In the LTE system, eNBs 1a-05, 1a-10, 1a-15, and 1a-20 correspond to conventional Node Bs of the UMTS system. The eNBs are connected to UEs 1a-35 through radio channels and play a more complex role than conventional Node Bs. In the LTE system, since all user services (including real-time services such as Voice over IP (VoIP) over Internet Protocol) are served through shared channels, a device is required to perform scheduling by collecting status information such as buffer status, available transmit power status, and channel status of the UE. eNBs 1a-05 to 1a-20 can be used as devices for performing scheduling. One eNB generally controls multiple cells. For example, in order to achieve a transmission rate of 100 Mbps, the LTE system uses an orthogonal frequency division multiplexing (hereinafter referred to as OFDM) scheme with a 20 MHz bandwidth as a radio access technology. In addition, an adaptive modulation and coding (hereinafter referred to as AMC) scheme is adopted that determines the modulation scheme and channel coding rate according to the channel status of the UE. The S-GW 1a-30 is a device for providing a data bearer, and generates or removes a data bearer under the control of the MME 1a-25. The MME is a device responsible for various control functions of the UE and a mobility management function, and is connected to a plurality of base stations.

[0074] Figure 1B A radio protocol architecture in an LTE system according to an embodiment of the present disclosure is shown.

[0075] refer to Figure 1B For each of the UE and eNB, the radio protocols of the LTE system include Packet Data Convergence Protocol (PDCP) 1b-05 and 1b-40, Radio Link Control (RLC) 1b-10 and 1b-35, and Medium Access Control (MAC) 1b-15 and 1b-30. PDCP 1b-05 and 1b-40 are responsible for operations such as IP header compression / reconstruction. The main functions of PDCP are summarized as follows.

[0076] -Header compression and decompression: ROHC only

[0077] -Transmission of user data

[0078] - For RLC AM, in-sequence delivery of upper layer PDUs during PDCP re-establishment

[0079] - For split bearers in DC (supports RLC AM only): PDCP PDU routing for transmission and PDCP PDU reordering for reception

[0080] - For RLC AM, duplicate detection of lower layer SDUs during PDCP re-establishment

[0081] - For RLC AM, during PDCP data restoration, for split bearers in DC and for retransmission of PDCP SDUs at handover

[0082] -Encryption and decryption

[0083] - Timer-based SDU discard in uplink

[0084] Radio Link Control (hereinafter referred to as RLC) 1b-10 and 1b-35 reconfigures a PDCP Packet Data Unit (PDU) into an appropriate size to perform an ARQ operation. The main functions of the RLC are summarized as follows.

[0085] -Transmission of upper layer PDU

[0086] - Error correction via ARQ (for AM data transmission only)

[0087] -RLC SDU concatenation, segmentation and reassembly (only for UM and AM data transmission)

[0088] - Re-segmentation of RLC data PDU (only for AM data transmission)

[0089] - Reordering of RLC data PDUs (only for UM and AM data transmission)

[0090] - Duplicate detection (for UM and AM data transmission only)

[0091] -Protocol error detection (for AM data transmission only)

[0092] -RLC SDU discard (only for UM and AM data transmission)

[0093] -RLC reconstruction

[0094] MAC 1b-15 and 1b-30 are connected to a plurality of RLC layer devices configured in one terminal, and can perform operations of multiplexing RLC PDU with MAC PDU and demultiplexing RLC PDU from MAC PDU. The main functions of MAC are summarized as follows.

[0095] - Mapping between logical channels and transport channels

[0096] - Multiplex MAC SDUs belonging to one or different logical channels into a transport block (TB) delivered to the physical layer on a transport channel / demultiplex MAC SDUs belonging to one or different logical channels from a transport block (TB) delivered from the physical layer on a transport channel

[0097] -Dispatch information report

[0098] - Error correction through HARQ

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

[0100] - Prioritization between UEs through dynamic scheduling

[0101] -MBMS service logo

[0102] -Transmission format selection

[0103] -filling

[0104] The physical layers 1b-20 and 1b-25 may perform operations of channel coding and modulating upper layer data, generating upper layer data into OFDM symbols, sending OFDM symbols through a radio channel or demodulating OFDM symbols received through a radio channel, channel decoding OFDM symbols, and sending OFDM symbols to an upper layer.

[0105] Figure 1C A structure of a next generation mobile communication system according to an embodiment of the present disclosure is shown.

[0106] refer to Figure 1C , the radio access network of the next generation mobile communication system includes a next generation base station (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. User equipment (new radio user equipment, hereinafter referred to as NR UE or terminal) 1c-15 accesses the external network via NR gNB 1c-10 and NR CN 1c-05.

[0107] exist Figure 1CIn the NR gNB 1c-10, the NR gNB corresponds to the evolved Node B (eNB) of the conventional LTE system. The NR gNB is connected to the NR UE 1c-15 via a radio channel and can provide better services than the conventional Node B. In the next generation mobile communication system, since all types of user services are served through shared channels, a device is required to perform scheduling by collecting status information such as buffer status, available transmit power status, and channel status of the UE. In addition, the NR gNB1c-10 is responsible for such device functions. One NR gNB generally controls multiple cells. In order to achieve ultra-high-speed data transmission compared to conventional LTE, the NR gNB can have a conventional maximum bandwidth or a larger bandwidth, and can additionally utilize 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 (hereinafter referred to as AMC) scheme that determines the modulation scheme and channel coding rate based on the channel status of the UE. The NR CN 1c-05 performs functions such as mobility support, bearer setup, and QoS configuration. NR-CN is a device responsible for various control functions of UE and mobility management functions, and is connected to multiple base stations. In addition, the next-generation mobile communication system can also operate in conjunction with the traditional LTE system, and NR-CN is connected to MME 1c-25 via a network interface. MME is connected to eNB 1c-30, that is, a traditional base station.

[0108] Figure 1D A radio protocol architecture of a next generation mobile communication system according to an embodiment of the present disclosure is shown.

[0109] refer to Figure 1D For each of the UE and the NR base station, the radio protocol of the next generation mobile communication system includes NR PDCP 1d-05 and 1d-40, NR RLC 1d-10 and 1d-35, and NR MAC 1d-15 and 1d-30. The main functions of NR PDCP 1d-05 and 1d-40 may include some of the following functions:

[0110] -Header compression and decompression: ROHC only

[0111] -Transmission of user data

[0112] - In-sequence delivery of upper layer PDUs

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

[0114] - Reordering of received PDCP PDUs

[0115] - Duplicate detection of lower layer SDU

[0116] -Retransmission of PDCP SDU

[0117] -Encryption and decryption

[0118] - Timer-based SDU discard in uplink

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

[0120] The main functions of NR RLC 1d-10 and 1d-35 may include some of the following functions:

[0121] -Transmission of upper layer PDU

[0122] - In-sequence delivery of upper layer PDUs

[0123] - Out-of-order delivery of upper layer PDUs

[0124] - Error correction via ARQ

[0125] - Concatenation, segmentation and reassembly of RLC SDU

[0126] - Re-segmentation of RLC data PDUs

[0127] - Reordering of RLC data PDUs

[0128] - Duplicate detection

[0129] -Protocol error detection

[0130] -RLC SDU discarded

[0131] -RLC reconstruction

[0132] The in-sequence delivery function of the NR RLC device refers to a function of sending the RLC SDU received from the lower layer to the upper layer in the reception sequence, and may include: a function of reassembling and sending multiple RLC SDUs if one RLC SDU is initially segmented into multiple RLC SDUs and received; a function of reordering the received RLC PDUs based on the RLC sequence number (SN) or PDCP SN; a function of reordering the sequence and recording the lost RLC PDUs; a function of providing a status report on the lost RLC PDUs to the transmitting side; and a function of requesting retransmission of the lost RLC PDUs. Alternatively, if a lost RLC SDU occurs, the in-sequence delivery function of the NR RLC device may include a function of sequentially sending only the RLC SDUs preceding the lost RLC SDU to the upper layer, or if a predetermined timer expires despite the presence of a lost RLC SDU, a function of sequentially sending all RLC SDUs received before the timer starts to the upper layer, or if a predetermined timer expires despite the presence of a lost RLC SDU, a function of sequentially sending all RLC SDUs received so far to the upper layer. In addition, the RLC PDUs may be processed in the order in which they are received (in the order of arrival, regardless of the order of sequence numbers and sequence numbers), and may be sent to the PDCP device out of order. For segmentation, the in-order delivery function may include the functions of receiving segments stored in a buffer or segments to be received later, reconfiguring segments in a complete RLC PDU, processing the RLC PDU, and sending the RLC PDU to the PDCP device. The NR RLC layer may not include a cascading function, and the cascading function may be performed by the NR MAC layer, or may be replaced by a multiplexing function of the NR MAC layer.

[0133] The out-of-order delivery function of the NR RLC device refers to a function of directly sending the RLC SDU received from the lower layer to the upper layer without considering the order, and if one RLC SDU is originally segmented into multiple RLC SDUs and received, it may include: a function of reassembling multiple RLC SDUs and sending them; and a function of storing the RLC SN or PDCP SN of the received RLC PDU, reordering the sequence, and recording the lost RLC PDU.

[0134] NR MAC 1d-15 and 1d-30 can be connected to multiple NR RLC layer devices configured in one UE, and the main functions of NR MAC can include some of the following functions:

[0135] - Mapping between logical channels and transport channels

[0136] -Multiplexing / demultiplexing of MAC SDU

[0137] -Dispatch information report

[0138] - Error correction through HARQ

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

[0140] - Prioritization between UEs through dynamic scheduling

[0141] -MBMS service logo

[0142] -Transmission format selection

[0143] -filling

[0144] NR PHY layers 1d-20 and 1d-25 can perform operations of channel coding and modulating upper layer data, generating upper layer data into OFDM symbols, sending OFDM symbols via a radio channel, or demodulating and channel decoding OFDM symbols received via a radio channel, and transmitting the OFDM symbols to an upper layer.

[0145] In the present disclosure, the transmitting terminal device may be a base station or a UE and the receiving terminal device may be a base station or a UE. That is, the present disclosure may include both the case where the transmitting terminal device is a base station and the receiving terminal device is a UE (downlink data transmission scenario) or the case where the transmitting terminal device is a UE and the receiving terminal device is a base station (uplink data transmission scenario). The transmitting terminal device may indicate a base station or a UE, and the receiving terminal device may indicate a base station or a UE.

[0146] The present disclosure considers a UE configured with carrier aggregation (CA), dual connectivity (DC) technology, or packet copy transmission technology, and uses the following terms to specify the proposed methods.

[0147] -Primary cell (Pcell): Pcell refers to a serving cell used when a UE establishes a first connection with a base station and establishes a connection by sending or receiving a primary RRC message using the Pcell. In addition, the Pcell can indicate HARQ ACK or NACK because the Pcell always has PUCCH transmission resources and uplink and downlink are always configured therein, and the Pcell can be used as a reference cell for timing adjustment (timing advance, primary timing advance group (pTAG)). For example, if a carrier aggregation technology is configured after the configuration of the Pcell and an Scell ​​is added thereto, the Scell ​​can perform uplink data transmission by referring to the timing advance value of the Pcell. In addition, if a dual access technology is configured, the Pcell refers to the Pcell of the primary cell group (MCG).

[0148] -Master Cell Group (MCG): MCG refers to the serving cell to which the UE initially establishes a connection with a base station or a cell group supported by the base station. If dual access technology is configured, the main RRC message is sent or received through the MCG.

[0149] - Secondary Cell Group (SCG): SCG refers to a cell group supported by another base station in addition to MCG, where the UE can establish a connection with the base station and add a cell of another base station. In addition, if dual access technology is established, SCG can be added to increase additional data rate or effectively support UE mobility.

[0150] - Primary Secondary Cell (PScell): If a dual access technology in which a UE establishes a connection with a base station and a cell group of another base station is added in addition to the MCG is configured, the cell corresponding to the Pcell in the SCG is called a PScell.

[0151] -Secondary Cell (Scell): Scell ​​is a cell additionally configured by the base station in order to configure the carrier aggregation technology after the UE establishes the first connection with the base station. According to the base station configuration, the SCell can have PUCCH transmission resources, and according to the configuration of the base station, the uplink or downlink can be configured therein. In addition, according to the configuration of the base station, the SCell can be used as a reference cell for the timing advance (secondary timing advance group (sTAG)). For example, if the carrier aggregation technology is configured after the configuration of the Pcell, the Scell ​​is added thereto, and the sTAG is configured, and the other Scells of the sTAG can perform uplink data transmission by referring to the timing advance value of the specified Scell. In addition, if dual access technology is configured for the UE, the Scell ​​refers to a Scell ​​other than the PCell of the primary cell group (MCG) or a Scell ​​other than the PScell ​​of the secondary cell group (SCG).

[0152] -Master RLC entity: If the packet duplication configuration technology is configured, multiple RLC layer devices can be configured in one PDCP layer device, and one RLC layer device that is always used and not deactivated among the multiple RLC layer devices is called the master RLC entity. In addition, the PDCP layer device can always send the PDCP control PDU to the master RLC entity without performing its duplication transmission.

[0153] -Secondary RLC entity: If the packet duplication configuration technology is configured, multiple RLC layer devices can be configured in one PDCP layer device, and the remaining RLC layer devices except the primary RLC entity among the multiple RLC layer devices are called secondary RLC entities.

[0154] The present disclosure proposes a method for dynamic packet replication transmission, which can realize dynamic replication transmission of zero, one, two or at most three packets, so as to enhance reliability and reduce delay for UEs configured with carrier aggregation technology (CA), dual connectivity technology (DC) or packet replication technology. In other words, the present disclosure proposes a method for transmitting data, in which one original data fragment and at most three replicated data fragments can be sent.

[0155] In the present disclosure, the packet replication technology can be configured for the UE through RRC messages by applying dual access technology or carrier dual access technology. Specifically, multiple RLC layer devices can be configured to be connected to one MAC layer device, and multiple RLC layer devices can be configured to be connected to one PDCP layer device and perform their packet replication. According to another method, multiple RLC layer devices are configured to be connected to one MCG MAC layer device, multiple RLC layer devices are configured to be connected to one SCGMAC layer device, and multiple RLC layer devices connected to different MAC layer devices can be configured to be connected to one PDCP layer device, and then, their packet replication can be configured to be performed.

[0156] In addition, the RRC message can use a logical channel identifier and a bearer identifier to indicate which RLC layer device among multiple RLC layer devices is the primary RLC entity and which are secondary RLC entities. For example, the cell group configuration information can indicate the configuration information of each RLC layer device, and can indicate the bearer identifier and logical channel identifier corresponding to each RLC layer device. In addition, the bearer establishment information can indicate the configuration information of each PDCP layer device, and indicate the bearer identifier corresponding to each PDCP layer device, and if multiple RLC layer devices are configured for the PDCP layer device or the bearer identifier, the bearer establishment information can indicate the primary RLC entity via the logical channel identifier corresponding to the primary RLC entity. Therefore, upon receiving the RRC message, the UE can configure the PDCP layer device based on the bearer identifier, connect multiple RLC layer devices corresponding to the bearer identifier to the PDCP layer device, and specify the primary RLC entity and multiple secondary RLC entities.

[0157] The present disclosure may consider an embodiment in which one primary RLC entity and at most three secondary RLC entities are configured.The embodiments proposed in the present disclosure may be extended to embodiments in which one or more primary RLC entities or secondary RLC entities are configured.

[0158] The present disclosure proposes a method for efficiently processing PDCP control data (PDCP Control PDU) generated by a PDCP layer device in a case where a packet copy transmission technology is configured as described above.

[0159] In the (1-1) embodiment or the (1-2) embodiment, if the packet duplication transmission technology proposed in the present disclosure is configured, the (1-1) embodiment or the (1-2) embodiment effectively processes the PDCP control data (PDCP control PDU) generated by the PDCP layer device, and the PDCP layer device: configures PDCP data (PDCP PDU) for the PDCP SDU received from the upper layer, and sends the PDCP data in duplicate to multiple secondary RLC entities; applies packet duplication to the PDCP control data generated by the PDCP layer device, and sends the duplicated PDCP control data to multiple secondary RLC entities. However, the receiving PDCP layer device does not process the duplicated PDCP control data multiple times, and if the duplicated PDCP control data has been received by detecting duplication, the PDCP layer device defines and indicates a new field in the duplicated PDCP control data so as to discard the duplicated PDCP control data. In the UE implementation, there is an advantage in that packet duplication can be commonly applied to PDCP data (PDCP SDU) received from an upper layer and PDCP control data generated by a PDCP layer device without distinguishing between the PDCP data and the PDCP control data.

[0160] In the (1-3) embodiment, if the packet replication transmission technology proposed in the present disclosure is configured, the (1-3) embodiment effectively processes the PDCP control data (PDCP control PDU) generated by the PDCP layer device, the PDCP layer device can configure the PDCP data (PDCP PDU) for the PDCP SDU received from the upper layer, and send the PDCP data to the primary RLC entity and multiple secondary RLC entities in a replicated manner, and packet replication may not be applied to the PDCP control data generated by the PDCP layer device, and the replicated PDCP control data is always sent to the primary RLC entity instead of being sent to the secondary RLC entity. Since the primary RLC entity is always in an activated state in the packet replication technology, in the UE implementation, it is easier to send the PDCP control data to the primary RLC entity than to send the PDCP control data to the secondary RLC entity (which can be changed to an activated state or a deactivated state).

[0161] Figure 1E A process of processing data at each layer in a next generation mobile communication system according to an embodiment of the present disclosure is shown.

[0162] refer to Figure 1E If the IP packet reaches the PDCP layer device, the PDCP layer can perform the above Figure 1DThe RLC layer as the lower layer can recognize the entire PDCP PDU 1e-05 received by the PDCP layer as one data, and can perform the following operations according to Figure 1D The RLC layer functions described in the above are operated, and the RLC header 1e-10 can be configured and transmitted to the lower layer. If the MAC layer device as the lower layer receives the header 1e-10 from the RLC layer, that is, when receiving the RLC PDU, the MAC layer device recognizes the entire data and performs Figure 1D The function of the MAC layer device described in , and configures the MAC subheader 1e-15 and transmits it to the lower layer.

[0163] if Figure 1E If a receiving MAC layer device receives a MAC PDU from a lower layer, the MAC layer device may read the content of the MAC subheader 1e-20 and may regard all remaining contents as data and transmit them to the RLC layer as the upper layer. If the RLC layer receives data 1e-25, the RLC layer only reads the RLC header corresponding to the RLC layer, performs the RLC layer function corresponding to the RLC layer, and transmits the data 1e-30 to the upper layer. Similarly, the PDCP layer may only read the PDCP header, may perform operations corresponding to the PDCP layer device, may remove the PDCP header, and may transmit it to the upper layer.

[0164] As described above, each layer of the next generation mobile communication system can read only the header corresponding to each layer, without reading the header or data of other layers. Therefore, each layer can manage and process independent information.

[0165] Figure 1F The invention shows a process of configuring a packet copy transmission function in a PDCP layer through an RRC message when a UE establishes a connection with a network according to an embodiment of the present disclosure.

[0166] Figure 1F The present invention shows a process in which a UE switches from an RRC idle mode or an RRC inactive mode (or a lightly connected mode) to an RRC connected mode and establishes a connection with a network according to an embodiment of the present disclosure, and shows a process for configuring an uplink packet copy transmission function (PDCP packet copy) of a PDCP layer. Such a process can be similarly applied to the configuration of a downlink packet copy transmission function, and the uplink packet copy transmission function configuration can also be used to configure both the uplink packet copy transmission function and the downlink packet copy transmission function.

[0167] refer to Figure 1F, if the UE for performing data transmission or reception in RRC connection mode does not perform data transmission or reception due to a predetermined reason or within a predetermined time, the base station may send a message to the UE to allow the UE to switch to RRC idle mode (indicated by reference numeral 1f-01). The message may be an RRCConnectionRelease message. Subsequently, if there is data to be sent, the UE that is not currently connected (hereinafter referred to as an idle mode UE) may perform an RRC connection establishment procedure with the base station. If the UE is in RRC inactive mode, the UE may send a message to perform an RRC connection recovery procedure. The message may be an RRCConnectionResumeRequest message. The UE establishes reverse transmission synchronization with the base station through a random access procedure and sends a message to the base station (indicated by reference numeral 1f-05). The message may be an RRCConnectionRequest message. The message may include a reason (establishmentCause) for establishing a connection with the UE's identifier. The base station may send an RRCConnectionSetup message so that the UE establishes an RRC connection (indicated by reference numeral 1f-10). The message can configure whether to use the packet copy transmission function for each logical channel (logical channel config (logical channel configuration)) or for each bearer or for each PDCP device (PDCP-config (PDCP configuration)). Specifically, the message can specify a primary RLC entity and a secondary RLC entity that are connected to the PDCP layer device and can be used for packet copy transmission. The primary RLC entity or the secondary RLC entity can be indicated by a logical channel identifier of a primary cell group (MCG) or a secondary cell group (SCG) or an RLC layer device. In addition, if the message configures two RLC layer devices to be connected to the PDCP layer device, a threshold that can be used by a separate bearer can be configured. If the amount of data to be transmitted is less than the threshold in the case of operating as a separate bearer, data transmission can be performed only to the primary RLC entity, and if the amount of data to be transmitted is greater than the threshold, data transmission can be performed to the primary RLC entity and the secondary RLC entity. The configured threshold and the primary RLC entity and the secondary RLC entity activate and use the packet copy transmission function in the dual connection. If the packet copy transmission function is deactivated via MAC control information, it falls back to the separate bearer and data can be continuously sent or received. Furthermore, if the message configures the packet copy transmission function, it may configure whether to activate or deactivate the packet copy transmission function for a data radio bearer (DRB). Alternatively, if the packet copy transmission function is configured, the message specifies the packet copy transmission function as being in an activated state or a deactivated state.Specifically, in the case of a control bearer (signaling radio bearer (SRB)) instead of a data bearer, the packet copy transmission function can be configured to be always activated. Alternatively, the packet copy transmission function can be configured to be always deactivated. In addition, in the case of configuring the packet copy transmission function, the message can specify and configure the initial state to be activated or deactivated. In addition, in the case of configuring the packet copy transmission function, the message can specify the default RLC entity to which the PDCP layer device sends data in the deactivated state, and the default RLC entity can be designated as a primary RLC entity or a secondary RLC entity, or can be indicated by a logical channel identifier. In addition, the packet copy transmission technology is configured to prevent unnecessary configuration information from being added to the message, and if the packet copy transmission function is in the deactivated state, the PDCP layer device can be allowed to always send data to the primary RLC entity (the primary RLC entity is always used in the activated state and the deactivated state, so the implementation becomes easier). In addition, the message may include mapping information between the logical channel identifier to which the packet copy transmission technology is applied and the cell to which the packet copy transmission technology is applied, that is, in the case of applying the packet copy transmission technology, the message may be configured to include mapping information indicating whether the data corresponding to a specific logical channel identifier is sent to a specific cell (the logical channel identifier may be configured to send data only to the mapped cell). If the packet copy transmission function is deactivated, the mapping information between the logical channel identifier and the cell configured in the message may release the mapping relationship, and the data corresponding to the logical channel identifier may be sent to any cell. In addition, the message may include indication information indicating whether packet copy transmission of PDCP control data (PDCP control PDU) is performed for each bearer or logical channel, and by applying the packet copy transmission technology to the PDCP control data without sending data to multiple RLC layer devices, the indication information indicates one RLC layer device to which the data is sent. The indicated RLC layer device may be indicated as a primary RLC entity or a secondary RLC entity, and if there is no indication information, the message may always be sent to the primary RLC entity.

[0168] Specifically, the packet replication technology can be configured for the UE through the RRC message by applying the dual access technology or the carrier dual access technology. Specifically, multiple RLC layer devices can be configured to be connected to one MAC layer device, and multiple RLC layer devices can be configured to be connected to one PDCP layer device and perform their packet replication. According to another method, multiple RLC layer devices are configured to be connected to one MCG MAC layer device, multiple RLC layer devices are configured to be connected to one SCG MAC layer device, and multiple RLC layer devices connected to different MAC layer devices can be configured to be connected to one PDCP layer device, and then, their packet replication can be configured to be performed. In addition, the RRC message can use a logical channel identifier and a bearer identifier to indicate which RLC layer device among the multiple RLC layer devices is the primary RLC entity and which are the secondary RLC entities. For example, the cell group configuration information can indicate the configuration information of each RLC layer device, and can indicate the bearer identifier and logical channel identifier corresponding to each RLC layer device. In addition, the bearer establishment information may indicate configuration information of each PDCP layer device and indicate a bearer identifier corresponding to each PDCP layer device, and if multiple RLC layer devices are configured for the PDCP layer device or the bearer identifier, the bearer establishment information may indicate the primary RLC entity via a logical channel identifier corresponding to the primary RLC entity. Therefore, upon receiving the RRC message, the UE may configure the PDCP layer device based on the bearer identifier, connect multiple RLC layer devices corresponding to the bearer identifier to the PDCP layer device, and specify the primary RLC entity and multiple secondary RLC entities.

[0169] In addition, the 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 an RRC message, which is a control message between a UE and a base station. A UE that has established an RRC connection may send an RRC Connection Setup Complete message (indicated by reference numerals 1f-15) to a base station. If the base station does not know the UE capabilities of the UE currently being connected, or if the base station expects to identify the UE capabilities, the base station may send a message to inquire about the UE capabilities. In addition, the UE may send a message reporting its own capabilities. The message may indicate whether the UE supports a new packet copy transmission function, and the UE may include an indicator indicating whether the UE supports the new packet copy transmission function in the message and send the indicator. The message includes a control message (e.g., SERVICE REQUEST), an access and mobility management function (AMF), a user plane function (UPF), or a session management function (SMF) requesting bearer establishment for a predetermined service from an MME. The message may be an RRC Connection Setup Complete message. The base station may send the control message stored in the message to the MME, AMF, UPF, or SMF (indicated by reference numeral 1f-20). The MME may determine whether to provide the service requested by the UE. As a result of the determination, if the UE determines to provide the requested service, the MME, AMF, UPF, or SMF may send an INITIAL CONTEXT SETUP REQUEST message (indicated by reference numeral 1f-25) to the base station. The message may include information such as quality of service (QoS) information applied when a data radio bearer (DRB) is configured, and security-related information (e.g., security keys and security algorithms) applied to the DRB. The base station may exchange SecurityModeCommand messages 1f-30 and SecurityModeComplete messages 1f-35 to establish security with the UE. If the security configuration is completed, the base station may send an RRCConnectionReconfiguration (indicated by reference numeral 1f-40) to the UE. The message may configure whether to use the packet copy transmission function for each logical channel (logical channelconfig) or for each bearer or for each PDCP device (PDCP-config). Specifically, the message can specify a primary RLC entity and a secondary RLC entity that are connected to a PDCP layer device and can be used for packet copy transmission. The primary RLC entity or the secondary RLC entity can be indicated by a logical channel identifier of a primary cell group (MCG) or a secondary cell group (SCG) or an RLC layer device.In addition, if the message configures two RLC layer devices to be connected to the PDCP layer device, a threshold value that can be used by the split bearer can be configured. If the amount of data to be sent when operating as a split bearer is less than the threshold, data transmission can be performed only to the primary RLC entity, and if the amount of data to be sent is greater than the threshold, data transmission to the primary RLC entity and the secondary RLC entity can be performed. The configured threshold and the primary RLC entity and the secondary RLC entity activate and use the packet copy transmission function in the dual connection, and if the packet copy transmission function is deactivated by the MAC control information, it falls back to the split bearer, and data can be continuously sent or received. In addition, if the message configures the packet copy transmission function, it can be configured whether to activate or deactivate the packet copy transmission function of the data radio bearer (DRB). Alternatively, if the packet copy transmission function is configured, the message specifies the packet copy transmission function as being in an activated state or a deactivated state. Specifically, in the case of a control bearer (signaling radio bearer (SRB)) instead of a data bearer, the packet copy transmission function can be configured to be always activated. Alternatively, the packet copy transmission function can be configured to be always deactivated. In addition, if the packet copy transmission function is configured, the message can specify and configure the initial state to be activated or deactivated. In addition, if the packet copy transmission function is configured, the message can specify the default RLC entity to which the PDCP layer device sends data in the deactivated state, and the default RLC entity can be designated as the main RLC entity or the secondary RLC entity, or can be indicated by a logical channel identifier. In addition, the packet copy transmission technology is configured to prevent unnecessary configuration information from being added to the message, and if the packet copy transmission function is in the deactivated state, the PDCP layer device can be allowed to always send data to the main RLC entity (the main RLC entity is always used in the activated state and the deactivated state, so the implementation becomes easier). In addition, the message may include mapping information between the logical channel identifier to which the packet copy transmission technology is applied and the cell to which the packet copy transmission technology is applied, that is, in the case where the packet copy transmission technology is applied, the message can be configured to include mapping information indicating whether data corresponding to a specific logical channel identifier is sent to a specific cell (the logical channel identifier can be configured to send data only to the mapped cell). If the packet copy transmission function is deactivated, the mapping information between the logical channel identifier and the cell configured in the message can release the mapping relationship, and the data corresponding to the logical channel identifier is sent to any cell. In addition, the message may include indication information indicating whether to perform packet copy transmission of PDCP control data (PDCP control PDU) for each bearer or logical channel, and the indication information indicates an RLC layer device to which the data is sent by applying the packet copy transmission technology to the PDCP control data without transmitting two RLC layer data fragments.The indicated RLC layer device may be indicated as a primary RLC entity or a secondary RLC entity, and if there is no indication information, the message may always be sent to the primary RLC entity.

[0170] Specifically, the packet replication technology can be configured for the UE through the RRC message by applying the dual access technology or the carrier dual access technology. Specifically, multiple RLC layer devices can be configured to be connected to one MAC layer device, and multiple RLC layer devices can be configured to be connected to one PDCP layer device and perform their packet replication. According to another method, multiple RLC layer devices are configured to be connected to one MCG MAC layer device, multiple RLC layer devices are configured to be connected to one SCG MAC layer device, and multiple RLC layer devices connected to different MAC layer devices can be configured to be connected to one PDCP layer device, and then, their packet replication can be configured to be performed. In addition, the RRC message can use a logical channel identifier and a bearer identifier to indicate which RLC layer device among the multiple RLC layer devices is the primary RLC entity and which are the secondary RLC entities. For example, the cell group configuration information can indicate the configuration information of each RLC layer device, and can indicate the bearer identifier and logical channel identifier corresponding to each RLC layer device. In addition, the bearer establishment information may indicate configuration information of each PDCP layer device and indicate a bearer identifier corresponding to each PDCP layer device, and if multiple RLC layer devices are configured for the PDCP layer device or the bearer identifier, the bearer establishment information may indicate the primary RLC entity via a logical channel identifier corresponding to the primary RLC entity. Therefore, upon receiving the RRC message, the UE may configure the PDCP layer device based on the bearer identifier, connect multiple RLC layer devices corresponding to the bearer identifier to the PDCP layer device, and specify the primary RLC entity and multiple secondary RLC entities.

[0171] In addition, the message includes configuration information of the DRB to process user data, and the UE can configure the DRB by applying the information, and can send an RRCConnectionReconfigurationComplete message to the base station (indicated by reference numeral 1f-45). The base station that has completed the DRB configuration with the UE can send an INITIAL CONTEXT SETUP COMPLETE message to the MME (indicated by reference numeral 1f-50). The MME that has received the INITIAL CONTEXT SETUP COMPLETE message can exchange S1BEARER SETUP (S1 bearer establishment) message and S1BEARER SETUP RESPONSE (S1 bearer establishment response) message (indicated by reference numerals 1f-55 and 1f-60). The S1 bearer can be a connection established between the S-GW and the base station for data transmission, and can correspond to the DRB in a one-to-one relationship. If the above process is completed, the UE can send or receive data to or from the base station through the S-GW (indicated by reference numerals 1f-65 and 1f-70). Therefore, the general data transmission process can generally include three operations: RRC connection configuration, security configuration and DRB configuration. In addition, the base station can send an RRCConnectionReconfiguration message to the UE to perform an update, addition or change to the configuration (indicated by reference numeral 1f-75).

[0172] Figure 1G A packet duplication transmission technology in which a PDCP layer performs packet transmission by duplicating packets based on a carrier aggregation technology in a next generation mobile communication system according to an embodiment of the present disclosure is shown.

[0173] refer to Figure 1G , if Figure 1FAs shown, UE 1g-05 receives an RRC message, then UE 1g-05 can configure the bearer (DRB or SRB) based on the configuration information received through the message, and can configure the PDCP layer device, RLC layer device and MAC layer device corresponding to each bearer. If the PDCP packet copy transmission technology based on the carrier aggregation technology is configured for the bearer, PDCP layer device or logical channel, the base station can configure two RLC layer devices 1g-10 and 1g-15 to be connected to the PDCP layer device of the UE for the bearer. The two RLC layer devices can be configured as the main RLC entity 1g-10 and the auxiliary RLC entity 1g-15, and the indication can be performed using the logical channel identifier (LCID). As described above, if the packet copy transmission technology is configured based on the carrier aggregation technology, the initial state can be in an activated state immediately after it is configured according to the configuration information of the RRC message, or can be in a deactivated state immediately. If the bearer is an SRB, the initial state can be in an activated state immediately. The base station can indicate whether the packet copy transmission technology is activated or deactivated for the bearer through MAC control information (MAC control element). The base station sends an indication of activating or deactivating the packet copy transmission technology to the UE through MAC control information, and can indicate whether to activate or deactivate the packet copy transmission technology through control information for the uplink packet copy transmission technology. Therefore, depending on the implementation of the base station, the downlink packet copy transmission technology may be used or not. Therefore, if the primary RLC entity and the secondary RLC entity for the packet copy transmission technology are configured, the UE can always perform a receiving operation in an activated state.

[0174] Figure 1H A packet duplication transmission technique in which a PDCP layer performs packet transmission by duplicating packets based on a dual connectivity technique in a next generation mobile communication system according to an embodiment of the present disclosure is shown.

[0175] refer to Figure 1H , if Figure 1FAs shown, UE 1h-05 receives an RRC message, then UE 1h-05 can configure the bearer (DRB or SRB) based on the configuration information received through the message, and can configure the PDCP layer device, RLC layer device and MAC layer device corresponding to each bearer. If the PDCP packet replication transmission technology based on the dual connection technology is configured for the bearer, PDCP layer device or logical channel, the base station can configure two RLC layer devices 1h-10 and 1h-15 to be connected to the PDCP layer device of the UE for the bearer. The two RLC layer devices can be configured as the main RLC entity 1h-10 and the auxiliary RLC entity 1h-15, and the indication can be performed using the logical channel identifier (LCID) and the cell group identifier. As described above, if the packet replication transmission technology is configured based on the dual connection technology, the initial state can be in an activated state immediately after it is configured according to the configuration information of the RRC message, or it can be in a deactivated state immediately. If the bearer is an SRB, the initial state can be in an activated state immediately. The base station can indicate whether the packet replication transmission technology is activated or deactivated for the bearer through MAC control information (MAC control element). The base station sends an indication to the UE via MAC control information as to whether to activate or deactivate the packet copy transmission technology, and may indicate whether to activate or deactivate the packet copy control via control information for the uplink packet transmission technology. In the above description, the base station may send MAC control information indicating whether to activate or deactivate the uplink packet copy transmission to the MAC layer devices 1h-20 and 1h-55 corresponding to the main cell group or the MAC layer devices 1h-25 and 1h-60 corresponding to the secondary cell group. Alternatively, for ease of implementation, the main cell group is always activated, and the base station may always send MAC control information only to the MAC layer device corresponding to the main cell group. Unlike the uplink packet copy transmission technology, the downlink packet copy transmission technology may or may not be used depending on how the base station is implemented. Therefore, if the main RLC entity and the secondary RLC entity for the packet copy transmission technology are configured, the UE may always perform a receiving operation in an activated state.

[0176] Fig. 1I The embodiment according to the present disclosure is shown Figure 1G or Figure 1H The packet copy transmission technology described in is extended to an embodiment of multiple RLC layer devices.

[0177] refer to Fig. 1IThe present disclosure contemplates a method for dynamic packet duplication transmission, which enables dynamic duplication transmission of zero, one, two, or at most three packets, so as to improve reliability and reduce latency for UEs that have been configured with carrier aggregation technology (CA), dual connectivity technology (DC), or packet duplication technology. In other words, the present disclosure proposes a method for transmitting data, in which one original data fragment and at most three duplicate data fragments can be sent.

[0178] In the present disclosure, the base station can send MAC control information to indicate the channel activation and deactivation of the secondary RLC entity connected to the bearer for which the packet replication transmission technology is configured for each bearer or logical channel. In addition, the base station can change the main RLC entity to another secondary RLC entity through the indication of the MAC control information.

[0179] The packet copy transmission technology disclosed above can be applied to user data (PDCP data PDU) of a PDCP layer device. In addition, the packet copy transmission technology described and proposed above can also be applied to control data (PDCP control PDU) of a PDCP layer device. That is, the present disclosure can apply the above-mentioned packet copy technology to interspersed ROHC feedback of a PDCP layer status report or a header compression protocol generated by a PDCP layer device, and can copy the PDCP layer control data (PDCP layer status report or interspersed ROHC feedback of a header compression protocol), and perform packet copy transmission to a primary RLC entity and multiple secondary RLC entities.

[0180] However, it should be noted that in the case of user data of the PDCP layer device, due to the existence of the PDCP sequence number, if any one of the data sent by the transmitting terminal in a duplicate manner is received, the receiving terminal can identify the duplicate packet received thereafter and immediately discard the duplicate packet. For example, if the receiving terminal receives data corresponding to PDCP sequence number 3, and other RLC layer devices receive data corresponding to PDCP sequence number 3 in a duplicate manner, the duplicate data can be immediately discarded because the data has already been received. That is, the receiving PDCP layer device can perform duplicate detection on the PDCP user data. On the other hand, since the PDCP control data does not have a PDCP sequence number and does not have a special field, the receiving PDCP layer device cannot perform duplicate detection on the PDCP control data, and therefore it is necessary to treat the PDCP control data received in a duplicate manner as new PDCP control data and perform its receiving process multiple times.

[0181] If a PDCP layer status report and header compression protocol (ROHC) for reporting information on data successfully received or unsuccessfully received from a PDCP layer device is configured, the control data (PDCP control PDU) of the PDCP layer device may include interspersed ROHC feedback for enabling the header compression protocol to send header decompression successfully via feedback, as well as configuration information. Even if the PDCP layer status report is received in a duplicated manner, only the data throughput may increase, but no major problems will occur. However, if more feedback is received than originally sent from the transmitting terminal, the feedback of the header compression protocol may have an adverse effect on the compression rate of the header compression protocol.

[0182] Therefore, the present disclosure proposes a method for reducing unnecessary duplicate data throughput of a receiving PDCP layer device, and a method for processing control data of a PDCP layer device through a bearer if header compression (Robust Header Compression (ROHC)) is configured, in which method a packet copy transmission technology is configured for smooth operation of a header compression / decompression protocol.

[0183] In the present disclosure, the (1-1) embodiment of processing control data of a PDCP layer device using a packet copy transmission technology based on a carrier aggregation technology or a packet copy transmission technology based on a dual access technology is as follows.

[0184] Figure 1J The (1-1) embodiment according to the embodiment of the present disclosure is shown, in which the control data of the PDCP layer device is processed using a packet copy transmission technology based on a carrier aggregation technology or a packet copy transmission technology based on a dual access technology.

[0185] The (1-1) embodiment proposes that if the receiving terminal receives the PDCP layer status report as shown in the figure mark 1j-05 or the interspersed ROHC feedback of the header compression protocol as shown in the figure mark 1j-10 in a duplicated manner via the packet copy transmission technology, a new D field 1j-15 is introduced so that unnecessary data processing is not performed repeatedly. The D field can be defined as 2 bits, for example, and can indicate which RLC layer device sends the PDCP layer control data. That is, "00" can indicate the PDCP control data sent from the primary RLC entity during the packet copy transmission, and "01" can indicate the PDCP control data sent from the secondary RLC layer entity with the lowest (or highest) logical channel identifier value among the secondary RLC entities, "10" can indicate the PDCP control data sent from the secondary RLC layer with the second lowest (or second highest) logical channel identifier value among the secondary RLC layer entities, and "11" can indicate the PDCP control data sent from the secondary RLC layer entity with the next lowest (or next highest) logical channel identifier value among the secondary RLC entities. Therefore, the receiving PDCP layer device can use the D field to perform duplicate detection and prevent unnecessary duplicate data processing. That is, the receiving PDCP layer device can indicate which RLC layer device among multiple RLC layer devices transmits 2 bits in a duplicated manner.

[0186] The PDU Type field may indicate whether the PDCP layer control data is a PDCP layer status report or an interspersed ROHC feedback of the header compression protocol.

[0187] Therefore, if duplicate PDCP layer control data is received from a receiving PDCP layer device using the D field proposed in the present disclosure, and if it is identified by checking the D field that the PDCP layer control data is PDCP layer control data that has already been received, the PDCP layer control data can be immediately discarded without repeatedly performing unnecessary data processing.

[0188] In the present disclosure, the (1-2) embodiment of using a packet copy transmission technology based on a carrier aggregation technology or a packet copy transmission technology based on a dual access technology to process control data of a PDCP layer device is as follows.

[0189] Figure 1K The (1-2) embodiment according to the embodiment of the present disclosure is shown, in which the control data of the PDCP layer device is processed using a packet copy transmission technology based on a carrier aggregation technology or a packet copy transmission technology based on a dual access technology.

[0190] Embodiment (1-2) proposes that if the receiving terminal receives the data in a duplicated manner via the packet duplication transmission technology, Figure 1K The PDCP layer status report shown in the reference numeral 1k-05 in FIG. Figure 1K The interspersed ROHC feedback of the header compression protocol shown in the reference numeral 1k-10 in the figure, a new sequence number (SN field) for the PDCP control PDU1k-15, so that unnecessary data processing is not repeatedly performed. The SN field can be defined as 2 bits, 3 bits, or 4 bits, and the sequence number of the SN field can be increased by 1 each time a PDCP layer control data is sent. The sequence number can be cyclically assigned, where the numbering starts from 0, increases to a value of 2^(bit length)-1, and then returns to 0. In the case of increasing the sequence number, a separate SN field can be used for the PDCP layer status report or the interspersed ROHC feedback of the header compression protocol. That is, the SN field for the PDCP layer status report and the SN field for the interspersed ROHC feedback of the header compression protocol can be independently defined and used. Alternatively, for ease of implementation, the SN field for the PDCP layer status report and the SN field for the interspersed ROHC feedback of the header compression protocol are not separately distinguished and share one SN field, and the sequence number of the SN field can be increased by one each time a PDCP layer control data is sent. The PDU Type field may indicate whether the PDCP layer control data is a PDCP layer status report or an interspersed ROHC feedback of the header compression protocol.

[0191] In the case of using the SN field, if the PDCP layer control data is transmitted to the primary RLC entity and the plurality of secondary RLC entities in a duplicated manner, the same sequence number value of the SN field may be allocated and transmitted in a duplicated manner. Therefore, if the PDCP layer control data having the same sequence number value is received in a duplicated manner using the SN field, the receiving PDCP layer device may immediately discard the unnecessary PDCP layer control data received in a duplicated manner without performing processing thereof.

[0192] In addition, the transmitting PDCP layer device and the receiving PDCP layer device may define and use new state variables to allocate, compare, increase and operate the sequence number SN field value introduced above. For example, the transmitting terminal may define and use TX_PDCP_CONTROL_SN to allocate the sequence number of the PDCP layer control data, and the receiving terminal may also define RX_PDCP_CONTROL_SN to check, update and perform duplicate detection of the sequence number of the received PDCP layer control data. If necessary, the receiving PDCP layer device may drive the PUSH receiving window or the PULL receiving window based on the sequence number of the SN field, and a timer may be applied.

[0193] Therefore, if the receiving terminal PDCP layer device uses the SN field proposed in the present disclosure to receive the copied PDCP layer control data, if it is identified by checking the SN field that the PDCP layer control data is data that has been received, the PDCP layer control data can be discarded immediately without performing unnecessary data processing.

[0194] In the present disclosure, the (1-3) embodiments of processing control data of a PDCP layer device using a packet copy transmission technology based on a carrier aggregation technology or a packet copy transmission technology based on a dual access technology are as follows.

[0195] Embodiment (1-3) proposes that if the receiving terminal receives the following Figure 1K The PDCP layer status report shown in the reference numeral 1k-05 in FIG. Figure 1K In the interspersed ROHC feedback of the header compression protocol shown by reference numeral 1k-10 in the figure, the packet copy transmission technology is not applied to the PDCP layer control data to prevent unnecessary data processing from being repeatedly performed.

[0196] Embodiment (1-3) proposes an aspect in which, if the base station Figure 1F If the RRC message in the UE configures the packet copy transmission technology for each bearer or logical channel and activates the packet copy transmission technology through the MAC control information, the UE applies the packet copy transmission technology only to the PDCP layer control data (PDCP data PDU) and does not apply the packet copy transmission technology to the PDCP layer control data (PDCP control PDU). Figure 1F In the RRC message, if the RLC layer device (primary RLC entity or secondary RLC entity) to which the PDCP layer control data is to be sent is indicated, the UE can send the PDCP layer control data only to the RLC layer device indicated above. If the packet copy transmission function is activated for ease of implementation, the UE does not apply the packet copy transmission technology to the PDCP layer control data, and can send the PDCP layer control data to the primary RLC entity that is always connected. As mentioned above, Figure 1F The master RLC entity may be configured to indicate, through an RRC message, the cell group to which the RLC entity belongs and the bearer identifier or logical channel identifier corresponding to the RLC layer device.

[0197] Therefore, as proposed in the (1-3) embodiment, the packet copy transmission technology may not be applied to the PDCP layer control data, so the receiving terminal PDCP layer device may not receive the copied PDCP layer control data.

[0198] The method of applying the packet copy transmission technology to PDCP layer control data proposed in the (1-3) embodiment can identify data when the packet copy transmission technology is applied, and distinguish between PDCP layer user data and PDCP layer control data to perform different data processing thereof.

[0199] In the (1-3) embodiments, if the packet replication transmission technology proposed in the present disclosure is configured, the PDCP control data (PDCP control PDU) generated by the PDCP layer device is effectively processed, the PDCP layer device can configure PDCP data (PDCP PDU) for the PDCP SDU received from the upper layer, and send the PDCP data to the primary RLC entity and multiple secondary RLC entities in a replicated manner, and packet replication may not be applied to the PDCP control data generated by the PDCP layer device, and the replicated PDCP control data is always sent to the primary RLC entity instead of being sent to the secondary RLC entity. Since the primary RLC entity may always be in an activated state in the packet replication technology, in the UE implementation, it is easier to send the PDCP control data to the primary RLC entity than to send the PDCP control data to the secondary RLC entity (which can be changed to an activated state or a deactivated state).

[0200] In addition, in the (1-3) embodiments, since the PDCP layer device only performs transmission to the primary RLC entity and does not apply packet replication to the PDCP control data, if the primary RLC entity is changed to another RLC layer device (for example, one RLC layer device among multiple different secondary RLC entities), then after the change, when the newly generated PDCP control data is sent, the newly generated PDCP control data needs to be sent to the newly changed primary RLC entity.

[0201] Therefore, if the MAC layer device receives a MAC CE and receives an instruction indicating that the primary RLC entity connected to the bearer for which the packet copy transmission technology is configured is changed to another RLC layer device (for example, one RLC layer device among multiple different secondary RLC entities), the MAC layer device needs to notify the PDCP layer device of the instruction information or indicate the instruction to the PDCP layer device. That is, the MAC layer device needs to indicate which RLC layer device (or logical channel identifier) ​​is the new primary RLC entity. Then, the PDCP layer device changes the existing primary RLC entity to a secondary RLC entity, or regards the existing primary RLC entity as a secondary RLC entity, configures the newly indicated RLC layer device as the primary RLC entity, and can perform processing of the PDCP control data as described above.

[0202] In addition, the RRC layer device receives an RRC message and receives an instruction indicating that the primary RLC entity connected to the bearer for which the packet copy transmission technology is configured is changed to another RLC layer device (for example, one RLC layer device among multiple different secondary RLC entities), and the RRC layer device needs to notify the PDCP layer device of the instruction information or indicate the instruction information to the PDCP layer device. That is, the RRC layer device needs to indicate which RLC layer device (or logical channel identifier) ​​is the new primary RLC entity. Then, the PDCP layer device changes the existing primary RLC entity to a secondary RLC entity, or regards the existing primary RLC entity as a secondary RLC entity, configures the newly indicated RLC layer device as the primary RLC entity, and performs processing of the PDCP control data as described above.

[0203] If the (1-3) embodiments of processing PDCP control data proposed in the present disclosure are applied to the case of sending duplicate data to multiple RLC layer devices by applying the packet duplication transmission technology proposed in the present disclosure, and if the multiple RLC layer devices operate in RLC AM mode, the RLC layer device can receive an RLC status report and indicate that the data successfully transmitted to the higher PDCP layer device has been performed. The PDCP layer device can indicate to the other multiple RLC layer devices that it is no longer necessary to perform duplicate transmission of PDCP user data that has been successfully sent from a specific RLC layer device among the multiple RLC layer devices. However, the PDCP layer device may not indicate to the other multiple RLC layer devices that it is no longer necessary to perform duplicate transmission of PDCP user data that has been successfully sent from a specific RLC layer device among the multiple RLC layer devices.

[0204] In the case where the (1-1) embodiment or the (1-2) embodiment for processing the PDCP control data proposed in the present disclosure is applied to sending duplicated data to multiple RLC layer devices by applying the packet duplication transmission technology proposed in the present disclosure, if the multiple RLC layer devices operate in the RLCCAM mode, the RLC layer device can receive an RLC status report and indicate the identification of data successfully transmitted to a higher PDCP layer device. The PDCP layer device can indicate to the other multiple RLC layer devices that it is no longer necessary to perform a duplicate transmission of the PDCP user data successfully sent from one RLC layer device among the multiple RLC layer devices. However, the PDCP layer device may not indicate to the other multiple RLC layer devices that it is no longer necessary to perform a duplicate transmission of the PDCP user data that has been successfully sent from one RLC layer device among the multiple RLC layer devices.

[0205] Figure 1L The operation of a terminal in a next generation mobile communication system according to an embodiment of the present disclosure is illustrated, wherein the PDCP layer performs a packet copy transmission technology based on a carrier aggregation technology or a dual access technology.

[0206] refer to Figure 1L , if Figure 1F As shown, UE 11-01 receives an RRC message, and UE 11-01 can configure a bearer (DRB or SRB) based on the configuration information received through the message, and can configure the PDCP layer device, RLC layer device and MAC layer device corresponding to each bearer. If the PDCP packet replication transmission technology based on carrier aggregation technology or dual connection technology is configured for the bearer, PDCP layer device or logical channel, the base station can configure two RLC layer devices to be connected to the PDCP layer device for the UE relative to the bearer. The two RLC layer devices can be configured as a primary RLC entity and a secondary RLC entity, and the indication can be performed using a logical channel identifier (LCID). As described above, if the packet replication transmission technology is configured as described above, the initial state can be in an activated state immediately after it is configured according to the configuration information of the RRC message, or can be in a deactivated state immediately. If the bearer is an SRB, the initial state can be in an activated state immediately. The base station can indicate whether the packet replication transmission technology is activated or deactivated for the bearer through MAC control information (MAC control element). The base station can indicate whether to activate or deactivate the packet copy transmission technology for the bearer through MAC control information, and can indicate whether to activate or deactivate the packet copy transmission technology through control information for the uplink packet copy transmission technology. The activation state (indicated by reference numeral 11-05) can be configured using MAC control information.

[0207] If packet copy transmission is performed in the PDCP layer device for which the packet copy transmission technology is activated, the UE may first identify data to which the packet copy transmission is to be applied (indicated by reference numeral 11-10). As a result of the identification, if the data is PDCP layer user data (PDCP data PDU) (indicated by reference numeral 11-20), the UE performs the second data processing. Figure 1G and Figure 1H The second data processing indicates that packet duplication of PDCP layer user data is performed, and the PDCP layer user data is sent to the primary RLC entity and the secondary RLC entity in a duplicated manner. The data to which packet duplication is applied can be identified (indicated by reference numeral 11-10). If the data is PDCP layer control data (PDCP control PDU) (indicated by reference numeral 11-15), its first data processing can be performed. In the above description, the first data processing refers to data processing performed by applying the (1-1) embodiment, the (1-2) embodiment, or the (1-3) embodiment.

[0208] Figure 1M The structure of a UE according to an embodiment of the present disclosure is shown.

[0209] refer to Figure 1M , the UE includes a radio frequency (RF) processor 1m-10, a baseband processor 1m-20, a storage device 1m-30 and a controller 1m-40.

[0210] The RF processor 1m-10 can perform functions such as frequency band conversion and amplification of signals for sending or receiving signals through a radio channel. That is, the RF processor 1m-10 up-converts the baseband signal provided by the baseband processor 1m-20 into an RF band signal, transmits the RF band signal through an antenna, and down-converts the RF band signal received through the antenna into a baseband signal. For example, the RF processor 1m-10 may include a transmitting filter, a receiving filter, an amplifier, a mixer, an oscillator, a digital-to-analog converter (DAC), an analog-to-digital converter (ADC), and the like. Figure 1M In the figure, only one antenna is shown, but the UE may include multiple antennas. In addition, the RF processor 1m-10 may include multiple RF chains. In addition, the RF processor 1m-10 can perform beamforming. For beamforming, the RF processor 1m-10 can adjust the phase and amplitude of each of the signals sent or received through multiple antennas or antenna elements. In addition, the RF processor can perform MIMO operations, and can receive multiple layers when performing MIMO operations. The RF processor 1m-10 can perform receive beam scanning by appropriately configuring multiple antennas or antenna elements under the control of the controller, or can adjust the direction and width of the receive beam so that the receive beam is coordinated with the transmit beam.

[0211] The baseband processor 1m-20 can perform conversion functions between baseband signals and bit strings according to the physical layer standard of the system. For example, when sending data, the baseband processor 1m-20 generates complex symbols by encoding and modulating the transmitted bit string. In addition, when receiving data, the baseband processor 1m-20 reconstructs the received bit string by demodulating and decoding the baseband signal provided from the RF processor 1m-10. For example, according to the orthogonal frequency division multiplexing (OFDM) scheme, when sending data, the baseband processor 1m-20 generates complex symbols by encoding and modulating the transmitted bit string, maps the complex symbols to subcarriers, and then configures OFDM symbols by performing inverse fast Fourier transform (IFFT) operations and cyclic prefix (CP) insertion. In addition, when receiving data, the baseband processor 1m-20 divides the baseband signal provided from the RF processor 1m-10 into units of OFDM symbols, reconstructs the signal mapped to the subcarriers through a fast Fourier transform (FFT) operation, and then reconstructs the received bit string by demodulating and decoding the mapped signal.

[0212] The baseband processor 1m-20 and the RF processor 1m-10 send or receive signals as described above. Therefore, the baseband processor 1m-20 and the RF processor 1m-10 can be referred to as a transmitter, a receiver, a transceiver or a communication unit. In addition, at least one of the baseband processor 1m-20 and the RF processor 1m-10 may include multiple communication modules to support different radio access technologies. In addition, at least one of the baseband processor 1m-20 and the RF processor 1m-10 may include different communication modules to process signals of different frequency bands. For example, different radio access technologies may include LTE networks, NR networks, etc. In addition, different frequency bands may include ultra-high frequency (SHF) (e.g., 2.5 GHz, 5 GHz) bands and millimeter wave (e.g., 60 GHz) bands.

[0213] The storage device 1m-30 stores data for performing UE operations, such as basic programs, application programs, and configuration information. The storage device 1m-30 provides the stored data at the request of the controller 1m-40.

[0214] The controller 1m-40 controls the overall operation of the UE. For example, the controller 1m-40 can send or receive signals through the baseband processor 1m-20 and the RF processor 1m-10. In addition, the controller 1m-40 records or reads data in the storage device 1m-30. To this end, the controller 1m-40 may include at least one processor. For example, the controller 1m-40 may include a communication processor (CP) for performing communication control and an application processor (AP) for controlling an upper layer such as an application (not shown). For example, the controller 1m-40 may also include a multi-connection processor lm-42 for connection.

[0215] Figure 1N A block configuration of TRP in a wireless communication system according to an embodiment of the present disclosure is shown.

[0216] refer to Figure 1N , the base station may include an RF processor 1n-10, a baseband processor 1n-20, a backhaul communication unit 1n-30, a storage device 1n-40 and a controller 1n-50.

[0217] The RF processor 1n-10 may perform functions such as frequency band conversion and amplification of signals for transmitting or receiving signals through a radio channel. That is, the RF processor 1n-10 up-converts the baseband signal provided by the baseband processor 1n-20 into an RF band signal, transmits the RF band signal through an antenna, and down-converts the RF band signal received through the antenna into a baseband signal. For example, the RF processor 1n-10 may include a transmitting filter, a receiving filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, etc. Figure 1NIn the figure, only one antenna is shown, but the first access node may include multiple antennas. In addition, the RF processor 1n-10 may include multiple RF chains. In addition, the RF processor 1n-10 can perform beamforming. For beamforming, the RF processor 1n-10 can adjust the phase and amplitude of each of the signals sent and received through multiple antennas or antenna elements. The RF processor can perform downlink MIMO operations by sending one or more layers.

[0218] The baseband processor 1n-20 can perform a conversion function between a baseband signal and a bit string according to the physical layer standard of the first radio access technology. For example, when sending data, the baseband processor 1n-20 generates complex symbols by encoding and modulating the transmission bit stream. In addition, when receiving data, the baseband processor 1n-20 reconstructs the received bit string by demodulating and decoding the baseband signal provided from the RF processor 1n-10. For example, according to the OFDM scheme, when sending data, the baseband processor 1n-20 generates complex symbols by encoding and modulating the transmission bit stream, maps the complex symbols to subcarriers, and then configures OFDM symbols by performing IFFT operations and CP insertion. In addition, when receiving data, the baseband processor 1n-20 divides the baseband signal provided from the RF processor 1n-10 in units of OFDM symbols, reconstructs the signal that has been mapped to the subcarrier through FFT operations, and then reconstructs the received bit string by demodulating and decoding the mapped signal. The baseband processor 1n-20 and the RF processor 1n-10 send or receive signals as described above. Therefore, the baseband processor 1n-20 and the RF processor 1n-10 can be referred to as a transmitter, a receiver, a transceiver, a communication unit, or a wireless communication unit.

[0219] The communication unit 1n-30 provides an interface for communicating with other nodes in the network.

[0220] The storage device 1n-40 stores data for performing the operation of the master station, such as basic programs, application programs, and configuration information. Specifically, the storage device 1n-40 may store information about the bearer assigned to the connected terminal, the measurement result reported from the connected terminal, etc. In addition, the storage device 1n-40 may store information used as a criterion for determining whether to provide or stop multiple connections to the terminal. In addition, the storage device 1n-40 provides the stored data at the request of the controller 1n-50.

[0221] The controller 1n-50 controls the overall operation of the master station. For example, the controller 1n-50 may send or receive a signal through the baseband processor 1n-20 and the RF processor 1n-10 or through the backhaul communication unit 1n-30. In addition, the controller 1n-50 records or reads data in the storage device 1n-40. To this end, the controller 1n-50 may include at least one processor. For example, the controller 1m-40 may also include a multi-connection processor ln-52 for connection.

[0222] Figure 2A The structure of an LTE system according to an embodiment of the present disclosure is shown.

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

[0224] exist Figure 2A In the LTE system, eNBs 2a-05, 2a-10, 2a-15, and 2a-20 correspond to conventional Node Bs of the UMTS system. The eNBs may be connected to the UEs 2a-35 via radio channels and may play a more complex role than conventional Node Bs. In the LTE system, since all user services (including real-time services such as Voice over IP (VoIP) over Internet Protocol) are served via shared channels, a device is required to perform scheduling by collecting status information such as buffer status, available transmit power status, and channel status of the UE. eNBs 2a-05, 2a-10, 2a-15, and 2a-20 may be used as devices for performing scheduling. One eNB generally controls multiple cells. For example, in order to achieve a transmission rate of 100 Mbps, the LTE system uses an orthogonal frequency division multiplexing (hereinafter referred to as OFDM) scheme with a 20 MHz bandwidth as a radio access technology. In addition, an adaptive modulation and coding (hereinafter referred to as AMC) scheme is adopted that determines the modulation scheme and channel coding rate according to the channel status of the UE. The S-GW 2a-30 is a device for providing a data bearer, and generates or removes a data bearer under the control of the MME 2a-25. The MME is a device responsible for various control functions of the UE and a mobility management function, and is connected to a plurality of base stations.

[0225] Figure 2B A radio protocol architecture in an LTE system according to an embodiment of the present disclosure is shown.

[0226] refer to Figure 2B For each of the UE and eNB, the radio protocol of the LTE system includes Packet Data Convergence Protocol (PDCP) 2b-05 and 2b-40, Radio Link Control (RLC) 2b-10 and 2b-35, and Medium Access Control (MAC) 2b-15 and 2b-30. PDCP 2b-05 and 2b-40 are responsible for operations such as IP header compression / reconstruction. The main functions of PDCP are summarized as follows.

[0227] -Header compression and decompression: ROHC only

[0228] -Transmission of user data

[0229] - For RLC AM, in-sequence delivery of upper layer PDUs during PDCP re-establishment

[0230] - For split bearers in DC (supports RLC AM only): PDCP PDU routing for transmission and PDCP PDU reordering for reception

[0231] - For RLC AM, duplicate detection of lower layer SDUs during PDCP re-establishment

[0232] - For RLC AM, during PDCP data restoration, for split bearers in DC and for retransmission of PDCP SDUs at handover

[0233] -Encryption and decryption

[0234] - Timer-based SDU discard in uplink

[0235] Radio Link Control (hereinafter referred to as RLC) 2b-10 and 2b-35 reconfigures a PDCP Packet Data Unit (PDU) into an appropriate size in order to perform an ARQ operation. The main functions of the RLC are summarized as follows.

[0236] -Transmission of upper layer PDU

[0237] - Error correction via ARQ (for AM data transmission only)

[0238] -RLC SDU concatenation, segmentation and reassembly (only for UM and AM data transmission)

[0239] - Re-segmentation of RLC data PDU (only for AM data transmission)

[0240] - Reordering of RLC data PDUs (only for UM and AM data transmission)

[0241] - Duplicate detection (for UM and AM data transmission only)

[0242] -Protocol error detection (for AM data transmission only)

[0243] -RLC SDU discard (only for UM and AM data transmission)

[0244] -RLC reconstruction

[0245] MAC 2b-15 and 2b-30 are connected to a plurality of RLC layer devices configured in one terminal, and can perform operations of multiplexing RLC PDU with MAC PDU and demultiplexing RLC PDU from MAC PDU. The main functions of MAC are summarized as follows.

[0246] - Mapping between logical channels and transport channels

[0247] - Multiplex MAC SDUs belonging to one or different logical channels into a transport block (TB) delivered to the physical layer on a transport channel / demultiplex MAC SDUs belonging to one or different logical channels from a transport block (TB) delivered from the physical layer on a transport channel

[0248] -Dispatch information report

[0249] - Error correction through HARQ

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

[0251] - Prioritization between UEs through dynamic scheduling

[0252] -MBMS service logo

[0253] -Transmission format selection

[0254] -filling

[0255] The physical layers 2b-20 and 2b-25 may perform operations of channel coding and modulating upper layer data, generating upper layer data into OFDM symbols, sending OFDM symbols through a radio channel or demodulating OFDM symbols received through a radio channel, channel decoding OFDM symbols, and sending OFDM symbols to an upper layer.

[0256] Figure 2C A structure of a next generation mobile communication system according to an embodiment of the present disclosure is shown.

[0257] refer to Figure 2C, the radio access network of the next generation mobile communication system may include a next generation base station (new radio node B) (hereinafter referred to as NR gNB or NR base station) 2c-10 and a new radio core network (NR CN) 2c-05. User equipment (new radio user equipment, hereinafter referred to as NR UE or terminal) 2c-15 accesses an external network through a radio access channel 2c-20, via NRgNB 2c-10 and NR CN 2c-05.

[0258] exist Figure 2C In the present invention, the NR gNB 2c-10 may correspond to an evolved Node B (eNB) of a conventional LTE system. The NR gNB is connected to the NR UE 2c-15 via a radio channel and may provide services that are better than those of a conventional Node B. In the next generation mobile communication system, since all types of user services are served through shared channels, a device is required to perform scheduling by collecting status information such as buffer status, available transmit power status, and channel status of the UE. In addition, the NRgNB 2c-10 is responsible for such device functions. One NR gNB generally controls multiple cells. In order to achieve ultra-high-speed data transmission compared to conventional LTE, the NR gNB may have a conventional maximum bandwidth or a larger bandwidth, and may additionally utilize 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 (hereinafter referred to as AMC) scheme that determines the modulation scheme and channel coding rate based on the channel status of the UE. The NR CN 2c-05 may perform functions such as mobility support, bearer setup, and QoS configuration. NR-CN is a device responsible for various control functions of UE and mobility management functions, and is connected to multiple base stations. In addition, the next-generation mobile communication system can also operate in conjunction with the traditional LTE system, and NR-CN is connected to MME2c-25 via a network interface. MME is connected to eNB 2c-30, that is, a traditional base station.

[0259] Figure 2D A radio protocol architecture of a next generation mobile communication system according to an embodiment of the present disclosure is shown.

[0260] refer to Figure 2D , for each of the UE and the NR base station, the radio protocol of the next-generation mobile communication system includes NR SDAP 2d-01 and 2d-45, NR PDCP 2d-05 and 2d-40, NR RLC 2d-10 and 2d-35, and NR MAC 2d-15 and 2d-30.

[0261] The main functions of NR SDAP 2d-01 and 2d-45 may include some of the following functions:

[0262] -Transmission of user plane data

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

[0264] - Marking of QoS flow ID in both UL and DL packets

[0265] - For UL SDAP PDU, map the reflective QoS flow to the data bearer.

[0266] The UE can receive configurations for each PDCP layer device, each bearer, or each logical channel through an RRC message, such as whether to use the header of the SDAP layer device or the function of the SDAP layer device. If the SDAP header is configured, the UE can be instructed to update or reconfigure the mapping information between the QoS flows and data bearers of the uplink and downlink through the NAS QoS reflection configuration 1-bit indicator (NAS reflective QoS) and AS QoS reflection configuration 1-bit indicator (AS reflective QoS) of the SDAP header. The SDAP header may include QoS flow ID information indicating QoS. QoS information can be used as data processing priority, scheduling information, etc. to support smooth services.

[0267] The main functions of NR PDCP 2d-05 and 2d-40 may include some of the following functions:

[0268] -Header compression and decompression: ROHC only

[0269] -Transmission of user data

[0270] - In-sequence delivery of upper layer PDUs

[0271] - Out-of-order delivery of upper layer PDUs

[0272] - Reordering of received PDCP PDUs

[0273] - Duplicate detection of lower layer SDU

[0274] -Retransmission of PDCP SDU

[0275] -Encryption and decryption

[0276] - Timer-based SDU discard in uplink

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

[0278] The main functions of NR RLC 2d-10 and 2d-35 may include some of the following functions:

[0279] -Transmission of upper layer PDU

[0280] - In-sequence delivery of upper layer PDUs

[0281] - Out-of-order delivery of upper layer PDUs

[0282] - Error correction via ARQ

[0283] - Concatenation, segmentation and reassembly of RLC SDU

[0284] - Re-segmentation of RLC data PDUs

[0285] - Reordering of RLC data PDUs

[0286] - Duplicate detection

[0287] -Protocol error detection

[0288] -RLC SDU discarded

[0289] -RLC reconstruction

[0290] The in-sequence delivery function of the NR RLC device refers to a function of sending the RLC SDU received from the lower layer to the upper layer in the reception sequence, and may include: a function of reassembling and sending multiple RLC SDUs if one RLC SDU is initially segmented into multiple RLC SDUs and received; a function of reordering the received RLC PDUs based on the RLC sequence number (SN) or PDCP SN; a function of reordering the sequence and recording the lost RLC PDUs; a function of providing a status report on the lost RLC PDUs to the transmitting side; and a function of requesting retransmission of the lost RLC PDUs. Alternatively, if a lost RLC SDU occurs, the in-sequence delivery function of the NR RLC device may include a function of sequentially sending only the RLC SDUs preceding the lost RLC SDU to the upper layer, or if a predetermined timer expires despite the presence of a lost RLC SDU, a function of sequentially sending all RLC SDUs received before the timer starts to the upper layer, or if a predetermined timer expires despite the presence of a lost RLC SDU, a function of sequentially sending all RLC SDUs received so far to the upper layer. In addition, the RLC PDUs may be processed in the order in which they are received (in the order of arrival, regardless of the order of sequence numbers and sequence numbers), and may be sent to the PDCP device out of order. For segmentation, the in-order delivery function may include the functions of receiving segments stored in a buffer or segments to be received later, reconfiguring segments in a complete RLC PDU, processing the RLC PDU, and sending the RLC PDU to the PDCP device. The NR RLC layer may not include a cascading function, and the cascading function may be performed by the NR MAC layer, or may be replaced by a multiplexing function of the NR MAC layer.

[0291] The out-of-order delivery function of the NR RLC device refers to a function of directly sending the RLC SDU received from the lower layer to the upper layer without considering the order, and if one RLC SDU is originally segmented into multiple RLC SDUs and received, it may include: a function of reassembling multiple RLC SDUs and sending them; and a function of storing the RLC SN or PDCP SN of the received RLC PDU, reordering the sequence, and recording the lost RLC PDU.

[0292] NR MAC 2d-15 and 2d-30 can be connected to multiple NR RLC layer devices configured in one UE, and the main functions of NR MAC can include some of the following functions:

[0293] - Mapping between logical channels and transport channels

[0294] -Multiplexing / demultiplexing of MAC SDU

[0295] -Dispatch information report

[0296] - Error correction through HARQ

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

[0298] - Prioritization between UEs through dynamic scheduling

[0299] -MBMS service logo

[0300] -Transmission format selection

[0301] -filling

[0302] The NR PHY layers 2d-20 and 2d-25 may perform operations of channel coding and modulating upper layer data, generating upper layer data into OFDM symbols, sending OFDM symbols via a radio channel, or demodulating and channel decoding OFDM symbols received via a radio channel, and transmitting the OFDM symbols to an upper layer.

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

[0304] Figure 2E The invention shows a process in which a base station configures Ethernet header protocol related configuration information for a UE when the UE establishes a connection with a network according to an embodiment of the present disclosure.

[0305] Figure 2EThe process of UE switching from RRC idle mode or RRC inactive mode (or light connection mode) to RRC connection mode and establishing a connection with the network is shown, and the process of configuring Ethernet header protocol related configuration information for UE by the base station is shown. Specifically, the SDAP layer device or the PDCP layer device indicates whether to perform the Ethernet header compression and decompression process, and indicates whether the Ethernet header compression and decompression process is used only in the downlink, only in the uplink, or in both the uplink and the downlink. The Ethernet header protocol related configuration information is 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. If the UE reports the UE capability to the base station, the UE defines a new indicator and can report to the base station whether the UE can use the Ethernet protocol or whether the Ethernet header compression and decompression process can be used. In addition, the base station can configure the type of Ethernet frame or Ethernet header to be used for each bearer or logical channel to determine the field type configured in the Ethernet header, the size of the Ethernet header is how many bytes, the size of each field of the Ethernet header is how many bits, or how the field of the Ethernet header is configured. Furthermore, in the case of adding padding to an Ethernet frame, the UE can be configured by indicating whether to use a function of preventing the padding from being transmitted over an actual wireless link by removing the padding at a transmitting terminal and adding the padding at a receiving terminal.

[0306] refer to Figure 2E, if the UE used to perform data transmission or reception in RRC connection mode does not perform data transmission or reception due to a predetermined reason or within a predetermined time, the base station may send a message to the UE to allow the UE to switch to RRC idle mode (indicated by reference numeral 2e-01). The message may be an RRCConnectionRelease message. Subsequently, if data to be sent is generated, the UE that is not currently connected (hereinafter referred to as an idle mode UE or an inactive UE) may perform an RRC connection recovery procedure or an RRC connection establishment procedure with the base station. The UE establishes reverse transmission synchronization with the base station through a random access procedure and sends a message to the base station (indicated by reference numeral 2e-05). The message may be an RRCConnectionRequest message (in the case of a recovery procedure, an RRCResumeRequest message). The message may include a reason (establishmentCause) for establishing a connection with an identifier of the UE. The base station sends a message so that the UE establishes an RRC connection (indicated by reference numeral 2e-10). The message may be an RRCConnectionSetup message (in the recovery procedure, an RRCRumeRequest message). The message may include information indicating whether the Ethernet protocol or header compression and decompression process is used for each logical channel (logical channel config), each bearer, each PDCP device (PDCP-config), or each SDAP layer device. In addition, more specifically, each logical channel, bearer, or each PDCP device (or SDAP device) can indicate whether the Ethernet protocol or Ethernet header compression and decompression process is used only for a specific IP flow or a specific QoS flow (the SDAP device can be configured with information about the IP flow or QoS flow in order to determine whether the Ethernet protocol is applied or whether the Ethernet header compression method is used, so that the SDAP device can indicate to the PDCP device whether the Ethernet protocol is applied or whether the Ethernet header compression method is used for each QoS flow. According to another method, the SDAP layer device or the PDCP device can check each QoS flow for itself and determine whether the Ethernet protocol or the Ethernet header compression method is applied). In addition, if the SDAP device indicates whether the Ethernet protocol is applied or whether the Ethernet header compression method is used, the SDAP device can indicate an identifier of a predefined library or dictionary information to be used in whether the Ethernet protocol or the Ethernet header compression method is applied or the buffer size to be used. Furthermore, the message may include a command for establishing or releasing whether to apply the Ethernet protocol or to perform an Ethernet header compression method.In addition, in the above description, whether to apply the Ethernet protocol or use the Ethernet header compression method can be always configured via the RLC AM bearer (ARQ function, lossless mode with retransmission function) or via the RLC UM bearer, or can be configured together with the header compression protocol (ROHC), or can be configured at different times according to the situation. In addition, the message can 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-config). The message can indicate whether to apply IP packet header compression (ROHC) to each logical channel (logicalchannelconfig), each bearer or each PDCP device (PDCP-config), and whether to apply ROHC to the uplink and downlink respectively can be configured via an indicator. In addition, whether to use the user data compression method (UDC) for each logical channel, for each bearer or for each PDCP device can be configured for the uplink and downlink respectively. That is, UDC can be configured to be used for the uplink but not for the downlink. On the contrary, UDC can be configured not for the uplink but for the downlink. In addition, UDC can be configured to be used in both directions. In addition, the message can configure the Ethernet header compression process and the ROHC header compression process at the same time. In addition, the message can define an indicator (drbEthHCContinue) to indicate the continuous use of context or Ethernet header compression protocol related configuration information without initialization thereof in the case of handover (e.g., handover in a base station) or in the case of switching from RRC inactive mode to RRC connected mode. By considering the indicator in the case of rebuilding an SDAP layer device or a PDCP layer device, a UE that has received the indicator can continuously use the Ethernet header compression protocol related configuration information or context without initializing it. Therefore, the overhead caused by the reconfiguration of the Ethernet header compression protocol can be reduced. In addition, the message can define a new indicator and indicate the initialization context or Ethernet header compression protocol related configuration information. In addition, the RRC message can be configured whether to configure the SDAP protocol or the SDAP header. In addition, the message may configure the type of Ethernet frame or Ethernet header to be used for each bearer or logical channel to determine the type of field 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 in which the Ethernet header field is configured. In addition, in the case of adding padding to the Ethernet frame, the UE may indicate whether to use a function of preventing the padding from being transmitted over the actual wireless link by removing the padding at the transmitting terminal and adding the padding at the receiving terminal for configuration.

[0307] In addition, the 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 an RRC message, which is a control message between a UE and a base station. A UE that has established an RRC connection may send a message to a base station (indicated by reference numeral 2e-15). The message may be an RRCConnectionSetupComplete message. If the base station does not know the UE capabilities of the UE currently being connected, or if the base station expects to identify the UE capabilities, the base station may send a message to inquire about the UE capabilities. In addition, the UE may send a message reporting its own capabilities. The message may indicate whether the UE supports a new packet copy transmission function, and the UE may include an indicator indicating whether the UE supports a new packet copy transmission function in the message and send the indicator. The message may include a control message (e.g., SERVICE REQUEST (service request)) requesting bearer establishment for a predetermined service from the MME. The base station may send the control message stored in the message to the MME (indicated by reference numeral 2e-20), and the MME may determine whether to provide the service requested by the UE. As a result of the determination, if the UE determines to provide the requested service, the MME may send an INITIAL CONTEXT SETUP REQUEST message (indicated by reference numeral 2e-25) to the base station. The message may include information such as quality of service (QoS) information to be applied if a data radio bearer (DRB) is configured, and security-related information (e.g., security keys and security algorithms) to be applied to the DRB. The base station may exchange SecurityModeCommand messages 2e-30 and SecurityModeComplete messages 2e-35 to establish security with the UE. If the security configuration is completed, the base station may send a message (indicated by reference numeral 2e-40) to the UE. The message may be an RRCConnectionReconfication message.

[0308] The message may include information indicating whether the Ethernet protocol is used for each logical channel (logical channel config), each bearer, each PDCP device (PDCP-config) or each SDAP layer device or whether a header compression and decompression process is used. In addition, more specifically, each logical channel, bearer or each PDCP device (or SDAP device) may indicate whether the Ethernet protocol or the Ethernet header compression and decompression process is used only for a specific IP flow or a specific QoS flow (the SDAP device may be configured with information about the IP flow or QoS flow in order to determine whether the Ethernet protocol is applied or whether the Ethernet header compression method is used, so that the SDAP device can indicate to the PDCP device each QoS flow about whether the Ethernet protocol is applied or whether the Ethernet header compression method is used. Alternatively, the SDAP layer device or the PDCP device may check each QoS flow for itself and determine whether the Ethernet protocol or the Ethernet header compression method is applied). In addition, if the SDAP device indicates whether the Ethernet protocol is applied or whether the Ethernet header compression method is used, the SDAP device may indicate an identifier of a predefined library or dictionary information to be used in whether the Ethernet protocol or the Ethernet header compression method is applied or the buffer size to be used. In addition, the message may include a command for establishing or releasing whether to apply the Ethernet protocol or to perform the Ethernet header compression method. In addition, in the above description, whether to apply the Ethernet protocol or use the Ethernet header compression method can always be configured via the RLC AM bearer (ARQ function, lossless mode with retransmission function) or via the RLC UM bearer, or can be configured together with the header compression protocol (ROHC), or can be configured at different times according to the situation. In addition, the message can 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-config). The message can indicate whether to apply IP packet header compression (ROHC) to each logical channel (logicalchannelconfig), each bearer or each PDCP device (PDCP-config), and whether to apply ROHC to the uplink and downlink respectively can be configured via an indicator. In addition, whether to use the user data compression method (UDC) for each logical channel, for each bearer or for each PDCP device can be configured for the uplink and downlink respectively. That is, UDC can be configured for uplink but not for downlink. Conversely, UDC may be configured not for uplink but for downlink. In addition, UDC may be configured for use in both directions.

[0309] In addition, the message can configure the Ethernet header compression process and the ROHC header compression process at the same time. In addition, the message can define an indicator (drbEthHCContinue) to indicate the continuous use of the context or Ethernet header compression protocol related configuration information without initialization thereof in the case of handover (e.g., handover in a base station) or in the case of switching from RRC inactive mode to RRC connected mode. By considering the indicator in the case of rebuilding the SDAP layer device or the PDCP layer device, the UE that has received the indicator can continuously use the Ethernet header compression protocol related configuration information or context without initializing it. Therefore, the overhead caused by the reconfiguration of the Ethernet header compression protocol can be reduced. In addition, the message can define a new indicator and indicate the initialization context or Ethernet header compression protocol related configuration information. In addition, the RRC message can be configured whether to configure the SDAP protocol or the SDAP header. In addition, the message can configure the type of Ethernet frame or Ethernet header to be used for each bearer or logical channel to determine the field type configured in the Ethernet header, the size of the Ethernet header is how many bytes, the size of each field of the Ethernet header is how many bits, or the method of configuring the Ethernet header field. Furthermore, in the case of adding padding to an Ethernet frame, the UE can be configured by indicating whether to use a function of preventing the padding from being transmitted over an actual wireless link by removing the padding at a transmitting terminal and adding the padding at a receiving terminal.

[0310] In addition, the message includes configuration information of the DRB in which user data is to be processed, and the UE can configure the DRB by applying the information and send the message to the base station (indicated by reference numeral 2e-45). The message can be an RRCConnectionReconfigurationComplete message. The base station that has completed the DRB configuration with the UE can send an INITIALCONTEXT SETUP COMPLETE message to the MME (indicated by reference numeral 2e-50), and the MME that has received the INITIAL CONTEXT SETUP COMPLETE message can exchange S1 BEARER SETUP (S1 bearer setup) message and S1 BEARER SETUP RESPONSE (S1 bearer setup response) message (indicated by reference numerals 2e-55 and 2e-60). The S1 bearer can be a connection established between the S-GW and the base station for data transmission, and can correspond to the DRB in a one-to-one relationship. If the above processing is completed, the UE sends or receives data to or from the base station through the S-GW (indicated by reference numerals 2e-65 and 2e-70). Therefore, the general data transmission process may generally include three operations: RRC connection configuration, security configuration and DRB configuration. In addition, the base station may send an RRCConnectionReconfiguration message to the UE to perform an update, addition or change to the configuration (indicated by reference numeral 2e-75).

[0311] Figure 2F An Ethernet Header Compression (EthHC) method according to an embodiment of the present disclosure is shown.

[0312] refer to Figure 2F , the upper layer data 2F-05 may be generated as data corresponding to services such as video transmission, photo transmission, web search, and VoLTE. The data generated by the application layer device may be processed by TCP / IP or UDP corresponding to the network data transmission layer, or may be processed by the Ethernet protocol, and the corresponding headers 2f-10, 2f-15, and 2f-20 (upper layer header or Ethernet header) may be configured, and may be transmitted to the PDCP layer. If the PDCP layer receives data (PDCP SDU) from the upper layer, the PDCP layer may perform the following process.

[0313] If the header compression (ROHC) or Ethernet header compression process is configured to be transmitted via RRC messages such as Figure 2E2e-10, 2e-40 or 2e-75) is used in the PDCP layer, the TCP / IP header is compressed via ROHC, as shown in the figure mark 2f-21, and the PDCP layer device can perform an Ethernet header compression process on the Ethernet header 2f-20, as shown in the figure mark 2f-22. In addition, a separate Ethernet header compression (EHC) header 2f-40 (which includes a field for indicating whether the Ethernet header is compressed or a field for indicating which fields of the Ethernet header are compressed (omitted) or not compressed (not omitted)) is configured, and the EHC header can be configured before the compressed header. If integrity verification is configured, the PDCP PDU can be configured by performing integrity protection on the PDCP header, the EHC header, the compressed header and the data, performing an encryption process on the EHC header, the compressed header and the data or the data and the compressed header except the EHC header, and configuring the PDCP header 2f-30. The PDCP layer device may include a header compressor / decompressor, may determine whether to perform header compression on each data configured through an RRC message, and may use the header compressor / decompressor. The transmitting terminal may use the header compressor in the transmitting PDCP layer device to compress the Ethernet header or the upper layer header (e.g., the TCP / IP header), and the receiving terminal may use the header decompressor in the receiving PDCP layer device to decompress the Ethernet header or the upper layer header (e.g., the TCP / IP header).

[0314] Above Figure 2F 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 uplink data can be applied to downlink data in the same manner.

[0315] The method for performing Ethernet header compression on an Ethernet header proposed in the present disclosure is a method for reducing the size of the header by omitting fields indicating static information and only indicating changed information. Therefore, first, information can be sent by including complete header information for compression and configuration information (e.g., an identifier (type) specific to the business (or service) of the Ethernet protocol, a sequence number specific to the business (or service), information related to the compression rate, etc.). In addition, compared with the complete information sent first, fields corresponding to unchanged information (e.g., a send address field or a receive address field (MAC address), a leading field, a start of frame delimiter (SFD) or a frame checksum (FCS) or an Ethernet type field, etc.) can be omitted or not sent, and the header can be configured to include only fields corresponding to changed information in order to reduce the size of the header. Alternatively, a compressible field and an incompressible field are distinguished, and if the value of the compressible field does not change compared to the field value of the complete header sent first, only the compressible field is compressed (or omitted) and sent, and the incompressible field is always sent without being compressed (or omitted). In addition, if the value of even one of the compressible fields has changed compared to the field value of the previously sent complete header, it is characterized in that the complete header is sent again. In addition, each time a complete header is received, the receiving PDCP layer device can always send feedback indicating that the complete header is received well to the sending PDCP layer device.

[0316] Figure 2G An Ethernet Header Compression (EthHC) method proposed in accordance with an embodiment of the present disclosure when an SDAP header or layer device is configured is shown.

[0317] refer to Figure 2G , the upper layer data 2g-05 may be generated as data corresponding to services such as video transmission, photo transmission, web search, and VoLTE. The data generated by the application layer device may be processed by TCP / IP or UDP corresponding to the network data transmission layer, or may be processed by the Ethernet protocol and SDAP layer device, and the corresponding headers 2g-10, 2g-15, and 2g-20 (upper layer header, Ethernet header, or SDAP header) may be configured, and may be transmitted to the PDCP layer. If the PDCP layer receives data (PDCP SDU) from the upper layer, the PDCP layer may perform the following process.

[0318] If the header compression (ROHC) or Ethernet header compression process is configured to be transmitted via RRC messages such as Figure 2E2e-10, 2e-40 or 2e-75) is used in the PDCP layer, the TCP / IP header is compressed via ROHC, as shown in 2g-21, and the PDCP layer device can perform the Ethernet header compression process on the Ethernet header 2g-23 except the SDAP header, as shown in 2g-22. In addition, a separate Ethernet Header Compression (EHC) 2g-40 header (which includes a field for indicating whether the Ethernet header is compressed or a field for indicating which fields of the Ethernet header are compressed (omitted) or not compressed (not omitted)) is configured, and the EHC header can be configured before the compressed header. If integrity verification is configured, the PDCP PDU may be configured by performing integrity protection on the SDAP header, PDCP header, EHC header, compressed header, and data, performing an encryption process on the compressed header, data, and EHC header except the SDAP header, or data and compressed header except the SDAP header and EHC header, and configuring the PDCP header 2g-30. The PDCP layer device may include a header compressor / decompressor, may determine whether to perform header compression on each data configured through an RRC message, and may use the header compressor / decompressor. The transmitting terminal may use the header compressor in the transmitting PDCP layer device to compress the Ethernet header or the upper layer header (e.g., the TCP / IP header), and the receiving terminal may use the header decompressor in the receiving PDCP layer device to decompress the Ethernet header or the upper layer header (e.g., the TCP / IP header).

[0319] Above Figure 2G 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 uplink data can be applied to downlink data in the same manner.

[0320] The method for performing Ethernet header compression on an Ethernet header proposed in the present disclosure is a method for reducing the size of the header by omitting fields indicating static information and only indicating changed information. Therefore, first, information can be sent by including complete header information for compression and configuration information (e.g., an identifier (type) specific to a business (or service) of the Ethernet protocol, a sequence number specific to a business (or service), information related to a compression rate, etc.). In addition, compared with the complete information sent first, fields corresponding to unchanged information (e.g., a send address field or a receive address field (MAC address), a leading field, a start of frame delimiter (SFD) or a frame checksum (FCS) or an Ethernet type field, etc.) can be omitted or not sent, and the header can be configured to include only fields corresponding to changed information in order to reduce the size of the header. Alternatively, a compressible field and an incompressible field are distinguished, and if the value of the compressible field does not change compared to the field value of the complete header sent first, only the compressible field is compressed (or omitted) and sent, and the incompressible field is always sent without being compressed (or omitted). In addition, if the value of even one of the compressible fields has changed compared to the field value of the previously sent complete header, it is characterized in that the complete header is sent again. In addition, each time a complete header is received, the receiving PDCP layer device can always send feedback indicating that the complete header is received well to the sending PDCP layer device.

[0321] Figure 2H Another Ethernet Header Compression (EthHC) method proposed when an SDAP header or layer device is configured according to an embodiment of the present disclosure is shown.

[0322] refer to Figure 2H , the upper layer data 2H-05 may be generated as data corresponding to services such as video transmission, photo transmission, web search, and VoLTE. The data generated by the application layer device may be processed by TCP / IP or UDP corresponding to the network data transmission layer, or may be processed by the Ethernet protocol and SDAP layer device, and the corresponding headers 2h-10, 2h-15, and 2h-20 (upper layer header, Ethernet header, or SDAP header) may be configured and may be transmitted to the PDCP layer. If the PDCP layer receives data (PDCP SDU) from the upper layer, the PDCP layer may perform the following process.

[0323] If the header compression (ROHC) or Ethernet header compression process is configured to be transmitted via RRC messages such as Figure 2E2e-10, 2e-40 or 2e-75) is used in the PDCP layer, the TCP / IP header is compressed via ROHC, as shown in the figure mark 2h-21, and the PDCP layer device can perform the Ethernet header compression process on the SDAP header and the Ethernet header 2h-23, as shown in the figure mark 2h-22. In addition, a separate Ethernet header compression (EHC) 2h-40 header (which includes a field for indicating whether the SDAP header and the Ethernet header are compressed or a field for indicating which fields of the SDAP header or the Ethernet header are compressed (omitted) or not compressed (not omitted)) is configured, and the EHC header can be configured before the compressed header. If integrity verification is configured, the PDCP PDU may be configured by performing 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, performing 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 data and the compressed header (compressed SDAP header, compressed Ethernet header or compressed TCP / IP header) except the EHC header, and configuring the PDCP header 2h-30. The PDCP layer device may include a header compressor / decompressor, may determine whether to perform header compression on each data configured through an RRC message, and may use the header compressor / decompressor. The sending terminal can use the header compressor in the sending PDCP layer device to compress the Ethernet header or the upper layer header (e.g., the TCP / IP header), and the receiving terminal can use the header decompressor in the receiving PDCP layer device to decompress the Ethernet header or the upper layer header (e.g., the TCP / IP header).

[0324] Above Figure 2H 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 uplink data can be applied to downlink data in the same manner.

[0325] The method for performing Ethernet header compression on an Ethernet header proposed in the present disclosure is a method for reducing the size of the header by omitting fields indicating static information and only indicating changed information. Therefore, first, information can be sent by including complete header information for compression and configuration information (e.g., an identifier (type) specific to a business (or service) of the Ethernet protocol, a sequence number specific to a business (or service), information related to a compression rate, etc.). In addition, compared with the complete information sent first, fields corresponding to unchanged information (e.g., a send address field or a receive address field (MAC address), a leading field, a start of frame delimiter (SFD) or a frame checksum (FCS) or an Ethernet type field, etc.) can be omitted or not sent, and the header can be configured to include only fields corresponding to changed information in order to reduce the size of the header. Alternatively, a compressible field and an incompressible field are distinguished, and if the value of the compressible field does not change compared to the field value of the complete header sent first, only the compressible field is compressed (or omitted) and sent, and the incompressible field is always sent without being compressed (or omitted). In addition, if the value of even one of the compressible fields has changed compared to the field value of the previously sent complete header, it is characterized in that the complete header is sent again. In addition, each time a complete header is received, the receiving PDCP layer device can always send feedback indicating that the complete header is received well to the sending PDCP layer device.

[0326] The Ethernet header compression method as described above can be similarly applied to the SDAP header as well as the Ethernet header in order to compress the SDAP header. This is because the D / C field, QFI field, RQI field, and 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 RCI field is not used except when the base station indicates that a QoS mapping update is required. Therefore, by applying a method for compressing the Ethernet header to the SDAP header, the SDAP header is compressed together with the Ethernet header. If 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 LTE systems and NR systems that can configure the SDAP header for easy implementation.

[0327] In addition, the header compression algorithm proposed in the present disclosure may be applicable only to PDCP user data (PDCP data PDU) received from an upper layer, but not to PDCP control data (PDCP control PDU) generated by a PDCP layer device.

[0328] As proposed in the above disclosure, in the Ethernet header compression protocol 2f-22, the PDCP layer device can identify the Ethernet header when receiving data from the upper layer device, compress the Ethernet header by using the protocol for compressing the Ethernet header, and define and use a new header 2f-40 before the compressed Ethernet header. In the above description, encryption of the new header 2f-40 is not performed. This is because, if encryption of the new header 2f-40 is not performed in the UE implementation, and if the SDAP header has been configured in the PDCP layer device when sending data to the lower layer device after performing data processing (such as integrity protection or encryption process), the SDAP header, the PDCP header or the new header can be cascaded together at once, so that the UE can be easily implemented.

[0329] According to another method, encryption may be performed on the new header 2f-40.

[0330] This is because the new header is regarded as data generated by the PDCP layer device and data processing is performed, so the data processing process can be simplified.

[0331] In the case of applying the header compression method proposed in the present disclosure, in order to decompress the compressed Ethernet header on the receiving terminal side, it is necessary to know which fields are not compressed, omitted or sent. Therefore, if the transmitter side compresses the Ethernet header, a new header (e.g., an EHC header) can be defined and placed in front of the compressed Ethernet header, and then the new header is sent. A new first field is defined in the new EthHC header to indicate which field among the multiple fields of the Ethernet header is compressed, omitted or not sent (e.g., a context identifier). According to another method, the new field can indicate whether a specific field has been compressed (or omitted or not sent) or not compressed (or included or sent) using each bit in the bitmap format. In addition, since the first field can indicate which field in the Ethernet header has been compressed (or omitted) or not compressed (or included), the receiving terminal side can use the first field to calculate the size of the compressed Ethernet header that has been received. That is, by subtracting the size of the omitted header field from the size of the original Ethernet header, the size of the compressed Ethernet header can be known.

[0332] 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 allowing only compressible (or omittable) fields among the fields of the Ethernet header to have a mapping indicating whether compression (or omission) is performed, the overhead of the new EthHC header can be reduced.

[0333] In addition, a 1-bit indicator may be defined in the new EHC header to indicate whether the Ethernet header (or SDAP header) is compressed or no compression is applied. A 1-bit indicator may be defined and used in the PDCP header.

[0334] In addition, the EHC header may indicate the size or length of the Ethernet header compressed into the second field so as to accurately indicate the size of the compressed Ethernet header (e.g., for ease of implementation). In addition, if the Ethernet header includes multiple size types, the second field may indicate the size type of the Ethernet header. Alternatively, a new third field indicating whether Ethernet header compression is performed may be defined in the EHC header.

[0335] According to another method, identifiers indicating multiple Ethernet header compression methods can be defined and used in the EHC header, respectively. The identifier can also indicate an Ethernet header type or a QoS flow identifier. Since multiple upper-layer headers with different header structures (e.g., various types of Ethernet headers) are configured by different fields, it is necessary to change the method for compressing and not compressing the field according to the field type. Therefore, for example, a first identifier indicating a header type or content can indicate the application of a first Ethernet header compression method, and a second identifier can indicate the application of a second Ethernet header compression method. Therefore, if multiple data streams or QoS streams are mapped to one PDCP layer device, different header compression methods can be applied by applying new identifiers, and the receiving terminal can distinguish the compression methods and perform different decompression methods.

[0336] In the present disclosure, the Ethernet header compression method can be applied not only to the Ethernet header, but also to the general upper layer device header. For convenience, in the present disclosure, the header compression method is referred to as the Ethernet header compression method.

[0337] In addition, the configuration of the Ethernet header field according to the above Ethernet header type can be configured for each bearer through the RRC message, so that Figure 2E Which types of Ethernet headers or header fields are configured as described in . For example, a header compression or decompression method can be adopted by configuring information in an upper-layer header type (e.g., Ethernet header type) that can be configured in an upper-layer device of each bearer and configuring an identifier mapped to each header type. That is, an identifier or indicator indicating the Ethernet header type can be defined and used in a new header. In addition, a receiving terminal of the new header can include a checksum field for whether successful decompression of the Ethernet header has been performed. Alternatively, a field indicating initialization of a buffer for compression of a sending PDCP layer device and a buffer for decompression of a receiving PDCP layer device can be defined and used. The fields defined in the new header can be defined and used in a PDCP header or an SDAP header.

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

[0339] Another Ethernet header compression method may be used based on the new EHC header. For example, if the transmitting terminal compresses the Ethernet header, the compression is performed sequentially, and during the compression, if the value of the header field does not change compared to the value of the previously transmitted Ethernet header field, the Ethernet header is compressed (omitted) and the first field is configured according to it, and if the Ethernet header field value is different from the previously transmitted Ethernet header field value, the Ethernet header is decompressed (included) and the first field may be configured according to it, thereby completing the compression of the Ethernet header. The above-mentioned Ethernet header compression may be performed in ascending order based on the PDCP sequence number or COUNT value, and the previous Ethernet header may indicate an Ethernet header corresponding to the data, which has a value less than 1 of the PDCP sequence number or COUNT value. Upon receiving the compressed Ethernet header, the receiving terminal may check the first field, and if the compressed (omitted) field in the Ethernet header has the same value as the field of the previously received Ethernet header, the receiving terminal may reconstruct the compressed (omitted) field in the Ethernet header according to it, and the uncompressed (included) field may be newly updated. The transmitting terminal and the receiving terminal may have a separate buffer for compressing the Ethernet header, the buffer may be updated each time the Ethernet header is compressed, and the buffer may be updated each time the Ethernet header is decompressed. If the compressed Ethernet header is reconstructed, the receiving terminal may remove the new EthHC header and send the reconstructed Ethernet header to the upper layer. In addition, if the Ethernet header is sent first, the transmitting terminal may send the complete Ethernet header information. That is, first, the receiving terminal may send the Ethernet header without performing Ethernet header compression so that the receiving terminal can recognize the complete Ethernet header information.

[0340] In the following description of the present disclosure, specific embodiments of an Ethernet header compression method are proposed.

[0341] Fig.2I The (2-1) specific embodiment of the Ethernet header compression method according to the embodiment of the present disclosure is shown.

[0342] According to the (2-1) embodiment of the present disclosure, a method for compressing an Ethernet header is a method of omitting fields having unchanged field values, fields having unchanged field values ​​compared to a previously sent Ethernet header, or fields having Ethernet header field values ​​that do not need to be sent among multiple header fields 2i-31, 2i-32, 2i-33, 2i-34, 2i-35, 2i-36, and 2i-37 in the Ethernet header, and selectively sending necessary fields, valid fields, or fields having changed field values. Therefore, among the multiple fields included in the Ethernet header, for example, among the first field 2i-31, the second field 2i-32, the third field 2i-33, the fourth field 2i-34, the fifth field 2i-35, the sixth field 2i-36 or the seventh field 2i-37, if the first field 2i-31, the second field 2i-32, the fourth field 2i-34, the fifth field 2i-35 or the seventh field 2i-37 is omissible or does not need to be sent, or its field value is the same as the previously sent Ethernet header field value, then only the third field 2i-33 and the sixth field 2i-36 are sent.

[0343] In addition, the present embodiment proposes a separate configuration of the new EHC header so that the above-mentioned method can be applied to perform compression and decompression at the receiving terminal. In the (2-1) embodiment of the present disclosure, the new EHC header may have bitmap structures 2i-11 and 2i-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 with 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 with a value of 0 or 1.

[0344] For example, Fig.2I As shown, if the PDCP layer device of the transmitting terminal receives an Ethernet frame 2i-05 from an upper layer device, and if the Ethernet header compression process is configured, the PDCP layer device may store the corresponding field value of the Ethernet header of the first received Ethernet frame in a buffer 2i-15 for transmitting Ethernet compression. The PDCP layer device may send the complete header of the first Ethernet frame as is without performing Ethernet header compression. When feedback indicating that the complete header is received normally is received from the receiving PDCP layer device, the Ethernet compression process may be applied. In the above description, multiple complete headers may be sent. For example, multiple complete headers and data (first data, second data, and subsequent data) may be sent until feedback indicating that the complete header is received normally is received from the receiving PDCP layer device.

[0345] In the above description, if the Ethernet compression process is started, and if the next Ethernet frame is received, each field value of the Ethernet header is compared with the field value stored in the transmission buffer for Ethernet compression. If the Ethernet header has a field having the same value as the field value stored in the transmission buffer, the corresponding field is omitted, and the bit corresponding to the omitted field or mapped to the omitted field can be configured as 1 (or 0), and it can be indicated that the field is omitted. If each field value of the Ethernet header of the second Ethernet frame is compared with the field value stored in the transmission buffer for Ethernet compression, and if the Ethernet header has a field having a different value from the field value stored in the transmission buffer, the corresponding field is not omitted, and the bit corresponding to the field that is not omitted or mapped to the field can be configured as 1 (or 0), and it can be indicated that the field is not omitted.

[0346] If integrity protection is configured, integrity protection may be performed, an encryption process may be performed, a new header 2i-10 may be configured, a PDCP header may be configured, and the new header and the PDCP header may be concatenated and transmitted to a lower layer device.

[0347] The new header 2i-10 may allow each bit to indicate which field of the Ethernet header is present (uncompressed) or missing (compressed), such as a bitmap.

[0348] In the new header 2i-10, a new field (e.g., a 1-bit indicator) may be defined to indicate whether the Ethernet header compression process is performed. The 1-bit indicator may directly indicate that the Ethernet header compression has not been performed, so that the receiving terminal does not perform processing on the new header and the uncompressed upper layer header. If the Ethernet header compression algorithm is configured, the 1-bit indicator may be defined to be located at the very front end of the new EHC header that is always present, so that the receiving terminal may directly check whether compression is performed. In addition, a 1-bit indicator indicating whether the Ethernet header compression process is performed may be defined and used in the SDAP header or the PDCP header. If a 1-bit indicator is defined in the SDAP header or the PDCP header, and if the Ethernet header compression process is not performed, the overhead may be reduced because the new header 2i-10 for Ethernet header compression may be omitted. In addition, a case where all bit values ​​in the bitmap field are configured to 0 (or 1) can be defined and used as a special value indicating an uncompressed complete header (indicated by reference numeral 2i-26), or can indicate initialization of a buffer for compression of a sending PDCP layer device and a buffer for decompression of a receiving PDCP layer device.

[0349] exist Fig.2IIn the present invention, the PDCP layer device or SDAP layer device of the receiving terminal can receive the compressed Ethernet frame 2i-25 from the lower layer device, and if the Ethernet header compression process is configured, the corresponding field value of the Ethernet header of the Ethernet frame with the first received uncompressed complete header can be checked and the field value can be stored in the receiving buffer 2i-30 for Ethernet decompression in the receiving terminal. If the complete header (e.g., SDAP header or Ethernet header) is successfully received, feedback indicating the successful reception of the complete header is sent to the sending PDCP layer device to enable the application of Ethernet header compression to begin. The first Ethernet frame can be sent to the upper layer device without decompressing the Ethernet header. Then, when the next Ethernet frame is received, the next Ethernet frame is decrypted, and when the new EHC header is checked to see whether the header is compressed or uncompressed, if the new EHC header is uncompressed, integrity verification is performed, the EHC header is removed, and the data is sent to the upper layer. If the new EHC header indicates that the Ethernet header (or SDAP header) is compressed, the field values ​​of the new header 2i-10 for Ethernet compression are checked to determine which fields are omitted (compressed) and which fields are not omitted (not compressed). In addition, the receiving terminal can reconstruct the values ​​of the fields indicated as omitted (compressed) in the above description into field values ​​stored in the receiving buffer 2i-30 to reconstruct (decompress) the Ethernet header before it is compressed for Ethernet decompression. Since the values ​​of the fields indicated as not omitted (not compressed) are new or changed values, the receiving terminal can store the new or changed values ​​as field values ​​according to the fields in the receiving buffer for decompression. If decryption is performed and integrity protection is configured, integrity verification is performed. If there are no errors, the Ethernet frame can be configured with the reconstructed Ethernet header and sent to the upper layer device.

[0350] In the above description, if the field value of the Ethernet header is changed while the sending PDCP layer device applies the Ethernet header compression method, the sending PDCP layer device indicates to the new EHC header that the Ethernet header is not compressed, and sends a complete header to initialize the buffer of the receiving terminal, and configures the buffer to have the value of the complete header again. Upon receiving the uncompressed complete header, the receiving PDCP layer device may send feedback indicating that the uncompressed complete header is successfully received to the sending PDCP layer device. In the present disclosure, each time the receiving PDCP layer device receives the uncompressed complete upper layer header, the receiving PDCP layer device may always send feedback indicating that the uncompressed complete upper layer header is successfully received to the sending PDCP layer device. In addition, in the present disclosure, upon receiving the uncompressed complete upper layer header, the receiving PDCP layer device always sends feedback indicating that the uncompressed complete upper layer header is successfully received to the sending PDCP layer device, but does not send feedback in the case of receiving the uncompressed upper layer header. The receiving PDCP layer device performs different operations depending on whether to perform upper layer compression on the received data.

[0351] The separate new EHC header may have a fixed size (eg, 1 byte or 2 bytes).

[0352] In the above embodiment, the length field of the Ethernet header may also be compressed and decompressed by applying the above method. According to another method, the length field of the Ethernet header may always be transmitted without being compressed.

[0353] According to another method, the length field of the Ethernet header can always be sent without being compressed. The receiving PDCP layer device can 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 thereto (because the length of the length field is a fixed value), and then the PDCP layer device can 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 can be omitted in the new EHC header, the sending PDCP layer device can always omit (compress) the length field, even if the length field value is different for each data, and perform transmission, the receiving PDCP layer device can calculate the length field value according to the above method, thereby reconstructing the length field value of the Ethernet header.

[0354] In addition, in the case where the Ethernet header compression method and ROHC (e.g., TCP / IP header or UDP header compression method) are configured together for the bearer, if the length field of the Ethernet header can always be sent without being compressed, the receiving PDCP layer device can first apply the ROHC decompression method to the received data (e.g., PDCP PDU or PDCP SDU), and then apply the Ethernet header decompression method to the received data. This is because, in the case where the receiving terminal (e.g., the receiving PDCP layer device) reconstructs the length field of the Ethernet header, if the length field is reconstructed as the length of the data to which header compression is applied via ROHC, the length field in the upper layer device (e.g., the Ethernet layer device) may be incorrectly reconstructed, resulting in data truncation or an error. Therefore, if the Ethernet header compression method and the ROHC header compression method are configured together, the receiving PDCP layer device can first decompress the upper layer header by applying the ROHC header decompression method, and can decompress the Ethernet header by applying the Ethernet decompression method. In addition, when reconstructing the length field value of the Ethernet header during Ethernet header decompression, the receiving PDCP layer device can use a method of deriving and calculating the length field value by considering the size of the length field (e.g., performing decompression of the remaining fields except the length field), the length of the length field (because the length of the length field is known to be a fixed value), the size of the decompressed Ethernet header, or the length of the data (e.g., upper layer data or Ethernet frame) to which ROHC header decompression is applied, and then reconstructing the length value (e.g., the length of the data reconstructed by applying ROHC header decompression), and adding 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 if the length field value is different for each data, the sending PDCP layer device can always perform transmission in a state where the length field is omitted (compressed), and the receiving PDCP layer device can calculate the length field value according to the above method so as to always reconstruct the length field value of the Ethernet header.

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

[0356] In the new EHC header, identifiers and bitmap fields indicating multiple Ethernet header compression methods can be defined and used. The identifier can also indicate an Ethernet header type or a QoS flow identifier. Since multiple upper-layer headers (e.g., various types of Ethernet headers) with different header structures are configured by different fields, it is necessary to change the method of field compression or non-compression according to the field type, and the bitmap field corresponding to the field of the upper-layer header type needs to be applied accordingly. Therefore, for example, a first identifier indicating a header type or content can indicate the application of a first bitmap field or bitmap mapping, and a second identifier can indicate the application of a second bitmap field or bitmap mapping. Therefore, if multiple data streams or QoS streams are mapped to one PDCP layer device, different header compression methods can be applied by applying a new identifier, and the receiving terminal can distinguish between compression methods and perform different decompression methods. In this case, 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 value is independently stored in the buffer of the sending PDCP layer device or the buffer of the receiving PDCP layer device.

[0357] Figure 2J The (2-2) specific embodiment of the Ethernet header compression method according to the embodiment of the present disclosure is shown.

[0358] In the (2-2) embodiment of the present disclosure, if multiple data streams or QoS streams are mapped to one bearer or one PDCP layer device, a method for applying a header compression and decompression method according to different data streams or QoS streams having header structures of different upper layer devices is applied.

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

[0360] For example, the transmitting PDCP layer device may store the upper layer header field values ​​of the data having the first upper layer header structure received from the upper layer in the transmitting buffer 2j-15, send data including a complete header (on which compression is not performed during the first transmission), and if feedback indicating successful reception of the complete header information is received from the receiving PDCP layer device, the header compression method may be applied. That is, if all field values ​​of the compressible fields among the upper layer header field values ​​of the data received next time are the same as the field values ​​stored in the transmitting buffer, all compressible fields may be compressed, and the incompressible fields may be configured as is. In addition, an identifier indicating the first upper layer header structure and an indicator indicating that compression has been performed (compression field (C field)) 2j-04 may be configured and sent to a new EHC header.

[0361] If the new EHC header of the received data indicates that the upper layer header is not compressed, the receiving PDCP layer device regards the new EHC header of the received data as a complete upper layer header (if the field values ​​of one or more fields among the compressible fields change, the sending PDCP layer device can send the complete upper layer header without performing compression on the upper layer header to indicate that the field value stored in the buffer of the receiving PDCP layer device will be updated), and can update the field value stored in the buffer 2j-30 of the receiving PDCP layer device with the field value of the received complete upper layer header, and send feedback indicating successful reception to the sending PDCP layer device.

[0362] If the new EHC header of the received data indicates that the upper layer header is compressed, the receiving PDCP layer device checks the identifier indicating the type of the upper layer header included in the new EHC header, and can reconstruct the field defined as compressible in the upper layer header structure indicated by the identifier based on the field value stored in the receiving buffer. For example, the identifier indicating the upper layer header type can indicate a first upper layer header structure (a field that can be compressed and decompressed in the first upper layer header structure), and can indicate a second upper layer header structure (a field that can be compressed and decompressed in the second upper layer header structure).

[0363] In the (2-2) embodiment of the present disclosure, each time an uncompressed complete header is received, the receiving PDCP layer device may always send feedback to the sending PDCP layer device indicating that the complete header is successfully received. In the present disclosure, each time the receiving PDCP layer device receives an uncompressed complete upper layer header, the receiving PDCP layer device may always send feedback to the sending PDCP layer device indicating that the uncompressed complete upper layer header is successfully received. However, when receiving an uncompressed complete upper layer header, the receiving PDCP layer device always sends feedback to the sending PDCP layer device indicating that the uncompressed complete upper layer header is successfully received, but does not send feedback when an uncompressed upper layer header is received. The receiving PDCP layer device performs different operations depending on whether upper layer compression of the received data is performed.

[0364] In addition, in embodiment (2-2), 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 value is independently stored in the buffer of the sending PDCP layer device or the buffer of the receiving PDCP layer device.

[0365] In the new EHC header, an identifier indicating each of a plurality of Ethernet header compression methods and an indicator field indicating whether compression is performed may be defined and used. The identifier may also indicate an Ethernet header type (type) or a QoS flow identifier. This is because a plurality of upper layer headers (e.g., various types of Ethernet headers) with different header structures are configured as different fields, and the method for compressing or not compressing a particular field is applied differently thereto. Thus, for example, a first identifier indicating a header type or content may indicate the application of a first Ethernet header compression method, and a second identifier may indicate the application of a second Ethernet header compression method. Therefore, if a plurality of data streams or QoS streams are mapped to one PDCP layer device, different header compression methods may be applied by applying a new identifier, and the receiving terminal may distinguish between header compression methods and perform different decompression methods.

[0366] When feedback indicating that the complete header is received normally is received from the receiving PDCP layer device, the transmitting PDCP device may start applying the Ethernet compression process. In the above description, multiple complete headers may be sent. For example, multiple complete headers and data (first data, second data, and subsequent data) may be sent until feedback indicating that the complete header is successfully received is received from the receiving PDCP layer device.

[0367] In the new header 2g-10, a new field (e.g., a 1-bit indicator) may be defined to indicate whether the Ethernet header compression process has been performed. The 1-bit indicator may directly indicate that the Ethernet header compression has not been performed, so that the receiving terminal does not perform processing on the new header and the uncompressed upper layer header. If the Ethernet header compression algorithm is configured, the 1-bit indicator may be defined to be located at the very front end of the new EHC header that is always present, so that the receiving terminal may directly check whether 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 an SDAP header or a PDCP header. If a 1-bit indicator is defined in an SDAP header or a PDCP header, overhead may be reduced if the Ethernet header compression process has not been performed, because the new header 2g-10 for Ethernet header compression may be omitted. In addition, a case where the bitmap field is configured to have an all-zero (or all-one) value can be defined and used as a special value indicating an uncompressed complete header, or it can also indicate initializing a buffer for compression of a sending PDCP layer device and a buffer for decompression of a receiving PDCP layer device.

[0368] exist Figure 2GIn the embodiment of the present invention, the PDCP layer device or SDAP layer device in the receiving terminal receives the compressed Ethernet frame 2g-25 from the lower layer device, and if the Ethernet header compression process is configured, the PDCP layer device or SDAP layer device can identify the corresponding field value of the Ethernet header of the Ethernet frame with the first received uncompressed complete header, and store the field value in the buffer for decompressing the received Ethernet. In addition, if the complete header (e.g., SDAP header or Ethernet header) is successfully received, the PDCP layer device or SDAP layer device in the receiving terminal sends feedback related to the successful receipt of the complete header to the sending PDCP layer device to start the application of Ethernet header compression. The PDCP layer device or SDAP layer device in the receiving terminal can send the first Ethernet frame to the upper layer device without decompressing the Ethernet header. Then, if the next Ethernet frame is received, decryption is performed on the next Ethernet frame, and the new EHC header is checked to see whether the header is compressed or uncompressed. If the new EHC header is not compressed, its integrity verification can be performed, the EHC header can be removed, and the data can be sent to the upper layer. If the new EHC header indicates that the Ethernet header (or SDAP header) is compressed, the field values ​​of the new header 2g-10 for Ethernet compression are checked to determine which fields are omitted (compressed) and which fields are not omitted (not compressed). In addition, in the above description, the receiving terminal can reconstruct the value of the field indicated as omitted (compressed) as a field value stored in the receiving buffer so as to reconstruct (decompress) the Ethernet header for decompression before it is compressed. Since the value of the field indicated as not omitted (not compressed) is a new or changed value, the receiving terminal can store the new or changed value as a field value according to the field in the receiving buffer for decompression. In addition, decryption is performed and integrity protection is configured, and integrity verification is performed. If there is no error, the Ethernet frame can be configured with the reconstructed Ethernet header and sent to the upper layer device.

[0369] In the above description, if the field value of the Ethernet header is changed while the sending PDCP layer device applies the Ethernet header compression method, the sending PDCP layer device indicates to the new EHC header that the field value is not compressed, and sends a complete header to initialize the buffer of the receiving terminal, and configures the buffer to have the value of the complete header again. Then, upon receiving the uncompressed complete header, the receiving PDCP layer device may send feedback indicating successful reception of the uncompressed complete header to the sending PDCP layer device. In the present disclosure, each time the receiving PDCP layer device receives the uncompressed complete header, the receiving PDCP layer device may always send feedback indicating successful reception of the uncompressed complete upper layer header to the sending PDCP layer device. In addition, in the present disclosure, upon receiving the uncompressed complete upper layer header, the receiving PDCP layer device may always send feedback indicating successful reception of the uncompressed complete header to the sending PDCP layer device. However, upon receiving the uncompressed upper layer header, the receiving PDCP layer device may not send feedback, and may perform different operations depending on whether the received data is compressed at the upper layer.

[0370] The separate new EHC header may have a fixed size (eg, 1 byte or 2 bytes).

[0371] In the above-mentioned embodiment, the length field of the Ethernet header can also be compressed and decompressed by applying the above-mentioned method. Alternatively, the length field of the Ethernet header can be transmitted without always performing compression thereon.

[0372] According to another method, the length field of the Ethernet header can always be sent without being compressed. After the remaining fields except the length field are decompressed by the receiving PDCP layer device, the PDCP layer device can calculate the length of the Ethernet frame by adding the length of the length field (because the length of the length field is known as a fixed value) to the Ethernet frame, and 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, the sending PDCP layer device can always omit (compress) the length field even if the length field value of each data is different, and transmission is performed, and the receiving PDCP layer device can calculate the length field value according to the above description, and can always reconstruct the length field value of the Ethernet header.

[0373] In addition, in the case where the Ethernet header compression method and ROHC (e.g., TCP / IP header or UDP header compression method) are configured together for the bearer, the length field of the Ethernet header is always sent without being compressed, and the receiving PDCP layer device may first apply the ROHC decompression method to the received data (e.g., PDCP PDU or PDCP SDU), and then apply the Ethernet header decompression method thereto. This is because, in the case where the receiving terminal (e.g., receiving PDCP layer device) reconstructs the length field of the Ethernet header, if the length field is reconstructed as the length of the data to which header compression is applied via ROHC, the length field in the upper layer device (e.g., Ethernet layer device) may be incorrectly reconstructed, resulting in data truncation or an error. Therefore, if the Ethernet header compression method and the ROHC header compression method are configured together, the receiving PDCP layer device may first decompress the upper layer header by applying the ROHC header decompression method, and may decompress the Ethernet header by applying the Ethernet decompression method. In addition, when reconstructing the length field value of the Ethernet header during Ethernet header decompression, the receiving PDCP layer device may use a method of deriving and calculating the length field value by considering the size of the length field (e.g., decompressing the remaining fields except the length field), considering the length of the length field (because the length of the length field is known to be a fixed value), or the size of the decompressed Ethernet header or the length of the data (e.g., upper layer data or Ethernet frame) to which ROHC header decompression is applied, and then reconstructing the length value (e.g., the length of the reconstructed data by applying ROHC header decompression) and adding 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 if the length field value is different for each data, the transmitting PDCP layer device can always perform transmission in a state where the length field is omitted (compressed), and the receiving PDCP layer device can calculate the length field value according to the above method so as to always reconstruct the length field value of the Ethernet header.

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

[0375] The specific (2-3) embodiments of the Ethernet header compression method proposed in the present disclosure are as follows.

[0376] In the (2-3) embodiment of the present disclosure, the header compression and decompression method proposed in the (2-2) embodiment can be applied in the same manner. However, if the base station maps only one data stream or QoS stream to one bearer or one PDCP layer device through an RRC message, it is not necessary to distinguish between data streams or QoS streams with header structures of different upper layer devices. That is, the new EHC header does not need to indicate identifiers of different upper layer header structures or different upper layer compression methods. This is because one upper layer header structure or header compression method can be configured in one PDCP layer device.

[0377] Therefore, in the (2-3) embodiment of the present disclosure, only the field indicating whether the upper layer header is compressed or uncompressed is defined and configured in the new EHC header or PDCP header, and the method proposed in the (2-2) embodiment is applied as is, so that the sending PDCP layer device can perform compression on the upper layer device header, and the receiving PDCP layer device can perform decompression on it.

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

[0379] Figure 2K An embodiment of a feedback structure that can be used in an upper layer header compression method according to an embodiment of the present disclosure is shown.

[0380] refer to Figure 2K , an embodiment proposes new PDCP control data (PDCP control PDU), which is defined by determining a new PDU type field value via a first feedback structure 2k-01. In the case where an upper layer compression and decompression method (or protocol) is configured in the receiving PDCP layer device, each time the upper layer header of the received data is not compressed and a complete upper layer header is received (or if the sending PDCP layer device indicates feedback), new PDCP control data will be triggered and configured, and the new PDCP control data will be sent to the sending PDCP layer device. The new PDCP control data can define an indicator, and through the indicator, indicate the successful receipt or failure to receive the complete upper layer header sent by the sending PDCP layer device without compression. According to another method, the new PDCP control data itself can indicate that the complete upper layer header sent by the sending PDCP layer device without compression has been successfully received. Through the above feedback, the sending PDCP layer device can determine the time point of applying the compression method of the upper layer device.

[0381] If Ethernet decompression fails (for example, if a checksum error occurs), the new PDCP control data can also be used to provide feedback to the transmitting terminal Ethernet compression protocol. That is, the newly defined PDCP control data can indicate that Ethernet decompression has failed (or a checksum error has occurred) and can indicate that initialization of a transmit buffer for Ethernet header compression of the transmitting terminal needs to be performed.

[0382] exist Figure 2K In the embodiment, new PDCP control data (PDCP control PDU) is proposed, which is defined by determining a new PDU type field value via a second feedback structure 2k-02. In the case where the upper layer compression and decompression method (or protocol) is configured in the receiving PDCP layer device, each time the upper layer header of the received data is not compressed and the complete upper layer header is received (or if the sending PDCP layer device indicates feedback), the new PDCP control data will be triggered and configured, and the new PDCP control data will be sent to the sending PDCP layer device. The new PDCP control data can define an indicator, and through the indicator, indicate the successful receipt or failure to receive the complete upper layer header sent by the sending PDCP layer device without compression. According to another method, the new PDCP control data itself can indicate that the complete upper layer header sent by the sending PDCP layer device without compression has been successfully received.

[0383] In addition, by defining and indicating a new field (CTI) for an upper layer header or an upper layer header compression method, the new field (CTI) indicates the type of the upper layer header or the type of the upper layer header compression method, and the new PDCP control data can define an indicator, and indicate the successful reception or failure to receive the complete upper layer header sent by the transmitting PDCP layer device without compression through the indicator. According to another method, for the upper layer header or the upper layer header compression method indicated by the new CTI field, the new PDCP control data itself can indicate the successful reception of the complete upper layer header sent by the transmitting PDCP layer device without compression.

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

[0385] In addition, if Ethernet decompression fails (for example, if a checksum error occurs), the new PDCP control data can also be used to provide feedback to the Ethernet compression protocol of the transmitting terminal. That is, the newly defined PDCP control data can indicate that Ethernet decompression fails (or a checksum error occurs) for a specific upper layer header or upper layer header compression method, and can indicate that initialization of a transmit buffer for Ethernet header compression of the transmitting terminal needs to be performed.

[0386] exist Figure 2K In the embodiment, new PDCP control data (PDCP control PDU) is proposed, which is defined by determining a new PDU type field value via a third feedback structure 2k-03. In the case where the upper layer compression and decompression method (or protocol) is configured in the receiving PDCP layer device, each time the upper layer header of the received data is not compressed and the complete upper layer header is received (or if the sending PDCP layer device indicates feedback), the new PDCP control data will be triggered and configured, and the new PDCP control data will be sent to the sending PDCP layer device. The new PDCP control data can define an indicator, and through the indicator, indicate the successful receipt or failure to receive the complete upper layer header sent by the sending PDCP layer device without compression. According to another method, the new PDCP control data itself can indicate the successful receipt of the complete upper layer header sent by the sending PDCP layer device without compression.

[0387] In addition, a new field (PDCP SN) is defined and indicated to indicate the PDCP sequence number, and for a specific PDCP sequence number, the new PDCP control data may define an indicator and indicate, through the indicator, whether a complete upper layer header sent by the transmitting PDCP layer device without compression is successfully received or not received. According to another method, for the data indicated by the new PDCP sequence number field, the new PDCP control data itself may indicate whether a complete upper layer header sent by the transmitting PDCP layer device without compression is successfully received.

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

[0389] In addition, if Ethernet decompression fails (for example, if a checksum error occurs), the new PDCP control data can also be used to provide feedback to the Ethernet compression protocol of the transmitting terminal. That is, the newly defined PDCP control data can indicate that Ethernet decompression fails (or a checksum error occurs) for a specific PDCP sequence number, and can indicate that initialization of a transmit buffer for Ethernet header compression of the transmitting terminal needs to be performed.

[0390] exist Figure 2KIn the embodiment, new PDCP control data (PDCP control PDU) is proposed, which is defined by determining a new PDU type field value via the fourth feedback structure 2k-04. In the case where the upper layer compression and decompression method (or protocol) is configured in the receiving PDCP layer device, each time the upper layer header of the received data is not compressed and the complete upper layer header is received (or if the sending PDCP layer device indicates feedback), the new PDCP control data will be triggered and configured, and sent to the sending PDCP layer device. The new PDCP control data can define an indicator, and through the indicator, indicate the successful receipt or failure to receive the complete upper layer header sent by the sending PDCP layer device without compression. According to another method, the new PDCP control data itself can indicate the successful receipt of the complete upper layer header sent by the sending PDCP layer device without compression.

[0391] In addition, a new field (PDCP SN) indicating a COUNT value is defined and indicated, and for a specific COUNT value, the new PDCP control data may define an indicator, and the indicator indicates the successful reception or failure to receive the complete upper layer header sent by the transmitting PDCP layer device without compression. According to another method, for the data indicated by the new COUNT value field, the new PDCP control data itself may indicate the successful reception of the complete upper layer header sent by the transmitting PDCP layer device without compression.

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

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

[0394] exist Figure 2KIn the embodiment, the PDCP status report in the PDCP control data (PDCP control PDU) is used as feedback via the fifth feedback structure 2k-05. In the case where the upper layer compression and decompression method (or protocol) is configured in the receiving PDCP layer device, each time the upper layer header of the received data is not compressed and the complete upper layer header is received (or if the sending PDCP layer device indicates feedback), the PDCP status report will be triggered and configured, and the PDCP status report will be sent to the sending PDCP layer device. The PDCP status report can define an indicator and indicate the successful receipt or failure to receive the complete upper layer header sent by the sending PDCP layer device without compression by giving the indicator.

[0395] In addition, via the PDCP status report, for a specific COUNT value, the new PDCP control data itself can indicate that a complete upper layer header sent by the transmitting PDCP layer device without compression has been successfully received, the FMC field indicates a first COUNT value that has not yet been sent from the receiving PDCP layer device to the upper layer, and a subsequent bitmap field can indicate whether a value of "0" or "1" has been successfully received by using one bit mapped to each of the COUNT values ​​greater than the first COUNT value.

[0396] In addition, if an Ethernet decompression failure occurs (for example, if a checksum error occurs), the PDCP status report can also be used to provide feedback to the Ethernet compression protocol of the transmitting terminal. That is, the newly defined PDCP control data can indicate that the Ethernet decompression of data for a specific COUNT value has failed (or a checksum error has occurred), and can indicate that initialization of the transmit buffer for Ethernet header compression of the transmitting terminal needs to be performed. That is, the FMC field indicates the first COUNT value that the receiving PDCP layer device has not yet sent to the upper layer, and the subsequent bitmap field can use one bit to indicate a COUNT value greater than the first COUNT value.

[0397] The present disclosure proposes a sixth feedback structure, through which a new field is defined in a new EHC header or PDCP header of data sent by a receiving PDCP layer device to a sending PDCP layer device and used as feedback. In the case where an upper layer compression and decompression method (or protocol) is configured in the receiving PDCP layer device, a new field of the PDCP header or EHC header is configured each time the upper layer header of the received data is not compressed and a complete upper layer header is received (or if the sending PDCP layer device indicates feedback), and the new header is sent to the sending PDCP layer device. The new field can indicate the successful receipt or failure to receive the complete upper layer header sent by the sending PDCP layer device without compression.

[0398] In a case where a receiving terminal (e.g., a receiving PDCP layer device) uses the first feedback structure, the second feedback structure, the third feedback structure, the fourth feedback structure, the fifth feedback structure, or the sixth feedback structure proposed in the present disclosure to indicate to a transmitting terminal that header decompression has failed or that the receiving terminal has not successfully received data (e.g., an Ethernet frame) with a complete header (e.g., a complete Ethernet header), the transmitting terminal (e.g., the transmitting PDCP layer device) may send data including a complete header to the receiving terminal.

[0399] In the present disclosure, a complete header sent by a transmitting terminal (e.g., a transmitting PDCP layer device) may indicate a header including uncompressed Ethernet header fields and values ​​corresponding to the fields, as well as configuration information for compressing the Ethernet header, for example, an identifier for Ethernet header compression or mapping information for field compression between fields and identifiers (or indicators) may be indicated.

[0400] In the present disclosure, as a method for enabling a transmitting terminal (e.g., a transmitting PDCP layer device) to start an Ethernet header compression process faster, the transmitting PDCP layer device sends a plurality of data with a complete header to a receiving terminal, and, even if the above-mentioned feedback is not received from the receiving terminal (e.g., the receiving PDCP layer device), the transmitting PDCP layer device can apply and start the Ethernet header compression process for the next data and perform transmission. If the RLC layer device connected to the transmitting PDCP layer device operates in AM mode, the data with a complete header will not be lost, and even if the RLC layer device operates in UM mode, a packet copy transmission technology is applied thereto, thereby improving reliability. In the above description, if the transmitting terminal sends a plurality of data with a complete header to the receiving terminal, the number of data to be sent can be configured by an RRC message or can be appropriately configured in the implementation method.

[0401] The present disclosure proposes the operation of a sending PDCP layer device and the operation of a receiving PDCP layer device when the upper layer compression and decompression method (Ethernet header compression method) or ROHC (upper layer compression and decompression method, such as TCP / IP or UDP) proposed in the present disclosure is configured.

[0402] The operation of the sending PDCP layer device of the UE or base station proposed in the present disclosure is as follows.

[0403] The transmitting PDCP layer device uses a first COUNT variable which holds a COUNT value to be allocated to the next transmitted data when processing data, and the first COUNT variable may be referred to as TX_NEXT.

[0404] The operation of the sending PDCP layer device proposed in the present disclosure is as follows.

[0405] - The transmitting PDCP layer device activates a PDCP data discard timer when receiving data (eg, PDCP SDU) from an upper layer, and discards the data if the timer expires.

[0406] - The transmitting PDCP layer device allocates a COUNT value corresponding to TX_NEXT to the data received from the upper layer. TX_NEXT may be configured to be 0 as an initial value, and TX_NEXT holds the COUNT value for the next transmitted data (PDCP SDU).

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

[0408] - If the upper layer header compression protocol (Ethernet Header Compression method, EthHC) is configured for the sending PDCP layer device,

[0409] ■If the data received from the upper layer is the first data received after the Ethernet header compression method is configured,

[0410] ■ Alternatively, if even one field value among the field values ​​of the compressible fields among the fields of the Ethernet header of the data received from the upper layer is different from the field value stored in the buffer of the transmitting PDCP layer device (or different from the Ethernet header field value previously transmitted),

[0411] ■ Alternatively, if no feedback is received from the receiving PDCP layer device indicating successful reception of data with a previously sent uncompressed complete upper layer header (Ethernet header),

[0412] ◆The transmitting PDCP layer device does not perform Ethernet header compression until feedback is received from the receiving PDCP layer device indicating successful reception of the complete uncompressed upper layer header (Ethernet header).

[0413] ■ If feedback is received from the receiving PDCP layer device indicating successful reception of data with a previously transmitted uncompressed complete upper layer header (Ethernet header).

[0414] ◆The transmitting PDCP layer device can perform compression by applying the Ethernet header compression method to the data received from the upper layer.

[0415] -If integrity protection is configured for the transmitting PDCP layer device, a PDCP header may be generated, and integrity protection of the PDCP header and data may be performed using a security key and a COUNT value of TX_NEXT assigned to the data.

[0416] - The encryption process of the data may be performed using the security key and the COUNT value of the TX_NEXT variable assigned to the data. Like the PDCP sequence number, the COUNT value of the TX_NEXT variable is configured with as many lower LSBs as the length of the PDCP sequence number.

[0417] - In addition, the COUNT value of the TX_NEXT variable may be increased by 1, and the above processed data may be concatenated with the PDCP header and sent to the lower layer.

[0418] The operation of the receiving PDCP layer device of the UE or base station proposed in the present disclosure is as follows.

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

[0420] If a PDCP sequence number gap occurs based on the PDCP sequence number in the receiving PDCP layer device, and if data corresponding to the PDCP sequence number gap does not arrive until the PDCP reordering timer expires, the PDCP reordering timer is triggered, data is sent to the upper layer device in ascending order of the PDCP sequence number or COUNT value, and the receiving window is moved. Therefore, if data corresponding to the PDCP sequence number gap arrives after the PDCP reordering timer expires, the data is not data in the receiving window and is therefore discarded.

[0421] The detailed process of the above-mentioned receiving PDCP layer device is briefly described below.

[0422] The receiving PDCP layer device of the UE or base station proposed in the present disclosure operates as follows.

[0423] The receiving PDCP layer device may maintain and manage three COUNT variables when processing received data. The receiving PDCP layer device may use a second COUNT variable (which maintains a COUNT value of data (e.g., PDCP SDU) expected to be received next when processing received data), and the second COUNT variable may be referred to as RX_NEXT. In addition, the receiving PDCP layer device uses a third COUNT variable (which maintains a COUNT value of first data (e.g., PDCP SDU) not sent to an upper layer when processing received data), and the third COUNT variable may be referred to as RX_DELIV. In addition, when processing received data, the receiving PDCP layer device uses a fourth COUNT variable (which maintains a COUNT value of data (e.g., PDCP SDU) by which a PDCP reordering timer (t-Reordering) is triggered), and the fourth COUNT variable may be referred to as RX_REORD. In addition, when processing the received data, the receiving PDCP layer device uses a fifth COUNT variable (which holds the COUNT value of the currently received data (e.g., PDCP SDU)), and the fifth COUNT variable is called RCVD_COUNT. In the above description, the PDCP reordering timer uses a timer value or interval configured through an RRC message in an upper layer (RRC layer), such as Figure 2E As shown, this timer is used to detect lost PDCP PDUs and only one timer can be running at a time.

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

[0425] - HFN: HFN indicates the hyperframe number (HFN) portion of the window state variable.

[0426] -SN: SN indicates the sequence number (SN) portion of the window state variable.

[0427] -RCVD_SN: RCVD_SN indicates the PDCP sequence number included in the header of the received PDCP PDU

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

[0429] The operation of the receiving PDCP layer device of the UE or base station proposed in the present disclosure is as follows.

[0430] If a PDCP PDU is received from a lower layer, the receiving PDCP layer device may determine a COUNT value of the received PDCP PDU as follows.

[0431] - If the received RCVD_SN is RCVD_SN <= SN(RX_DELIV) - Window_Size,

[0432] ■ Update to RCVD_HFN = HFN(RX_DELIV) + 1.

[0433] - Otherwise, if the RCVD_SN is RCVD_SN > SN(RX_DELIV) + Window_Size,

[0434] ■ Update to RCVD_HFN = HFN(RX_DELIV) - 1.

[0435] - If not,

[0436] ■ Update to RCVD_HFN = HFN(RX_DELIV).

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

[0438] After determining the COUNT value of the received PDCP PDU, the receiving PDCP layer device can update the window state variables and process the PDCP PDU as follows.

[0439] - Use the RCVD_COUNT value to decode the PDCP PDU and perform integrity verification.

[0440] ■ If the integrity verification fails,

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

[0442] - If a PDCP PDU in the state of RCVD_COUNT < RX_DELIV or with the RCVD_COUNT value has been received previously (cases of expiration, timeout, out-of-window packets or duplicate packets)

[0443] ■ Discard the received PDCP data PDU (the data part of the PDCP PDU).

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

[0445] - The PDCP SDU processed above can be stored in the receive buffer.

[0446] - If RCVD_COUNT >= RX_NEXT

[0447] ■Update RX_NEXT to RCVD_COUNT+1.

[0448] - if the out-of-order delivery indicator (outOfOrderDelivery) is configured (if out-of-order delivery operation is indicated),

[0449] ■PDCP SDU can be sent to upper layers.

[0450] - If RCVD_COUNT is equal to RX_DELIV,

[0451] ■ If the header decompression process has not been previously applied (even if the Ethernet Header Compression protocol or ROHC is configured) (i.e., no data processing of the upper layer headers has been performed),

[0452] If the Ethernet Header Compression protocol is configured and the Ethernet header is compressed (if the indicator for the new EHC header is checked and indicates that the Ethernet header is compressed),

[0453] ●Decompression of the Ethernet header of the data can be performed.

[0454] ◆ Otherwise, if the Ethernet header compression protocol is configured and the Ethernet header is not compressed (if the indicator of the new EHC header is checked and indicates that the Ethernet header is compressed),

[0455] - The Ethernet header of the data is treated as an uncompressed header and no decompression is performed on it.

[0456] • Since the uncompressed Ethernet header has been successfully received, feedback may be triggered to indicate successful reception to the sending PDC layer device, and feedback may be sent to the sending PDC layer device.

[0457] Otherwise, if Ethernet Header Compression is not configured and ROHC is configured

[0458] ●Decompression of the upper layer header of the data (TCP / IP or UDP header, etc.) can be performed.

[0459] ■The above data can be sent to the upper layer in the order of COUNT value.

[0460] ◆Starting from COUNT = RX_DELIV value, all consecutive PDCP SDUs can be sent to the upper layer.

[0461] ■ Update the RX_DELIV value to the COUNT value of the first PDCP SDU which has a COUNT value greater than or equal to the current RX_DELIV value and is not sent to upper layers.

[0462] - If the t-Reordering timer is running and the RX_DELIV value is greater than or equal to RX_REORD,

[0463] ■Stop and reset the t-Reordering timer.

[0464] - If the t-Reordering timer is not running (including the stopped case under the above conditions), and RX_DELIV is less than RX_NEXT,

[0465] ■Update RX_REORD value to RX_NEXT.

[0466] ■Start the t-Reordering timer.

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

[0468] - If the header decompression process has not been applied before (even if the Ethernet Header Compression protocol or ROHC is configured) (i.e., data processing of upper layer headers has not been performed)

[0469] ■ If the Ethernet header compression protocol is configured and the Ethernet header is compressed (if the indicator for the new EHC header is checked and it indicates that the Ethernet header is compressed),

[0470] ◆Can perform decompression of the Ethernet header of the data.

[0471] ■ Otherwise, if the Ethernet header compression protocol is configured and the Ethernet header is not compressed (if the indicator of the new EHC header is checked and it indicates that the Ethernet header is compressed),

[0472] ◆The Ethernet header of the data is treated as an uncompressed header and no decompression is performed on it.

[0473] ◆Since the uncompressed Ethernet header has been successfully received, feedback can be triggered to indicate its successful reception to the sending PDC layer device, and feedback can be sent to the sending PDC layer device.

[0474] ■ Otherwise, if Ethernet Header Compression is not configured and ROHC is configured

[0475] ◆Can perform decompression of the upper layer header of the data (TCP / IP or UDP header, etc.).

[0476] -Send the above data to the upper layer in the order of COUNT value.

[0477] ■ All PDCP SDUs with a COUNT value less than the RX_REORD value may be transmitted.

[0478] ■ Starting from the value COUNT = RX_REORD, all consecutive PDCP SDUs may be sent to upper layers.

[0479] - The RX_DELIV value is updated to the COUNT value of the first PDCP SDU which has a COUNT value greater than or equal to the current RX_REORD value and is not sent to upper layers.

[0480] - If the RX_DELIV value is less than the RX_NEXT value,

[0481] ■Update the RX_REORD value to the RX_NEXT value.

[0482] ■Start the t-Reordering timer.

[0483] Hereinafter, the present disclosure proposes an aspect in which, if an SDAP layer device or an SDAP header is configured, an Ethernet header compression protocol (or method) is configured, and an ROHC protocol is configured, a PDCP layer device performs encryption and decryption.

[0484] Figure 2L The (2-1) embodiment according to the embodiment of the present disclosure is shown, in which the PDCP layer device effectively performs encryption and decryption when the SDAP layer device or SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured.

[0485] In the (2-1) embodiment, upon receiving an Ethernet frame from an upper layer (21-05), the transmitting SDAP layer device may configure an SDAP header and transmit the SDAP header to a lower layer transmitting PDCP layer device (indicated by reference numeral 21-10). In addition, the transmitting PDCP layer device may perform an Ethernet header compression process on an Ethernet header of an upper layer device other than the SDAP header, and may generate a separate new EHC header. Header compression may be performed on an upper layer device header (e.g., TCP / IP or UDP of an upper layer device) using the ROHC protocol (indicated by reference numerals 21-15 and 21-20).

[0486] For ease of implementation, the compression of the Ethernet header at the front end may be started first, and then the ROHC compression may be performed.

[0487] According to another method, since separate compression methods are applied to different upper layer headers, the Ethernet header compression process and the ROHC header compression process may be performed in parallel to speed up data processing of the UE.

[0488] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing procedure, ROHC compression may be performed first and then Ethernet header compression may be performed.

[0489] Since the EHC header is separately generated by the PDCP layer device, the transmitting PDCP layer device may configure the EHC header before the SDAP header received from the upper layer.

[0490] In the (2-1) embodiment for performing effective encryption, since the UE is configured to encrypt only the ROHC compressed header and the already compressed data, the newly generated EHC header, SDAP header, and compressed Ethernet header (indicated by reference numerals 21-25 and 21-30) for ease of implementation cannot be encrypted. In addition, in the UE implementation, the implementation complexity can be reduced by configuring the PDCP header, EHC header, SDAP header, and compressed Ethernet header together at the front end of the encrypted data for the last time after the encryption process is completed.

[0491] In addition, the encryption process is completed and a PDCP header is generated, and the generated PDCP header is configured before a new EHC header and sent to a lower layer.

[0492] In the (2-1) embodiment of performing effective encryption, when receiving data from the lower layer device, the receiving PDCP layer device can process the unencrypted EHC header, SDAP header and compressed Ethernet header, perform Ethernet decompression, decrypt the remaining ROHC compressed header and data, and perform the ROHC decompression process on them.

[0493] For ease of implementation, the Ethernet header at the front end may be decompressed and ROHC decompression may be performed.

[0494] According to another method, since separate decompression methods are applied to different upper layer headers, the Ethernet header decompression process and the ROHC header decompression process can be performed in parallel to speed up data processing of the UE.

[0495] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing process, the ROHC decompression can be performed first and then the Ethernet header decompression can be performed. In addition, if the receiving PDCP layer device attempts to reconstruct the length field value by calculating and deriving the Ethernet frame size with respect to the length field of the Ethernet header field, the ROHC decompression must be performed first in order to accurately calculate the total Ethernet frame size. Therefore, it is necessary to perform the ROHC decompression process first and then perform the Ethernet decompression process.

[0496] Figure 2M The (2-2) embodiment according to the embodiment of the present disclosure is shown, wherein the PDCP layer device effectively performs encryption and decryption when the SDAP layer device or SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured.

[0497] In the (2-2) embodiment, upon receiving an Ethernet frame from an upper layer (indicated by reference numeral 2m-05), the transmitting SDAP layer device may configure an SDAP header and transmit the SDAP header to a lower layer transmitting PDCP layer device (indicated by reference numeral 2m-10). In addition, the transmitting PDCP layer device may perform an Ethernet header compression process on an Ethernet header of an upper layer device other than the SDAP header, and may generate a separate new EHC header. Header compression may be performed on an upper layer device header (such as TCP / IP or UDP of an upper layer device) using the ROHC protocol (indicated by reference numerals 2m-15 and 2m-20).

[0498] For ease of implementation, the compression of the Ethernet header at the front end may be started first, and then the ROHC compression may be performed.

[0499] According to another method, since separate compression methods are applied to different upper layer headers, the Ethernet header compression process and the ROHC header compression process may be performed in parallel to speed up data processing of the UE.

[0500] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing procedure, ROHC compression may be performed first and then Ethernet header compression may be performed.

[0501] Since the EHC header is separately generated by the PDCP layer device, the transmitting PDCP layer device may configure the EHC header before the SDAP header received from the upper layer.

[0502] In the (2-2) embodiment of performing effective encryption, in order to enhance security, the UE may perform encryption on the compressed Ethernet header, the compressed ROHC compressed header, and the data, and may not perform encryption on the newly generated EHC header and SDAP header (indicated by reference numerals 2m-25 and 2m-30). In addition, in the UE implementation, by configuring the PDCP header, the EHC header, and the SDAP header together at the front end of the encrypted data for the last time after the encryption process is completed, the implementation complexity can be reduced.

[0503] In addition, the encryption process is completed and a PDCP header is generated, and the generated PDCP header is configured before a new EHC header and sent to a lower layer.

[0504] In the (2-2) embodiment of performing effective encryption, when receiving data from the lower layer device, the receiving PDCP layer device can process the unencrypted EHC header and SDAP header, can perform decryption on the remaining compressed Ethernet header, ROHC compressed header and data, and can perform Ethernet decompression and ROHC decompression processes on them.

[0505] For ease of implementation, the Ethernet header at the front end may be decompressed first, and then ROHC decompression may be performed.

[0506] According to another method, since separate decompression methods are applied to different upper layer headers, the Ethernet header decompression process and the ROHC header decompression process can be performed in parallel to speed up data processing of the UE.

[0507] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing process, the ROHC decompression can be performed first and then the Ethernet header decompression can be performed. In addition, if the receiving PDCP layer device attempts to reconstruct the length field value by calculating and deriving the Ethernet frame size with respect to the length field of the Ethernet header field, the ROHC decompression must be performed first in order to accurately calculate the total Ethernet frame size. Therefore, it is necessary to perform the ROHC decompression process first and then perform the Ethernet decompression process.

[0508] In addition, in the case where the Ethernet header compression method and ROHC (e.g., TCP / IP header or UDP header compression method) are configured together for the bearer, the length field of the Ethernet header is always sent without being compressed, and the receiving PDCP layer device may first apply the ROHC decompression method to the received data (e.g., PDCP PDU or PDCP SDU), and then apply the Ethernet header decompression method to the received data. If, in the case where the receiving terminal (e.g., the receiving PDCP layer device) reconstructs the length field of the Ethernet header, the length field is reconstructed as the length of the data to which header compression is applied via ROHC, the length field in the upper layer device (e.g., the Ethernet layer device) may be incorrectly reconstructed, and the data may be truncated or an error may occur. Therefore, if the Ethernet header compression method and the ROHC header compression method are configured together, the receiving PDCP layer device may first decompress the upper layer header by applying the ROHC header decompression method, and may decompress the Ethernet header by applying the Ethernet decompression method. In addition, when reconstructing the length field value of the Ethernet header during Ethernet header decompression, the receiving PDCP layer device may use a method of deriving and calculating the length field value by considering the size of the length field (e.g., decompressing the remaining fields except the length field), considering the length of the length field (because the length of the length field is known to be a fixed value), or the size of the decompressed Ethernet header or the length of the data (e.g., upper layer data or Ethernet frame) to which ROHC header decompression is applied, and then reconstructing the length value (e.g., the length of the data reconstructed by applying ROHC header decompression), and adding 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 if the length field value is different for each data, the sending PDCP layer device can always perform transmission in a state where the length field is omitted (compressed), and the receiving PDCP layer device can calculate the length field value according to the above method so as to always reconstruct the length field value of the Ethernet header.

[0509] Figure 2N The (2-3) embodiment according to the embodiment of the present disclosure is shown, wherein the PDCP layer device effectively performs encryption and decryption when the SDAP layer device or SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured.

[0510] In the (2-3) embodiment, upon receiving an Ethernet frame from an upper layer (indicated by reference numeral 2n-05), the sending SDAP layer device may configure an SDAP header and send the SDAP header to a lower layer sending PDCP layer device (indicated by reference numeral 2n-10). The sending PDCP layer device may perform an Ethernet header compression process on an Ethernet header of an upper layer device other than the SDAP header, and may generate a separate new EHC header. The header compression of an upper layer device header (e.g., TCP / IP or UDP of an upper layer device) is performed using the ROHC protocol (indicated by reference numerals 2n-15 and 2n-20).

[0511] For ease of implementation, the compression of the Ethernet header at the front end may be started first, and then the ROHC compression may be performed.

[0512] According to another method, since separate compression methods are applied to different upper layer headers, the Ethernet header compression process and the ROHC header compression process may be performed in parallel to speed up data processing of the UE.

[0513] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing procedure, ROHC compression may be performed first and then Ethernet header compression may be performed.

[0514] Since the EHC header is separately generated by the PDCP layer device, the transmitting PDCP layer device may configure the EHC header before the SDAP header received from the upper layer.

[0515] In the (2-3) embodiment of performing effective encryption, in order to enhance security, and in order to enhance the security between the sending PDCP layer device and the receiving PDCP layer device by applying the principle of being able to perform encryption on data processed by the PDCP layer device, the UE can perform encryption on the newly generated EHC header, the compressed Ethernet header, the compressed ROHC compressed header and the data, and may not perform encryption on the SDAP header (indicated by the figure marks 2n-25 and 2n-30).

[0516] In addition, the encryption process is completed and a PDCP header is generated, and the generated PDCP header is configured before a new EHC header and sent to a lower layer.

[0517] In the (2-3) embodiment of performing effective encryption, when receiving data from the lower layer device, the receiving PDCP layer device can process the unencrypted SDAP header, can decrypt the remaining EHC header, compressed Ethernet header, ROHC compressed header and data, and can perform Ethernet decompression and ROHC decompression processes on it.

[0518] For ease of implementation, the Ethernet header at the front end may be decompressed first, and then ROHC decompression may be performed.

[0519] According to another method, since separate decompression methods are applied to different upper layer headers, the Ethernet header decompression process and the ROHC header decompression process can be performed in parallel to speed up data processing of the UE.

[0520] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing process, the ROHC decompression can be performed first and then the Ethernet header decompression can be performed. In addition, if the receiving PDCP layer device attempts to reconstruct the length field value by calculating and deriving the Ethernet frame size with respect to the length field of the Ethernet header field, the ROHC decompression must be performed first in order to accurately calculate the total Ethernet frame size. Therefore, it is necessary to perform the ROHC decompression process first and then perform the Ethernet decompression process.

[0521] Fig.2O The (2-4) embodiment according to the embodiment of the present disclosure is shown, wherein the PDCP layer device effectively performs encryption and decryption when the SDAP layer device or SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured.

[0522] In the (2-4) embodiment, upon receiving an Ethernet frame from an upper layer (indicated by reference numeral 2o-05), the sending SDAP layer device may configure an SDAP header and send the SDAP header to a lower layer sending PDCP layer device (indicated by reference numeral 2o-10). In addition, the sending PDCP layer device may perform an Ethernet header compression process on an Ethernet header of an upper layer device other than the SDAP header, and may generate a separate new EHC header. The ROHC protocol may be used to perform header compression on an upper layer device header (e.g., TCP / IP or UDP of an upper layer device) (indicated by reference numerals 2o-15 and 2o-20).

[0523] For ease of implementation, the compression of the Ethernet header at the front end may be started first, and then the ROHC compression may be performed.

[0524] According to another method, since separate compression methods are applied to different upper layer headers, the Ethernet header compression process and the ROHC header compression process may be performed in parallel to speed up data processing of the UE.

[0525] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing procedure, ROHC compression may be performed first and then Ethernet header compression may be performed.

[0526] Since the EHC header is separately generated by the PDCP layer device, the transmitting PDCP layer device may configure the EHC header before the SDAP header received from the upper layer.

[0527] In the (2-4) embodiment of performing effective encryption, in order to enhance security, the UE may perform encryption on the SDAP header, the compressed Ethernet header, the compressed ROHC compressed header, and the data, and may not perform encryption on the newly generated EHC header (indicated by reference numerals 2o-25 and 2o-30). In addition, in the UE implementation, the implementation complexity can be reduced by configuring the PDCP header and the EHC header together at the front end of the encrypted data for the last time after the encryption process is completed.

[0528] In addition, the encryption process is completed and a PDCP header is generated, and the generated PDCP header is configured before a new EHC header and sent to a lower layer.

[0529] In the (2-4) embodiments of performing effective encryption, when receiving data from the lower layer device, the receiving PDCP layer device can process the unencrypted EHC header, can decrypt the remaining SDAP header, compressed Ethernet header, ROHC compressed header and data, and can perform Ethernet decompression and ROHC decompression processes on it.

[0530] For ease of implementation, the Ethernet header at the front end may be decompressed first, and then ROHC decompression may be performed.

[0531] According to another method, since separate decompression methods are applied to different upper layer headers, the Ethernet header decompression process and the ROHC header decompression process can be performed in parallel to speed up data processing of the UE.

[0532] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing process, the ROHC decompression can be performed first and then the Ethernet header decompression can be performed. In addition, if the receiving PDCP layer device attempts to reconstruct the length field value by calculating and deriving the Ethernet frame size with respect to the length field of the Ethernet header field, the ROHC decompression must be performed first in order to accurately calculate the total Ethernet frame size. Therefore, it is necessary to perform the ROHC decompression process first and then perform the Ethernet decompression process.

[0533] Figure 2PThe (2-5) embodiment according to the embodiment of the present disclosure is shown, wherein the PDCP layer device effectively performs encryption and decryption when the SDAP layer device or SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured.

[0534] In the (2-5) embodiment, upon receiving an Ethernet frame from an upper layer (indicated by reference numeral 2p-05), the transmitting SDAP layer device may configure an SDAP header and transmit the SDAP header to a lower layer transmitting PDCP layer device (indicated by reference numeral 2p-10). The transmitting PDCP layer device may perform an Ethernet header compression process on an Ethernet header of an upper layer device other than the SDAP header, and generate a separate new EHC header. The ROHC protocol may be used to perform header compression on an upper layer device header (e.g., TCP / IP or UDP of an upper layer device) (indicated by reference numerals 2p-15 and 2p-20).

[0535] For ease of implementation, the compression of the Ethernet header at the front end may be started first, and then the ROHC compression may be performed.

[0536] According to another method, since separate compression methods are applied to different upper layer headers, the Ethernet header compression process and the ROHC header compression process may be performed in parallel to speed up data processing of the UE.

[0537] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing procedure, ROHC compression may be performed first and then Ethernet header compression may be performed.

[0538] Since the EHC header is separately generated by the PDCP layer device, the transmitting PDCP layer device may configure the EHC header before the SDAP header received from the upper layer.

[0539] In the (2-5) embodiment of performing effective encryption, in order to enhance security, the UE may perform encryption on the newly generated EHC header, SDAP header, compressed Ethernet header, compressed ROHC compression header and data (indicated by reference numerals 2p-25 and 2p-30).

[0540] In addition, the encryption process is completed and a PDCP header is generated, and the generated PDCP header is configured before a new EHC header and sent to a lower layer.

[0541] In the (2-5) embodiment of performing effective encryption, when receiving data from the lower layer device, the receiving PDCP layer device can process the unencrypted PDCP header, can perform decryption on the remaining EHC header, SDAP header, compressed Ethernet header, ROHC compressed header and data, and can perform Ethernet decompression and ROHC decompression processes on it.

[0542] For ease of implementation, the Ethernet header at the front end may be decompressed first, and then ROHC decompression may be performed.

[0543] According to another method, since separate decompression methods are applied to different upper layer headers, the Ethernet header decompression process and the ROHC header decompression process can be performed in parallel to speed up data processing of the UE.

[0544] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing process, the ROHC decompression can be performed first and then the Ethernet header decompression can be performed. In addition, if the receiving PDCP layer device attempts to reconstruct the length field value by calculating and deriving the Ethernet frame size with respect to the length field of the Ethernet header field, the ROHC decompression must be performed first in order to accurately calculate the total Ethernet frame size. Therefore, it is necessary to perform the ROHC decompression process first and then perform the Ethernet decompression process.

[0545] Figure 2Q The (2-6) embodiment according to the embodiment of the present disclosure is shown, wherein the PDCP layer device effectively performs encryption and decryption when the SDAP layer device or SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured.

[0546] In the (2-6) embodiment, upon receiving an Ethernet frame from an upper layer (indicated by reference numeral 2q-05), the transmitting SDAP layer device may configure an SDAP header and transmit the SDAP header to a lower layer transmitting PDCP layer device (indicated by reference numeral 2q-10). The transmitting PDCP layer device may perform an Ethernet header compression process on an Ethernet header of an upper layer device other than the SDAP header, and may generate a separate new EHC header. The ROHC protocol may be used to perform header compression on an upper layer device header (e.g., TCP / IP or UDP of an upper layer device) (indicated by reference numerals 2q-15 and 2q-20).

[0547] For ease of implementation, the compression of the Ethernet header at the front end may be started first, and then the ROHC compression may be performed.

[0548] According to another method, since separate compression methods are applied to different upper layer headers, the Ethernet header compression process and the ROHC header compression process may be performed in parallel to speed up data processing of the UE.

[0549] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing procedure, ROHC compression may be performed first and then Ethernet header compression may be performed.

[0550] Since the EHC header is separately generated by the PDCP layer device, the transmitting PDCP layer device may configure the EHC header before the SDAP header received from the upper layer.

[0551] In the (2-6) embodiment for performing effective encryption, in order to improve the compression rate, the UE is characterized in that an Ethernet header compression process is applied to the SDAP header and the Ethernet header to perform compression. In addition, the encryption process may not be applied to the EHC header and the compressed SDAP / Ethernet header, and the encryption process may be performed on the compressed ROHC compressed header and data (indicated by reference numerals 2q-25 and 2q-30). In addition, in the UE implementation, the implementation complexity can be reduced by configuring the PDCP header, the EHC header, and the compressed SDAP / Ethernet header together at the front end of the encrypted data for the last time after the encryption process is completed. In addition, since the existing UE is implemented to encrypt only the ROHC compressed header and data, the implementation complexity can be reduced.

[0552] In addition, the encryption process is completed and a PDCP header is generated, and the generated PDCP header is configured before a new EHC header and sent to a lower layer.

[0553] In the (2-6) embodiment of performing effective encryption, when receiving data from the lower layer device, the receiving PDCP layer device can process the unencrypted EHC header, can decompress the compressed SDAP / Ethernet header, can perform decryption on the remaining ROHC compressed header and data, and can perform Ethernet decompression and ROHC decompression processes.

[0554] For ease of implementation, the Ethernet header at the front end may be decompressed first, and then ROHC decompression may be performed.

[0555] According to another method, since separate decompression methods are applied to different upper layer headers, the Ethernet header decompression process and the ROHC header decompression process can be performed in parallel to speed up data processing of the UE.

[0556] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing process, the ROHC decompression can be performed first and then the Ethernet header decompression can be performed. In addition, if the receiving PDCP layer device attempts to reconstruct the length field value by calculating and deriving the Ethernet frame size with respect to the length field of the Ethernet header field, the ROHC decompression must be performed first in order to accurately calculate the total Ethernet frame size. Therefore, it is necessary to perform the ROHC decompression process first and then perform the Ethernet decompression process.

[0557] Figure 2R The (2-7) embodiment according to the embodiment of the present disclosure is shown, wherein the PDCP layer device effectively performs encryption and decryption when the SDAP layer device or SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured.

[0558] In the embodiment (2-7), the encryption method of the embodiment (2-6) can be applied, and in order to enhance security, the compressed SDAP / Ethernet header can also be encrypted and decrypted.

[0559] Figure 2S The (2-8) embodiment according to the embodiment of the present disclosure is shown, wherein the PDCP layer device effectively performs encryption and decryption when the SDAP layer device or SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured.

[0560] In the (2-8) embodiment, the encryption method of the (2-6) embodiment may be applied, and in order to enhance security, the compressed SDAP / Ethernet header and EHC header may also be encrypted and decrypted.

[0561] Figure 2T The (2-9) embodiment according to the embodiment of the present disclosure is shown, wherein the PDCP layer device effectively performs encryption and decryption when the SDAP layer device or SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured.

[0562] In the (2-9) embodiment, upon receiving an Ethernet frame from an upper layer (indicated by reference numeral 2t-05), the sending SDAP layer device may configure an SDAP header and send the SDAP header to a lower layer sending PDCP layer device (indicated by reference numeral 2t-10). The sending PDCP layer device may perform an Ethernet header compression process on an Ethernet header of an upper layer device other than the SDAP header, and may generate a separate new EHC header. The ROHC protocol may be used to perform header compression on an upper layer device header (e.g., TCP / IP or UDP of an upper layer device) (indicated by reference numerals 2t-15 and 2t-20).

[0563] For ease of implementation, the compression of the Ethernet header at the front end may be started first, and then the ROHC compression may be performed.

[0564] According to another method, since separate compression methods are applied to different upper layer headers, the Ethernet header compression process and the ROHC header compression process may be performed in parallel to speed up data processing of the UE.

[0565] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing procedure, ROHC compression may be performed first and then Ethernet header compression may be performed.

[0566] In the present disclosure, even if the EHC header is generated separately by the PDCP layer device, since the EHC header is data generated by the Ethernet compression process in the PDCP layer device, the sending PDCP layer device regards the EHC header as part of the PDCP data (PDCP SDU) and allows the EHC header to be placed after the SDAP header.

[0567] In the (2-9) embodiment for performing effective encryption, the UE may perform encryption on the compressed ROHC compressed header and data, and may not perform encryption on the SDAP header, the newly generated EHC header, and the compressed Ethernet header (indicated by reference numerals 2t-25 and 2t-30). In addition, in the UE implementation, the implementation complexity may be reduced by configuring the PDCP header, SDAP header, EHC header, and compressed Ethernet header together at the front end of the encrypted data for the last time after the encryption process is completed.

[0568] In addition, a PDCP header is generated after the encryption process is completed, and the generated PDCP header is configured before the new SDAP header and sent to the lower layer.

[0569] In the (2-9) embodiment of performing effective encryption, when receiving data from the lower layer device, the receiving PDCP layer device can process the unencrypted SDAP header, the newly generated EHC header and the compressed Ethernet header, can perform the Ethernet header decompression process, can perform decryption of the remaining ROHC compressed header and data, and can perform the ROHC decompression process.

[0570] For ease of implementation, the Ethernet header at the front end may be decompressed first, and then ROHC decompression may be performed.

[0571] According to another method, since separate decompression methods are applied to different upper layer headers, the Ethernet header decompression process and the ROHC header decompression process can be performed in parallel to speed up data processing of the UE.

[0572] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing process, the ROHC decompression can be performed first and then the Ethernet header decompression can be performed. In addition, if the receiving PDCP layer device attempts to reconstruct the length field value by calculating and deriving the Ethernet frame size with respect to the length field of the Ethernet header field, the ROHC decompression must be performed first in order to accurately calculate the total Ethernet frame size. Therefore, it is necessary to perform the ROHC decompression process first and then perform the Ethernet decompression process.

[0573] Figure 2U The (2-10) embodiment according to the embodiment of the present disclosure is shown, wherein the PDCP layer device effectively performs encryption and decryption when the SDAP layer device or SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured.

[0574] In the (2-10) embodiment, upon receiving an Ethernet frame from an upper layer (indicated by reference numeral 2u-05), the sending SDAP layer device may configure an SDAP header and send the SDAP header to a lower layer sending PDCP layer device (indicated by reference numeral 2u-10). The sending PDCP layer device may perform an Ethernet header compression process on an Ethernet header of an upper layer device other than the SDAP header, and may generate a separate new EHC header. The ROHC protocol may be used to perform header compression on an upper layer device header (e.g., TCP / IP or UDP of an upper layer device) (indicated by reference numerals 2u-15 and 2u-20).

[0575] For ease of implementation, the compression of the Ethernet header at the front end may be started first, and then the ROHC compression may be performed.

[0576] According to another method, since separate compression methods are applied to different upper layer headers, the Ethernet header compression process and the ROHC header compression process may be performed in parallel to speed up data processing of the UE.

[0577] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing procedure, ROHC compression may be performed first and then Ethernet header compression may be performed.

[0578] In the present disclosure, even if the EHC header is generated separately by the PDCP layer device, since the EHC header is data generated by the Ethernet compression process in the PDCP layer device, the sending PDCP layer device regards the EHC header as part of the PDCP data (PDCP SDU) and allows the EHC header to be placed after the SDAP header.

[0579] In the (2-10) embodiment for performing effective encryption, the UE may perform encryption on the compressed Ethernet header, the compressed ROHC compressed header, and the data, and may not perform encryption on the SDAP header and the newly generated EHC header (indicated by reference numerals 2u-25 and 2u-30). In addition, in the UE implementation, the implementation complexity may be reduced by configuring the PDCP header, the SDAP header, and the EHC header together at the front end of the encrypted data for the last time after the encryption process is completed.

[0580] In addition, a PDCP header may be generated after the encryption process is completed, and the generated PDCP header may be configured before the SDAP header and sent to a lower layer.

[0581] In the (2-10) embodiment of performing effective encryption, when receiving data from the lower layer device, the receiving PDCP layer device can process the unencrypted SDAP header and the newly generated EHC header, can perform decryption of the remaining compressed Ethernet header, ROHC compressed header and data, and can perform Ethernet decompression and ROHC decompression processes.

[0582] For ease of implementation, the Ethernet header at the front end may be decompressed first, and then ROHC decompression may be performed.

[0583] According to another method, since separate decompression methods are applied to different upper layer headers, the Ethernet header decompression process and the ROHC header decompression process can be performed in parallel to speed up data processing of the UE.

[0584] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing process, the ROHC decompression can be performed first and then the Ethernet header decompression can be performed. In addition, if the receiving PDCP layer device attempts to reconstruct the length field value by calculating and deriving the Ethernet frame size with respect to the length field of the Ethernet header field, the ROHC decompression must be performed first in order to accurately calculate the total Ethernet frame size. Therefore, it is necessary to perform the ROHC decompression process first and then perform the Ethernet decompression process.

[0585] Figure 2V The (2-11) embodiment according to the embodiment of the present disclosure is shown, wherein the PDCP layer device effectively performs encryption and decryption when the SDAP layer device or SDAP header is configured, the Ethernet header compression protocol (or method) is configured, and the ROHC protocol is configured.

[0586] In the (2-11) embodiment, upon receiving an Ethernet frame from an upper layer (indicated by reference numeral 2v-05), the sending SDAP layer device may configure an SDAP header and send the SDAP header to a lower layer sending PDCP layer device (indicated by reference numeral 2v-10). The sending PDCP layer device may perform an Ethernet header compression process on an Ethernet header of an upper layer device other than the SDAP header, and may generate a separate new EHC header. The ROHC protocol is used to perform header compression on an upper layer device header (e.g., TCP / IP or UDP of an upper layer device) (indicated by reference numerals 2v-15 and 2v-20).

[0587] For ease of implementation, the compression of the Ethernet header at the front end may be started first, and then the ROHC compression may be performed.

[0588] According to another method, since separate compression methods are applied to different upper layer headers, the Ethernet header compression process and the ROHC header compression process may be performed in parallel to speed up data processing of the UE.

[0589] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing procedure, ROHC compression may be performed first and then Ethernet header compression may be performed.

[0590] In the present disclosure, even if the EHC header is generated separately by the PDCP layer device, since the EHC header is data generated by the Ethernet compression process in the PDCP layer device, the sending PDCP layer device regards the EHC header as part of the PDCP data (PDCP SDU) and allows the EHC header to be placed after the SDAP header.

[0591] In the (2-11) embodiment for performing effective encryption, the UE may perform encryption on the newly generated EHC header, the compressed Ethernet header, the compressed ROHC compressed header, and the data, and may not perform encryption on the SDAP header (indicated by reference numerals 2v-25 and 2v-30). In addition, in the UE implementation, the implementation complexity may be reduced by configuring the PDCP header and the SDAP header together at the front end of the encrypted data for the last time after the encryption process is completed.

[0592] In addition, a PDCP header may be generated after completing the encryption process, and the generated PDCP header may be configured before the SDAP header and sent to a lower layer.

[0593] In the (2-11) embodiment for performing effective encryption, when receiving data from the lower layer device, the receiving PDCP layer device can process the unencrypted SDAP header, can perform decryption on the remaining newly generated EHC header, compressed Ethernet header, ROHC compressed header and data, and can perform Ethernet decompression and ROHC decompression processes on them.

[0594] For ease of implementation, the Ethernet header at the front end may be decompressed first, and then ROHC decompression may be performed.

[0595] According to another method, since separate decompression methods are applied to different upper layer headers, the Ethernet header decompression process and the ROHC header decompression process can be performed in parallel to speed up data processing of the UE.

[0596] According to another method, since the ROHC protocol is an already implemented algorithm and has been implemented as part of the PDCP data processing process, the ROHC decompression can be performed first and then the Ethernet header decompression can be performed. In addition, if the receiving PDCP layer device attempts to reconstruct the length field value by calculating and deriving the Ethernet frame size with respect to the length field of the Ethernet header field, the ROHC decompression must be performed first in order to accurately calculate the total Ethernet frame size. Therefore, it is necessary to perform the ROHC decompression process first and then perform the Ethernet decompression process.

[0597] In an embodiment where the SDAP header is not encrypted, if the base station implements a CU-DU separation structure and only implements from the DU to the RLC layer device, because if the SDAP header is encrypted, the DU may not check the QoS of the SDAP header, in order to easily utilize QoS in scheduling, the DU may not perform encryption of the SDAP header.

[0598] In the case where the SDAP layer device or the SDAP header is not configured in the present disclosure, the method of the above-mentioned embodiment from which the SDAP header is excluded may be equally applied to the present disclosure.

[0599] Furthermore, in the case where the ROHC protocol is not configured in the present disclosure, the methods of the embodiments from which the ROHC header compression process is excluded may be equally applied to these embodiments.

[0600] The embodiments proposed in the present disclosure can be applied not only to Ethernet headers but also to headers of other upper layer devices that can be configured in the upper layer of the PDCP layer device. Therefore, the present disclosure does not propose an Ethernet header compression method limited to the Ethernet header, where the Ethernet header is described as an embodiment, but the present disclosure proposes a method for compressing and decompressing an upper layer header, which can be applied to the header of an upper layer device (other application layer devices) of the PDCP layer device.

[0601] In the following description, if an RRC message (such as Figure 2E 2e-10, 2e-40 or 2e-75), the SDAP layer device is configured to use or the SDAP header is configured to use, and if Ethernet header compression (EHC) is configured, the present disclosure proposes a method for efficiently processing SDAP control data when a sending PDCP layer device receives SDAP control data from an upper layer device (e.g., an SDAP layer device).

[0602] In the present disclosure, SDAP control data may have the same structure as the uplink SDAP header. The SDAP control data structure is SDAP control data indicating that the data flow corresponding to the QoS flow ID (QFI) field value has ended or the last SDAP control data of the field indicating the QFI, and may be referred to as end marker control data (end marker control PDU).

[0603] In the following description, if an RRC message (such as Figure 2E 2e-10, 2e-40 or 2e-75), the SDAP layer device is configured to use or the SDAP header is configured to use, and if Ethernet header compression (EHC) is configured, the present disclosure proposes a method for efficiently processing SDAP control data when a sending PDCP layer device receives SDAP control data from an upper layer device (e.g., an SDAP layer device).

[0604] In the present disclosure, if an SDAP layer device is configured or an SDAP header is configured through an RRC message, the following proposes a (2-12) embodiment for effectively performing an Ethernet header compression method and processing SDAP control data.

[0605] In the (2-12)th embodiment, the Ethernet header compression method is not applied to the SDAP control data, and the SDAP control data is not encrypted, and the EHC header is not encrypted. Therefore, the QoS information of the SDAP header can be utilized without the need for the transmitting terminal or the receiving terminal to perform decryption on the information of the SDAP control data. In addition, since the EHC header is not encrypted, the receiving PDCP layer device can check that the SDAP control data is not compressed through the 1-bit indicator of the EHC header, and the decryption process can be not applied because the SDAP control data is not encrypted, and the SDAP control data can be processed quickly. For example, in the case of a base station, the QoS information can be used for scheduling, and in the UE implementation, the decryption process does not need to be performed each time the SDAP control data is received, and if integrity protection is configured, integrity protection is performed, and the EHC header and the PDCP header can be generated, concatenated, and transmitted to the lower layer so that the UE implementation can be easily performed for fast data processing. In the (2-12) embodiment of the present disclosure, the EHC header is placed before the SDAP control data, so that the PDCP PDU structure configures data in the order of the PDCP header, the EHC header, and the SDAP control data. Since the EHC header is generated by the PDCP layer device, it may be efficient for the UE implementation to place the EHC header before the SDAP control data generated by the SDAP layer device, which is a logically upper layer device. Therefore, in the (2-12) embodiment, the EHC header may be placed before the SDAP control data, so that the embodiment has a structure of cascading the EHC header and the SDAP control data.

[0606] Specifically, if the SDAP layer device is configured to use or the SDAP header is configured to use through the RRC message, and if Ethernet header compression (EHC) is configured, when receiving SDAP control data from the upper layer, the sending PDCP layer device does not perform the Ethernet header compression process on the SDAP control data received from the upper layer (SDAP layer device). In addition, the sending PDCP layer device can calculate the checksum field and generate an EHC header (indicated by reference numeral 2s-15) by configuring whether to apply the EHC header and attaching the EHC header before the SDAP control data. If integrity protection is configured, integrity protection will be applied to the PDCP header, EHC header, and SDAP control data before performing the encryption process, and then encryption of the EHC header and SDAP control data will not be performed. In addition, the PDCP header can be configured at the very front of the data, cascaded and transmitted to the lower layer device.

[0607] In the present disclosure, if an SDAP layer device is configured or an SDAP header is configured through an RRC message, the following proposes a (2-13) embodiment for effectively performing an Ethernet header compression method and processing SDAP control data.

[0608] In the (2-13)th embodiment, the Ethernet header compression method is not applied to the SDAP control data, and the SDAP control data is not encrypted, and the EHC header is not encrypted. Therefore, the QoS information of the SDAP header can be utilized without the need for the transmitting terminal or the receiving terminal to perform decryption on the information of the SDAP control data. In addition, since the EHC header is not encrypted, the receiving PDCP layer device can check that the SDAP control data is not compressed through the 1-bit indicator of the EHC header, and the decryption process can be not applied because the SDAP control data is not encrypted, and the SDAP control data can be processed quickly. For example, in the case of a base station, the QoS information can be used for scheduling, and in the UE implementation, the decryption process does not need to be performed each time the SDAP control data is received. If integrity protection is configured, integrity protection is performed, and the EHC header and the PDCP header can be generated, concatenated, and transmitted to the lower layer so that the UE implementation can be easily performed for fast data processing. In the (2-13) embodiment of the present disclosure, the EHC header is placed after the SDAP control data, so that the PDCP PDU structure configures data in the order of the PDCP header, SDAP control data, and the EHC header. Since the EHC process is the first in the processing process of the PDCP layer device, the EHC header is generated first, and the SDAP control data received from the upper layer is placed before the EHC header for UE implementation. Therefore, in the (2-13) embodiment, the SDAP control data can be placed before the EHC header, so that the embodiment has a structure of cascading SDAP control data and EHC header.

[0609] Specifically, if an RRC message (such as Figure 2E2e-10, 2e-40 or 2e-75), the SDAP layer device is configured to use or the SDAP header is configured to use, and if Ethernet header compression (EHC) is configured, when receiving SDAP control data from the upper layer, the sending PDCP layer device does not perform the Ethernet header compression process on the SDAP control data received from the upper layer (SDAP layer device). In addition, the sending PDCP layer device can calculate the checksum field and generate an EHC header by configuring whether to apply the EHC header and attaching the EHC header after the SDAP control data. If integrity protection is configured, integrity protection will be applied to the PDCP header, SDAP control data, and EHC header before the encryption process is performed, and then encryption of the SDAP control data and the EHC header is not performed. In addition, the PDCP header can be configured at the very front of the data, cascaded and transmitted to the lower layer device.

[0610] In the present disclosure, if an SDAP layer device is configured or an SDAP header is configured through an RRC message, the following proposes a (2-14) embodiment for effectively performing an Ethernet header compression method and processing SDAP control data.

[0611] In the (2-14) embodiment, the Ethernet header compression method is not applied to the SDAP control data, and the SDAP control data is not encrypted, and the EHC header is encrypted. Therefore, the QoS information of the SDAP header can be utilized without the need for the transmitting terminal or the receiving terminal to perform decryption on the information of the SDAP control data. In addition, since the EHC header is encrypted, the receiving PDCP layer device can distinguish the data generated due to the attack as a decryption failure, and the security can be enhanced. After decrypting the EHC header, the receiving PDCP layer device can check that the SDAP control data is not compressed by the 1-bit indicator of the EHC header, and the decryption process can be not applied because the SDAP control data is not encrypted, and the SDAP control data can be processed quickly. For example, in the case of a base station, the QoS information can be used for scheduling, and in the UE implementation, the decryption process does not need to be performed each time the SDAP control data is received, and if integrity protection is configured, integrity protection is performed, and the PDCP header is generated by decrypting only the EHC header, the PDCP header is cascaded and transmitted to the lower layer, so that the UE implementation can be easily performed for fast data processing. In the (2-14) embodiment of the present disclosure, the EHC header is placed before the SDAP control data, so that the PDCP PDU structure configures data in the order of the PDCP header, the EHC header, and the SDAP control data. Since the EHC header is generated by the PDCP layer device, it may be efficient for the UE implementation to place the EHC header before the SDAP control data generated by the SDAP layer device, which is a logically upper layer device. Therefore, in the (2-14) embodiment, the EHC header may be placed before the SDAP control data, so that the embodiment has a structure of cascading the EHC header and the SDAP control data.

[0612] Specifically, if an RRC message (such as Figure 2E 2e-10, 2e-40 or 2e-75), the SDAP layer device is configured to use or the SDAP header is configured to use, and if Ethernet header compression (EHC) is configured, when receiving SDAP control data from the upper layer, the sending PDCP layer device does not perform the Ethernet header compression process on the SDAP control data received from the upper layer (SDAP layer device). In addition, the sending PDCP layer device can calculate the checksum field and generate an EHC header by configuring whether to apply the EHC header and attaching the EHC header before the SDAP control data. If integrity protection is configured, integrity protection will be applied to the PDCP header, SDAP control data, and EHC header before the encryption process is performed, and then encryption of the EHC header is performed without encryption of the SDAP control data. In addition, the PDCP header can be configured at the very front of the data, cascaded and transmitted to the lower layer device.

[0613] In the present disclosure, if an SDAP layer device is configured or an SDAP header is configured through an RRC message, the following proposes a (2-15) embodiment for effectively performing an Ethernet header compression method and processing SDAP control data.

[0614] In the (2-15) embodiment, the Ethernet header compression method is not applied to the SDAP control data, and the SDAP control data is not encrypted, and the EHC header is encrypted. Therefore, the QoS information of the SDAP header can be utilized without the need for the transmitting terminal or the receiving terminal to perform decryption on the information of the SDAP control data. In addition, since the EHC header is encrypted, the receiving PDCP layer device can distinguish the data generated due to the attack as a decryption failure, and security can be enhanced. After decrypting the EHC header, the receiving PDCP layer device can check that the SDAP control data is not compressed by the 1-bit indicator of the EHC header, and the decryption process can be not applied because the SDAP control data is not encrypted, and the SDAP control data can be processed quickly. For example, in the case of a base station, the QoS information can be used for scheduling, and in the UE implementation, it is not necessary to perform the decryption process each time the SDAP control data is received, if integrity protection is configured, integrity protection is performed, and the EHC header can be encrypted immediately, and the PDCP header can be generated, cascaded and transmitted to the lower layer so that the UE implementation can be easily performed for fast data processing. In the (2-15) embodiment of the present disclosure, the EHC header is placed after the SDAP control data, so that the PDCP PDU structure configures data in the order of the PDCP header, SDAP control data, and the EHC header. Since the EHC process is the first in the processing process of the PDCP layer device, the EHC header is generated first, and the SDAP control data received from the upper layer is placed before the EHC header for UE implementation. Therefore, in the (2-15) embodiment, the SDAP control data can be placed before the EHC header, so that the embodiment has a structure of cascading SDAP control data and EHC header.

[0615] Specifically, if an RRC message (such as Figure 2E2e-10, 2e-40 or 2e-75), the SDAP layer device is configured to use or the SDAP header is configured to use, and if Ethernet header compression (EHC) is configured, when receiving SDAP control data from the upper layer, the sending PDCP layer device does not perform the Ethernet header compression process on the SDAP control data received from the upper layer (SDAP layer device). In addition, the sending PDCP layer device can calculate the checksum field and generate an EHC header by configuring whether to apply the EHC header and attaching the EHC header after the SDAP control data. If integrity protection is configured, integrity protection is applied to the PDCP header, SDAP control data, and EHC header before performing the encryption process, and then encryption of the SDAP control data is not performed, and encryption of the EHC header is performed. In addition, the PDCP header can be configured at the very front of the data, cascaded and transmitted to the lower layer device.

[0616] In the present disclosure, if an SDAP layer device is configured or an SDAP header is configured through an RRC message, the following proposes a (2-16) embodiment for effectively performing an Ethernet header compression method and processing SDAP control data.

[0617] In the (2-16)th embodiment, the Ethernet header compression method is not applied to the SDAP control data, the SDAP control data is not encrypted, and the SDAP control data can be indicated by a 1-bit indicator of the PDCP header without generating an EHC header, or the 1-bit indicator can indicate that there is no EHC header. Due to the above characteristics, the overhead can be reduced. In addition, the sending PDCP layer device may not need to generate an EHC header unnecessarily, and because there is no EHC header, the receiving PDCP layer device can immediately check the 1-bit indicator of the PDCP header, and because the SDAP control data is not encrypted, the receiving PDCP layer device performs fast processing of the SDAP control data without applying the decryption process. For example, in the case of a base station, QoS information can be used for scheduling, and in the UE implementation, there is no need to perform a decryption process each time the SDAP control data is received, if integrity protection is configured, integrity protection is performed, and the EHC header can be encrypted immediately, and the PDCP header can be generated, cascaded and transmitted to the lower layer so that the UE implementation can be easily performed for fast data processing. In addition, the embodiment (2-16) of the present disclosure proposes a process for processing SDAP control data without an EHC header so that the PDCP PDU structure configures data in the order of the PDCP header and the SDAP control data. In addition, when processing the SDAP control data received from the upper layer, the embodiment (2-16) includes a structure for cascading the PDCP header before the SDAP control data.

[0618] Specifically, if an RRC message (such as Figure 2E 2e-10, 2e-40 or 2e-75 in), the SDAP layer device is configured to use or the SDAP header is configured to use, and if Ethernet header compression (EHC) is configured, when receiving SDAP control data from the upper layer, the sending PDCP layer device does not perform the Ethernet header compression process on the SDAP control data received from the upper layer (SDAP layer device). In addition, the sending PDCP layer device may not generate an EHC header for the SDAP control data. In addition, if integrity protection is configured, integrity protection is applied to the PDCP header and SDAP control data before the encryption process is performed, and then encryption of the SDAP control data is not performed. In addition, the PDCP header can be configured at the very front of the SDAP control data, cascaded and transmitted to the lower layer device.

[0619] The 1-bit indicator of the PDCP header proposed in the (2-16) embodiment of the present disclosure has the function of indicating the presence or absence of the EHC header, and can be extended and applied to the (2-1) embodiment, the (2-2) embodiment, the (2-3) embodiment, the (2-4) embodiment, the (2-5) embodiment, the (2-6) embodiment, the (2-7) embodiment, the (2-8) embodiment, the (2-9) embodiment, the (2-10) embodiment or the (2-11) embodiment, therefore, if the user compression process is not applied to the SDAP header and data received from the upper layer, the EHC header is omitted, and the 1-bit indicator of the PDCP header can indicate that the EHC header is not attached, thereby reducing overhead.

[0620] In the following description, the present disclosure proposes an operation in a PDCP layer device of a UE or a base station, wherein the UE or the base station performs different data processing by distinguishing between a case where a sending or receiving PDCP layer device receives an SDAP header and upper layer data from an upper layer device or a lower layer device, and a case where a sending PDCP layer device or a receiving PDCP layer device receives SDAP control data.

[0621] -exist Figure 2E In the case of an SDAP layer device configured to use or an SDAP header configured to use, via an RRC message (such as 2e-10, 2e-40, 2e-75), and if Ethernet Header Compression (EHC) is configured,

[0622] ■If the data (e.g., PDCP SDU) received from an upper layer device (SDAP layer device) includes an SDAP header and upper layer data, or if the data is not SDAP control data,

[0623] ◆The sending PDCP layer device can perform the process of embodiment (2-1), embodiment (2-2), embodiment (2-3), embodiment (2-4), embodiment (2-5), embodiment (2-6), embodiment (2-7), embodiment (2-8), embodiment (2-9), embodiment (2-10) or embodiment (2-11) of the present disclosure.

[0624] ■If the data (e.g., PDCP SDU) received from the upper layer device (SDAP layer device) does not include the SDAP header and upper layer data, or if the data is SDAP control data,

[0625] ◆The sending PDCP layer device can perform the process of embodiment (2-12), embodiment (2-13), embodiment (2-14), embodiment (2-15) or embodiment (2-16) of the present disclosure.

[0626] ■ If the data (e.g., PDCP PDU) received from the lower layer device (RLC layer device) includes an SDAP header and upper layer data, or if the data is not SDAP control data,

[0627] ◆The receiving PDCP layer device can perform the process of embodiment (2-1), embodiment (2-2), embodiment (2-3), embodiment (2-4), embodiment (2-5), embodiment (2-6), embodiment (2-7), embodiment (2-8), embodiment (2-9), embodiment (2-10) or embodiment (2-11) of the present disclosure.

[0628] ■If the data (e.g., PDCP PDU) received from the lower layer device (RLC layer device) does not include the SDAP header and upper layer data, or if the data is SDAP control data,

[0629] ◆The receiving PDCP layer device may perform the process of the embodiment (2-12), the embodiment (2-13), the embodiment (2-14), the embodiment (2-15) or the embodiment (2-16) of the present disclosure.

[0630] As described above, if a header or data compression method is configured in a PDCP layer device through an RRC message, the present disclosure proposes an effective method for processing an SDAP header or SDAP control data. In particular, a method for considering whether to perform encryption or a header position and a new header generated by a header or data compression method configured in a PDCP layer device has been specifically proposed. The specific embodiments proposed in the present disclosure (the (2-1) embodiment, the (2-2) embodiment, the (2-3) embodiment, the (2-4) embodiment, the (2-5) embodiment, the (2-6) embodiment, the (2-7) embodiment, the (2-8) embodiment, the (2-9) embodiment, the (2-10) embodiment, the (2-11) embodiment, the (2-12) embodiment, the (2-13) embodiment, the (2-14) embodiment, the (2-15) embodiment or the (2-16) embodiment) can be extended and applied to the case where a new compression method is introduced and configured in a PDCP layer device. If another new header is generated due to a new compression method, the embodiments of the present disclosure considering whether encryption is performed or the header position and the new header may be extended and applied to the present disclosure.

[0631] Figure 2W The operation of a sending PDCP layer device or the operation of a receiving PDCP layer device of a UE or a base station according to an embodiment of the present disclosure is shown.

[0632] In the present disclosure, in a case where an upper layer header compression protocol (Ethernet header compression method, EthHC) is configured for a sending PDCP layer device, if data 2w-05 received from an upper layer is first received after the Ethernet header compression method is configured; if even one of the field values ​​of the compressible fields among the fields of the Ethernet header of the data received from the upper layer is different from the field value stored in the buffer of the sending PDCP layer device (or different from the previously sent Ethernet header field value); or if no feedback indicating successful reception of data with a previously sent uncompressed complete upper layer header (Ethernet header) is received from the receiving PDCP layer device (indicated by reference numeral 2w-10), the sending PDCP layer device does not perform Ethernet header compression until feedback indicating successful reception of an uncompressed complete upper layer header (Ethernet header) is received from the receiving PDCP layer device (indicated by reference numeral 2w-20). If feedback is received from a receiving PDCP layer device indicating successful reception of data having a previously sent uncompressed complete upper layer header (Ethernet header) (indicated by reference numeral 2w-10), the sending PDCP layer device may perform compression by applying an Ethernet header compression method to the data received from the upper layer (indicated by reference numeral 2w-15).

[0633] In the present disclosure, if an Ethernet header compression protocol for a receiving PDCP layer device is configured and data is received from a lower layer (indicated by reference numeral 2w-30), and if the Ethernet header is compressed (if an indicator of a new EHC header is checked and the indicator indicates that the Ethernet header is compressed) (indicated by reference numeral 2w-35), the Ethernet header of the data may be decompressed (indicated by reference numeral 2w-40). Otherwise, if an Ethernet header compression protocol is configured and the Ethernet header is not compressed (if an indicator of a new EHC header is checked and the indicator indicates that the Ethernet header is compressed) (indicated by reference numeral 2w-35), the Ethernet header of the data is regarded as an uncompressed header and decompression thereof is not performed. Since the uncompressed Ethernet header is successfully received, feedback is triggered to indicate its successful reception to the sending PDCP layer device, and the feedback may be sent to the sending PDC layer device (indicated by reference numeral 2w-45).

[0634] Figure 2X The structure of a UE according to an embodiment of the present disclosure is shown.

[0635] refer to Figure 2X , the UE includes a radio frequency (RF) processor 2x-10, a baseband processor 2x-20, a storage device 2x-30 and a controller 2x-40.

[0636] The RF processor 2x-10 can perform functions such as frequency band conversion and amplification of signals for sending or receiving signals through a radio channel. That is, the RF processor 2x-10 up-converts the baseband signal provided by the baseband processor 2x-20 into an RF band signal, transmits the RF band signal through an antenna, and down-converts the RF band signal received through the antenna into a baseband signal. For example, the RF processor 2x-10 may include a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a digital-to-analog converter (DAC), an analog-to-digital converter (ADC), etc. Figure 2X In the figure, only one antenna is shown, but the UE may include multiple antennas. In addition, the RF processor 2x-10 may include multiple RF chains. In addition, the RF processor 2x-10 can perform beamforming. For beamforming, the RF processor 2x-10 can adjust the phase and amplitude of each signal sent or received through multiple antennas or antenna elements. In addition, the RF processor can perform MIMO operations and can receive multiple layers when performing MIMO operations. The RF processor 2x-10 can perform receive beam scanning by appropriately configuring multiple antennas or antenna elements under the control of the controller, or can adjust the direction and width of the receive beam so that the receive beam is coordinated with the transmit beam.

[0637] The baseband processor 2x-20 can perform the conversion function between the baseband signal and the bit string according to the physical layer standard of the system. For example, when sending data, the baseband processor 2x-20 can generate complex symbols by encoding and modulating the sending bit string. In addition, when receiving data, the baseband processor 2x-20 can reconstruct the received bit string by demodulating and decoding the baseband signal provided by the RF processor 2x-10. For example, according to the orthogonal frequency division multiplexing (OFDM) scheme, when sending data, the baseband processor 2x-20 generates complex symbols by encoding and modulating the sending bit string, maps the complex symbols to subcarriers, and then configures OFDM symbols by performing an inverse fast Fourier transform (IFFT) operation and a cyclic prefix (CP) insertion. In addition, when receiving data, the baseband processor 2x-20 can divide the baseband signal provided by the RF processor 2x-10 in OFDM symbol units, can reconstruct the signal that has been mapped to the subcarrier by a fast Fourier transform (FFT) operation, and can then reconstruct the received bit string by demodulating and decoding the mapped signal.

[0638] The baseband processor 2x-20 and the RF processor 2x-10 send or receive signals as described above. Therefore, the baseband processor 2x-20 and the RF processor 2x-10 can be referred to as a transmitter, a receiver, a transceiver or a communication unit. In addition, at least one of the baseband processor 2x-20 and the RF processor 2x-10 may include a plurality of communication modules to support different radio access technologies. In addition, at least one of the baseband processor 2x-20 and the RF processor 2x-10 may include different communication modules to process signals of different frequency bands. For example, different radio access technologies may include LTE networks, NR networks, etc. In addition, different frequency bands may include ultra-high frequency (SHF) (e.g., 2.5 GHz, 5 GHz) bands and millimeter wave (e.g., 60 GHz) bands.

[0639] The storage device 2x-30 may store data such as basic programs, application programs, and configuration information for performing UE operations. The storage device 2x-30 provides the stored data at the request of the controller 2x-40.

[0640] The controller 2x-40 controls the overall operation of the UE. For example, the controller 2x-40 may send or receive signals through the baseband processor 2x-20 and the RF processor 2x-10. In addition, the controller 2x-40 records or reads data in the memory 2x-40. To this end, the controller 2x-40 may include at least one processor. For example, the controller 2x-40 may include a communication processor (CP) for performing communication control and an application processor (AP) for controlling an upper layer such as an application (not shown). For example, the controller 2x-40 may also include a multi-connection processor 2x-42 for connection.

[0641] Figure 2Y A block configuration of a TRP in a wireless communication system according to an embodiment of the present disclosure is shown.

[0642] refer to Figure 2Y The base station may include an RF processor 2y-10, a baseband processor 2y-20, a backhaul communication unit 2y-30, a storage device 2y-40 and a controller 2y-50.

[0643] The RF processor 2y-10 can perform functions such as frequency band conversion and amplification of signals for sending or receiving signals through a radio channel. That is, the RF processor 2y-10 up-converts the baseband signal provided by the baseband processor 2y-20 into an RF band signal, transmits the RF band signal through an antenna, and down-converts the RF band signal received through the antenna into a baseband signal. For example, the RF processor 2y-10 may include a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, etc. Figure 2Y In the figure, only one antenna is shown, but the first access node may include multiple antennas. In addition, the RF processor 2y-10 may include multiple RF chains. In addition, the RF processor 2y-10 can perform beamforming. For beamforming, the RF processor 2y-10 can adjust the phase and amplitude of each signal sent and received through multiple antennas or antenna elements. The RF processor can perform downlink MIMO operations by sending one or more layers.

[0644] The baseband processor 2y-20 can perform the conversion function between the baseband signal and the bit string according to the physical layer standard of the first radio access technology. For example, when sending data, the baseband processor 2y-20 can generate complex symbols by encoding and modulating the sending bit stream. In addition, when receiving data, the baseband processor 2y-20 can reconstruct the received bit string by demodulating and decoding the baseband signal provided from the RF processor 2y-10. For example, according to the OFDM scheme, when sending data, the baseband processor 2y-20 generates complex symbols by encoding and modulating the sending bit stream, maps the complex symbols to the subcarrier, and then configures the OFDM symbol by performing IFFT operation and CP insertion. In addition, when receiving data, the baseband processor 2y-20 can divide the baseband signal provided from the RF processor 2y-10 in OFDM symbol units, can reconstruct the signal that has been mapped to the subcarrier by FFT operation, and can then reconstruct the received bit string by demodulating and decoding the mapped signal. The baseband processor 2y-20 and the RF processor 2y-10 send or receive signals as described above. Therefore, the baseband processor 2y-20 and the RF processor 2y-10 can be referred to as a transmitter, a receiver, a transceiver, a communication unit, or a wireless communication unit.

[0645] Communication unit 2y-30 provides an interface for communicating with other nodes in the network.

[0646] The storage device 2y-40 can store data such as basic programs, applications, and configuration information for performing master station operations. Specifically, the storage device 2y-40 can store information about the bearer assigned to the connected terminal, the measurement results reported from the connected terminal, etc. In addition, the storage device 2y-40 can store information used as a criterion for determining whether to provide or terminate multiple connections to the terminal. In addition, the storage device 2y-40 provides the stored data at the request of the controller 2y-50.

[0647] The controller 2y-50 controls the overall operation of the master station. For example, the controller 2y-50 can send or receive signals through the baseband processor 2y-20 and the RF processor 2y-10 or through the backhaul communication unit 2y-30. In addition, the controller 2y-50 records or reads data in the storage device 2y-40. To this end, the controller 2y-50 may include at least one processor. For example, the controller 2y-50 may also include a multi-connection processor 2y-52 for connection.

[0648] While the present disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present disclosure as defined by the appended claims and their equivalents.

Claims

1. A method performed by a terminal in a wireless communication system, the method comprising: Identify whether the Service Data Adaptation Protocol (SDAP) header is configured and whether the Ethernet Header Compression (EHC) is configured; as well as When EHC is configured, EHC is performed on the data in the Packet Data Convergence Protocol (PDCP) layer. The EHC header is located after the SDAP header. Among them, the PDCP header and SDAP header are not encrypted. The Ethernet header compression is not applied to the SDAP header or the SDAP control packet data unit (PDU).

2. The method according to claim 1, in, The EHC header generated in the PDCP layer is encrypted.

3. The method according to claim 1, wherein: The EHC header is not generated for the SDAP control protocol data unit PDU.

4. The method according to claim 1, wherein: In case both EHC and Robust Header Compression (ROHC) are configured, the ROHC header is located after the EHC header.

5. A method performed by a base station in a wireless communication system, the method comprising: Identify whether the Service Data Adaptation Protocol (SDAP) header is configured and whether the Ethernet Header Compression (EHC) is configured; as well as When EHC is configured, EHC is performed on the data in the Packet Data Convergence Protocol (PDCP) layer. The EHC header is located after the SDAP header. Among them, the PDCP header and SDAP header are not encrypted. The Ethernet header compression is not applied to the SDAP header or the SDAP control packet data unit (PDU).

6. The method according to claim 5, in, The EHC header generated in the PDCP layer is encrypted.

7. The method according to claim 5, wherein: The EHC header is not generated for the SDAP control protocol data unit PDU.

8. The method according to claim 5, wherein: In case both EHC and Robust Header Compression (ROHC) are configured, the ROHC header is located after the EHC header.

9. A terminal, comprising: a transceiver capable of transmitting or receiving at least one signal; as well as A controller, coupled to the transceiver, Wherein, the controller is configured as: Identify whether a Service Data Adaptation Protocol (SDAP) header is configured and whether Ethernet Header Compression (EHC) is configured; and When EHC is configured, EHC is performed on the data in the Packet Data Convergence Protocol (PDCP) layer. The EHC header is located after the SDAP header. Among them, the PDCP header and SDAP header are not encrypted. The Ethernet header compression is not applied to the SDAP header or the SDAP control packet data unit (PDU).

10. The terminal according to claim 9, in, The EHC header generated in the PDCP layer is encrypted.

11. The terminal according to claim 9, wherein: The EHC header is not generated for the SDAP control protocol data unit PDU.

12. The terminal according to claim 9, wherein: In case both EHC and Robust Header Compression (ROHC) are configured, the ROHC header is located after the EHC header.

13. A base station, comprising: a transceiver capable of transmitting or receiving at least one signal; as well as A controller, coupled to the transceiver, Wherein, the controller is configured as: Identify whether a Service Data Adaptation Protocol (SDAP) header is configured and whether Ethernet Header Compression (EHC) is configured; and When EHC is configured, EHC is performed on the data in the Packet Data Convergence Protocol (PDCP) layer. The EHC header is located after the SDAP header. Among them, the PDCP header and SDAP header are not encrypted. The Ethernet header compression is not applied to the SDAP header or the SDAP control packet data unit (PDU).

14. The base station according to claim 13, in, The EHC header generated in the PDCP layer is encrypted.

15. The base station according to claim 13, wherein: No EHC header is generated for SDAP control protocol data unit PDU, and In case both EHC and Robust Header Compression (ROHC) are configured, the ROHC header is located after the EHC header.

Images