Method and apparatus for reducing ethernet frame overhead in next generation mobile communication system

Abstract

The disclosure relates to a communication method and system for converging a 5th-Generation (5G) communication system for supporting higher data rates beyond a 4th-Generation (4G) system with a technology for Internet of Things (IoT). The disclosure can be applied to smart services, such as smart home, smart building, smart city, smart car, connected car, health care, digital education, smart retail, security and safety services, based on 5G communication technology and IoT-related technology. The disclosure discloses a method and apparatus for reducing overhead of an Ethernet frame, a method and apparatus for efficiently performing a connection resume procedure of a terminal, and a method and apparatus for preventing data loss when performing an uplink user data compression procedure.

Description

Methods and apparatus for reducing Ethernet frame overhead in next-generation mobile communication systems

[0001] This application is a divisional application of patent application filed on October 30, 2019, with application number 201980072460.6 and invention title "Method and apparatus for reducing Ethernet frame overhead in next-generation mobile communication systems". Technical Field

[0002] This disclosure relates to next-generation wireless communication. Specifically, this disclosure relates to a method and apparatus for reducing the overhead of Ethernet frames supporting high reliability and low latency terminals in next-generation communication systems. Furthermore, this disclosure relates to a method and apparatus for efficiently performing a connection restoration process for a terminal in a wireless communication system. Additionally, this disclosure relates to a method and apparatus for preventing data loss during uplink user data compression processes in a wireless communication network. Background Technology

[0003] To meet the growing demand for wireless data services since the development of 4G communication systems, efforts have been made to develop enhanced 5G or pre-5G communication systems. Therefore, 5G or pre-5G communication systems are also referred to as "super 4G networks" or "post-LTE systems." The implementation of 5G communication systems in higher frequency (millimeter wave, mmWave) bands (e.g., the 60GHz band) is being considered to achieve higher data rates. To reduce radio wave propagation loss and increase transmission distance, beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive MIMO technologies are discussed in 5G communication systems. Furthermore, in 5G communication systems, development is underway to improve system networks based on: advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, coordinated multipoint (CoMP), and receiver interference cancellation. In 5G systems, the following technologies have been developed: hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) as advanced coding and modulation (ACM); and filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access technologies.

[0004] The Internet, as a human-centric connectivity network where humans generate and consume information, is evolving into the Internet of Things (IoT), in which distributed entities, such as things, exchange and process information without human intervention. The Internet of Everything (IoE) has emerged, combining IoT technologies with big data processing technologies via connections to cloud servers. Because IoT implementations require technological elements such as sensing technology, wired / wireless communication and network infrastructure, service interface technology, and security technology, sensor networks, machine-to-machine (M2M) communication, and machine-type communication (MTC) have recently been studied. Such an IoT environment can provide intelligent Internet technology services that create new value for human life by collecting and analyzing data generated from connected things. Through the integration and combination of existing information technology (IT) with various industrial applications, IoT can be applied to a wide range of fields, including smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, healthcare, smart appliances, and advanced medical services.

[0005] Correspondingly, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, machine-type communication (MTC), and machine-to-machine (M2M) communication can be implemented using beamforming, MIMO, and array antennas. The application of cloud radio access networks (RAN) as a big data processing technology can also be considered an example of the convergence between 5G and IoT technologies.

[0006] In next-generation communication systems, there is a growing need for various improvements to the Ethernet protocol. Summary of the Invention

[0007] Technical issues

[0008] In 5G wireless communication systems, there is a need to develop Ethernet protocols. Additionally, there is a need to develop Radio Resource Control (RRC) connection recovery procedures in 5G wireless communication systems.

[0009] Solution

[0010] The aspects of this disclosure will address at least the aforementioned problems and / or disadvantages, and provide at least the following advantages. Therefore, the aspects of this disclosure will provide a communication method and system for integrating fifth-generation (5G) communication systems to support higher data rates than fourth-generation (4G).

[0011] According to an aspect of this disclosure, a method for providing a terminal is provided. The method includes: receiving from a base station a control message for restoring a Radio Resource Control (RRC) connection, the control message including information requesting the re-establishment of a Packet Data Convergence Protocol (PDCP) entity; based on the information, identifying whether at least one PDCP Service Data Unit (SDU) associated with a PDCP Sequence Number (SN) is stored; when the at least one PDCP SDU is stored, identifying a first PDCP SDU from the at least one PDCP SDU, wherein successful delivery of a corresponding PDCP Protocol Data Unit (PDU) from a lower layer has not yet been confirmed for the first PDCP SDU; associating a count value with the at least one PDCP SDU, starting from the first PDCP SDU; and transmitting the at least one PDCP SDU to the base station.

[0012] According to another aspect of this disclosure, a method for a base station is provided. The method includes: sending a control message to a terminal for resuming a Radio Resource Control (RRC) connection, the control message including information requesting the re-establishment of a Packet Data Convergence Protocol (PDCP) entity; and receiving from the terminal at least one PDCP Service Data Unit (SDU), wherein whether at least one PDCP SDU associated with a PDCP Sequence Number (SN) is stored is identified by the terminal based on the information, wherein when the at least one PDCP SDU is stored, a first PDCP SDU from the at least one PDCP SDU is identified, for which successful delivery of a corresponding PDCP Protocol Data Unit (PDU) from a lower layer has not yet been confirmed, and wherein a count value is associated with the at least one PDCP SDU, starting from the first PDCP SDU.

[0013] According to another aspect of this disclosure, a terminal is provided. The terminal includes: a transceiver configured to transmit and receive signals; and a controller configured to: receive from a base station a control message for restoring a Radio Resource Control (RRC) connection, the control message including information requesting the re-establishment of a Packet Data Convergence Protocol (PDCP) entity; based on the information, identify whether at least one PDCP Service Data Unit (SDU) associated with a PDCP Sequence Number (SN) is stored; when the at least one PDCP SDU is stored, identify a first PDCP SDU from the at least one PDCP SDU, wherein successful delivery of a corresponding PDCP Protocol Data Unit (PDU) from a lower layer has not yet been confirmed for the first PDCP SDU; associate a count value with the at least one PDCP SDU starting from the first PDCP SDU; and transmit the at least one PDCP SDU to the base station.

[0014] According to another aspect of this disclosure, a base station is provided. The base station includes: a transceiver configured to transmit and receive signals; and a controller configured to: transmit a control message to a terminal for restoring a Radio Resource Control (RRC) connection, the control message including information requesting the re-establishment of a Packet Data Convergence Protocol (PDCP) entity; and receive at least one PDCP Service Data Unit (SDU) from the terminal, wherein whether at least one PDCP SDU associated with a PDCP Sequence Number (SN) is stored is identified by the terminal based on the information, wherein when the at least one PDCP SDU is stored, a first PDCP SDU from the at least one PDCP SDU is identified, for which successful delivery of a corresponding PDCP Protocol Data Unit (PDU) from a lower layer has not yet been confirmed, and wherein a count value is associated with the at least one PDCP SDU, starting from the first PDCP SDU.

[0015] Advantages of the present invention

[0016] In next-generation mobile communication systems, there is a need to efficiently utilize transmission resources to support services with low latency and high reliability (e.g., Ultra-Reliable Low-Latency Communication (URLLC) or Industrial IoT (IIoT) services). Furthermore, next-generation mobile communication systems also involve events that suspend the bearer or protocol layer devices of the terminal (e.g., Service Data Adaptation Protocol (SDAP) layer devices, Packet Data Convergence Protocol (PDCP) layer devices, Radio Link Control (RLC) layer devices, Media Access Control (MAC) layer devices, or Physical (PHY) layer devices).

[0017] Specifically, if a terminal changes its mode to Radio Resource Control (RRC) inactive mode in response to a command from the network, the terminal needs to effectively handle the bearer or protocol layer devices appropriately in response to the command from the network. However, depending on whether the terminal supports general services or uses narrowband and supports limited services, the terminal needs to handle the bearer or protocol layer devices differently. Therefore, the network needs to instruct different terminals (narrowband (NB)-IoT terminals or general terminals) to change their mode to RRC suspended mode, RRC inactive mode, or RRC idle mode through different indicators, and indicate the corresponding protocol handling procedures.

[0018] Furthermore, in wireless communication systems, the downlink utilizes high-frequency bands and wide bandwidth, thus ensuring more transmission resources. Additionally, because more antennas can be physically installed in the base station, it can achieve beamforming gain and high signal strength. Therefore, the base station can transmit more data to the terminal via the downlink by carrying more data on the same frequency / time resources. However, in the uplink case, due to the small physical size of the terminal and the difficulty in utilizing high-frequency bands and wide bandwidths for uplink frequencies, uplink transmission resources may experience bottlenecks compared to downlink transmission resources. Moreover, since the maximum transmission power of the terminal is much lower than the maximum transmission power of the base station, there is a problem of reduced coverage during uplink data transmission. Therefore, uplink data compression is necessary to effectively utilize transmission resources.

[0019] The method for compressing uplink data is based on performing data compression sequentially from previous data. Therefore, if one of the compressed data in a series is lost or discarded, or if data decompression fails midway, then data decompression is performed on all data following the lost or discarded data or the data that failed to decompress.

[0020] The transmit-level PDCP layer device can drive a PDCP drop timer for each piece of data whenever it receives data from a higher-layer device; it can execute an uplink compression process if one has been configured; it can configure a User Data Compression (UDC) header; it can encrypt data that has undergone uplink data compression (excluding the UDC header); it can assign PDCP sequence numbers; and it can generate PDCP PDUs by configuring the PDCP header. In the above description, when the PDCP drop timer expires, the PDCP layer device discards the data corresponding to that timer by considering it no longer valid.

[0021] Therefore, if the sending PDCP layer device discards previously generated data (e.g., PDCP Protocol Data Units (PDUs)) due to the expiration of the PDCP discard timer, any data in the series of compressed data will be discarded. As a result, due to the mid-journey discarding or loss of compressed data, consecutive uplink data decompression failures may occur in the receiving PDCP layer device. Attached Figure Description

[0022] To gain a more complete understanding of this disclosure and its advantages, the following description, taken in conjunction with the accompanying drawings, in which the same reference numerals denote the same parts:

[0023] Figure 1A shows a diagram illustrating the configuration of an LTE system in relation to embodiments of this disclosure;

[0024] Figure 1B shows a diagram of the radio protocol structure in an LTE system in relation to embodiments of the present disclosure;

[0025] Figure 1C shows a diagram of the configuration of a next-generation mobile communication system in relation to embodiments of the present disclosure;

[0026] Figure 1D shows a diagram of the radio protocol structure of a next-generation mobile communication system in relation to embodiments of this disclosure;

[0027] Figure 1E illustrates the process by which a base station configures configuration information related to the Ethernet header protocol in a terminal when the terminal establishes a connection with the network, in accordance with embodiments of the present disclosure.

[0028] Figure 1F illustrates a method for Ethernet header compression (EthHC) according to an embodiment of the present disclosure;

[0029] Figure 1G shows a diagram of a detailed embodiment of the EthHC method according to an embodiment of the present disclosure;

[0030] Figure 1H illustrates a method, relating to embodiments of the present disclosure, for supporting low transmission latency and high reliability in a next-generation mobile communication system by using the Ethernet protocol to efficiently utilize radio transmission resources in a wireless environment, thereby enabling both the transmitting and receiving stages to perform their functions.

[0031] Figure 1I illustrates the operation of a transmission and reception SDAP layer device or PDCP layer device according to an embodiment of the present disclosure;

[0032] Figure 1J illustrates the configuration of a terminal in relation to an embodiment of this disclosure;

[0033] Figure 1K shows a block diagram of a transmit receiver point (TRP) in a wireless communication system in relation to embodiments of the present disclosure;

[0034] Figure 2A illustrates a pattern in which a terminal can remain in a next-generation mobile communication system in relation to embodiments of this disclosure;

[0035] Figure 2B illustrates the process of a terminal switching from RRC connection mode to RRC idle mode and the process of a terminal switching from RRC idle mode to RRC connection mode in relation to embodiments of this disclosure.

[0036] Figure 2C illustrates a terminal mode switching indication method for a network according to an embodiment of the present disclosure;

[0037] Figure 2D illustrates a diagram of terminal operation in relation to embodiments of this disclosure;

[0038] Figure 2E illustrates the configuration of a terminal in relation to embodiments of this disclosure;

[0039] Figure 2F shows a block diagram of a TRP in a wireless communication system in relation to embodiments of the present disclosure;

[0040] Figure 3A illustrates the process of whether the base station configuration performs uplink data compression when a terminal establishes a connection with the network, in relation to embodiments of this disclosure.

[0041] Figure 3B illustrates a process for performing uplink data compression and data configuration in relation to embodiments of this disclosure;

[0042] Figure 3C illustrates an embodiment of the uplink data compression method in relation to embodiments of the present disclosure;

[0043] Figure 3D illustrates a problem of decompression failure occurring in an uplink data compression method, in relation to embodiments of this disclosure.

[0044] Figure 3E illustrates a PDCP control PDU format that can be applied in a checksum failure handling method in relation to embodiments of this disclosure;

[0045] Figure 3F illustrates terminal operation according to an embodiment of the present disclosure in the following situation: if the transmit-level PDCP layer device drives the PDCP discard timer, data has not been transmitted due to the PDCP discard timer expiring, and data that has already undergone the User Data Compression (UDC) process is discarded;

[0046] Figure 3G illustrates the configuration of a terminal in relation to embodiments of this disclosure;

[0047] Figure 3H shows a block diagram of a TRP in a wireless communication system in relation to embodiments of the present disclosure;

[0048] Figure 3I illustrates the following embodiment: wherein, according to an embodiment of the present disclosure, if a configuration or SDAP header has been configured via an RRC message, the SDAP layer apparatus effectively performs the user data compression method;

[0049] Figure 3J illustrates another embodiment of the following: wherein, according to an embodiment of the present disclosure, if a configuration or SDAP header has been configured via an RRC message, the SDAP layer apparatus effectively performs the user data compression method;

[0050] Figure 3K illustrates another embodiment of the present disclosure, in which, according to an embodiment of the present disclosure, if a configuration or SDAP header has been configured via an RRC message, the SDAP layer apparatus effectively performs the user data compression method.

[0051] Figure 3L illustrates another embodiment of the present disclosure, in which, according to an embodiment of the present disclosure, if a configuration or SDAP header has been configured via an RRC message, the SDAP layer apparatus effectively performs the user data compression method.

[0052] Figure 3M illustrates another embodiment of the following: in which, according to an embodiment of the present disclosure, if a configuration or SDAP header has been configured via an RRC message, the SDAP layer apparatus effectively performs the user data compression method;

[0053] Figure 3N illustrates another embodiment of the present disclosure, in which, according to an embodiment of the present disclosure, if a configuration or SDAP header has been configured via an RRC message, the SDAP layer apparatus effectively performs the user data compression method.

[0054] Figure 30 illustrates a diagram of terminal operation as presented in an embodiment of this disclosure; and

[0055] Figure 3P illustrates a diagram of the following embodiment: wherein, in an embodiment of this disclosure, integrity protection is configured in the data bearer. Detailed Implementation

[0056] Before proceeding with the following detailed description, it may be advantageous to clarify the definitions of certain words and phrases used throughout this patent document: the terms “comprising” and “including” and their derivatives mean including but not limited to; the term “or” is inclusive, meaning and / or; the phrases “associated with” and “related to” and their derivatives may mean including, being included in, interconnected with, containing, contained within, connected to or connected to, coupled to or coupled to, communicable with, cooperating with, intertwined, juxtaposed, adjacent, bound to or bound to, having, having the properties of, etc.; and the term “controller” means any device, system, or part thereof that controls at least one operation, such a device may be implemented in hardware, firmware, or software, or some combination of at least two of them. It should be noted that the functionality associated with any particular controller can be centralized or distributed, and whether local or remote.

[0057] Furthermore, the various functions described below can be implemented or supported by one or more computer programs, each computer program being formed by computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, associated data, or portions thereof adapted to be implemented with suitable computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium accessible by a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drive, compact disc (CD), digital video disc (DVD), or any other type of storage. "Non-transitory" computer-readable medium excludes wired, wireless, optical, or other communication links that transmit transient electrical or other signals. Non-transitory computer-readable medium includes media in which data can be permanently stored and media in which data can be stored and subsequently overwritten, such as rewritable optical discs or erasable memory devices.

[0058] Throughout this patent document, definitions of certain words and phrases are provided, and those skilled in the art will understand that, in many cases (if not most), such definitions also apply to the prior and future use of such defined words and phrases.

[0059] The figures 1A through 3P discussed below, along with the various embodiments used to illustrate the principles of this disclosure in this patent document, are merely illustrative and should not be construed in any way as limiting the scope of this disclosure. Those skilled in the art will understand that the principles of this disclosure can be implemented in any suitably arranged system or device.

[0060] In the following, various embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. It should be noted that the same reference numerals are used throughout the drawings to refer to the same elements. Furthermore, detailed descriptions of known functions or constructions that might obscure the main points of the present disclosure have been omitted.

[0061] In this specification, descriptions of well-known elements in the art and not directly related to this disclosure have been omitted to make the main points of the disclosure clearer when describing embodiments. For the same reason, some elements are enlarged, omitted, or depicted schematically in the drawings. Furthermore, the size of each element does not accurately reflect its actual size. Identical or similar elements are assigned the same reference numerals in the drawings.

[0062] The advantages and features of this disclosure, as well as the methods for achieving these advantages and features, will become clearer from the embodiments described in detail with reference to the accompanying drawings. However, this disclosure is not limited to the disclosed embodiments, but can be implemented in a variety of different ways. The embodiments are provided only to complete the disclosure and to allow those skilled in the art to understand the category of this disclosure. This disclosure is defined by the category of the claims. Throughout the drawings, the same reference numerals will be used to refer to the same or similar elements.

[0063] In this disclosure, it will be understood that each block of the flowchart illustration, and combinations of blocks in the flowchart illustration, can be executed by computer program instructions. These computer program instructions can be mounted on a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus, such that the instructions, which are executed by the processor of the computer or other programmable data processing apparatus, create means for performing the functions specified in the flowchart blocks. These computer program instructions can also be stored in a computer-usable or computer-readable memory, which can instruct the computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-usable or computer-readable memory produce an article of writing including instruction means that implement the functions specified in the flowchart blocks. The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-executed process, such that the instructions executing the computer or other programmable apparatus provide steps for performing the functions described in the flowchart blocks.

[0064] Furthermore, each box in the flowchart diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the boxes may occur out of order. For example, depending on the functionality involved, two boxes shown consecutively may actually be executed substantially concurrently, or sometimes they may be executed in reverse order.

[0065] In this context, the term "unit," as used in this embodiment, means a software or hardware component, such as an FPGA or ASIC, and the "unit" performs a specific task. A "unit" can advantageously be configured to reside on an addressable storage medium and to operate on one or more processors. Therefore, a "unit" can include, for example, components (such as software components, object-oriented software components, class components, and task components), processes, functions, attributes, procedures, subroutines, code snippets, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functionality provided in components and "units" can be combined into fewer components and "units," or can be further separated into additional components and "units." Furthermore, components and "units" can be implemented to operate on one or more CPUs within a device or security multimedia card.

[0066] In the following description, for ease of description, terms for identifying access nodes, terms for representing network entities, terms for representing messages, terms for representing interfaces between network entities, and terms for representing various types of identity information have been described. Therefore, this disclosure is not limited to the following terms, and other terms that represent objects with equivalent technical meanings may be used.

[0067] In the following text, the base station is the entity that performs resource allocation to the terminal, and can be at least one of a g node B (gNB), an e node B (eNB), 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, but is not limited to, user equipment (UE), a mobile station (MS), a cellular phone, a smartphone, a computer, or a multimedia system capable of performing communication functions.

[0068] In this disclosure, the transmitting stage is an apparatus for transmitting data and may include a base station, a terminal, a network entity, and a PDCP layer transmitting apparatus. Furthermore, in this disclosure, the receiving stage is an apparatus for receiving data and may include a base station, a terminal, a network entity, and a PDCP layer receiving apparatus.

[0069] In the following description, for ease of description, the terms and names defined in the 3GPP LTE standard, or modified from those defined, are used in the embodiments of this disclosure. However, this disclosure is not limited to these terms and names and can be applied equivalently to systems based on other standards. In one embodiment of this disclosure, for ease of description, eNB and gNB can be used interchangeably. That is, a base station described as eNB can refer to a gNB.

[0070] <First Embodiment>

[0071] Figure 1A shows a diagram of the configuration of an LTE system in relation to embodiments of the present disclosure.

[0072] Referring to Figure 1A, the radio access network of the LTE system includes: Next Generation Evolved Node Bs (hereinafter referred to as "ENB", "Node B", or "base station") 1a-05, 1a-10, 1a-15, and 1a-20; Mobility Management Entity (MME) 1a-25; and Service Gateway (S-GW) 1a-30. User Equipment (hereinafter referred to as "UE" or "terminal") 1a-35 communicates with the ENB. It connects to the external network via S-GW 1a-30.

[0073] In Figure 1A, ENB Corresponding to Node B in the existing UMTS system, the ENB connects to the UE 1a-35 via a radio channel and performs more complex functions than the existing Node B. In LTE systems, all types of user traffic, including real-time services such as Voice over IP (VoIP) via a shared channel, are served. Therefore, a device is needed to perform scheduling by collecting state information such as the UE's channel state, available transmission power state, and buffer state. This is the responsibility of the equipment. Typically, one ENB controls multiple cells. For example, to achieve a transmission rate of 100 Mbps, the LTE system uses Orthogonal Frequency Division Multiplexing (hereinafter referred to as "OFDM") as the radio access technology in a 20 MHz bandwidth. Furthermore, the LTE system employs an Adaptive Modulation and Coding (hereinafter referred to as "AMC") scheme to determine the modulation scheme and channel coding rate based on the UE's channel state. The S-GW 1a-30 provides the data bearer and generates or removes the data bearer under the control of the MME 1a-25. Besides mobility management functions for the UE, the MME is responsible for various control functions and connects to multiple ENBs.

[0074] Figure 1B shows a diagram of the radio protocol structure in an LTE system in relation to embodiments of the present disclosure.

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

[0076] - Header compression and decompression functions (Header compression and decompression: ROHC only)

[0077] - User data transmission function (transmission of user data)

[0078] - Sequential delivery function (sequential delivery of upper-layer PDUs during the PDCP re-establishment process for RLC AM)

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

[0080] - Duplicate detection function (duplicate detection of low-level SDUs during the PDCP re-establishment process for RLC AM)

[0081] - Retransmission function (for RLC AM, PDCP SDU retransmission during handover and PDCP PDU retransmission during PDCP data recovery for offloaded bearers in DC)

[0082] - Encryption and decryption functions (encryption and decryption)

[0083] - Timer-based SDU dropping function (timer-based SDU dropping in the uplink).

[0084] RLC 1b-10 and 1b-35 reconfigure PDCP packet data units (PDUs) to the appropriate size and perform ARQ operations. The main functions of the RLC are summarized below.

[0085] - Data transmission function (transmission of upper-layer PDUs)

[0086] -ARQ function (error correction via ARQ (AM data transmission only))

[0087] - Concatenation, segmentation, and reassembly functions (concatenation, segmentation, and reassembly of RLC SDUs (only for UM and AM data transfers))

[0088] - Re-segmentation function (re-segmentation of RLC data PDUs (AM data transmission only))

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

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

[0091] - Error detection function (protocol error detection (AM data transmission only))

[0092] -RLC SDU Drop Function (RLC SDU Drop (for UM and AM data transfers only))

[0093] -RLC Re-establishment Function (RLC Re-establishment)

[0094] MAC 1b-15 and 1b-30 connect to multiple RLC layer devices configured in a UE and perform operations to multiplex RLC PDUs with MAC PDUs and to demultiplex RLC PDUs from MAC PDUs. The main functions of the MAC are summarized below.

[0095] - Mapping function (mapping between logical channels and transport channels)

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

[0097] - Scheduling information reporting function (Scheduling Information Report)

[0098] - HARQ function (error correction via HARQ)

[0099] - Priority processing function between logical channels (priority processing between logical channels of a UE)

[0100] - UE priority handling function (UE priority handling through dynamic scheduling)

[0101] -MBMS service identification function (MBMS service identification)

[0102] -Transmission format selection function (Transmission format selection)

[0103] -Padding (filling / recharging)

[0104] -Physical layers 1b-20 and 1b-25 perform the following operations: channel coding and modulation of higher-layer data, generating OFDM symbols from higher-layer data, transmitting OFDM symbols via radio channels, or demodulating OFDM symbols received via radio channels, channel decoding of OFDM symbols, and transmitting OFDM symbols to higher layers.

[0105] Figure 1C shows a diagram of the configuration of a next-generation mobile communication system in relation to embodiments of the present disclosure.

[0106] Referring to Figure 1C, the radio access network of the next-generation mobile communication system (hereinafter referred to as "NR" or "5G") includes a new radio node B (hereinafter referred to as "NR gNB" or "NR base station") 1c-10 and a new radio core network (NR CN) 1c-05. New radio user equipment (hereinafter referred to as "NR UE" or "terminal") 1c-15 accesses external networks through NR gNB 1c-10 and NR CN 1c-05.

