KR102216510B1 - Method and apparatus for transmitting and receiving data using a plurality of carriers in mobilre communication system - Google Patents

Abstract

The present specification relates to a mobile communication system, and more specifically, to a method and apparatus for transmitting and receiving data using a plurality of carriers in a mobile communication system, and a mobile communication system supporting multiple bearers according to an embodiment of the present invention. The bearer reconfiguration method in a communication system includes a process of receiving a first control message for bearer reconfiguration, and upon resetting a bearer from a single bearer to the multi-bearer based on the first control message, converting PDCP PDUs into PDCP SDUs It includes the process of delivering the ordered PDCP SDUs to the upper layer.

Description

Method and device for transmitting and receiving data using multiple carriers in a mobile communication system {METHOD AND APPARATUS FOR TRANSMITTING AND RECEIVING DATA USING A PLURALITY OF CARRIERS IN MOBILRE COMMUNICATION SYSTEM}

The present invention relates to a method and apparatus for transmitting and receiving data using a plurality of carriers in a mobile communication system.

In general, mobile communication systems have been developed for the purpose of providing communication while securing user mobility. These mobile communication systems have reached the stage of providing high-speed data communication services as well as voice communication thanks to the rapid development of technology.

Recently, as one of the next generation mobile communication systems, the Long Term Evolution (LTE) system in the 3rd Generation Partnership Project (3GPP) is providing services in a number of countries. The LTE system is a technology for implementing high-speed packet-based communication having a transmission rate of about 100 Mbps.

Recently, commercialization of an evolved LTE communication system (LTE-Advanced, LTE-A) that has improved transmission speed by combining various new technologies with the LTE communication system is in progress. A representative of the newly introduced technologies is carrier aggregation. Carrier aggregation refers to one terminal using a plurality of forward carriers and a plurality of reverse carriers, unlike the conventional terminal transmitting and receiving data using only one forward carrier and one reverse carrier.

Currently, in LTE-A, only intra-ENB carrier aggregation is defined. This leads to a reduction in the applicability of the carrier aggregation function, and in particular, in a scenario in which a plurality of pico cells and one macro cell are overlapped and operated, it may cause a problem in that a macro cell and a pico cell cannot be integrated. The pico cell may be referred to as a micro cell or a small cell in other terms.

The present invention provides a method and apparatus for efficiently transmitting and receiving data using a plurality of carriers in a mobile communication system.

In addition, the present invention provides a method and apparatus for inter-ENB carrier aggregation between different base stations.

In addition, the present invention provides a method and apparatus for switching PDCP operation in a mobile communication system supporting multiple bearers.

In addition, the present invention provides a method and apparatus for reordering PDCP in a mobile communication system supporting multiple bearers.

According to an embodiment of the present invention, a bearer reconfiguration method in a mobile communication system supporting multiple bearers includes a process of receiving a first control message for bearer reconfiguration, and the multi-bearer in a single bearer based on the first control message. When reconfiguring the lower bearer, it includes a process of converting PDCP PDUs to PDCP SDUs and delivering the ordered PDCP SDUs to a higher layer.

In addition, the method of the present invention includes a process of receiving a second control message for bearer reconfiguration, and based on the second message, and when resetting a bearer from the multi-bearer to the single bearer, the PDCP transmitted from the MCG RLC and the SCG RLC. A process of converting the PDUs to PDCP SDUs by processing the PDUs corresponding to the COUNT, and storing all SDUs after the first unreceived SDU in a buffer are further included.

According to various embodiments of the present specification, by integrating carriers between different base stations, it is possible to further improve the transmission/reception speed of the terminal.

In addition, according to various embodiments of the present invention, PDCP reordering may be efficiently performed when reconfiguring a bearer between a single bearer and multiple bearers in a communication environment using multiple bearers such as carrier aggregation.

1 is a diagram showing a structure of an LTE system to which an embodiment of the present specification is applied,
2 is a diagram showing a radio protocol structure in an LTE system to which an embodiment of the present specification is applied,
3 is a diagram for explaining carrier aggregation in a base station in an LTE system;
4 is a diagram for explaining carrier aggregation between base stations in an LTE system according to an embodiment of the present specification;
5 is a diagram illustrating a connection structure of a PDCP device in an LTE system according to an embodiment of the present specification;
6 is a diagram illustrating a process of switching a PDCP operation in an LTE system according to an embodiment of the present specification;
7 is a diagram for explaining reconfiguration of an RLC device when switching a PDCP operation in an LTE system according to an embodiment of the present specification;
8 is a diagram for explaining an operation of a terminal when resetting a bearer in an LTE system according to an embodiment of the present specification;
9 is a diagram for explaining an upper layer transmission condition of a PDCP operation in an LTE system according to an embodiment of the present specification;
10 is a diagram for explaining an operation of a PDCP receiving device in an LTE system according to an embodiment of the present specification;
FIG. 11 is a diagram for explaining an operation when timer 1 expires in the PDCP receiving apparatus of FIG. 10;
12 is a diagram for explaining an operation of a terminal for setting a PBR for a multi-bearer according to an embodiment of the present specification;
13 is a diagram showing a format of a state PDU according to an embodiment of the present specification;
14 is a diagram for explaining an operation of an RLC receiving apparatus for generating a state PDU according to an embodiment of the present specification;
15 is a diagram for explaining an operation of an RLC transmitting apparatus for receiving a status PDU according to an embodiment of the present specification;
16 is a block diagram showing the configuration of a terminal device in an LTE system according to an embodiment of the present invention;
17 is a block diagram showing the configuration of a base station device in an LTE system according to an embodiment of the present invention;
18 is a diagram illustrating an operation of a terminal reporting three categories and a base station performing downlink data transmission and reception with the terminal according to an embodiment of the present invention;
19 is a diagram showing a terminal operation according to an embodiment of the present invention;
20, 24, 28, and 29 are diagrams showing various examples of a terminal operation when resetting a bearer according to an embodiment of the present invention;
21 is a diagram illustrating an operation of a PDCP receiving device operating as a multi-bearer according to an embodiment of the present invention.
FIG. 22 is a diagram illustrating an operation of a PDCP receiving device to switch to PDCP operation 5 when resetting from a multi-bearer to an MCG bearer according to an embodiment of the present invention.
23 is a diagram showing an operation of a PDCP receiving apparatus when timer 3 expires according to an embodiment of the present invention;
25 is a diagram showing a PDCP operation 7 of a PDCP receiving device operating as a multi-bearer according to an embodiment of the present invention;
26 is a diagram illustrating an operation of a PDCP receiving apparatus when timer 3 expires according to an embodiment of the present invention;
FIG. 27 is a diagram illustrating an operation of determining whether a terminal receiving a PDCP PDU receives duplicate reception according to an embodiment of the present invention.

In the following, when it is determined that a detailed description of a known function or configuration related to the present specification may unnecessarily obscure the subject matter of the present specification, a detailed description thereof will be omitted. Hereinafter, exemplary embodiments of the present specification will be described with reference to the accompanying drawings. Hereinafter, prior to describing the present specification, an LTE system and carrier aggregation will be briefly described. And in the embodiments of the present specification, the LTE system will be understood as encompassing the LTE-A system.

1 is a diagram illustrating a structure of an LTE system to which an embodiment of the present specification is applied.

Referring to Figure 1, the radio access network of the LTE system is a next-generation base station (Evolved Node B, hereinafter ENB, Node B or base station) (105, 110, 115, 120) and MME (125, Mobility Management Entity) and S-GW (130, Serving-Gateway). The user equipment (UE or terminal) 135 connects to an external network (not shown) through ENBs 105, 110, 115, 120 and S-GW 130.

In FIG. 1, ENBs 105, 110, 115, and 120 correspond to existing Node Bs in the UMTS system. The ENBs 105, 110, 115, and 120 are connected to the UE 135 through a radio channel and perform a more complex role than the existing Node B. In the LTE system, all user traffic including real-time services such as VoIP (Voice over IP) through the Internet protocol are serviced through a shared channel, so status information such as buffer status, available transmission power status, and channel status of UEs A device for collecting and scheduling is required, and ENBs 105, 110, 115, and 120 are in charge of this. One ENB (105, 110, 115, 120) typically controls a number of cells. For example, in order to implement a transmission rate of 100 Mbps, the LTE system uses orthogonal frequency division multiplexing (OFDM) in a 20 MHz bandwidth as a radio access technology. In addition, ENBs 105, 110, 115, and 120 determine a modulation scheme and a channel coding rate according to the channel state of the terminal 135. Adaptive Modulation & Coding (AMC) D) method is used. The S-GW 130 is a device that provides a data bearer, and creates or removes a data bearer under the control of the MME 125. The MME 125 is a device responsible for various control functions as well as a mobility management function for the terminal 135 and is connected to a plurality of ENBs.

2 is a diagram showing a radio protocol structure in an LTE system to which an embodiment of the present specification is applied.

Referring to FIG. 2, the radio protocol structure of the LTE system includes Packet Data Convergence Protocol 205 and 240 (PDCP), Radio Link Control 210 and 235 (RLC), and Medium Access Control 215 and 230 (MAC) in a UE and an ENB, respectively.

PDCP (Packet Data Convergence Protocol) (205, 240) is in charge of operations such as IP header compression / restoration, and radio link control (Radio Link Control, hereinafter referred to as RLC) (210, 235) PDCP PDU (Packet Data Unit ) Is reconfigured to an appropriate size to perform ARQ (Automatic Repeat Request) operation. The MACs 215 and 230 are connected to several RLC layer devices configured in one UE, multiplexing RLC PDUs to MAC PDUs, and demultiplexing RLC PDUs from MAC PDUs. The physical layers 220 and 225 perform channel coding and modulation of upper layer data, making them into OFDM symbols and transmitting them through a wireless channel, or demodulating and channel decoding OFDM symbols received through a radio channel and transmitting them to the upper layers. .

3 is a diagram for explaining carrier aggregation in a base station in an LTE system.

Referring to FIG. 3, a single base station can generally transmit and receive multiple carriers over several frequency bands. For example, when a carrier 315 having a forward center frequency f1 and a carrier 310 having a forward center frequency f3 are transmitted from the base station 305, conventionally, one of the two carriers f1 and f3 Data was transmitted and received using one carrier. However, the terminal 330 having carrier aggregation capability can simultaneously transmit and receive data through multiple carriers. The base station 305 can increase the transmission speed of the terminal 330 by allocating more carriers to the terminal 330 having the carrier aggregation capability according to the situation. As described above, aggregation of forward carriers and uplink carriers transmitted and received by one base station is referred to as intra-base station carrier aggregation. However, in some cases, unlike the example shown in FIG. 3, it may be necessary to aggregate forward and uplink carriers transmitted and received from different base stations.

4 is a diagram for explaining carrier aggregation between base stations, which is a carrier aggregation method according to an embodiment of the present specification.

Referring to FIG. 4, when base station 1 405 transmits and receives data through a carrier having a center frequency f1, and base station 2 415 transmits and receives data through a carrier having a center frequency f2, the terminal 430 When a carrier having a forward center frequency f1 and a carrier having a forward center frequency f2 are aggregated (combined), it leads to a result of a single terminal integrating carriers from two or more base stations, and in this specification, this is inter-ENB. It is called carrier aggregation (or inter-base station CA). In this specification, carrier aggregation between base stations is referred to as dual connectivity (DC), and for example, DC is configured means that carrier aggregation between base stations has been established, that one or more cell groups are configured, and that SCG (Secondary Cell Group) ) Is configured, that at least one secondary serving cell (SCell) controlled by a base station other than the serving base station (SeNB) is configured, that a primary serving cell (PCell or pSCell) is configured, for SeNB It means that a MAC entity is set, that two MAC entities are set in the terminal, and so on.

Hereinafter, terms used in the present specification will be described.

In the traditional sense, when one forward carrier transmitted by one base station and one uplink carrier received by the base station constitute one cell, carrier aggregation means that the terminal transmits and receives data through multiple cells at the same time. It may be understood. In this case, the maximum transmission rate and the number of aggregated carriers have a positive correlation.

Hereinafter, in the present specification, that the terminal receives data through an arbitrary forward carrier or transmits data through an arbitrary uplink carrier means a control channel and data provided by a cell corresponding to the center frequency and frequency band characterizing the carrier. It has the same meaning as transmitting and receiving data using a channel. In this specification, in particular, carrier aggregation will be expressed as'a plurality of serving cells are configured', and terms such as a primary serving cell (hereinafter referred to as PCell) and a secondary serving cell (hereinafter referred to as SCell), or an activated serving cell will be used. The terms have the same meaning as used in the LTE mobile communication system. In the present invention, terms such as carrier, component carrier, and serving cell are used interchangeably.

In this specification, a set of serving cells controlled by the same base station is defined as a cell group or carrier group (CG). The cell group is further divided into a master cell group (MCG) and a secondary cell group (SCG). MCG refers to a set of serving cells controlled by a base station controlling a PCell (hereinafter, a master base station, MeNB), and SCG refers to a base station that is not a base station controlling a PCell, that is, a base station that controls only SCells (hereinafter, a slave base station, SeNB) refers to a set of serving cells controlled by. In the process of configuring the serving cell, whether a predetermined serving cell belongs to the MCG or the SCG is notified to the UE. One MCG and one or more SCGs may be configured in one terminal, and the present invention considers only the case where one SCG is configured for convenience of description. However, even if one or more SCGs are configured, the contents of the present invention are not added or subtracted. It can be applied as it is. PCell and SCell are terms indicating the type of serving cell configured in the terminal. There are several differences between the PCell and the SCell. For example, the PCell always maintains the active state, but the SCell repeats the active state and the inactive state according to the instruction of the base station. The mobility of the terminal is controlled by the PCell, and the SCell can be understood as an additional serving cell for data transmission and reception. PCell and SCell in the present specification mean PCell and SCell defined in LTE standard TS36.331 or TS36.321 proposed by 3GPP.

In the present invention, a macro cell and a pico cell are considered. A macro cell is a cell controlled by a macro base station and provides services in a relatively wide area. On the other hand, a pico cell is a cell controlled by the SeNB and provides a service in a significantly narrower area than a typical macro cell. Although there is no strict criterion for distinguishing between a macro cell and a pico cell, for example, it may be assumed that a macro cell has a radius of about 500 m and a pico cell has a radius of several tens of m. In this specification, pico cells and small cells are used interchangeably.

4, if base station 1 405 is a MeNB and base station 2 415 is a SeNB, a serving cell 410 with a center frequency f1 is a serving cell belonging to an MCG and a serving cell 420 with a center frequency f2 is an SCG It is a serving cell belonging to.

In the description to be described later, for understanding, other terms may be used instead of MCG and SCG. For example, terms such as MCG and secondary set or primary carrier group and secondary carrier group may be used. However, in this case, it should be noted that only the terms are different and the meanings are the same. The main purpose of these terms is to distinguish which cell is controlled by the base station that controls the PCell of a specific terminal, and when the cell is controlled by the base station that controls the PCell of a specific terminal or not. And the operation method of the corresponding cell may be different.

One or more than one SCG may be configured in the terminal, but in the present invention, it is assumed that only one SCG may be configured for convenience of description. SCG can be composed of several SCells, one of which has special properties.

In a typical base station CA, the UE transmits not only HARQ feedback and CSI for the PCell, but also HARQ feedback and CSI for the SCell, through the PUCCH of the PCell. This is to apply CA even to a terminal in which simultaneous uplink transmission is impossible.

In the case of inter-base station CA, it may be practically impossible to transmit HARQ feedback of CSG SCells and CSI through PUCCH, which is an uplink control channel of PCell. HARQ feedback should be delivered within HARQ RTT (Round Trip Time, typically 8 ms), because a transmission delay between MeNB and SeNB may be longer than HARQ RTT. Because of the above-described problem, a PUCCH transmission resource is set in one of the SCells belonging to the SCG, and HARQ feedback and CSI for SCG SCells are transmitted through the PUCCH. The special SCell is referred to as pSCell (primary SCell). In the following description, the CA between base stations uses dual connectivity.

In general, one user service is serviced by one Evolved Packet System (EPS) bearer, and one EPS bearer is connected to one radio bearer. The radio bearer is composed of PDCP and RLC. In the CA between base stations, the PDCP device and the RLC device of one radio bearer are located in different base stations to increase data transmission/reception efficiency. At this time, different approaches are required depending on the type of user service.

5 is a diagram illustrating a connection structure of a PDCP device in an LTE system according to an embodiment of the present specification.

Referring to FIG. 5, in the case of a large data service, for example, a user service can transmit and receive data with both the MeNB and the SeNB by forming two RLC devices as shown by reference numeral 510. In the case of a service with strict QoS requirements such as VoLTE, the user service can transmit and receive data using only the serving cell of the MeNB by placing the RLC device in the MeNB as shown by reference number 505. Hereinafter, for convenience of description, a bearer such as 505 is referred to as a single bearer, and a bearer such as 510 is referred to as a multiple bearer. A single bearer PDCP device is connected to one RLC device, and a multi-bearer PDCP device is connected to two RLC devices. An RLC device for transmitting and receiving data through the MCG (or connected to a MAC device related to the serving cells of the MCG) is referred to as an MCG RLC 515, and an RLC device for transmitting and receiving data through the SCG is referred to as an SCG RLC 520. The MAC 525 related to data transmission and reception through the MCG is referred to as MCG-MAC, and the MAC 530 related to data transmission and reception through the SCG is referred to as SCG-MAC. The logical channel between the MAC and the RLC device is connected, the logical channel between the MCG RLC and the MCG-MAC is called the MCG logical channel, and the logical channel between the SCG RLC and the SCG-MAC is called the SCG logical channel.

