Processing packets in a fronthaul network

Abstract

A method of processing packets received from two or more radio units (120a-1, 120a2) in a fronthaul network (100). The method comprises receiving the packets (440, 540u) into a common buffer (555) and transmitting the packets (440) from the common buffer to a baseband unit (110, 320); and sending at least one flow control instruction (442, 557) to at least one of the radio units (120a-1) to prevent reception of packets into the common buffer from the at least one of the radio units (120a- 1).

Description

[0001] Processing packets in a fronthaul network

[0002] Technical Field

[0003] The present disclosure relates to processing packets to and / or from radio units in a fronthaul network.

[0004] Background

[0005] In Radio Access Networks (RAN), Radio Units (RU) are typically connected to local or remote Baseband Units (BBU) by means of transport links (e.g. optical fibers) carrying 10G, 25G, 50G and future higher rates - known as the Fronthaul. If the RU and the BBU are co-located, the architecture is considered as a Distributed RAN (D-RAN), if they are dislocated (typically at a distance up to 20km) the architecture is considered as a Centralized RAN (C-RAN).

[0006] Optical modules in Fronthaul equipment are very sensitive to temperature which poses challenging constraints for RU designs which are aiming to provide enclosures as compact as possible. RU are often deployed in outdoor scenarios, such as mounted on poles, or at the top of buildings or towers. In such scenarios, the RU can be exposed to weather and outdoor environmental conditions. For this reason, the RU are typically installed within enclosures designed to protect them against the weather and environmental conditions they may experience. For example, the enclosures may be designs to IP65 standards or greater. In some situations, such enclosures are camouflaged to respect the local rules for deployment in urban environments.

[0007] When RU are installed within such an enclosure, the internal temperature of the RU can reach high temperatures. For example, the RU may reach a temperature above 85 degrees Celsius. In particular, such internal temperatures can be reached when the RRU is installed within an enclosure in an environment where the temperature can reach or exceed 50 degrees Celsius, even for short periods.

[0008] Normally, the RU to be installed within such enclosures are designed to be fan-less. However, even when a fan is present, the optical modules, e.g. pluggable optical modules, installed in the radio unit may not benefit from any airflow. Furthermore, the optical modules are typically positioned close to other high temperature components of the radio units, such as the power supply and its dissipaters, which can further increase the temperature of the optical modules. The use of processors for switching packets also adds to the footprint and power supply requirements.

[0009] Due to fiber scarcity and fiber costs, multiple Fronthaul interfaces or ports may be multiplexed over a single fiber using WDM lambda multiplexing in the optical domain. In some cases, this allows a single fiber to support more than one RU, for example where two or more RU are co-located. Here, one RU coupled to the single fiber may interface with an allocated Fronthaul interface or port whilst acting to cascade other Fronthaul interfaces to downstream RU. To enable this, the RU coupled to the optical fiber from the BBU may be configured to convert optical signals corresponding to the Fronthaul ports into electrical signals which are internally processed to separate the Fronthaul port allocated to the RU. The other Fronthaul ports may then be re-packaged for transmission to downstream RU via other optical fibers using respective optical modules.

[0010] BBU are typically deployed in Central Offices and aggregate traffic from many RU and therefore tend to be equipped with high capacity eCPRI Ethernet interfaces (50G, 100G and future 400G). They are also typically locally deployed as a single BBU at Distributed RAN (DRAN) sites where the number of physical ports limits the amount of connected RU without adding a Fronthaul switch at the site. The RU are typically deployed in outdoor environment with considerable temperature variations and have a lower capacity to manage traffic. For this reason, their eCPRI ports are typically at lower rates with respect to the BBU. This mismatch between capacity of the BBU and RU either limits utilization of the optical fiber or in packet switched networks, requires network switching which adds to complexity, cost, footprint and heating.

[0011] The introduction of eCPRI allows to interconnect C-RAN and Cloud RAN nodes via Ethernet instead of using TDM technologies such as CPRI and allows for the introduction of Packet Fronthaul networks. It also enables “multiplexing” of multiple radios on a single BBU port applicable for DRAN and CRAN deployments. eCPRI enables compressing of CPRI data and of using Ethernet ports that can be switched in a packet switched network serving a C- RAN, Cloud RAN network or local switching at a DRAN site.

[0012] Whilst this increases flexibility, most of the C-RAN and Cloud RAN networks are based on point-to-point (P2P) or point-to-multi-point (P2MP) connections for many reasons including fiber constraints and the limited extension of the Fronthaul networks (<20km); the sensitivity of eCPRI and PTP protocols to packet jitter and delay variations, and the unavailability of overbooking in eCPRI.

[0013] Summary

[0014] According to an aspect of the present disclosure, there is provided a method of processing packets received from two or more radio units in a fronthaul network. The method comprises receiving the packets into a common buffer and transmitting the packets from the common buffer to a baseband unit, and sending at least one flow control instruction to at least one of the radio units to prevent reception of packets into the common buffer from the at least one of the radio units.

