the processing load. Traffic directing is mostly done based on 108 Open Radio Access Network (O-RAN) Systems Architecture and Design some classification rule that directs all traffic associated with a single flow to a single (set of) processing resource(s). An example of such a classification rule could be the IP Source/ Destination address tuple or something similar. In the "average" case where many flows pass through the system, there are no issues; statistical multiplexing of many flows over relatively few parallel processing elements means that the amount of flows processed by each resource is more or less the same and we have a balanced system. The Elephant Flow is the exemption to the rule, in the extreme case, all traffic is associ- ated with a single flow and hence assigned a single (set of) processing resource(s), leaving all other parallel resources underutilized. The result is an unbalanced system: The assigned resource will be overloaded and the remainder resources stale. This makes the Elephant Flow both a performance metric and a benchmarking/optimiza- tion use-case because it defines the minimum processing power that a single resource (core, accelerator, or even input/output (IO interface) needs to be able to sustain. The use-case is very intuitive and has a practical impact (who likes to wait long for a download to finish?) but also often overlooked. Use-case dimensioning for latency Overall application latency is composed of the various components shown in Fig. 3-6. The picture includes the Radio Access Network (RAN) latency (User Equipment (UE) to RU/DU and CU), but also the latency from the Communication Service Provider (CSP or RAN/ Operator network), as well as the latency from the internet itself. Note that the CSP and Internet latencies can be eliminated by use of Metro Edge Computing where the application server is colocated with the CU/DU components. CSP and Internet latencies. This is the combined delay incurred by the operator network as well as the access network connection to the oper