Technical Field

The disclosure relates in general to methods and nodes for use in a communication network and in particular to methods in a control node and methods in a radio access node in a communication network and control nodes and radio access nodes in a communication network.

Background

Due to the noisiness of over-the-air radio communication, data transmission between a terminal device and the network in a mobile communication system is usually considered non-reliable. Most mobile communication systems use a layered architecture where each layer performs specific functions and communicates with a peer entity in the same layer on the other side over the air interface. Transmission between different layers on the same side (e.g. within the terminal device or within the network node) is considered reliable. Thus, when a message is passed down to a lower layer, it is considered delivered. The reliability aspects are handled within the lower layer, e.g., by performing retransmissions, and are usually not a concern for the higher layer.

Figure 1 illustrates generic layered peer-to-peer communication between a terminal device and a mobile network. The protocol stack can be divided roughly into L1 - Layer 1 (the physical, PHY, layer), L2 - Layer 2 (the data link layer(s)), and L3 - Layer 3 (the network layer(s); although only the control-plane Radio Resource Control, RRC, protocol is shown in Figure 1). Layer 2 is often divided further into the Radio Link Control, RLC, and the Medium Access Control, MAC, layer for the control plane and also the Packet Data Convergence Protocol, PDCP, layer (not shown in Figure 1) for the user plane. In cases where reliability is critical, explicit acknowledgement is requested between the peer entities of the same layer (and sometimes also between adjacent layers). In layer 3, Radio Resource Control (RRC) procedures often end with an acknowledgement in the form of a "Complete" or "Confirm" message. For example, "Cell Update" is acknowledged by "Cell Update Confirm". In layer 2, the Radio-Link Control protocol (RLC) runs in 3 different modes: Acknowledged mode (AM), Unacknowledged mode (UM), and Transparent mode (TM). For RLC AM, acknowledgement is requested by setting a poll bit in a RLC header of a transmission. The RLC entity on the opposite side then responds with an RLC control protocol data unit (PDU) acknowledging the correctly received RLC PDUs.

In layer 1 , with the introduction of High Speed Downlink Packet Access (HSDPA) and Enhanced Uplink (EUL) in Third Generation Partnership Project (3GPP) Release 5 and 6, each physical transmission is acknowledged in a dedicated physical control channel. On the UE side, the High Speed-Dedicated Physical Control Channel (HS-DPCCH) carries the acknowledgements for successful reception and decoding of High Speed- Downlink Shared Channel (HS-DSCH) transmissions, and on the network side, the Enhanced Dedicated Channel (E-DCH) Hybrid Automatic Repeat Request (ARQ) Indicator Channel (E-HICH) carries similar acknowledgements for E-DCH transmissions. Both HSDPA and EUL are equipped with multiple hybrid ARQ (HARQ) processes, which perform automatic retransmission of any transmission that is not positively acknowledged. In earlier 3GPP releases, L1 transmissions are not acknowledged. The round-trip time, i.e., the time it takes for the acknowledgement to come back after a transmission, differs significantly between the different layers. It typically ranges from a few milliseconds (ms) to up to 40 ms for L1 (depending on the Transmission Time Interval (TTI) length and the number of HARQ processes), to 100-200 ms for L2, and to 0.5 to 1 seconds (s) or even more for L3.

For a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), the network side is made up of two types of nodes: Radio Network Controllers (RNCs) and radio base stations (RBSs) called Node Bs, with one RNC controlling a, usually large, number of RBSs. The RRC and RLC protocols originate and terminate in the RNC while the HARQ protocol originates and terminates in the RBS.

For higher-layer protocol and procedures such as RRC, messages are exchanged directly between the terminal device (referred to as a User Equipment (UE)) and RNC and pass through the RBS transparently (i.e. the RBS relays the messages between the RNC and UE). The RBS is responsible for the delivery the messages in a generic way (e.g. via the physical layer) and is unaware of the identity of the messages.

Figure 2 shows the protocol stacks for UTRAN 2 including the split of the radio access network (RAN) into the RNC 4 and the Node B 6. The MAC protocol is split into multiple layers, MAC-d, MAC-c and MAC-is which operate in the RNC 4 and UE 8, and MAC-i and MAC-ehs which operate in the Node B 6 and UE 8. To improve the reliability of the Uu interface (the interface between Node B 6 and UE 8), the layers that are directly supervising the physical transmissions, MAC-ehs (on the downlink, DL) and MAC-i (on the uplink, UL) implement the HARQ protocol, which makes use of fast retransmissions. UL and DL data are carried over the lub interface (the interface between the RNC 4 and Node B 6 provided by a Transport Network Layer, TNL) using different lub frame protocols (HS-DSCH frame protocol, FP, and e-DCH FP). Figure 3 shows the protocol stacks for UTRAN 2 in the situation where the UE 8 is connected via a drift RNC (DRNC) to a serving RNC (SRNC) using a lur interface.

In UTRAN, a UE can be in one of five states: IDLE, URA_PCH, CELL_PCH, CELL_FACH, and CELL_DCH. The IDLE state is also called the idle mode and the rest are collectively referred to as the connected mode. Data transmission and reception (other than reading broadcast information and paging indications) are not possible in IDLE, URA_PCH, and CELL_PCH. To do so, the UE needs to transition to the CELL_FACH state, and for the UE to know that it has data to receive, it must be notified via paging.

When a data unit is passed to an RLC entity in Layer 2, it may be segmented if it cannot fit into a single RLC PDU. It may also be concatenated with an earlier or later data unit if it does not fill up a whole RLC PDU. Various headers are added depending on whether the data unit is to be transmitted in Acknowledged Mode (AM), Unacknowledged Mode (UM), or Transparent Mode (TM). The results are then passed down to the MAC-d layer, which may or may not add an additional header.

The MAC-d PDUs are transmitted from the RNC 4 to the RBS 6 over the lub interface. They are then assembled into Transport Blocks (TBs) by adding appropriate headers and any necessary padding. For transmissions over HS-DSCH, two types of high speed (HS) transport protocols are used: MAC-hs and MAC-ehs. MAC-ehs is an enhanced version of the MAC-hs protocol. It accepts variable MAC-d PDU size and is capable of segmenting and reassembling MAC-d PDUs to minimise the need for padding and to reduce the amount of protocol overhead. This handling is shown in Figure 4 for the MAC-hs case.