[0107] In Figure 1C, NR gNB 1c-10 corresponds to the Evolved Node B (ENB) of the existing LTE system. The NR gNB connects to the NR UE 1c-15 via radio channels and provides superior service compared to existing Node Bs. The NR requires equipment to perform scheduling by collecting state information such as the UE's channel state, available transmission power state, and buffer state, as all types of user traffic are served through a shared channel. NR gNB 1c-10 is responsible for this equipment. Typically, one NR gNB controls multiple cells. To achieve ultra-high-speed data transmission compared to existing LTE, the NR can have the maximum available bandwidth or greater, and can use OFDM to additionally graft beamforming technology as a radio access technology. Furthermore, the NR employs an AMC scheme, which determines the modulation scheme and channel coding rate based on the UE's channel state. NR CN1c-05 performs functions such as mobility support, bearer setup, and QoS configuration. In addition to the UE's mobility management functions, NR CN 1c-05 is responsible for various control functions and connects to multiple ENBs. Furthermore, NR can also operate in conjunction with existing LTE systems. The NR CN connects to the MME 1c-25 via a network interface. The MME connects to the ENB 1c-30, i.e., the existing ENB.

[0108] Figure 1D shows a diagram of the radio protocol structure of a next-generation mobile communication system to which embodiments of the present disclosure can be applied.

[0109] Referring to Figure 1D, the NR radio protocols in the UE and NR base station include NR SDAP 1d-01 and 1d-45, NRPDCP 1d-05 and 1d-40, NR RLC 1d-10 and 1d-35, and NR MAC 1d-15 and 1d-30, respectively.

[0110] The main functions of NR SDAP 1d-01 and 1d-45 may include some of the following functions.

[0111] - Functionality for transmitting user data (transmission of user plane data)

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

[0113] - A tagging function for QoS flow IDs in both uplink and downlink packets (tags QoS flow IDs in both DL and UL packets).

[0114] - Regarding uplink SDAP PDUs, the function of mapping reflected QoS flows to data bearers (for UL SDAP PDUs, mapping reflected QoS flows to DRBs).

[0115] RRC messages about SDAP layer devices allow for configuration in the terminal of whether to use the SDAP layer device header or its functionality, for each PDCP layer device, each bearer, or each logical channel. If the SDAP header is already configured, instructions can be executed to allow the terminal to update or reconfigure the mapping information for QoS flows and data bearers for uplink and downlink based on the NAS QoS reflection setting 1-bit indicator (NAS reflective QoS) and AS QoS reflection setting 1-bit indicator (AS reflective QoS) in the SDAP header. The SDAP header may include QoS flow ID information indicating QoS. QoS information can be used as data processing priority or scheduling information to support smooth service.

[0116] The main functions of NR PDCP 1d-05 and 1d-40 may include some of the following functions.

[0117] - Header compression and decompression functions (Header compression and decompression: ROHC only)

[0118] - User data transmission function (transmission of user data)

[0119] - Sequential delivery function (sequential delivery of upper-layer PDUs)

[0120] - Out-of-sequence delivery function (out-of-sequence delivery of upper-layer PDUs)

[0121] - Sequence reordering function (for reordering received PDCP PDUs)

[0122] - Duplicate detection function (duplicate detection of low-level SDUs)

[0123] - Retransmission function (PDCP SDU retransmission)

[0124] - Encryption and decryption functions (encryption and decryption)

[0125] - Timer-based SDU dropping function (timer-based SDU dropping in the uplink).

[0126] In the above description, the reordering function of the NR PDCP entity refers to the function of reordering PDCP PDUs received from lower layers based on the PDCP sequence number (SN). The reordering function may include sending data to higher layers in a reordered sequence, sending data directly to higher layers regardless of the sequence, reordering the sequence and recording lost PDCP PDUs, generating a status report on lost PDCP PDUs sent to the transmitting side, and requesting the retransmission of lost PDCP PDUs.

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

[0128] - Data transmission function (transmission of upper-layer PDUs)

[0129] - Sequential delivery function (sequential delivery of upper-layer PDUs)

[0130] - Out-of-order delivery function (out-of-order delivery of upper-layer PDUs)

[0131] -ARQ function (error correction via ARQ)

[0132] - Cascading, segmentation, and reassembly functions (cascading, segmentation, and reassembly of RLC SDU)

[0133] - Re-segmentation function (re-segmentation of RLC data PDUs)

[0134] - Sequence reordering function (reordering RLC data PDUs)

[0135] - Duplicate detection function (duplicate detection)

[0136] - Error detection function (protocol error detection)

[0137] -RLC SDU discard function (RLC SDU discard)

[0138] -RLC Re-establishment Function (RLC Re-establishment)

[0139] In the above description, the sequential delivery function of an NR RLC entity refers to the function of sequentially sending RLC SDUs received from a lower layer to a higher layer, and if an RLC SDU has been originally segmented into multiple RLC SDUs and received, it may include the function of reassembling and sending multiple RLC SDUs. The sequential delivery function may include: reordering received RLC SDUs based on the RLCSN(SN) or PDCP SN; reordering the sequence and recording lost RLC SDUs; sending a status report about lost RLC SDUs to the transmitting side; requesting retransmission of lost RLC SDUs; and sequentially sending only RLC SDUs preceding the lost RLC SDU to the higher layer if a lost RLC SDU exists, or sequentially sending all RLC SDUs received before a given timer expires when a lost RLC SDU exists but a timer expires, or sending all currently received RLC SDUs to the higher layer when a lost RLC SDU exists but a given timer expires. In addition, sequential delivery functionality can include the following functions: processing RLC PDUs in the order they are received (according to the order of arrival, regardless of the sequence number sequence); and sending RLC PDUs to the PDCP entity regardless of their sequence (i.e., out-of-order delivery). Sequential delivery functionality can include the following functions: receiving fragments placed in a buffer or fragments to be received subsequently, reconfiguring fragments into a complete RLC PDU, processing the RLC PDU, and sending the RLC PDU to the PDCP entity. The NR RLC layer may not include concatenation functionality. Concatenation functionality can be performed by the NR MAC layer, or it can be replaced by multiplexing functionality of the NR MAC layer.

[0140] In the above description, the out-of-order delivery function of an NR RLC entity refers to the function of directly sending RLC SDUs received from a lower layer to a higher layer regardless of their order. If an RLC SDU has been originally segmented into multiple RLCSDUs and received, the out-of-order delivery function may include the ability to reassemble the multiple RLC SDUs. The out-of-order delivery function may include the following functions: storing the RLC SN or PDCP SN of the received RLC PDUs, reordering their sequence, and recording lost RLC PDUs.

[0141] NR MAC 1d-15 and 1d-30 can connect to multiple NR RLC layer devices configured in a single UE. The main functions of the NR MAC may include some of the following.

[0142] - Mapping function (mapping between logical channels and transport channels)

[0143] - Multiplexing / demultiplexing function (MAC SDU multiplexing / demultiplexing)

[0144] - Scheduling information reporting function (Scheduling Information Report)

[0145] - HARQ function (error correction via HARQ)

[0146] - Priority processing function between logical channels (priority processing between logical channels of a UE)

[0147] - UE priority handling function (UE priority handling through dynamic scheduling)

[0148] -MBMS service identification function (MBMS service identification)

[0149] -Transmission format selection function (Transmission format selection)

[0150] - Fill function (Fill)

[0151] The NR PHY layers 1d-20 and 1d-25 can perform the following operations: channel coding and modulation of higher-layer data, generating OFDM symbols from higher-layer data, transmitting OFDM symbols to the radio channel, or demodulating OFDM symbols received through the radio channel, channel decoding of OFDM symbols, and transmitting OFDM symbols to higher layers.

[0152] This disclosure presents a method for performing compression and decompression of Ethernet headers when using the Ethernet protocol in next-generation mobile communication systems.

[0153] Figure 1E illustrates a process, in relation to embodiments of the present disclosure, in which a base station configures configuration information related to the Ethernet header protocol in a terminal when the terminal establishes a connection with the network.

[0154] Figure 1E illustrates the process by which a terminal switches from RRC idle mode or RC inactive mode (or lightly connected mode) to RRC connected mode and establishes a connection with the network, as disclosed in this disclosure, and also illustrates the process by which a base station configures configuration information related to the Ethernet protocol in the terminal.

[0155] Specifically, the base station can indicate whether to perform Ethernet header compression and decompression in the SDAP layer device or PDCP layer device, whether to use Ethernet header compression and decompression only in the downlink or uplink, or bidirectionally in both the downlink and uplink, and can configure Ethernet header protocol-related configuration information only in terminals with UE capabilities capable of using the Ethernet protocol or in terminals with UE capabilities capable of using the Ethernet header compression and decompression process. When a terminal reports its UE capabilities to the base station, it can define a new indicator and use this indicator to report to the base station whether the terminal can use the Ethernet protocol or the Ethernet header compression and decompression process. Furthermore, the base station can configure what type of Ethernet frame or Ethernet header will be used for each bearer or for each logical channel, and can configure which fields are already configured in the Ethernet header, how many bytes the Ethernet header is, how many bits each field in the Ethernet header is, or how the fields of the Ethernet header are configured. In addition, the base station can indicate whether to use the following function: this function enables the transmitting stage to remove padding and enables the receiving stage to add padding, such that if padding is added to an Ethernet frame, the padding is not transmitted in the actual radio link.

[0156] In Figure 1E, if a terminal sending and receiving data in RRC connection mode has no data to send and receive for a given reason or at a given time, the base station can instruct the terminal to switch to RRC idle mode or RRC inactive mode by sending an RRCConnectionRelease message (1e-01). Subsequently, if a terminal that has not yet established a connection (hereinafter referred to as an idle mode UE or INACTIVE UE) has data to send, the terminal performs an RRC connection setup procedure or an RRC connection recovery procedure with the base station. The terminal establishes reverse transmission synchronization with the base station through a random access procedure and sends an RRCConnectionRequest message (or an RRCResumeRequest message in the case of a recovery procedure) to the base station (1e-05). This message contains the terminal's ID and the reason for establishing the connection (establishmentCause).

[0157] The base station sends an RRCConnectionSetup message (or RRCResume message in the case of a recovery process) to enable the terminal to establish an RRC connection (1e-10). This message may include information indicating whether Ethernet protocol or Ethernet header compression and decompression procedures are used for each logical channel (logicalchannelconfig), each bearer, each PDCP device (PDCP-config), or each SDAP layer device. Furthermore, more specifically, the base station can instruct which IP flow or QoS flow in each logical channel, or bearer, or each PDCP device (or SDAP device) uses the Ethernet protocol or whether the Ethernet header compression and decompression process is used (i.e., the base station can configure information in the SDAP device regarding whether the Ethernet protocol is applied to IP flows or QoS flows for which the EthHC method is not used, and therefore, the SDAP device can instruct whether the Ethernet protocol is applied or the EthHC method is used in the PDCP device for each QoS flow. Alternatively, the SDAP layer device or PDCP device can autonomously identify each QoS flow and determine whether the Ethernet protocol is applied or the EthHC method is used).

[0158] Furthermore, in the above description, if it indicates whether to apply the Ethernet protocol or use the EthHC method, the base station can indicate whether to apply the Ethernet protocol or the ID of a predefined library or dictionary to be used in the EthHC method. Additionally, the message may include commands for establishing or releasing whether to apply the Ethernet protocol or execute the EthHC method. Furthermore, in the above description, when the base station configures whether to apply the Ethernet protocol or use the EthHC method, the base station can always use an RLC AM bearer (which does not have a data loss mode because it includes ARQ or retransmission functionality) or an RLC UM bearer to configure whether to apply the Ethernet protocol or use the EthHC method. It can be configured together with the Header Compression Protocol (ROHC), and depending on the situation, they may not be configured simultaneously.

[0159] Furthermore, the base station can indicate via messages whether to use the functions of the SDAP layer device or whether to use the SDAP header for each logical channel (logicalchannelconfig), or for each bearer, or for each PDCP device (PDCP-config), and can configure whether to apply IP packet header compression (ROHC) for each logical channel (logicalchannelconfig), or for each bearer, or for each PDCP device (PDCP-config), and can configure whether to apply ROHC via indicators for each of the uplink and downlink. In addition, the base station can configure whether to use the User Data Compression (UDC) method for each of the uplink and downlink, for each bearer, for each logical channel, or in each PDCP device configuration or SDAP device configuration. That is, the base station can be configured to use the User Data Compression (UDC) method in the uplink but not in the downlink, or it can be configured not to use the User Data Compression (UDC) method in the uplink but use it in the downlink, or it can be configured to use the User Data Compression (UDC) method in both the uplink and downlink.

[0160] Furthermore, the base station can configure both the EthHC procedure and the ROHC header compression procedure simultaneously using this message. Additionally, in handover situations (e.g., intra-base station handover), or when switching from RRC inactive mode to RRC connected mode, the base station can define and indicate an indicator (drbEthHCContinue) that suggests the configuration information or context related to the EthHC protocol should continue to be used without being reset. When a terminal that has received the indicator reconfigures its SDAP or PDCP layer devices, it can continue to use the configuration information or context related to the EthHC protocol by considering the indicator, without resetting it. In this case, the overhead attributable to EthHC protocol reset can be reduced.

[0161] Furthermore, the base station can define new indicators through this message and can indicate whether configuration information or context related to the EthHC protocol should be reset. Additionally, the base station can configure whether to configure the SDAP protocol or SDAP header through the RRC message. Furthermore, the base station can configure which type of Ethernet frame or Ethernet header to use for each bearer or for each logical channel through this message, and can configure which fields are already configured in the Ethernet header, the size of the Ethernet header in bytes, the size of each field in the Ethernet header in bits, or how the fields of the Ethernet header are configured. Additionally, the base station can indicate whether to use a function that enables the transmitting stage to remove padding and the receiving stage to add padding, such that if padding is added to the Ethernet frame, the padding is not transmitted in the actual radio link.

[0162] In addition, this message contains RRC connection setup information, etc. The RRC connection, also known as the Signaling Radio Bearer (SRB), is used to send and receive RRC messages, i.e., control messages, between the terminal and the base station. A terminal that has established an RRC connection sends an RRCConnectionSetupComplete message (1e-15) to the base station. If the base station does not know the UE capabilities of the terminal with which it has now established a connection, or wants to check the UE capabilities of the terminal, it can send a message to inquire about the UE capabilities. Furthermore, the terminal can send a message reporting its capabilities. This message can indicate whether the terminal can use the Ethernet protocol or whether the terminal can use the Ethernet header compression and decompression process. The base station can send a message including indicators for whether the terminal can use the Ethernet protocol or whether the terminal can use the Ethernet header compression and decompression process.

[0163] The RRCConnetionSetupComplete message includes a control message called SERVICE REQUEST, which the terminal uses to request bearer setup for a given service from the MME. The base station sends the SERVICE REQUEST message included in the RRCConnetionSetupComplete message to the MME (1e-20). The MME determines whether to provide the service requested by the terminal. As a result of this determination, if the MME has determined to provide the service requested by the terminal, the MME sends a message called INITIAL CONTEXT SETUP REQUEST (1e-25) to the base station. This message includes information such as Quality of Service (QoS) information to be applied when configuring the Data Radio Bearer (DRB) and security-related information to be applied to the DRB (e.g., security keys, security algorithms). The base station exchanges a SecurityModeCommand message (1e-30) and a SecurityModeComplete message (1e-35) to establish security with the terminal. When the security settings are complete, the base station sends an RRCConnectionReconfiguration message to the terminal (1e-40).

[0164] The base station may include the following information in the message: this information indicates whether Ethernet protocol or Ethernet header compression and decompression procedures are used for each logical channel (logicalchannel configuration), or for each bearer, or for each PDCP device (PDCP-config), or for each SDAP layer device. Furthermore, more specifically, the base station may indicate which IP flow or QoS flow in each logical channel, or bearer, or each PDCP device (or SDAP device) uses Ethernet protocol or Ethernet header compression and decompression procedures (i.e., the base station may configure information in the SDAP device regarding whether Ethernet protocol is applied to IP flows or QoS flows for which the EthHC method is not used, and therefore, the SDAP device may indicate whether Ethernet protocol is applied or the EthHC method is used in the PDCP device for each QoS flow. Alternatively, the SDAP layer device or PDCP device may autonomously identify each QoS flow and determine whether Ethernet protocol or the EthHC method is applied).

[0165] Furthermore, in the above description, if it indicates whether to apply the Ethernet protocol or whether to use the EthHC method, the base station may indicate whether to apply the Ethernet protocol or the ID of a predefined library or dictionary to be used in the EthHC method. Additionally, the message may include commands for establishing or releasing whether to apply the Ethernet protocol or whether to execute the EthHC method.

[0166] Furthermore, in the above description, when configuring whether to apply the Ethernet protocol or use the EthHC method, the base station can always use an RLC AM bearer (which does not have a data loss mode because it includes ARQ or retransmission functionality) or an RLC UM bearer to configure whether to apply the Ethernet protocol or use the EthHC method. This can be configured together with Header Compression Protocol (ROHC), and depending on the situation, they may not be configured simultaneously. Additionally, the base station can indicate via messages whether to use the SDAP layer device functionality or whether to use the SDAP header for each logical channel (logicalchannelconfig), or for each bearer, or for each PDCP device (PDCP-config), whether to apply IP Packet Header Compression (ROHC), and whether to apply ROHC via indicators for each of the uplink and downlink. Furthermore, the base station can configure whether to use the User Data Compression (UDC) method for each of the uplink and downlink, for each bearer, for each logical channel, or in each PDCP device configuration or SDAP device configuration. That is, the base station can be configured to use the User Data Compression (UDC) method in the uplink but not in the downlink, or it can be configured to not use the User Data Compression (UDC) method in the uplink but use it in the downlink, or it can be configured to use the User Data Compression (UDC) method in both the uplink and downlink.

[0167] Furthermore, the base station can configure both the EthHC procedure and the ROHC header compression procedure simultaneously using this message. Additionally, in handover situations (e.g., intra-base station handover), or when switching from RRC inactive mode to RRC connected mode, the base station can define and indicate an indicator (drbEthHCContinue) that suggests the configuration information or context related to the EthHC protocol should continue to be used without being reset. When a terminal that has received the indicator reconfigures its SDAP or PDCP layer devices, it can continue to use the configuration information or context related to the EthHC protocol by considering the indicator, without resetting it. In this case, the overhead attributable to EthHC protocol reset can be reduced.

[0168] Furthermore, the base station can define new indicators through this message and can indicate whether configuration information or context related to the EthHC protocol should be reset. Additionally, the base station can configure whether to configure the SDAP protocol or SDAP header through the RRC message. Furthermore, the base station can configure which type of Ethernet frame or Ethernet header to use for each bearer or for each logical channel, and can configure which fields are already configured in the Ethernet header, the size of the Ethernet header in bytes, the size of each field in the Ethernet header in bits, or how the fields of the Ethernet header are configured. Additionally, the base station can indicate whether to use a function that enables the transmitting stage to remove padding and the receiving stage to add padding, such that if padding is added to the Ethernet frame, the padding is not transmitted in the actual radio link.

[0169] In addition, this message includes configuration information for the DRB, in which user data will be processed. The terminal configures the DRB by applying this information and sends an RRCConnectionReconfigurationComplete message to the base station (1e-45). The base station, with which the terminal has completed DRB setup, sends an INITIAL CONTEXT SETUP COMPLETE message to the MME (1e-50). The MME, having received the INITIAL CONTEXT SETUP COMPLETE message, exchanges an S1 BEARER SETUP message and an S1 BEARER SETUP RESPONSE message with the S-GW to establish the S1 bearer (1e-055 and 1e-60). The S1 bearer is a connection established between the S-GW and the base station for data transmission and corresponds to a DRB on a one-to-one basis. When this process is complete, the terminal sends data to and receives data from the base station via the S-GW (1e-65 and 1e-70). As mentioned above, the common data transmission process is basically configured through the following three steps: RRC connection establishment, security settings, and DRB setup. In addition, the base station can send an RRCConnectionReconfiguration message to the terminal to provide new configurations or to add or change configurations for a given reason (1e-75).

[0170] This message may include information indicating whether Ethernet protocol or Ethernet header compression and decompression procedures are used for each logical channel (logicalchannelconfig), or for each bearer, or for each PDCP device (PDCP-config), or for each SDAP layer device. Furthermore, more specifically, the base station may indicate which IP flow or QoS flow in each logical channel, or bearer, or PDCP device (or SDAP device) uses Ethernet protocol or Ethernet header compression and decompression procedures (i.e., the base station may configure information in the SDAP device regarding whether Ethernet protocol is applied to IP flows or QoS flows for which the EthHC method is not used, and therefore, the SDAP device may indicate whether Ethernet protocol is applied or the EthHC method is used in the PDCP device for each QoS flow. Alternatively, the SDAP layer device or PDCP device may autonomously identify each QoS flow and determine whether Ethernet protocol or the EthHC method is applied).

[0171] Furthermore, in the above description, if it indicates whether to apply the Ethernet protocol or use the EthHC method, the base station can indicate whether to apply the Ethernet protocol or the ID of a predefined library or dictionary to be used in the EthHC method. Additionally, the message may include commands for establishing or releasing whether to apply the Ethernet protocol or execute the EthHC method. Furthermore, in the above description, when the base station configures whether to apply the Ethernet protocol or use the EthHC method, the base station can always use an RLC AM bearer (which does not have a data loss mode because it includes ARQ or retransmission functionality) or an RLC UM bearer to configure whether to apply the Ethernet protocol or use the EthHC method. It can be configured together with the Header Compression Protocol (ROHC), and depending on the situation, they may not be configured simultaneously.

[0172] Furthermore, the base station can indicate via messages whether to use the functions of the SDAP layer device or whether to use the SDAP header for each logical channel (logicalchannelconfig), or for each bearer, or for each PDCP device (PDCP-config), and can configure whether to apply IP packet header compression (ROHC) for each logical channel (logicalchannelconfig), or for each bearer, or for each PDCP device (PDCP-config), and can configure whether to apply ROHC via indicators for each of the uplink and downlink. In addition, the base station can configure whether to use the User Data Compression (UDC) method for each of the uplink and downlink, for each bearer, for each logical channel, or in each PDCP device configuration or SDAP device configuration. That is, the base station can be configured to use the User Data Compression (UDC) method in the uplink but not in the downlink, or it can be configured not to use the User Data Compression (UDC) method in the uplink but use it in the downlink, or it can be configured to use the User Data Compression (UDC) method in both the uplink and downlink.

[0173] Furthermore, the base station can configure both the EthHC procedure and the ROHC header compression procedure simultaneously using this message. Additionally, in handover situations (e.g., intra-base station handover), or when switching from RRC inactive mode to RRC connected mode, the base station can define and indicate an indicator (drbEthHCContinue) that suggests the configuration information or context related to the EthHC protocol should continue to be used without being reset. When a terminal that has received the indicator reconfigures its SDAP or PDCP layer devices, it can continue to use the configuration information or context related to the EthHC protocol by considering the indicator, without resetting it. In this case, the overhead attributable to EthHC protocol reset can be reduced.

[0174] Furthermore, the base station can define new indicators through this message and can indicate whether configuration information or context related to the EthHC protocol should be reset. Additionally, the base station can configure whether to configure the SDAP protocol or SDAP header through the RRC message. Furthermore, the base station can configure which type of Ethernet frame or Ethernet header to use for each bearer or for each logical channel, and can configure which fields are already configured in the Ethernet header, the size of the Ethernet header in bytes, the size of each field in the Ethernet header in bits, or how the fields of the Ethernet header are configured. Additionally, the base station can indicate whether to use a function that enables the transmitting stage to remove padding and the receiving stage to add padding, such that if padding is added to the Ethernet frame, the padding is not transmitted in the actual radio link.

[0175] Figure 1F shows a diagram of the Ethernet header compression (EthHC) method proposed in this disclosure.

[0176] In Figure 1F, higher-layer data 1f-05 can be generated as data corresponding to services such as video transmission, photo transmission, web search, or VoLTE. Data generated from the application layer device can be processed via TCP / IP or UDP corresponding to the network data transmission layer, or via the Ethernet protocol to configure headers 1f-10, 1f-15, and 1f-20 (higher-layer headers or Ethernet headers), and can be delivered to the PDCP layer. When data (e.g., PDCP SDU) is received from a higher layer, the PDCP layer can perform the following procedures.

[0177] If Header Compression (ROHC) or EthHC procedures have been configured for use in an SDAP layer device or PDCP layer via RRC messages (such as 1e-10, 1e-40, or 1e-75 in Figure 1E), the transmitting stage can perform EthHC procedures on Ethernet headers 1f-20 in the SDAP layer device or on PDCP layer devices (such as 1f-22). Integrity verification can be performed if integrity protection is configured, encryption can be performed, and PDCP PDUs can be configured by configuring PDCP headers 1f-30. In the above description, the SDAP layer device or PDCP layer device includes header compression / decompression means, as configured in the RRC messages, to determine whether to perform header compression on each data segment, and to use the header compression / decompression means. The transmitting stage uses the header compression means in the transmitting SDAP layer device or PDCP layer device to perform compression on Ethernet headers or higher-layer headers (e.g., TCP / IP headers). The receiver uses the header decompression device in the receive SDAP layer device or PDCP layer device to perform header decompression on Ethernet headers or higher-layer headers (e.g., TCP / IP headers).

