Amarisoft MME + Open5GS

The purpose of this tutorial is to show you how to setup an opensource 5G Core called Open5GS on a local Virtual Machine and how to use it as a whole or in combination with Amarisoft Core (mme). The main motivations for this tutorial are as follows :

• Demonstrate a use case where Amarisoft RAN works with a Non-Amarisoft Corenetwork
• Demonstrate a use case where Amarisoft RAN works with a heterogenously composed core network. By heterogeneously componsed core network, I mean the some components of the corenetwork is from Amarisoft and some other components are from non-Amarisoft component.

NOTE : This is just an example (Proof of Concept demo) of utilization of non-Amarisoft corenetwork with Amarisoft RAN or Amarisoft Core network, we are not following up or supporting any technical issues of non-Amarisoft Product.

Table of Contents

• Amarisoft MME + Open5GS
• Introduction
• Summary of the Tutorial
• Test Setup
• Key Configuration Parameters
• Configuration
• Virtual Machine
• Open5GS
• Open5GS - User DataBase
• Callbox
• UEsim
• Test 1 : Amari gNB + Open5GS
• Configuration
• Open5gs
• Callbox
• Perform the Test
• Log Analysis
• Test 2 : Amari gNB + Amari MME + n12 + Open5GS AUSF
• Configuration
• Open5gs
• Callbox
• Perform the Test
• Log Analysis
• Test 3 : Amari gNB + Amari MME + n8/n12 + Open5GS AUSF,UDM
• Configuration
• Open5gs
• Callbox
• Perform the Test
• Log Analysis
• Test 4 : Amari gNB + Amari MME + n8/n13 + Open5GS UDM
• Configuration
• Open5gs
• Callbox
• Perform the Test
• Log Analysis

Introduction

Open5GS is a widely adopted open-source implementation of the 5G core network architecture, designed to provide a comprehensive, standards-compliant foundation for next-generation mobile networks. Built using robust modular principles, Open5GS supports both 4G (EPC) and 5G (5GC) core functionalities, enabling seamless integration with a variety of radio access network (RAN) solutions, including those from Amarisoft. The core network architecture includes critical components such as the Access and Mobility Function (AMF), Session Management Function (SMF), User Plane Function (UPF), and more, each responsible for distinct aspects of connectivity, session management, mobility, and policy enforcement. By deploying Open5GS on a local virtual machine, users can simulate real-world 5G deployments, experiment with network slicing, and validate interoperability with third-party RAN or core components—such as integrating Amarisoft's RAN or combining Open5GS with specific Amarisoft core elements like the MME. This flexibility is essential for research, prototyping, and proof-of-concept demonstrations, making Open5GS a critical tool in the evolving 5G ecosystem. Its role extends to facilitating heterogeneous network topologies, where components from different vendors interoperate to deliver end-to-end mobile connectivity. The significance of such configurations lies in their ability to validate multi-vendor deployments, encourage innovation, and reduce vendor lock-in—key objectives in modern telecom infrastructure. Through this tutorial, you will gain practical experience in setting up, configuring, and testing an open-source 5G core network, while also exploring hybrid integration scenarios with Amarisoft products, further enhancing your understanding of contemporary mobile network architectures.

• Context and Scope
  • Open5GS provides an open-source, standards-based 5G core network that supports both LTE/EPC and 5G/5GC functionalities.
  • The tutorial demonstrates interoperability between Amarisoft RAN and a non-Amarisoft core network (Open5GS).
  • It explores hybrid network architectures where components from Amarisoft and non-Amarisoft sources coexist in the core network.
  • Focuses on proof-of-concept scenarios for demonstrating multi-vendor network integration.
• Relevance and Importance
  • Multi-vendor interoperability is a cornerstone of modern 5G deployments, enabling flexibility and innovation.
  • Open5GS offers a cost-effective, transparent way to understand and experiment with 5G core concepts.
  • Prototyping heterogeneous network setups helps validate deployment strategies for real-world networks.
  • Enables researchers, developers, and engineers to gain hands-on experience with advanced network topologies without proprietary restrictions.
• Learning Outcomes
  • Understand the architecture and deployment of an open-source 5G core network using Open5GS.
  • Acquire skills in setting up and managing core network components on a local virtual machine.
  • Learn to integrate Amarisoft RAN with Open5GS, as well as mix Amarisoft and non-Amarisoft core network elements.
  • Gain insight into troubleshooting and validating multi-vendor interoperability in a controlled environment.
• Prerequisite Knowledge and Skills
  • Familiarity with basic networking and virtualization concepts.
  • Understanding of cellular network fundamentals (e.g., concepts of RAN, core, interfaces).
  • Basic experience with Linux command-line operations and system administration.
  • Optional: Prior exposure to 4G/5G technology, network functions, or related open-source projects.

Summary of the Tutorial

This tutorial provides a comprehensive guide for testing various integration scenarios between Amarisoft RAN components (gNB, MME) and Open5GS Core Network elements using Amarisoft UEsim as the test UE. The document covers test setup, key configuration parameters, common configurations, and detailed step-by-step procedures for four primary test cases. All original formatting, indentation, and structure are preserved below.

• Test Setup Overview
  • Amarisoft UEsim is used as the Test UE for increased flexibility in SIM and network slicing configuration.
  • Open5GS is deployed in a Virtual Machine running Ubuntu Server 20.04.
  • Amarisoft gNB and, in some scenarios, Amari MME, are deployed as RAN and partial Core Network elements.
• Key Configuration Steps (Common to All Tests)
  • Virtual Machine setup with network interfaces configured to avoid subnet issues.
  • Open5GS installation and verification; configuration files located under /etc/open5gs, logs under /var/log/open5gs.
  • Subscriber information managed through Open5GS WebUI, enabling addition and modification of UE profiles.
  • Callbox network interface configured to match the test environment’s IP scheme.
  • UEsim configuration aligned with Open5GS UE DB, including USIM, APN, and network slicing parameters.

• Test 1: Amari gNB + Open5GS (Full Core)
  • Configuration:
    • Modify only three Open5GS configuration files from default; all other settings remain unchanged.
    • Restart relevant Open5GS components after configuration changes:

      $ sudo systemctl restart open5gs-amfd
      $ sudo systemctl restart open5gs-upfd
      $ sudo systemctl restart open5gs-udmd
                              

    • Callbox uses gnb-sa-open5gs.cfg (copied and modified from gnb-sa.cfg).
    • Callbox MME uses default configuration.
  • Test Procedure:
    • Restart LTE service on callbox and verify gNB configuration. Cell configuration is flexible.
    • Check gNB’s connection to Open5GS core on the virtual machine.
    • Restart LTE service on UEsim and power on the UE.
    • Verify successful UE registration and IP assignment.
    • Confirm connection via callbox commands ('t', 'ue').
    • Test data connectivity by pinging the UE from the callbox.
• Test 2: Amari gNB + Amari MME + n12 + Open5GS AUSF
  • Configuration:
    • Modify the same three Open5GS configuration files as in Test 1; restart components as needed.
    • Callbox gNB uses gnb-sa.cfg without modification.
    • Callbox MME uses mme-ims-open5gs-n12.cfg (modified from mme-ims.cfg); this enables n12 interface towards Open5GS AUSF.
  • Test Procedure:
    • Restart LTE service on callbox and verify gNB configuration.
    • Ensure gNB is connected to Amari MME, which in turn connects to Open5GS AUSF over n12.
    • Restart LTE service on UEsim and power on the UE.
    • Confirm UE registration and IP assignment.
    • Validate connection on the callbox using 't' and 'ue' commands.
• Test 3: Amari gNB + Amari MME + n8/n12 + Open5GS AUSF, UDM
  • Configuration:
    • Same Open5GS configuration modifications as previous tests.
    • Callbox gNB uses gnb-sa.cfg unchanged.
    • Callbox MME uses mme-ims-open5gs-n12-n8.cfg (modified from mme-ims.cfg) to enable both n12 (AUSF) and n8 (UDM) connectivity towards Open5GS.
  • Test Procedure:
    • Restart LTE service on callbox and verify gNB setup.
    • Ensure gNB is connected to Amari MME, which uses n12/n8 towards Open5GS AUSF/UDM.
    • Restart LTE service on UEsim and power on the UE.
    • Check for successful registration and IP assignment.
    • Confirm UE connection using callbox commands.
• Test 4: Amari gNB + Amari MME + n8/n13 + Open5GS UDM
  • Configuration:
    • Consistent Open5GS configuration adjustments as in previous tests.
    • Callbox gNB uses gnb-sa.cfg without changes.
    • Callbox MME uses mme-ims-open5gs-n8-n13.cfg (modified from mme-ims.cfg) to enable n8/n13 interfaces towards Open5GS UDM.
  • Test Procedure:
    • Restart LTE service on callbox and confirm gNB configuration.
    • Validate gNB’s connection to Amari MME, which connects to Open5GS UDM via n8/n13.
    • Restart LTE service on UEsim and power on the UE.
    • Verify that UE registers and receives IP address.
    • Use callbox commands to check UE connection status.

General Test Methodology:

• Each test involves configuring the appropriate elements (Open5GS, gNB, MME, UEsim) as per the scenario.
• After configuration changes, associated services are restarted to apply updates.
• UE registration, connectivity, and data path are verified using both network-side logs and callbox commands.
• Sample logs and screenshots are referenced to validate each step of the process.

This structured approach allows for isolation and verification of individual network functions (AUSF, UDM) and their integration with Amarisoft and Open5GS components across different reference point interfaces (n8, n12, n13).

Test Setup

Test setup for this tutorial is as shown below.  I assume that you would know on how to setup the Virtual Machine and run an instances of operating system (Ubuntu in this tutorial) and I would not explain on the procedure of those installation procedure.

This setup shows a simple private 5G test environment built to verify the operation of Open5GS together with an Amarisoft radio access network and a test UE. The system is organized so that the radio network, the core network, and the management host run on separate machines but are connected through the same local IP network.

The Amarisoft Callbox machine works as the radio access node. In this setup it runs the gNB together with the MME functionality and provides the NR radio interface over the air. The Callbox is connected to the local network and communicates with the core network through the IP interface. The Callbox uses the address 192.168.100.17.

The UE side is implemented using Amarisoft UEsim running on a separate PC. This machine behaves like a real user device and connects to the gNB over the air interface. It allows flexible configuration of parameters such as network slicing and subscriber information, which is useful because Open5GS does not support the XOR based 3GPP test USIM algorithm used by many commercial test UEs. The UEsim PC has the address 192.168.100.15, and once the connection is established the UE IP address is assigned by the network.

The core network runs Open5GS on an Ubuntu Server instance. This server provides the 5G core network functions and manages subscriber authentication, session management, and user plane connectivity. The Open5GS server is reachable through the local network at IP address 192.168.100.32.

A Windows host machine is used as the control and management system. It is connected to the same WiFi network and runs a virtual machine that hosts the Ubuntu server for Open5GS. This machine is mainly used to access the Open5GS environment, configure the system, and monitor the behavior of the network components. The Windows host uses IP address 192.168.100.10.

All machines are connected through the same local network, typically through a WiFi router. The router provides simple IP connectivity so that the Callbox, the Open5GS server, the UE simulator, and the management host can communicate with each other. In operation, the UE simulator attaches to the gNB provided by the Callbox, the gNB communicates with the Open5GS core network through the IP network, and the Open5GS server manages the overall registration and session procedures. This arrangement allows basic end to end testing of a private 5G network using software based components.

