# A Next-Generation Core Network Architecture for Mobile Networks
## 8 Scalability  
Due to the very large amount of connected devices that a network operator has to manage (also of the order of 100 million), a _statically_ assigned dedicated core network to each UE might easily lead to scalability problems. Our architecture overcomes this issue by assigning a VCN to a UA only for a limited amount of time. After the UA comes back to the _idle_ state and persists for a while, the UA is connected back to its SN, while the VCN is destroyed. As shown in Section 11, this mechanism drastically improves the scalability.  
A VCN instance can be created on a physical node by using one of the following mechanisms: VMs, containers, clear containers [33], or separated processes. The choice of the mechanism to use depends on different factors and usually it is a trade-off between scalability and isolation.  
Running VCN instances simply through different _processes_ maximizes, of course, the scalability, but it guarantees very little isolation. From a security point of view, this solution requires a very high level of trust (and protection) of the underlying OS. For this reason, the choice of this solution will strongly depend on the type of network and system which VCNs have to be deployed in and on the corresponding threat model.  
A solution based on _containers_ guarantees higher isolation than processes, while it still very easy to deploy and performs very well in terms of scalability with respect to other virtualization mechanisms. The main drawback is that it still relies on a high level of trust in the underlying OS. Moreover,a particular attention must be payed to the rights assigned to the various containers: a container with root privileges may compromise the security of all other containers running on the machine.  
A possible alternative is the use of _clear containers_ that provide the same characteristics and properties in terms of flexibility and scalability with respect to traditional containers, while they guarantee stronger isolation, of the same level of classical VM, by exploiting various kernel level features and CPU support. From a scalability point of view, results have shown that a clear container can be launched in less than 150 ms and has a memory footprint of about 20 MB, allowing the running up to 3500 clear containers on a single machine with 128 GB of RAM. (Source: [[https://clearlinux.org/features/clear-containers](https://clearlinux.org/features/clear-containers)]([https://clearlinux.org/features/clear-containers](https://clearlinux.org/features/clear-containers))) Although it cannot be considered yet as a \"large scale\" solution yet, it is very promising since it seems to combine the best of two opposite approaches, i.e., \"classical\" containers and VMs.  
In terms of isolation, the strongest solution is the use of classical _VMs_. Unfortunately, it comes at the cost of higher CPU and memory consumption, leading to a limited scalability. However, for scenarios with a small user population, this solution can be attractive too. Moreover, in some cases, a combination of these different mechanisms can be also considered: for example, containers running in VMs.  
Another parameter that has to be taken into account is the delay in setting-up the VCN. Amongst the four different mechanisms, the one that may require longer set-up time is the use of VMs. In order to reduce this delay, a technique similar to the thread-pool pattern used in multi-threaded programming can be used. A pool of idle VMs containing an already configured VCN can be maintained by each SN. Then, when a new VCN is requested, the SN has just to load the UE state and data into one VM (HSS data, billing, etc.) and make the VM reachable.  
Some measurement results will be shown in Section 11, together with some consideration on scalability and other issues related to real-world mobile networks.