Patent Description:
In certain communications networks, such as for example <NUM> networks, connections between baseband processing nodes and radio nodes, called fronthaul (FH) connections, may be packet-based, carrying time-sensitive data. Utilization of fronthaul communication links may fluctuate with the number of user equipments (UEs) being served. Additionally, fronthaul links may be shared between multiple baseband processing nodes and/or radio nodes. This can lead to unacceptable queueing (due to excessive traffic that may need to be transmitted simultaneously) or packet losses that have detrimental effect on radio performance.

<FIG> is a schematic of an example of a communications network <NUM>, such as for example a <NUM> network. The network <NUM> may also include other nodes (not shown). The network <NUM> includes three baseband processing units <NUM>, <NUM> and <NUM> (also called digital units, DUs), and three radio units (RUs) <NUM>, <NUM> and <NUM>. In other examples, the network may include any number of (one or more) DUs and any number of (one or more) RUs. The DUs and RUs may be connected via a packet-based fronthaul network <NUM> that includes a first switch <NUM> and a second switch <NUM> connected by a fronthaul link <NUM>. The network <NUM> may suffer from the queueing and packet loss problems illustrated above.

A fronthaul manager, such as for example a node or a packet processing function within a node, may be responsible among other things for determining packet priorities, managing queue sizes, and marking and/or dropping packets. It is aware of, or can estimate, available instantaneous capacity in the fronthaul network. It may also consider the fronthaul network's state when deciding what should be done with fronthaul data. One such decision may be to drop data (e.g. one or more fronthaul packets) due to, for example, limited fronthaul capacity. When this happens, data such as for example in a physical downlink shared channel (PDSCH) never reaches the UE, because it is never sent to the radio unit or is dropped by an intermediate network node. This in turn may trigger a hybrid automatic repeat request negative acknowledgement (HARQ NACK) from the UE, particularly if other transmissions have insufficient redundancy to compensate for the dropped data. Thus, there may be a loss of efficiency in the air interface.

There is known a document related to packet-switched fronthaul networks, namely <NPL>. However, devices and operations as in the invention now to be described are neither disclosed nor suggested in this document.

The following sets forth specific details, such as particular embodiments or examples for purposes of explanation, the scope of the invention is defined by the appended claims. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and/or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and/or using software programs and data in conjunction with one or more digital microprocessors or general-purpose computers.

One way to avoid the loss of efficiency of the air interface as described above is to limit the fronthaul load available to nodes to a fraction of its full capacity. This could be implemented for example with "negotiation rounds" between the radio scheduler (e.g. in a baseband processing node or digital unit) and a fronthaul manager. The scheduler (or a group of schedulers) could submit scheduling proposals to a fronthaul manager or fronthaul coordinating entity and receive feedback, such that the decisions could be modified until a feasible set of allocations is reached. This incurs additional latency between the base station and the UE, and timing requirements (e.g. for LTE or New Radio, NR/<NUM> traffic) may not be respected.

An alternative solution may be to introduce a fixed limitation on the amount of traffic a scheduler can schedule, in such a way that all nodes sharing fronthaul links will not exceed the fronthaul capacity. This scheme is suboptimal since it does not take into account dynamics of the air interface, number of UEs in each cell and other parameters. Therefore, it may result in under-utilization of fronthaul resources and cell capacity.

Embodiments of this disclosure include methods in which the radio scheduler (e.g. baseband processing unit or digital unit) is made aware that data may not reach a radio unit and cause the radio unit to make a transmission to at least one User Equipment (UE). This may be due to for example a packet drop by a fronthaul manager or switch. The radio scheduler may then employ actions to mitigate the efficiency loss in the air interface. These actions may involve, for example, (a) notifying the affected UE(s); (b) scheduling transmissions to utilize some of the lost transmission opportunities; and/or (c) configuring itself in preparation for the (expected) response from the affected UE(s), such as for example one or more HARQ NACKs.

<FIG> is a flow chart of an example of a method <NUM> of sending data using a packet-based interface to cause a radio unit to send transmissions to at least one UE. The method <NUM> may be performed in some examples by a radio scheduler, baseband processing unit, baseband processing network function, radio equipment controller, eCPRI radio equipment controller, distributed unit or digital unit. In some examples, the interface may comprise a common public radio interface, CPRI, or enhanced common public radio interface, eCPRI, and/or the data sent over the interface may include for example CPRI or eCPRI data.