This figure shows the processing of incoming "higher layer" data (when read from top to bottom). The higher layer PDU may be an RRC message or a user data unit in the form of a PDCP PDU. Various headers are attached to the data by the different L2 protocols. Note that a MAC-d header is needed only if different logical channels are multiplexed on the same MAC-d flow. The MAC-d PDUs are transmitted over the lub interface inside an lub data frame (not shown). In Figure 4, the operations covered by bracket 20 represent segmentation and concatenation of service data units (SDUs) or reassembly of SDUs (depending on whether the data is flowing up or down the protocol stack). It will be noted that in Layer 1 , Cyclic Redundancy Check, CRC, information is added to the Transport Block as part of the HARQ protocol.

When transmitted over the lub interface, the MAC-d PDUs are carried inside an lub data frame. Two types of HS-DSCH data frames can be used, one for fixed MAC-d PDU size and one for flexible MAC-d PDU size. The structure of the two types of data frames are shown in Figures 5 and 6 respectively. The bits in the data frame 22 are transmitted from left to right (i.e., bit 7 first) and then from top to bottom.

As shown in Figures 5 and 6, in general the data frames 22 are divided into a header part 24 and a payload part 26. The header 24 provides some control information concerning the payload 26. Additional control information can also be carried in the payload 26 of the data frame 22.

The data frame 22 in Figure 5 is used for carrying data with fixed MAC-d PDU size. The common PDU size and the number of PDUs in the data frame 22 are given in the "MAC-d PDU Length" and the "Num Of PDUs" fields in the header 24.

The data frame 22 in Figure 6 is used for carrying data with flexible MAC-d PDU size. Consecutive MAC-d PDUs 28 from the same logical channel and having the same size are grouped into PDU blocks 30. Each PDU block 30 (which may contain one or more PDUs) are indicated in the header 24 by an Information Element (IE) group 36 "MAC-d PDU Length in block n", "#PDUs in block n", and "Logical CH ID block n" for the PDU size, number of PDUs, and the logical channel of the block respectively.

In both frame types, one or more octets of New Information Element Flags (NIFs) may follow immediately after the last MAC-d PDU 28. Bits 0-6 of each octet are Boolean flags that indicate if specific control information will follow. Bit 7 is used as an extension flag, which indicates that the current octet is followed by another "New IE Flags" octet. It should be noted that some spare bits exist in the header 24 and the payload 26 of the data frames 22 as defined in the specification. These spare bits are set to "0" and can be used for further extensions of the protocol as set out in later or revised versions of the standards. In Figure 5, spare bits 32 are found in each MAC-d PDU 28. In Figure 6 multiple sets of spare bits 34 are found in the header 24, for example in each IE group 36.

Summary

In some situations, it is critical for the network to know if the UE has successfully executed a procedure, but there may still be some ambiguity on the part of the network that cannot be resolved by simply sending more acknowledgements (ACKs). One specific example is the case where the UE is ordered to transition from CELL_DCH or CELL_FACH to one of the paging states, e.g., URA_PCH.

The RNC sends a Radio Bearer Reconfigure message to the UE and the UE responds with a Radio Bearer Reconfigure Complete message before making the transition. Both messages are sent using RLC AM which means that the procedure should be quite robust.

However, despite the RLC acknowledgements, there is the problem that after transmitting a RLC ACK for the L3 Radio Bearer Reconfigure Complete message, the RNC does not know if the ACK has been received correctly by the UE or not. This ambiguity has significant consequences since if the UE has received the ACK, it will transition to URA_PCH and will only be reachable via paging, whereas if the UE has not received the ACK, it will remain in CELL_FACH and be reachable in a different way. One way to work around this problem is to note that if the UE has not received the RLC ACK correctly, it would retransmit the L3 message (Radio Bearer Reconfigure Complete) when the RLC retransmission timer expires. The RNC, therefore, waits to see if the L3 message is received again. If it doesn't receive the message again, the RNC can conclude that the UE has most likely received the ACK correctly. However, to account for possible loss of the message over the air, this waiting must be long enough to allow for several RLC retransmissions. The result is the RNC waiting on the order of 1 second. This long waiting leads to reachability problems and the tying up of system resources. This is an unfortunate situation since in the majority of the cases, the UE would have received the ACK correctly and the RNC is just waiting for a retransmission that will never come.

It will be appreciated that the above example is just one of many examples where the lack of information in the RNC on whether a data unit has reached the UE can cause sub-optimum performance of the RNC/network.

With the advent of High Speed Packet Access (HSPA), fast and robust L1 acknowledgements are made possible by the use of HARQ processes and new physical control channels. These acknowledgements constitute a large amount of information that is currently used for RBS-internal purposes only since it is neither practical nor necessary to transfer all of this information up to the RNC.

Thus, the techniques described herein make use of the L1 HARQ acknowledgement capability to provide a solution to the problem described above. Briefly, a method is provided for an RNC (or more generally a control node) to request L1 delivery confirmation for specific data units from the RBS (or more generally a radio access node). On reception of these data units, the RBS notifies the RNC when it has received a positive acknowledgement from the UE for the over-the-air transmission or when the over-the-air transmission has failed after a certain number of HARQ retransmissions.

This technique therefore can provide better latency to the end user and improve the utilization of system resources. For example, when the L1 delivery result shows that the terminal device has received the data in question, system resources used for the old configuration can be released immediately, and any new data can be sent to the terminal device in the new configuration earlier. If the L1 delivery result shows that the transmission has failed, the data can be retransmitted immediately without having to wait for L2 or L3 timeouts.

According to a first exemplary aspect, there is provided a method of operating a control node in a communication network, the method comprising sending a data unit for a terminal device to a radio access node in the communication network; sending a delivery information request for the data unit to the radio access node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; and receiving delivery information for the data unit from the radio access node, the delivery information being based on a hybrid automatic repeat request, HARQ, protocol used by the radio access node to transmit the data unit to the terminal device over the air interface. According to a second aspect, there is provided a control node for use in a communication network, the control node being adapted to send a data unit for a terminal device to a radio access node in the communication network; send a delivery information request for the data unit to the radio access node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; and receive delivery information for the data unit from the radio access node, the delivery information being based on a hybrid automatic repeat request, HARQ, protocol used by the radio access node to transmit the data unit to the terminal device over the air interface.

