KR20200114978A - Method and apparatus for transmitting and receiving data in a wireless communication system - Google Patents

Abstract

The present disclosure relates to a method and apparatus for transmitting and receiving data in a wireless communication system. According to the present disclosure, an operation method of a transmission end in a wireless communication system may comprise the steps of: receiving data from an upper layer; identifying a preset condition based on the received data; determining whether to compress a header of the upper layer based on the identified condition; and transmitting the data according to the determined compression status.

Description

Method and apparatus for transmitting and receiving data in a wireless communication system {METHOD AND APPARATUS FOR TRANSMITTING AND RECEIVING DATA IN A WIRELESS COMMUNICATION SYSTEM}

The present disclosure relates to a method and apparatus for transmitting and receiving data in a wireless communication system.

4G (4 ^th generation) to meet the traffic demand in the radio data communication system increases since the commercialization trend, efforts to develop improved 5G (5 ^th generation) communication system, or pre-5G communication system have been made. For this reason, a 5G communication system or a pre-5G communication system is called a Beyond 4G Network communication system or a Long-Term Evolution (LTE) system and a system after 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, 60 gigabyte (70 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 machine type communication (MTC) are implemented by techniques such as beamforming, MIMO, and array antenna, which are 5G communication technologies. . The application of a cloud radio access network (cloud RAN) as the big data processing technology described above can be said as an example of the convergence of 3eG technology and IoT technology.

As described above, with the development of mobile communication systems, a method for transmitting and receiving data is required.

Based on the discussion as described above, the present disclosure is a service that requires low transmission delay and high reliability in a next-generation mobile communication system (e.g., URLLC (Ultra Reliable Low Latency Communication) or IIoT (Industrial Internet of Things) service), an apparatus and method for efficiently using transmission resources are provided.

According to an embodiment of the present disclosure, a method of operating a transmitter in a wireless communication system includes: receiving data from an upper layer; Identifying a preset condition based on the received data; Determining whether to compress a header of an upper layer based on the identified condition; And transmitting data according to the determined compression.

1A is a diagram illustrating a structure of an LTE system to which an embodiment of the present disclosure can be applied.
1B is a diagram illustrating a radio protocol structure in an LTE system to which an embodiment of the present disclosure can be applied.
1C is a diagram illustrating a structure of a next-generation mobile communication system to which an embodiment of the present disclosure can be applied.
1D is a diagram showing a radio protocol structure of a next-generation mobile communication system to which an embodiment of the present disclosure can be applied.
1E is a diagram illustrating a procedure for a base station to set Ethernet header protocol related configuration information to a terminal when a terminal establishes a connection with a network according to an embodiment of the present disclosure.
1F is a diagram illustrating an Ethernet Header Compression (EthHC) method according to an embodiment of the present disclosure.
FIG. 1G is a diagram illustrating a method of compressing an Ethernet header proposed when a Service Data Adaptation Protocol (SDAP) header or a layer device is configured according to an embodiment of the present disclosure.
1H is a diagram illustrating another Ethernet header compression method proposed when an SDAP header or a layer device is configured according to an embodiment of the present disclosure.
1I is a diagram illustrating a specific first embodiment of an Ethernet header compression method according to an embodiment of the present disclosure.
1J is a diagram illustrating a specific second embodiment of an Ethernet header compression method according to an embodiment of the present disclosure.
1K is a diagram illustrating embodiments of a structure of a feedback that can be used in a method for compressing a higher layer header according to an embodiment of the present disclosure.
1L is a diagram illustrating an operation of a transmitting PDCP layer device or a receiving PDCP layer device of a terminal or a base station according to an embodiment of the present disclosure.
1M illustrates a structure of a terminal according to an embodiment of the present disclosure.
1N illustrates a block configuration of a Transmission Reception Point (TRP) in a wireless communication system according to an embodiment of the present disclosure.

Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. In addition, in describing the present disclosure, when 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 disclosure and may vary according to the intention or custom of users or operators. Therefore, the definition should be made based on the contents throughout this specification.

Advantages and features of the present disclosure, and a method of achieving them will be apparent with reference to embodiments described later in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below, but may be implemented in a variety of different forms, and only these embodiments make the disclosure of the present disclosure complete, and common knowledge in the technical field to which the disclosure belongs. It is provided to completely inform the scope of the invention to those who have it, and the present disclosure is only defined by the scope of the claims. The same reference numerals refer to the same components throughout the specification.

In this case, it will be appreciated that each block of the flowchart diagrams and combinations of the flowchart diagrams may be executed by computer program instructions. Since these computer program instructions can be mounted on the processor of a general purpose computer, special purpose computer or other programmable data processing equipment, the instructions executed by the processor of the computer or other programmable data processing equipment are described in the flowchart block(s). It creates a means to perform functions. These computer program instructions can also be stored in computer-usable or computer-readable memory that can be directed to a computer or other programmable data processing equipment to implement a function in a particular way, so that the computer-usable or computer-readable memory It is also possible to produce an article of manufacture containing instruction means for performing the functions described in the flowchart block(s). Computer program instructions can also be mounted on a computer or other programmable data processing equipment, so that a series of operating steps are performed on a computer or other programmable data processing equipment to create a computer-executable process to create a computer or other programmable data processing equipment. It is also possible for instructions to perform processing equipment to provide steps for executing the functions described in the flowchart block(s).

In addition, each block may represent a module, segment, or part of code that contains one or more executable instructions for executing the specified logical function(s). In addition, it should be noted that in some alternative execution examples, functions mentioned in blocks may occur out of order. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order depending on the corresponding function.

In this case, the term'~ unit' used in this embodiment refers to software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and'~ unit' performs certain roles. do. However,'~ part' is not limited to software or hardware. The'~ unit' may be configured to be in an addressable storage medium, or may be configured to reproduce one or more processors. Thus, as an example,'~ unit' refers to components such as software components, object-oriented software components, class components and task components, processes, functions, properties, and procedures. , Subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, database, data structures, tables, arrays, and variables. The components and functions provided in the'~ units' may be combined into a smaller number of elements and'~ units', or may be further divided into additional elements and'~ units'. In addition, components and'~ units' may be implemented to play one or more CPUs in a device or a security multimedia card. Also, in an embodiment, the'~ unit' may include one or more processors.

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

A term for identifying an access node, a term for a network entity (network entity), a term for messages, a term for an interface between network objects, and various identification information used in the description below. Terms and the like are exemplified for convenience of description. Accordingly, the present disclosure is not limited to the terms described later, and other terms referring to objects having an equivalent technical meaning may be used.

For convenience of description below, this disclosure uses terms and names defined in the 3GPP 3rd Generation Partnership Project Long Term Evolution (LTE) standard. However, the present disclosure is not limited by the above-described terms and names, and may be equally applied to systems conforming to other standards. In the present disclosure, 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. In addition, the term terminal may refer to mobile phones, NB-IoT devices, sensors as well as other wireless communication devices.

Hereinafter, the base station is a subject that performs resource allocation of the terminal, and may be at least one of a gNode B, an eNode B, a Node B, a base station (BS), a radio access unit, a base station controller, or a node on a network. The terminal may include a user equipment (UE), a mobile station (MS), a cellular phone, a smart phone, a computer, or a multimedia system capable of performing a communication function. Of course, it is not limited to the above-described example.

The present disclosure relates to a method and apparatus for supporting compression and decompression of an Ethernet header in a next generation mobile communication system.

The present disclosure proposes a method of compressing and decompressing an Ethernet header in a next-generation mobile communication system using an Ethernet protocol. Through the method for compressing and decompressing the Ethernet header proposed in the present disclosure, transmission resources can be efficiently used. In addition, by using the method proposed in the present disclosure, more data can be transmitted with fewer transmission resources, and a more reliable modulation method can be used. Thus, high reliability and low delay can be guaranteed.

In the present disclosure, a transmitting end is a device that transmits data, and may include a base station, a terminal, a network entity, and a transmitting PDCP layer device. In addition, in the present disclosure, the receiving end refers to a device that receives data, and may include a base station, a terminal, a network entity, and a receiving PDCP layer device.

1A is a diagram illustrating a structure of an LTE system to which an embodiment of the present disclosure 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 consists of a Mobility Management Entity (MME) 1a-25 and a Serving-Gateway (S-GW) 1a-30. User Equipment (hereinafter referred to as UE or UE) 1a-35 may access an external network through ENBs 1a-05 to 1a-20 and S-GW 1a-30.

In FIG. 1A, ENBs 1a-05 to 1a-20 may correspond to an existing node B of the UMTS system. The ENB is connected to the UEs 1a-35 through a radio channel and can perform 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 required, and ENB (1a-05 ~ 1a-20) can be in charge of this. One ENB can typically control 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) for determining a modulation scheme and a channel coding rate according to a channel state of the terminal may be 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 illustrating a radio protocol structure in an LTE system to which an embodiment of the present disclosure 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) in the terminal and the ENB, respectively, It consists of 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 illustrating a structure of a next-generation mobile communication system to which an embodiment of the present disclosure 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 (New Radio Core Network)(1c-05). 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) for determining a modulation scheme and a channel coding rate according to a channel state of the terminal may be 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 an embodiment of the present disclosure can be applied. .

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

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

-Transfer of user plane data

-Mapping between a QoS flow and a DRB for both DL and UL for uplink and downlink

-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 above-described SDAP layer device, the UE may be configured with an RRC message to determine whether to use the header of the SDAP layer device or use the function of the SDAP layer device for each PDCP layer device, for each bearer, or for each logical channel. When the SDAP header is set, the UE can use 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 for the uplink and downlink QoS flow and data bearer. Mapping information can be instructed to be updated or reset. The SDAP header may include QoS flow ID information indicating QoS. The above-described QoS information may be used as data processing priority, scheduling information, and the like to support smooth service.

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.

Among the above-described functions, 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 reordering data in the rearranged order. It may include a function to convey to. Alternatively, the reordering function of the NR PDCP device may include a function that does not take the order into account and delivers it immediately, and may include a function of reordering the order to record the lost PDCP PDUs, and the lost PDCP PDU It may include a function to report the status of the data to the transmitting side, and may include a function of requesting retransmission of the 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

Among the above-described functions, the in-sequence delivery function of the NR RLC device refers to a function of sequentially delivering RLC SDUs received from a lower layer to an upper layer, and originally, one RLC SDU consists of several RLC SDUs. When it is divided and received, it may include a function of reassembling and transmitting it, and may include a function of rearranging the received RLC PDUs based on an RLC sequence number (SN) or a PDCP sequence number (SN). , May include a function of reordering the order to record the lost RLC PDUs, may include a function of reporting the status of the lost RLC PDUs to the sender, and request retransmission of the 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 the upper layer in order, or even if there is a lost RLC SDU, If the timer expires, it may include a function of delivering all RLC SDUs received before the timer starts to the upper layer in order, or if a predetermined timer expires even if there is a lost RLC SDU, all RLC SDUs received so far are It can include a function that is delivered to higher layers in order.

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 a complete RLC PDU, processed, and transmitted to the PDCP device. The above-described NR RLC layer may not include a concatenation function, and the above-described function may be performed in the NR MAC layer or may be replaced by a multiplexing function of the NR MAC layer.

The out-of-sequence delivery function of the NR RLC device described above refers to a function of directly delivering RLC SDUs received from a lower layer to an upper layer regardless of the order. When received divided into RLC SDUs, 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. can do.

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.

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

1E is a diagram illustrating a procedure for a base station to set Ethernet header protocol related configuration information to a terminal when a terminal establishes a connection with a network according to an embodiment of the present disclosure.

Referring to Figure 1e, in the present disclosure, the UE switches from an RRC idle mode or an RRC inactive mode (RRC Inactive mode or lightly-connected mode) to an RRC connected mode to establish a connection with a network. The procedure to be performed is described, and a procedure for the base station to set the Ethernet protocol related configuration information to the terminal is described. 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 or only in the uplink or in both directions, and the Ethernet header Protocol-related configuration information can be set only to terminals with UE capability to use the Ethernet protocol or to terminals with UE capability to use Ethernet header compression and decompression procedures.

When reporting the terminal capability to the base station, the terminal may define a new indicator and report to the base station whether the terminal can use the Ethernet protocol or the Ethernet header compression and decompression procedure as the indicator. In addition, by setting what type of Ethernet frame or Ethernet header to use for each bearer or logical channel, which fields are configured in the Ethernet header or the size of the Ethernet header in bytes or the size of each field of the Ethernet header. It is possible to set how many bits of is or how the fields of the Ethernet header are configured. In addition, when padding is added to the Ethernet frame, it may be indicated whether or not the function of preventing padding from being transmitted in an actual wireless link is set to be used or not set by removing the padding at the transmitting end and adding the padding at the receiving end.

