# QoS Management and Flexible Traffic Detection Architecture for 5G Mobile Networks
## 5 Quantitative and Qualitative Analysis
### High Controller Response Time and Network Overload Problem Simulation  
In order to obtain quantitative results related to the proposed two-pipeline processing, the standard OpenFlow control is implemented over the prototype as well, and the behavior on routing traffic with the specific QoS requirement is compared for both the proposed architecture and standard OpenFlow Control. It is important to note that the standard OpenFlow implemented uses \begin{table}
\begin{tabular}{l l l l l} \hline \hline  & **AF** & **TDF** & **Centralized** & \multirow{2}{*}{**Proposed Mechanism**} \\  & **Mechanism** & **Mechanism** & **Data Center** & \\ \hline Robustness & Low & Low & Good & Very good \\ Scalability & Good & Low & Very good & Very good \\ QoS processing & Distributed & Centralized & Centralized & Distributed/Centralized \\ Traffic detection possibilities & Good & Good & Very good & Very good \\ Additional delay during QoS detection & Low & Low & Intermediate & Low \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Comparison of QoS traffic detection strategies. AF, Application Function; TDF, Traffic Detection Function. \begin{table}
\begin{tabular}{l l l l} \hline \hline  & **EPC** & **Standard** & **Proposed** \\  & **Architecture** & **OpenFlow** & **Architecture** \\ \hline Forwarding response time & Immediate & Intermediate & Immediate \\ Traffic engineering possibilities & Good & Very good & Very good \\ GTP-U requirement & Required & Required & Not required \\ Traffic detection flexibility & Good & Good & Very good \\ Specific treatment for QoS traffic & Intermediate & High & High \\ Controller processing requirement & N/A & very High & Intermediate \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Comparison of mobile network architectures. GTP-U, GPRS Tunneling Protocol User plane. the reactive path setup mode for initial configuration and for traffic without QoS requirement and the reactive setup mode for traffic with QoS requirement; then, when a specific QoS packet arrives, a packet-in message is generated, and the node must wait for the controller response to route the QoS packet. With the proposed architecture and the standard OpenFlow architecture implemented, some problems related to the communication with the controller are emulated, and the behavior of the architectures when a new packet with specific QoS requirement is sent from OF-NB 1 to the application server is compared. In the comparative analysis, the following problems are considered:  
1. Queuing delay in the controller;
2. Controller overload and controller high response time;
3. Requirement of TCP retransmissions in the packet-in request;
4. Delay on the path used for the packet-in request due to link saturation. It is important to note that the first two mentioned problems affect the packet-in request and the controller response (i.e., a two-way delay), whereas the third and fourth problems could only affect a packet-in request (i.e., a one-way delay). The tests consider the UE 1 attached and consist of erasing all specific OF-Bearer with QoS (specific service flow entries) and generating traffic with QoS from the OF-NB 1 to the application server with IP 20.20.20.20 (see Figure 7) to measure the average round-trip time between them. This test is repeated for both the proposed and standard OpenFlow controls by adding a variable delay in the communication of OF-NB 1 and OF-GW 1 with the controller. The introduced additional delay ranges from 0 ms-100 ms, with increments of 10 ms. In addition, all tests are done simulating the two types of controller communication delay (the two-way delay and the one-way delay), which are implemented by programming a waiting time in the controller communication. The results are shown in Figure 9. As can be seen, the round-trip time between the hosts is not affected in the proposed architecture.