KR20200114960A - Method and apparatus for processing pdcp control data in system supporting ultra reliable low latency communication - Google Patents

Abstract

The present disclosure relates to a communication technique for fusing a 5G communication system with IoT technology to support a higher data transmission rate after a 4G system, and a system thereof. The present disclosure can be applied to intelligent services (e.g., smart home, smart building, smart city, smart car or connected car, healthcare, digital education, retail, security, and safety related services, etc. ) based on 5G communication technology and IoT-related technology. The present invention discloses a method for efficiently processing PDCP control data of a PDCP layer device when applying a packet redundant transmission technique in a system for supporting a high-reliability and low-latency service.

Description

Method and apparatus for processing PDCP control data in a system supporting high-reliability, low-latency service {METHOD AND APPARATUS FOR PROCESSING PDCP CONTROL DATA IN SYSTEM SUPPORTING ULTRA RELIABLE LOW LATENCY COMMUNICATION}

The present invention proposes a method and apparatus for efficiently processing PDCP control data of a PDCP layer device when a packet redundant transmission technique is applied in a system supporting a high-reliability low-delay service.

In addition, the present invention proposes a method and apparatus for supporting Ethernet header compression and decompression in a next-generation mobile communication system.

Efforts are being made to develop an improved 5G communication system or a pre-5G communication system in order to meet the increasing demand for wireless data traffic after the commercialization of 4G communication systems. For this reason, the 5G communication system or the pre-5G communication system is called a communication system after a 4G network (Beyond 4G Network) or a system after an LTE system (Post LTE). In order to achieve a high data rate, the 5G communication system is being considered for implementation in the ultra-high frequency (mmWave) band (eg, such as the 60 Giga (60 GHz) band). In order to mitigate the path loss of radio waves in the ultra-high frequency band and increase the transmission distance of radio waves, in 5G communication systems, beamforming, massive MIMO, and Full Dimensional MIMO (FD-MIMO) ), array antenna, analog beam-forming, and large scale antenna technologies are being discussed. In addition, in order to improve the network of the system, in 5G communication system, advanced small cell, advanced small cell, cloud radio access network (cloud RAN), ultra-dense network , Device to Device communication (D2D), wireless backhaul, moving network, cooperative communication, CoMP (Coordinated Multi-Points), and interference cancellation And other technologies are being developed. In addition, in the 5G system, advanced coding modulation (ACM) methods such as Hybrid FSK and QAM Modulation (FQAM) and SWSC (Sliding Window Superposition Coding), advanced access technologies such as Filter Bank Multi Carrier (FBMC), NOMA (non orthogonal multiple access), and sparse code multiple access (SCMA) have been developed.

Meanwhile, the Internet is evolving from a human-centered connection network in which humans create and consume information, to an Internet of Things (IoT) network that exchanges and processes information between distributed components such as objects. IoE (Internet of Everything) technology, which combines IoT technology with big data processing technology through connection with cloud servers, is also emerging. In order to implement IoT, technology elements such as sensing technology, wired/wireless communication and network infrastructure, service interface technology, and security technology are required, and recently, a sensor network for connection between objects, machine to machine , M2M), and MTC (Machine Type Communication) technologies are being studied. In the IoT environment, intelligent IT (Internet Technology) services that create new value in human life by collecting and analyzing data generated from connected objects can be provided. IoT is the field of smart home, smart building, smart city, smart car or connected car, smart grid, healthcare, smart home appliance, advanced medical service, etc. through the convergence and combination of existing IT (information technology) technology and various industries. Can be applied to.

Accordingly, various attempts have been made to apply a 5G communication system to an IoT network. For example, technologies such as sensor network, machine to machine (M2M), and MTC (Machine Type Communication) are implemented by techniques such as beamforming, MIMO, and array antenna. There is. As the big data processing technology described above, a cloud radio access network (cloud RAN) is applied as an example of the convergence of 5G technology and IoT technology.

With the recent development of next-generation mobile communication systems, it is necessary to efficiently use transmission resources to support services that require low transmission delay and high reliability (e.g., URLLC (Ultra Reliable Low Latency Communication) or IIoT (Industrial IoT) service). There is a need.

In a next-generation mobile communication system, in order to increase reliability and lower transmission delay, the same data can be transmitted through different independent paths in a carrier aggregation technology or dual connectivity technology. Each RLC device supporting packet duplication in the direct frequency technology or dual access technology can operate in RLC AM (Acknowledged Mode) or RLC UM (Unacknowledged Mode), and can be activated by MAC control information. Yes, it can be disabled. However, when applying the packet redundant transmission method, there is a need to consider the ease of implementation and a method of processing control data of the PDCP layer so as not to cause a problem of the receiving PDCP layer device.

In addition, in the next-generation mobile communication system, there is a need to efficiently use transmission resources to support services that require low transmission delay and high reliability (e.g., URLLC (Ultra Reliable Low Latency Communication) or IIoT (Industrial IoT) service). have. In addition, it is necessary to efficiently perform an encryption and decryption procedure, which is the most processing burden among data processing procedures of the terminal.

The present invention for solving the above problem is a control signal processing method in a wireless communication system, the method comprising: receiving a first control signal transmitted from a base station; Processing the received first control signal; And transmitting a second control signal generated based on the processing to the base station.

In the present invention, in order to efficiently use packet duplication that can be applied in a next-generation mobile communication system, ease of implementation is considered, and control data of the PDCP layer that does not cause a problem of the receiving PDCP layer device is provided. A processing method is proposed so that the packet redundant transmission technique can be efficiently used.

The present invention proposes a method of compressing and decompressing an Ethernet header in a next-generation mobile communication system using an Ethernet protocol so that transmission resources can be efficiently used. Therefore, more data can be transmitted with less transmission resources, and since a more reliable modulation method can be used, high reliability and low delay can be guaranteed. In addition, an efficient encryption and decryption method for data to which the Ethernet header decompression procedure is applied is proposed to reduce the implementation complexity of the terminal and reduce the processing burden.

1A is a diagram showing the structure of an LTE system to which the present invention can be applied.
1B is a diagram showing a radio protocol structure in an LTE system to which the present invention can be applied.
1C is a diagram showing the structure of a next-generation mobile communication system to which the present invention can be applied.
1D is a diagram showing a radio protocol structure of a next-generation mobile communication system to which the present invention can be applied. .
1E is a diagram showing a procedure in which data is processed at each layer in the next-generation mobile communication system of the present invention.
1F is a diagram illustrating a procedure for a base station to set a packet redundant transmission function in a PDCP layer with an RRC message when a terminal establishes a connection with a network in the present invention.
1G is a diagram showing a packet duplication in which a PDCP layer proposed by the present invention transmits a packet by overlapping packets based on a carrier aggregation technology in a next-generation mobile communication system.
FIG. 1H is a diagram showing a packet duplication in which a PDCP layer proposed in the present invention transmits packets by overlapping packets based on dual connectivity in a next-generation mobile communication system.
FIG. 1I is a diagram showing an embodiment of extending the packet redundant transmission technique described in FIG. 1G or 1H to a plurality of RLC layer devices.
1J is a diagram for explaining an embodiment 1-1 of processing control data of a PDCP layer device in a packet redundant transmission technology based on a carrier aggregation technology or a packet redundancy transmission technology based on a dual access technology in the present invention.
FIG. 1K is a diagram illustrating a second embodiment of processing control data of a PDCP layer device in a packet redundant transmission technology based on a carrier aggregation technology or a packet redundancy transmission technology based on a dual access technology in the present invention.
FIG. 1L is a diagram illustrating a terminal operation in which a PDCP layer proposed in the present invention performs packet duplication based on a carrier aggregation technology or a dual access technology in a next-generation mobile communication system.
1M shows the structure of a terminal to which an embodiment of the present invention can be applied.
1N is a block diagram of a TRP in a wireless communication system to which an embodiment of the present invention can be applied.
2A is a diagram illustrating a structure of an LTE system to which the present invention can be applied.
2B is a diagram showing a radio protocol structure in an LTE system to which the present invention can be applied.
2C is a diagram showing the structure of a next-generation mobile communication system to which the present invention can be applied.
2D is a diagram showing a radio protocol structure of a next-generation mobile communication system to which the present invention can be applied. .
2E is a diagram illustrating a procedure for a base station to set Ethernet header protocol related configuration information to a terminal when a terminal proposed in the present invention establishes a connection with a network.
2F is a diagram showing a method for compressing an Ethernet (EthHC) header proposed by the present invention.
2G is a diagram illustrating a method for compressing an Ethernet Header Compression (EthHC) header proposed when an SDAP header or a layer device is configured in the present invention.
2H is a diagram showing another Ethernet (EthHC, Ethernet Header Compression) header compression method proposed when an SDAP header or a layer device is configured in the present invention.
2I is a diagram illustrating a specific first embodiment of an Ethernet header compression method proposed in the present invention.
2J is a diagram illustrating a second embodiment of a method for compressing an Ethernet header proposed in the present invention.
2K is a diagram illustrating embodiments of a feedback structure that can be used in the higher layer header compression method proposed in the present invention.
2L is a 2-1 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.
2M is a 2-2 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.
2N is a 2-3rd for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.
Figure 2o is a 2-4 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.
2P is a 2-5 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.
2q is a 2-6 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.
2R is a 2-7 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.
2S is a 2-8 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.
2T is a 2-9 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.
2u is a 2-10 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.
2V is a 2-11 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.
2W is a diagram showing an operation of a transmitting PDCP layer device or a receiving PDCP layer device of a terminal or a base station.
2X shows the structure of a terminal to which an embodiment of the present invention can be applied.
2Y shows a block configuration of a TRP in a wireless communication system to which an embodiment of the present invention can be applied.

Hereinafter, the operating principle of the present invention will be described in detail with reference to the accompanying drawings. In the following description of the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present invention, a detailed description thereof will be omitted. In addition, terms to be described later are terms defined in consideration of functions in the present invention, which may vary depending on the intention or custom of users or operators. Therefore, the definition should be made based on the contents throughout this specification.

In the following description of the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present invention, a detailed description thereof will be omitted. Hereinafter, exemplary embodiments of the present invention will be described with reference to the accompanying drawings.

A term for identifying an access node used in the following description, a term for network entities, a term for messages, a term for an interface between network objects, a term for various identification information And the like are illustrated for convenience of description. Therefore, the present invention is not limited to the terms described below, and other terms referring to objects having an equivalent technical meaning may be used.

For convenience of description below, the present invention uses terms and names defined in the 3GPP 3rd Generation Partnership Project Long Term Evolution (LTE) standard. However, the present invention is not limited by the terms and names, and can be applied equally to systems conforming to other standards. In the present invention, the eNB may be used interchangeably with gNB for convenience of description. That is, a base station described as an eNB may represent a gNB.

1A is a diagram showing the structure of an LTE system to which the present invention can be applied.

Referring to Figure 1a, as shown, the radio access network of the LTE system is a next-generation base station (Evolved Node B, hereinafter ENB, Node B or base station) (1a-05, 1a-10, 1a-15, 1a-20) and It is composed of MME (1a-25, Mobility Management Entity) and S-GW (1a-30, Serving-Gateway). User Equipment (hereinafter, referred to as UE or terminal) 1a-35 accesses an external network through ENBs 1a-05 to 1a-20 and S-GW 1a-30.

In FIG. 1A, ENBs 1a-05 to 1a-20 correspond to the existing node B of the UMTS system. The ENB is connected to the UEs 1a-35 through a radio channel and performs a more complex role than the existing Node B. In the LTE system, all user traffic including real-time services such as VoIP (Voice over IP) through the Internet protocol are serviced through a shared channel, so status information such as buffer status, available transmission power status, and channel status of UEs A device that collects and schedules is required, and ENB (1a-05 ~ 1a-20) is in charge of this. One ENB typically controls multiple cells. For example, in order to implement a transmission rate of 100 Mbps, the LTE system uses, for example, an orthogonal frequency division multiplexing (OFDM) in a 20 MHz bandwidth as a radio access technology. In addition, an adaptive modulation and coding method (hereinafter referred to as AMC) that determines a modulation scheme and a channel coding rate according to the channel state of the terminal is applied. The S-GW 1a-30 is a device that provides a data bearer, and creates or removes a data bearer under the control of the MME 1a-25. The MME is a device responsible for various control functions as well as mobility management functions for a terminal, and is connected to a plurality of base stations.

1B is a diagram showing a radio protocol structure in an LTE system to which the present invention can be applied.

Referring to Figure 1b, the radio protocol of the LTE system is PDCP (Packet Data Convergence Protocol 1b-05, 1b-40), RLC (Radio Link Control 1b-10, 1b-35), MAC (Medium Access Control 1b-15, 1b-30). PDCP (Packet Data Convergence Protocol) (1b-05, 1b-40) is in charge of operations such as IP header compression/restore. The main functions of PDCP are summarized as follows.

-Header compression and decompression (ROHC only)

-Transfer of user data

-In-sequence delivery of upper layer PDUs at PDCP re-establishment procedure for RLC AM

-Order reordering function (For split bearers in DC (only support for RLC AM): PDCP PDU routing for transmission and PDCP PDU reordering for reception)

-Duplicate detection of lower layer SDUs at PDCP re-establishment procedure for RLC AM

-Retransmission of PDCP SDUs at handover and, for split bearers in DC, of PDCP PDUs at PDCP data-recovery procedure, for RLC AM

-Encryption and decryption function (Ciphering and deciphering)

-Timer-based SDU discard in uplink.

Radio Link Control (hereinafter referred to as RLC) (1b-10, 1b-35) performs ARQ operation by reconfiguring a PDCP packet data unit (PDU) to an appropriate size. The main functions of RLC are summarized as follows.

-Data transfer function (Transfer of upper layer PDUs)

-ARQ function (Error Correction through ARQ (only for AM data transfer))

-Concatenation, segmentation and reassembly of RLC SDUs (only for UM and AM data transfer)

-Re-segmentation of RLC data PDUs (only for AM data transfer)

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

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

-Error detection function (Protocol error detection (only for AM data transfer))

-RLC SDU discard function (RLC SDU discard (only for UM and AM data transfer))

-RLC re-establishment

The MACs 1b-15 and 1b-30 are connected to several RLC layer devices configured in one terminal, and perform an operation of multiplexing RLC PDUs to MAC PDUs and demultiplexing RLC PDUs from MAC PDUs. The main functions of MAC are summarized as follows.

-Mapping between logical channels and transport channels

-Multiplexing/demultiplexing of MAC SDUs belonging to one or different logical channels into/from transport blocks (TB) delivered to/from the physical layer on transport channels

-Scheduling information reporting function

-HARQ function (Error correction through HARQ)

-Priority handling between logical channels of one UE

-Priority handling between UEs by means of dynamic scheduling

-MBMS service identification

-Transport format selection

-Padding function

The physical layer (1b-20, 1b-25) channel-codes and modulates upper layer data, converts it into OFDM symbols, and transmits it to the radio channel, or demodulates OFDM symbols received through the radio channel and decodes the channel and delivers it to the upper layer. Do the action.

1C is a diagram showing the structure of a next-generation mobile communication system to which the present invention can be applied.

Referring to Figure 1c, as shown, the radio access network of the next-generation mobile communication system (hereinafter NR or 5G) is a next-generation base station (New Radio Node B, hereinafter NR gNB or NR base station) (1c-10) and NR CN (1c). -05, New Radio Core Network). The user terminal (New Radio User Equipment, hereinafter NR UE or terminal) 1c-15 accesses the external network through the NR gNB 1c-10 and NR CN 1c-05.

In FIG. 1C, the NR gNB 1c-10 corresponds to an Evolved Node B (eNB) of an existing LTE system. The NR gNB is connected to the NR UE 1c-15 through a radio channel and can provide a service superior to that of the existing Node B. In the next-generation mobile communication system, all user traffic is serviced through a shared channel, so a device that collects and schedules status information such as buffer status, available transmission power status, and channel status of UEs is required. (1c-10) is in charge. One NR gNB typically controls multiple cells. In order to implement ultra-high-speed data transmission compared to the current LTE, it may have more than the existing maximum bandwidth, and a beamforming technology may be additionally grafted by using Orthogonal Frequency Division Multiplexing (OFDM) as a wireless access technology. . In addition, an adaptive modulation and coding method (hereinafter referred to as AMC) that determines a modulation scheme and a channel coding rate according to the channel state of the terminal is applied. The NR CN (1c-05) performs functions such as mobility support, bearer setup, and QoS setup. The NR CN is a device responsible for various control functions as well as mobility management functions for a terminal, and is connected to a plurality of base stations. In addition, the next-generation mobile communication system can be interlocked with the existing LTE system, and the NR CN is connected to the MME (1c-25) through a network interface. The MME is connected to the existing eNB (1c-30).

1D is a diagram showing a radio protocol structure of a next-generation mobile communication system to which the present invention can be applied. .

Referring to Figure 1d, the radio protocol of the next-generation mobile communication system is NR PDCP (1d-05, 1d-40), NR RLC (1d-10, 1d-35), NR MAC (1d-15) in the terminal and the NR base station, respectively. , 1d-30). The main functions of NR PDCP (1d-05, 1d-40) may include some of the following functions.

Header compression and decompression (ROHC only)

-Transfer of user data

-In-sequence delivery of upper layer PDUs

-Out-of-sequence delivery of upper layer PDUs

-Order reordering function (PDCP PDU reordering for reception)

-Duplicate detection of lower layer SDUs

-Retransmission of PDCP SDUs

-Encryption and decryption function (Ciphering and deciphering)

-Timer-based SDU discard in uplink.

In the above, the reordering function of the NR PDCP device refers to a function of rearranging the PDCP PDUs received from the lower layer in order based on the PDCP sequence number (SN), and the function of delivering data to the upper layer in the rearranged order. It may include, or may include a function of immediately delivering without considering the order, may include a function of recording lost PDCP PDUs by rearranging the order, and reporting the status of lost PDCP PDUs It may include a function of performing the transmission side, and may include a function of requesting retransmission of lost PDCP PDUs.

The main functions of the NR RLC (1d-10, 1d-35) may include some of the following functions.

-Data transfer function (Transfer of upper layer PDUs)

-In-sequence delivery of upper layer PDUs

-Out-of-sequence delivery of upper layer PDUs

-ARQ function (Error Correction through ARQ)

-Concatenation, segmentation and reassembly of RLC SDUs

-Re-segmentation of RLC data PDUs

-Reordering of RLC data PDUs

-Duplicate detection

-Protocol error detection

-RLC SDU discard function (RLC SDU discard)

-RLC re-establishment

In the above, the in-sequence delivery function of the NR RLC device refers to the function of delivering RLC SDUs received from the lower layer to the upper layer in order, and originally, one RLC SDU is divided into several RLC SDUs and received. If so, it may include a function of reassembling and delivering it, and may include a function of rearranging the received RLC PDUs based on RLC sequence number (SN) or PDCP sequence number (SN), and rearranging the order It may include a function of recording lost RLC PDUs, may include a function of reporting a status of lost RLC PDUs to a transmitting side, and a function of requesting retransmission of lost RLC PDUs. If there is a lost RLC SDU, it may include a function of transferring only RLC SDUs before the lost RLC SDU to a higher layer in order, or if a predetermined timer expires even if there is a lost RLC SDU, the timer It may include a function of delivering all RLC SDUs received before the start of the system in order to the upper layer, or if a predetermined timer expires even if there is a lost RLC SDU, all RLC SDUs received so far are sequentially transferred to the upper layer. It may include the ability to deliver. In addition, RLC PDUs may be processed in the order in which they are received (regardless of the order of serial number and sequence number, in the order of arrival) and delivered to the PDCP device regardless of the order (Out-of sequence delivery). Segments stored in a buffer or to be received in the future may be received, reconstructed into one complete RLC PDU, processed, and delivered to the PDCP device. The NR RLC layer may not include a concatenation function, and the function may be performed by the NR MAC layer or may be replaced with a multiplexing function of the NR MAC layer.

In the above, the out-of-sequence delivery function of the NR RLC device refers to a function of directly delivering RLC SDUs received from the lower layer to the upper layer regardless of the order, and originally, one RLC SDU is When it is divided into SDUs and received, it may include a function of reassembling and transmitting them, and includes a function of storing the RLC SN or PDCP SN of the received RLC PDUs, sorting the order, and recording the lost RLC PDUs. I can.

The NR MACs 1d-15 and 1d-30 may be connected to several NR RLC layer devices configured in one terminal, and the main functions of the NR MAC may include some of the following functions.

-Mapping between logical channels and transport channels

-Multiplexing and demultiplexing function (Multiplexing/demultiplexing of MAC SDUs)

-Scheduling information reporting function

-HARQ function (Error correction through HARQ)

-Priority handling between logical channels of one UE

-Priority handling between UEs by means of dynamic scheduling

-MBMS service identification

-Transport format selection

-Padding function

The NR PHY layer (1d-20, 1d-25) channel-codes and modulates upper layer data, makes it into OFDM symbols, and transmits it to the radio channel, or demodulates and channel-decodes OFDM symbols received through the radio channel to the upper layer. You can perform the transfer operation.

In the present invention, the transmitting end device may be a base station or a terminal, and the receiving end device may be a base station or a terminal. That is, a case where the transmitting end device is a base station and the receiving end device is a terminal (downlink data transmission scenario), or a case where the transmitting end device is a terminal and the receiving end device is a base station (uplink data transmission scenario) may be included. The transmitting end device can indicate the base station or the terminal, and the receiving end device can indicate the base station or the terminal.

In the present invention, a terminal in which a frequency aggregation technology (Carrier Aggregation, CA), dual connectivity technology (Dual connectivity, DC), or packet redundancy technology is configured is considered, and the proposed method is specified using the following terms.

- Pcell (Primary Cell): refers to a serving cell used by the UE when initially establishing a connection with a base station, and establishes a connection by transmitting and receiving a major RRC message using the Pcell. In addition, since the Pcell always has PUCCH transmission resources, it can indicate HARQ ACK or NACK, and both uplink and downlink are always configured, and as a reference cell for timing adjustment (Timing Advance, Primary Timing Advance Group (pTAG)). Can be used. For example, when a frequency integration technique is set after a Pcell is set and an Scell is added, the Scell may perform uplink data transmission by referring to the timing adjustment value of the Pcell. And when dual access technology is set, Pcell means a PCell of MCG (Master Cell Group).

- MCG (Master Cell Group): refers to a serving cell to which a UE initially establishes a connection with a base station or a group of cells supported by a base station. When dual access technology is configured, major RRC messages are transmitted or received through the MCG.

- SCG (Secondary Cell Group): The terminal establishes a connection with the base station and can add cells of another base station in addition to the MCG. In this case, it refers to a group of cells supported by the other base station. When dual access technology is configured, additional It can be added to increase the data rate or to efficiently support the mobility of the terminal.

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

- Scell (Secondary Cell): Cells additionally configured by the base station to set the carrier aggregation technology after the terminal establishes a connection with the base station for the first time is called an Scell. The SCell may have PUCCH transmission resources according to the base station configuration, and the uplink or downlink may be configured according to the configuration of the base station, and also timing adjustment according to the configuration of the base station (Timing Advance, Secondary Timing Advance Group (sTAG)). ) Can be used as a reference cell. For example, when a frequency integration technique is set after a Pcell is set, Scells are added and sTAG is set, other Scells of the sTAG may perform uplink data transmission with reference to the timing adjustment value of the designated Scell. In addition, when the dual access technology is configured for the terminal, Scell means Scells excluding PCells of MCG (Master Cell Group) or Scells excluding PScells of Secondary Cell Group (SCG).

- When the first RLC layer device (Primary RLC entity) packet redundancy configuration technology is set, a plurality of RLC layer devices may be configured in one PDCP layer device, and are not deactivated among the plurality of RLC layer devices and are always used. One RLC layer device is called a Primary RLC layer device. In addition, in the PDCP layer device, the PDCP control PDU is not repeatedly transmitted, and is always transmitted to the primary RLC layer device.

- Secondary RLC layer device (Secondary RLC entity): When a packet redundancy configuration technique is set, a plurality of RLC layer devices may be configured in one PDCP layer device, and a Primary RLC layer device among the plurality of RLC layer devices Other RLC layer devices are referred to as secondary RLC layer devices.

In the present invention, in order to further increase reliability for a terminal configured with a frequency aggregation technology (Carrier Aggregation, CA), dual connectivity (DC) or packet redundancy technology, and to further lower a transmission delay, packet redundancy is dynamically zero or We propose a method that allows transmission of one or two or three. In other words, we propose a method of transmitting one original data and up to three duplicated data when transmitting certain data.

In the present invention, the packet redundancy technology may be configured as an RRC message to the terminal by applying a dual access technology or a carrier dual access technology, and specifically, a plurality of RLC layer devices connected within one MAC layer device may be configured, and the It is possible to configure a plurality of RLC layer devices to be connected to one PDCP layer device and to perform packet redundancy. As another method, a plurality of RLC layer devices connected within one MCG MAC layer device may be configured, and a plurality of RLC layer devices connected within one SCG MAC layer device may be configured, and connected to the different MAC layer devices. It is possible to configure a plurality of RLC layer devices to be connected to one PDCP layer device and to perform packet redundancy.

In addition, in the RRC message, which RLC layer device is a first RLC layer device or a second RLC layer device among the plurality of RLC layer devices may be indicated by a logical channel identifier and a bearer identifier. For example, in the cell group configuration information, each RLC layer device configuration information may be indicated, and a bearer identifier and a logical channel identifier corresponding to each RLC layer device may be indicated. In addition, in the bearer configuration information, when each PDCP layer device configuration information is indicated, a bearer identifier corresponding to each PDCP layer device is indicated, and a plurality of RLC layer devices are set in the PDCP layer device or bearer identifier, the first RLC layer The logical channel identifier corresponding to the device may be indicated to the first RLC layer device. Therefore, upon receiving the RRC message, the UE configures the PDCP layer device based on the bearer identifier, connects and configures a plurality of RLC layer devices corresponding to the bearer identifier to the PDCP layer device, and configures the first RLC layer device and It is possible to designate a plurality of second RLC layer devices.