In Figure 1e, the base station transmits a 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, so that the terminal can be switched to the RRC idle mode or the RRC inactive mode. (1e-01). In the future, a terminal for which a connection is not currently established (hereinafter, an idle mode UE or an INACTIVE UE) may perform an RRC connection establishment process or an RRC Connection Resume procedure with the base station when data to be transmitted occurs. The UE may establish reverse transmission synchronization with the base station through a random access process and transmit an RRCConnectionRequest message (in the case of a resume procedure, an RRCResumeRequest message) to the base station (1e-05). In the above-described message, the identifier of the terminal and the reason for establishing a connection (establishmentCause) may be stored.

The base station may transmit an RRCConnectionSetup message (in the case of a resume procedure, an RRCResume message) so that the terminal establishes an RRC connection (1e-10). In the above-described message, whether to use the Ethernet protocol or the Ethernet header compression and decompression procedure, or use, by each logical channel (logicalchannelconfig) or by bearer or by each PDCP device (PDCP-config) or by each SDAP layer device. Information indicating whether not to do so may be included. In addition, more specifically, in each logical channel or bearer or each PDCP device (or SDAP device), whether to use the Ethernet protocol or whether to use the Ethernet header compression and decompression procedure for a certain IP flow or QoS flow may be indicated. (In the SDAP device, information on whether to apply the Ethernet protocol, or the IP flow or QoS flow that uses or does not use the Ethernet header compression method is set, so that the SDAP device determines whether the Ethernet protocol is applied to the PDCP device, or the Ethernet header compression method. Whether to use or not may be indicated for each QoS flow.

As another method, the SDAP layer device or the PDCP device can self-check each QoS flow and decide whether to apply the Ethernet protocol or the Ethernet header compression method). In addition, as described above, if it is instructed whether to apply the Ethernet protocol or to use the Ethernet header compression method, the identifier for the predefined library or dictionary to be used in the Ethernet protocol application or the Ethernet header compression method or to be used. The size of the buffer size and the like may be indicated. In addition, the above-described 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, it can always be set to RLC AM bearer (a lossless mode with ARQ function, retransmission function) or RLC UM bearer, and header compression protocol (ROHC) And may be set together, and in some cases, may not be set at the same time. In addition, in the above-described message, whether to use the function of the SDAP layer device or whether to use the SDAP header may be indicated for each logical channel (logicalchannelconfig), for each bearer or for each PDCP device (PDCP-config), The above-described 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). Whether or not to apply ROHC to each of each may be set as an indicator.

In addition, it may be set whether to use a user data compression method (UDC) for each logical channel, each bearer, or each PDCP device, respectively, for an uplink and a downlink. That is, it may be set to be used in the uplink and not used in the downlink, and conversely, it may be set to be used in the uplink and not in the downlink. In addition, it can be set to be used in both directions. In addition, in the above-described message, the Ethernet header compression procedure and the ROHC header compression procedure may be set at the same time. In addition, in the above-described message, in the case of a handover (for example, a handover within a base station), or when transitioning from an RRC inactive mode to an RRC connected mode, an indicator to continue using the Ethernet header compression protocol-related configuration information or context without initializing (drbEthHCContinue) may be defined and indicated, and the terminal receiving the above-described indicator does not initialize the Ethernet header compression protocol-related configuration information or context in consideration of the above-described indicator when re-establishing the SDAP layer device or the PDCP layer device. , You can keep using it. This can reduce the overhead caused by reconfiguring the Ethernet header compression protocol.

In addition, the above-described message may instruct to initialize the Ethernet header compression protocol related configuration information or context by defining a new indicator. In addition, the above-described RRC message may set whether to set the SDAP protocol or the SDAP header. In addition, the above-described message sets what kind of Ethernet frame or Ethernet header to use for each bearer or for each logical channel, and determines which fields are configured in the Ethernet header or the size of the Ethernet header in bytes or the Ethernet header. You can set how many bits the size of each field is or how the fields of the Ethernet header are configured. In addition, when padding is added to the Ethernet frame, whether to set or not set to use a function of preventing padding from being transmitted in an actual wireless link by removing padding at the transmitting end and adding padding at the receiving end may be indicated.

In addition, RRC connection configuration information and the like are stored in the above-described 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 (1e-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 may transmit a message asking for the capabilities of the terminal. And the terminal can transmit a message reporting its capabilities. In the above-described message, whether the terminal can use the Ethernet protocol or the Ethernet header compression and decompression procedure may be indicated, and an indicator indicating this may be included and transmitted.

The RRCConnetionSetupComplete message described above 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 (1e-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 (1e-25). The above-described 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 (eg, Security Key, Security Algorithm) to be applied to the DRB. The base station exchanges a SecurityModeCommand message (1e-30) and a SecurityModeComplete message (1e-35) to configure security with the terminal. When the security configuration is completed, the base station transmits an RRCConnectionReconfiguration message to the terminal (1e-40).

In the above-described message, whether to use Ethernet protocol or Ethernet header compression and decompression procedures for each logical channel (logicalchannelconfig), for each bearer, for each PDCP device (PDCP-config), or for each SDAP layer device. Information indicating whether not to do so may be included. In addition, more specifically, in each logical channel or bearer or each PDCP device (or SDAP device), whether to use the Ethernet protocol only for a certain IP flow or a QoS flow, or whether to use the Ethernet header compression and decompression procedure will be indicated. (By setting information on whether to apply the Ethernet protocol to the SDAP device or the IP flow or QoS flow not to use or use the Ethernet header compression method, the SDAP device determines whether to apply the Ethernet protocol to the PDCP device or the Ethernet header compression method. Whether to use or not may be indicated for each QoS flow.

As another method, the SDAP layer device or the PDCP device may self-check each QoS flow and determine whether to apply the Ethernet protocol or the Ethernet header compression method or not). In addition, when it is instructed 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 size to be used. Etc may be indicated. In addition, the above-described 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, if the Ethernet protocol is applied or the Ethernet header compression method is set to be used, 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 the header compression protocol (ROHC ) May be set together, and in some cases, may not be set at the same time. In addition, the above-described 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 above-described 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 uplink and downlink Whether to apply ROHC to each of each of the indicators can be set as an indicator.

In addition, whether to use a user data compression method (UDC) for an uplink and a downlink may be set for each logical channel, each bearer, or each PDCP device. That is, it may be set to be used in the uplink and not used in the downlink, and conversely, it may be set to be used in the uplink and not in the downlink. In addition, it can be set to be used in both directions.

In addition, the above-described message may set the Ethernet header compression procedure and the ROHC header compression procedure at the same time. In addition, the above-described message is an indicator to continue use without initializing the Ethernet header compression protocol related configuration information or context in the case of handover (e.g., intra-base station handover) or when transitioning from RRC deactivation mode to RRC connection mode ( drbEthHCContinue) can be defined and indicated, and when re-establishing the SDAP layer device or the PDCP layer device, the terminal receiving the above indicator does not initialize the Ethernet header compression protocol related configuration information or context in consideration of the above indicator. , You can keep using it. This can reduce the overhead caused by reconfiguring the Ethernet header compression protocol.

In addition, the above-described message may instruct to initialize the Ethernet header compression protocol related configuration information or context by defining a new indicator. In addition, the above-described RRC message may set whether to set the SDAP protocol or the SDAP header. In addition, the above-described message sets what kind of Ethernet frame or Ethernet header to use for each bearer or for each logical channel, so what fields are configured in the Ethernet header, or how many bytes the Ethernet header is, or It is possible to set how many bits each field of the header is, or how the fields of the Ethernet header are configured. In addition, when padding is added to the Ethernet frame, it may be indicated whether or not to set or not to use a function to prevent padding from being transmitted in an actual wireless link by removing padding at the transmitting end and adding padding at the receiving end. .

In addition, the above-described message includes configuration information of the DRB in which user data is to be processed, and the terminal configures the DRB by applying the above-described information and transmits an RRCConnectionReconfigurationComplete message to the base station (1e-45). The base station after completing DRB setup with the terminal transmits an INITIAL CONTEXT SETUP COMPLETE message to the MME (1e-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 (1e-055, 1e-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-described processes are completed, the terminal transmits and receives data to and from the base station through the S-GW (1e-65, 1e-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 to refresh, add, or change the configuration (1e-75).

1F is a diagram illustrating an Ethernet Header Compression (EthHC) method according to an embodiment of the present disclosure.

Referring to FIG. 1F, higher layer data 1f-05 may be generated as data corresponding to services such as video transmission, photo transmission, web search, and Voice over LTE (VoLTE). Data generated in the application layer device may be processed through TCP/IP or UDP corresponding to the network data transport layer, or processed through Ethernet protocol and each header (1f-10, 1f-15, 1f-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 PDCP layer may perform the following procedure.

If the PDCP layer is configured to use a header compression (ROHC) or Ethernet header compression procedure by an RRC message such as 1e-10, 1e-40, or 1e-75 in FIG. 1e, TCP is used as ROHC as shown in 1f-21. The /IP header is compressed, and in the PDCP layer device as shown in 1f-22, an Ethernet header compression procedure may be performed on the Ethernet header 1f-20. In addition, a separate EHC (Ethernet header compression) field having a field for indicating whether the Ethernet header is compressed or a field indicating whether any fields of the Ethernet header are compressed (omitted) or not compressed (not omitted) , 1f-40) header may be configured and may be configured before 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 EHC header and compressed headers and data or EHC header A ciphering procedure is performed on and a PDCP PDU can be configured by configuring the PDCP header 1f-30. The above-described PDCP layer device includes a header compression/decompression device, and determines whether to perform header compression or not for each data as set in the above-described RRC message, and the above-described header compression/decompression device use. At the transmitting end, the transmitting PDCP layer device uses a header compression device to compress the Ethernet header or upper layer header (for example, TCP/IP header), and at the receiving end, the receiving PDCP layer device uses the header decompression device to compress the Ethernet header Alternatively, header decompression is performed on the upper layer header (eg, TCP/IP header).

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

The method of performing Ethernet header compression on the Ethernet header proposed in the present disclosure may mean a method of reducing the size of the header by omitting fields indicating fixed information and indicating only changed information. Therefore, initially, the entire 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 related to compression rate, etc.) are included and transmitted. Can be. In addition, according to an embodiment of the present disclosure, fields corresponding to unchanged information compared to all information initially transmitted (for example, a transmission address field or a destination address field (MAC address), or a preamble field or a start of frame (SFD)) Delimiter) or FCS (Frame CheckSum) or Ethernet type field, etc.) is omitted, or by including only fields corresponding to changed information without transmission, the header is configured to reduce the size of the header. As another method, according to an embodiment of the present disclosure, when compressible fields and non-compressible fields are distinguished, and when values of fields capable of compression are compared with field values of a complete header initially transmitted, If not changed, only fields that can be compressed are compressed (or omitted) and transmitted, and fields that cannot be compressed are always transmitted without compression (or omitting). In addition, an embodiment of the present disclosure may be characterized in that even one field among fields capable of compression is compared with a field value of a previously transmitted complete header, and if there is a changed value, the complete header is transmitted again. And, whenever the receiving PDCP layer device receives the complete header, it can always transmit a feedback that the complete header has been well received to the transmitting PDCP layer device.

In Figure 1f, the PDCP layer device or the SDAP layer device of the receiving end receives the compressed Ethernet frame (1f-25) from the lower layer device, and when the Ethernet header compression procedure is set, the first received uncompressed complete header By checking each field value of the Ethernet header of the Ethernet frame, it can be stored in the buffer 1f-30 for decompressing the receive Ethernet.

FIG. 1G is a diagram illustrating a method of compressing an Ethernet header proposed when a Service Data Adaptation Protocol (SDAP) header or a layer device is configured according to an embodiment of the present disclosure.

Referring to FIG. 1G, upper layer data 1g-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 (1g- 10, 1g-15, 1g-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 PDCP layer may perform the following procedure.

If the PDCP layer is configured to use a header compression (ROHC) or Ethernet header compression procedure by an RRC message such as 1e-10, 1e-40, or 1e-75 in FIG. 1e, TCP/ The IP header is compressed, and the Ethernet header compression procedure may be performed on the Ethernet header 1g-20 except for the SDAP header in the PDCP layer device as shown in 1g-22. In addition, a separate EHC (Ethernet header compression) field having a field for indicating whether the Ethernet header is compressed or a field indicating whether any fields of the Ethernet header are compressed (omitted) or not compressed (not omitted) , 1g-40) header may be configured, and may be configured before the compressed header. If integrity verification is set, integrity protection is performed on the SDAP header, PDCP header, EHC header, compressed headers and data, and the EHC header and compressed headers and data or SDAP header excluding the SDAP header A ciphering procedure is performed on compressed headers and data excluding the EHC header, and a PDCP PDU may be configured by configuring the PDCP header 1g-30.

The above-described PDCP layer device includes a header compression/decompression device, and determines whether to perform header compression or not for each data as set in the above-described RRC message, and the above-described header compression/decompression device use. At the transmitting end, the transmitting PDCP layer device uses a header compression device to compress the Ethernet header or upper layer header (for example, TCP/IP header), and at the receiving end, the receiving PDCP layer device uses the header decompression device to compress the Ethernet header Alternatively, header decompression is performed on the upper layer header (eg, TCP/IP header).

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

The method of performing Ethernet header compression on the Ethernet header proposed in the present disclosure may mean a method of reducing the size of the header by omitting fields indicating fixed information and indicating only changed information. Therefore, the entire header information and configuration information for compression (e.g., traffic (or service)-specific identifier (type) for Ethernet protocol, or traffic (or service)-specific serial number, compression rate-related information, etc.) I can. In addition, according to an embodiment of the present disclosure, fields corresponding to unchanged information compared to all information initially transmitted (for example, a transmission address field or a destination address field (MAC address), or a preamble field or a start of frame (SFD)) Delimiter) or FCS (Frame CheckSum) or Ethernet type field, etc.) is omitted, or by including only fields corresponding to changed information without transmission, the header is configured to reduce the size of the header.

