WO2018060674A1 - Arq and harq in 5g wireless communication - Google Patents

Abstract

A method to dynamically control and define the location and the behaviour of an ARQ or HARQ retransmission buffer when the Base Station is physically split into two different entities which are physically separated. In a RAN centralized architecture having a functional split between a Centralized Unit (CU 300) for the upper layers and a Distributed Unit (DU 200} for the lower layers, connected via a fronthaul link, the location of the retransmission buffer (i.e. in the CU or the DU) is critical for the performance and efficiency, including the fronthaul latency and minimum traffic data rate. The optimal location will be impacted by different criteria (e.g. traffic, radio link quality, MAC layer inputs). A method is provided to select the optimal location of the retransmission buffer along with the modification of a RLC PDU header to indicate the selected location.

Description

ARQ and HARQ in 5G Wireless Communication

Field of the Invention

5 This invention generally relates to wireless communications systems and methods and especially, but not necessarily exclusively, to systems and methods transmitting data using Automatic Repeat reQuest (ARQ) and/or Hybrid Automatic Repeat reQuest (HARQ). applicable to future base station architectures. The present Invention is of particular relevance to downlink (DL) ARQ and HARQ in which data is transmitted on0 the DL and is acknowledged by an ACK or NACK transmitted on the uplink (UL).

Background of the Invention

Wireless communication standards such as LTE (3GPP Long-Term Evolution) are5 based on the OSI model, which divides the complex tasks of wireless communications into a set of protocols arranged in a series of layers. Layers in the OSI model are ordered from lowest level to highest Together, these layers form a "protocol stack".

The LTE protocol stack contains, from lowest to highest, a Physical or PHY layer,

Medium Access Control, Radio Link Control, and Packet Data Convergence Protocol0 layers (MAC, RLC, and PDCP) and Radio Resource Control, RRC. which layers can also be numbered as Layer 1 (PHY), Layer 2 (MAC, RLC, and PDCP) and Layer 3

(RRC).

It is expected that future wireless communication standards, including those currently5 under discussion under the umbrella term "5G". will likewise follow the OSI model. For assistance in understanding the invention to be described, some relevant aspects of LTE will be briefly outlined, it being understood that the present invention is in no way limited to LTE.

