Method for transmitting status report of pdcp layer in mobile telecommunications system and receiver of mobile telecommunications

TECHNICAL FIELD [0001] The present invention relates to a method of transmitting a PDCP layer status report for reporting to another side of the PDU PDCP receiving status in a PDP layer in a Long Term Evolution (LTE).

BACKGROUND ART [0002] Fig. 1 shows an exemplary structure of a long-term evolution (LTE) network as a mobile communication system of a related technique. The LTE system is a system that has evolved from the existing UMTS system, and standardization work on it is carried out by the 3GPP standardization organization.

[0003] The LTE network can be roughly divided into a developed terrestrial radio access network to the UMTS system (E-UTRAN, Evolved UMTS Terrestrial Radio Access Network) and backbone network (CN) Core Network). E-UTRAN essentially includes a terminal (i.e. user equipment (UE, User Equipment)), base station (i.e. eNodeB), access gateway (aGW, ang. Access Gateway) located at the end of the network and connecting to one or more external networks. aGW can be divided into a part for handling user traffic and a part for processing control traffic. In this case, the part of the access gateway that processes user traffic and the part of the access gateway that processes control traffic can communicate via the new interface. One or more cells may exist in a single eNB. An interface can be used to transmit user traffic and control traffic between eNB nodes. The CN may include an access gateway and a node or element similar to a UE user registration. An interface can be used to distinguish between E-UTRAN and CN.

[0004] Fig. 2 shows an exemplary architecture of the control plane of the radio interface protocol between the terminal and E-UTRAN according to the 3GPP standard of the radio access network. Fig. 3 shows an exemplary user plane architecture of the interface protocol between the terminal and E-UTRAN in accordance with the 3GPP radio access network standard.

[0005] In the following, with reference to Figs. 2 and 3, the structures for the radio interface protocols between the terminal and E-UTRAN are described.

[0006] The radio interface protocol horizontally consists of a physical layer, data link layer and network layer, and vertically consists of a user plane for transmitting user data and a control plane for transmitting control signaling. Protocol layer as shown in Fig. 2 and 3, can be divided into L1 (layer 1), L2 (layer 2) and L3 (layer 3) based on the bottom three layers of the open system joining model (OSI) Open System Interconnection), which is widely known in the field of communication systems. These radio protocol layers occur as pairs between the terminal and E-UTRAN and support data transmission over the radio interface.

[0007] Specific layers of the radio protocol control plane of Fig. 2 and the user planes of the radio protocol of Fig. 3 will be described below.

[0008] The physical layer (layer 1) uses a physical channel to provide an information transfer service to the upper layer. The physical layer is connected via a transport channel to the medium access control layer (MAC) located above it. medium access control) and data is transferred between the physical layer and the MAC layer through a transport channel. The transport channel is divided into a dedicated transport channel and a shared channel according to whether the channel is shared or not. Furthermore, between suitably different physical layers, namely between

In the respective physical layers of the transmitting side (transmitter) and receiving side (receiver), the data is transmitted via a physical channel.

[0009] The second layer comprises various layers. First, the Medium Access Control (MAC) layer performs mapping of different logical channels to different transport channels and performs logical channel multiplexing by mapping several logical channels to a single transport channel. The MAC layer is connected to a higher layer called the radio link control layer (RLC). radio link control) via a logical channel. The logical channel is divided into a control channel that transmits control plane information and a traffic channel that transmits user plane information according to the type of information transmitted.

[0010] Radio Resource Control Layer (RLC) The Radio Resource Control) of the second layer segments and / or combines the data received from the higher layer to adjust the data size so that the lower layer properly transmits the data to the radio interface. In addition, to guarantee different quality of services (QoS, Quality of Services) required by each radio carrier (RB) radio bearer), the RLC layer provides three modes of operation: transparent mode (TM) Transparent Mode); unconfirmed mode (UM, Unacknowledged Mode); and confirmed mode (AM, Acknowledged Mode). In particular, the RLC layer operating in AM (hereinafter referred to as "RLC AM layer") performs the retransmission function through the function of automatic request and repetition (ARQ). automatic repeat and request) for reliable data transmission.

[0011] The packet data convergence protocol (PDCP) layer packet data convergence protocol) of the second layer performs a function called header compression, which reduces the size of the IP packet header, which is relatively large and contains unnecessary control information, for efficient transmission of an IP packet, such as IPv4 or IPv6 on a narrow band radio interface. Header compression improves transmission performance between radio interfaces by allowing only key information in the data header part to be transmitted.

[0012] The RRC layer located in the lowest part of the third layer is defined only in the control plane, and controls the logical channel, transport channel and physical channel with respect to configuring, reconfiguring and releasing radio carriers (RBs). In this case, RB relates to the logical path provided by the first and second layers of the radio protocol for data transmission between the UE and UTRAN. Generally, configuring (or setting) RBs refers to the process of determining the radio protocol and channel layer characteristics required to provide a particular data service, and setting the appropriate detailed parameters and operational methods.