As another method, according to an embodiment of the present disclosure, when compressible fields and non-compressible fields are distinguished, and when values of fields capable of compression are compared with field values of a complete header initially transmitted, If not changed, only fields that can be compressed are compressed (or omitted) and transmitted, and fields that cannot be compressed are always transmitted without compression (or omitting). In addition, according to an embodiment of the present disclosure, even one field among fields capable of compression may be characterized in that, if there is a field value and a changed value of a previously transmitted complete header, the complete header is transmitted again. And, whenever the receiving PDCP layer device receives the complete header, it can always transmit a feedback that the complete header has been well received to the transmitting PDCP layer device.

In addition, the Ethernet header compression method proposed in the present disclosure may not be applied to SDAP control data (SDAP control PDU) and SDAP header of an upper layer device. Therefore, in terms of network implementation, uncompressed SDAP control data or QoS information of an SDAP header can be read, and transmission resources can be scheduled quickly. In terms of terminal implementation, since the receiving end can read QoS information from the SDAP control data or SDAP header before decompression, implementation can be simplified. In addition, since the transmitting end can perform the SDAP control data or SDAP header generation in parallel with the header or data compression processing procedure or encryption procedure of the PDCP layer device, data processing time can be reduced.

1H is a diagram illustrating another Ethernet header compression method proposed when an SDAP header or a layer device is configured according to an embodiment of the present disclosure.

Referring to FIG. 1H, higher layer data 1h-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 (1h-10). , 1h-15, 1h-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 PDCP layer may perform the following procedure.

If the PDCP layer is configured to use a header compression (ROHC) or Ethernet header compression procedure by an RRC message such as 1e-10, 1e-40 or 1e-75 in FIG. 1e, TCP/ The IP header is compressed, and an Ethernet header compression procedure may be performed on the SDAP header and the Ethernet header 1h-20 in the PDCP layer device as shown in 1h-22. 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 (is omitted) or not compressed (are not omitted). EHC (Ethernet header compression, 1h-40) header is configured, and may 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 the EHC header 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 are ciphering, and the PDCP PDU can be configured by configuring the PDCP header 1h-30.

The above-described PDCP layer device includes a header compression/decompression device, and determines whether to perform header compression or not for each data as set in the above-described RRC message, and uses the above-described header compression/decompression device. do. At the transmitting end, the transmitting PDCP layer device uses a header compression device to compress the Ethernet header or upper layer header (for example, TCP/IP header), and at the receiving end, the receiving PDCP layer device uses the header decompression device to compress the Ethernet header Alternatively, header decompression is performed on the upper layer header (eg, TCP/IP header).

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

The method of performing Ethernet header compression on the Ethernet header proposed in the present disclosure may mean a method of reducing the size of the header by omitting fields indicating fixed information and indicating only changed information. Therefore, initially, the entire 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 related to compression rate, etc.) are included and transmitted. Can be. In addition, according to an embodiment of the present disclosure, fields corresponding to unchanged information compared to all information initially transmitted (for example, a transmission address field or a destination address field (MAC address), or a preamble field or a start of frame (SFD)) Delimiter) or FCS (Frame CheckSum) or Ethernet type field, etc.) is omitted, or by including only fields corresponding to changed information without transmission, the header is configured to reduce the size of the header.

As another method, according to an embodiment of the present disclosure, when compressible fields and non-compressible fields are distinguished, and when values of fields capable of compression are compared with field values of a complete header initially transmitted, If not changed, only the fields that can be compressed are compressed (or omitted) and transmitted, and fields that cannot be compressed are always transmitted without compression (or omitting). In addition, according to an embodiment of the present disclosure, even one field among fields capable of compression may be compared with a field value of a previously transmitted complete header, and if there is a changed value, the complete header may be transmitted again. And, whenever the receiving PDCP layer device receives the complete header, it can always transmit a feedback that the complete header has been well received to the transmitting PDCP layer device.

In Figure 1h, the PDCP layer device or SDAP layer device of the receiving end receives the compressed Ethernet frame (1h-25) from the lower layer device, and when the Ethernet header compression procedure is set, the first received uncompressed complete header By checking each field value of the Ethernet header of the Ethernet frame, it can be stored in the buffer 1h-30 for decompressing the receive Ethernet.

The above-described Ethernet header compression method may be applied equally to the SDAP header as well as the Ethernet header, and accordingly, the SDAP header may be compressed. Because, D/C (Data/Control) field, QFI (QoS Flow ID) field, RQI (Reflective QoS flow to DRB mapping Indication) field, RDI (Reflective QoS Indication) configured in SDAP header (uplink or downlink) This is because fields usually have fixed values. 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 the QoS mapping update is required. Accordingly, according to an embodiment of the present disclosure, a method of compressing an Ethernet header may be applied to the SDAP header and may be compressed together with the Ethernet header. As described above, when compression is also applied to the SDAP header, an embodiment of the present disclosure may be characterized in that the SDAP header is encrypted, and in an embodiment of the present disclosure, an LTE system and an SDAP header may be configured. By providing the same compression method to the existing NR system, it is possible to have convenience of implementation.

In addition, the header compression algorithm proposed in an embodiment of the present disclosure is applied only to PDCP user data (PDCP data PDU) received from an upper layer, and not applied to PDCP control data (PDCP control PDU) generated by a PDCP layer device. It is characterized by not.

As proposed in an embodiment of the present disclosure, in the Ethernet header compression protocol (1f-22), the PDCP layer device checks the Ethernet header when receiving data from the upper layer device, and uses the protocol to compress the Ethernet header. You can compress the header and define and use a new header (1f-40) in front of the compressed Ethernet header. An embodiment of the present disclosure may be characterized in that encryption is not performed on the new header 1f-40. Because, if encryption is not performed on the new header (1f-40) in the terminal implementation, after data processing such as integrity protection or encryption procedure is performed in the PDCP layer device, the SDAP header is set when data is transmitted to the lower layer device. If so, since the SDAP header, the PDCP header, or the new header can all be joined together at once, the terminal implementation can be facilitated.

As another method, an embodiment of the present disclosure may be characterized in that encryption is performed on the new header 1f-40.

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

When the header compression method proposed in an embodiment of the present disclosure is applied, in order for the receiving side to decompress the compressed Ethernet header, it is necessary to know which fields are compressed, omitted, or not transmitted. When compressing this 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 can be indicated which of a plurality of fields of the Ethernet header is compressed, omitted or not transmitted (for example, a context identifier), and a new The 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 not (or included) in the Ethernet header, the receiving side uses the first field to receive the compressed Ethernet header. You can calculate the size of That is, the receiving side can know the size of the received compressed Ethernet header 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) for all fields of the Ethernet header, but among fields of the Ethernet header, fields that can be compressed (or can be omitted) By restricting the mapping for indicating the presence or absence of compression (or the presence or absence of omission), the overhead of a new EthHC header can be reduced.

In addition, a 1-bit indicator may be defined in the new EHC header, and the indicator may indicate whether the Ethernet header (or SDAP header) is compressed or whether compression is not applied. 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 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.

Alternatively, 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 upper 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. For example, a first identifier indicating a header type or content may instruct to apply a first Ethernet header compression method, and the second identifier may instruct to apply a second Ethernet header compression method. Therefore, when a plurality of data streams or QoS flows are mapped to one PDCP layer device, various embodiments of the present disclosure may apply different header compression methods by applying a new identifier, and the receiving ends may distinguish them from each other. Other decompression methods can be performed.

In an embodiment of the present disclosure, the Ethernet header compression method may be applied not only to the Ethernet header but also to a general higher layer device header, and the header compression method may be referred to as an Ethernet header compression method in the present disclosure for convenience.

In addition, the configuration of the Ethernet header fields according to the type of the Ethernet header described above may be configured for each bearer as to which Ethernet header type or header fields are configured as an RRC message as described in FIG. 1E. For example, the configuration of the Ethernet header fields according to the type of the Ethernet header sets information on the type of the upper layer header (for example, the Ethernet header type) that can be set in the upper layer device of each bearer. Identifiers mapped to can be set to be applied to a header compression or decompression method. That is, an identifier or indicator indicating the type of the Ethernet header may be defined and used in the new header. In addition, the new header may include a checksum field so that the receiving end can successfully decompress the Ethernet header. Alternatively, a field instructing to initialize a buffer for compression of the transmitting PDCP layer device and a 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, the new EHC header may define and use a field indicating a feedback request when the receiving end PDCP layer device successfully receives data. That is, the PDCP layer device at the receiving end does not always send a feedback whenever it receives a complete header, but transmits the feedback only when the PDCP layer device at the transmitting end requests it as an indicator, thereby reducing overhead.

Another Ethernet header compression method may be used based on the new EHC header. For example, when the transmitting end compresses the Ethernet header, it performs compression in order, and when compression is performed, it is compared with the fields of the previously transmitted Ethernet header and compressed (omitted) if the values of the header fields have not changed. The first field can be set accordingly, and if the Ethernet header field value is different from the previously transmitted Ethernet header field value, the Ethernet header compression is completed by not compressing (including) and setting the first field accordingly. can do. In the above description, the order may be defined in ascending order based on the PDCP serial number or COUNT value, and the previous Ethernet header includes an Ethernet header corresponding to data having a PDCP serial number or COUNT value as small as 1. I can instruct.

When the receiving end receives the compressed Ethernet header, the first field can be checked, and if the fields compressed (omitted) in the Ethernet header have the same values as the fields of the previously received Ethernet header, 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. By restoring the compressed Ethernet header, the receiver may remove the new EthHC header and transmit the restored data to an upper layer. In addition, the transmitting end can transmit all Ethernet header information when initially transmitting the Ethernet header. In other words, the transmitting end can transmit without performing Ethernet header compression so that the receiving end can identify all Ethernet header information at first.

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

1I is a diagram illustrating a specific first embodiment of an Ethernet header compression method according to an embodiment of the present disclosure.

Referring to FIG. 1i, in the method of compressing an Ethernet header in the first embodiment of the present disclosure, a plurality of header fields 1i-31, 1i-32, 1i-33, 1i-34, 1i- 35, 1i-36, 1i-37), the field value does not change, or 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 the required field or valid field This is a method of selectively transmitting only fields or fields whose field values have been changed. For example, in the method of compressing an Ethernet header in the first embodiment of the present disclosure, among a plurality of fields included in the Ethernet header, a first field 1i-31, a second field 1i-32, Among the third field (1i-33), fourth field (1i-34), fifth field (1i-35), sixth field (1i-36), and seventh field (1i-37), the first field If (1i-31), the second field (1i-32), the fourth field (1i-34), the fifth field (1i-35), and the seventh field (1i-37) can be omitted, or to be transmitted If not required, or if the values are the same as previously transmitted Ethernet header field values, it may mean a method of transmitting only the third field 1i-33 and the sixth field 1i-36.