In the present invention, as an embodiment, an embodiment in which one first RLC layer device is set and up to three second RLC layer devices can be set is considered, and the embodiments proposed in the present invention are the first It may be extended and applied to embodiments in which one or more RLC layer devices or a second RLC layer device are configured.

The present invention proposes a method of efficiently processing PDCP control data (PDCP control PDU) generated by a PDCP layer device when a packet redundant transmission technique is configured as described above.

In Embodiment 1-1 or Embodiment 1-2, in which the PDCP control data (PDCP control PDU) generated by the PDCP layer device is efficiently processed when the packet redundant transmission technology proposed in the present invention is configured, the PDCP layer device is For the PDCP SDU received from the upper layer, PDCP data (PDCP PDU) is configured and redundantly transmitted to a plurality of second RLC layer devices, and packet duplication is also applied to the PDCP control data generated by the PDCP layer device. A new field in the duplicated PDCP control data to be transmitted to two second RLC layer devices, but to be able to discard the duplicated PDCP control data if it has already been received by detecting the duplicate without processing the duplicated PDCP control data multiple times. It can be characterized by defining and indicating. In the terminal implementation, there is an advantage that packet duplication can be applied collectively without distinguishing between PDCP data (PDCP SDU) received from a higher layer and PDCP control data generated by a PDCP layer device.

In Embodiment 1-3, in which the PDCP control data (PDCP control PDU) generated by the PDCP layer device is efficiently processed when the packet redundant transmission technology proposed in the present invention is configured, the PDCP layer device receives the PDCP SDU from the upper layer. PDCP data (PDCP PDU) is configured and transmitted to the first RLC layer device and a plurality of second RLC layer devices in duplicate, and packet duplication is not applied to the PDCP control data generated by the PDCP layer device. , It is characterized in that the transmission is not always transmitted to the second RLC layer device, but only to the first RLC layer device. In the packet redundancy technique, since the first RLC layer device can always be kept in an active state, it is easier in a terminal implementation than transmitting the PDCP control data to a second RLC layer device that can be changed to an active or inactive state. .

1E is a diagram showing a procedure in which data is processed at each layer in the next-generation mobile communication system of the present invention.

As shown in FIG. 1E, if an IP packet arrives at the PDCP layer device, the PDCP layer performs the functional operation of the PDCP layer described in 1d, configures a PDCP header, configures data such as 1e-05, and transmits the data to the lower layer. The lower layer RLC layer recognizes the entire PDCP PDU 1e-05 received from the PDCP layer as one data, performs an operation according to the RLC layer function described in FIG. 1D, and configures the RLC header to create 1e-10. , Pass to the lower layer. When the lower layer MAC layer device receives 1e-10 from the RLC layer, that is, when it receives an RLC PDU, it recognizes the entire data, performs the function of the MAC layer device described in 1d, and configures the MAC subheader to configure 1e-15 And transfer to a lower layer to perform transmission.

If the MAC layer device of FIG. 1E receives the MAC PDU from the lower layer, the MAC layer device can read the contents of the MAC header, and all the rest are regarded as data and transmitted to the upper layer, the RLC layer. When the RLC layer receives 1e-25, only the RLC header corresponding to the RLC layer is read, the RLC layer function corresponding thereto is performed, and 1e-30 is transmitted to the upper layer. Likewise, the PDCP layer can read only the PDCP header, perform an operation corresponding to the PDCP layer device, remove the PDCP header to the upper layer, and transfer it to the upper layer.

As described above, each layer of a next-generation mobile communication system can read only a header corresponding to each layer, and cannot read headers or data of another layer. Therefore, it manages and processes independent information.

1F is a diagram illustrating a procedure for a base station to set a packet redundant transmission function in a PDCP layer with an RRC message when a terminal establishes a connection with a network in the present invention.

1F is a procedure for establishing a connection with a network by a terminal switching from an RRC idle mode or an RRC inactive mode (RRC Inactive mode or lightly-connected mode) to an RRC connected mode in the present invention. Hereinafter, a procedure for setting uplink packet duplication of the PDCP layer will be described. The above procedure may be applied equally to setting the redundant downlink packet transmission function, and the configuration of the redundant uplink packet transmission function may be used to configure both the uplink and downlink redundant transmission functions.

In FIG. 1f, the base station may send an RRCConnectionRelease message to the terminal when the terminal transmitting and receiving data in the RRC connected mode does not transmit or receive data for a predetermined reason or for a predetermined period of time to switch the terminal to the RRC idle mode (1f-01). In the future, when the current connection is not established (hereinafter, idle mode UE), when data to be transmitted occurs, it performs an RRC connection establishment process with the base station. If the terminal is in the RRC deactivation mode, the RRC connection resumption procedure can be performed by sending an RRCConnectionResumeRequest message. The UE establishes uplink transmission synchronization with the base station through a random access process and transmits an RRCConnectionRequest message to the base station (1f-05). In the message, the identifier of the terminal and the reason for establishing a connection (establishmentCause) are stored. The base station transmits an RRCConnectionSetup message so that the terminal establishes an RRC connection (1f-10). In the message, whether to use the packet redundant transmission function for each logical channel (logicalchannelconfig), for each bearer, or for each PDCP device (PDCP-config) can be set. Specifically, it is connected to the PDCP layer device to prevent packet redundant transmission. A first RLC layer device that can be used (Primary RLC entity) and a second RLC layer device (Secondary RLC entity) can be designated, and the first RLC layer device or the second RLC layer device is a master cell group ( It may be indicated by one RLC layer device or logical channel identifier of MCG, Master Cell Group) or Secondary Cell Group (SCG). In addition, when two RLC layer devices are configured to be connected to the PDCP layer device in the message, a threshold that can be used in a split bearer may be set. When the amount of data to be transmitted when operating as a split bearer is less than the threshold value, data is transmitted only to a first RLC layer device (primary RLC entity), and when the amount of data to be transmitted is greater than the threshold value, the first Data may be transmitted to the RLC layer device (primary RLC entity) and the second RLC layer device (Secondary RLC entity). The set threshold value and the first RLC layer device and the second RLC layer device activate and use the packet redundant transmission function in dual connectivity, and fall back to the split bearer when deactivated by MAC control information. You can still send and receive data. In addition, when configuring the packet redundant transmission function in the message, whether to activate or deactivate the redundant packet transmission function for a data radio bearer (DRB) may be set. Alternatively, when the packet redundant transmission function is set, it can be designated as active or inactive. In particular, in the case of a control bearer (SRB, Signaling Radio Bearer), not a data bearer, it can be designated as always active by setting the packet redundant transmission function. Alternatively, you can specify it to always be disabled. In addition, the message can be set by designating an initial state as active or inactive when configuring the packet redundant transmission function. In addition, the message may designate a default RLC entity to which the PDCP layer device transmits data in an inactive state when configuring the packet redundancy transmission function, and the default RLC layer device is a first RLC layer device (primary RLC). entity) or a second RLC layer device (secondary RLC entity), or may be indicated by a logical channel identifier. In addition, in order to prevent unnecessary increase of configuration information in the message, the PDCP layer device may always send data to the first RLC layer device (active Since the first RLC layer device is always used in the state and the inactive state, it is possible to facilitate implementation). In addition, the message may include a logical channel identifier to which the packet redundant transmission technology is applied and mapping information of cells to which the packet redundant transmission technology is applied. That is, when the packet redundant transmission technology is applied, the data corresponding to a certain logical channel identifier is This may be set by including mapping information on whether or not transmission is possible to cells (the logical channel identifiers may be set to transmit data only to the mapped cells). When the packet redundant transmission function is deactivated, the mapping relationship between the logical channel identifier set in the message and the cell may be released, and data corresponding to the logical channel identifier may be transmitted to a certain cell. In addition, the message may include indication information indicating whether to perform packet redundancy transmission for each bearer or logical channel for PDCP control data (PDCP Control PDU), and the indication information includes packet redundancy transmission technology in PDCP control data. By applying, it is possible to indicate one RLC layer device to transmit data without transmitting data to a plurality of RLC layer devices. The indicated RLC layer device may be indicated as a first RLC layer device (primary RLC entity) or a second RLC layer device (secondary RLC entity), and in the absence of the indication information, always a first RLC layer device It may be transmitted to (primary RLC entity).

Specifically, the packet redundancy technology may be set to the terminal as the RRC message by applying a dual access technology or a carrier dual access technology, and specifically, a plurality of RLC layer devices connected in one MAC layer device may be configured, and the It is possible to configure a plurality of RLC layer devices to be connected to one PDCP layer device and to perform packet redundancy. As another method, a plurality of RLC layer devices connected within one MCG MAC layer device may be configured, and a plurality of RLC layer devices connected within one SCG MAC layer device may be configured, and connected to the different MAC layer devices. It is possible to configure a plurality of RLC layer devices to be connected to one PDCP layer device and to perform packet redundancy. In addition, in the RRC message, which RLC layer device is a first RLC layer device or a second RLC layer device among the plurality of RLC layer devices may be indicated by a logical channel identifier and a bearer identifier. For example, in the cell group configuration information, each RLC layer device configuration information may be indicated, and a bearer identifier and a logical channel identifier corresponding to each RLC layer device may be indicated. In addition, in the bearer configuration information, when each PDCP layer device configuration information is indicated, a bearer identifier corresponding to each PDCP layer device is indicated, and a plurality of RLC layer devices are set in the PDCP layer device or bearer identifier, the first RLC layer The logical channel identifier corresponding to the device may be indicated to the first RLC layer device. Therefore, upon receiving the RRC message, the UE configures the PDCP layer device based on the bearer identifier, connects and configures a plurality of RLC layer devices corresponding to the bearer identifier to the PDCP layer device, and configures the first RLC layer device and It is possible to designate a plurality of second RLC layer devices.

In addition, RRC connection configuration information and the like are stored in the message. RRC connection is also called SRB (Signaling Radio Bearer), and is used for transmission and reception of RRC messages, which are control messages between the terminal and the base station. The terminal that has established the RRC connection transmits an RRCConnetionSetupComplete message to the base station (1f-15). If the base station does not know the terminal capabilities of the terminal that is currently establishing a connection, or wants to determine the terminal capabilities, it can send a message asking for the capabilities of the terminal. In addition, the terminal can send a message reporting its capabilities. In the message, it may indicate whether the terminal supports a new packet redundant transmission function, and may include an indicator indicating this. The RRCConnetionSetupComplete message includes a control message called SERVICE REQUEST that the UE requests to set up a bearer for a given service to an MME or AMF (Access and Mobility Management Function), UPF (User Plane Function), or SMF (Session Management Function). . The base station transmits the SERVICE REQUEST message contained in the RRCConnetionSetupComplete message to the MME or AMF or UPF or SMF (1f-20), and the MME determines whether to provide the service requested by the terminal. As a result of the determination, if the terminal decides to provide the requested service, the MME or AMF or UPF or SMF transmits an INITIAL CONTEXT SETUP REQUEST message to the base station (1f-25). The message includes information such as QoS (Quality of Service) information to be applied when setting up a Data Radio Bearer (DRB), and security-related information (for example, Security Key, Security Algorithm) to be applied to the DRB. The base station exchanges a SecurityModeCommand message (1f-30) and a SecurityModeComplete message (1f-35) to configure security with the terminal. When the security configuration is completed, the base station transmits an RRCConnectionReconfiguration message to the terminal (1f-40). In the message, whether to use the packet redundant transmission function for each logical channel (logicalchannelconfig), for each bearer, or for each PDCP device (PDCP-config) can be set. Specifically, it is connected to the PDCP layer device to prevent packet redundant transmission. A first RLC layer device that can be used (Primary RLC entity) and a second RLC layer device (Secondary RLC entity) can be designated, and the first RLC layer device or the second RLC layer device is a master cell group ( It may be indicated by one RLC layer device or logical channel identifier of MCG, Master Cell Group) or Secondary Cell Group (SCG). In addition, when two RLC layer devices are configured to be connected to the PDCP layer device in the message, a threshold that can be used in a split bearer may be set. When the amount of data to be transmitted when operating as a split bearer is less than the threshold value, data is transmitted only to a first RLC layer device (primary RLC entity), and when the amount of data to be transmitted is greater than the threshold value, the first Data may be transmitted to the RLC layer device (primary RLC entity) and the second RLC layer device (Secondary RLC entity). The set threshold value and the first RLC layer device and the second RLC layer device activate and use the packet redundant transmission function in dual connectivity, and fall back to the split bearer when deactivated by MAC control information. You can still send and receive data. In addition, when configuring the packet redundant transmission function in the message, whether to activate or deactivate the redundant packet transmission function for a data radio bearer (DRB) may be set. Alternatively, when the packet redundant transmission function is set, it can be designated as active or inactive. In particular, in the case of a control bearer (SRB, Signaling Radio Bearer), not a data bearer, it can be designated as always active by setting the packet redundant transmission function. Alternatively, you can specify it to always be disabled. In addition, the message can be set by designating an initial state as active or inactive when configuring the packet redundant transmission function. In addition, the message may designate a default RLC entity to which the PDCP layer device transmits data in an inactive state when configuring the packet redundancy transmission function, and the default RLC layer device is a first RLC layer device (primary RLC). entity) or a second RLC layer device (secondary RLC entity), or may be indicated by a logical channel identifier. In addition, in order to prevent unnecessary increase of configuration information in the message, the PDCP layer device may always send data to the first RLC layer device (active Since the first RLC layer device is always used in the state and the inactive state, it is possible to facilitate implementation). In addition, the message may include a logical channel identifier to which the packet redundant transmission technology is applied and mapping information of cells to which the packet redundant transmission technology is applied. That is, when the packet redundant transmission technology is applied, the data corresponding to a certain logical channel identifier is This may be set by including mapping information on whether or not transmission is possible to cells (the logical channel identifiers may be set to transmit data only to the mapped cells). When the packet redundant transmission function is deactivated, the mapping relationship between the logical channel identifier set in the message and the cell may be released, and data corresponding to the logical channel identifier may be transmitted to a certain cell. In addition, the message may include indication information indicating whether to perform packet redundancy transmission for each bearer or logical channel for PDCP control data (PDCP Control PDU), and the indication information includes packet redundancy transmission technology in PDCP control data. By applying, it is possible to indicate one RLC layer device to transmit data without transmitting two RLC layer data. The indicated RLC layer device may be indicated as a first RLC layer device (primary RLC entity) or a second RLC layer device (secondary RLC entity), and in the absence of the indication information, always a first RLC layer device It may be transmitted to (primary RLC entity).

Specifically, the packet redundancy technology may be set to the terminal as the RRC message by applying a dual access technology or a carrier dual access technology, and specifically, a plurality of RLC layer devices connected in one MAC layer device may be configured, and the It is possible to configure a plurality of RLC layer devices to be connected to one PDCP layer device and to perform packet redundancy. As another method, a plurality of RLC layer devices connected within one MCG MAC layer device may be configured, and a plurality of RLC layer devices connected within one SCG MAC layer device may be configured, and connected to the different MAC layer devices. It is possible to configure a plurality of RLC layer devices to be connected to one PDCP layer device and to perform packet redundancy. In addition, in the RRC message, which RLC layer device is a first RLC layer device or a second RLC layer device among the plurality of RLC layer devices may be indicated by a logical channel identifier and a bearer identifier. For example, in the cell group configuration information, each RLC layer device configuration information may be indicated, and a bearer identifier and a logical channel identifier corresponding to each RLC layer device may be indicated. In addition, in the bearer configuration information, when each PDCP layer device configuration information is indicated, a bearer identifier corresponding to each PDCP layer device is indicated, and a plurality of RLC layer devices are set in the PDCP layer device or bearer identifier, the first RLC layer The logical channel identifier corresponding to the device may be indicated to the first RLC layer device. Therefore, upon receiving the RRC message, the UE configures the PDCP layer device based on the bearer identifier, connects and configures a plurality of RLC layer devices corresponding to the bearer identifier to the PDCP layer device, and configures the first RLC layer device and It is possible to designate a plurality of second RLC layer devices.

In addition, the message includes configuration information of the DRB to which user data is to be processed, and the terminal applies the information to configure the DRB and transmits an RRCConnectionReconfigurationComplete message to the base station (1f-45). The base station after completing DRB setup with the terminal transmits an INITIAL CONTEXT SETUP COMPLETE message to the MME (1f-50), and the MME that receives it sends an S1 BEARER SETUP message and an S1 BEARER SETUP RESPONSE message to set up the S-GW and S1 bearers. Exchange the (1f-055, 1f-60). The S1 bearer is a connection for data transmission established between the S-GW and the base station, and corresponds to DRB and 1:1. When all of the above processes are completed, the terminal transmits and receives data through the base station and the S-GW (1f-65, 1f-70). This general data transmission process is largely composed of three steps: RRC connection setup, security setup, and DRB setup. In addition, the base station may transmit an RRCConnectionReconfiguration message to the terminal for a predetermined reason in order to newly, add, or change the configuration (1f-75).

1G is a diagram showing a packet duplication in which a PDCP layer proposed by the present invention transmits a packet by overlapping packets based on a carrier aggregation technology in a next-generation mobile communication system.

In FIG. 1G, when the terminal 1g-05 receives an RRC message as in FIG. 1f, it sets a bearer (DRB or SRB) based on the configuration information received in the message, and a PDCP layer device corresponding to each bearer, RLC Layer devices and MAC layer devices can be configured. If a bearer or PDCP layer device or logical channel is to be configured with a packet duplication transmission technology (PDCP packet duplication) based on a carrier aggregation technology, the base station tells the UE to connect to the PDCP layer device for the bearer. Three RLC layer devices (1g-10, 1g-15) can be set. The two RLC layer devices may be configured as a first RLC layer device (primary RLC entity, 1g-10) and a second RLC layer device (secondary RLC entity, 1g-15), and a logical channel identifier (LCID) Can be used to indicate. When the packet redundant transmission technology is set based on the carrier aggregation technology as described above, the initial state may be activated immediately after setting according to the setting information of the RRC message, or may be immediately deactivated. When the bearer is SRB, it can be immediately activated. Whether to activate or deactivate a packet redundant transmission technique for the bearer may be indicated by the base station through MAC control information. The MAC control information indicating whether to activate or deactivate the packet redundant transmission technology is transmitted by the base station to the terminal, and whether the packet redundant transmission technology is activated or deactivated is control information on the uplink redundant transmission technology. Therefore, the downlink packet redundant transmission technique may or may not be used depending on the implementation of the base station. Accordingly, when the first RLC layer device and the second RLC layer device for packet redundancy transmission technology are configured, the terminal may always receive a reception operation in an active state.

FIG. 1H is a diagram showing a packet duplication in which a PDCP layer proposed in the present invention transmits packets by overlapping packets based on dual connectivity in a next-generation mobile communication system.

In FIG. 1H, when the terminal 1h-05 receives an RRC message as in FIG. 1f, it sets a bearer (DRB or SRB) based on the configuration information received in the message, and a PDCP layer device corresponding to each bearer, RLC Layer devices and MAC layer devices can be configured. If a certain bearer or PDCP layer device or logical channel is to be configured with a packet duplication transmission technology (PDCP packet duplication) based on dual connectivity, the base station tells the UE to connect to the PDCP layer device for the bearer. The number of RLC layer devices (1h-10, 1h-15) can be set. The two RLC layer devices may be configured as a first RLC layer device (primary RLC entity, 1h-10) and a second RLC layer device (secondary RLC entity, 1h-15), and a logical channel identifier (LCID) and It can be indicated using the cell group identifier. When the packet redundant transmission technology is set based on the dual access technology as described above, the initial state may be activated immediately after setting according to the setting information of the RRC message, or may be immediately deactivated. When the bearer is SRB, it can be immediately activated. Whether to activate or deactivate a packet redundant transmission technique for the bearer may be indicated by the base station through MAC control information. The MAC control information indicating whether to activate or deactivate the packet redundant transmission technology is transmitted by the base station to the terminal, and whether the packet redundant transmission technology is activated or deactivated is control information on the uplink redundant transmission technology. In the above, the base station transmits MAC control information indicating whether to enable or disable the redundant uplink packet transmission (MAC layer devices 1h-20, 1h-55) corresponding to the master cell group or MAC layer devices corresponding to the secondary cell group ( 1h-25, 1h-60). Alternatively, for convenience of implementation, since the master cell group is always activated, it may always be sent only to the MAC layer device corresponding to the master cell group. Unlike the uplink packet redundant transmission technology, the downlink packet redundant transmission technology may or may not be used depending on the implementation of the base station. Accordingly, when the first RLC layer device and the second RLC layer device for packet redundancy transmission technology are configured, the terminal may always receive a reception operation in an active state.

FIG. 1I is a diagram showing an embodiment of extending the packet redundant transmission technique described in FIG. 1G or 1H to a plurality of RLC layer devices.

In the present invention, as shown in FIG. 1i, packet redundancy is performed to further increase reliability and lower transmission delay for a terminal configured with a frequency aggregation technology (Carrier Aggregation, CA), dual connectivity (DC), or packet redundancy technology. Consider a method of dynamically transmitting 0 or 1 or 2 or 3. In other words, when transmitting certain data, consider a method of transmitting 1 original data and up to 3 replicated data.

In the present invention, the base station may transmit MAC control information to indicate activation and deactivation of the second RLC layer devices connected to the bearer to which the packet redundancy transmission technology is configured, for each bearer or for each logical channel. In addition, the first RLC layer device may be changed to another second RLC layer device by indicating the MAC control information.

The above-described packet redundant transmission technique of the present invention can be applied to user data (PDCP data PDU) of a PDCP layer device. In addition, the packet redundant transmission technique described and proposed above can be equally applied to control data (PDCP control PDU) of a PDCP layer device. In other words, the PDCP layer control data (PDCP layer status report or interspersed ROHC feedback) generated by the PDCP layer device is applied by applying the packet redundancy technique described above. By replicating the feedback for the header compression protocol), packet redundant transmission may be performed to a first RLC layer device (primary RLC entity) and a plurality of second RLC layer devices (secondary RLC entity).

However, it should be noted that in the case of user data of the PDCP layer device, since there is a PDCP serial number, the receiving end can identify the duplicated packets received after that and can immediately discard it if any of the data that the transmitting end has repeatedly transmitted is received. . For example, if data corresponding to PDCP serial number 3 is received, but data corresponding to PDCP serial number 3 are duplicated in other RLC layer devices, they have already been received and can be immediately discarded. That is, the receiving PDCP layer device can detect duplicate PDCP user data. On the other hand, since there is no PDCP serial number in the PDCP control data and there is no special field, the receiving PDCP layer device cannot perform duplicate detection on the PDCP control data, so the received PDCP control data is considered as new PDCP control data, respectively. And you have to perform receiving processing several times.

When the PDCP layer device control data (PDCP control PDU) is set to a PDCP layer status report (PDCP status report) and header compression protocol (ROHC) reporting information on data that has been successfully received or not received by the PDCP layer device , May include feedback for a header compression protocol capable of transmitting whether header decompression is successful and configuration information as feedback (Interspersed ROHC feedback). In the above, even if the PDCP layer status report is repeatedly received, the data throughput increases, but a major problem may not occur. However, the feedback for the header compression protocol may adversely affect the compression rate of the header compression protocol when more feedback is received than the feedback originally transmitted by the transmitting end.

Therefore, in the present invention, the PDCP layer in the bearer with the packet redundant transmission technology configured to reduce the unnecessary redundant data processing amount of the PDCP layer device at the receiving end, and for smooth operation of the header compression/decompression protocol when header compression is set (ROHC, Robust Header Compression). It proposes a method of processing device control data.

Embodiment 1-1 of processing control data of a PDCP layer device in a packet redundant transmission technology based on a carrier aggregation technology or a packet redundancy transmission technology based on a dual access technology in the present invention is as follows.

1J is a diagram for explaining an embodiment 1-1 of processing control data of a PDCP layer device in a packet redundant transmission technology based on a carrier aggregation technology or a packet redundancy transmission technology based on a dual access technology in the present invention.

In the first embodiment of the present invention, a PDCP status report as shown in FIG. 1j-05 or interspersed ROHC feedback for a header compression protocol as shown in FIG. 1j-10 is performed by a packet redundant transmission technique. It is proposed to introduce a new D field (1j-15) in order to prevent unnecessary data processing from being duplicated when it is repeatedly received at the receiving end. The D field may be defined with 2 bits, for example, and may indicate from which RLC layer device the PDCP layer control data is transmitted. That is, if 00 indicates the PDCP control data transmitted from the first RLC layer device during packet redundancy transmission, and if it is 01, the second RLC with the lowest (or highest) logical channel identifier value among the second RLC layer devices Indicating PDCP control data transmitted from the layer device, and if 10, PDCP control data transmitted from the second RLC layer device having the next lowest (or next highest) logical channel identifier value among the second RLC layer devices Is indicated, and if it is 11, the PDCP control data transmitted from the second RLC layer device having the next lowest (or next highest) logical channel identifier value among the second RLC layer devices may be indicated. Accordingly, the receiving PDCP layer device can perform duplicate detection by using the D field and prevent unnecessary duplicate data processing. That is, it may indicate from which device from among a plurality of RLC layer devices the 2 bits are repeatedly transmitted.