[0013] Fig. 4 shows an exemplary PDCP unit structure. The following section contains a detailed description of the PDCP unit. It should be noted that the blocks shown in Fig. 4 are functional blocks, so there may be a difference in the actual implementation of such blocks.

[0014] The PDCP unit is connected upwards to the RRC layer or user application, and downwards to the RLC layer. The detailed structure of this is described below.

[0015] One PDCP unit as shown in Fig. 4 consists of a transmitting side and a receiving side. The transmitting side on the left can configure the SDU received from the higher layer, such as PDU, or configure as the PDU information generated by the PDCP unit itself, and transmit it to the equivalent PDCP being the receiving side. The receiving side on the right, the PDCP peer unit, separates the PDCP SCU or control information from the PDCP PDU received from the transmitting side.

[0016] As described above, the PDU generated by the transmitting side of the PDCP unit may have two types: data PDU and control PDU. First, the PDCP data PDU is a data block created by processing the SDU received from the higher layer by the PDCP unit, and the PDCP control PDU is a data block generated by the PDCP unit itself to provide control information to the peer.

[0017] PDCP data PDU is generated in RB user planes (U planes) and control planes (C planes), and some functions of the PDCP unit are selectively used according to the type of plane used. That is, the header compression function is applied only to U-plane data, and the integrity protection function together with the security functions are applied only to C-plane data. In addition to the integrity protection function, encryption functions for data security may also be included in the security functions. Here, the encryption function is applied to both U plane data and C plane data.

[0018] PDCP control PDU is generated only in the RB U plane and can roughly be divided into two types: "status PDCP report" for notifying the sender of the receiving buffer status of the PDCP unit; and " Header Compression Feedback (HC)" for notifying the compressor unit of the transmitting header about the state of the decompressor of the receiving header.

[0019] Fig. 5 is a block diagram illustrating the processing steps of each PDCP PDU in the PDCP unit.

In particular, Fig. 5 shows the steps for processing three types of PDCP PDUs (i.e. PDCP PDU data, PDCP control PDU for status PDCP report and PDCP control PDU for header compression feedback) using paths to ® in the PDCP unit . The PDCP unit processing path descriptions for each PDU type are as follows.

1. The PDU PDU data handling process in the PDCP unit is associated with paths ®, ®, @ and @. Each of the paths is described below.

Path®: The sending side PDCP compresses the header and secures the SDU received from the upper layer, and then generates PDCP PDU data by adding the Sequence Number PDCP, the D / C field indicating whether it is data PDU or PDU control and so on to the header, thereby transmitting it to the receiving party's PDCP (i.e. equivalent PDCP). Here, the header compression may be performed by the header compression unit.

Path®: the receiving party's PDCP unit removes the header from the PDU of the PDCP data provided from the lower layer, and decompresses the PDCP SDU by performing a security check and decompressing the header, thereby providing it to the upper layer. The PDCU SDU for the upper layer is delivered sequentially. If the PDCP PDU is received out of sequence, it is rearranged in the receive buffer and then delivered to a higher layer. Here, header decompression can be performed by a header decompression unit.

Path @: the transmitting PDCP entity may impose an HC feedback packet on the PDCP data PDU (e.g., the HC feedback packet is transmitted by adding or including PDCP data in the PDU). Here, the HC feedback packet receives information from the decompression of the header of the PDCP unit of the receiving side that has a common location

With the transmitting party PDCP unit, and generates the packet by superimposing such information on the PDCP SDU when performing header compression on the PDCP SDU received from the higher layer. Then security is performed on the PDCP SDU and the header has a HC feedback packet, SN PDCP, D / C field and so on for generating PDU PDCP data and thus transmitting from the PDCP unit of the transmitting party to the PDCP unit of the receiving party.

Path ©: After receiving the PDCP data PDU, the receiving PDCP unit first removes the header, and performs security check and header decompression for the SDCP PDCP decompression. Here, if a superimposed HC feedback packet is present, it is separated and provided for header compression of the jointly located transmitting PDCP unit. After receiving the HC feedback packet, the compression of the PDCP header of the sending side can determine from the feedback whether the subsequent packets should be delivered with the full header or the compressed header.

2. The PDCP control PDU service process for the PDCP report on the status in the PDCP unit is associated with paths @ and ©. Each of the paths is described below.

Path®: The receiving side PDCP may check the receiving buffer for a retransmission request of a PDCP SDU not received from the sending side's PDCP. Here, the status of the receive buffer is configured as a PDCP status report, and the configured PDCP status report is transmitted in the form of a control PDU to the jointly located PDCP unit of the transmit side. Meanwhile, the PDCP control PDU header may include a D / C field indicating whether the PDU is data PDU or control PDU, a control PDU (CPT) field indicating whether the control PDU includes a status PDCP report or HC feedback packet and the like.