In addition, an embodiment of the present disclosure proposes a method of separately configuring a new EHC header so that compression by applying the above-described method and decompression at a receiving end can be performed. In the first embodiment of the present disclosure, a new EHC header may have bitmap structures 1i-11 and 1i-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 whether each bit has a corresponding header field is compressed or not, as a value of 0 or 1. I can instruct. Alternatively, the above-described 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. 1i, when the PDCP layer device of the transmitting end receives the Ethernet frame (1i-05) from the upper layer device and the Ethernet header compression procedure is set, each field of the Ethernet header of the first received Ethernet frame Values can be stored in a buffer (1i-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 start to be applied. A plurality of all of the aforementioned headers may be transmitted. For example, a plurality of all headers and data (first data, second data, and subsequent data) may be transmitted until a feedback indicating that the entire header has been normally received from the receiving PDCP layer device is received.

If the above-described Ethernet compression procedure has started, and when the next Ethernet frame is received, each field value of the Ethernet header can be compared with the field values stored in the transmission buffer for Ethernet compression described above, and fields having the same value If present, the corresponding field may be omitted, a bit corresponding to or mapped to the omitted field is 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 Ethernet compression described above, and a field having a different value exists, the corresponding field is not omitted, but omitted. A bit corresponding to or mapped to a field that has not been mapped may be set to 0 (or 1), and it may be indicated that the field is not omitted.

And, if integrity protection is set, integrity protection can be performed, and encryption procedures can be performed, a new header (1i-10) is configured, a PDCP header is configured and spliced, and transmitted to a lower layer device. Can be.

The new header 1i-10 may indicate which field of the Ethernet header is present (not compressed) or not (compressed) in each bit like a bitmap.

The new header 1i-10 may indicate whether the Ethernet header compression procedure has been performed or not by defining a new field (for example, a 1-bit indicator). The new header 1i-10 is a 1-bit indicator so that it is possible to immediately indicate when Ethernet header compression has not been performed, so that the receiving end may not perform processing for the new header and the uncompressed higher layer header. When the Ethernet header compression algorithm is set, the 1-bit indicator may be defined to be located at the beginning of a new EHC header that always exists, and 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 is performed or not performed may be defined and used in the SDAP header or PDCP header. When the 1-bit indicator is defined in the SDAP header or the PDCP header, when the Ethernet header compression procedure is not performed, the new header 1i-10 itself for Ethernet header compression may be omitted, thereby reducing overhead. In addition, when the bitmap field is set to a value of 0 (or 1), it can be defined and used as a special value indicating an uncompressed complete header (1i-26), or compression of the transmitting PDCP layer device. It may be instructed to initialize a buffer for and a buffer for decompression of the receiving PDCP layer device.

In Figure 1i, the PDCP layer device or the SDAP layer device of the receiving end receives the compressed Ethernet frame (1i-25) from the lower layer device, and when the Ethernet header compression procedure is set, the first received uncompressed complete header Each field value of the Ethernet header of the Ethernet frame can be checked and stored in the buffer 1i-30 for decompressing the receive Ethernet. And, when the PDCP layer device or SDAP layer device of the receiving end has successfully received a complete header (for example, SDAP header or Ethernet header), it transmits feedback on this to the transmitting PDCP layer device to start applying Ethernet header compression. can do. The first Ethernet frame can be delivered to the upper layer device without decompressing the Ethernet header.

Then, the PDCP layer device or the SDAP layer device of the receiving end decodes the next Ethernet frame when it receives it, and checks a new EHC header to determine whether the header is compressed or not. If not compressed, the PDCP layer device or the SDAP layer device of the receiving end may perform integrity verification, remove the EHC header, and transmit data to the upper layer. If it is indicated that the Ethernet header (or SDAP header) is compressed in the new EHC header, certain fields are omitted (compressed) by checking the field value of the new header (1i-10) for Ethernet compression, and some fields are It can be checked whether it is omitted (not compressed). At this time, the fields indicated to be omitted (compressed) are restored to the field values stored in the receiving buffer 1i-30 for decompression by the receiving end, thereby restoring the Ethernet header before compression is performed (decompression is performed). Perform). 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 fields described above. . Then, the receiving end performs decoding, and if integrity protection is set, performs integrity verification, and if there is no error, an Ethernet frame is constructed with the above-described restored Ethernet header, and transmitted to the upper layer device.

The transmitting PDCP layer apparatus applies the Ethernet header compression method, and if the field values of the Ethernet header are changed, indicates to the new EHC header that it has not been compressed, transmits a complete header to initialize the buffer of the receiver, and returns the complete header. You can set them to values. In addition, when receiving the complete uncompressed header, the receiving PDCP layer device may transmit a successful feedback to the transmitting PDCP layer device.

In an embodiment of the present disclosure, whenever the receiving PDCP layer device receives a complete uncompressed header, it may always transmit a feedback indicating that it has been successfully received to the transmitting PDCP layer device. In addition, in an embodiment of the present disclosure, when receiving a complete uncompressed upper layer header, the receiving PDCP layer device always transmits a successful feedback to the transmitting PDCP layer device, but receives an uncompressed upper layer header. When doing so, you can choose not to send feedback. That is, the receiving PDCP layer device may perform different operations according to whether the received data is compressed by an upper layer.

In an embodiment of the present disclosure, a separate new EHC header may have a fixed size (eg, 1 byte or 2 bytes).

In addition, in an embodiment of the present disclosure, compression and decompression may be performed by applying the above-described method to the length field of the Ethernet header. Alternatively, the length field of the Ethernet header may be transmitted without always performing compression.

Alternatively, the length field of the Ethernet header may not always be compressed and transmitted, and the receiving PDCP layer device decompresses the remaining fields except the length field, and then the length of the length field (the length of the length field is known as fixed). Value), the PDCP layer device may calculate the length of the Ethernet frame, 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, 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, and the receiving PDCP layer device can By calculating the field value and deriving it as described above, the length field value of the Ethernet header 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 is defined and may be used. That is, the overhead may be reduced by not always sending the feedback whenever the PDCP layer device at the receiving end receives a complete header, but transmits the feedback only when the PDCP layer device at the transmitting end requests it as an 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, and a method for compressing and not compressing which fields is also 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 may instruct to apply a first bitmap field or bitmap mapping, and the second identifier may indicate to apply a second bitmap field or bitmap mapping. have.

Therefore, when a plurality of data streams or QoS flows are mapped to one PDCP layer device, different header compression methods may be applied by applying the above-described new identifier, and the receiver performs different decompression methods by distinguishing them. I can do it. 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 buffered by the transmitting PDCP layer device for each higher layer header structure. Alternatively, it may be stored in the buffer of the receiving PDCP layer device.

1J is a diagram illustrating a specific second embodiment of an Ethernet header compression method according to an embodiment of the present disclosure.

Referring to FIG. 1J, in the second embodiment of the present disclosure, when a plurality of data streams or QoS flows are mapped to one bearer or one PDCP layer device, a data stream having different header structures of higher layer devices or It describes a method of applying different header compression and decompression methods for each QoS flow.

In the second embodiment of the present disclosure, 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 1j-01. In addition, fields that can be compressed (can be omitted) and fields that cannot be compressed (cannot be omitted) can be defined in the second higher layer header structure 1j-02. In the new EHC header, identifiers indicating different upper layer header structures, that is, CTI (Compressed Type Identifier) fields (1j-10), are configured to determine which upper layer device header structure is compressed to the receiving PDCP layer device. Can be indicated.

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 1j-15, and performs compression when initially transmitted. A header compression method can be applied when data including a complete header that has not been completed is transmitted, and a feedback indicating that the complete header information has been successfully received is received from the receiving PDCP layer device. That is, if, among the higher layer header field values of the received data, all fields that can be compressed are the same as the field values stored in the transmission buffer, the transmitting PDCP layer device compresses all fields that can be compressed. , Fields that cannot be compressed are configured as they are, and an identifier indicating the first upper layer header structure and an indicator CTI (Compressed Type Identifier) field (1j-10) indicating that compression has been performed are set in the new EHC header. Can be transmitted.

When it is indicated that the higher layer header is not compressed in the new EHC header of the received data, the receiving PDCP layer device considers it to be a complete higher layer header (field values of one or more fields among fields that can be compressed) When this 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 a complete upper layer header without performing compression on the upper layer header.) The field values stored in the buffer 1j-30 of the receiving PDCP layer device may be updated with the field values of the header, and a feedback indicating successful reception may be transmitted to the transmitting PDCP layer device.

If the receiving PDCP layer device indicates that the higher layer header is compressed in the new EHC header of the received data, the receiving PDCP layer device checks the identifier indicating the type of the higher layer header included in the new EHC header, Fields defined to enable compression in the upper layer header structure indicated by the identifier may 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 The structure (fields that can be compressed and decompressed in the second higher layer header structure) can be indicated.

In the second embodiment of the present disclosure described above, the receiving PDCP layer device may always transmit a feedback indicating that it has been successfully received to the transmitting PDCP layer device whenever it receives the complete uncompressed header. In addition, in the present disclosure, the receiving PDCP layer device always transmits a feedback that it has been successfully received to the transmitting PDCP layer device when receiving a complete uncompressed upper layer header, but when receiving an uncompressed upper layer header, it transmits the feedback. It may not be transmitted, and different operations may be performed depending on whether the received data is compressed by an upper layer.

In addition, in the second embodiment of the present disclosure, 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 selected for each higher layer header structure. It can be stored in a buffer of a transmitting PDCP layer device or a buffer of a receiving PDCP layer device.

In the above-described new EHC header, an identifier indicating each of the plurality of Ethernet header compression methods and an indicator field indicating whether compression has been performed may be defined and used. In addition, the above-described identifier may indicate an Ethernet header type (type) or a QoS flow identifier. Because, a plurality of upper layer headers (eg, various types of Ethernet headers) having different header structures are composed of different fields, and the method of compressing and not compressing which fields is also appropriately used. It has to be applied differently. Thus, 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 a new identifier, and different decompression methods can be performed at the receiving end by distinguishing them. have.

In an embodiment of the present disclosure, when the transmitting PDCP layer device receives 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. Multiple headers may be transmitted. For example, the transmitting PDCP layer device transmits a plurality of total headers and data (first data, second data, and subsequent data) until feedback that the entire header has been normally received from the receiving PDCP layer device. I can.

In an embodiment of the present disclosure, by defining a new field (for example, a 1-bit indicator) in the above-described new header 1g-10, it may be indicated whether or not the Ethernet header compression procedure has been performed. In an embodiment of the present disclosure, a case in which Ethernet header compression is not performed can be immediately indicated by a 1-bit indicator, so that processing for a new header and an uncompressed higher layer header may not be performed at the receiving end. When the Ethernet header compression algorithm is set, the 1-bit indicator is defined to be located 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 or not the Ethernet header compression procedure has been performed may be defined and used in the SDAP header or the 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 1g-10 itself for Ethernet header compression can be omitted, thereby reducing overhead. In addition, when the bitmap field is set to a value of 0 (or 1), it may be defined and used as a special value indicating a complete uncompressed header. Alternatively, it may be instructed to initialize the buffer for compression of the transmitting PDCP layer device and the buffer for decompression of the receiving PDCP layer device.

In Figure 1g, the PDCP layer device or the SDAP layer device of the receiving end receives the compressed Ethernet frame (1g-25) from the lower layer device, and when the Ethernet header compression procedure is set, the first received uncompressed complete header By checking each field value of the Ethernet header of the Ethernet frame, it can be stored in the buffer (1g-30) for decompression of the receive Ethernet. In addition, when the PDCP layer device or SDAP layer device of the receiving end has successfully received a complete header (for example, SDAP header or Ethernet header), it transmits feedback on this to the transmitting PDCP layer device to start applying Ethernet header compression. I can. The first Ethernet frame can be delivered to the upper layer device without decompressing the Ethernet header. Then, the PDCP layer device or the SDAP layer device of the receiving end decodes when the next Ethernet frame is received, and checks whether the header is compressed or not, by checking the new EHC header, and if it is not compressed, the integrity verification May be performed, the EHC header is removed, and data may be transmitted to an upper layer.

If the new EHC header indicates that the Ethernet header (or SDAP header) is compressed, the PDCP layer device or SDAP layer device of the receiving end checks the field value of the new header (1g-10) for Ethernet compression Is omitted (compressed) and which fields are not omitted (uncompressed), and fields indicated to be omitted (compressed) are restored to the field values stored in the receiving buffer for decompression. By doing so, the Ethernet header before compression is performed is restored (decompression is performed). Further, since values for fields indicated as not being omitted (not compressed) are new or changed values, the receiving end stores new or changed values in the receiving buffer for decompression as field values according to the field. Then, the receiving end performs decoding, and if integrity protection is set, performs integrity verification, and if there is no error, an Ethernet frame is constructed with the restored Ethernet header and transmitted to the upper layer device.

In an embodiment of the present disclosure, when the Ethernet header compression method is applied and the field values of the Ethernet header are changed, the transmitting PDCP layer device indicates to the new EHC header that it is not compressed, and transmits the complete header, thereby providing a buffer of the receiving end. Can be initialized and set back to the values of the complete header. 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 an embodiment of the present disclosure, the receiving PDCP layer device may always transmit a feedback indicating that it has been successfully received to the transmitting PDCP layer device whenever it receives a complete uncompressed header. In addition, in an embodiment of the present disclosure, when receiving a complete uncompressed upper layer header, the receiving PDCP layer device always transmits a feedback that it has successfully received to the transmitting PDCP layer device, but receives the uncompressed upper layer header. When doing so, you can choose not to send feedback. That is, the receiving PDCP layer device may perform different operations depending on whether the received data is compressed by an upper layer.

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