[0015] According to another aspect of the present disclosure, there is provided a method of processing packets in a fronthaul network. The method comprises in response to receiving an Ethernet frame from a baseband unit, determining a non-address tag in the Ethernet frame and forwarding the Ethernet frame to one of two or more radio units depending on the non-address tag.

[0016] According to another aspect, there is provided a method of processing evolved Common Public Radio Interface, eCPRI, packets for transmission to two or more radio units in a fronthaul network. The method comprises transmitting Ethernet frames addressed to the two or more radio units from a common port, the Ethernet frames carrying the eCPRI packets, wherein the Ethernet frames comprise a non-address tag dependent on the radio unit to which the respective Ethernet frame is addressed.

[0017] These methods advantageously simplify the physical connection of optical fibers within a fronthaul network, whilst minimizing additional circuitry or processing required which in turn reduces heating of critical components such as optical modules. This in turn reduces power requirements and enables greater flexibility using the available physical fiber and connections as well as improving the utilization of these assets.

[0018] There is also provided corresponding apparatus such as adapters and BBU as well as computer programs.

[0019] To avoid unnecessary duplication of effort and repetition of text in the specification, certain features are described in relation to only one or several aspects or embodiments of the invention. However, it is to be understood that, where it is technically possible, features described in relation to any aspect or embodiment of the invention may also be used with any other aspect or embodiment of the invention.

[0020] Brief Description of the Drawings

[0021] For a better understanding of the present invention, and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the accompanying drawings, in which:

[0022] Figure 1 is a schematic view of a radio access network (RAN) according to an example;

[0023] Figure 2 is a schematic view of a radio unit (RU) and adapter assembly according to an example;

[0024] Figure 3 illustrates downstream packet flow according of an example;

[0025] Figure 4 illustrates upstream packet flow according to an example;

[0026] Figure 5 is a schematic view of an adapter according to an example;

[0027] Figure 6 illustrates a method of processing packets according to an example;

[0028] Figure 7 illustrates a method of processing packets according to another example; and

[0029] Figure 8 is a schematic view of a baseband unit according to an example.

[0030] Detailed Description

[0031] Examples of the present disclosure propose methods for processing packets in a Fronthaul network and adapters for facilitating cascading of Radio Units (RU) in a Radio Access Network (RAN) using optical fibers to couple the RU to a Baseband Unit (BBU). Example adapters may additionally or alternatively be used to couple multiple ports of one RU to a BBU, which may be used when individual RU ports have lower capacity than that available via the optical fiber. These methods and adapters simplify the physical connection of the optical fibers with the RU whilst minimizing additional circuitry or processing required which in turn reduces heating of critical components such as optical modules. The adapter can be in the form of a small outdoor dongle with low power requirements and which enables greater flexibility using the available physical fiber and connections as well as improving the utilization of these assets.

[0032] Figure 1 is a schematic view of a RAN according to an example. The RAN 100 comprises a core node 105 coupled to a number of BBU 110, some of which may be co-located in a pool 112 of BBU. The core node 105 may be provided in a central office and enable interconnection with other networks, such as the Internet. The BBU 110 are coupled to RU 120a-1 , 120b via optical fiber 150. The RRU 120a-1 , 120b may be mounted on a pole 115a, 115b having an antenna and other equipment. In some cases, more than one RRU 120a-1 , 120a-2 may be co-located as shown. An adapter according to an example may be employed to facilitate physical connection of optical fibers between RU and BBU as well as between RU and other RU.

[0033] Figure 2 is a schematic view of a RU and an adapter according to an example. The illustrated arrangement 200 comprises a RU 220 connected to an adapter 230 which terminates an optical fiber from a BBU and an optical fiber from another RU port. The other RU port may be another port on the same RU or an RU port on another RU (RU2), such as the second co-located RU 120a-2 of Figure 1 .

[0034] The RU 220 comprises radio and digital signal processing circuitry 224, radio frequency amplifying and receiving circuitry 226, and power circuitry 228. The power circuitry provides power for the other circuitry 224, 226, as well as the adapter 230 via a standard connection, such as an MSA connector. The RF amplifying and receiving circuitry 226 is coupled to an antenna and is configured to amplify radio frequency (RF) signals to be transmitted from the antenna and to amplify RF signals received by the antenna. The radio and digital signal processing circuitry 224 is configured to convert between baseband and RF signals and to process baseband and control signals. The radio and digital processing circuitry 224 is coupled to the adapter 230 via an electrical signal connection such as an MSA plug and socket / cage.

[0035] The adapter 230 converts between the optical and electrical domains to enable communication between the RU and the BBU or other RU ports via optical fiber. The adapter 230 may comprise one or more optical modules or transceivers to convert between optical and electrical signals. The optical modules may be implemented as standardized small form-factor pluggable transceivers (SFP) and the adapter assembly 230 may comprise internal SFP cages for installing SFP optical modules. In some examples, quad small formfactor pluggable transceivers (QSFP) may be employed. SFP, QSFP or other types of optical modules may be implemented for handling WDM (wave division multiplex) optical signals or Grey optical signals. Bidirectional modules may use different wavelengths for uplink and downlink over the same optical fiber. Optical modules may be used for converting between WDM and Grey optical signals within the adapter assembly in some examples.