In the above, the PDU type field may indicate whether the PDCP layer control data is a PDCP layer status report or interspersed ROHC feedback for a header compression protocol.

Therefore, when receiving duplicated PDCP layer control data from the receiving end PDCP layer device using the D field proposed in the present invention, if the PDCP layer control data that has already been received by checking the D field, unnecessary data processing is duplicated. Instead, the PDCP layer control data can be immediately discarded.

In the present invention, embodiments 1-2 for processing control data of a PDCP layer device in a packet redundant transmission technology based on a carrier aggregation technology or a packet redundancy transmission technology based on a dual access technology are as follows.

1K is a diagram illustrating a second embodiment of processing control data of a PDCP layer device in a packet redundant transmission technology based on a carrier aggregation technology or a packet redundancy transmission technology based on a dual access technology in the present invention.

In the 1-2 embodiment of the present invention, a PDCP status report as shown in FIG. 1k-05 or interspersed ROHC feedback for a header compression protocol as shown in FIG. 1k-10 is performed by a packet redundant transmission technique. It is proposed to introduce a new SN field (Sequence Number for PDCP Control PDU, 1k-15) in order to prevent unnecessary data processing from being duplicated when redundantly received at the receiving end. The SN field may be defined as 2 bits, 3 bits, or 4 bits, and the serial number of the SN field may be increased by 1 each time one PDCP layer control data is transmitted. The serial number can be allocated starting from 0, increasing to a value of 2^(bit length)-1, and then cycling back to 0. In the above, when increasing the serial number, a separate SN field may be used for PDCP status report or interspersed ROHC feedback for header compression protocol. That is, the SN field for PDCP status report and interspersed ROHC feedback for the header compression protocol may be independently defined and used. Alternatively, for convenience of implementation, the SN field for PDCP status report and the SN field for interspersed ROHC feedback for header compression protocol are not individually distinguished and are shared as one SN field. Each time one of the PDCP layer control data is transmitted, the serial number of the SN field may be increased by 1. In the above, the PDU type field may indicate whether the PDCP layer control data is a PDCP layer status report or interspersed ROHC feedback for a header compression protocol.

When the SN field is used above, when the PDCP layer control data is repeatedly transmitted to the first RLC layer device and the plurality of second RLC layer devices, a serial number value of the same SN field may be allocated and transmitted repeatedly. Therefore, when the PDCP layer control data having the same serial number value is repeatedly received by using the SN field, the receiving PDCP layer device can immediately discard the PDCP layer control data that has been unnecessarily redundantly received without processing.

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 serial number SN field value introduced above. For example, the transmitter defines TX_PDCP_CONTROL_SN and can be used to allocate the serial number of the PDCP layer control data, and the receiver also defines RX_PDCP_CONTROL_SN to check and update the serial number of the received PDCP layer control data, and detect duplicate detection. Can be done. If necessary, the receiving PDCP layer device may drive a PUSH receiving window or a PULL receiving window based on the serial number of the SN field, and may apply a timer.

Therefore, when receiving duplicated PDCP layer control data from the receiving end PDCP layer device using the SN field proposed in the present invention, if the PDCP layer control data has already been received by checking the SN field, unnecessary data processing is duplicated. Instead, the PDCP layer control data can be immediately discarded.

In the present invention, embodiments 1-3 for processing control data of a PDCP layer device in a packet redundant transmission technology based on a carrier aggregation technology or a packet redundancy transmission technology based on a dual access technology are as follows.

In embodiments 1-3 of the present invention, a PDCP status report as shown in FIG. 1K-05 or interspersed ROHC feedback for a header compression protocol as shown in FIG. 1K-10 is performed by a packet redundant transmission technique. It is proposed that the packet redundant transmission technique is not applied to PDCP layer control data in order to prevent unnecessary data processing from being repeatedly performed when redundantly received at the receiving end.

When the base station configures the packet redundant transmission technology for each bearer or logical channel as an RRC message in FIG. 1F and activates the packet redundant transmission technology, or when the packet redundant transmission technology is activated using MAC control information, the terminal It is proposed in Embodiments 1-3 that apply to only PDCP layer user data (PDCP data PDU) and not to PDCP layer control data (PDCP control PDU). In addition, when an RLC layer device (a first RLC layer device or a second RLC layer device) to transmit PDCP layer control data is indicated in an RRC message in FIG. 1f, PDCP layer control data is transmitted only to the RLC layer indicated above. I can. Or, if the packet redundant transmission function is activated for convenience of implementation, the terminal does not apply the packet redundant transmission technology to the PDCP layer control data, and controls the PDCP layer only with the first RLC layer device (primary RLC entity) that is always connected. Data can be transmitted. As described with reference to FIG. 1F, the first RLC layer device may be configured with an RRC message as to which bearer identifier or which RLC layer device corresponds to which logical channel identifier.

Accordingly, as proposed in Embodiments 1-3 of the present invention, the packet redundant transmission technique is not applied to the PDCP layer control data, so that the PDCP layer device at the receiving end may not receive the redundant PDCP layer control data.

The method for applying to PDCP layer control data of the packet redundant transmission technology proposed in Embodiment 1-3 of the present invention is to check the data when applying the redundant packet transmission technology, and to distinguish between PDCP layer user data and PDCP layer control data. It is characterized by performing different data processing.

In Embodiment 1-3, in which the PDCP control data (PDCP control PDU) generated by the PDCP layer device is efficiently processed when the packet redundant transmission technology proposed in the present invention is configured, the PDCP layer device receives the PDCP SDU from the upper layer. PDCP data (PDCP PDU) is configured and transmitted to the first RLC layer device and a plurality of second RLC layer devices in duplicate, and packet duplication is not applied to the PDCP control data generated by the PDCP layer device. , It is characterized in that the transmission is not always transmitted to the second RLC layer device, but only to the first RLC layer device. In the packet redundancy technique, since the first RLC layer device can always be kept in an active state, it is easier in a terminal implementation than transmitting the PDCP control data to a second RLC layer device that can be changed to an active or inactive state. .

In addition, in Embodiment 1-3 of the present invention, since the PDCP layer device transmits only to the first RLC layer device without applying packet duplication to the PDCP control data, the first RLC layer device is If the device is changed to (for example, one RLC layer device among a plurality of second RLC layer devices), after the change, when the newly created PDCP control data is transmitted, transmission to the newly changed first RLC layer device is performed. Must be done.

Therefore, the MAC layer device receives the MAC CE and transfers the first RLC layer device connected to the bearer to which the packet redundancy transmission technology is set to another RLC layer device (e.g., one RLC layer device among a plurality of second RLC layer devices). ), the MAC layer device must inform or indicate the indication information to the PDCP layer device. That is, which RLC layer device (or logical channel identifier) is a new first RLC layer device must be indicated. Then, the PDCP layer device changes or considers the existing first RLC layer device to be the second RLC layer device, sets the newly-instructed RLC layer device to the first RLC layer device, and sets the PDCP control data as described above. Can handle.

In addition, by receiving the RRC message from the RRC layer device, the first RLC layer device connected to the bearer for which the packet redundancy transmission technology is set is transferred to another RLC layer device (for example, one RLC layer device among a plurality of second RLC layer devices). ) Is received, the RRC layer device must inform or indicate the indication information to the PDCP layer device. That is, which RLC layer device (or logical channel identifier) is a new first RLC layer device must be indicated. Then, the PDCP layer device changes or considers the existing first RLC layer device to be the second RLC layer device, sets the newly-instructed RLC layer device to the first RLC layer device, and sets the PDCP control data as described above. Can handle.

When applying the packet redundancy transmission technique proposed in the present invention to transmit redundant data to a plurality of RLC layer devices, if the 1-3 embodiment of processing the PDCP control data proposed in the present invention is applied, if the plurality of RLC If the layer devices operate in the RLC AM mode, they may receive an RLC status report and indicate to an upper PDCP layer device about data for which successful delivery is confirmed. In addition, the PDCP layer device may indicate that it is no longer necessary to transmit redundantly to other plurality of RLC layer devices for PDCP user data that has been successfully transmitted from a certain RLC layer device among the plurality of RLC layer devices. However, the PDCP layer device does not indicate that it is no longer necessary to transmit redundantly to other plurality of RLC layer devices for PDCP control data for which successful delivery is confirmed from a certain RLC layer device among the plurality of RLC layer devices. To do.

When the redundant packet transmission technology proposed in the present invention is applied to transmit redundant data to a plurality of RLC layer devices, the first or second embodiment of processing PDCP control data proposed in the present invention may be applied. In this case, if the plurality of RLC layer devices operate in the RLC AM mode, the RLC status report may be received and data for which successful delivery is confirmed may be indicated to a higher PDCP layer device. In addition, the PDCP layer device may indicate that it is no longer necessary to transmit redundantly to other plurality of RLC layer devices for PDCP user data that has been successfully transmitted from a certain RLC layer device among the plurality of RLC layer devices. However, the PDCP layer device is characterized in that it indicates that it is no longer necessary to transmit redundantly to other plurality of RLC layer devices even for PDCP control data for which successful delivery is confirmed from any RLC layer device among the plurality of RLC layer devices. do.

FIG. 1L is a diagram illustrating a terminal operation in which a PDCP layer proposed in the present invention performs packet duplication based on a carrier aggregation technology or a dual access technology in a next-generation mobile communication system.

In FIG. 1L, when the terminal 1l-01 receives an RRC message as in FIG. 1f, it sets a bearer (DRB or SRB) based on the configuration information received in the message, and a PDCP layer device corresponding to each bearer, RLC Layer devices and MAC layer devices can be configured. If a carrier aggregation technology (Carrier aggregation) or dual connectivity technology (dual connectivity) for a bearer or a PDCP layer device or a logical channel is to be configured, the base station transmits the bearer to the terminal. For, two RLC layer devices to be connected to the PDCP layer device can be set. The two RLC layer devices may be configured as a first RLC layer device (primary RLC entity) and a second RLC layer device (secondary RLC entity), and may be indicated using a logical channel identifier (LCID). When the packet redundant transmission technology is set as described above, the initial state may be activated immediately after setting according to the setting information of the RRC message, or may be immediately deactivated. When the bearer is SRB, it can be immediately activated. In addition, whether to activate or deactivate a packet redundant transmission technology for the bearer may be indicated by the base station through MAC control information. The MAC control information indicating whether to activate or deactivate the packet redundant transmission technology is transmitted by the base station to the terminal, and whether the packet redundant transmission technology is activated or deactivated is control information on the uplink redundant transmission technology. An activation state can be set with the MAC control information (1l-05).

The UE first checks the data to which packet redundancy transmission is applied when redundant transmission of packets from the PDCP layer device on which the packet redundancy transmission technology is enabled (1l-10), and in case of PDCP layer user data (PDCP data PDU) (1l-20 ), the second data processing can be performed. In the second data processing, the PDCP layer user data is transmitted to the first RLC layer device and the second RLC layer device by overlapping packets as described in FIGS. 1G and 1H. If data to which packet redundant transmission is to be applied is checked (11-10) and PDCP layer control data (PDCP control PDU) (11-15), the first data processing may be performed. In the above, the first data processing refers to processing data by applying the first embodiment, the 1-2 embodiment, or the 1-3 embodiment proposed in the present invention.

1M shows the structure of a terminal to which an embodiment of the present invention can be applied.

Referring to the drawing, the terminal includes a radio frequency (RF) processing unit (1m-10), a baseband processing unit (1m-20), a storage unit (1m-30), and a control unit (1m-40). .

The RF processing unit 1m-10 performs a function of transmitting and receiving a signal through a wireless channel such as band conversion and amplification of a signal. That is, the RF processing unit (1m-10) up-converts the baseband signal provided from the baseband processing unit (1m-20) to an RF band signal and then transmits it through an antenna, and the RF band signal received through the antenna Is down-converted to a baseband signal. For example, the RF processing unit 1m-10 may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a digital to analog convertor (DAC), an analog to digital convertor (ADC), and the like. I can. In the drawing, only one antenna is shown, but the terminal may include a plurality of antennas. In addition, the RF processing unit 1m-10 may include a plurality of RF chains. Furthermore, the RF processing unit 1m-10 may perform beamforming. For the beamforming, the RF processing unit 1m-10 may adjust a phase and a magnitude of signals transmitted and received through a plurality of antennas or antenna elements. In addition, the RF processing unit may perform MIMO, and may receive multiple layers when performing the MIMO operation. The RF processing unit 1m-10 may perform reception beam sweeping by appropriately setting a plurality of antennas or antenna elements under control of the controller, or adjust the direction and beam width of the reception beam so that the reception beam cooperates with the transmission beam. have.

The baseband processing unit 1m-20 performs a function of converting between a baseband signal and a bit string according to the physical layer standard of the system. For example, when transmitting data, the baseband processing unit 1m-20 generates complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the baseband processing unit 1m-20 restores a received bit stream through demodulation and decoding of the baseband signal provided from the RF processing unit 1m-10. For example, in the case of the OFDM (orthogonal frequency division multiplexing) method, when transmitting data, the baseband processing unit 1m-20 generates complex symbols by encoding and modulating a transmission bit stream, and subcarriers of the complex symbols After mapping to, OFDM symbols are constructed through an inverse fast Fourier transform (IFFT) operation and a cyclic prefix (CP) insertion. In addition, when receiving data, the baseband processing unit 1m-20 divides the baseband signal provided from the RF processing unit 1m-10 in units of OFDM symbols, and applies a fast Fourier transform (FFT) operation to subcarriers. After reconstructing the mapped signals, the received bit stream is restored through demodulation and decoding.

The baseband processing unit 1m-20 and the RF processing unit 1m-10 transmit and receive signals as described above. Accordingly, the baseband processing unit 1m-20 and the RF processing unit 1m-10 may be referred to as a transmission unit, a reception unit, a transmission/reception unit, or a communication unit. Furthermore, at least one of the baseband processing unit 1m-20 and the RF processing unit 1m-10 may include a plurality of communication modules to support a plurality of different wireless access technologies. In addition, at least one of the baseband processing unit 1m-20 and the RF processing unit 1m-10 may include different communication modules to process signals of different frequency bands. For example, the different radio access technologies may include an LTE network, an NR network, and the like. In addition, the different frequency bands may include a super high frequency (SHF) (eg, 2.5GHz, 5Ghz) band, and a millimeter wave (eg, 60GHz) band.

The storage unit 1m-30 stores data such as a basic program, an application program, and setting information for the operation of the terminal. The storage unit 1m-30 provides stored data at the request of the control unit 1m-40.

The control unit 1m-40 controls overall operations of the terminal. For example, the control unit 1m-40 transmits and receives signals through the baseband processing unit 1m-20 and the RF processing unit 1m-10. In addition, the control unit 1m-40 writes and reads data in the storage unit 1m-40. To this end, the control unit 1m-40 may include at least one processor. For example, the control unit 1m-40 may include a communication processor (CP) that controls communication and an application processor (AP) that controls an upper layer such as an application program.

1N is a block diagram of a TRP in a wireless communication system to which an embodiment of the present invention can be applied.

As shown in the figure, the base station includes an RF processing unit (1n-10), a baseband processing unit (1n-20), a backhaul communication unit (1n-30), a storage unit (1n-40), and a control unit (1n-50). Consists of including.

The RF processing unit 1n-10 performs a function for transmitting and receiving a signal through a wireless channel such as band conversion and amplification of a signal. That is, the RF processing unit 1n-10 up-converts the baseband signal provided from the baseband processing unit 1n-20 to an RF band signal and transmits it through an antenna, and the RF band signal received through the antenna Downconverts to a baseband signal. For example, the RF processing unit 1n-10 may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, and the like. In the drawing, only one antenna is shown, but the first access node may include a plurality of antennas. In addition, the RF processing unit 1n-10 may include a plurality of RF chains. Furthermore, the RF processing unit 1n-10 may perform beamforming. For the beamforming, the RF processing unit 1n-10 may adjust a phase and a magnitude of each of signals transmitted and received through a plurality of antennas or antenna elements. The RF processor may perform a downlink MIMO operation by transmitting one or more layers.

The baseband processing unit 1n-20 performs a function of converting between a baseband signal and a bit stream according to the physical layer standard of the first wireless access technology. For example, when transmitting data, the baseband processing unit 1n-20 generates complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the baseband processing unit 1n-20 restores a received bit stream through demodulation and decoding of the baseband signal provided from the RF processing unit 1n-10. For example, in the case of the OFDM scheme, when transmitting data, the baseband processing unit 1n-20 generates complex symbols by encoding and modulating a transmission bit stream, mapping the complex symbols to subcarriers, and then IFFT OFDM symbols are configured through calculation and CP insertion. In addition, when receiving data, the baseband processing unit 1n-20 divides the baseband signal provided from the RF processing unit 1n-10 in units of OFDM symbols, and reconstructs signals mapped to subcarriers through FFT operation. After that, the received bit stream is restored through demodulation and decoding. The baseband processing unit 1n-20 and the RF processing unit 1n-10 transmit and receive signals as described above. Accordingly, the baseband processing unit 1n-20 and the RF processing unit 1n-10 may be referred to as a transmission unit, a reception unit, a transmission/reception unit, a communication unit, or a wireless communication unit.

The communication unit 1n-30 provides an interface for performing communication with other nodes in the network.

The storage unit 1n-40 stores data such as a basic program, an application program, and setting information for the operation of the main station. In particular, the storage unit 1n-40 may store information on bearers allocated to the connected terminal, measurement results reported from the connected terminal, and the like. In addition, the storage unit 1n-40 may store information that is a criterion for determining whether to provide or stop providing multiple connections to the terminal. In addition, the storage unit 1n-40 provides stored data according to the request of the control unit 1n-50.

The control unit 1n-50 controls overall operations of the main station. For example, the control unit 1n-50 transmits and receives a signal through the baseband processing unit 1n-20 and the RF processing unit 1n-10 or through the backhaul communication unit 1n-30. Further, the control unit 1n-50 writes and reads data in the storage unit 1n-40. To this end, the control unit 1n-50 may include at least one processor.

2A is a diagram illustrating a structure of an LTE system to which the present invention can be applied.

Referring to Figure 2a, as shown, the radio access network of the LTE system is a next-generation base station (Evolved Node B, hereinafter ENB, Node B or base station) (2a-05, 2a-10, 2a-15, 2a-20) and It is composed of MME (2a-25, Mobility Management Entity) and S-GW (2a-30, Serving-Gateway). User Equipment (hereinafter referred to as UE or terminal) 2a-35 accesses an external network through ENBs 2a-05 to 2a-20 and S-GW 2a-30.

In FIG. 2A, ENBs 2a-05 to 2a-20 correspond to the existing node B of the UMTS system. The ENB is connected to the UEs 2a-35 through a radio channel and performs a more complex role than the existing Node B. In the LTE system, all user traffic including real-time services such as VoIP (Voice over IP) through the Internet protocol are serviced through a shared channel, so status information such as buffer status, available transmission power status, and channel status of UEs A device that collects and performs scheduling is needed, and ENB (2a-05 ~ 2a-20) is in charge of this. One ENB typically controls multiple cells. For example, in order to implement a transmission rate of 100 Mbps, the LTE system uses, for example, an orthogonal frequency division multiplexing (OFDM) in a 20 MHz bandwidth as a radio access technology. In addition, an adaptive modulation and coding method (hereinafter referred to as AMC) that determines a modulation scheme and a channel coding rate according to the channel state of the terminal is applied. The S-GW 2a-30 is a device that provides a data bearer, and creates or removes a data bearer under the control of the MME 2a-25. The MME is a device responsible for various control functions as well as mobility management functions for a terminal, and is connected to a plurality of base stations.

2B is a diagram showing a radio protocol structure in an LTE system to which the present invention can be applied.

Referring to Figure 2b, the radio protocol of the LTE system is PDCP (Packet Data Convergence Protocol 2b-05, 2b-40), RLC (Radio Link Control 2b-10, 2b-35), MAC (Medium Access Control 2b-15, 2b-30). PDCP (Packet Data Convergence Protocol) (2b-05, 2b-40) is in charge of operations such as IP header compression/restore. The main functions of PDCP are summarized as follows.

-Header compression and decompression (ROHC only)

-Transfer of user data

-In-sequence delivery of upper layer PDUs at PDCP re-establishment procedure for RLC AM

-Order reordering function (For split bearers in DC (only support for RLC AM): PDCP PDU routing for transmission and PDCP PDU reordering for reception)

-Duplicate detection of lower layer SDUs at PDCP re-establishment procedure for RLC AM

-Retransmission of PDCP SDUs at handover and, for split bearers in DC, of PDCP PDUs at PDCP data-recovery procedure, for RLC AM

-Encryption and decryption function (Ciphering and deciphering)

-Timer-based SDU discard in uplink.

Radio Link Control (hereinafter referred to as RLC) (2b-10, 2b-35) performs an ARQ operation by reconfiguring a PDCP packet data unit (PDU) to an appropriate size. The main functions of RLC are summarized as follows.

-Data transfer function (Transfer of upper layer PDUs)

-ARQ function (Error Correction through ARQ (only for AM data transfer))

-Concatenation, segmentation and reassembly of RLC SDUs (only for UM and AM data transfer)

-Re-segmentation of RLC data PDUs (only for AM data transfer)

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

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

-Error detection function (Protocol error detection (only for AM data transfer))

-RLC SDU discard function (RLC SDU discard (only for UM and AM data transfer))

-RLC re-establishment

The MACs 2b-15 and 2b-30 are connected to several RLC layer devices configured in one terminal, and perform an operation of multiplexing RLC PDUs to MAC PDUs and demultiplexing RLC PDUs from MAC PDUs. The main functions of MAC are summarized as follows.

-Mapping between logical channels and transport channels

-Multiplexing/demultiplexing of MAC SDUs belonging to one or different logical channels into/from transport blocks (TB) delivered to/from the physical layer on transport channels

-Scheduling information reporting function

-HARQ function (Error correction through HARQ)

-Priority handling between logical channels of one UE

-Priority handling between UEs by means of dynamic scheduling

-MBMS service identification

-Transport format selection

-Padding function

The physical layer (2b-20, 2b-25) channel-codes and modulates upper layer data, converts it into OFDM symbols, and transmits it to the radio channel, or demodulates OFDM symbols received through the radio channel and decodes the channel and transmits it to the upper layer. Do the action.

2C is a diagram showing the structure of a next-generation mobile communication system to which the present invention can be applied.

Referring to Figure 2c, as shown, the radio access network of the next-generation mobile communication system (hereinafter NR or 5G) is a next-generation base station (New Radio Node B, hereinafter NR gNB or NR base station) 2c-10 and NR CN (2c). -05, New Radio Core Network). The user terminal (New Radio User Equipment, hereinafter NR UE or terminal) 2c-15 accesses the external network through the NR gNB 2c-10 and the NR CN 2c-05.

In FIG. 2c, the NR gNB 2c-10 corresponds to the eNB (Evolved Node B) of the existing LTE system. The NR gNB is connected to the NR UE (2c-15) through a radio channel and can provide a service superior to that of the existing Node B. In the next-generation mobile communication system, all user traffic is serviced through a shared channel, so a device that collects and schedules status information such as buffer status, available transmission power status, and channel status of UEs is required. (2c-10) is in charge. One NR gNB typically controls multiple cells. In order to implement ultra-high-speed data transmission compared to the current LTE, it may have more than the existing maximum bandwidth, and a beamforming technology may be additionally grafted by using Orthogonal Frequency Division Multiplexing (OFDM) as a wireless access technology. . In addition, an adaptive modulation and coding method (hereinafter referred to as AMC) that determines a modulation scheme and a channel coding rate according to the channel state of the terminal is applied. The NR CN (2c-05) performs functions such as mobility support, bearer setup, and QoS setup. The NR CN is a device responsible for various control functions as well as mobility management functions for a terminal, and is connected to a plurality of base stations. In addition, the next-generation mobile communication system can be interlocked with the existing LTE system, and the NR CN is connected to the MME (2c-25) through a network interface. The MME is connected to the existing eNB (2c-30).

2D is a diagram showing a radio protocol structure of a next-generation mobile communication system to which the present invention can be applied. .

Referring to Figure 2d, the radio protocol of the next-generation mobile communication system is NR SDAP (2d-01, 2d-45), NR PDCP (2d-05, 2d-40), NR RLC (2d-10) in the terminal and the NR base station, respectively. , 2d-35), NR MAC (2d-15, 2d-30).

The main functions of the NR SDAP (2d-01, 2d-45) may include some of the following functions.

- Transfer of user plane data

- QoS flow and data bearer mapping function for uplink and downlink (mapping between a QoS flow and a DRB for both DL and UL)

- Marking QoS flow ID for uplink and downlink (marking QoS flow ID in both DL and UL packets)

- A function of mapping a relective QoS flow to a data bearer for uplink SDAP PDUs (reflective QoS flow to DRB mapping for the UL SDAP PDUs).

For the SDAP layer device, the UE may be configured with an RRC message to set whether to use the header of the SDAP layer device or the function of the SDAP layer device for each PDCP layer device, bearer or logical channel, and the SDAP header. When is set, the UE uses the NAS QoS reflective configuration 1-bit indicator (NAS reflective QoS) and the AS QoS reflective configuration 1-bit indicator (AS reflective QoS) in the SDAP header. Can be instructed to update or reset. The SDAP header may include QoS flow ID information indicating QoS. The QoS information may be used as data processing priority, scheduling information, etc. to support smooth service.

The main functions of NR PDCP (2d-05, 2d-40) may include some of the following functions.

Header compression and decompression (ROHC only)

-Transfer of user data

-In-sequence delivery of upper layer PDUs

-Out-of-sequence delivery of upper layer PDUs

-Order reordering function (PDCP PDU reordering for reception)