In addition, in an embodiment of the present disclosure, compression and decompression may be performed by applying the above-described method to the length field of the Ethernet header. Alternatively, the length field of the Ethernet header may be transmitted without always performing compression.

Alternatively, the length field of the Ethernet header may not be transmitted by always compressing, and after the receiving PDCP layer device decompresses the remaining fields except the length field, the length of the length field (the length of the length field is fixed). Since it is a known value), the PDCP layer device calculates the length of the Ethernet frame, and then restores the length value in the length field of the Ethernet header. In this case, the indication of the length field may be omitted in the new EHC header, and even if the length field value is different for each data, the transmitting PDCP layer device can always omit (compress) the length field and transmit it, and the receiving PDCP layer device may By calculating the length field value and deriving it as described above, it is possible to always restore the length field value of the Ethernet header.

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

In the Ethernet header compression method proposed in the present disclosure, by applying the first embodiment of the present disclosure, the transmitting PDCP layer apparatus includes an identifier indicating a compression method, a header type, or a data flow type together with a bitmap field, and is not compressed. It can be configured to transmit data with an Ethernet header that is not available. Through data transmission of the transmitting PDCP layer device, the receiving PDCP layer device can know a header compression method applied to the type of Ethernet header of each data from the bitmap field. In addition, the receiving PDCP layer device may store field values of the uncompressed Ethernet header and use the stored field values when restoring field values of the compressed Ethernet headers later. The above-described bitmap field may be used as a field indicating a header compression method with an identifier indicated together. For example, as a compression method for the indicated identifier, it may be indicated which field is to be compressed or which field is not compressed as a bitmap field.

In the present disclosure, the complete header transmitted by the transmitting PDCP layer apparatus includes an EHC header including a bitmap field and a compression method, an identifier indicating a header type or a data flow type, an indicator indicating whether to compress, etc., and an uncompressed A header including an Ethernet header can be indicated. For example, the above-described complete header may indicate an Ethernet header compression method using a bitmap field and an identifier for a corresponding data flow before applying the Ethernet header compression method. In addition, the above-described complete header may indicate an initial complete header transmitted by the transmitting PDCP layer apparatus in order to indicate to the receiving PDCP layer apparatus the uncompressed Ethernet header field values. When the receiving PDCP layer apparatus receives the above-described complete header, the receiving PDCP layer apparatus uses the above-described bitmap field to determine an Ethernet header compression method, an identifier for the data flow, and uncompressed Ethernet header field values. Able to know. Through this, the receiving PDCP layer device may perform a decompression procedure for compressed Ethernet headers received later.

In the present disclosure, the transmitting PDCP layer device may transmit data having a plurality of complete headers to the receiving PDCP layer device, and then immediately apply an Ethernet header compression procedure to the data to be transmitted. In this case, since the transmitting PDCP layer device does not need to check the feedback from the receiving end, the header compression procedure can be quickly started. As another method, when the sending PDCP layer device transmits data having one or more complete headers and then receives a feedback indicating that the complete header has been successfully received from the receiving PDCP layer device, the sending PDCP layer device The header compression method can be applied to data. In this case, an error rate in decompression of the receiving end, which may occur when complete headers are lost, may be reduced.

As described above, when the identifier for the data flow and the header compression method are synchronized and applied by a complete header in the transmitting PDCP layer device and the receiving PDCP layer device, as in the second embodiment of the present disclosure, A new EHC header including an identifier or an identifier indicating a header compression method or an indicator indicating whether to compress a header, and the like, and an Ethernet header compression method are applied, so that a compressed Ethernet header may be transmitted together with data. In addition, the compressed Ethernet header may be decompressed by applying new EHC header information of the receiving end and an Ethernet header decompression method. Accordingly, when the method described in the second embodiment of the present disclosure is applied, even when a plurality of data flows are mapped to one bearer, different header compression and decompression methods may be applied for each data flow. Through this, the ease of implementation can be enhanced.

Embodiments proposed in the present disclosure may be applied together to improve the convenience of implementation. For example, in the initial stage of the header compression method, the first embodiment of the present disclosure may be applied to identify a data flow or type, or to define a header compression method and synchronize a transmitting PDCP layer device and a receiving PDCP layer device. have. Thereafter, in order to apply the header compression procedure, the second embodiment of the present disclosure may be applied. In addition, by applying the first embodiment again during data transmission/reception, the transmitting PDCP layer device and the receiving PDCP layer device may be updated with a new identifier or header compression method.

In the first and second embodiments of the present disclosure described above, a method in which a transmitting PDCP layer device can dynamically indicate an identifier or a header compression method using user layer data (eg, a complete header) is proposed. Became.

Hereinafter, in the present disclosure, an identifier indicating a predefined header compression method may be set together with an identifier for each Ethernet header structure or for each data flow as an RRC message. In addition, methods for applying different compression methods to each Ethernet header structure or data flow in the transmitting PDCP layer device and the receiving PDCP layer device are proposed.

A specific third embodiment of the Ethernet header compression method proposed in the present disclosure is as follows.

In the third embodiment of the present disclosure, the header compression and decompression methods proposed in the second embodiment may 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 necessary to distinguish data streams or QoS flows having header structures of different upper layer devices. It may not be. That is, an identifier indicating different upper layer header structures or different higher layer compression methods may be unnecessary 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 third embodiment of the present disclosure, only a field indicating whether the higher layer header is compressed or not compressed is defined and set in the new EHC header or the PDCP header, so that the method proposed in the second embodiment described above is Can be applied. Through this, compression on the upper layer device header may be performed in the transmitting PDCP layer device, and decompression may be performed in the receiving PDCP layer device.

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

1K is a diagram illustrating embodiments of a structure of a feedback that can be used in a method for compressing a higher layer header according to an embodiment of the present disclosure.

Referring to FIG. 1K, it is proposed to define a new PDCP control data (PDCP control PDU) by setting a new PDU type field value with a first feedback structure 1k-01. New PDCP control data, when the upper layer compression and decompression method (or protocol) is set in the receiving PDCP layer device, each time the upper layer header of the received data is not compressed and a complete upper layer header is received (or feedback When instructed by the transmitting PDCP layer device), it is triggered and configured, and may be transmitted to the transmitting PDCP layer device. The new PDCP control data may be indicated by defining an indicator indicating that the transmitting PDCP layer apparatus has successfully received the complete upper layer header transmitted without compression or has not received it.

Alternatively, the new PDCP control data itself may indicate that the transmitting PDCP layer device has successfully received the complete upper layer header transmitted without compression. With the above-described 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 deliver feedback to the Ethernet compression protocol of the transmitter when Ethernet decompression failure occurs (for example, a checksum error occurs). That is, in the newly defined PDCP control data, that Ethernet decompression has failed (or that a checksum error has occurred) may be indicated, and that the transmission buffer for Ethernet header compression at the transmitting end should be initialized. It could be.

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

In addition, a new field (CTI) indicating the type of the upper layer header or the type of the higher layer header compression method may be defined and indicated, and for a certain higher layer header or higher layer header compression method as new PDCP control data, An indicator indicating that the transmitting PDCP layer device has successfully received or failed to receive a complete upper layer header transmitted without compression may be defined and indicated. 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 dictate that.

With the feedback as described above, 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 deliver feedback to the Ethernet compression protocol of the transmitter when an Ethernet decompression failure occurs (for example, a checksum error occurs). That is, the newly defined PDCP control data can 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, and that the transmitting end Ethernet header compression It may also indicate that initialization of the transmit buffer for the device should be performed.

In FIG. 1K, 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 (1k-03). New PDCP control data is, when the upper layer compression and decompression method (or protocol) is set in the receiving PDCP layer device, 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) is triggered and configured, and may be transmitted to the transmitting PDCP layer device. The new PDCP control data may be indicated by defining an indicator indicating that the transmitting PDCP layer apparatus has successfully received the complete upper layer header transmitted without compression or has not received it. Alternatively, the new PDCP control data itself may indicate that the transmitting PDCP layer device has successfully received the complete upper layer header transmitted without compression.

In addition, a new field indicating the PDCP serial number (PDCP SN) is defined and indicated, so that a complete upper layer header transmitted by the transmitting PDCP layer device without compression is successfully received for a certain PDCP serial number as new PDCP control data. An indicator indicating that it has done or has not been received may be defined and indicated. Alternatively, the new PDCP control data itself may indicate that, for data indicated by the new PDCP serial number field, the transmitting PDCP layer apparatus has successfully received the complete higher layer header transmitted without compression.

With the above-described 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 deliver 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 be indicated 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 compression of the Ethernet header at the transmitting end It may be indicated that the initialization of is to be performed.

In FIG. 1K, it is proposed to define a new PDCP control data (PDCP control PDU) by determining a new PDU type field value with a fourth feedback structure (1k-04). New PDCP control data, when the upper layer compression and decompression method (or protocol) is set in the receiving PDCP layer device, each time a complete upper layer header is received without compression of the upper layer header of the received data (or feedback When instructed by the transmitting PDCP layer device), it may be triggered, configured, and transmitted to the transmitting PDCP layer device. The new PDCP control data may be indicated by defining an indicator indicating that the transmitting PDCP layer apparatus has successfully received the complete upper layer header transmitted without compression or has not received it. Alternatively, the new PDCP control data itself may indicate that the transmitting PDCP layer device has successfully received the complete upper layer header transmitted without compression.

In addition, a new field (COUNT) indicating the COUNT value is defined and indicated, and for a certain COUNT value as new PDCP control data, the transmitting PDCP layer device has successfully received the complete upper layer header transmitted without compression, or An indicator indicating that the reception has not been received may be defined and indicated. As another method, the new PDCP control data itself may indicate that, for data indicated by the new COUNT value field, the transmitting PDCP layer apparatus has successfully received the complete upper layer header transmitted without compression.

With the above-described 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 deliver 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 be indicated that Ethernet decompression has failed (or that a checksum error has occurred) for the data of a certain COUNT value, and the transmission buffer for compressing the Ethernet header of the transmitting end It may be indicated that initialization should be performed.

In FIG. 1K, it is proposed to use a PDCP status report as a feedback among PDCP control data (PDCP control PDUs) in a fifth feedback structure 1k-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 transmitted. When instructed by the PDCP layer device), it may be triggered, configured, and transmitted to the transmitting PDCP layer device. The PDCP status report may be indicated by defining an indicator indicating that the transmitting PDCP layer apparatus has successfully received the complete upper layer header transmitted without compression or has not received it.

In addition, with the PDCP status report, it may be indicated that the transmitting PDCP layer apparatus has successfully received or failed to receive the complete upper layer header transmitted without compression for a certain COUNT value. That is, the FMC (First Missing COUNT value) field indicates the first COUNT value that the receiving PDCP layer device has not yet delivered to the upper layer, and bitmap fields after that are 1 bit for COUNT values greater than the first COUNT value. Mapping can be performed to indicate whether a value of 0 or 1 has been successfully received.

In addition, the PDCP status report may be used to deliver feedback to the Ethernet compression protocol of the transmitting end when an Ethernet decompression failure occurs (for example, a checksum error occurs). That is, in the newly defined PDCP control data, it may be indicated that Ethernet decompression has failed (or that a checksum error has occurred) for the data of a certain COUNT value, and the transmission buffer for compressing the Ethernet header of the transmitting end It may be indicated that initialization should be performed. That is, the FMC field indicates the first COUNT value that the receiving PDCP layer device has not yet delivered to the upper layer, and bitmap fields after that may indicate COUNT values greater than the first COUNT value using 1 bit. .

In the present disclosure, as a sixth feedback structure, it is proposed 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. A new field of the PDCP header or EHC header is set whenever a higher layer compression and decompression method (or protocol) is set in the receiving PDCP layer device, when the upper layer header of the received data is not compressed and a complete upper layer header is received. (Or feedback is indicated by the transmitting PDCP layer device) It may be set and transmitted to the transmitting PDCP layer device. The new field may indicate that the transmitting PDCP layer device has successfully received or failed to receive the complete upper layer header transmitted without compression.

The present disclosure relates to the operation of the transmitting PDCP layer device when the upper 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.

An operation of a transmitting PDCP layer apparatus of a terminal or a base station proposed by an embodiment of the present disclosure 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 referred to as TX_NEXT.

The operation of the transmitting PDCP layer device proposed in an embodiment of the present disclosure is as follows.

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

-And the transmitting PDCP layer device allocates a COUNT value corresponding to TX_NEXT to the data received from the upper layer. TX_NEXT may be set to 0 as an initial value, and TX_NEXT maintains a COUNT value for the next data to be transmitted (PDCP SDU).

