ge hardware or modify expectations from the customer. Where possible, we recommend development of a "Proof Point" for the application code that implements the whole "Ethernet-to-sample" path in a quick-and-dirty manner but including the performance critical phases. This could include a minimized-feature implementation of PDCP, RLC, MAC, and PHY components for a single bearer and only Shared Channel support. The Proof Point highlights any potential system bottlenecks and, when padded with enough margin, can provide a system implementation performance baseline. When first software deliverables are made, automated regression test frameworks can be built to capture key performance metrics (CPU loading, memory loading, and so on) for performance critical use case-for example, a loopback scenario that does not rely on actual wireless connectivity that will only be established later in the project (example in Fig. 10-9). This performance report is then compared to the initial performance projections to identify points for software optimization. Code instrumentation can be applied as part of performance logs to be able to track per- formance numbers during field deployment or over time as bugs are fixed and features are added. This allows the system to become more resilient against "Heisenbugs" or errors that disappear once one attempts to study them. Heisenbugs commonly appear only during field deployment and are notoriously hard to fix given that they are both rare and often associated Chapter 10 Interoperability and test 345 Server DU platform Server UE Emulator gNB Stack 5G Core Application Client NR-PDCP Application Server NR-PDCP Application OAM NR-RLC NR-RLC NR-MAC NR-MAC + SCH Convergence Layer Convergence Layer Ethernet Ethernet FIGURE 10-9 DU L2 stack unit test benchmarking platform. with system timing that occurs in unenvisioned scenarios. These topics can often be traced back to unexpected performance issues. Front-, mid-, and backhaul testing Fronthaul networks have strict requirements set by the 802.1CM sta