Patent Application
20250106683
This patent application is directed to a fronthaul analyzer, and more specifically, to an analyzer of packet traffic flow on an Open Radio Access Network (O-RAN) fronthaul link between an O-RAN-Distributed Unit (O-DU) and an O-RAN-Radio Unit (O-RU), in which the fronthaul analyzer includes an integrated impairment generator that may generate impairments on packet traffic flows to mimic real world O-RAN transmission scenarios.
Presently, cellular telephony technology is developing and adopting the Open Radio Access Network (O-RAN) standards, which may provide interoperability that may enable multiple cellular network/communication protocols/types and the products of multiple vendors to work together in the same network. O-RAN standards focus on openness (open source software, hardware interoperability/open interfaces, flexible deployment in a disaggregated multi-vendor/multi-tech architecture), intelligence (incorporating artificial intelligence (AI) into the deployment, operation, and maintenance of the network and using software-defined implementations of wireless communications and networking functions), and virtualization (in order to decouple legacy entities and layers, thereby enabling the interoperability, flexibility, disaggregation, and heterogeneity of the O-RAN environment).
Features of the present disclosure are illustrated by way of example and not limited in the following Figure(s), in which like numerals indicate like elements, in which:
For simplicity and illustrative purposes, the present disclosure is described by referring mainly to examples and embodiments thereof. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be readily apparent, however, that the present disclosure may be practiced without limitation to these specific details. In other instances, some methods and structures readily understood by one of ordinary skill in the art have not been described in detail so as not to unnecessarily obscure the present disclosure. As used herein, the terms “a” and “an” are intended to denote at least one of a particular element, the term “includes” means includes but not limited to, the term “including” means including but not limited to, and the term “based on” means based at least in part on.
Analyzers/testers may be used to test, analyze, and evaluate both the hardware and the software of the components operating in a cellular communication network that implements the O-RAN standards. In examples of the present disclosure, a real-time O-RAN fronthaul (FH) analyzer (FHA) provides real-time hardware analysis, processing, and measurement and/or real-time continuous generation of analysis, measurements, statistics, etc., of an O-RAN FH link between at least one O-RAN Distributed Unit (O-DU) and at least one O-RAN Radio Unit (O-RU). As used herein in reference to an O-RAN FHA according to examples of the present disclosure, the terms “real-time” or “in real time” refer to an O-RAN FHA according to examples of the present disclosure performing the processing, functions, and/or actions within roughly a nanosecond of receipt at the O-RAN FHA of the frame and/or packet upon which the processing, functions, and/or actions performed, e.g., from about 0.5 nanosecond to about 1.5 milliseconds after receipt.
Some advantages and benefits of the systems and methods for a real-time O-RAN FHA according to examples of the present disclosure are described, while other benefits and advantages may also be apparent to anyone of ordinary skill in the art. For instance, a real-time O-RAN FHA according to examples of the present disclosure may provide real-time analysis, processing, and measurement of the O-RAN fronthaul link in hardware, rather than (and/or in addition to) post-processing in software of captured packets/frames from the O-RAN fronthaul link. Accordingly, a user may perform “live” analysis in real-time on a running O-RAN fronthaul link.
The O-RAN FHA disclosed herein may include an integrated impairment generator to selectively generate impairments on packet traffic that flow through the O-RAN FHA. Particularly, the impairment generator may generate impairments to emulate impairments that may occur during real world transmission scenarios on an O-RAN fronthaul link. In other words, the O-RAN FHA disclosed herein may include an impairment generator that selectively generates impairments on the packet traffic flow between an O-DU and an O-RU or between multiple O-DUs and multiple O-RUs.
As discussed herein, the O-RAN FHA may include a Parser that may parse packets in packet traffic flows received from an O-DU and/or an O-RU and may determine types of packets in the received packet traffic flows. The Parser may also output the parsed packets to a hardware packet analyzer and the impairment generator. The Parser may set action bits for the packets in the packet traffic flows that are to receive impairments and the impairment generator may generate impairments on the packets in the packet traffic flows based on the action bits. The impairments may include at least one of a packet traffic flow latency modification, one or more dropped packets in the packet traffic flow, a modification to an order of the packets in the packet traffic flow, and/or the like.
Through implementation of features of the present disclosure, an O-RAN FHA may include both an impairment generator that may generate impairments in packet traffic flows and a packet analyzer that may analyze packets. In one regard, a separate impairment generator may not be employed during the testing of an O-RAN fronthaul link, which may reduce the number of components employed in the testing process. In another regard, the integration of the impairment generator into the O-RAN FHA may enable fine-grained testing of the O-RAN fronthaul link. Particularly, for instance, the features of the present disclosure may enable testing of specific types of packet flows, e.g., C-plane packet flows, U-Plane packet flows, S-Plane packet flows, and M-plane packet flows. As a result, a technical improvement afforded through implementation of features of the present disclosure may be that the accuracy of O-RAN fronthaul links may be improved, which may result in more efficient and accurate testing.
In examples of a real-time O-RAN FHA according to the present disclosure, packet analysis may be performed/implemented in parallel in hardware, rather than serially in post-processing by software reading and accessing captured frames/packets. Accordingly, packet analysis may be faster. In examples of a real-time O-RAN FHA according to the present disclosure, low level analysis of packet traffic flow over the O-RAN fronthaul link may be performed/implemented in hardware for continuous real-time processing, rather than (and/or in addition to) being performed by after-the-fact post-processing in software of captured packets/frames from the O-RAN fronthaul link. Accordingly, when a user performs live analysis in real-time on a running O-RAN fronthaul link, the live analysis may be continuously generated and/or updated in real-time as environmental/system changes occur.
In
In the design of the O-RAN architecture, which is in harmony with the 5G New Radio (NR) RAN architecture defined by the 3GPP, the O-CU 110, the O-DU 120, and the O-RU 140 may be responsible for delivering the diverse functions of the radio protocol stack associated with the Radio Resource Control (RRC), Service Data Adaption Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Protocol (RLC), and the Ethernet Medium Access Control (MAC) and physical (PHY) layers.
The O-RU 140 may integrate antenna elements with radio processing components, such as transceivers, analog beamformers, and power amplifiers, by which the O-RU 140 may use its RF antenna 145 to establish a PHY layer connection with the UE 160. In addition to the RF processing, the O-RU 140 integrates the lower level PHY layer processing (Low PHY), such as digital and/or analog beamforming, the fast Fourier transform (FFT)/inverse-FFT (i-FFT) processing, Cyclic Prefix (CP) addition, Digital-Analog Conversion, IQ Compression/Decompression, etc. The O-RU 140 communicates with the O-DU 120 over the O-RAN FH link 130.
As would be understood by one of ordinary skill in the art, although labelled a “link” herein, the O-RAN FH link 130 may take any number of forms, including a network or a cloud. Moreover, the O-RAN FH link 130 may use Ethernet as a transport mechanism (i.e., the Institute of Electrical and Electronic Engineers (IEEE) Standard 802.3 (IEEE 802.3)), as it does in the present disclosure, but the O-RAN FH link 130 may also use the Internet Protocol (IP), the Internet Engineering Task Force (IETF) Request for Comments (RFCs) 791 & 2460, and the User Datagram Protocol (UDP), IETF RFC 768, in addition to Ethernet, or in place thereof. When using Ethernet, the payload of the Ethernet frame may contain a further transport header and payload, which encapsulation may be indicated in the EtherType field of the Ethernet frame header. O-RAN allows for multiple different headers within the Ethernet payload to further describe how the data may be handled, including the evolved Common Public Radio Interface (eCPRI) transport header. For further details, see, e.g., Sect. 5 of the Control, User, and Synchronization Plane Specification of O-RAN Working Group 4 (O-RAN.WG4.CUS.0-R003-v12.00), which is hereby incorporated by reference herein in its entirety (hereinafter referred to as “the O-RAN FH C/U/S-Plane standard”).
As would be understood by one of ordinary skill in the art, although
Referring to
As shown in
As also shown in
According to examples, the impairment generator 152 may emulate packet impairments in the packet traffic flow transmitted and/or received over an O-RAN fronthaul link 130. In other words, the impairment generator 152 may model real world transmission scenarios such as fixed latency, Packet Delay Variation (PDV), jitter, etc., into packets in the packet traffic flows. The impairments may include at least one of a packet traffic flow latency modification, one or more dropped packets in the packet traffic flow, a modification to an order of the packets in the packet traffic flow, and/or the like. Thus, for instance, and as discussed in greater detail herein below, the impairment generator 152 may receive packets in the packet traffic flow between the O-DU 120 and the O-RU 140 and may generate impairments on packets in selected packet traffic flows.
The determination as to which of the packet traffic flows are to receive impairments may be dependent upon the types of the packets in the packet traffic flow, the directions in which the packets are flowing (from the O-DU 120 to the O-RU 140 or from the O-RU 140 to the O-DU 120), etc. In addition, a user may control the types of the packets that are to receive the impairments via a software interface and the impairment generator 152 may operate through software as discussed in greater detail herein.
The user may make the selection through a software interface (not shown), e.g., a graphical user interface, on which packet traffic flow information may be presented to the user. The user may also select/input the type of impairment, e.g., a packet delay to be applied to the packets in a packet traffic flow, and the magnitude of the impairment, e.g., the length of the packet delay to be applied to the packet traffic flow. The selection may be coded into a ternary content-addressable memory (TCAM) by software and a Parser (or a Programming Protocol-independent Packet Processor (P4) that may include a Parser) may set an action bit for the particular packet as enabled. For instance, the software may code values corresponding to the packet and the impairment to be applied into the impairment generator 152. Once the impairment generator 152 receives this packet along with the enabled action bit, the impairment generator 152 may insert the impairment, e.g., delay or drop the packet, based on the selected actions. In some examples, the user may select a number of simultaneous flows and impairments that may be generated and applied on the flows.
The Synchronization Plane (S-Plane) 204 and the Management Plane (M-Plane) 206 are so-called “slow protocols,” carrying less packet traffic than the C/U-Plane. The S-Plane 204 periodically sends timing and synchronization messages using the Precision Timing Protocol (PTP) to synchronize the O-RU 140 to the rest of the network. See, e.g., the O-RAN FH C/U/S-Plane standard; and PTP (IEEE 1588), which is hereby incorporated by reference in its entirety. The M-Plane 206 contains non-real-time traffic (which, as such, has no especially strict timing parameters), carrying non-real-time management and configuration Network Configuration Protocol (NETCONF) and Yet Another Generation (YANG) (NETCONF/YANG)-based operations. See, e.g., Management Plane Specification of O-RAN Working Group 4 (O-RAN.WG4.MP.0-R003-v12.00), which is hereby incorporated by reference herein in its entirety (hereinafter referred to as “the O-RAN FH M-Plane standard”); IETF RFC 5277, IETF RFC 6241, IETF RFC 6242, IETF RFC 6470, IETF RFC 8071, IETF RFC 7951, and IETF RFC 8639, all of which are hereby incorporated by reference in their entireties.
Although typically contained/encapsulated in Ethernet frames, as mentioned above, the C/U/S/M-Plane packets may have their own typically used protocols. The C/U-Plane 200/202 packets may use eCPRI/Radio over Ethernet (RoE) headers/messages/protocols; the S-Plane 204 may use PTP; and the M-Plane 206 may use NETCONF/YANG headers/messages/protocols.
As shown in
Most timing parameters may be identified with reference to these reference points, or to the letters and/or numerals of these reference points. For example, the DL delay may be T12, the UL delay may be T34, with further qualifications such as, e.g., T12 min and T12max indicating the minimum and maximum DL delays. As other examples, Tla may indicate the delay from the O-DU DL output (R1) to transmission over the air (Ra); T2a may indicate the delay from the O-RU DL input (R2) to transmission over the air (Ra); T3a may indicate the delay from (receiving) the transmission over the air (Ra) to the O-RU UL output port (R3); and T4a may indicate the delay from (receiving) the transmission over the air (Ra) to the O-DU UL input port (R4). Additional details may be found in the O-RAN FH C/U/S-Plane standard.
It is the relationships between the timing parameters on the O-RAN FH link 130 that are particularly stringent, not necessarily the individual parameters themselves. For example, it may be more important that packets in the traffic flow arrive within a particular reception window and transmit within a particular transmission window than individual packets arriving and departing at specific times. Moreover, because of new complexities and complications in developing 5G/6G cellular communication, such as, e.g., numerology, where the size and shape of any particular symbol may be different among the packet flows, and beamforming, both the necessity of keeping to precise transmission/reception windows may be more important and the ability to measure the important timing and other parameters may be more difficult (as discussed further below).
More specifically, and as an example, it takes some amount of time for the sender to transmit the packets in either direction (DL/UL) over the transmission media. However, the amount of data for any interval (e.g., symbol) can vary thus resulting in differing transmit times. This transmission time can be affected by several factors including (but not limited to) transport media rate, air interface bandwidth, and amount of data compression. The maximum amount of time allowed for the transmitter to send all data for an interval (transmission window) is defined by T1amax−Tamin. This is the allowed time, based on transport and O-RU characteristics, and its impacts on O-DU's is explained in clause 4.4.1.2 of the O-RAN FH C/U/S-Plane standard. To account for transport variation and transmission time, the receiver similarly implements a reception window. This allows packets containing samples for a specific symbol to be received within the window and still be transmitted at Ra at the time specified in the O-RAN standards.
The size of the reception window may account for both the maximum transmission time at the sender and the transport variation through the O-RAN fronthaul network. The result is the first of the delay relationships in the O-RAN FH C/U/S-Plane standard that may be met to ensure a working delay solution (see Table 4.4.2.1-1 et seq.), where T2amax−T2amin is the DL reception window, T1amax−Tiamin is the DL transmission window, T4amax−T4amin is the UL reception window, T4amax−T4amin is the UL transmission window, while T12max−T12 min is the allowed DL transport variation and T34max−T34 min is the allowed UL transport variation. The above description is only of some specific examples, the full range and details of windows and other higher-level timing parameters which are to be met by a working O-RAN fronthaul link are detailed in, inter alia, the O-RAN FH C/U/S-Plane standard, the O-RAN FH M-Plane standard, and the O-RAN FH IoT standard. As used herein, the term “analytical timing measurements” may include, for example, any parameter, measurement, quantity, and/or quality discussed, described, and/or identified in any of the O-RAN standards.
At least because O-RAN is predicated upon, inter alia, providing standards/specifications for the successful interoperability between the O-DU 120 and the O-RU 140 on the O-RAN FH link 130 so that different telecommunication systems may be implemented by using various components from multiple vendors, the timing details, parameters, and tolerances of the communications on the O-RAN FH link 130 may also have standardized, industry-wide testing parameters to guarantee workability, many of which are described and detailed in the O-RAN FH C/U/S-Plane standard, the O-RAN FH M-Plane standard, and the O-RAN FH IoT standard. Accordingly, the O-RAN FH IoT standard lists and details test configurations, parameters, the O-RAN standards, including, e.g., the O-RAN FH C/U/S-Plane standard, the O-RAN FH M-Plane standard, and the O-RAN FH IoT standard, list and detail test configurations, parameters, measurements, etc., which may be used to prove the interoperability of any O-DU 120 with any other O-RU 140 over any O-RAN FH link 130.
For instance, the O-RAN FH IoT standard describes many tests for each of the C/U-Plane (sect. 2.2.3), the S-Plane (sect. 2.2.2), and the M-Plane (sect. 2.2.1) by the FHA, as well as appropriate testing tools and parameters. Moreover, other components and instruments may be used with the FHA to perform these tests, such as an O-CU emulator (including, e.g., 5G NR O-CU emulator), a network core emulator, an evolved Node B (eNB) emulator (including, e.g., a 4G LTE Master eNB (MeNB) or other MeNB emulator), an UE testers/emulator, optional beamforming network equipment, an Application Test Server, an RF Spectrum and/or Beam Signal Analyzer, and O-RU emulator, a flow traffic emulator, etc., as discussed at, e.g., Sect. 2.1.1.3 of the O-RAN FH IoT standard. As would be understood by one of ordinary skill in the art, the various examples in the present disclosure may be intended for use (and to be compliant) with both present, currently planned, and future testing protocols of the O-RAN FH IoT standard. See, e.g., Sect. 1.2.3 of the O-RAN FH IoT standard (“Future Enhancements”). However, as would also be understood by one of ordinary skill in the art, the various examples in the present disclosure are not in any limited by the present or future O-RAN FH IoT standard, but may be used for many other types of testing.
As mentioned above, there are multiple challenges with testing the O-RAN FH link 130, some but not all of which are discussed herein. Despite providing an intensive description of what is to be tested, the O-RAN standards provide no guidance on how to perform those tests, including how to create instrumentalities to provide such testing results. Moreover, previous telecommunication link analyzers provide limited guidance to creating such testing instrumentalities as some of the O-RAN testing parameters may be new and unique in detail and implementation to the O-RAN FH link 130, which effectively divides what was once a single component and layer (the PHY layer) into two components and two sub-layers (and the upper PHY layer for the O-DU and the lower PHY layer for the O-RU), thereby requiring relatively tight timing tolerances between the two (to at least match the overall timing of the previously-single device/component).
Presently, at least partially because of the new and novel nature of the O-RAN FH link 130 and its requirements, many who attempt to perform O-RAN FH link 130 testing have struggled to build their own ad hoc software and hardware for such testing. As far as is known, most instrumentalities that perform O-RAN FH link 130 testing use a capture method, where a snapshot of the O-RAN FH link 130 traffic flow may be captured (i.e., recorded/stored) in hardware and then analyzed, after the fact, usually in software (i.e., post-processing). Because of the tight timing and speed of the traffic flow on the O-RAN FH link 130, such instrumentalities may not be able to handle the traffic flow, becoming quickly overwhelmed by the flood of packets, even before the software may be able to perform any type of analysis. Furthermore, even with instrumentalities that perform O-RAN FH link 130 testing using the capture method, many parts of the analysis and processing required for O-RAN FH link 130 analysis may be performed sequentially, thereby delaying the analysis and processing in general. Furthermore, analysis of a snapshot does not take into consideration packets outside of the snapshot which may be outside tolerances.
As mentioned above, examples of a real-time O-RAN FHA 150 according to the present disclosure provide real-time analysis, processing, and measurement in hardware of the O-RAN FH link 130, rather than (and/or in addition to) post-processing in software of captured packets/frames from the O-RAN FH link 130. In examples of a real-time O-RAN FHA 150 according to the present disclosure, packet analysis may be performed/implemented in parallel in hardware, rather than serially in post-processing by software reading and accessing captured frames/packets. In examples of a real-time O-RAN FHA 150 according to the present disclosure, low level analysis of packet traffic flow over the O-RAN FH link 130 may be performed/implemented in hardware for continuous real-time processing, rather than (and/or in addition to) being performed by after-the-fact post-processing in software of captured packets/frames from the O-RAN FH link 130.
In
In some examples, the O-RAN FHA HW 300 may include a hardware accelerator. As used herein, a “hardware accelerator” may be any group of programmable logic blocks with reconfigurable interconnects, such as, e.g., a Programmable Logic Device (PLD) and/or Programmable Read-Only Memory (PROM), and may include an Application-Specific Integrated Circuit (ASIC), a programmable gate array, a Field Programmable Gate Array (FPGA), and/or Configurable Logic Blocks (CLBs) with Lookup Tables (LUTs), Reconfigurable Acceleration Devices (RADs), or the like, and may have one or more soft processor cores, one or more hard processor cores, one or more general purpose Advanced Reduced Instruction Set Computer (RISC) Machine (ARM) core processors, one or more vector processors, one or more memories, one or more inputs and/or outputs, one or more memory controllers, one or more Networks-on-Chip (NoCs) to provide a pervasive system-wide network, one or more network controllers, one or more network interfaces, and/or one or more transceivers, as would be understood by one of ordinary skill in the art. In some examples, the hardware accelerator may include an FPGA and associated peripherals, such as, e.g., one or more Double Data Rate (DDR) memories, one or more clocks, one or more Phase-Locked Loops (PLLs), etc., as would be understood by one of ordinary skill in the art.
An overview of the traffic flow through the O-RAN FHA HW 300 in
As shown in
The Counter 360 may maintain a clock using, for example, incoming S-Plane PTP packets from a PTP master at the O-DU 120 (routed to the Counter 360 by the Parser 320, discussed further below), one or more External Clocks 365, and/or a stable internal oscillator which may keep time within a billionth of a second deviation (i.e., nanosecond timing resolution). In some examples, the stable internal oscillator may include a Voltage-Controlled Oscillator (VCO). Under some conditions, including, e.g., when the packet traffic flow on the O-RAN FH link 130 is on-time and not congested, the Counter 360 may use the PTP timing information in the incoming S-Plane PTP packets. Under some conditions, including, e.g., when the packet traffic flow on the O-RAN FH link 130 is delayed (perhaps caused by congestion) or when the timing received via the incoming S-Plane PTP packets is otherwise degraded, the Counter 360 may switch to External Clock(s) 365 and/or a highly accurate internal timing oscillator.
In some examples, the Counter 360 may include a hardware module which may receive and parse in-coming PTP packets in order to synchronize the Counter 360. In some examples, such a hardware module may include an ARM core processor embedded in the O-RAN FHA HW 300. In some examples, such a hardware module may include a processor from the x86 family, a PowerPC (PPC) processor, and/or an Intel multicore processor. The External Clock(s) 365 may be any suitable reference time source, as would be understood by one of ordinary skill in the art. In some examples, the External Clock(s) 365 may provide one or more Global Navigation Satellite System (GNSS) timing signals, such as, e.g., a Global Positioning System (GPS) timing signal. In some examples, the External Clock(s) 365 may provide both a one pulse per second (1PPS) signal and a Time of Day (ToD) signal, which may be received from an external GPS receiver and may be used in order to synchronize the Counter 360. In some examples, the External Clock(s) 365 may include one or more external clock generation/synchronization subsystems and/or chips.
In some examples, the Counter 360 may include a ToD counter which may be initialized and incremented by an internal clock that has its frequency adjusted by at least one of the following inputs: the PTP packets received from/on the circuit path 320t; a 1PPS signal at 10 MHz from the External Clock(s) 365; and/or a 1PPS/ToD signal from the External Clock(s) 365. In some examples, the Counter 360 may be a register with a suitable number of bits to maintain a sufficient timing accuracy—for instance, 64 bits may be sufficient to maintain a timing accuracy within about one nanosecond. In some examples, the Counter 360 may be implemented as a hardware register with logic gates, clocked by an internal oscillator, and accessible by other components via a memory mapped address.
In some examples, the Counter 360 may include an auto-detect mechanism to select which timing signal source to use as a primary timing signal, e.g., the PTP packets (parsed and synchronized in hardware circuitry), one or more External Clock(s) timing signals (e.g., GPS signals, timing package/chip signals), and/or an internal timing signal generated by an on-board timing oscillator capable of nanosecond resolution. In some examples, the user may choose a primary timing source and/or select an auto-detect mechanism in order to synchronize the Counter 360. In some examples, the Counter 360 may combine two or more timing sources together to generate a primary timing signal.
In some examples, the Counter 360 may recover synchronization for Synchronous Ethernet (SyncE) transparency. In some examples, the real-time O-RAN FHA 150 may provide bidirectional SyncE clock recovery, which may avoid any break/interrupt of the SyncE line frequency from, e.g., the O-DU 120 to the O-RU 140 (in network configuration LLS-C1), which may be beneficial when in either intrusive mode. In such examples, the real-time O-RAN FHA 150 may provide SyncE line transparency in each direction (“bidirectional SyncE clock transparency”), i.e., a recovered clock from inputs 305 to transmit clock of outputs 357 and vice-versa, which may be beneficial for both the non-intrusive and intrusive modes.
In typical telecommunication link analyzers, such low level timing synchronization and analysis per packet may be performed mostly via software on one or more captured packets/frames of the packet traffic flow on the link (i.e., post-processing of captured traffic packets/frames in storage/memory). By contrast, the O-RAN FHA HW 300 according to examples of the present disclosure provides processing such as, low level timing synchronization and analysis on a per packet basis, in real-time (i.e., real-time-processing of tapped traffic packets/frames currently being transmitted/received on the O-RAN FH link 130).
Returning to the packet traffic flow through the O-RAN FHA HW 300, an Arbiter 310 may combine the timestamped packets from each of the MAC receivers 307-DU and 307-RU into a single stream. In some examples, the resulting single stream has twice the data rate as the individual O-DU or O-RU packet flows. Combining the two flows at high speed in hardware into a single stream may be helpful at least because some of the timing parameters, measurements, and tolerances analyzed in the real-time O-RAN FHA 150 are based on the relative timings of packets from one flow with the packets of another. For instance, as discussed above, because each C-Plane packet (transmitted on the downlink) associated with an uplink U-Plane packet should be received before the associated uplink U-Plane packet is transmitted, having both the C-Plane packet from the downlink and its associated U-Plane packet from the uplink immediately available in the same stream may be beneficial when performing, for example, a C/U-Plane Timing Analysis. In some examples, the Arbiter 310 may combine additional packet traffic flows with the O-DU and O-RU packet flows.
The single stream of timestamped packets then enters the Parser 320 which may appropriately sort and route the packets by parsing the appropriate header information in each packet. In some examples, the sorting and routing may also be determined by user set criteria and/or parameters set by the type of analyses being performed in the real-time O-RAN FHA 150. As used herein, the term “routing criteria” may refer to any set of one or more conditions, parameters, and/or qualities of any packet and/or frame on an O-RAN FH link 130 (and thus, like in common usage, the term “criteria” as used herein may refer to either or both the singular and the plural, like “agenda” and “data”).
As shown in
As used herein, “hardware packet analyzer” refers to any type of hardware component or module in/on the O-RAN FHA HW 300 that may process, analyze, measure, scan, quantify, estimate, evaluate, modify, and/or further parse any packet received by the O-RAN FHA 150. In some examples, a hardware packet analyzer may include digital and/or analog circuitry (e.g., one or more transistors, logic gates, registers, memory devices, resistive elements, conductive elements, capacitive elements, and/or the like, as would be understood by one of ordinary skill in the art) and/or more complex discrete hardware components such as, e.g., a single- and/or multi-chip processor, a single- and/or multi-core processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, other discrete hardware components, and/or any combination thereof suitable to perform any of the functions described herein, as would be understood by one of ordinary skill in the art.
In some examples, the Parser 320 may use metadata parsed from the headers of the incoming packets along with routing criteria in order to perform certain functions. For example, as described in detail below, if a C/U-Plane Timing Analysis is to be performed, the Parser 320 may, in accordance with the routing criteria, use the parsed metadata to identify the packets in the C/U-Plane, and then may route those identified C/U-Plane packets on the circuit path 320a to the Window Estimation hardware packet analyzer 330-A where C/U Timing Analysis may be performed. As another example, as described in detail below, if a Packet Capture operation is to be performed, the routing criteria may indicate what kind, type, and/or number of packets are to be captured, the Parser 320 may, in accordance with the routing criteria, use the parsed metadata to identify the packets to be captured, and then may route those identified packets on the circuit path 320b to the Packet Capture hardware packet analyzer 330-B. As another example, as described in detail above, the Counter 360 may use the incoming S-Plane PTP packets as part of maintaining the clock, thus the Parser 320 may, in accordance with the routing criteria for the timing functionality, use the parsed metadata to identify the S-Plane PTP packets, and then may route those identified S-Plane PTP packets on the circuit path 320t to the Counter 360. In such an example, the Counter 360 may include PTP processing software and a suitable servo (such as, e.g., the embedded ARM core processor discussed above). As yet another example, if the O-RAN FHA SW 390 is to perform a higher-level M-Plane analysis, the Parser 320 may, in accordance with the routing criteria for the higher-level M-Plane analysis, use the parsed metadata to identify the packets in the M-Plane, and then may route those identified M-Plane packets on the circuit path 320c to the HW/SW interface 389 for transmittal to the O-RAN FHA SW 390 for the higher-level M-Plane analysis.
In some examples, the Parser 320 parses specific header fields of the incoming packets for metadata and may use the resulting metadata to appropriately route individual packets and/or packet flows and/or supply the metadata to the Flow Tracker 370. In some examples, the Parser 320 may be implemented as a Programming Protocol-independent Packet Processor (P4), which is an open source, domain specific programming language for network devices, specifying how data plane devices (switches, routers, Network Interface Controllers (NICs), filters, etc.) process packets in hardware. In some examples, the Parser 320 may be designed directly using Hardware Description Language (HDL) and/or implemented using Node Processing Unit (NPU) type blocks/functions, Tensor Processing Units (TPUs), and/or any other suitable means, as would be understood by one of ordinary skill in the art. In some examples, P4 tables may be implemented using multiple memory mapped tables, such as, e.g., Content Addressable Memory (CAM), Direct CAM (DCAM), Binary CAM (BCAM or BiCAM), Ternary CAM (TCAM), Semi-Ternary CAM (STCAM) tables; block RAM (BRAM), ultra-RAM (URAM), and the like; as well as other hash tables with match fields, as would be understood by one of ordinary skill in the art.
In some examples, the Flow Tracker 370 may use the metadata from the Parser 320 to track whether each Ethernet frame is a new type of frame flow or a frame flow that has been received before. In some examples, the metadata parsed by the Parser 320 and/or used by the Flow Tracker 370 may include, for example, a source address, a destination address, an Ethernet MAC address, a Virtual Local Area Network (VLAN) tag and ID, an EtherType, an eCPRI Message Type, an extended Antenna-Carrier identification (eAxC ID), data direction, source IP address, destination IP address, etc., as would be understood by one of ordinary skill in the art. The Flow Tracker 370 may maintain details and statistics for each flow—if there is a new flow, the new flow may be entered and initialized for tracking by the Flow Tracker 370; if it is an existing flow, the statistics for that flow may be updated (for example, its frame and byte count may be incremented). Statistics maintained by the Flow Tracker 370 may include, for example, packet count, the total bytes of each flow, timestamps of corresponding packets, etc. The Flow Tracker 370 may allow the tracking of the complete information about each flow, such as, e.g., each individual C-Plane, U-Plane, S-Plane, and M-Plane packet flows on the O-RAN FH link 130. In some examples, the Flow Tracker 370 may be implemented as pipeline arrays and processor-less block RAM (BRAM). In some examples, the Parser 320 may parse packets per Ethernet MAC layer and Layer 2 through Layer 4, as well as basic eCPRI/O-RAN headers, in order that the Flow Tracker 370 may maintain Layer 2 counters and statistics (aggregated per port), as well as flow discovery and tracking per connection.
The O-RAN FHA SW 390 may periodically query and receive data to and from the Flow Tracker 370 via a HW/SW interface 389 for analysis, processing, and then presentation on a Browser/GUI 397. In some examples, the HW/SW interface 389 may include a Peripheral Component Interconnect Express (PCIe) Subsystem, and/or another suitable card/bus subsystem, as would be understood by one of ordinary skill in the art. In some examples, the Browser/GUI of O-RAN FHA SW 390 may present a user with filtering or action selections (such as, e.g., capture, window analysis, real-time software (SW) analysis, etc.) for any user-selected flow. In such examples, when the user chooses a specific packet flow and a matching particular action for that packet flow, O-RAN FHA SW 390 may enter a TCAM function in the Parser 320 with a rule (typically identifying a flow) and the action, which results in action bits indicating the appropriate routing and/or downstream processing for the packet flow. In such examples, this may be how the Parser 320 uses the metadata parsed from the incoming packets to appropriately route individual packets and/or packet flows. One or more hardware packet analyzers 330 perform such downstream processing.
Accordingly, the Parser 320 may route one or more packets and/or packet flows for downstream processing by the one or more hardware packet analyzers 330, which may perform, e.g., analyses, hardware processing, measurements, and/or the like on the particular received packets and/or packet flow(s). In the example of
For instance, a user may select the C/U-Plane Timing Analysis function using the O-RAN FHA SW 390, so that the O-RAN FHA SW 390 may configure the TCAM in the Parser 320 with the appropriate rule (i.e., select the C/U-Plane packet flows) and the matching action (i.e., (i) route the selected packet flow to the Window Estimation hardware packet analyzer 330-A; and (ii) direct the Window Estimation hardware packet analyzer 330-A to perform the appropriate hardware processing). In some examples, the selected flow may be accompanied by action bits or an action field (generated by the Parser 320), which serves as instructions/control information for the specific hardware packet analyzer; such action bits may be routed via separate control circuitry/pathways from the Parser 320 to each of the hardware packet analyzers 330 as well as other analytical/measuring/processing/etc. components on the O-RAN FHA HW 300.
In this example/instance, the action bits/field accompanying the C/U-Plane packet flows to the Window Estimation hardware packet analyzer 330-A may instruct the Window Estimation hardware packet analyzer 330-A to perform real-time packet analysis in hardware to directly measure/calculate/determine early/late/on-time packet arrival for at least one of the C/U-Plane transmission/reception windows. In some examples, the user may select threshold values for the C/U-Plane Timing Analysis using, for example, a pull-down menu, a touchscreen, or a keyboard of the Browser/GUI 397 of the O-RAN FHA SW 390, which will result in the O-RAN FHA SW 390 programming/instructing/controlling the O-RAN FHA HW 300 to use the entered threshold values as stored hardware register values to be machine matched, set, calculated from, and the results stored in other hardware registers. The O-RAN FHA SW 390 may query those hardware registers in the O-RAN FHA HW 300 based on an event (such as, e.g., user input) or periodically/on a set schedule, and display those values and/or further analyze/process them for higher-level analysis or simpler visual graphical representation. In some examples, the O-RAN FHA SW 390 may set/control the O-RAN FHA HW 300 to continuously transmit the calculated values in real-time so that the Browser/GUI 397 of the O-RAN FHA SW 390 may present a visual display of those values and/or an intuitive graphical representation of the same information to the user in real-time.
In some examples, the Window Estimation hardware packet analyzer 330-A may perform monitoring of the C/U-Plane packets using CAM filtering rules provided by the Parser 320. Early, late, and on-time windows as specified in the O-RAN FH C/U/S-Plane standard may be calculated here and presented to the user via the O-RAN FHA SW 390. In some examples, C/U Timing Analysis may be performed via the Window Estimation hardware packet analyzer 330-A using the timing signal provided by the Counter 360.
As another instance, a user may select a Packet Capture function using the O-RAN FHA SW 390, so that the O-RAN FHA SW 390 may configure the TCAM in the Parser 320 with the appropriate rule (i.e., select the user-identified packets and/or packet flows) and the matching action (i.e., (i) route the selected packet flow to the Packet Capture hardware packet analyzer 330-B; and (ii) direct the Packet Capture hardware packet analyzer 330-B to store the packets and perhaps perform appropriate hardware processing). In such an example, the selected packets/packet flow(s) being routed by the Parser 320 to the Packet Capture hardware packet analyzer 330-B may be accompanied by action bits/field which instructs the Packet Capture hardware packet analyzer 330-B to capture the selected packets/packet flows and store them in, e.g., a Double Data Rate (DDR) buffer. In some examples, the Packet Capture hardware packet analyzer 330-B, following instructions indicated by the action bits/field, may implement a line rate dual port capture by making use of separate (or integrated) DDR components and/or Dual In-line Memory Modules (DIMMs) to store the packets/packet flows based on some criteria. For example, a separate capture buffer may be implemented for each direction, i.e., the UL and the DL, or for each plane, e.g., the C-Plane and the U-Plane; or by matching C-Plane packets to the U-Plane packets they pertain to; or by some other criteria, which criteria may be set by a user, or by the O-RAN FHA SW 390 for higher-level analysis and reporting/monitoring, etc. In some examples, the Packet Capture hardware packet analyzer 330-B may support dual port 100-Gbps line rate capture.
In these examples involving the Packet Capture hardware packet analyzer 330-B, the timestamp put on the individual packets upon entering the O-RAN FHA HW 300 by the MAC receivers 307 may play a crucial role in analysis by, for example, providing a “real-time” check separate from the time(s) already stored in the packet headers by the sender. In some examples, these O-RAN FHA HW 300-generated timestamps may be saved as corresponding metadata for each captured packet. When requested, these timestamps along with the other metadata and, in some examples, the Packet Capture hardware packet analyzer 330-B may provide the captured packets themselves to the O-RAN FHA SW 390 for higher-level analysis and processing. In some examples, the action bits/field may also indicate a trigger threshold for the buffer storage, which may, e.g., inform the O-RAN FHA SW 390 or its user of the event, or automatically purge the buffer and send its contents to the O-RAN FHA SW 390 for higher-level analysis and processing. The O-RAN FHA SW 390 may use the timestamped packets from the capture buffer for, e.g., offline decode functionalities. In some examples, C/U/S/M-Plane packet flows may be captured in Double Data Rate Synchronous Dynamic Random Access Memory (DDR-SDRAM) embedded in the Packet Capture hardware packet analyzer 330-B.
In typical telecommunication link analyzers, such low level timing synchronization and analysis per packet as the Window Estimation and Packet Capture functions described above may be performed mostly via software on one or more captured packets/frames (stored in hardware) of the packet traffic flow on the link (i.e., post-processing of captured traffic packets/frames in storage/memory). By contrast, the O-RAN FHA HW 300 according to examples of the present disclosure provides processing such as, e.g., Window Estimation, C/U Timing Analysis, in real-time by hardware (i.e., real-time-processing of tapped traffic packets/frames from the O-RAN FH link 130).
As indicated by the three dots in between the hardware packet analyzers 330 of
As another instance, a user may select specific packets/packet flows of interest for generating impairments using the O-RAN FHA SW 390, so that the O-RAN FHA SW 390 may configure the TCAM in the Parser 320 with the appropriate rule (i.e., select the user-identified packets and/or packet flows) and the matching action (i.e., (i) route the selected packet flow to the Impairment Generation hardware packet analyzer 330-Z; and (ii) direct the Impairment Generation hardware packet analyzer 330-Z to apply one or more impairments on the received packets, perhaps different impairments depending on other conditions, and forward the impaired packet so that they re-enter the live, real-time packet traffic flow on the O-RAN FH link 130). In such an example, the selected packets/packet flow(s) being routed by the Parser 320 to the Impairment Generation hardware packet analyzer 330-Z may be accompanied by action bits/field which instruct the Impairment Generation hardware packet analyzer 330-Z to delay (i.e., Packet Delay Variation-PDV) or even drop the packet/packet flow entirely as discussed herein.
In some examples, the Impairment Generation hardware packet analyzer 330-Z (impairment generator 152), following instructions indicated by the action bits/field, may establish a specific delay, delay range/window, or jitter, for the selected packets/flow(s). In some examples, the Impairment Generation hardware packet analyzer 330-Z, following instructions indicated by the action bits/field, may generate header field errors in packets of the selected packets/flow(s). It is considered that, in some examples, the Impairment Generation hardware packet analyzer 330-Z, following instructions indicated by the action bits/field, may generate low level spoofing and/or security hazards in packets of the selected packets/flow(s) in order to test the security of the system. In these examples involving the Impairment Generation hardware packet analyzer 330-Z, the timestamp put on the individual packets upon entering the O-RAN FHA HW 300 by the MAC receivers 307-DU/307-RUs may play a role in, for example, generating the appropriately synchronized and timed impairments, or providing a “real-time” check separate from the time(s) already stored in the packet headers by the sender.
As mentioned above, and in some examples, only the packets/packet flow(s) output from the Impairment Generation hardware packet analyzer 330-Z actually “flows through” the O-RAN FHA HW 300 to re-enter the packet traffic flow on the O-RAN FH link 130, as indicated by the line connecting the output of the Impairment Generation hardware packet analyzer 330-Z to a De-Arbiter 340. The De-Arbiter 340 takes the single stream of packets/flow(s) from the Impairment Generation hardware packet analyzer 330-Z and splits the packets/flow(s) into respective target paths based on, e.g., action bits/field provided by either the Impairment Generation hardware packet analyzer 330-Z or the Parser 320, and/or the original metadata of the packet upon entering the O-RAN FHA HW 300. This information may include port information, indicating whether the packet was received by the O-RAN FHA HW 300 by input 305-DU/MAC receiver 307-DU (i.e., the transmissions on the O-RAN FH link 130 from the O-DU 120) or by input 305-RU/MAC receiver 307-RU (i.e., the transmissions on the O-RAN FH link 130 from the O-RU 140). If the packet was received at input 305-DU/MAC receiver 307-DU, it may be forwarded on to be transmitted to O-RU 140; if the packet was received at input 305-RU/MAC receiver 307-RU, it may be forwarded on to be transmitted to O-DU 120.
More specifically, as shown in
The O-DU packet flow traffic exits Fixed Delay 350-DU and may enter MAC transmitter 355-DU, while the O-RU packet flow traffic exits Fixed Delay 350-RU and may enter MAC transmitter 355-RU before exiting the O-RAN FHA HW 300 and re-entering the packet traffic flow on FH link 130 via an output 357-DU and an output 357-RU, respectively. In some examples, the general purpose of the MAC transmitters 355 may be to ensure that frames going back onto the O-RAN FH link 130 may have the proper format to meet the IEEE 802.3 standard (with, e.g., a Frame Check Sequence (FCS)/Cyclic Redundancy Check (CRC), a proper interface gap, Physical Coding Sublayer (PCS)/Physical Layer encoding, etc.). In some examples, the MAC transmitters 355 may receive a timing signal from the Counter 360 which may be used to adjust the PTP correction field in S-Plane packets when the real-time O-RAN FHA 150 may include a PTP boundary clock (i.e., a Telecom Boundary Clock (T-BC) and/or Telecom Transparent Clock (T-TC) function). In some examples, the MAC transmitters 355 may use the timing signal when the real-time O-RAN FHA 150 may be emulating S-Plane impairments.
In some examples, the MAC receivers 307 may be timestamping incoming packets with an accuracy of about 20-30 ns. In some examples, an accuracy of about +/−100 ns may be maintained for the packets flowing thru the real-time O-RAN FHA 150 in intrusive mode with some fixed delay of about 2-15 microseconds depending on the line rate. In some examples, the parsing/processing of received frames may be roughly a few hundred nanoseconds after the first bit/symbol is received at the inputs 305. In some examples, processing in “real-time” may be understood as processing every received frame in real-time O-RAN FHA 150 and performing some real-time operation on each frame (such as, e.g., parsing, defining/identifying a packet flow, and/or counting or performing some other function on a per frame or per frame payload basis).
In various examples of the present disclosure, the packet flows from one, some, or all of the hardware packet analyzers 330 may or may not be forwarded onward in the real-time O-RAN FHA 150, i.e., the packets exiting from one, some, or all of the hardware packet analyzers 330 may or may enter the next three modules, e.g., the De-Arbiter 340, one of Fixed Delays 350-A and 350-B, and one of MAC transmitters 355-DU and 355-RU. In some examples of the real-time O-RAN FHA in the intrusive mode, all packet flows from the hardware packet analyzer(s) 330 (and/or any traffic routed elsewhere by the Parser 320) would continue to the De-Arbiter 340, which separates the incoming packets into appropriate traffic flows for the O-DU 120 and O-RU 140, in a manner complementary and opposite to the combining process performed by the Arbiter 310. In other examples of the intrusive mode, packet flows exiting from only some or one hardware packet analyzer 330 would be forwarded to the De-Arbiter 340 as part of the process of being re-introduced to the traffic flow on the FH link. For instance, in the example shown in
In some examples, the real-time O-RAN FHA 150 may have a low-latency/non-intrusive mode which may employ circuit paths which run directly from input 305-DU to output 357-RU and directly from input 305-RU to output 357-DU with the same parallel transceiver data and recovered clock. In examples using such a low-latency/non-intrusive mode, the packet flow through the real-time O-RAN FHA 150 may bypass most of the interior components, such as, e.g., the Arbiter 310, the Parser 320, the De-Arbiter 340, and the Fixed Delays 350-DU and 350-RU.
In some examples, where less than all of the incoming packet flows may be, after analysis by the O-RAN FHA HW 300, output to rejoin the packet traffic flow on the O-RAN FH link 130, or when in non-intrusive mode, only copies of the O-RAN FH link packet traffic flow may actually enter the real-time O-RAN FHA 150 in real-time. In such examples, a splitter may be used so a replica of the packet traffic flow on the O-RAN FH link 130 enters the real-time O-RAN FHA 150 for analysis in real-time. In examples specifically like
As described in detail above, after all, some, or none of the packet traffic from one or more of the hardware packet analyzers 330 may be separated into two streams by De-Arbiter 340, one containing O-DU traffic and the other containing O-RU traffic, the two streams may be modified by Fixed Delays 350, which may ensure the packets may be synchronized appropriately with the other traffic on the O-RAN FH link 130, transmitted by MAC transmitters 355, and exit through outputs 357 to re-enter the packet traffic flow of the O-RAN FH link 130.
As shown in
Returning to
The O-RAN FHA SW 390 may be implemented in and/or by any number of processors and non-transitory computer-readable storage media storing instructions executable by the processor(s) which may be separate from the hardware accelerator which may comprise the O-RAN FHA HW 300. The processor(s) implementing the O-RAN FHA SW 390 may include multiple processing units executing instructions in parallel. The non-transitory computer-readable storage medium/media implementing the O-RAN FHA SW 390 may be any memory, such as a hard disk drive, a removable memory, or a solid-state drive (e.g., flash memory or dynamic random access memory (DRAM)). In some examples, one or more processors in the O-RAN FHA SW 390 may perform one or more functions; in some examples, one or more non-transitory computer-readable storage media in the O-RAN FHA SW 390 may store instructions that, when executed by the one or more processors, cause the one or more processors to perform any of the functions described herein. In some examples, functions such as those described herein in reference to the O-RAN FHA SW 390 may be performed by one or more processors wired/wirelessly connected to the O-RAN FHA HW 300.
In some examples, the O-RAN FHA SW 390 may be implemented by a rack server, such as, for example, a Dell™ PowerEdge Rack Server (e.g., a R7515 server), containing one or more processors, such as, for example, an Advanced Micro Devices (AMD™) EPYC 700x/900x series server processor, with from 8 GB to 2 TB of DDR4 Registered DIMM (RDIMM) and/or Load-Reduced DIMM (LRDIMM) having a bandwidth up to 3200 MegaTransfers per second (MT/s), and 100 GB-1 TB Solid State Drive (SSD) memory. As would be understood by one of ordinary skill in the art, this is only one specific configuration of a wide variety of possible configurations suitable for implementing the O-RAN FHA SW 390.
Returning to the O-RAN FHA HW 300 in
As shown, the O-RAN FHA 400 may include a hardware accelerator 410 (which may also be termed a hardware packet analyzer or a packet analyzer that includes hardware). As discussed herein, the hardware accelerator 410 may be any group of programmable logic blocks with reconfigurable interconnects, such as, a PLD, an FPGA, CLBs, and/or the like. The hardware accelerator 410 may include a Parser (or P4) 320 that may include a memory 412, which may be a TCAM. The hardware accelerator 410 may also include an impairment generator 152 and one or more packet analyzers 154.
According to examples, the Parser/P4 320 may receive packet traffic flows 420, 422 outputted by an O-DU 120 and/or an O-RU 140. Particularly, for instance, the Parser/P4 320 may receive packet traffic flows 420 that include packets that an O-DU 120 has outputted to an O-RU 140. Additionally, or alternatively, the Parser/P4 320 may receive packet traffic flows 422 that include packets that an O-RU 140 has outputted to an O-DU 120. As discussed herein, the Parser/P4 320 may receive the packet traffic flows 420, 422 through connections with the O-DU 120 and the O-RU 140 as shown in
According to examples, a user may select which of the packet traffic flows 420, 422 are to receive impairments and the types of impairments (actions) that are to be applied to the selected packet traffic flows 420, 422. The selection of the packet traffic flows 420, 422 and the actions may result in software programming the memory 412 (e.g., TCAM functions) with rules that identify the packet traffic flows 420, 422 and the actions. For instance, the rules may identify the packet traffic flows 420, 422 upon which the actions are to be applied and the action bits may denote the types of impairments to be applied to the identified packet traffic flows 420, 422. By way of particular example, the O-RAN FHA software 390 may configure the memory 412 (TCAM) with the identities, e.g., flow numbers, of the packet traffic flows 420, 422 on which the actions are to be performed and types of actions that are to be performed on the packet traffic flows 420, 422. The actions may also correspond to actions that the packet analyzer(s) 154 are to perform on the packet traffic flows 420, 422.
According to examples, the user may select which of the packet traffic flows 420, 422 are to receive impairments and the types of impairments (actions) that are to be applied to the selected packet traffic flows 420, 422 based on the types of the traffic flows. For instance, whether the packet traffic flows 420, 422 are from an O-DU 120 to an O-RU 140 or from an O-RU 140 to an O-DU 120. In addition or alternatively, the selection may be based on whether packets in the packet traffic flows 420, 422 are Control Plane (C-Plane) packets, User Plane (U-Plane) packets, or Synchronization Plane (S-Plane) packets. In other words, the user may select which of these types of packets certain types of impairments are to be applied.
As discussed herein, the Parser/P4 320 may parse the packets in the received packet traffic flows 420, 422. In addition, the Parser/P4 320 may determine which of the received packet traffic flows 420, 422 are to receive impairments. For instance, the Parser/P4 320 may compare the identities of the packet traffic flows 420, 422 with the information stored in the memory 412 to make this determination. That is, and as discussed herein, the memory 412 may have stored thereon the identities, e.g., flow numbers, of the packet traffic flows 420, 422 that are to receive impairments. The memory 412 may also have stored thereon the impairments, e.g., actions, that are to be performed on certain ones of the packet traffic flows 420, 422.
The Parser/P4 320 may set action bits for the packets in the packet traffic flows 420, 422 that are to receive impairments to enabled. Likewise, the Parser/P4 320 may not set the action bits for the packets in a packet traffic flow 420, 422 that are not to receive an impairment. In addition, the Parser/P4 320 may set the action bits for the packets to denote information indicating types of impairments to be applied to the packets that are to receive impairments. In addition, the Parser/P4 320 may output packet traffic flow 424 with the set action bits to the impairment generator 152. For instance, the Parser/P4 320 may forward the packets with the set action bits to the impairment generator 152 as sidebands.
The Parser/P4 320 may also output packet traffic flow 426 to the packet analyzer(s) 154. The Parser/P4 320 may set action bits on the packets that are to be outputted to the packet analyzer(s) 154, in which the action bits may identify which of the packet flows the packet analyzer(s) 154 are to analyze. The packet traffic flow 426 outputted to the packet analyzer(s) 154 may also include the action bits as sidebands. The packet analyzer(s) 154 may analyze the packets in the packet traffic flow 426 in any of the manners discussed herein. In some examples, the packet analyzer(s) 154 may analyze the packets in parallel with the generation of the impairments by the impairment generator 152.
The impairment generator 152 may generate impairments on the packet traffic flows 424 and may output the packet traffic flows 430, 432 with the impairments applied to the packet traffic flows to an O-DU 120 and/or an O-RU 140. The impairment generator 152 may output the packet traffic flows 430, 432 through the hardware accelerator 410 as discussed herein.
As shown, packet traffic flows 424 with set action bits may be inputted into the impairment generator 152, e.g., from the Parser/P4 module 320. When inside the impairment generator 152, the packet traffic flows 424 may be inputted into the flow selectors 502-A to 502-N. In some examples, the flow selectors 502-A to 502-N may be instantiated a number of times equal to the number of packet traffic flows 420, 422 selected to receive impairments.
As discussed herein, the action bits for the packets in the packet traffic flows 424 may have the information about the flow number (among the 256 flows) and the sideband of incoming packet traffic flows 424 may have indications of port directions (O-DU 120 to O-RU 140 or O-RU 140 to O-DU 120). Based on this information, the flow selectors 502-A to 502-N check for both the flow number and the impairment corresponding action bits. In addition, the flow selectors 502-A to 502-N take the decision of passing the packet traffic flows 424 through the impairment flow modules 510-A to 510-N or passing it to the next flow selector. Based on the information, the flow selector 510-N may bypass the impairment flow module 510-N and may pass the packet traffic flow 424 to a next action block. If there is no next action block, the current action block may stop passing the packet traffic flow 424, e.g., the output packet traffic flow 424 from the current action block may be dropped.
In examples in which the flow selector 502-A finds the corresponding flow configured from software for impairment, the flow selector 502-A passes the packet traffic flow 424 to the impairment flow module 510-A. The impairment flow module 510-A may buffer the incoming packet traffic flow 424 that has been selected for impairment into a memory. In addition, the impairment flow module 510-A may generate a type of impairment on the packets in the packet traffic flow 424. As discussed herein, the action bits for the packets may denote the type of impairment that is to be generated for the packet traffic flow 424. For instance, the impairment flow module 510-A may introduce latency into the delivery of the packets in the packet traffic flow 424 by delaying the output of some of the packets. As another example, the impairment flow module 510-A may drop one or more packets from the packet traffic flow 424, i.e., may prevent the one or more packets from being delivered to their intended destination. As a further example, the impairment flow module 510-A may modify an order in which some of the packets in the packet traffic flow 424 are delivered to their intended destination. The other flow selectors 502-B to 502-N and the other impairment flow modules 510-A to 510-N may operate in similar manners.
The impairment flow module 510-A may also output the packets of the packet traffic flow 424 with the impairment applied to the packets to the output scheduler module 520. The output scheduler module 520 may schedule when packets in the packet traffic flow 424 are to be outputted from the impairment generator 152. Particularly, the output scheduler module 520 may schedule the output of packets in packet traffic flows 424 with impairments added to the packet traffic flows 424 by other impairment flow modules 510-B to 510-N.
According to examples, a first impairment flow module 510-A may generate a first type of impairment, e.g., a latency impairment, on a first packet traffic flow based on information denoted by the action bits for the packets in the first packet traffic flow. In addition, a second impairment flow module 510-B may generate a second type of impairment, e.g., a packet drop, on a second packet traffic flow based on information denoted by the action bits for the packets in the second packet traffic flow.
At block 702, a Programming Protocol-independent Packet Processor (P4) 320 (or, equivalently, a Parser 320), may receive packet traffic flows 420 outputted by an O-DU 120 and/or an O-RU 140. As disclosed herein, a user may have programmed the P4 320 via software to apply impairments on selected ones of the packet traffic flows 420, e.g., by flow number and type of action.
At block 704, the P4 320 may set action bits for packets in the packet traffic flows 420, 422 that are to receive impairments to enabled, in which the action bits denote information indicating types of impairments to be applied to certain ones of the packet traffic flows 420, 422.
At block 706, the P4 320 may output the packet traffic flows 424, 426 with the action bits set for the packets in the packet traffic flows to a packet analyzer 154 and an impairment generator 152.
At block 708, the packet analyzer 154 may analyze the packet traffic flows 426 based on the settings of the action bits for the packets in the packet traffic flows 426.
At block 710, the impairment generator 152 may generate impairments on the packet traffic flows 424 based on settings of the action bits for the packets in the packet traffic flows. As discussed herein, the generation of the impairments on the packet traffic flows 424 may result in the delay in the delivery of some packets in a packet traffic flow 424, a drop of some packets in a packet traffic flow 424, and/or the like.
According to examples, the P4 320 may generate a first type of impairment on a first packet traffic flow based on information denoted by the action bits for the packets in the first packet traffic flow. The P4 320 may also generate a second type of impairment on a second packet traffic flow based on the information denoted in the action bits for the packets in the second packet traffic flow.
While specific circuit configurations such as the arrangements of a number of components are shown in conjunction with the figures herein, the illustrated configurations are not intended to be limiting. A real-time O-RAN FHA 150 in accordance with examples of the present disclosure may be implemented with other configurations and component values using the principles described herein. Moreover, while examples described herein are directed to configurations as shown, it should be appreciated that any of the components described or mentioned herein may be altered, changed, replaced, or modified, in size, shape, and numbers, or material, depending on application or use case, and adjusted for desired analysis or optimal measurement results.
It should be appreciated that the apparatuses, systems, and methods described herein may minimize and/or reduce the timing for performing O-RAN FH link 130 analysis and impairment generation, and thereby facilitate the construction of more reliable and accurate O-RAN FH links 130, specifically by ensuring the interoperability of different components manufactured by different vendors.
It should also be appreciated that the apparatuses, systems, and methods, as described herein, may also include, or communicate with other components not shown. For example, these may include external processors, counters, analyzers, computing devices, and other measuring devices or systems. This may also include middleware (not shown) as well. The middleware may include software hosted by one or more servers or devices. Furthermore, it should be appreciated that some of the middleware or servers may or may not be needed to achieve functionality. Other types of servers, middleware, systems, platforms, and applications not shown may also be provided at the backend to facilitate the features and functionalities of the testing and measurement system.
Moreover, single components may be provided as multiple components, and vice versa, to perform the functions and features described herein. It should be appreciated that the components of the system described herein may operate in partial or full capacity, or it may be removed entirely. It should also be appreciated that analytics and processing techniques described herein with respect to the O-RAN FH link 130, for example, may also be performed partially or in full by other various components of the overall system.
It should be appreciated that data stores may also be provided to the apparatuses, systems, and methods described herein, and may include volatile and/or nonvolatile data storage that may store data and software or firmware including machine-readable instructions. The software or firmware may include subroutines or applications that perform the functions of the measurement system and/or run one or more applications that utilize data from the measurement or other communicatively coupled system.
The various components, circuits, elements, components, and interfaces, may be any number of mechanical, electrical, hardware, network, or software components, circuits, elements, and interfaces that serves to facilitate communication, exchange, and analysis data between any number of or combination of equipment, protocol layers, or applications. For example, the components described herein may each include a network or communication interface to communicate with other servers, devices, components or network elements via a network or other communication protocol.
Generally speaking, any one or more of the components and/or functionalities described in reference to any of the figures herein may be implemented by hardware, software, and/or any combination thereof, as described in the above examples of the present disclosure. In some examples, the components and/or functionalities may be implemented by at least one of any type of application, program, library, script, task, service, process, or any type or form of executable instructions executed on hardware such as circuitry that may include digital and/or analog elements (e.g., one or more transistors, logic gates, registers, memory devices, resistive elements, conductive elements, capacitive elements, and/or the like, as would be understood by one of ordinary skill in the art). In some examples, the hardware and data processing components used to implement the various processes, operations, logic, and circuitry described in connection with the examples described herein may be implemented with a general purpose single—and/or multi-chip processor, a single—and/or multi-core processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, and/or any combination thereof suitable to perform the functions described herein. A general purpose processor may be any conventional processor, microprocessor, controller, microcontroller, and/or state machine. In some examples, the memory/storage may include one or more components (e.g., random access memory (RAM), read-only memory (ROM), flash or solid state memory, hard disk storage, etc.) for storing data and/or computer-executable instructions for completing and/or facilitating the processing and storage functions described herein. In some examples, the memory/storage may be volatile and/or non-volatile memory, and may include database components, object code components, script components, or any other type of information structure suitable for implementing the various activities and storage functions described herein.
What has been described and illustrated herein are examples of the disclosure along with some variations. The terms, descriptions, and figures used herein are set forth by way of illustration only and are not meant as limitations. Many variations are possible within the scope of the disclosure, which is intended to be defined by the following claims—and their equivalents—in which all terms are meant in their broadest reasonable sense unless otherwise indicated.