[0036] Figures 3 and 4 illustrate how an adapter 330 may be configured to process packets received from a BBU and / or from two or more RU according to examples. Figure 3 illustrates a downlink processing example where packets 340 are received from the BBU 310. In some examples, the packets are Ethernet frames which are carried over an optical link having optical modules 346 at the BBU and adapter ends. The Ethernet frames 340 may carry eCPRI packets towards one of two or more RU 320a-1 , 320a-2, with the Ethernet frames addressed to the MAC address of the respective RU. Alternatively or additionally, the Ethernet frames 340 may carry a synchronization message to maintain adequate timing synchronization between the equipment of the fronthaul network. The synchronization message may be a Precision Timing Protocol (PTP) packet, carrying a PTP timestamp for example, which is added when the PTP packet is transmitted.

[0037] According to one example, the Drop Eligible Indictor (DEI) bit of each Ethernet frame header is set to 1 (S) by the BBU if the Ethernet frame 340 is addressed to one of the RU (RU2) 320a-2 and is set to 0 (N) by the BBU if the Ethernet frame 340 is addressed to the other RU (RU1) 320a-1. The adapter 330 is configured to read the DEI bit of each Ethernet frame 340 and forward the frame 340-N to the first RU 320a-1 if DEI=0 (N or not set) or to forward the frame 340-S to the second RU 320a-2 if DEI= 1 (S or set). Alternatively, the bits may be set in the reverse way depending on the configuration of the adapter 330.

[0038] In this way, the DEI bit acts as a non-address tag which is used by the adapter 330 to forward the packet to the intended RU. This means that the adapter does to need to read the Ethernet destination MAC address nor act as an Ethernet switch and so requires less processing, lower power and avoids the need to learn and maintain a routing table. In some examples, the simple nonaddress tag based forwarding may be implemented using a low cost, small footprint ASIC implementing simple interrogation and forwarding logic whilst only requiring low power. This may be paired with a small simple downlink buffer as described below, and which buffer receives the packets and from which the packets are forwarded. Such an implementation may be advantageously applied as a dongle for connection with an outdoors RU.

[0039] The DEI bit is not used in point-to-point (P2P) links and therefore is readily available for use as a non-address tag in optical fronthaul networks where two RU are addressed by the BBU in a P2P manner. Other unused header bits may alternatively be used. For example one or more bits of the Priority Code Point (PCP) field or unused proprietary bits. The use of more than one bits allows for more than two RU to be addressed in a P2P manner over the same optical fiber between the BBU and the adapter, with the additional RU being cascaded from multiple adapters as described in more detail below. For example, the use of 3 bits for the non-address tag allows for up to 7 cascaded RU.

[0040] In some examples, the adapter 330 may be physically connected to an RU 320a-1 such that packets 340-N with one value of non-address tag (e.g. N or 0) are forwarded via that connection or “drop” port to the connected RU. Packets 340-S with another value of non-address tag (e.g. S or 1) are forwarded via another “cascade” port to another RU via a connected optical fiber. In some examples, the adapter may be configured to forward packets 340 received from the BU 310 towards three or more RU. For example, two bits of the PCP field may be used to discriminate between four RU. When PCP = 0, the packet may be forwarded to the local connected RU via a drop port, with all other values being forwarded to a cascade port. A downstream adapter connected the cascade port and to a second RU then forwards packets to the second RU when PCP = 1 , otherwise packets with other values of PCP are forwarded to a cascade port of the downstream adapter which is then connected to a further downstream adapter, also connected to a third RU. This further downstream adapter is configured to forward packets with PCP = 3 to the connected third RU and packets with other PCP values are forwarded to its cascade port which is connected to a fourth RU. This is just one example implementation and different numbers of bits and different coding of those bits for tagging packets corresponding to respective RU may be employed.

[0041] Advantages of these examples include low power consumption, reduced heating, smaller size, reduced cost, reduced processing requirements and lower or no control and maintenance traffic overhead. The examples also allow for increased utilization of the optical fiber assets. Typically, the BBU port may be paired with a lower capability port on the RU side, for example 50G verses 25G, which means the link is limited to 25G. By utilizing the adapter, the full 50G may be used to carry packets for two RU which are only capable of 25G. This means that traffic demand for both RU may be provided on the spoke or link between the BBU and adapter without exceeding the line rate (no overbooking), even though the two RU have lower capability. This is achieved without the need for Ethernet switching in the adapter, or an RU, which provides the above noted advantages. In addition, the examples do not require any modification of the RU. This arrangement can also be scaled up to more than two RU, for example by using a 100G link between BBU and adapter, with each of four RU being connected at 25G. Other examples are possible, such as one RU at 25G, another at 50G and yet another at 75G with the BBU to adapter link operating at 200G. These examples are non-limiting and many other configurations are also possible. Figure 4 illustrates uplink processing where packets 440 are received from an RU 320a-1 and forwarded to the BBU 310. As with the downlink configuration, the packets may be Ethernet frames. The Ethernet frames 440 may carry eCPRI packets towards the BBU, with the Ethernet frames addressed to the MAC address of the BBU. Alternatively or additionally, the Ethernet frames 440 may carry a synchronization message to maintain adequate timing synchronization between the equipment of the fronthaul network. The synchronization message may be a Precision Timing Protocol (PTP) packet, carrying a PTP timestamp for example.