Path ©: After receiving a PDCP control PDU containing a status PDCP report, the receiving side PDCP unit delivers the received status PDCP report to the jointly located transmitting side PDCP unit. Based on the PDCP status report, the jointly located transmitting party PDCP unit retransmits the PDCP SDU not picked up by the receiving party PDCP unit.

3. The PDU process for PDCP control for HC feedback in a PDCP unit is associated with paths © and ©. Each of the paths is described below.

Path ©: the transmitting PDCP unit may transmit the PDCP control PDU by independently including the HC feedback packet in it, without applying the HC feedback packet to the PDCP data PDU. Here, the HC feedback packet receives information from the decompression of the header of the receiving PDCP unit which is jointly located with the transmitting PDCP unit. The HC feedback packet is configured as a PDCP PDU by adding the D / C field, CPT field and so on to the header, and then transmitted to the receiving party's PDCP as a peer.

Path ©: after receiving a PDCP control PDU containing HC feedback, the receiving side PDCP provides it for compressing the header of the transmitting PDCP unit. After receiving the PDCP control PDU, the compression of the PDCP header of the sending side can determine, based on feedback, whether the next

The packet should be delivered with a full header or a compressed header.

[0021] In the document "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification (Release 8) ”, 3GPP TS 36.323 V8.1.0, a description of the packet data convergence protocol (PDCP) is disclosed.

[0022] In the document "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification (Release 8) ”, 3GPP TS 36.323 V8.2.1 discloses the description of the packet data convergence protocol (PDCP).

[0023] WO-A2-2006118418 discloses a method of transmitting control information in a wireless communication system and a method of updating a transmission window using them, so that transmission efficiency on the transmitting side can be increased. It includes the steps of receiving from the receiving side the first block of control information containing the first information about the status report, with the first status information providing acknowledgment of receipt information for multiple data blocks sent to the receiving page, receiving a second control information block containing the second status report information placed as the last status report information in the second control information block, and updating the transmission window using the acknowledgment of receipt information in the first status report information.

[0024] Document EP-A2-1626518 discloses a bitmap structure that allows a significant reduction in the size of the bitmap field containing information about the receipt result while fully performing its acknowledgment function. To this end, a message area is allocated for recording indications that allows acknowledgment of successful or unsuccessful reception for the maximum allowable number of SN level packets that can be processed by the ACK. A message area is also allocated to record only receive results for unsuccessfully received packets. The receiving side acknowledges unsuccessfully received packets through the pointers and retransmits unsuccessfully received packets. In addition, the transmitting side provides the receiving side with the number of SN level packets and the maximum number of fragmentation packets. The receiving side determines the optimized bitmap configuration scheme and, based on the specified bitmap configuration scheme, transmits the reception results for the respective fragmentation packets to the transmitting side.

[0025] Document WO-A1-2007078142 discloses a provided method that can reduce losses in data transmission. The data block is prepared at a high level layer and the data block is transmitted at a low level layer. Status report information associated with receiving or not receiving a data block is received through the low-level layer. When the receiver fails to receive data sent from the transmitter, the transmitter can quickly recognize a receiving failure and can retransmit data.

[0026] WO-A2-0178286 discloses a method and telecommunications system for numbering data packets in packet switched data transmission in connection with call forwarding in which responsibility for the connection is transferred from the connection between the mobile station and the first wireless telecommunications network per connection between the mobile station and the second wireless telecommunications network. In the first wireless telecommunications network, the available data packet number space for numbering the data packets is larger than the data packet number space of the second

EP 2 188 952 B1 wireless telecommunications network. The numbering of data packets is limited in the first wireless telecommunications network, such that the data packet numbers of the first wireless telecommunications network do not exceed the maximum value of the number location of the data packets number of the second wireless telecommunications network.

[0027] NEC in document "Lower PDCP layer for Mobility", R2-061344 from meeting number 53 of working group TSG-RAN Working Group 2 on May 8-12, 2006 reveals the mechanism of transferring intra-E-UTRAN connection, proposing a delivery mechanism in order during lossless call forwarding.

SUMMARY OF THE INVENTION [0028] As described above, the receiving party PDCP may use a status PDCP report to request the retransmission of a PDCP SDU not received from the transmitting party PDCP. For this purpose, the PDCP should generate the PDCP for PDCP in the appropriate form and transmit it to another party. However, the type of format to use in transmission has not yet been decided.

[0029] Thus, the object of the invention is to define the PDCP control PDU format that the receiving party PDCP unit uses to transmit the status PDCP report to the transmitting party PDCP unit as a peer. To this end, the invention provides a way for the PDCP to inform about the state of the receive buffer in the form of a bit map.