For convenience of explanation, the macro cell area means an area in which a small cell signal is not received but only a macro cell signal is received, and the small cell area means an area in which both a macro cell signal and a small cell signal are received. When the terminal with high demand for downlink data moves from the macro cell area to the small cell area, a small cell can be additionally set up for the terminal, and among some bearers of the terminal, bearers with a large amount of downlink data such as file transfer protocol (FTP) are It can be reset from a single bearer to multiple bearers. In other words, when the UE moves from the macro cell area to the small cell area back to the macro cell area, the predetermined bearer is reset to a single bearer from a single bearer to a multiple bearer. Since the PDCP device of a single bearer is connected to one RLC and the RLC delivers the packets in order to the PDCP, the PDCP device processes the packets transmitted by the RLC in order. On the other hand, a multi-bearer PDCP device is connected to two RLCs, and each RLC delivers the packets in order, but the order may not be aligned between the RLC devices, so the PDCP processes the packets after ordering. . Accordingly, when the PDCP device is reconfigured from a single bearer to a multi-bearer or from a multi-bearer to a single bearer, the action taken by the PDCP device is also changed at an appropriate time.

Hereinafter, in an embodiment of the present invention, the operation of the terminal is divided into a PDCP operation 1, a PDCP operation 2, and a PDCP operation 3.

PDCP operation 1 is an operation applied to PDCP of a single bearer. For details on the above operation, follow Section 5.1.2 of 3GPP standard TS36.323. PDCP device operation 2 is another operation applied to PDCP of a single bearer, and PDCP device operation 1 is applied in a general case.

PDCP device operation 2 is applied in an exceptional case in which the lower layer device cannot perform order reordering, for example, in a handover situation or an RRC connection reestablishment procedure. Details of the above operation also follow section 5.1.2 of TS36.323. In the case of operation of the PDCP device operation 1, the PDCP performs a necessary process on the assumption that the order of the received packets is correct, and then delivers the received packet and the packets having a lower serial number than the received packet to the upper layer. On the other hand, when the lower layer device does not perform the order rearrangement, for example, in PDCP operation 2, since the order of the received packets may be incorrect, the packets are not transferred to the upper layer and are stored in the order rearrangement buffer. And when it comes to the time when the lower layer device provides reordering in the future (that is, when the handover is completed or the RRC connection reconfiguration process is completed), the PDCP device operation 1 is switched, and the stored PDCP SDUs are newly received PDCP. It is delivered to the upper layer along with the SDUs. The switching between PDCP operation 1 and operation 2 occurs immediately upon receiving, for example, a control message indicating handover, and PDCP operation 2 is applied briefly immediately after handover occurs. And in the embodiment of the present invention, PDCP operation 3 is newly introduced.

The PDCP operation 3 is an operation applied to the multi-bearer PDCP, in which two RLC devices connected to the PDCP device receive a PDCP Protocol Data Unit (PDU), and'the order is arranged between the PDCP PDUs received from one RLC device. However, it is designed for use in a situation where the order is not aligned between PDCP PDUs received from different RLC devices. In PDCP operation 1 and operation 2, the received PDCP PDUs are processed as a PDCP Service Data Unit (SDU) and then the order is checked for reordering, whereas in PDCP operation 3, the order of received PDCP PDUs is checked first, and then, Only the ordered PDCP PDUs are processed as PDCP SDUs and delivered to higher layers. Alternatively, in PDCP operation 3, it is also possible to perform reordering after processing PDCP PDUs as PDCP SDUs. Details of PDCP operation 1, PDCP operation 2, and PDCP operation 3 will be described later. As described above, PDCP operation 2 is temporarily applied in a handover situation, but PDCP operation 3 is continuously applied while operating as a multi-bearer. PDCP operation 1 is applied to a single bearer and PDCP operation 3 is applied to a multi-bearer. When any bearer is switched from a single bearer to multiple bearers, or vice versa, the PDCP operation is switched from operation 1 to operation 3, or from operation 3 to operation 1. In this case, if the operation changeover is performed at an early time point, unnecessary delay may occur when the PDCP device transmits data to the upper layer device, and if the operation changeover is performed at a late time point, data loss may occur.

6 is a diagram for describing a process of switching a PDCP operation in an LTE system according to an embodiment of the present specification. In FIG. 6, the operation of the terminal and the base station related to bearer reconfiguration including a process of performing the PDCP operation switching at an appropriate time point will be described in detail.

6, in a mobile communication system composed of a terminal 605, a MeNB 610, and a SeNB 615, at an arbitrary point in time, the MeNB 610 provides a serving cell of the SeNB 615 to the terminal 605 in step 620. It is determined to add and performs a procedure for adding a serving cell with the SeNB 615. If the SCell of the SeNB 615 is first configured to the UE 605 (that is, if the first SCG SCell is configured), the MeNB 610 and the SeNB 615 serve a certain bearer by the MeNB 610 and SeNB 615 determines which bearer is to be serviced. The MeNB 610 and the SeNB 615 may reconfigure a bearer meeting a predetermined condition, for example, a bearer requiring high-speed data transmission through a downlink, to a multi-bearer. For convenience of description below, it is assumed that bearer x has been reset from a single bearer to multiple bearers.

In step 625, the MeNB 610 transmits a predetermined RRC control message to the terminal 605. SCell configuration information and multi-bearer information are stored in the RRC control message. The SCell configuration information is for a newly added SCell, and includes information indicating whether the SCell is an MCG SCell or an SCG SCell. The multi-bearer configuration information is information on a radio bearer reconfigured from a single bearer to a multi-bearer, and may include an identifier of the radio bearer, SCG RLC configuration information, and the like.

Upon receiving the control message in step 630, the terminal 605 creates an SCG RLC for the bearer indicated by the bearer identifier, connects it with the PDCP device, and connects the SCG RLC device with the MAC device for SCG. The UE switches from the above-described PDCP operation 1 to the PDCP operation 3 at the time when the configuration of the multi-bearer is completed or when the random access to be described later is completed. In the existing RLC device of the bearer, that is, the MCG RLC, normal data transmission and reception, for example, ordered PDCP PDUs are delivered to the PDCP device even during the reconfiguration process. Performs an operation that attempts to recover unreceived PDUs. As will be described later, in the reconfiguration process from a multi-bearer to a single bearer, unlike reconfiguration from a single bearer to a multiple bearer, the MCG RLC device also stops the RLC reception operation and performs the RLC reconfiguration process.

In step 635, the terminal 605 performs random access in the newly added SCG SCell. Through the random access process, the UE 605 establishes uplink synchronization with the newly added SCG SCell and sets uplink transmission output. When the random access process is completed, in step 640, the terminal 605 switches the operation of the PDCP device reset to the multi-bearer from the PDCP device operation 1 to the PDCP device operation 3. The timing at which the random access process is completed is when the terminal receives a valid random access response message when a dedicated preamble is used, and when a random preamble is used, the terminal is C-RNTI (Cell- Radio Network Temporary Identifier) and this is the time when an uplink grant or downlink assignment indicating a new transmission is received. Other matters related to the above random access follow standard TS36.321.

In step 645, the terminal 605 transmits a predetermined RRC control message to the MeNB 610 to report that SCell configuration and multi-bearer reconfiguration have been completed. In step 650, when the MeNB 610 receives the reported information, it forwards the downlink data of the multi-bearer to the SeNB 615, and the SeNB initiates the downlink data transmission to the UE through the SCG RLC of the multi-bearer. .

Meanwhile, the terminal 605 transmits the predetermined RRC control message in step 655 and then receives downlink data of the multi-bearer from the MCG RLC device and the SCG RLC device, and performs PDCP operation 3 for the received PDCP PDUs. Apply.

Thereafter, in step 670, the MeNB 610 or the SeNB 615 determines to release the SCG SCell at any time. The MeNB 610 and SeNB 61 perform a procedure for SCG SCell release, and in step 675, the MeNB 610 transmits a predetermined RRC control message to the UE 605 to instruct the SCG SCell release.

In step 680, upon receiving the control message, the terminal 605 releases the SCG SCell according to the instruction. If the control message indicates the release of the last SCG SCell (that is, if the SCG SCell is released according to the instruction of the control message, no more SCG SCells exist), even if there is no separate indication, the single Perform the necessary procedures for resetting to the bearer. Even when the control message explicitly indicates reconfiguration from multiple bearers to single bearers, an operation for reconfiguration from multiple bearers to single bearers is similarly performed.

[Reset operation from multiple bearers to single bearers]

1) SCG RLC release of the commanded multi-bearer

2) Resetting the MCG RLC receiving device of the instructed multi-bearer

3) Discarding downlink HARQ buffer data of MCG-MAC

4) Trigger PDCP status report

In the process of releasing the SCG RLC, the UE 605 reconstructs the downlink RLC PDUs stored in the SCG RLC into RLC SDUs and transfers them to the PDCP, and discards the uplink RLC PDUs and the uplink RLC SDUs stored in the SCG RLC. The RLC SDU/PDCP PDUs delivered from the SCG RLC are RLC SDU/PDCP PDUs whose order is not aligned (that is, there are RLC SDUs that have been transmitted before the RLC SDU but have not yet been received).

Reconfiguring the MCG RLC receiving device by the UE means that the receiving window is initialized, the receiving serial number is initialized, and the downlink RLC PDUs stored in the receiving buffer that can be reconfigured as RLC SDUs are transferred to the PDCP and the remaining downlink RLC. This means that PDUs are discarded. The UE does not discard uplink RLC PDUs and RLC SDUs stored in the transmission buffer.

The PDCP status report may be triggered for each radio bearer, and the terminal 605 examines the serial number of the PDCP packet stored in the buffer of the PDCP of the bearer reset to a single bearer from multiple bearers, Generates a PDCP status report including related information. The PDCP buffer stores PDCP PDUs transmitted from SCG RLC and PDCP PDUs transmitted from MCG RLC.

The PDCP status report is control information used to prevent PDCP packet loss during handover or RRC connection reestablishment. The handover or RRC connection re-establishment process involves re-establishment of all RLC devices set in the terminal 605 (re-establishment of lower layers from the perspective of the PDCP device). When the handover or RRC connection re-establishment process is initiated, the terminal 605 triggers a PDCP status report for all DRBs that satisfy the PDCP status report generation condition 1 below. When the last SCG SCell is released, the UE 605 triggers a PDCP status report for all DRBs that satisfy the PDCP status report generation condition 2 below. When a bearer is reset from a multi-bearer to a single bearer, the UE checks whether the corresponding bearer satisfies the following PDCP status report generation condition 3 to determine whether to generate a PDCP status report.

[PDCP status report generation condition 1]

Among DRBs with RLC AM set, DRB with statusReportRequired set

[PDCP status report generation condition 2]

Among DRBs with RLC AM and statusReportRequired set, multiple bearers

[PDCP status report generation condition 3]

At least one of the SCG RLC and MCG RLC of the multi-bearer operates as an RLC AM

The statusReportRequired complies with standards TS36.331 and TS36.323.

When the UE resets the multi-bearer to a single bearer, the operation of the PDCP of the reset bearer is switched from the PDCP operation 3 to the PDCP operation 2 in step 685. The PDCP stores PDCP SDUs in which the order delivered from the MCG RLC is not aligned and PDCP SDUs in which the order delivered from the SCG RLC is not aligned. The PDCP SDUs delivered during the reconfiguration of the MCG RLC and the PDCP SDUs delivered during the release of the SCG RLC are stored in the PDCP buffer in COUNT order, and the reception status of the PDCP SDUs delivered from the MCG RLC and the PDCP delivered from the SCG RLC A PDCP status report reflecting all the reception status of SDUs is generated and transmitted to the MeNB.

Meanwhile, in step 690, the UE 605 transmits a predetermined RRC control message to the MeNB 610 to report that the process has been successfully completed, and the UE 605 and the MeNB 610 communicate with uplink data through MCG SCells. It transmits and receives downlink data.

The UE not only releases the SCG RLC device but also resets the MCG RLC device in the process of reconfiguring the multi-bearer to a single bearer. In principle, since the MCG RLC device is not affected during the reconfiguration process from a multi-bearer to a general bearer, it is unnecessary to reset the MCG RLC device.

However, in an embodiment of the present invention, as in the example of FIG. 7, the MCG RLC device is artificially reconfigured in order to efficiently switch the PDCP operation.

7 is a diagram for explaining reconfiguration of an RLC device when switching a PDCP operation in an LTE system according to an embodiment of the present specification.

Referring to FIG. 7, for example, at a time when reconfiguration from a multi-bearer to a single bearer is instructed, an unordered PDCP PDU [10] and a PDCP PDU [11] are stored in the MCG RLC 710 (ie PDCP PDU [9] is not received), SCG RLC 715 has an unordered PDCP PDU [7], PDCP PDU [8], PDCP PDU [12], PDCP PDU [13], PDCP PDU [14] Has been saved. For reference, it is assumed that the RLC serial number of PDCP PDU [10] is 5 and the RLC serial number of PDCP PDU [11] is 6, and so on. If a PDCP PDU is delivered only from the SCG RLC when reconfiguration from a multi-bearer to a single bearer is instructed, the sequence of packets after PDCP PDU [12] until PDCP PDU [10] and [11] are delivered from MCG RLC. Since it is difficult for the PDCP to determine whether or not to reorder, another reordering operation must be introduced. In an embodiment of the present invention, in order to solve the above problem, when a multi-bearer is reset to a single bearer, the reconfiguration is applied to the MCG RLC device as well, so that all PDCP SDUs out of order at the time are stored in the PDCP buffer. In addition, the PDCP operation 2 is applied first instead of immediately applying the PDCP operation 1 so that the ordered PDCP SDUs are not immediately delivered to the upper layer. In other words, the UE releases the SCG RLC device and resets the MCG RLC device, and then switches the PDCP device operation from operation 3 to operation 2, and when the first PDCP PDU is received after resetting to a single bearer, it switches from PDCP operation 2 to PDCP operation 1. do.

8 is a diagram illustrating an operation of a terminal when resetting a bearer in an LTE system according to an embodiment of the present specification. In the embodiment of FIG. 8, an operation of a terminal reconfiguring an arbitrary bearer x from a normal bearer to a multi-bearer back to a normal bearer will be described.

Referring to FIG. 8, in step 805, the UE applies PDCP device operation 1 to bearer x, which is a single bearer. In step 810, a control message for resetting the bearer x to multiple bearers is received. In step 815, the UE creates an SCG RLC device to be connected to the multi-bearer according to the configuration information indicated in the control message, and then connects to the PDCP. The terminal proceeds to step 820 and switches the operation of the PDCP device from operation 1 to operation 3. In other words, the UE applies PDCP operation 3, which determines whether to transfer to a higher layer after checking for reordering from the first PDCP PDU received after being reconfigured as a multi-bearer. Thereafter, the UE converts the PDCP PDUs into PDCP SDUs by applying PDCP operation 3 to the PDCP PDUs of the reset bearer, and performs an operation of transferring the ordered PDCP SDUs to a higher layer.

When receiving a control message instructing to reset the multi-bearer to a single bearer in step 825, the UE proceeds to step 830 to release the SCG RLC and re-establish the MCG RLC. At this time, the SCG RLC releases both the transmitting device and the receiving device, and the MCG RLC re-establishes only the receiving device. In other words, RLC SDUs and RLC PDUs stored in the MCG RLC transmitting device are processed normally without discarding, and all RLC PDUs stored in the RLC receiving device that can be assembled as RLC SDUs are assembled as RLC SDUs and then delivered to PDCP. And discard the remaining RLC PDUs.

In step 835, the terminal does not immediately switch the operation of the PDCP device from operation 3 to operation 1, but switches to operation 2 once. That is, the UE processes PDCP PDUs transmitted from the MCG RLC and SCG RLC according to the COUNT and converts them into PDCP SDUs, and then stores all SDUs after the first unreceived SDU in the buffer.

In step 840, the UE applies operation 1 from the first PDCP PDU received after re-establishment to a single bearer. That is, after converting the first PDCP PDU into an SDU, the UE determines that the order is aligned even though there are unreceived SDUs among SDUs with a COUNT lower than the COUNT of the received SDU, and the COUNT is consecutive before and after the received SDU. SDUs are delivered to the upper layer.

Steps 830, 835, and 840 may be modified as follows. In step 830, the UE releases the SCG RLC, maintains the MCG RLC, and switches the PDCP device operation from operation 3 to operation 2 in step 835. That is, the UE processes the PDCP PDUs delivered from the SCG RLC, and stores the PDCP SDUs out of order in the PDCP buffer without delivering them to the upper layer. In step 840, when switching to a single bearer is completed, or upon receiving the first PDCP PDU after switching to a single bearer, the UE drives a predetermined timer 2. The terminal maintains operation 2 while timer 2 is running, and switches from operation 2 to operation 1 when timer 2 expires. In other words, while the timer 2 is running, it waits for the order of the PDCP PDUs whose order occurred due to the release of the SCG RLC to be aligned. The timer 2 should be set to a time long enough to eliminate the sequence mixing, and the values of the timer 1 and the timer 2 are notified by the base station to the terminal using a predetermined RRC control message.