According to a third aspect, there is provided a method of operating a radio access node in a communication network, the method comprising receiving a data unit for a terminal device from a control node in the communication network; receiving a delivery information request for the data unit from the control node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; transmitting the data unit to the terminal device over the air interface using a hybrid automatic repeat request, HARQ, protocol; receiving an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface; and sending delivery information for the data unit to the control node, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface.

According to a fourth aspect, there is provided a radio access node for use in a communication network, the radio access node being adapted to receive a data unit for a terminal device from a control node in the communication network; receive a delivery information request for the data unit from the control node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; transmit the data unit to the terminal device over the air interface using a hybrid automatic repeat request, HARQ, protocol; receive an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface; and send delivery information for the data unit to the control node, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface.

According to a fifth aspect, there is provided a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of the aspects described above.

According to a sixth aspect, there is provided a control node for use in a communication network, with the control node comprising a processor and a memory. The memory contains instructions executable by the processor whereby the control node is operative to send a data unit for a terminal device to a radio access node in the communication network; send a delivery information request for the data unit to the radio access node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; and receive delivery information for the data unit from the radio access node, the delivery information being based on a hybrid automatic repeat request, HARQ, protocol used by the radio access node to transmit the data unit to the terminal device over the air interface. According to a seventh aspect, there is provided a radio access node for use in a communication network, with the radio access node comprising a processor and a memory. The memory contains instructions executable by the processor whereby the radio access node is operative to receive a data unit for a terminal device from a control node in the communication network; receive a delivery information request for the data unit from the control node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; transmit the data unit to the terminal device over the air interface using a hybrid automatic repeat request, HARQ, protocol; receive an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface; and send delivery information for the data unit to the control node, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface.

According to an eighth aspect, there is provided a control node for use in a communication network. The control node comprises a first sending module configured to send a data unit for a terminal device to a radio access node in the communication network; a second sending module configured to send a delivery information request for the data unit to the radio access node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; and a first receiving module configured to receive delivery information for the data unit from the radio access node, the delivery information being based on a hybrid automatic repeat request, HARQ, protocol used by the radio access node to transmit the data unit to the terminal device over the air interface.

According to a ninth aspect, there is provided a radio access node for use in a communication network. The radio access node comprises a first receiving module configured to receive a data unit for a terminal device from a control node in the communication network; a second receiving module configured to receive a delivery information request for the data unit from the control node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; a first transmitting module configured to transmit the data unit to the terminal device over the air interface using a hybrid automatic repeat request, HARQ, protocol; a third receiving module configured to receive an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface; and a first sending module configured to send delivery information for the data unit to the control node, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface.

Brief Description of the Drawings

Features, objects and advantages of the presently disclosed techniques will become apparent to those skilled in the art by reading the following detailed description where references will be made to the appended figures in which:

Figure 1 illustrates generic layered peer-to-peer communication between a terminal device and a mobile network;

Figure 2 shows the protocol stacks for UTRAN;

Figure 3 shows the protocol stacks for UTRAN when a drift RNC is used; Figure 4 shows the data flow for transmission on HS-DSCH using MAC-hs; Figure 5 shows a HS-DSCH data frame type 1 ; Figure 6 shows a HS-DSCH data frame type 2;

Figure 7 is a block diagram of a radio access node according to an exemplary embodiment;

Figure 8 is a block diagram of a control node according to an exemplary embodiment;

Figure 9 is a flow chart illustrating a method in a communication network according to an exemplary embodiment of the techniques described herein;

Figure 10 shows an exemplary lub control frame for reporting delivery information;

Figure 11 shows HS-DSCH data frame types 1 and 2 that include a Request ID according to an exemplary embodiment; Figure 12 shows another exemplary mechanism for requesting delivery information;

Figure 13 is a flow chart illustrating an exemplary method of operating a control node; Figure 14 is a flow chart illustrating an exemplary method of operating a radio access node;

Figure 15 is a block diagram of a control node according to another exemplary embodiment;

Figure 16 is a block diagram of a radio access node according to another exemplary embodiment;

Figure 17 is a block diagram of a control node according to yet another exemplary embodiment; and

Figure 18 is a block diagram of a radio access node according to yet another exemplary embodiment. Detailed Description

The following sets forth specific details, such as particular embodiments for purposes of explanation and not limitation. But it will be appreciated by one skilled in the art that other embodiments may be employed apart from these specific details. In some instances, detailed descriptions of well known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and/or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and/or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer- readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein. Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.

In terms of computer implementation, a computer is generally understood to comprise one or more processors, one or more processing units, one or more processing modules or one or more controllers, and the terms computer, processor, processing unit, processing module and controller may be employed interchangeably. When provided by a computer, processor, processing unit, processing module or controller, the functions may be provided by a single dedicated computer, processor, processing unit, processing module or controller, by a single shared computer, processor, processing unit, processing module or controller, or by a plurality of individual computers, processors, processing units, processing modules or controllers, some of which may be shared or distributed. Moreover, these terms also refer to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above. Although in the description below the term user equipment (UE) is used, it should be understood by the skilled in the art that "UE" is a non-limiting term comprising any mobile or wireless device or node equipped with a radio interface allowing for at least one of: transmitting signals in uplink (UL) and receiving and/or measuring signals in downlink (DL). A UE herein may comprise a UE (in its general sense) capable of operating or at least performing measurements in one or more frequencies, carrier frequencies, component carriers or frequency bands. It may be a "UE" operating in single- or multi-radio access technology (RAT) or multi-standard mode. As well as "UE", the terms "mobile device" and "terminal device" may be used interchangeably in the following description, and it will be appreciated that such a device does not necessarily have to be 'mobile' in the sense that it is carried by a user. Instead, the terms "mobile device" and "terminal device" encompass any device that is capable of communicating with communication networks that operate according to one or more mobile communication standards, such as the Global System for Mobile communications, GSM, UMTS, Long-Term Evolution, LTE, etc. A cell is associated with a base station or radio base station (RBS), where a base station comprises in a general sense any network node transmitting radio signals in the downlink and/or receiving radio signals in the uplink. Some example base stations, or terms used for describing base stations, are eNodeB, eNB, Node B, macro/micro/pico/femto radio base station, home eNodeB (also known as femto base station), relay, repeater, sensor, transmitting-only radio nodes or receiving-only radio nodes. A base station may operate or at least perform measurements in one or more frequencies, carrier frequencies or frequency bands and may be capable of carrier aggregation. It may also be a single-radio access technology (RAT), multi-RAT, or multi-standard node, e.g., using the same or different base band modules for different RATs.