[0042] The packets 440 may be received by the adapter 330 into an uplink or common buffer as described in more detail below. The received packets may then be forwarded to the BBU 310 in a first-in-first-out (FIFO) order. In some modes of operation, the adapter 330 may be configured to restrict or prevent the reception of packets from one of the RU 320a-2 by sending a flow control instruction 442 to that RU 320a-2. An example flow control instruction 442 is an Ethernet PAUSE packet which causes the recipient device to pause transmitting packets. This means that packets are subsequently only received from the other RU 320a-1 which is not receiving the PAUSE packets.

[0043] This configuration is useful when processing synchronization messages such as PTP packets sent by the RU. If a PTP packet from one RU 320a-1 is received into the buffer when there is already one or more packets received into the buffer from the other RU 320a-2, this will cause jitter by delaying transmission of the PTP packet to the BBU. This in turn will affect the synchronization of the various equipment in the fronthaul network. By preventing reception of packets from one of the RU 320a-2, PTP or other timing or synchronization related packets received from the other RU 320a-1 will be received into an empty or reduced fill buffer so that transmission to the BBU is not significantly delayed; thereby significantly reducing jitter and improving fronthaul network synchronization accuracy.

[0044] In one example, the PAUSE packets may be sent continuously and alternatively to the RU, to RU1 , then RU2, then RU1 and so on. This ensures that there are no packets in the buffer when a PTP packet arrives. This results in no or minimal jitter, at the expense of reduced uplink capacity which is not an issue in this eCPRI based fronthaul application. In another example, such as with a fixed one-packet length buffer, PAUSE packets may only be sent if a PTP packet is received from either RU. For example if a PTP packet is received from RU1 a PAUSE packet is sent to RU2, and vice versa. In this case the outgoing packet can still be delivered as the PTP packet will reach the end of the FIFO queue after a fixed delay equivalent to the maximum packet length. The other RU (e.g. RU2 when the PTP packet is received from RU1) is paused so that other packets cannot be received before the PTP packet is transmitted. This approach still achieves significant reduction in jitter whilst maintaining uplink capacity.

[0045] Prevention of transmission of packets from one of the RU 320a-2 may be continued by periodically sending flow control instructions 442. In this example, when the sending of flow control instructions is stopped, the RU 320a-2 may then begin transmitting packets again so that packets from both RU 320a-1 and 320a-2 are received into the common buffer of the adapter. The adapter may be configured to switch between sending one or more flow control instructions to a first of the RU 320a-1 and receiving packets only from a second of the RU 320a-2, then switching to sending one or more flow control instructions to the second of the RU 320a-2 and receiving packets only from the first of the RU 320a-1 . This then allows each of the two RU to alternatively transmit PTP packets toward the BBU without jitter.

[0046] In some examples, the adapter 330 may be configured to send flow control instructions to both RU until the common buffer reaches a predetermined state such as being empty or containing a certain number of packets, such as only one packet. Upon reaching the predetermined state, the adapter may be configured to stop sending flow control instructions to one RU in order to begin receiving packets from that RU, but continuing to send flow control instructions to the other RU to prevent reception of packets from that RU. This further improves jitter by ensuring reduced delay in the adapter when transmitting packets to the BBU which it has received from one of the RU.

[0047] In other examples as noted above, the adapter is configured to send at least one flow control instruction to an RU in response to receiving a packet from another RU. For example, when a PTP packet is received from RU2 a PAUSE packet is sent to RU1.

[0048] In some examples, the common or uplink buffer and a downlink buffer of the adapter have a common length and / or a common transit time. This is advantageous when handling synchronization messages such as PTP packets. A same or similar jitter in the uplink and downlink direction improves the accuracy of the PTP synchronization process.

[0049] In some examples, this uplink approach may be applied with more than two RU. In this case, flow control instructions are sent to all but one RU to allow packets, such as PTP packets, to be received from only that one RU. Another RU may then be allowed to send packets by sending flow control instructions to the other RU. In this way, the RU that is allowed to send packets may be changed whist all other RU are blocked from sending packets. This may allow PTP packets from each RU in turn to be sent without or with minimal jitter.

[0050] In some examples, the adapter 330 may implement only one of the downlink or uplink packet handling processes. In other examples, both uplink and downlink packet handling processes may be implemented.