[0030] According to claim 1, the invention provides a method of transmitting a receive buffer status report regarding a service data unit, SDU (Service Data Unit), packet data convergence protocol, PDCP, from the receiving side of the PDCP layer to the transmitting side of the PDCP layer in a mobile communication system.

[0031] According to claim The invention also provides a receiving apparatus in a mobile communication system.

Effect [0031] Embodiments of the invention result, when transmitting a status PDCP report for retransmitting a PDCP SDU not received in the PDCP layer, reduce the header size by effectively generating a status report, as well as preventing waste of radio resources.

DESCRIPTION OF THE FIGURES [0033]

Fig. 1 illustrates an exemplary structure of a Long Term Evolution (LTE) network as a mobile communication system of a related technique;

Fig. 2 shows an exemplary architecture of the control plane of the radio interface protocol between the terminal and E-UTRAN in accordance with the 3GPP standard of a radio access network;

Fig. 3 shows an exemplary user plane architecture of the interface protocol between the terminal and E-UTRAN in accordance with the 3GPP radio access network standard;

Fig. 4 is a block diagram illustrating a method of transmitting, via the receiving side, a status report to the transmitting side after the clock has expired, according to one embodiment of the invention;

Fig. 5 is a block diagram illustrating a method of stopping a clock when receiving a PDU for which the clock has been started, according to one embodiment of the invention;

Fig. 6 shows the architecture of the L2 protocol and the sequential order of data processing by the transmitting side;

EP 2 188 952 B1

Fig. 7 shows an exemplary PDCP PDU control format for a PDCP status report, according to a first embodiment of the invention; and

Fig. 8 illustrates an example PDCP PDU control format for a PDCP status report, according to a second embodiment of the invention.

DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION [0034] The invention is applied to the long-term evolution (LTE) system of a mobile telecommunications system, and particularly to the developed universal mobile telecommunications system (E-UMTS). Evolved Universal Mobile Telecommunications System), which developed from UMTS. However, without being limited thereto, the invention may also be applied to any mobile telecommunications system and communication protocol to which the technical characteristics of the invention apply. [0035] Various modifications and embodiments can be made to the invention, and the detailed references will refer to preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings.

[0036] However, it should also be understood that the embodiments are not limited by any details of the description below, but instead their scope should be interpreted broadly, and it is envisaged that the invention includes modifications and variations of the invention assuming that they fall within scope of attached claims.

[0037] Although terms covering ordinal numbers such as first, second and so on may be used to explain the various elements, the elements are not limited to these terms.

[0038] The terms are used only to distinguish one element from another element. For example, the first element may be called the second element, and similarly the second element may be called the first element without departing from the scope of the invention. The term "and / or" is used to include a combination of many disclosed elements or one of the elements.

[0039] In the case where it is mentioned that a particular element is "connected" or "accesses" to another element, it can be understood that the particular element is directly connected or directly accesses the other element, or that this element is inserted between the elements. On the other hand, in the case where it is mentioned that a particular element is "directly connected" or "directly accesses" another element, it should be understood that any other element is not in between.

[0040] The terms used in the invention are merely for the purpose of explaining specific embodiments and are therefore not intended to be limiting. The singular expression includes the plural except for two expressions that are contextually different from each other. In the invention, the term "includes" or "ma" is intended to indicate that there are various features, figures, steps, actions, components, elements disclosed herein, or combinations thereof. Rather, the term "includes" or "has" is to be understood as not precluding the occurrence of one or more other features, figures, steps, actions, components, elements or combinations thereof, or additional possibilities.

[0041] Except where otherwise defined, all terms used in the invention comprising technical or scientific terms have the same meaning as terms generally understood by those skilled in the art to refer to the field of the invention. Terms that are the same as those defined in the general dictionary should be understood as terms having the same meaning as the contextual meanings of the related art. And, as long as the terms are not strictly defined in the invention, the terms are not interpreted as ideal or excessively formal.

[0042] The invention recognizes that there is no suitable PDCP PDU control format when the receiving party PDCP uses a status PDCP report to request retransmission of a PDCP SDU not received from the transmitting party PDCP as a peer.

[0043] Given this point, the invention conceptually relates to 1) notification by the PDCP entity of the state of the receive buffer in the form of a bitmap, and 2) defining the PDU format of the PDCP control in the form of a bitmap to notify the transmitting party PDCP as an equivalent unit . 3) That is, the receiving party PDCP expresses the receiving status of each PDCP SDU in 1 bit so that the receiving success is set to 1 and the receiving failure is set to 0. 4) In particular, the presence of a successful receipt is not determined by whether the PDCP PDU was received successfully or not, but by whether or not the PDCP SDU was received. That is, if the PDCP SDU obtained by decrypting and decompressing the header on the received PDCP PDU has no errors, it is considered a successful reception.