The PDCP operation 1, operation 2, and operation 3 may be understood as a series of detailed operations to be applied to the PDCP PDU delivered from the RLC device. In Table 1 below, detailed actions constituting these actions and their sequence are listed. The following detailed operations are performed in the order from top to bottom.

PDCP operation 1 PDCP operation 2 PDCP operation 3 Receive PDCP PDU Receive PDCP PDU Receive PDCP PDU PDCP PDU HFN/COUNT determination. Discard if PDU received duplicate PDCP PDU HFN/COUNT determination. Discard if PDU received duplicate PDCP PDU HFN/COUNT determination. Discard if PDU received duplicate PDCP PDU is processed as PDCP SDU PDCP PDU is processed as PDCP SDU PDCP PDU is processed as PDCP SDU Delivering the PDCP SDU and PDCP SDUs that satisfy the higher layer transfer condition 1 to the upper layer. The rest is stored in the buffer The PDCP SDU that satisfies the higher layer delivery condition 2 is delivered to the higher layer. The remaining SDUs are stored in the PDCP buffer Save PDCP SDU to PDCP buffer. Deliver PDCP SDUs that satisfy higher layer delivery condition 3 to higher layers. The remaining SDUs are stored in the PDCP buffer.

A method of determining the HFN/COUNT of the received PDCP PDU described in Table 1 will be described below. COUNT is a 32-bit integer, starting at 0 and increasing by 1. One COUNT is assigned per PDCP packet, and is used for security-related operations such as secret/decryption of PDCP packets. The COUNT monotonically increases according to the order in which PDCP packets are delivered to the lower layer, and in principle, PDCP SDUs are allocated in the order delivered from the upper layer. COUNT consists of HFN and PDCP SN. The PDCP SN is included in the header of the PDCP packet and transmitted, but the HFN is not explicitly transmitted. Therefore, the PDCP receiving device must determine the HFN of the received packet by itself. When the PDCP transmitting device complies with a predetermined condition (transmitted so that the out of order of the PDCP SN is less than half of the total sum of the serial numbers that can be indicated by the PDCP SN), the PDCP receiving device will receive the most recently. The serial number of one PDCP packet (received PDCP SN, see specification 36.323), the highest serial number received so far (Next_PDCP_RX_SN, see specification 36.323), a window with a predetermined size (Reordering_Window, see specification 36.323), now HFN is determined by using the highest serial number (Last_Submitted_PDCP_RX_SN, refer to standard 36.323) among the serial numbers transmitted to the upper layer. And, if a packet with a higher serial number than the received packet has already been delivered to the upper layer (that is, if the received packet has already been received or has been delayed), header decompression is performed on the received packet. Discard after carrying out. In more detail, when a packet is repeatedly received or delayed for an unspecified reason, since the packet may contain useful information for updating the header restoration context, the header is restored and then discarded. The process of determining the HFN follows as described in section 5.1.2.1.2 of 36.323.

Processing the PDCP PDU for which the HFN and COUNT are determined as a PDCP SDU means that the PDCP PDU is de-secreted and the header of the IP package stored in the PDCP PDU is restored, and details are as described in standard 36.323.

For convenience of explanation, the COUNT corresponding to Last_Submitted_PDCP_RX_SN is referred to as Last_Submitted_PDCP_RX_COUNT, the COUNT corresponding to the received PDCP SN is referred to as the received PDCP COUNT, and the COUNT corresponding to Next_PDCP_RX_SN is referred to as Next_PDCP_RX_COUNT. Last_Submitted_PDCP_RX_COUNT is the highest COUNT delivered to the upper layer (or the highest COUNT in order), the received PDCP COUNT is the COUNT of the received PDCP packet, and Next_PDCP_RX_COUNT is the sum of 1 to the highest COUNT among the COUNTs received so far. I assume.

The higher layer transfer condition 1 of PDCP operation 1 is as follows.

[Higher layer transmission condition 1 of PDCP operation 1]

When processing for a certain PDCP SDU [X] is completed in PDCP operation 1, the UE is the lowest non-received among the'SDUs with a COUNT lower than X'and'Not received COUNTs greater than X'among the PDCP SDUs stored in the buffer. SDUs with COUNT lower than COUNT are judged to have satisfied condition 1 and transferred to the upper layer. For example, when PDCP SDU [100] is received, PDCP SDU [90] ~ PDCP SDU [99], PDCP SDU [101] ~ PDCP SDU [110], PDCP [112] ~ PDCP [115] are stored in the PDCP buffer. PDCP SDU [100] and PDCP SDUs with a COUNT lower than that, PDCP SDU [90] ~ PDCP SDU [100] and PDCP SDU, the first unreceived PDCP SDU among PDCP SDUs with a COUNT higher than the PDCP SDU [100] PDCP SDU [101] ~ PDCP SDU [110], which are PDCP SDUs prior to SDU[111], satisfy condition 1 and are delivered to the upper layer, and PDCP SDU[112] ~ PDCP SDU [115] are kept stored in the buffer. . In PDCP operation 1 triggered by receiving a random PDCP PDU, the received PDCP SDU is unconditionally delivered to the upper layer, and PDCP SDUs satisfying condition 1 are also delivered to the upper layer.

The higher layer transfer condition 2 of PDCP operation 2 is as follows.

[Higher layer transmission condition 2 of PDCP operation 2]

In PDCP operation 2 triggered by receiving a random PDCP PDU, if the received PDCP SDU is a non-received PDCP SDU with the lowest COUNT (that is, if Received PDCP COUNT is equal to Last_Submitted_PDCP_RX_COUNT plus 1), including the received PDCP SDU. The next unreceived PDCP SDUs are delivered to the upper layer. If the received PDCP SDU is not a non-received PDCP SDU with the lowest COUNT, the PDCP SDU is stored in the PDCP buffer. In PDCP operation 3 triggered by receiving a random PDCP PDU, it checks whether there are SDUs that satisfy condition 3 among the PDCP SDUs stored in the PDCP buffer including the processed PDCP SDU, and only those SDUs that satisfy condition 3 are higher layer. To deliver.

Below, PDCP operation 3 and higher layer transfer condition 3 will be described.

[Higher layer transmission condition 3 of PDCP operation 3]

As illustrated in FIG. 9, in the single bearer 905 in which one logical channel is configured, the PDCP transmission device 910 performs RLC in the order of packet [1], packet [2], packet [3], and packet [4]. The packet is delivered to the transmission device 915. The packets are received by the RLC receiving device 920 through the MAC device and the radio channel. At this time, when an error occurs in the radio channel, retransmission/error recovery is performed through HARQ and ARQ, so the order of the packets received by the RLC receiving device 920 in this process is the order of the packets transmitted by the PDCP transmitting device 915 May be different from The RLC receiving device 920 rearranges the misaligned order again and transfers the rearrangement to the PDCP receiving device 925. For example, the RLC receiving device 920 delivers packets to the PDCP receiving device 925 in the order of packet [1], packet [2], packet [3], and packet [4].

In the case of the multi-bearer 930 in which two logical channels are configured, the PDCP transmission device 935 transmits a packet to the two RLC transmission devices 940 and 845. For example, the PDCP transmission device 935 forwards packets [1] and [3] to the first RLC transmission device 940 and packets [2] and [4] to the second RLC transmission device 945. do. The first RLC transmitting device 940 transmits a packet to the first RLC receiving device 950, and the second RLC transmitting device 945 transmits a packet to the second RLC receiving device 955. The first RLC reception device 950 rearranges the order of the received packets in the order in which the first RLC transmission device 940 receives packets from the PDCP transmission device 935. That is, the first RLC receiving device 950 delivers packets to the PDCP receiving device 960 in the order of packet [1] and packet [3]. Similarly, the second RLC receiving device 955 rearranges the order of the packets received in the order in which the second RLC transmitting device 945 received packets from the PDCP transmitting device 935. That is, the second RLC transmission device 945 delivers packets to the PDCP reception device 960 in the order of packet [2] and packet [4]. However, the order of packets transmitted by the first RLC receiving device 950 and the second RLC receiving device 955 is not aligned. For example, packets transmitted by the first RLC receiving apparatus 950 and the second RLC receiving apparatus 955 may be delivered in the order of packet [1], packet [2], packet [4], and packet [3]. It may be delivered in the order of packet [2], packet [4], packet [1], and packet [3]. Accordingly, the PDCP receiving device 960 needs to sort the order of packets transmitted by the two or more RLC receiving devices 950 and 855 once again.

In an embodiment of the present invention, it is determined whether the order reordering of any unreceived PDCP SDU [x] is satisfied as whether the order reordering condition 3 is satisfied. Condition 3 can be summarized as follows.

[Reorder condition 3 of arbitrary PDCP SDU [x]]

A PDCP SDU with a COUNT higher than X was received from both the MCG RLC and the SCG RLC, and the associated timer 1 has expired.

The timer 1 is driven when a PDCP SDU having a COUNT higher than x is received from the RLC SCG, and is intended to cope with an out-of-sequence reception phenomenon between the MeNB and the SeNB.

In the following description, the fact that the order of the random non-received PDCP SDU [x] is rearranged means that the SDU [x] is regarded as if it has been received because there is no possibility to receive the non-received SDU [x] anymore, and a subsequent operation is performed. Means that. When the order of the non-received SDUs [x] is rearranged, SDUs whose COUNT is between [x+1] and y among received PDUs having a COUNT higher than x are transferred to the upper layer, and Last_Submitted_PDCP_RX_COUNT is updated to y. The y is a value obtained by subtracting 1 from the COUNT of the first non-received PDCP SDU higher than x. For example, <Table 2> below shows whether the order is reordered and related operations in the PDCP receiving device.

MCG RLC SCG RLC Last_submitted_PDCP_RX_COUNT T1 timer PDCP operation t ₀ 10 t ₁ 11 11 Pass 11 to the upper layer t ₂ 13 11 Save [13] to the buffer; [12] SDU not received t ₃ 15 11 T1 timer operation related to [15] [13], [15] Save to buffer t ₄ 14 11 Save to buffer [13], [14], [15] t ₅ 15 T1 timer expiration [12] is considered to be no longer received. The first non-received COUNT higher than 12 is 16, so SDUs between 12 and 16 are delivered to the upper layer.

For example, if an SDU[11] is received from the MCG RLC at a certain time t1, the SDU is an ordered SDU, so it is transferred to an upper layer and a related variable is updated to 11.

Upon receiving the SDU[13] from the MCG RLC at any time t2, a non-received RLC SDU[12] occurs, and the UE stores the SDU [13] in the PDCP buffer.

After that, SDU[15] is received from the SCG RLC at an arbitrary time point t3. Since the COUNT of the SDU received from the SCG RLC is higher than the non-received COUNT, the UE drives the T1 timer. If a non-received PDU is not received before the T1 timer expires, it means that the non-received PDU is not received at least in the SCG RLC.

Thereafter, an SDU[14] is received from the SCG RLC at a random time t4, and a T1 timer related to the SDU[15] (or related to SDU[12]) expires at a random time t5. Since a COUNT higher than the not received COUNT was received from both the MCG RLC and the SCG RLC, and the related T1 timer has expired, the UE PDCP SDUs [13], [[13], [13], [ 14], [15] are transferred to the upper layer and Last_submitted_PDCP_RX_COUNT is updated to 15.

Timer 1 is the first in the SCG RLC among the'lowest counts received from SCG RLC among the COUNTs higher than the'not received COUNT'or'counts higher than the not received COUNT' when it is found that no PDCP SDU has been received as described above. It may be related to'Received COUNT'or'Not Received COUNT'. In the above example, the serial number of the unreceived SDU is 12, and the COUNT first received from the SCG RLC among the COUNTs higher than 12 is 15, so the timer 1 is 12 or timer 1 related to 15. The size of Timer 1 is large enough to cope with the order mixing that may occur between the MeNB and the SeNB, that is, a phenomenon in which a packet transmitted by the MeNB to the SeNB at an arbitrary time arrives at the SeNB before the packet transmitted immediately before the packet. When is referred to as a sequence shuffle phenomenon, the size of the timer 1 is determined so as to correspond to the maximum possible value of the difference between the reception time points of two packets in which the sequence shuffle occurs.

10 is a view for explaining the operation of the PDCP receiving device in the LTE system according to an embodiment of the present specification, which shows the operation when a PDCP receiving device of a multi-bearer receives a PDCP PDU from the RLC receiving device.

Referring to FIG. 10, in step 1005, a PDCP receiving device receives a PDCP PDU [x] from an RLC receiving device. In step 1010, the UE de-crypts the PDCP PDU [x], restores the header of the IP packet stored in the PDCP PDU [x], and reconfigures (or converts or restores) the IP packet into PDCP SDU [x]. If the PDCP SDU [x] is duplicated, it is discarded and waits until the next PDU is received. If the PDCP SDU [x] is not repeatedly received, the process proceeds to step 1015 and the PDCP SDU [x] is stored in the PDCP buffer according to the COUNT order. In step 1020, it checks whether the PDCP SDU [x] is received from the SCG RLC device, and if so, proceeds to step 1020, otherwise proceeds to step 1035. In step 1025, the UE has an unreceived SDU with a serial number lower than the SDU[x], and whether the SDU [x] is the first SDU received from the SCG RLC device after the unreceived SDU has occurred (or is driven in relation to the unreceived SDU) If there is no timer 1 in progress), the process proceeds to step 1030 if the above condition is satisfied, and if not, proceeds to step 1035. In step 1030, timer 1 is driven, and the timer is associated with a COUNT related to the not received SDU, for example, a received COUNT, a not received COUNT, or a value obtained by adding 1 to the received COUNT.

In step 1035, the PDCP receiving device checks whether there is an ordered SDU among SDUs stored in the PDCP buffer. For example, if SDU[x] is an unreceived SDU, the condition may be satisfied, and the process proceeds to step 1040 to deliver the ordered SDUs to the upper layer. The ordered SDUs can mean SDUs between'the highest COUNT delivered to the upper layer' or'the highest COUNT ordered' and the lowest among non-received COUNTs' before receiving the SDU [x]. have. The PDCP receiving device transmits the SDUs arranged in order in step 1040 to the upper layer in order.

In steps 1045 and 1050, the UE determines SDUs that are no longer likely to be received among the unreceived SDUs, and delivers the ordered SDUs among the SDUs after the SDUs that are no longer likely to be received to a higher layer. For this, it is determined whether condition 3 is satisfied. First, the UE checks whether there is a non-received SDU having a COUNT lower than the highest COUNT received from the SCG RLC and the highest COUNT received from the MCG RLC among the not received SDUs. For example, if the COUNT of not received SDU is 10, the highest COUNT received from MCG RLC is A, and the highest COUNT received from SCG RLC is B, if both A and B are higher than 10, the condition is met. If Rado is lower than 10, the condition does not hold. If the condition is satisfied, the process proceeds to step 1050, and if the condition is not satisfied, the process proceeds to step 1060. For convenience of explanation, the COUNT not received that satisfies the above condition is referred to as Y.

In step 1050, the terminal checks whether the timer 1 associated with the unreceived SDU or Y has already expired, and if so, proceeds to step _1055, otherwise proceeds to step 1060. In step 1055, the UE delivers predetermined SDUs to the upper layer and proceeds to step 1060. The predetermined SDUs are SDUs between'[Y+1'] and'the lowest COUNT among unreceived COUNTs higher than Y'. For example, if Y is 10 and the unreceived COUNT higher than 10 is 15, 20, 25, SDU [11], SDU[12], SDU[13], SDU[14] are transferred to the upper layer and the rest are stored in the PDCP buffer. Do it. And it is considered to be ordered at least up to SDU [14]. In step 1060, the UE waits until the next PDU is received or timer 1 expires.

FIG. 11 is a diagram for explaining an operation when timer 1 expires in the PDCP receiving apparatus of FIG. 10.

Referring to FIG. 11, in step 1105, timer 1 associated with any unreceived PDCP SDU [z] expires. At this time, the UE considers that the possibility that the PDCP SDU [z] is not received due to the sequence mixing phenomenon between the MeNB and the SeNB is extinguished. That is, when a COUNT higher than z is received from the MCG RLC, the subsequent operation is performed as if the SDU[z] was received.

In step 1110, the UE checks whether the highest COUNT received from the SCG RLC and the highest COUNT received from the MCG RLC are higher than z. Since the timer 1 associated with the non-received SDU z is started when a PDCP SDU having a COUNT higher than z is received from the SCG RLC, only the highest COUNT received from the MCG RLC is higher than z in step 1110. If the condition is satisfied in step 1110, it is determined that the unreceived SDU [z] is no longer likely to be received, and SDUs immediately before the next unreceived SDU with a COUNT higher than z among SDUs having a COUNT higher than z are delivered to the upper layer, The order is considered to be sorted up to the highest COUNT among SDUs delivered to the upper layer. In step _1120, the UE waits until the next PDU is received or the timer 1 associated with another non-received SDU expires.

In the present invention, the PDCP receiving the PDCP PDU from the MCG RLC has the same meaning as receiving the PDCP PDU reconstructed from the data received from the MCG serving cell or from the MCG-MAC. When the PDCP receives the PDCP PDU from the SCG RLC, it has the same meaning as receiving the PDCP PDU reconstructed from the data received from the SCG serving cell or from the SCG-MAC.