[0051] These examples provided a number of advantages including being implementable using an ASIC and simple buffer having low power consumption, reduced heating, smaller size, reduced cost, reduced processing requirements and lower or no control and maintenance traffic overhead. As with the downlink process, the examples allow for increased utilization of the optical fiber assets with multiple RU sharing the same fiber link between the adapter and BBU. This includes accommodating BBU and RU using different traffic rates without reducing capacity and without the use of external switches. At the same time, synchronization of all of the fronthaul equipment may be achieved by using this low jitter approach, providing improved accuracy. In addition, the examples do not require any modification of the RU. This approach can be enabled or disabled as required, depending on the need for PTP on the RU involved.

[0052] Figure 5 is a schematic of an adapter according to an example. The adapter 530 comprises processing hardware 550 coupled between two optical modules 535-1 , 535-2 and a connector 537. The connector 537 can be seen as a local or drop port which is adapted to physically connect with a port of an RU 520 and may comprise another optical module or an electrical connector. The connector 537 may also provide a power supply connection with the RU 520, when connected. The optical modules may be any suitable component for converting between optical and electrical signals, such as SPF25 or SPF50 devices as previously described. The optical modules 535-1 and 535-2 are connected respectively to a cascade port 533-1 coupled to another RU and a common port 533-2 coupled to a BBU.

[0053] The processing hardware 550 includes a downlink buffer 554, a DEI tag reader function 553 downlink forwarding logic 552, an uplink or common buffer 555, uplink control logic 556, and a PAUSE packet sending function 557. These may be implemented using separate a processor 558 and memory 559 or using an ASIC with onboard buffers.

[0054] In the downlink direction, packets or Ethernet frames 546d from a BBU are received via the common port 533-2 into the downlink buffer 554. The Ethernet frames 540d may carry eCPRI packets 560 or PTP packets for example. The DEI tag reader function is configured to determine the value of the DEI bit 562 in the header of the Ethernet frames 540d. The downlink forwarding logic 552 is configured to forward the packet in the buffer 554 to the drop port 537 or the cascade port 533-1 depending on the value of the DEI. The drop 537 and cascade 533-1 ports are coupled to different RU so the received packets are forwarded to one of these RU depending on this non-address tag, without having to read the destination Ethernet or MAC address of the packet.

[0055] In the uplink direction, packets such as Ethernet frames 540d from both of the RUs are received into the common or uplink buffer 555 via the local or drop 537 and cascade 533-1 ports. These packets are then transmitted to the BBU via the common port 533-2. When required, for example when the Ethernet frames are carrying PTP packets, the uplink control logic 556 is configured to determine which RU to receive packets from and instructs the send PAUSE packets function 557 to send PAUSE packets to the other RU. The uplink control logic 556 may initially instruct the send PAUSE packets function to send such packets to both RUs until the uplink buffer reaches a predetermined state, such as being empty. At that point, the uplink control logic may instruct the send Pause packets function to stop sending such packets to the selected RU so that it can being sending its packets which are then received into an empty or nearly empty buffer. These packets are then transmitted to the BBU via the common port 533-1 with a minimum of delay, resulting in low jitter and improved accuracy when the packets carry PTP packets.

[0056] The uplink control logic 556 may then be configured to swap RU by instructing the send PAUSE packets function 557 to stop sending such packets to the currently blocked RU and instead send such packets to the other RU. Blocking of one RU following by blocking of the other RU may be implemented for a predetermined time according to the requirements of the PTP. The blocking or pausing of RU may be implemented alternatively and continuously as previous described. In other examples, the pausing of RU may be implemented in response to reception of a PTP packet from another RU as previously described. In some example, the PTP packets are always transmitted before any other packets waiting in the buffer.

[0057] Once the required synchronization process has been completed, the uplink control logic may revert to a non-synchronization mode in which PAUSE packets are not sent so that packets from both RU are received into the uplink buffer 555 and forwarded onto the BBU in a FIFO order.

[0058] In some examples, the uplink buffer 555 may have a size of a single packet in order to minimize the transmission delay between reception into the buffer 555 and transmission to the BBU. In some examples, the downlink buffer 554 may be of the same size or length as the uplink buffer 555. Additionally or alternatively, the downlink buffer 554 may have the same transit time as the uplink buffer 555. These configurations improve the symmetry of packet transmission times through the adapter which improves PTP accuracy.

[0059] The send PAUSE packets function 557 may be configured to send Ethernet PAUSE packets or frames, for example as defined in IEEE 802.3 which describes an Ethernet flow control mechanism using PAUSE frames. Ethernet PAUSE frames were introduced for congestion management and to avoid data loss in Ethernet based networks. However, the inventors have recognized that these same PAUSE frames may be employed in a noncongestion context in the present examples to reduce jitter associated with PTP packets and other time sensitive uplink traffic. As already described, this is achieved by using the PAUSE packets to pause transmission of packets from one or more RU in a fronthaul network in order to reduce the transit time through the adapter for time sensitive packets from another of the RU. This novel use of PAUSE frames allows for examples to be implemented without having to modify the RU as these will already have the required packet transmission pausing functionality associated with receiving PAUSE frames.