[0044] Among the terms used in the invention, the PDCP PDU sequence number (SN) and SDU PDCP sequence number (SN) are distinguished from each other. Below, referring to fig. 6, describes the difference between PDCP PDCP and SDU PDCP and the difference between SN PDU PDCP and SN SDU PDCP. It should be noted that the content of Fig. 6 is a citation from the content of Fig. 5 in the description of Korean Patent Application No. 10-20080021112 (filed March 6, 2008) (US Provisional Patent Application No. 60/895720 of March 19, 2007) used by the applicant. Meanwhile, other parts of the above application may be cited to clarify the invention.

[0045] Fig. 6 shows the architecture of the L2 protocol and the sequential order of data processing by the transmitting side.

[0046] Fig. 6 shows the sequential order of processing and transmitting data that has been received by the transmitting side of the RLC and PDCP layers in LTE from the upper layer. The sequential order is as below.

[0047] Among the terms used in the invention, SDU refers to data received from a higher layer, and PDU refers to data sent to a lower layer after receiving from a higher layer and processing. [0048] The terms required to explain the invention, i.e. the difference between PDCP PDU and PDU PDU and the difference between SN PDU PDCP and SN SDU PDCP will now be described with reference to Fig. 6.

S11: As shown in fig. 6, the PDCP layer receives from the upper layer data (PDCP SDU) for transmission to the lower layer. The PDCP layer sets the virtual sequence number (SN) Sequence Number) for each PDCP SDU. In this case, the SN SD PDCP are set sequentially to distinguish the corresponding PDCP SDU. Step S11 is carried out by the first positioning module. In S11 with fig. 6 SNs are not actually added to the PDCP SDU, but the corresponding PDCP SDUs are managed by the type of indicators (not shown) that are distinguished by each other SN. For this reason, SNs in step S11 are expressed as virtual SNs. In addition, this reason provides the implicit expression in step S11 in Fig. 6, where each SN (i.e. virtual SN) PDCP SDU is drawn with dashed lines.

S12: The PDCP layer stores the corresponding PDCO SDU in the PDCP SDU buffer. This is so that the source base station (i.e., the source NodeB) during the transfer of connection sends to the target NodeB SDU PDCP, whose selection has not been confirmed by the terminal (UE) to the target base station by the source NodeB. When PDCP SDUs are sent or retransmitted during call forwarding, only PDCP SDUs that have not been transferred or retransmitted

Correctly received by the receiving side according to the RLC layer or PDCP layer status report. This is called selective transfer / retransmission. Step 12 is performed by the PDCP SDU buffer. Two-time setup of virtual SN and three-time buffering of SDCP PDCP can be done simultaneously. If the PDCP layer does not support selective transmission / retransmission, the PDCP buffer may not be provided.

S13: The header compression unit (or header compression module) sequentially performs header compression on the PDCP SDU. In this case, the header compression unit may independently generate a header compression feedback packet or PDCP STATE PDU and so on that are not associated with the PDCP SDU.

S14: The PDCP layer sequentially encrypts the PDCP SDU with compressed headers. In this case, the PDCP layer performs encryption using virtual PDCP SNs that were set when the PDCP SDUs were saved in the buffer. Namely, SN PDCPs act as input parameters in the encryption algorithm to serve in generating each different encryption mask for each SDU. Step S14 is performed by the encryption module. In addition to encryption operations, the PDCP layer can perform a security function that includes integrity protection. Also, for integrity protection, the PCDP SDUs have protected integrity by using virtual PDCP SNs. The PDCP layer may include packets generated by the PDCP layer itself, such as feedback packet generated by the header compression unit and PDCP STATE PDU itself, and the like generated by the PDCP layer itself. The PDCP STATE Feedback or PDU packet and the like are not encrypted because they do not have any corresponding PDCP SDUs or any PDCP virtual SNs set.

S15: Virtual PDCP SN (i.e. SN set in step S11) corresponding to the corresponding SDU with compressed headers and encrypted by the above steps (S13 and S14) are attached to PDCP PDU headers for creating PDCP PDUs. Namely, when PDCP PDUs are sent to the RLC layer, the virtual PDCP SN set in step S11 are uniquely attached to the corresponding SDU as SN PDCP. Step S15 is performed by the second positioning module. In this case, since there are no virtual PDCP SNs set up for the feedback packet generated by the PDCP STATE header or PDU compression unit itself generated by the PDCP layer itself and the like, the PDCP STATE feedback or PDU packet and the like configure the PDCP PDU themselves without SN PDCP. The PDCP layer sends the PDCP PDU configured in this way to the lower RLC layer.

S16: After receiving the RLC SDU, namely PDCP PDU, from the PDCP layer, the RLC layer writes them to the RLC SDU buffer. It's for flexible support of the RLC layer PDU size.