-Duplicate detection of lower layer SDUs

-Retransmission of PDCP SDUs

-Encryption and decryption function (Ciphering and deciphering)

-Timer-based SDU discard in uplink.

In the above, the reordering function of the NR PDCP device refers to a function of rearranging the PDCP PDUs received from the lower layer in order based on the PDCP sequence number (SN), and the function of delivering data to the upper layer in the rearranged order. It may include, or may include a function of immediately delivering without considering the order, may include a function of recording lost PDCP PDUs by rearranging the order, and reporting the status of lost PDCP PDUs It may include a function of performing the transmission side, and may include a function of requesting retransmission of lost PDCP PDUs.

The main functions of the NR RLC (2d-10, 2d-35) may include some of the following functions.

-Data transfer function (Transfer of upper layer PDUs)

-In-sequence delivery of upper layer PDUs

-Out-of-sequence delivery of upper layer PDUs

-ARQ function (Error Correction through ARQ)

-Concatenation, segmentation and reassembly of RLC SDUs

-Re-segmentation of RLC data PDUs

-Reordering of RLC data PDUs

-Duplicate detection

-Protocol error detection

-RLC SDU discard function (RLC SDU discard)

-RLC re-establishment

In the above, the in-sequence delivery function of the NR RLC device refers to the function of delivering RLC SDUs received from the lower layer to the upper layer in order, and originally, one RLC SDU is divided into several RLC SDUs and received. If so, it may include a function of reassembling and delivering it, and may include a function of rearranging the received RLC PDUs based on RLC sequence number (SN) or PDCP sequence number (SN), and rearranging the order It may include a function of recording lost RLC PDUs, may include a function of reporting a status of lost RLC PDUs to a transmitting side, and a function of requesting retransmission of lost RLC PDUs. If there is a lost RLC SDU, it may include a function of transferring only RLC SDUs before the lost RLC SDU to a higher layer in order, or if a predetermined timer expires even if there is a lost RLC SDU, the timer It may include a function of delivering all RLC SDUs received before the start of the system in order to the upper layer, or if a predetermined timer expires even if there is a lost RLC SDU, all RLC SDUs received so far are sequentially transferred to the upper layer. It may include the ability to deliver. In addition, RLC PDUs may be processed in the order in which they are received (regardless of the order of serial number and sequence number, in the order of arrival) and delivered to the PDCP device regardless of the order (Out-of sequence delivery). Segments stored in a buffer or to be received in the future may be received, reconstructed into one complete RLC PDU, processed, and delivered to the PDCP device. The NR RLC layer may not include a concatenation function, and the function may be performed by the NR MAC layer or may be replaced with a multiplexing function of the NR MAC layer.

In the above, the out-of-sequence delivery function of the NR RLC device refers to a function of directly delivering RLC SDUs received from the lower layer to the upper layer regardless of the order, and originally, one RLC SDU is When it is divided into SDUs and received, it may include a function of reassembling and transmitting them, and includes a function of storing the RLC SN or PDCP SN of the received RLC PDUs, sorting the order, and recording the lost RLC PDUs. I can.

The NR MACs 2d-15 and 2d-30 may be connected to several NR RLC layer devices configured in one terminal, and the main functions of the NR MAC may include some of the following functions.

-Mapping between logical channels and transport channels

-Multiplexing and demultiplexing function (Multiplexing/demultiplexing of MAC SDUs)

-Scheduling information reporting function

-HARQ function (Error correction through HARQ)

-Priority handling between logical channels of one UE

-Priority handling between UEs by means of dynamic scheduling

-MBMS service identification

-Transport format selection

-Padding function

The NR PHY layer (2d-20, 2d-25) channel-codes and modulates upper layer data, converts it into OFDM symbols, and transmits it to the radio channel, or demodulates and channel-decodes OFDM symbols received through the radio channel to the upper layer. You can perform the transfer operation.

The present invention proposes a method of compressing and decompressing an Ethernet header when using an Ethernet protocol in a next-generation mobile communication system.

2E is a diagram illustrating a procedure for a base station to set Ethernet header protocol related configuration information to a terminal when a terminal proposed in the present invention establishes a connection with a network.

2E is a procedure for establishing a connection with a network by a terminal switching from an RRC idle mode or an RRC inactive mode (RRC Inactive mode or lightly-connected mode) to an RRC connected mode in the present invention. The following describes the procedure for the base station to set the Ethernet protocol related configuration information to the terminal. Specifically, the SDAP layer device or the PDCP layer device indicates whether to perform the Ethernet header compression and decompression procedure, indicates whether to use only in the downlink, only in the uplink, or in both directions, and the Ethernet header protocol The related configuration information can be set only for a terminal with UE capability capable of using the Ethernet protocol or only for a terminal capable of using the Ethernet header compression and decompression procedure. When reporting the terminal capability to the base station, the terminal defines a new indicator, and the indicator may report to the base station whether the terminal can use the Ethernet protocol or the Ethernet header compression and decompression procedure. Also, by setting what type of Ethernet frame or Ethernet header to use for each bearer or logical channel, what fields are configured in the Ethernet header, how many bytes are the size of the Ethernet header, or what are the size of each field of the Ethernet header? It is possible to set whether it is a bit or how the fields of the Ethernet header are configured. In addition, when padding is added to the Ethernet frame, it is possible to indicate whether to use a function that prevents the transmission of padding in an actual wireless link by removing padding at the transmitting end and adding padding at the receiving end.

In FIG. 2e, the base station may send an RRCConnectionRelease message to the terminal when the terminal transmitting and receiving data in the RRC connected mode does not transmit or receive data for a predetermined reason or for a predetermined period of time, thereby switching the terminal to the RRC idle mode or the RRC deactivation mode (2e -01). In the future, the terminal for which the current connection is not established (hereinafter, idle mode UE or INACTIVE UE) performs an RRC connection establishment process or RRC Connection Resume procedure with the base station when data to be transmitted occurs. The terminal establishes uplink transmission synchronization with the base station through a random access process and transmits an RRCConnectionRequest message (in the case of a resume procedure, an RRCResumeRequest message) to the base station (2e-05). In the message, the identifier of the terminal and the reason for establishing a connection (establishmentCause) are stored. The base station transmits an RRCConnectionSetup message (in the case of a resume procedure, an RRCResume message) so that the terminal establishes an RRC connection (2e-10). The message indicates whether to use the Ethernet protocol or the Ethernet header compression and decompression procedure for each logical channel (logicalchannelconfig), bearer, or PDCP device (PDCP-config), or for each SDAP layer device. May contain information. In addition, in more detail, it is possible to indicate whether to use the Ethernet protocol or to use the Ethernet header compression and decompression procedure for a certain IP flow or a QoS flow in each logical channel or bearer or each PDCP device (or SDAP device). Each QoS to determine whether to apply Ethernet protocol or whether to use Ethernet header compression method or not to use Ethernet header compression method or whether SDAP device applies Ethernet protocol to PDCP device by setting information on IP flow or QoS flow that will or will not use Ethernet header compression method. As another method, the SDAP layer device or the PDCP device can self-check each QoS flow and determine whether to apply the Ethernet protocol or the Ethernet header compression method). In addition, if the above indicates whether to apply the Ethernet protocol or the Ethernet header compression method, whether to apply the Ethernet protocol or the identifier for a predefined library or dictionary to be used in the Ethernet header compression method, or the size of the buffer to be used, etc. Can be ordered. In addition, the message may include a command for setting up or releasing whether to apply the Ethernet protocol or to perform the Ethernet header compression method. In addition, when setting whether to apply the Ethernet protocol or to use the Ethernet header compression method above, it can always be set to an RLC AM bearer (a lossless mode with an ARQ function, retransmission function) or an RLC UM bearer, and is different from the header compression protocol (ROHC). It can be set together, and in some cases, it may not be set at the same time. In addition, in the message, the message may indicate whether to use the function of the SDAP layer device or whether to use the SDAP header for each logical channel (logicalchannelconfig), for each bearer or for each PDCP device (PDCP-config), The message may indicate whether to apply ROHC (IP packet header compression) for each logical channel (logicalchannelconfig), for each bearer, or for each PDCP device (PDCP-config), and for uplink and downlink, respectively. Whether or not to apply ROHC can be set with each indicator. In addition, it is possible to set whether to use a user data compression method (UDC) for each logical channel, each bearer, or each PDCP device for an uplink and a downlink, respectively. That is, it can be set to be used in the uplink and not used in the downlink. Conversely, it can be set to be used in the uplink and not in the downlink. It can also be configured to be used in both directions. In addition, an Ethernet header compression procedure and an ROHC header compression procedure may be set simultaneously in the message. In addition, in the above message, an indicator (drbEthHCContinue) to continue use without initializing the Ethernet header compression protocol-related configuration information or context in case of handover (e.g., intra-base station handover) or transition from RRC deactivation mode to RRC connection mode. It can be defined and indicated, and the terminal receiving the indicator can continue to use the Ethernet header compression protocol-related configuration information or context in consideration of the indicator when re-establishing the SDAP layer device or the PDCP layer device. have. In this way, the overhead due to reconfiguration of the Ethernet header compression protocol can be reduced. In addition, the message may instruct to initialize the Ethernet header compression protocol related configuration information or context by defining a new indicator. In addition, the RRC message may set whether to set the SDAP protocol or the SDAP header. Also, in the message, what kind of Ethernet frame or Ethernet header is to be used for each bearer or logical channel, and which fields are configured in the Ethernet header or the size of the Ethernet header in bytes or each field of the Ethernet header. You can set how many bits the size is or how the fields of the Ethernet header are structured. In addition, when padding is added to the Ethernet frame, it is possible to indicate whether to use a function that prevents the transmission of padding in an actual wireless link by removing padding at the transmitting end and adding padding at the receiving end.

In addition, RRC connection configuration information and the like are stored in the message. RRC connection is also called SRB (Signaling Radio Bearer), and is used for transmission and reception of RRC messages, which are control messages between the terminal and the base station. The terminal that has established the RRC connection transmits an RRCConnetionSetupComplete message to the base station (2e-15). If the base station does not know the terminal capabilities of the terminal that is currently establishing a connection, or wants to determine the terminal capabilities, it can send a message asking for the capabilities of the terminal. In addition, the terminal can send a message reporting its capabilities. In the message, whether the terminal can use the Ethernet protocol or the Ethernet header compression and decompression procedure can be indicated, and can be sent including an indicator indicating this. The RRCConnetionSetupComplete message includes a control message called SERVICE REQUEST for requesting the MME to set up a bearer for a predetermined service by the UE. The base station transmits the SERVICE REQUEST message contained in the RRCConnetionSetupComplete message to the MME (2e-20), and the MME determines whether to provide the service requested by the terminal. As a result of the determination, if the terminal determines to provide the requested service, the MME transmits an INITIAL CONTEXT SETUP REQUEST message to the base station (2e-25). The message includes information such as QoS (Quality of Service) information to be applied when setting up a Data Radio Bearer (DRB), and security-related information (for example, Security Key, Security Algorithm) to be applied to the DRB. The base station exchanges a SecurityModeCommand message (2e-30) and a SecurityModeComplete message (2e-35) to configure security with the terminal. When the security configuration is completed, the base station transmits an RRCConnectionReconfiguration message to the terminal (2e-40).

The message indicates whether to use the Ethernet protocol or the Ethernet header compression and decompression procedure for each logical channel (logicalchannelconfig), bearer, or PDCP device (PDCP-config), or for each SDAP layer device. May contain information. In addition, in more detail, it is possible to indicate whether to use the Ethernet protocol or to use the Ethernet header compression and decompression procedure for a certain IP flow or a QoS flow in each logical channel or bearer or each PDCP device (or SDAP device). Each QoS to determine whether to apply Ethernet protocol or whether to use Ethernet header compression method or not to use Ethernet header compression method or whether SDAP device applies Ethernet protocol to PDCP device by setting information on IP flow or QoS flow that will or will not use Ethernet header compression method. As another method, the SDAP layer device or the PDCP device can self-check each QoS flow and determine whether to apply the Ethernet protocol or the Ethernet header compression method). In addition, if the above indicates whether to apply the Ethernet protocol or the Ethernet header compression method, whether to apply the Ethernet protocol or the identifier for a predefined library or dictionary to be used in the Ethernet header compression method, or the size of the buffer to be used, etc. Can be ordered. In addition, the message may include a command for setting up or releasing whether to apply the Ethernet protocol or to perform the Ethernet header compression method. In addition, when setting whether to apply the Ethernet protocol or to use the Ethernet header compression method above, it can always be set to an RLC AM bearer (a lossless mode with an ARQ function, retransmission function) or an RLC UM bearer, and is different from the header compression protocol (ROHC). It can be set together, and in some cases, it may not be set at the same time. In addition, in the message, the message may indicate whether to use the function of the SDAP layer device or whether to use the SDAP header for each logical channel (logicalchannelconfig), for each bearer or for each PDCP device (PDCP-config), The message may indicate whether to apply ROHC (IP packet header compression) for each logical channel (logicalchannelconfig), for each bearer, or for each PDCP device (PDCP-config), and for uplink and downlink, respectively. Whether or not to apply ROHC can be set with each indicator. In addition, it is possible to set whether to use a user data compression method (UDC) for each logical channel, each bearer, or each PDCP device for an uplink and a downlink, respectively. That is, it can be set to be used in the uplink and not used in the downlink. Conversely, it can be set to be used in the uplink and not in the downlink. It can also be configured to be used in both directions.

In addition, an Ethernet header compression procedure and an ROHC header compression procedure may be set simultaneously in the message. In addition, in the above message, an indicator (drbEthHCContinue) to continue use without initializing the Ethernet header compression protocol-related configuration information or context in case of handover (e.g., intra-base station handover) or transition from RRC deactivation mode to RRC connection mode. It can be defined and indicated, and the terminal receiving the indicator can continue to use the Ethernet header compression protocol-related configuration information or context in consideration of the indicator when re-establishing the SDAP layer device or the PDCP layer device. have. In this way, the overhead due to reconfiguration of the Ethernet header compression protocol can be reduced. In addition, the message may instruct to initialize the Ethernet header compression protocol related configuration information or context by defining a new indicator. In addition, the RRC message may set whether to set the SDAP protocol or the SDAP header. Also, in the message, what kind of Ethernet frame or Ethernet header is to be used for each bearer or logical channel, and which fields are configured in the Ethernet header or the size of the Ethernet header in bytes or each field of the Ethernet header. You can set how many bits the size is or how the fields of the Ethernet header are organized. In addition, when padding is added to the Ethernet frame, it is possible to indicate whether to use a function that prevents the transmission of padding in an actual wireless link by removing padding at the transmitting end and adding padding at the receiving end.

In addition, the message includes configuration information of a DRB to which user data is to be processed, and the terminal applies the information to configure the DRB and transmits an RRCConnectionReconfigurationComplete message to the base station (2e-45). The base station that has completed the DRB setup with the terminal transmits an INITIAL CONTEXT SETUP COMPLETE message to the MME (2e-50), and the MME that receives it sends an S1 BEARER SETUP message and an S1 BEARER SETUP RESPONSE message to set up the S-GW and S1 bearers. Exchange the (2e-055, 2e-60). The S1 bearer is a connection for data transmission established between the S-GW and the base station, and corresponds to DRB and 1:1. When all of the above processes are completed, the terminal transmits and receives data to and from the base station through the S-GW (2e-65, 2e-70). This general data transmission process is largely composed of three steps: RRC connection setup, security setup, and DRB setup. In addition, the base station may transmit an RRCConnectionReconfiguration message to the terminal for a predetermined reason in order to refresh, add, or change the configuration (2e-75).

2F is a diagram showing a method for compressing an Ethernet (EthHC) header proposed by the present invention.

In FIG. 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. Data generated by the application layer device can be processed through TCP/IP or UDP corresponding to the network data transport layer, or processed through Ethernet protocol and each header (2f-10, 2f-15, 2f). -20) (higher layer header or Ethernet header) can be configured and delivered to the PDCP layer. When the PDCP layer receives data (PDCP SDU) from an upper layer, the following procedure may be performed.

If the PDCP layer is configured to use a header compression (ROHC) or Ethernet header compression procedure by an RRC message such as 2e-10, 2e-40, or 2e-75 in FIG. 2e, a TCP/IP header with ROHC as shown in 2f-21. Is compressed, and the Ethernet header compression procedure can be performed on the Ethernet header (2f-20) in the PDCP layer device as shown in 2f-22. In addition, a separate EHC (Ethernet header compression), which has a field for indicating whether the Ethernet header is compressed, or a field for indicating whether any fields of the Ethernet header are compressed (is omitted) or not compressed (not omitted). 2f-40) You can configure the header and precede the compressed header. If integrity verification is set, integrity protection is performed on the PDCP header, EHC header, compressed headers and data, and compressed headers and data excluding the EHC header and compressed headers and data, or A PDCP PDU may be configured by performing a ciphering procedure and configuring the PDCP header 2f-30. In the above, the PDCP layer device includes a header compression/decompression device, determines whether to perform header compression on each data as set in the RRC message or not, and uses the header compression/decompression device. The transmitting end compresses the Ethernet header or upper layer header (for example, TCP/IP header) using the header compression device in the transmitting PDCP layer device, and the receiving end compresses the Ethernet header using the header decompression device in the receiving PDCP layer device. Alternatively, header decompression is performed on a higher layer header (for example, a TCP/IP header).

The procedure of FIG. 2F described above can be applied not only when the UE compresses the uplink header but also compresses the downlink data. In addition, the description of the uplink data may be equally applied to downlink data.

The method of performing Ethernet header compression on the Ethernet header proposed in the present invention is a method of reducing the size of the header by omitting fields indicating fixed information and indicating only changed information. Therefore, it can be transmitted by including all header information and configuration information for compression (e.g., identifier (type) per traffic (or service) for Ethernet protocol, serial number per traffic (or service), information on compression rate, etc.) have. And fields corresponding to the unchanged information compared to the total information initially transmitted (e.g., a transmission address field or a destination address field (MAC address), or a preamble field or a start of frame delimiter (SFD) or a frame checksum (FCS)) Alternatively, the size of the header can be reduced by configuring a header including only fields corresponding to changed information without omitting or transmitting the Ethernet type field. In another way, fields that can be compressed are separated from fields that can not be compressed, and only the fields that can be compressed if the values of the fields that can be compressed are not changed when compared with the field values of the complete header initially transmitted. Is compressed (or omitted) and transmitted, and fields that cannot be compressed may be transmitted at all times without compression (or omitting). In addition, even one of the fields capable of compression may be characterized in that the complete header is transmitted again if there is a field value and a changed value of the previously transmitted complete header. In addition, the receiving PDCP layer device may always transmit a feedback indicating that the complete header has been well received to the transmitting PDCP layer device whenever a complete header is received.

2G is a diagram illustrating a method for compressing an Ethernet Header Compression (EthHC) header proposed when an SDAP header or a layer device is configured in the present invention.

In FIG. 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. Data generated in the application layer device can be processed through TCP/IP or UDP corresponding to the network data transport layer, or processed through the Ethernet protocol and processed by the SDAP layer device, and each header (2g-10 , 2g-15, 2g-20) (upper layer header or Ethernet header or SDAP header) can be configured and delivered to the PDCP layer. When the PDCP layer receives data (PDCP SDU) from an upper layer, the following procedure may be performed.

If the PDCP layer is configured to use a header compression (ROHC) or Ethernet header compression procedure by an RRC message such as 2e-10, 2e-40, or 2e-75 in FIG. 2e, a TCP/IP header with ROHC as shown in 2g-21 As shown in 2g-22, the PDCP layer device can perform an Ethernet header compression procedure on the Ethernet header (2g-20) excluding the SDAP header. In addition, a separate EHC (Ethernet header compression), which has a field for indicating whether the Ethernet header is compressed, or a field for indicating whether any fields of the Ethernet header are compressed (is omitted) or not compressed (not omitted). 2g-40) You can compose a header and compose it before the compressed header. If integrity verification is set, integrity protection is performed on SDAP header, PDCP header, EHC header, compressed headers and data, and EHC header and compressed headers and data excluding SDAP header, or SDAP header and EHC A PDCP PDU may be configured by performing a ciphering procedure on compressed headers and data excluding the header, and configuring the PDCP header 2g-30. In the above, the PDCP layer device includes a header compression/decompression device, determines whether to perform header compression on each data as set in the RRC message or not, and uses the header compression/decompression device. The transmitting end compresses the Ethernet header or upper layer header (for example, TCP/IP header) using the header compression device in the transmitting PDCP layer device, and the receiving end compresses the Ethernet header using the header decompression device in the receiving PDCP layer device. Alternatively, header decompression is performed on a higher layer header (for example, a TCP/IP header).

The procedure of FIG. 2G described above can be applied not only when the UE compresses the uplink header but also compresses the downlink data. In addition, the description of the uplink data may be equally applied to downlink data.

The method of performing Ethernet header compression on the Ethernet header proposed in the present invention is a method of reducing the size of the header by omitting fields indicating fixed information and indicating only changed information. Therefore, it can be transmitted by including all header information and configuration information for compression (e.g., identifier (type) per traffic (or service) for Ethernet protocol, serial number per traffic (or service), information on compression rate, etc.) have. And fields corresponding to the unchanged information compared to the total information initially transmitted (e.g., a transmission address field or a destination address field (MAC address), or a preamble field or a start of frame delimiter (SFD) or a frame checksum (FCS)) Alternatively, the size of the header can be reduced by configuring a header including only fields corresponding to changed information without omitting or transmitting the Ethernet type field. In another way, fields that can be compressed are separated from fields that can not be compressed, and only the fields that can be compressed if the values of the fields that can be compressed are not changed when compared with the field values of the complete header initially transmitted. Is compressed (or omitted) and transmitted, and fields that cannot be compressed may be transmitted at all times without compression (or omitting). In addition, even one of the fields capable of compression may be characterized in that the complete header is transmitted again if there is a field value and a changed value of the previously transmitted complete header. In addition, the receiving PDCP layer device may always transmit a feedback indicating that the complete header has been well received to the transmitting PDCP layer device whenever a complete header is received.

2H is a diagram showing another Ethernet (EthHC, Ethernet Header Compression) header compression method proposed when an SDAP header or a layer device is configured in the present invention.

In FIG. 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. Data generated in the application layer device can be processed through TCP/IP or UDP corresponding to the network data transport layer, or processed through the Ethernet protocol and processed by the SDAP layer device, and each header (2h-10 , 2h-15, 2h-20) (upper layer header or Ethernet header or SDAP header) may be configured and transmitted to the PDCP layer. When the PDCP layer receives data (PDCP SDU) from an upper layer, the following procedure may be performed.

If the PDCP layer is configured to use a header compression (ROHC) or Ethernet header compression procedure by an RRC message such as 2e-10, 2e-40, or 2e-75 in FIG. 2e, a TCP/IP header with ROHC as shown in 2h-21. As shown in 2h-22, the PDCP layer device may perform an Ethernet header compression procedure for the SDAP header and the Ethernet header 2h-20. In addition, a separate field having a field indicating whether the SDAP header and the Ethernet header are compressed, or a field indicating whether any fields of the SDAP header or the Ethernet header are compressed (omitted) or not compressed (not omitted) EHC (Ethernet header compression, 2h-40) header can be configured and can be configured before the compressed header. If integrity verification is set, integrity protection is performed on the PDCP header, EHC header, compressed headers (compressed SDAP header or compressed Ethernet header or compressed TCP/IP header) and data, and Compressed headers (compressed SDAP header or compressed Ethernet header or compressed TCP/IP header) and compressed headers excluding data or EHC header (compressed SDAP header or compressed Ethernet header or compressed TCP/IP header) ) And data, and configures the PDCP header (2h-30) to configure the PDCP PDU. In the above, the PDCP layer device includes a header compression/decompression device, determines whether to perform header compression on each data as set in the RRC message or not, and uses the header compression/decompression device. The transmitting end compresses the Ethernet header or upper layer header (for example, TCP/IP header) using the header compression device in the transmitting PDCP layer device, and the receiving end compresses the Ethernet header using the header decompression device in the receiving PDCP layer device. Alternatively, header decompression is performed on a higher layer header (for example, a TCP/IP header).

The procedure of FIG. 2H described above can be applied not only when the UE compresses the uplink header, but also compresses the downlink data. In addition, the description of the uplink data may be equally applied to downlink data.

The method of performing Ethernet header compression on the Ethernet header proposed in the present invention is a method of reducing the size of the header by omitting fields indicating fixed information and indicating only changed information. Therefore, it can be transmitted by including all header information and configuration information for compression (e.g., identifier (type) per traffic (or service) for Ethernet protocol, serial number per traffic (or service), information on compression rate, etc.) have. And fields corresponding to the unchanged information compared to the total information initially transmitted (e.g., a transmission address field or a destination address field (MAC address), or a preamble field or a start of frame delimiter (SFD) or a frame checksum (FCS)) Alternatively, the size of the header can be reduced by configuring a header including only fields corresponding to changed information without omitting or transmitting the Ethernet type field. In another way, fields that can be compressed are separated from fields that can not be compressed, and only the fields that can be compressed if the values of the fields that can be compressed are not changed when compared with the field values of the complete header initially transmitted. Is compressed (or omitted) and transmitted, and fields that cannot be compressed may be transmitted at all times without compression (or omitting). In addition, even one of the fields capable of compression may be characterized in that the complete header is transmitted again if there is a field value and a changed value of the previously transmitted complete header. In addition, the receiving PDCP layer device may always transmit a feedback indicating that the complete header has been well received to the transmitting PDCP layer device whenever a complete header is received.