-If the header compression protocol (ROHC) is set for the transmitting PDCP layer device, header compression may be performed on 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,

■ Or, if any 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 with the previously transmitted Ethernet header field values) If different)

■ 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 sending PDCP layer device does not perform Ethernet header compression until a feedback from the receiving PDCP layer device indicating that it has been successfully received for the uncompressed complete upper layer header (Ethernet header).

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

◆ The transmitting PDCP layer device performs compression by applying the Ethernet header compression method to the data received from the upper layer.

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

And, the encryption procedure may be performed using a security key for data and a COUNT value of TX_NEXT allocated to the data. In addition, in the COUNT value of the TX_NEXT variable, lower LSBs equal to the length of the PDCP serial number may be set as the PDCP serial number.

And, the transmitting PDCP layer apparatus increases the COUNT value of the TX_NEXT variable by 1, and transmits the above-described processed data to the lower layer together with the PDCP header to the lower layer.

In another method of the present disclosure, when the receiving PDCP layer device receives the complete header transmitted by the transmitting PDCP layer device, the receiving PDCP layer device generates and transmits feedback, or the transmitting PDCP layer device applies a header compression procedure. The timing and method may be performed differently according to the mode of the RLC layer device to which the transmission/reception PDCP layer device is connected. For example, in the case of a transmit/receive PDCP layer device connected to an RLC layer device operating in the RLC AM mode, since there is no data loss, the transmitting PDCP layer device may transmit one complete header. When the receiving PDCP layer device receives one complete header, it may configure a corresponding feedback and transmit it to the transmitting PDCP layer device. When receiving feedback for the first time, the transmitting PDCP layer apparatus may transmit the data by applying a header compression procedure to subsequent data.

As another method, in the case of a transmitting/receiving PDCP layer device connected to an RLC layer device operating in the RLC UM mode, data loss may occur, so the transmitting PDCP layer device may transmit a plurality of complete headers. Whenever the receiving PDCP layer device receives a plurality of complete headers, it may configure a feedback corresponding thereto and transmit it to the transmitting PDCP layer device. When receiving feedback for the first time, the transmitting PDCP layer device may apply a header compression procedure to subsequent data and transmit.

As another method, in the case of the transmitting/receiving PDCP layer device connected to the RLC layer device operating in the RLC UM mode, data loss may occur, so the transmitting PDCP layer device provides feedback from the receiving PDCP layer device (complete header has been successfully received. Can continue to send the complete header until it receives feedback). Whenever the receiving PDCP layer device receives the complete header, it may construct a feedback corresponding thereto and transmit it to the transmitting PDCP layer device. When receiving feedback for the first time, the transmitting PDCP layer device may stop transmitting the complete header and apply a header compression procedure to subsequent data to transmit.

Alternatively, in the case of a transmitting/receiving PDCP layer device connected to an RLC layer device operating in the RLC AM mode, the transmitting PDCP layer device continues until it receives a feedback (feedback indicating that the complete header has been successfully received) from the receiving PDCP layer device. So you can send the complete header. Whenever the receiving PDCP layer device receives the complete header, it may construct a feedback corresponding thereto and transmit it to the transmitting PDCP layer device. When receiving feedback for the first time, the transmitting PDCP layer device may stop transmitting the complete header and apply a header compression procedure to the data to transmit.

As another method, in the case of the transmitting/receiving PDCP layer device connected to the RLC layer device operating in the RLC AM mode, since there is no data loss, the transmitting PDCP layer device may configure and transmit one complete header. The transmitting PDCP layer device may process data and perform transmission by applying a header compression procedure from immediately next data. That is, the transmitting PDCP layer device may immediately apply the data compression procedure without receiving a feedback (feedback that a complete header has been successfully received) from the receiving PDCP layer device. The above-described receiving PDCP layer device may sort the received data in ascending order of the PDCP serial number or COUNT value. Also, since the data loss does not occur in the RLC AM, the receiving PDCP layer apparatus may first receive and process the complete header, and check the data flow identifier value and the header compression method. Thereafter, the receiving PDCP layer device may perform data processing by applying a header decompression procedure to the data in an ascending order to deliver the data to the upper layer device.

As another method, in the case of a transmitting/receiving PDCP layer device connected to an RLC layer device operating in the RLC UM mode, data loss may occur, so that the transmitting PDCP layer device transmits a plurality of complete headers, and the header starts from the next data. Data can be processed and transmitted by applying a compression procedure. That is, without receiving feedback from the receiving PDCP layer device (feedback that the complete header has been successfully received), the data compression procedure can be applied immediately.

The above-described receiving PDCP layer device may sort the received data in ascending order of the PDCP serial number or COUNT value. In addition, even if data loss occurs in RLC UM, the receiving PDCP layer device assumes that it can receive at least one complete header from among a plurality of complete headers with a high probability, receives and processes the complete header first, and processes the data flow identifier. You can check the value and header compression method. Thereafter, the receiving PDCP layer device may perform data processing by applying a header decompression procedure to the data in ascending order, and transmit the data to the upper layer device.

In addition, for a receiving PDCP layer device connected to an RLC layer device driven by RLC UM or AM, a new timer value may be set as an RRC message. When receiving the complete header, the receiving PDCP layer device may transmit feedback and start a timer. The receiving PDCP layer device may prevent unnecessary feedback generation by performing an operation of not additionally transmitting feedback even if a complete header is received until the timer expires.

In addition, the transmitting PDCP layer device connected to the RLC layer device driven by RLC UM or AM, when the feedback is received for the first time, considers that the receiving PDCP layer device has successfully received the complete header, and performs the header compression procedure afterwards. Can be applied to the field to perform transmission. The transmitting PDCP layer device may ignore additional received feedbacks for a certain period of time (eg, when setting a new timer value with an RRC message and receiving feedback for the first time, starting a new timer, and until the timer expires). have. The above-described feedback structure may be applied to the feedback structures of FIG. 1K proposed in the present disclosure.

As described above, the Ethernet header compression algorithm proposed in the present disclosure may be driven without feedback as described in the present disclosure. That is, the transmitting PDCP layer apparatus may transmit a plurality of data having a complete header including configuration information or context of the Ethernet header compression algorithm without being compressed by the Ethernet header compression algorithm. After transmitting a plurality of pieces of data, the transmitting PDCP layer device may transmit data including the compressed Ethernet header by immediately applying an Ethernet header compression algorithm to the next data. In an embodiment, the complete header may indicate an uncompressed higher layer header or a new EHC header including configuration information of an Ethernet header compression algorithm in a PDCP layer device. And, in one embodiment, when the transmitting PDCP layer device transmits data having a plurality of complete headers, a new EHC header included in the complete header may indicate the same information, and each data includes different upper layer data. can do.

In addition, in one embodiment, when the transmitting PDCP layer device starts to apply the Ethernet header compression method, or when the transmitting PDCP layer device tries to change the Ethernet header compression method, the transmitting PDCP layer device tries to transmit the complete header. The base station may set how many pieces of data including a plurality of data are to be transmitted. For example, the base station may set how many pieces of data including a complete header are transmitted for each bearer using an RRC message (e.g., RRCSetup or RRCResume or RRCReconfiguration message) as in FIG. 1E.

An embodiment of the present disclosure proposes methods for driving an Ethernet header compression algorithm without the above-described feedback when an Ethernet header compression algorithm is configured in a PDCP layer device as follows.

-Method 1: When the Ethernet header compression method starts to be applied in the sending PDCP layer device for each bearer, or when the sending PDCP layer device tries to change the Ethernet header compression method, a complete header transmitted by the sending PDCP layer device is included. The number of pieces of data to be transmitted may be set by the base station as the first number of times. For example, the base station may set each bearer by using an RRC message (for example, RRCSetup or RRCResume or RRCReconfiguration message) as shown in FIG. 1E.

That is, when the sending PDCP layer device tries to apply the Ethernet header compression method, or when the sending PDCP layer device tries to change the Ethernet header compression method, the sending PDCP layer device compresses the Ethernet header to set the Ethernet header compression method. A plurality of data having a complete header including algorithm setting information or context may be transmitted as many as the first number of times set by the RRC message. After transmitting a plurality of times the first number of times, the transmitting PDCP layer apparatus may transmit data including the compressed Ethernet header by immediately applying the Ethernet header compression algorithm to the next data.

In an embodiment, how many pieces of data including the above-described complete header are transmitted may be determined by implementation. In an embodiment, a plurality of QoS flows (or a plurality of different Ethernet header types) may be mapped to one bearer. Therefore, when the Ethernet header compression method starts to be applied in the transmitting PDCP layer device per bearer or QoS flow of one bearer, or when the transmitting PDCP layer device tries to change the Ethernet header compression method, the transmitting PDCP layer device transmits The number of pieces of data including a complete header to be transmitted may be set by the base station as a second number of times.

In one embodiment, when the Ethernet header compression method starts to be applied in the transmitting PDCP layer device for each bearer, or when the transmitting PDCP layer device attempts to change the Ethernet header compression method, a complete header transmitted by the transmitting PDCP layer device is included. The number of pieces of data to be transmitted may be set by the base station as the first number of times. In addition, a plurality of QoS flows (or a plurality of QoS flows each mapped with a plurality of context identifiers (indicating an Ethernet header compression method)) (or a plurality of different Ethernet header types) may be mapped to one bearer. Therefore, each transmitting PDCP layer device may transmit data including each context identifier (or each Ethernet header compression method) or a complete header corresponding to each QoS flow a first number of times. And, after each transmitting PDCP layer device transmits the data including a complete header a first number of times, each transmitting PDCP layer device includes the next data corresponding to each context identifier or each QoS flow (or each Ethernet header type). The Ethernet header can be compressed by applying the Ethernet header compression method corresponding to each context identifier to the fields. Alternatively, each transmitting PDCP layer device may compress the Ethernet header and transmit data to a lower layer for transmission.

In an embodiment, the transmitting PDCP layer device may allocate different context identifiers for different QoS flows (or Ethernet header types), and may set and apply different Ethernet header compression methods. In an embodiment, the above-described Method 1 may be applied to a bearer corresponding to a PDCP layer device connected to an RLC UM or a bearer corresponding to a PDCP layer device connected to an RLC AM.

-Method 2: Method 2 may include applying different methods to a bearer corresponding to a PDCP layer device connected to the RLC UM and a bearer corresponding to a PDCP layer device connected to the RLC AM. In one embodiment, when the Ethernet header compression method starts to be applied in the transmitting PDCP layer device for each bearer, or when the transmitting PDCP layer device attempts to change the Ethernet header compression method, a complete header transmitted by the transmitting PDCP layer device is included. The number of pieces of data to be transmitted may be set by the base station as the first number of times.

For example, the base station may set each bearer by using an RRC message (for example, RRCSetup or RRCResume or RRCReconfiguration message) as shown in FIG. 1E. That is, when the sending PDCP layer device tries to apply the Ethernet header compression method, or when the sending PDCP layer device tries to change the Ethernet header compression method, the sending PDCP layer device compresses the Ethernet header to set the Ethernet header compression method. A plurality of data having a complete header including algorithm setting information or context may be transmitted as many as the first number of times set in the RRC message. After transmitting the first number of times, the transmitting PDCP layer device may transmit data including the compressed Ethernet header by immediately applying the Ethernet header compression algorithm to the next data.

In an embodiment, how many pieces of data including the above-described complete header are transmitted may be determined by implementation. In an embodiment, a plurality of QoS flows may be mapped to one bearer. Therefore, when the Ethernet header compression method starts to be applied in the transmitting PDCP layer device per bearer or QoS flow of one bearer, or when the transmitting PDCP layer device tries to change the Ethernet header compression method, the transmitting PDCP layer device transmits The number of pieces of data including a complete header to be transmitted may be set by the base station as a second number of times.

In one embodiment, when the Ethernet header compression method starts to be applied in the transmitting PDCP layer device for each bearer, or when the transmitting PDCP layer device attempts to change the Ethernet header compression method, a complete header transmitted by the transmitting PDCP layer device is included. The number of pieces of data to be transmitted can be set as the first number of times. And, since a plurality of QoS flows (or a plurality of QoS flows each mapped to a plurality of context identifiers (indicating an Ethernet header compression method) (or a plurality of Ethernet header types)) can be mapped to one bearer, Each transmitting PDCP layer device may transmit data including each context identifier (or each Ethernet header compression method) or a complete header corresponding to each QoS flow a first number of times. And, after each transmitting PDCP layer device transmits the data including a complete header the first number of times, each transmitting PDCP layer device, the next data corresponding to each context identifier or each QoS flow (or each Ethernet header type) The Ethernet header can be compressed by applying the Ethernet header compression method corresponding to each context identifier to the fields. Alternatively, each transmitting PDCP layer device may compress the Ethernet header and transmit data to a lower layer for transmission.