The method <NUM> comprises, in step <NUM>, determining that a packet for causing the radio unit to send transmissions to a first user equipment, UE, in at least a portion of a time interval allocated to the first UE (e.g. a plurality of resource blocks allocated to the first UE) for transmissions to the first UE will not reach the radio unit. This may be due to, for example, the packet being dropped. Determining that the packet will not reach the radio unit may in some examples comprise receiving a notification from a controller of the packet based-interface or switch of the packet-based interface that the packet will not reach the radio unit (e.g. because the packet has been or will be dropped). In some examples, the notification identifies the packet and/or the at least a portion of the time interval, for example using a sequence number, MACsec packet number (Media Access Control Security defined in IEEE <NUM>. 1AE standard), time stamp and/or frame check sequence.

The method <NUM> also comprises, in step <NUM>, sending at least one further packet to the radio unit (e.g. using the packet-based interface) to cause the radio unit to send transmissions to a second UE in at least part of the time interval (e.g. using at least some of the resource blocks allocated to the first UE).

<FIG> shows an example of timings for scheduled transmissions and actual transmissions in a communications network. <FIG> shows scheduled transmissions <NUM>, for example that were scheduled before step <NUM> of <FIG>, i.e. before a node such as a scheduler has determined that a packet will not reach a radio unit. The horizontal axis represents time. Also shown are actual transmissions, e.g. as a result of steps <NUM> and <NUM> of the method <NUM>. As shown in <FIG>, a time interval <NUM> is allocated for transmissions to a first UE (in some examples, the time interval <NUM> may comprise one or more time slots). However, the scheduler may determine (e.g. be informed) that a fronthaul packet may not reach the radio interface. As a result, transmissions to the first UE scheduled for a portion <NUM> of the time interval will not be transmitted to the first UE. The scheduler may determine that the fronthaul packet may not reach the radio interface at any appropriate time, such as for example during the time interval <NUM>, before the time period <NUM>, at the start of the time portion <NUM>, or even during the first part of the time portion <NUM> (e.g. during time td).

Due to the time-sensitive nature of fronthaul communications, it may not be possible to send a replacement packet to the radio unit to cause the radio unit to make the dropped transmissions to the first UE in the portion <NUM> of the time interval. However, there may be sufficient time to send one or more packets to the radio unit to cause the radio unit to send transmissions to a second UE in at least part of the time interval <NUM>. For example, transmissions may be sent to the second UE in a part <NUM> of the portion <NUM> of the time interval <NUM>. Due to timing constraints, it may not be possible to cause the radio unit to send transmissions to the second UE for all of the portion <NUM> of the time interval, though if data is sent to the radio unit quickly enough, e.g. within a time period td shown in <FIG>, transmissions may be sent to the second UE in a remaining portion <NUM> of the portion <NUM> following the time period td. In some examples, transmissions may also be sent to the second UE also during the remainder of the time interval <NUM> that was originally allocated for transmissions only to the first UE. This may be useful for example in embodiments where a HARQ NACK is expected from the first UE corresponding to the entire time interval <NUM>, due to the dropped transmissions in the portion <NUM> of the time interval. In such cases, it may not be useful to transmit to the first UE in the time interval following the portion <NUM> as it may be assumed that the first UE will reject (due to the NACK) the transmissions for the whole of the time interval <NUM>.

In some examples, which may include receiving a notification from a controller of the packet based-interface or switch of the packet-based interface that the packet will not reach the radio unit, the controller or switch may be co-located with an entity performing the method. For example, the controller or switch may be within the same apparatus as the entity (which is for example a scheduler), or may be in adjacent or nearby apparatus. As a result, for example, the notification may be provided to the entity quickly. If the entity performing the method <NUM> is informed quickly, for example, then the further packet(s) may be sent to the radio unit more quickly. As a result, more of the portion <NUM> of the time interval <NUM> may be utilized for transmissions to the second UE, which may result in lower degradation of efficiency of the air interface.

In some examples, sending the at least one further packet to the radio unit to cause the radio unit to send transmissions to the second UE in at least part of the time interval comprises sending the at least one further packet to the radio unit to cause the radio unit to send transmissions to the second UE in at least a sub-portion of the portion of the time interval. The sub-portion may comprise for example the part <NUM> of the portion <NUM> of the time interval, as shown in <FIG>.

Subsequent to the transmissions sent to the first UE and the second UE, the method may comprise receiving a hybrid automatic repeat request acknowledgement, HARQ ACK, or negative acknowledgement, NACK, associated with the at least part of the time interval from the second UE and a HARQ NACK associated with the at least a portion of the time interval from the first UE. The HARQ NACK may be expected from the first UE because of the disruption to the transmissions to the UE in the portion <NUM> of the time interval. In some examples, the HARQ ACK or NACK from the second UE and the HARQ NACK from the first UE are received simultaneously. As a result, the NACK from the first UE may interfere with the HARQ response from the second UE. However, in some examples, the knowledge that the response from the first UE will be a NACK may be used to improve reception of the HARQ response from the second UE, for example using interference cancellation techniques.