The above-described Ethernet header compression method is characterized in that the SDAP header can be compressed by applying the same to the SDAP header as well as the Ethernet 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 in many cases. In particular, the QFI field has almost a fixed value, and the RQI field or the RCI field is not used except in that case because the base station indicates when QoS mapping update is required. Accordingly, the method of compressing the Ethernet header may be applied to the SDAP header and may be compressed together with the Ethernet header. When compression is applied to the SDAP header as described above, the SDAP header may be encrypted, and implementation convenience may be achieved by providing the same compression method for the LTE system and the NR system in which the SDAP header can be set.

In addition, the header compression algorithm proposed in the present invention is characterized in that it applies only to PDCP user data (PDCP data PDU) received from an upper layer and not to PDCP control data (PDCP control PDU) generated by a PDCP layer device.

As proposed above of the present invention, in the Ethernet header compression protocol (2f-22), when the PDCP layer device receives data from the upper layer device, it checks the Ethernet header, compresses the Ethernet header using a protocol to compress the Ethernet header, A new header (2f-40) can be defined and used in front of the compressed Ethernet header. In the above, it may be characterized in that encryption is not performed on the new header 2f-40. This is because if the terminal implementation does not perform encryption on the new header (2f-40), the SDAP header is set when data is transmitted to the lower layer device after data processing such as integrity protection or encryption procedure is performed in the PDCP layer device. Alternatively, since the PDCP header or the new header can be spliced together at once, it is possible to facilitate terminal implementation.

As another method, encryption may be performed on the new header 2f-40 above.

This is because if the new header is regarded as data generated by the PDCP layer device and data processing is performed with the data, a data processing procedure can be simplified.

In the case of applying the header compression method proposed in the present invention, in order to decompress the compressed Ethernet header at the receiving side, it is necessary to know which fields are compressed, omitted, or not transmitted. Therefore, when the transmission side compresses the Ethernet header, a new header (eg, EHC header) can be defined and transmitted by attaching it to the front of the compressed Ethernet header. By defining a new first field in the new EthHC header, it is possible to indicate which of the plurality of fields of the Ethernet header is compressed, omitted or not transmitted (for example, a context identifier), and another method As such, the new field may indicate whether a specific field is compressed (or omitted or not transmitted) or not (or included or transmitted) with each bit in a bitmap format. In addition, since the first field can indicate which field is compressed (or omitted) or uncompressed (or included) in the Ethernet header, the receiving side uses the first field to receive the compressed Ethernet. You can calculate the size of the header. That is, it can be determined by subtracting the size of the omitted header field from the original Ethernet header size.

In addition, the first field may have a mapping for indicating the presence or absence of compression (or omission) of all fields of the Ethernet header, but is limited to fields capable of compression (or omission) among the fields of the Ethernet header. Accordingly, it is possible to have a mapping for indicating the presence or absence of compression (or the presence or absence of omission), thereby reducing the overhead of a new EthHC header.

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 not applied with the indicator. The 1-bit indicator may be defined and used in the PDCP header.

In addition, the EHC header may indicate the size or length of the compressed Ethernet header as a second field in order to accurately indicate the size of the compressed Ethernet header (eg, for convenience of implementation). In addition, when the size of the Ethernet header can have a plurality of types, the type of the type may be indicated by the second field. Alternatively, a new third field indicating whether Ethernet header compression is performed or not performed may be defined in the EHC header.

As another method, an identifier indicating each of a plurality of Ethernet header compression methods may be defined and used in the EHC header. In addition, the identifier may indicate an Ethernet header type (type) or a QoS flow identifier. Because a plurality of higher layer headers (eg, various types of Ethernet headers) having different header structures are composed of different fields, the method of compressing and not compressing which fields must be changed accordingly. Because it does. Therefore, for example, a first identifier indicating a header type or content may instruct to apply the first Ethernet header compression method, and the second identifier may instruct to apply the second Ethernet header compression method. Therefore, when a plurality of data streams or QoS flows are mapped to one PDCP layer device, different header compression methods can be applied by applying the new identifier, and different compression decompression methods can be performed at the receiving end by distinguishing them. have.

In the present invention, the Ethernet header compression method can be applied not only to the Ethernet header but also to a general upper layer device header, and the header compression method is referred to as an Ethernet header compression method in the present invention for convenience.

In addition, the configuration of the Ethernet header fields according to the type of the Ethernet header in the above is an RRC message, as described with reference to FIG. 2E, which Ethernet header type or header fields are configured for each bearer. For example, a header compression or decompression method by setting information on the type of upper layer header (for example, Ethernet header type) that can be set in the upper layer device of each bearer, and setting identifiers mapped to the respective header types. Can be applied to. That is, an identifier or indicator indicating the type of Ethernet header may be defined and used in the new header. In addition, a checksum field may be included in the new header so that the receiving end can successfully decompress the Ethernet header. Alternatively, a field instructing to initialize the buffer for compression of the transmitting PDCP layer device and the buffer for decompression of the receiving PDCP layer device may be defined and used. Fields defined in the new header may be defined and used in the PDCP header or SDAP header.

In addition, in the new EHC header, when the PDCP layer device of the receiving end successfully receives data, a field indicating a feedback request may be defined and used. That is, it is possible to reduce overhead by not always sending feedback whenever the PDCP layer device at the receiving end receives a complete header, but transmits feedback only when the PDCP layer device at the transmitting end requests the indicator.

Another Ethernet header compression method may be used based on the new EHC header. For example, when compressing the Ethernet header at the transmitting end, compression is performed in order, and when compression is performed, it is compared with the fields of the previously transmitted Ethernet header, and if the values of the header fields have not changed, compress (omit) the first If the Ethernet header field value is different from the previously transmitted Ethernet header field value, the first field is set accordingly without compression (including) and the Ethernet header compression can be completed. have. In the above order, the order may be determined in ascending order based on the PDCP serial number or COUNT value, and the previous Ethernet header may indicate an Ethernet header corresponding to data having a PDCP serial number or COUNT value as small as 1. . When the receiving end receives the compressed Ethernet header, the first field is checked, and the compressed (omitted) fields in the Ethernet header have the same values as the previously received Ethernet header fields, so they are restored accordingly and not compressed. Fields that are not (included) can be updated newly. The transmitting end and the receiving end may have separate buffers for compressing the Ethernet header, update the buffer each time the Ethernet header is compressed, and update the buffer each time the Ethernet header is decompressed. When the receiving end restores the compressed Ethernet header, the new EthHC header may be removed and the restored data may be delivered to a higher layer. In addition, the transmitter can send the entire Ethernet header information when initially transmitting the Ethernet header. That is, initially, transmission can be performed without performing Ethernet header compression so that the receiving end can grasp all Ethernet header information.

In the following of the present invention, specific embodiments of the Ethernet header compression method are proposed.

2I is a diagram illustrating a specific embodiment 2-1 of the Ethernet header compression method proposed in the present invention.

In the second embodiment of the present invention, a method of compressing an Ethernet header includes a plurality of header fields (2i-31, 2i-32, 2i-33, 2i-34, 2i-35, 2i-36) in the Ethernet header. , 2i-37), the field value does not change compared to the previously transmitted Ethernet header, or the Ethernet header field value that does not need to be transmitted is omitted, and only required fields or valid fields or fields whose field values have changed. This is a selective transmission method. Therefore, among a plurality of fields included in the Ethernet header, for example, the first field (2i-31), the second field (2i-32), the third field (2i-33), and the fourth field ( 2i-34), the first field (2i-31), the second field among the fifth field (2i-35), the sixth field (2i-36), and the seventh field (2i-37) If (2i-32), the fourth field (2i-34), the fifth field (2i-35), and the seventh field (2i-37) can be omitted, or if there is no need to transmit, or previously transmitted If the values of the Ethernet header fields are the same, only the third field 2i-33 and the sixth field 2i-36 are transmitted.

In addition, it is proposed to separately configure a new EHC header so that compression can be performed by applying the above method and decompression at the receiving end. In embodiment 2-1 of the present invention, the new EHC header may have bitmap structures 2i-11 and 2i-12. That is, the bitmap structure may be composed of as many bits as the number of fields of the header structure to which compression is applied, and each bit indicates whether the corresponding header field is compressed or not, with a value of 0 or 1. I can. As another method, the bitmap structure may be composed of as many bits as the number of fields that can be compressed among fields of a header structure to which compression is applied, and whether a header field corresponding to each bit is compressed or not. It can be indicated by a value of 0 or 1.

For example, as shown in Fig. 2i, when the PDCP layer device of the transmitter receives the Ethernet frame (2i-05) from the upper layer device and the Ethernet header compression procedure is set, each field value of the Ethernet header of the first received Ethernet frame Can be stored in a buffer (2i-15) for transmission Ethernet compression. In addition, the first Ethernet frame can be transmitted as it is without the Ethernet header compression. In addition, when a feedback indicating that the entire header has been normally received from the receiving PDCP layer device is received, the Ethernet compression procedure may be started. In the above, a plurality of all headers may be transmitted. For example, a plurality of all headers and data (first data, second data, and subsequent data) may be transmitted until feedback indicating that the entire header has been normally received from the receiving PDCP layer device is received.

If the Ethernet compression procedure is started above, when the next Ethernet frame is received, each field value of the Ethernet header is compared with the field values stored in the transmission buffer for Ethernet compression, and if there is a field having the same value, the corresponding field is omitted. A bit corresponding to or mapped to the omitted field may be set to 1 (or 0), and it may 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 values stored in the transmission buffer for the Ethernet compression, and if there is a field having a different value, the corresponding field is not omitted and corresponds to a field that is not omitted. It is possible to set the bit or the mapped bit to 0 (or 1) and indicate that the field is not omitted.

In addition, if integrity protection is set, integrity protection is performed, an encryption procedure is performed, the new header 2i-10 is configured, a PDCP header is configured, spliced, and transmitted to a lower layer device for transmission.

In the above, the new header 2i-10 may indicate which field of the Ethernet header exists (whether not compressed) or not (compressed) for each bit like a bitmap.

In the above, a new field (for example, a 1-bit indicator) may be defined in the new header 2i-10 to indicate whether the Ethernet header compression procedure has been performed or not. By using the 1-bit indicator, it is possible to immediately indicate a case in which Ethernet header compression has not been performed, so that a new header and an uncompressed upper layer header may not be processed at the receiving end. When the Ethernet header compression algorithm is set, the 1-bit indicator may be defined to be positioned at the beginning of a new EHC header that always exists, so that the receiving end may immediately check whether or not compression is performed. In addition, a 1-bit indicator indicating whether the Ethernet header compression procedure has been performed or not may be defined and used in the SDAP header or PDCP header. If the 1-bit indicator is defined in the SDAP header or the PDCP header, if the Ethernet header compression procedure is not performed, the new header 2i-10 itself for Ethernet header compression can be omitted, thereby reducing overhead. In addition, a case in which all values of 0 (or 1) in the bitmap field are set as a special value indicating an uncompressed complete header and can be used (2i-26), or for compression of a transmitting PDCP layer device. It may be instructed to initialize the buffer and the buffer for decompression of the receiving PDCP layer device.

In Figure 2i, the PDCP layer device or SDAP layer device of the receiving end receives the compressed Ethernet frame (2i-25) from the lower layer device, and when the Ethernet header compression procedure is set, the first received Ethernet with a complete uncompressed header Each field value of the frame's Ethernet header can be checked and stored in the buffer (2i-30) for decompression of the receive Ethernet. In addition, when a complete header (for example, an SDAP header or an Ethernet header) is successfully received, a feedback on this can be transmitted to the transmitting PDCP layer device to start applying Ethernet header compression. The first Ethernet frame can be delivered to an upper layer device without decompressing the Ethernet header. Then, when the Ethernet frame is received, it is decoded and the new EHC header is checked to check whether the header is compressed or not. If not, integrity verification is performed, the EHC header is removed, and data can be transmitted to the upper layer. have. If the new EHC header indicates that the Ethernet header (or SDAP header) is compressed, the field value of the new header (2i-10) for Ethernet compression is checked, and some fields are omitted (compressed) and some fields are not omitted. Compressing is performed by checking whether it is not (not compressed), and performing compression by restoring the fields indicated as omitted (compressed) at the receiving end to field values stored in the receiving buffer 2i-30 for decompression. Restores the previous Ethernet header (decompresses). In addition, since values for fields indicated as not being omitted (not compressed) are new or changed values, the receiving end stores the new or changed values in the receiving buffer for decompression as field values according to the field. In addition, if the decryption is performed, and integrity protection is set, integrity verification is performed. If there is no error, an Ethernet frame with the restored Ethernet header is configured and transmitted to the upper layer device.

In the above, if the field values of the Ethernet header are changed while applying the Ethernet header compression method, the transmitting PDCP layer device indicates to the new EHC header that it has not been compressed, and sends a complete header to initialize the buffer of the receiver, and the values of the complete header again. Can be set to Then, when the receiving PDCP layer device receives the complete uncompressed header, it may transmit a feedback indicating that it has been successfully received to the transmitting PDCP layer device. In the present invention, whenever a receiving PDCP layer device receives a complete uncompressed header, it may be characterized in that it always transmits a feedback indicating that it has been successfully received to the transmitting PDCP layer device. In addition, in the present invention, when receiving a complete uncompressed upper layer header, the receiving PDCP layer device always transmits a feedback that it has been successfully received to the transmitting PDCP layer device, but does not transmit feedback when receiving an uncompressed upper layer header. It characterized in that it may be characterized in that different operations are performed according to whether the received data is compressed by an upper layer.

In the above, a separate new EHC header may have a fixed size (eg, 1 byte or 2 bytes).

In addition, in the above embodiment, the length field of the Ethernet header may also be compressed and decompressed by applying the method described above. As another method, the length field of the Ethernet header may be transmitted without always performing compression.

As another method, the length field of the Ethernet header may be compressed and not transmitted. After decompressing the remaining fields except for the length field in the receiving PDCP layer device, the length of the length field (length Since the length of the field is known as a fixed value), the PDCP layer device may calculate the length of the Ethernet frame by adding it, and then restore and add the length value to the length field of the Ethernet header. In this way, the indication of the length field in the new EHC header can be omitted. Even if the length field value is different for each data, the length field can always be omitted (compressed) in the transmitting PDCP layer device and transmitted, and the length field can be transmitted in the receiving PDCP layer device. By calculating the field value and deriving it as described above, the value of the length field of the Ethernet header can always be restored.

Also, if the Ethernet header compression method and the ROHC (for example, TCP/IP header or UDP header compression method) are set together for a bearer, the length field of the Ethernet header is always compressed and the length field is not transmitted. If not characterized, the receiving PDCP layer device may be characterized by first applying the ROHC decompression method to the received data (for example, PDCP PDU or PDCP SDU) and then applying the Ethernet header decompression method. . This is because when the length field of the Ethernet header is restored by the receiving end (for example, the receiving PDCP layer device), if the length field is restored to the length of data to which header compression is applied by ROHC, the upper layer device (for example, the Ethernet layer device) This is because the length field is incorrectly recovered in the file and data may be truncated or an error may occur. Therefore, when the Ethernet header compression method and the ROHC header compression method are set together, the receiving PDCP layer device first decompresses the upper layer header by applying the ROHC header decompression method, and decompresses the Ethernet header by applying the Ethernet decompression method. can do. And when restoring the length field value of the Ethernet header in the Ethernet header decompression procedure, the size of the length field (for example, after decompressing the remaining fields except the length field, the length field (the length of the goal field is known as fixed) Value) or the length of the Ethernet header after deriving and calculating the length field value in consideration of the size of the decompressed Ethernet header or the length of the data to which ROHC header decompression has been applied (for example, upper layer data or Ethernet frame) A method of restoring and adding the length value (eg, the length of data restored by decompression of the ROHC header) to the field may be used In this way, an indication of the length field in the new EHC header can be omitted, and , Even if the length field value is different for each data, the transmitting PDCP layer device can always omit (compress) the length field and transmit it, and the receiving PDCP layer device calculates the length field value and induces the length field value of the Ethernet header as above. Can always be restored.

In addition, in the new EHC header, when the PDCP layer device of the receiving end successfully receives data, a field indicating a feedback request may be defined and used. That is, it is possible to reduce overhead by not always sending feedback whenever the PDCP layer device at the receiving end receives a complete header, but transmits feedback only when the PDCP layer device at the transmitting end requests the indicator.

In the new EHC header, an identifier indicating each of a plurality of Ethernet header compression methods together with a bitmap field may be defined and used. In addition, the identifier may indicate an Ethernet header type (type) or a QoS flow identifier. Because a plurality of higher layer headers (eg, various types of Ethernet headers) having different header structures are composed of different fields, the method of compressing and not compressing which fields must be changed accordingly. This is because the bitmap field corresponding to the fields of the higher layer header type must be applied accordingly. Therefore, for example, a first identifier indicating a header type or content instructs to apply a first bitmap field or bitmap mapping, and a second identifier to apply a second bitmap field or bitmap mapping. I can instruct. Therefore, when a plurality of data streams or QoS flows are mapped to one PDCP layer device, different header compression methods can be applied by applying the new identifier, and different compression decompression methods can be performed at the receiving end by distinguishing them. have. In this case, in order to apply different header compression and decompression methods to data streams having different upper layer header structures, higher layer header field values are independently transmitted for each higher layer header structure. Buffer or reception of PDCP layer device It may be characterized in that it is stored in the buffer of the PDCP layer device.

2J is a diagram illustrating a specific embodiment 2-2 of the Ethernet header compression method proposed by the present invention.

In the second embodiment of the present invention, when a plurality of data streams or QoS flows are mapped to one bearer or one PDCP layer device, different data streams or QoS flows having header structures of different upper layer devices A method that can apply header compression and decompression methods is applied.

In the 2-2 embodiment, a unique header compression and decompression method fixed for each header structure (eg, an Ethernet header structure or an SDAP header structure) of different upper layer devices may be applied. For example, fields that can be compressed (can be omitted) and fields that cannot be compressed (cannot be omitted) can be defined in the first higher layer header structure 2j-01. In addition, fields that can be compressed (omitted) and fields that cannot be compressed (cannot be omitted) can be defined in the second higher layer header structure 2j-02. In addition, by configuring an identifier (CTI field, Compressed Type Identifier, 2j-10) indicating the different higher layer header structures in the new EHC header, it is possible to indicate to the receiving PDCP layer device which upper layer device header structure is compressed and how. have.

For example, the transmitting PDCP layer device stores the upper layer header field values of the data having the first upper layer header structure received from the upper layer in the transmission buffer 2j-15, and does not perform compression when initially transmitted. When data including a complete header is transmitted, and a feedback indicating that the complete header information has been successfully received is received from a receiving PDCP layer device, the header compression method can be applied. That is, if the field values of fields that can be compressed among the values of the higher layer header field values of the next received data are the same as the field values stored in the transmission buffer, all the fields that can be compressed are compressed and fields that cannot be compressed are It can be configured as it is and transmitted by setting an identifier indicating the first higher layer header structure and an indicator (field C, compression field, 2j-10) indicating that compression has been performed in a new EHC header.

If the receiving PDCP layer device indicates that the higher layer header is not compressed in the new EHC header of the received data, it is regarded as a complete higher layer header (if the field value of one or more fields among fields that can be compressed is changed. , The transmitting PDCP layer device may instruct to update the field values stored in the buffer of the receiving PDCP layer device by transmitting the complete upper layer header without performing compression on the higher layer header.) Field values stored in the buffer 2j-30 of the receiving PDCP layer apparatus may be updated with the field values, and a feedback indicating that the reception was successfully received may be transmitted to the transmitting PDCP layer apparatus.

If the receiving PDCP layer device indicates that the higher layer header is compressed in the new EHC header of the received data, it checks the identifier indicating the type of the higher layer header included in the new EHC header, and the higher layer indicated by the identifier Fields defined to be compressed in the header structure can be recovered based on field values stored in the receive buffer. For example, the identifier indicating the type of the higher layer header may indicate the first higher layer header structure (fields that can be compressed and decompressed in the first higher layer header structure), or the second higher layer header structure. A hierarchical header structure (fields that can be compressed and decompressed in the second higher hierarchical header structure) may be indicated.

In the second embodiment of the present invention, the receiving PDCP layer device always transmits a feedback indicating that it has been successfully received to the transmitting PDCP layer device whenever a complete uncompressed header is received. In addition, in the present invention, when receiving a complete uncompressed upper layer header, the receiving PDCP layer device always transmits a feedback that it has been successfully received to the transmitting PDCP layer device, but does not transmit feedback when receiving an uncompressed upper layer header. It characterized in that it may be characterized in that different operations are performed according to whether the received data is compressed by an upper layer.

In addition, in the second embodiment, in order to apply different header compression and decompression methods to data streams having different upper layer header structures, higher layer header field values are independently transmitted for each higher layer header structure. It may be characterized in that it is stored in a buffer of a device or a buffer of a receiving PDCP layer device.

In the new EHC header, an identifier indicating each of a plurality of Ethernet header compression methods and an indicator field indicating whether compression has been performed may be defined and used. In addition, the identifier may indicate an Ethernet header type (type) or a QoS flow identifier. Because a plurality of higher layer headers (eg, various types of Ethernet headers) having different header structures are composed of different fields, the methods for compressing and not compressing which fields are different accordingly. Because it has to be applied. Therefore, for example, a first identifier indicating a header type or content may instruct to apply the first Ethernet header compression method, and the second identifier may instruct to apply the second Ethernet header compression method. Therefore, when a plurality of data streams or QoS flows are mapped to one PDCP layer device, different header compression methods can be applied by applying the new identifier, and different compression decompression methods can be performed at the receiving end by distinguishing them. have.

In the above, when the transmitting PDCP layer device receives a feedback indicating that the entire header has been normally received from the receiving PDCP layer device, it may start to apply the Ethernet compression procedure. In the above, a plurality of all headers may be transmitted. For example, a plurality of all headers and data (first data, second data, and subsequent data) may be transmitted until feedback indicating that the entire header has been normally received from the receiving PDCP layer device is received.

In the above, a new field (for example, a 1-bit indicator) can be defined in the new header (2g-10) to indicate whether the Ethernet header compression procedure has been performed or not. However, the Ethernet header compression is not performed with the 1-bit indicator. If not, it is possible to immediately indicate that a new header and an uncompressed upper layer header are not processed at the receiving end. When the Ethernet header compression algorithm is set, the 1-bit indicator may be defined to be positioned at the beginning of a new EHC header that always exists, so that the receiving end may immediately check whether or not compression is performed. In addition, a 1-bit indicator indicating whether the Ethernet header compression procedure has been performed or not may be defined and used in the SDAP header or PDCP header. If the 1-bit indicator is defined in the SDAP header or the PDCP header, if the Ethernet header compression procedure is not performed, a new header (2g-10) for Ethernet header compression itself can be omitted, thereby reducing overhead. In addition, a case in which all values of 0 (or 1) in the bitmap field are set as a special value indicating a complete uncompressed header and can be used, or a buffer for compression of a transmitting PDCP layer device and a receiving PDCP layer It may also instruct you to initialize the buffer for decompressing the device.

In Figure 2g, the PDCP layer device or SDAP layer device of the receiving end receives the compressed Ethernet frame (2g-25) from the lower layer device, and when the Ethernet header compression procedure is set, the first received Ethernet with a complete uncompressed header Each field value of the frame's Ethernet header can be checked and stored in a buffer (2g-30) for decompression of the receive Ethernet. In addition, when a complete header (for example, an SDAP header or an Ethernet header) is successfully received, a feedback on this can be transmitted to the transmitting PDCP layer device to start applying Ethernet header compression. The first Ethernet frame can be delivered to an upper layer device without decompressing the Ethernet header. Then, when the Ethernet frame is received, it is decoded and the new EHC header is checked to check whether the header is compressed or not. If not, integrity verification is performed, the EHC header is removed, and data can be transmitted to the upper layer. have. If the new EHC header indicates that the Ethernet header (or SDAP header) is compressed, the field value of the new header (2g-10) for Ethernet compression is checked and some fields are omitted (compressed) and some fields are not omitted. It checks whether it is not (not compressed), and restores the Ethernet header before compression is performed by restoring the fields indicated as omitted (compressed) to the field values stored in the receiving buffer for decompression at the receiving end. Do (it performs decompression). In addition, since values for fields indicated as not being omitted (not compressed) are new or changed values, the receiving end stores the new or changed values in the receiving buffer for decompression as field values according to the field. In addition, if the decryption is performed, and integrity protection is set, integrity verification is performed. If there is no error, an Ethernet frame with the restored Ethernet header is configured and transmitted to the upper layer device.

In the above, if the field values of the Ethernet header are changed while applying the Ethernet header compression method, the transmitting PDCP layer device indicates to the new EHC header that it has not been compressed, and sends a complete header to initialize the buffer of the receiver, and the values of the complete header again. Can be set to Then, when the receiving PDCP layer device receives the complete uncompressed header, it may transmit a feedback indicating that it has been successfully received to the transmitting PDCP layer device. In the present invention, whenever a receiving PDCP layer device receives a complete uncompressed header, it may be characterized in that it always transmits a feedback indicating that it has been successfully received to the transmitting PDCP layer device. In addition, in the present invention, when receiving a complete uncompressed upper layer header, the receiving PDCP layer device always transmits a feedback that it has been successfully received to the transmitting PDCP layer device, but does not transmit feedback when receiving an uncompressed upper layer header. It characterized in that it may be characterized in that different operations are performed according to whether the received data is compressed by an upper layer.

In the above, a separate new EHC header may have a fixed size (eg, 1 byte or 2 bytes).

In addition, in the above embodiment, the length field of the Ethernet header may also be compressed and decompressed by applying the method described above. As another method, the length field of the Ethernet header may be transmitted without always performing compression.

