## 4 Proposed Orchestrator
### Description of the Architecture
#### 4.1.4 Multi-Provider Network Slice Selector  
Selecting the so-called RAN networks in an environment of heterogeneous technologies is a complex problem since operators can provide specific types of slices directly to meet the requirements of an application or multiple slices to meet different requirements of the same user. Therefore, there is still no solution or technique that understands all aspects and mechanisms of access to these technologies [102; 103; 104]. Furthermore, the implementation of new selection techniques becomes necessary due to the demand in the growing use in vehicular networks, patient monitoring, smart cities, IoT, among other technologies and scenarios involving network convergence, mobility management, and service continuity in 5G networks [95; 105]. In general, the literature suggests approaches that consider the following situation: Given a set of criteria or network parameters, verify at any given time and among the available slices, which better fits the user needs, supporting the network exchange (handover process) for the mobile [95; 102; 106]. In this case, the process of choosing the slice is subject to some criteria [83; 107; 108]. Our work presents a new approach that employs several techniques aiming at the integration and interoperability between RAN networks and the core of the proposed orchestration architecture based on an efficient and robust Slice Selection Service (SSS) that provides compatibility with the specification standards in progress (e.g., 3 GPP, ETSI NFVI, and 5G-PPP). An overview of the proposed framework to NS selection is shown in Figure 5. The Multi-Provider Network Slice Selector Framework consists of a solution, where a part is executed in the user's equipment (e.g., smartphones, vehicles, IoT brokers), running as a transparent service, and another part runs at the edge of the network operator. The framework has three modules that can be configured according to the context of applications, geographic location, scenarios of mobility, strategies of slices selection, and others. For energy saving, the user equipment only signals its consumption profile or user application preference for the framework hosted at the edge of the architecture. That is, no processing is conducted in the mobile device or the IoT broker. According to Figure 5, the framework proposed is divided into three main blocks: data collection, processing, and classification of NSs. Fundamentally, the criteria for network selection are closely related to the demands or applications in use. Thus, parameters that measure the application QoS, as well as objective quality metrics, for specific applications, such as QoV (Quality of Video), and subjective metrics, such as indicators based on the user experience (QoE) and MOS (Mean Opinion Score), may be considered [109; 110]. The _Collector_ Module focuses on the assessment and dynamic mapping of the appropriate QoS requirements for each type of service, in addition to considering the signaling of the User Profile (e.g., V2X, Virtual Reality--VR, Augmented Reality--AR, Video on Demand--VoD, Video Stream), monetization, and geographic location [109; 111; 112]. The _Multi-Provider Network Slice Selector_ is indifferent to the technique used to mark packets in gNodeB. That is, our architecture assumes that a software instance based on widely used solutions, such as Segment Routing, Multi-Protocol Label Switching, and/or definitions of IPv6 classes of service, have already marked (labeled) the packets [113]. Therefore, our framework only identifies and collects the QoS, QoE, and MOS parameters, processes them, and, from there, defines which NS best meets those requirements  
Figure 5: Proposed Multi-Provider Network Slice Selector Framework. or in case of non-existence, signals to the _Network Slice Definition_ block, the parameters for instancing the slice at run time (already in the cloud). Regarding the _Processor_ Module, several strategies can be used.