In an embodiment, the transmitting PDCP layer device may allocate different context identifiers for different QoS flows, and set and apply different Ethernet header compression methods. In an embodiment, the above-described Method 2 may be applied as it is to a bearer corresponding to a PDCP layer device connected to the RLC UM. However, when Method 2 is applied to a bearer corresponding to a PDCP layer device connected to an RLC AM, the first number or the second number may always be set to 1. Because there is no data loss in the RLC AM mode, and the receiving PDCP layer device always performs the data sequence alignment and then performs the header decompression procedure, the transmitting PDCP layer device does not need to transmit a plurality of complete headers unnecessarily This is because it is enough to send the complete header of.

Therefore, the transmitting PDCP layer device connected to the RLC AM mode configures and transmits one data including each context identifier (or each Ethernet header compression method) or a complete header corresponding to each QoS flow, and then transmits each context identifier or each QoS flow. It is possible to start compressing the Ethernet header by applying the Ethernet header compression method corresponding to each context identifier to the following data corresponding to the flow. Alternatively, the transmitting PDCP layer device may compress the Ethernet header and transmit data to a lower layer for transmission.

-Method 3: Method 3 may include applying different methods to the bearer corresponding to the PDCP layer device connected to the RLC UM and the bearer corresponding to the PDCP layer device connected to the RLC AM. In one embodiment, the base station transmits only to bearers connected to the RLC UM, when the Ethernet header compression method starts to be applied in the transmitting PDCP layer device, or when the transmitting PDCP layer device tries to change the Ethernet header compression method, transmits How many pieces of data including a complete header transmitted by the PDCP layer apparatus are transmitted, the base station may set as the first number of times.

For example, the base station may configure each bearer only for bearers connected to the RLC UM by using an RRC message (for example, RRCSetup or RRCResume or RRCReconfiguration message) as in FIG. 1E. That is, when the sending PDCP layer device connected to the RLC UM tries to apply the Ethernet header compression method, or when trying to change the Ethernet header compression method, to set the Ethernet header compression method, the setting information or context of the Ethernet header compression algorithm. A plurality of data having a complete header including a may be transmitted as many times as the first number of times set in the RRC message. After transmitting the first number of times, the transmitting PDCP layer device connected to the RLC UM can transmit data including the compressed Ethernet header by immediately applying the Ethernet header compression algorithm to the next data.

In an embodiment, how many pieces of data including the above-described complete header are transmitted may be determined by implementation. In an embodiment, a plurality of QoS flows (or a plurality of Ethernet header types) may be mapped to one bearer. Therefore, when the Ethernet header compression method starts to be applied in the transmitting PDCP layer device by each bearer or by QoS flow of one bearer (or each Ethernet header type) only for bearers connected to the RLC UM, or the transmitting PDCP layer device is In the case of changing the Ethernet header compression method, the number of pieces of data including a complete header transmitted by the transmitting PDCP layer apparatus may be set by the base station as a second number of times.

In one embodiment, when the Ethernet header compression method starts to be applied in the transmitting PDCP layer device for each bearer only to bearers connected to the RLC UM, or when the transmitting PDCP layer device tries to change the Ethernet header compression method, the transmitting PDCP layer The number of pieces of data including a complete header transmitted by the device may be set by the base station as the first number of times. In addition, since a plurality of QoS flows (or a plurality of QoS flows each mapped to a plurality of context identifiers (indicating the Ethernet header compression method) (or each Ethernet header type)) can be mapped to one bearer, each The transmitting PDCP layer device connected to the RLC UM may transmit data including a complete header corresponding to each context identifier (or each Ethernet header compression method) or each QoS flow (or each Ethernet header type) a first number of times. . After the transmitting PDCP layer device connected to each RLC UM transmits the data including the complete header the first number of times, the transmitting PDCP layer device connected to each RLC UM, the following data corresponding to each context identifier or each QoS flow You can start to compress the Ethernet header by applying the Ethernet header compression method corresponding to each context identifier. Alternatively, a transmitting PDCP layer device connected to each RLC UM may compress the Ethernet header and transmit data to a lower layer for transmission.

In an embodiment, the transmitting PDCP layer device may allocate different context identifiers for different QoS flows, and set and apply different Ethernet header compression methods. However, when the Ethernet header compression algorithm is set in Method 3, the PDCP layer device (or bearer) connected to the RLC AM applies each context identifier (or each Ethernet header compression method) or each QoS flow when the Ethernet header compression algorithm is applied. After configuring and transmitting one data including a complete header corresponding to (or each Ethernet header type), each context identifier is added to the following data corresponding to each context identifier or each Q o S flow (or each Ethernet header type) You can start to compress the Ethernet header by applying the Ethernet header compression method corresponding to. Alternatively, a PDCP layer device (or bearer) connected to the RLC AM may compress the Ethernet header and transmit data to a lower layer for transmission. Because there is no data loss in the RLC AM mode, and the receiving PDCP layer device always performs a data order alignment and then performs a header decompression procedure, the transmitting PDCP layer device does not need to unnecessarily transmit a plurality of complete headers This is because sending only one complete header is sufficient.

Accordingly, for the transmitting PDCP layer device or bearers connected to the RLC AM mode, the first number or the second number may not be set as an RRC message as described above.

In addition, in an embodiment of the present disclosure, when the transmitting PDCP layer device applies the Ethernet header compression method, between the transmitting PDCP layer device and the receiving PDCP layer device, each context identifier (or for each QoS flow or each Ethernet header type) ), setting information on the Ethernet header compression method, such as which fields are compressed or can be compressed, needs to be shared and synchronized.

In one embodiment, when the Ethernet header compression method is set for each context identifier, when the transmitting PDCP layer device applies the Ethernet header compression method, setting information about the Ethernet header compression method (for example, a context identifier or a bitmap field, etc.) ) In the above-described complete header, a method of transmitting data together when transmitting data has been proposed.

However, in another embodiment, referring to the RRC message of FIG. 1E, which fields are compressed for each context identifier (or for each QoS flow or for each Ethernet header type) applicable to each bearer or each PDCP layer device, or Setting information on the Ethernet header compression method for whether compression is possible or the like may be preset as an RRC message. According to the configuration information on the Ethernet header compression method, the transmitting PDCP layer device may apply an Ethernet header compression procedure for each context. In addition, when the transmitting PDCP layer device starts to apply the Ethernet header compression method, or attempts to change the Ethernet header compression method, the complete header in the data having a plurality of complete headers transmitted by the transmitting PDCP layer device is a bitmap field. It does not include configuration information on the Ethernet header compression method, and may include a context identifier or an uncompressed Ethernet header. In addition, the above-described Method 1, Method 2, or Method 3 may be applied to how many complete headers are transmitted.

In one embodiment, since configuration information on the Ethernet header compression method for which fields are compressed or compressible for each context identifier (or for each QoS flow or for each Ethernet header type) is preset as an RRC message, The transmitting PDCP layer device may reduce overhead by not including configuration information on the Ethernet header compression method in a complete header.

An embodiment of the present disclosure specifically proposes a procedure for compressing the padding of an Ethernet frame at a transmitting end and recovering at a receiving end.

According to an embodiment, the Ethernet protocol is data smaller than the first predetermined size (e.g., 64 bytes, may be predetermined, and may be set as an RRC message as in FIG. 1E) (e.g., Ethernet frame ) May be designed to be discarded at the receiving end. Therefore, if the size of the Ethernet frame is smaller than the first predetermined size, the transmitter may transmit data according to the first size by adding padding.

Therefore, if the transmitting PDCP layer device receives data from an upper layer device (for example, an Ethernet protocol layer device) and transmits it as it is, in the case of serving small data, the transmission resource is wasted because padding is continuously included in the transmission resource. May result. Data transmission delay may occur due to such waste of transmission resources.

Accordingly, in an embodiment of the present disclosure, when the Ethernet header compression method is set for each bearer, the transmitting PDCP layer device may check the size of data received from the upper layer device. In the transmitting PDCP layer device, the size of the identified data is equal to or smaller than the second size (e.g., 64 bytes, may be determined in advance, and may be set as an RRC message as in FIG. For example, for an Ethernet frame), or for data equal to or larger than the second size, padding may be checked, padding removed, and transmitted.

In addition, in an embodiment, the receiving PDCP layer device in which the Ethernet header compression method is set may check the size of data received from a lower layer device (eg, an RLC layer device). And, the receiving PDCP layer device, the size of the confirmed data is the third size (for example, 64 bytes, may be determined in advance, may be set as an RRC message as in Figure 1e) or smaller data For (for example, an Ethernet frame), by adding padding, a size can be configured according to the first size (or the third size), and then data can be transferred to the upper layer device. Through this, waste of transmission resources can be reduced.

According to an embodiment, one of an Ethernet header compression method or an ROHC header compression method may be configured in the PDCP layer device, and both methods may be configured simultaneously.

In one embodiment, when the size of data received from the upper layer device by the transmitting PDCP layer device for which the Ethernet header compression method is set is the fourth size, the transmitting PDCP layer device applies the Ethernet header compression method to the received data, The size can be reduced to the size of the 5-1. In addition, if the Ethernet header compression method and the ROHC header compression method are also set, the transmitting PDCP layer apparatus applies the ROHC header method to data having a size of 5-1, thereby reducing the size to data having a size of 6-1. You can also reduce it.

In one embodiment, when the size of data received from the upper layer device by the transmitting PDCP layer device on which the ROHC header compression method is set is the fourth size, the transmitting PDCP layer device applies the ROHC header compression method to the received data, The size can be reduced to the size of the 5-2. In addition, in an embodiment, if the Ethernet header compression method and the ROHC header compression method are set, the transmitting PDCP layer apparatus applies the Ethernet header compression method or the ROHC header compression method to data having a size of 5-2, You can also reduce the size to data having a size of -2.