As another operation of rearranging the order of PDCP PDUs according to an embodiment of the present invention, when reconfigured from a single bearer to multiple bearers, a timer-based reordering is performed, while when reconfigured from a multi-bearer to a single bearer, reordering is performed using a timer. A method of determining a time point to stop the operation and using the same timer as the two timers for performing the sequence rearrangement and determining the stop time is presented.

20 is a diagram illustrating a terminal operation when resetting a bearer according to an embodiment of the present invention.

Referring to FIG. 20, in step 2005, the UE applies PDCP device operation 1 to bearer x, which is a single bearer. In step 2010, a control message for resetting the bearer x to multiple bearers is received. In step 2015, the UE creates a Secondary Cell Group (SCG) RLC device to be connected with the multi-bearer according to the configuration information indicated in the control message, and then connects it with the PDCP device. The terminal proceeds to step 2020 and switches the operation of the PDCP device from operation 1 to operation 4. In other words, the UE applies PDCP operation 4, which determines whether or not to transfer to a higher layer after checking for reordering from the first PDCP PDU received after being reconfigured to a multi-bearer. Thereafter, the UE converts the PDCP PDUs into PDCP SDUs by applying PDCP operation 4 to the PDCP PDUs of the reset bearer, and performs an operation of transferring the ordered PDCP SDUs to a higher layer. In determining whether the order is arranged, the terminal uses timer 3.

When receiving a control message instructing to reset the multi-bearer to a single bearer in step 2025, the UE proceeds to step 2030 to release the SCG RLC, switch PDCP operation 4 to PDCP operation 5, and drive timer 3. The UE performs PDCP operation 5 while timer 3 is running, and stops PDCP operation 5 when timer 3 expires in step 2035 and switches to PDCP operation 1.

The PDCP operations 1, 4, and 5 may be understood as listing various detailed operations to be applied to the PDCP PDU delivered from the RLC device in a series of order. In Table 3 below, detailed actions constituting these actions and their sequence are listed. The following detailed operations are performed in the order from top to bottom.

PDCP operation 1 PDCP operation 4 PDCP operation 5 Receive PDCP PDU Receive PDCP PDU Receive PDCP PDU PDCP PDU HFN/COUNT determination. Discard if PDU received duplicate PDCP PDU HFN/COUNT determination. Discard if PDU received duplicate PDCP PDU HFN/COUNT determination. Discard if PDU received duplicate PDCP PDU is processed as PDCP SDU PDCP PDU is processed as PDCP SDU PDCP PDU is processed as PDCP SDU Delivering the PDCP SDU and PDCP SDUs that satisfy the higher layer transfer condition 1 to the upper layer. The rest is stored in the buffer The PDCP SDU that satisfies the upper layer delivery condition 4 is delivered to the upper layer. The remaining SDUs are stored in the PDCP buffer Save PDCP SDU to PDCP buffer. Deliver PDCP SDUs that satisfy higher layer delivery condition 5 to higher layers. The remaining SDUs are stored in the PDCP buffer.

[Higher layer delivery condition 5 of PDCP operation 5]

In PDCP operation 5, which is applied while timer 3 is running, if the serial number of the received PDCP SDU is the lowest serial number/count not received PDCP SDU (that is, if the received PDCP SN is equal to Last_Submitted_PDCP_RX_SN plus 1), the received PDCP SDUs of consecutive serial numbers/COUNTs, including SDUs, up to the next unreceived PDCP SDU are delivered to the upper layer. If the received PDCP SDU is not a non-received PDCP SDU of the lowest serial number, the PDCP SDU is stored in the PDCP buffer. And when timer 3 expires, all PDCP SDUs currently stored in the PDCP buffer are transferred to the upper layer in COUNT order, and the serial number of the last transmitted PDCP SDU is stored in Last_Submitted_PDCP_RX_SN.

For convenience of description below, the serial number below is used interchangeably with COUNT.

[Higher layer transmission condition 4 of PDCP operation 4]

If the serial number of the received PDCP SDU is the lowest non-received PDCP SDU (that is, if the received PDCP SN is equal to Last_Submitted_PDCP_RX_SN plus 1), SDUs continuously received up to the next unreceived PDCP SDU including the received PDCP SDU Pass them to the upper layer. If the received PDCP SDU is not a non-received PDCP SDU of the lowest serial number, the PDCP SDU is stored in the PDCP buffer. If timer 3 is running, it waits until the next PDCP PDU is received. If timer 3 is not running, timer 3 is driven, and a COUNT that is 1 higher than the highest count among the PDCP SDUs received at that time is stored in Reordering_PDCP_RX_COUNT. When timer 3 expires, PDCP SDUs with a COUNT lower than Reordering_PDCP_RX_COUNT and PDCP SDUs associated with consecutive COUNTs higher than Reordering_PDCP_RX_COUNT are delivered to the upper layer. For example, if Reordering_PDCP_RX_COUNT is N and a PDCP SDU with COUNT is N+M is not received, and all PDCP SDUs between N and [N+M] are stored in the PDCP buffer, when timer 3 expires, the PDCP buffer is Among the stored SDUs, all PDCP SDUs with a COUNT lower than N and all PDCP SDUs with a COUNT between them including N and [N+M-1] are delivered to the upper layer. Then, the serial number of the last transmitted PDCP SDU is stored in Last_Submitted_PDCP_RX_SN.

21 is a diagram illustrating an operation of a PDCP receiving apparatus operating as a multi-bearer according to an embodiment of the present invention. This shows the operation of the PDCP receiving device that has received a packet from the RLC receiving device.

Referring to FIG. 21, in step 2105, a PDCP receiving device receives a PDCP PDU [x] from an RLC receiving device. In step 2110, the PDCP receiving device determines the Hyper Frame Number (HFN) of the received packet using the serial number (Received PDCP SN), Next_PDCP_RX_SN, Reordering_Window, Last_Submitted_PDCP_RX_SN, etc. of the received packet. The PDCP receiving apparatus concatenates the determined HFN and the received PDCP SN to calculate a COUNT associated with the PDCP packet. Then, the PDCP PDU [x] is descrambled by applying the COUNT, and the header of the IP packet stored in the PDCP PDU [x] is restored and reconfigured (or converted or restored) into PDCP SDU [x]. If the PDCP SDU [x] is duplicated, it is discarded and waits until the next PDU is received. If the PDCP SDU [x] is not repeatedly received, the process proceeds to step 2115 and the PDCP SDU [x] is stored in the PDCP buffer according to the COUNT order.

In step 2120, the PDCP receiving apparatus checks whether the received packet is an unreceived packet having the lowest COUNT. If the following conditions are satisfied, it is the unreceived packet with the lowest COUNT, and proceeds to step 2130. If the following conditions are not satisfied, proceeds to step 2125 and waits until the next PDCP PDU is received.

[Condition to determine whether the received packet is a non-received packet with the lowest COUNT]

Received PDCP SN = Last_Submitted_PDCP_RX_SN + 1; or

received PDCP SN = Last_Submitted_PDCP_RX_SN-Maximum_PDCP_SN

In step 2130, the PDCP receiving device transfers the PDCP SDUs associated with successive COUNTs to the upper layer in COUNT order starting from the COUNT of the received PDCP SDU among the PDCP SDUs stored in the PDCP buffer, and finally delivers Last_Submitted_PDCP_RX_SN. It is set with the serial number of the PDCP SDU. For example, PDCP SDUs with COUNTs [M], [M+1], [M+2], [M+4], and [M+5] are stored in the PDCP buffer, and PDCP with COUNT [M-1] When the SDU is received, the PDCP receiving device delivers PDCP SDUs with COUNTs of [M-1], [M], [M+1], and [M+2] to the upper layer.

In step 2135, after performing the above operation, the PDCP receiving apparatus checks whether at least one PDCP SDU is still stored in the PDCP buffer in an unordered state. If yes, proceed to step 2140, otherwise proceed to step 2125.

In step 2140, the PDCP receiving apparatus checks whether timer 3 is running, and if so, proceeds to step 2125, and if not, proceeds to step 2145.

In step 2145, the PDCP receiving apparatus drives timer 3 and sets Reordering_PDCP_RX_COUNT to a value that connects RX_HFN and Next_PDCP_RX_SN. In other words, a value 1 higher than the highest COUNT received so far is stored in Reordering_PDCP_RX_COUNT, and the PDCP receiving device proceeds to step 2125.

22 is a diagram illustrating an operation of a PDCP receiving device to switch to PDCP operation 5 when resetting from a multi-bearer to an MCG bearer according to an embodiment of the present invention.

MCG (Master Cell Group) bearer is a bearer in which data is transmitted and received only through MCG among single bearers. When a PDCP receiving device performing a dual connectivity operation releases the SeNB and the SCG for reasons such as leaving the area of the serving base station (SeNB), the multi-bearer may be reset to the MCG bearer.

Referring to FIG. 22, in step 2205, the PDCP receiving apparatus receives a control message instructing to reset the multi-bearer to the MCG bearer. The control message may be, for example, explicitly instructing to reset the multi-bearer to an MCG bearer, or may be a control message for releasing the last SCG cell although not an explicit reset command.

In step 2210, the PDCP receiving device releases the SCG-RLC of the multi-bearer, and all of the RLC packets stored in the RLC that can be assembled into a PDCP PDU are assembled into a PDCP PDU, and then transferred to the PDCP receiving device.

In step 2215, the PDCP receiving apparatus checks whether timer 3 is currently running. Step 2215 may be performed as soon as the interpretation of the control message indicating MCG bearer switching is completed, or may be performed when a PDCP PDU is received from the released SCG-RLC.

If the timer 3 is not running, the process proceeds to step 2225, and if the timer 3 is already running, the process proceeds to step 2220. In step 2220, various operations are possible. The PDCP receiving device performs one of the following operations 1) to 3).

1) Stop currently running Timer 3, restart Timer 3, and proceed to 2230

2) Wait for the currently running Timer 3 to expire, restart Timer 3 and proceed to 2230

3) If a PDCP PDU is received from the released SCG-RLC, stop the currently running timer 3, restart the timer 3, and proceed to 2230. If a PDCP PDU is not received from the released SCG-RLC, the currently running timer 3 is maintained as it is, and the current running timer 3 is not proceeded to step 2230, and when the currently running timer 3 expires, the PDCP operation 1 is switched.

In step 2225, several actions are possible. The PDCP receiving device performs one of the following operations a) and b).

a) Start timer 3 and proceed to 2230

b) If a PDCP PDU is received from the released SCG-RLC, start timer 3 and proceed to 2230. If a PDCP PDU is not received from the released SCG-RLC, immediately switch to PDCP operation 1 without proceeding to step 2230

In step 2230, the PDCP receiving device waits until timer 3 expires, and when timer 3 expires, it delivers all the PDCP SDUs currently stored in the PDCP buffer to the upper layer in COUNT order, and the last transmitted SDU sequence. Set Last_Submitted_PDCP_RX_SN as the number. Then, it switches to PDCP operation 1.

23 is a diagram illustrating an operation of a PDCP receiving apparatus when timer 3 expires according to an embodiment of the present invention.

Referring to FIG. 23, in step 2305, timer 3 of a PDCP receiving apparatus of a bearer expires.

In step 2310, the PDCP receiving device checks whether the bearer is a multi-bearer or an MCG bearer. If it is a multi-bearer, it proceeds to step 2315, and if it is an MCG bearer, it proceeds to step 2320. Proceeding to step 2320 means that the bearer has been reconfigured from a multi-bearer to an MCG bearer, and since timer 3 has expired, all the PDCP SDUs currently stored in the PDCP buffer are transferred to the upper layer in order to terminate PDCP operation 5 and switch to PDCP operation 1. To deliver.

Proceeding to step 2315 means that the PDCP operation 4 is being operated, and the PDCP receiving device is based on the Reordering_PDCP_RX_COUNT among the PDCP SDUs stored in the PDCP buffer, and continues from all PDCP SDUs with a COUNT lower than Reordering_PDCP_RX_COUNT and Reordering_PDCP_RX_COUNT. All PDCP SDUs associated with COUNT are delivered to the upper layer. In other words, PDCP SDUs corresponding to the conditions of <Table 4> below are delivered to the upper layer.

-all stored PDCP SDU(s) with an associated COUNT value less than Reordering_PDCP_RX_COUNT;
-all stored PDCP SDU(s) with consecutively associated COUNT value(s) starting from Reordeing_PDCP_RX_COUNT;

In step 2325, the PDCP receiving device updates Last_Submitted_PDCP_RX_SN and proceeds to step 2330. In step 2330, the PDCP receiving apparatus checks whether at least one PDCP SDU remains in the PDCP buffer, and if it remains, proceeds to step 2335, and if not, proceeds to step 2340.

In step 2335, the PDCP receiving apparatus drives timer 3 and sets Reordering_PDCP_RX_COUNT to a value that connects RX_HFN and Next_PDCP_RX_SN.

In step 2340, it waits until the next PDCP PDU arrives.

As shown in the above embodiment, in determining whether the received PDCP SDU is a non-received SDU, the PDCP receiving device uses a variable managed by the PDCP SDU serial number, and determines the PDCP SDU to be transferred to the upper layer after timer 3 expires. In this case, a variable managed by COUNT is used.

As another operation of rearranging the order of PDCP PDUs according to an embodiment of the present invention, when a bearer configuration is reconfigured from a single bearer to multiple bearers, a timer-based order rearrangement is performed, while a timer is used when reconfigured from a multi-bearer to a single bearer. Thus, a time point at which the reordering operation is to be stopped is determined, and a method of using the amount of data stored in the reordering buffer and whether a lower layer is re-established to determine the stop time point is presented.

24 is a diagram illustrating a terminal operation when resetting a bearer according to an embodiment of the present invention.

Referring to FIG. 24, in step 2405, the UE applies PDCP device operation 6 to bearer x, which is a single bearer. In step 2410, a control message for resetting the bearer x to multiple bearers is received. In step 2415, the UE creates an SCG (Secondary Cell Group) RLC device to be connected to the multi-bearer according to the configuration information indicated in the control message, and then connects it with the PDCP device. The terminal proceeds to step 2420 and switches the operation of the PDCP device from operation 6 to operation 7. Operation 6 will be described later. In other words, the UE applies PDCP operation 7 in order from the first PDCP PDU received after being reset to a multi-bearer, and operation 7 will be described later. Thereafter, the UE applies PDCP operation 7 to the PDCP PDUs of the bearer reset to the multi-bearer, checks whether the order of received PDCP PDUs is reordered, converts the ordered PDCU PDUs into PDCP SDUs to a higher layer. Perform the transfer operation. In determining whether the order is arranged, the terminal uses timer 3.

In step 2425, when the UE receives a control message instructing to reset the multi-bearer to a single bearer, the UE proceeds to step 2430 to release the SCG RLC. PDCP PDUs out of order due to the SCG RLC release are delivered to the PDCP device, and the PDCP device continues to apply operation 7 to the PDCP PDUs. The operation 7 is applied until the reordering stop condition is satisfied, and if the reordering stop condition is satisfied, the process proceeds to step 2435, and whether the reordering stop condition is'lower layer re-establishment' or'no sequence unsorted packets'. Cognitive test. If it is due to the absence of unsorted packets, the process proceeds to step 2440 to switch to operation 6 of the PDCP device and ends the process. If it is due to re-establishment of lower layers, proceed to step 2445. The lower layer is an MCG-RLC device. Or, since it has already switched to a single bearer, the PDCP device is connected to only one RLC device, and the only RLC device is re-established. In step 2445, the UE sorts the PDCP PDUs currently stored in the reordering buffer and the PDCP PDUs delivered to the lower layer re-establishment in the order of COUNT, processes them as PDCP SDUs in the order of COUNT, and then switches to operation 6 of the PDCP device. After the process ends. At this time, the PDCP device processes the PDCP PDUs stored in the reordering buffer as if they were PDCP PDUs delivered due to re-establishment of the lower layer.

The PDCP operations 6 and 7 can be understood as listing various detailed operations to be applied to the PDCP PDU delivered from the RLC device in a series of order. In Table 5 below, detailed actions constituting these actions and their sequence are listed. The following detailed operations are performed in the order from top to bottom.

PDCP operation 6 PDCP operation 7 Receive PDCP PDU Receive PDCP PDU PDCP PDU HFN/COUNT determination. Duplicate received PDU is processed as PDCP SDU and discarded PDCP PDU HFN/COUNT determination. PDCP PDU is processed as PDCP SDU PDCP PDUs that satisfy the higher layer transfer condition 7 are processed as PDCP SDUs and delivered to higher layers. The remaining PDUs are stored in the PDCP buffer. Delivering the PDCP SDU and PDCP SDUs that satisfy the higher layer transfer condition 1 to the upper layer. The rest is stored in the buffer

In PDCP operation 6, it is determined whether or not duplicate reception is detected, but in PDCP operation 7, it is not checked for duplicate reception. This is because, when PDCP operation 6 is applied, there is a possibility that packets that have already been received after handover may be repeatedly received, but there is no such possibility in PDCP operation 7. The redundantly received PDU is processed as an SDU prior to discarding, in order to update the header restoration context. In a situation in which the PDCP operation 7 is applied, there is no need to perform an operation of determining duplicated packets, processing them as SDUs, and discarding them.

