# A Flexible Infrastructure-Sharing 5G Network Architecture Based on Network Slicing and Roaming
## 3 Proposed Architecture
### Architecture Implementation
#### 3.2.2. Implemented System  
Taking into account the chosen software tools and computational resource limitations, a basic scenario was developed to implement and validate the proposed solution. According to the proposed conceptual architecture (Figure 2), the RAN should support multiple PLMNs to simulate their sharing. However, since the UERANSIM RAN simulator does not have this capability, we virtualized an instance of UERANSIM for each client in a different VM.  
Regarding the CNs, compared to the conceptual architecture proposed, the interfaces implemented by Open5 GS are limited to the authentication of the UE. This means that only the AMF interacts with the operator's CN for UE authentication and that it does not include the necessary connections between the SMF and this CN for updating and verifying authentications. Regarding the slicing envisaged in the proposed conceptual architecture, there were also some changes in the implemented architecture due to some limitations of Open5 GS. Therefore, only the NFs SMF and UPF are part of each client's slice. Finally, issues of billing policies, resource distribution, and QoS management are not addressed in this paper. In the current architecture implementation, each slicing is manually configured using the functionalities provided by Open5 GS. This tool supports slicing and NFs creation by changing the configuration files of Open5 GS, and a service restart is required to apply the new settings and NFs.  
Figure 5 illustrates the simplified implemented architecture, which consists of different instances of VMs wherein each client has a dedicated UERANSIM instance within a dedicated VM, and their number is contingent on the number of clients. The core networks of the operators were implemented in the same VM as the neutral host core, as the Open5 GS does not require their separation.  
To demonstrate the development of the implemented architecture, highlighting the configuration of virtual machines and the software used in interactions between different parts of the system, a basic scenario was designed. This scenario considers both types of clients: operator and non-operator. Figure 5 presents the implemented system, as well as the VMs used and the interactions between them.  
Figure 6 presents a more detailed illustration of the implemented architecture, emphasizing the used VMs and their interactions. This scenario, which was used on the tests presented in Section 4, includes up to four clients: one operator client and up to three non-operator clients, as well as four SMFs and UPFs. This figure represents the most comprehensive architecture employed in the tests, the places where the UERANSIM VMs were used, and the SMF-UPF pairs for each slice, which are proportional to the number of clients.  
All the VMs used run the Ubuntu 20.04 operating system. The VM with the neutral host core has two CPU cores, 2 GB of RAM, and 20 GB of storage, while the VMs with UERANSIM are equipped with one CPU core, 1 GB of RAM, and 15 GB of storage.  
Figure 5: Architecture of the implemented system.