S17: The RLC layer writes the RLC SDU to the SDU buffer, and when the lower MAC layer requests their transmission in each transmission period, the RLC layer segments and / or combines as many RLC SDUs as required according to the desired size. Step S17 is performed by the segmenting and joining module.

S18: The RLC layer sequentially attaches SN RLC to segmented and / or combined data blocks. In this case, the RLC layer can independently generate the RLC control PDU independently of the RLC SDU. Data blocks with connected SN RLC or PDUs RLC control free from SN RLC make up the RLC PDUs. Step S18 is performed by the third positioning module.

EP 2 188 952 B1

S19: Because the RLC AM layer supports retransmission, the RLC AMC layer writes the RLC PDUs created to the RLC PDU buffer. This is for retransmission which may later be necessary.

[0049] As described above, SN PDCP in steps S11 and S15 and SN RLC step S18 have different properties. Namely, SN PDCPs are used for encryption in the PDCP layer and ultimately used to send or retransmit only those PDCP data whose receipt has not been confirmed by the receiving party. Meanwhile, SN RLC are used in the RLC layer and have a different purpose from SN PDCP. That is, in the invention, when SDUs are received by the PDCP layer from the upper layer, SN PDCPs are attached to the SDU, and when SDUs with SN PDCPs are sent to the RLC layer, SN RLCs are additionally added to them.

[0050] Reference will now be made in detail to preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. Where possible, the same reference numbers will be used for the same or similar parts between drawings, and the same descriptions will be omitted.

[0051] The invention defines the PDCP control PDU format that the receiving party PDCP unit uses to transmit the status PDCP report to the transmitting party PDCP unit as a peer. To this end, the invention proposes a method for notifying the PDCP unit about the state of the receive buffer in the form of a bit map.

[0052] The following describes the format (or configuration) of the PDCP control PDU bitmap corresponding to the PDCP status report. A bitmap consists of one or more bits. Each bit of a bitmap contains information about the receiving status report, i.e. whether the PDCP SDUs were successfully received or not.

[0053] That is, the receiving party PDCP expresses the receiving status of each PDCP SDU in 1 bit, such that the receiving success is set to "1" and the receiving failure is set to "0". Here, the presence of successful reception is not determined by whether or not the PDCP PDU was received successfully, but by whether or not the PDCP PDU was received, that is, if the PDCP SDU obtained by decrypting and decompressing the header on the received PDCP PDU there are no errors, it is considered a successful receipt. This is each bit of the PDCP bitmap status report that acts as an indicator to indicate the presence of a successful receipt of a single PDCP SDU.

[0054] Bits adjacent to each other based on a specific bit (indicating the presence of successful PDCP PDU SDU reception) in the bitmap includes information regarding whether or not the PDCP SDU with adjacent sequence numbers were successfully received. Accordingly, all bitmaps serve as status reports indicating the receiving status (i.e., receiving success or receiving failure) of all PDCP SDUs with sequence numbers within a specified range.

[0055] However, the exact sequence numbers of each PDCP SDU cannot be identified solely by means of a bitmap. For notification of such exact sequence numbers, the sequence number corresponding to the first or last bitmap SDU should be added to the PDCP control PDU and then sent. In other words, if the receiving party PDCP transmits using the PDCP control PDU the receiving status of the PDCP PDU SDU in the form of a bitmap to the transmitting party PDCP, then the transmitting party PDCP as a peer cannot only determine using a bit map whether the PDCP SDU has been successfully received from received PDU PDCP control or not. Therefore, information is needed whether each bit of a bitmap indicates a PDCP SDU or not. For this purpose, the SN SDU PDCP information indicated by the first or last bit of the bitmap should

EP 2 188 952 B1 should be included in the PDC of the PDC. Such SN SDU PDCP information may be SN SDU PDCP corresponding to the first bit of the bitmap ("FSN" in Fig. 8) or SN SDU PDCP corresponding to the last bit ("LSN" in Fig. 7).

[0056] Also, when there is a need to notify the bitmap length, a Length field indicating the length is also needed.

[0057] In the following, referring to Figs. 7 and 8, a description is provided of the PDCP PDU control format for the PDC status report according to the invention.

[0058] Fig. 7 shows an exemplary PDCP PDU control format for a PDCP status report, according to a first embodiment of the invention. Here, Fig. 7 shows an embodiment containing the "LSN" field.

[0059] In addition to the D / C field and control PDU field, the PDCP control PDU format of Fig. 7 may include a LENGTH field, an LSN field, and a BIT MAP. Here, the LENGTH field is an optional field and may or may not be included in the PDCP control PDU.

[0060] The LENGTH field is added to the PDCP of the PDCP control when the bitmap length must be notified. When there is no need to notify the bitmap length, such as when the bitmap length is fixed or if the bitmap length can be derived from the PDU length of the PDCP control, the LENGTH field is not required.