As another method, the length field of the Ethernet header may be compressed and not transmitted. After decompressing the remaining fields except for the length field in the receiving PDCP layer device, the length of the length field (length Since the length of the field is known as a fixed value), the PDCP layer device may calculate the length of the Ethernet frame by adding it, and then restore and add the length value to the length field of the Ethernet header. In this way, the indication of the length field in the new EHC header can be omitted. Even if the length field value is different for each data, the length field can always be omitted (compressed) in the transmitting PDCP layer device and transmitted, and the length field can be transmitted in the receiving PDCP layer device. By calculating the field value and deriving it as described above, the value of the length field of the Ethernet header can always be restored.

Also, if the Ethernet header compression method and the ROHC (for example, TCP/IP header or UDP header compression method) are set together for a bearer, the length field of the Ethernet header is always compressed and the length field is not transmitted. If not characterized, the receiving PDCP layer device may be characterized by first applying the ROHC decompression method to the received data (for example, PDCP PDU or PDCP SDU) and then applying the Ethernet header decompression method. . This is because when the length field of the Ethernet header is restored by the receiving end (for example, the receiving PDCP layer device), if the length field is restored to the length of data to which header compression is applied by ROHC, the upper layer device (for example, the Ethernet layer device) This is because the length field is incorrectly recovered in the file and data may be truncated or an error may occur. Therefore, when the Ethernet header compression method and the ROHC header compression method are set together, the receiving PDCP layer device first decompresses the upper layer header by applying the ROHC header decompression method, and decompresses the Ethernet header by applying the Ethernet decompression method. can do. And when restoring the length field value of the Ethernet header in the Ethernet header decompression procedure, the size of the length field (for example, after decompressing the remaining fields except the length field, the length field (the length of the goal field is known as fixed) Value) or the length of the Ethernet header after deriving and calculating the length field value in consideration of the size of the decompressed Ethernet header or the length of the data to which ROHC header decompression has been applied (for example, upper layer data or Ethernet frame) A method of restoring and adding the length value (eg, the length of data restored by decompression of the ROHC header) to the field may be used In this way, an indication of the length field in the new EHC header can be omitted, and , Even if the length field value is different for each data, the transmitting PDCP layer device can always omit (compress) the length field and transmit it, and the receiving PDCP layer device calculates the length field value and induces the length field value of the Ethernet header as above. Can always be restored.

In addition, in the new EHC header, when the PDCP layer device of the receiving end successfully receives data, a field indicating a feedback request may be defined and used. That is, it is possible to reduce overhead by not always sending feedback whenever the PDCP layer device at the receiving end receives a complete header, but transmits feedback only when the PDCP layer device at the transmitting end requests the indicator.

Specific embodiments 2-3 of the Ethernet header compression method proposed by the present invention are as follows.

In Embodiment 2-3 of the present invention, the header compression and decompression method proposed in Embodiment 2-2 can be applied in the same manner. However, when the base station maps only one data stream or QoS flow to one bearer or one PDCP layer device with an RRC message, it is not necessary to distinguish between data streams or QoS flows having header structures of different upper layer devices. . That is, there is no need for identifiers indicating different upper layer header structures or different higher layer compression methods in the new EHC header. This is because one higher layer header structure or header compression method will be set in one PDCP layer device.

Therefore, in the 2-3rd embodiment of the present invention, only a field indicating whether the higher layer header is compressed or uncompressed is defined and set in the new EHC header or PDCP header, and the method proposed in the second embodiment is applied as it is. Accordingly, the transmitting PDCP layer device may perform compression on the upper layer device header, and the receiving PDCP layer device may perform compression decompression.

In the present invention, a detailed structure of feedback that can be used in embodiments of the above-proposed higher layer header (Ethernet header) compression method is proposed.

2K is a diagram illustrating embodiments of a feedback structure that can be used in the higher layer header compression method proposed in the present invention.

In FIG. 2K, it is proposed to define new PDCP control data (PDCP control PDU) by setting a new PDU type field value as the first feedback structure 2k-01. When the upper layer compression and decompression method (or protocol) is set in the receiving PDCP layer device, the new PDCP control data is transmitted whenever the upper layer header of the received data is not compressed and a complete upper layer header is received (or feedback When instructed by the transmitting PDCP layer device), it may be configured to be triggered and transmitted to the transmitting PDCP layer device. The new PDCP control data may indicate by defining an indicator that the transmitting PDCP layer apparatus has successfully received or failed to receive a complete upper layer header transmitted without compression. As another method, the new PDCP control data itself may indicate that the transmitting PDCP layer apparatus has successfully received the complete higher layer header transmitted without compression. Based on the above feedback, the transmitting PDCP layer device may determine the timing of applying the compression method of the higher layer device.

In addition, the new PDCP control data may be used to transmit feedback to the Ethernet compression protocol of the transmitter when an Ethernet decompression failure occurs (for example, a checksum error occurs). That is, it can indicate that Ethernet decompression has failed (or that a checksum error has occurred) in the newly defined PDCP control data, and indicates that initialization of the transmission buffer for compression of the Ethernet header at the transmitting end should be performed. You may.

In FIG. 2K, it is proposed to define a new PDCP control data (PDCP control PDU) by setting a new PDU type field value as a second feedback structure (2k-02). When the upper layer compression and decompression method (or protocol) is set in the receiving PDCP layer device, the new PDCP control data is transmitted whenever the upper layer header of the received data is not compressed and a complete upper layer header is received (or feedback When instructed by the transmitting PDCP layer device), it may be configured to be triggered and transmitted to the transmitting PDCP layer device. The new PDCP control data may indicate by defining an indicator that the transmitting PDCP layer apparatus has successfully received or failed to receive a complete upper layer header transmitted without compression. As another method, the new PDCP control data itself may indicate that the transmitting PDCP layer apparatus has successfully received the complete higher layer header transmitted without compression.

In addition, by defining and indicating a new field (CTI) indicating the type of the upper layer header or the type of the higher layer header compression method, the transmitting PDCP layer device can use the new PDCP control data for a certain upper layer header or a higher layer header compression method. It can be indicated by defining an indicator that the complete upper layer header transmitted without compression has been successfully received or has not been received. As another method, the new PDCP control data itself has successfully received the complete upper layer header transmitted by the transmitting PDCP layer device without compression for the higher layer header or higher layer header compression method indicated by the new CTI field. You can also instruct.

Based on the above feedback, the transmitting PDCP layer device may determine the timing of applying the compression method of the higher layer device.

In addition, the new PDCP control data may be used to transmit feedback to the Ethernet compression protocol of the transmitter when an Ethernet decompression failure occurs (for example, a checksum error occurs). That is, in the newly defined PDCP control data, it may indicate that Ethernet decompression has failed (or that a checksum error has occurred) for a certain upper layer header or higher layer header compression method. It may also indicate that initialization of the transmit buffer for the device should be performed.

In FIG. 2K, it is proposed to define a new PDCP control data (PDCP control PDU) by setting a new PDU type field value as a third feedback structure (2k-03). When the upper layer compression and decompression method (or protocol) is set in the receiving PDCP layer device, the new PDCP control data is transmitted whenever the upper layer header of the received data is not compressed and a complete upper layer header is received (or feedback When instructed by the transmitting PDCP layer device), it may be configured to be triggered and transmitted to the transmitting PDCP layer device. The new PDCP control data may indicate by defining an indicator that the transmitting PDCP layer apparatus has successfully received or failed to receive a complete upper layer header transmitted without compression. As another method, the new PDCP control data itself may indicate that the transmitting PDCP layer apparatus has successfully received the complete higher layer header transmitted without compression.

In addition, a new field indicating the PDCP serial number (PDCP SN) is defined and indicated to transmit a certain PDCP serial number as the new PDCP control data. The complete upper layer header transmitted by the PDCP layer device without compression has been successfully received or received. It can be indicated by defining an indicator that it was not possible. As another method, the new PDCP control data itself may indicate that the transmission PDCP layer device has successfully received the complete higher layer header transmitted without compression for the data indicated by the new PDCP serial number field.

Based on the above feedback, the transmitting PDCP layer device may determine the timing of applying the compression method of the higher layer device.

In addition, the new PDCP control data may be used to transmit feedback to the Ethernet compression protocol of the transmitter when an Ethernet decompression failure occurs (for example, a checksum error occurs). That is, in the newly defined PDCP control data, it is possible to indicate that Ethernet decompression has failed (or that a checksum error has occurred) for the data of a certain PDCP serial number, and the transmission buffer for compressing the Ethernet header of the transmitting end It can also indicate that the initialization of the should be performed.

In FIG. 2K, it is proposed to define a new PDCP control data (PDCP control PDU) by determining a new PDU type field value using the fourth feedback structure (2k-04). When the upper layer compression and decompression method (or protocol) is set in the receiving PDCP layer device, the new PDCP control data is transmitted whenever the upper layer header of the received data is not compressed and a complete upper layer header is received (or feedback When instructed by the transmitting PDCP layer device), it may be configured to be triggered and transmitted to the transmitting PDCP layer device. The new PDCP control data may indicate by defining an indicator that the transmitting PDCP layer apparatus has successfully received or failed to receive a complete upper layer header transmitted without compression. As another method, the new PDCP control data itself may indicate that the transmitting PDCP layer apparatus has successfully received the complete higher layer header transmitted without compression.

In addition, by defining and indicating a new field (COUNT) indicating the COUNT value, for a certain COUNT value as the new PDCP control data, the transmitting PDCP layer device has successfully received or failed to receive the complete upper layer header transmitted without compression. Can be indicated by defining an indicator. As another method, the new PDCP control data itself may indicate that the transmission PDCP layer apparatus has successfully received the complete higher layer header transmitted without compression for the data indicated by the new COUNT value field.

Based on the above feedback, the transmitting PDCP layer device may determine the timing of applying the compression method of the higher layer device.

In addition, the new PDCP control data may be used to transmit feedback to the Ethernet compression protocol of the transmitter when an Ethernet decompression failure occurs (for example, a checksum error occurs). In other words, it is possible to indicate that Ethernet decompression has failed (or that a checksum error has occurred) for data of a certain COUNT value in the newly defined PDCP control data. It can also indicate that initialization should be performed.

In FIG. 2K, it is proposed to use a PDCP status report as feedback among PDCP control data (PDCP control PDUs) as a fifth feedback structure (2k-05). When the upper layer compression and decompression method (or protocol) is set in the receiving PDCP layer device, the PDCP status report is performed whenever the upper layer header of the received data is not compressed and a complete upper layer header is received (or feedback is provided). When instructed by the transmitting PDCP layer device), it may be configured to be triggered and transmitted to the transmitting PDCP layer device. The PDCP status report may indicate by defining an indicator that the transmitting PDCP layer device has successfully received or failed to receive a complete upper layer header transmitted without compression.

In addition, the PDCP status report may indicate that the transmitting PDCP layer device has successfully received or failed to receive a complete upper layer header transmitted without compression for a certain COUNT value. That is, the FMC field indicates the first COUNT value that has not yet been transferred from the receiving PDCP layer device to the upper layer, and the bitmap fields after that are mapped by 1 bit for COUNT values greater than the first COUNT value between 0 or 1 It can indicate whether or not the value of is successfully received.

In addition, the PDCP status report may be used to deliver feedback to the Ethernet compression protocol of the transmitter when an Ethernet decompression failure occurs (for example, a checksum error occurs). In other words, it is possible to indicate that Ethernet decompression has failed (or that a checksum error has occurred) for data of a certain COUNT value in the newly defined PDCP control data. It can also indicate that initialization should be performed. That is, the FMC field indicates the first COUNT value that has not yet been transferred from the receiving PDCP layer device to the upper layer, and bitmap fields after that may indicate COUNT values greater than the first COUNT value between using 1 bit. .

In the present invention, a sixth feedback structure proposes to define a new field in a PDCP header or a new EHC header of data transmitted from a receiving PDCP layer device to a transmitting PDCP layer device and use it as feedback. When the upper layer compression and decompression method (or protocol) is set in the receiving PDCP layer device, the new field of the PDCP header or EHC header is when the upper layer header of the received data is not compressed and a complete upper layer header is received. It may be characterized in that it is set each time (or when feedback is indicated by the transmitting PDCP layer apparatus) and transmitted to the transmitting PDCP layer apparatus. The new field may indicate that the transmitting PDCP layer device has successfully received or failed to receive a complete higher layer header transmitted without compression.

Using 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 invention, the receiving end (for example, the receiving PDCP When the layer device) indicates to the sender that a header decompression failure has occurred, or that the receiver has not successfully received data (for example, an Ethernet frame) with a complete header (for example, a complete Ethernet header). , The transmitting end (eg, a transmitting PDCP layer device) may transmit data including a complete header to the receiving end.

In the present invention, the complete header transmitted by the transmitter (for example, the transmitting PDCP layer device) includes uncompressed Ethernet header fields, values corresponding to the fields, and configuration information for compression of the Ethernet header, such as Ethernet header compression. It is possible to indicate an identifier for or a header including mapping information between a field for field compression and an identifier (or indicator).

In the present invention, as a method for allowing the transmitting end (for example, the transmitting PDCP layer device) to start the Ethernet header compression procedure faster, the transmitting PDCP layer device transmits a plurality of data having a complete header to the receiving end, and the Even if the same feedback is not received from the receiving end (for example, the receiving PDCP layer device), the transmitting PDCP layer device may apply the Ethernet header compression procedure to the next data, start, and perform transmission. Because when the RLC layer device connected to the transmitting PDCP layer device operates in the AM mode, data with the complete header will not be lost, and even if the RLC layer device operates in the UM mode, packet redundancy technology is applied to increase reliability. Because there is. In the above, when the transmitting end transmits a plurality of data having a complete header to the receiving end, the number of pieces to be transmitted may be set as an RRC message, or may be appropriately set in the implementation.

In the present invention, the operation of the transmitting PDCP layer device when the higher layer compression and decompression method (Ethernet header compression method) or ROHC (higher layer compression and decompression method such as TCP/IP or UDP) is set We propose the operation of the receiving PDCP layer device.

The operation of a transmitting PDCP layer apparatus of a terminal or a base station proposed in the present invention is as follows.

When processing data, the transmitting PDCP layer apparatus uses a first COUNT variable that maintains a COUNT value to be allocated to the next transmitted data, and the first COUNT variable may be named TX_NEXT.

The operation of the transmitting PDCP layer device proposed in the present invention is as follows.

- When the transmitting PDCP layer device receives data (for example, PDCP SDU) from an upper layer, it activates the PDCP data discard timer, and discards the data when the timer expires.

- Then, a COUNT value corresponding to TX_NEXT is allocated to the data received from the upper layer. The TX_NEXT may be set to 0 as an initial value, and TX_NEXT maintains a COUNT value for the next data to be transmitted (PDCP SDU).

- If a header compression protocol (ROHC) is set for the transmitting PDCP layer device, header compression is performed on the data.

- If the upper layer header compression protocol (Ethernet header compression method, EthHC) is set for the transmitting PDCP layer device

■ If the data received from the upper layer is the first data received after the Ethernet header compression method is set

■ Alternatively, if one of the field values of fields that can be compressed 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 is different from the previously transmitted Ethernet header field values. if)

■ Or, if feedback has not yet been received from the receiving PDCP layer device for data having previously transmitted uncompressed complete upper layer headers (Ethernet headers) that have been successfully received

◆ The transmitting PDCP layer device does not perform the Ethernet header compression until a feedback indicating that the uncompressed complete upper layer header (Ethernet header) has been successfully received from the receiving PDCP layer device.

■ If feedback is received from the receiving PDCP layer device indicating that it has been successfully received for previously transmitted data with a complete, uncompressed upper layer header (Ethernet header),

◆ The transmitting PDCP layer device compresses data received from an upper layer by applying an Ethernet header compression method.

- If integrity protection is set for the transmitting PDCP layer device, a PDCP header is generated, and integrity protection is performed using a PDCP header and a security key for the data and a COUNT value of TX_NEXT allocated to the data.

- Then, an encryption procedure is performed for the data using a security key and a COUNT value of TX_NEXT allocated to the data. In addition, in the COUNT value of the TX_NEXT variable, the lower LSBs of the length of the PDCP serial number are set as PDCP serial numbers.

- Then, the COUNT value of the TX_NEXT variable is increased by 1, and the data processed above is spliced together with the PDCP header to the lower layer and transmitted to the lower layer.

The operation of the receiving PDCP layer apparatus of the terminal or the base station proposed in the present invention is as follows.

The receiving PDCP layer device uses the length of the PDCP serial number (e.g. 12 bits or 18 bits) set by the base station as RRC, checks the PDCP serial number of the received data (e.g. PDCP PDU), and checks the reception window. Drive. In the above, the reception window is set to the size of half of the PDCP serial number space (for example, 2^(PDCP SN length-1)), and is used to distinguish valid data. That is, data received outside the reception window is determined as invalid data and discarded. The reason why data arrives outside the reception window is that data arrives very late in the lower layer device due to retransmission of the RLC layer device or HARQ retransmission of the MAC layer device. In addition, the receiving PDCP layer device drives a PDCP reordering timer (t-Reordering) together with the receiving window.

In the above, the PDCP reorder timer is triggered if a PDCP serial number gap occurs based on the PDCP serial number in the receiving PDCP layer device, and data corresponding to the PDCP serial number gap until the PDCP reorder timer expires. If is not arrived, data is transferred to the upper layer device in ascending order of the PDCP serial number or COUNT value, and the receiving window is moved. Therefore, if data corresponding to the PDCP serial number gap arrives after the PDCP reorder timer expires, it is discarded because it is not data in the reception window.

A detailed procedure of the receiving PDCP layer device briefly described above is as follows.

The operation of a receiving PDCP layer apparatus of a terminal or a base station proposed in the present invention is as follows.

The receiving PDCP layer device maintains and manages three COUNT variables when processing received data. The receiving PDCP layer device uses a second COUNT variable that maintains a COUNT value of data expected to be received next (for example, PDCP SDU) when processing received data, and the second COUNT variable is It can be named RX_NEXT. When processing the received data, the receiving PDCP layer device uses a third COUNT variable that maintains a COUNT value of the first data (for example, PDCP SDU) that has not been transferred to an upper layer, and the third COUNT The variable can be named RX_DELIV. In addition, the receiving PDCP layer device uses a fourth COUNT variable that maintains a COUNT value of data (for example, PDCP SDU) that triggered a PDCP reordering timer (t-Reordering) when processing the received data, and the The fourth COUNT variable may be named RX_REORD. When processing the received data, the receiving PDCP layer device uses a fifth COUNT variable that maintains the COUNT value of the currently received data (for example, PDCP SDU), and the fifth COUNT variable is named RCVD_COUNT. Can be. In the above, the PDCP rearrangement timer uses a timer value or interval set as an RRC message as in FIG. do.

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

- HFN: Represents the HFN (Hyper Frame Number) part of the window state variable.

- SN: Represents the serial number (SN, Sequence Number) part of the window state variable.

- RCVD_SN: PDCP serial number included in the header of the received PDCP PDU

- RCVD_HFN: HFN value of the received PDCP PDU calculated by the receiving PDCP layer device

The operation of the receiving PDCP layer apparatus of the terminal or the base station proposed in the present invention is as follows.

When receiving a PDCP PDU from a lower layer, the receiving PDCP layer device determines the COUNT value of the received PDCP PDU as follows.

- If the received RCVD_SN is RCVD_SN <= SN(RX_DELIV)-Window_Size

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

- Otherwise, if RCVD_SN is RCVD_SN> SN(RX_DELIV) + Window_Size

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

- If not above

■ Update to RCVD_HFN = HFN(RX_DELIV).

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

After determining the COUNT value of the received PDCP PDU, the receiving PDCP layer device updates the window state variables and processes the PDCP PDU as follows.

- The PDCP PDU is decoded using the RCVD_COUNT value and integrity verification is performed.

■ If integrity verification fails

■ Instructs the higher layer to fail integrity verification and discards the received PDCP Data PDU (the data part of the PDCP PDU).

- If RCVD_COUNT <RX_DELIV or a PDCP PDU with a value of RCVD_COUNT has been previously received (expired or expired, out-of-window packets, or duplicate packets)

■ The received PDCP Data PDU (the data portion of the PDCP PDU) is discarded.

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

- The PDCP SDU processed above is stored in the receive buffer.

- If RCVD_COUNT >= RX_NEXT

■ Update RX_NEXT to RCVD_COUNT + 1.

- If the out of order delivery indicator (outOfOrderDelivery) is set (if out of order delivery operation is indicated),

■ The PDCP SDU is delivered to an upper layer.

- If RCVD_COUNT is equal to RX_DELIV

■ (Ethernet header compression protocol or ROHC is set) If the header decompression procedure has not been applied before (i.e. data has not yet been processed for the upper layer header)

◆ If the Ethernet header compression protocol is configured and the Ethernet header is compressed (if you check the indicator of the new EHC header and indicate that the Ethernet header is compressed)

● Decompression is performed on the Ethernet header of the data.

◆ Otherwise, if the Ethernet header compression protocol is configured and the Ethernet header is not compressed (if you check the indicator of the new EHC header and indicate that the Ethernet header is not compressed)

● The Ethernet header of the data is regarded as an uncompressed header and decompression is not performed.

● Since the uncompressed Ethernet header has been successfully received, a feedback is triggered to indicate it to the transmitting PDC layer device, and the feedback is configured and transmitted to the transmitting PDCP layer device.

◆ Otherwise, if the Ethernet header compression protocol is not set and ROHC is set

● Decompression is performed on the upper layer header (TCP/IP or UDP header, etc.) of the data.

■ The above data are delivered to the upper layer in the order of COUNT values.

◆ Starting from the value of COUNT = RX_DELIV, all consecutive PDCP SDUs are delivered to the upper layer.

■ The RX_DELIV value is updated with the COUNT value of the first PDCP SDU that is greater than or equal to the current RX_DELIV and has not been transferred to the upper layer.

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

■ Stop and reset the t-Reordering timer.

- If the t-Reordering timer is not running (including when it is stopped under the above condition) and RX_DELIV is less than RX_NEXT,

■ Update RX_REORD value to RX_NEXT.

■ Start the t-Reordering timer.

When the PDCP reordering timer (t-Reordering) expires, the receiving PDCP layer device operates as follows.

- (Ethernet header compression protocol or ROHC is set) If the header decompression procedure has not been applied before (i.e. data has not yet been processed for the upper layer header)

■ If the Ethernet header compression protocol is configured and the Ethernet header is compressed (if you check the indicator of the new EHC header and indicate that the Ethernet header is compressed)

◆ Decompression is performed on the Ethernet header of the data.

■ Otherwise, if the Ethernet header compression protocol is configured and the Ethernet header is not compressed (if you check the indicator of the new EHC header and indicate that the Ethernet header is not compressed)

◆ The Ethernet header of the data is regarded as an uncompressed header and decompression is not performed.

◆ Since the uncompressed Ethernet header has been successfully received, a feedback is triggered to indicate it to the transmitting PDC layer device, and the feedback is configured and transmitted to the transmitting PDCP layer device.

■ Otherwise, if the Ethernet header compression protocol is not set and ROHC is set

◆ Decompression is performed on the upper layer header (TCP/IP or UDP header, etc.) of the data.

- In the above, data are delivered to the upper layer in the order of COUNT values.

■ All PDCP SDUs with COUNT values smaller than the RX_REORD value are delivered.

■ All PDCP SDUs with consecutive COUNT values starting from the RX_REORD value are delivered.

- The RX_DELIV value is updated with the COUNT value of the first PDCP SDU that is greater than or equal to RX_REORD and has not been delivered to the upper layer.

- If the value of RX_DELIV is less than the value of RX_NEXT,

■ Updates the RX_REORD value to the RX_NEXT value.

■ Start the t-Reordering timer.

In the following of the present invention, when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set, it is proposed how to perform encryption and decryption in the PDCP layer device.

2L is a 2-1 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.

In the 2-1 embodiment, when the transmitting SDAP layer device receives the Ethernet frame from the upper layer (2l-05), the SDAP header is configured and transmitted to the lower transmitting PDCP layer device (2l-10). In addition, the transmitting PDCP layer device performs an Ethernet header compression procedure on the Ethernet header of the upper layer device except for the SDAP header, and generates a separate new EHC header. In addition, header compression is performed using the ROHC protocol on the header of the upper layer device such as TCP/IP or UDP of the upper layer device (2l-15, 2l-20).

In the above, for convenience of implementation, compression may be performed from an Ethernet header located in front, and ROHC compression may be performed.

As another method, since a separate compression method is applied to different upper layer headers, parallel processing may be performed on the Ethernet header compression procedure and the ROHC header compression procedure in order to accelerate data processing of the terminal.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as a part of the PDCP data processing procedure, ROHC compression may be performed first and Ethernet header compression may be performed later.

In the above, the transmitting PDCP layer device can configure the EHC header in front of the SDAP header received from the higher layer because the PDCP layer device separately generates the EHC header.

In Embodiment 2-1, which efficiently encrypts, only the ROHC compression header and data that are already compressed by the terminal are encrypted. For convenience of implementation, the newly created EHC header and SDAP header and compressed Ethernet are implemented. It is characterized by not encrypting the header (2l-25, 2l-30). In addition, implementation complexity may be reduced by implementing a PDCP header, an EHC header, an SDAP header, and a compressed Ethernet header to be configured at the beginning of the encrypted data at the end after performing all the encryption procedures from the terminal implementation.

In addition, after the encryption procedure is completed, a PDCP header is generated, configured in front of the new EHC header, and transmitted to a lower layer.