It should be noted that the term "radio access node" as used herein refers to a network node, e.g. a base station, Node B or eNodeB, that communicates with a terminal device over an air interface, and the term "control node" can refer to a node in the radio access network (RAN) part of the communication network (e.g. in the case of an RNC in UTRAN) or a node in a core network part of the communication network (e.g. a mobility management entity, MME, or serving gateway, SGW in an LTE communication network).

Unless otherwise indicated herein, the signalling described is either via direct links or logical links (e.g. via higher layer protocols and/or via one or more network nodes).

Figure 7 shows exemplary components of a radio access node 40 (e.g. a Node B in UMTS) that can be used in one or more of the embodiments described below. The radio access node 40 comprises a processing unit 42 that controls the operation of the radio access node 40. The processing unit 42 is connected to transceiver circuitry 44 with one or more associated antenna(s) 46 which are used to transmit signals to, and receive signals from, terminal devices in the network over the air (i.e. over an air interface). The radio access node 40 also comprises a memory unit 48 that is connected to the processing unit 42 and that stores information and data required for the operation of the radio access node 40. The radio access node 40 also includes components and/or circuitry 50 for allowing the radio access node 40 to exchange information with a control node (e.g. an RNC, typically via the lub interface). Figure 8 shows exemplary components of a control node 60 (e.g. an RNC in UMTS) that can be used in one or more of the embodiments described below. The control node 60 comprises a processing unit 62 that controls the operation of the control node 60. The processing unit 62 is connected to components and/or circuitry 64 for allowing the control node 60 to exchange information with the radio access node(s) 40 with which it is associated (which is typically via the lub interface), and components or circuitry 66 for allowing the control node 60 to exchange information with the core network. The control node 60 also comprises a memory module 46 that is connected to the processing module 40 and that stores information and data required for the operation of the control node 60.

It will be appreciated that, for simplicity, only components of the radio access node 40 and control node 60 required to illustrate the methods described below are shown in Figures 7 and 8.

Although the embodiments of the present disclosure will mainly be described in the context of UTRAN (i.e. Node Bs and RNCs), it will be appreciated by those skilled in the art that the problems and solutions described herein are equally applicable to other types of wireless access networks and user equipments (UEs) implementing other access technologies and standards, and thus UTRAN (and the other UTRAN-specific terminology used herein) should only be seen as examples of the technologies to which the techniques can be applied. For example, those skilled in the art will appreciate that the techniques described herein can be applied to an evolved UTRAN (E-UTRAN) that is part of an LTE network.

As noted above, according to the techniques described herein, a control node (e.g. RNC) can request a radio access node (e.g. RBS or Node B) provide delivery feedback to the control node for specific data units. This can be accomplished in different ways, but it is more convenient to do it directly in the user plane. The control node can mark the data units when they are sent to the radio access node. These specific data units may include downlink user plane data, L2 and/or L3 control plane data, including (but not limited to) RLC control data and acknowledgements for uplink user plane and control plane data. The radio access node can then keep track of these specific data units and when the delivery of the data units are acknowledged by the terminal device at L1 , the radio access node informs the control node about the delivery results, so that the control node can skip or avoid waiting for a higher layer retransmission and/or higher layer acknowledgment from the terminal device. This overall procedure in the context of an RNS and Node B is illustrated by the flow chart in Figure 9.

Thus, in step 901 the RNC 60 indicates in the lub frame protocol that a L1 delivery result is required for one or more specific data units. The Node B 40 then keeps track of the L1 delivery status of the one or more data units (step 903). Once the delivery status is known (e.g. delivered or undelivered), the Node B 40 sends the delivery result to the RNC 60 (step 905), and the RNC 60 acts according to the delivery result (step 907).

The following description indicates techniques by which an RNC (or more generally a control node) can mark specific user-plane and/or control-plane data sent to a Node B (or more generally a radio access node) over the lub interface for the purpose of requesting an explicit L1 delivery report. It will be appreciated that if the Node B is connected to the SRNC via a DRNC, the described solutions can also be applied to communications over the lur interface.

The following description also indicates techniques by which a radio access node can provide L1 feedback of the delivery results to a control node.

Briefly, it will be understood that all transmissions between the UE and RBS go through the Physical layer (i.e. L1). The RBS sends the data unit to the UE over a transport channel, which has its own protocols. This is done in the MAC layer which is part of Layer 2. The protocol(s) add headers and possibly other information such as CRC before it is handed down to the physical layer for transmission over the air. The physical layer also adds other processing (coding, modulation, etc.) before transmission.

One of the protocols used by the transport channel for HSDPA is the HARQ protocol. The HARQ protocol enables fast retransmission in the MAC layer (rather than the RLC layer), and it requires that the peer entity (i.e. the reception side of the transport channel) in the MAC layer of the UE transmits an ACK when it receives the data. The ACK is sent on a physical control channel (the HS-DPCCH) dedicated for the purpose. If no ACK is received, the MAC layer would retransmit the data again for a certain number of times before it gives up. Thus, the MAC layer knows if the delivery over the air is successful (an ACK is received) or failed (it has given up without receiving an ACK). The techniques described herein provide that the RBS provides information to the RNC on whether the data unit has been delivered over the air based on delivery information obtained from the HARQ protocol.

Marking of a data unit to request L1 delivery feedback

The marking of a data unit by the RNC for the purpose of requesting L1 delivery feedback (also referred to herein as delivery information) can be done in different ways. The MAC-d PDUs, which contain the data units, are transferred over the lub on an lub data frame from the RNC to the Node B. In general, there are two different approaches: marking at the data-frame level and marking at the MAC-d PDU level. The details depends to a certain extent on whether the HS-DSCH Data Frame Type 1 or the HS-DSCH Data Frame Type 2 is being used. The two approaches set out below can also be combined and used together.

Solution 1 : Marking at the lub data-frame level - This solution is most appropriate when the data unit that delivery information is being requested for is contained in a single lub data frame that contains no other data. It can be accomplished by introducing a flag in the lub data frame that, when set, indicates to the RBS that a L1 delivery report is to be provided. There are at least two ways of achieving this. The first is to make use of the spare bits 32 in the header 24 or in the payload 26 of the data frame 22. The second is to introduce such an indication in the spare extension.