In PDCP operation 6, after processing received PDUs as SDUs, the ordered SDUs are stored in the buffer and the ordered SDUs are transferred to the upper layer, whereas in PDCP operation 7, the order of received PDUs is determined. First of all, only if the ordered PDU is an ordered PDU, it is processed as an SDU and transferred to a higher layer, and PDUs that are not ordered are stored in a buffer in a PDU state.

This is because if the PDCP operation 6 is applied, when packet [X] is received, packets with a serial number lower than packet [X] are no longer received. Although it does not occur, if the PDCP operation 7 is applied, packets whose order is not aligned can be received at all times. Therefore, it is possible to prevent a header restoration operation error only after ordering the order and processing it as an SDU.

Higher layer delivery condition 7 of PDCP operation 7 targets PDCP PDUs instead of PDCP SDUs, and higher layer delivery condition 4 and higher layer delivery condition 4, except that packets that satisfy the condition are not delivered to the upper layer but are delivered to the PDCP PDU processing unit. same.

[Higher layer delivery condition 7 of PDCP operation 7]

If the serial number of the received PDCP PDU is the lowest non-received PDCP PDU (i.e., if the received PDCP SN is equal to Last_Submitted_PDCP_RX_SN plus 1), the PDU that has been continuously received up to the next non-received PDCP PDU including the received PDCP PDU These are delivered to a processing device (eg, a header recovery device, a de-scrambler device). The defragmentation device refers to a device that dechipering the received PDCP PDU. The PDUs are processed as SDUs in the processing device and then delivered to an upper layer. If the received PDCP PDU is not a non-received PDCP PDU with the lowest serial number, the PDCP PDU is stored in the PDCP buffer. If timer 3 is running, it waits until the next PDCP PDU is received. If timer 3 is not running, timer 3 is driven, and a COUNT that is 1 higher than the highest COUNT among the PDCP PDUs received at that time is stored in Reordering_PDCP_RX_COUNT. When timer 3 expires, PDCP PDUs with a COUNT lower than Reordering_PDCP_RX_COUNT and PDCP PDUs associated with a consecutive COUNT higher than Reordering_PDCP_RX_COUNT are delivered to the processing device. Then, the serial number of the last transmitted PDCP SDU is stored in Last_Submitted_PDCP_RX_SN.

When multiple bearers are reset to a single bearer, the PDCP operation must be switched from operation 7 to operation 6. In an embodiment of the present invention, after being reset to a single bearer, the PDCP device continues to apply PDCP operation 7 until the reordering stop condition is satisfied, but when the reordering stop condition is satisfied, it switches to PDCP operation 6. The reordering condition is satisfied when a lower layer is reestablished or when there are no more PDUs to reorder.

The lower layer re-establishment may occur, for example, when a terminal operating as a single bearer is instructed to handover. In this case, all PDCP PDUs stored in the MCG-RLC device whose order is not aligned are delivered to the PDCP receiving device, and the UE is delivered from the lower layer and PDCP PDUs whose order is currently stored in the PDCP buffer. After the PDCP PDUs are sequentially processed according to the COUNT order, the ordered SDUs are transferred to the upper layer, the ordered SDUs are stored in the buffer, and PDUs received from the newly set lower layer are stored. Switches to operation 6 of the PDCP device, which determines SDUs to be delivered to the upper layer based on the serial number.

The fact that there are no more PDUs to rearrange the sequence means that as a result of the sequence rearrangement operation using timer 3, timer 3 associated with the unreceived PDUs expires and PDUs that were considered out of order by the non-received PDUs. As a result of processing as SDUs and transferring them to a higher layer, there may be a case where no more unreceived PDUs exist. For example, if the value obtained by adding 1 to Last_Submitted_PDCP_RX_SN becomes equal to Next_PDCP_RX_SN, it means that there are no more unreceived PDUs, or that there are no more unordered PDUs. Since the above condition is satisfied means that no more PDUs are stored in the PDCP buffer, the PDCP receiving device immediately switches to operation 6 of the PDCP device.

Since the PDCP operation 7 is the same as the PDCP operation 4 shown in FIG. 25 except for the following, a detailed description thereof will be omitted.

25 is a diagram illustrating a PDCP operation 7 of a PDCP receiving apparatus operating as a multi-bearer according to an embodiment of the present invention. The embodiment of FIG. 25 shows an operation of a PDCP receiving device receiving a packet from an RLC receiving device. Referring to FIG. 25, in step 2505, a PDCP receiving device receives a PDCP PDU [x] from an RLC receiving device. In step 2510, the PDCP receiving device determines the Hyper Frame Number (HFN) of the received packet using the serial number (Received PDCP SN), Next_PDCP_RX_SN, Reordering_Window, Last_Submitted_PDCP_RX_SN, etc. of the received packet. The PDCP receiving apparatus concatenates the determined HFN and the received PDCP SN to calculate a COUNT associated with the PDCP packet. Then, by applying the COUNT, it is checked whether the received packet is a non-received packet having the lowest COUNT.

In step 2520, if the following conditions are satisfied, the PDCP receiving apparatus is a non-received packet with the lowest COUNT, and proceeds to step 2530, and if the following conditions are not satisfied, proceeds to step 2525 and waits until the next PDCP PDU is received.

[Condition to determine whether the received packet is a non-received packet with the lowest COUNT]

Received PDCP SN = Last_Submitted_PDCP_RX_SN + 1; or

received PDCP SN = Last_Submitted_PDCP_RX_SN-Maximum_PDCP_SN

In step 2530, the PDCP receiving device processes the PDCP PDUs associated with consecutive COUNTs starting from the COUNT of the received PDCP PDU among the PDCP PDUs stored in the PDCP buffer as PDCP SDUs in the COUNT order, and delivers them to the upper layer. , Last_Submitted_PDCP_RX_SN is set as the serial number of the last transmitted PDCP SDU. For example, PDCP PDUs with COUNTs [M], [M+1], [M+2], [M+4], and [M+5] are stored in the PDCP buffer, and PDCP with COUNT [M-1]. When a PDU is received, the PDCP receiving device transfers the PDCP PDUs with COUNTs of [M-1], [M], [M+1], and [M+2] to the next processing device, converts them into PDCP SDUs, and To deliver. In step 2535, after performing the above operation, the PDCP receiving apparatus checks whether at least one PDCP PDU is still stored in the PDCP buffer in an unordered state. If so, proceed to step 2540, otherwise proceed to step 2525.

In step 2540, the PDCP receiving apparatus checks whether timer 3 is running, and if so, proceeds to step 2525, and if not, proceeds to step 2545. In step 2545, the PDCP receiving apparatus drives timer 3 and sets Reordering_PDCP_RX_COUNT to a value that connects RX_HFN and Next_PDCP_RX_SN. In other words, a value 1 higher than the highest COUNT received so far is stored in Reordering_PDCP_RX_COUNT. Then, the PDCP receiving device proceeds to step 2525.

26 is a diagram illustrating an operation of a PDCP receiving apparatus when timer 3 expires according to an embodiment of the present invention.

Referring to FIG. 26, in step 2605, timer 3 of a PDCP receiving device of an arbitrary bearer expires. In step 2615, the PDCP receiving device sequentially performs PDCP PDUs associated with consecutive COUNTs from all PDCP PDUs with a COUNT lower than Reordering_PDCP_RX_COUNT and Reordering_PDCP_RX_COUNT based on Reordering_PDCP_RX_COUNT among the PDCP PDUs stored in the PDCP buffer according to the COUNT order. After processing as SDU, it is delivered to the upper layer. In other words, PDCP PDUs corresponding to the conditions in <Table 6> below are processed as PDCP SDUs and then delivered to the upper layer.

-all stored PDCP PDU(s) with an associated COUNT value less than Reordering_PDCP_RX_COUNT;
-all stored PDCP PDU(s) with consecutively associated COUNT value(s) starting from Reordeing_PDCP_RX_COUNT;

In step 2625, the PDCP receiving device updates Last_Submitted_PDCP_RX_SN and proceeds to step 2630. In step 2630, the PDCP receiving device checks whether at least one PDCP PDU remains in the PDCP buffer, and if it remains, proceeds to step 2635, and if not, proceeds to step 2640. In step 2630, the PDCP receiving device starts timer 3, RX_HFN and Next_PDCP_RX_SN Reordering_PDCP_RX_COUNT is set as the value concatenated. In step 2640, it waits until the next PDCP PDU arrives.

As another operation of rearranging the order of PDCP PDUs according to an embodiment of the present invention, a method of reconfiguring a bearer configuration from a single bearer to multiple bearers to operate as a multiple bearer is proposed. In this embodiment, when the UE is reconfigured as a multi-bearer, PDUs in the ordered order among the received PDCP PDUs are processed as PDCP SDUs and delivered to the upper layer, and PDCP PDUs out of order are processed as half PDCP SDUs. , Store in the buffer until the order is sorted. In addition, when the order of the PDCP PDUs stored in the buffer is aligned, the UE converts the half PDCP SDUs into PDCP SDUs and transfers them to the upper layer. The PDCP processing operation includes deciphering and header decompression, and when the above-described procedure is completed, the received PDCP PDUs become PDCP SDUs. Here, the half PDCP SDU refers to a packet in which only part of the PDCP processing operation is applied to the PDCP PDU, and is de-secreted but not header recovery.

Defragmenting packets received from the multi-bearer and storing them in the reordering buffer means that if the SCG of the terminal is changed, the defragmentation key may be changed, and at this time, the PDCP PDUs that have not yet been defragmented to the PDCP device are reordered. If it is stored for, the complexity of applying different security keys to the previous PDCP PDU and the newly received PDCP PDU occurs.

28 is a diagram illustrating a terminal operation when resetting a bearer according to an embodiment of the present invention.

Referring to FIG. 28, in step 2805, the UE applies PDCP device operation 6 to bearer x, which is a single bearer. In step 2810, the UE receives a control message for resetting the bearer x to a multi-bearer. In step 2815, the UE creates a Secondary Cell Group (SCG) RLC device to be connected with the multi-bearer according to the configuration information indicated in the control message, and then connects it with the PDCP device. The terminal proceeds to step 2820 and switches the operation of the PDCP device from operation 6 to operation 8. In other words, the UE applies PDCP operation 8 in order from the first PDCP PDU received after being reconfigured to a multi-bearer.

Specifically, the UE applies PDCP operation 8 to the PDCP PDUs of the bearer reconfigured to the multi-bearer, and the ordered PDCP PDUs among the received PDCP PDUs are processed as PDCP SDUs and delivered to the upper layer, and the order is aligned. PDCP PDUs that have not yet been converted are converted into the above-described half PDCP SDUs and stored in the PDCP reordering buffer, and timer 3 is started if necessary.

Thereafter, in step 2825, when the UE receives a control message instructing to reset the multi-bearer to a single bearer, the UE proceeds to step 2830 to release the SCG RLC. PDCP PDUs out of order due to the SCG RLC release are transferred to the PDCP device, and the PDCP device continues to apply operation 8 to the PDCP PDUs. The operation 8 is applied until the reordering stop condition is satisfied, and if the reordering stop condition is satisfied, the process proceeds to step 2835, and the reordering stop condition is'lower layer re-establishment' or'the absence of unsorted packets'. Cognitive test. If the reordering stop condition in step 2835 is due to the absence of unsorted packets, the terminal proceeds to step 2840, switches to operation 6 of the PDCP device, and ends the process. If the reordering stop condition in step 2835 is due to re-establishment of a lower layer, the terminal proceeds to step 2845. Here, the lower layer is, for example, an MCG-RLC device. Alternatively, since it has already switched to a single bearer, the PDCP device is connected to only one RLC device, and the only RLC device may be the lower layer. In step 2845, the UE checks whether there is a PDCP PDU or a half PDCP SDU in which the order is aligned by referring to the serial number or COUNT of the PDCP PDUs delivered by the lower layer re-establishment and the half PDCP SDUs stored in the sequence rearrangement buffer. , If there is a PDCP PDU or half PDCP SDU in order, the required PDCP processing operation is applied and converted into a PDCP SDU, and then transferred to the upper layer according to the COUNT order. In addition, half PDCP SDUs and PDCP PDUs that are not in order are converted into PDCP SDUs and stored in the PDCP order rearrangement buffer according to the COUNT order. In this case, it is also possible to store the unordered PDCP SDUs in the PDCP reorder buffer in which the half PDCP SDUs were stored. In some cases, half PDCP SDUs and PDCP SDUs may be stored in the same storage space.In this case, half PDCP SDUs are not stored for each half PDCP SDU, and PDCP SDUs are not stored for each PDCP SDU, but together according to the COUNT order. Then, it switches to PDCP operation 6.

Meanwhile, the presence of a PDCP PDU or half PDCP SDU in order in step 2845 is the same as the existence of a PDCP PDU or a half PDCP SDU having a serial number higher than Last_Submitted_PDCP_RX_SN among the PDCP PDUs or half PDCP SDUs.

The PDCP operations 6 and 8 can be understood as listing various detailed operations to be applied to the PDCP PDU delivered from the RLC device in a series of order. In Table 7 below, detailed operations constituting the PDCP operation 6 and operation 8 and their sequence are illustrated. And detailed operations in the following <Table 7> are performed in the order from top to bottom.

PDCP operation 6 PDCP operation 8 Receive PDCP PDU Receive PDCP PDU PDCP PDU HFN/COUNT determination. Duplicate received PDU is processed as PDCP SDU and discarded PDCP PDU HFN/COUNT determination. Duplicate received PDUs are discarded without processing them as PDCP SDUs PDCP PDU is processed as PDCP SDU PDCP PDUs are processed as half PDCP SDUs Delivering the PDCP SDU and PDCP SDUs that satisfy the higher layer transfer condition 1 to the upper layer. The rest is stored in the buffer The half PDCP SDU that satisfies the upper layer transfer condition 8 is processed as a PDCP SDU and delivered to the upper layer. The remaining half PDCP SDUs are stored in the PDCP buffer.

In PDCP operation 6, after processing the received PDUs as SDUs, the UE stores the unsorted SDUs in the buffer and delivers the ordered SDUs to the upper layer, whereas in PDCP operation 8, the received PDUs are predetermined. It is determined whether the order is arranged after converting to half PDCP SDU by applying only the PDCP processing process (for example, dechipering). In addition, the UE processes only the ordered half PDCP SDUs as PDCP SDUs by applying the remaining PDCP processing (e.g., header restoration) and delivers them to the upper layer, and the half PDCP SDUs that are not ordered are transferred to the half PDCP SDU state. Save it to the buffer.

The following upper layer transfer condition 8 of the PDCP operation 8 targets the half PDCP SDU instead of the PDCP SDU, and the packet satisfying the condition is not delivered to the first PDCP processing unit (deciphering unit), but the second PDCP processing unit (header restoration) It is the same as the higher layer transfer condition 7 except that it is transferred to the device). In some cases, the PDCP receiving device may store not only the unordered half PDCP SDUs but also the unordered PDCP SDUs. In this case, the PDCP receiving device considers not only the half PDCP SDU but also the PDCP SDU in applying the higher layer transfer condition 8.

[Higher layer delivery condition 8 of PDCP operation 8]

If the serial number of the received PDCP PDU is the serial number of the unreceived PDCP PDU with the lowest serial number (i.e., if the received PDCP SN is equal to the value of Last_Submitted_PDCP_RX_SN plus 1), the received PDCP PDU (or half PDCP corresponding thereto) SDU) to the next unreceived PDCP PDU (or a corresponding half PDCP SDU) to the next PDCP processing unit (eg, a header recovery unit). The half PDCP SDUs are processed as PDCP SDUs in the next PDCP processing device and then delivered to an upper layer. If the received PDCP PDU is not a non-received PDCP PDU with the lowest serial number, the PDCP PDU is processed as a half PDCP SDU and stored in the PDCP buffer. In addition, if Timer 3 is running, the UE waits until the next PDCP PDU is received. If Timer 3 is not running, it drives Timer 3 and stores a COUNT that is 1 higher than the highest COUNT among the PDCP PDUs received at that time in Reordering_PDCP_RX_COUNT. do. When timer 3 expires, half PDCP SDUs with a COUNT lower than Reordering_PDCP_RX_COUNT and half PDCP SDUs associated with consecutive COUNTs higher than Reordering_PDCP_RX_COUNT are delivered to the next PDCP processing device (for example, a header recovery device). In addition, the PDCP SDUs processed by the header recovery device are transmitted to the upper layer, and the serial number of the last transmitted PDCP SDU is stored in Last_Submitted_PDCP_RX_SN.

When multiple bearers are reset to a single bearer, the PDCP operation must be switched from operation 8 to operation 6. In an embodiment of the present invention, the PDCP processing apparatus continues to apply PDCP operation 8 until the reordering stop condition is satisfied after being reset to a single bearer, but switches to PDCP operation 6 when the reordering stop condition is satisfied. The reordering condition is satisfied when a lower layer is reestablished or when there are no more PDUs to reorder.