The transmissions to the first UE in the at least a portion of a time interval may in some examples comprise physical downlink shared channel, PDSCH, transmissions. Additionally or alternatively, in some examples, the transmissions to the second UE in the at least part of the time interval comprise PDSCH transmissions. However, in other examples the transmissions to either UE may comprise other types of transmissions.

In some examples, the method <NUM> may comprise, before determining that the packet will not reach the radio unit, preparing transmissions to at least one further UE including the second UE. Then, sending at least one further packet to the radio unit to cause the radio unit to send transmissions to the second UE in at least part of the time interval may comprise selecting the prepared transmissions to the second UE. This may for example reduce the time needed to prepare the transmissions to the second UE, and hence may allow a longer period for transmissions to the second UE. For example, this may allow greater utilization of the portion <NUM> of the time period for transmissions to the second UE.

In some examples, the method <NUM> may comprise, after determining that the packet will not reach the radio unit, causing the radio unit to send a notification to the first UE that there will be no transmissions to the first UE in the at least a portion of the time interval. Informing the first UE in this manner (e.g. using downlink control information, DCI) may allow the UE to take certain actions. For example, the UE may decide that transmissions to the first UE in the time interval <NUM> preceding the portion <NUM> may have been successfully received, and these transmissions received by the first UE may be stored by the first UE (e.g. in a soft buffer). This may in some examples aid in reception of a later retransmission of data that would have been sent to the first UE during the time interval <NUM>, as at least part of the retransmission may be combined with the stored earlier transmissions.

<FIG> shows an example of communications in a network <NUM>, for example during a particular example implementation of a method of sending data using a packet-based interface to cause a radio unit to send transmissions to at least one UE. The network includes a gNodeB <NUM> that may be a distributed gNodeB. The gNodeB comprises a digital unit (DU) <NUM> that includes a scheduler and a fronthaul (FH) manager. The gNodeB <NUM> also includes a fronthaul (e. g fronthaul interface) and a radio unit (RU). The network <NUM> also includes a first UE (UE A) and a second UE (UE B). A method may include the following method steps, which correspond to steps and communications shown in <FIG>.

In some examples, the New Radio (NR) preemption indicator (for example using DCI format <NUM>-<NUM>, as defined in 3GPP TS <NUM><NUM>. <NUM>, release <NUM>. <NUM>, <NUM>-<NUM>) can be used to inform the affected UE(s) what part of their PDSCH is compromised by the FH packet drop. This may help mitigate efficiency loss, since the UE(s) can flush only that part of the soft buffer that corresponds to parts of the PDSCH that were not transmitted, and the unaffected regions of the PDSCH might still be decoded correctly, increasing the chance that a single retransmission (incremental redundancy) will be sufficient for successful reception and decoding of the whole PDSCH.