For HS-DSCH Data Frame Type 1 , the marking of a data frame using spare bits can be achieved, e.g., by using one of the four spare bits 32 in the beginning of the payload 26, i.e., before the first MAC-d PDU 28. For HS-DSCH Data Frame Type 2, the marking of a data frame using spare bits can be achieved using one of the spare bits 34 at bit 0-2 on the 4th octet in the header 24. To mark a data frame using a spare extension, the next unused "New IE Flag" 36 from either of the Type 1 or Type 2 data frame can be selected and a new Indication can be defined.

Solution 2: Marking at the MAC-d PDU level - This solution is most appropriate when the data unit that delivery information is being requested for is contained in a data frame together with other data units. It can however, also be used when the data frame only contains the data unit that delivery information is being requested for. Like solution 1 , this marking can also be done by making use of the spare bits or by introducing a new IE by means of a new "New IE Flag" in the spare extension. For HS-DSCH Data Frame Type 1 the marking of a MAC-d PDU using spare bits can be achieved by using one of the four spare bits 32 before each of the MAC-d PDUs. The bit used can be the same bit as the one used for Solution 1 , or it can be a different bit, for example if the two solutions are to be used together or not. For HS-DSCH Data Frame Type 2 the marking of a MAC-d PDU using spare bits can be achieved by using the single spare bit after the "MAC-d PDU length in block n" IE in the header 24. In addition, an overall flag, like the one in Solution 1 , can also be used to indicate at the data-frame level that a L1 delivery report is required for some of the PDUs in the data frame. To mark a MAC-d PDU using a "New IE Flag" in the spare extension, as in Solution 1 above, the next unused "New IE Flag" from either of the Type 1 or Type 2 data frame can be selected. Here, a new IE is needed to indicate the individual MAC-d PDUs that delivery information is required. As an example, the MAC-d PDUs in the data frame can be numbered from 0 to N, and a bitmap may be defined with each bit indicating one MAC-d PDU in the data frame.

Combined solutions - It is possible (and may also be desirable) to use the two solutions together. For example, the data unit that delivery information is being requested for may be split into many MAC-d PDUs that are put into multiple lub data frames. For data frames that contain only PDUs from the required data unit, Solution 1 can be used. For the last (or first) data frame that may contain PDUs from other data units, Solution 2 can be used.

When multiple data frames are involved in a single request for L1 delivery feedback, the RNC needs to identify which frame is the last data frame. This can be done, for example, using a 1-bit more-to-come flag, although those skilled in the art will appreciate that other solutions are possible. A spare bit from the first octet in the payload 26 of the Type 1 data frame or the 4th octet in the header 24 of the Type 2 data frame can be used for this purpose. Alternatively, this information can also be carried in a new IE introduced by a new "New IE Flag" in the spare extension. Providing feedback of delivery results