In the efficiently encrypting embodiment 2-1, when the receiving PDCP layer device receives data from the lower layer device, it processes the unencrypted EHC header, the SDAP header, and the compressed Ethernet header, performs Ethernet decompression, and compresses the remaining ROHC. The header and data may be decoded and the ROHC decompression procedure may be performed.

In the above, for convenience of implementation, decompression may be performed from an Ethernet header located in front, and ROHC decompression may be performed.

As another method, since a separate decompression method is applied to different upper layer headers, parallel processing may be performed for the Ethernet header decompression procedure and the ROHC header decompression procedure in order to accelerate data processing of the terminal. have.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as part of the PDCP data processing procedure, ROHC decompression may be performed first and Ethernet header decompression may be performed later. And, if the receiving PDCP layer device calculates and induces the Ethernet frame size for the length field of the Ethernet header field and attempts to recover the length field value, ROHC decompression must first be performed to accurately calculate the total Ethernet frame size. Therefore, the ROHC decompression procedure must be performed first and then the Ethernet decompression procedure must be performed.

2M is a 2-2 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.

In the second embodiment, when the transmitting SDAP layer device receives the Ethernet frame from the upper layer (2m-05), the SDAP header is configured and transmitted to the lower transmitting PDCP layer device (2m-10). In addition, the transmitting PDCP layer device performs an Ethernet header compression procedure on the Ethernet header of the upper layer device except for the SDAP header, and generates a separate new EHC header. In addition, header compression is performed using the ROHC protocol on the header of the upper layer device such as TCP/IP or UDP of the upper layer device (2m-15, 2m-20).

In the above, for convenience of implementation, compression may be performed from an Ethernet header located in front, and ROHC compression may be performed.

As another method, since a separate compression method is applied to different upper layer headers, parallel processing may be performed on the Ethernet header compression procedure and the ROHC header compression procedure in order to accelerate data processing of the terminal.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as a part of the PDCP data processing procedure, ROHC compression may be performed first and Ethernet header compression may be performed later.

In the above, the transmitting PDCP layer device can configure the EHC header in front of the SDAP header received from the higher layer because the PDCP layer device separately generates the EHC header.

In the second embodiment of efficient encryption, in order to enhance security, the terminal performs encryption on the compressed Ethernet header, the compressed ROHC compression header, and data, and the newly generated EHC header and SDAP header are encrypted. It is characterized by not doing (2m-25, 2m-30). In addition, implementation complexity may be reduced by implementing a PDCP header, an EHC header, and an SDAP header to be configured at the beginning of the encrypted data at the end after performing all the encryption procedures from the terminal implementation.

In addition, after the encryption procedure is completed, a PDCP header is generated, configured in front of the new EHC header, and transmitted to a lower layer.

In the second embodiment of efficient encryption, when receiving data from a lower layer device, the receiving PDCP layer device processes the unencrypted EHC header and SDAP header, and decrypts the remaining compressed Ethernet header, ROHC compression header, and data. And perform Ethernet decompression and ROHC decompression procedures.

In the above, for convenience of implementation, decompression may be performed from an Ethernet header located in front, and ROHC decompression may be performed.

As another method, since a separate decompression method is applied to different upper layer headers, parallel processing may be performed for the Ethernet header decompression procedure and the ROHC header decompression procedure in order to accelerate data processing of the terminal. have.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as part of the PDCP data processing procedure, ROHC decompression may be performed first and Ethernet header decompression may be performed later. And, if the receiving PDCP layer device calculates and induces the Ethernet frame size for the length field of the Ethernet header field and attempts to recover the length field value, ROHC decompression must first be performed to accurately calculate the total Ethernet frame size. Therefore, the ROHC decompression procedure must be performed first and then the Ethernet decompression procedure must be performed.

Also, if the Ethernet header compression method and the ROHC (for example, TCP/IP header or UDP header compression method) are set together for a bearer, the length field of the Ethernet header is always compressed and the length field is not transmitted. If not characterized, the receiving PDCP layer device may be characterized by first applying the ROHC decompression method to the received data (for example, PDCP PDU or PDCP SDU) and then applying the Ethernet header decompression method. . This is because when the length field of the Ethernet header is restored by the receiving end (for example, the receiving PDCP layer device), if the length field is restored to the length of data to which header compression is applied by ROHC, the upper layer device (for example, the Ethernet layer device) This is because the length field is incorrectly recovered in the file and data may be truncated or an error may occur. Therefore, when the Ethernet header compression method and the ROHC header compression method are set together, the receiving PDCP layer device first decompresses the upper layer header by applying the ROHC header decompression method, and decompresses the Ethernet header by applying the Ethernet decompression method. can do. And when restoring the length field value of the Ethernet header in the Ethernet header decompression procedure, the size of the length field (for example, after decompressing the remaining fields except the length field, the length field (the length of the goal field is known as fixed) Value) or the length of the Ethernet header after deriving and calculating the length field value in consideration of the size of the decompressed Ethernet header or the length of the data to which ROHC header decompression has been applied (for example, upper layer data or Ethernet frame) A method of restoring and adding the length value (eg, the length of data restored by decompression of the ROHC header) to the field may be used In this way, an indication of the length field in the new EHC header can be omitted, and , Even if the length field value is different for each data, the transmitting PDCP layer device can always omit (compress) the length field and transmit it, and the receiving PDCP layer device calculates the length field value and induces the length field value of the Ethernet header as above. Can always be restored.

2N is a 2-3rd for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.

In the 2-3rd embodiment, when the transmitting SDAP layer device receives the Ethernet frame from the upper layer (2n-05), the SDAP header is constructed and transmitted to the lower transmitting PDCP layer device (2n-10). In addition, the transmitting PDCP layer device performs an Ethernet header compression procedure on the Ethernet header of the upper layer device except for the SDAP header, and generates a separate new EHC header. In addition, header compression is performed using the ROHC protocol on the header of the upper layer device such as TCP/IP or UDP of the upper layer device (2n-15, 2n-20).

In the above, for convenience of implementation, compression may be performed from an Ethernet header located in front, and ROHC compression may be performed.

As another method, since a separate compression method is applied to different upper layer headers, parallel processing may be performed on the Ethernet header compression procedure and the ROHC header compression procedure in order to accelerate data processing of the terminal.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as a part of the PDCP data processing procedure, ROHC compression may be performed first and Ethernet header compression may be performed later.

In the above, the transmitting PDCP layer device can configure the EHC header in front of the SDAP header received from the higher layer because the PDCP layer device separately generates the EHC header.

In the second and third embodiments of the efficient encryption, security between the transmitting PDCP layer device and the receiving PDCP layer device is enhanced by applying the principle of performing encryption on the data processed by the PDCP layer device to enhance security and For this purpose, encryption is performed on the newly generated EHC header, the compressed Ethernet header, the compressed ROHC compressed header, and data, and the SDAP header is not encrypted (2n-25, 2n-30).

In addition, after the encryption procedure is completed, a PDCP header is generated, configured in front of the new EHC header, and transmitted to a lower layer.

In the second-third embodiment of the efficient encryption, when receiving data from a lower layer device, the receiving PDCP layer device processes the unencrypted SDAP header and decrypts the remaining EHC header, compressed Ethernet header, ROHC compressed header, and data. And perform Ethernet decompression and ROHC decompression procedures.

In the above, for convenience of implementation, decompression may be performed from an Ethernet header located in front, and ROHC decompression may be performed.

As another method, since a separate decompression method is applied to different upper layer headers, parallel processing may be performed for the Ethernet header decompression procedure and the ROHC header decompression procedure in order to accelerate data processing of the terminal. have.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as part of the PDCP data processing procedure, ROHC decompression may be performed first and Ethernet header decompression may be performed later. And, if the receiving PDCP layer device calculates and induces the Ethernet frame size for the length field of the Ethernet header field and attempts to recover the length field value, ROHC decompression must first be performed to accurately calculate the total Ethernet frame size. Therefore, the ROHC decompression procedure must be performed first and then the Ethernet decompression procedure must be performed.

Figure 2o is a 2-4 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.

In the second embodiment, when the transmitting SDAP layer device receives the Ethernet frame from the upper layer (2o-05), the SDAP header is configured and transmitted to the lower transmitting PDCP layer device (2o-10). In addition, the transmitting PDCP layer device performs an Ethernet header compression procedure on the Ethernet header of the upper layer device except for the SDAP header, and generates a separate new EHC header. In addition, header compression is performed using the ROHC protocol on the header of the upper layer device such as TCP/IP or UDP of the upper layer device (2o-15, 2o-20).

In the above, for convenience of implementation, compression may be performed from an Ethernet header located in front, and ROHC compression may be performed.

As another method, since a separate compression method is applied to different upper layer headers, parallel processing may be performed on the Ethernet header compression procedure and the ROHC header compression procedure in order to accelerate data processing of the terminal.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as a part of the PDCP data processing procedure, ROHC compression may be performed first and Ethernet header compression may be performed later.

In the above, the transmitting PDCP layer device can configure the EHC header in front of the SDAP header received from the higher layer because the PDCP layer device separately generates the EHC header.

In the second to fourth embodiments of the efficient encryption, in order to enhance security, the terminal performs encryption on the SDAP header, the compressed Ethernet header, the compressed ROHC compression header, and data, and the newly generated EHC header is encrypted. It is characterized by not doing (2o-25, 2o-30). In addition, implementation complexity may be reduced by implementing a PDCP header and an EHC header to be configured at the beginning of the encrypted data at the end after performing all the encryption procedures in the terminal implementation.

In addition, after the encryption procedure is completed, a PDCP header is generated, configured in front of the new EHC header, and transmitted to a lower layer.

In the efficiently encrypting embodiment 2-4, when receiving data from the lower layer device, the receiving PDCP layer device processes the unencrypted EHC header and decrypts the remaining SDAP header, compressed Ethernet header, ROHC compression header, and data. And perform Ethernet decompression and ROHC decompression procedures.

In the above, for convenience of implementation, decompression may be performed from an Ethernet header located in front, and ROHC decompression may be performed.

As another method, since a separate decompression method is applied to different upper layer headers, parallel processing may be performed for the Ethernet header decompression procedure and the ROHC header decompression procedure in order to accelerate data processing of the terminal. have.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as part of the PDCP data processing procedure, ROHC decompression may be performed first and Ethernet header decompression may be performed later. And, if the receiving PDCP layer device calculates and induces the Ethernet frame size for the length field of the Ethernet header field and attempts to recover the length field value, ROHC decompression must first be performed to accurately calculate the total Ethernet frame size. Therefore, the ROHC decompression procedure must be performed first and then the Ethernet decompression procedure must be performed.

2P is a 2-5 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.

In the 2-5 embodiment, when the transmitting SDAP layer device receives the Ethernet frame from the upper layer (2p-05), the SDAP header is configured and transmitted to the lower transmitting PDCP layer device (2p-10). In addition, the transmitting PDCP layer device performs an Ethernet header compression procedure on the Ethernet header of the upper layer device except for the SDAP header, and generates a separate new EHC header. In addition, header compression is performed using the ROHC protocol on the header of the upper layer device such as TCP/IP or UDP of the upper layer device (2p-15, 2p-20).

In the above, for convenience of implementation, compression may be performed from an Ethernet header located in front, and ROHC compression may be performed.

As another method, since a separate compression method is applied to different upper layer headers, parallel processing may be performed on the Ethernet header compression procedure and the ROHC header compression procedure in order to accelerate data processing of the terminal.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as a part of the PDCP data processing procedure, ROHC compression may be performed first and Ethernet header compression may be performed later.

In the above, the transmitting PDCP layer device can configure the EHC header in front of the SDAP header received from the higher layer because the PDCP layer device separately generates the EHC header.

In the embodiment 2-5 of efficiently encrypting, encryption is performed on the EHC header, the SDAP header, the compressed Ethernet header, the compressed ROHC compression header, and data newly generated by the terminal in order to enhance security. (2p-25, 2p-30).

In addition, after the encryption procedure is completed, a PDCP header is generated, configured in front of the new EHC header, and transmitted to a lower layer.

In the efficiently encrypting embodiment 2-5, when receiving data from the lower layer device, the receiving PDCP layer device processes the unencrypted PDCP header, and the remaining EHC header, SDAP header, compressed Ethernet header, ROHC compressed header, and data Decryption can be performed on and the Ethernet decompression and ROHC decompression procedures can be performed.

In the above, for convenience of implementation, decompression may be performed from an Ethernet header located in front, and ROHC decompression may be performed.

As another method, since a separate decompression method is applied to different upper layer headers, parallel processing may be performed for the Ethernet header decompression procedure and the ROHC header decompression procedure in order to accelerate data processing of the terminal. have.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as part of the PDCP data processing procedure, ROHC decompression may be performed first and Ethernet header decompression may be performed later. And, if the receiving PDCP layer device calculates and induces the Ethernet frame size for the length field of the Ethernet header field and attempts to recover the length field value, ROHC decompression must first be performed to accurately calculate the total Ethernet frame size. Therefore, the ROHC decompression procedure must be performed first and then the Ethernet decompression procedure must be performed.

2q is a 2-6 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.

In the 2-6 embodiment, when the transmitting SDAP layer device receives the Ethernet frame from the upper layer (2q-05), the SDAP header is constructed and transmitted to the lower transmitting PDCP layer device (2q-10). In addition, the transmitting PDCP layer device performs an Ethernet header compression procedure on the Ethernet header of the upper layer device except for the SDAP header, and generates a separate new EHC header. In addition, header compression is performed using the ROHC protocol on the header of the upper layer device such as TCP/IP or UDP of the upper layer device (2q-15, 2q-20).

In the above, for convenience of implementation, compression may be performed from an Ethernet header located in front, and ROHC compression may be performed.

As another method, since a separate compression method is applied to different upper layer headers, parallel processing may be performed on the Ethernet header compression procedure and the ROHC header compression procedure in order to accelerate data processing of the terminal.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as a part of the PDCP data processing procedure, ROHC compression may be performed first and Ethernet header compression may be performed later.

In the above, the transmitting PDCP layer device can configure the EHC header in front of the SDAP header received from the higher layer because the PDCP layer device separately generates the EHC header.

In the embodiment 2-6 for efficient encryption, in order to increase the compression rate, the terminal compresses by applying an Ethernet header compression procedure to the SDAP header as well as the Ethernet header. In addition, encryption is not applied to the EHC header and the compressed SDAP/Ethernet header, and encryption is performed on the compressed ROHC compressed header and data (2q-25, 2q-30). In addition, implementation complexity may be reduced by implementing a PDCP header, an EHC header, and a compressed SDAP/Ethernet header at the end to configure the encrypted data at the beginning after performing all the encryption procedures from the terminal implementation. In addition, since the existing terminal is implemented to encrypt only the ROHC compression header and data, the implementation complexity can be reduced.

In addition, after the encryption procedure is completed, a PDCP header is generated, configured in front of the new EHC header, and transmitted to a lower layer.

In the efficiently encrypting embodiment 2-6, when the receiving PDCP layer device receives data from the lower layer device, the receiving PDCP layer device processes the unencrypted EHC header, decompresses the compressed SDAP/Ethernet header, and stores the remaining ROHC compression header and data. Decryption may be performed on the network, and Ethernet decompression and ROHC decompression procedures may be performed.

In the above, for convenience of implementation, decompression may be performed from an Ethernet header located in front, and ROHC decompression may be performed.

As another method, since a separate decompression method is applied to different upper layer headers, parallel processing may be performed for the Ethernet header decompression procedure and the ROHC header decompression procedure in order to accelerate data processing of the terminal. have.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as part of the PDCP data processing procedure, ROHC decompression may be performed first and Ethernet header decompression may be performed later. And, if the receiving PDCP layer device calculates and induces the Ethernet frame size for the length field of the Ethernet header field and attempts to recover the length field value, ROHC decompression must first be performed to accurately calculate the total Ethernet frame size. Therefore, the ROHC decompression procedure must be performed first and then the Ethernet decompression procedure must be performed.

2R is a 2-7 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.

In embodiments 2-7, the encryption method of embodiments 2-6 is applied, but the compressed SDAP/Ethernet header is also encrypted and decrypted to enhance security.

2S is a 2-8 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.

In the second to eighth embodiments, the encryption method of the second to sixth embodiments is applied, but in order to enhance security, compressed SDAP/Ethernet headers and EHC headers are also encrypted and decrypted.

2T is a 2-9 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.

In the second embodiment 2-9, when the transmitting SDAP layer device receives the Ethernet frame from the upper layer (2t-05), the SDAP header is configured and transmitted to the lower transmitting PDCP layer device (2t-10). In addition, the transmitting PDCP layer device performs an Ethernet header compression procedure on the Ethernet header of the upper layer device except for the SDAP header, and generates a separate new EHC header. In addition, header compression is performed using the ROHC protocol on the header of the upper layer device such as TCP/IP or UDP of the upper layer device (2t-15, 2t-20).

In the above, for convenience of implementation, compression may be performed from an Ethernet header located in front, and ROHC compression may be performed.

As another method, since a separate compression method is applied to different upper layer headers, parallel processing may be performed on the Ethernet header compression procedure and the ROHC header compression procedure in order to accelerate data processing of the terminal.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as a part of the PDCP data processing procedure, ROHC compression may be performed first and Ethernet header compression may be performed later.

In the above invention, the transmitting PDCP layer device generates the EHC header separately in the PDCP layer device, but since the data is generated by the Ethernet compression procedure in the PDCP layer device, it is considered as a part of the PDCP data (PDCP SDU) and placed after the SDAP header. It can be characterized.

In the second and nineth embodiments of the efficient encryption, the terminal encrypts only the compressed ROHC compression header and data, and does not encrypt the SDAP header, the newly created EHC header, and the compressed Ethernet header. (2t-25, 2t-30). In addition, implementation complexity may be reduced by implementing a PDCP header, an SDAP header, an EHC header, and a compressed Ethernet header at the end to configure the encrypted data at the beginning after performing all the encryption procedures from the terminal implementation.

In addition, after the encryption procedure is completed, a PDCP header is generated, configured in front of the SDAP header, and transmitted to a lower layer.

In the second and nineth embodiments of the efficient encryption, when receiving data from the lower layer device, the receiving PDCP layer device processes an unencrypted SDAP header, a newly created EHC header, and a compressed Ethernet header, and performs an Ethernet header decompression procedure. Then, decoding may be performed on the remaining ROHC compression header and data, and a ROHC decompression procedure may be performed.

In the above, for convenience of implementation, decompression may be performed from an Ethernet header located in front, and ROHC decompression may be performed.

As another method, since a separate decompression method is applied to different upper layer headers, parallel processing may be performed for the Ethernet header decompression procedure and the ROHC header decompression procedure in order to accelerate data processing of the terminal. have.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as part of the PDCP data processing procedure, ROHC decompression may be performed first and Ethernet header decompression may be performed later. And, if the receiving PDCP layer device calculates and induces the Ethernet frame size for the length field of the Ethernet header field and attempts to recover the length field value, ROHC decompression must first be performed to accurately calculate the total Ethernet frame size. Therefore, the ROHC decompression procedure must be performed first and then the Ethernet decompression procedure must be performed.

2u is a 2-10 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or the SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.

In the second embodiment, when the transmitting SDAP layer device receives the Ethernet frame from the upper layer (2u-05), the transmitting SDAP layer device constructs an SDAP header and transmits it to the lower transmitting PDCP layer device (2u-10). In addition, the transmitting PDCP layer device performs an Ethernet header compression procedure on the Ethernet header of the upper layer device except for the SDAP header, and generates a separate new EHC header. In addition, header compression is performed using the ROHC protocol on the header of the upper layer device such as TCP/IP or UDP of the upper layer device (2u-15, 2u-20).

In the above, for convenience of implementation, compression may be performed from an Ethernet header located in front, and ROHC compression may be performed.

As another method, since a separate compression method is applied to different upper layer headers, parallel processing may be performed on the Ethernet header compression procedure and the ROHC header compression procedure in order to accelerate data processing of the terminal.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as a part of the PDCP data processing procedure, ROHC compression may be performed first and Ethernet header compression may be performed later.

In the above invention, the transmitting PDCP layer device generates the EHC header separately in the PDCP layer device, but since the data is generated by the Ethernet compression procedure in the PDCP layer device, it is considered as a part of the PDCP data (PDCP SDU) and placed after the SDAP header. It can be characterized.

In the second embodiment of the efficient encryption, for enhanced security, the terminal performs encryption on the compressed Ethernet header, the compressed ROHC compression header, and data, and the SDAP header and the newly created EHC header are not encrypted. It is characterized by not being (2u-25, 2u-30). In addition, implementation complexity may be reduced by implementing the PDCP header, SDAP header, and EHC header to be configured at the beginning of the encrypted data at the end after performing all the encryption procedures from the terminal implementation.

In addition, after the encryption procedure is completed, a PDCP header is generated, configured in front of the SDAP header, and transmitted to a lower layer.

In the efficiently encrypting embodiment 2-10, when receiving data from the lower layer device, the receiving PDCP layer device processes the unencrypted SDAP header and the newly created EHC header, and the remaining compressed Ethernet header, ROHC compressed header and data Decryption may be performed on and an Ethernet decompression or ROHC decompression procedure may be performed.

In the above, for convenience of implementation, decompression may be performed from an Ethernet header located in front, and ROHC decompression may be performed.

As another method, since a separate decompression method is applied to different upper layer headers, parallel processing may be performed for the Ethernet header decompression procedure and the ROHC header decompression procedure in order to accelerate data processing of the terminal. have.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as part of the PDCP data processing procedure, ROHC decompression may be performed first and Ethernet header decompression may be performed later. And, if the receiving PDCP layer device calculates and induces the Ethernet frame size for the length field of the Ethernet header field and attempts to recover the length field value, ROHC decompression must first be performed to accurately calculate the total Ethernet frame size. Therefore, the ROHC decompression procedure must be performed first and then the Ethernet decompression procedure must be performed.

2V is a 2-11 for efficiently performing encryption and decryption in the PDCP layer device when the SDAP layer device or SDAP header is set, the Ethernet header compression protocol (or method) is set, and the ROHC protocol is set in the present invention. Show examples.

In the 2-11 embodiment, when the transmitting SDAP layer device receives the Ethernet frame from the upper layer (2v-05), the SDAP header is configured and transmitted to the lower transmitting PDCP layer device (2v-10). In addition, the transmitting PDCP layer device performs an Ethernet header compression procedure on the Ethernet header of the upper layer device except for the SDAP header, and generates a separate new EHC header. In addition, header compression is performed using the ROHC protocol on the header of the upper layer device such as TCP/IP or UDP of the upper layer device (2v-15, 2v-20).

In the above, for convenience of implementation, compression may be performed from an Ethernet header located in front, and ROHC compression may be performed.

As another method, since a separate compression method is applied to different upper layer headers, parallel processing may be performed on the Ethernet header compression procedure and the ROHC header compression procedure in order to accelerate data processing of the terminal.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as a part of the PDCP data processing procedure, ROHC compression may be performed first and Ethernet header compression may be performed later.

In the above invention, the transmitting PDCP layer device generates the EHC header separately in the PDCP layer device, but since the data is generated by the Ethernet compression procedure in the PDCP layer device, it is considered as a part of the PDCP data (PDCP SDU) and placed after the SDAP header. It can be characterized.

In the embodiment 2-11 of efficiently encrypting, encryption is performed on the newly generated EHC header, the compressed Ethernet header, the compressed ROHC compressed header, and data in the terminal to enhance security, and only the SDAP header is not encrypted. It is characterized by not being (2v-25, 2v-30). In addition, implementation complexity may be reduced by implementing the PDCP header and SDAP header to be configured at the beginning of the encrypted data at the end after performing all the encryption procedures from the terminal implementation.

In addition, after the encryption procedure is completed, a PDCP header is generated, configured in front of the SDAP header, and transmitted to a lower layer.

In the second embodiment of the efficient encryption, when receiving data from the lower layer device, the receiving PDCP layer device processes the unencrypted SDAP header, and the remaining newly generated EHC header, compressed Ethernet header, ROHC compressed header, and data Decryption may be performed on and an Ethernet decompression or ROHC decompression procedure may be performed.

In the above, for convenience of implementation, decompression may be performed from an Ethernet header located in front, and ROHC decompression may be performed.

As another method, since a separate decompression method is applied to different upper layer headers, parallel processing may be performed for the Ethernet header decompression procedure and the ROHC header decompression procedure in order to accelerate data processing of the terminal. have.

Alternatively, since the ROHC protocol is an algorithm that has already been implemented and is already implemented as part of the PDCP data processing procedure, ROHC decompression may be performed first and Ethernet header decompression may be performed later. And, if the receiving PDCP layer device calculates and induces the Ethernet frame size for the length field of the Ethernet header field and attempts to recover the length field value, ROHC decompression must first be performed to accurately calculate the total Ethernet frame size. Therefore, the ROHC decompression procedure must be performed first and then the Ethernet decompression procedure must be performed.

If the SDAP header is not encrypted in the embodiments of the present invention, if the base station implements the CU-DU split structure and implements only from the DU to the RLC layer device, if the SDAP header is encrypted, the QoS of the SDAP header is set in the DU. Since it cannot be verified, the SDAP header may not be encrypted in order to easily utilize QoS for scheduling in the DU.

When the SDAP layer device or the SDAP header is not set in the present invention, the method of the above embodiments may be applied in the same manner except for the SDAP header in the embodiments of the present invention.

In addition, when the ROHC protocol is not set in the present invention, the method of the above embodiments can be applied in the same manner except for the ROHC header compression procedure in the embodiments of the present invention.

