[go: up one dir, main page]

WO2018060674A1 - Arq et harq dans une communication sans fil 5g - Google Patents

Arq et harq dans une communication sans fil 5g Download PDF

Info

Publication number
WO2018060674A1
WO2018060674A1 PCT/GB2017/052686 GB2017052686W WO2018060674A1 WO 2018060674 A1 WO2018060674 A1 WO 2018060674A1 GB 2017052686 W GB2017052686 W GB 2017052686W WO 2018060674 A1 WO2018060674 A1 WO 2018060674A1
Authority
WO
WIPO (PCT)
Prior art keywords
station
data
rlc
wireless communication
buffer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/GB2017/052686
Other languages
English (en)
Inventor
Julien Muller
Paul Bucknell
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB1616682.9A external-priority patent/GB2554661A/en
Priority claimed from GB1621713.5A external-priority patent/GB2557960A/en
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of WO2018060674A1 publication Critical patent/WO2018060674A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1874—Buffer management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1896—ARQ related signaling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092—Error control systems characterised by the topology of the transmission link
    • H04L2001/0097—Relays

Definitions

  • 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.
  • ARQ Automatic Repeat reQuest
  • HARQ Hybrid Automatic Repeat reQuest
  • 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).
  • 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,
  • MAC Medium Access Control, Radio Link Control, and Packet Data Convergence Protocol0 layers
  • RRC Radio Resource Control
  • layers can also be numbered as Layer 1 (PHY), Layer 2 (MAC, RLC, and PDCP) and Layer 3
  • transport block 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).
  • 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).
  • NPRB Physical Resource Blocks
  • MCS Modulation and Coding Scheme
  • a CRC cyclic redundancy check
  • 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).
  • ARQ Automatic Repeat reQuest
  • HARQ Hybrid ARQ
  • FEC Forward Error Coding
  • FIG. 1 shows the user plane protocol stack for LTE.
  • data packets are defined as SDUs (Service Data Units) and PDUs (Protocol Data Units) with respect to a specific layer.
  • SDUs Service Data Units
  • PDUs Protocol Data Units
  • 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.
  • the resulting PDU may also be encrypted.
  • the RLC layer and RLC entities shown in Figure 1 are of particular relevance to ARQ.
  • the RLC layer performs segmentation of PDCP SDUs to form RLC PDUs.
  • 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.
  • 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.
  • 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.
  • RLC sub layer Functions of the RLC sub layer are performed by RLC entities.
  • a RLC entity configured at the eNB there is a peer RLC entity configured at the UE and vice versa.
  • 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.
  • SL sidelink
  • STCH Traffic Channel
  • SBCCH SL Broadcast Control Channel
  • 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.
  • SAP Service Access Point
  • 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.
  • TM Transparent Mode
  • UM Unacknowledged Mode
  • AM Acknowledged Mode
  • 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
  • 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).
  • 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.
  • 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 .
  • the upper layer e.g. PDCP
  • Reception buffer & HARQ reordering This is part of a HARQ function (see below).
  • 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
  • the AM RLC entity receives an SDU from the upper layer (e.g. PDCP or RLC in LTE).
  • 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.
  • the AM RLC entity adds the header to the RLC PDU according to section 6 of 3GPP specification TS 36.322.
  • the AM RLC entity stores (a copy of) the resulting RLC PDU into the
  • steps S34 and S35 can be switched, in which case the RLC PDU will be stored in the Retransmission Buffer without the RLC header).
  • 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.
  • the AM RLC entity receives a RLC PDU from lower layer (e.g. MAC in LTE).
  • lower layer e.g. MAC in LTE
  • 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).
  • the upper layer e.g. PDCP or RLC In LTE.
  • 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.
  • SN Sequence Number
  • 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. .
  • 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.
  • 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.
  • 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.
  • the AM RLC entity receives a Negative Acknowledgment via an RLC STATUS PDU.
  • the AM RLC entity retrieves the corresponding RLC PDU, identified by its SN, from the Retransmission Buffer.
  • 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.
  • 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.
  • the lower layer e.g. MAC for LTE
  • 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.
  • one to seven padding bits are included in the end of the STATUS PDU to achieve octet alignment
  • 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.
  • NACK Negative ACKnowiedgment
  • 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.
  • the TB is cached in a HARQ sending buffer, only being discarded when an ACK for that TB is received.
  • 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.
  • 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.
  • HARQ schemes can be categorized as either synchronous or asynchronous in their timing relationship between first and re-transmissions.
  • 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.
  • 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.
  • LTE synchronous HARQ is used for the UL and asynchronous HARQ is used for the DL.
  • 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.
  • 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.
  • MAC Medium Access Control
  • Logical channels Provide services for the Medium Access Control (MAC) layer within the LTE protocol structure.
  • MAC Medium Access Control
  • the Physical and Transport channels are of most importance, and the following channels are of particular relevance.
  • PDCCH Physical Downlink Control Channel
  • DCI Downlink Control Information
  • PDSCH Physical Downlink Shared Channel
  • PDSCH is used to carry user data on the downlink, including the above mentioned TBs in DL HARQ, as well as some control signalling.
  • PHICH Physical Hybrid ARQ Indicator Channel
  • 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.
  • PUCCH Physical Uplink Control Channel
  • PUSCH Physical Uplink Shared Channel
  • Physical layer transport channels offer information transfer to medium access control (MAC) and higher layers. The following will be mentioned below:
  • DL-SCH Downlink Shared Channel
  • 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.
  • the HARQ within the MAC sublayer has the following characteristics:
  • 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;
  • 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.
  • 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)
  • HARQ is controlled in the MAC layer but the HARQ retransmission occurs at the PHY layer.
  • PHICH is used to carry HARQ in the downlink direction for the received uplink data
  • 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.
  • the uplink process starts with a UE 10 transmitting user data via PUSCH to the eNB 20.
  • 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.
  • the transport channels DL-SCH and UL-SCH also support HARQ.
  • 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.
  • NDI Hew Data Indicator
  • TB Transport Block
  • the HARQ information also includes HARQ process ID.
  • the HARQ information also includes Redundancy Version (RV).
  • RV Redundancy Version
  • the HARQ information comprises a set of NDI and TB size for each transport block.
  • HARQ processes 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
  • 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
  • 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.
  • 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.
  • FIG. 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.
  • RRH Remote Radio Head
  • the baseband signal is digitized using any of a number of available protocols including CPRI (Common Public Radio
  • FIG. 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.
  • C-RAN Centralized Radio Access Network
  • 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.
  • 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.
  • FH fronthaul
  • the separate fiber connections 23 from the BBU pool to each RRH are replaced by a fronthaul network 27.
  • 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.
  • FIG. 20 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.
  • 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)).
  • a Central Unit CU corresponding for example to the BBU Pool of Figure 10(d)
  • Distributed Unit DU corresponding for example to the RRH having some BB functionality in Figure 10(d)
  • 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.
  • CU Centralized Unit
  • DU Distributed Unit
  • 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:
  • RRC is in the Central Unit PDCP, RLC, MAC, physical layer and RF are in the Distributed Unit
  • RRC Radio Resource Control
  • PDCP are in the Central Unit RLC
  • MAC media access control
  • RF Radio Network Control Function
  • 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
  • MAC physical layer
  • RF Radio Resource Control
  • PDCP physical layer
  • RLC Radio Link Control
  • RF, physical layer and part of the MAC layer 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)
  • RF functionality is in the Distributed Unit and upper layer are in the Central Unit
  • 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.
  • the HARQ function could be situated either in the Central Unit or in the Distributed Unit Both options have some advantages and disadvantages:
  • 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 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.
  • 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.
  • the third station decides whether to buffer that data itself, or to instruct the second station to buffer the data.
  • the second station is linked via fronthaul to the third station. Whilst a "wired" fronthaul would be typical, a wireless fronthaul is also possible.
  • the first station referred to above is a terminal such as a mobile station, user equipment (UE), Machine-Type Communication (MTC) device or the like.
  • UE user equipment
  • MTC Machine-Type Communication
  • 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.
  • 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.
  • the third station decides whether to buffer that data itself for ARQ purposes, or to instruct the second station to buffer the data.
  • 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.
  • the second station Is linked via fronthaul to the third station. Whilst a "wired'' fronthaul would be typical, a wireless fronthaul is also possible.
  • the first station referred to above 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:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the retransmission protocol comprises Hybrid Automatic Repeat relitis, HARQ, and data is provided to the first station with use of one or more HARQ processes.
  • 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.
  • any data being transmitted to the first station via the second station is buffered.
  • 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.
  • 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:
  • 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 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.
  • the first station is arranged to include the second extension information in an acknowledgement of the transmitted data.
  • 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.
  • CU Centralised Unit
  • 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.
  • 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.
  • UE user equipment
  • MTC Machine-Type Communication
  • 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:
  • 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:
  • 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.
  • 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.
  • the location of the buffer i.e. in the CU or the DU
  • the performance e.g. latency
  • 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.
  • 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.
  • Figure 1 illustrates a protocol stack in a conventional UE and eNB in a wireless communication system
  • FIG. 2 is a schematic block diagram of an Acknowledged Mode (AM) Radio Link Control (RLC) entity in the wireless communication system;
  • AM Acknowledged Mode
  • RLC Radio Link Control
  • Figure 3 is a flowchart of steps performed by a transmitting side AM RLC entity
  • FIG. 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;
  • ACK Acknowledgement
  • 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;
  • NACK Negative Acknowledgement
  • 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
  • FIG. 12 shows possible functional splits under discussion in 3GPP
  • FIG. 13 is a flowchart of steps performed by a Central Unit (CU) in an embodiment of the present invention applied to ARQ;
  • CU Central Unit
  • FIG 14 is a flowchart of steps performed by a Distributed Unit (DU) in an embodiment of the present invention applied to ARQ;
  • DU Distributed Unit
  • 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;
  • DU Distributed Unit
  • CU Central Unit
  • 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;
  • DU Distributed Unit
  • CU Central Unit
  • 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.
  • Figure 23 Is a schematic block diagram of a computing device which may be employed as a CU in the present invention.
  • 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.
  • CU Centralized Unit
  • OU Distributed Unit
  • 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".
  • 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).
  • 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.
  • the new field contains the caching bit added by the CU, used by the DU to know if H needs to cache the packet.
  • 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
  • FIG. 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.
  • the upper layer e.g. PDCP or RLC in LTE
  • 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.
  • the header is added to the RLC PDU in the same way as in the conventional procedure.
  • 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.
  • the CU wil receive from the DU an RLC STATUS report showing the outcome of the transmission (step S1209).
  • 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.
  • 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.
  • step S1301 the DU receives an RLC PDU transmitted over the FH from the CU.
  • 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.
  • 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.
  • 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.
  • this RLC PDU is stored in a reception buffer of the UE.
  • 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.
  • 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.
  • DUs may be connected to the same CU.
  • a single bit value suffices to distinguish between CU and a single DU.
  • 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.
  • 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).
  • 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.
  • the ARQ caching function can decide to cache the next RLC PDUs in the DU.
  • TNL Transport Network Layer
  • OAM OAM
  • 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.
  • 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.
  • E2E End-to-End
  • 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.
  • Ultra-Reliable and Low Latency Communications (URLLC) services or slices need very quick retransmissions in order to reach their Key Performance
  • KPIs Indicators
  • 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.
  • 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
  • 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.
  • the invention can be applied to ARQ at any or all of the following levels:
  • the same CU may operate at more than one level at once.
  • 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.
  • “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.
  • Retransmission Buffer is not necessarily an "either/or" decision. Rather, a
  • 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
  • Embodiments of the present invention applied to HARQ wil now be described.
  • 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.
  • TB Transmission Block
  • - HARQ function The full HARQ process functional entity. It can be situated in the
  • 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
  • Figure 17 shows the corresponding call flow in the case where the buffer is located in the CU.
  • 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).
  • 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.
  • 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.
  • the DU 200 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.
  • 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.
  • this buffer ID is 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 DU 200 process depicted in the flowchart of Figure 18 begins in step S202 with the DU receiving a TB from CU 300.
  • 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.
  • step S212 the DU 200 receives the ACK/NACK response from UE100.
  • 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
  • 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.
  • 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.
  • 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).
  • 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.
  • the process starts in S102 with the UE receiving a TB from the DU200.
  • 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.
  • this ACK/NACK information is different from conventional ACK/NACK because it is extended by addition of the buffer ID.
  • 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.
  • 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.
  • 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.
  • steps S106 to S116 are optional.
  • steps S120 and S122 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 .
  • 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.
  • the HARQ caching function 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:
  • 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.
  • the HARQ caching function can decide to cache the next TBs in the DU.
  • 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%.
  • TNL Transport Network Layer
  • SNMP stands for Simple Network Management Protocol.
  • 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
  • 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.
  • E2E End-to-End
  • 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.
  • Uftra-Refiable and Low Latency Communications (URLLC) services or slices need very quick retransmissions in order to reach their KPIs.
  • URLLC Low Latency Communications
  • the HARQ caching function wil be deployed in the DU no matter what the other criteria.
  • 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).
  • 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.
  • QoE Quality of Experience
  • the HARQ caching function can decide to use CU or DU caching for a given UE according to its CQI.
  • 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.
  • the invention can be applied to HARQ at any or all of the following levels:
  • the same CU may operate at more than one level at once.
  • 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.
  • “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:
  • NB-loT Narrow Band loT
  • FIG 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.
  • DSP digital signal processor
  • ASIC application-specific integrated circuit
  • FPGA field-programmable gate array
  • 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.
  • 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.
  • 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.
  • the controller is connected to the fronthaul FH and thereby to the CU 300.
  • FIG. 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
  • the computing device also includes a network adapter 999 for communication with other such computing devices of embodiments.
  • a network adapter 999 for communication with other such computing devices of embodiments.
  • an embodiment may be composed of a network of such computing devices.
  • 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.
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • DSP digital signal processor
  • network processor or the like.
  • 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.
  • 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.
  • computer-readable storage medium may accordingly be taken to include, but not be limited to, solid-state memories, optical media and magnetic media.
  • computer-readable media may include non-transitory computer-readable storage media, including Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable
  • EEPROM Electrically Programmable Read-Only Memory
  • CD-ROM Compact Disc Read-Only Memory
  • 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.
  • 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.
  • 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.
  • the UE examines the buffer ID in order to construct the RLC status report (see Figure 15, steps S1406 - S1409).
  • 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.
  • the DU retransmits each NACK PDU without including the buffer ID.
  • 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.
  • 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.
  • the DU may forward the RLC status report in unchanged form so that the CU has to make this determination for itself.
  • the fields of application of this invention includes ail wireless communications systems where ARQ, HARQ protocols or related re-transmission protocols are used.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé de commande et de définition dynamiques de la position et du comportement d'un tampon de retransmission ARQ ou HARQ lorsque la station de base est divisée physiquement en deux entités différentes qui sont physiquement séparées. Dans une architecture centralisée de RAN comprenant une division fonctionnelle entre une unité centralisée (CU, 300) pour les couches supérieures et une unité distribuée (DU, 200} pour les couches inférieures, reliées via une liaison fronthaul, la position du tampon de retransmission (dans la CU ou la DU) est critique pour la performance et l'efficacité, y compris la latence fronthaul et le débit minimal de données de trafic. La position optimale sera impactée par différents critères (le trafic, la qualité de liaison radio, des entrées de couche MAC, par exemple). Un procédé selon l'invention est apte à sélectionner la position optimale du tampon de retransmission conjointement avec la modification d'un en-tête de PDU RLC pour indiquer la position sélectionnée.