After receiving a data frame and an indication that L1 delivery feedback is required, the Node B monitors the delivery of the MAC-d PDUs from the data frame over the air interface (i.e. the Node B monitors the HARQ protocol associated with the MAC-d PDUs). The result could be a successful or unsuccessful delivery over the air interface. The Node B then needs to return this delivery information to the RNC. In order to do this in an unambiguous way (i.e. in such a way that ensures the RNC knows exactly which PDUs have been successfully received (or not), an identification is needed for each request of a L1 delivery report.

After accommodating the exemplary PDU-marking using spare bits described above, a 3-bit number may be used as a Request ID (i.e. an identifier of the request). For the Type 1 data frame, there are four spare bits 32 in the beginning of the payload part 26. Three bits can be used for the Request ID, and one bit can be used for marking the first MAC-d PDU as requiring delivery information. For the Type 2 data frame, the three spare bits in the 4th octet in the header 24 can be used for this purpose. For marking at the data-frame level, the Request ID can also used as the marking flag (i.e. the flag to indicate that delivery information is required). Alternatively the Request ID can be introduced as a new IE using a new "New IE Flag" in the spare extension for both the Type 1 and Type 2 data frames.

It should be noted that when using spare bits for the Request ID, there are only 7 values available in a 3-bit number since the value "000" is already used for indicating "spare". The number of bits needed for the Request ID depends on the frequency of the request and the time it takes for the delivery information report to be delivered. If the request is not made very frequently, a two-value ID may be sufficient. Therefore, to accommodate multiple-data-frame requests, a 2-bit Request ID (giving 3 values) can be used to make room for the 'more-to-come' flag. Based on the teachings above, those skilled in the art will appreciate other ways in which the feedback requests can be identified using spare bits and/or the New IE Flag(s) in the data frames.

For reporting the L1 delivery result, there are at least two options:

1. The delivery report can indicate the overall result, with the delivery being indicated as successful only if all of the marked PDUs are delivered successfully. 2. Alternatively the delivery report can indicate the results per-PDU.

It should be noted that this is independent of the marking scheme. For example, per- PDU reporting can be used with marking at the data-frame level.

The L1 delivery report may be implemented in the lub interface user-plane protocol by either using a new control frame, or modifying an existing control or data frame sent from the Node B to the RNC. Figure 10 shows an example of a new lub control frame that could be used for this purpose. It defines a new Control Frame Type in the header 80 and carries the Request ID followed by an optional HS-DSCH Radio Network Temporary Identity (H-RNTI) in the payload 82 in case the report is sent on a common channel. The payload 82 also includes a HI (H-RNTI Indication) field that indicates whether a 16-bit H-RNTI follows the Request ID. One or more delivery results (Rx) then follow. The bit labelled "Ex" is an extension bit indicating if another octet of results follows.

Alternatively, an lub control plane (Node B Application Part, NBAP) message can be used for this purpose. Those skilled in the art will be aware of alternative ways in which the delivery information can be sent from the Node B to the RNC.

The techniques described above provide a general way of obtaining L1 delivery feedback. For many purposes, a simplified version may suffice. A minimal scheme can be created by restricting the data unit (whose delivery report is required) to be included in a single data frame by itself, i.e., without including data from any other data units. The marking can then be done on the data-frame level with no ambiguity.

Figures 1 1 (a) and 1 1 (b) show implementations for the Type 1 and Type 2 HS-DSCH data frames respectively for this minimal scheme that use the existing spare bits. Thus, in Figure 1 1 (a), three of the four spare bits at the start of the first MAC-d PDU 28 in the payload 26 are used for the Request ID 84. In Figure 1 1 (b), the three spare bits in the header 24 are used for the Request ID 86. Figure 12 shows the minimal implementation of a L1 delivery feedback request using a new IE indicated by a new "New IE Flag" in the spare extension. This implementation is common to both types of data frames, differing only in the position of the next available "New IE Flag" field. The example shown in Figure 12 is for the HS-DSCH Data Frame Type 1 , where the next available New IE Flag is used as a "Request ID Flag" which, when set, indicates that there is a "Request ID" IE in one of the following octets.

In the example, the Request ID in the HS-DSCH data frame is used also for marking the data-frame that the RNC is requesting the L1 delivery report for. The delivery report remains the same as that shown in Figure 10, but will contain only one reported result (R1).

Figure 13 is a flow chart illustrating an exemplary method of operating a control node 60 in a communication network according to the techniques presented herein. In a first step, step 1301 , the control node 60 sends a data unit for a terminal device 8 to a radio access node 40 in the communication network. The data unit can comprise user plane data and/or control plane data. The user plane data and/or control plane data can originate in a Layer 2 or Layer 3 protocol.

In some embodiments the control node is an RNC, the radio access node is a Node B, and the communication network is a UTRAN. In other embodiments the control node is a node in an Evolved Packet Core, EPC, and the radio access node is an eNodeB in a E-UTRAN.

In step 1303, the control node 60 sends a delivery information request for the data unit to the radio access node 40. The delivery information request requests the radio access node provide delivery information for the data unit that indicates whether the data unit was successfully received by the terminal device over an air interface.

It will be appreciated that although the sending of the data unit and the sending of the delivery information request are shown as separate steps in Figure 13, the steps can occur together, (and indeed it will be appreciated from the above embodiments that the delivery information request can be included or indicated in the same data frame as the data unit(s)). In some embodiments the steps of sending a data unit (step 1301) and/or sending a delivery information request (step 1303) are performed using a transport layer communication protocol (e.g. the Transport Network Layer protocol). In these embodiments the delivery information request can be indicated in an lub frame protocol, e.g. in an lub data frame. The data unit can be carried inside a payload of a data frame that comprises a payload and a header. In this case, the delivery information can be indicated in the payload or the header of the data frame. In some embodiments the delivery information request can be indicated in a MAC PDU. In some embodiments the delivery information request is included in a HS-DSCH Data Frame Type 1 or HS-DSCH Data Frame Type 2.

Next, in step 1305, the control node 60 receives delivery information for the data unit from the radio access node 40. The delivery information is based on a HARQ protocol that is used by the radio access node 40 to transmit the data unit to the terminal device over the air interface. In some embodiments step 1305 is performed using a transport layer communication protocol (e.g. the Transport Network Layer protocol). In some embodiments the delivery information is received in an lub frame protocol, e.g. an lub control frame. In some embodiments, step 1301 can comprise sending a plurality of data units, and step 1305 can comprise receiving delivery information for each of the plurality of data units.

In alternative embodiments, step 1301 can comprise sending a plurality of data units, and step 1305 can comprise receiving a piece of single delivery information covering all of the data units. In this embodiment, an indication that the transmission is successful may only be provided if all of the plurality of data units have been successfully transmitted. In some embodiments, step 1301 can comprise sending a plurality of data units, and the delivery information request can request the radio access node provide delivery information in respect of a specific one or more (i.e. not all) of the plurality of data units.

In some embodiments, the delivery information request comprises an identifier for the data unit that is the subject of the request, and the received delivery information comprises an identifier for the data unit that is the subject of the delivery information. In some embodiments the method further comprises the step of using the received delivery information for the data unit to determine an action to perform in respect of a higher layer communication protocol in the control node. In some embodiments, in the event that the received delivery information indicates that the data unit was not successfully received by the terminal device, the step of using the received delivery information can comprise initiating a retransmission of the data unit according to the higher layer communication protocol. The higher layer communication protocol can be a Layer 2 communication protocol or a Layer 3 communication protocol.

Figure 14 is a flow chart illustrating an exemplary method of operating a radio access node 40. In step 1401 , the radio access node 40 receives a data unit for a terminal device from a control node 60 in the communication network. The data unit can comprise user plane data and/or control plane data. The user plane data and/or control plane data can originate in a Layer 2 or Layer 3 protocol.

In some embodiments the control node is an RNC, the radio access node is a Node B, and the communication network is a UTRAN. In other embodiments the control node is a node in an Evolved Packet Core, EPC, and the radio access node is an eNodeB in a E-UTRAN.

In step 1403, the radio access node 40 receives a delivery information request for the data unit from the control node. The delivery information request requests the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface.

It will be appreciated that although the receiving of the data unit and the receiving of the delivery information request are shown as separate steps in Figure 14, the steps can occur together, (and indeed it will be appreciated from the above embodiments that the delivery information request can be included or indicated in the same data frame as the data unit(s)).

In some embodiments, the step of receiving a data unit (step 1401) and/or receiving a delivery information request (step 1403) are performed using a transport layer communication protocol (e.g. the Transport Network Layer protocol). In these embodiments the delivery information request can be indicated in an lub frame protocol, e.g. in an lub data frame.

The data unit can be carried inside a payload of a data frame that comprises a payload and a header. In this case the delivery information request is indicated in the payload or the header of the data frame. In some embodiments, the delivery information request can be indicated in a MAC PDU. In some embodiments, the delivery information request is included in a HS-DSCH Data Frame Type 1 or a HS-DSCH Data Frame Type 2.

Next, in step 1405, the radio access node 40 transmits the data unit to the terminal device over the air interface using a HARQ protocol.

The radio access node 40 then receives an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface (step 1407). This indication can be an acknowledgement (ACK) message or a negative acknowledgement (NACK) message.

The radio access node 40 then sends delivery information for the data unit to the control node 60. The delivery information is based on the indication according to the HARQ protocol and indicates whether the data unit was successfully received by the terminal device over the air interface. In some embodiments step 1409 is performed using a transport layer communication protocol (e.g. the Transport Network Layer protocol). In some embodiments the delivery information is sent in an lub frame protocol, e.g. in an lub control frame.

In some embodiments, step 1401 can comprise receiving a plurality of data units, and step 1409 can comprise sending delivery information for each of the plurality of data units.

In alternative embodiments, step 1401 can comprise receiving a plurality of data units, and step 1409 can comprise sending a piece of single delivery information covering all of the data units. In this embodiment, an indication that the transmission is successful may only be provided if all of the plurality of data units have been successfully transmitted. In some embodiments, step 1401 can comprise receiving a plurality of data units, and the delivery information request can request the radio access node provide delivery information in respect of a specific one or more (i.e. not all) of the plurality of data units. In some embodiments, the delivery information request comprises an identifier for the data unit that is the subject of the request, and the sent delivery information comprises an identifier for the data unit that is the subject of the delivery information.

Figure 15 is a block diagram of a control node 60 according to another exemplary embodiment. A control node 60 is for use in a communication network and comprises a processor 1501 and a memory 1502. The memory 1502 contains instructions executable by the processor 1501 , whereby said control node 60 is operative to send a data unit for a terminal device to a radio access node 40 in the communication network, send a delivery information request for the data unit to the radio access node 40, the delivery information request requesting the radio access node 40 provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface, and receive delivery information for the data unit from the radio access node 40, the delivery information being based on a HARQ protocol used by the radio access node 40 to transmit the data unit to the terminal device over the air interface.

Figure 16 is a block diagram of a radio access node 40 according to another exemplary embodiment. The radio access node 40 is for use in a communication network and comprises a processor 1601 and a memory 1602. The memory 1602 contains instructions executable by the processor 1601 , whereby the radio access node 40 is operative to receive a data unit for a terminal device from a control node 60 in the communication network; receive a delivery information request for the data unit from the control node 60, the delivery information request requesting the radio access node 40 provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; transmit the data unit to the terminal device over the air interface using a HARQ protocol; receive an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface; and send delivery information for the data unit to the control node 60, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface. Figure 17 is a block diagram of a control node 60 according to yet another exemplary embodiment. The control node 60 is for use in a communication network and comprises a first sending module 1701 , a second sending module 1702 and a first receiving module 1703. The first sending module 1701 is configured to send a data unit for a terminal device to a radio access node 40 in the communication network. The second sending module 1702 is configured to send a delivery information request for the data unit to the radio access node 40, the delivery information request requesting the radio access node 40 provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface. The first receiving module 1703 is configured to receive delivery information for the data unit from the radio access node 40, the delivery information being based on a HARQ protocol used by the radio access node 40 to transmit the data unit to the terminal device over the air interface.

Figure 18 is a block diagram of a radio access node 40 according to yet another exemplary embodiment. The radio access node 40 is for use in a communication network and comprises a first receiving module 1801 , a second receiving module 1802, a first transmitting module 1803, a third receiving module 1804 and a first sending module 1805. The first receiving module 1801 is configured to receive a data unit for a terminal device from a control node 60 in the communication network. The second receiving module 1802 is configured to receive a delivery information request for the data unit from the control node 60, the delivery information request requesting the radio access node 40 provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface. The first transmitting module 1803 is configured to transmit the data unit to the terminal device over the air interface using a HARQ protocol. The third receiving module 1804 is configured to receive an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface. The first sending module 1805 is configured to send delivery information for the data unit to the control node, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface. Modifications and other variants of the described embodiment(s) will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the embodiment(s) is/are not to be limited to the specific examples disclosed and that modifications and other variants are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Various exemplary embodiments of the techniques described herein are set out in the following statements: 1. A method of operating a control node in a communication network, the method comprising:

sending a data unit for a terminal device to a radio access node in the communication network;

sending a delivery information request for the data unit to the radio access node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; and

receiving delivery information for the data unit from the radio access node, the delivery information being based on a hybrid automatic repeat request, HARQ, protocol used by the radio access node to transmit the data unit to the terminal device over the air interface.

2. A method as defined in statement 1 , wherein the data unit comprises either or both of user plane data and control plane data.

3. A method as defined in statement 1 or 2, wherein the step of sending a data unit comprises sending a plurality of data units, and wherein the step of receiving delivery information for the data unit comprises receiving respective delivery information for each of the plurality of data units.

4. A method as defined in statement 1 or 2, wherein the step of sending a data unit comprises sending a plurality of data units, and wherein the step of receiving delivery information for the data unit comprises receiving a single delivery information in respect of the plurality of data units. 5. A method as defined in any of statements 1-4, wherein the step of sending a data unit comprises sending a plurality of data units, and wherein the delivery information request requests the radio access node provide delivery information in respect of a specific one or more of the plurality of data units.

6. A method as defined in any of statements 1-5, wherein the delivery information request comprises an identifier for the data unit that is the subject of the request, and wherein the received delivery information comprises an identifier for the data unit that is the subject of the delivery information.

7. A method as defined in any of statements 1-6, wherein the steps of sending a data unit and/or sending a delivery information request are performed using a transport layer communication protocol with the data unit carried inside a payload of a data frame that comprises a payload and a header.

8. A method as defined in statement 7, wherein the delivery information request is indicated in the payload and/or the header of the data frame.

9. A method as defined in any of statements 1-8, wherein the delivery information request is indicated in an lub data frame.

10. A method as defined in any of statements 1-8, wherein the delivery information request is indicated in a Medium Access Control, MAC, packet data unit, PDU. 1 1. A method as defined in any of statements 1-10, wherein the delivery information request is included in a High-Speed Downlink Shared Channel, HS-DSCH, Data Frame Type 1 or a HS-DSCH Data Frame Type 2.

12. A method as defined in any of statements 1-11 , wherein the step of receiving delivery information is performed using a transport layer communication protocol.

13. A method as defined in any of statements 1-12, wherein the delivery information is received in an lub control frame.

14. A method as defined in any of statements 1-13, wherein the method further comprises the step of: using the received delivery information for the data unit to determine an action to perform in respect of a higher layer communication protocol in the control node.

15. A method as defined in statement 14, wherein in the event that the received delivery information indicates that the data unit was not successfully received by the terminal device, the step of using the received delivery information comprises initiating a retransmission of the data unit according to the higher layer communication protocol.

16. A method as defined in statement 14 or 15, wherein the higher layer communication protocol is a Layer 2 communication protocol or a Layer 3 communication protocol.

17. A method as defined in any of statements 1-16, wherein the control node is a Radio Network Controller, RNC, the radio access node is a Node B, and the communication network is a Universal Mobile Telecommunications System, UMTS, Terrestrial Radio Access Network, UTRAN.

18. A method as defined in any of statements 1-16, wherein the control node is a node in an Evolved Packet Core, EPC of the communication network and the radio access node is an eNodeB is in an Evolved-Universal Mobile Telecommunications System, UMTS, Terrestrial Radio Access Network, E-UTRAN.

19. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of statements 1-18.

20. A control node for use in a communication network, the control node being adapted to:

send a data unit for a terminal device to a radio access node in the communication network;

send a delivery information request for the data unit to the radio access node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; and receive delivery information for the data unit from the radio access node, the delivery information being based on a hybrid automatic repeat request, HARQ, protocol used by the radio access node to transmit the data unit to the terminal device over the air interface.

Various additional embodiments of the control node are also contemplated in which the control node is further adapted to perform the method steps set out in any of statements 2-18. 21. A method of operating a radio access node in a communication network, the method comprising:

receiving a data unit for a terminal device from a control node in the communication network;

receiving a delivery information request for the data unit from the control node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface;

transmitting the data unit to the terminal device over the air interface using a hybrid automatic repeat request, HARQ, protocol;

receiving an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface; and

sending delivery information for the data unit to the control node, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface.

22. A method as defined in statement 21 , wherein the data unit comprises either or both of user plane data and control plane data.

23. A method as defined in statement 21 or 22, wherein the step of receiving a data unit comprises receiving a plurality of data units, and wherein the step of sending delivery information for the data unit comprises sending respective delivery information for each of the plurality of data units.

24. A method as defined in statement 21 or 22, wherein the step of receiving a data unit comprises receiving a plurality of data units, and wherein the step of sending delivery information for the data unit comprises sending a single delivery information in respect of the plurality of data units.

25. A method as defined in any of statements 21-24, wherein the step of receiving a data unit comprises receiving a plurality of data units, and wherein the delivery information request requests the radio access node provide delivery information in respect of a specific one or more of the plurality of data units.

26. A method as defined in any of statements 20-25, wherein the delivery information request comprises an identifier for the data unit that is the subject of the request, and wherein the sent delivery information comprises an identifier for the data unit that is the subject of the delivery information.

27. A method as defined in any of statements 20-26, wherein the steps of receiving a data unit and/or receiving a delivery information request are performed using a transport layer communication protocol with the data unit carried inside a payload of a data frame that comprises a payload and a header.

28. A method as defined in statement 27, wherein the delivery information request is indicated in the payload and/or the header of the data frame.

29. A method as defined in any of statements 20-28, wherein the delivery information request is indicated in an lub data frame. 30. A method as defined in any of statements 20-29, wherein the delivery information request is indicated in a Medium Access Control, MAC, packet data unit, PDU.

31. A method as defined in any of statements 20-30, wherein the delivery information request is included in a High-Speed Downlink Shared Channel, HS-DSCH, Data Frame Type 1 or a HS-DSCH Data Frame Type 2.

32. A method as defined in any of statements 20-31 , wherein the steps of receiving a data unit and/or receiving a delivery information request are performed using a transport layer communication protocol. 33. A method as defined in any of statements 20-32, wherein the step of sending delivery information is performed using a transport layer communication protocol.

34. A method as defined in any of statements 20-33, wherein the delivery information is sent in an lub control frame.

35. A method as defined in any of statements 20-34, wherein the control node is a Radio Network Controller, RNC, the radio access node is a Node B, and the communication network is a Universal Mobile Telecommunications System, UMTS, Terrestrial Radio Access Network, UTRAN.

36. A method as defined in any of statements 20-35, wherein the control node is a node in an Evolved Packet Core, EPC of the communication network and the radio access node is an eNodeB is in an Evolved-Universal Mobile Telecommunications System, UMTS, Terrestrial Radio Access Network, E-UTRAN.

37. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of statements 21-36.

38. A radio access node for use in a communication network, the radio access node being adapted to:

receive a data unit for a terminal device from a control node in the communication network;

receive a delivery information request for the data unit from the control node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface;

transmit the data unit to the terminal device over the air interface using a hybrid automatic repeat request, HARQ, protocol;

receive an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface; and

send delivery information for the data unit to the control node, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface. Various additional embodiments of the radio access node are also contemplated in which the radio access node is further adapted to perform the method steps set out in any of statements 22-36.

Some alternative exemplary embodiments are set out below:

A. A method for a first node in a mobile communication network with a multi-layer communication protocol to obtain lower-layer transmission information of specific data units from a second network node that is responsible for the delivery of the data units to a communication device. The method can comprise a requesting mechanism for the first network node to indicate to the second network node the specific data unit for which information on delivery results are wanted, and a reporting mechanism for the second network node to provide the wanted delivery information to the first network node.

B. A method as defined in A, wherein the communication network is a UTRAN, the first network node is an RNC, and the second network node is a Node B. C. A method as defined in A or B, wherein the requesting mechanism is realised in terms of the control-plane protocol and/or the user-plane protocol of the transport layer of the inter-node communication protocols. In the case of a UTRAN, they are the NBAP and the lub user-plane protocols, respectively. D. A method as defined in any of A, B or C, wherein the requesting mechanism is realised using a user-plane protocol, specifically, the HS-DSCH Data Frame Type 1 and HS-DSCH Data Frame Type 2, which are two data-frame types of the lub user- plane protocols. E. A method as defined in D, wherein some or all of the following request information is provided in each data frame that contains data whose delivery information is wanted: (i) an identifier for the request; (ii) the part of the payload in the data frame where delivery information is wanted; (iii) whether a single delivery result should be provided for the entire request or separately for each indicated part in the request; and (iv) whether the request includes data from a following data frame. F. A method as defined in D, wherein the data unit whose delivery information is wanted is always contained in a single data frame that contains no other data units and reporting is to be provided always on a per-request basis. G. A method as defined in E or F, wherein the information on the request is provided using spare bits in the data frame.

H. A method as defined in E or F, wherein the information on the request is provided by adding new control information at the end of the payload in the data frame.

I. A method as defined in any of A-H, wherein the reporting mechanism is realised in terms of the control-plane protocol and/or the user-plane protocol of the transport layer of the inter-node communication protocols. In the case of a UTRAN, they are the NBAP and the lub user-plane protocols, respectively.

J. A method as defined in any of A-l, wherein the reporting mechanism is realised using a new or modified control frame of the lub user-plane protocols, with the control frame containing (i) the identifier for the original request; and/or (ii) whether the delivery of each separately-indicated part is successful or not.