[0178] The terminal can apply the procedure in Figure 1F to perform uplink header compression, and the base station can also apply the procedure in Figure 1F to perform downlink header compression. Furthermore, the description of uplink data can be applied in the same way to downlink data.

[0179] The method for performing EthHC on Ethernet headers as proposed in this disclosure is a method to reduce the header size by omitting fields indicating fixed information and only indicating changed information. Therefore, the transmitting stage can first (i.e., during the first transmission) transmit the entire header information and configuration information for compression (e.g., sequence number or ID (type) for each service of the Ethernet protocol, and information related to compression ratio). Furthermore, during subsequent transmissions, the transmitting stage can configure the header to reduce its size by omitting fields corresponding to information unchanged compared to all the information transmitted in the first transmission (e.g., send address field or receive address field (MAC address) or start of frame delimiter (SFD) or frame checksum (FCS) or Ethernet type field), or by including only fields corresponding to the changed information that has not been transmitted.

[0180] Specifically, in the EthHC method disclosed herein, the following describes how to compress the Ethernet header (1f-22).

[0181] In EthHC protocol 1f-22, when data is received from a higher-layer device, the SDAP layer device or PDCP layer device (at the transmitting level) can identify the Ethernet header, compress the Ethernet header using a protocol that compresses the Ethernet header, and define and use a new header 1f-40 before the compressed Ethernet header. In the above description, the transmitting level may not perform encryption on the new header 1f-40. The reason for this is that if the new header 1f-40 is not encrypted, when the PDCP layer device delivers data to the lower-layer device after performing data processing such as integrity protection or encryption, a terminal implementation can be easily performed because if the SDAP header has already been configured at that time, the SDAP header, PDCP header, or new header can all be attached together at once.

[0182] As mentioned above, the method for compressing Ethernet headers is as follows: selectively sending only the necessary or valid fields by omitting field values ​​that are unchanged from previous Ethernet headers, or field values ​​that are unchanged from previous Ethernet headers, or Ethernet header field values ​​that do not need to be sent. Therefore, this method is used for the transmitting stage to transmit as follows: if the first field 1f-31, the second field 1f-32, the fourth field 1f-34, the fifth field 1f-35, the sixth field 1f-36, and the seventh field 1f-37 of the multiple fields included in the Ethernet header (e.g., the first field 1f-31, the second field 1f-32, the fourth field 1f-34, the fifth field 1f-35, and the seventh field 1f-37) can be omitted, do not need to be transmitted, or have the same values ​​as previously transmitted Ethernet header field values, then the transmitting stage only transmits the third field 1f-33 and the sixth field 1f-36.

[0183] However, the receiving side needs to know which fields have not been compressed, omitted, or transmitted in order to decompress the compressed Ethernet header. Therefore, when the sending side compresses the Ethernet header, it can define a new header (e.g., an EthHC header) and transmit it by appending it to the compressed Ethernet header. The sending level can define a new first field in the new EthHC header, indicating which of the multiple fields in the compressed Ethernet header has been compressed, or whether a field has been omitted or transmitted. The new field can indicate, bit by bit, whether a given field has been compressed (or omitted or not transmitted) or has not been compressed (or included or transmitted). Furthermore, the first field can indicate which fields in the Ethernet header have been compressed (or omitted) or have not been compressed (or included). Therefore, the receiving side can use the first field to calculate the size of the compressed Ethernet header. That is, the receiving level can determine the size of the compressed Ethernet header by subtracting the size of the omitted header fields from the original Ethernet header size.

[0184] In addition, the first field may have a mapping to indicate whether all fields of the Ethernet header have been compressed (or omitted), but may also have a mapping to indicate whether only the fields of the Ethernet header that can be compressed (or omitted) have been compressed (or omitted), thereby reducing the overhead of the new EthHC header.

[0185] Furthermore, the EthHC header can use a second field to indicate the size or length of the compressed Ethernet header, allowing for accurate indication of the compressed Ethernet header size (e.g., for implementation convenience). Additionally, if the Ethernet header size can have multiple types, the EthHC header can use a second field to indicate which type it is. Alternatively, a new third field can be defined indicating whether EthHC has been performed on the EthHC header.

[0186] Furthermore, as described above, the base station can configure the following for each bearer via the RRC message as depicted in Figure 1E: the type of Ethernet header or header field configured according to the Ethernet header type. Alternatively, an identifier or indicator indicating the type of Ethernet header in a new header can be defined and used between the base station and the terminal.

[0187] Another EthHC method can be used based on the new EthHC header. For example, when compressing the Ethernet header at the transmit level, if the values ​​of the header fields do not change when performing compression sequentially compared to fields in previously transmitted Ethernet headers, the Ethernet header can be compressed (omitted), and the first field can be configured accordingly. If the values ​​of the Ethernet header fields differ from the values ​​of fields in previously transmitted Ethernet headers, the Ethernet header is not compressed (including), and the first field can be configured accordingly, thus completing EthHC. In the above description, the term "sequentially" can include determining the sequence in ascending order based on PDCP sequence numbers or COUNT values. Previous Ethernet headers may indicate Ethernet headers corresponding to data whose PDCP sequence numbers or COUNT values ​​have as many as 1.

[0188] Upon receiving a compressed Ethernet header, the receiver can identify the first field and restore the compressed (omitted) fields in the Ethernet header accordingly, as these fields have the same values ​​as fields in previously received Ethernet headers, and can also update any uncompressed (inclusive) fields. The transmitter and receiver can have separate buffers for compressing the Ethernet header, which can be updated whenever the Ethernet header is compressed and whenever it is decompressed. If the compressed Ethernet header is restored, the receiver can remove the new EthHC header and deliver the restored data to a higher layer. Furthermore, when sending the Ethernet header for the first time, the transmitter can send the entire Ethernet header information. That is, initially, the transmitter can send the entire Ethernet header information, allowing the receiver to know the entire Ethernet header information without performing EthHC.

[0189] Figure 1G illustrates a detailed embodiment of the EthHC method proposed in this disclosure.

[0190] In Figure 1G, the PDCP or SDAP layer device at the transmitting stage receives Ethernet frame 1g-05 from the higher-layer device. If the EthHC procedure has been configured, the PDCP or SDAP layer device can store the field values ​​of the Ethernet header of the first received Ethernet frame in buffer 1g-15 for Ethernet compression during transmission. Alternatively, the PDCP or SDAP layer device can transmit the first Ethernet frame without performing EthHC. Furthermore, when a second Ethernet frame is received, the transmitting stage can compare each of the field values ​​in the Ethernet header with each of the field values ​​stored in the transmit buffer used for Ethernet compression. As a result of the comparison, if a field with the same value exists, the transmitting stage can omit the corresponding field by setting the bit corresponding to or mapped to the omitted field to 1 (or 0) and indicating that the field has been omitted. The result of comparing each of the field values ​​in the Ethernet header of the second Ethernet frame with each of the fields stored in the transmit buffer for Ethernet compression, if there are fields with different values, the transmit stage may not omit the corresponding field, may set the bit corresponding to or mapped to the field that has not been omitted to 0 (or 1), and may indicate that the field has not been omitted.

[0191] Furthermore, if integrity protection has been configured, the transmitting stage can perform integrity protection, perform encryption processes, configure new header 1g-10, configure PDCP headers, attach new headers and PDCP headers, and send them to the receiving stage by delivering them to lower-level devices.

[0192] In the above description, the new header 1g-10 can indicate which field of the Ethernet header each bit is included (not yet compressed) in, or which field of the Ethernet header it is not included (already compressed), as in a bitmap.

[0193] In the above description, the transmitting stage can indicate whether the EthHC procedure has been performed by defining a new field (e.g., a 1-bit indicator) in the new header 1g-10. The 1-bit indicator can directly indicate that EthHC has not been performed, therefore the receiving stage does not perform processing for the new header. Furthermore, in the above description, the transmitting stage can define and use the 1-bit indicator indicating whether the EthHC procedure has been performed in the SDAP or PDCP header. If both the transmitting and receiving stages define this 1-bit indicator in the SDAP or PDCP header, overhead can be reduced because: if the EthHC procedure is not performed, the new header 1g-10 itself for EthHC can be omitted.

[0194] In Figure 1G, the PDCP or SDAP layer device of the receiver stage can receive compressed Ethernet frames 1g-25 from the lower-layer device. If the EthHC procedure has been configured, the PDCP or SDAP layer device can identify each of the field values ​​in the Ethernet header of the first received Ethernet frame and store the field values ​​in a buffer 1g-30 for receiving Ethernet decompression. Furthermore, the receiver stage can deliver the first Ethernet frame to the higher-layer device without performing Ethernet header decompression. Additionally, when a second Ethernet frame is received, the receiver stage can identify which fields have been omitted (compressed) and which fields have not been omitted (uncompressed) by examining the field values ​​in the new header 1g-10 for Ethernet compression. The receiver stage restores the Ethernet header before compression (performs decompression) by restoring the fields indicated as omitted (compressed) in the above description to their stored values ​​in the receive buffer for decompression. Furthermore, the receiver level stores new or changed values ​​in the receive buffer for decompression based on the fields described above, because the values ​​of fields indicated as not omitted (uncompressed) in the above description are new or changed values. Additionally, the receiver level: performs decryption; performs integrity verification if integrity protection is configured; configures the Ethernet frame along with the restored Ethernet header as described above if no errors are found; and delivers the Ethernet frame to the higher-layer device.

[0195] This disclosure proposes generating and adding a separate header, such as 1g-10. The separate header can have a fixed size (e.g., 1 byte or 2 bytes) and can be assigned a separate name, such as an EthHC header. Specifically, after performing the EthHC procedure on the Ethernet header, the transmitting stage can generate a separate header and add it before the compressed header. Furthermore, the separate header can include a length field indicating the size of the compressed Ethernet header, an indicator field indicating whether the EthHC procedure has been performed, and a checksum field so that the receiving stage can identify whether the Ethernet header decompression was successful. Alternatively, the transmitting and receiving stages can define an indicator field for resetting the EthHC protocol, and the indicator field can be used to synchronize the protocols of the transmitting and receiving stages. Alternatively, the transmitting and receiving stages can define and use a field indicating that the EthHC protocol has been reset. Alternatively, the transmitting and receiving stages can define and use a field indicating that the EthHC protocol buffer has been flushed.

[0196] In the above description, the length field that indicates the size of the compressed Ethernet header, the indicator field that indicates whether the EthHC process has been performed, the checksum field that enables the receiver to know whether the Ethernet header decompression was successful, the indicator field for resetting the EthHC protocol, and the field that indicates that the EthHC protocol has been reset, proposed for individual headers, can be defined and used in existing headers (e.g., PDCP headers or SDAP headers) rather than in separate headers.

[0197] Alternatively, if Ethernet decompression failure occurs (e.g., a checksum error has occurred), an indicator or PDCP header indicator can be defined and used in the new SDAP control PDU or PDCP control PDU or SDAP header to allow the receiver to deliver feedback according to the transmitter's Ethernet compression protocol. The newly defined SDAP control PDU or PDCP control PDU or SDAP header indicator or PDCP header indicator can indicate that the receiver failed in Ethernet decompression (or a checksum error occurred) and can indicate that a refresh of the transmit buffer for the transmitter's EthHC is required. Furthermore, the corresponding indicator can indicate the PDCP sequence number or COUNT value of the data for which Ethernet decompression failure occurred in the newly defined SDAP control PDU or PDCP control PDU or SDAP header or PDCP header to prevent data loss. That is, when the transmitter receives the PDCP sequence number or COUNT value via feedback, it can know which PDCP sequence number or COUNT value corresponds to the data for which Ethernet decompression failure occurred. Therefore, the sending stage can perform integrity protection or encryption processes on the data and subsequent data using existing PDCP sequence numbers and COUNT values ​​or new PDCP sequence numbers and COUNT values, can reprocess the data, and can perform retransmissions, thereby preventing data loss.

[0198] Figure 1H illustrates a method for supporting low transmission latency and high reliability by the transmitting and receiving stages in a next-generation mobile communication system by effectively utilizing radio transmission resources in a wireless environment through the use of the Ethernet protocol.

[0199] The Ethernet protocol specifies a minimum size (e.g., 64 bytes). That is, if the data to be sent is smaller than the predefined minimum size (e.g., 64 bytes), the sending stage can add padding and send the data based on the minimum size. This is because if the received data is smaller than the predefined minimum size in the Ethernet protocol, the receiving stage will treat the received data as abnormal and discard it.

[0200] In the above description, if padding is added, the transmitting-level Ethernet protocol indicates the length of the padding in the Ethernet header. Therefore, the receiving-level Ethernet protocol can recognize the Ethernet header and check the size of the padding.

[0201] In this disclosure, a method for effectively using transmission resources is proposed as follows.

[0202] If the data size is less than a predefined minimum size, such as 1h-05, the transmitting-level Ethernet protocol adds padding based on the minimum size and delivers the data to the lower-level device. Therefore, the SDAP layer device or PDCP layer device 1h-10 (i.e., the lower-level device): reads the Ethernet header; removes padding if present; and performs transmission by processing only the actual data. In the above description, the Ethernet header may have a field indicating the size of the actual data. The receiving level can calculate the padding size by subtracting the size of the actual data from the size of the received data. Alternatively, the transmitting and receiving levels may define and use a field indicating the padding size in the Ethernet header, SDAP header, or PDCP header.

[0203] PDCP layer device or SDAP layer device 1h-20 (i.e., receiver-level lower-layer device): reads the Ethernet header; checks the padding size; adds padding based on the minimum size if no padding is present or if the data size is less than the minimum size; and delivers Ethernet frames via higher-layer Ethernet protocols. If no padding is needed (e.g., if padding is not indicated in the Ethernet header, if there is no field indicating the actual data, or if the actual data size is greater than the minimum size supported by Ethernet), the receiver-level device can perform data processing and deliver the data to the higher-layer device. In the above description, the Ethernet header may have a field indicating the size of the actual data. The receiver-level device can calculate the size of the padding to be added by subtracting the size of the actual data from the minimum size of data supported by Ethernet. Alternatively, the receiver-level device can know the size of the padding directly from the field indicating the size of the padding in the Ethernet header, SDAP header, or PDCP header.

[0204] As described above, when transmitting actual data in a wireless environment, only the actual data, excluding padding, is transmitted. Therefore, because transmission resources can be used efficiently, low transmission latency and high reliability can be supported.

[0205] In Figure 1H, padding may not actually be sent in the data of the Ethernet frame and can be omitted at the transmitting level. It can indicate how much padding has been omitted and only the actual data can be sent. The receiving level checks the indication to see how much padding has been omitted, restores and adds the omitted padding, and delivers it to the higher-layer device. That is, the transmitting level does not actually send fields in the Ethernet header that can be compressed or omitted. The transmitting level compresses or omits fields, uses a new header to indicate which fields have been omitted, and performs transmission only for fields that are actually valid or important. The receiving level identifies which fields have been omitted by checking the indications in the new header, restores and adds the omitted fields, and delivers them to the higher-layer device. In the above description, when fields in the Ethernet header are omitted at the transmitting level, they can be omitted based on the fields in the previously generated Ethernet header. When the receiving level restores the fields in the Ethernet header, it can restore the fields based on the fields in the previously received Ethernet header. As another approach, if the transmitting-level PDCP or SDAP layer device and the receiving-level PDCP or SDAP layer device have been configured or agreed not to use unnecessary Ethernet header fields, the transmitting-level PDCP or SDAP layer device can omit or remove unnecessary Ethernet header fields and can send only the necessary Ethernet header fields (compressed Ethernet headers) along with the data. The receiving level can restore the fields that were configured to be omitted or removed because they are unnecessary Ethernet header fields as described above; the original Ethernet header can be configured; and it can be delivered to a higher Ethernet protocol.

[0206] Figure 1I illustrates the operation of the transmitting and receiving SDAP layer apparatus or PDCP layer apparatus as proposed in this disclosure.

[0207] First, the sending SDAP or PDCP layer device performs the EthHC procedure (1i-01) on the Ethernet header of the data received from the higher layer. Specifically, if the SDAP header has been configured via RRC messages as described above, the EthHC procedure (1i-10) is performed only on the first given byte (e.g., 18 bytes) of the data received from the higher layer (e.g., PDCP SDU), excluding the SDAP header, i.e., the Ethernet header; and not on the SDAP header or other higher layer headers besides Ethernet. Furthermore, if integrity protection and authentication procedures have been configured, integrity protection is performed on the entire SDAP header (1i-10), the compressed Ethernet header, and the compressed TCP / IP header, and the MAC-I is calculated and appended to the end of the data. An encryption procedure (1i-15) is performed on the remaining portion of the data, excluding the SDAP header and a separate header for Ethernet compression. Next, the sending stage generates a PDCP header, concatenates the PDCP header and the processed data, and delivers the PDCP header and data together to the lower layer (1i-20).

[0208] The receiving SDAP layer device or PDCP layer device (1i-02) first reads or excludes the SDAP header or PDCP header (1i-30), performs a decryption process except for the separate header used for Ethernet compression (1i-35), checks the size of the compressed Ethernet header by reading the separate header, restores the Ethernet header by performing the Ethernet header decompression process (1i-40), and delivers the data along with the restored Ethernet header and / or SDAP header to the higher layer (1i-45).

[0209] Figure 1J illustrates the configuration of a terminal to which embodiments of the present disclosure can be applied.

[0210] Referring to Figure 1J, the terminal includes a radio frequency (RF) processor 1j-10, a baseband processor 1j-20, a storage unit 1j-30, and a controller 1j-40.

[0211] RF processor 1j-10 performs functions for transmitting / receiving signals via a radio channel, such as signal band conversion and amplification. Specifically, RF processor 1j-10 up-converts baseband signals received from baseband processor 1j-20 to RF band signals, transmits RF band signals via an antenna, and down-converts RF band signals received via an antenna back to baseband signals. For example, RF processor 1j-10 may include transmit filters, receive filters, amplifiers, mixers, oscillators, digital-to-analog converters (DACs), and analog-to-digital converters (ADCs). In Figure 1J, only one antenna is shown, but the UE may include multiple antennas. Furthermore, RF processor 1j-10 may include multiple RF chains. Additionally, RF processor 1j-10 can perform beamforming. For beamforming, RF processor 1j-10 can adjust the phase and magnitude of each signal transmitted / received via multiple antennas or antenna elements. Furthermore, the RF processor can perform MIMO. When performing MIMO operation, the RF processor can receive multiple layers. The RF processor 1j-10 can appropriately configure multiple antennas or antenna elements under the control of the controller, and can perform receive beam scanning (swip) or adjust the direction and beamwidth of the receive beam so that the receive beam cooperates with the transmit beam.

[0212] The baseband processor 1j-20 performs baseband signal and bitstream conversion functions based on the system's physical layer standard. For example, when transmitting data, the baseband processor 1j-20 generates complex symbols by encoding and modulating the transmitted bitstream. Furthermore, when receiving data, the baseband processor 1j-20 reconstructs the received bitstream based on the baseband signal received from the RF processor 1j-10 by demodulating and decoding. For example, if an Orthogonal Frequency Division Multiplexing (OFDM) scheme is applied, when transmitting data, the baseband processor 1j-20 generates complex symbols by encoding and modulating the transmitted bitstream, maps the complex symbols to subcarriers, and then configures the OFDM symbols through inverse Fast Fourier Transform (IFFT) operations and cyclic prefix (CP) insertion. In addition, when data is received, the baseband processor 1j-20 segments the baseband signal received from the RF processor 1j-10 in units of OFDM symbols, reconstructs the signal mapped to the subcarrier through Fast Fourier Transform (FFT) operations, and reconstructs the received bitstream through demodulation and decoding.

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

[0214] Storage unit 1j-30 stores data such as basic programs, application programs, and configuration information for UE operation. Storage unit 1j-30 provides the stored data in response to requests from controller 1j-40.

[0215] Controller 1j-40 controls the overall operation of the UE. For example, controller 1j-40 transmits / receives signals via baseband processor 1j-20 and RF processor 1j-10. Furthermore, controller 1j-40 writes data to and reads data from storage unit 1j-40. For this purpose, controller 1j-40 may include at least one processor. For example, controller 1j-40 may include a communication processor (CP) that performs control for communication and an application processor (AP) that controls higher-level processes such as applications. Additionally, controller 1j-40 may include a multi-connectivity processor 1j-42 configured to perform processing for operation in multi-connectivity mode.

[0216] Figure 1K shows a block diagram of a TRP in a wireless communication system to which embodiments of the present disclosure may be applied.

[0217] As shown in Figure 1K, the base station is configured to include an RF processor 1k-10, a baseband processor 1k-20, a backhaul communication unit 1k-30, a storage unit 1k-40, and a controller 1k-50.

[0218] RF processor 1k-10 performs functions for transmitting / receiving signals over a radio channel, such as signal band conversion and amplification. Specifically, RF processor 1k-10 up-converts baseband signals received from baseband processor 1k-20 to RF band signals, transmits RF band signals through an antenna, and down-converts RF band signals received through an antenna back to baseband signals. For example, RF processor 1k-10 may include transmit filters, receive filters, amplifiers, mixers, oscillators, DACs, and ADCs. Only one antenna is shown in Figure 1K, but the first access node may include multiple antennas. Furthermore, RF processor 1k-10 may include multiple RF chains. Additionally, RF processor 1k-10 can perform beamforming. For beamforming, RF processor 1k-10 can adjust the phase and magnitude of each signal transmitted / received through multiple antennas or antenna elements. The RF processor can perform downlink MIMO operation by transmitting one or more layers.

[0219] The baseband processor 1k-20 performs baseband signal and bitstream conversion functions based on the physical layer standard of the first radio access technology. For example, when transmitting data, the baseband processor 1k-20 generates complex symbols by encoding and modulating the transmitted bitstream. Furthermore, when receiving data, the baseband processor 1k-20 reconstructs the received bitstream based on the baseband signal received from the RF processor 1k-10 through demodulation and decoding. For example, if an OFDM scheme is applied, when transmitting data, the baseband processor 1k-20 generates complex symbols by encoding and modulating the transmitted bitstream, maps the complex symbols to subcarriers, and configures the OFDM symbols through IFFT operations and CP insertion. Furthermore, when receiving data, the baseband processor 1k-20 segments the baseband signal received from the RF processor 1k-10 in units of OFDM symbols, reconstructs the signal mapped to the subcarriers through FFT operations, and then reconstructs the received bitstream through demodulation and decoding. As described above, the baseband processor 1k-20 and the RF processor 1k-10 transmit and receive signals. Therefore, the baseband processor 1k-20 and the RF processor 1k-10 can be referred to as a transmitter, a receiver, a transceiver, a backhaul communication unit, or a wireless backhaul communication unit.

[0220] The backhaul communication unit 1k-30 provides an interface for communicating with other nodes within the network.

[0221] Storage unit 1k-40 stores data such as basic procedures, application programs, and configuration information for base station operation. Specifically, storage unit 1k-40 can store information about bearers assigned to accessing UEs and measurement results reported by the accessing UEs. Furthermore, storage unit 1k-40 can store information, i.e., criteria for determining whether to provide multiple connections to the UE. Additionally, storage unit 1k-40 provides the stored data in response to requests from controller 1k-50.

[0222] The controller 1k-50 controls the overall operation of the main base station. For example, the controller 1k-50 transmits / receives signals via the baseband processor 1k-20 and the RF processor 1k-10, or via the backhaul communication unit 1k-30. Furthermore, the controller 1k-50 writes data to and reads data from the storage unit 1k-40. For this purpose, the controller 1k-50 may include at least one processor. Additionally, the controller 1k-50 may include a multi-connectivity processor 1k-52, which is configured to perform processing for operation in multi-connectivity mode.

[0223] <Second Embodiment>

[0224] Figure 2A illustrates a pattern in which a terminal can remain in a next-generation mobile communication system in relation to embodiments of this disclosure.

[0225] In Figure 2A, a terminal can remain in RRC Connected Mode 2a-03, RRC Inactive Mode 2a-02, or RRC Idle Mode 2a-01, and may undergo switching to different modes 2a-05, 2a-10, 2a-15, 2a-20, and 2a-25. That is, if data to be transmitted in the uplink is generated due to the arrival of downlink data, or a paging message is received, or to send and receive data to update the tracking area or RAN paging area by establishing a connection with the network (periodically, or if the terminal deviates from the tracking area), a terminal in RRC Idle Mode 2a-01 can switch to RRC Connected Mode 2a-03 (2a-05). In the above description, if the RAN paging area is updated, the terminal can perform the update by exchanging messages while maintaining RRC Inactive Mode. If no data is generated within a given time after sending and receiving data, a terminal in RRC Connected Mode can switch to RRC Idle Mode (2a-15) via the network. Furthermore, if no data is generated within a given time, a terminal in RRC connection mode 2a-03 can switch to RRC inactive mode 2a-02 (2a-20) autonomously by changing the mode by the network or for the following purposes: when the battery power is low and fast connection is supported (e.g., when a timer value set by the network expires).

