## 3 Proposed Virtualized Network Function Orchestration System
### Cluster Management Method for the Arrangement of VNFs  
This paper proposes a form of arranging service in a dynamic way as a 5G network with cluster composition for virtualized network function arrangement based on dynamic network composition. As explained above, since a Docker is lighter than the existing virtual machine, it is suitable for use in the proposed method to compose a system using open-source hardware. However since a container is activated with the process, it cannot provide functions like virtual machines when relocation or movement is conducted. Virtual machines, when restarted from the stopped condition, can provide continuity by starting from the stopped point; but in the case of a container, since it needs to start from the very beginning, it cannot provide continuity, which is a deficiency. The proposed virtualized network function orchestration system explains the method of providing continuity for the container and through this, it presents a method that has low overhead and provides service continuity. The proposed method based on the Docker virtualized platform, network resource sharing between devices using a Docker swarm and load monitoring, locates network functions. When actions such as relocation are committed, a method is proposed for restarting from the point at which the process stopped by reporting the action status. As seen in the network configuration method above, the roles of the master and member nodes is the same and the Docker swarm manager container is created at the master node while, at member nodes, the Docker swarm agent container is distributed. While the existing Docker swarm recognition method is a Docker-hub-based online method, the proposed method achieves recognition offline through IP, replacing the IP information given during network setting. Figure 8: Mesh net controller mutual recognition and information exchange procedure. As shown in Table 1, through the Docker swarm API, although the master can obtain other network device information, it is not suitable to judge the network status using the number of containers. In the status quo, the information that we can gain from the Docker swarm is limited; so, in order to achieve flexible container location and movement, a module that can check CPU usage at each node is needed. Therefore, as shown in Figure 9, member nodes help in the configuration of a cluster with the previously proposed module and Docker swarm agent and, through cluster node monitoring, it can monitor CPU usage and report to the master node when there is an error. When a member node notifies that CPU usage is over a given limit, by collecting the status of each node, the master node moves the container to the node at which the error occurred to the optimal node so that it can continually provide network function. To achieve this, the master node is operated as depicted in Figure 10 (as previously proposed), with a Docker swarm master and a cluster service controller. The proposed operating procedure is shown in Figure 11. Firstly, every node implements the cluster node monitoring module and checks its own CPU usage at set times. The master node waits for error message reports from member nodes and prepares for incoming messages by opening a port. If, as in process 1, the CPU loading rate exceeds a threshold value at some nodes, process 2's error message is reported to the master node. In the error message, the container's last status needs to be written and sent. At this time, the master node sends the request message regarding CPU loading information to the all nodes and then receives messages from the responding nodes, leading to a search