In addition, in an embodiment, the transmitting PDCP layer device in which the Ethernet header compression method is set checks the size of data received from the upper layer device, and thus the second size (for example, it is 64 bytes, may be predetermined, and FIG. Padding can be checked for data that is equal to or smaller than (which may be set as an RRC message, for example, an Ethernet frame), or for data equal to or larger than the second size. After checking the padding, the transmitting PDCP layer device may remove the padding and transmit.

In an embodiment, the transmitting PDCP layer device may determine the presence or absence of padding and perform a padding removal procedure by checking the size of data received from the upper layer device or by checking field information of the Ethernet header. In this case, the padding removal procedure may be performed prior to the Ethernet header compression procedure or the ROHC header compression procedure. This is because, after the Ethernet header compression procedure or the ROHC header compression procedure is performed, the size of the data becomes smaller than the original fourth size, so that it may be difficult to accurately remove the padding. In an embodiment, the transmitting PDCP layer device may receive data from the upper layer device, store the above-described fourth size, and perform the padding removal procedure after the Ethernet header compression procedure or the ROHC header compression procedure. That is, the padding removal procedure may be implemented regardless of the order.

In one embodiment, the receiving PDCP layer device in which the Ethernet header compression method is set checks the size of data received from the lower layer device, and thus the third size (for example, it is 64 bytes, may be predetermined, and in FIG. It is determined that the padding has been removed to prevent waste of transmission resources for data that is equal to or smaller than or equal to (may be set as an RRC message, for example), and fits the third size or the first size. The padding recovery procedure can be performed by adding or configuring padding to the data. In addition, the receiving PDCP layer device may transmit data on which the padding recovery procedure has been performed to the upper layer device. However, as described above, when the receiving PDCP layer device checks the size of data received from the lower layer device, the Ethernet header compression method or the ROHC header compression method may be set. When the Ethernet header compression method or ROHC header compression method is set, the receiving PDCP layer device checks the size of data received from the lower layer device and performs a padding recovery procedure after completing Ethernet header compression decompression or ROHC header decompression. I can.

Because data to which the Ethernet header compression method or the ROHC header compression method is applied has a smaller data size, after the data is restored to the size of the original data, the receiving PDCP layer device transfers the recovered data to the third size. Alternatively, it may be compared with the first size, or the Ethernet header field information may be checked and a padding recovery procedure may be applied. That is, the receiving PDCP layer device applies a decryption procedure or integrity protection procedure or Ethernet header decompression or ROHC header decompression procedure to the received data before checking the size of the data received from the lower layer device, and the size of the original data. After recovering to, it can be compared with the third size or the first size.

The receiving PDCP layer device has data equal to or smaller than the third size (e.g., 64 bytes, may be predetermined, and may be set as an RRC message as in FIG. 1E) (e.g., Ethernet frame) For, when padding removal (or compression) is confirmed by checking the Ethernet header (or PDCP header indicator or EHC header indicator) field information, it may be determined that the padding has been removed to prevent waste of transmission resources. After determining that the padding has been removed, the receiving PDCP layer device may perform the padding recovery procedure by adding or configuring the padding to the data according to the third size or the first size, and the data on which the padding recovery procedure is performed Can be delivered to a layered device.

That is, in one embodiment, the padding recovery (or decompression) procedure for an Ethernet frame of a receiving PDCP layer device in which an Ethernet header compression method or an ROHC header compression method is set is performed by the receiving PDCP layer device decompressing the Ethernet header or compressing the ROHC header. After completing the release procedure, it can be performed by checking the size of data or header field information.

In addition, in an embodiment, when the Ethernet header compression method and the ROHC header compression method are simultaneously set, the receiving PDCP layer device may perform a decoding or integrity verification procedure on data received from the lower layer device. After performing the decryption or integrity verification procedure, the receiving PDCP layer device may check the size of the compressed Ethernet header by first applying the Ethernet header decompression method. After checking the size of the compressed Ethernet header, the receiving PDCP layer device may check the header compressed with ROHC and apply the ROHC header decompression procedure to the header compressed with ROHC.

In an embodiment, decompression of the Ethernet header or decompression of the ROHC header may be performed independently. That is, the Ethernet header decompression or ROHC header decompression procedure may be performed regardless of the order. However, the receiving PDCP layer device first checks the size of the compressed Ethernet header after the PDCP header, checks the size of the header compressed with ROHC, and then independently performs Ethernet header decompression or ROHC header decompression. May be.

In an embodiment, for convenience of implementation, an indicator indicating whether Ethernet header compression or ROHC header compression has been performed may be defined in the PDCP header or EHC header, and the transmitting PDCP layer device may deliver the above-described indicator. . The receiving PDCP layer device, which has received the indicator from the transmitting PDCP layer device, may check the indicator and apply Ethernet header decompression or ROHC header decompression.

The above-described methods may be necessary because the receiving PDCP layer apparatus does not know where the location of the compressed ROHC header is located in the received data when both the Ethernet header compression and ROHC header compression methods are set.

In addition, in FIG. 1E of the present disclosure, a transmitting PDCP layer device may transmit a complete header for each bearer or for each PDCP layer device using an RRC message. After transmitting the complete header, the transmitting PDCP layer device may receive a feedback indicating that the complete header has been successfully received from the receiving PDCP layer device. After receiving the above-described feedback from the receiving PDCP layer device, the transmitting PDCP layer device indicates whether to start the Ethernet header compression procedure or immediately after transmitting a plurality of data having a complete header, as an indicator. You can set it up.

For example, the RRC message (e.g., RRCSetup, RRCResume, RRCRecofiguration message), when the Ethernet header compression method is configured for each bearer or for each PDCP layer device configuration information, may indicate whether to use feedback. In addition, in the RRC message, when transmission of a plurality of data having a complete header is set, a number of times corresponding thereto may be set. In addition, the RRC message may set different Ethernet header compression configuration information (for example, whether feedback or whether or not to transmit a plurality of complete headers, or the number of transmissions) to the PDCP layer device in which RLC UM or RLC AM is configured.

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

The receiving PDCP layer device uses the length of the PDCP serial number (for example, 12 bits or 18 bits) set by the base station as RRC, and checks the PDCP serial number of the received data (for example, PDCP PDU), and the reception window Drive. 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 may be determined as invalid data and discarded. The reason that data arrives outside the reception window is that data arrives very late due to retransmission of the RLC layer device or HARQ retransmission of the MAC layer device in the lower layer device. Also, the receiving PDCP layer device drives a PDCP reordering timer (t-Reordering) together with the receiving window.

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 is stored until the PDCP reorder timer expires. If it does not arrive, data can be transferred to the upper layer device in ascending order of the PDCP serial number or COUNT value, and the receiving window can be moved. Therefore, if data corresponding to the PDCP serial number gap arrives after the PDCP reorder timer expires, it may be discarded because it is not data in the reception window.

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

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

The receiving PDCP layer device maintains and manages three COUNT variables when processing received data. When the receiving PDCP layer device processes the received data, it uses a second COUNT variable that maintains the COUNT value of the data expected to be received next (for example, PDCP SDU), and the second COUNT variable is referred to as RX_NEXT. Can be. In addition, when the receiving PDCP layer device processes the received data, it uses a third COUNT variable that maintains the COUNT value of the first data (for example, PDCP SDU) that has not been delivered to the upper layer, and the third COUNT variable is It may be referred to as RX_DELIV.

And, when processing the received data, the receiving PDCP layer device uses a fourth COUNT variable that maintains the COUNT value of the data (for example, PDCP SDU) that triggered the PDCP reordering timer (t-Reordering). 4 The COUNT variable may be referred to as RX_REORD. In addition, when the receiving PDCP layer device processes the received data, it uses a fifth COUNT variable that maintains the COUNT value of the currently received data (for example, PDCP SDU), and the fifth COUNT variable may be referred to as RCVD_COUNT. have. The PDCP rearrangement timer uses a timer value or interval set in an RRC message as shown in FIG. 1E in an upper layer (RRC layer), and the timer is used to detect a lost PDCP PDU, and only one timer is driven at a time.

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: indicates the sequence number (SN) 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 disclosure is as follows. When receiving a PDCP PDU from a lower layer, the receiving PDCP layer apparatus determines a COUNT value of the received PDCP PDU as follows.

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

■ Update 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 in the above case

■RCVD_HFN = Update to 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 decrypted 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)

■ Discard the received PDCP Data PDU (the data part of the PDCP PDU).

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

-The processed PDCP SDU 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),

■ Deliver PDCP SDUs to higher layers.

-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 (that is, if 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 has been set 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, the feedback is triggered to instruct the sending PDC layer device, and the feedback is configured and transmitted to the sending PDCP layer device.

◆ If not, 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.

■ 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.

■ Update the RX_DELIV value to the COUNT value of the first PDCP SDU that is greater than or equal to the current RX_DELIV and has not been delivered 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-described conditions) 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 set 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 no decompression is performed.

◆ Since the uncompressed Ethernet header has been successfully received, it triggers a feedback to instruct the sending PDC layer device, constructs the feedback, and sends it to the sending PDCP layer device.

■ If not, if 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.

-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.

-Updates the RX_DELIV value to 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,

■ Update RX_REORD value to RX_NEXT value.

■ Start the t-Reordering timer.

According to an embodiment of the present disclosure, when a PDCP re-establishment procedure is triggered, a procedure of a transmitting PDCP layer device for each bearer for an Ethernet header protocol is proposed as follows.

-If it is not instructed to continue using the Ethernet header compression protocol, the Ethernet header compression protocol is initialized for UM Data Radio Bearer (DRB) or AM DRBs.

-AM DRBs perform a new Ethernet header compression procedure for data to be transmitted and retransmitted, and newly compress the Ethernet header and perform a new ROHC header compression to process data and perform transmission and retransmission.

-UM DRBs perform a new Ethernet header compression procedure for data that have not yet been transmitted, and perform a new compression of the Ethernet header and a new ROHC header compression to process and transmit the data.

1L is a diagram illustrating an operation of a transmitting PDCP layer device or a receiving PDCP layer device of a terminal or a base station according to an embodiment of the present disclosure.

Referring to FIG. 1L, when an upper layer header compression protocol (Ethernet header compression method, EthHC) is set for a transmitting PDCP layer device in an embodiment of the present disclosure, data (1l-05) received from an upper layer is If the Ethernet header compression method is set and the first data is received, or 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 (Or different from previously transmitted Ethernet header field values), or feedback from the receiving PDCP layer device that has been successfully received for data with a previously transmitted uncompressed complete upper layer header (Ethernet header). If not (1l-10), the sending PDCP layer device does not perform Ethernet header compression until a feedback indicating that it has been successfully received for the uncompressed complete upper layer header (Ethernet header) from the receiving PDCP layer device (1l-10). -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 (1l-10), the transmitting PDCP layer device receives from the upper layer. Compression is performed by applying the Ethernet header compression method to one data (1l-15).

In an embodiment of the present disclosure, if the Ethernet header compression protocol is set for the receiving PDCP layer device, and the receiving PDCP layer device has received data from the lower layer (1l-25), the Ethernet header is compressed (the new EHC header If the indicator is checked and indicates that the Ethernet header is compressed) (1l-35), the receiving PDCP layer device performs decompression on the Ethernet header of the data (1l-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 not compressed) (1l-35), the receiving PDCP layer device is The header is regarded as an uncompressed header, and decompression may not be performed. In addition, since the uncompressed Ethernet header has been successfully received, the receiving PDCP layer device triggers a feedback to instruct the transmitting PDCP layer device, and configures the feedback and transmits the feedback to the transmitting PDCP layer device (1l-45).

1M illustrates a structure of a terminal according to an embodiment of the present disclosure.

Referring to FIG. 1M, 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 functions for transmitting and receiving signals through a wireless channel such as band conversion and amplification of signals. 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 the antenna, and transmits the RF band signal received through the antenna to the baseband signal. Down-convert to 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. have. In FIG. 1M, 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 beamforming, the RF processing unit 1m-10 may adjust a phase and a magnitude of each 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 the control of the controller, or may adjust the direction and beam width of the reception beam so that the reception beam cooperates with the transmission beam. .

The baseband processing unit 1m-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 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 the 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 mapping the complex symbols to subcarriers After that, OFDM symbols are configured 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 is mapped to subcarriers through a fast Fourier transform (FFT) operation. After restoring the 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, different radio access technologies may include an LTE network, an NR network, and the like. In addition, 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 basic programs, application programs, 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 controller 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 controller 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 illustrates a block configuration of a Transmission Reception Point (TRP) in a wireless communication system according to an embodiment of the present disclosure.

Referring to FIG. 1N, in an embodiment of the present disclosure, TRP may mean a base station. 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).

The RF processing unit 1n-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 1n-10 up-converts the baseband signal provided from the baseband processing unit 1n-20 to an RF band signal, and then transmits it through an antenna, and transmits the RF band signal received through the antenna to the baseband signal. Down-convert to 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 beamforming, the RF processing unit 1n-10 may adjust the phase and 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 string 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 the 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 performing an IFFT operation and OFDM symbols are configured through 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 restores the signals mapped to the subcarriers through FFT operation. , Demodulation and decoding to restore the received bit stream. 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 and measurement results reported from the connected terminal. 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 the 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 signals 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.

The methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. One or more programs stored in a computer-readable storage medium are configured to be executable by one or more processors in an electronic device (device). The one or more programs include instructions that cause the electronic device to execute methods according to embodiments described in the claims or specification of the present disclosure.

These programs (software modules, software) include random access memory, non-volatile memory including flash memory, read only memory (ROM), and electrically erasable programmable ROM. (EEPROM: Electrically Erasable Programmable Read Only Memory), magnetic disc storage device, Compact Disc-ROM (CD-ROM), Digital Versatile Discs (DVDs), or other types of It may be stored in an optical storage device or a magnetic cassette. Alternatively, it may be stored in a memory composed of a combination of some or all of them. In addition, a plurality of configuration memories may be included.

In addition, the program is accessed through a communication network such as the Internet, Intranet, LAN (Local Area Network), WLAN (Wide LAN), or SAN (Storage Area Network), or a communication network composed of a combination thereof. It may be stored in an (access) attachable storage device. Such a storage device may be connected to a device performing an embodiment of the present disclosure through an external port. In addition, a separate storage device on the communication network may access a device performing an embodiment of the present disclosure.

In the specific embodiments of the present disclosure described above, the constituent elements included in the invention are expressed in the singular or plural according to the specific embodiments presented. However, the singular or plural expression is selected appropriately for the situation presented for convenience of explanation, and the present disclosure is not limited to the singular or plural constituent elements, and even constituent elements expressed in plural are composed of the singular or in the singular. Even the expressed constituent elements may be composed of pluralities.

On the other hand, the embodiments of the present disclosure disclosed in the present specification and drawings are merely provided with specific examples to easily describe the technical content of the present disclosure and to aid understanding of the present disclosure, and are not intended to limit the scope of the present disclosure. That is, that other modified examples based on the technical idea of the present disclosure may be implemented is obvious to those of ordinary skill in the technical field to which the present disclosure belongs. In addition, each of the above-described embodiments may be combined and operated as necessary. For example, portions of an embodiment of the present disclosure and another embodiment may be combined with each other to operate a base station and a terminal. In addition, although the above embodiments have been presented based on the FDD LTE system, other systems such as a TDD LTE system, a 5G or NR system may also be implemented with other modifications based on the technical idea of the embodiment.

Claims (1)

In the method of operating a transmitting end in a wireless communication system,
Receiving data from an upper layer;
Identifying a preset condition based on the received data;
Determining whether to compress the header of the upper layer based on the identified condition; And
And transmitting data according to the determined compression status.

Images