# Fog Computing: Enabling the Management and Orchestration of Smart City Applications in 5G Networks
## 3 A Fog-Based Management and Orchestration Framework for 5G Smart Cities
### System Architecture Overview
#### 3.2.3 Cloud Node System Architecture  
The architecture of the CN is essentially the same of the FN. However, CN functionalities are different since the CN is responsible for the global management and control operations in the network. The CN is mainly responsible for the following operations:  
* Software updates of VNFs or NSs on the FNs;
* Coordination and control of FNs;
* Global data analysis operations;
* Overall QoS and Service Level Agreements (SLAs) monitoring;
* Applying the global network behavior indicated by network administrators;  
Fog Protocol: Enabling Exchange of Application Service Information between Fog Nodes and the Cloud Layer  
In the presented framework, each FN will communicate with the other FNs and with the CN in the cloud layer in order to exchange resource provisioning information. To the best of our knowledge, no suitable way to provide the exchange of this kind of information between the fog and the cloud layer is available in literature. This is still a key research challenge in the fog computing domain. By taking into account the main advantages of fog computing architectures, which are minimized latency and reduced bandwidth use, a suitable fog protocol should be lightweight, transport agnostic and customizable, since QoS parameters must be selected according to the requested application. This way, the fog protocol should be able to cope with the requirements introduced by the different IoT use cases, such as low-power communication devices, low bandwidth data links, low latency communications and high mobility scenarios. The allocation of smart city application composed of micro-services with delay-sensitive requirements must be reactive if the device that is requesting the application is moving through the network area. This will imply a need for fast service migrations, which can be achieved if messages are exchanged between the multiple FNs with information regarding services and applications. This way, each FD module can decide where and when it is more suitable to deploy and instantiate each instance of the micro-services composing the smart city application since the application service topology information of the network will be known by the different FNs. Therefore, in the presented framework, an application layer fog protocol based on a lightweight version of the OSPF [37] routing protocol for the exchange of application service information between FNs and the cloud layer is proposed. OSPF provides routing functionality within the same domain. It was designed to optimize the propagation of topological changes in the network. Our goal is to use a lightweight application layer protocol based on the advantages of OSPF to propagate the application service logic information in the network, such as micro-service allocations and migrations, so that each FN knows exactly the application service topology, i.e., what and where each micro-service is allocated. This way, application service information can be shared among FNs similar to P2P networks. In fact, the foreseen fog protocol is a hierarchical application layer P2P networking protocol based on the advantages of OSPF. In Figure 8, a topology scenario of our fog protocol is presented. By using a fog protocol based on the advantages of OSPF, it will be possible to achieve rapid decisions related to the resource provisioning in smart cities, based on the exchange of application service tables. Each instance of applications and services have a unique ID allowing one to know exactly which instance is allocated to a certain FN. Each FN has an Internet Protocol (IP) address, IPv4 or IPv6, and also a unique ID. These attributes are transmitted as headers on the application service tables. These application service tables enable the exchange of resource operational information allowing the FD module to provide fast decisions on the resource provisioning because the overall network service allocation will be known by each fog node system, and therefore, decisions on service migrations can be achieved in a timely manner.