[0226] If data to be transmitted in the uplink is generated due to the arrival of downlink data, or a paging message is received, or to send and receive data to update the tracking area (or RAN notification area) by establishing a connection with the network (periodically, or if the terminal deviates from the tracking area (or RAN notification area)), a terminal in RRC inactive mode 2a-03 can switch to RRC connected mode 2a-03 (2a-10). A terminal in RRC inactive mode 2a-03 can change its mode to RRC idle mode 2a-01 (2a-25) in response to instructions from the network or according to a pre-agreed configuration or autonomously (e.g., when a timer value set by the network expires). The above operations are required because if there are many terminals in RRC inactive mode in the network, the frequent RAN notification area update process may increase the signaling overhead of the network. Terminals with a given object can send data in RRC inactive mode 2a-03 even without switching to RRC connected mode, can switch repeatedly between RRC inactive mode and RRC idle mode in response to instructions from the network, and can switch to RRC connected mode when needed.

[0227] The advantage of this process is that, by sending data in RRC inactive mode, the terminal in RRC inactive mode can have very short transmission latency and very low signaling overhead. In the above description, the given object can correspond to the following situation: where, if the terminal attempts to send only small amounts of data, the terminal periodically, intermittently, or at long intervals, sends data. Furthermore, a terminal in RRC idle mode 2a-01 can immediately switch to RRC inactive mode 2a-03 via the network, and can switch to RRC connected mode and then switch back to RRC inactive mode (2a-03, 2a-20).

[0228] In the above description, when the terminal switches between modes, additional timers (or inactive timers) can be configured in the terminal to resolve the mismatch between the terminal's mode and the mode recognized by the network. Furthermore, additional timers can be driven in the base station.

[0229] Figure 2B illustrates the process of a terminal switching from RRC connection mode to RRC idle mode and the process of a terminal switching from RRC idle mode to RRC connection mode in this disclosure.

[0230] In Figure 2B, if a terminal that transmits and receives data in RRC connection mode does not perform data transmission and reception for a given reason or at a given time, the base station can send an RRCConnectionRelease message to the terminal, causing the terminal to switch to RRC idle mode (2b-01). Subsequently, if a terminal that has not yet established a connection (hereinafter referred to as an idle mode UE) has data to transmit, the terminal performs an RRC connection setup procedure with the base station. The terminal establishes reverse transmission synchronization with the base station through a random access procedure and sends an RRCConnectionRequest message to the base station (2b-05). This message contains the terminal's ID and the establishment cause.

[0231] The base station sends an RRCConnectionSetup message to the terminal to establish an RRC connection (2b-10). This message contains RRC connection setup information. The RRC connection, also known as the Signaling Radio Bearer (SRB), is used to send and receive RRC messages, i.e., control messages between the terminal and the base station. The terminal that has established an RRC connection sends an RRCConnectionSetupComplete message to the base station (2b-15). This message includes a control message called a Service Request (SERVICEREQUEST), which requests bearer setup for a given service from the MME. The base station sends the SERVICE REQUEST message included in the RRCConnectionSetupComplete message to the MME (2b-20). The MME determines whether to provide the service requested by the terminal. As a result of this determination, if the MME has determined to provide the service requested by the terminal, the MME sends a message called Initial Context Setup Request (INITIAL CONTEXT SETUPREQUEST) to the base station (2b-25). This message includes information such as Quality of Service (QoS) information to be applied when configuring the Data Radio Bearer (DRB) and security-related information to be applied to the DRB (e.g., security keys, security algorithms). The base station exchanges SecurityModeCommand messages 2b-30 and SecurityModeComplete messages 2b-35 to establish security with the terminal.

[0232] When security settings are complete, the base station sends an RRCConnectionReconfiguration message to the terminal (2b-40). This message includes configuration information for the DRB, which will handle user data. The terminal configures the DRB by applying this information and sends an RRCConnectionReconfigurationComplete message to the base station (2b-45). The base station, having completed DRB configuration with the terminal, sends an INITIAL CONTEXT SETUP COMPLETE message to the MME (2b-50). Upon receiving this message, the MME exchanges an S1 BEARER SETUP message and an S1 BEARER SETUP RESPONSE message to establish an S1 bearer with the S-GW (2b-055, 2b-60). The S1 bearer is a connection established between the S-GW and the base station for data transmission and corresponds to a DRB on a one-to-one basis. When this process is complete, the terminal sends data to and receives data from the base station via the S-GW (2b-65, 2b-70). As mentioned above, the common data transmission process is basically configured through the following three steps: RRC connection setup, security configuration, and DRB setup. In addition, the base station can send an RRCConnectionReconfiguration message to provide new configurations in the terminal or to add or change configurations for a given reason (2b-75).

[0233] In bearer settings, a bearer can mean both SRB and DRB. SRB refers to a signaling radio bearer that transmits control messages (RRC messages), while DRB refers to a data radio bearer that transmits data. Furthermore, UM DRB means a DRB used by an RLC layer device operating in Unacknowledged (UM) mode. AM DRB means a DRB used by an RLC layer device operating in Acknowledged (AM) mode.

[0234] As mentioned above, switching from RRC idle mode to RRC connected mode requires numerous signaling procedures. Therefore, in next-generation mobile communication systems, a new RRC inactive mode can be defined. In this new mode, the terminal and base station can store the terminal's context and maintain the S1 bearer if needed. Thus, faster access to the terminal and base station can be achieved with fewer signaling procedures.

[0235] Figure 2C shows a diagram of the terminal mode switching indication method for the network proposed in this disclosure.

[0236] Specifically, this disclosure proposes different indicators for network definition and use of RRCConnectionRelease messages, and changes the mode of different terminals (e.g., NB-IoT terminals or general terminals) to RRC idle mode or RRC suspended mode (or suspended state / mode) or RRC inactive mode, as well as the corresponding protocol layer data processing methods.

[0237] The terminal described in Figure 2C can refer to several wireless devices, such as NB-IoT terminals, general-purpose terminals, or MTC terminals.

[0238] In Figure 2C, the base station can change the RRC connection mode of terminal 2c-01 to RRC mode by sending an RRC message 2c-05 for a given reason. In the above description, the given reason may be due to the scheduling of effective transmission resources for the network, or it may correspond to a situation where downlink or uplink data toward the terminal has not yet been generated or is expected to not be generated for a period of time (a while).

[0239] In the above description, the base station (network) can define and use a release cause to instruct the terminal to switch to RRC idle mode or RRC suspended mode (or suspended state / mode) or RRC inactive mode.

[0240] Specifically, if the connection release reason indicates another reason, it can instruct the terminal to switch to RRC idle mode. In the above description, if the connection release reason is RRC connection suspension (rrc-Suspend), it can instruct the terminal to switch to RRC suspended mode or RRC inactive mode. Furthermore, the base station can define and use configuration information (rrc-InactiveConfig) for RRC inactive mode.

[0241] When the terminal receives the RRCConnectionRelease message, if the release cause is RRC connection suspension (rrc-Suspend) and there is no configuration information for RRC inactive mode (rrc-InactiveConfig), the terminal can switch to RRC suspension mode and perform the corresponding operation of the protocol layer device.

[0242] However, when the terminal receives the RRCConnectionRelease message, if the release cause is RRC connection suspension (rrc-Suspend) and includes configuration information for RRC inactive mode (rrc-InactiveConfig), the terminal switches to RRC inactive mode and performs the corresponding operation of the protocol layer device.

[0243] As described above, in this disclosure, based on the connection release cause (releaseCause) included in the RRCConnectionRelease message and the configuration information for RRC inactive mode (rrc-InactiveConfig), the network can change the terminal's mode to RRC idle mode or RRC suspended mode (or suspended state / mode) or RRC inactive mode.

[0244] This disclosure discloses efficient operation of the terminal's protocol layer apparatus when the terminal switches its RRC mode based on the connection release cause (releaseCause) included in the RRCConnectionRelease message 2c-05 and configuration information for the RRC inactive mode (rrc-InactiveConfig).

[0245] When the RRCConnectionRelease message is received, if the release cause is RRC connection suspended (rrc-Suspend) and includes configuration information for RRC inactive mode (rrc-InactiveConfig), the terminal performs the following operations and switches to RRC inactive mode.

[0246] As another method, if the RRCConnectionRelease message includes configuration information for RRC inactive mode (rrc-InactiveConfig), the terminal performs the following actions and switches to RRC inactive mode. That is, even if the connection release cause is not RRC connection suspension (rrc-Suspend), if configuration information for RRC inactive mode (rrc-InactiveConfig) is included, the terminal can perform the following procedures.

[0247] As another method, when the terminal receives an instruction from the base station to switch to RRC inactive mode, it can perform the following procedure.