In some examples, to mitigate the air interface efficiency loss, the scheduler can assign at least some of the affected resource blocks (e.g. those reserved or allocated to the first UE for the portion of the time interval) to one or more other UEs (e.g. step <NUM> in <FIG>). That is, for example, a large block of resource blocks could be interrupted and substituted by a smaller number of resource blocks in order to respect fronthaul limitations, even prior to most of the traffic leaving the baseband. In NR, for example, this could be done with downlink preemption and in some examples a "mini-slot" (e.g. PDSCH Type B transmission, as illustrated in 3GPP TS <NUM><NUM>. In this nonlimiting example, only UE B is selected for this reduced size transmission e.g. reduced size PDSCH. This decision and subsequent transport of the relevant PDSCH data for UE B (e.g. steps <NUM>-<NUM> in <FIG>) may in some examples be sufficiently fast to allow transmission by the radio unit before the initially scheduled PDSCH for UE A is over. There may be a tradeoff between how much time the FH manager takes to respond and how much resources can be reused. In some examples, the FH manager is in the same hardware node as the FH traffic source, e.g. scheduler (this may be the case, for example, when high performance computing platforms are used to implement virtualized baseband processing units).

To avoid costly searches in limited time, the scheduler (e.g. digital unit, etc) can keep a table of opportunistic transmissions, ranked by e.g. mini-slot (or part of the time interval) size/duration, such that when a drop notification arrives and the scheduler identifies that UE A's transmission will be affected, it could quickly select which opportunistic transmission fits the remainder of this compromised PDSCH for UE A. This "overbooking" of RBs can be used for example for expediency of the scheduling, meaning that the scheduler can react quickly to the drop notification.

In the case of virtualized applications mentioned above, the concept of "drops" may in some examples be extended to cover also the erasing of PDUs from a shared memory region used by the NIC (Network Interface Controller) to store packets prior to transmission, for example where the NIC is shared by multiple virtualized nodes in the same hardware node. It is entirely possible that packets carrying data for a certain user are identified in some examples. That is, there is a mapping between a transmission to a certain UE and the packets it occupies in fronthaul. This mapping might exist as a header field, or any other type of implementation-dependent indicator and can be used to drop on a "decision" basis instead of a packet basis.

In some examples, FH managers may not be within the same hardware node as a traffic source (scheduler, digital unit etc) but instead in an immediately adjacent switch, and hence may also be co-located with the traffic source, for example in the same hardware cabinet or at the same location or premises. Additionally or alternatively, in some examples, fronthaul traffic could be encrypted using e.g. MACsec. In this case, there can be no reliance on the actual contents of the packets, since the payload would not be visible to the FH manager. Instead, a notification from the FH manager may allow the scheduler to identify which flow has been compromised, and this can be done using for example a sequence number, MACsec packet number, timestamp or frame check sequence (plus a table lookup), which MACsec does not obscure.

Even though at least some of the data for UE A will never reach the RU due to one or more dropped packets, the RU effectively transmits a compromised PDSCH that UE A might not be able to fully decode (e.g. steps <NUM> and <NUM> in <FIG>). UE A is then likely in some examples to transmit a HARQ NACK corresponding to at least some of the time interval reserved for the PDSCH transmissions. In some examples, the scheduler can simply ignore the NACK from UE A (e.g. steps <NUM> and <NUM> in <FIG>). Alternatively, the scheduler may use the knowledge that a NACK is expected from UE A to aid in decoding (step <NUM> in <FIG>) the corresponding PUCCH (or PUSCH when the feedback is multiplexed with data). Additionally or alternatively, in some examples, the feedback (ACK/NACKs) of UE B could be multiplexed with the feedback of A in PUCCH.

In examples disclosed herein, the scheduler is used as the traffic source and the PDSCH is the transmissions to UEs A and B. However, other types of transmissions and/or other traffic sources may be used.

<FIG> is a schematic of an example of apparatus <NUM> for sending data using a packet-based interface to cause a radio unit to send transmissions to at least one UE. The apparatus <NUM> comprises processing circuitry <NUM> (e.g. one or more processors) and a memory <NUM> in communication with the processing circuitry <NUM>. The memory <NUM> contains instructions executable by the processing circuitry <NUM>. The apparatus <NUM> also comprises an interface <NUM> in communication with the processing circuitry <NUM>. Although the interface <NUM>, processing circuitry <NUM> and memory <NUM> are shown connected in series, these may alternatively be interconnected in any other way, for example via a bus.

In one embodiment, the memory <NUM> contains instructions executable by the processing circuitry <NUM> such that the apparatus <NUM> is operable to determine that a packet for causing the radio unit to send transmissions to a first user equipment, UE, in at least a portion of a time interval allocated to the first UE for transmissions to the first UE will not reach the radio unit, and send at least one further packet to the radio unit to cause the radio unit to send transmissions to a second UE in at least part of the time interval. In some examples, the apparatus <NUM> is operable to carry out the method <NUM> described above, or the method described above with reference to <FIG>.

One embodiment of a network implementing the solution disclosed in this document is illustrated in Figure <NUM>. The network, <NUM>, comprises an apparatus, <NUM>, for sending data using a packet-based interface to cause a radio unit to send transmissions to at least one UE. The apparatus may be in one embodiment a baseband processing unit, <NUM> (also called digital units, DUs). The apparatus comprises a processor, <NUM>, and a memory, <NUM>, the memory containing instructions executable by the processor such that the apparatus is operable to determine, <NUM>, that a packet for causing the radio unit to send transmissions to a first user equipment, UE, in at least a portion, <NUM>, of a time interval, <NUM>, allocated to the first UE for transmissions to the first UE will not reach the radio unit. When executing the instructions, the apparatus, <NUM>, is further operative to send at least one further packet to the radio unit to cause the radio unit to send transmissions to a second UE in at least part, <NUM>, <NUM>, of the time interval, <NUM>. The network, <NUM>, with DUs, <NUM> - <NUM>, is configured to operate in accordance with embodiments of the method described above.

Claim 1:
A method (<NUM>) performed by an apparatus, wherein the apparatus comprises a packet-based interface, the method comprising:
receiving a notification from a controller of the packet based-interface or from a switch of the packet-based interface (<NUM>), wherein the notification indicates that a packet for transmission by a radio unit to a first user equipment, UE, in at least a portion (<NUM>) of a time interval (<NUM>) allocated to transmissions to the first UE has been dropped or will be dropped; and
sending (<NUM>) at least one further packet to the radio unit, wherein the at least one further packet indicates the radio unit to send transmissions to a second UE in at least part (<NUM>, <NUM>) of the time interval.