The lower layer re-establishment may occur, for example, when a terminal operating as a single bearer is instructed to handover. In this case, all of the PDCP PDUs stored in the MCG-RLC device whose order is not aligned are delivered to the PDCP receiving device, and the UE currently stores half PDCP SDUs in the PDCP buffer and the order of the unordered half PDCP SDUs in the lower layer. The delivered PDCP PDUs are sequentially processed as PDCP SDUs according to the COUNT order, the ordered SDUs are delivered to the upper layer, the ordered SDUs are stored in the buffer, and the PDUs received from the newly set lower layer Switches to operation 6 of the PDCP device, which determines SDUs to be delivered to the upper layer based on their serial numbers.

On the other hand, the fact that there are no more PDUs to rearrange the order means that as a result of the order rearrangement operation using timer 3, timer 3 associated with the unreceived PDUs expired and the order was considered to be unsorted by the not received PDUs. As a result of processing PDCP SDUs as SDUs and transferring them to an upper layer, there may be a case where no more unreceived PDUs exist. Alternatively, the fact that there are no more PDUs to rearrange the order may be a case where the PDCP PDU delivered from the lower layer is a non-received PDCP PDU having the lowest serial number. For example, if the serial number of the received PDCP PDU after resetting to a single bearer from multiple bearers is the same as the sum of Last_Submitted_PDCP_RX_SN and 1, and Last_Submitted_PDCP_RX_SN is the same as Next_PDCP_RX_SN, it means that there are no more unreceived PDUs, or any more. Means that there are no half PDCP SDUs out of order. Since the above-described condition is satisfied means that no more half PDCP SDUs are stored in the PDCP buffer, the PDCP receiving device immediately switches to operation 6 of the PDCP device.

In another embodiment of the present invention, an operation taken by a PDCP receiving apparatus when a bearer is reset will be described.

Reconfiguration of the bearer refers to a case where, for example, an MCG bearer is reset to a multi-bearer, a multi-bearer is reset to an MCG bearer, or a multi-bearer is reset to a multi-bearer.

When resetting the barrier, the terminal may alternately apply PDCP operation 9 and PDCP operation 10 or may apply sequentially.

An example of PDCP operation 9 and PDCP operation 10 will be described with reference to Table 8 below.

PDCP operation 9: operation for a single bearer PDCP operation 10: operation for multiple bearers Receive PDCP PDU Receive PDCP PDU PDCP PDU HFN/COUNT determination. Duplicate received PDU is processed as PDCP SDU and discarded PDCP PDU HFN/COUNT determination. Duplicate received PDUs are discarded without processing them as PDCP SDUs PDCP PDU is processed as PDCP SDU If the received PDU is the first PDU, PDCP PDUs that satisfy the conditions in Table 9 are delivered to the upper layer.
If the received PDU is the 2nd PDU, PDCP PDUs satisfying the conditions in Table 10 are delivered to the upper layer. PDCP PDUs that satisfy the higher layer delivery condition 7 are processed as PDCP SDUs and delivered to higher layers. PDCP PDUs that do not meet the higher layer transfer condition 7 are stored in a buffer and reorder operation is performed using a timer.
When Timer 3 expires, PDCP PDUs ordered based on Reordering_PDCP_RX_COUNT are processed as PDCP SDUs and then delivered to higher layers.

-all stored PDCP SDU(s) with consecutively associated COUNT value(s) starting from the COUNT value associated with the received PDCP SDU;

-all stored PDCP SDU(s) with an associated COUNT value less than the COUNT value associated with the received PDCP SDU;
-all stored PDCP SDU(s) with consecutively associated COUNT value(s) starting from the COUNT value associated with the received PDCP SDU;

When the condition of <Table 9> is satisfied, it means that the received PDCP PDU is a non-received PDCP PDU with the lowest serial number (i.e., received PDCP SN = Last_Submitted_PDCP_RX_SN + 1), so the PDCP PDUs in order by receiving the PDUs Occurs.

The PDCP PDUs satisfying the conditions of Table 10 refer to all non-received PDUs having a lower serial number than the received PDCP PDUs, including non-received PDCP PDUs, and continuously received PDCP PDUs.

In Table 8, the first PDU is a PDCP PDU received by reconfiguration or release of a lower layer, and is generated during handover. That is, when handover is instructed, PDCP PDUs stored in the RLC layer in an unordered order are delivered to the PDCP device, and these PDCP PDUs are referred to as a first PDU.

In Table 8, the second PDUs are PDCP PDUs that are not received by reconfiguration of the lower layer and not set by release of the lower layer, and are PDCP PDUs received from the target cell after handover is completed.

Based on handover, the first PDU may be understood as a PDCP PDU in which the order received from the source cell is not aligned, and the second PDU may be understood as a PDCP PDU received from the target cell.

In an embodiment of the present invention, the master base station (MeNB) may reset a specific bearer type or instruct handover through an RRC connection reconfiguration control message. At this time, the UE performs an optimized operation according to the type of reconfiguration indicated in the RRC connection reconfiguration message.

29 is a diagram illustrating a terminal operation when resetting a bearer according to an embodiment of the present invention.

Referring to FIG. 29, in step 2905, the UE receives a bearer reconfiguration message related to multiple bearers. In the present embodiment, the relationship with the multi-bearer means that the multi-bearer is changed to, for example, an MCG bearer or a multi-bearer or the MCG bearer is changed to a multi-bearer through the control message.

In step 2910, the terminal checks whether handover is instructed through the control message. When handover is instructed, the PDCP performs a reset operation. PDCP reconfiguration consists of specific operations such as applying a new security key and resetting the header compression operation, and is performed during handover.

If handover is not instructed, the terminal proceeds to step 2915. If handover is instructed, the terminal proceeds to step 2935.

In step 2915, the UE checks the type of reconfiguration and proceeds to step 2920 if the reconfiguration from the MCG bearer to the multi-bearer, proceeds to step 2925 if reconfiguration from the multi-bearer to the multi-bearer, and re-establishes the multi-bearer to the MCG bearer. Proceed to step 2930.

In step 2935, the UE checks the type of reconfiguration and proceeds to step 2940 if resetting from the MCG bearer to the multi-bearer, proceeds to step 2945 if reconfiguration from the multi-bearer to the multi-bearer, and re-establishing the multi-bearer to the MCG bearer. Proceed to step 2950.

In step 2920, the UE stops applying PDCP operation 9 and applies PDCP operation 10. That is, if the RRC connection reconfiguration message related to the multi-bearer is received, and when the re-establishment is performed, the PDCP is not reset (ie, not re-established with handover), and the MCG bearer is re-established as a multi-bearer, the terminal is MCG The application of PDCP operation 9, which is an operation for bearers, is stopped, and PDCP operation 10, which is an operation for multiple bearers, is applied.

In step 2925, the UE continues to apply PDCP operation 10. That is, if the RRC connection reconfiguration message related to the multi-bearer is received, and the PDCP is not reset when the reconfiguration is performed (i.e., not re-established with handover), and the multi-bearer is reconfigured to a multi-bearer, the UE The operation for the bearer, PDCP operation 10, continues to be applied.

In step 2930, the UE applies PDCP operation 10 until a predetermined condition is satisfied. The predetermined condition is satisfied when the PDCP is reset for the first time after bearer reset is completed. That is, if the RRC connection reconfiguration message related to the multi-bearer is received, and when the reconfiguration is performed, the PDCP is not reset (i.e., not re-established with handover), and the multi-bearer is reconfigured to the MCG bearer, Even though the bearer is reset, PDCP operation 10, which is an operation for multiple bearers, continues to be applied. When the PDCP is reset, the UE applies PDCP operation 9, which is an operation for the MCG bearer (i.e., the UE continues to apply operation 10 until handover is instructed after resetting to the MCG bearer is completed, and when handover is indicated. PDCP operation 9 is applied).

If the PDCP operation 9 is not immediately applied in step 2930, since there may be PDCP PDUs out of order when the multi-bearer is reconfigured to the MCG bearer, operation 10 until the order of the PDUs that are not in order is rearranged. This is because you need to keep applying to avoid data loss.

In step 2940, the UE applies PDCP operation 9 to the first PDU and PDCP operation 10 to the second PDU. As described above, the first PDUs are PDCP PDUs received by the source cell, and if the PDCP operation 10 is applied to the PDUs, the order reordering performance is deteriorated. The second PDU is PDUs received by the target cell, and the second PDU is received after all the first PDUs have been received. Since the second PDUs are received after reconfiguration to the multi-bearer is completed, PDCP operation 10 is applied. That is, if the RRC connection reconfiguration message related to the multi-bearer is received, and when the reconfiguration is performed, the PDCP is also reset (that is, the reconfiguration proceeds with the handover), and if the multi-bearer is reconfigured as an MCG bearer, the UE is PDCP operation 9 is applied to PDCP PDUs received by reconfiguration/release of the PDCP operation, and PDCP operation 10 is applied to PDCP PDUs not received by reconfiguration/release of a lower layer.

In step 2945, as in step 2940, the UE applies PDCP operation 9 to the first PDU and PDCP operation 10 to the second PDU. That is, if the RRC connection reconfiguration message related to the multi-bearer is received, and when the reconfiguration is performed, the PDCP is also reset (i.e., reconfiguration proceeds with handover), and if the multi-bearer is re-established as a multi-bearer, the UE is PDCP operation 9 is applied to PDCP PDUs received by reconfiguration/release of the PDCP operation, and PDCP operation 10 is applied to PDCP PDUs not received by reconfiguration/release of a lower layer.

In step 2950, the UE applies PDCP operation 9 to both the first PDU and the second PDU. That is, if the RRC connection reconfiguration message related to the multi-bearer is received, and when the reconfiguration is performed, the PDCP is also reset (that is, the reconfiguration proceeds with the handover), and the multi-bearer is reconfigured to the MCG bearer, the UE is PDCP operation 9 is applied to PDCP PDUs received by reconfiguration/release of, and PDCP operation 9 is also applied to PDCP PDUs not received by reconfiguration/release of a lower layer. That is, PDCP operation 9 is applied immediately.

In another embodiment of the present invention, an operation of processing a PDCP PDU received from a lower layer by a PDCP receiving device is proposed.

In this embodiment, when a PDCP PDU is received from a lower layer, the PDCP receiving device determines whether the PDU satisfies a predetermined “redundant reception condition”, and takes a predetermined action for a PDU that satisfies the “redundant reception condition”. Take it. At this time, depending on whether the PDCP receiving device is a device connected to a single bearer or a device connected to multiple bearers, the PDCP receiving device performs a differential operation.

The “duplicate reception condition” for an arbitrary PDU is defined as in <Table 11>.

if received PDCP SN-Last_Submitted_PDCP_RX_SN> Reordering_Window or
0 ≤ Last_Submitted_PDCP_RX_SN-received PDCP SN <Reordering_Window:

The “duplicate reception condition” is not to determine whether a certain PDCP PDU has been previously received, but whether the serial number of the received PDU is lower than Last_Submitted_PDCP_RX_SN (or the number assigned before Last_Submitted_PDCP_RX_SN, that is, older number) Or not), and is to determine whether the serial number is lower than the lowest serial number that has already been transmitted to the upper layer.

The fact that the “duplicate reception condition” is satisfied for any PDCP PDU means that it is very likely that the payload of the PDCP PDU has already been delivered to the upper layer. Therefore, it is highly likely that unnecessary malfunctions occur when the PDCP SDU is delivered to the upper layer. it means. Accordingly, in the present embodiment, the PDCP receiving apparatus discards the PDCP PDU satisfying the “duplicate reception condition” without delivering it to the upper layer.

If the PDCP PDU satisfying the redundant reception condition is received from a single bearer, the UE processes the PDCP SDU as a PDCP SDU before discarding the PDCP PDU and performs an operation such as updating the ROHC context (refer to RFC 3095), and then PDCP. Discard the SDU. On the other hand, if the PDCP PDU that satisfies the redundant reception condition is received from a multiple bearer, the UE immediately discards the PDCP PDU without processing the PDCP PDU as an SDU. The reasons for applying the differential operation as described above are as follows.

In the case of PDCP PDUs received from a single bearer, important packets related to ROHC may be included in the PDU even if the PDUs are repeatedly received. This phenomenon may occur when the ROHC is reset during a process such as handover. Therefore, even if a PDCP PDU received from a single bearer is duplicated, the UE processes it as a PDCP SDU and updates the ROHC context and discards the PDCP SDU.

Since the ROHC is not reset in the multi-bearer operation, there is no need to perform the operation of updating the ROHC context by processing the duplicated packets as described above. Therefore, if the UE determines that the PDCP PDU has been duplicated, it immediately discards it.

27 is a diagram illustrating an operation of a PDCP receiving apparatus according to an embodiment of the present invention.

Referring to FIG. 27, in step 2705, the PDCP receiving apparatus receives a PDCP PDU from a lower layer. In step 2710, the PDCP receiving apparatus checks whether the SN of the PDCP PDU satisfies the “redundant reception condition”. If the redundant reception condition is not satisfied, the PDCP reception apparatus proceeds to step 2715, and if it does, proceeds to step 2720. In step 2715, the PDCP receiving device determines whether the received PDCP PDU is received from multiple bearers or from a single bearer, and if it is from multiple bearers, proceeds to step 2719, and if it is from a single bearer, step 2717. Proceed to.

In step 2717, the UE processes the received PDCP PDU, configures it as a PDCP SDU, and transmits it to a higher layer without considering whether the order is reordered. In step 2719, if the order of the received PDCP PDUs is aligned, the UE immediately processes the PDCP PDUs, configures them as PDCP SDUs, and transfers them to a higher layer. If the order is not aligned, the order rearrangement for the PDCP PDUs is performed. After completion, it is processed as a PDCP SDU and delivered to the upper layer. That is, in step 2719, the UE processes only PDCP PDUs for which reordering has been completed as PDCP SDUs and transfers them to a higher layer. Here, processing a PDCP PDU as a PDCP SDU means converting a PDCP PDU into a PDCP SDU by performing an operation such as defragmenting the PDCP PDU and restoring a header.

Meanwhile, if the redundant reception condition is satisfied in step 2710, in step 2720, the PDCP receiving device checks whether the bearer to which the PDCP PDU is delivered is a single bearer or a multi-bearer, and proceeds to step 2725 if it is a single bearer, and step 2730 if it is a multi-bearer. Proceed to. In step 2725, the PDCP receiving apparatus discards the PDCP SDU after processing the PDCP PDU as a PDCP SDU. In step 2730, the PDCP receiving apparatus does not process the PDCP PDU as a PDCP SDU, but discards the PDCP PDU.

In the embodiment of FIG. 27, when a PDCP PDU or a half PDCP SDU or PDCP SDU having the same serial number as the received PDCP PDU is already stored in the receiving buffer of the PDCP, the terminal is Differential operation can be performed on the bearer.

For example, if a PDCP SDU having the same serial number as the received PDCP PDU is already stored in the PDCP reception buffer of a single bearer, the UE de-secrets the PDCP PDU, restores the header, and discards. The reason for discarding after restoring the header is to update the header restoration context by restoring the header because it is highly likely that the redundantly transmitted PDCP PDU is a packet whose header has been compressed with a more recent header compression context.

In addition, if a PDCP SDU or half PDCP SDU or PDCP PDU having the same serial number as the received PDCP PDU is already stored in the multi-bearer's PDCP reception buffer, the UE de-secrets the PDCP PDU and processes it as a half PDCP SDU, The currently stored PDCP packet (PDCP PDU or half PDCP SDU or PDCP SDU) of the same serial number is discarded, and the half PDCP SDU is stored.

In the case of a multi-bearer, when restoring the header of an unordered half PDCP SDU, the header of subsequent half PDCP SDUs may be adversely affected. Therefore, the order is not restored without restoring the header of the duplicate received packet as described above. Save until sorted.

Meanwhile, although not shown in the embodiment of FIG. 27, another differential operation when the PDCP PDU or PDCP SDU having the same serial number as the PDCP PDU received by the operation of another terminal is already stored in the PDCP reception buffer of the multi-bearer. Can be done.

For example, if the PDCP SDU of the same COUNT as the COUNT of the received PDCP PDU is already stored in the PDCP reception buffer of the multi-bearer, the UE de-secrets the PDCP PDU, restores the header, and discards. The reason for discarding after restoring the header is to update the header restoration context by restoring the header because it is highly likely that the redundantly transmitted PDCP PDU is a packet whose header has been compressed with a more recent header compression context.

In addition, if the PDCP PDU of the same COUNT as the COUNT of the received PDCP PDU is already stored in the PDCP reception buffer of the multi-bearer, the UE discards the stored PDCP PDU and stores the newly received PDCP PDU. In the case of a single bearer, the reason for performing an operation different from discarding a duplicated PDCP PDU is that in a multi-bearer structure, when retransmitting a predetermined PDCP PDU, the header can be recompressed in a more recent header compression context and then retransmitted. Because. In processing a PDCP packet (PDCP PDU or PDCP SDU) of the same COUNT as a PDCP PDU received by another terminal operation, a differential operation may be performed according to whether the PDCP packet of the same COUNT is a PDCP SDU or a PDCP PDU. .

If a PDCP packet with a COUNT equal to the COUNT of the received PDCP PDU is already stored, the UE checks whether the stored PDCP packet is a PDCP PDU or a PDCP SDU, and if it is a PDCP PDU, discards it without performing an additional operation. On the other hand, if the stored PDCP packet is a PDCP SDU, the header of the received PDCP PDU is restored, de-crypted, and then discarded.

Hereinafter, a method of setting a PBR for a multi-bearer according to an embodiment of the present invention will be described.