PCT/GB2017/052686 2016-09-30 2017-09-13 Arq et harq dans une communication sans fil 5g Ceased WO2018060674A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB1616682.9A GB2554661A (en) 2016-09-30 2016-09-30 HARQ in 5G wireless communication
GB1616682.9 2016-09-30
GB1621713.5 2016-12-20
GB1621713.5A GB2557960A (en) 2016-12-20 2016-12-20 ARQ in 5G Wireless communication

Publications (1)

Publication Number Publication Date
WO2018060674A1 true WO2018060674A1 (fr) 2018-04-05

Family

ID=59923473

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2017/052686 Ceased WO2018060674A1 (fr) 2016-09-30 2017-09-13 Arq et harq dans une communication sans fil 5g

Country Status (1)

Country Link
WO (1) WO2018060674A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108923892A (zh) * 2018-06-20 2018-11-30 南京中感微电子有限公司 一种蓝牙接收方法、蓝牙接收机及蓝牙音频设备
US10728826B2 (en) 2018-07-02 2020-07-28 At&T Intellectual Property I, L.P. Cell site routing based on latency
CN112751775A (zh) * 2020-12-30 2021-05-04 紫光展锐(重庆)科技有限公司 一种数据包的处理方法及相关装置
WO2022076996A1 (fr) * 2020-10-05 2022-04-14 Cohere Technologies, Inc. Ordonnancement et retransmission dans des unités centrales et des unités distribuées
US11533777B2 (en) 2018-06-29 2022-12-20 At&T Intellectual Property I, L.P. Cell site architecture that supports 5G and legacy protocols
CN116249155A (zh) * 2023-05-09 2023-06-09 北京大唐高鸿数据网络技术有限公司 一种信息传输方法、装置及用户设备
WO2025161516A1 (fr) * 2024-02-01 2025-08-07 华为技术有限公司 Procédé et appareil de communication

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1183616A1 (fr) * 2000-03-23 2002-03-06 Motorola, Inc. Procede et appareil fournissant un systeme de communications sans fil numerique a architecture distribuee
US20150043507A1 (en) * 2002-05-10 2015-02-12 Interdigital Technology Corporation Apparatus and method for prioritization of retransmission of protocol data units to assist radio link control retransmission
US20150103666A1 (en) * 2002-05-10 2015-04-16 Signal Trust For Wireless Innovation Cognitive flow control based on channel quality conditions

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1183616A1 (fr) * 2000-03-23 2002-03-06 Motorola, Inc. Procede et appareil fournissant un systeme de communications sans fil numerique a architecture distribuee
US20150043507A1 (en) * 2002-05-10 2015-02-12 Interdigital Technology Corporation Apparatus and method for prioritization of retransmission of protocol data units to assist radio link control retransmission
US20150103666A1 (en) * 2002-05-10 2015-04-16 Signal Trust For Wireless Innovation Cognitive flow control based on channel quality conditions

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Study on New Radio Access Technology; Radio Access Architecture and Interfaces (Release 14)", 3GPP STANDARD; 3GPP TR 38.801, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG3, no. V0.4.0, 13 September 2016 (2016-09-13), pages 1 - 36, XP051172437 *
NEC: "How many splits in Function Split options and principles", vol. RAN WG3, no. Göteborg; 20160822 - 20160828, 21 August 2016 (2016-08-21), XP051127546, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Meetings_3GPP_SYNC/RAN3/Docs/> [retrieved on 20160821] *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108923892A (zh) * 2018-06-20 2018-11-30 南京中感微电子有限公司 一种蓝牙接收方法、蓝牙接收机及蓝牙音频设备
US11533777B2 (en) 2018-06-29 2022-12-20 At&T Intellectual Property I, L.P. Cell site architecture that supports 5G and legacy protocols
US10728826B2 (en) 2018-07-02 2020-07-28 At&T Intellectual Property I, L.P. Cell site routing based on latency
WO2022076996A1 (fr) * 2020-10-05 2022-04-14 Cohere Technologies, Inc. Ordonnancement et retransmission dans des unités centrales et des unités distribuées
CN112751775A (zh) * 2020-12-30 2021-05-04 紫光展锐(重庆)科技有限公司 一种数据包的处理方法及相关装置
CN116249155A (zh) * 2023-05-09 2023-06-09 北京大唐高鸿数据网络技术有限公司 一种信息传输方法、装置及用户设备
CN116249155B (zh) * 2023-05-09 2023-08-04 北京大唐高鸿数据网络技术有限公司 一种信息传输方法、装置及用户设备
WO2025161516A1 (fr) * 2024-02-01 2025-08-07 华为技术有限公司 Procédé et appareil de communication