[0060] In some examples, alternative flow control instructions may be employed.

[0061] In alternative arrangements, the adapter may be configured to process different non-address tags such as PCP bits or other reserved Ethernet header bits.

[0062] Figure 6 illustrates a method of processing downlink packets in a fronthaul network, according to an example. The method 600 may be implemented by a processor 558 such as an ASIC, and is arranged to forward packets received from a BBU to one of two RU.

[0063] At 605, the method receives an Ethernet packet, for example into a downlink buffer. At 610, the method reads the DCI bit in the header of the received Ethernet packet. As previously described, this bit may be used as a nonaddress tag in order to direct the packet to one of two RU. In other examples, different header bits or fields may be used, such as PCP bits, which may be used to direct the packet to one or more than two RU.

[0064] At 615, the method determines whether the DCI bit is “1” (i.e. set) in which case the method moves to 620. Otherwise, if the DCI bit is “0” (i.e. not set), the method moves to 625. At 620, the method transmits the packet to a predetermined one of the RU (RU2). At 625, the method transmits the packet to the other of the two RU (RU1). In this way, the method does not need to read the destination address of the packet.

[0065] Figure 7 illustrates a method of processing uplink packets in a fronthaul network, according to an example. The method 700 may be implemented by a processor 558 such as an ASIC, and is arranged to forward packets received from two RU (RU-1 , RU-2) to a BBU.

[0066] At 705, the method sends a PAUSE packet to RU-2. This may be an Ethernet PAUSE packet as previously described, however any suitable flow control instruction may be used. The method may be started at the beginning of a PTP synchronization procedure.

[0067] At 710, the method receives Ethernet packets carrying PTP timestamps from RU-1 . The PAUSE packet sent to RU-2 prevents RU-packets from RU-2 being received. The packets received from RU-1 may carry PTP timestamps which are quickly transmitted to the BBU with minimal delay, due to a lack of packets being received from RU-2.

[0068] At 715, the method determines whether to switch to receiving packets from RU-2. This may be determined based on the expiry of a predetermined time period over which RU-2 has been blocked in order to only allow reception of packets from RU-1. If it is appropriate to switch, the method moves to 720, otherwise the method returns to 705. In some examples, the switching may be configured to occur after one packet time so that the pausing of RU toggles between RU after every time frame in which a packet may have been received. A PAUSE frame may be sent to a non-paused RU as soon as a packet has started to be received from that RU. This will have the effect that the active RU only sends one packet at a time, following which it will receive a PAUSE frame. As previously described, this minimizes jitter.

[0069] At 720, the method sends PAUSE packets to RU-1. This then prevents reception of packets from RU-1 as well as RU-2.

[0070] At 725, the method determines whether the common or uplink buffer has reached a predetermined state. The predetermined state may be a certain fill level such as one packet, or empty. If the predetermined state has not yet been reached, the method returns to 720 where it continues to send PAUSE packets to RU-1 . Otherwise, if the predetermined state of the buffer has been reached the method moves to 730.

[0071] At 730, the method stops sending PAUSE packets to RU-2 which restores the ability of PU-2 to send packets. At 740, the method continues to send PAUSE packets to RU-1 to prevent packets being received from this device. At 745, the method receives Ethernet packets carrying PRP timestamps from RU-2. The method is then able to quickly forward those received packets to the BBU with minimal delay.

[0072] At 750, the method determines whether to switch back to receiving packets from RU-1 . This may be based on the same conditions as previously described with respect to 715.

[0073] At 755, the method sends PAUSE packets to RU-2 which prevents reception of packets from RU-2 as well as RU-1 . At 760, the method determines whether the common or uplink buffer has reached the predetermined state. If not, the method returns to 755 where it continues to send PAUSE packets to RU-2. Otherwise, the method moves to 765.

[0074] At 765, the method stops sending PAUSE packets to RU-1 to allow reception of packets again from this RU. The method then returns to 705 where the process continues until stopped. In some examples, as previously described, the method may continue indefinitely with the paused RU toggling the two or more RU. In other examples, as previously described, the method may only be implemented in response to receiving a PTP packet.

[0075] Figure 8 illustrates a baseband unit (BBU) according to an example. The baseband unit 810 comprises a processor 874 and memory 876 containing processor readable instructions 878. The BBU 810 may be running a first baseband (BB) process 815-1 which is communicating with a first radio unit (RU-1 ) by sending Ethernet frames 840 addressed to RU-1 . The BBU 810 may also be running a second baseband process 815-2 which is communicating with a second radio unit (RU-2) by sending Ethernet frames 840 addressed to RU-2. The two sets of Ethernet frames 840 are sent via a common port 872 along the same optical fiber towards the two RU. The common port 872 may be an optical module such as an SPF50 for example.