When transmitting data using the uplink grant allocated by the base station, the terminal determines what data to transmit in consideration of the priority of the logical channel. If data is continuously generated in a high-priority logical channel, data of a low-priority logical channel may not be serviced for a long time. This may cause a problem in that it is impossible to transmit and receive data at a minimum for maintaining a data session, and to solve this, the concept of PRB (Prioritized Bit Rate) was introduced. When the PBR is set in the logical channel, the UE increases the PBR-related token Bj by PBR for each TTI for the logical channel. In addition, in determining the data to be transmitted, the terminal preferentially considers Bj. For example, even if there is data that can be transmitted on a logical channel x having a high priority, if Bj of the logical channel x is 0, data of a logical channel whose priority is low but Bj is not 0 are transmitted with priority at least Bj. This operation is as described in section 5.7 of 36.321.

The PBR is allocated and managed for each logical channel. However, in the case of a logical channel connected to multiple bearers, it is preferable to operate the PBR in consideration of all related logical channels rather than independently operating the PBR as a logical channel. This is because the purpose of PBR is to guarantee a minimum transmission bandwidth for any data service, and in the case of a multi-bearer, one service is related to two logical channels.

In the existing signaling system, parameters related to PBR are prioritisedBitRate and bucketSizeDuration, and are signaled for each logical channel. Bj is initially initialized to 0 and then increases by prioritisedBitRate for each TTI, and the maximum size of Bj is limited by the product of prioritisedBitRate and bucketSizeDuration. In general, a specific radio bearer is set as a single bearer that is connected to only one logical channel. Subsequently, when the UE moves to the macro cell region, the single bearer may be reset to a multi-bearer, and the UE appropriately distributes the PBR of the multi-bearer to the SCG logical channel and the MCG logical channel according to a predetermined rule.

12 is a diagram for describing an operation of a terminal for configuring a PBR for a multi-bearer according to another embodiment of the present specification.

Referring to FIG. 12, in step 1205, the UE receives a control message instructing to reset a single bearer to multiple bearers. In step 1210, the UE adjusts the PBR of the MCG logical channel and the PBR of the SCG logical channel to appropriate values by referring to the PBR information of the control message 1 and the control message 2. The control message 2 denotes a control message for resetting a single bearer to a multi-bearer, and control message 1 denotes a control message containing PBR information for the single bearer. Normally, control message 1 occurs first and control message 2 occurs later. There may be several embodiments of a method of adjusting the PBR of the MCG logical channel and the SCG logical channel, and one of the methods presented below may be used.

[Method 1 of setting PBR of arbitrary multi-bearer x]

If A is set as the PBR of the logical channel of bearer x in control message 1, and the PBR of the SCG LCH of bearer x is set to B in the control message 2, the PBR of the SCG LCH is set as signaled B, and the PBR of the MCG LCH. Is adjusted to AB.

[Method 2 of setting PBR of arbitrary multi-bearer x]

If there is PBR information in control message 2, the PBR is applied to the SCG LCH, and if there is no PBR information, the PBR is applied to the MCG LCH; That is, if A is set as the PBR of the logical channel of bearer x in control message 1, and the PBR of the SCG LCH of bearer x is set to B in control message 2, the PBR of the SCG LCH is set to signaled B, and the MCG LCH PBR is adjusted to zero. Or, if the PBR for the SCG LCH of bearer x is not set in the control message 2, the PBR of the MCG LCH is maintained as A and the PBR of the SCG LCH is set to 0.

[Method 3 of setting PBR of arbitrary multi-bearer x]

Specifies which LCH to apply PBR to through control message 2. For example, the PBR is set as shown in <Table 12> below.

PBR of LCH of bearer x of control message 1 PBR of LCH of bearer x of control message 2 PBR indicator of control message 2 PBR of MCG LCH and SCG LCH A B SCG MCG LCH PBR = 0
SCG LCH PBR = B A B MCG MCG LCH PBR = B
SCG LCH PBR = 0 A Absent Absent MCG LCH PBR = A
SCG LCH PBR = 0 A Absent SCG MCG LCH PBR = 0
SCG LCH PBR = A

For example, if A is notified to the PBR of the logical channel of bearer x in control message 1 and B is the PBR of the logical channel of bearer x in control message 2 and the PBR indicator is set to MCG, the UE adjusts the PBR of the MCG LCH to B. And the PBR of the SCG LCH is set to 0. In step 1215, the UE moves a predetermined amount of Bj of the existing MCG LCH to the SCG LCH.

If the PBR setting method 1 is used, Bj of a predetermined ratio of Bj of the MCG LCH is subtracted from the MCG LCH and added to the SCG LCH. Therefore, Bj of the SCG LCH is not initialized to 0, but is initialized to the amount of Bj transferred from the MCG LCH.

If PBR setting method 2 or 3 is used, if PBR is applied to SCG, all Bj of MCG LCH are moved to SCG LCH. If PBR is applied to MCG, Bj of MCG LCH is maintained.

In step 1220, the adjusted PBR and the adjusted Bj are applied to perform an operation related to the PBR in the MCG LCH and the SCG LCH. That is, the operation of increasing Bj for each TTI by the amount of PBR and decreasing Bj by the amount of data transmission is performed.

In the above-described embodiment, the embodiments of the present invention have been described as an example that both the MCG serving cell and the SCG serving cell use LTE technology, but it is also possible for two cell groups to use different radio technologies. For example, the MCG serving cell may transmit and receive data using an LTE radio technology, and data may be transmitted and received using a radio technology different from the SCG serving cell, such as WiFi technology or HSPA technology. In the scenario in which a terminal transmits and receives data using different radio technologies as described above, one PDCP device performs reordering of the PDCP PDUs received through different radio technologies, and lower layers of different radio technologies Distributed as PDCP PDUs to devices. In this case, it is possible to apply the techniques presented throughout the present specification, for example, a timer-based reordering technique or a reordering operation switching process. In the present specification, when referring to a multi-bearer, one PDCP device is connected to two lower layers using different radio technologies, and at least one of them may be defined as a bearer, which is a lower layer using LTE technology.

Hereinafter, a method for requesting retransmission of a packet that the RLC device of the terminal has not received according to an embodiment of the present specification will be described.

When a predetermined event occurs, the RLC receiving device generates an RLC STATUS PDU, reports the serial number of a well-received RLC PDU, and requests retransmission for an RLC PDU or part of an RLC PDU (RLC PDU segment) that needs retransmission. For general operation of RLC, it follows 3GPP standard TS36.322, and RLC PDU is mixed with AMD PDU.

Depending on the radio channel condition, the RLC STATUS PDU may increase considerably, and the RLC STATUS PDU may not be transmitted as it is with a given transmission resource. In this case, the terminal may selectively report only information that can be reported in a given transmission resource.

For example, it is assumed that the reception situation of the terminal is as follows.

-Highest RLC serial number received so far = 100

-RLC PDU not received = 90, 95

-RLC PDU segment not received = 150th byte from 100th byte of 93

The STATUS PDU consists of one ACK_SN, one or more NACK_SN, zero per NACK_SN, one or more SOstart/SOend pairs, as in the example of FIG. 13 showing the format of the STATUS PDU. The STATUS PDU to be configured in the above situation is as follows, and the size of the STATUS PDU is 101 bits.

-ACK_SN = 101

-NACK_SN = 90

-NACK_SN = 93; SOstart = 100; SOend = 150

-NACK_SN = 95

If the amount of transmission resources allocated to the RLC device is 16 bits, for example, the UE configures a STATUS PDU according to the amount that can be transmitted as follows.

-ACK_SN = 90

That is, it reports only the information that it has been well received up to the serial number 89 and does not report the remaining RLC PDUs.

In some cases, reporting only some of the information as above may lead to inaccurate information. As shown in FIG. 13, several SOstart/SOend pairs may be accommodated for one NACK_SN. If only some information is included because of the amount of a given transmission resource, the RLC device receiving the STATUS PDU may make an erroneous determination. For example, the reception situation of the RLC receiving device at an arbitrary time is as follows.

-Highest RLC serial number received so far = 100

-RLC PDU segment not received = 150th byte from 100th byte of 93, remaining byte from 180th byte of 93

That is, some of the RLC PDUs of serial number 93 (1st to 99th byte and 151st to 179th byte) have been properly received, and other parts (100 to 150th and 180th to last byte) are not properly received.

If the amount of transmission resources available to the UE at the time the RLC STATUS PDU is triggered is only enough to include ACK_SN, NACK_SN and one SOstart/SOend, the UE will generate and transmit the following STATUS PDU.

-ACK_SN = 100

-NACK_SN = 93; SOstart = 100; SOend = 150

Upon receiving the STATUS PDU, the RLC device may erroneously determine that the UE has well received the 180 to the last byte part of the serial number 93 and discard the part from the buffer. Accordingly, the operation of the RLC receiving apparatus to solve this problem will be described with reference to FIG. 14.

14 is a diagram for describing an operation of an RLC receiving apparatus generating a state PDU according to an embodiment of the present specification.

Referring to FIG. 14, in step 1405, an RLC STATUS PDU is triggered. The RLC STATSU PDU is triggered when the t-Reordering timer expires or the first transmission opportunity occurs after receiving the RLC PDU with the poll bit set in a situation where the t-StatusProhibit is not driven.

In step 1410, it is checked whether the STATUS PDU including all ACK_SN, NACK_SN, and SOstart/SOend reflecting the current reception situation can be generated at the transmission opportunity (or the size of the STATUS REPORT reflecting all the current status) of the available RLC PDU. If it is smaller than the size, then proceed to step 1415, otherwise proceed to step 1420.

In step 1415, the UE generates a STATSU PDU by writing ACK_SN, NACK_SN, and SOstart/SOend to reflect the reception situation at the time point.

In step 1420, it checks whether the following <condition> is satisfied, and if it is satisfied, proceeds to step 1425.

<condition>

When generating a STATUS PDU according to the amount of a given transmission resource (or the size of an RLC PDU notified by a lower layer), are only some of the one or more SOstart/SOend pairs for one NACK_SN included in the STATUS PDU? (ie, one or more segments are included in the STATUS PDU)? For RLC PDUs that have not been received, is it possible to report the reception status for only some segments, that is, can only some SOstart/SOends among multiple SOstart/SOends be included?)

In step 1425, the RLC receiving apparatus sets the SOend value of the last SOstart/SOend pair included in the NACK_SN to a predetermined value, for example, "111111111111111". If SOend is set to the above value, it indicates that the reception from the byte indicated in the SOstart to the last byte has not been received. That is, by setting the value of the last SOend to the value as described above, retransmission is requested for a segment that has been successfully received, and at least a segment that has not yet been received can be prevented from being discarded by the RLC transmission apparatus. In the above example, the following STAUTS PDU is generated.

-ACK_SN = 100

-NACK_SN = 93; SOstart = 100; SOend = predetermined value

The transmitting device receiving the STATUS PDU will not discard the 151 to 179th bytes of the RLC PDU of serial number 93.

As another operation, it is possible to cancel the STATUS PDU triggered in step 1425 and trigger the STATUS PDU again at the next transmission opportunity. That is, more transmission resources may be allocated to the next transmission opportunity and all necessary information may be included.

In step 1430, the UE determines to which RLC PDU segment to report NACK information according to the size of the RLC PDU, writes the serial number of the unreceived RLC PDU after the last RLC PDU segment in ACK_SN, and RLC PDU to report the NACK information. Alternatively, the STATUS PDU is generated by sequentially writing NACK information for the RLC PDU segment. Therefore, the operation of the RLC transmission apparatus for solving this will be described with reference to FIG. 15.

15 is a diagram for describing an operation of an RLC transmitting apparatus for receiving a status PDU according to an embodiment of the present specification. Referring to FIG. 15, in step 1505 a STATUS PDU is received.

In step 1510, using ACK_SN, NACK_SN, SOstart, and SOend of the STATSU PDU, it is checked which RLC PDU and RLC PDU segment have been successfully transmitted, the well-transmitted ones are discarded from the transmission buffer, and those requiring retransmission are prepared for retransmission. At this time, the transmitting device determines data to be discarded and data to be retransmitted in the transmission buffer as follows. For convenience of explanation, NACK information composed of one NACK_SN and one or more SOstart/SOend pairs is referred to as partial NACK information. Those that contain meaningful information such as ACK_SN, NACK_SN, NACK_SN, and SOstart/SOend are called STATUS elements.

-It is determined that RLC PDUs indicated only by NACK_SN in the STATUS PDU should retransmit the entire RLC PDU.

-RLC PDU segments reported as'lost' by partial NACK information included in the STATUS PDU are determined to be retransmitted.

-Among the partial NACK information included in the STATUS PDU, the remaining segments except for the RLC PDU segments reported as'lost' by partial NACK information other than the last STATUS element are determined to have been properly received and discarded.

-If the last STATUS element of the STATUS PDU is partial NACK information, it is not determined whether the remaining segments except for the RLC PDU segments reported as'lost' by the partial NACK information are received. That is, neither discards nor retransmissions.

Hereinafter, according to an embodiment of the present invention, a method in which the terminal reports a plurality of categories and applies one of the categories to perform the HARQ operation will be described.

In order for the terminal and the base station to transmit and receive data, the base station must recognize the capabilities of the terminal. For example, information such as the maximum downlink data rate of the terminal and the HARQ buffer performance of the terminal is information that the base station must be aware of in order to transmit downlink data to the terminal. The performance information related to the transmission and reception of downlink data of the terminal is reported to the base station in the form of a terminal category. The following table is a'terminal category' defined in standard 36.306. To classify based on the downlink data reception capability of the terminal, Category 1 is 10 Mbps, Category 2 is 50 Mbps, Category 3 is 100 Mbps, Category 4 is 150 Mbps, Category 5, 6, 7 is 300 Mbps, Category 8 is 3 It corresponds to Gbps.

UE Category The terminal can receive within one TTI (1ms)
Number of bits Total number of soft channel bits (buffer size) Maximum number of layers that can be supported in downlink Category 1 10296 250368 One Category 2 51024 1237248 2 Category 3 102048 1237248 2 Category 4 150752 1827072 2 Category 5 299552 3667200 4 Category 6 301504 3667200 2 Category 6' 301504 3667200 4 Category 7 301504 3667200 2 Category 7' 301504 3667200 4 Category 8 2998560 35982720 8

In Table 13, the categories 1 to 5 were introduced in LTE standard release 8, and categories 6 to 8 were introduced in LTE standard release 10. In other words, Release 8 base stations do not understand categories 6-8. In addition to the above categories, it may be necessary to introduce categories corresponding to other data rates. For example, in LTE standard release 12, the introduction of new categories 9 and 10 corresponding to 450 Mbps was decided. For convenience of description, categories 1 to 5 are referred to as a first category, categories 6 to 8 are referred to as a second category, and categories 9 to 10 are referred to as a third category. The base stations of Release 8 and Release 9 do not understand the second and third categories, the base stations of Release 10 and 11 do not understand the third category, and the base stations of Release 12 or later understand all categories. Since the UE does not recognize the release of the base station, it reports several categories in some cases. For example, the terminal of the second category reports not only the second category but also the first category. The terminal of the third category reports not only the third category, but also the second category and the first category. Since the category has a close relationship with the size of the soft buffer as described below, the UE and the base station must apply the same category to each other. Therefore, there is a need for a method in which the terminal and the base station apply the same category to a terminal reporting a plurality of categories. Each item in the table will be described in more detail below.

In the table above, multiplying'the maximum number of bits that a terminal can receive within one TTI (1ms)' by 1000 can be converted into the system's maximum transmission rate per second.

