## 4 Proposed Orchestrator
Multiple & & & & & & & & & & & & \\ \hline \multirow{4}{*}{Orchestration Functions} & Services & \multirow{4}{*}{SG**} & \multirow{4}{*}{SG**} & \multirow{4}{*}{SG**} & \multirow{4}{*}{SG**} & \multirow{4}{*}{SG**} & \multirow{4}{*}{SG**} & \multirow{4}{*}{SG**} & \multirow{4}{*}{SG**} & \multirow{4}{*}{SG**} \\  & Resources & & & & & & & & & & & & \\  & Life Cycle & & & & & & & & & & & \\ \hline \multicolumn{2}{c}{Open Source} & \multirow{4}{*}{**SG**} & \multirow{4}{*}{**SG**} & \multirow{4}{*}{SG**} & \multirow{4}{*}{SG**} & \multirow{4}{*}{SG**} & \multirow{4}{*}{SG**} & \multirow{4}{*}{SG**} & \multirow{4}{*}{SG**} & \multirow{4}{*}{SG**} \\ \cline{2-2} \cline{1-1} \Furthermore, vital is the support of Distributed Cloud Computing towards meeting latency [4], which may be low at the millisecond level [79]. Unlike 4G orchestration, which is vertical, the 5G Orchestrator proposed here must comply with the principle of the automated and horizontal orchestration, making it possible to perform measurements to verify whether QoS, QoE, and SLAs are being met. Therefore, efforts are needed to develop algorithms and methods capable of managing resources and providing advanced and reliable 5G services with appropriate QoS for end-users and generating an economic system [56]. For all these reasons, the proposed Orchestrator will be extremely important in the regulation models since it may offer data for newer regulation definitions. Therefore, for composing the system, concepts and tools of AI, Distributed Cloud Computing, Big Data, Isomorphic Cryptography, and Prediction shall be used under a private computing cloud environment, where the system components are software elements that will operate in an integrated manner. The implementation has been conducted through open source solutions and tools, such as the Open Network Automation Platform (ONAP) [80], so the final cost is as low as possible and updates and maintenance are facilitated. Whenever there is no ready-made block of free access to be used and integrated, it will be developed. Thus, the intention is to use the maximum of existing components for the system implementation. Digging deeper, Figure 3 shows the process for establishing and managing the NS in terms of the Orchestrator's view, from which the workflow should be executed as follows:  
1. First, the 5G-Horizontal receives the description of the service request to be provided (represented by the arrow _Service Request_) in a standardized format from the Business Function layer [23; 31], with the definitions established in [81]. Moreover, for executing QoS parameters and SLA analysis (QoE), an instance that will be hosted at the edge of the network, as described in Section 4.1.4, which uses multicriteria decision-making methods, will analyze the parameters at run time, such as mapping (labeling) from the radio base station (gNodeB). As observed, the _Service_ is set up based on historical service data stored in a Big Data structure, in which AI algorithms are used to estimate service resource requirements according to operation history to fit network slicing parameters to packages flow needs. 2. The _Service Request_ is received by the **Application Requirements** block, whose function is to generate the information for defining the NS. This follows the description of the services, from which the network performance requirements necessary for providing the service with the quality requirement contracted by the end-user to the SP are extracted, that is, a table of QoS parameters is defined from generic templates existing in the database of the block and filled with the respective values necessary to  
Figure 2: Conceptual model: workflow of 5G-Horizontal multi-provider Orchestrator. serve the end-user. AI tools and service history databases will be used to implement this block. 3.