[0076] In order to enable a downstream adapter to use non-address tags to discriminate between these Ethernet frames, the instructions 876 implement a function 870 to update the DEI bit of the Ethernet frames, depending on which BB process they originate and / or which RU they are addressed to.

[0077] Using the first instruction 882, the BBU is configured to set the DEI=1 for Ethernet frames from BB process 2 and to set DEI=0 for Ethernet frames from BB process 1 . Alternatively or additionally, the DEI value may be set based on the destination MAC address of the Ethernet frame 840.

[0078] Using instruction 884, the BBU is configured to transmit Ethernet frames from both BB processes 1 and 2 from the common port 872.

[0079] Therefore, with a small modification to the software of the BBU, this may be configured to interwork with adapters as previously described in order to provide the various functionality and advantages previously described. No modification of the RU is required, and the adapter may be implemented as a simple dongle connected to one of the RU as well as the optical fiber links to the BBU and the other RU.

[0080] Automatic detection of an adapter function and configuration of the downlink traffic non-address tagging from the BBU to each RU may be performed based on the initial assignment of a management IP address when the RU boots up. The following detection steps may be used:

[0081] RU-A (with or without adapter)

[0082] - RU-A boots and request an IP address (DHCP discover)

[0083] - BBU DHCP server sends DHCP offer (normal DEI=0)

[0084] - RU-A sends DHCP request for offered IP address

[0085] - BBU DHCP server sends DHCP ACK

[0086] RU-B (with adapter)

[0087] - RU-B boots and request an IP address (DHCP discover)

[0088] - BBU DHCP server sends DHCP offer (normal DEI=0) o RU-B will not respond (packet forwarded to RU-A by adapter but wrong MAC address, dropped by RU-A)

[0089] - Short Time-out in BBU DHCP server (alternative wait for next time RU- B sends a new DHCP discover) - BBU DHCP server sends DHCP offer (DEI=1) o RU-B will now see the message (forwarded to RU-B by adapter)

[0090] - RU-B sends DHCP request for offered IP address

[0091] - BBU DHCP server sends DHCP ACK (DEI=1) o forward to RU-B by M PE

[0092] - BBU sets policy to associating Radio MAC B with DEI= 1

[0093] All traffic from baseband to RU-A will now use destination MAC A with DEI=0 and all traffic to RU-B will now use destination MAC B to use DE I = 1 .

[0094] The DHCP process is a control plane software function and the DEI (Drop Eligibility indicator) non-address tagging based on destination MAC is a hardware policy function.

[0095] Whilst the examples have been described in the context of the adapters connecting to RU ports, they may also be used with other types of telecommunications equipment. Examples include Radio Processor Units and FWA (fixed wireless access) systems.

[0096] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

Claims

CLAIMS1 . A method of processing packets received from two or more radio units in a fronthaul network, the method comprising: receiving the packets into a common buffer and transmitting the packets from the common buffer to a baseband unit; sending at least one flow control instruction to at least one of the radio units to prevent reception of packets into the common buffer from the at least one of the radio units.

2. The method of claim 1 , comprising receiving packets from the baseband unit into a second common buffer and transmitting the packets from the second common buffer to one of the radio units; wherein the first and second common buffers comprise one or more of the following: a common length; a common transit time,3. The method of claim 1 or 2, comprising sending at least one flow control instruction to one of the radio units in response to receiving a packet from said radio unit.

4. The method of any one preceding claim, comprising switching between sending at least one flow control instruction to one of the radio units and sending at least one flow control instruction to another of the radio units in order to receive packets from the respective radio units at different times.

5. The method of claim 4, comprising sending at least one flow control instruction to both of the radio units prior to the switching, until the common buffer reaches a predetermined state.

6. The method of claim 5, wherein the predetermined state is one or more of the following: empty; containing at least one packet.

7. The method of claim 5 or 6, wherein upon the common buffer reaching the predetermined state, the sending of flow control instructions to a first radiounit is stopped and the sending of flow control instructions to a second radio unit is continued in order to receive packets from the first radio unit but not the second radio unit.

8. The method of any one preceding claim, wherein the packets are Ethernet frames and the flow control instructions are Ethernet PAUSE frames.

9. The method of claim 8, wherein the Ethernet frames carry one or more of the following: evolved Common Public Radio Interface, eCPRI, packets; a synchronization message.

10. The method of claim 9, wherein the synchronization message is a Precision Timing Protocol, PTP, timestamp.

11. The method of any one of claims 8 to 10, wherein the packet is an Ethernet frame which is forwarded to the baseband unit based on a nonaddress tag in the Ethernet frame.

12. The method of claim 11 , wherein the non-address tag is one or more of the following: a Drop Eligible Indicator, DEI, bit of a header of the Ethernet Frame; a Priority Code Point, PCP, bit of a header of the Ethernet Frame.