[0061] The bitmap field contains information about the reception status of each PDCP SDU indicating whether the PDCP SDU received from the receiving side PDCP and processed by the receiving side PDCP unit was successfully received without any error or not. Here, the SN of the first or last PDCP SDU should be added for accurate notification of the sequence numbers of the respective PDCP SDUs corresponding to each bitmap. In fig. 7 the last SDU PDCP SN is added (this is the last sequence number (LSN Last Sequence Number)). In addition, fig. 7 shows the PDU format for PDCP control when the bitmap length should be transmitted.

[0062] The following describes in detail the setting method for the LSN and bitmap of Fig. 7.

- D / C: field indicating whether the relevant PDCP PDU is a data PDU or a control PDU.

- Control PDU type: a field indicating the type of relevant control information, for example, indicates whether the relevant control information is a status report or HC feedback.

- LSN field: contains the SN SDU PDCP value corresponding to the last bit of the bitmap. This is the SN SDU PDCP value that was last received or failed to be received by the receiving side PDCP. That is, by using the SN SDU PDCP corresponding to the last bit, the SN SDU PDCP indicated by each bit in the bitmap can be recognized. This is because each bit of a bitmap indicates the receiving status of subsequent PDCP SDUs. Accordingly, since the last bit, i.e. LSN, is the SN PDU PDCP indicated by the last bit (lowest bit) of the bit map, each SN of the respective PDCP SDU indicated by the bits below the last bit can be recognized. By using the bitmap format, the PDCP PDU size for the PDCP status report can be reduced and the radio resource efficiency increased.

- BIT MAP: contains (information) a report on the PDU PDU receipt status received from the transmitting party PDCP as an equivalent unit. In the bitmap field containing the reception status of each PDCP SDU, the target SDCP PDCPs are those whose SN is [LSN LENGTH * 8 + 1, LSN], which is between "LSN - LENGTH * 8 + 1" and "LSN". Every bit of each

The bitmap has information about the reception state (i.e., PDCP status report) regarding whether the PDCP SDU indicated by each bit has been correctly received or not. For example, if the LSN value is "100" and the LENGTH value is "5", the SN SDU PDCP range as the purpose of the receipt status report would be "61" ~ "100".

[0063] Each bit_position in the bitmap is 1 ~ LENGTH * 8, and for example, if the LENGTH is "5", each bit_position would be "1" ~ "40". That is the number of bits in the bitmap is 40. In other words, the number of PDCP SDUs that are the purpose of the receiving status reports (receiving success or failure) of the respective PDCU SDUs is 40. The interpretation of each bit_position is as follows:

♦ 1: successful receipt of the PDCP PDU, which has the PDCP sequence number = (LSN - LENGTH * 8 + bit_position).

♦ 0: SDU PDCP receiving failure which has PDCP sequence number = (LSN - LENGTH * 8 + bit_position).

[0064] Meanwhile, if the LENGTH is "0" the bitmap field does not exist. In this case, only LSN is included, assuming that all PDCP SDUs have been successfully received.

[0065] Fig. 8 illustrates an example PDCP PDU control format for a PDCP status report, according to a second embodiment of the invention. Here, Figure 8 shows an embodiment including the "FSN" field. Below, the embodiment of figure 8 will describe the differences to that of figure 7.

[0066] Compared to Fig. 7, the embodiment of Fig. 8 uses the first sequence number (FSN) instead of LSN to notify the exact sequence number of the SDU PDCP. FSN corresponds to the SN of the PDCP PDU target indicated by the first bit of the bitmap. That is, the first bit of the bitmap has information about the receiving status of the SDCP PDCP indicated by FSN.

[0067] Also, as in Fig. 7, when there is no need to notify the bitmap length, such as when the bitmap length is constant or if the bitmap length can be derived from the PDU of the PDCP control, the LENGTH field is not required .

[0068] The method of setting FSN and bitmap using FSN instead of LSN has little difference from the description of Fig. 7.

- FSN field:

[0069] The value of the FSN field indicates the SN SDU PDCP corresponding to the first bit of the bitmap field. [0070] The value of the FSN field corresponds to the PDCP SN SDU, which was not received first, by the receiving side PDCP from among the PDCP PDUs received from the transmitting side PDCP.

- BIT MAP [0071] Contains (information) a report on the reception status of PDCP PDUs received from the transmitting PDCP unit as a peer.

[0072] The BIT MAP range indicates the PDCP SDUs whose SNs are in the range [FSN, FSN + LENGTH * 8-1] and contains information about successful or unsuccessful reception.

[0073] In the BIT MAP containing the receiving status of each PDCP SDU, the target PDCP SDUs are those whose SNs fall between "FSN" and "LSN + LENGTH * 8-1". Each bit of a bitmap has information about the reception status (i.e. a PDCP status report) regarding whether or not the PDCP SDU indicated by each bit has been received correctly. For example, if the FSN value is "100" and the LENGTH value is "5", the SN SDU PDCP range as the purpose of the receipt status report would be "100" ~ "139".

