## 4 Proposed Orchestrator
The data tables generated by the _Application Requirements_ block are received by the **Network Slice Definition** block, which accounts for generating the NS through a series of generic SLAs (types of NSs), which will be sent to the _Network Slice Negotiation_ block so that the NS can be negotiated with the TIPs and MNOs. The parameters from SLAs are generated using the tables received and information about the locations where the service will be provided, including mobility, communication infrastructure available from TIPs in the areas in question, and information of operation related to MNOs that serve specific areas. Bearing in mind that, as the orchestration is horizontal, all the existing infrastructure must be considered regardless of which TIP or MNO the technology used belongs to. The infrastructures that provide coverage in the target locations of the services will be the candidates, with the rest being discarded. It is worth noting that, in the case of mobility, it may be necessary to carry out a horizontal handover procedure when a candidate does not cover all areas. Nevertheless, it will not be discarded, as it may still be chosen to provide connectivity in the area it serves. With the infrastructures chosen by the criterion of physical coverage, an analysis will be made that lists which infrastructures meet the requirements present in the tables. After that, a list ordered by degree of adherence to the required QoS parameters will be generated and horizontal NSs will be defined using, if applicable, different MNOs for each telecommunications service (for example, core and access). 1. To generate the list of candidate NSs, the **Network Slice Definition** block simulates its operation for each of the NSs present in the list, considering the data present in the operational databases. Figure 3: Flow for establishing and managing the network slicing. After the simulation, the candidates will be sent to the **Network Slice Negotiation** block through a set of SLAs. The use of AI tools is essential for operating the **Network Slice Negotiation** block due to the need for negotiation processing time. Note that the infrastructure database related to the use of the network must be populated and maintained with the support of the TIPs and that the operation database can be negotiated with the MNOs so that their data can be used, ensuring security and privacy with the use of isomorphic encryption. This is a sore point. If it is not possible to obtain this information, it will be sought from open sources or created from the previous work experience of our own Orchestrator. Thus, if it is not possible to use the MNOs operating databases, they can be created with the information collected by 5G-Horizontal during its operation. Then, in the opposite direction, the **Network Slice Definition** block receives QoS data from the services and draws up a new list of candidate NSs if it is not feasible to establish the NSs for the services in progress and whose requirements are not being met (impossibility of horizontal handover). This feedback is part of the proposed Orchestrator's dynamic and operating time specification, and also to popularize the operation database, which has a Big Data structure. Candidate NSs are sent to the **Network Slice Negotiation** block, which accounts for negotiating and establishing NSs through the negotiation of SLAs with the MNOs involved in the slicing in question (horizontal orchestration). At this point, only MNOs with the possibility of negotiating SLAs online are observed to be in the candidate NSs, which, in the future, will encourage the softwarization and virtualization of communication infrastructures, in compliance with the 5G philosophy. The negotiation will take into account the operational parameters of the MNO, as well as its statistical behavior, seeking to predict the behavior of the infrastructure in question during the provision of the service.