[0248] - It can store connection recovery identifiers (full connection recovery identifier (full I-Radio Network Temporary Identifier (RNTI)) or short connection recovery identifiers (short I-RNTI), values ​​for delivering security keys (NextchiningCount (NCC)) or periodic values ​​for RAN paging calculations.

[0249] - The MAC layer device can be reset to prevent unnecessary HARQ retransmission of data stored in the MAC layer device's buffer (MAC reset). As described above, the process of resetting the MAC layer device may include the following procedures: discarding stored data (MAC SDU or MAC PDU), flushing and resetting the HARQ buffer, resetting the HARQ processor identifier or associated timer, or resetting the logical channel identifier.

[0250] When the terminal subsequently re-establishes a connection with the network, it can receive RRCResume messages and send RRCResumeComplete messages via SRB1. Therefore, if data exists stored in the RLC layer device, to prevent unnecessary retransmissions and for buffer management efficiency, the terminal can discard the stored data (e.g., RLC SDU, RLC SDU fragments, or RLC PDU) and reset the RLC window state parameters (e.g., transmit window parameters or receive window parameters), and can perform an RLC layer device re-establishment (RLC re-establishment) procedure on SRB1. Furthermore, if data exists stored in the RLC layer device for other SRBs and DRBs, to prevent unnecessary retransmissions and for buffer management efficiency, the terminal can discard the stored data (e.g., RLC SDU, RLC SDU fragments, or RLCPDU), and can perform an RLC layer device re-establishment procedure on other SRBs and DRBs, thereby resetting the RLC window state parameters (e.g., transmit window parameters or receive window parameters). In the above description, when attempting to reconnect to the network, after the terminal receives the RRCResume message, the RLC layer device re-establishment procedure that is performed on other SRBs and DRBs can be executed. However, to maximize the efficiency of buffer management, when the RRCResume message is received, the RLC layer device re-establishment procedure can be executed on other SRBs and DRBs (i.e., the network can determine the RLC re-establishment procedure indication for each bearer through an indicator).

[0251] - The terminal can store the current terminal context. The terminal context may include RRC configuration information, security settings information, ROHC context of PDCP layer devices, configuration information of SDAP layer devices, cell identifier (C-RNTI), etc.

[0252] - When the process is complete, bearers other than SRB0 (SRB or DRB) can be suspended, because SRB0 is a bearer that always needs to send messages during random access without requiring a security procedure.

[0253] - In the above description, because data processing has been suspended by suspending the bearer, data discarding and parameter setting of the PDCP layer device can be performed. Therefore, the terminal instructs or triggers a PDCP layer device reset procedure or suspension procedure (PDCP reset or PDCP suspension) for the DRB. The PDCP layer device reset procedure or suspension procedure can be applied to the UM DRB. Although the reset procedure or suspension procedure is applied to the UM DRB, the terminal can perform procedures such as parameter reset and data discarding in the same manner in advance. Therefore, the reset procedure or suspension procedure can be extended and applied to the UM DRB (or SRB).

[0254] *In the above description, the PDCP layer device reset or suspension process (PDCP reset or PDCP suspension) can be materialized as follows, and some or all of the following processes can be executed.

[0255] The terminal can reset the COUNT value used in the security key and reset the transmit window state parameter (TX_NEXT) to its initial value, enabling parameter synchronization with the base station to be performed during subsequent reconnection to the network.

[0256] **In order to discard long data for effective buffer operations, the terminal can discard data (e.g., PDCP PDU) stored in the transmitting PDCP layer device.

[0257] **If data with an assigned COUNT value (e.g., PDCP SDU) is stored in the transmitting PDCP layer device (i.e., if the data has not been discarded because the PDCP data discard timer has not expired or a PDCP status report has not been received), the terminal can treat the stored data (e.g., PDCP SDU) as newly received data from a higher layer and can sequentially reassign COUNT values ​​in ascending order, starting from the aforementioned reset COUNT value (e.g., from 0). (E.g., using the TX_NEXT value, i.e., the transmission status parameter) (the reason being that if data encrypted based on a previously assigned COUNT value is transmitted, an error will occur in the receiving stage). As described above, the terminal can receive an RRCResume message and execute the proposed procedure. However, to restore the RRC connection, the terminal can perform an RRC connection restoration procedure, receive an RRCResume message from the base station, and execute the proposed procedure simultaneously with the PDCP re-establishment procedure. However, as proposed in this disclosure, if the procedure for reassigning a reset COUNT value is executed upon receiving an RRCResume message, there is an advantage that the above procedure can be performed in advance before connection restoration.** When a terminal receives an RRRCResume message and executes the PDCP re-establishment procedure, it can send and retransmit newly allocated data based on the reset COUNT value. This procedure can be applied to the terminal's UM DRB or AM DRB. Furthermore, during this procedure, if a PDCP drop timer for the transmitting PDCP layer device has already been set in each data segment, the PDCP drop timer is not suspended or reset. When the substantially driven PDCP drop timer expires, the corresponding data can be discarded. Therefore, unnecessary transmissions can be prevented by discarding data based on the valid time period of each data segment.

[0258] As another method, to prevent wasted transmission resources and unnecessary retransmissions, if data with assigned COUNT values ​​(e.g., PDCP SDUs) is stored in the transmitting PDCP layer device (and has not been discarded due to the PDCP data discard timer not yet expiring or the PDCP status report not yet being received), the terminal can treat only the data (e.g., PDCP SDUs) that has not yet been acknowledged as successfully delivered from the lower layer device (RLC ACK) as newly received data from the higher layer. The terminal can then sequentially reassign COUNT values ​​in ascending order, starting from the reset COUNT value (e.g., from 0) (e.g., using the TX_NEXT value, i.e., the transmission status parameter). (The reason is that if data encrypted based on previously assigned COUNT values ​​is transmitted, an error will occur at the receiving stage). As described above, the terminal can receive an RRCResume message and execute the proposed procedure. However, to restore the RRC connection, the terminal can execute the RRC connection restoration procedure, receive an RRCResume message from the base station, and execute the proposed procedure simultaneously with the PDCP re-establishment procedure. However, as proposed in this disclosure, if the process of reassigning and resetting the COUNT value is performed upon receiving the RRRCRelease message, there is an advantage that the above process can be performed in advance before the connection is restored. When the terminal receives the RRRCResume message and performs the PDCP re-establishment process, the data newly assigned based on the reset COUNT value can be sent and retransmitted. This process can be applied to the terminal's UM DRB or AM DRB. Furthermore, in this process, if a PDCP discard timer for the PDCP layer device has already been set in each data, the PDCP discard timer is not suspended or reset. When the substantially driven PDCP discard timer expires, the corresponding data can be discarded. Therefore, unnecessary transmissions can be prevented by discarding data based on the valid period of each data.

[0259] As another method, to prevent wasted transmission resources and unnecessary retransmissions, if data (e.g., PDCP SDUs) with assigned COUNT values ​​is stored in the transmitting PDCP layer device (and the data has not been discarded because the PDCP data discard timer has not expired or a PDCP status report has not been received), the terminal can treat data (e.g., PDCP SDUs) that have not yet been acknowledged as successfully delivered (RLC ACK) from the lower layer device and have a COUNT value or PDCP sequence number equal to or greater than the first data (e.g., data with the smallest COUNT value, or data with the smallest PDCP sequence number) as newly received data from the higher layer. The terminal can then reassign COUNT values ​​sequentially in ascending order, starting from resetting the COUNT value (e.g., from 0), using the TX_NEXT value, i.e., the transmission status parameter (because an error occurs at the receiving level if data encrypted based on a previously assigned COUNT value is transmitted). As described above, the terminal can receive an RRCrease message and execute the proposed procedure. However, to restore the RRC connection, the terminal can perform an RRC connection restoration procedure, receive an RRCResume message from the base station, and perform the proposed procedure simultaneously with the PDCP re-establishment procedure. However, as proposed in this disclosure, if the procedure for re-allocating the COUNT value is performed upon receiving the RRCResume message, there is an advantage that the procedure can be performed in advance before connection restoration. When the terminal receives the RRCResume message and performs the PDCP re-establishment procedure, the newly allocated data based on the reset COUNT value can be sent and retransmitted. This procedure can be applied to the terminal's UM DRB or AMDRB. Furthermore, in this procedure, if a PDCP discard timer for the PDCP layer device has been set in each data segment, the PDCP discard timer is not suspended or reset. When the substantially driven PDCP discard timer expires, the corresponding data can be discarded. Therefore, unnecessary transmissions can be prevented by discarding data based on the valid time period of each data segment.

[0260] As another method, to prevent wasted transmission resources and unnecessary retransmissions, if data with assigned COUNT values ​​(e.g., PDCP SDUs) is stored in the transmitting PDCP layer device (and has not been discarded due to the PDCP data discard timer not yet expiring or the PDCP status report not yet being received), the terminal can treat data (e.g., PDCP SDUs) that has not yet been delivered from the lower-layer device as newly received data from the higher-layer device, and can reassign COUNT values ​​sequentially in ascending order from the time the COUNT value is reset (e.g., from 0) (e.g., using the TX_NEXT value, i.e., the transmission status parameter) (the reason being that if data encrypted based on previously assigned COUNT values ​​is transmitted, an error will occur in the receiving stage). As described above, the terminal can receive the RRCResume message and execute the proposed procedure. However, to restore the RRC connection, the terminal can execute the RRC connection restoration procedure, receive the RRCResume message from the base station, and execute the proposed procedure simultaneously with the PDCP re-establishment procedure. However, as proposed in this disclosure, if the process of reassigning a reset COUNT value is performed upon receiving an RRRCRelease message, there is an advantage that the above process can be performed in advance before the connection is restored. When the terminal receives the RRRCResume message and performs the PDCP re-establishment process, the data newly assigned based on the reset COUNT value can be sent and retransmitted. This process can be applied to the terminal's UMDRB or AM DRB. Furthermore, in this process, if a PDCP discard timer for the PDCP layer device has already been set in each data, the PDCP discard timer is not suspended or reset. When the substantially driven PDCP discard timer expires, the corresponding data can be discarded. Therefore, unnecessary transmissions can be prevented by discarding data based on the valid period of each data.

[0261] **As another method, to prevent waste of transmission resources and unnecessary retransmission of AM DRB, if data (e.g., PDCP SDU) with an assigned COUNT value is stored in the transmitting PDCP layer device (if the data has not been discarded because the PDCP data discard timer has not expired or a PDCP status report has not been received), the terminal can treat only the data (e.g., PDCP SDU) that has not yet been acknowledged as successfully delivered from the lower layer device (RLC ACK) as newly received data from the higher layer, and can reassign COUNT values ​​in ascending order starting from the reset COUNT value (e.g., starting from 0) (e.g., using the TX_NEXT value, i.e., the transmission status parameter) (the reason being that if data encrypted based on the previously assigned COUNT value is transmitted, an error will occur in the receiving stage). Furthermore, to prevent wasted transmission resources and unnecessary retransmission of UM DRBs, if data with assigned COUNT values ​​(e.g., PDCP SDUs) is stored in the transmitting PDCP layer device (and has not been discarded due to the PDCP data discard timer not yet expiring or the PDCP status report not yet being received), the terminal can treat only the data (e.g., PDCP SDUs) that has not yet been delivered from the lower-layer device as newly received data from the higher-layer device, and can reassign COUNT values ​​in ascending order starting from the reset COUNT value (e.g., starting from 0) (e.g., using the TX_NEXT value, i.e., the transmission status parameter) (the reason being that if data encrypted based on the previously assigned COUNT value is transmitted, an error will occur in the receiving stage). As described above, the terminal can receive the RRC Resume message and execute the proposed procedure. However, to restore the RRC connection, the terminal can execute the RRC connection restoration procedure, receive the RRC Resume message from the base station, and execute the proposed procedure simultaneously with the PDCP re-establishment procedure. However, as proposed in this disclosure, if the process of reassigning a reset COUNT value is performed upon receiving an RRRCRelease message, there is an advantage that the above process can be performed in advance before the connection is restored. When the terminal receives the RRRCResume message and performs the PDCP re-establishment process, the newly assigned data based on the reset COUNT value can be sent and retransmitted. This process can be applied to the terminal's UM DRB or AM DRB. Furthermore, in this process, if a PDCP discard timer for the PDCP layer device has already been set in each data, the PDCP discard timer is not suspended or reset. When the substantially driven PDCP discard timer expires, the corresponding data can be discarded. Therefore, unnecessary transmissions can be prevented by discarding data based on the valid period of each data.

[0262] As another method, to prevent waste of transmission resources and unnecessary retransmission of AM DRB, if data (e.g., PDCP SDU) with an assigned COUNT value is stored in the transmitting PDCP layer device (if the data has not been discarded because the PDCP data discard timer has not expired or a PDCP status report has not been received), the terminal can treat data (e.g., PDCP SDU) that has not been acknowledged as successfully delivered (RLC ACK) from the lower layer device and has a COUNT value or PDCP sequence number equal to or greater than the first data (e.g., data with the minimum COUNT value, or data with the minimum PDCP sequence number) as newly received data from the higher layer, and can reassign COUNT values ​​in ascending order starting from the reset COUNT value (e.g., starting from 0) (e.g., using the TX_NEXT value, i.e., the transmission status parameter) (the reason being that if data encrypted based on the previously assigned COUNT value is transmitted, an error occurs in the receiving stage). Furthermore, to prevent wasted transmission resources and unnecessary retransmission of UM DRBs, if data with assigned COUNT values ​​(e.g., PDCP SDUs) is stored in the transmitting PDCP layer device (and has not been discarded due to the PDCP data discard timer not yet expiring or the PDCP status report not yet being received), the terminal can treat only the data (e.g., PDCPSDUs) that has not yet been delivered from the lower-layer device as newly received data from the higher-layer device, and can sequentially reassign COUNT values ​​in ascending order starting from the reset COUNT value (e.g., starting from 0) (e.g., using the TX_NEXT value, i.e., the transmission status parameter) (the reason being that if data encrypted based on the previously assigned COUNT value is transmitted, an error will occur in the receiving stage). As described above, the terminal can receive the RRCResume message and execute the proposed procedure. However, to restore the RRC connection, the terminal can execute the RRC connection restoration procedure, receive the RRCResume message from the base station, and execute the proposed procedure simultaneously with the PDCP re-establishment procedure. However, as proposed in this disclosure, if the process of reassigning a reset COUNT value is performed upon receiving an RRRCRelease message, there is an advantage that the above process can be performed in advance before the connection is restored. When the terminal receives the RRRCResume message and performs the PDCP re-establishment process, the data newly assigned based on the reset COUNT value can be sent and retransmitted. This process can be applied to the terminal's UMDRB or AM DRB. Furthermore, in this process, if a PDCP drop timer for transmitting the PDCP layer device has already been set in each data transmission, the PDCP drop timer is not suspended or reset.When the essentially driven PDCP discard timer expires, the corresponding data can be discarded. Therefore, unnecessary transmissions can be prevented by discarding data based on the valid period of each data item.

[0263] Regarding the receiving PDCP layer device, in order to quickly deliver stored data (e.g., PDCP SDU or PDCP PDU) to the higher-layer device when the PDCP reordering timer is operating, the terminal can suspend and reset the receiving PDCP layer device if the PDCP reordering timer is operating. If the stored data has been header compressed, the terminal can release the header compression and deliver the data to the higher layer in ascending order of the COUNT value.

[0264] The terminal can reset the COUNT value used in the security key and reset the receive window state parameters (e.g., RX_NEXT and RX_DELIV) to their initial values, so that the parameters can be synchronized with the base station when performing subsequent reconnection with the network.

[0265] **If the receiving PDCP layer device receives data from the lower layer device (RLC layer device) through the RLC re-establishment process, the terminal can also decode the received data, perform integrity verification if necessary, release header compression if necessary, suspend and reset the PDCP reordering timer, align the data together with the data to be sent to the higher layer in ascending order of the COUNT value, and send it (this is useful if connected to EN-DC (LTE base station and NR base station) or if an NR PDCP layer device is used in the LTE base station, i.e., when the NR PDCP layer device is connected to the LTE RLC layer device and the LTE RLC layer device is re-established).

[0266] - When the process is complete, the terminal can report to the higher-level device (NAS layer device) that the RRC connection has been suspended and can switch to RRC inactive mode.

[0267] When a terminal receives an RRCConnectionRelease message (2c-05), if the connection release reason indicates another reason or the connection release reason in the message is not RRC connection suspend (rrc-Suspend), the terminal may perform the following operations and switch to RRC idle mode.

[0268] -Terminal reset MAC layer device.

[0269] - The terminal releases all radio transmission resources, releases MAC-related configuration information, releases RLC layer devices, releases PDCP layer devices, and releases bearer connections.

[0270] - In addition, the terminal indicates to the higher-level device (NAS) that the RRC connection has been released and that it has switched to RRC idle mode.

[0271] When the terminal receives the RRCConnectionRelease message (2c-05), if the release cause is RRC connection suspension (rrc-Suspend) and there is no configuration information for RRC inactive mode (rrc-InactiveConfig), the terminal performs the following operations and switches to RRC suspension mode.

[0272] -Terminal reset MAC layer device.

[0273] - The terminal re-establishes the RLC layer device regarding SRB and DRB.

[0274] - The terminal stores the terminal context (e.g., RRC configuration information, security settings information, ROHC context, C-RNTI, or the cell identifier or physical cell identifier of the source cell).

[0275] - The terminal stores the connection recovery identifier (resumeIdentity) or NCC (nextHopChainingCount) or ROHC context continue use indicator (drb-ContinueROHC) stored in the RRCConnectionRelease message.

[0276] - The terminal suspends SRBs and DRBs other than SRB0.

[0277] - The terminal suspends the RRC connection and reports the suspension to the higher-level device.

[0278] -Terminal suspension is for the integrity protection or encryption of lower-level devices.

[0279] In the above description, a terminal that has switched to RRC mode can perform a connection restoration with the network (RRC connection restoration procedure) for a given reason. In the above description, a given reason can correspond to the terminal receiving a paging message (2c-15) or generating uplink data in the terminal. To perform connection restoration with the network for this reason, the terminal can perform some or all of the following actions (actions related to the transmission of the RRC ResumeRequest message) before, during, or after the terminal sends the RRC Resume Request message 2c-20.

[0280] - The terminal places the stored connection recovery identifier (full connection recovery identifier (full I-RNTI) or short connection recovery identifier (short I-RNTI)) in the RRCResumeRequest message, sets the connection recovery (resumeCause) reason, and exports and places the connection recovery MAC-I based on the currently set security key.

[0281] - The terminal restores the RRC configuration and security settings information from the stored terminal context, derives a new security key based on the value used to derive the security key (NextchiningCount(NCC)), and applies the new security key to integrity protection and encryption algorithms for bearers other than SRB0 (other SRBs and DRBs).

[0282] - The terminal restores the PDCP configuration information (e.g., ROHC context) of the PDCP layer device, sends an RRRCResumeRequest message via SRB0, and receives its response message (RRCResume) via SRB1. In order to perform integrity checks or decryption procedures, the terminal can perform a PDCP re-establishment procedure on SRB1, so that the derived new security key can be applied.

[0283] - When the security key is updated according to the PDCP re-establishment procedure for SRB1, the terminal restarts (restores) SRB1 (i.e., resumes).

[0284] In the above description, the terminal may send an RRC recovery request message 2c-20. In response, the base station may send an RRC recovery message or an RRCResume message 2c-30 with an rrc-suspend indicator to the terminal. In this disclosure, when the base station sends the RRCResume message 2c-30, it may generate and update a security key based on the NCC delivered to the terminal via RRC message 2c-05 to enhance security, perform an encryption process on the RRC message 2c-30, perform an integrity protection process, and send an RRCResume message.

[0285] When the terminal receives RRCResume message 2c-30 from the base station, the terminal may perform some or all of the following procedures (UE's RRCResume reception).

[0286] When a terminal receives an RRCresume message, it can restore the PDCP state of SRB2 or all DRBs. In the above description, the PDCP state may include context or security key information for the Header Compression Protocol (ROHC). Furthermore, when a terminal sends an RRCresumeRequest message, in order to apply the newly derived key to encryption and integrity protection algorithms, the terminal can perform a PDCP re-establishment process on SRB2 or all DRBs.

[0287] - The terminal discards the connection recovery identifier or the stored terminal context, except for the RAN notification area information, because the terminal has already received a response indicating that the terminal can connect to the network via the RRCResume message.

[0288] - The terminal resumes or restarts SRB2 or all DRBs. In the above description, the term "resume" can mean that the terminal resumes data processing and transmission or reception. In the above description, the term "suspend" can mean that the terminal suspends data processing and transmission or reception.

[0289] - The terminal enters RRC connection mode and can indicate to higher-level devices that the suspended RRC connection has been restored.

[0290] The terminal terminates the connection recovery process by sending an RRRCResumeComplete message to the base station.

[0291] As described above, when the terminal receives the RRC Resume message 2c-30, it switches to RRC connection mode, sends the RRC Resume Complete message 2c-40 to the base station indicating that the RRC connection setup is complete, and resumes data transmission and data reception from the base station.

[0292] Figure 2D illustrates the terminal operation proposed in this disclosure.

[0293] When RRC connection mode terminal 2d-01 receives an RRCConnectionRelease message (2d-05) from the network, the terminal performs different processes and switches to different RRC modes based on the connection release reason included in the message and whether the message already includes configuration information for RRC inactive mode.

[0294] When the terminal receives the RRCConnectionRelease message, if the release cause is RRC connection suspension (rrc-Suspend) (2d-10) and the message includes configuration information for RRC inactive mode (rrc-InactiveConfig) (2d-15), the terminal performs the following operations and switches to RRC inactive mode (2d-20).

[0295] - The terminal can store connection recovery identifiers (full connection recovery identifier (full I-RNTI) or short connection recovery identifier (short I-RNTI)) to derive the value of the security key or cycle value (NextchiningCount(NCC)) calculated for RAN paging.

[0296] - The terminal can reset the MAC layer device (MAC reset) to prevent unnecessary HARQ retransmission of data stored in the buffer of the MAC layer device. In the above description, the process of resetting the MAC layer device may include the following procedures: discarding the stored data (e.g., MAC SDU or MAC PDU), flushing and resetting the HARQ buffer, and resetting the HARQ processor identifier or the associated timer or logical channel identifier.

[0297] When the terminal subsequently re-establishes a connection with the network, it can receive an RRCResume message and send an RRCResumeComplete message via SRB1. If the terminal has data stored in the RLC layer device, to prevent unnecessary retransmissions and for buffer management efficiency, the terminal can discard the stored data (e.g., RLCSDU, RLC SDU fragments, or RLC PDUs) and perform an RLC layer device re-establishment procedure on SRB1, resetting the RLC window state parameters (e.g., transmit window parameters or receive window parameters). Furthermore, if the terminal has data about other SRBs and DRBs stored in the RLC layer device, to prevent unnecessary retransmissions and for buffer management efficiency, the terminal can discard the stored data (e.g., RLC SDU, RLC SDU fragments, or RLC PDUs) and perform an RLC layer device re-establishment (RLC re-establishment) procedure on the other SRBs and DRBs, resetting the RLC window state parameters (e.g., transmit window parameters or receive window parameters). In the above description, when the terminal subsequently attempts to reconnect to the network, after the terminal receives the RRCResume message, the RLC layer device re-establishment procedure performed on other SRBs and DRBs can be executed. However, to maximize the efficiency of buffer management, when the RRCResume message is received, the terminal can execute the RLC layer device re-establishment procedure on other SRBs and DRBs (the network can determine the RLC re-establishment procedure indication for each bearer through an indicator).

[0298] - The terminal can store the current terminal context. The terminal context may include RRC configuration information, security settings information, ROHC context of PDCP layer devices, configuration information of SDAP layer devices, cell identifier (C-RNTI), etc.

[0299] - When the process is complete, the terminal can suspend bearers other than SRB0 (e.g., SRB or DRB), because SRB0 should be a bearer that always sends messages during the random access process without requiring a security procedure.

[0300] - In the above description, because data processing has been suspended by suspending the bearer, the terminal can perform data discarding and parameter reset of the PDCP layer device. Therefore, the terminal instructs or triggers a PDCP layer device reset procedure or suspension procedure (PDCP reset or PDCP suspension) for the PDCP layer device of the DRB. The PDCP layer device reset procedure or suspension procedure can be applied to the AM DRB. Because although the PDCP layer device reset procedure or suspension procedure is applied to the UM DRB, the terminal can perform procedures such as parameter reset and data discarding in the same way in advance, so the terminal can extend and apply the PDCP layer device reset procedure or suspension procedure to the UM DRB (or SRB).

[0301] *In the above description, the PDCP layer device reset process or suspension process (PDCP reset or PDCP suspension) can be represented as follows, and some or all of the following processes can be executed.

[0302] The terminal can reset the COUNT value used in the security key and reset the transmit window state parameter (TX_NEXT) to its initial value, enabling parameter synchronization with the base station to be performed during subsequent reconnection to the network.

[0303] **In order to discard long data for effective buffer operations, the terminal can discard data (e.g., PDCP PDU) stored in the transmitting PDCP layer device.

[0304] To quickly deliver stored data (e.g., PDCP SDU or PDCP PDU) to higher-layer devices during PDCP reordering timer operation, the terminal can suspend and reset the receiving PDCP layer device if the PDCP reordering timer is active. If the stored data has been header compressed, the terminal can release the header compression and deliver the data to the higher layer in ascending order of the COUNT value.

[0305] The terminal can reset the COUNT value used in the security key and reset the receive window state parameters (e.g., RX_NEXT and RX_DELIV) to their initial values, so that the parameters can be synchronized with the base station when performing subsequent reconnection with the network.

[0306] **If the receiving PDCP layer device receives data from the lower layer device (RLC layer device) through the RLC re-establishment process, the terminal can also decode the received data, perform integrity verification if necessary, release header compression if necessary, suspend and reset the PDCP reordering timer, align the data together with the data to be sent to the higher layer in ascending order of the COUNT value, and send them (this is useful if connected to EN-DC (LTE base station and NR base station) or if an NR PDCP layer device is used in the LTE base station, i.e., when the NR PDCP layer device is connected to the LTE RLC layer device and the LTE RLC layer device is re-established).

[0307] - When the process is complete, the terminal can report to the higher-level device (NAS layer device) that the RRC connection has been suspended and can switch to RRC inactive mode.

[0308] When a terminal receives an RRCConnectionRelease message (2d-05), if the connection release reason indicates another reason (2d-01) or the connection release reason in the message is not RRC connection suspension (rrc-Suspend), the terminal may perform the following operations and switch to RRC idle mode (2d-30).

[0309] -Terminal reset MAC layer device.

[0310] - The terminal releases all radio transmission resources, releases MAC-related configuration information, releases RLC layer devices, releases PDCP layer devices, and releases bearer connections.

[0311] - In addition, the terminal indicates to the higher-level device (NAS) that the RRC connection has been released and that it has switched to RRC idle mode.

[0312] When the terminal receives the RRCConnectionRelease message (2c-05), if the release cause is RRC connection suspension (rrc-Suspend) (2d-10) and there is no configuration information for RRC inactive mode (rrc-InactiveConfig) (2d-15), the terminal performs the following operations and switches to RRC suspension mode (2d-25).

[0313] -Terminal reset MAC layer device.

[0314] - The terminal re-establishes the RLC layer device regarding SRB and DRB.

[0315] - The terminal stores the terminal context (e.g., RRC configuration information, security settings information, ROHC context, C-RNTI, or the cell identifier or physical cell identifier of the source cell).

[0316] - The terminal stores the connection recovery identifier (resumeIdentity), NCC (nextHopChainingCount), or ROHC context continue use indicator (drb-ContinueROHC) in the RRCConnectionRelease message.

[0317] - The terminal suspends SRBs and DRBs other than SRB0.

[0318] - The terminal suspends the RRC connection and reports the suspension to the higher-level device.

[0319] -Terminal suspension is for the integrity protection or encryption of lower-level devices.

[0320] Figure 2E illustrates the configuration of a terminal to which embodiments of the present disclosure can be applied.

[0321] Referring to Figure 2E, the terminal includes a radio frequency (RF) processor 2e-10, a baseband processor 2e-20, a storage unit 2e-30, and a controller 2e-40.

[0322] RF processor 2e-10 performs functions for transmitting / receiving signals via a radio channel, such as signal band conversion and amplification. Specifically, RF processor 2e-10 up-converts baseband signals received from baseband processor 2e-20 to RF band signals, transmits RF band signals via antennas, and down-converts RF band signals received via antennas back to baseband signals. For example, RF processor 2e-10 may include transmit filters, receive filters, amplifiers, mixers, oscillators, digital-to-analog converters (DACs), and analog-to-digital converters (ADCs). In Figure 2E, only one antenna is shown, but the UE may include multiple antennas. Furthermore, RF processor 2e-10 may include multiple RF chains. Additionally, RF processor 2e-10 can perform beamforming. For beamforming, RF processor 2e-10 can adjust the phase and magnitude of each signal transmitted / received via multiple antennas or antenna elements. Furthermore, the RF processor can perform MIMO. When performing MIMO operation, the RF processor can receive multiple layers. The RF processor 2e-10 can appropriately configure multiple antennas or antenna elements under the control of the controller, and can perform receive beam scanning (swip) or adjust the direction and beamwidth of the receive beam so that the receive beam cooperates with the transmit beam.

[0323] The baseband processor 2e-20 performs baseband signal and bitstream conversion functions based on the system's physical layer standard. For example, when transmitting data, the baseband processor 2e-20 generates complex symbols by encoding and modulating the transmitted bitstream. Furthermore, when receiving data, the baseband processor 2e-20 reconstructs the received bitstream based on the baseband signal received from the RF processor 2e-10 by demodulating and decoding. For example, if an Orthogonal Frequency Division Multiplexing (OFDM) scheme is applied, when transmitting data, the baseband processor 2e-20 generates complex symbols by encoding and modulating the transmitted bitstream, maps the complex symbols to subcarriers, and then configures the OFDM symbols through inverse Fast Fourier Transform (IFFT) operations and cyclic prefix (CP) insertion. In addition, when data is received, the baseband processor 2e-20 segments the baseband signal received from the RF processor 2e-10 in units of OFDM symbols, reconstructs the signal mapped to the subcarrier through a Fast Fourier Transform (FFT) operation, and reconstructs the received bitstream through demodulation and decoding.

[0324] As described above, the baseband processor 2e-20 and the RF processor 2e-10 transmit and receive signals. Therefore, the baseband processor 2e-20 and the RF processor 2e-10 can be referred to as transmitters, receivers, transceivers, or communication units. Furthermore, at least one of the baseband processor 2e-20 and the RF processor 2e-10 may include multiple communication modules to support various radio access technologies. Additionally, at least one of the baseband processor 2e-20 and the RF processor 2e-10 may include different communication modules to process signals in different frequency bands. For example, different radio access technologies may include LTE networks and NR networks. Furthermore, different frequency bands may include ultra-high frequency (SHF) bands (e.g., 2.5 GHz, 5 GHz) and millimeter wave (e.g., 60 GHz) bands.

[0325] Storage unit 2e-30 stores data such as basic programs, application programs, and configuration information for UE operation. Storage unit 2e-30 provides the stored data in response to requests from controller 2e-40.

[0326] Controller 2e-40 controls the overall operation of the UE. For example, controller 2e-40 transmits / receives signals via baseband processor 2e-20 and RF processor 2e-10. Furthermore, controller 2e-40 writes data to and reads data from storage unit 2e-40. For this purpose, controller 2e-40 may include at least one processor. For example, controller 2e-40 may include a communication processor (CP) that performs control for communication and an application processor (AP) that controls higher-level processes such as applications. Additionally, controller 2e-40 may include a multi-connectivity processor 2e-42 configured to perform processing for operation in multi-connectivity mode.

[0327] Figure 2F shows a block diagram of a TRP in a wireless communication system to which embodiments of the present disclosure may be applied.

[0328] As shown in Figure 2F, the base station is configured to include an RF processor 2f-10, a baseband processor 2f-20, a backhaul communication unit 2f-30, a storage unit 2f-40, and a controller 2f-50.

[0329] RF processor 2f-10 performs functions for transmitting / receiving signals over a radio channel, such as signal band conversion and amplification. Specifically, RF processor 2f-10 up-converts baseband signals received from baseband processor 2f-20 to RF band signals, transmits RF band signals through an antenna, and down-converts RF band signals received through an antenna back to baseband signals. For example, RF processor 2f-10 may include transmit filters, receive filters, amplifiers, mixers, oscillators, DACs, and ADCs. Only one antenna is shown in Figure 2F, but the first access node may include multiple antennas. Furthermore, RF processor 2f-10 may include multiple RF chains. Additionally, RF processor 2f-10 can perform beamforming. For beamforming, RF processor 2f-10 can adjust the phase and magnitude of each signal transmitted / received through multiple antennas or antenna elements. The RF processor can perform downlink MIMO operation by transmitting one or more layers.

[0330] The baseband processor 2f-20 performs baseband signal and bitstream conversion functions based on the physical layer standard of the first radio access technology. For example, when transmitting data, the baseband processor 2f-20 generates complex symbols by encoding and modulating the transmitted bitstream. Furthermore, when receiving data, the baseband processor 2f-20 reconstructs the received bitstream based on the baseband signal received from the RF processor 2f-10 by demodulation and decoding. For example, if an OFDM scheme is applied, when transmitting data, the baseband processor 2f-20 generates complex symbols by encoding and modulating the transmitted bitstream, maps the complex symbols to subcarriers, and configures the OFDM symbols through IFFT operations and CP insertion. Furthermore, when receiving data, the baseband processor 2f-20 segments the baseband signal received from the RF processor 2f-10 in units of OFDM symbols, reconstructs the signal mapped to the subcarriers through FFT operations, and then reconstructs the received bitstream through demodulation and decoding. As described above, the baseband processor 2f-20 and the RF processor 2f-10 transmit and receive signals. Therefore, the baseband processor 2f-20 and the RF processor 2f-10 can be referred to as a transmitter, a receiver, a transceiver, a backhaul communication unit, or a wireless backhaul communication unit.

[0331] The backhaul communication unit 2f-30 provides an interface for communicating with other nodes within the network.

[0332] Storage unit 2f-40 stores data such as basic procedures, application programs, and configuration information for base station operation. Specifically, storage unit 2f-40 can store information about bearers assigned to accessing UEs and measurement results reported by the accessing UEs. Furthermore, storage unit 2f-40 can store information, i.e., criteria for determining whether to provide multiple connections to the UE. Additionally, storage unit 2f-40 provides the stored data in response to requests from controller 2f-50.

[0333] Controller 2f-50 controls the overall operation of the main base station. For example, controller 2f-50 transmits / receives signals via baseband processor 2f-20 and RF processor 2f-10 or via backhaul communication unit 2f-30. Furthermore, controller 2f-50 writes data to storage unit 2f-40 and reads data from storage unit 2f-40. For this purpose, controller 2f-50 may include at least one processor. Additionally, controller 2f-50 may include a multi-connectivity processor 2f-52, which is configured to perform processing for operation in multi-connectivity mode.

[0334] <Third Embodiment>

[0335] This disclosure presents a process for a terminal to compress data and for a base station to decompress data when transmitting data on the uplink in a wireless communication system. It also provides a detailed header format and supporting methods for the data transmission and reception process (such as solutions for decompression failures), wherein the transmitting stage compresses and transmits the data, and the receiving stage decompresses the data. Furthermore, the method proposed in this disclosure can also be applied to the process for a base station to compress and transmit downlink data when sending data to a terminal, and for the terminal to receive and decompress the compressed downlink data. As described above, this disclosure can have the following effects: by compressing and transmitting data by the transmitting stage, more data can be transmitted and coverage can be improved.

[0336] Figure 3A illustrates the process by which the base station is configured to perform uplink data compression when a terminal establishes a connection with the network, as proposed in this disclosure.

[0337] Figure 3A illustrates the process for a terminal to switch from RRC idle mode or RRC inactive mode (lightly connected mode) to RRC connected mode and establish a connection with the network, and shows the process for configuring whether to perform uplink data compression (UDC).

[0338] In Figure 3A, if a terminal sending and receiving data in RRC connection mode has no data to send or receive for a given reason or at a given time, the base station can instruct the terminal to switch to RRC idle mode by sending an RRCConnectionRelease message (3a-01). Subsequently, if a terminal that has not yet established a connection (hereinafter referred to as an idle mode UE) has data to send, the terminal performs an RRC connection establishment procedure with the base station. The terminal establishes reverse transmission synchronization with the base station through a random access procedure and sends an RRCConnectionRequest message (3a-05) to the base station. This message contains the terminal's ID and the establishment cause.

[0339] The base station sends an RRCConnectionSetup message to enable the terminal to establish an RRC connection (3a-10). This message may include information indicating whether an uplink data compression (UDC) method is used for each logical channel (logicalchannelconfig), or for each bearer, or for each PDCP device (PDCP-config). Furthermore, more specifically, the base station may indicate which IP flow or QoS flow in each logical channel, or bearer, or PDCP device (or SDAP device) uses the UDC method (i.e., by configuring information in the SDAP device regarding whether the IP flow or QoS flow will use the UDC method, the base station may instruct each QoS flow whether the SDAP device will use the UDC method for the PDCP device, or the PDCP device may autonomously identify each QoS flow and determine whether to apply the uplink compression method). Additionally, in the above description, if the base station indicates that the UDC method should be used, it may indicate the ID of a predefined library or dictionary to be used in the UDC method or the buffer size used in the UDC method.

[0340] Furthermore, this message may include commands for establishing or releasing uplink decompression to enable uplink decompression. Additionally, when the base station configures the UDC method as described above, it can always use the RLC AM bearer (which does not have a data loss mode because it includes ARQ or retransmission functionality) to configure the UDC method, and may not configure the UDC method along with the Header Compression Protocol (ROHC). Furthermore, this message contains RRC connection setup information. The RRC connection is also known as the Signaling Radio Bearer (SRB) and is also used to send and receive RRC messages, i.e., control messages between the terminal and the base station.

[0341] The terminal that has established an RRC connection sends an RRCConnectionSetupComplete message to the base station (3a-15). If the base station is unaware of the UE capabilities of the terminal with which it has now established a connection, or wants to check the UE capabilities of the terminal, it can send a message to inquire about the UE capabilities. Additionally, the terminal can send a message reporting its capabilities. This message can indicate whether the terminal can use uplink data compression (UDC). The base station can send a message including an indicator for whether the terminal can use uplink data compression (UDC). The RRCConnectionSetupComplete message includes a control message called a SERVICE REQUEST, through which the terminal requests bearer settings for a given service from the MME. The base station sends the SERVICE REQUEST message included in the RRCConnectionSetupComplete message to the MME (3a-20). The MME determines whether to provide the service requested by the terminal. As a result of this determination, if the MME has determined to provide the service requested by the terminal, the MME sends a message called an INITIALCONTEXT SETUP REQUEST to the base station (3a-25). This message includes information such as Quality of Service (QoS) information to be applied when configuring the Data Radio Bearer (DRB) and security-related information to be applied to the DRB (e.g., security keys, security algorithms). The base station exchanges SecurityModeCommand messages 3a-30 and SecurityModeComplete messages 3a-35 to establish security with the terminal.

[0342] When security settings are complete, the base station sends an RRCConnectionReconfiguration message to the terminal (3a-40). This message may include information indicating whether an uplink data compression (UDC) method is used for each logical channel (logicalchannelconfig), or for each bearer, or for each PDCP device (PDCP-config). More specifically, the base station may indicate which IP flow or QoS flow in each logical channel, or bearer, or PDCP device (or SDAP device) uses the UDC method (i.e., by configuring information in the SDAP device regarding whether the IP flow or QoS flow will use the UDC method, the base station may instruct each QoS flow whether the SDAP device will use the UDC method for the PDCP device, or the PDCP device may autonomously identify each QoS flow and determine whether to apply the uplink compression method). Furthermore, in the above description, if the base station indicates that the UDC method should be used, it may indicate the ID of a predefined library or dictionary to be used in the UDC method or the buffer size used in the UDC method. Additionally, the message may include commands for establishing or releasing uplink decompression to enable uplink decompression execution. Furthermore, when configuring the UDC method at the base station as described above, it can always use the RLC AM bearer (which does not have a data loss mode because it includes ARQ or retransmission functionality) to configure the UDC method, and it can also configure the UDC method without header compression protocol (ROHC). Additionally, this message includes configuration information for the DRB that will handle user data. The terminal configures the DRB by applying this information and sends an RRCConnectionReconfigurationComplete message to the base station (3a-45). The base station, having completed the DRB establishment with the terminal, sends an Initial Context Setup Complete message to the MME (3a-50). Upon receiving this message, the MME exchanges an S1 Bearer Setup message and an S1 Bearer Setup Response message to establish an S1 bearer with the S-GW (3a-55, 3a-60). The S1 bearer is used to establish a data transmission connection between the S-GW and the base station, and corresponds to a DRB on a one-to-one basis. When this process is complete, the terminal sends data to and receives data from the base station via the S-GW (3a-65, 3a-70).

[0343] As described above, the general data transmission process is basically configured through the following three steps: RRC connection establishment, security settings, and DRB settings. Furthermore, the base station can send an RRCConnectionReconfiguration message to the terminal to provide new configurations or add or change configurations for a given reason (3a-75). This message may include information indicating whether an uplink data compression (UDC) method is used for each logical channel (logicalchannel configuration), or for each bearer, or for each PDCP device (PDCP-config). More specifically, the base station can indicate which IP flow or QoS flow in each logical channel, or bearer, or PDCP device (or SDAP device) uses the UDC method (i.e., by configuring information in the SDAP device regarding whether the IP flow or QoS flow will use the UDC method, the base station can instruct each QoS flow whether the SDAP device will use the UDC method for the PDCP device, or the PDCP device can autonomously identify each QoS flow and determine whether to apply the uplink compression method). Furthermore, in the above description, if the base station indicates that the UDC method should be used, it may indicate the ID of a predefined library or dictionary to be used in the UDC method, or the size of the buffer to be used in the UDC method. Additionally, the message may include commands for establishing or releasing uplink decompression to enable uplink decompression. Furthermore, when the base station configures the UDC method as described above, it may always use an RLC AM bearer (which does not have a data loss mode because it includes ARQ or retransmission functionality) to configure the UDC method, and may not configure the UDC method along with the Header Compression Protocol (ROHC).

[0344] Figure 3B illustrates the process of performing uplink data compression and data configuration as proposed in this disclosure.

[0345] In Figure 3B, uplink data 3b-05 can be generated as data corresponding to services such as video transmission, photo transmission, web search, and VoLTE. Data generated from the application layer device is processed via TCP / IP or UDP, corresponding to the network data transmission layer, and can be delivered to the PDCP layer after configuring headers 3b-10 and 3b-15. When receiving data from higher layers (e.g., PDCP SDUs), the PDCP layer can perform the following procedures.

[0346] In Figure 3A, if the uplink data compression (UDC) method has been configured for use in the PDCP layer via RRC messages such as 3a-10, 3a-40, or 3a-75, the PDCP layer can compress uplink data by performing the UDC method on PDCP SDUs (e.g., 3b-20), configure the corresponding UDC header 3b-25 (the header for compressed uplink data), perform encryption on the compressed data excluding the UDC header, perform integrity protection if it has been established, and configure the PDCP PDU by configuring the PDCP header 3b-30. In the above description, the PDCP layer apparatus includes a UDC / decompression device that determines whether to perform the UDC procedure for each piece of data as configured in the RRC message, and uses the UDC / decompression device. At the transmitting stage, the transmitting PDCP layer apparatus uses the UDC device to perform data compression. At the receiving stage, the receiving PDCP layer apparatus uses the UDC decompression device to perform data decompression.

[0347] Besides the case where the terminal performs uplink data compression, the process in Figure 3B can also be applied to downlink data compression. Furthermore, the description of uplink data can be applied in the same way to downlink data.

[0348] Figure 3C illustrates an embodiment of the UDC method that can be applied in this disclosure.

[0349] Figure 3C illustrates the DEFLATE-based uplink data compression algorithm. The DEFLATE-based uplink data compression algorithm is a lossless compression algorithm. It compresses uplink data by essentially combining the LZ77 algorithm and Huffman coding. The LZ77 algorithm performs a search for redundant data arrays, using a sliding window to search within the window. If a redundant array exists, the LZ77 algorithm performs data compression by representing the location of the redundant array within the sliding window and expressing the degree of redundancy as a length. The sliding window, also called a buffer in the uplink data compression (UDC) method, can be set to 8 kilobytes or 32 kilobytes. That is, the sliding window or buffer can hold 8192 or 32768 characters, search for redundant arrays, represent the redundant arrays using position and length, and perform compression. Therefore, the LZ77 algorithm is a sliding window method. That is, the LZ77 algorithm uses previously encoded data to update the buffer and directly encodes the next data, thus making consecutive data correlated. Therefore, the next data can only be decoded normally if the previously encoded data has been decoded normally. In the above description, the code represented as position and length and compressed by the LZ77 algorithm (i.e., expressions such as position and length) is further compressed by Huffman coding. When searching for redundant code again, Huffman coding performs compression again by using short tokens for codes with high redundancy and long tokens for codes with low redundancy. Huffman coding is a prefix code and is the best encoding method in which all codes are uniquely decodable.

[0350] As described above, the transmitting stage can perform encoding (3c-10) by applying the LZ77 algorithm to the original data 3c-05, update the buffer (3c-15), and configure checksum bits for the contents (or data) of the buffer in the UDC header by generating checksum bits. The checksum bits are used to determine the validity of the buffer state in the receiving stage. The transmitting stage can again compress the code encoded using the LZ77 algorithm using Huffman coding and can transmit the compressed code as uplink data (3c-25). In contrast to the transmitting stage, the receiving stage performs decompression on the received compressed data. That is, the receiving stage performs Huffman decoding (3c-30), updates the buffer (3c-35), and checks the validity of the updated buffer using the checksum bits in the UDC header. If the checksum bits are determined to be error-free, the receiving stage can decompress the data by performing decoding using the LZ77 algorithm (3c-40), restore the original data, and deliver the data to higher layers (3c-45).

[0351] As described above, the LZ77 algorithm is a sliding window method. That is, the LZ77 algorithm uses previously encoded data to update the buffer and directly encodes the next data, thus consecutive data are correlated. Therefore, the next data can only be decoded normally when the previously encoded data has been decoded normally. Therefore, the receiving PDCP layer device checks the PDCP sequence number in the PDCP header, checks the UDC header (checking the indicator indicating whether data compression has been performed), and performs data decompression on the data that has already undergone data compression in ascending order of the PDCP sequence number.

[0352] The process for configuring uplink data compression (UDC) in a terminal for a base station and the process for executing UDC in a terminal, as presented in this disclosure, are as follows.

[0353] The base station can configure the terminal to perform uplink data compression in a bearer or logical channel where RLC AM mode has been set using RRC messages such as 3a-10, 3a-40, or 3a-75 in Figure 3A, or it can release the terminal. Furthermore, the base station can use RRC messages to reset the UDC device (or protocol) of the terminal's PDCP layer apparatus. In the above description, resetting the UDC device (or protocol) means resetting the UDC buffer used for uplink data compression of the terminal, and it is for the purpose of synchronizing the terminal's UDC buffer with the UDC buffer used for uplink data decompression of the base station. In the operation of resetting the buffer of the UDC device, a new PDCP control PDU can be defined, or a new PDCP control PDU can be defined by modifying an existing PDCP control PDU. The new PDCP control PDU can be used by the transmitting level (base station) to reset the UDC buffer of the receiving level (terminal) instead of using RRC messages; and it can be used for synchronization of user data compression and decompression between the transmitting and receiving levels. Furthermore, the base station can use RRC messages to configure whether to perform uplink data compression for each bearer, or for each logical channel, or for each PDCP layer device. More specifically, the base station can configure whether to perform uplink data decompression for each IP flow (or QoS flow) in a bearer, logical channel, or PDCP layer device.

[0354] In addition, the base station can use RRC messages to set PDCP drop timer values ​​in the terminal. The base station can set PDCP drop timer values ​​separately for data to which uplink data compression has not been performed and for data to which uplink data compression has been performed.

[0355] If, via an RRC message, the terminal has been configured to perform uplink data compression on a given bearer or logical channel or PDCP layer device (or certain QoS flows of a given bearer or logical channel or PDCP layer device), the terminal resets the buffer in the UDC device of the PDCP layer device based on the configuration and prepares for the uplink data compression process. Furthermore, when receiving data (e.g., PDCP SDU) from a higher layer, if the terminal has been configured to perform uplink data compression on the PDCP layer device, it performs uplink data compression on the received data. If the terminal has been configured to perform uplink data compression only on a given QoS flow of the PDCP layer device, the terminal determines whether to perform uplink data compression by checking the indication or QoS flow identifier of a higher SDAP layer, and then performs uplink data compression.

[0356] If the terminal has already performed uplink data compression (UDC) and updated the buffer based on the data compression, the terminal configures the UDC buffer. In the above description, if UDC is performed, the terminal can compress PDCP SDUs received from higher layers into UDC data (or UDC blocks) with a smaller size. Furthermore, the terminal configures a UDC header for the compressed UDC data. The UDC header may include an indicator of whether uplink data compression has been performed (e.g., in the UDC header, a 1-bit indicator of 0 indicates that UDC has been applied, while a 1-bit indicator of 1 indicates that UDC has not been applied, and vice versa). In the above description, cases where the terminal does not apply uplink data compression may include the following: in this case, because the PDCP SDU data structure received from higher layers does not have a repetitive data structure, the UDC method (DEFLATE algorithm) cannot be used to perform data compression. In the above description, if uplink data compression (UDC) has been performed on the data received from the higher layer (e.g., PDCP SDU) and the UDC buffer has been updated, the terminal can calculate checksum bits to confirm the validity of the updated UDC buffer in the receiver-level PDCP layer device, and can include checksum bits (checksum bits have a given length and can be configured to, for example, 4 bits) in the UDC buffer.

[0357] In the above description, if the terminal has been configured to encrypt data that has been applied or has not yet been applied to the uplink data decompression, the terminal performs integrity protection and delivers the data to the lower layer.

[0358] Figure 3D illustrates a problem in which decompression failure occurs in the uplink data compression method described in this disclosure.

[0359] As described with reference to Figure 3C, the algorithm (i.e., the DEFLATE algorithm for performing uplink data compression (UDC) after performing LZ77 algorithm and Huffman coding) is as follows: During data compression at the transmitting stage, the buffer is updated using previously compressed data; based on the buffer, the compressed data is compared with the data to be compressed subsequently; a repeating structure is searched; and compression is performed based on position and length. Therefore, the receiving stage can successfully perform decompression only if it performs decompression in the sequence ordered by the transmitting stage. For example, if the transmitting stage has already performed UDC on data with PDCP sequence numbers 1, 3, 4, and 5, and has not yet performed UDC on data with PDCP sequence number 2 (3d-05), then the receiving stage can successfully perform decompression only if the received data is decompressed in the order of PDCP sequence numbers 1, 3, 4, and 5 in the PDCP layer device. In the above description, if the transmitting stage has already performed UDC, the receiving stage can determine whether UDC has been applied by checking the UDC header, as this is indicated in the UDC header. During the process of performing a series of UDC decompressions, if PDCP sequence number 3 (3d-15) is lost, all subsequent UDC decompressions will fail. That is, UDC decompression (3d-10) cannot be performed on data with PDCP sequence numbers 4 and 5. Therefore, lost data (or packets) should not occur during uplink decompression, and the receiving stage needs to perform decompression according to the sequence in which the transmitting stage performed UDC on the data. Therefore, the operation needs to be performed in lossless RLC AM mode with retransmission capability.

[0360] However, data loss may occur due to the PDCP discard timer in the PDCP layer device. Specifically, the PDCP layer device drives a timer based on the PDCP discard timer value set via RRC messages for each data (or packet or PDCP SDU) received from a higher layer. Furthermore, when the timer expires, the PDCP layer device discards the data corresponding to that timer. Therefore, when the timer for data to which UDC has already been performed expires, that data may be discarded. Consequently, UDC decompression failure may occur at the receive stage for data to which UDC has already been performed.

[0361] As described with reference to Figure 3C of this disclosure, according to the algorithm used to perform uplink data compression (UDC) (i.e., the DEFLATE algorithm (which performs Huffman coding after performing the LZ77 algorithm)), when the transmitting stage performs UDC, it generates a checksum using the current buffer contents after performing UDC and configures the checksum in the UDC buffer. Furthermore, the algorithm described above involves updating the buffer using the original data for which compression has already been performed, comparing the data with the data to be compressed subsequently, searching for repeating structures, and performing compression based on position and length. In the above description, the checksum bits in the UDC header are used by the UDC device (or function) of the receiving stage PDCP layer apparatus to determine the validity of the current buffer state before performing data decompression. That is, before performing data decompression, the receiving stage checks the validity of the current receiving stage UDC buffer based on the checksum bits in the UDC header. If no checksum error exists, the receiving stage performs data decompression. If a checksum failure occurs, the receiving stage should not perform data decompression and reports the checksum failure to the transmitting stage for recovery.

[0362] The receiver can successfully decompress data only if it performs decompression in the sequence that the transmitter has already compressed. For example, if the transmitter has performed UDC on data with PDCP sequence numbers 1, 3, 4, and 5, and has not yet performed UDC on data with PDCP sequence number 2, the receiver can successfully decompress the received data only if it performs decompression in the PDCP layer device in the order of PDCP sequence numbers 1, 3, 4, and 5. In the above description, if the transmitter has already performed UDC, the receiver can determine whether UDC has been applied by checking the UDC header, as this is indicated in the UDC header. During the execution of a series of UDC decompressions, if a checksum failure occurs at PDCP sequence number 3, all subsequent UDC decompressions may fail. That is, the receiver cannot successfully perform UDC decompression on data with PDCP sequence numbers 4 and 5.

[0363] In the following, this disclosure proposes a method for handling checksum failures to solve the above-mentioned checksum failure problem.

[0364] Figure 3E illustrates the PDCP control PDU format that can be applied in the verification and failure handling method of this disclosure.

[0365] In Figure 3E, the D / C field identifies whether the data is general data or PDCP layer control information (or PDCP control PDU) within the PDCP layer. The PDU type field indicates which piece of PDCP layer control information the data corresponds to. Furthermore, a 1-bit indicator (FE field) indicating whether a checksum failure occurred can be defined and used in the PDCP control PDU format for feedback in the checksum failure handling method proposed in this disclosure, such as 3e-01. When the 1-bit indicator value is 0, it indicates that UDC decompression performed normally. When the 1-bit indicator value is 1, it indicates that a checksum failure occurred during UDC decompression and may indicate that the UDC buffer of the transmitting PDCP layer device should be reset.

[0366] To define format 3e-01, the transmitting and receiving stages can define new PDCP control PDUs by assigning PDU types to reserved values ​​(e.g., a given reserved value between 011 or 100-111), such that PDCP control PDUs with defined PDU types can act as feedback mechanisms to perform functions indicating checksum failures. For example, methods such as those in Table 1 can be considered to define the following PDU types.

[0367] [Table 1]

[0368] Bit Description 000 PDCP Status Report 001 Scattered ROHC Feedback Packet 010 LWA Status Report 011 UDC Checksum Failure Feedback 100-111 Reserved surface

[0369] In this disclosure, the following are embodiments of the verification and failure handling method for the PDCP control PDU proposed in Figure 3E.

[0370] If the receiver (base station) identifies a checksum failure in the receive UDC buffer used for releasing data for uplink data compression (UDC), the receiver indicates the checksum failure by sending a PDCP control PDU to the terminal. A new PDCP control PDU can be defined and used as the PDCP control PDU, or a new indicator can be defined and included in an existing PDCP control PDU, and an existing PDCP control PDU can be modified and used as the PDCP control PDU. Alternatively, instead of a PDCP sequence number, the receiver can define an indicator that indicates the UDC buffer should be reset due to a checksum failure and can also indicate this indicator.

[0371] - Receiver-level operation: The receiver-level resets the receiver-level UDC buffer and discards data whose indicators, indicating a UDC checksum failure, have been reset, are not included in the UDC header of newly received data, and for which UDC has already been performed. The receiver-level can process and deliver this data to higher-layer devices: data whose indicators, indicating a UDC checksum failure, have been reset, are not included in the UDC header of newly received data, and for which UDC has not been performed in ascending order of PDCP sequence numbers, provided that all data has been received in PDCP sequence number order without gaps. Furthermore, the receiver-level can restart decompression from data whose UDC header includes the indicator that the transmitter-level UDC buffer has been reset due to a UDC checksum failure, in ascending order of PDCP sequence numbers.

[0372] - Transmitter-level operations: When the transmitter (terminal) receives a PDCP control PDU, it resets the UDC transmit buffer. Before resetting the UDC transmit buffer, the UDC procedure is performed. The transmitter discards any data generated that has not yet been transmitted (e.g., PDCP PDUs) (if any). The transmitter can perform uplink data compression (UDC) on data that has not yet been retransmitted, update the UDC buffer, encrypt the data portion of the UDC header (excluding the UDC header itself) containing checksum bits, generate a PDCP header, configure a PDC PDU, and deliver a PDCP PDU to the lower layer. Furthermore, the transmitting level can deliver a newly configured PDCP PDU's UDC header or PDCP header (including an indicator indicating that the transmitting level buffer has been reset), and can reassign PDCP sequence numbers to data that has not yet been transmitted in ascending order (in this case, the rule of performing encryption and transmission once based on a PDCP COUNT value can be followed, because if data that has already been encrypted and transmitted once using a PDCP sequence number or HFN or COUNT value and security key is encrypted and retransmitted using the same PDCP COUNT value and security key, the risk of hacking is high). Alternatively, when receiving an indication that a checksum failure has occurred, the transmitting level can reset the transmitting UDC buffer, and can only perform new UDC and deliver the data to the lower layer if the data's PDCP sequence number is greater than or equal to the PDCP sequence number of data that has not yet been delivered from the transmitting level to the lower layer or only has a newly configured PDC PDU. In addition, the transmitting stage can deliver a UDC header or PDCP header of a newly configured PDCP PDU, including an indicator that the transmitting stage UDC buffer has been reset (or an indicator that the receiving stage UDC buffer should be reset) (i.e., it can follow the rule of performing encryption and transmission once according to a PDCP COUNT value, because if data that has been encrypted and transmitted once using the PDCP sequence number or HFN or COUNT value and security key is encrypted and retransmitted using the same PDCP COUNT value and security key, the risk of being cracked is high).

[0373] However, the aforementioned checksum failure may occur due to the PDCP discard timer in the PDCP layer device. Specifically, the PDCP layer device drives the timer for each piece of data (e.g., packets or PDCP SDUs) received from the higher layer based on the PDCP discard timer value set via RRC messages. Furthermore, when the timer expires, the PDCP layer device discards the data corresponding to the timer. Therefore, when the timer for data to which UDC has already been performed expires, some of the UDC data may be discarded. Consequently, UDC decompression failure may occur in subsequent data to which UDC has been performed in the receiver stage.

[0374] This disclosure presents an embodiment (3-1) in which data that has been subjected to UDC is discarded based on a PDCP discard timer in the transmitting PDCP layer device, thereby preventing data loss and reducing data with checksum failures in the receiving stage.

[0375] - Transmitter-level operation: If an uplink data compression process has been configured in the transmitting PDCP layer device, and if the transmitting level discards data that has not yet been transmitted due to the PDCP discard timer expiring and for which UDC has been applied, the transmitting level can transmit data corresponding to the next PDCP sequence number of the discarded data. It can discard all remaining data (i.e., PDCP sequence numbers with a higher next PDCP sequence number than the discarded data, and data for which user data compression has been applied and has been stored but not transmitted). If data has already been delivered to the lower layer device, it can send an indicator indicating that the data should be discarded to the lower layer device. The transmitting level can suspend data transmission until it receives a PDCP control PDU indicating that a checksum failure has occurred in the transmitting PDCP layer device. The reason for this is obvious: because intermediate data or some data of UDC-compressed data has been discarded, user data compression has previously been performed; and in the receiving PDCP layer device, checksum failure may occur in data with a higher PDCP sequence number than the discarded data (e.g., PDCPPDU). Therefore, if the transmitting stage sends data corresponding to the next PDCP sequence number of the discarded data, the receiving PDCP layer device can identify the checksum failure and expect to send the PDCP control PDU.

[0376] Therefore, when a PDCP control PDU indicating a checksum failure has occurred is received, or before receiving a PDCP control PDU, the transmitting PDCP layer device resets the transmit buffer used for user data compression (in this case, the transmit UDC buffer will not be reset if it has already been reset). The transmitting level can re-execute the user data compression (UDC) process from data whose PDCP discard timer has not expired and has not yet been transmitted, or whose PDCP discard timer has not expired and has eventually been transmitted (i.e., data transmitted because it corresponds to the next PDCP sequence number of the discarded data); can assign a new PDCP sequence number or a first PDCP sequence number to data that has not yet been transmitted in ascending order; and can prepare data by encrypting and generating data (e.g., PDCP PDU). The transmitting level can resume the transmission of newly generated and prepared data after receiving a PDCP control PDU indicating a checksum failure has occurred in the newly generated and prepared data. That is, the transmitting level can deliver data to the lower layer device.

[0377] Therefore, if a user data compression process has been configured, discarding some of the data previously generated by the PDCP drop timer and for which user data compression has been applied can reduce the likelihood of checksum failures in data with PDCP sequence numbers larger than the discarded data. Furthermore, data loss can be prevented because the data is generated from data that has not yet been sent or that has eventually been sent (i.e., data sent because it corresponds to the next PDCP sequence number of the discarded data).

[0378] If the receiver (base station) detects a checksum failure in the receive UDC buffer used for releasing data for uplink data compression (UDC), it indicates the checksum failure has occurred by sending a PDCP control PDU to the terminal. A new PDCP control PDU can be defined and used as the PDCP control PDU, or a new indicator can be defined and included in an existing PDCP control PDU, and an existing PDCP control PDU can be modified and used as the PDCP control PDU. Alternatively, instead of the PDCP sequence number, the receiver can define an indicator that indicates the UDC buffer should be reset due to a checksum failure, and this indicator can be used to indicate the failure.

[0379] - Receiver-level operation: The receiver-level resets the receiver-level UDC buffer and discards data whose indicators indicating a reset due to a UDC checksum failure have not been included in the UDC header of newly received data and for which UDC has already been performed. The receiver-level can process and deliver this data to higher-level devices: data whose indicators indicating a reset due to a UDC checksum failure have not been included in the UDC header of newly received data, and for which UDC has not been performed in ascending order of PDCP sequence numbers if all data has been received in PDCP sequence number order without gaps. Furthermore, the receiver-level can restart decompression from data whose UDC header includes the indicator indicating a reset due to a UDC checksum failure, in ascending order of PDCP sequence numbers.

[0380] This disclosure presents (3-2) embodiments in which data that has been subjected to UDC is discarded based on a PDCP discard timer in the transmitting PDCP layer device, thereby preventing data loss and reducing data with checksum failures in the receiving stage.

[0381] - Transmitter-level operations: If an uplink data compression process has been configured in the transmitting PDCP layer device, and if data that has not been transmitted due to the PDCP drop timer expiring and for which UDC has been applied is discarded, the transmitting level may discard all data that: has a PDCP sequence number greater than the discarded data; has been subjected to user data compression; has been generated as a PDCP PDU; or has been stored but not transmitted. Furthermore, if the data has been delivered to the lower-layer device, the transmitting level may send an indicator indicating that the data should be discarded to the lower-layer device. Additionally, the transmitting PDCP layer device may reset the buffer used for transmitting user data compression (i.e., the UDC buffer), allocate new PDCP sequence numbers or allocate untransmitted PDCP sequence numbers in ascending order starting from the first untransmitted data, re-perform user data compression, and perform encryption. Furthermore, the transmitting level may define and indicate a new 1-bit indicator to indicate that the buffer used for transmitting user data compression was reset when generating the UDC header, and may instruct the receiving level to reset the buffer used for receiving user data decompression. As another method, using the FR bit, the transmitting stage can indicate that the buffer used for transmitting compressed user data has been reset, and can instruct the receiving stage to reset the buffer used for receiving decompressed user data. That is, the terminal can trigger the process of resetting the transmit and receive UDC buffers.

[0382] The transmitting stage can indicate that the buffer used for transmitting compressed user data has been reset in the UDC header for newly generated and prepared data. On the receiving side, the transmitting PDCP layer device can begin transmission either sequentially or immediately, starting with the data indicating that the buffer used for receiving decompressed user data should be reset, in ascending order of the PDCP sequence numbers. That is, the transmitting stage can deliver data to the lower-layer device.

[0383] In embodiment (3-2), the terminal can autonomously trigger the process of resetting the send and receive UDC buffers using a 1-bit indicator in the UDC header before the checksum fails.

[0384] Therefore, if a user data compression process has been configured, discarding some of the data previously generated by the PDCP drop timer and for which user data compression has been applied can reduce the likelihood of checksum failures in data with PDCP sequence numbers greater than those of the discarded data. Furthermore, data loss can be prevented because data that has not yet been sent can be regenerated.

[0385] - Receiver-level operation: If the transmitter indicates that the buffer used for transmitting user data compression has been reset in the UDC header of the received data, and indicates that the buffer used for receiving user data decompression should be reset on the receiver side, the receiver-level can reset the receiver-level UDC buffer, decode the received data in ascending order of PDCP sequence number, perform and process user data decompression, and deliver the data to higher-level devices.

[0386] Figure 3F illustrates the terminal operation in this disclosure when the transmit-level PDCP layer device drives the PDCP discard timer and data that has not been transmitted due to the expiration of the PDCP discard timer and for which the User Compression Process (UDC) has been applied is discarded.

[0387] In Figure 3F, whenever data is received from a higher-layer device (3f-05), terminal 3f-01 can drive a PDCP drop timer (3f-10) for each received data. If the terminal has been configured to perform uplink data compression (UDC) on data (e.g., PDCP SDU) related to PDCP layer devices, the terminal performs UDC on the received data. Furthermore, the terminal performs UDC, updates the buffer based on the data compression, and configures the transmit UDC buffer. If the terminal performs UDC, it can compress the PDCP SDU received from the higher layer into UDC data (or UDC blocks) with a smaller size (3f-15). Additionally, the terminal configures a UDC header for the compressed UDC data. The UDC header may include an indicator indicating whether UDC has been performed (e.g., in the UDC header, if the 1-bit indicator is 0, then UDC has been applied; and if the 1-bit indicator is 1, then UDC has not been applied).

[0388] In the above description, if the terminal has performed uplink data compression (UDC) on the data received from the higher layer (e.g., PDCP SDU) and updated the UDC buffer, it can calculate checksum bits to identify the validity of the updated UDC buffer and include them in the UDC buffer (the checksum bits have a given length and can be configured to, for example, 4 bits).

[0389] In the above description, if the terminal has been configured with uplink data decompression that has been applied or has not yet been applied, the terminal performs integrity protection, performs encryption, and delivers the data to the lower layer (3f-20).

[0390] If the transmitting PDCP layer device discards data (3f-30) that has been UDC applied but not yet transmitted due to the PDCP discard timer expiring, the terminal can transmit data corresponding to the next PDCP sequence number of the discarded data, discard all remaining data (i.e., PDCP sequence numbers with a higher next PDCP sequence number than the discarded data, data for which UDC has been applied, and data that has been stored but not transmitted), and if data has already been delivered, an indicator indicating that data already delivered to the lower layer device should be discarded can be sent to the lower layer device. The transmitting stage can suspend data transmission until it receives a PDCP control PDU indicating that a checksum failure has occurred. The reason for this is obvious: because intermediate data or some data of UDC compressed data has been discarded, user data compression has previously been performed; and in the receiving PDCP layer device, checksum failure may occur in data with a higher PDCP sequence number than the discarded data (e.g., PDCP PDU). Therefore, if the transmitting stage transmits data corresponding to the next PDCP sequence number of the discarded data, the receiving PDCP layer device can recognize the checksum failure and expect to transmit a PDCP control PDU.

[0391] Therefore, when a PDCP control PDU indicating a checksum failure has been received, or before receiving a PDCP control PDU, the transmitting PDCP layer device resets the transmit buffer used for user data compression (in this case, the transmit UDC buffer will not be reset if it has already been reset). The transmitting level can re-execute the user data compression (UDC) process from data whose PDCP discard timer has not expired and has not yet been transmitted, or whose PDCP discard timer has not expired and has eventually been transmitted (i.e., data transmitted because it corresponds to the next PDCP sequence number of the discarded data); can assign a new PDCP sequence number or a first PDCP sequence number to data that has not yet been transmitted in ascending order; and can prepare data by encrypting and generating data (e.g., PDCP PDU). The transmitting level can resume the transmission of newly generated and prepared data after receiving a PDCP control PDU indicating a checksum failure has occurred in the newly generated and prepared data. That is, the transmitting level can deliver the data to the lower layer device. If the PDCP discard timer has not expired, the transmitting level performs the transmission by delivering the data for which UDC has already been performed to the lower layer device (3f-25).

[0392] Figure 3G illustrates the configuration of a terminal to which embodiments of the present disclosure can be applied.

[0393] Referring to Figure 3G, the terminal includes a radio frequency (RF) processor 3g-10, a baseband processor 3g-20, a storage unit 3g-30, and a controller 3g-40.

[0394] RF processor 3g-10 performs functions for transmitting / receiving signals via a radio channel, such as signal band conversion and amplification. Specifically, RF processor 3g-10 up-converts baseband signals received from baseband processor 3g-20 into RF band signals, transmits RF band signals via an antenna, and down-converts RF band signals received via an antenna back into baseband signals. For example, RF processor 3g-10 may include transmit filters, receive filters, amplifiers, mixers, oscillators, digital-to-analog converters (DACs), and analog-to-digital converters (ADCs). In Figure 3G, only one antenna is shown, but the UE may include multiple antennas. Furthermore, RF processor 3g-10 may include multiple RF chains. Additionally, RF processor 3g-10 can perform beamforming. For beamforming, RF processor 3g-10 can adjust the phase and magnitude of each signal transmitted / received via multiple antennas or antenna elements. Furthermore, the RF processor can perform MIMO. When performing MIMO operation, the RF processor can receive multiple layers. The RF processor 3g-10 can appropriately configure multiple antennas or antenna elements under the control of the controller, and can perform receive beam scanning (swip) or adjust the direction and beamwidth of the receive beam so that the receive beam cooperates with the transmit beam.

[0395] The baseband processor 3g-20 performs baseband signal and bitstream conversion functions based on the system's physical layer standard. For example, when transmitting data, the baseband processor 3g-20 generates complex symbols by encoding and modulating the transmitted bitstream. Furthermore, when receiving data, the baseband processor 3g-20 reconstructs the received bitstream based on the baseband signal received from the RF processor 3g-10 by demodulating and decoding. For example, if an Orthogonal Frequency Division Multiplexing (OFDM) scheme is applied, when transmitting data, the baseband processor 3g-20 generates complex symbols by encoding and modulating the transmitted bitstream, maps the complex symbols to subcarriers, and then configures the OFDM symbols through inverse Fast Fourier Transform (IFFT) operations and cyclic prefix (CP) insertion. In addition, when data is received, the baseband processor 3g-20 segments the baseband signal received from the RF processor 3g-10 in units of OFDM symbols, reconstructs the signal mapped to the subcarrier through Fast Fourier Transform (FFT) operations, and reconstructs the received bitstream through demodulation and decoding.

[0396] As described above, the baseband processor 3g-20 and the RF processor 3g-10 transmit and receive signals. Therefore, the baseband processor 3g-20 and the RF processor 3g-10 can be referred to as transmitters, receivers, transceivers, or communication units. Furthermore, at least one of the baseband processor 3g-20 and the RF processor 3g-10 may include multiple communication modules to support various radio access technologies. Additionally, at least one of the baseband processor 3g-20 and the RF processor 3g-10 may include different communication modules to process signals in different frequency bands. For example, different radio access technologies may include LTE networks and NR networks. Furthermore, different frequency bands may include ultra-high frequency (SHF) bands (e.g., 2.5 GHz, 5 GHz) and millimeter wave (e.g., 60 GHz) bands.

[0397] Storage unit 3g-30 stores data such as basic programs, application programs, and configuration information for UE operation. Storage unit 3g-30 provides the stored data in response to requests from controller 3g-40.

[0398] The controller 3g-40 controls the overall operation of the UE. For example, the controller 3g-40 transmits / receives signals via the baseband processor 3g-20 and the RF processor 3g-10. Furthermore, the controller 3g-40 writes data to and reads data from the storage unit 3g-40. For this purpose, the controller 3g-40 may include at least one processor. For example, the controller 3g-40 may include a communication processor (CP) that performs control for communication, and an application processor (AP) that controls higher-level processes such as applications. Additionally, the controller 3g-40 may include a multi-connectivity processor 3g-42, which is configured to perform processing for operation in multi-connectivity mode.

[0399] Figure 3H shows a block diagram of a TRP in a wireless communication system to which embodiments of the present disclosure may be applied.

[0400] As shown in Figure 3H, the base station is configured to include an RF processor 3f-10, a baseband processor 3f-20, a backhaul communication unit 3f-30, a storage unit 3f-40, and a controller 3f-50.

[0401] RF processor 3h-10 performs functions for transmitting / receiving signals via a radio channel, such as signal band conversion and amplification. Specifically, RF processor 3h-10 up-converts baseband signals received from baseband processor 3h-20 to RF band signals, transmits RF band signals via antennas, and down-converts RF band signals received via antennas back to baseband signals. For example, RF processor 3h-10 may include transmit filters, receive filters, amplifiers, mixers, oscillators, DACs, and ADCs. Only one antenna is shown in Figure 3H, but the first access node may include multiple antennas. Furthermore, RF processor 3h-10 may include multiple RF chains. Additionally, RF processor 3h-10 can perform beamforming. For beamforming, RF processor 3h-10 can adjust the phase and magnitude of each signal transmitted / received via multiple antennas or antenna elements. The RF processor can perform downlink MIMO operation by transmitting one or more layers.

[0402] The baseband processor 3h-20 performs baseband signal and bitstream conversion functions based on the physical layer standard of the first radio access technology. For example, when transmitting data, the baseband processor 3h-20 generates complex symbols by encoding and modulating the transmitted bitstream. Furthermore, when receiving data, the baseband processor 3h-20 reconstructs the received bitstream based on the baseband signal received from the RF processor 3h-10 through demodulation and decoding. For example, if an OFDM scheme is applied, when transmitting data, the baseband processor 3h-20 generates complex symbols by encoding and modulating the transmitted bitstream, maps the complex symbols to subcarriers, and configures the OFDM symbols through IFFT operations and CP insertion. Furthermore, when receiving data, the baseband processor 3h-20 segments the baseband signal received from the RF processor 3h-10 in units of OFDM symbols, reconstructs the signal mapped to the subcarriers through FFT operations, and then reconstructs the received bitstream through demodulation and decoding. As described above, the baseband processor 3h-20 and the RF processor 3h-10 transmit and receive signals. Therefore, the baseband processor 3h-20 and the RF processor 3h-10 can be referred to as a transmitter, a receiver, a transceiver, a backhaul communication unit, or a wireless backhaul communication unit.

[0403] The backhaul communication unit 3h-30 provides an interface for communicating with other nodes within the network.

[0404] Storage unit 3h-40 stores data such as basic procedures, application programs, and configuration information for base station operation. Specifically, storage unit 3h-40 can store information about bearers assigned to accessing UEs and measurement results reported by the accessing UEs. Furthermore, storage unit 3h-40 can store information, i.e., criteria for determining whether to provide multiple connections to the UE. Additionally, storage unit 3h-40 provides the stored data in response to requests from controller 3h-50.

[0405] The controller 3h-50 controls the overall operation of the main base station. For example, the controller 3h-50 transmits / receives signals via the baseband processor 3h-20 and the RF processor 3h-10, or via the backhaul communication unit 3h-30. Furthermore, the controller 3h-50 writes data to and reads data from the storage unit 3h-40. For this purpose, the controller 3h-50 may include at least one processor. Additionally, the controller 3h-50 may include a multi-connectivity processor 3h-52, which is configured to perform processing for operation in multi-connectivity mode.

[0406] In the following, this disclosure proposes a method that effectively performs the user data compression method (or uplink data compression (UDC)) proposed in this disclosure if an SDAP layer device or an SDAP header has been configured.

[0407] This disclosure presents an embodiment (3-3-1) in which the user data compression method is effectively performed if the SDAP layer device or the SDAP header has been configured via an RRC message. In the embodiment (3-3-1), the user data compression method is used to compress the SDAP header and encrypt the UDC header. Therefore, due to this characteristic, the convenience of the implementation can be improved because the same process can be performed on higher-layer data regardless of the presence of the SDAP header; and security can be enhanced by encrypting the UDC header.

[0408] Figure 3I shows a diagram of the (3-3-1) embodiment, in which, in this disclosure, the user data compression method is effectively performed if the SDAP layer device has been configured via RRC messages or the SDAP header has been configured.

[0409] In Figure 3I, if the SDAP layer device has been configured to use or the SDAP header has been configured to use via RRC messages (such as 3a-10, 3a-40, or 3a-75 in Figure 3A), and if User Data Compression (or Uplink Data Compression) (UDC) has been configured, then when receiving data from a higher layer, the SDAP layer device can generate and configure the SDAP header (SH) (e.g., 3i-05) and deliver the SDAP header to the PDCP layer device. The PDCP layer device can perform User Data Compression (3i-07) on the PDCP SDU (i.e., SDAP header and IP packet) 3i-06 received from the higher SDAP layer device. Furthermore, the PDCP layer device can calculate the checksum field, configure whether UDC has been applied, and generate and attach the UDC header (UH) (3i-10). Furthermore, the PDCP layer device can perform encryption on the UDC header and compressed UDC blocks, generate and configure the PDCP header (PH)3i-20, and attach and deliver the PDCP header to the lower layers. Therefore, the RLC layer device and MAC layer device can perform data processing.

[0410] In the process described in Figure 3I, the SDAP header is compressed using a user data compression method, and the UDC header is encrypted. Therefore, due to this characteristic, the same process can be performed on higher-level data regardless of the presence of the SDAP header, thus improving the convenience of the implementation; and by encrypting the UDC header, security is enhanced.

[0411] This disclosure presents an embodiment (3-3-2) in which the user data compression method is effectively performed if the SDAP layer device or the SDAP header has been configured via an RRC message. In the embodiment (3-3-2), the user data compression method is not applied to the SDAP header, the SDAP header is not encrypted, but the UDC header is encrypted. Therefore, there is an advantage that, due to this characteristic, the transmitting or receiving level can use the QoS information of the SDAP header without a decryption process. For example, the base station can use the QoS information for scheduling. Furthermore, even in the terminal implementation, whenever higher-layer data is received, the UDC process and encryption can be performed via a hardware accelerator without generating the SDAP header, and the SDAP header can be appended later. This simplifies the terminal implementation. Furthermore, security is enhanced because the UDC header is encrypted.

[0412] Figure 3J shows a diagram of the (3-3-2) embodiment, in which, in this disclosure, the user data compression method is effectively performed if the SDAP layer device has been configured via RRC messages or the SDAP header has been configured.

[0413] In Figure 3J, if the SDAP layer device has been configured to use or the SDAP header has been configured to use via RRC messages (such as 3a-10, 3a-40, or 3a-75 in Figure 3A), and if User Data Compression (or Uplink Data Compression) (UDC) has been configured, then when data is received from a higher layer, the SDAP layer device can generate and configure the SDAP header (SH) (as in 3j-05) and deliver the SDAP header to the PDCP layer device. The PDCP layer device can perform the User Data Compression (UDC) process (3j-07) on the remaining data portion of the PDCP SDU (i.e., SDAP header and IP packet) 3j-06 received from the higher SDAP layer device, excluding the SDAP header (SH). Furthermore, the PDCP layer device can calculate a checksum field, configure whether UDC has been applied, generate a UDC header (UH), and append the UDC header (UH) before the SDAP header (SH) (3j-10). Furthermore, if integrity protection is already configured, the PDCP layer device can apply integrity protection to the UDC header and compressed UDC block before the encryption process, encrypt the UDC block to encrypt the UDC header and compressed UDC block, and also encrypt the UDC header separately (3j-15, 3j-20). If only the encryption process is to be performed, the SDAP header can be detached midway, and encryption can be performed only once on the UDC header and UDC block. The PDCP layer device can reconfigure the data by inserting an unencrypted SDAP header between the UDC header and UDC block, can generate and configure the PDCP header (PH) 3j-20, can attach it to the data, and can deliver the data to the lower layers. Therefore, the RLC layer device and MAC layer device can perform data processing.

[0414] This disclosure presents an embodiment (3-3-3) in which the user data compression method is effectively performed if the SDAP layer device or the SDAP header has been configured via an RRC message. In the embodiment (3-3-3), the user data compression method is not applied to the SDAP header, the SDAP header is not encrypted, and the UDC header is not encrypted. Due to this characteristic, there are advantages such as the ability of the transmitting or receiving level to use the QoS information of the SDAP header without the need for a decryption process. For example, the base station can use the QoS information for scheduling. Furthermore, even in the terminal implementation, whenever higher-layer data is received, the UDC process can be performed via a hardware accelerator, and encryption can be performed without generating an SDAP header, which can then be appended later. This simplifies the terminal implementation. Furthermore, since the UDC header is not encrypted, the SDAP layer device can continue to perform user data compression and encryption processes on the data received from higher layers via a hardware accelerator. The PDCP header, UDC header, and SDAP header generated after data processing at the PDCP layer device are completed can be appended to the data that has already undergone data processing at its end and can be delivered to the lower layer. Therefore, there is an advantage in simplifying the implementation of the terminal. Furthermore, if the UDC header is not encrypted during this process, the receiver can identify the validity of the UDC buffer content by first reading and calculating the checksum field of the UDC header before performing decryption. Therefore, if a checksum failure occurs, the receiver can immediately discard the corresponding data without performing the decryption process and can perform a checksum failure handling procedure. Thus, the processing burden can be reduced.

[0415] Figure 3K illustrates a diagram of the (3-3-3) embodiment, in which, in this disclosure, the user data compression method is effectively performed if the SDAP layer device has been configured via RRC messages or the SDAP header has been configured.

[0416] In Figure 3K, if the SDAP layer device has been configured to use SDAP layer device functions or SDAP headers via RRC messages (such as 3a-10, 3a-40, or 3a-75 in Figure 3A), and user data compression (or uplink data compression) (UDC) has been configured, then when data is received from a higher layer, the SDAP layer device can generate and configure the SDAP header (SH) (e.g., 3k-05) and deliver the SDAP header to the PDCP layer device. The PDCP layer device can perform user data compression (3k-07) on the remaining data portion of the PDCP SDU (i.e., SDAP header and IP packet) 3k-06 received from the higher SDAP layer device, excluding the SDAP header (SH). Furthermore, if integrity protection has been configured, the PDCP layer device can apply integrity protection to the UDC block and UDC header (UH), SDAP header, and PDCP header compressed by user data compression before the encryption process. Furthermore, in addition to the UDC header and SDAP header, the PDCP layer device can apply encryption (3k-10) only to the UDC block compressed by user data compression. The PDCP layer device can also calculate a checksum field, configure whether UDC has been applied, and generate and attach UDC headers (UH) (3k-15 and 3k-20). After the PDCP header is generated, configured, and attached, the PDCP layer device can deliver the PDCP header to the lower layers. The RLC layer device and MAC layer device can perform data processing. As mentioned above, if the UDC header is not applied to the SDAP header and encryption is not applied to the UDC header, the user data compression process and the encryption or decryption process are simplified in the terminal and base station implementations. Furthermore, because complex processes are avoided, the processing procedures of the implementation can be simplified and the processing burden reduced.

[0417] This disclosure presents an embodiment (3-3-4) in which the user data compression method is effectively performed if the SDAP layer device or the SDAP header has been configured via an RRC message. In the embodiment (3-3-4), the user data compression method may not be applied to the SDAP header, the SDAP header may not be encrypted, the UDC header may be encrypted, the UDC header may be appended after the SDAP header, or the UDC header may be appended just before the compressed UDC block, while the SDAP header may be appended before the UDC header. Due to these characteristics, there are advantages such as the ability of the transmitting or receiving level to use the QoS information of the SDAP header without a decryption process. For example, the base station can use the QoS information for scheduling. Furthermore, even in the terminal implementation, whenever higher-layer data is received, the UDC process can be performed via a hardware accelerator without generating the SDAP header; the UDC can be directly generated and appended, encryption can be performed, and the SDAP header can be appended later. Therefore, the terminal implementation is simplified. Furthermore, security can be enhanced by encrypting the UDC header. Furthermore, in this embodiment, the positions of the SDAP header and the UDC header are shifted. Therefore, there are advantages such as: when performing user data compression, unnecessary processes other than those involving the SDAP header, or those performed after the SDAP header is separated, can be reduced; and a single, unified process can be performed on both the UDC header and the UDC data block.

[0418] Figure 3L shows a diagram of the (3-3-4) embodiment, in which, in this disclosure, the user data compression method is effectively performed if the SDAP layer device has been configured via RRC messages or the SDAP header has been configured.

[0419] In Figure 3L, if the SDAP layer device has been configured to use or the SDAP header has been configured to use via RRC messages (such as 3a-10, 3a-40, or 3a-75 in Figure 3A), and User Data Compression (or Uplink Data Compression) (UDC) has been configured, then when data is received from a higher layer, the SDAP layer device can generate and configure the SDAP header (SH) (as in 3l-05), and can deliver the SDAP header to the PDCP layer device. The PDCP layer device can perform the User Data Compression (UDC) process (3l-07) on the remaining data portion of the PDCP SDU (i.e., SDAP header and IP packet) 3l-06 received from the higher SDAP layer device, excluding the SDAP header. Furthermore, the PDCP layer device can calculate the checksum field, configure whether UDC has been applied, generate the UDC header (UH), and append the UDC header exactly before the compressed UDC data block (or after the SDAP header (SH)) (31-10). Additionally, if integrity protection is configured, the PDCP layer device can apply integrity protection to the SDAP header, UDC header, compressed UDC block, and PDCP header before performing the encryption process, and can perform encryption on the UDC header and compressed UDC block. The PDCP layer device can configure data, generate and configure the PDCP header (PH) (31-20), append the SDAP header first, and append the PDCP header and deliver it to the lower layer. Therefore, the RLC layer device and MAC layer device can perform data processing.

[0420] This disclosure presents an embodiment (3-3-5) in which the user data compression method is effectively performed if the SDAP layer device or the SDAP header has been configured via an RRC message. In the embodiment (3-3-5), the user data compression method may not be applied to the SDAP header, the SDAP header may not be encrypted, the UDC header may not be encrypted, the UDC header may be appended after the SDAP header, or the UDC header may be appended exactly before the compressed UDC block, while the SDAP header may be appended before the UDC header.

[0421] Due to this characteristic, the following advantages exist: the transmitting or receiving level can use the QoS information in the SDAP header without the need for a decryption process. For example, the base station can use the QoS information for scheduling. Furthermore, even in the terminal implementation, whenever higher-layer data is received, the UDC process and encryption can be performed via a hardware accelerator without attaching the SDAP header. The UDC can be generated and attached directly, and the SDAP header can be attached later. This simplifies the terminal implementation. Moreover, in the implementation, the SDAP layer apparatus can perform User Data Compression (UDC) and encryption processes on data received from higher layers via a hardware accelerator, generate the SDAP header, UDC header, and PDCP header in parallel, attach the headers to the data generated as a result of the hardware accelerator all at once, and deliver the data to lower layers. Therefore, the complexity of the terminal implementation can be reduced.

[0422] Furthermore, in this embodiment, the positions of the SDAP header and the UDC header are shifted. Therefore, there are advantages such as: when performing user data compression, unnecessary processes other than those involving the SDAP header, or processes performed after the SDAP header is separated, can be reduced; and a single, unified process can be performed on the UDC header and the UDC data block. Additionally, because the UDC header is not encrypted, the receiver can first identify whether a checksum failure has occurred before performing decryption; and if a checksum failure occurs, the receiver data can be discarded before decryption, and the checksum failure handling process can be performed directly.

[0423] Figure 3M illustrates an embodiment (3-3-5), in which, in this disclosure, the user data compression method is effectively performed if the SDAP layer device has been configured via RRC messages or the SDAP header has been configured.

[0424] In Figure 3M, if the SDAP layer device has been configured to use or the SDAP header has been configured to use via RRC messages (such as 3a-10, 3a-40, or 3a-75 in Figure 3A), and User Data Compression (or Uplink Data Compression) (UDC) has been configured, then when data is received from a higher layer, the SDAP layer device can generate and configure the SDAP header (SH) (e.g., 3m-05) and deliver the SDAP header to the PDCP layer device. The PDCP layer device can perform the User Data Compression (UDC) process (3m-07) on the remaining data portion of the PDCP SDU (i.e., SDAP header and IP packet) 3m-06 received from the higher SDAP layer device, excluding the SDAP header. Furthermore, the PDCP layer device can calculate the checksum field, configure whether UDC has been applied, generate the UDC header (UH), and append the UDC header exactly before the compressed UDC data block (after the SDAP header) (3m-10). Furthermore, if integrity protection is already configured, the PDCP layer device can apply integrity protection to the SDAP header, UDC header, compressed UDC block, and PDCP header before performing the encryption process, and then can perform encryption only on the compressed UDC block except for the SDAP header and UDC header. Additionally, the PDCP layer device can configure data, generate and configure PDCP headers (PH)3m-20, attach the SDAP header first and then the PDCP header, and deliver them to lower layers. Therefore, the RLC layer device and MAC layer device can perform data processing.

[0425] This disclosure presents an embodiment (3-3-6) in which the user data compression method is effectively performed if the SDAP layer device or the SDAP header has been configured via an RRC message. In embodiment (3-3-6), the user data compression method is used to compress the SDAP header, and the UDC header is not encrypted. Due to this characteristic, there is an advantage that the convenience of the implementation can be improved because the same process can be performed on higher-layer data regardless of the presence of the SDAP header. Furthermore, there is an advantage that because the UDC header is not encrypted, the receiver can first identify whether a checksum failure has occurred before performing decryption, and if a checksum failure occurs, the receiver can discard the data and directly perform the checksum failure handling process before performing decryption.

[0426] Figure 3N shows a diagram of the (3-3-6) embodiment, in which, in this disclosure, the user data compression method is effectively performed if the SDAP layer device has been configured via RRC messages or the SDAP header has been configured.

[0427] In Figure 3N, if the SDAP layer device has been configured to use or the SDAP header has been configured to use via RRC messages (such as 3a-10, 3a-40, or 3a-75 in Figure 3A), and User Data Compression (or Uplink Data Compression) (UDC) has been configured, then when data is received from a higher layer, the SDAP layer device can generate and configure the SDAP header (SH) (e.g., 3n-05) and deliver the SDAP header to the PDCP layer device. The PDCP layer device can perform User Data Compression (UDC) (3n-07) on the PDCP SDU (i.e., SDAP header and IP packet) 3n-06 received from the higher SDAP layer device. Furthermore, the PDCP layer device can calculate the checksum field, configure whether UDC has been applied, and generate and attach a UDC header (UH) (3n-10). Furthermore, the PDCP layer device can perform encryption on compressed UDC blocks except for the UDC header, can generate and configure PDCP headers (PH) 3n-20, can attach PDCP headers and UDC headers, and can deliver them to lower layers. Therefore, the RLC layer device and MAC layer device can perform data processing.

[0428] Figure 30 is a diagram illustrating the terminal operation proposed in this disclosure.

[0429] In Figure 30, terminal 3o-01 can be configured to apply user data compression functionality (3o-05) via RRC messages (such as 3a-10, 3a-40, or 3a-75 in Figure 3A). Furthermore, if the SDAP layer device has been configured to use or the SDAP header has been configured to use via RRC messages (3o-10), the terminal can execute embodiments (3-3-1), (3-3-2), (3-3-3), (3-3-4), (3-3-5), or (3-3-6), wherein, in this disclosure, if the SDAP layer device or the SDAP header has been configured, the user data compression method (3o-15) is effectively executed. However, if the SDAP layer device has not been configured to use or the SDAP header has not been configured to use (3o-10) via RRC messages, the terminal can perform a process other than the data processing for the SDAP header in embodiments (3-3-1), (3-3-2), (3-3-3), (3-3-4), (3-3-5), or (3-3-6) without any changes. In the aforementioned data processing, in the disclosure of this disclosure, if the SDAP layer device has been configured or the SDAP header has been configured, the user data compression method is effectively executed.

[0430] This disclosure presents various scenarios that may occur due to the SDAP header generation and encryption process and the uplink data compression process (or uplink data compression) (UDC), as well as methods for implementing these scenarios.

[0431] In the above description, whether to use the SDAP header for each bearer can be configured by the base station via the RRC message described with reference to Figure 3A. As mentioned above, the base station can configure whether UDC has been applied to each bearer via the RRC message.

[0432] This disclosure proposes that when a base station configures whether to use an SDAP header and whether to apply a UDC for each bearer via RRC messages, the SDAP header and UDC cannot be used simultaneously for a single bearer. That is, for a DRB configured with a UDC, the SDAP header cannot be configured; or for a DRB, neither the SDAP header nor the UDC can be configured; or for a DRB, either the SDAP header or the UDC can be configured instead of both. In other words, the base station can prevent the simultaneous configuration of whether to use an SDAP header and whether to apply a UDC for a single bearer via RRC messages. As mentioned above, when performing the UDC process on a bearer that has already been configured with a UDC, the UDC process becomes complex and the implementation complexity increases due to the generation and unencryption of the SDAP header. The UDC is applied to uplink data. Applying the SDAP header to uplink data corresponds to the case of remapping configured between bearers and flows. This situation may not be suitable if a UDC is used. The reason for this is that data compression during the UDC process requires synchronization between the sending and receiving stages, making the remapping between the bearer and the streams on the bearer that have already applied UDC very inefficient.

[0433] Therefore, the aforementioned complex problem would not occur if the use of the SDAP header and the configuration of UDC for a single bearer were not configured simultaneously to address this complexity. Therefore, as another embodiment, this disclosure proposes that the base station disallows the terminal from simultaneously configuring the use of the SDAP header and the configuration of UDC for a single bearer.

[0434] In the above description, when the base station does not configure the use of SDAP headers and UDC configuration for a single bearer in the terminal, the base station can encrypt the UDC header for enhanced security. That is, when receiving higher-layer data, the terminal can use the UDC process to perform data compression and generate a UDC header. Subsequently, the terminal can encrypt the UDC header and compressed UDC data blocks, generate a PDCP header before the encrypted UDC header and UDC data blocks, and concatenate and send them to the lower layers.

[0435] As another method, as described above, when the base station does not configure the use of SDAP headers and UDC configuration simultaneously for a bearer, the terminal can be configured to quickly check the checksum field of the UDC header and quickly determine whether to discard the UDC data, thereby reducing the number of decryption processes. That is, the terminal may not encrypt the UDC header. Specifically, when receiving higher-layer data, the terminal can use the UDC process to perform data compression, encrypt compressed data blocks, generate UDC and PDCP headers, concatenate the UDC and PDCP headers before encrypted UDC data blocks, and deliver them to lower layers. Therefore, the receiving PDCP layer device can identify the UDC header before performing decryption and can identify the validity of the UDC based on the checksum field. If the UDC is invalid, the receiving PDCP layer device can directly discard the received data without performing decryption. The receiving PDCP layer device can perform decryption and user data decompression processes only on data whose validity has been identified based on the checksum field.

[0436] Furthermore, similarly, when configuring integrity protection procedures along with the use of SDAP headers or the application of UDC for a single bearer, complex implementation issues may arise. Therefore, a base station may not allow the simultaneous configuration of SDAP header usage and integrity protection for a single bearer. Additionally, a base station may not allow simultaneous integrity verification and UDC application configuration for a single bearer.

[0437] In the following sections of this disclosure, embodiments of methods for configuring integrity protection in data bearers are described to increase data reliability or maintain security against hacker attacks.

[0438] Figure 3P illustrates a method for configuring integrity protection in data bearers in this disclosure to increase data reliability or maintain security against hacker attacks.

[0439] Terminals can configure integrity protection functions for each bearer via RRC messages (such as 3a-10, 3a-40, or 3a-75 in Figure 3A). They can configure or deconfigure, activate or deactivate integrity protection functions for each data bearer (DRB) or control bearer (SRB), and suspend or resume integrity protection functions for bearers. In the case of handover between base stations or handover within a base station, integrity protection is configured using the reconfigwithSync configuration information of the RRCReconfiguration message.

[0440] Figure 3P illustrates the process of processing data in the terminal's protocol when configuring, activating, or restoring integrity protection for the Data Bearer (DRB) or Control Bearer (SRB).

[0441] If an SDAP layer device or SDAP header (SH) 3p-10 has been configured, when data is received from a higher-layer device, the terminal will attach the SDAP header and deliver the data to the PDCP layer device. When data (e.g., PDCPSDU) is received from a higher layer, because integrity protection has been configured, the PDCP layer device generates a PDCP header (PH), applies the algorithm to the PDCP header 3p-15, the SDAP header, and the data to configure integrity protection, and calculates the MAC-I value 3p-20. The size of the MAC-I value can be a given length, and for example, it can be 4 bytes. When calculating the MAC-I value, the PDCP layer device can append the MAC-I field to the end of the data received from the higher layer, apply the encryption 3p-25 to the data and the MAC-I field except for the PDCP header and SDAP header, and deliver the data to the lower layer for lower-layer data processing.

[0442] Upon receiving data, the receiver performs decryption and integrity verification checks. This involves performing a reverse computation using the MAC-I field value to check for errors in the PDCP header, SDAP header, and data. If integrity verification fails and an error occurs, the receiver can discard the data to prevent erroneous data from being delivered to higher layers and to distinguish data randomly sent by a hacker.

[0443] This disclosure discloses the following operations for each bearer of a terminal when it moves from its current cell to another cell and performs an intra-base station handover or an inter-base station handover, in response to instructions from the network, when integrity protection is suspended, when the integrity protection configuration is released, or when the integrity protection is reconfigured or restored. Reasons for suspending or restoring integrity protection may include changes in service reliability or QoS requirements due to changes in mapping information mapped to QoS flows of the bearer, and may include situations where the signal strength of the target cell to which the handover has been performed is good or poor. In such cases, the processing burden on the terminal can be reduced by changing whether the integrity protection function is configured.

[0444] The terminal can suspend or resume the integrity protection function based on RRC messages such as 3a-10, 3a-40, or 3a-75 in Figure 3A (i.e., reconfigwithSync configuration information based on RRCReconfiguration messages).

[0445] In this disclosure, when the integrity protection function is suspended or resumed based on an RRC message (i.e., the reconfigwithSync configuration information of the RRCReconfiguration message), the first embodiment of the terminal is as follows.

[0446] - If the terminal receives an RRC message and receives an instruction that the terminal should suspend or configure integrity protection features based on the reconfigwithSync configuration information.

[0447] *In the above description, if the bearer indicated to have its integrity protection function suspended is a control bearer (SRB), then as described above in this disclosure, the terminal's PDCP layer device does not calculate the MAC-I value for data received from higher layers, but can perform padding on the MAC-I field; that is, it can insert values ​​all zeros into the MAC-I field, can continuously attach a MAC-I field of a given length (e.g., 4 bytes after the data), and can encrypt and transmit the data. The reason the terminal's PDCP layer device continues to attach the MAC-I field even though integrity protection for the control bearer has been suspended is to facilitate the terminal's transmission and reception processing for the control bearer by unifying the data format of the PDCP layer device for the control bearer to a single format. That is, in this case, although integrity protection is restored, the terminal's PDCP layer device can continue to use the same process to generate data without changing the format.

[0448] *In the above description, if the bearer indicated for suspending its integrity protection function is a data bearer (DRB), then as described above in this disclosure, the terminal's PDCP layer device may not calculate the MAC-I value for data received from higher layers, may not add or append a MAC-I field to the data, may process the data by encrypting the data without a MAC-I field, and may send the data to lower layers. The reason for not appending the MAC-I field when suspending the integrity protection of the data bearer is that, with respect to the data bearer, the overhead of the MAC-I field can be reduced; and because the data bearer has a high data transmission rate, unlike the control bearer, the processing burden attributable to the calculation of the MAC-I value and the appending of the MAC-I field can be reduced.

[0449] - If the terminal receives an RRC message and receives an instruction that the terminal should restore or configure integrity protection based on the reconfigwithSync configuration information.

[0450] *In the above description, if the bearer indicated for restoring its integrity protection function is a control bearer (SRB), then as described above in this disclosure, the PDCP layer device of the terminal can again perform MAC-I value calculation on the data received from the higher layer, can suspend the padding of the MAC-I field, can insert the calculated value, can continue to attach the MAC-I field with a given length (e.g., 4 bytes after the data), and can encrypt and transmit the data.

[0451] *In the above description, if the bearer indicated for restoring its integrity protection function is a data bearer (DRB), then as described above in this disclosure, the terminal's PDCP layer device can again perform MAC-I value calculation on the data received from the higher layer, can add or append a MAC-I field to the data, can perform encryption and processing on the data, and can send the data to the lower layer.

[0452] In this disclosure, when the integrity protection function is suspended or resumed based on an RRC message (i.e., the reconfigwithSync configuration information of the RRCReconfiguration message), the second embodiment of the terminal is as follows.

[0453] - If the terminal receives an RRC message and receives an instruction that the terminal should suspend or configure integrity protection features based on the reconfigwithSync configuration information.

[0454] *In the above description, if the bearer indicated to have its integrity protection function suspended is a control bearer (SRB), then as described above in this disclosure, the terminal's PDCP layer device does not calculate the MAC-I value for data received from higher layers, but can perform padding on the MAC-I field; that is, it can insert values ​​all zeros into the MAC-I field, can continuously attach MAC-I fields of a given length (e.g., 4 bytes after the data), and can encrypt and transmit data. The reason the terminal's PDCP layer device continues to attach the MAC-I field even though integrity protection for the control bearer has been suspended is to facilitate the terminal's transmission and reception processing for the control bearer by unifying the data format of the PDCP layer device for the control bearer to a single format. That is, in this case, although integrity protection is restored, the terminal's PDCP layer device can continue to use the same process to generate data without changing the format.

[0455] *In the above description, if the bearer indicated for suspending its integrity protection function is a data bearer (DRB), then as described above in this disclosure, the terminal's PDCP layer device does not calculate the MAC-I value for data received from higher layers, but can perform padding on the MAC-I field; that is, it can insert values ​​all zeros into the MAC-I field, can continuously attach MAC-I fields of a given length (e.g., 4 bytes after the data), and can encrypt and transmit data. The reason the terminal's PDCP layer device continues to attach the MAC-I field even though integrity protection for the data bearer has been suspended is to facilitate the terminal's transmission and reception processing for the data bearer by unifying the data format of the PDCP layer device for the data bearer to a single format. That is, in this case, although integrity protection is restored, the terminal's PDCP layer device can continue to use the same process to generate data without changing the format.

[0456] - If the terminal receives an RRC message and receives an instruction that the terminal should restore or reconfigure the integrity protection function based on the reconfigwithSync configuration information,

[0457] *In the above description, if the bearer indicating the restoration of its integrity protection function is a control bearer (SRB), then as described above in this disclosure, the PDCP layer device of the terminal can again perform MAC-I value calculation on the data received from the higher layer, can suspend the padding of the MAC-I field, can insert the calculated value, can continue to attach the MAC-I field with a given length (e.g., 4 bytes after the data), and can encrypt and transmit the data.

[0458] *In the above description, if the bearer indicated for restoring its integrity protection function is a data bearer (DRB), then as described above in this disclosure, the PDCP layer device of the terminal can again perform MAC-I value calculation on the data received from the higher layer, can suspend the padding of the MAC-I field, can insert the calculated value, can continue to attach the MAC-I field with a given length (e.g., 4 bytes after the data), and can encrypt and transmit the data.

[0459] According to embodiments of this disclosure, in next-generation mobile communication systems using the Ethernet protocol, transmission resources can be used efficiently by reducing the overhead of Ethernet frames.

[0460] According to another embodiment of this disclosure, the operation of a terminal in a next-generation mobile communication system can be improved when an event occurs that suspends bearer or protocol layer devices (e.g., SDAP layer devices, PDCP layer devices, RLC layer devices, MAC layer devices, or PHY layer devices). Specifically, a scheme is proposed for: if the terminal needs to switch to RRC inactive mode in response to an instruction from the network, depending on whether the terminal supports services using narrow bandwidth (i.e., NB-IoT terminal) or supports services using wide bandwidth (i.e., general-purpose terminal), enabling the terminal to effectively handle bearer or protocol layer devices.

[0461] In the above description, if a general-purpose terminal needs to switch to RRC inactive mode in response to an instruction from the network, the general-purpose terminal first stores the terminal context. Furthermore, if data stored in the bearer or protocol layer device by the general-purpose terminal remains there until it is subsequently reconnected, it may lead to unnecessary retransmissions and is inefficient for buffer management. Therefore, a process is needed to discard data stored in the bearer or protocol layer device, and the parameter values ​​applied as security keys need to be reset. Additionally, when data is received, if the received data has not been delivered to a higher layer, it can be delivered directly to the higher layer to reduce transmission latency. Furthermore, additional data transmission or reception can be suspended by suspending the bearer.

[0462] However, in the above description, if an NB-IoT terminal needs to switch to RRC suspend mode in response to a command from the network, the NB-IoT terminal first stores the terminal context. However, unlike general-purpose terminals, NB-IoT terminals (e.g., sensors) do not require a process for effectively managing buffers because they use narrow bandwidth and do not send or receive large amounts of data. Furthermore, because NB-IoT terminals are not sensitive to transmission latency, even the receiver stage does not require a process to reduce transmission latency.

[0463] According to another embodiment of this disclosure, a process is proposed for a terminal to compress data and for a base station to decompress data when transmitting data on the uplink in a wireless communication system; a detailed header format and supporting methods for the data transmission and reception process (such as solutions for decompression failures), wherein the transmitting stage compresses and transmits the data, and the receiving stage decompresses the data. Furthermore, this supporting method can also be applied to the process for a base station to compress and transmit downlink data and for a terminal to receive and decompress the compressed downlink data when transmitting downlink data to a terminal. As described above, this disclosure has the following effects: by compressing and transmitting data, the transmitting stage can transmit more data and can improve coverage.

[0464] Furthermore, in this disclosure, if an uplink data compression process has been configured, if the transmitting PDCP layer device discards data that has not yet been transmitted due to the expiration of the PDCP discard timer and for which UDC has already been applied, the transmitting PDCP layer device can transmit data corresponding to the next PDCP sequence number of the discarded data, and can discard all remaining data (i.e., PDCP sequence numbers with a higher next PDCP sequence number than the discarded data, data for which user data compression has been applied, and data that has been stored but not transmitted). If data has already been delivered, an indicator for discarding data already delivered to the lower layer device can be sent to the lower layer device. Data transmission can be suspended until a PDCP control PDU indicating that a checksum failure has occurred at the transmitting PDCP layer device is received. The reason for this is obvious: because intermediate data or some data of UDC-compressed data has been discarded, user data compression has previously been performed; and in the receiving PDCP layer device, checksum failure may occur in data with a higher PDCP sequence number than the discarded data (e.g., PDCPPDU). Therefore, if the transmitting PDCP layer device sends data corresponding to the next PDCP sequence number of the discarded data, the receiving PDCP layer device can identify the checksum failure and expect to send the PDCP control PDU.

[0465] Therefore, when a PDCP control PDU indicating a checksum failure has been received, or before receiving a PDCP control PDU, the transmitting PDCP layer device resets the transmit buffer used for user data compression (in this case, the transmit UDC buffer will not be reset if it has already been reset). The transmitting PDCP layer device can: re-execute the user data compression (UDC) process from data whose PDCP discard timer has not expired and has not yet been transmitted, or data whose PDCP discard timer has not expired and has eventually been transmitted (i.e., data transmitted because it corresponds to the next PDCP sequence number of the discarded data); assign a new PDCP sequence number or a first PDCP sequence number to data that has not yet been transmitted in ascending order; and prepare data (e.g., a PDCP PDU) by encrypting and generating data. The transmitting PDCP layer device can resume the transmission of newly generated and prepared data after receiving a PDCP control PDU indicating a checksum failure has occurred in the newly generated and prepared data. That is, the transmitting PDCP layer device can deliver data to the lower layer device.

[0466] Therefore, if a user data compression process has been configured, discarding some of the data previously generated by the PDCP drop timer and for which user data compression has been applied can reduce the likelihood of checksum failures in data with PDCP sequence numbers greater than those of the discarded data. Furthermore, data loss can be prevented because the data is generated from data that has not yet been sent or that has ultimately been sent (i.e., data sent because it corresponds to the next PDCP sequence number of the discarded data).

[0467] Although this disclosure has been described with reference to various embodiments, various changes and modifications may be suggested to those skilled in the art. This disclosure is intended to cover such changes and modifications that fall within the scope of the appended claims.

Claims

1. A method performed by a terminal in a wireless communication system, the method comprising: Based on the suspension configuration for the inactive state of Radio Resource Control (RRC), the suspension confirmation mode data radio bearer AM DRB and packet data convergence protocol PDCP entities; A first control message is sent to the base station to request the resumption of a suspended RRC connection; a second control message is received from the base station to request the re-establishment of the PDCP entity; based on the second control message, a first PDCP SDU is identified among at least one Packet Data Convergence Protocol Service Data Unit (PDCP SDU) associated with a Packet Data Convergence Protocol Sequence Number (PDCP SN) for the suspended AM DRB, wherein the successful delivery of the corresponding Packet Data Convergence Protocol Data Unit (PDCP PDU) for the first PDCP SDU has not yet been acknowledged by a lower layer; the at least one PDCP SDU associated with the PDCP SN is treated as being received from a higher layer; starting from the first PDCP SDU, a count value corresponding to a state variable set to an initial value based on the suspended configuration is associated with the at least one PDCP SDU; And to the base station, the at least one PDCP SDU is transmitted in ascending order of the associated count value, starting from the first PDCP SDU.

2. The method according to claim 1, wherein, The PDCP entity is suspended by setting the state variable to the initial value based on the suspension configuration.

3. The method according to claim 1, wherein, The at least one PDCP SDU is sent without restarting the discard timer for the at least one PDCP SDU.

4. The method according to claim 1, wherein, The first PDCP SDU is a PDCP SDU with the lowest count value or the lowest PDCPSN.

5. The method according to claim 1, wherein, The suspension configuration is based on control messages used to release the RRC connection.

6. A method performed by a base station in a wireless communication system, the method comprising: The terminal receives a first control message for requesting the restoration of a suspended Radio Resource Control (RRC) connection, the terminal being in an RRC inactive state, wherein the suspension configuration includes a Suspended Acknowledgment Mode Data Radio Bearer (AM DRB) and a Packet Data Convergence Protocol (PDCP) entity; a second control message is sent to the terminal for restoring the suspended RRC connection and requesting the re-establishment of the PDCP entity, wherein the second control message is used to identify a first PDCPSDU in at least one Packet Data Convergence Protocol Service Data Unit (PDCP SDU) associated with a Packet Data Convergence Protocol Sequence Number (PDCP SN) for the suspended AM DRB, wherein successful delivery of the corresponding Packet Data Convergence Protocol Protocol Data Unit (PDCP PDU) for the first PDCP SDU has not yet been acknowledged by a lower layer; and the terminal receives the at least one PDCP SDU, wherein the at least one PDCP SDU associated with the PDCP SN is considered to be received from a higher layer, and a count value corresponding to a state variable set to an initial value based on the suspension configuration is associated with the at least one PDCP SDU starting from the first PDCP SDU, and wherein the at least one PDCP SDU is received in ascending order of the associated count values ​​starting from the first PDCP SDU.

7. The method according to claim 6, wherein, The PDCP entity is suspended by setting the state variable to the initial value based on the suspension configuration.

8. The method according to claim 6, wherein, The at least one PDCP SDU is received without restarting the discard timer for the at least one PDCP SDU.

9. The method according to claim 6, wherein, The first PDCP SDU is a PDCP SDU with the lowest count value or the lowest PDCPSN.

10. The method according to claim 6, wherein, The suspension configuration is based on control messages used to release the RRC connection.

11. A terminal in a wireless communication system, the terminal comprising: A transceiver is configured to receive and transmit signals. The controller, coupled to and configured with the transceiver, is configured to: based on a suspension configuration for Radio Resource Control (RRC) inactive state, a suspension confirmation mode data radio bearer (AM DRB), and a Packet Data Convergence Protocol (PDCP) entity, send a first control message to the base station requesting the resumption of a suspended RRC connection; receive from the base station a second control message requesting the re-establishment of the suspended RRC connection, the second control message requesting the re-establishment of the PDCP entity; based on the second control message, identify, for the suspended AM DRB, a first PDCP SDU among at least one Packet Data Convergence Protocol Service Data Unit (PDCP SDU) associated with a Packet Data Convergence Protocol Sequence Number (PDCP SN), wherein, for the first PDCP SDU, successful delivery of the corresponding Packet Data Convergence Protocol Data Unit (PDCP PDU) has not yet been confirmed by a lower layer; treat the at least one PDCP SDU associated with the PDCP SN as received from a higher layer; starting from the first PDCP SDU, associate a count value corresponding to a state variable set to an initial value based on the suspension configuration with the at least one PDCP SDU; and send to the base station, in ascending order of the associated count values, starting from the first PDCP SDU. SDU begins, at least one PDCP SDU is sent.

12. The terminal according to claim 11, wherein, The PDCP entity is suspended by setting the state variable to the initial value based on the suspension configuration.

13. The terminal according to claim 11, wherein, The at least one PDCP SDU is sent without restarting the discard timer for the at least one PDCP SDU.

14. The terminal according to claim 11, wherein, The first PDCP SDU is a PDCP SDU with the lowest count value or the lowest PDCP SN.

15. The terminal according to claim 11, wherein, The suspension configuration is based on control messages used to release the RRC connection.

16. A base station in a wireless communication system, the base station comprising: A transceiver is configured to receive and transmit signals. The controller, coupled to and configured to: receive from a terminal a first control message for requesting the resumption of a suspended Radio Resource Control (RRC) connection, the terminal being in an RRC inactive state, wherein, based on a suspended configuration, a suspended confirmation mode data radio bearer (AM DRB) and a packet data convergence protocol (PDCP) entity, a second control message is sent to the terminal for resuming the suspended RRC connection and requesting the re-establishment of the PDCP entity, wherein the second control message is used to identify, for the suspended AM DRB, a first PDCPSDU in at least one packet data convergence protocol service data unit (PDCP SDU) associated with a packet data convergence protocol sequence number (PDCP SN), wherein, for the first PDCP SDU, successful delivery of the corresponding packet data convergence protocol protocol data unit (PDCP PDU) has not yet been acknowledged by a lower layer; and receive from the terminal the at least one PDCP SDU, wherein the at least one PDCP SDU associated with the PDCP SN is considered to have been received from a higher layer, and a count value corresponding to a state variable set to an initial value based on the suspended configuration is associated with the at least one PDCP SDU starting from the first PDCP SDU, and wherein the at least one PDCP... SDUs are received starting with the first PDCP SDU in ascending order of their associated count values.

17. The base station according to claim 16, wherein, The PDCP entity is suspended by setting the state variable to the initial value based on the suspension configuration.

18. The base station according to claim 16, wherein, The at least one PDCP SDU is received without restarting the discard timer for the at least one PDCP SDU.

19. The base station according to claim 16, wherein, The first PDCP SDU is a PDCP SDU with the lowest count value or the lowest PDCP SN.

20. The base station according to claim 16, wherein, The suspension configuration is based on control messages used to release the RRC connection.

Images