2 Setup and SgNB Addition procedures, showing X2 interface compliance. Typical test tools include monitoring type of equipment such as: Test UEs/UE monitors. Traffic generators. Traffic sources/sinks that can generate or process deterministic traffic patterns (throughput, packet size, protocol, etc.) as well as deliver test reports to capture KPIs, including received throughput, latency, packet loss, etc. Protocol analyzers are typically connected through a spoofing port that makes their existence invisible to the equipment communicating over the network. Protocol analyzers can analyze control plane and user plane traffic. RF and spectrum analyzer. CU, DU, and/or RU emulator. Core or core emulator. Consumer application hardening This type of testing centers around end-user application performance on the system under test. Rather than deploying artificial traffic patterns, end-user applications are exposed to the system under test to ensure that no unexpected behaviors are observed and to validate per- formance. Examples include the following: HTTP testing. Web browsing between a UE and a server that is colocated to the core network. This implies TCP traffic with a very asymmetrical traffic pattern and bursty traffic. Streaming TV, either using buffered or live (more latency sensitive) traffic sources and User Datagram Protocol (UDP) traffic. Gaming between multiple users on the wireless system under test or between a wireless user and a server that is colocated with the core network. Performance testing Performance testing can be done in two different ways: black box testing where the combina- tion of the CU/DU/RU and UE becomes a combined system under test validated against pre- set performance goals, as well as low-level "white box" performance testing associated with identification of performance bottlenecks or validation of component-level performance as opposed to system-level performance against set values. Black box testing As the name indicates, this testing evaluates system performance looking "from the 