[0074] Each bit_position in the bitmap is 1 ~ LENGTH * 8, and for example if LENGTH is "5", each bit_position would be "1" ~ "40". That is the number of bits in the bitmap is 40. In other words, the number of PDCP SDUs that are the purpose of the receiving status reports (receiving success or failure) of the respective PDCU SDUs is 40.

[0075] The method of interpreting each bit_position is as follows:

♦ 1: SDU PDCP receiving successful, which has PDCP sequence number = (FSN + LENGTH * 8 bit_position).

♦ 0: PDU PDCP receiving failure which has PDCP sequence number = (FSN + LENGTH * 8 bit_position).

[0076] Meanwhile, if the LENGTH is "0" the bitmap field does not exist. In this case, only LSN is included, assuming that all PDCP SDUs have been successfully received.

[0077] The embodiments of Figs. 7 and 8 describe the PDU format of the PDCP control of receive status information (i.e., PDCP status report) for a series of data (i.e., PDCP SDU) in which the receive side PDCP unit receives from the transmit side PDCP unit as an equivalent unit.

[0078] The method of transmitting the PDCP control PDU of the reception status information (i.e. the PDCP status report) for a series of data (i.e. the PDCP SDU) is summarized as follows.

[0079] The receiving side PDCP unit obtains the DPCP SDU by encrypting and decompressing the header on the PDCP PDU received from the sending side PDCP unit, and then checks whether or not each PDCP SDU has an error, thereby determining the success or failure of each from PDCP PDU.

[0080] The receiving side PDCP unit adds to the BIT MAP field each indicator (each bit of a bit map) indicating the receiving status (i.e. receiving success or failure) of each PDCP SDU.

[0081] The receiving side PDCP unit configures the PDCP control PDU containing the BIT MAP field and transmits the configured PDCP control PDU to the transmit side PDCP unit.

[0082] Meanwhile, the PDCP control PDU may include a LENGTH field indicating the size of the BIT MAP field.

[0083] Furthermore, the PDCP control PDU may include an LSN field or an FSN field. Here, the LSN field has information about the SN SDU PDCP corresponding to the last bit of the BIT MAP field. The FSN field has information about the SN SDU PDCP corresponding to the first bit (highest bit) of the BIT MAP field. In this way, the invention uses LSN and FSN fields, thus not requiring the SN of the corresponding PDCP SDUs for all bit_possition items of the BIT MAP field, thus limiting the PDU size of the PDCP control, as well as increasing resource efficiency.

[0084] The following describes the transmitter (transmitting device) and receiver (receiving device) according to the invention.

[0085] The receiver (receiving device) according to the invention comprises hardware, software, software module and the like which can implement the embodiments of figures 7 and 8.

[0086] The device according to the invention may be called a unit and the device according to the invention may be a terminal.

[0087] The receiver according to the invention may comprise a communication module capable of performing the functions described in figures 7 and 8.

[0088] That is, a communication module is provided to determine the success or failure of receiving each PDCP SDU in the order received through the PDCP layer, generating a status report for specific

The results are in the form of a bitmap and transmitting PDU for PDCP control containing a status report generated in the form of a bitmap.

[0089] The PDCP control PDU comprises an LSN field or an FSN field, here the field indicates the sequence number (SN) of the SDU PDCP corresponding to the last bit of the bitmap field, and the FSN field indicates the sequence number (SN) of the SDU PDCP corresponding to the first bit of the bitmap field.

[0090] The transmitter (transmitting device) according to the invention comprises a communication module capable of implementing the embodiments of Figures 7 and 8. Here, the functions of such a communication module have already been described in Figures 7 and 8, so its detailed description is omitted.

[0091] As described above, the receiver and transmitter of the invention generally include software, hardware in addition to those described above required to implement the technical idea of ​​the invention, such as an output unit (display, speaker and the like), an input unit (keyboard, microphone and the like similar), memory, microprocessor, transmitting / receiving unit (RF module, antenna and the like). Such elements are obvious to those skilled in the art, so their description is omitted.

[0092] The method described so far can be implemented by means of software, hardware or a combination thereof. For example, the method of the invention may be implemented by means of coding languages ​​or commands in a computer program that can be recorded on a data carrier (e.g., in the memory of a mobile terminal, flash memory, on a hard disk and the like), and which can be executed by a processor ( for example, the internal microprocessor of the mobile terminal).

[0093] It will also be apparent to those skilled in the art that various modifications and variations can be made to the invention without departing from the scope of the invention. Thus, it is envisaged that the invention includes modifications and variations of the invention, provided that they fall within the scope of the appended claims.