# QoS Management and Flexible Traffic Detection Architecture for 5G Mobile Networks
## 3 Proposed Architecture
### Other Considerations Regarding QoS Traffic and Processing  
As traffic can be routed directly between two OF-NB, the traffic counter and time counter must be moved to the edge of the mobile access to the OF-NB. In particular, the counters present in the specific service flow entries and in the default flow entries to the specific UE can be used. If during an EPS-Bearer with QoS creation, the OCS informs that the EPS-Bearer to be created has X minutes of credit, the specific service flow entry must be established with an idle-timeout of X minutes. On the other hand, if the credit is related to an amount of remaining traffic, the specific service flow entry should be checked periodically to know when the credit limit is reached.  
During normal operation, the traffic without QoS requirements is routed using the default path previously preconfigured, and the Controller interacts only if the traffic has QoS requirements (or in the attachment process). This method reduces the number of OpenFlow messages that the Controller must process, decreasing the Controller overload.  
Additionally, since the proposed architecture always routes the packets using the default OF-Bearer immediately, this architecture has less impact during the Controller high response times since traffic continues to be routed through the default OF-Bearer. This behavior improves the robustness of the solution if it is compared with traditional SDN implementations, in which the packets of new flows must wait for the Controller response to be routed.  
It is important to note that the proposed traffic detection logic is composed of two main steps, one implemented in a distributed way at OF-NB using the OpenFlow traffic detection table and the second one at SDD using dedicated software to customize the QoS characteristics to be detected. The first step is limited by OpenFlow matching criteria, and the second one is unlimited. Then, the proposed combined detection logic can be considered unlimited. As a practical example, the necessity to identify specific content in the application layer when the packets are sent to a specific server can be considered. In this case, the traffic detection table at OF-NB is responsible for matching when a packet is sent to the server (and to a specific TCP port), as well as for sending the packet to the appropriate SDD. Once the packet is received by the SSD, this element is responsible for extracting the specific application layer requirement.  
In order to reduce the processing in the SDD element, this can be implemented in a distributed way in the mobile network domain. In this way, OF-NB can be divided into groups, and depending on their geographical location, they will have a specific SDD associated. Another alternative is to create specific SDDs for the analysis of different types of traffic, and the OF-NB will be responsible for routing the traffic to the appropriate SDD.  
Finally, to increment the architecture's robustness, the Controller function can optionally be divided and put into three different Controllers working together in a complementary way [39]. The optimal Controller separation for the proposed architecture is the use of a Controller for proactive flow configuration, which will be responsible for default OF-Bearer creation, traffic detection tables, and general routing rules. Another Controller for the attachment process will be responsible for the default EPS-Bearer creation and for the association between UE and the traffic detection table. The last one will be responsible for specific OF-Bearer with QoS creation.