In LTE, data from Layer 2 (or MAC) given to the PHY (in the form of one or more Layer0 2 packets) is referred to as a transport block (TB). In the simplest case, namely a single antenna transmission mode, one transport block is generated for each TTI (Transmission Time Interval). The transport block size is decided by the number of Physical Resource Blocks (NPRB) and the MCS (Modulation and Coding Scheme). A CRC (cyclic redundancy check) in the form of parity bits is appended to each transport5 block to allow error detection. The receiver can then request retransmission using Automatic Repeat reQuest (ARQ) or Hybrid ARQ (HARQ), to the transmitter in case errors are detected (in the case of HARQ, if a TB cannot be decoded). A difference between the two schemes is that HARQ (which is a combination of ARQ and some Forward Error Coding (FEC» takes place in the lowest sublayer of Iayer2 and the ARQ is in the RLC (one sub-layer higher). (1) ARQ

Figure 1 shows the user plane protocol stack for LTE. As can be seen, there are peer entities in the UE 10 and eNB 20 for each of the PHY, MAC, RLC, and PDCP protocol layers. In each layer, data packets are defined as SDUs (Service Data Units) and PDUs (Protocol Data Units) with respect to a specific layer. On the transmitter side for example, a layer N receives data from layer N+1 and this data is called the SDU of layer N. Layer N converts the data into a PDU. In its simplest form, this conversion by layer N of the layer N+1 SDU involves encapsulation in which the SDU is preserved as it is and an additional header is added by the layer N protocol. It can also involve concatenation (where more than one SDU is combined in a single PDU), segmentation (where a SDU can be split so that different parts of it end up in different PDU), or padding (if a SDU is so small that filler bits need to be added to complete the PDU). The resulting PDU may also be encrypted. The RLC layer and RLC entities shown in Figure 1 are of particular relevance to ARQ. In accordance with the principle just mentioned, the RLC layer performs segmentation of PDCP SDUs to form RLC PDUs. In addition, the RLC adds a header to each packet based on an RLC mode of operation (see below), and RLC submits these RLC PDUs (MAC SDUs) to the MAC layer. If an RLC SDU is too large for the transport block size available at MAC level (e.g. the available radio resources are low), the RLC SDU may be segmented into several RLC PDUs. If the transport block size available at MAC level is larger than the RLC SDU (e.g. the available radio data rate is low several RLC SDUs may be packed into a single PDU. In more detail, the RLC layer in LTE is defined by 36PP Specification TS 36.322, "Radio Link Control (RLC) protocol specrfi cation" hereby incorporated by reference, and the following high-level description can be found in chapter 4.2.1.

Functions of the RLC sub layer are performed by RLC entities. For a RLC entity configured at the eNB, there is a peer RLC entity configured at the UE and vice versa. For an RLC entity configured at the transmitting UE for STCH or SBCCH there is a peer RLC entity configured at each receiving UE for STCH or SBCCH. (Note: this is a reference to sidelink (SL) communication logical channels recently defined for device- tod θ vice communication, the SL Traffic Channel (STCH) and the SL Broadcast Control Channel (SBCCH)).

An RLC entity receives/delivers RLC SDUs from/to upper layer and sends/receives RLC PDUs to/from its peer RLC entity via lower layers. An RLC PDU can either be a RLC data PDU or a RLC control PDU. If an RLC entity receives RLC SDUs from upper layer, it receives them through a single Service Access Point (SAP) between RLC and upper layer, and after forming RLC data PDUs from the received RLC SDUs, the RLC entity delivers the RLC data PDUs to lower layer through a single logical channel. If an RLC entity receives RLC data PDUs from lower layer, it receives them through a single logical channel, and after forming RLC SDUs from the received RLC data PDUs, the RLC entity delivers the RLC SDUs to upper layer through a single SAP between RLC and upper layer. If an RLC entity delivers/receives RLC control PDUs to/from lower layer, it delivers/receives them through the same logical channel it delivers/receives the RLC data PDUs through.

An RLC entity can be configured to perform data transfer in one of the following three modes: Transparent Mode (TM), Unacknowledged Mode (UM) or Acknowledged Mode (AM). Consequently, an RLC entity is categorized as a TM RLC entity, an UM RLC entity or an AM RLC entity depending on the mode of data transfer that the RLC entity is configured to provide.

An AM RLC entity consists of a transmitting side and a receiving side. The transmitting side of an AM RLC entity receives RLC SDUs from upper layer and sends RLC PDUs - also known in this case as RLC AMD PDUs where AMD stands for Acknowledged Mode Data - to its peer AM RLC entity via lower layers. The receiving side of an AM RLC entity delivers RLC SDUs to upper layer and receives RLC PDUs from its peer AM RLC entity via lower layers. AM involves the use of the above mentioned

Automatic Repeat reQuest (ARQ) and therefore the following explanation will describe the behaviour of the AM RLC entity only.

Figure 2 shows the different functions of an AM RLC entity, as well as their interactions (taken from section of 4.2.1.3.1-1 of 3GPP specification TS 36.322). The constituent functions in Figure 2 are briefly outlined as follows.

Transmission buffer POUs from the higher layers are stored in the transmission buffer (as RLC SDUs). These RLC SDUs are sent to the segmentation and concatenation function until the buffer becomes empty or the RLC transmitting window (see section 5.1.3.1.1 of 3GPP specification TS 36.322) needs data. The transmission buffer should not be confused with the retransmission buffer (see below).

Segmentation & Concatenation

This segments and/or concatenates the RLC SDUs so that the AMD PDUs fit within the total size of RLC PDU(s) indicated by a lower layer at the particular transmission opportunity notified by the lower layer.

Add RLC header This adds an RLC header to the AMD PDU according to section 6 in 3GPP

specification TS 36.322.

Retransmission buffer This is part of the ARQ function; the retransmission buffer (distinct from the above mentioned transmission buffer) stores the AMD PDUs sent to lower layer (i.e. MAC) until an positive acknowledgment is received, and deletes the AMD PDU in that case. Alternatively the AMD PDUs (which may need re-segmentation) are retransmitted to the lower layer if a Negative Acknowledgment is received.

RLC control

The RLC control unit controls the RLC entity and handles control signalling between the peer entitles (e.g. establishment and release of a RLC link). It is spKt between the transmitting and receiving side .

SDU reassembly

This reassembles the SDUs contained in the AMD PDU and delivers them in sequence to the upper layer (e.g. PDCP).

Remove RLC header As the name suggests this removes the RLC header from the AMD PDU.

Reception buffer & HARQ reordering This is part of a HARQ function (see below). When receiving a RLC data PDU from lower layer, the receiving side of an AM RLC entity places K in the reception buffer. The advantage of HARQ reordering in RLC is that no additional SN and reception buffer are needed for HARQ reordering. Routing

This routes the incoming packets from lower layer (i.e. MAC) to the right function (i.e. RLC control in case of RLC control PDU, Reception buffer in case of user data). The folowing figures describe the behaviour of the AM RLC entity applicable to the downlink, which is the case of particular relevance to the present invention.

In Figure 3 the following steps are used by the transmitting side of the AM RLC entity: S31 : The AM RLC entity receives an SDU from the upper layer (e.g. PDCP or RLC in LTE).

S32: The AM RLC entity stores the SDU into the Transmission Buffer. S33: The AM RLC entity segments the SDU into several RLC PDUs, or concatenates it with other SDUs from the Reception Buffer in order to build a RLC PDU which fulfils the total size indicated by lower layer at the particular transmission opportunity.

S34: The AM RLC entity adds the header to the RLC PDU according to section 6 of 3GPP specification TS 36.322.

S35: The AM RLC entity stores (a copy of) the resulting RLC PDU into the

Retransmission Buffer (incidentally, steps S34 and S35 can be switched, in which case the RLC PDU will be stored in the Retransmission Buffer without the RLC header).

S36: The AM RLC entity transmits the resulting RLC PDU to the lower layer (e.g. MAC in LTE) for transmission over the air in the transmission opportunity (as determined by a scheduler). Figure 4 shows the corresponding steps to Figure 3 as performed by the receiving side of the AM RLC entity.

S41 : The AM RLC entity receives a RLC PDU from lower layer (e.g. MAC in LTE).

S42: The AM RLC removes the RLC header.

S43: If the CRC check succeeds, the PDU was received correctly and the AM RLC marks the received RLC PDU for acknowledgment (i.e. using its Sequence Number (SN) contained in the RLC header). Acknowledgments (ACKs) are sent periodically to the peer AM RLC entity.

S44: The AM RLC entity assembles SDUs if received in more than 1 RLC PDU. S45: The AM RLC entity transmits the resulting SDUs to the upper layer (e.g. PDCP or RLC In LTE).

S46: The AM RLC entity detects that RLC PDU is missing or corrupted (i.e. CRC check fails) and marks the corresponding RLC PDU for negative acknowledgment, using its Sequence Number (SN) contained in the RLC header. Negative Acknowledgments (NACKs) are sent periodically to the peer AM RLC entity together with any ACK in the same RLC message.

ARQ employs a sliding window (transmitting window and receiving window) of one or more PDUs to facilitate keeping track of which packets have been received. .

However, the behaviour of the transmitting window and the update of the

Acknowledged Mode Transmit State Variables, likewise the receiving window and the update of the Acknowledged Mode Receive State Variables, are not relevant to this invention and therefore not described. The full description of this behaviour and these variables can be found in 3GPP specification TS 36.322.

Figure 5 is a flowchart of the steps taken at the transmitting side of the AM RLC entity when receiving a positive acknowledgment for a given RLC PDU.

S51 : The AM RLC entity receives a Positive Acknowledgment via an RLC STATUS PDU. S52: The AM RLC entity removes the corresponding RLC PDU, identified by its SN, from the Retransmission Buffer.

S53: The Acknowledged Mode Transmit State Variables are updated according to 3GPP specification TS 36.322. This includes updating the received sequence rvumbers to advance a sliding window.

On the other hand, Figure 6 shows the steps performed on the transmitting side of the AM RLC entity when receiving a negative acknowledgment for a given RLC PDU.

S61: The AM RLC entity receives a Negative Acknowledgment via an RLC STATUS PDU.

S62: The AM RLC entity retrieves the corresponding RLC PDU, identified by its SN, from the Retransmission Buffer.

S63: Optionally, the AM RLC entity re-segments the RLC PDU if its size does not correspond to the total size of RLC PDU<s) indicated by lower layer at the particular transmission opportunity notified by a lower layer. This may occur for example if lower layers no longer support the transmission rate previously used, perhaps due to a deterioration of the radio channel.

S64: The AM RLC entity re-transmits the missing or corrupted RLC PDU to the lower layer (e.g. MAC for LTE) until ACK is received or a threshold number of retransmission attempts is reached, whereupon the AM RLC entity removes the corresponding RLC PDU from the Retransmission Buffer.

In order to know the status of each RLC PDU sent by the transmitting side of the AM RLC entity, the receiving side of the AM RLC entity sends periodically a STATUS PDU described in section 6.2.1.6 of 3GPP specification TS 36.322, and examples of which are illustrated in Figures 7 and 8. Figure 7 shows the case of a STATUS PDU with a 10 bit SN (Sequence Number), and Figure 8 the case of a 16 bit SN and with 16 bit SOstart and SOend fields (see below). In each case, the STATUS PDU consists of a STATUS PDU paytoad and a RLC control PDU header, where this RLC control PDU header, in turn, consists of a D/C field, which indicates whether a RLC PDU is a RLC data PDU or RLC control PDU, and a CPT field which indicates the type of an RLC control PDU. The STATUS PDU payload starts from the first bit following the RLC control PDU header, and it consists of one ACK_SN and one E1 , zero or more sets of a NACK_SN, an E1 and an E2, and possibly a set of a SOstart and a SOend for each NACK_SN. SOstart and SOend are used to indicate the portion of the NACKed AMD PDU with the sequence number given by NACK_SN that has been detected as lost at the receiving side of the AM RLC entity. When necessary, one to seven padding bits are included in the end of the STATUS PDU to achieve octet alignment

(2) HARQ

HARQ operates at the level of the Transport Block (TB), rather than at the RLC PDU level as in ARQ, and facilitates retransmission in case a Transport Block cannot be decoded. If a TB was received with errors a NACK (Negative ACKnowiedgment) bit is sent to the transmitter to indicate this error. For a TB successfully decoded by the receiver an ACK (ACKnowledgement) bit is sent to the transmitter. The transmitter will either retransmit a TB or send a new TB depending on the received control signal. Usually when the transmitter receives an ACK, a new TB is generated and transmitted, and when a NACK is received a re-transmission of the previously transmitted TB is transmitted to the receiver, until the configured maximum number of retransmission is reached. To allow retransmission, the TB is cached in a HARQ sending buffer, only being discarded when an ACK for that TB is received.

Typically HARQ is performed in the DL and UL by multiple HARQ processes (stop and wait HARQ time slots acting as transmission opportunities for transport blocks) in a HARQ entity (an entity with HARQ enabled). That is, the HARQ process for one TB can start before the HARQ process for the previous TB is complete. The use of multiple HARQ processes allows the transmission of data to be continuous and not stop whilst the transmitter is awaiting the transmission of ACK or NACK from the receiver. In the case of Frequency Division Duplex, FDD, transmission, TBs can be sent in 8 consecutive time slots without having to wait for the ACK/NACK signal to be sent back from the receiver to the transmitter. The receiver can transmit NACK a number of times for the same TB up to a maximum number of transmissions.

In general, HARQ schemes can be categorized as either synchronous or asynchronous in their timing relationship between first and re-transmissions. In a synchronous scheme, the re-transmissions of data packets which have been NACKed occur at a pre-defined timing relative to the initial transmission. The advantage of using this predefined timing offset is that there is no need to signal to the receiver such control information as an HARQ process number. Such an HARQ process number is obtained from the timing of the received data packets. In an asynchronous scheme, a retransmission can occur at any time relative to the first transmission. In this case the HARQ process number win be required so as to identify which HARQ process the re- transmission is related to. In LTE synchronous HARQ is used for the UL and asynchronous HARQ is used for the DL.

As already mentioned, in order that data can be transported across the LTE radio interface, various "channels" are defined at different protocol layers in LTE. Each channel at a given layer receives data from the higher layers) within the LTE protocol structure and packages the data in a manner understood by the next lower layer. Different channels are used to segregate different types of data, allowing the data to be transported across the radio access network in an orderly fashion.

There are three categories into which the various channels may be grouped.

Physical channels: These are transmission channels that carry user data and control messages.

Transport channels: The physical layer transport channels offer information transfer to Medium Access Control (MAC) and higher layers.

Logical channels: Provide services for the Medium Access Control (MAC) layer within the LTE protocol structure.

For present purposes, the Physical and Transport channels are of most importance, and the following channels are of particular relevance.

Physical Channels

Physical Downlink Control Channel (PDCCH): PDCCH is used to carry control signalling from the network to a UE. and In particular scheduling information of different types. The PDCCH contains a message known as the Downlink Control Information, DCI which carries the control information for a particular UE or group of UEs.

Physical Downlink Shared Channel (PDSCH): PDSCH is used to carry user data on the downlink, including the above mentioned TBs in DL HARQ, as well as some control signalling.

Physical Hybrid ARQ Indicator Channel (PHICH): PHICH carries the above mentioned ACK and NACK bits used in HARQ. The PHICH is transmitted within the control region of the subframe and is typically only transmitted within the first symbol. If the radio link is poor, then the PHICH is extended to a number symbols for robustness. Physical Uplink Control Channel (PUCCH): PUCCH provides the means for a UE to send control signalling, such as SRs, Scheduling Requests, to the network.

Physical Uplink Shared Channel (PUSCH): This physical channel found on the LTE uplink is the Uplink counterpart of PDSCH.

Transport channels

Physical layer transport channels offer information transfer to medium access control (MAC) and higher layers. The following will be mentioned below:

Downlink Shared Channel (DL-SCH): DL-SCH is the main channel for downlink data transfer. It is used by many logical channels.

Uplink Shared Channel (UL-SCH): UL-SCH is the main channel for uplink data transfer. It is used by many logical channels.

According to TS 36.300 [1], the HARQ within the MAC sublayer has the following characteristics:

1) Regardless of the content of the HARQ feedback (A CK or SACK), when a PDCCH for the UE is correctly received, the UE follows what the PDCCH asks the UE to do i.e. perform a transmission or a retransmission (referred to as adaptive retransmission);

2) When no PDCCH addressed to the C RNTI of the UE is detected, the HARQ feedback dictates how the UE performs retransmissions:

• NACK: the UE performs a non-adaptive retransmission i.e. a retransmission on the same uplink resource as previously used by the same process;