In the above table, the'total number of soft channel bits' is related to the buffer size of the terminal and affects the rate matching operation. _Assuming that _the'total number of soft channel bits' is N _soft , _{the'transport} block soft buffer size' is N _IR , and _the'code block soft buffer size' is N _cb , there is a relationship of the following <Equation 1>.

Here, K _MIMO has a value of 2 or 1 depending on the transmission mode, and the value of min(M _{DL_HARQ} , M _limit ) generally has a value of 8. In addition, C is the number of code blocks, K _W represents the length of the circular buffer, and has a relationship of K _W =3K _Π , and K _Π is the interleaver size of the subblock and has a length of 6144 bits. That is, as shown in the above formula, when the N _soft value affects the N _IR value and the N _IR /C value is less than K _{W, that} is, when high-speed data transmission and reception is in progress, the N _IR value is the value of N _cb It can be seen that it affects. Since the puncturing/repetition pattern affects the value of N _cb , if the N _soft value between the terminal and the ENB is misunderstood, it can be seen that the incorrect operation is affected. Various matters related to other rate matching, etc., follow standard 36.212.

18 is a diagram illustrating an operation of a terminal reporting three categories and a base station performing downlink data transmission and reception with the terminal according to an embodiment of the present invention.

Referring to FIG. 18, in a mobile communication system composed of a terminal 1805, a base station 1810, and an MME 1815, the terminal is powered on (1820). The UE performs a cell search and, when an accessible cell is found, performs an RRC connection establishment procedure (see RRC connection establishment procedure, standard 36.331) with the base station through the cell (1825). The terminal transmits a predetermined control message to the MME through the established RRC connection (1830). The control message may be, for example, a service requesting message (SERVICE REQUEST) or an initial registration requesting message (ATTACH REQUEST). The MME determines whether or not to accept the request from the terminal through a predetermined procedure, and if it accepts the request and decides to provide the mobile communication service to the terminal, the MME transmits a control message containing information related to the terminal to the base station. Do (1835). The control message may include information necessary for the base station to transmit and receive data with the terminal, for example, security key information, service profile information of the terminal, and the like. If the MME has the UE capability information, the MME also includes the UE capability information in the control message. If the MME does not have the capability information of the UE, the capability information is not delivered, and the base station transmits a predetermined RRC control message to the UE in order to obtain the capability information of the UE (1840). The control message is referred to as a UE capability information request message (UE CAPABILITY ENQUIRY), and a field indicating which radio access technology capability information is requested is stored in the control message. The LTE base station sets the field so that performance information for E-UTRA is requested. When the terminal receives the control message, the UE checks which RAT performance information is requested, and if the E-UTRA performance information is requested, a UE capability information message containing performance information related to E-UTRA (UE CAPABILITY INFORMATION) Is generated and transmitted to the base station (1845). In particular, at least one category information is included in the control message.

If the performance of the terminal falls within one of categories 1 to 5, the terminal reports only the first category corresponding to its performance.

If the performance of the terminal corresponds to one of categories 6 to 8, the terminal reports a second category corresponding to its performance and a first category most similar to the second category. For example, a category 6 or 7 terminal reports category 4 as a first category, and a category 8 terminal reports category 5 as a first category.

If the performance of the terminal is category 9 or 10, the terminal reports a third category corresponding to its performance and a second category and a first category most similar to the third category. For example, the category 9 terminal reports category 9 as the third category, category 6 as the second category, and category 4 as the first category.

When the base station receives the performance information of the terminal, the base station determines the configuration of the terminal by referring to the performance information and determines which category to apply (1850).

The base station may set an antenna, transmission mode, carrier aggregation, and the like, and determine a category to be applied in relation to the configuration according to a predetermined rule. The above rule will be described in more detail in FIG. 18. The base station transmits an RRC connection reconfiguration message containing the configuration information to the terminal (1855). The control message includes information for determining which category the base station has applied. The terminal sets the antenna, transmission mode, carrier aggregation, etc. by applying the configuration information of the control message. Then, it determines which category to apply by referring to the information of the control message. Then, the downlink HARQ soft buffer is reset according to the determined category.

The base station configures a downlink HARQ buffer by applying Nsoft of the determined category, and transmits downlink data to the terminal by using the HARQ buffer (1865). For example, the UE determines N _IR by applying Nsoft of the determined category, and determines the size of the HARQ soft buffer according to the N _IR . If Nsoft and N _IR are changed, change the size of the soft buffer accordingly. If the size of the reset soft buffer becomes smaller than the size of the previous soft buffer, the terminal discards data larger than the reset soft buffer among the data stored in the soft buffer, and keeps only the data smaller than the reset soft buffer. do. This operation is referred to as a data management operation when resetting the soft buffer.

The terminal receives downlink data from the base station using the reset soft buffer (1865).

Thereafter, at a certain point in time, the base station changes the configuration of the terminal. Accordingly, the category to be applied may be changed. For example, when the terminal handovers to a new base station, if the version of the new base station is lower than the version of the previous base station and some of the categories of the terminal are not understood, the new category must be applied. Taking handover as an example, the target base station determines configuration information to be applied by the terminal after handover and transmits it to the source base station, and the source base station transmits an RRC connection reconfiguration message containing the configuration information to the terminal (1875). A control message indicating handover is stored in the RRC connection reconfiguration message, and the terminal establishes downlink synchronization with the target cell indicated in the control message. The UE also determines a category to be applied in the target cell using the information contained in the RRC connection reconfiguration message. Then, the downlink soft buffer is reset according to the category (1880). The UE receives downlink data from the target cell using the reset downlink soft buffer (1885). In particular, when downlink synchronization with the target cell is established, the UE performs a random access process in the target cell, and when the random access process is completed, the UE starts using the reset downlink soft buffer.

19 is a diagram illustrating a terminal operation according to an embodiment of the present invention.

Before starting the operation of FIG. 19, the terminal determines its own category. The terminal category may be determined in the production stage and stored in a nonvolatile internal memory. As described above, the terminal has at least one category. A terminal belonging to the third category also has a second category and a first category that can be recognized by the old base station in case it is connected to the old base station. Thereafter, when the terminal is powered on, an appropriate cell to be'camped on' is selected through a cell search operation or the like, and a network access process is performed through the cell (2005). Until the terminal receives the first RRC connection reconfiguration message (RRC CONNECTION RECONFIGURATION), the downlink soft buffer size is determined by applying Nsoft of the first category and performs a HARQ operation.

Referring to FIG. 19, in step 1910, the UE reports its own category while reporting performance information. The terminal may report a first category, a second category, and a third category, and report a category 9 as a third category, a category 6 as a second category, and a category 4 as a first category, or a category 10 as a third category, Category 7 as the second category and category 4 as the first category may be reported.

When receiving the RRC connection reconfiguration message in step 1915, the terminal resets the connection by applying the configuration information stored in the control message, and proceeds to step 1920. In step 1920, the terminal checks whether the information contained in the control message satisfies the second category selection condition or the third category selection condition. If neither of the two conditions is satisfied, the process proceeds to step 1925, if the second category selection condition is satisfied, to step 1930, and if the third category selection condition is satisfied, the process proceeds to step 1935.

In step 1925, the UE determines Nsoft by applying the first category. For example, if the terminal reports category 9 as the third category, category 6 as the second category, and category 4 as the first category, the terminal applies category 4. If a value different from the currently used Nsoft is determined with the new Nsoft, or if a different NIR from the currently used NIR is determined, data management is performed when the soft buffer is reset.

In step 1930, the terminal determines Nsoft by applying the second category. For example, if the terminal reports category 9 as the third category, category 6 as the second category, and category 4 as the first category, the terminal applies category 6. If a new Nsoft value is determined different from the currently used NIR, or if a different NIR from the currently used NIR is determined, data management is performed when the soft buffer is reset.

In step 1930, the terminal determines Nsoft by applying the third category. For example, if the terminal reports category 9 as the third category, category 6 as the second category, and category 4 as the first category, the terminal applies category 9. If a new Nsoft value is determined different from the currently used NIR, or if a different NIR from the currently used NIR is determined, data management is performed when the soft buffer is reset.

In the present embodiment, various examples of the second category selection condition and the third category selection condition may be as follows.

[Criteria for selecting the second category (1)]

Among the serving cells, there is no serving cell with TM 10 set and at least one serving cell with TM 9 set

[3rd category selection condition (1)]

Among serving cells, there is at least one serving cell with TM 10 set

In short, a category is selected based on the transmission mode set in the terminal.

TM 9 and TM 10 are forward transmission modes defined in standard 36.213. TM 9 is a mode that supports single user-multi-input multi-output (SU-MIMO) having a maximum of 8 ranks, and TM10 is a mode that supports coordinated multi-point transmission (CoMP). A transmission mode with a high possibility of applying a high data rate is previously associated with a category of a high data rate to determine which category to apply.

That is, if TM 9 is set, the second category is applied, if TM 10 is set, the third category is applied, and if neither of the two is set, the first category is applied.

[Criteria for selecting the second category (2)]

A maximum of two serving cells are configured in the terminal, and at least one serving cell in which TM 9 is configured exists.

[3rd category selection condition (2)]

At least three serving cells are configured in the terminal.

In short, the category is determined in consideration of the carrier aggregation situation of the terminal and the transmission mode of the terminal.

The 450 Mbps data rate is likely to be achieved when at least three serving cells are integrated. Therefore, when the number of set serving cells is three or more, it can be defined to apply the third category.

That is, if at least three serving cells are set, the third category is set, if at most two serving cells are set and TM 9 is set, the second category is set, and if at most two serving cells are set and TM 9 is not set, the first category is assigned. Apply.

[Criteria for selecting the second category (3)]

At least one serving cell in which TM 9 is configured is configured, and control information of'the terminal category to be applied' is not included in the RRC reconfiguration control message.

[3rd category selection condition (3)]

Control information of'the terminal category to be applied' is included in the RRC reconfiguration control message.

In short, it explicitly indicates which category to apply to the RRC reconfiguration control message. In particular, it is possible to reduce signaling overhead by explicitly applying only whether or not the third category is applied, and linking the second category with whether or not TM9 is used. In other words, if the category information to be applied is included, the third category is applied. If there is no above information and TM 9 is set, the second category is applied, and if there is no above information and TM 9 is not set, the first category is applied. do.

16 is a block diagram showing a configuration of a terminal device in an LTE system according to an embodiment of the present invention.

Referring to FIG. 16, the terminal device includes an MCG-MAC device 1610, a control message processing unit 1665, various upper layer processing units 1670, 1775, 1785, a control unit 1680, an SCG-MAC device 1615, and an MCG. -Including MAC device 1610, transceiver 1605, PDCP devices 1645, 1750, 1755, 1760, RLC devices 1620, 1725, 1730, 1735, 1740.

The transceiver 1605 receives data and a predetermined control signal through a downlink channel of a serving cell and transmits data and a predetermined control signal through an uplink channel. When multiple serving cells are configured, the transceiver performs data transmission/reception and control signal transmission/reception through the multiple serving cells.

The MCG-MAC device 1610 performs a role of multiplexing the data generated by the RLC device or demultiplexing the data received from the transmitting/receiving unit 1605 and transferring the data to an appropriate RLC device. The MCG-MAC device also handles the BSR or PHR triggered on the MCG.

The control message processing unit 1665 is an RRC layer device and processes the control message received from the base station to take necessary actions. For example, it receives an RRC control message and transmits various configuration information to the control unit.

The upper layer processing units 1670, 1775, and 1785 may be configured for each service. Data generated from user services such as FTP (File Transfer Protocol) or VoIP (Voice over Internet Protocol) are processed and transferred to the PDCP device.

The control unit 1680 controls the transmission/reception unit 1605 and the multiplexing and demultiplexing unit so that reverse transmission is performed with an appropriate transmission resource at an appropriate time by checking the scheduling command received through the transmission/reception unit 1605, for example, reverse grants. . The control unit also performs various control functions for the operation of the terminal shown in FIG. 15.

The PDCP devices 1645, 1750, 1755, 1760 are divided into a single bearer PDCP (1645, 1750, 1760) and a multi-bearer PDCP (1755). A single bearer PDCP transmits and receives data only through MCG or SCG, and is connected to one RLC transceiver. Multi-bearer PDCP transmits and receives data through MCG and SCG. The RLC devices 1620, 1725, 1730, 1735, and 1740 perform the operations described in FIGS. 14 and 15. The multi-bearer PDCP performs the PDCP operation illustrated in FIG. 5 to FIG. 7, and the controller 1680 oversees various control operations illustrated in FIG. 5 to FIG. 12. The control unit 1680 also oversees various control operations shown in FIGS. 18 to 29.

17 is a block diagram showing the configuration of a base station device in an LTE system according to an embodiment of the present invention.

Referring to FIG. 17, the base station includes a MAC device 1710, a control message processor 1765, a control unit 1780, a transceiver 1705, a PDCP device 1745, 1850, 1855, 1860, an RLC device 1720, 1825, 1830, 1835, 1840), and a scheduler 1790.

The transmission/reception unit 1705 transmits data and a predetermined control signal through a forward carrier, and receives data and a predetermined control signal through a reverse carrier. When multiple carriers are set, the transmission/reception unit performs data transmission/reception and control signal transmission/reception through the multiple carriers.

The MAC device 1710 serves to multiplex the data generated by the RLC device or demultiplex the data received from the transmission/reception unit and transmit the multiplexed data to an appropriate RLC device or control unit. The control message processing unit processes the control message transmitted by the terminal and takes necessary actions, or generates a control message to be transmitted to the terminal and delivers it to the lower layer.

The scheduler 1790 allocates transmission resources to the terminal at an appropriate time in consideration of the buffer state of the terminal, the channel state, etc., and processes the transmission/reception unit to process a signal transmitted by the terminal or to transmit a signal to the terminal.

The PDCP devices 1745, 1850, 1855, and 1860 are divided into a single bearer PDCP (1745, 1750, 1760) and a multi-bearer PDCP (1755). A single bearer PDCP transmits and receives data only through MCG or SCG, and is connected to one RLC transceiver. Multi-bearer PDCP transmits and receives data through MCG and SCG. The multi-bearer PDCP performs the PDCP operation illustrated in FIG. 5 to FIG. 7, and the controller 1780 oversees various control operations illustrated in FIG. 5 to FIG. 12. The control unit 1780 also oversees various control operations illustrated in FIGS. 18 and 19 and FIGS. 21 to 29. The RLC device performs the operations shown in FIGS. 14 and 15.

Claims (20)

In the method of the terminal in a wireless communication system,
When a packet data convergence protocol (PDCP) entity is associated with two radio link control (RLC) entities, reordering the order of PDCP protocol data units (PDUs) using a timer associated with reordering;
Processing the ordered PDCP PDUs into one or more PDCP service data units (SDUs); And
And restarting the timer when at least one of the one or more PDCP SDUs remains when the timer expires.
The method of claim 1,
Receiving a control message for reconfiguration from the base station; And
The method further comprising performing the reconfiguration to associate a PDCP entity associated with one RLC entity with two RLC entities based on the control message.
The method of claim 1,
The method further comprising removing at least one PDCP PDU received in duplicate among the PDCP PDUs without processing it as a PDCP SDU.
The method of claim 1,
The order reordering of the PDCP PDUs is performed based on a count value associated with a hyper frame number (HFN) and a PDCP sequence number (SN) of a received packet.
The method of claim 4,
The one or more PDCP SDUs are delivered to an upper layer according to an order of count values associated with the one or more PDCP SDUs.
In the method of the terminal in a wireless communication system,
When a packet data convergence protocol (PDCP) entity associated with two radio link control (RLC) entities is associated with one RLC entity by reconfiguration, a PDCP PDU using a timer associated with reordering based on a predetermined condition the process of rearranging the order of (protocol data units);
Processing the ordered PDCP PDUs into one or more PDCP service data units (SDUs); And
And restarting the timer when at least one of the one or more PDCP SDUs remains when the timer expires.
The method of claim 6,
Receiving a control message for the reconfiguration from a base station; And
The method further comprising performing the reset based on the control message.
The method of claim 6,
The method further comprising processing at least one PDCP PDU received in duplicate among the PDCP PDUs as a PDCP SDU, and removing the at least one PDCP PDU received in duplicate.
The method of claim 6,
The order reordering of the PDCP PDUs is performed based on a count value associated with a hyper frame number (HFN) and a PDCP sequence number (SN) of a received packet.
The method of claim 9,
The one or more PDCP SDUs are delivered to an upper layer according to an order of count values associated with the one or more PDCP SDUs.
In a terminal in a wireless communication system,
A receiver configured to receive data; And
Processing the data into packet data convergence protocol (PDCP) protocol data units (PDUs),
When the PDCP entity is associated with two radio link control (RLC) entities, rearrange the order of the PDCP PDUs using a timer associated with reordering,
Processing the ordered PDCP PDUs into one or more PDCP service data units (SDUs),
And a controller for restarting the timer when at least one of the one or more PDCP SDUs remains at the time the timer expires.
The method of claim 11, wherein the control unit,
Controlling the receiver to receive a control message for reconfiguration from a base station,
And performing the reconfiguration to associate a PDCP entity associated with one RLC entity with two RLC entities based on the control message.
The method of claim 11, wherein the control unit,
A terminal, characterized in that, among the PDCP PDUs, at least one PDCP PDU received in duplicate is removed without processing it as a PDCP SDU.
The method of claim 11, wherein the control unit,
A terminal, characterized in that the order rearrangement of the PDCP PDUs is performed based on a count value associated with a hyper frame number (HFN) and a PDCP sequence number (SN) of a received packet.
The method of claim 14, wherein the control unit,
The one or more PDCP SDUs are transmitted to an upper layer according to an order of count values associated with the one or more PDCP SDUs.
In a terminal in a wireless communication system,
A receiver configured to receive data; And
Processing the data into packet data convergence protocol (PDCP) protocol data units (PDUs),
When a PDCP entity associated with two radio link control (RLC) entities is associated with one RLC entity by reconfiguration, the order of PDCP PDUs is rearranged using a timer associated with reordering based on a predetermined condition,
Processing the ordered PDCP PDUs into one or more PDCP service data units (SDUs),
And a controller for restarting the timer when at least one of the one or more PDCP SDUs remains at the time the timer expires.
The method of claim 16, wherein the control unit,
Controlling the receiver to receive a control message for the reconfiguration from a base station,
The terminal, characterized in that to perform the reset based on the control message.
The method of claim 16, wherein the control unit,
And processing at least one PDCP PDU received in duplicate among the PDCP PDUs as a PDCP SDU, and removing the at least one PDCP PDU received in duplicate.
The method of claim 16, wherein the control unit,
A terminal, characterized in that the order rearrangement of the PDCP PDUs is performed based on a count value associated with a hyper frame number (HFN) and a PDCP sequence number (SN) of a received packet.
The method of claim 19, wherein the control unit,
The one or more PDCP SDUs are transmitted to an upper layer according to an order of count values associated with the one or more PDCP SDUs.

Images