NOTE : In this tutorial, I used Amarisoft UEsim as a Test UE instead of commercial UE. The main reason is becaue Open5GS does not support 3GPP Test USIM algorithm (XOR) and (as far as I have observed) Network Slicing configuration doesn't seem to be very flexible (so I need a test UE in which I can change Network Slicing Configuration as it can be accepted by open5gs).

NOTE : We are not testing Open5GS in detail and are not following up with the revisions and upgrade of Open5G, I would suggest you to consult to Open5GS forum / support for any issues related to Open5GS.

Key Configuration Parameters

Followings are important configuration parameters for this tutorial. You may click on the items for the descriptions from Amarisoft documents.

• gtp_addr
• mme configuration
• n8
• api_root
• bind_addr
• n12
• api_root
• bind_addr
• n13
• api_root
• bind_addr
• UEsim Configuration
• sim_algo
• imsi
• opc
• amf
• sqn
• K
• apn
• attach_pdn_type
• default_pdu_session_snssai
• sst
• sd
• default_nssai
• sst
• sd

Configuration

In this section, I will show the configurations for various components in the test setup that will be commonly used for every test cases in this tutorial.  The configurations that is specific to each test case will be described in the configuration section under each test case.

Virtual Machine

The virtual machine that I used is the Virtual Box but I think you can use any type of Virtual Machine, but (as of Jun 2022) it seems that open5gs is running OK only on Ubuntu Server 20.04 (I have tried it later release : 2204 but the installation of open5gs didn't go through).

In this setup the Open5GS core network runs inside a virtual machine. The virtual machine is created on a Windows 10 host using VirtualBox. This allows the core network environment to run independently from the host operating system while still being able to access the same local network.

The host computer runs Windows 10 and acts as the main management machine. Inside this host, VirtualBox is used to create a virtual machine that runs Ubuntu Server. The Ubuntu system is where Open5GS is installed and executed. By using a virtual machine, the core network can be configured and modified without affecting the host operating system.

In this tutorial the virtual machine uses VirtualBox version 6.1 and runs Ubuntu Server 20.04.3 LTS. At the time of the experiment this version worked reliably with Open5GS. Later Ubuntu releases such as 22.04 were tested but the Open5GS installation did not complete successfully, so Ubuntu 20.04 was selected as the stable environment for the core network.

This arrangement allows the Open5GS core network to operate as if it were running on a dedicated Linux server while still being managed conveniently from the Windows host system. The virtual machine simply becomes another node on the local network and communicates with the gNB and UE simulator through its assigned IP address.

In this setup the network interface of the virtual machine is configured in a way that the VM behaves like a normal device on the same physical network. The key point is that the adapter is set to bridged mode instead of using NAT or host-only networking.

When the virtual machine is attached as a bridged adapter, it connects directly to the physical network through the host’s network interface. This means the Ubuntu server running inside the VM can obtain an IP address from the same subnet as the other devices such as the Callbox, the UE simulator, and the router. As a result, all components can communicate with each other directly without any additional routing or port forwarding.

If NAT mode were used, the VM would be placed behind a separate internal network created by VirtualBox. In that case the Open5GS server would have a different subnet and the gNB or UE would not be able to reach it properly, which often leads to connection failures or GTP/NAS signaling issues.

By using bridged mode, the Open5GS server becomes a peer node on the same LAN. This removes most of the common IP related problems such as unreachable core network functions, incorrect routing paths, or mismatched subnets. This configuration is especially important in telecom testing environments where multiple nodes must exchange signaling and user plane traffic directly over IP.

Some OS related information that I used in this tutorial is as shown below.  This screenshot shows the operating system environment used for the Open5GS setup in this tutorial. The system runs Ubuntu Server 20.04.3 LTS, which was selected because it provides stable compatibility with Open5GS and related networking components.

The command lsb_release -a is used to verify the Linux distribution information. The result indicates that the system is Ubuntu with release version 20.04 and codename focal. This confirms that the system belongs to the Ubuntu 20.04 LTS series, which is commonly used for server environments due to its long-term support and stable package repository.

The command uname -a displays detailed information about the running kernel and system architecture. The output shows that the system is using a Linux kernel from the 5.4 series and is running on an x86_64 architecture. This means the system is operating on a 64-bit platform, which is the standard environment for modern server deployments and virtualization platforms.

The command uname -r is used to check the exact kernel version currently running on the system. In this setup the kernel version is 5.4.0-120-generic. This kernel version is part of the default Ubuntu 20.04 distribution and provides the necessary networking and system support required for running the Open5GS core network and related components.

These commands are useful for verifying that the operating system environment matches the expected configuration before proceeding with the installation and testing of the Open5GS system.

This is not manadatory if you install Binary version of the open5gs. This step shows the version of the GNU C Compiler installed on the Ubuntu system. The command gcc --version is used to verify the compiler version available in the environment.

In this setup the system uses GCC version 9.4.0, which is the default compiler provided with Ubuntu 20.04. This compiler is required only if Open5GS is built from source code. During source compilation, the GCC compiler is used to build the various Open5GS components and libraries.

If the binary package of Open5GS is installed directly from the repository, this step is not mandatory because the software has already been compiled. However, it is still useful to confirm that a proper compiler environment exists in case additional modules or related software need to be compiled later.

Checking the compiler version is a common practice when preparing a development or build environment because some telecom software components depend on specific compiler capabilities and library compatibility.

Open5GS

I assume that you know how to install open5gs and would not explain about the detailed installation procedure. If you are not familiar with open5gs installation procedure, refer to the QuickStart of Open5gs official site or a note in sharetechnote.

Once you successfully installed the open5gs on the virtual machine, you would get the configuration as shown below.  Once Open5GS is successfully installed and started on the Ubuntu server, multiple core network functions will run as independent processes. The command ps aux | grep open5gs is used to verify that these services are running properly in the system.

The output shows several Open5GS components running simultaneously. Each component corresponds to a specific function of the 5G core network and is executed as a separate process. These processes are launched from the /usr/bin directory and each one loads its configuration from a corresponding YAML file located in /etc/open5gs.

For example, the AMF process handles access and mobility management, the SMF manages PDU session control, and the UPF manages the user plane data forwarding. Other components such as NRF, AUSF, UDM, UDR, and PCF handle service registration, authentication, subscriber data management, and policy control. In addition, functions such as BSF and NSSF support service discovery and network slicing related operations.

When the Open5GS system is running correctly, all of these processes should appear in the process list. Each process runs in the background and continuously waits for signaling messages from other network functions or from the radio access network.

This command is a simple way to confirm that the Open5GS core network has started correctly and that all required network functions are active before attempting to connect the gNB and UE to the system.

The NIC and IP configuration after the installation of open5gs on the virtual machine is as shown below. After installing and starting Open5GS on the Ubuntu virtual machine, the network interface configuration can be verified using the ifconfig command. This command shows the available network interfaces and their assigned IP addresses.

The interface enp0s3 represents the main network interface of the virtual machine. Because the VM is configured with a bridged adapter, this interface receives an IP address directly from the WiFi router or access point. In this setup the interface is assigned the address 192.168.100.32 with the subnet mask 255.255.255.0. This means the Open5GS server becomes a normal device on the same local network as the Callbox, UE simulator, and other hosts.

The output also shows the loopback interface lo. This interface is used internally by the operating system for local communication within the machine. It uses the address 127.0.0.1 and is not visible to other devices on the network.

Another important interface shown in the output is ogstun. This interface is created automatically by Open5GS when the user plane function starts. It acts as a virtual tunnel interface used for routing UE data traffic between the core network and external networks. In this setup the ogstun interface is assigned the address 10.45.0.1 with a subnet mask of 255.255.0.0.

When a UE successfully attaches to the network and establishes a PDU session, the UE will receive an IP address from this tunnel network. User plane traffic from the UE is then forwarded through this ogstun interface so that it can reach other networks or the internet.

By checking the ifconfig output, it is possible to confirm that the main network interface is correctly connected to the local network and that the ogstun tunnel interface required by Open5GS has been created successfully.

Following is the directory (/etc/open5gs) where the configuration files of open5gs are located.  The configuration files of Open5GS are located in the directory /etc/open5gs. This directory contains the YAML configuration files for each network function that makes up the 5G core network.

Each network function runs as an independent process and reads its configuration from its corresponding YAML file. For example, amf.yaml contains the configuration for the Access and Mobility Management Function, smf.yaml contains the configuration for the Session Management Function, and upf.yaml defines the parameters for the User Plane Function. Other files such as nrf.yaml, ausf.yaml, udm.yaml, udr.yaml, and pcf.yaml configure the service based architecture components that manage authentication, subscriber data, service registration, and policy control.

Some configuration files correspond to EPC components such as mme.yaml, sgwc.yaml, sgwu.yaml, and hss.yaml. These are included because Open5GS supports both LTE EPC and 5G core network functions in the same software package.

All of these files are written in YAML format and define important parameters such as interface addresses, ports, database connections, and inter-network function communication settings. When each Open5GS service starts, it loads the corresponding YAML file from this directory to determine how the network function should operate.

This directory therefore acts as the central location where the behavior and connectivity of the entire Open5GS core network is defined and configured.

Following is the directory (/var/log/open5gs) where the log files of open5gs are stored. The log files of Open5GS are stored in the directory /var/log/open5gs. This directory contains runtime logs generated by each network function while the system is operating.

Each network function writes its own log file independently. For example, amf.log records the signaling and procedures handled by the AMF, smf.log shows session management related activities, and upf.log contains user plane data handling information. Other files such as nrf.log, ausf.log, udm.log, and pcf.log provide detailed traces of service registration, authentication, subscriber data access, and policy control operations.

These log files are continuously updated while the Open5GS processes are running. They capture important events such as UE registration, authentication procedures, session establishment, and error conditions. This makes them essential for debugging and understanding the behavior of the core network.

In a typical test scenario, when the UE attempts to attach to the network, you can monitor amf.log to track the registration procedure, check smf.log for session creation, and observe upf.log to confirm that user plane traffic is flowing correctly. If any issue occurs, these logs provide detailed information that helps identify the root cause.

This directory therefore serves as the main place for monitoring and troubleshooting the Open5GS system during setup and testing.

Open5GS - User DataBase

Before configuring subscriber information in Open5GS, it is important to verify that the Open5GS WebUI service is running properly. The WebUI provides a graphical interface that allows the user to manage the subscriber database and configure UE related parameters.

The command sudo systemctl status open5gs-webui.service is used to check the current status of the WebUI service. If the service is running correctly, the output will show that the service is active and running. This indicates that the WebUI backend server has started successfully.

In this setup the WebUI service is implemented using a Node.js based server. The process runs the script server/index.js and listens on port 3000. Once the service starts successfully, it prints a message indicating that the system is ready and accessible through [http://localhost:3000](http://localhost:3000).

If the WebUI service is installed but not running, it can be started or restarted using the command sudo systemctl restart open5gs-webui.service. After starting the service, the WebUI can be accessed through a web browser, which allows the user to add subscriber profiles, configure IMSI information, and manage other user related parameters required for UE registration.

This WebUI interface is commonly used during testing because it simplifies the process of managing the Open5GS subscriber database without directly editing configuration files or database records.

After confirming that the Open5GS WebUI service is running, the next step is to add subscriber information to the Open5GS user database. This can be done through a web browser using the WebUI interface(If you are not familiar with WebUI setup, refer to this note from sharetechnote).

The WebUI is accessed by opening a browser and navigating to the address [http://127.0.0.1:3000](http://127.0.0.1:3000) from the Open5GS server. Once connected, the Open5GS dashboard appears and provides several management menus on the left side such as Subscriber, Profile, and Account.

To register a UE in the system, subscriber information must be added through the Subscriber menu. When the database is empty, the interface shows that there are no subscribers registered yet. A new subscriber can be added by selecting the Add a Subscriber option or clicking the plus button displayed on the screen.

After selecting this option, the user can enter the required subscriber parameters such as IMSI, authentication key, OP or OPc value, and other network related settings. These parameters must match the configuration used by the UE or the UE simulator. Once the subscriber entry is saved, the information is stored in the Open5GS database and the core network will be able to authenticate and register the UE when it attempts to attach to the network.

This WebUI interface provides a convenient way to manage subscriber data without directly modifying database entries or configuration files, which makes it especially useful during testing and experimentation.

Then, Select the Subscriber menu from the left panel. This menu is used to manage the list of UEs that are allowed to register with the Open5GS core network. When the database is empty, the main screen indicates that there are no subscribers configured yet.

To create a new subscriber entry, click the ADD A SUBSCRIBER button or press the plus icon shown on the lower right side of the screen. This action opens the subscriber configuration page where the UE parameters can be entered.

In this configuration page, you will define the subscriber identity and authentication parameters such as IMSI, authentication key, and operator parameters. These values must match the configuration used by the UE or the UE simulator so that the network can authenticate the device correctly during the registration procedure.

After entering the required parameters and saving the configuration, the subscriber entry will be stored in the Open5GS database. Once this step is completed, the UE will be able to register to the network and establish a data session through the core network.

When the Add Subscriber button is selected in the Open5GS WebUI, the Edit Subscriber page appears. This page allows the user to define the parameters required for UE authentication and service configuration.

The first field is IMSI, which represents the unique identity of the subscriber. This value must match the IMSI configured in the UE or in the UE simulator. The network uses this identifier to locate the subscriber profile in the database during the registration procedure.

The Subscriber Key (K) field contains the secret authentication key stored in the USIM. This value is used during the authentication process between the UE and the core network. The Authentication Management Field (AMF) defines the authentication algorithm related parameters used during the authentication procedure.

The USIM Type parameter specifies whether the operator key is provided as OP or OPc. In most test setups OPc is used because it is easier to configure directly. The Operator Key field contains the OP or OPc value used together with the subscriber key during the authentication process.

The UE-AMBR Downlink and UE-AMBR Uplink parameters define the aggregate maximum bit rate allowed for the subscriber. These values limit the maximum data rate that the UE can achieve for downlink and uplink traffic.

All of these parameters must match the configuration used by the UE or the UE simulator. Once the information is entered and saved, the subscriber profile is stored in the Open5GS database. When the UE attempts to register to the network, the AMF retrieves this subscriber information and uses it to perform authentication and authorize network access.

Further down in the subscriber configuration page, additional parameters define the network slice and session configuration for the UE. These parameters determine how the UE is allowed to access the network and what type of data session it can establish.

The Slice Configuration section defines the S-NSSAI information assigned to the subscriber. The SST parameter represents the Slice/Service Type, which identifies the type of service slice that the UE is allowed to use. In most basic test setups SST value 1 is used, which corresponds to the standard eMBB type slice. The SD field represents the Slice Differentiator and can be used to distinguish between multiple slices of the same type. The Default S-NSSAI option indicates that this slice will be used as the default slice for the subscriber.

The Session Configuration section defines the data session parameters that will be used when the UE establishes a PDU session. The DNN or APN field specifies the data network name that the UE will connect to. In many test configurations the value internet is used. The Type field specifies the IP protocol type assigned to the UE, such as IPv4, IPv6, or dual stack.

The 5QI or QCI field defines the default QoS profile associated with the session. A value of 9 is commonly used for normal data traffic in test environments. The ARP Priority Level defines the allocation and retention priority used when the network decides whether to accept or reject a session request.

The Capability and Vulnerability parameters control whether the session can preempt other sessions or be preempted by higher priority traffic. In most basic test setups these values are left disabled.

After configuring these parameters, selecting the Save button stores the subscriber profile in the Open5GS database. Once the profile is saved, the UE with the matching IMSI and authentication parameters can successfully register to the network and establish a data session through the configured slice and DNN.

After saving the subscriber configuration, the new subscriber entry appears in the Subscriber list of the Open5GS WebUI. This page shows the list of all subscriber profiles currently stored in the Open5GS database.

Each entry in the list represents a UE that is allowed to access the network. The entry is typically displayed using the IMSI value, which acts as the unique identifier of the subscriber. In this example the subscriber with IMSI 001010000000001 has been successfully added to the system.

From this page the user can quickly verify that the subscriber has been registered in the database. The WebUI also allows the user to select an existing subscriber entry to edit the configuration or remove it if necessary.

Once the subscriber profile appears in this list, the Open5GS core network is ready to authenticate the UE with the corresponding IMSI and authentication parameters. When the UE or UE simulator attempts to register to the network through the gNB, the AMF retrieves this subscriber information from the database and performs the authentication and registration procedure.

If you need to modify the configuration of an existing subscriber, the Open5GS WebUI provides an edit function directly from the subscriber list page.

In the Subscriber list, each subscriber entry is displayed using the IMSI value. When you move the mouse pointer over the subscriber entry, additional control icons appear next to the IMSI. One of these icons is the Edit option.

By selecting the Edit icon, the subscriber configuration page opens again. This page allows you to change any of the subscriber parameters such as authentication keys, slice configuration, session configuration, or QoS related settings.

After updating the required fields, the changes can be saved and the new configuration will be stored in the Open5GS database. The updated parameters will then be used by the core network when the UE performs authentication, registration, or session establishment procedures.

This editing capability is useful during testing because it allows the user to quickly adjust subscriber parameters without removing and recreating the entire subscriber entry.

When the Edit option is selected for an existing subscriber, the same subscriber configuration page is displayed again with all previously saved values already filled in. This allows you to review and modify the current configuration without creating a new entry.

The IMSI field remains fixed because it represents the unique identity of the subscriber. Other parameters such as Subscriber Key, AMF, Operator Key, and UE-AMBR values can be updated depending on the test scenario. For example, you may change the authentication parameters if you update the UE configuration, or adjust the AMBR values to test different throughput limits.

After making the required changes, selecting Save updates the subscriber information in the Open5GS database. The modified parameters will then be applied during the next registration or session establishment procedure of the UE.

This editing process is useful when tuning configurations during testing, especially when you need to align the core network settings with changes made on the UE or UE simulator side.

Callbox

This section shows the network configuration of the Amarisoft Callbox used in the setup. The Callbox acts as the gNB and connects to the Open5GS core network through its Ethernet interface.

The interface eno1 is the main network interface of the Callbox(the interface name would vary depending on the system that you are using). It is configured with the IP address 192.168.100.17 and subnet mask 255.255.255.0. This address is assigned by the WiFi router or access point and places the Callbox in the same subnet as the Open5GS server and the UE simulator. This common subnet is important because all components need direct IP connectivity for signaling and user plane communication.

This IP address is also used in the Callbox configuration file. Specifically, it is set as the gtp_addr in the enb or gNB configuration. This parameter defines the IP address used for GTP-U communication between the radio access network and the core network. If this address is incorrect or does not match the actual interface IP, the user plane data path will not function properly.

The loopback interface lo is also shown in the output. This interface is used for internal communication within the Callbox and is not involved in external network communication.

In practice, the exact IP address of the Callbox may differ depending on the local network environment. Therefore, all related configuration files in the Callbox and Open5GS must be updated accordingly to match the actual IP addresses used in the test setup.

(NOTE : The IP address of the NIC of the callbox would be different in your test setup. You should change the IP addresses in each of the configurations for each test according to the IP of your own test setup)

UEsim

This section shows the configuration used for the UE simulator in the test environment. In this setup Amarisoft UEsim is used as the test UE instead of a commercial device. The same UE configuration is reused for all test cases in this tutorial so that the core network behavior can be tested consistently.

The directory listing shows several UE configuration files available in the UEsim configuration directory. Among them, the file ue.cfg is the main configuration file that the simulator loads when it starts. In this setup ue.cfg is linked to the file ue-nr-sa-open5gs.cfg, which means the simulator will use this configuration when running the UE.

This configuration file defines the UE identity and network parameters that must match the subscriber information configured in Open5GS. It typically contains parameters such as the IMSI, authentication key, operator key, and other UE related settings required for the registration and authentication procedure.

Other configuration files shown in the directory are example configurations for different scenarios, such as LTE multi-UE testing or reference configurations for LTE channels. However, for this tutorial the UE simulator is configured specifically for NR standalone operation with Open5GS, so the ue-nr-sa-open5gs.cfg configuration is used.

By linking ue.cfg to this configuration file, the UE simulator always starts with the correct parameters required to connect to the Open5GS core network used in this test environment.

This configuration file defines the UE parameters used by the Amarisoft UE simulator. The file ue-nr-sa-open5gs.cfg is created by copying the reference configuration ue-nr.cfg and modifying it to match the subscriber information configured in the Open5GS database.

The ue_list section defines the identity and authentication parameters of the simulated UE. The sim_algo parameter is set to milenage, which is the authentication algorithm used by Open5GS. The imsi value identifies the subscriber and must match the IMSI configured in the Open5GS subscriber database.

The authentication parameters opc, amf, and K define the security credentials used during the authentication procedure. The opc value represents the operator key derived value used together with the subscriber key K. The amf parameter specifies the authentication management field, and the sqn parameter represents the sequence number used in the authentication process. All of these parameters must match the values configured in the Open5GS WebUI subscriber configuration.

The UE capability section defines general capabilities of the simulated UE. The as_release parameter indicates the supported 3GPP release version, and ue_category specifies the type of radio capability used by the UE.

The apn parameter defines the data network name that the UE will request during the session establishment procedure. In this configuration the value internet is used, which matches the default DNN configuration in Open5GS. The attach_pdN_type parameter specifies the IP type requested by the UE, which is set to IPv4 in this setup.

The default_pdu_session_snssai parameter defines the network slice that the UE will request when establishing a PDU session. The sst value is set to 1, which corresponds to the default eMBB slice configuration used in the Open5GS setup. The default_nssai section lists the slices supported by the UE, and in this configuration the UE is configured to request the slice with SST value 1.

By aligning the UE simulator configuration with the subscriber database and slice configuration in Open5GS, the UE can successfully authenticate with the core network and establish a PDU session through the configured slice and data network.

Test 1 : Amari gNB + Open5GS

In this test, I will show you a case where Amarisoft callbox is used as 5G/NR RAN only and Open5GS as a whole core network (i.e, AMF + AUSF + UDM + SMF + UPF and everything else).

Configuration

The configuration for Open5gs and callbos are as shown below.

Open5gs

In this test scenario only a small number of parameters in the Open5GS configuration are modified from the default installation. Most of the Open5GS configuration files remain unchanged, and only the parameters required for communication with the Amarisoft gNB are updated.

 

One of the modified files is amf.yaml. This file defines the configuration of the Access and Mobility Management Function. The AMF is responsible for UE registration, mobility management, and control plane signaling between the gNB and the core network.

The sbi section defines the Service Based Interface used for communication between core network functions. The address and port specify where the AMF exposes its service interface to other network functions inside the core network.

The ngap section defines the IP address used for communication between the gNB and the AMF through the NG control plane interface. In this setup the address is configured as 192.168.100.32, which corresponds to the IP address of the Open5GS server. The Amarisoft gNB will use this address to establish the NGAP connection to the AMF.

The guami section defines the Globally Unique AMF Identifier used by the network. The PLMN information includes the MCC and MNC values that identify the mobile network. These values must match the PLMN configuration used in the gNB and UE configuration.

The tai section defines the Tracking Area Identity supported by the AMF. The PLMN and TAC values identify the tracking area in which the UE is allowed to register.

The plmn_support section specifies which PLMN and network slice combinations are supported by the network. In this configuration the network supports the slice with SST value 1, which corresponds to the default slice used in this test setup.

The security section defines the preferred order of integrity and ciphering algorithms used during the security procedure between the UE and the network.

These parameters ensure that the AMF configuration matches the PLMN, slice, and IP addressing used by the Amarisoft gNB and UE simulator in the test environment.

Another configuration file modified in this test setup is upf.yaml. This file defines the configuration of the User Plane Function in the Open5GS core network.

The pfcp section specifies the address used for PFCP communication between the SMF and the UPF. PFCP is the protocol used to control user plane forwarding rules. In this configuration the PFCP interface is bound to the local loopback address.

The gtpu section defines the IP address used for GTP-U communication. This is the interface that carries the actual user data between the gNB and the UPF. In this setup the address is configured as 192.168.100.32, which corresponds to the IP address of the Open5GS virtual machine. The Amarisoft gNB sends user plane traffic to this address during data session operation.

The subnet section defines the IP address pool that will be assigned to UEs when they establish a PDU session. In this configuration the IPv4 subnet 10.45.0.1/16 is used. When a UE successfully attaches and establishes a session, it will receive an IP address from this subnet. The configuration also includes an IPv6 prefix that can be used if IPv6 sessions are enabled.

These parameters ensure that the user plane traffic from the gNB is correctly forwarded through the UPF and that UE devices receive IP addresses from the configured subnet.

The third configuration file modified in this setup is udm.yaml. This file defines the configuration of the Unified Data Management function in the Open5GS core network.

The UDM is responsible for handling subscriber related information such as authentication data, subscription profiles, and mobility related parameters. It communicates with other core network functions through the Service Based Interface.

In this configuration the sbi section defines the address and port used by the UDM service. The address is set to 192.168.100.32, which corresponds to the IP address of the Open5GS virtual machine. This allows other network functions inside the core network to reach the UDM service through the same network interface used by the system.

The port number is configured as 8888. In this tutorial the port numbers of the Open5GS components are adjusted so that each network function uses a unique IP and port combination. This helps clearly separate the services and avoids possible conflicts between different components running on the same machine.

By configuring the UDM service to use the correct IP address and a dedicated port, the other core network functions such as the AMF and AUSF can correctly access subscriber data during authentication and registration procedures.

After modifying any Open5GS configuration file, the corresponding network function must be restarted so that the new configuration is applied. Open5GS components run as system services, so restarting the service reloads the updated YAML configuration.

In this setup three configuration files were modified, so the related services must be restarted. The AMF service is restarted to apply the changes made in amf.yaml. The UPF service is restarted to load the updated parameters defined in upf.yaml. The UDM service is restarted to apply the configuration changes in udm.yaml.

This is done using the systemctl restart command for each component. Once the services restart successfully, the updated configuration becomes active and the network functions will operate using the new parameters. Restarting the services is an important step because configuration changes do not take effect until the associated processes are restarted.

$ sudo systemctl restart open5gs-amfd $ sudo systemctl restart open5gs-upfd $ sudo systemctl restart open5gs-udmd

Callbox

In this test, gnb-sa-open5gs.cfg is used as gNB configuration and it is copied and modified from gnb-sa.cfg.

For mme, no special configurations are used. Everything is used as default configuration.

The configuration in gnb-sa-open5gs.cfg  are set as follows. This configuration shows the key parameters defined in the file gnb-sa-open5gs.cfg used by the Amarisoft gNB. This file configures how the gNB connects to the Open5GS core network.

The amf_list section defines the address of the AMF used for NGAP signaling. The parameter amf_addr specifies the IP address of the AMF running on the Open5GS server. In this setup the value is configured as 192.168.100.32, which corresponds to the IP address assigned to the network interface of the virtual machine running Open5GS. When the gNB starts, it uses this address to establish the NG control plane connection with the AMF.

The gtp_addr parameter defines the IP address used by the gNB for GTP-U communication. This address corresponds to the Ethernet interface of the Amarisoft Callbox that connects to the local network. In this setup the address is configured as 192.168.100.17, which is the IP assigned to the NIC of the Callbox PC. This interface is used for exchanging user plane traffic between the gNB and the UPF in the core network.

The configuration also includes the gNB identity parameters. The gnb_id_bits parameter defines the number of bits used to represent the gNB identifier, and the gnb_id parameter specifies the actual identifier value of the gNB. These values uniquely identify the base station within the network.

By configuring the AMF address and the GTP bind address correctly, the Amarisoft gNB can establish both control plane and user plane connections with the Open5GS core network.

Perform the Test

In this step the LTE service on the Amarisoft Callbox is restarted and the basic configuration of the gNB is verified. After restarting the service, the cell status can be checked from the Callbox console to confirm that the base station is running correctly.

The output shows the physical cell configuration currently active on the gNB. It displays parameters such as the PLMN identifier, the gNB ID, the radio band, bandwidth, ARFCN, and other radio settings. In this example the PLMN is configured as 00101 and the gNB identifier is set to 0x12345.

The table also shows the downlink and uplink radio configuration. The cell operates in NR band n78 with a bandwidth of 20 MHz. The ARFCN value defines the center frequency used by the cell. Other parameters such as antenna configuration, subcarrier spacing, and modulation capability are also displayed.

The SSB section shows the synchronization signal block configuration used by the UE during cell search and initial access. The SCS value indicates the subcarrier spacing used for synchronization signals.

For this particular test the detailed radio configuration of the cell is not critical. The purpose of this test is to verify the integration between the Amarisoft gNB and the Open5GS core network. Therefore the cell can be configured using any reasonable radio parameters as long as the UE can detect the cell and attempt to connect to it.

After the gNB is started, the next step is to verify that it has successfully connected to the Open5GS core network. This can be checked from the Callbox console using the NG interface status command.

The output shows the NG connection state between the gNB and the AMF. The server field indicates the IP address and port of the AMF that the gNB is connected to. In this setup the address 192.168.100.32 corresponds to the Open5GS server running on the virtual machine.

The state value setup_done indicates that the NGAP connection between the gNB and the AMF has been successfully established. This means that the control plane signaling path is working correctly and the gNB is now registered with the core network.

The PLMN value shown in the output confirms that both the gNB and the core network are using the same network identifier. This is important because a mismatch in PLMN configuration would prevent the connection from being established.

When this state is confirmed, it indicates that the integration between the Amarisoft gNB and the Open5GS core network is functioning properly at the control plane level.

After confirming that the gNB is connected to the core network, the next step is to start the UE simulator and power on the UE. This is done by restarting the LTE service on the UE simulator and issuing the power_on command.

When the UE powers on, it begins the initial cell search procedure. During this process the UE scans the radio spectrum to detect available cells and attempts to synchronize with the broadcast signals transmitted by the gNB.

The output shows the message indicating that the UE has detected the cell and successfully decoded the system information. The message Cell 0: SIB found means that the UE has received and decoded the System Information Block broadcast by the gNB. This confirms that the UE has successfully synchronized with the cell and obtained the basic configuration parameters required for further procedures.

Once this step is completed, the UE can proceed with the registration process with the 5G core network through the gNB.

Once the UE completes the registration and session establishment procedures, the UE status can be checked from the UE simulator console.

The output shows that the UE is in the running state and the EMM state is registered. This indicates that the UE has successfully completed the registration procedure with the core network and is now fully attached to the system.

The RRC state running means that the UE has an active radio connection with the gNB. This confirms that both the radio link and the control plane signaling are working correctly.

The most important part is the IP_ADDR field. In this example the UE is assigned the IP address 10.45.0.2. This address is allocated from the subnet configured in the UPF, which was defined as 10.45.0.0/16 in the Open5GS configuration.

This result confirms that the UE has successfully established a PDU session and that the user plane path between the UE, gNB, and UPF is functioning properly. At this point the UE is able to send and receive data through the Open5GS core network.

After the UE successfully registers to the network, the connection status can also be verified from the Amarisoft Callbox console. This can be done using the t command and the ue command.

The t command enables the trace display for the active radio connection. Once the trace is started, the Callbox shows real time radio information related to the connected UE. The output includes parameters for both downlink and uplink transmission such as CQI, RI, MCS, retransmissions, throughput, and signal quality measurements like SNR. It also shows information related to PRACH access, timing advance, and other radio link indicators. These values confirm that the UE is actively communicating with the gNB over the air interface.

The ue command displays the list of UEs currently connected to the gNB. The output shows identifiers such as RAN_UE_ID, CN_UE_ID, the serving cell ID, and the RNTI assigned to the UE. This confirms that the UE has an active radio connection with the gNB and is recognized by the base station.

By checking both the trace information and the UE list on the Callbox, it is possible to verify that the UE is successfully connected at the radio level and that the communication between the UE and the gNB is functioning properly.

After the UE is successfully registered and assigned an IP address, the end to end connectivity can be verified using a simple ping test from the Callbox.

In this step, the ping command is executed toward the UE IP address 10.45.0.2. This IP address was assigned to the UE from the UPF subnet during the PDU session establishment.

The output shows that ICMP echo requests are sent from the Callbox and responses are received from the UE. Each line indicates a successful round trip communication with measured latency values. This confirms that packets are successfully transmitted through the full user plane path.

The data path in this case flows from the Callbox to the UPF over GTP-U, then through the ogstun interface inside Open5GS, and finally reaches the UE. The response follows the reverse path back to the Callbox.

Successful ping results indicate that the user plane is fully operational. This means the UE, gNB, and Open5GS core network are correctly integrated and data traffic can flow end to end.

Log Analysis

Sample Log

This log shows the signaling trace captured from the Amarisoft Web GUI during the connection procedure between the gNB and the Open5GS core network.

 

The log shows the NGAP signaling messages exchanged between the gNB and the AMF. Initially the gNB establishes a TCP connection toward the AMF running on the Open5GS server at IP address 192.168.100.32. After the transport connection is established, the NG interface setup procedure begins.

The message NG Setup Request is sent from the gNB to the AMF. This message contains information about the gNB such as its identity, supported PLMN, and supported network slices. The purpose of this message is to register the gNB with the core network.

After receiving this request, the AMF processes the information and sends back an NG Setup Response message. This response confirms that the gNB has been successfully accepted by the core network and that the NG interface is now established.

Once this procedure is completed, the gNB becomes part of the 5G network and can begin serving UEs. At this point UE registration and session establishment procedures can proceed through the NG interface between the gNB and the AMF.

This trace shows the signaling procedure that occurs when the UE registers to the 5G network. The log includes messages from different protocol layers such as RRC, NAS, and NGAP.

The procedure begins with the RRC connection establishment between the UE and the gNB. The UE sends an RRC Setup Request, and the gNB responds with RRC Setup. After the radio connection is established, the UE sends the Registration Request message through the NAS layer. This message contains the UE identity and registration information required by the core network.

The gNB forwards the NAS message to the AMF using the NGAP Initial UE Message. The AMF then begins the authentication procedure by sending an Authentication Request to the UE through the Downlink NAS Transport message. The UE processes the challenge and sends an Authentication Response back to the network.

Once authentication is completed, the security procedure begins. The AMF sends a Security Mode Command to establish encryption and integrity protection between the UE and the network. After the UE responds with Security Mode Complete, secure communication between the UE and the core network is established.

The network then performs capability exchange procedures. The AMF requests the UE capability information, and the UE responds with its supported radio features. This information allows the network to determine the appropriate configuration for the UE.

After these steps, the AMF sends a Registration Accept message to confirm that the UE has successfully registered to the network. The gNB may also send RRC Reconfiguration messages to configure the UE radio parameters for normal operation.

Finally the Initial Context Setup procedure is completed between the gNB and the AMF. This step prepares the radio and core network resources required for the UE session. Once these procedures are finished, the UE becomes fully registered and ready to establish data sessions through the network.

This trace shows the procedure after the UE registration, focusing on PDU session establishment and user plane data transfer.

After the UE is registered, the network proceeds with session setup. The AMF sends signaling through NGAP and NAS to initiate the PDU session. This is shown by the Downlink NAS transport carrying session related information and the PDU session resource setup request sent from the AMF to the gNB.

The gNB configures the radio resources and responds with RRC reconfiguration. The UE applies the configuration and sends RRC reconfiguration complete. At this point the radio bearer for user data is established.

Following this, the Initial Context Setup and PDU session setup procedures are completed. This creates the user plane path between the UE, gNB, and UPF. The GTP-U tunnel is established using TEIDs exchanged between the gNB and the UPF.

After the session is established, the trace shows multiple GTP-U packets. These packets correspond to actual user data traffic flowing through the network. In this example the packets are ICMP messages, which match the ping test performed earlier. The source and destination IP addresses show traffic between the Callbox and the UE IP address 10.45.0.2.

Finally, the trace shows the deregistration procedure. The UE sends a Deregistration Request, and the network responds by releasing the UE context. The UE context release command and complete messages indicate that the connection between the UE and the network has been properly terminated.

This trace confirms the full lifecycle of the UE connection, including registration, session establishment, data transfer, and release, demonstrating that both control plane and user plane are functioning correctly.

Test 2 : Amari gNB + Amari MME + n12 + Open5GS AUSF

In this test, I will show you a case where Amarisoft callbox is used as 5G/NR RAN  and most part of 5G Core except AUSF. The AUSF of open5gs works together with Amari MME via n12 interface .

In this test, the Amarisoft Callbox is used not only as the 5G NR radio access network but also to provide most of the core network functions. In this setup the Amarisoft system handles the majority of the core network, while Open5GS is used only for a specific function.

The key difference from the previous test is that the AUSF function is provided by Open5GS, while the remaining core network components such as AMF, SMF, and UPF are handled by the Amarisoft MME and related components. The integration between the Amarisoft core and the Open5GS AUSF is done through the n12 interface.

In operation, the UE connects to the Amarisoft gNB over the radio interface. The Amarisoft core network manages the registration and session procedures, but when authentication is required, it communicates with the Open5GS AUSF over the n12 interface. The AUSF performs the authentication procedure using the subscriber data configured in Open5GS.

This setup demonstrates a hybrid deployment where part of the 5G core network is implemented by Amarisoft and a specific network function is offloaded to Open5GS. It shows how different implementations of 5G core components can interoperate using standardized interfaces such as n12.

Configuration

The configuration for Open5GS and Callbox is as shown below.

Open5gs

In this test configuration, only a few parameters of Open5GS are modified from the default configuration. Most of the settings remain unchanged. The purpose of these changes is mainly to align the Open5GS configuration with the Amarisoft Callbox environment.

The first modification is in the SBI configuration. The SBI address is set to 127.0.0.5 and the port is changed to 7777. The port number is modified so that each Open5GS network function can use a unique IP and port combination without conflict.

The NGAP section defines the interface used for communication between the AMF and the gNB. The address is configured as 192.168.100.32, which corresponds to the IP address assigned to the NIC of the virtual machine running Open5GS. This allows the Amarisoft gNB to establish an NGAP connection to the AMF.

The GUAMI section defines the global identifier of the AMF. The PLMN is configured with MCC 001 and MNC 01. The AMF identifier is composed of region value 2 and set value 1. These parameters allow the UE and the network to uniquely identify the serving AMF.

The TAI configuration specifies the Tracking Area Identity used by the network. The PLMN values again use MCC 001 and MNC 01, and the tracking area code is set to 1. This configuration must match the tracking area configuration used by the gNB.

The PLMN support section indicates which network and slice the AMF supports. The slice configuration specifies SST value 1, meaning that the network supports the default slice.

The security section defines the priority order of integrity and ciphering algorithms. The integrity algorithms are NIA2, NIA1, and NIA0, while the ciphering algorithms are NEA0, NEA1, and NEA2.

Finally, the network name and AMF name are configured as Open5GS and open5gs-amf0. These values are mainly used for identification and logging purposes within the core network.

This configuration shows the basic settings of the UPF component in Open5GS. Only a few parameters are modified so that the UPF can properly communicate with the Amarisoft system and allocate IP addresses to the UE.

The PFCP section defines the control plane interface used between the SMF and the UPF. The address is set to 127.0.0.7, which means that PFCP signaling is handled locally inside the virtual machine where the Open5GS core is running.

The GTP-U section defines the user plane interface used for data tunneling between the gNB and the UPF. The address is configured as 192.168.100.32. This is the IP address assigned to the NIC of the virtual machine running Open5GS. The gNB sends user plane packets to this address using the GTP-U protocol.

The subnet section defines the IP address pool that will be assigned to the UE devices. In this configuration the IPv4 subnet is set to 10.45.0.1/16. When a UE successfully registers and establishes a PDU session, the UPF allocates an IP address from this range.

An IPv6 prefix is also defined as 2001:db8:cafe::1/48. This allows the network to support IPv6 addressing for UE devices if required.

Overall, this configuration ensures that the UPF can receive GTP-U traffic from the gNB and correctly allocate IP addresses for connected UEs.

This configuration shows the basic settings of the UDM component in Open5GS. Only a small modification is made from the default configuration to adapt the system to the test environment.

The SBI section defines the service-based interface used for communication between the UDM and other core network functions such as the AMF and AUSF. In this configuration, the address is set to 192.168.100.32, which corresponds to the IP address assigned to the NIC of the virtual machine running the Open5GS core network.

The port number is configured as 8888. In this tutorial, the port number is intentionally changed from the default so that each Open5GS network function can use a unique IP and port combination. This helps avoid conflicts between different services running on the same host.

With this configuration, the UDM becomes reachable by other network functions through the service-based interface using the specified IP address and port. This allows subscriber data and authentication-related information to be exchanged correctly during UE registration and authentication procedures.

Whenever you modify the configuration of a network component, the corresponding service must be restarted so that the new configuration can take effect.

In this setup, configuration files for several Open5GS components were modified. Therefore the related services need to be restarted using systemctl. The commands shown restart the AMF, UPF, and UDM services of Open5GS.

Restarting open5gs-amfd reloads the AMF configuration and reinitializes the NGAP and SBI interfaces used to communicate with the gNB and other core network functions. Restarting open5gs-upfd reloads the UPF configuration so that the updated GTP-U interface and UE IP address pool settings are applied. Restarting open5gs-udmd reloads the UDM configuration so that the updated SBI address and port settings are activated.

After these services are restarted, the Open5GS core components will run with the updated configuration and will be ready to accept new connections from the gNB and UE.

$ sudo systemctl restart open5gs-amfd $ sudo systemctl restart open5gs-upfd $ sudo systemctl restart open5gs-udmd

Callbox

In this test,  gnb-sa.cfg is used without any change.

For mme, mme-ims-open5gs-n12.cfg is used. It is copied and modified from mme-ims.cfg.

The configuration in gnb-sa.cfg  are set as follows. This configuration shows the basic gNB settings used to connect the Amarisoft gNB to the core network.

The amf_list section defines the address of the AMF that the gNB will connect to through the NGAP interface. In this configuration the AMF address is set to 127.0.1.100. This means the gNB will establish the NGAP signaling connection with the AMF running at this address. If the AMF runs on another host, this address must be changed to the IP address of that machine.

The gtp_addr parameter defines the IP address used by the gNB for the GTP-U user plane interface. This address represents the Ethernet interface connected to the core network. In this example it is configured as 127.0.1.1, which indicates that the user plane interface is running locally on the same system. If the UPF runs on a different host, this address should be updated accordingly.

The gnb_id_bits parameter defines the number of bits used for the gNB identifier. In this configuration the value is set to 28 bits, which is a common setting for identifying the base station within the PLMN.

The gnb_id parameter defines the actual identifier of the gNB. In this example the ID is configured as 0x12345. This value is used by the network to uniquely identify the gNB during signaling procedures such as NG setup and UE context management.

The configuration in mme-ims-open5gs-n12.cfg  is set as follows. This configuration shows the key parameters used when Amarisoft MME communicates with the Open5GS AUSF through the n12 interface.

The gtp_addr parameter defines the GTP-U bind address used by the Amarisoft system. In this configuration it is set to 127.0.1.100. This means the user plane GTP-U interface is bound to a local interface so that the Amarisoft components such as ltemme and lteenb can run on the same machine. By default the S1AP SCTP connection also uses the same address.

The n12 section defines the interface used for communication between the Amarisoft core and the Open5GS AUSF. This interface is used during the authentication procedure.

The api_root parameter specifies the address of the AUSF service. In this configuration it is set to [http://192.168.100.32:7777](http://192.168.100.32:7777). This corresponds to the IP address and port configured for the SBI interface of the AUSF in Open5GS. When the Amarisoft MME needs to perform authentication, it sends requests to this API endpoint.

The bind_addr parameter defines the local address used by the Amarisoft system to initiate the n12 connection. In this configuration it is set to 192.168.100.17, which corresponds to the IP address of the NIC on the Callbox machine.

The remaining parameters define basic network identifiers. The plmn parameter is set to 00101, which represents MCC 001 and MNC 01. The mme_group_id and mme_code parameters are identifiers used by the MME to uniquely identify itself within the network. These values are used during procedures such as UE attachment and mobility management.

Perform the Test

First restart the LTE service on the Callbox and verify that the basic gNB configuration is running correctly. For this test, the detailed radio configuration is not critical. The cell can be configured with any valid parameters.

After restarting the service, you can check the physical cell configuration using the 'cell phy' command in the Callbox console. The output shows the current radio configuration of the gNB.

The log indicates that the system is running with PLMN 00101 and the gNB identifier set to 0x12345. The cell is configured in NR band n78 with a bandwidth of 20 MHz and subcarrier spacing of 30 kHz. The downlink and uplink ARFCN values are both set to 632628, while the SSB is transmitted at ARFCN 632544.

The output also shows additional parameters such as the number of antennas, modulation order, and other radio settings. These parameters confirm that the NR cell is active and properly configured.

This step verifies that the gNB is operating normally before proceeding with the core network connectivity and UE registration tests.

Next check the core network connection that the gNB is using. This can be verified with the `ng` command in the Callbox console.

The output shows the NG connection state of the gNB. In this example the gNB is connected to the core network server at address 127.0.1.100 using port 38412. Port 38412 is the default SCTP port used for NGAP communication between the gNB and the AMF.

The status 'state=setup_done' indicates that the NG setup procedure between the gNB and the AMF has been successfully completed. This means the NGAP signaling connection is fully established and the gNB is registered with the core network.

The PLMN value shown as 00101 confirms that both the gNB and the core network are operating under the same PLMN configuration.

This step verifies that the signaling interface between the gNB and the core network is working correctly before attempting UE registration.

After confirming that the gNB is connected to the core network, restart the LTE service on the UE simulator and power on the UE.

When the UE powers on, it starts the initial access procedure. The UE scans the radio environment, detects the cell, and attempts synchronization with the gNB.

The message Cell 0: SIB found indicates that the UE has successfully detected the cell and decoded the System Information Block. This confirms that the UE has synchronized with the gNB and obtained the necessary system information such as PLMN, cell configuration, and access parameters.

Once this step is completed, the UE is ready to proceed with the registration procedure toward the core network through the gNB.

If the connection procedure is completed successfully, the UE should appear in the UE list of the Callbox with a valid registration state and an assigned IP address.

This can be checked using the 'ue' command in the UE simulator console. The output shows the status of the connected UE.

The RRC_STATE value 'running' indicates that the radio connection between the UE and the gNB is active. The UE has completed the RRC connection setup and is operating in normal connected mode.

The EMM_STATE value 'registered' confirms that the UE has successfully completed the registration procedure with the core network. This means the authentication, security setup, and registration procedures have all been completed.

The IP_ADDR field shows the IP address assigned to the UE. In this example the UE is assigned the address 192.168.3.2. This address is allocated during the PDU session establishment and allows the UE to send and receive user plane data through the network.

This output confirms that the UE has successfully attached to the network and is ready for data communication.

You can further confirm the UE connection status from the Callbox console using the 't' command and the 'ue' command.

The 't' command starts the trace display. This trace shows the real-time radio activity between the gNB and the UE. The output includes parameters such as CQI, MCS, SNR, throughput, and other uplink and downlink statistics. These values indicate the current radio link quality and transmission performance.

The trace also shows the PRACH information at the beginning. This confirms that the UE successfully performed the random access procedure and established the initial connection with the gNB.

The table that follows displays the uplink and downlink transmission statistics. Parameters such as CQI, MCS, and bitrate provide an indication of the radio conditions and the amount of data being transmitted between the UE and the network.

You can also run the 'ue' command on the Callbox. This command displays the list of connected UEs managed by the gNB. The output shows the RAN UE identifier, the corresponding core network UE identifier, the serving cell, and the RNTI assigned to the UE.

From the output shown, the UE with RAN_UE_ID 1 is connected to Cell 0x001 and is assigned RNTI 0x4601. This confirms that the UE is properly connected to the gNB and that the UE context is successfully established in the RAN.

Log Analysis

Sample Log

This log shows that the gNB is connected to the MME running on the local PC. In this setup, the Amarisoft MME is used as the core network component.

When the gNB starts, it attempts to establish a signaling connection with the MME using the NGAP interface over SCTP. The log shows that the gNB first attempts to connect to the server at address 127.0.1.100 on port 38412. Port 38412 is the standard SCTP port used for NGAP communication between the gNB and the core network.

After the SCTP connection is established, the gNB sends an NG Setup Request message to the MME. This message contains information about the gNB such as the Global RAN Node ID, the gNB identifier, and the supported tracking area list.

The MME processes this request and responds with an NG Setup Response. This response confirms that the core network accepts the gNB and allows it to operate within the network.

Once the NG Setup procedure is completed, the signaling connection between the gNB and the MME becomes active. From this point onward, the gNB can forward UE registration messages and other control plane signaling to the core network through the MME.

This log therefore confirms that the gNB has successfully established its control plane connection with the Amarisoft MME running on the local PC.

N12 is communicating with open5gs in the virtual machine. This trace shows how the Amarisoft core network communicates with the Open5GS AUSF through the n12 interface during the UE authentication procedure.

After the UE sends the Registration Request, the Amarisoft MME handles the NAS signaling and extracts the authentication related information. Instead of performing authentication locally, it forwards the request to the Open5GS AUSF using the n12 interface.

The log shows N12 messages where HTTP requests are sent to the AUSF endpoint at 192.168.100.32:7777. This corresponds to the SBI address configured in Open5GS. The request includes authentication information derived from the UE such as the SUCI or IMSI.

The AUSF processes the request and responds with HTTP status 200. This indicates that the authentication procedure has been successfully handled. The AUSF generates the authentication vectors and returns the required parameters to the Amarisoft core network.

After receiving the response from the AUSF, the Amarisoft MME continues the standard NAS authentication procedure with the UE. It sends the Authentication Request to the UE, receives the Authentication Response, and proceeds with the security setup.

This trace clearly shows the separation of roles in this test setup. The Amarisoft system handles most of the core network functions, while Open5GS is used specifically for the AUSF role. The interaction over the n12 interface confirms that different implementations of 5G core functions can interoperate using standardized service-based interfaces.

All other part except N12 are communicating with the core running on the local PC which is Amari MME. This trace shows that all signaling procedures except the N12 authentication interface are handled by the Amarisoft MME running on the local PC.

After the UE begins the registration procedure, the gNB forwards NAS signaling to the Amarisoft MME through NGAP. The MME processes most of the control plane procedures including security setup, capability exchange, and registration handling.

The log shows several internal service-based communications inside the Amarisoft core network. Interfaces such as N8 and N17 appear in the trace. These are internal SBI communications between different network functions running in the Amarisoft core environment.

For example, N17 messages are used when the core retrieves UE security capabilities. The N8 interface is used to access subscriber data from the UDM. The trace shows HTTP requests such as '/nudm-uecm' and '/nudm-sdm', which are used to retrieve UE context and subscription data.

These communications occur locally using the loopback address 127.0.1.100, indicating that the Amarisoft core functions are running on the same machine.

The registration procedure then continues normally. The MME sends Security Mode Command to the UE, receives Security Mode Complete, retrieves the UE capabilities, and finally sends Registration Accept.

This trace confirms the architecture used in this test. The Amarisoft MME handles almost all core network signaling locally, while only the authentication function is delegated to the Open5GS AUSF through the N12 interface.

Test 3 : Amari gNB + Amari MME + n8/n12 + Open5GS AUSF,UDM

In this test, I will show you a case where Amarisoft callbox is used as 5G/NR RAN  and most part of 5G Core except {AUSF, UDM}. The {AUSF,UDM} of open5gs works together with Amari MME via n12/n8 interface .

In this test, the Amarisoft Callbox is used as the 5G NR RAN and also provides most of the 5G core network functions. However, two core network functions are implemented using Open5GS instead of the Amarisoft core.

In this configuration, the AUSF and UDM functions are provided by Open5GS. These components handle authentication and subscriber data management. The remaining core network components continue to run on the Amarisoft system.

Communication between the Amarisoft MME and the Open5GS components is performed through the standardized service-based interfaces. The n12 interface is used for communication between the MME and the AUSF during the authentication procedure. The n8 interface is used for communication between the MME and the UDM to retrieve subscriber data and other user-related information.

During UE registration, the Amarisoft MME coordinates the overall procedure. When authentication is required, it sends requests to the Open5GS AUSF over the n12 interface. When subscriber data is needed, it communicates with the Open5GS UDM over the n8 interface.

This setup demonstrates a hybrid deployment where Amarisoft handles the majority of the core network functions while Open5GS provides the authentication and subscriber data management functions. It also illustrates how different implementations of 5G core components can interoperate using standardized interfaces such as n12 and n8.

Configuration

The configuration for Open5GS and Callbox is as shown below

Open5gs

In this test setup, the Open5GS configuration remains mostly the same as in the previous scenarios. Only a few parameters are modified to align with the Amarisoft environment and to support the interaction over n8 and n12 interfaces.

The AMF configuration defines the service-based interface and the NGAP interface. The SBI address is set to 127.0.0.5 with port 7777 so that the Open5GS services can communicate internally using unique IP and port combinations. The NGAP address is configured as 192.168.100.32, which corresponds to the IP address of the virtual machine running Open5GS.

The GUAMI configuration defines the identity of the AMF. The PLMN is set to MCC 001 and MNC 01, and the AMF identifier is defined using region 2 and set 1. These values must match the configuration used by the Amarisoft system and the UE.

The TAI configuration defines the tracking area supported by the network. It uses the same PLMN values and a TAC value of 1. This ensures that the UE can register within the correct tracking area.

The PLMN support section defines the supported slice configuration. In this setup the network supports a slice with SST value 1, which is the default slice used throughout the test.

The security configuration specifies the preferred integrity and ciphering algorithms. The order of algorithms is defined so that both the UE and the network can agree on the security parameters during the registration procedure.

Overall, this configuration ensures that the Open5GS AMF, AUSF, and UDM components can interoperate correctly with the Amarisoft core network through the standardized service-based interfaces.

This configuration shows the UPF settings used in the Open5GS core network for this test setup. Only a few parameters are modified from the default configuration so that the UPF can properly communicate with the Amarisoft system.

The PFCP section defines the control plane interface used between the SMF and the UPF. The address is configured as 127.0.0.7, which means that the PFCP signaling between the SMF and the UPF is handled locally inside the virtual machine where Open5GS is running.

The GTP-U section defines the user plane interface used to exchange user data packets between the gNB and the UPF. The address is set to 192.168.100.32. This corresponds to the IP address assigned to the NIC of the virtual machine running Open5GS. The gNB sends GTP-U packets to this address when forwarding user plane traffic.

The subnet section defines the IP address pool that will be allocated to the UE when a PDU session is established. In this configuration the IPv4 subnet is defined as 10.45.0.1/16. When a UE successfully completes the registration and session setup procedure, the UPF assigns an IP address from this range.

An IPv6 prefix is also configured as 2001:db8:cafe::1/48. This allows the system to support IPv6 addressing for the UE if required.

This configuration ensures that the UPF can receive user plane traffic from the gNB and properly allocate IP addresses to the UE devices connected through the network.

This configuration shows the settings for the UDM component in Open5GS used in this test environment.

The SBI section defines the service-based interface used by the UDM to communicate with other core network functions. In this configuration the address is set to 192.168.100.32, which corresponds to the IP address assigned to the NIC of the virtual machine where Open5GS is running.

The port number is configured as 8888. In this tutorial the port number is intentionally changed from the default so that each Open5GS network function can operate with a unique IP and port combination. This helps avoid port conflicts when multiple services are running on the same host.

Through this SBI interface, the UDM provides subscriber related services to other network functions. In the context of this test setup, the Amarisoft MME communicates with the Open5GS UDM over the n8 interface to retrieve subscriber data such as authentication information and UE subscription parameters.

This configuration allows the UDM running on the Open5GS virtual machine to provide subscriber data services to the Amarisoft core network through the standardized service-based interface.

Whenever a configuration file of an Open5GS component is modified, the corresponding service must be restarted so that the new settings are applied.

In this setup several Open5GS components were configured, including the AMF, UPF, and UDM. After updating their configuration files, the related services must be restarted using the systemctl command.

The command `sudo systemctl restart open5gs-amfd` restarts the AMF service so that the updated NGAP and SBI configuration parameters are reloaded.

The command `sudo systemctl restart open5gs-upfd` restarts the UPF service. This ensures that the updated GTP-U interface settings and the UE IP address pool configuration are applied.

The command `sudo systemctl restart open5gs-udmd` restarts the UDM service so that the updated SBI address and port configuration becomes active.

After these services are restarted, the Open5GS components will run with the new configuration and will be ready to communicate with the Amarisoft system through the n8 and n12 interfaces.

$ sudo systemctl restart open5gs-amfd $ sudo systemctl restart open5gs-upfd $ sudo systemctl restart open5gs-udmd

Callbox

In this test,  gnb-sa.cfg is used without any change.

For mme, mme-ims-open5gs-n12-n8.cfg is used. It is copied and modified from mme-ims.cfg.

The configuration in gnb-sa.cfg  are set as follows. This configuration shows the basic gNB settings used in the Amarisoft system to connect the gNB to the core network.

The amf_list section defines the AMF that the gNB will connect to through the NGAP signaling interface. In this configuration the AMF address is set to 127.0.1.100. This means the gNB will establish its NGAP connection with the AMF running on the local PC. If the AMF is running on a different machine, this address must be changed to the IP address of that host.

The gtp_addr parameter defines the IP address used for the GTP-U user plane interface. This address represents the Ethernet interface through which the gNB exchanges user plane traffic with the core network. In this example the address is set to 127.0.1.1, indicating that the interface is bound locally on the same machine.

The gnb_id_bits parameter defines the number of bits used to represent the gNB identifier. In this configuration the value is set to 28 bits, which determines the length of the identifier used by the network.

The gnb_id parameter defines the unique identifier of the gNB. In this example the value is set to 0x12345. This identifier is included in signaling procedures such as the NG setup request so that the core network can uniquely identify the gNB within the PLMN.

The configuration in mme-ims-open5gs-n12-n8.cfg  is set as follows. This configuration shows how the Amarisoft MME communicates with the Open5GS components through the n12 and n8 interfaces.

The gtp_addr parameter defines the GTP-U bind address used by the Amarisoft core. In this configuration it is set to 127.0.1.100. This address is used internally for user plane communication when the Amarisoft components run on the same machine.

The n12 section defines the interface used between the MME and the AUSF. The api_root parameter specifies the address of the AUSF service running on the Open5GS virtual machine. In this example it is configured as [http://192.168.100.32:7777](http://192.168.100.32:7777), which matches the SBI address and port configured in the Open5GS AUSF configuration.

The bind_addr parameter defines the local address used by the Amarisoft system when initiating the n12 communication. This is set to 192.168.100.17, which corresponds to the IP address of the Callbox network interface.

The n8 section defines the interface used between the MME and the UDM. The api_root parameter specifies the address of the UDM service running on the Open5GS virtual machine. In this configuration the address is set to [http://192.168.100.32:8888](http://192.168.100.32:8888), which corresponds to the SBI address and port configured in the Open5GS UDM configuration.

The bind_addr parameter again specifies the local interface address used by the Amarisoft MME when communicating with the UDM. This is also set to 192.168.100.17, indicating that the communication originates from the Callbox network interface.

The remaining parameters define the network identity. The plmn value is set to 00101, which corresponds to MCC 001 and MNC 01. The mme_group_id and mme_code parameters are identifiers used by the MME to uniquely identify itself within the network.

This configuration allows the Amarisoft MME to perform authentication through the Open5GS AUSF using the n12 interface and retrieve subscriber data from the Open5GS UDM using the n8 interface.

Perform the Test

First restart the LTE service on the Callbox and verify that the gNB is operating normally. For this test, the detailed radio configuration of the cell is not critical. Any valid cell configuration can be used.

After restarting the service, you can check the physical configuration of the gNB using the `cell phy` command in the Callbox console. The output shows the radio parameters currently used by the NR cell.

The log indicates that the gNB is operating with PLMN 00101 and gNB identifier 0x12345. The cell is configured in NR band n78 with a bandwidth of 20 MHz and subcarrier spacing of 30 kHz.

The downlink and uplink ARFCN values are both configured as 632628, while the SSB is transmitted at ARFCN 632544. The output also shows additional parameters such as the number of antennas and modulation settings used for the transmission.

The second part of the output shows additional cell parameters such as the tracking area code, downlink ARFCN, PRACH configuration, and other radio related settings.

This step confirms that the gNB is running correctly and the NR cell is active before proceeding with the UE registration and core network interaction tests.

Next verify the core network connection that the gNB is using. This can be checked from the Callbox console with the 'ng' command.

The output shows the NG connection state between the gNB and the core network. In this example the gNB is connected to the server at address 127.0.1.100 using port 38412. Port 38412 is the standard SCTP port used for NGAP signaling between the gNB and the core network.

The status 'state=setup_done' indicates that the NG setup procedure has completed successfully. This means the signaling connection between the gNB and the core network is fully established.

The PLMN value shown as 00101 confirms that the gNB and the core network are operating under the same PLMN configuration.

This step verifies that the gNB has successfully connected to the core network running on the local PC before continuing with the UE registration procedure.

After confirming that the gNB is connected to the core network, restart the LTE service on the UE simulator and power on the UE.

When the UE starts, it begins the initial access procedure. The UE scans the radio environment, detects the available cell, and attempts synchronization with the gNB.

The message 'Cell 0: SIB found' indicates that the UE has successfully detected the cell and decoded the System Information Block. This means the UE has synchronized with the gNB and obtained the essential system information required for access, such as PLMN identity and cell configuration parameters.

Once this step is completed, the UE proceeds with the registration procedure through the gNB toward the core network.

If the connection procedure is completed successfully, the UE should appear in the UE list with a valid registration state and an assigned IP address.

This can be verified using the 'ue' command in the UE simulator console. The output displays the status of the connected UE.

The RRC_STATE value 'running' indicates that the radio connection between the UE and the gNB is active. This means the RRC connection has been successfully established and the UE is operating in connected mode.

The EMM_STATE value 'registered' confirms that the UE has completed the registration procedure with the core network. At this stage the UE has successfully passed authentication, security setup, and registration.

The IP_ADDR field shows the IP address assigned to the UE. In this example the UE receives the address 192.168.3.2. This address is allocated during the PDU session establishment and allows the UE to exchange user plane data through the network.

This output confirms that the UE is fully attached to the network and ready for normal communication.

You can further verify the UE connection status from the Callbox using the 't' command and the 'ue' command.

The 't' command starts the real-time trace of radio activity between the gNB and the UE. The trace shows parameters such as CQI, MCS, SNR, bitrate, and retransmission statistics. These values reflect the current radio link condition and data transmission performance.

At the beginning of the trace, the PRACH information is displayed. This indicates that the UE has successfully completed the random access procedure and established the initial connection with the gNB.

The table shows both downlink and uplink statistics. Parameters like CQI and MCS indicate link quality and modulation efficiency. The bitrate values show that actual data transfer is ongoing between the UE and the network.

You can also run the 'ue' command on the Callbox to check the UE context. The output lists the connected UE along with identifiers such as RAN_UE_ID, CN_UE_ID, serving cell, and RNTI.

In this example, the UE is connected to Cell 0x001 with RNTI 0x4601. This confirms that the UE context is properly established in the gNB and the UE is actively connected to the network.

Log Analysis

Sample Log

This log shows that the gNB is connected to the MME running on the local PC. In this setup the Amarisoft MME provides the core network functions.

When the gNB starts, it attempts to establish an NGAP signaling connection with the MME using SCTP. The log shows the gNB connecting to the server at address 127.0.1.100 on port 38412. This is the standard NGAP SCTP port used for communication between the gNB and the core network.

After the SCTP connection is established, the gNB sends an NG setup request to the MME. This message contains information about the gNB such as the Global RAN Node ID, the gNB identifier, and the supported tracking area list.

The MME processes this request and sends an NG setup response back to the gNB. This response confirms that the core network accepts the gNB and allows it to operate within the network.

Once the NG setup procedure is completed, the signaling connection between the gNB and the Amarisoft MME becomes active. From this point onward, the gNB can forward UE registration messages and other control plane signaling to the core network.

This log shows the communication between the Amarisoft MME and the Open5GS AUSF through the n12 interface during the UE authentication procedure.

After the UE sends the Registration Request, the Amarisoft MME processes the NAS signaling and extracts the identity information of the UE. When authentication is required, the MME contacts the AUSF using the n12 interface.

The log shows HTTP requests sent from the Amarisoft system to the AUSF running on the Open5GS virtual machine at address 192.168.100.32 with port 7777. The message shown as a POST request corresponds to the authentication request sent to the AUSF service.

The AUSF processes the request and generates the authentication vectors required for the UE authentication procedure. The response is returned with an HTTP status code indicating successful processing.

After receiving the authentication response from the AUSF, the Amarisoft MME continues the normal NAS authentication procedure with the UE. The MME sends the Authentication Request to the UE, receives the Authentication Response, and verifies the authentication result.

The log also shows the message AUSF_5G_AKA_CONFIRMATION, which confirms that the authentication process has been successfully completed. After this step the security procedure continues and the UE proceeds with the registration process.

This trace confirms that the authentication function is handled by the Open5GS AUSF through the n12 interface while the Amarisoft MME manages the rest of the control plane procedures.

This trace shows the communication between the Amarisoft MME and the Open5GS UDM through the n8 interface.

After the UE completes the authentication and security procedures, the Amarisoft MME needs to retrieve subscriber related information from the UDM. This includes UE subscription data and session management related parameters.

The log shows several HTTP requests sent from the Amarisoft system to the UDM service running on the Open5GS virtual machine. The requests are directed to address 192.168.100.32 on port 8888, which corresponds to the SBI configuration defined for the UDM in Open5GS.

The messages include requests to endpoints such as '/nudm-uecm' and '/nudm-sdm'. These interfaces are used to retrieve UE context information and subscription data stored in the UDM.

Each request receives an HTTP response with status code 200, indicating that the request was successfully processed by the UDM and the requested data was returned to the Amarisoft MME.

After retrieving the subscriber data from the UDM, the Amarisoft MME continues the registration procedure. The trace shows the Registration Accept message being sent to the UE, indicating that the UE has successfully completed the registration process.

This trace confirms that the Amarisoft MME interacts with the Open5GS UDM through the n8 interface to retrieve subscriber information, while the rest of the control plane signaling remains handled by the Amarisoft core network.

Test 4 : Amari gNB + Amari MME + n8/n13 + Open5GS UDM

In this test, I will show you a case where Amarisoft callbox is used as 5G/NR RAN  and most part of 5G Core except  UDM. The UDM of open5gs works together with Amari MME via n13/n8 interface .

In this test, Amarisoft Callbox is used to implement the 5G NR radio access network and most of the core network functions. The only core component provided by Open5GS is the UDM. The purpose of this setup is to demonstrate how Amarisoft core components can interwork with an external subscriber database implemented by Open5GS.

During the registration procedure, the Amarisoft MME communicates with the Open5GS UDM through the n8 and n13 interfaces. These interfaces are part of the Service Based Architecture of the 5G core and allow the core network to retrieve subscriber information and authentication related data from the UDM.

When the UE initiates registration, the Amarisoft MME performs the standard authentication and security procedures. As part of this process, it queries the Open5GS UDM to obtain the UE subscription profile and session related information. The UDM responds with the required data, allowing the Amarisoft core to complete the registration and establish connectivity for the UE.

This test demonstrates that Amarisoft core components can successfully interoperate with Open5GS network functions through standardized SBI interfaces, enabling a hybrid core network deployment where specific functions such as UDM can be provided by external implementations.

Configuration

The configuration for Open5GS and Callbox is as shown below.

Open5gs

In this test, the Open5GS core is mostly kept in its default configuration. Only a small number of parameters are modified so that the Amarisoft components can communicate correctly with the Open5GS network functions. In this example, only three configuration files are modified while all other configuration files remain unchanged.

The first configuration file modified is 'amf.yaml'. This file defines how the Open5GS AMF exposes its service interfaces and how it communicates with the radio access network.

The 'sbi' section defines the Service Based Interface address and port used by other network functions. In this configuration the AMF service runs on address '127.0.0.5' with port '7777'. This address is used by other components such as AUSF and UDM when communicating with the AMF through HTTP-based SBI signaling.

The 'ngap' section specifies the IP address used for the NGAP interface toward the gNB. In this setup the address is configured as '192.168.100.32', which corresponds to the IP address assigned to the network interface of the Open5GS virtual machine.

The 'guami' section defines the Globally Unique AMF Identifier. This identifier allows the UE and the network to identify the AMF that manages the UE. It includes the PLMN information ('MCC=001', 'MNC=01') and the AMF identifier composed of region and set values.

The 'tai' section defines the Tracking Area Identity supported by this AMF. It contains the PLMN identifier and the Tracking Area Code used for mobility management.

The 'plmn_support' section indicates which PLMN and network slice the AMF supports. In this configuration the network slice has 'SST = 1', which is typically used for the default slice.

The 'security' section defines the preferred integrity and ciphering algorithms used during NAS security setup. The configuration lists the algorithm priority order for integrity protection ('NIA2', 'NIA1', 'NIA0') and encryption ('NEA0', 'NEA1', 'NEA2').

Finally, the 'network_name' and 'amf_name' parameters define the name of the network and the AMF instance. These values are broadcast to the UE during the registration procedure and help identify the network in the system.

This configuration shows the UPF settings used in this test setup. Only a few parameters are adjusted so that the user plane traffic can be properly exchanged between the Amarisoft system and the Open5GS core.

The PFCP section defines the control plane interface between the SMF and the UPF. The address is set to 127.0.0.7, which means the PFCP signaling is handled locally inside the Open5GS virtual machine.

The GTP-U section defines the user plane interface used to exchange data packets with the gNB. The address is configured as 192.168.100.32, which corresponds to the IP address of the virtual machine running Open5GS. The gNB sends GTP-U packets to this address for user data transfer.

The subnet section defines the IP address pool assigned to the UE when a PDU session is established. In this configuration, the IPv4 subnet is 10.45.0.1/16. The UPF allocates an IP address from this range to the UE during session setup.

An IPv6 prefix is also defined as 2001:db8:cafe::1/48, which allows the network to support IPv6 addressing if needed.

This configuration ensures that the UPF can correctly receive user plane traffic from the gNB and assign IP addresses to the UE devices connected through the network.

This configuration shows the settings used for the UDM in the Open5GS core. In this test scenario the UDM is the only core network function provided by Open5GS while most of the other functions are handled by the Amarisoft system.

The 'sbi' section defines the Service Based Interface address used by other network functions when communicating with the UDM. In this configuration the UDM service runs on address '192.168.100.32', which corresponds to the IP address assigned to the network interface of the virtual machine running Open5GS.

The port number is set to '8888'. In this tutorial the port number is intentionally changed from the default value so that each Open5GS network function can use a unique IP and port combination. This makes it easier to clearly identify which component is being accessed when external systems such as the Amarisoft MME communicate with the Open5GS services.

With this configuration, the Amarisoft MME can access the Open5GS UDM through the N8 interface using the HTTP service exposed at '192.168.100.32:8888'. Through this interface the MME retrieves subscriber information and subscription data required during the UE registration procedure.

Whenever a configuration file for an Open5GS network component is modified, the corresponding service must be restarted so that the new configuration is applied. Open5GS reads its configuration files only when the service starts, so any changes made in the YAML files will not take effect until the service is restarted.

In this example, the configuration files for three components were modified: AMF, UPF, and UDM. Therefore, the corresponding services must be restarted.

$ sudo systemctl restart open5gs-amfd $ sudo systemctl restart open5gs-upfd $ sudo systemctl restart open5gs-udmd

Each command restarts the related Open5GS network function so that the updated configuration parameters become active. After restarting these services, the system will operate using the new settings defined in the configuration files.

Callbox

In this test,  gnb-sa.cfg is used without any change.

For mme, mme-ims-open5gs-n8-n13.cfg is used. It is copied and modified from mme-ims.cfg.

This configuration shows the parameters used in gnb-sa.cfg  for connecting the Amarisoft gNB to the core network.

The amf_list section defines the AMF address that the gNB will connect to through the NGAP interface. In this configuration the AMF address is set to 127.0.1.100. If the AMF is running on a different host or different interface, this address must be modified accordingly so that the gNB can establish the NGAP connection with the correct AMF.

The gtp_addr parameter defines the local IP address used by the gNB for the GTP-U interface. This is the address used for user plane traffic between the gNB and the core network. In this example the address is set to 127.0.1.1, which corresponds to the local interface used for communication with the AMF and other core components.

The gnb_id_bits parameter specifies the number of bits used to represent the gNB identifier. This value determines how the gNB ID is encoded when forming the global gNB identifier used in NGAP signaling.

The gnb_id parameter defines the identifier of the gNB. This value uniquely identifies the base station within the network and is used during the NG setup procedure between the gNB and the AMF.

This configuration shows the parameters used in 'mme-ims-open5gs-n8-n13.cfg ' for connecting the Amarisoft MME to the Open5GS UDM through the N8 and N13 interfaces.

The 'gtp_addr' parameter defines the local IP address used by the MME for the GTP interface. In this configuration the address is set to '127.0.1.100'. This address is used internally by the Amarisoft system for control plane communication related to GTP signaling.

The 'n13' section defines the configuration used by the MME to communicate with the UDM through the N13 interface. The 'api_root' parameter specifies the HTTP endpoint of the UDM service. In this setup the address is 'http://192.168.100.32:8888', which corresponds to the SBI address configured in 'udm.yaml' on the Open5GS virtual machine. The 'bind_addr' parameter defines the local IP address of the Amarisoft Callbox that will be used as the source address when sending requests to the UDM. In this configuration the address is '192.168.100.17', which is the IP address assigned to the network interface of the Callbox.

The 'n8' section defines another interface used for communication with the UDM. Similar to the N13 configuration, the 'api_root' parameter points to the UDM service endpoint at 'http://192.168.100.32:8888'. The 'bind_addr' parameter again specifies the local IP address of the Callbox that will be used as the source address when accessing the UDM service.

The 'plmn' parameter defines the public land mobile network identifier used by the system. In this configuration the PLMN is set to '00101', which corresponds to MCC '001' and MNC '01'.

The 'mme_group_id' and 'mme_code' parameters define identifiers used to uniquely identify the MME within the network. These values are included in signaling messages so that the network and the UE can correctly identify the serving MME.

Perform the Test

First restart the LTE service on the Callbox and verify that the gNB is operating normally. For this test, the detailed cell configuration is not critical, so the cell can be configured with any valid parameters.

After restarting the service, use the 'cell phy' command to check the current radio configuration of the gNB. The output shows that the system is running with PLMN 00101 and gNB identifier 0x12345.

The cell is configured in NR band n78 with a bandwidth of 20 MHz and subcarrier spacing of 30 kHz. The downlink and uplink ARFCN values are both set to 632628, and the SSB is transmitted at ARFCN 632544.

Additional parameters such as antenna configuration, modulation order, and PRACH settings are also displayed. These values confirm that the NR cell is active and properly configured.

This step verifies that the gNB is running correctly before proceeding with the core network connection and UE registration.

After the gNB is running, check which core network the gNB is connected to. This can be verified using the 'ng' command in the Callbox console.

The output shows the NG connection status between the gNB and the core network. In this example, the gNB is connected to the AMF running on the virtual machine at address '127.0.1.100' using port '38412', which is the standard SCTP port used for NGAP signaling.

The field 'state=setup_done' indicates that the NG setup procedure between the gNB and the AMF has been successfully completed. This means the NGAP connection has been established and the gNB is now registered with the core network.

The output also shows the PLMN value '00101', confirming that the gNB and the core network are operating under the same PLMN configuration.

This step confirms that the radio access network is properly connected to the core network before starting the UE registration procedure.

Now restart the LTE service on the UE simulator and power on the UE. This step starts the UE radio procedure so that it can search for available cells and attempt to connect to the network.

After the UE is powered on, the log shows the message 'Cell 0: SIB found'. This indicates that the UE has successfully detected the broadcast cell and decoded the System Information Block transmitted by the gNB.

Decoding the SIB confirms that the UE has synchronized with the cell and obtained the basic system information required to start the access procedure. At this point the UE can proceed with the random access process and begin the registration procedure with the core network.

If the connection procedure is successfully completed, the UE will be registered to the network and assigned an IP address.

You can verify this by using the 'ue' command in the UE simulator console. The output shows the current status of the connected UE.

The field 'RRC_STATE' shows 'running', which indicates that the RRC connection between the UE and the gNB has been successfully established.

The field 'EMM_STATE' shows 'registered', meaning the UE has completed the registration procedure with the core network.

The column 'IP_ADDR' shows the IP address assigned to the UE, which in this example is '192.168.3.2'. This address is allocated by the core network during the session establishment procedure.

This confirms that the UE has successfully connected to the network, completed authentication and registration, and obtained an IP address for data communication.

You can further confirm the UE connection status from the Callbox using the 't' command and the 'ue' command.

When you run the 't' command, it starts a real-time trace of the radio link between the gNB and the UE. The trace shows parameters such as CQI, MCS, SNR, retransmission, and bitrate for both downlink and uplink. These values indicate the current radio condition and data transmission performance.

At the top of the trace, the PRACH information is shown. This confirms that the UE has successfully performed the random access procedure and established the initial connection with the gNB.

The table that follows shows continuous transmission statistics. The presence of bitrate values and stable CQI and SNR indicates that the UE is actively exchanging data with the network.

You can also run the 'ue' command on the Callbox to check the UE context. The output shows the mapping between the RAN UE ID and the core network UE ID, along with the serving cell and the assigned RNTI.

In this example, the UE is connected to Cell 0x001 with RNTI 0x4601. This confirms that the UE context is properly established in the gNB and that the UE is actively connected to the network.

Log Analysis

Sample Log

This log shows that the gNB is connected to the MME running on the local PC, which is the Amarisoft MME in this setup.

When the gNB starts, it attempts to establish an NGAP signaling connection with the MME over SCTP. The log shows the gNB connecting to the server at address 127.0.1.100 on port 38412. This is the standard NGAP SCTP port used for communication between the gNB and the core network.

After the SCTP connection is established, the gNB sends an NG setup request to the MME. This message includes information such as the gNB identifier and supported tracking area.

The MME processes this request and sends back an NG setup response. This confirms that the core network accepts the gNB and allows it to operate.

Once this exchange is completed, the NGAP connection is established and the gNB is fully connected to the Amarisoft MME. From this point, the gNB can forward UE signaling messages to the core network.

This log shows the communication between the Amarisoft MME and the Open5GS UDM through the N13 interface.

During the UE registration procedure, the Amarisoft MME needs to access subscriber related information stored in the UDM. This interaction is performed through the N13 interface, which allows the MME to communicate with the UDM using HTTP-based service requests.

In the log, the highlighted message shows a POST request sent to the UDM service running on the Open5GS virtual machine at address 192.168.100.32 on port 8888. This corresponds to the SBI address configured in the 'udm.yaml' file.

The request is sent to the '/nudm-ueau' service endpoint, which is used to retrieve authentication related information associated with the UE. The UDM processes the request and returns the required data to the Amarisoft MME.

The log also shows the HTTP response with status code 200, indicating that the request was successfully processed by the UDM.

After receiving the response from the UDM, the Amarisoft MME continues the authentication and registration procedure with the UE. This confirms that the N13 interface between the Amarisoft MME and the Open5GS UDM is operating correctly.

This log shows the communication between the Amarisoft MME and the Open5GS UDM through the N8 interface.

After the UE authentication is completed, the MME needs to retrieve and update subscriber related data such as subscription profile, session information, and mobility context. This interaction is performed over the N8 interface using HTTP-based SBI messages.

In the highlighted section, you can see multiple HTTP requests sent from the Amarisoft MME to the UDM at address 192.168.100.32 on port 8888. This matches the SBI configuration defined in the 'udm.yaml' file in Open5GS.

The messages include PUT and GET requests to endpoints such as '/nudm-uecm' and '/nudm-sdm'. These APIs are used for UE context management and subscription data management.

The responses from the UDM show status codes such as 200 and 201, indicating that the requests are successfully processed. This confirms that the UDM is properly handling subscriber data queries and updates from the MME.

After these N8 interactions are completed, the registration procedure proceeds, and you can see the Registration Accept message being sent to the UE.

This confirms that the N8 interface between the Amarisoft MME and the Open5GS UDM is working correctly and that subscriber data exchange is successfully completed.