13. A method of processing packets in a fronthaul network, the method comprising: in response to receiving an Ethernet frame from a baseband unit, determining a non-address tag in the Ethernet frame and forwarding the Ethernet frame to one of two or more radio units depending on the non-address tag.

14. The method of claim 14, wherein the non-address tag is one or more of the following: a Drop Eligible Indicator, DEI, bit of a header of the Ethernet Frame; a Priority Code Point, PCP, bit of a header of the Ethernet Frame.

15. The method of claim 13 or 14, wherein the Ethernet frames carryevolved Common Public Radio Interface, eCPRI, packets.

16. A method of processing evolved Common Public Radio Interface, eCPRI, packets for transmission to two or more radio units in a fronthaul network, the method comprising: transmitting Ethernet frames addressed to the two or more radio units from a common port, the Ethernet frames carrying the eCPRI packets; wherein the Ethernet frames comprise a non-address tag dependent on the radio unit to which the respective Ethernet frame is addressed.

17. The method of claim 16, wherein the non-address tag is one or more of the following: a Drop Eligible Indicator, DEI, bit the Ethernet Frame; a Priority Code Point, PCP, bit of a header of the Ethernet Frame.

18. A computer program comprising instructions which, when executed on a processor, cause the processor to carry out the method of any one of claims 1 to 17.

19. A computer program product comprising non transitory computer readable media having stored thereon a computer program according to claim 18.

20. An adapter for a radio unit in a fronthaul network, the adapter comprising: a common buffer arranged to receive packets from two or more radio units; a processor arranged to transmit the packets from the common buffer to a baseband unit; the processor arranged to send at least one flow control instruction to at least one of the radio units to prevent reception of packets into the common buffer from the at least one of the radio units.21 . The adapter of claim 20, comprising a second common buffer arranged to receive packets from the baseband unit and the processor is arranged totransmit the packets from the second common buffer to one of the radio units; wherein the first and second common buffers comprise one or more of the following: a common length; a common transit time.

22. The adapter of claim 20 or 21 , wherein the processor is arranged to send at least one flow control instruction to one of the radio units in response to receiving a packet from said radio unit.

23. The adapter of any one of claims 20 to 22, wherein the processor is arranged to switch between sending at least one flow control instruction to one of the radio units and sending at least one flow control instruction to another of the radio units in order to receive packets from the respective radio units at different times.

24. The adapter of claim 23, wherein the processor is arranged to send at least one flow control instruction to both of the radio units prior to the switching, until the common buffer reaches a predetermined state.

25. The adapter of claim 24, wherein the predetermined state is one or more of the following: empty; containing at least one packet.

26. The adapter of claim 24 or 25, wherein upon the common buffer reaching the predetermined state, the processor is arranged to stop sending flow control instructions to a first radio unit and to continue to send of flow control instructions to a second radio unit in order to receive packets from the first radio unit but not the second radio unit.

27. The adapter of any one of claims 20 to 26, wherein the packets are Ethernet frames and the flow control instructions are Ethernet PAUSE frames.

28. The adapter of claim 27, wherein the Ethernet frames carry one or more of the following: evolved Common Public Radio Interface, eCPRI, packets; a synchronization message.

29. The adapter of claim 28, wherein the synchronization message is a Precision Timing Protocol, PTP, timestamp.

30. The adapter of any one of claims 27 to 29, wherein the packet is an Ethernet frame which is forwarded to the baseband unit based on a nonaddress tag in the Ethernet frame.31 . The adapter of claim 30, wherein the non-address tag is one or more of the following: a Drop Eligible Indicator, DEI, bit of a header of the Ethernet Frame; a Priority Code Point, PCP, bit of a header of the Ethernet Frame.

32. An adapter for a radio unit in a fronthaul network, the adapter comprising: a processor arranged to determine a non-address tag in an Ethernet frame received from a baseband unit; the processor arranged to forward the Ethernet frame to one of two radio units depending on the non-address tag.

33. The adapter of claim 32, wherein the non-address tag is a Drop Eligible Indicator, DEI, bit of a header of the Ethernet Frame.

34. The adapter of claim 32 or 33, wherein the Ethernet frames carry evolved Common Public Radio Interface, eCPRI, packets.

35. A baseband unit for a fronthaul network, the baseband unit comprising: a processor (874) arranged to add non-address tags to Ethernet frames addressed to two radio units, the Ethernet frames carry evolved Common Public Radio Interface, eCPRI, packets; wherein the non-address tags are dependent on the radio unit to which the Ethernet frame is addressed; a transmitter arranged to transmit the Ethernet frames from a common port.

36. The baseband unit claim 35, wherein the non-address tag is a DropEligible Indicator, DEI, bit the Ethernet Frame.

37. The baseband unit of claim 35 or 36, wherein the transmitter comprises an optical electrical module.

38. A frounthaul network comprising two or more of: an adapter according to any one of claims 20 to 31 ; an adapter according to any one of claims 32 to 34; a baseband unit according to claim 35 or 36.

Images