The embodiments proposed in the present invention are not simply applied to the Ethernet header, but can be applied to the headers of other upper layer devices that may be set above the PDCP layer device. Therefore, the present invention does not propose a method for compressing an Ethernet header limited to an Ethernet header, but describes an embodiment of the Ethernet header, and an upper layer that can be applied to headers of an upper layer device (other application layer devices) of a PDCP layer device. This is a proposal for a header compression and decompression method.

In the following of the present invention, when the SDAP layer device is configured to be used by an RRC message such as 2e-10, 2e-40, or 2e-75 in FIG. 2e or is configured to use an SDAP header and Ethernet header compression, EHC) is set, and when the transmitting PDCP layer device receives SDAP control data from an upper layer device (eg, SDAP layer device), methods for efficiently processing SDAP control data are proposed.

In the present invention, SDAP control data may have the same structure as an uplink SDAP header. The SDAP control data structure is a field indicating QFI (QoS Flow ID), SDAP control data indicating that the data flow corresponding to the QFI field value has ended or is the last, and the last indicator control data (End Marker Control PDU) It can also be called.

In the following of the present invention, when the SDAP layer device is configured to be used by an RRC message such as 2e-10, 2e-40, or 2e-75 in FIG. 2e or is configured to use an SDAP header and Ethernet header compression, EHC) is set, and when the transmitting PDCP layer device receives SDAP control data from an upper layer device (eg, SDAP layer device), methods for efficiently processing SDAP control data are proposed.

In the present invention, when an SDAP layer device is set or an SDAP header is set as an RRC message, embodiments 2-12 of efficiently performing an Ethernet header compression method and processing SDAP control data are proposed as follows.

In embodiments 2-12, the Ethernet header compression method is not applied to the SDAP control data, the SDAP control data is not encrypted, and the EHC header is not encrypted. The SDAP control data information can have the advantage that the transmitting end or the receiving end can utilize the QoS information of the SDAP header without the need for a decoding procedure. In addition, the receiving PDCP layer device can confirm that the SDAP control data is not compressed through the 1-bit indicator of the EHC header because the EHC header is not encrypted. Since the SDAP control data is not encrypted, the decryption procedure is not applied, It can have the advantage of being able to process SDAP control data quickly. For example, in the case of the base station, the QoS information can be used for scheduling, and the terminal implementation does not perform a decoding procedure every time SDAP control data is received, and integrity protection is performed when it is set, and the EHC header and PDCP It is easy to implement a terminal for fast data processing because it can create and attach a header and transfer it to a lower layer. In addition, in embodiments 2-12 of the present invention, the EHC header is positioned in front of the SDAP control data, so that the structure of the PDCP PDU comprises the 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 to implement the terminal to be logically located in front of the SDAP control data generated by the SDAP layer device, which is a higher layer device. Accordingly, embodiments 2-12 may have a structure in which the EHC header and the SDAP control data are joined by placing the EHC header in front of the SDAP control data.

Specifically, when the SDAP layer device is configured to be used by the RRC message or when the SDAP header is set to be used, and when Ethernet header compression (EHC) is configured, SDAP control data is transmitted from an upper layer (SDAP layer device). Upon receipt, the transmitting PDCP layer device does not perform the Ethernet header compression procedure on the SDAP control data received from the upper SDAP layer device. Then, by calculating the checksum field and setting whether to apply EHC, an EHC header can be generated and attached to the front of SDAP control data (1s-15). And if integrity protection is set, integrity protection is applied to the PDCP header, EHC header, and SDAP control data before performing an encryption procedure, and then encryption is not performed on the EHC header and SDAP control data. You can do it. In addition, a PDCP header may be configured at the beginning of the data and may be spliced to be transmitted to a lower layer device.

In the present invention, when the SDAP layer device is set or the SDAP header is set as an RRC message, a 2-13 embodiment of efficiently performing an Ethernet header compression method and processing SDAP control data is proposed as follows.

In the 2-13th embodiment, the Ethernet header compression method is not applied to the SDAP control data, the SDAP control data is not encrypted, and the EHC header is not encrypted. The SDAP control data information can have the advantage of being able to utilize the QoS information of the SDAP header without the need for a decoding procedure at the transmitting end or the receiving end. In addition, the receiving PDCP layer device can confirm that the SDAP control data is not compressed through the 1-bit indicator of the EHC header because the EHC header is not encrypted. Since the SDAP control data is not encrypted, the decryption procedure is not applied, It can have the advantage of being able to process SDAP control data quickly. For example, in the case of the base station, the QoS information can be used for scheduling, and the terminal implementation does not perform a decoding procedure every time SDAP control data is received, and integrity protection is performed when it is set, and the EHC header and PDCP It is easy to implement a terminal for fast data processing because it can create and attach a header and transfer it to a lower layer. In addition, in the 2-13th embodiment of the present invention, the EHC header is positioned after the SDAP control data, so that the structure of the PDCP PDU comprises data in the order of a PDCP header, SDAP control data, and EHC header. Since the EHC procedure is the first in the processing procedure of the PDCP layer device, the EHC header is generated first, and the SDAP control data received from the upper layer is placed in front of the EHC header, thereby making it easier to implement the terminal. Accordingly, the 2-13th embodiment may have a structure in which the SDAP control data and the EHC header are joined by placing the SDAP control data in front of the EHC header.

Specifically, when the SDAP layer device is configured to be used by an RRC message such as 2e-10, 2e-40, or 2e-75 in FIG. 2e or is configured to use an SDAP header, and Ethernet header compression (EHC) is performed. When set, when SDAP control data is received from an upper layer (SDAP layer device), the transmitting PDCP layer device does not perform the Ethernet header compression procedure on the SDAP control data received from the upper SDAP layer device. In addition, by calculating the checksum field and setting whether to apply EHC, an EHC header can be generated and attached to the back of SDAP control data. In addition, if integrity protection is set, integrity protection is applied to the PDCP header, SDAP control data, and EHC header before performing an encryption procedure, and then encryption is not performed on the SDAP control data and EHC header. You can do it. In addition, a PDCP header may be configured at the beginning of the data and may be spliced to be transmitted to a lower layer device.

In the present invention, when the SDAP layer device is set or the SDAP header is set as an RRC message, embodiments 2-14 of efficiently performing an Ethernet header compression method and processing SDAP control data are proposed as follows.

In the second to 14th embodiment, the Ethernet header compression method is not applied to the SDAP control data, the SDAP control data is not encrypted, and the EHC header is encrypted. It can have the advantage of being able to utilize QoS information of the SDAP header without the need for a decoding procedure at the transmitting end or the receiving end of the control data information. Also, since the EHC header is encrypted, the receiving PDCP layer device can classify the data due to the attack as a decryption failure, and security can be enhanced. After the EHC header is decoded, it can be confirmed that the SDAP control data is not compressed through the 1-bit indicator of the EHC header. Since the SDAP control data is not encrypted, the SDAP control data is quickly processed without applying a decryption procedure. It can have the advantage of being able to do it. For example, in the case of the base station, the QoS information can be used for scheduling, and the terminal implementation does not perform a decoding procedure every time SDAP control data is received, and integrity protection is performed when it is set, and only the EHC header is decoded immediately. Therefore, it is easy to implement a terminal for fast data processing because it can create and attach a PDCP header and transfer it to a lower layer. In addition, in the second to 14th embodiments of the present invention, the EHC header is positioned in front of the SDAP control data, so that the structure of the PDCP PDU comprises the 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 to implement the terminal to be logically located in front of the SDAP control data generated by the SDAP layer device, which is a higher layer device. Accordingly, the embodiment 2-14 may have a structure in which the EHC header and the SDAP control data are joined by placing the EHC header in front of the SDAP control data.

Specifically, when the SDAP layer device is configured to be used by an RRC message such as 2e-10, 2e-40, or 2e-75 in FIG. 2e or is configured to use an SDAP header, and Ethernet header compression (EHC) is performed. When set, when SDAP control data is received from an upper layer (SDAP layer device), the transmitting PDCP layer device does not perform the Ethernet header compression procedure on the SDAP control data received from the upper SDAP layer device. In addition, by calculating a checksum field and setting whether to apply EHC, an EHC header can be generated and attached to the front of SDAP control data. And if integrity protection is set, integrity protection is applied to the PDCP header, EHC header, and SDAP control data before performing the encryption procedure, and then encryption is performed on the EHC header and encryption is performed on the SDAP control data. It can be characterized by not doing. In addition, a PDCP header may be configured at the beginning of the data and may be spliced to be transmitted to a lower layer device.

In the present invention, when an SDAP layer device is set or an SDAP header is set as an RRC message, embodiments 2-15 of efficiently performing an Ethernet header compression method and processing SDAP control data are proposed as follows.

In the embodiment 2-15, the Ethernet header compression method is not applied to the SDAP control data, the SDAP control data is not encrypted, and the EHC header is encrypted. It can have the advantage of being able to utilize QoS information of the SDAP header without the need for a decoding procedure at the transmitting end or the receiving end of the control data information. In addition, since the EHC header is encrypted, the receiving PDCP layer device can distinguish data from an attack as a decryption failure, and enhance security. In addition, after decoding the EHC header, it can be confirmed that the SDAP control data is not compressed through the 1-bit indicator of the EHC header. Since the SDAP control data is not encrypted, the SDAP control data is processed quickly without applying a decryption procedure. It can have the advantage of being able to do it. For example, in the case of the base station, the QoS information can be used for scheduling, and the terminal implementation does not perform a decryption procedure every time SDAP control data is received, and integrity protection is performed when it is set, and the EHC header is immediately encrypted. It is easy to implement a terminal for fast data processing because it can create and attach a PDCP header and deliver it to the lower layer. In addition, in the embodiment 2-15 of the present invention, the EHC header is positioned after the SDAP control data, so that the structure of the PDCP PDU comprises the data in the order of the PDCP header, the SDAP control data, and the EHC header. Since the EHC procedure is the first in the processing procedure of the PDCP layer device, the EHC header is generated first, and the SDAP control data received from the upper layer is placed in front of the EHC header, thereby making it easier to implement the terminal. Accordingly, the embodiment 2-15 may have a structure in which the SDAP control data and the EHC header are joined by placing the SDAP control data in front of the EHC header.

Specifically, when the SDAP layer device is configured to be used by an RRC message such as 2e-10, 2e-40, or 2e-75 in FIG. 2e or is configured to use an SDAP header, and Ethernet header compression (EHC) is performed. When set, when SDAP control data is received from an upper layer (SDAP layer device), the transmitting PDCP layer device does not perform the Ethernet header compression procedure on the SDAP control data received from the upper SDAP layer device. In addition, by calculating the checksum field and setting whether to apply EHC, an EHC header can be generated and attached to the back of SDAP control data. In addition, if integrity protection is set, integrity protection is applied to the PDCP header, SDAP control data, and EHC header before performing the encryption procedure, and then encryption is not performed on the SDAP control data and encryption is performed on the EHC header. It can be characterized by performing. In addition, a PDCP header may be configured at the beginning of the data and may be spliced to be transmitted to a lower layer device.

In the present invention, when an SDAP layer device is set or an SDAP header is set as an RRC message, embodiments 2-16 of efficiently performing an Ethernet header compression method and processing SDAP control data are proposed as follows.

In the embodiment 2-16, the Ethernet header compression method is not applied to the SDAP control data, the SDAP control data is not encrypted, the EHC header is not generated for the SDAP control data, and a 1-bit indicator of the PDCP header It is characterized in that it is possible to indicate that there is no SDAP control data or that there is no EHC header, and may have the advantage of reducing overhead due to the above characteristics. In addition, the transmitting PDCP layer device does not need to unnecessarily generate an EHC header, and the receiving PDCP layer device does not have an EHC header, so it immediately checks the 1-bit indicator of the PDCP header and does not apply the decryption procedure because the SDAP control data is not encrypted. However, it can have the advantage of being able to quickly process SDAP control data. For example, in the case of a base station, the QoS information can be used for scheduling, and the terminal implementation does not perform a decoding procedure every time SDAP control data is received, and integrity protection is performed when it is set, and generates an EHC header. It is easy to implement a terminal for fast data processing because the PDCP header can be created and attached without a procedure and transmitted to a lower layer. In addition, the 2-16 embodiment of the present invention proposes a procedure for processing SDAP control data without an EHC header, so that the structure of the PDCP PDU may be characterized in that data is configured in the order of PDCP header and SDAP control data. When processing the SDAP control data received from the SDAP control data, the embodiment 2-16 may have a structure in which a PDCP header is attached in front of the SDAP control data.

Specifically, when the SDAP layer device is configured to be used by an RRC message such as 2e-10, 2e-40, or 2e-75 in FIG. 2e or is configured to use an SDAP header, and Ethernet header compression (EHC) is performed. When set, when SDAP control data is received from an upper layer (SDAP layer device), the transmitting PDCP layer device does not perform the Ethernet header compression procedure on the SDAP control data received from the upper SDAP layer device. In addition, it is characterized in that the EHC header for the SDAP control data is not generated. In addition, if integrity protection is set, integrity protection is applied to the PDCP header and SDAP control data before performing an encryption procedure, and then the SDAP control data is not encrypted. In addition, a PDCP header may be configured at the beginning of the SDP control data and may be spliced to be transmitted to a lower layer device.

The 1-bit indicator of the PDCP header proposed in Embodiment 2-16 of the present invention has a function to indicate the presence or absence of an EHC header, and Embodiment 2-1 or Embodiment 2-2 of the present invention Or the 2-3rd embodiment or 2-4th embodiment or 2-5th embodiment or 2-6th embodiment or 2-7th embodiment or 2-8th embodiment or 2-9th embodiment or When the user compression procedure is not applied to the SDAP header and data received from the upper layer by extending and applying to the 2-10th embodiment or the 2-11th embodiment, the EHC header is omitted, and 1 of the PDCP header It is also possible to reduce overhead by indicating that the EHC header is not attached as a bit indicator.

In the following of the present invention, a terminal that performs different data processing by distinguishing between the case where the transmitting or receiving PDCP layer device receives the SDAP header and the upper layer data from the upper layer device or the lower layer device and the SDAP control data. Alternatively, the operation of the PDCP layer device of the base station is proposed.

- In Figure 2e, when the SDAP layer device is configured to be used by an RRC message such as 2e-10, 2e-40, or 2e-75, or when the SDAP header is configured, and Ethernet header compression (EHC) is configured, Occation,

■ If data (e.g. PDCP SDU) received from an upper layer device (SDAP layer device) is composed of SDAP header and upper layer data, or is not SDAP control data

◆ The transmitting PDCP layer device is the 2-1 embodiment or the 2-2 embodiment or the 2-3 embodiment or the 2-4 embodiment or the 2-5 embodiment or the 2-6 embodiment or The procedure of the 2-7th embodiment or the 2-8th embodiment or the 2-9th embodiment or the 2-10th embodiment or 2-11th embodiment is performed.

■ If the data (e.g. PDCP SDU) received from the upper layer device (SDAP layer device) is not composed of SDAP header and upper layer data, or if SDAP control data

◆ The transmitting PDCP layer device performs the procedures of the 2-12th embodiment, the 2-13th embodiment, the 2-14th embodiment, the 2-15th embodiment, or the 2-16th embodiment of the present invention.

■ If data (e.g., PDCP PDU) received from a lower layer device (RLC layer device) is composed of SDAP header and upper layer data, or is not SDAP control data

◆ The receiving PDCP layer device is the 2-1 embodiment or the 2-2 embodiment or the 2-3 embodiment or the 2-4 embodiment or the 2-5 embodiment or the 2-6 embodiment or The procedure of the 2-7th embodiment or the 2-8th embodiment or the 2-9th embodiment or the 2-10th embodiment or 2-11th embodiment is performed.

■ If data (e.g. PDCP PDU) received from lower layer device (RLC layer device) is not composed of SDAP header and upper layer data, or SDAP control data

◆ The receiving PDCP layer device performs the procedures of the 2-12th embodiment, the 2-13th embodiment, the 2-14th embodiment, the 2-15th embodiment, or the 2-16th embodiment of the present invention.

In the above of the present invention, efficient methods for processing SDAP header or SDAP control data when a header or data compression method is set as an RRC message in a PDCP layer device have been proposed. In particular, methods in which the encryption or the header location are considered together with a header set in the PDCP layer device or a new header generated by a data compression method have been specifically proposed. Specific embodiments proposed by the present invention (the 2-1 embodiment or the 2-2 embodiment or the 2-3rd embodiment or the 2-4 embodiment or the 2-5 embodiment or the 2-6 embodiment Or the 2-7th embodiment or the 2-8th embodiment or the 2-9th embodiment or the 2-10th embodiment or the 2-11th embodiment or the 2-12th embodiment or the 2-13th embodiment or Embodiment 2-14 or Embodiment 2-15 or Embodiment 2-16) can be extended and applied when a new compression method is introduced and set in the PDCP layer device, and due to the new compression method, When another new header is generated, embodiments of the present invention that consider whether encryption or a header position is considered together with the new header may be extended and applied.

2W is a diagram showing an operation of a transmitting PDCP layer device or a receiving PDCP layer device of a terminal or a base station.

In the present invention, when the upper layer header compression protocol (Ethernet header compression method, EthHC) is set for the transmitting PDCP layer device, the data (2w-05) received from the upper layer is first received after the Ethernet header compression method is set. Data, or if one of the field values of fields that can be compressed 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 the previously transmitted Ethernet header field (2w-10) if a feedback indicating that the data has been successfully received has not yet been received from the receiving PDCP layer device (2w-10) for data having a previously transmitted uncompressed complete upper layer header (Ethernet header). Does not perform the Ethernet header compression until a feedback indicating that the uncompressed complete upper layer header (Ethernet header) has been successfully received from the receiving PDCP layer device (2w-20). If feedback indicating that the data with the previously transmitted uncompressed complete upper layer header (Ethernet header) has been successfully received from the receiving PDCP layer device (2w-10), the transmitting PDCP layer device is Compression is performed by applying the Ethernet header compression method to the data (2w-15).

In the present invention, for the receiving PDCP layer device, if the Ethernet header compression protocol is set and data is received from the lower layer (2w-25), and the Ethernet header is compressed (check the indicator of the new EHC header and confirm that the Ethernet header is compressed). If indicated) (2w-35) Decompression is performed on the Ethernet header of the data (2w-40). Otherwise, if the Ethernet header compression protocol is set and the Ethernet header is not compressed (if the indicator of the new EHC header is checked and the Ethernet header is indicated that the Ethernet header is not compressed) (2w-35), the Ethernet header of the data is uncompressed. It is regarded as a header and no decompression is performed. Further, since the uncompressed Ethernet header has been successfully received, a feedback is triggered to indicate it to the transmitting PDC layer device, and the feedback is configured and transmitted to the transmitting PDCP layer device (2w-45).

2X shows the structure of a terminal to which an embodiment of the present invention can be applied.

Referring to the drawing, the terminal includes a radio frequency (RF) processing unit (2x-10), a baseband, a processing unit (2x-20), a storage unit (2x-30), and a control unit (2x-40). do.

The RF processing unit 2x-10 performs functions for transmitting and receiving signals through a wireless channel, such as band conversion and amplification of signals. That is, the RF processing unit (2x-10) up-converts the baseband signal provided from the baseband processing unit (2x-20) to an RF band signal and then transmits it through an antenna, and the RF band signal received through the antenna Is down-converted to a baseband signal. For example, the RF processing unit 2x-10 may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a digital to analog convertor (DAC), an analog to digital convertor (ADC), and the like. I can. In the drawing, only one antenna is shown, but the terminal may include a plurality of antennas. In addition, the RF processing unit 2x-10 may include a plurality of RF chains. Furthermore, the RF processing unit 2x-10 may perform beamforming. For the beamforming, the RF processing unit 2x-10 may adjust a phase and a magnitude of each of signals transmitted/received through a plurality of antennas or antenna elements. In addition, the RF processing unit may perform MIMO, and may receive multiple layers when performing the MIMO operation. The RF processing unit (2x-10) may perform reception beam sweeping by appropriately setting a plurality of antennas or antenna elements under control of the controller, or adjust the direction and beam width of the reception beam so that the reception beam cooperates with the transmission beam. have.

The baseband processing unit 2x-20 performs a function of converting between a baseband signal and a bit stream according to the physical layer standard of the system. For example, when transmitting data, the baseband processing unit 2x-20 generates complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the baseband processing unit 2x-20 restores a received bit stream through demodulation and decoding of the baseband signal provided from the RF processing unit 2x-10. For example, in the case of the OFDM (orthogonal frequency division multiplexing) method, when transmitting data, the baseband processing unit 2x-20 generates complex symbols by encoding and modulating a transmission bit stream, and subcarriers the complex symbols. After mapping to, OFDM symbols are constructed through an inverse fast Fourier transform (IFFT) operation and a cyclic prefix (CP) insertion. In addition, when receiving data, the baseband processing unit 2x-20 divides the baseband signal provided from the RF processing unit 2x-10 in units of OFDM symbols, and applies a fast Fourier transform (FFT) operation to subcarriers. After reconstructing the mapped signals, the received bit stream is restored through demodulation and decoding.

The baseband processing unit 2x-20 and the RF processing unit 2x-10 transmit and receive signals as described above. Accordingly, the baseband processing unit 2x-20 and the RF processing unit 2x-10 may be referred to as a transmission unit, a reception unit, a transmission/reception unit, or a communication unit. Further, at least one of the baseband processing unit 2x-20 and the RF processing unit 2x-10 may include a plurality of communication modules to support a plurality of different wireless access technologies. In addition, at least one of the baseband processing unit 2x-20 and the RF processing unit 2x-10 may include different communication modules to process signals of different frequency bands. For example, the different radio access technologies may include an LTE network, an NR network, and the like. In addition, the different frequency bands may include a super high frequency (SHF) (eg, 2.5GHz, 5Ghz) band, and a millimeter wave (eg, 60GHz) band.

The storage unit 2x-30 stores data such as a basic program, an application program, and setting information for the operation of the terminal. The storage unit 2x-30 provides stored data at the request of the control unit 2x-40.

The controller 2x-40 controls overall operations of the terminal. For example, the control unit 2x-40 transmits and receives signals through the baseband processing unit 2x-20 and the RF processing unit 2x-10. In addition, the control unit 2x-40 writes and reads data in the storage unit 2x-40. To this end, the control unit 2x-40 may include at least one processor. For example, the control unit 2x-40 may include a communication processor (CP) that controls communication and an application processor (AP) that controls an upper layer such as an application program.

2Y shows a block configuration of a TRP in a wireless communication system to which an embodiment of the present invention can be applied.

As shown in the drawing, the base station includes an RF processing unit (2y-10), a baseband processing unit (2y-20), a backhaul communication unit (2y-30), a storage unit (2y-40), and a control unit (2y-50). Consists of including.

The RF processing unit 2y-10 performs functions for transmitting and receiving signals through a wireless channel, such as band conversion and amplification of signals. That is, the RF processing unit 2y-10 up-converts the baseband signal provided from the baseband processing unit 2y-20 to an RF band signal and then transmits it through an antenna, and an RF band signal received through the antenna Downconverts to a baseband signal. For example, the RF processing unit 2y-10 may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, and the like. In the drawing, only one antenna is shown, but the first access node may include a plurality of antennas. In addition, the RF processing unit 2y-10 may include a plurality of RF chains. Furthermore, the RF processing unit 2y-10 may perform beamforming. For the beamforming, the RF processing unit 2y-10 may adjust a phase and a magnitude of each of signals transmitted and received through a plurality of antennas or antenna elements. The RF processor may perform a downlink MIMO operation by transmitting one or more layers.

The baseband processing unit 2y-20 performs a function of converting between a baseband signal and a bit stream according to the physical layer standard of the first wireless access technology. For example, when transmitting data, the baseband processing unit 2y-20 generates complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the baseband processing unit 2y-20 restores a received bit stream through demodulation and decoding of the baseband signal provided from the RF processing unit 2y-10. For example, in the case of the OFDM scheme, when transmitting data, the baseband processing unit 2y-20 generates complex symbols by encoding and modulating a transmission bit stream, mapping the complex symbols to subcarriers, and then IFFT OFDM symbols are configured through calculation and CP insertion. In addition, when receiving data, the baseband processing unit 2y-20 divides the baseband signal provided from the RF processing unit 2y-10 in units of OFDM symbols, and reconstructs signals mapped to subcarriers through FFT operation. After that, the received bit stream is restored through demodulation and decoding. The baseband processing unit 2y-20 and the RF processing unit 2y-10 transmit and receive signals as described above. Accordingly, the baseband processing unit 2y-20 and the RF processing unit 2y-10 may be referred to as a transmission unit, a reception unit, a transmission/reception unit, a communication unit, or a wireless communication unit.

The communication unit 2y-30 provides an interface for performing communication with other nodes in the network.

The storage unit 2y-40 stores data such as a basic program, an application program, and setting information for the operation of the main station. In particular, the storage unit 2y-40 may store information on bearers allocated to the connected terminal, measurement results reported from the connected terminal, and the like. In addition, the storage unit 2y-40 may store information that is a criterion for determining whether to provide multiple connections to the terminal or to stop. In addition, the storage unit 2y-40 provides stored data according to the request of the control unit 2y-50.

The control unit 2y-50 controls overall operations of the main station. For example, the control unit 2y-50 transmits and receives a signal through the baseband processing unit 2y-20 and the RF processing unit 2y-10 or through the backhaul communication unit 2y-30. In addition, the control unit 2y-50 writes and reads data in the storage unit 2y-40. To this end, the control unit 2y-50 may include at least one processor.

Claims (1)

In the control signal processing method in a wireless communication system,
Receiving a first control signal transmitted from a base station;
Processing the received first control signal; And
And transmitting a second control signal generated based on the processing to the base station.

Images