- ACK: the UE does not perform any UL (retransmission and keeps the data in the HARQ buffer. A PDCCH is then required to perform a retransmission i.e. a non- adaptive retransmission cannot follow.

In the sidelink:

- No HARQ feedback;

- Retransmissions are always performed in a pre-defined/ configured number.

Measurement gaps are of higher priority than HARQ retransmissions: whenever an HARQ retransmission collides with a measurement gap, the HARQ retransmission does not take place.

Table 1: UL HARQ Operation (Table 9.1-1 in TS 36.300)

UE behaviour

Thus, HARQ is controlled in the MAC layer but the HARQ retransmission occurs at the PHY layer. At the PHY level, PHICH is used to carry HARQ in the downlink direction for the received uplink data, and PUSCH/PUCCH are used to carry HARQ feedback in the uplink direction for the received downlink data. Figure 9 shows a simplified call-flow of this mechanism. As shown In Rg. 9, the uplink process starts with a UE 10 transmitting user data via PUSCH to the eNB 20. In accordance with the HARQ protocol, the eNB 20 responds with ACK or NACK using PHICH, depending on whether or not the eNB 20 was able to successfully decode the user data. The UE10 determines if a NACK was received from the eNB 20. If so, the UE 10 retransmits the user data. Likewise on the downlink, the eNB 20 transmits user data on PDSCH and the UE 10 responds on PUCCH or PUSCH with ACK or NACK depending on whether it could decode the data. The eNB 20 checks whether a NACK was received and if so, resends the user data on PDSCH.

Meanwhile, the transport channels DL-SCH and UL-SCH also support HARQ. Within these channels each Transport Block is associated with its HARQ information in the following manner (taken from 3GPP TS 36.321: "Medium Access Control (MAC) protocol specification", hereby incorporated by reference: HARQ informations HARQ information for DL-SCH or for UL-SCH transmissions consists of Hew Data Indicator (NDI), Transport Block (TB) size. For DL-SCH transmissions and for asynchronous UL HARQ. the HARQ information also includes HARQ process ID. For UL-SCH transmission the HARQ information also includes Redundancy Version (RV). In case of spatial multiplexing on DL-SCH the HARQ information comprises a set of NDI and TB size for each transport block.

In FDD and for a given DL HARQ entity, 8 HARQ processes are used. In TDD the maximum number of DL HARQ processes depends on the TDD configuration (the following Table 2 taken from 3GPP TS 36.213). Each HARQ process requires a separate soft buffer in the receiver.

Table 2: Maximum number of DL HARQ processes for TDD (Table 7-1 in TS

36.213)

In order for ARQ or HARQ to function correctly, the time taken for the receiver to process the incoming data, to transmit ACK/NACK as appropriate and for this to be received at the transmitter, becomes a critical issue. In the case of DL ARQ or HARQ, one factor of importance is the functional split between different entities in the network; in other words, which entities are responsible for the processing in specific protocol layers.

Traditionally, the protocol stack shown in Figure 9 is implemented in the form shown in Figure 10(a), in which the base station 20 (elMB) defines a cell for wireless

communication by UEs 10, and provides aH the functionality of the protocol layers shown at the right-hand side in Figure 9. In this architecture, the base station consists of two functional units, a radio or RF unit (radio head), and a baseband unit (BBU). The baseband unit (BBU) connects to the network via the backhaul, which is typically an Ethernet circuit The function of the baseband unit is to translate the data stream coming from the network into a form that is suitable for transmission over the air, and in the other direction, to take the data stream from the radio units, and transform it into a form suitable for transport back to the network. The radio unit transmits and receives the carrier signal that is transmitted over the air to the UE 10. As indicated in Figure 10(a), normally both parts of base station 20 would be located at the foot of a tower with the antennas on top of the tower, the radio unit being connected via coaxial RF cables to the antennas. This arrangement has some drawbacks since the RF cables are bulky, expensive, and cause power loss.

However various alternative architectures have been proposed, and in some of these the functionality traditionally implemented in the base station 20 is divided among two or more physically-distinct units. For example, Figure 10(b) shows an arrangement which has come into use recently, in which the RF unit is split from the baseband unit (BBU) 22 and housed in a Remote Radio Head (RRH) 24 - also sometimes called Remote Radio Unit or RRU. In this arrangement the baseband signal is digitized using any of a number of available protocols including CPRI (Common Public Radio

Interface) and Open Base Station Architecture Initiative (OBSAI), and transmitted over fiber optic cable 23 to the RRH 24 mounted on the tower. This avoids the long runs of coaxial cable and the associated RF losses. This concept can be taken further because by use of CPRI, OBSAI or similar protocols there is no longer a need for the RRHs to be physically close to the baseband unit, in fact they can be separated by several kilometres. Figure 10(c) illustrates a so-caled Centralized Radio Access Network (C-RAN) in which a plurality of RRHs 24, located in different locations and providing respective cells covering a geographical area, are served by a common BBU pool 26 in a centralized location, with communication links 23 from the BBU pool to each RRH 24. The term "pool" indicates that there is no need for these BBUs to be distinct hardware units; rather they can be virtuaHsed within one hardware unit 26 or even placed "In the cloud".

Figure 10(d) shows a variant of Figure 10(c) in which part of the baseband processing is moved to the RRH 28. This is related to the idea of the Distributed Unit (DU) and Central Unit (CU) referred to below. In both cases, the connection from the BBU pool to each RRH, typically via optical fiber, is referred to as "fronthaul" (FH) to differentiate it from the traditional "backhaul" which connects the baseband unit to the network. In the case of Figure 10(d), the separate fiber connections 23 from the BBU pool to each RRH are replaced by a fronthaul network 27. In some cases, it may be possible to replace optical fibers by a microwave link. Protocols for communication over the FH are under study in the RAN3 3GPP study group.

Each of the above arrangements of Figures 10(b). 10(c) and (d) can be shown in protocol terms in Figure 20, where the left-hand part of the Figure indicates the protocol layers implemented in the BBU pool 22, 26 or 30 of Figure 10(b), (c) or (d) and the right-hand side shows the RF side handled tn the RRH 24. In current discussions, split entities of such a kind are referred to as a Central Unit CU (corresponding for example to the BBU Pool of Figure 10(d)), and Distributed Unit DU (corresponding for example to the RRH having some BB functionality in Figure 10(d)). For a C-RAN architecture to perform well, it is important that the fronthaul network is designed to keep the fronthaul latency as low as possible. One proposed guideline is to design the network so that the one-way delay is below 75 microseconds. Light travels approximately 1 kilometre in 5 microseconds, so 15 km of fiber would produce a one way latency of 75 microseconds. Transport equipment that injects extra data into the stream will add additional delay.

A BBU must process many signals to and from the RRHs and UEs. If the BBU and RRH are co-located then there is Ittie delay in sending signals between the two. If the radio head is placed 5 kilometres away, the BBU must wart at least 25 microseconds for the signal to reach the radio head, and 25 microseconds for the response signal to come back. Consequently, every communication exchange will take 50 microseconds longer than it would take if the units were co-located. As a result, the efficiency of the baseband unit is reduced because tasks now take longer to execute. Heavy traffic loads, with a large amount of signalling over a network with high latency may result in performance degradation.

As already mentioned, in the RAN centralized architecture there can be a functional split between a Centralized Unit (CU) for the upper layers and a Distributed Unit (DU) for the lower layers, which are connected via a fronthaul link. But different splits are foreseen and are being currently discussed in 3GPP for NR (i.e. New Radio, also caHed the 5G Radio Access Network). The following objective is extracted from the Release- 14 Study Item Description:

· Study the feasibility of different options of splitting the architecture into a 'Central Unit" and a "Distributed Unit", with potential interface in between, including transport, configuration and other required functional interactions between these nodes [RAN2, RAN3]

Figure 12 shows the possible split options in 3GPP (see 3GPP RAN WG3 TS 38.801 VO.4.0 (2016-08)). Figure 12 shows, in greater detail than Figure 11, the protocol layers to be implemented within the architecture. Each vertical arrow denotes an alternative split option, as follows:

Option 1

RRC is in the Central Unit PDCP, RLC, MAC, physical layer and RF are in the Distributed Unit

Option 2

RRC, PDCP are in the Central Unit RLC, MAC, physical layer and RF are in the Distributed Unit.

Option 3 (intra RLC split)

Low RLC (partial function of RLC), MAC, physical layer and RF are in Distributed Unit PDCP and high RLC (the other partial function of RLC) are in the Central Unit

Option 4 (RLC-MAC split)

MAC, physical layer and RF are in Distributed Unit. PDCP and RLC are in the Central Unit.

Option 5 (intra MAC split)

RF, physical layer and part of the MAC layer (e.g. HARQ) are fan the Distributed Unit Upper layer is in the Central Unit Option 6 (MAC-PHY split)

Physical layer and RF are in the Distributed Unit. Upper layers are in the Central Unit Option 7 (intra PHY split)

Part of physical layer function and RF are in the Distributed Unit. Upper layers are in the Central Unit

Option 8 (PHY-RF split)

RF functionality is in the Distributed Unit and upper layer are in the Central Unit

Many possible configurations are under discussion for 5G and it is possible that a combination of different architectures may be combined in one and the same network. In particular, an intra-RLC split (option 3 in Figure 12) is under consideration, and this has the following pros and cons.

Pros:

* Compared to the PDCP-RLC (Option 2) split, this option has the advantage of being more robust under non-ideal transport conditions because the ARQ and packet ordering is performed at the Central Unit CU.

* This split option may also have better flow control across the split.

* Centralization gains: ARQ located In the CU provides more centralization or pooling gains over Option 2.

* The failure over transport network is also recovered using the end-end ARQ mechanism at CU. This provides protection for critical data and C-plane signaling.

* DUs with only partial functionalities of RLC can handle more connected mode UEs as there is no RLC state information stored and hence no need for UE context

* Reduced processing and buffer requirements in DU due to absence of ARQ protocol management.

^* Could be used over multiple radio legs of different DUs for higher reliability (U- Plane and C- Plane).

Cons

* Comparatively, the spOt is more latency sensitive than the split with ARQ in DU, since re-transmissions are susceptible to transport network latency over a spit transport network. Therefore if this split is deployed, the retransmission buffer needed for the ARQ function could be situated either in the Central Unit or in the Distributed Unit Both options have some advantages and disadvantages, as follows. ARQ Retransmission Buffer in CU

Pros:

* More memory and computing resources available for ARQ function

* Less memory and computing resources are needed at DU side

* No RLC state information stored in DU and hence no need for UE context for ARQ purposes in DU (both stored instead in CU)

* More robust in case of non-ideal FH

* Centralization or pooling gains (using common hardware to serve multiple cells, as in the above mentioned BBU pool)

Cons:

* FH bandwidth needed for retransmission

* Higher latency

* More stringent FH latency requirement

ARQ Retransmission Buffer in DU Pros:

^* Lower latency

* Lower FH bandwidth

* Less stringent FH latency requirement

Cons:

* More memory and computing resources needed in the DU Likewise, the HARQ function could be situated either in the Central Unit or in the Distributed Unit Both options have some advantages and disadvantages:

(i) HARQ Buffer in CU:

Pros:

* More memory and computing resources available for HARQ function

* Less memory and computing resources are needed at DU side

* Information from HARQ retransmission can improve the scheduling function Cons:

* FH bandwidth needed for retransmission

* Higher latency

* Higher FH latency requirement

(ii)HARQ Buffer in DU:

Pros:

Lower latency

* Lower FH bandwidth

* Lower FH latency requirement

Cons:

* More memory and computing resources needed There is consequently a need to determine an appropriate functional split for the ARQ function in a 5G wireless communication system. The problem also arises of how to implement DL HARQ in the above kinds of architecture.

Summary of the Invention

In a RAN centralized architecture (i.e. with a functional split between a Centralized Unit (CU) for the upper layers and a Distributed Unit (DU) for the lower layers, connected via a fronthaul link), the location of the ARQ or HARQ retransmission buffer will be critical for the performance (e.g. latency) and efficiency (e.g. minimum fronthaul traffic data rate). The optimal location will be impacted by different criteria Including traffic, radio Bnk quality, and MAC layer inputs. [Embodiments of the present invention address the selection the optimal location of the ARQ or HARQ retransmission buffer and the signalling needed to control this new feature. Thus, embodiments of the present Invention provide a method to dynamically control and define the location and the behaviour of the retransmission buffer when the Base Station is physically split into two different entities which are physically separated. Since the retransmission buffer location may vary in accordance with circumstances, it is referred to as a Dynamic Retransmission Buffer. According to a first aspect of the present invention there is provided a wireless communication system comprising first, second and third stations, the first station wirelessly linked to the second station, the second station linked to the third station. data being transmitted to the first station via the second station with use of a retransmission protocol, wherein

the third station is arranged to make a determination of where to buffer data for possible retransmission, in accordance with which determination the data is buffered in at least one of the second station and the third station.

Thus, for a specific transmission of data to the first station, the third station decides whether to buffer that data itself, or to instruct the second station to buffer the data. In a preferred form of the system, the second station is linked via fronthaul to the third station. Whilst a "wired" fronthaul would be typical, a wireless fronthaul is also possible.

Preferably the first station referred to above (and subsequently) is a terminal such as a mobile station, user equipment (UE), Machine-Type Communication (MTC) device or the like.

The second station may be a Distributed Unit, DU, and the third station may be a Centralised Unit, CU in the sense in which these terms are employed in current 3GPP Release 14 discussion documents.

Embodiments of the present invention include embodiments applied to ARQ, and embodiments applied to HARQ. Both kinds of embodiments may be combined in the same system.

In embodiments appBed to ARQ, the third station is arranged to make a determination of where to buffer data for possible ARQ retransmission, in accordance with which determination the data is buffered in at least one of the second station and the third station, the third station is arranged to make a determination of where to buffer data for possible ARQ retransmission, in accordance with which determination the data is buffered in the second station or the third station. The second station is arranged to receive from the third station an instruction of whether to buffer the data for possible ARQ retransmission. Thus, for a certain level of granularity of wireless communication such as a specific transmission of data to the first station, the third station decides whether to buffer that data itself for ARQ purposes, or to instruct the second station to buffer the data. Preferably the data includes Radio Link Control Protocol Data Units. RLC PDUs which are buffered in an RLC-layer retransmission buffer in accordance with said determination. In a preferred form of the system, the second station Is linked via fronthaul to the third station. Whilst a "wired'' fronthaul would be typical, a wireless fronthaul is also possible.

Preferably the first station referred to above (and subsequently) is a terminal such as a mobile station, user equipment (UE), Machine-Type Communication (MTC) device or the like. The second station may be a Distributed Unit, DU, and the third station may be a Centralised Unit, CU in the sense in which these terms are employed in current 3GPP Release 14 discussion documents. The third station can make the determination on the basis of at least one of the following criteria:

an indication of RLC PDU size obtained from lower layers;

a number of unsuccessfully decoded RLC PDUs;

latency of the fronthaul link;

load on the fronthaul link;

error rate performance of the fronthaul link;

amount of memory available in the second station;

computing resources available in the second station; and

an ACK/NACK rate achieved in use of ARQ.

The wireless communication system preferably provides an End-to-End, E2E, service or slice to the first station, in which case the criteria may further include the kind of E2E service or slice provided to the first station. Preferably the third station is further arranged to notify the second station of its determination by transmitting additional information for ARQ purposes, this additional information Informing the second station whether or not to buffer the data for possible ARQ retransmission. This additional information may be contained in a header of the RLC PDU, for example as a "buffer ID" identifying the second or third station.

This additional information is employed by the second station (and optionally also by the first station) to manage the ARQ retransmission. Thus, preferably, the second station provides a status report to the third station including said additional information in a paytoad of the status report This allows the second station to know whether or not to buffer the data. In one embodiment, the second station is arranged to transmit said data to the first station including the additional information. The first station can then include the additional information in its own status report (ACK/NACKs) to the second station. This allows the second or third station to know which RLC PDUs can be removed from its retransmission buffer.

Alternatively the second station is arranged to transmit said data to the first station without including the additional information. In that case there is no modification required at the first station, which can send status reports (ACK/NACK) in the conventional manner. The second and/or third station then has to check whether the status reports relate to data buffered locaHy.

In other embodiments of the present invention, the retransmission protocol comprises Hybrid Automatic Repeat reOuest, HARQ, and data is provided to the first station with use of one or more HARQ processes.

In one such embodiment ("per-service" embodiment), the above mentioned data buffered for possible retransmission may be data of one or more specific services or slices provided to the first station via the second station. In another, "per-UE" embodiment, any data being transmitted to the first station via the second station is buffered.

In a third, "per-DLT embodiment, one or more other stations are wirelessly linked to the second station, and the buffered data includes data befang transmitted to any of the stations wirelessly linked to the second station.

Two or more of the above embodiments may be combined in the same third station.

As already mentioned the third station makes a determination where to buffer data for possible retransmission. This determination can be made using any one or more of the following criteria:

• latency of the fronthaul link;

• bad on the fronthaul link; • amount of memory available In the second station;

• computing resources available in the second station;

• an ACK/NACK rate achieved by the HARQ processes; and

• a number of CRC errors found during the HARQ processes.

The wireless Hnk between the first station and the second station may have a Channel Quality Indicator, CQI, and the system may provide at least one service or slice to the first station, in which case the criteria may further include:

• the CQI of the wireless link; and/or

· the kind of service or slice provided to the first station.

Preferably the third station is further arranged to notify the second station of its determination by transmitting first extension information of the retransmission protocol, the first extension information informing the second station whether or not to buffer the data for retransmission.

The second station may be arranged to transmit second extension information of the retransmission protocol, indicating whether transmitted data is buffered in the second station or in the third station. In this case, preferably, the first station is arranged to include the second extension information in an acknowledgement of the transmitted data.

According to a second aspect of the present invention, there is provided a third station in a wireless communication system comprising first, second and third stations, the first station wirelessly linked to the second station, the second station linked to the third station, data being transmitted to the first station via the second station with use of a retransmission protocol, wherein

the third station is arranged to make a determination of where to buffer data for possible retransmission, in accordance with which determination the data is buffered in the second station or the third station.

The above third station is, for example, a Centralised Unit (CU) as referred to elsewhere in this specification, and can have any of the features of the third station referred to above with respect to the wireless communication system of the invention.

According to a third aspect of the present invention, there is provided a second station in a wireless communication system comprising first, second and third stations, the first station wirelessly linked to the second station, the second station linked to the third station, data being transmitted to the first station via the second station with use of a retransmission protocol, wherein

the second station is arranged to receive from the third station an instruction of whether to buffer the data for possible retransmission.

This second station may be a Distributed Unit (DU) as referred to elsewhere in this specification, and can have any of the features of the second station referred to above with respect to the wireless communication system of the invention. According to a fourth aspect of the present invention, there is provided a first station in a wireless communication system comprising first, second and third stations, the first station wireiessly Hnked to the second station, the second station linked to the third station, data being transmitted to the first station via the second station with use of a retransmission protocol, wherein

the first station is arranged to receive, from the second station and in addition to the transmitted data, extension information of the retransmission protocol indicating whether the transmitted data is buffered in the second station or in the third station, and is arranged to include the extension information in an acknowledgement returned to the second station.

The above first station may be a terminal such as a mobile station, user equipment (UE), Machine-Type Communication (MTC) device or the like.

According to a fifth aspect of the present invention, there is provided a wireless communication method in a wireless communication system comprising first, second and third stations, the first station wireiessly linked to the second station, the second station Hnked to the third station, the method comprising:

transmitting data to the first station via the second station with use of a retransmission protocol, wherein the third station makes a determination of where to buffer data for possible retransmission, and the data is buffered in the second station or the third station in accordance with the determination.

According to a further aspect of the present invention there is provided a wireless communication system in which a terminal has a wireless link for communication with a Distributed Unit, the Distributed Unit has a fronthaul link for communication with a Central Unit and wherein communication over the wireless (ink from the Distributed Unit to the terminal is conducted using one or more Hybrid Automatic Repeat reQuest, HARQ. processes, the Central Unit comprising a HARQ manager arranged to determine the location of a HARQ retransmission buffer as one of:

in the Central Unit; and

in the Distributed Unit.

5

According to a final aspect, invention embodiments provide a computer program which when downloaded onto an apparatus causes it to become any one of the first, second and third stations detailed above or which when executed on a computing device of a telecommunications apparatus carries out a method as defined above.

0

Thus, embodiments of the present invention provide a method to dynamically control and define the location and the behaviour of a retransmission buffer (ARQ buffer and/or HARQ sending buffer) when the Base Station is physically split into two different entities which are physically separated.

5

In a RAN centralized architecture (i.e. functional split between a Centralized Unit (CU) for the upper layers and a Distributed Unit (DU) for the lower layers, connected via a fronthaul link), the location of the buffer (i.e. in the CU or the DU) is critical for the performance (e.g. latency) and efficiency (e.g. minimum fronthaul traffic data rate). The0 optimal location will be impacted by different criteria (e.g. traffic, radio link quality). This invention proposes a method to select the optimal location of the buffer and the signalling needed to control this new feature.

Features detailed above with respect to any different aspects may be combined with5 any or all the features of the other aspects since they refer to the same invention.

According to a final aspect, invention embodiments provide a computer program which when downloaded onto an apparatus causes it to become any one of the first second and third stations detailed above or which when executed on a computing device of a0 telecommunications apparatus carries out a method as defined above.

Features detailed above with respect to any different aspects may be combined with any or all the features of the other aspects since they refer to the same invention. 5 Brief Description of the Drawings

Preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings, in which:

Figure 1 illustrates a protocol stack in a conventional UE and eNB in a wireless communication system;

Figure 2 is a schematic block diagram of an Acknowledged Mode (AM) Radio Link Control (RLC) entity in the wireless communication system;

Figure 3 is a flowchart of steps performed by a transmitting side AM RLC entity;

Figure 4 is a flowchart of steps performed by a receiving side AM RLC entity,

Figure 5 is a flowchart of steps performed by the transmitting side AM RLC entity in response to a positive Acknowledgement (ACK) sent from the receiving side as part of an ARQ process;

Figure 6 is a flowchart of steps performed by the transmitting side AM RLC entity in response to a Negative Acknowledgement (NACK) from the receiving side in the ARQ process;

Figures 7 and 8 show alternative formats of a STATUS PDU employed in the ARQ process;

Figure 9 shows a conventional HARQ procedure;

Figures 10(a) to (d) show various possible architectures for the functional split between a BBU and RRH;

Figure 11 shows the functional split between a BBU and RRH in protocol terms;

Figure 12 shows possible functional splits under discussion in 3GPP;

Figure 13 is a flowchart of steps performed by a Central Unit (CU) in an embodiment of the present invention applied to ARQ;

Figure 14 is a flowchart of steps performed by a Distributed Unit (DU) in an embodiment of the present invention applied to ARQ;

Figure 15 is a flowchart of steps performed by a UE in an embodiment of the present invention applied to ARQ;

Figure 16 shows a HARQ process conducted in an embodiment of the present invention between a UE, a Distributed Unit (DU) and a Central Unit (CU) in a case where a HARQ buffer is located in the DU;

Figure 17 shows a HARQ process conducted in an embodiment of the present invention between a UE, a Distributed Unit (DU) and a Central Unit (CU) in a case where a HARQ buffer is located In the CU;

Figure 18 is a flowchart of processing steps in a DU In an embodiment of the present invention; Figure 19 Is a flowchart of processing steps in a CU In an embodiment of the present invention;

Figures 20(a) and (b) are flowcharts of processing steps in a UE in an embodiment of the present invention;

Figure 21 is a schematic block diagram of a UE which may be employed in the present invention;

Figure 22 is a schematic block diagram of a DU which may be employed in the present invention; and

Figure 23 Is a schematic block diagram of a computing device which may be employed as a CU in the present invention.

Detailed Description

Embodiments of the present invention will now be described with respect to the accompanying drawings, beginning with embodiments appied to ARQ, followed by embodiments applied to HARQ.

ARQ In a RAN centralized architecture, as already mentioned there can be a functional split between a Centralized Unit (CU) for the upper layers and a Distributed Unit (OU) for the lower layers, which are connected via a fronthaul link. For the intra RLC layer split, instead of having a unique ARQ Retransmission Buffer located at CU or DU, embodiments of the present invention employ a dynamic buffer scheme, where there are two ARQ Retransmission Buffers located in both CU and DU. This concept is referred to below as a "Dynamic Retransmission Buffer".

Embodiments of the present invention applied to ARQ therefore may comprise one or more of the following features:

* New behaviours for the CU, the DU and optionally the UE to handle the Dynamic Retransmission Buffer

* Decision-making functionality to control the location of the Dynamic

Retransmission Buffer

* A new RLC STATUS PDU to control the split buffer functionality

Taking the tatter of these features first to decide if the transmitting nodes (here the CU and the DU) should cache the received RLC PDU for ARQ purposes, and to know in which node the buffered RLC PDU is located, a new information field is provided in the existing, legacy STATUS PDU (see section 6.2.1.6 of the above mentioned 3GPP specification TS 36.322 for detailed description) and in the AMD PDU header (see section 6.2.1.4). Referring to Figures 7 and 8 discussed in the introduction, the new field can for example be formed with 1 or 2 bits, added to the legacy AMD PDU headers (to decide if an RLC PDU should be cached), and n the STATUS PDU payload, for each NACK field. In the AMD PDU header, the new field contains the caching bit added by the CU, used by the DU to know if H needs to cache the packet. In the embodiment to be described, the caching bit is copied into the STATUS PDU payload by the UE; in any case it is used by the CU and the DU to know which node cached the packet

Turning now to the new RLC behaviours required in each of the CU, the DU and (in this embodiment) the UE to handle retransmission of RLC PDUs, an example flowchart for each of these nodes is presented in Figures 13, 14 and 15 respectively.

Figure 13, showing the CU RLC entity behaviour for the Dynamic Retransmission Buffer, can be compared with Fig. 3 showing the corresponding conventional behaviour. The process begins at S1201 with the RLC entity receiving an SDU from the upper layer (e.g. PDCP or RLC in LTE) and adding it to a transmission buffer, which as already mentioned is distinct from the retransmission buffer used for ARQ.

Then in steps S1202 the CU RLC entity segments the SDU into several RLC PDUs, or concatenates it with other SDUs from the Reception Buffer in order to build a RLC PDU.

In S1203 the header is added to the RLC PDU in the same way as in the conventional procedure. In S1204 a decision is taken on whether to locate the retransmission buffer for this PDU in the CU or in the DU, on the basis of criteria described below.

In S1205 it is checked whether the buffer location is determined to be the CU. If so (S1205, "Yes") the flow proceeds to S 1206 in which the RLC PDU is stored in the retransmission buffer of the CU, and the buffer ID = CU is added to the header. Alternatively, (S1205, "No") the flow proceeds to S1207 in which the buffer ID (in this case "ID=DU") is added to the RLC PDU header but the PDU itself is not stored in the CU retransmission buffer. Then, in either case the PDU is transmitted over the FH to the DU in step S1208. The DU in turn will transmit the PDU(s) over the wireless interface to the UE.

In due course the CU wil receive from the DU an RLC STATUS report showing the outcome of the transmission (step S1209). In response, in S1210 the CU retransmits to the DU any PDU for which NACK was indicated in the RLC STATUS report and for which the buffer ID was given as CU. On the other hand, for RLC PDUs having buffer ID = CU and which ACK was indicated, in S1211 the CU merely removes them from the retransmission buffer. Figure 14 shows the corresponding process on the DU side. As already mentioned, more than one DU may be linked to the same CU, but it is only necessary to consider one DU.

In step S1301 , the DU receives an RLC PDU transmitted over the FH from the CU. In S1302, the DU checks the buffer ID contained in the header. If this indicates DU as the buffer ID (S1302, "YES") then the flow proceeds to S1303 in which the DU stores the received RLC PDU in a local retransmission buffer of the DU, and then flow proceeds to S1304. If in S1302 the buffer ID does not indicate the DU, this means that the PDU is already stored at the CU and the flow can proceed directly to S1304, in which the RLC PDU is forwarded for transmission to the UE. In RLC terms this means that the RLC PDU is passed down to lower layers including ultimately the PHY layer where it is transmitted over the radio channel.

Once the UE has received the transmission, it sends a report which the DU RLC entity receives in the form of an RLC status report, in S1305. As mentioned earlier, this report may cover multiple PDUs. The report is checked for any NACK of an RLC PDU having buffer ID = DU. If such a PDU is indicated than the relevant PDU is

retransmitted (re-sent from the DU retransmission buffer to lower layers). In addition, the RLC status report is forwarded to the CU in step S1307 so that any NACKed PDUs having buffer ID = CU can be retransmitted from the CU. Finally in S1308 any PDU having buffer ID = DU and for which ACK has been received, is removed from the DU's retransmission buffer. In this embodiment the buffer ID is forwarded to the UE. and so the UE behaviour is modified with respect to constructing the above mentioned RLC STATUS report to take account of the buffer ID, as shown in Figure 15. In step S1401 the RLC entity In the UE receives an RLC PDU from lower layers as a result of transmission over the wireless interface from the DU. In S1402 this RLC PDU is stored in a reception buffer of the UE. In S1403, depending on the outcome of the CRC the PDU was either received correctly (S1403, "Yes") in which case flow proceeds to S1404, or was not received correctly (S1403, "No") in which case the next step is S1405.

In S1404 the buffer ID is checked. If this indicates CU (S1405. "Yes") then the part of the RLC STATUS report for this PDU includes the Sequence Number, ACK and buffer ID = CU as shown in S1406. If the buffer ID did not indicate CU. S1407 adds corresponding information to the status report except that buffer ID = DU. Meanwhile in S1405, depending on the whether the buffer ID indicates CU or not, the SN of the PDU is placed in the status report along with a NACK and the buffer ID = CU or DU as the case may be, as shown in S1408 and S1409. In any case, the next step is to transmit the RLC STATUS report to upper layers and thence to the DU in steps S1410 and S1411.

The decision on where to locate the ARQ retransmission buffer (Figure 13, S1204) will now be described in more detail. An ARQ caching function based in the CU is in charge of making the decision. For each RLC PDU built by the RLC-layer, the ARQ caching function will then decide in which node the RLC PDU should be cached, and therefore setting the "Buffer ID" to the right value before sending it to the next node. For example, if the RAN architecture consists In 2 nodes, a Central Unit and a Distributed Unit, the Buffer ID will take the value "CU" if it has to be stored in the Central Unit, and the value "DU" if ft has to be stored in the Distributed Unit. More generally, several DUs may be connected to the same CU.. As will be apparent, a single bit value suffices to distinguish between CU and a single DU. In the case where the CU is connected to a plurality of DUs, 1 bit is also enough if the UE sends the ACK/NACK to the same DU it receives the PDU from. The UE knows from lower layers information from wh9tch DU it received the PDU.

On the other hand, an ID of more than 1 bit ID will be needed if: there is a cascaded architecture, in which one or more intermediate nodes exist between the CU and the DU; or

the UE sends the ACK/NACK to a different DU (different from the one from which it received the PDU).

In order to take the best decision concerning the cache location for each RLC PDU. the following criteria will be used by the ARQ function.

(a) Indication of RLC PDU size obtained from lower layers (e.g. MAC in LTE)

As already mentioned the RLC PDU size (length of one RLC PDU) may vary. If the RLC PDU size signalled by the lower layers fa Is below a certain threshold,

segmentation will become necessary for the PDU stored in the retransmission buffer. Then it is beneficial to move the Retransmission Buffer to the DU, so that the re- segmentation function is located in the same node as the Retransmission Buffer and the lower layer. This will improve the re-transmission latency.

(b) Number of unsuccessfully decoded RLC PDUs For example if the number of CRC errors (i.e. the number of NACKed RLC PDUs received by the ARQ function) reaches a certain threshold, the ARQ caching function can decide to cache the last NACKed RLC PDU and the foflowing ones in the DU in order to reduce the signaling on the FH. (c) Latency and load on FH

For example if the latency on the FH link reaches a certain limit where the performance is degraded, the ARQ caching function can decide to cache the next RLC PDUs in the DU.

Communication over the FH at the transport layer level, for example using Simple Network Management Protocol (SNMP), is managed with a Transport Network Layer (TNL) monitoring process employing a TNL buffer, which is not to be confused with the ARQ retransmission buffer referred to elsewhere. Then latency can be measured with the help of the Transport Network Layer (TNL) monitoring process. For example a SNMP message will be send to the CU when the TNL buffer is over 50%. Another possibility is that a SNMP message wil be send to the CU if the latency (e.g. monitored by a ping every second) is over a configured (e.g. OAM) threshold. This SNMP trap should be send to the CU, which will update its buffering policy. Another possibility is to define a parameter used as a threshold and based on a number of received PDUs not arriving in the required time. (d) Service / Slice

A given UE can access different kind of End-to-End (E2E) services from the same network infrastructure, such as video streaming or voice calls. A slice is a new concept which will be introduced in future NR specifications, the current definition of which is "a network created by the operator customized to provide an optimized solution for a specific market scenario which demands specific requirements with end to end scope". A slice can be built to support one or more specific services.

Each slice or service can have different requirements for the ARQ function, and control set-up signalling for the slice will specify the location of the ARQ retransmission buffer. For example Ultra-Reliable and Low Latency Communications (URLLC) services or slices need very quick retransmissions in order to reach their Key Performance

Indicators (KPIs). In that case the ARQ Retransmission Buffer wiN be deployed in the DU no matter what the other criteria.

(e) DU memory and CPU

The memory and the CPU resources in the DU will be very limited compared to CU resources. The ARQ caching function may decide the best location for the ARQ Retransmission Buffer according to available resources in both nodes.

(0 ACK/NACK rate

The overall ACK/NACK rate, that is, the throughput of the acknowledgements, has an impact on upper layers performance such as TCP throughput because the upper layers must wait for ACKs before sending the next packets. Improving the ACK/NACK rate by moving the ARQ Retransmission Buffer to the DU (in case of overloaded FH) or to the CU (in case of memory or computing resources shortage in the DU) can improve overall Quality of Experience (QoE). Therefore the ARQ function can take the

ACK/NACK rate into consideration to select the best location for the ARQ

Retransmission Buffer. As will be apparent from the above list of criteria, the ARQ caching function can take into account a range of factors when deciding the optimum location for the buffer. Some of these factors relate to a DU, some to a UE, and some to Individual services provided to a UE.

Accordingly, the invention can be applied to ARQ at any or all of the following levels:

(i) "per-DU": in other words to all RLC PDUs for transmission to a given DU, at least for a certain time period;

(B) "per-UE": to all RLC PDUs for transmission to a DU and intended for a specific UE; and

(iii) "per-service": to RLC PDUs both for transmission to a DU and intended for a specific UE, and furthermore relating to a specific or slice provided to that UE.

It should be noted that the same CU may operate at more than one level at once. For example, the same CU may handle a certain DU on a "per-DU^* basis, with all PDUs buffered in that DU, whilst in the case of another DU connected to that CU, the CU may apply the decision process on a "per-UE" basis to data for individual UEs, and/or "per- service" to particular services being provided to one or more UEs. In other words "per- DU", "per-UE" and "per-service" can co-exist for the same CU, with rule priorities, with the "per-DU" rule having the highest priority.

A further consequence of the above possibiity is that the location for the ARQ

Retransmission Buffer is not necessarily an "either/or" decision. Rather, a

retransmission buffer may exist in both nodes, the present invention modifying the size and frequency of use of the buffer. Generally, therefore, the Dynamic Retransmission Buffer may be thought of as having memory space available to it in both DU and CU, even if that space is not necessarily used for ARQ purposes in both nodes

simultaneously.

HARQ

Embodiments of the present invention applied to HARQ wil now be described.

In both cases, signalling to control the HARQ function and the retransmission is needed on and using the fronthaul link. Instead of having a unique buffer located at CU or DU, embodiments of the present invention employ a dynamic buffer scheme, where Transmission Block (TB) buffers for HARQ function are located in both CU and DU. The above principle will now be described in more detail. It is assumed that each UE is connected to one DU, that generally a plurality of UEs connect to the same DU, and (In a similar manner to that shown in Figure 3(c) or (d)) that a plurality of DUs are linked by fronthaul to the same CU.

The following definitions will be used:

- HARQ function: The full HARQ process functional entity. It can be situated in the

CU. the DU, or in both

- HARQ caching function: Always situated in the CU, it will decide where the TB needs to be cached

- HARQ information: As described in TS 36.321 3.1, "Medium Access Control (MAC) protocol specification"

Figure 16 shows a HARQ process (HARQ functional call flow) conducted in an embodiment of the present invention between a UE 100, a Distributed Unit(DU) 200 and a Central Unit (CU) 300 in a case where a retransmission buffer is located in the DU , and Figure 17 shows the corresponding call flow in the case where the buffer is located in the CU. in a dynamic scheme as proposed in embodiments of the present invention, it is necessary for the DU and CU to be able to keep track of where the buffer is located currently, so that each node knows if it needs to store data for possible retransmission.

In order for the node receiving the TB to know if it needs to cache data locally, embodiments of the present invention introduce a new information bit in the HARQ information. This information bit, called the "caching bit" is set to 1 when the HARQ caching function takes the decision to cache the TB in the next node (here the DU).

Thus in Figure 16 for example, the process begins with the CU 300 sending a transport block TB. intended for UE 100. to the DU 200 together with the Caching bit notifying that DU 200 that the DU is to be responsible for caching of this data. Alternatively, as shown in the initial step of Figure 17 the Caching bit is set to "0" denoting that for this TB. the caching will be done at the CU 300. As explained below, this notification need not be the same for all data (all TBs) received by the DU.

Embodiments of the present invention further introduce a new field called "buffer ID". This field will be set by the last network node (here the DU) before sending the TB to the UE.

Thus, in Figure 16, when the DU 200 forwards to UE 100 a TB received from the CU 300, it sets the Buffer ID field to indicate that the TB is being buffered in the DU 200 in this instance. The DU maintains a separate buffer for each UE (each HARQ process) in respect of which a caching bit "1" was received. Meanwhile in Figure 17, the corresponding transmission from DU 200 has Buffer ID = CU.

As shown in both Figures 1$ and 17, the UE 100 copies this field when sending its ACK/NACK response, but without interpreting it This will help the receiving node (here the DU) to know which buffer has been used, and therefore decide its behaviour concerning this ACK/NACK response. That is. in the case of Figure 16 the DU 200 itself must act upon the ACK/NACK information, managing the subsequent process and informing the CU 300 of the eventual successful transmission; whilst in the case of Figure 17 the DU merely forwards the ACK/NACK to the CU 300 without taking any further part in the HARQ process.

Assuming that any given UE is connected to only one DU, it is sufficient for this buffer ID to be a single bit The specific DU which transmitted the TB is identifiable to the CU using information from other layers, such as a transport MAC address.

The full behaviour of the HARQ function, for each element of the network, including the use of the "caching bit" and the "buffer ID" is described in Figures 18, 19 and 20.

The DU 200 process depicted in the flowchart of Figure 18 begins in step S202 with the DU receiving a TB from CU 300. At S204 the DU checks whether the value of the caching bit contained In the TB is "1". If it is, this indicates that the DU needs to cache this TB, and the DU does so in step S206. adding its own buffer ID to the TB prior to transmission. On the other hand, if the caching bit is set to "0", there is no need for the DU to store the TB, and the DU merely adds the buffer ID of CU 300 to the TB. In both cases, the flow then proceeds to S210 where the caching bit is removed from the TB, and the TB is forwarded to the UE100.

In step S212 the DU 200 receives the ACK/NACK response from UE100. In S214 the DU examines the buffer ID contained in the ACK/NACK response. If the buffer ID is that of the DU 200 (S214, Yes) the flow proceeds to S216 where the DU checks if ACK or NACK is indicated. If ACK (S216, Yes) the DU forwards the ACK to CU 300, and removes the TB from the relevant buffer since the TB has been transmitted

successfully. On the other hand, if a NACK is received (S216, No) the DU 200 retransmits the TB to UE 100 and the flow returns to step S212. Meanwhile, if the result of S214 was that the buffer ID is not that of the DU (in other words, identifies the CU) then the DU simply forwards the ACK/NACK information to CU 300 without examining it (S218). Figure 19 shows the corresponding flow In the CU 300. It should be noted that the CU carries out the process of Figure 19 separately for each DU connected to it (and possibly with finer granularity still, see below), so that for some DUs the CU would act as the buffer and others the DU would handle it.

Beginning at S302, the CU decides (in a manner described below) where the HARQ buffer should be located, in other words where data should be buffered for posstole retransmission. This step may be triggered periodically, in response to the some change in capabiRties of the DU (see below), or even every time a TB is prepared for transmission.

In S304, if the decision is to locate the buffer in the CU (S304. Yes) then CU 300 stores the TB itself and adds a caching bit with value "0" to the TB. On the other hand if the decision is to buffer the TB in the DU 200, then the CU sets the caching bit in the TB to "1", without itself storing the TB for possible retransmission. In both cases, flow proceeds to S310 where the TB is transmitted to the DU over the FH.

In Step S312 the CU 300 receives the ACK/NACK response from the DU (see Figure 18, steps S210 and S218). Step S313 is to examine the buffer ID contained in the ACK/NACK information. If this indicates the buffer ID of the CU. (S314. Yes), the flow proceeds to S316; otherwise (S314, No), this impRes that the DU is the buffer for the TB, and the DU will manage the ACK/NACK process; thus, the CU can wait to receive the next TB which is ready to be transmitted to the UE (S318).

In S316, It is checked whether ACK or NACK was received. If ACK (S316, Yes) then the CU 300 knows that the UE successfully received the TB, which can therefore be removed from the buffer in S320. On the other hand if NACK was received, then since the CU is handling the retransmission in this instance, the CU retransmits the TB to the DU in S322, and the flow returns to S312 to await the ACK/NACK response for the retransmitted TB.

Turning now to Figure 20(a), showing the corresponding operation steps in the UE 100, the process starts in S102 with the UE receiving a TB from the DU200. In S104 the UE 100 determines whether it could decode the TB or not (based on whether the CRC check is successful). If so, (S104, Yes) the flow proceeds to S106 where the UE 100 examines the buffer ID contained in the TB. In the case that this ID is that of the CU (S106, Yes), the UE sends ACK with this buffer ID back to the DU 200 In S110. In the case that this ID is that of the DU (S106, No), the UE sends ACK with this buffer ID back to the DU 200 in S112. It wiH be noted that this ACK/NACK information is different from conventional ACK/NACK because it is extended by addition of the buffer ID. Meanwhile, if the outcome of S104 was that the CRC check failed, in other words that the TB did not decode correctly, flow proceeds to S106, S114 and S116 where the UE returns NACK with the appropriate buffer ID, assuming that this can be identified from the decoded data.

However, it is possible that the UE cannot recover the Buffer ID from the TB. In that case, the UE can simply take no action (i.e. not send ACK/NACK). This wiR cause the DU or CU to retransmission time the TB (along with the buffer ID) after a time delay. Alternatively, the UE may be configured with a default behaviour to follow in this case, such as always to send the ACK/NACK to the CU. The CU, if it receives such an ACK/NACK can forward it to the DU if it is not recognised by the CU.

It should be noted that steps S106 to S116 are optional. In an alternative operation flow shown in Figure 20(b), these steps are replaced by an alternative steps S120 and S122 in which, after the CRC check in S104. the UE simply sends to DU 200 the ACK or NACK including the buffer ID copied from the TB, without examining the buffer ID . As will be apparent from the above description, embodiments of the present invention involve the CU 300 taking decisions with respect to the location of HARQ buffering for each DU and possibly each UE. A HARQ caching function, based in the CU, is provided for making these decisions. For each TB built by the upper MAC-iayer, the HARQ caching function will then decide in which node the TB should be cached, and therefore set the "caching bit" to the right value before sending it to the next node.

In order to take the best decision concerning the cache location for each TP, the cache size and the number of HARQ processes, the following criteria will be used by the HARQ caching function:

(i) Number of CRC errors at PHY layer

For example if the number of CRC errors (i.e. the number of NACK received by the HARQ function) reaches a certain threshold, the HARQ caching function can decide to cache the current TB and the following ones in the DU in order to reduce the signalling on the FH.

(ii) Latency and load on FH

For example if the latency on the FH link reaches a certain limit where the performance is degraded, the HARQ caching function can decide to cache the next TBs in the DU.

To determine that the performance is degraded, the CU can use the Transport Network Layer (TNL) monitoring process; for example the CU may receive (or detect) an SNMP message when the TNL buffer is over 50%. SNMP stands for Simple Network Management Protocol. Alternatively the CU may detect that the latency (monitored by a ping every second) is over a configured (e.g. OAM) threshold. This SNMP trap should be sent to the CU, which will update its buffering policy

(iii) Service / Sice

A given UE can access different kind of End-to-End (E2E) services from the same network infrastructure, such as video streaming or voice calls. A slice is a new concept which will be introduced in future NR specifications. The current definition of a network slice in the 3GPP RAN WG3 study TR 38.801 vO.4.0 "Study on New Radio Access Technology; Radio Access architecture and Interfaces" is:

A Network Slice is a network created by the operator customized to provide an optimized solution for a specific market scenario which demands specific requirements with end to end scope as described in TR 23.799.

A slice can be built to support one or more specific services.

Each sice or service can have different requirements for the HARQ function. For example Uftra-Refiable and Low Latency Communications (URLLC) services or slices need very quick retransmissions in order to reach their KPIs. In that case the HARQ caching function wil be deployed in the DU no matter what the other criteria.

(iv) DU memory and CPU

The memory and the CPU resources in the DU will be very limited compare to CU resources. The HARQ caching function win decide the best location for the HARQ buffer according to available resources in both nodes. The CU can be notified of the DU status such as free memory either periodically, or on an event basis (e.g. when free memory falls below a configurable threshold).

(v) ACK/NACK rate

The overall ACK/NACK rate has an impact on upper layers performance, such as TCP throughput. Improving the ACK/NACK rate by moving the HARQ buffer to the DU (in case of overloaded FH) or to the CU (in case of memory or computing resources shortage in the DU) can improve overall Quality of Experience (QoE). Therefore the HARQ buffer function can take the ACK/NACK rate into consideration to select the best location for the HARQ buffers.

(vi) CQI For a given UE, the overall performance will depend on the efficiency of the

retransmission methods. For example a UE at cell-edge wil need a lot more

retransmission than a UE with better coverage. This will impact the overall system (e.g. FH load). In that case the HARQ caching function can decide to use CU or DU caching for a given UE according to its CQI.

As will be apparent from the above list of criteria, the HARQ caching function can take into account a range of factors when deciding the optimum location for the buffer.

Some of these factors relate to a DU, some to a UE, and some to individual services provided to a UE.

Accordingly, the invention can be applied to HARQ at any or all of the following levels:

(i) "per-DU": in other words to al TBs transmitted to a given DU, at least for a certain time period;

(ii) "per-UE": to all TBs transmitted to a DU and intended for a specific UE; and

(ii) "per-service": to TBs transmitted to a DU, intended for a specific UE and

furthermore relating to a specific or slice provided to that UE.

As in the case of ARQ, the same CU may operate at more than one level at once. For example, the same CU may handle a certain DU on a "per-DU " basis, with all TBs sent to a certain DU using the same decision process, whilst in the case of another DU connected to that CU, the CU may apply the decision process on a "per-UE" basis to data for individual UEs, and/or "per-service" to particular services being provided to one or more UEs. In other words "per-DU", "per-UE" and "per-service" can co-exist for the same CU, with rule priorities, with the "per-DU" rule having the highest priority.

The HARQ caching function can apply rule priorities to manage this multi-level approach, with rule priorities. For example:

o Every UE using Narrow Band loT (NB-loT) will use CU HARQ buffer

o If above rule doesn't apply (i.e. other service) then the decision wil be taken according to UE-related criteria

With respect to the above mentioned criteria employed by the HARQ caching function, all of them can apply to each of these decision levels, with the difference that in case of "per-DU" or "per-service", the following criteria should be averaged with the values of all the UEs using the same DU or the same service:

o Number of CRC errors at PHY layer o ACK/MACK rate

o CQI

Figure 21 is a block diagram illustrating an example of a UE 100 to which the present invention may be applied. The UE 100 may include any type of device which may be used in a wireless communication system described above and may include cellular (or cell) phones (including smartphones), personal digital assistants (PDAs) with mobile communication capabilities, laptops or computer systems with mobile communication components, and/or any device that Is operable to communicate wirelessty. The UE 100 includes transmitter/receiver unit(s) 804 connected to at least one antenna 802 (together defining a communication unit) and a controller 806 having access to memory in the form of a storage medium 808. The controller 806 may be, for example, a microprocessor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other logic circuitry programmed or otherwise configured to perform the various functions described above, in particular to perform the steps shown in the flowchart of Figure 15. For example, the various functions described above may be embodied in the form of a computer program stored in the storage medium 808 and executed by the controller 806. The

transmission/reception unit 804 is arranged, under control of the controller 806, to receive wireless communications over the PHY from the DU 200 and send ACK/NACK and so forth as discussed previously.

Figure 22 is a block diagram illustrating an example of equipment suitable for use as a DU 200. It includes transmitter/receiver unit(s) 904 connected to at least one antenna 902 (together defining a communication unit) and a controller 906. The controller may be. for example, a microprocessor, DSP, ASIC, FPGA, or other logic circuitry programmed or otherwise configured to perform the various functions described above, in particular the steps in the flowchart of Figure 14. For example, the various functions described above may be embodied in the form of a computer program stored in the storage medium 908 and executed by the controler 906. The transmission/reception unit 904 is responsible for transmission over the wireless interface to the UE under control of the controller 906. In addition, as indicated in the Figure, the controller is connected to the fronthaul FH and thereby to the CU 300.

As will be apparent from the above description, although it is necessary for each UE and DU to have wireless communication capabilities, there is no such requirement on the CU 300, which can take the form of a general-purpose computer. Figure 23 is a block diagram of a computing device which may be used as a CU as referred to above in order to implement a method of an embodiment The computing device 300 comprises a computer processing unit (CPU) 993. memory, such as

Random Access Memory (RAM) 995, and storage, such as a hard disk, 996. The computing device also includes a network adapter 999 for communication with other such computing devices of embodiments. For example, an embodiment may be composed of a network of such computing devices. Optionally, the computing device also includes Read Only Memory 994, one or more input mechanisms such as keyboard and mouse 998, and a display unit such as one or more monitors 997. The components are connectable to one another via a bus 992. The CPU 993 is configured to control the computing device and execute processing operations, such as the steps in the flowchart shown in Figure 13. The RAM 995 stores data being read and written by the CPU 993. The storage unit 996 may be. for example, a non-volatile storage unit, and is configured to store data.

The CPU 993 may include one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. The processor may include a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processor may also include one or more special- purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. In one or more embodiments, a processor is configured to execute instructions for performing the operations and steps discussed herein.

The storage unit 996 may include a computer readable medium, which term may refer to a single medium or multiple media (e.g., a centralized or distributed database and/or associated caches and servers) configured to carry computer-executable instructions or have data structures stored thereon. Computer-executable instructions may include, for example, instructions and data accessible by and causing a general purpose computer, special purpose computer, or special purpose processing device (e.g., one or more processors) to perform one or more functions or operations. Thus, the term "computer-readable storage medium" may also include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methods of the present disclosure. The term "computer-readable storage medium" may accordingly be taken to include, but not be limited to, solid-state memories, optical media and magnetic media. By way of example, and not limitation, such computer-readable media may include non-transitory computer-readable storage media, including Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable

Programmable Read-Only Memory (EEPROM), Compact Disc Read-Only Memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices).

The display unit 997 displays a representation of data stored by the computing device and displays a cursor and dialog boxes and screens enabling interaction between a user and the programs and data stored on the computing device. The input mechanisms 998 enable a user to input data and instructions to the computing device.

The network adapter (network l/F) 999 is connected to a network, such as a high- speed LAN or the Internet and thereby to the fronthaul over which the CU 300 can communicate with one or more DUs 200. The network adapter 999 controls data input/output from/to other apparatus via the network. Other peripheral devices such as microphone, speakers, printer, power supply unit, fan, case, scanner, trackball etc may be included in the computing device 300.

The above mentioned ARQ caching function can be implemented on a computing device such as that illustrated in Figure 23. Such a computing device need not have every component illustrated in Figure 23, and may be composed of a subset of those components. A CU embodying the present invention may take the form of a single computing device 300 in communication with one or more other computing devices via a network. The computing device may be a data storage itself storing at least a portion of the objects. A computation node or staging node embodying the present invention may be carried out by a plurality of computing devices operating in cooperation with one another. One or more of the plurality of computing devices may be a data storage server storing at least a portion of the objects.

Any of the embodiments and variations mentioned above may be combined in the same system. Whilst the above description has been made with respect to LTE and LTE-A, the present invention may have application to other kinds of wireless communication system also. Accordingly, references in the claims to terminal" are intended to cover any kind of subscriber station, mobile device, MTC device and the like and are not restricted to the UE of LTE. The invention also provides a computer program or a computer program product for carrying out any of the methods described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein.

A computer program embodying the invention may be stored on a computer-readable medium, or it may, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it may be in any other form.

Various modifications are possible within the scope of the invention. In the ARQ embodiment described above, the UE examines the buffer ID in order to construct the RLC status report (see Figure 15, steps S1406 - S1409). However, this is not essential and the UE, if it receives the buffer ID, can include this information blindly in the status report without examining it.

More generally it is not essential for the UE to receive the buffer ID at all. As a modification of step S1306 in Figure 14, in an alternative embodiment the DU retransmits each NACK PDU without including the buffer ID. In this case the UE behaviour can be the same as that performed conventionally, so that no modification of the UE is required. This is advantageous for use of the present invention with legacy UEs which have not been updated to handle a Dynamic Retransmission Buffer.

However, this places an additional burden upon the DU and/or CU which now has to check each status report to see if the related data is cached or not. Step S1307 of Figure 14 may be modified by making the DU determine the location of the data and add this information to the RLC status report before transferring it to the CU.

Alternatively the DU may forward the RLC status report in unchanged form so that the CU has to make this determination for itself. Industrial Applicability

The fields of application of this invention includes ail wireless communications systems where ARQ, HARQ protocols or related re-transmission protocols are used.

Claims

CLAIMS:

1. A wireless communication system comprising first, second and third stations, the first station wirelessly linked to the second station, the second station linked to the third station data being transmitted to the first station via the second station with use of a retran mission protocol, wherein

the third station is arranged to make a determination of where to buffer data for possible retransmission, in accordance with which the data is buffered in at least one of the second station and the third station.

2. The wireless communication system according to claim 1 wherein the second station is linked via fronthaul to the third station.

3. The wireless communication system according to claim 1 or 2 wherein the first station is a terminal.

4. The wireless communication system according to any preceding claim wherein the second station is a Distributed Unit, DU, and the third station is a Central Unit, CU as referred to in 3GPP Release 14 discussion documents.

5. The wireless communication system according to any preceding claim wherein the retransmission protocol comprises Automatic Repeat request, ARQ, and the data includes Radio Link Control Protocol Data Units, RLC PDUs which are buffered in an RLC-layer retransmission buffer in accordance with said determination.

6. The wireless communication system according to claim 5 wherein the third station is arranged to make the determination on the basis of at least one of the following criteria:

an indication of RLC PDU size obtained from lower layers;

a number of unsuccessfully decoded RLC PDUs; latency of a fronthaul link between the second station and the third station;

load on the fronthaul link;

error rate performance of the fronthaul link;

amount of memory available in the second station;

computing resources available in the second station; and

an ACK/NACK rate achieved in use of ARQ.

7. The wireless communication system according to claim 6 wherein the system provides an End-to-End, E2E, service or slice to the first station, and wherein the criteria further include the kind of E2E service or slice provided to the first station.

8. The wireless communication system according to claim 5, 6 or 7 wherein:

the third station is further arranged to notify the second station of its

determination by transmitting additional information for ARQ purposes, this additional information Informing the second station whether or not to buffer the data for possible ARQ retransmission; and

the additional information is employed by the second station and optionally also by the first station to manage the ARQ retransmission.

9. The wireless communication system according to any preceding claim wherein the retransmission protocol comprises Hybrid Automatic Repeat reQuest, HARQ, and wherein data is provided to the first station with use of one or more HARQ processes.

10. The wireless communication system according to any preceding claim wherein the buffered data is data of one or more specific services or slices provided to the first station via the second station.

11. The wireless communication system according to any preceding claim wherein any data being transmitted to the first station via the second station is buffered in accordance with the determination.

12. The wireless communication system according to any preceding claim wherein one or more other stations are wirelessly linked to the second station, and the buffered data includes data being transmitted to any of the stations wirelessly linked to the second station.

13. The wireless communication system according to claim 6, wherein the third station is arranged to make the determination on the basis of at least one of the following criteria:

latency of the fronthaul link;

load on the fronthaul link;

amount of memory available in the second station;

computing resources available in the second station;

an ACK/NACK rate achieved by the HARQ processes; and

a number of CRC errors found during the HARQ processes.

14. The wireless communication system according to claim 13 wherein the wireless link between the first station and the second station has a Channel Quality Indicator, CQI, the system provides a service or slice to the first station, and wherein the criteria further include:

the CQI of the wireless link; and/or

the kind of service or slice provided to the first station.

15. The wireless communication system according to any preceding claim wherein the third station is further arranged to notify the second station of its determination by transmitting first extension information of the retransmission protocol, the first extension information informing the second station whether or not to buffer the data for retransmission.

16. The wireless communication system according to any preceding claim wherein the second station is arranged to transmit second extension information of the retransmission protocol, indicating whether that transmitted data is buffered in the second station or in the third station.

17. The wireless communication system according to claim 16 wherein the first station is arranged to include the second extension information in an acknowledgement of the transmitted data.

18. A third station in a wireless communication system comprising first, second and third sta ions, the first station wirelessly linked to the second station, the second station linked to the third station, data being transmitted to the first station via the second station ith use of a retransmission protocol, wherein

the third station is arranged to make a determination of where to buffer data for possible retransmission, in accordance with which the data is buffered in at least one of the second station and the third station.

19. A second station in a wireless communication system comprising first, second and third stations, the first station wirelessly linked to the second station, the second station linked to the third station, data being transmitted to the first station via the second station with use of a retransmission protocol, wherein

the second station is arranged to receive from the third station an instruction of whether to buffer the data for possible retransmission.

20. A first station in a wireless communication system comprising first, second and third stations, the first station wirelessly linked to the second station, the second station Jinked to the third station, data being transmitted to the first station via the second station with use of a retransmission protocol, wherein the first station is arranged to receive, from the second station and in addition to the transmitted data, extension information of the retransmission protocol indicating whether the transmitted data is buffered in the second station or in the third station, and to include the extension information in an acknowledgement returned to the second station.

21. A wireless communication method in a wireless communication system comprising first, second and third stations, the first station wirelessly linked to the second station, the second station linked to the third station, the method comprising: transmitting data to the first station via the second station with use of a retransmission protocol, wherein the third station makes a determination of where to buffer data for possible retransmission, and the data is buffered in the second station or in the third station in accordance with the determination.

22. Software in the form of computer-readable instructions which, when executed by a processor in a computing device, cause the computing device to be the first, second or third station referred to in any of the preceding claims.