Similar Documents

Publication Publication Date Title
US11202279B2 (en) Method and apparatus for processing data in wireless communication system
US11646825B2 (en) Transmitting node, receiving node, methods and mobile communications system
WO2018060674A1 (fr) Arq et harq dans une communication sans fil 5g
KR102674850B1 (ko) Nr 시스템에서 mr-dc에 대한 단말 능력을 보고하는 방법 및 장치
US12028759B2 (en) Method and apparatus for performing handover procedure in wireless communication system
US8413002B2 (en) Method of performing ARQ procedure for transmitting high rate data
US20180262950A1 (en) Enhancement of pdcp status report
GB2557960A (en) ARQ in 5G Wireless communication
US10819416B2 (en) Apparatuses and methods for using ARQ processes in a relay device
KR20200023952A (ko) 이종 네트워크에서 이중 연결 동작을 수행하기 위한 방법 및 장치.
JP2019533377A (ja) トランスポートブロックにおける制御情報の効率的な多重化
EP3556135B1 (fr) Procédé et appareil de traitement de données dans un système de communication sans fil
ZA200405986B (en) Method for moving a receive window in a radio access network
KR102794422B1 (ko) 무선 통신 시스템에서 단말 능력을 보고하는 방법 및 장치
KR102506464B1 (ko) 무선 통신 시스템에서 지연 감소를 위한 패킷 전송의 제어 방법 및 장치
KR102801298B1 (ko) 차세대 이동통신 시스템에서 복수의 무선 전송 기법에 대한 단말 능력을 보고하는 방법 및 장치
US11240703B2 (en) Communications devices, method and mobile communications system
KR20160135766A (ko) 개선된 멀티-캐리어 통신을 위한 방법 및 장치
KR102788913B1 (ko) 무선 통신 시스템에서 통신을 수행하는 방법 및 장치
GB2554661A (en) HARQ in 5G wireless communication
WO2018028712A1 (fr) Procédé et dispositif pour traitement de données
WO2025156230A1 (fr) Procédé pour un nouveau type de transmission de données dans un réseau sans fil
KR20250114456A (ko) 무선 통신 시스템에서 혼잡을 제어하기 위한 전자 장치 및 방법
CN113439401A (zh) 用于传输具有多个自动重传请求进程的数据流的方法、装置和系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17771526

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17771526

Country of ref document: EP

Kind code of ref document: A1