A method and a device for improved status reports

(54) Title: METHOD AND TRANSCEIVER FOR USE (57) Summary: IN A CELLULAR COMMUNICATIONS SYSTEM (30) Unionist Priority: 30/10/2007 us 60/983633,

01/02/2007 EP PCT / EP2007 / 050994, 02/01/2007 EP

PCT / EP2007 / 050994, 10/30/2007 US 60/983633 (73) Holder (s): Telefonaktiebolaget Lm Ericsson [Publ] (72) Inventor (s): Henning Wiemann, Johan Torsner, Michael Meyer (74) Attorney ( es): Momsen, Leonardos & Cia.

(86) International Order: pct se2008050108 of 28/01/2008 (87) International Publication: wo 2008 / 094i20de 07/08/2008

300

<td>D / C [typePDU | ACK SN</td>

<td>ΓεΤ NACK1 SN</td>

<td>| E l^F ~</td>

<td>NACK2 SN</td>

<td>Γ ε | FI NACK3 SN</td>

<td>| E | ^F</td>

<td>SO11</td>

<td>j</td>

<td>SO12</td>

<td></td>

<td>SO21</td>

<td>I</td>

<td>SO22</td>

<td></td>

<td></td>

PAD “METHOD AND TRANSCEIVER FOR USE IN A CELLULAR COMMUNICATIONS SYSTEM”

TECHNICAL FIELD

The present invention discloses a method for use in a cellular communications system, in which system traffic can be exchanged between a first and a second transceiver. Traffic is sent in data units, each of which is given an identifier and which can be divided into segments. A receiving transceiver can send status information in data frames or data units about data units transmitted to a transmitting transceiver, that is, to the transceiver from which the data was transmitted.

BACKGROUND

In the 3GPP LTE project (Projeto de Sociedade de 3 de^The generation, Long Term Evolution) for cellular communication systems, an RLC (Radio Link Control) protocol is used for communication between users in a cell and the cell's controlling node, that is, the so-called eNodeB, evolved NodeB.

In RLC, traffic is sent as called PDUs, that is, Protocol Data Units, which are identified by giving sequence numbers. In response to PDUs from a transmitting party, the receiving party sends so-called RLC status PDUs to the transmitting party, with so-called ACKs and / or NACKS, that is, acknowledgments (ACK) that data has been received correctly, or information (NACK) that data was not received correctly, that is, received only partially or in no way. The ACKs and NACKs on the RLC state PDUs are sent as PDU sequence numbers in order to identify the PDU in question.

In LTE systems, RLC PDUs can be segmented, which has the consequence that there will be two or more PDU segments with the same sequence number, since the sequence number is a property of the PDU. The process of segmenting PDUs is also referred to as re-segmentation.

Because of LTE re-segmentation, sequence numbers will not be enough to identify the data to which ACK or NACK is sent.

SUMMARY

As emerged from the explanation above, there is a need for a solution whereby ACKs and NACKs that are transmitted by a receiving party to a sending party on 3G LTE systems can be identified, with respect to the data segments to which they are sent. in response.

In addition, another need that should be addressed by the solution in question is that it should be possible to send a variable number of NACKs.

This need is addressed by the present invention since it exposes a method for use in a cellular communications system, in which system traffic can be exchanged between a first and a second transceiver. The traffic in the system is sent in data units, each of which is given an identifier. The data units can be divided into segments, and a receiving transceiver can send status information in data frames or data units about correctly received, partially received, or not received data units to a sending transceiver, that is, to the transceiver from which the data was sent.

According to the method of the invention, in the case of one or more data units partially or not received, the status information that is sent to the sending transceiver includes information on whether the data units were not received or partially received, and in the case of a partially received data unit, which parts of the data units that have not been received.

Thus, by means of the invention, it becomes possible for the receiving transceiver to distinctly identify parts of data units not received by the sending transceiver, thereby enabling the sending transceiver to retransmit those parts.

Also, the invention makes it possible to identify more or less any amount of data not received, which was another of the needs to be addressed by the invention.

In one embodiment of the invention, information about whether or not a data unit has been received or partially received is included as an indicator in said data frames or data units.

In another embodiment, information about which parts of a data unit that have not been received is included in the data frames or data units as information that indicates a first and a last part of the data not received.

In yet another aspect of the present invention, in the case that a data frame or unit of the sending transceiver has been segmented and one or more last segments have not reached the receiving transceiver, this can be indicated by the receiving transceiver.

In a further embodiment of the invention, information about whose parts of a data unit that have not been received is included in the data frames or data units as information indicating the data unit identifier, as well as information about the beginning of the data not received in said data unit, and the amount of data not received.

These and other aspects and advantages of the present invention will be explained in more detail in the detailed explanation given below.

The invention also exposes a transceiver for use in a system of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described in more detail in the following, with reference to the accompanying drawings, in which:

Figure 1 shows a schematic view of a system in which the invention can be applied; and

Figures 2-6 show several embodiments of the invention; and

Figure 7 shows a schematic flow chart of a method of the invention; and Figure 8 shows a block diagram of a transceiver of the invention.

DETAILED DESCRIPTION

Figure 1 shows a schematic view of a system 100 in which the invention can be applied. As previously mentioned, the invention is intended primarily for systems of the 3GPP LTE type, that is, systems of the Third Generation Society Project, Long Term Evolution, sometimes also referred to only as LTE systems, but officially in 3GPP known as Evolved UTRAN or E-UTRAN. These names will be used interchangeably throughout this description.

As shown in Figure 1, an LTE 100 system can include several so-called cells, one of which is shown as 130 in Figure 1. Each cell in an LTE system can accommodate multiple users, sometimes generically called UEs, User Equipment. In Figure 1, a UE is shown symbolically, with the reference number 120.

LTE systems like 100 in Figure 1 will also include an eNodeB, evolved NodeB, for each cell. One of the functions of a cell's eNodeB is to control traffic to and from users in a cell. In Figure 1, an eNodeB 110 is shown as the eNodeB for cell 130.

Traffic from eNodeB to an UE is called lower link traffic, or simply DL traffic, and traffic from the UEs to eNodeB is known as upper link traffic, or simply UL traffic.

In LTE systems, an RLC protocol. Radio Link Control, is used for communication between eNodeB and UEs in a cell.

According to RLC, in LTE systems, traffic between two transceivers, that is, a UE and its eNodeB is sent in so-called PDUs, Protocol Data Units. According to RLC, each PDU is assigned an identifier, a so-called sequence number, which allows both the sending and receiving parties to identify a PDU.

In the description below, it will be assumed that data PDUs are sent by eNodeB, that is, in DL, and that state PDUs are sent by a UE, that is, in UL. However, it should be shown that this is only an example intended to facilitate the reader's understanding of the invention, the invention can be applied equally well in the other direction, that is, Data PDUs in UL and State PDUs in DL. It can be mentioned here that EUTRAN RLC can operate in different modes, configured by eNodeB, ie Recognized Mode (AM), Unrecognized Mode (UM) and transparent mode (TM). State PDUs are currently used only in AM.

If eNodeB 110 sends a PDU that contains data to the UE 120, that is, a so-called data PDU, the UE can respond with a so-called state PDU, that is, a PDU that tells eNodeB the state of receipt of the data in the Data PDU that was sent from eNodeB.

In the state PDU for eNodeB, data units that are received correctly by the UE are recognized by the UE through so-called ACK messages or indicators, and data units that are received incorrectly, that is, they are only received in part, or not received in any way are indicated by the UE through a so-called negative ACK, a NACK. If the eNodeB from which the data originates receives a

In return for transmitted data, eNodeB will know that this information should be retransmitted, usually until an ACK is received. In the case of DL traffic data, a UE will thus send state PDUs with ACKs and / or NACKs to eNodeB in response to eNodeB data PDUs.

ACKs provide information on up to which sequence number PDUs were received correctly. This can be done either by providing the highest number of a PDU received successfully, or the first number of a PDU not received.

In E-UTRAN RLC, data PDUs can be re-segmented, that is, the payload of a previously created RLC PDU can, at the time of retransmission, be divided into segments that are sent separately.

In LTE, it is planned that RLC PDU segments should be identified by means of the sequence number of the original RLC PDU, as well as a so-called segmentation compensation, SO, which indicates the beginning of the segments in the original RLC PDU. An ACK or NACK is sent in the form of the sequence number of the original RLC PDU, but since re-segmentation may occur, the segments to which the UE ACK or NACK refers cannot be uniquely identified in eNodeB using the sequence number, and not even through the SO, due to the fact that segmentation can occur over several generations, that is, multiple re-segmentations can occur, and eNodeB does not know which generation the ACK / NACKs refer to.

It is this problem, that is, identification of RLC ACK / NACK: ed PDU data that the invention aims to address.

Different cases can be discerned when it comes to state PDUs:

The. A state PDU with only one ACK, and no NACK.

Ί

B. A state PDU with an ACK and one or more NACKs, which has two sub-cases:

i. One or more of the NACKs are segment NACKs.

ii. All NACKs are non-segment NACKs.

In order to deal with the case above, the invention proposes a state PDU which is shown in Figure 2 with the reference number 200. As shown in Figure 2, the state PDU 200 includes a D / C field 210, which indicates whether the PDU 200 is a data or control PDU. As will be understood, a state PDU is a control PDU.

In addition, the state PDU 200 includes an ACK field 220, with the ACK being provided in the form of the sequence number, SN, of the RLC PDU to which the ACK refers. The state PDU 200 also includes an indicator, for example an indication or bit, shown in Figure 2 as an E 230 bit, which is used to indicate the presence or absence of NACKs in the state PDU 200.

In the case of the absence of NACKs in the state PDU, that is, the case shown in Figure 2, called filling or false bits can be used in order to achieve correct alignment of the contents of the state PDU 200. An example of such an alignment is the called octet alignment, that is, alignment that is used if the state PDU is divided into data octets. The padding is shown as 240 in Figure 2.

Returning now to the case identified as bi above, that is, where one or more of the NACKs refer to segmented data units, in other words, the case in which the NACKs indicate that a data unit has been partially received, a concept used by invention will be introduced now. This concept is called here Segment Compensation pairs or SO pairs, that is, a data pair, one of which is used to indicate the first untouched data octet of the PDU to which NACK refers, and the other of which is used to indicate the last non-received data octet to which NACK refers. It can be added here that although octets are used to exemplify the invention, since octets are used in LTE RLC, the invention can be used naturally if data is sent in other sizes as well.

An example of a state PDU format 300 that can operate case bi ”above is shown in Figure 3. Similar to the state PDU format 200 in Figure 2, the state PDU format 300 includes a field that indicates whether the PDU 300 is a data or control PDU, and an ACK field with the ACK being provided in the form of the sequence number, SN, of the RLC PDU to which the ACK refers.

The state PDU 300 also includes an indicator, for example an indication or bit, shown in Figure 3 as an E bit, which is used to indicate the presence or absence of NACKs on the state PDU 300.

If one or more NACKs are included, as in Figure 3, each NACK is followed by an E bit or indication and an F bit or indication, where the E bit / indication indicates whether another NACK is present or not, and the bit / indication F indicates whether an SO pair is included for the particular NACK or not. In other words, the F bit / indication can be said to indicate whether the data unit to which NACK refers has been segmented or not, since it is the only case when SO pairs are used.

It can also be mentioned that the case of (for example) two missing parts, which but not consecutive of one and the same PDU can be operated by the present invention since one and the same NACK SN will occur twice, but with different SO pairs.

Similar to the embodiment of Figure 2, the ACKs and

NACKs of the state PDU 300 are provided in Figure 3 in the form of the sequence number, SN, of the RLC PDU to which the ACK or NACK refers, for which reason the ACK / NACKs are shown as ACKSN or NACK_SN.

After the last NACK of the state PDU 300 in Figure 3, the SO pairs are included for the NACKs to which the indications / F bits were set. Thus, the pair SO shown as SO11 and SO12 belong to NACK1SN, and the pair SO shown as SO21 and SO22 belong to NACK2_SN. Also, as shown in Figure 3, padding, PAD, can be used in the state PDU 300 of Figure 3 in order to achieve octet alignment or some similar purpose.

Returning now to the information included in the OS pairs, the first OS in an OS pair indicates the first lost data octet of the PDU, and the last OS in a pair indicates the last lost data octet in the PDU.

It should be shown that if the data in the received PDUs, that is, the PDUs to which the ACK / NACKs refer, are arranged in different groups of octets, the invention can certainly also be applied to such systems. The SO pairs would then indicate in a similar way to the one described above the beginning and the end of the data in the PDU to which NACK refers.

It can also be added that the state PDUs of the invention can also be expanded by means of a field after the D / C field, which indicates the nature of the state PDU, for example, if RLC control PDUs other than PDUs of STATE are used. This field is included in the example shown in Figure 3, indicated as the type of PDU. The same principle, that is, type of PDU, can be applied in the version shown in Figure 2.

With continued reference to the state PDUs of the invention, it should also be shown that the order of the data fields in the state PDUs shown in Figures 2 and 3 are only examples of suitable embodiments, the data fields in the state PDU of the invention can be moved to other positions in the state PDU without affecting the functionality of the invention, for example in order to achieve octet alignment. As an example, in the case with only one ACK and no NACKs, that is, the embodiment shown in Figure 2, the state PDU 200 could start with a D / C field followed by an E bit, followed by padding and finally the ACK with its sequence number.

Returning now to the case shown as b-ii above, that is, one or more NACKs refer to non-received data PDUs, instead of partially received data units, this is operated as follows: the F indicator corresponding to those NACKs indicates that no OS pairs are included in the state PDU for these NACKs.

A special case that is also dealt with by the invention is when the last PDU segment of an RLC PDU was not received by the UE (still assuming the case of DL PDUS data). Take an example where an RLC PDU with sequence number 10 has been segmented into 3 RLC PDUs, with the PDU segments containing octets

1-10, 11-25 and 26-40, respectively.

Now consider the case in which the UE received the first two RLC 10 PDU segments, that is, octets 1-10 and 11-25, and also received the next RLC PDU, that is, RLC 11 PDU, in its but the UE did not receive the last RLC 10 PDU segment, i.e., octets 26-40.

In this case, the UE knows that an RLC segment has been lost, but does not know its length, so the UE cannot fix the second segmentation compensation value in the corresponding SO pair in the state PDU. A solution to this that is proposed by the invention is to let a special value of an OS indicate that the end of the NACK: ed segment is not known. Thus, when eNodeB receives a NACK for RLC 10 PDU, a first SO is set to 26 and the second corresponding SO is set to the special value that tells eNodeB that all data octets of 26 and later for RLC 10 PDU need to be relayed.

In some cases, an OS pair is not always necessary to achieve the desired effect. As will be shown in the following, using two bits in the F ”field, a complete identification of the data not received can be achieved.

This is shown in the example in Figure 4, in which all four combinations of two bits in the F field are illustrated, that is, 00, 01, 10 and 11. The meanings of each of these combinations are also indicated in Figure 4, as follows:

Campo F Meaning

NACK refers to the entire RLC PDU, so no OS is needed.

NACK refers to a first part of the RLC PDU, 1

SO is needed in order to have the last group of data not received, such as, for example, an octet.

The NACK refers to a last part of the RLC PDU, 1 SO is needed in order to indicate the first group of data not received, such as, for example, an octet.

The NACK refers to a middle part of the RLC PDU, 2 SOs are needed in order to indicate the first and the last group of data not received, such as, for example, an octet.

It should be shown that in the case shown in Figure 4, similar to the embodiments shown previously, a type field may be needed in order to separate state RLC PDUs from other RLC control PDUs.

In another embodiment of the present invention, partially received DL RLC data PDUs are indicated to the eNodeB by the UE in a UL state RLC PDU in a slightly different way than shown above, i.e., the SO pairs. In the materialization in question, the

RLC 500 state PDU which is shown in Figure 5 the UE UL state RLC PDU includes a NACK field, shown as 510, and a sequence number field, SN, shown as 520, which indicates the sequence number of the DL RLC data PDU to which the NACK refers. Of course, in embodiment 500, SN can also be included together with NACK, as shown in previous embodiments.

Similar to the previous embodiments, embodiment 500 also includes the use of an E field, shown as 530 in Figure 5. However, the meaning of the E field, that is, a bit or an indication, differs slightly from that of the previous embodiments: In embodiment 500 of Figure 5, field E is used to mean whether NACK 510 refers to an entire RLC data PDU or to data within an RLC data PDU. For example, if field E equals zero, E = 0, this could mean that NACK 510 refers to the entire RLC data PDU that is identified by SN 520.

Conversely, if E = 0 means an entire PDU, then E = 1 means that NACK 510 refers to data within the PDU identified by SN 520. In this case, information is included in state PDU 500 in order for eNodeB to be able to identify the data in question. This data-related information in embodiment 500 includes a segment compensation value, SO, shown as 540 in Figure 5. SO 540 indicates byte compensation or the beginning of the DL data not received. However, in contrast to the previous embodiments, embodiment 500 does not use SO pairs to indicate the totality of data not received. Instead, embodiment 500 uses a Length Field, LF, 550, the value of which indicates the beginning of the data not received, from the value SO 540, up to the last byte of the data not received.

As can be seen, in this embodiment of the invention, that is, that shown in Figure 5, in order to achieve efficient retransmission of the original sender of the data, the exact number of bytes that should be retransmitted needs to be indicated to the sender. Since RLC LTE PDUs can be quite large (for example 32767 bytes), the fields (ie, SO and LF) needed to indicate the RLC PDU segments would need to be quite large equally. However, as will also be perceived, in many cases the maximum theoretical size of the SO and LF fields will not need to be used, which would thus lead to a waste of data space if the size of these fields were made static.

In one embodiment of the present invention, the inventors propose to alleviate this problem, that is, inefficient use of data space for the SO and LF fields. This embodiment will be described in the following.

In this aspect of the invention, a basic principle is that the SO and LF field sizes in the RLC state PDU are made adaptable to the needs of the current RLC state PDU. Obviously, it is possible to use two different sizes for SO and LF, for example 6 bits for RSO and 4 bits for RSL. However, in the subsequent description, it will be assumed that the size is the same.

If, as proposed in this aspect of the present invention, a dynamic length field for SO and LF is used, eNodeB (in the case of data in DL and status messages in UL) must know this length field size in order to be able to read the status message.

A first way to accomplish this is to have an additional field in the RLC status PDU message header that is indicative of the size of the SO and LF fields. For example, there could be a field that indicates that all length fields in the current message are 6 bits. This size could differ from RLC PDU status message to status message.

If the SO and LF were given different size values, two such length fields would be needed, or use could be made of a predefined relationship between them, for example SO is always x bits longer / shorter than LF. However, since SO and LF are typically of the same order, this optimization might not be required.

According to an alternative aspect of the invention, the explicit indication of the size of the SO and LF fields is superfluous, due to a rearrangement in the RLC PDU status message. In this aspect of the invention, it is proposed to move the fields of length SO and LF to the end of the RLC PDU status message, which will be described with reference to Figure 6.

In the embodiment shown in Figure 6, the status information for all included PDUs is provided first, that is, SN (segment number), RF (Re-segmentation Indication) and an extension bit, E. Thus, it will be It is also possible to include complete PDUs, where no specific segment information needs to be sent. For PDUs where re-segmentation has occurred, RF is used to indicate that segment location and length information follows, and SO and LF are attached to the message board.

Thus, in the embodiment of Figure 6, the dynamic part of the status message, that is, SO and LF, occurs after the last bit of extension E, that is, after the first bit E with a value indicating that it is the last, such as for example the value 0. Since the global message size in this embodiment needs to be known, for example from a MAC or RLC header, the receiver knows how many bits are left for the SO and LF fields. It also knows how many OS and LF pairs will follow after the last bit of extension. Thus, the receiver can calculate the sizes of the SO and LF fields.

If it is a requirement that the RLC status PDU should be aligned in bytes, an additional step has to be performed, since the number of bits remaining is also divided by the number of indicated segment fields. The integer result is used as the length, while the remaining bits are not used. As an example, if the remaining length is 51 bits, and byte alignment (8 bits) is used, we obtain the calculation 51/8 = 6 mod 3. Thus, in this example, 3 bits at the end of the state PDU will not be used.

In the example above, the LF is used to determine the end of an RLC PDU segment. However, it would be possible within the scope of the present invention to use absolute compensation, similar to the SO. In such a case, the offset would point to the original position of the last byte in the RLC PDU segment.

The status message content could describe data that is either ACKred or NACKred. Also, a mixture of ACKs and NACKs could be included, with one or more additional bits to provide a suitable ACK / NACK indicator.

The status message described in Figure 6 should only be seen as an example, additional fields as type indications to indicate whether the PDU contains data or a state, additional length fields and so on could be required in some applications, and would be within the scope of this invention.

Explicit status information can also be added to status reports, especially if the pattern or implementation allows multiple types of states to be reported, for example NACK and ACK.

An explicit indication of a status may also be necessary if the LTE system is configured to exchange a status report of a single type, for example only NACKs. Alternatively, the status report sender can receive a request for a status report of a certain type from the PDU sender (eg NACK only) and thus generate the status report only for the subset of received segments that were not received.

In a further aspect of the invention, it could be envisaged to send the RLC PDU status message as a separate PDU, or attached with another PDU.

Figure 7 shows an approximate flow chart of a method 700 of the invention. Steps that are options or alternatives are shown with dashed lines.

As indicated in the description above, the method of the invention is designed for use in a cellular communications system such as 100 in Figure 1, that is, a system in which traffic can be exchanged between a first and a second transceiver such as UE 120 and eNodeB 120.

Traffic on system 100 is sent in data units, and each of these data units is given an identifier. The data units can be divided into segments, and a receiving transceiver can send status information in data frames or data units about correctly received, partially received or not received data units to the sending transceiver, that is, to the transmitter's transceiver. which data was sent.

According to inventive method 700, as indicated in step 705, in the case of one or more units or units of data partially or not received, the status information that is sent to the sending transceiver includes, as shown in step 710, information about whether the unit of data units were not received or partially received, in which case, as shown in step 715, in the case of one or more data units partially received, whose parts of those data units were not received.

In one embodiment of the invention, as shown in step

720, information on whether or not a data unit was partially or not received is included as an indication in said data tables or data units.

As indicated in step 725, in a further embodiment of the invention, information about whose parts of a data unit that were not received is included in said data frames or data units as information indicating a first and last part of the unit data received.

Step 730 indicates that in one aspect of the invention, if a frame or data unit of the sending transceiver has been segmented or segmented, and a last segment has not reached the receiving transceiver, this can be indicated by the receiving transceiver to the sending transceiver, appropriately by means of a special default value for the information about the last part of the segments not received.

Step 735 indicates that in an embodiment of the invention, if a frame or data unit of the sending transceiver has been segmented and a last segment has not reached the receiving transceiver, this can be indicated by the receiving transceiver to the sending transceiver.

As previously indicated in this description, and as shown in step 740, method 700 of the invention can be applied properly to an LTE, Long Term Evolution system, such as 100 which is shown schematically in Figure 1.

If the inventive method 700 is applied to an LTE system, the data PDUs can be sent in DL and the corresponding status PDUs will then be sent in UL, as indicated in step 750, in which case the sending transceiver mentioned above is the eNodeB of an LTE cell, and the receiving transceiver is a User Equipment, UE, of the LTE cell.

Conversely, the invention can be applied equally well so that the data PDUs can be sent in UL and the corresponding status PDUs will then be sent in DL, as indicated in step

745, in which case the sending transceiver mentioned above is the UE of an LTE cell, and the receiving transceiver is the eNodeB of the LTE cell.

With reference to the state PDU 300 shown in Figure 3, it can be shown that the information from the receiving transceiver to the sending transceiver can be sent as a message that has the possibility of including one or more of the following:

Information (D / C) about the nature of the message, for example data or control message;

Information (type of PDU) about the type of message within said nature, for example a status message in the case of a control message;

Data (ACK) correctly recognizing units or frames of data received in the form of a certain sequence number;

A first extension indicator (E);

Data (NACK) relating to a unit or data frame not or partially received in the form of a certain sequence number (SN) of said unit or data frame;

A second extension indicator (F);

Information about the beginning (SO11, SO21) and end (SO12, SO22) of data not received.

In the exemplary state PDU shown in Figure 3, the first extension indicator, E, indicates the absence or presence of a set including another of the first, and second extension indicators, that is, E and F, and data, NACK, relative to a unit or data frame partially or not received, in the form of the identifier, SN, of the data unit or frame. The second extension indicator, F, indicates the absence or presence of information about the beginning, SO11, SO21, and end, SO21, SO22, of data not received.

The invention also exposes a transceiver for use in a system in which the invention is applied. As emerged from the description above, the invention can be applied both when data PDUs are sent in DL and the corresponding state PDUs are sent in UL, in which case the data-sending transceiver (in the case of E-UTRAN applications) is the eNodeB and the receiving transceiver, that is, the transceiver that transmits state PDUs is the UE, or conversely, when data PDUs are sent in UL and the corresponding state PDUs are sent in DL, in which case the data-sending transceiver is the UE and the receiving transceiver, that is, the transceiver that transmits state PDUs is eNodeB. SO, the transceiver of the invention can be either an E-UTRAN eNodeB or an E-UTRAN UE.

A schematic block diagram of a generic inventive transceiver 800 for use as an E-UTRAN eNodeB or an E-UTRAN UE is shown in Figure 8. As indicated in Figure 8, transceiver 800 will include an antenna, shown as block 810 , and will also include a receiving part 820 and a transmitting part 830. In addition, transceiver 800 also includes a control means 840 such as a microprocessor, as well as a memory 850. In addition, if transceiver 800 is to be used as an eNodeB, transceiver 800 also includes an 860 interface for other components in the system apart from the UEs. Since the interface may not be present if transceiver 800 is a UE, interface 860 is shown with dashed lines.

Transceiver 800 can use antenna 810, receiving part 820 and transmitting part 830 to send traffic and receive traffic from a second transceiver in the system, and transceiver 800 can use control means 840 together with memory 850 to send said traffic in data units.

The 840 control medium can also be used and the memory

850 to give each of the data units an identifier, such as a sequence number, for example, and the same means, ie blocks 840 and

850 can be used to divide data units into segments.

The inventive transceiver 800 also uses control means 840, memory 850, transmitter 830 and antenna 810 to send information in data frames or data units about correctly received, partially received or not received data units to the second transceiver, that is, to the transceiver from which the data was sent.

In addition, transceiver 800 can use control means 840 and memory 850 to, in the case of one or more data units not received or partially received, include information in the status information about whether the data unit or units were not received or partially received, and in the case of one or more data units partially received, parts of which data units were not received.

In one embodiment, means 840 and 850 are used by transceiver 800 to include information on whether or not a data unit was partially or not received as an indication in said data frames or data units.

In addition, in a further embodiment, blocks 840 and 850 are used by the transceiver to include information about which parts of a data unit were not received in said data frames or data units as information indicating a first and a last part of the data unit not received.

In another aspect of the invention, control means 840, memory 850, transmitter 830, together with antenna 810 can be used by transceiver 800 to indicate to a sending transceiver whether a frame or data unit of the sending transceiver has been segmented, and a last segment did not reach transceiver 800.

The indication about a lost segment is carried out properly by using a special predefined value for the information about the last part of the lost segment.

In one embodiment, control means 840 and memory 850 can be used by transceiver 800 to include information about which parts of a partially received data unit were not received in said data frames or data units as information indicating the data unit identifier, as well as information about the beginning of the data not received in said data unit, and the amount of data not received.

In addition, antenna 810, transmitter 830, control medium 840 and memory 850 can be used by the inventive transceiver to send status information to a sending transceiver as a message, such as the 300 in Figure 3, which can include one or more of the following:

Information (D / C) about the nature of the message, for example data or control message;

Information about the type of message within said nature, for example a status message in the case of a control message;

Data (ACK) recognizing units or frames of data received correctly in the form of a certain sequence number;

A first extension indicator (E);

Data (NACK) relating to a unit or frame of data not received or partially received, in the form of a certain sequence number;

A second extension indicator (F);

Information about the beginning (SO11, SO21) and end (SOI2,

SO22) of data not received.

Conveniently, the first extension indicator (E) indicates the absence or presence of a set including another one of said first (E) and second (F) extension and data indicators (NACK) related to a unit or frame partially or not received in the form of the identifier (SN) of said unit or data frame, and said second extension indicator (F) indicates the absence or presence of information about the beginning (SOI 1, SO21) and end (SOI2, SO22) of data not received .

The invention is not limited to the examples of embodiments described above and shown in the drawings, but can be varied freely within the scope of the appended claims.