# UAV Support for Mission Critical Services
## VMCS Concept
### VMCS Orchestration
#### 5.2.2 VMCS Edge Orchestration
* _Edge Connectivity Agent (ECA)_. This is a component of each Edge node that is responsible for the reliable delivery of orchestration and management messages between the Edge nodes. * _Edge Functions Migration Agent (EFMA)_. This is a component of the distributed Edge orchestrator that is responsible for decisions regarding migration Edge Virtual Functions (EVF) and functions of the distributed orchestrator, i.e., VOP, ERO and EIME. For the sake of reliability, multiple instances of EFMA are allowed. * _Edge Infrastructure Monitoring Entities (EIME)_. EIME is a set of entities that keeps the information about the infrastructure resources' state and location. They also try to predict the resource state based on historical data. In the case of mobile Edge nodes, EIME obtains their position, and at the request of ERO, can change it. For the sake of reliability, there are multiple synchronised EIME instances. * _Edge Reliable Orchestrator (ERO)_. This logical entity is responsible for the orchestration process. It interacts with EIME to obtain information about the state of resources. Based on the VMCS service template analysis and the state of resources, it deploys Edge Virtual Functions (EVFs). For reliability, there are multiple synchronised ERO instances in the system. * _Edge Virtual Functions (EVFs)_. These functions implement the required VMCS services in the Edge and are part of the service template. Please note that part of the Service can be implemented in a Fog and/or in a Cloud. * _Edge Operator Portal (EOP)_. The Edge Operator Portal is the functionality that allows the operator to interact with the Edge platform. It can be used to monitor Edge status and to enforce some Edge node actions, including the definition of mobile nodes' position. Logically it is a single entity but, for the sake of reliability, can be implemented as a set of multiple, synchronised components with assigned priorities of operations. It is assumed that for interactions between components a message bus will be used. The VMCS solution has to use some mechanisms that provide reliable services implemented in unreliable environments. They are responsible for intelligent management of the template instance, implementing the idea of self-managed network slices [57]. Their functionalities include self-configuration of a service/slice, reconfiguration of a service/slice, healing of the service, optimising service behaviour due to mobility of nodes and triggering an orchestration event when needed. Each of the services assesses the quality of the infrastructure resources and takes decisions regarding the placement of service functions. The functions' placement is complemented by the application-level routing that improves the connectivity reliability between them. The reliability of services is also provided by having replicas of service functions and databases. Each service should be written that way that it can work autonomously with marginal interaction with other services, even if the network is partitioned. The 'Service Reliability Mechanisms' can be different for each service, as each service node may have different requirements. It is proposed to separate resource orchestration from service orchestration and built-in the service orchestration capabilities in each of the deployed services. As already discussed, a UAV may play multiple roles in MCS. All the UAV roles described in Scenarios 1 and 2 apply to VMCS. In VMCS, however, a UAV may play an additional function; a UAV can transport the role of a'mobile server'. Such a'mobile server' is an infrastructure element that provides computing and storage capabilities (combined with connectivity) that can be added to the infrastructure resources to deploy the required application(s). Please note that UAV functionalities can be pre-programmed before the flight.