Amarisoft

Configuration Guide

This tutorial shows the overall architecture of Amari Callbox. It shows various components of the Callbox Protocol stack and various configuration files for each components of the callbox software. One of the challenges to configure the callbox as per your requirement would be to figure out which configuration file you need to modify and which parameter you have to set in each of the configuration file. I hope this digram would give you a first level hints to figure out which configuration file you need to pick for your test requirement.

On gNB/eNB side, there are many different types of configuration file. It would be a little challenging to get the detailed understanding on all the details of each and every configuration file. If you are new to Amarisoft System, try to understand the configuration files in the following order. This order is the order in which most of the customer would most frequently changes for the testing. The file location in the list below is based on the assumption that you installed Amarisoft software in default location (/root)

NOTE : The cofiguration file name shown above is not the physical file. It is the just file name symbolically linked to the real physical file name. If you want to apply a specific file, create your own configuration file and make a symbolic link with the corresponding name listed above. For example, if you want to use myenb.cfg file to configure enb/gnb, just make a symbolic link as follows in /root/enb/config.  

          enb.cfg -> myenb.cfg

To create the symbolic link as shown above. Run the following command within the corresponding directory.

          ln -sf myenb.cfg enb.cfg

Table of Contents

Introduction

Amari Callbox is a comprehensive software suite developed by Amarisoft, designed to emulate and test advanced cellular network components, particularly focusing on 4G LTE (eNB) and 5G NR (gNB) radio access networks. The Callbox architecture encompasses a modular protocol stack that integrates multiple network elements and allows for precise configuration and testing of wireless communication protocols. At the core of the Callbox system are various software modules, each responsible for different layers and functions within the protocol stack, such as radio resource control, mobility management, and session management. Configuration management is a central aspect of the Amari Callbox ecosystem, relying on a structured set of configuration files (e.g., enb.cfg, mme.cfg, ims.cfg) that dictate the behavior, parameters, and operational profiles of each network component. These files are symbolically linked for flexible deployment and customization, enabling users to adapt the system for diverse testing scenarios. Understanding the architectural layout and the interplay between configuration files is critical for effectively leveraging the Callbox for testing, development, and validation of wireless network deployments. This tutorial provides a detailed overview of the Amari Callbox architecture and guides users on identifying and modifying the appropriate configuration files to meet specific test requirements, particularly from the perspective of new users or those transitioning to Amarisoft systems.

Summary of the Tutorial

This document provides a comprehensive procedural overview for configuring and testing various aspects of Callbox software, focusing on the structure and methodology for each configuration and test scenario. The summary below outlines the steps and methodologies for configuring protocol stack components, RAN and core network elements, APN/QoS, network slicing, IMS, DRB, UE database, and various radio access scenarios, including LTE, NR/SA, NR/NSA, NB-IoT, LTE Carrier Aggregation, and LTE Handover configurations.

General Methodology:

This procedural summary provides the foundational steps and considerations necessary for configuring, testing, and managing the Callbox software across multiple network scenarios and protocol layers.

Overview

There are many different types of configuration files are involved in the operation of Callbox software and it would be tricky or confusing to figure out which configuration file is associated with which layers of protocol stack or which network component. Following illustrates each of the configuration files mapped to corresponding protocol stack or network component. This figure gives a high-level view of how a typical Amarisoft-based LTE/NR lab system is organized, showing the main functional blocks—eNB/gNB, MME/EPC, IMS, and external IP/Internet services—and how they are connected through radio and IP interfaces. The main purpose of the diagram is to map each part of the end-to-end system to the configuration files that control it, such as enb.cfg for radio stack and interface settings, drb.cfg for bearer-related behavior, mme.cfg and ue_db.cfg for core network and subscriber definitions, and ims.cfg for IMS service parameters. In other words, it serves as a practical configuration roadmap that helps you understand where the major network identities, addresses, protocol settings, and service-related parameters are defined so that the full lab setup can operate consistently from the RAN side to IMS and external connectivity.

ConfigurationGuide Overview 01

Followings are the bulleted summary of the illustration show above

The configurations files shown in the diagram above are distributed into two directories as shown below. As shown below, enb directory carries configuration files for RAN side operation and mme directory carries configuration files for core network.

This figure complements the previous configuration map by showing where those configuration files are physically located in the filesystem and how Amarisoft separates them by function. At a high level, it explains that the configuration files used for the RAN side (such as enb.cfg and drb.cfg) are stored under the enb directory, while the configuration files used for the core network and IMS side (such as mme.cfg and ims.cfg) are stored under the mme directory. The screenshots also illustrate a typical /root layout with symbolic links pointing to installed Amarisoft package directories, making it easier to understand how the lab environment is organized in practice and where to look when editing RAN versus core/IMS settings.

ConfigurationGuide Overview 02

Followings are the bulleted summary of the illustration show above

Data Path for Internet Access

Overall data path and components during internet access is illustrated as below.  This figure illustrates the overall data path and key components involved when a UE accesses the internet through an Amarisoft-based LTE/NR lab setup, and it compares the system behavior before and after the UE completes the initial attach process. In the upper part, the UE has not yet been assigned an IP address, so the RAN (eNB/gNB) and the core network are present but no user-data path is active toward external services. In the lower part, after the initial attach with PDN/PDU session establishment, the UE receives an IP address and the core network activates tunnel interfaces (such as tun0, tun1, etc.) with corresponding subnet addresses, enabling traffic to flow through the default gateway toward external networks such as Google DNS (8.8.8.8) and the internet. The diagram therefore provides a high-level operational view of how control-plane setup leads to user-plane connectivity, linking the UE, RAN stack, core network tunnels, and external IP services into one end-to-end path.

OutOfBox Internet Overall Flow 01

NOTE : You can assign IP address to each tun interface as you like in pdn_list: of mme configuration. The default configuration is shown at the section Check Up before trying UE connection

NOTE : In this example diagram, the GTPU is shown to be connected to tun 0, but the connection can be made to other tun during PDN/PDU establishement process.

NOTE : In this example diagram, DNS is specified to 8.8.8.8 (Google DNS), but this can be changed as well in  pdn_list: of of mme configuration.

NOTE : TCP/UDP port number is not shown here because it is automatically set (set differently depending on situation) when those sockets are created.

Followings are the bulleted summary of the illustration show above

Core Component / Interfaces / Protocol / Port

Structure of Full Stack Configuration

This shows the overall configuration file structure for the full stack configuration from RAN through Core Network/Application Layer, The purpose is not to show each and every detailed parameters for the full stack. This is just to show the overall structure of each configuration file for each component (i.e, RAN, Core network, Application layer etc)  Just try to grasp the big picture of the structure of the configuration files here.

Structure of RAN(eNB/gNB) Configuration

This configuration is the one pointed by (symbolically linked to) enb.cfg. This is to configure the full stack of RAN (eNB or gNB or Both) from PHY through RRC/PDCP.  At the top level, it defines node-wide runtime settings that apply to the whole eNB/gNB process, such as logging options, log file location, remote API address (com_addr), RF driver selection, and global TX/RX gain. The next level defines external interfaces and identities, including RF port definitions (rf_ports), core-network peer connections (mme_list for LTE and amf_list for NR), the GTP bind address (gtp_addr), and node identity (enb_id). Below that, the file branches into deployment-specific cell instances through cell_list (LTE) and nr_cell_list (NR), which represent the actual cells to run. In parallel, it also provides RAT-specific default templates (cell_default and nr_cell_default) that organize common protocol settings in a layered way, typically from PHY-related parameters down to mac_config, srb_config, and drb_config (with drb_config often linked to a separate file like drb.cfg). In short, the hierarchy is: global node settings → interfaces/core connectivity → LTE/NR cell instances → LTE/NR default protocol templates.

{

  log_options: configure what type of log to be collected

 

  log_filename: configure log file name and location

 

  com_addr: specify IP and port number for remote API

 

  rf_driver: {

        

  },

 

  tx_gain: set TX gain

  rx_gain: set RX gain

 

 rf_ports: [

    {

       /* RF port for the first cell */

    },

    {

        /* RF port for the second cell */

    },

  ],

    

  mme_list: [

    {

        mme_addr: /* address of MME for S1AP connection. Must be modified if the MME runs on a different host. */

    },

  ],

  

  gtp_addr: GTP bind address (=address of the ethernet interface connected to the MME). Must be modified if the MME runs on a different host.

 

  enb_id: high 24 bits of SIB1.cellIdentifier

 

  amf_list: [

    {    

      amf_addr: /* address of AMF for NGAP connection. Must be modified if the AMF runs on a different host. */

    },

  ],

 

  

cell_list: [ list of LTE cells

  ],

 

 nr_cell_list: [ list of NR cells

  ],

 

cell_default: { default parameters for LTE cells

    /* PHY Configurations */    

    

    mac_config: { /* MAC configuration (same for all UEs) */

    },

    

    srb_config: [ /* SRB configuration */

    ],

 

    

    drb_config: /* DRB configuration. Links to a separate file for drb configuration */

  },

 

nr_cell_default: {   default parameters for NR cells

    /* PHY Configurations */    

    

    mac_config: { /* MAC configuration (same for all UEs) */

    },

    

    srb_config: [ /* SRB configuration */

    ],

 

    

    drb_config: /* DRB configuration. Links to a separate file for drb configuration */

}

 

Among the parameters in the RAN configuration file, there are a set of parameters that applies in common regardless of RAN type and there are a set of parameters that are specific to a specify type of RAN.

The set of parameters that are specific to a specific types of RAN is summarized as follows. In this overall structure, I will put only a small portions of parameters that are most frequently changed by users. You may refer to lteenb documents for those parameters that are not mentioned here.

Structure of NAS/Core Configuration

This configuration is the one pointed by (symbolically linked to) mme.cfg. This is to configure NAS layer and Core network. At the top level, it defines node-wide runtime settings such as logging (log_options, log_filename), remote API access (com_addr), and the GTP-U bind address (gtp_addr). The next level defines core identity and operator information, including PLMN, MME identity fields (mme_group_id, mme_code), IMS voice support capability flags (ims_vops_*), emergency number list, and broadcasted operator names (network_name, network_short_name). Below that, it defines service and feature configuration, such as RX-related settings, CIoT options (cp_ciot_opt), IMS server list (ims_list), slice configuration (nssai), and PDN/APN definitions (pdn_list) that control data-session behavior and default APN selection. At the lower operational layer, it includes system integration and security preferences, such as the tunnel interface setup script (tun_setup_script) and NAS ciphering/integrity algorithm preferences (nas_cipher_algo_pref, nas_integ_algo_pref). Finally, it can include an external subscriber database configuration through include, which links user/UE authentication and subscription data into the core configuration. In short, the hierarchy is: global runtime settings → core identity/operator capabilities → services/slices/PDN definitions → integration/security preferences → included subscriber database.

{

  log_options: configure what type of log to be collected

 

  log_filename: configure log file name and location

 

  com_addr: specify IP and port number for remote API

 

  gtp_addr: bind address for GTP-U

 

  plmn:  specify the plmn of the cell

  mme_group_id: specify mme group id

  mme_code: specify mme code

 

  ims_vops_eps:  Specify wether "IMS voice over PS session in S1 mode" is supported or not

  ims_vops_5gs_3gpp:  Specify wether "IMS voice over PS session in 5G " is supported or not

  ims_vops_5gs_n3gpp: Specify wether "IMS voice over PS session over Non 3GPP " is supported or not

 

  emergency_number_list: [  Defines a list of emergency numbers to be sent to the UE in the NAS Messages

 

  ],

 

  rx: {

 

  },

 

  network_name:  network name sent in the EMM information message to the UE

  network_short_name:  network short name in the EMM information message to the UE

 

  cp_ciot_opt: Control Plane Cellular IoT EPS optimization support

 

  ims_list: [  configure ims address  ],

 

  nssai: [  Configure AMF slices

  ],

 

  pdn_list: [ Specify PDN and APN The first one is the default.

  ]

 

  tun_setup_script: Setup script for the network interface

 

  nas_cipher_algo_pref: NAS ciphering algorithm preference. EEA0 is always the last.

  nas_integ_algo_pref: NAS integrity algorithm preference.,

 

  include  Include user data base configuration.

 

}

Structure of APN/QoS Configuration

APN/QoS configuration is done as a part of mme.cfg (NAS and Core configuration) and basic structure is as follows. You can configure as many as APN you want in pdn_list:[  ] Array.  At the top of this subtree, pdn_list is an array of PDN/PDU session profiles, and each entry represents one APN/service definition (with the first entry typically acting as the default APN). Inside each PDN entry, the next level defines the session and IP allocation properties such as pdn_type (IPv4/IPv6/IPv4v6/unstructured), access_point_name, UE IP address pool range (first_ip_addr, last_ip_addr), address stepping behavior (ip_addr_shift), and DNS server addresses (dns_addr). Within each PDN entry, the hierarchy then goes one level deeper into erabs, which is an array of bearer/QoS-flow definitions associated with that APN or PDU session. Each erabs item defines the radio bearer or QoS flow characteristics, including qci (or 5QI), priority_level, pre_emption_capability, and pre_emption_vulnerability, with the first entry being the mandatory default bearer/flow and additional entries representing dedicated bearers/flows. In short, the hierarchy is: mme.cfg → pdn_list (APN profiles) → per-PDN IP/session settings → erabs (bearer/QoS flow list) → per-bearer QoS priority/pre-emption parameters.

{

 

  pdn_list: [ Specify PDN and APN The first one is the default.

      {

      pdn_type: ipv4, ipv6, ipv4v6, unstructured (default = ipv4). Select the PDN or PDU session type.

      access_point_name: the Access Point Name. Use dots (.) to separate the APN elements.

      first_ip_addr: first ip address of the ip address sets which are reserved for UE

      last_ip_addr: last ip address of the ip address sets which are reserved for UE

      ip_addr_shift:  The gap in the last segment of IP address from the previous IP. The gap is applied with 2^ip_addr_shift,

      dns_addr:  IPv4 or IPv6 addresses of the DNS servers.

 

      erabs: [ E-RAB (E-UTRAN Radio Access Bearer) associated to the PDN or a QoS flow associated to the PDU session. The first E-RAB or QoS flow is the default radio bearer and must always be present. The additional E-RABs and QoS flows are dedicated radio bearers and must include a Traffic Flow Template (TFT) unless they are defined as UE initiated.

        {

          qci: QoS Class Identifier of the E-RAB or 5G QoS Identifier of the QOS flow.

          priority_level: Priority level.

          pre_emption_capability: the ability of a particular type of traffic to displace other ongoing lower priority traffic when network resources are limited.

          pre_emption_vulnerability: the susceptibility of a particular type of traffic to being displaced by other traffic with higher priority and pre-emption capability.

        },

      ],

    },

  ]

 

}

Structure of Network Slice Configuration

Network slices are configured in both gNB and Core network configuration file.

Network Slice Configuration on gNB Configuration file (enb.cfg) is as in the following structure.  You can configure it in plmn_list[] object and put it in nr_cell_list[] or nr_cell_default: { } as shown below.  You can describe network slice configuration as a two-sided hierarchy that must be aligned between enb.cfg (gNB) and mme.cfg (core/AMF). On the gNB side, the hierarchy starts from the overall NR node configuration and goes down into nr_cell_default (or nr_cell_list[] for per-cell overrides), then into plmn_list[], and finally into nssai[], where each PLMN advertises one or more supported S-NSSAIs (sst, optional sd). This means the gNB side mainly defines which slices are broadcast/served for a given PLMN and cell context. On the core side (mme.cfg), the hierarchy starts with AMF-level nssai[] (the list of S-NSSAIs the core supports), then goes into pdn_list[] (APN/PDU session profiles), and under each PDN entry into either the default erabs[]/QoS-flow definitions or the slice-specific slices[] array. Inside slices[], each element maps one snssai (sst, optional sd) to its own qos_flows[], where per-flow QoS is defined using 5qi, priority, and pre-emption parameters. In short, the hierarchy is: gNB side = NR cell → PLMN → nssai[] (advertised slices), and core side = AMF nssai[] (supported slices) → pdn_list[] (APN/session) → slices[] (per-S-NSSAI policy) → qos_flows[] (per-slice QoS), with both sides needing consistent S-NSSAI definitions.

{

  /* Enable remote API and Web interface */

  com_addr: "0.0.0.0:9001",

 

  rf_driver: {Define and Configure rf_driver. this is the part in which you can configure what kind of RF hardware you use (e.g, Amarisoft SDR Card or Remote Radio Header etc)

        ...

  },

 

  amf_list: [This is the ip address of your 5Gcore network

    {

      ...

    },

  ],

 

  gtp_addr: "ip",This is the ip address of NIC that is connected to core network

 

  en_dc_support: true,

 

  rf_ports: [This is the configuration for the RF port of your hardware like frequency, sampling rate, number of antenna etc 

    {

 

    },

  ],

 

  /* list of cells */

  cell_list: [],This is configuration for NR cell, but is set to be empty when RAT is NR SA single cell

 

  nr_cell_list: [Configuration for NR Cells

  {

    rf_port: value,

    cell_id: value,

    

    /* band, arfcn, SCS, SSB bitmap */

  },

  ], /* nr_cell_list */

 

  nr_cell_default: { Default Configuration for NR Cells. This applies to every cell in nr_cell_list[]. If a configuration is not specified in nr_cell_list[], the configuration in this section is used

        plmn_list: [ List of plmns. If the plmn support network slice, specify network slice configuration here

           {

          tac: 100,

          plmn: "00101",

          reserved: false,

           nssai: [ List of S-NSSAIs served by this PLMN. Default content is sst: 1 (eMBB). This array can have one or more of objects of {sst, sd}

            {

              sst: Slice Service Type.,

              sd: (Optional) Slice Differentiator.

            }

           ],

          },

        ],

     

  },

}

Network Slice Configuration on Core Network Configuration (mme.cfg) is as in the following structure.

{

  nssai: [   List of S-NSSAIs served by the AMF. Default content is sst: 1 (eMBB). This array can have one or more of objects of {sst, sd}

   {

    sst: Slice Service Type.,

    sd: Slice Differentiator.

   },

  ],

 

  pdn_list: [ Specify PDN and APN The first one is the default.

      {

      ....

 

      erabs: [ E-RAB (E-UTRAN Radio Access Bearer) associated to the PDN or a QoS flow associated to the PDU session. The first E-RAB or QoS flow is the default radio bearer and must always be present. The additional E-RABs and QoS flows are dedicated radio bearers and must include a Traffic Flow Template (TFT) unless they are defined as UE initiated.

        ...

    },

    

   slices: [ Defines the QoS flows by S-NSSAI. It would carry one or multiple objects of { snssai: { }, qos_flows:[ ] } If a supported S-NSSAI is not present in the array, the QoS flows defined in erabs applies.

      {

       snssai: {  S-NSSAI value.

        sst: Slice Service Type.,

        sd: (Optional) Slice Differentiator.

       },

       qos_flows: [ Array of QoS flows. Each element of the array has the same structure as an element in erabs except that "5qi" shall be used instead of "qci".

        {

         "5qi": 5QI value

          priority_level: Priority level.

          pre_emption_capability: the ability of a particular type of traffic to displace other ongoing lower priority traffic when network resources are limited.

          pre_emption_vulnerability: the susceptibility of a particular type of traffic to being displaced by other traffic with higher priority and pre-emption capability.

        },

       ],

      },

   

     ],

  ]

 

}

Structure of IMS Configuration

This configuration is the one pointed by (symbolically linked to) ims.cfg. This is to configure IMS . At the top level, it defines runtime and operational settings such as logging (log_options, log_filename) and remote API access (com_addr). The next level defines IMS network interface endpoints and peer connections, including SIP server socket addresses (sip_addr), MMS server bind interface (mms_server_bind_addr), optional MME-facing SCTP endpoint for SMS over SG (sctp_addr), Cx interface connection/bind addresses to the HSS (cx_server_addr, cx_bind_addr), and the Rx interface address (rx_server_addr). Another layer defines service identity and subscriber/service behavior, including the global IMS domain (domain), included user database, echo/loopback numbers (echo), and call/media behavior such as mt_call_sdp_file. At the security and persistence layer, it configures IPsec capabilities (ipsec_aalg_list, ipsec_ealg_list) and runtime state storage via ue_db_filename, which persists IMS registration and pending SMS state. In short, the hierarchy is: runtime settings → IMS interfaces/peer connections → service identity and user/service definitions → security/media options → persistent state storage.

{

  log_options: configure what type of log to be collected

 

  log_filename: configure log file name and location

 

    sip_addr: [ List of SIP Server Sockets address

        ...

    ],

 

    mms_server_bind_addr:  the network interface on which MMS server will listen. It is used to configure the MMSC in the UE

 

    sctp_addr:  the IP address (and an optional port) for MME connection. This is only necessary for SMS over SG feature.

 

    cx_server_addr: the IP address (and optional port) of Cx SCTP connection to the HSS.

    cx_bind_addr: the IP address to which the Cx SCTP connection is bound

 

    rx_server_addr: the IP address of Rx SCTP connection to the MME

 

    com_addr: specify IP and port number for remote API

 

    domain: Global domain name (May be overriden for each user)

 

    include user data base

 

    echo: [ Echo(Loopback) phone number

      ...

    ],

 

    ipsec_aalg_list:  IPsec authentication algorithm supported by IMS

    ipsec_ealg_list:  IPsec encryption algorithm supported by IMS.

 

    mt_call_sdp_file: File to use as SDP when using MT call. Overrides global parameter.

 

    ue_db_filename:  the current IMS state(particular the registration info and pending SMS) in a persistent file. Refer to this for the details of this file

 

}

Structure of drb Configuration

This file is to configure drb (data radio bearer). This is not a major configuration file. It is a kind of subsidiary configuration file that are included in other major configuration file like enb.cfg. You can describe drb.cfg as a repeated bearer-profile hierarchy that is usually included from a higher-level file such as enb.cfg, rather than used as a standalone top-level system configuration. The file itself is structured as an array of DRB policy entries, where each entry typically corresponds to a qci (and therefore a bearer type/profile). Inside each entry, the hierarchy begins with bearer identification and usage flags such as qci and ims_dedicated_bearer (used to mark IMS/VoLTE-type dedicated bearers), then branches into protocol-layer configuration blocks including LTE PDCP settings (pdcp_config), NR PDCP settings (nr_pdcp_config, optionally restricted with restrict_to_ng_enb), RLC settings (rlc_config), and MAC logical channel settings (logical_channel_config). In short, the hierarchy is: drb.cfg array → per-bearer/QCI entry → bearer role flags → PDCP (LTE/NR) settings → RLC settings → logical channel (MAC) settings, making it a modular bearer-policy library that higher-level RAN configurations reference.

[This is made up of an array (repetition) of following structure. There are more parameters that can optionally be added.

 

  { for each qci, this structure is assigned .

    qci:

    ims_dedicated_bearer:  If set to true, it indicates that this QCI is used for IMS dedicated bearers (VoLTE, ...)

    pdcp_config: {  pdcp configuration for LTE

      

      },

      */

    },

    nr_pdcp_config: {  pdcp configuration for NR

      

      },

      restrict_to_ng_enb:  If set to true, the nr_pdcp_config settings are only used for UEs connected to the ng-eNB

    },

    rlc_config: { rlc configuration

      

    },

    logical_channel_config: {  MAC Logical channel configuration.

      

  },

]

Structure of ue-db Configuration

This file is to configure USIM / ISIM information. This is not a major configuration file. It is a kind of subsidiary configuration file that are included in other major configuration file like mme.cfg and ims.cfg. You can describe ue_db configuration as a subscriber-database hierarchy that is usually included from major core/IMS files such as mme.cfg and ims.cfg. At the top level, the file contains ue_db, which is an array of subscriber entries. Each entry represents one UE/subscriber profile and is organized into two main parts: USIM authentication parameters and IMS/ISIM identity parameters. The USIM side includes fields such as sim_algo, imsi, amf, sqn, and K, which define how the subscriber is authenticated at the mobile core level. The IMS/ISIM side includes fields such as impi, impu, domain, and authent_type, which define the subscriber’s IMS private/public identities and IMS authentication behavior. In short, the hierarchy is: ue_db array → per-subscriber entry → USIM authentication fields + IMS/ISIM identity/authentication fields, making it a reusable subscriber identity and credential database shared by NAS/core and IMS configuration.

{

ue_db: [ This is made up of an array (repetition) of following structure. There are more parameters that can optionally be added.

  {

    sim_algo: USIM authentication algorithm: xor, milenage or tuak

    imsi: IMSI value

    amf: Authentication Management Field

    sqn: Sequence Number

    K: K value

 

    impi: IMS priviate user identity

    impu: IMS public user identity

    domain: Home Network Domain name

    authent_type: Athentication Algorithm

},

Structure of Single LTE Cell

This shows the overall configuration file structure for Single LTE Cell. This is based on enb.default.cfg and you can refer to enb.default.cfg file for the example of detailed parameters.  Just try to grasp the big picture of the structure of the configuration file here.

You can describe a Single LTE Cell enb.cfg structure as a two-branch hierarchy under one LTE RAN node, built around cell_list[] and cell_default{}. At the top level, the file first defines node-wide and connectivity settings such as com_addr, RF driver include, mme_list (S1AP/MME address), gtp_addr, and enb_id, which apply to the overall eNB instance. Below that, the LTE cell configuration is split into two complementary parts: cell_list[], which contains the per-cell instance definitions, and cell_default{}, which contains the common default template used by all LTE cells. In the single-cell case, cell_list[] contains only one object, and that object usually holds cell-specific items such as broadcast PLMN (plmn_list), dl_earfcn, cell ID, and any per-cell overrides (for example, cell-specific RACH settings). The cell_default{} branch provides the shared LTE protocol and radio defaults, including antenna and bandwidth settings (n_antenna_dl, n_antenna_ul, n_rb_dl), PHY/MAC-related configurations (PHICH, PRACH, PUCCH, PUSCH, CQI/RI/SRS, scheduling, power control), and higher-layer defaults such as SRB/DRB and ciphering/integrity preferences. The key hierarchy rule is that cell_default{} defines the baseline, while cell_list[] overrides it per cell when the same parameter appears in both. In short, the structure is: global eNB settings → cell_list[] (single LTE cell instance) + cell_default{} (shared LTE template).

The key points to note here are

{

  /* Enable remote API and Web interface */

  com_addr: "ip",

  /* RF driver configuration. sdr card mapping is configured in the file : rf_driver/config.cfg */

  include "rf_driver/config.cfg",  

 

  mme_list: [   This is the ip address of your LTE core network

    {

      /* address of MME for S1AP connection. Must be modified if the MME runs on a different host. */

      mme_addr: "ip",

    },

  ],

  /* GTP bind address (=address of the ethernet interface connected to the MME). Must be modified if the MME runs on a different host. */

  gtp_addr: "ip", This is the ip address of NIC that is connected to core network

 

  /* high 20 bits of SIB1.cellIdentifier */

  enb_id: 0x1A2D0,

 

  /* list of cells */

  cell_list: [  Configuration for LTE Cells

  {

    /* Broadcasted PLMN identities */

    plmn_list: [

      "mccmnc",   plmn (mccmnc)

    ],

 

    dl_earfcn: value, dl earfcn. ul earfcn is automatically configured if not specified

 

    /* cell ID */

    /* RACH Config applicable only to this cell */

  },

  ], /* cell_list */

 

  /* default cell parameters */

  cell_default: {  Default Configuration for LTE Cells. . This applies to every cell in cell_list[]. If a configuration is not specified in cell_list[], the configuration in this section is used

 

    /* Number of Antenna for DL/UL and Bandwidth*/

    n_antenna_dl: value,  number of DL antennas

    n_antenna_ul: value,  number of UL antennas

    n_rb_dl:  LTE bandwidth in the unit of RBs 

 

    /* phich configuration */

    /* SIB Configuration */

    /* PDSCH dedicated config (currently same for all UEs) */

    /* PRACH Config */

    /* PUCCH dedicated config (currently same for all UEs) */

    /* PUSCH dedicated config (currently same for all UEs) */

    /* Scheduling request period (ms). Must be >= 40 for HD-FDD */

    /* CQI report config */

    /* RI reporting config */

    /* transmission mode */

    /* SRS dedicated config. */

    /* MAC configuration (same for all UEs) */

    /* CPU load limitation */

    /* dynamic power control */

    /* RRC/UP ciphering algorithm preference. EEA0 is always the last. */

    /* RRC integrity algorithm preference. EIA0 is always the last. */

    /* (in ms) send RRC connection release after this time of network inactivity */

    /* SRB configuration */

    /* DRB configuration */

  },

Structure of Single NR/SA Cell

This shows the overall configuration file structure for Single NR/SA Cell. This is based on gnb-sa.cfg and you can refer to gnb-sa.cfg file for the example of detailed parameters.  Just try to grasp the big picture of the structure of the configuration file here.

You can describe a Single NR SA Cell enb.cfg/gnb-sa.cfg structure as a two-branch hierarchy under one NR gNB node, centered on nr_cell_list[] and nr_cell_default{}. At the top level, the file defines node-wide runtime and connectivity settings such as com_addr, rf_driver, amf_list (NGAP/AMF peer), gtp_addr, en_dc_support, and rf_ports, which apply to the gNB instance as a whole. Below that, the NR cell configuration is split into two complementary branches: nr_cell_list[], which holds the actual NR cell instance definitions, and nr_cell_default{}, which provides the shared default template for all NR cells. In the single-cell SA case, cell_list[] is typically empty and nr_cell_list[] contains only one object, where you define cell-specific items such as rf_port, cell_id, band, dl_nr_arfcn, subcarrier_spacing, and ssb_pos_bitmap. The nr_cell_default{} branch then defines the common NR radio and protocol defaults, including channel bandwidth, DL/UL antenna counts, TDD UL/DL pattern, PLMN list, MIB/SIB scheduling and basic system information, PRACH/PDCCH/PDSCH/CSI-RS/PUCCH/SRS/PUSCH parameters, MAC behavior, ciphering/integrity options, and DRB configuration. The key hierarchy rule is the same as LTE: nr_cell_default{} provides the baseline, and nr_cell_list[] overrides it when the same parameter is explicitly set per cell. In short, the structure is: global gNB settings → nr_cell_list[] (single NR SA cell instance) + nr_cell_default{} (shared NR template).

The key points to note here are

{

  /* Enable remote API and Web interface */

  com_addr: "0.0.0.0:9001",

 

  rf_driver: {  Define and Configure rf_driver. this is the part in which you can configure what kind of RF hardware you use (e.g, Amarisoft SDR Card or Remote Radio Header etc)

        name: "sdr",

        /* list of devices. 'dev0' is always the master. */

        /* TDD: force the RX antenna on the RX connector */

        /* synchronisation source: none, internal, gps, external (default = none) */

        // sync: "gps",

  },

 

  amf_list: [    This is the ip address of your 5Gcore network

    {

      /* address of AMF for NGAP connection. Must be modified if the AMF runs on a different host. */

      amf_addr: "ip",

    },

  ],

 

  /* GTP bind address (=address of the ethernet interface connected to the AMF). Must be modified if the AMF runs on a different host. */

  gtp_addr: "ip", This is the ip address of NIC that is connected to core network

 

  en_dc_support: true,

 

  rf_ports: [ This is the configuration for the RF port of your hardware like frequency, sampling rate, number of antenna etc 

    {

 

    },

  ],

 

  /* list of cells */

  cell_list: [],  This is configuration for NR cell, but is set to be empty when RAT is NR SA single cell

 

  nr_cell_list: [  Configuration for NR Cells

  {

    rf_port: value,

    cell_id: value,

    

    /* band, arfcn, SCS, SSB bitmap */

    band: NR band

    dl_nr_arfcn: NR dl arfcn. ul_nr_arfcn is automatically configured if not specified

    subcarrier_spacing: subcarrier spacing of DL / UL

    ssb_pos_bitmap: ssb bitmap

  },

  ], /* nr_cell_list */

 

  nr_cell_default: { Default Configuration for NR Cells. This applies to every cell in nr_cell_list[]. If a configuration is not specified in nr_cell_list[], the configuration in this section is used

    /* number of antenna for DL, UL, CBW */

    bandwidth:  channel bandwidth 

    n_antenna_dl: value,  number of DL antennas

    n_antenna_ul: value,  number of UL antennas

    /* UL/DL Pattern (Applicable to TDD only) */

    /* PLMN List */

    /* SIB scheduling */

    /* Basic MIB/SIB1 Parameters */

    /* PRACH Params */

    /* PDCCH Params */

    /* PDSCH Params */

    /* CSI-RS Params */   

    /* PUCCH Params */

    /* SRS Params */

    /* PUSCH Params */

    /* MAC configuration */

    /* Ciphering, Integrity Option */

    /* DRB Config */

  },

}

Structure of NR/NSA Cell (1 LTE + 1 NR)

This shows the overall configuration file structure for NR/NSA Cell(1 LTE + 1NR). This is based on gnb-nsa.cfg and you can refer to gnb-nsa.cfg file for the example of detailed parameters.  Just try to grasp the big picture of the structure of the configuration file here.

You can describe an NR/NSA (1 LTE + 1 NR) configuration as a dual-RAT hierarchical tree under one combined eNB/gNB node, where LTE and NR are configured in parallel and linked for EN-DC operation. At the top level, the file defines shared node-wide settings such as com_addr, rf_driver, rf_ports (typically one RF port for LTE and one for NR), mme_list (LTE EPC/MME address, since NSA uses LTE core), gtp_addr, and en_dc_support: true to enable NSA behavior. Below that, the configuration splits into two parallel per-cell instance branches: cell_list[] for the LTE anchor cell and nr_cell_list[] for the NR secondary cell, with each list containing one object in the 1 LTE + 1 NR case. The LTE cell entry in cell_list[] defines LTE-specific identity and frequency settings (PLMN, EARFCN, PCI/TAC, etc.) and, importantly, includes en_dc_scg_cell_list[], which links the LTE anchor to the NR cell that will be added during NSA setup. The NR cell entry in nr_cell_list[] defines NR-specific cell settings such as rf_port, NR band, dl_nr_arfcn, subcarrier_spacing, and ssb_pos_bitmap. In parallel with these instance lists, the file also contains two default-template branches: cell_default{} for shared LTE parameters (antenna count, LTE bandwidth in RBs, SIB/RACH/PUCCH/PUSCH/CQI/SRS/MAC/measurement/DRB, etc.) and nr_cell_default{} for shared NR parameters (bandwidth, antenna count, TDD pattern, SSB timing, NR RACH/PDCCH/PDSCH/CSI-RS/PUCCH/SRS/PUSCH/MAC/SRB/DRB, etc.). The hierarchy rule is the same on both sides: the default blocks define the baseline, and the per-cell entries in cell_list[] / nr_cell_list[] override them when the same parameter is explicitly set. In short, the structure is: global NSA node settings → LTE cell instance branch + NR cell instance branch (linked by EN-DC) → LTE default template + NR default template.

The key points to note here are

  /* Enable remote API and Web interface */

  com_addr: "0.0.0.0:9001",

 

 rf_driver: {  Define and Configure rf_driver. this is the part in which you can configure what kind of RF hardware you use (e.g, Amarisoft SDR Card or Remote Radio Header etc)

        name: "sdr",

 

        /* list of devices. 'dev0' is always the master. */

        /* TDD: force the RX antenna on the RX connector */

        /* synchronisation source: none, internal, gps, external (default = none) */

 

  },

 

 

  rf_ports: [ This is the configuration for the RF port of your hardware like frequency, sampling rate, number of antenna etc 

    {

       /* RF port for the LTE cell */

    },

    {

        /* RF port for the NR cell */

    },

  ],

    

  mme_list: [   This is the ip address of your LTE core network. In case of NR NSA, LTE Core  (not 5G Core) is used

    {

      /* address of MME for S1AP connection. Must be modified if the MME runs on a different host. */

    },

  ],

 

  /* GTP bind address (=address of the ethernet interface connected to the MME). Must be modified if the MME runs on a different host. */

 

  en_dc_support: true, indicates NR NSA support

 

  /* list of cells */

  cell_list: [  Configuration for LTE Cells

  {

    rf_port: 0,

    /* Broadcasted PLMN identities */

    plmn_list: [

      "00101",

    ],

    /* Cell Frequency */

    dl_earfcn: value, dl earfcn. ul earfcn is automatically configured if not specified

    /* Cell ID - PCI, TAC */

    /* PRACH Root Sequence */  

 

    en_dc_scg_cell_list: [  Specify the NR cell that will be added during the NSA setup procedure

      { cell_id: id_value } Specify NR cell id that will be added

    ],

  },

  ], /* cell_list */

 

  nr_cell_list: [  Configuration for NR Cells

  {

    rf_port: 1,

    /* Cell ID */

    /* Cell Frequency - ARFCN, SCS, SSB Position */

    band:NR band

    dl_nr_arfcn:NR dl arfcn. ul_nr_arfcn is automatically configured if not specified

    subcarrier_spacing:subcarrier spacing of DL / UL

    ssb_pos_bitmap:ssb bitmap

  },

  ], /* nr_cell_list */

 

  /* default cell parameters for LTE */

  cell_default: {  Default Configuration for LTE Cells. . This applies to every cell in cell_list[]. If a configuration is not specified in cell_list[], the configuration in this section is used

    /* Number of DL / UL Antenna */

    n_antenna_dl: , number of DL antennas

    n_antenna_ul: , number of UL antennas

 

    /* Number of DL RB */

    n_rb_dl: LTE bandwidth in the unit of RBs 

 

    /* SIB1 */

    /* SIB schedule for Other SIBs */#if N_RB_DL == 6

    /* PDSCH dedicated config (currently same for all UEs) */

    /* RACH Config */

    /* PUCCH dedicated config (currently same for all UEs) */

    /* PUSCH dedicated config (currently same for all UEs) */

    /* MCS for Msg3 (=CCCH RRC Connection Request) */

    /* this CQI value is assumed when none is received from the UE */

    /* Scheduling request period (ms). Must be >= 40 for HD-FDD */

    /* CQI report config */

    /* RI reporting is done with a period of m_ri * cqi_period. m_ri = 0 (default) disables RI reporting. */

    /* transmission mode */

    /* SRS dedicated config. All UEs share these parameters. srs_config_index and freq_domain_position are allocated for each UE) */

    /* MAC configuration (same for all UEs) */

    /* CPU load limitation */

    /* dynamic power control */

    /* RRC/UP ciphering algorithm preference. EEA0 is always the last. */

    /* RRC integrity algorithm preference. EIA0 is always the last. */

    /* (in ms) send RRC connection release after this time of network inactivity */

    /* SRB configuration */

    /* measurement configuration */

    /* DRB configuration */

  },

 

  /* default cell parameters for NR */

  nr_cell_default: { Default Configuration for NR Cells. This applies to every cell in nr_cell_list[]. If a configuration is not specified in nr_cell_list[], the configuration in this section is used

    /* NR Bandwidth, Number of DL / UL Antenna */

     bandwidth: channel bandwidth 

    n_antenna_dl: value, number of DL antennas

    n_antenna_ul: value, number of UL antennas

    /* force the timing TA offset (optional) */

    /* TDD Pattern (Applicable only to TDD) */

    /* SSB Period */

    /* Cell ID (PCI) */

    /* Scheduling request period (slots). */

    /* DMRS A Pos */

    /* RACH Config */

    /* PDCCH Config - Both Common and Dedicated */

    /* PDSCH Config */

    /* CSI-RS Config */

    /* PUCCH Config */    

    /* SRS Config */

    /* PUSCH Config */

    /* MAC configuration */

    /* Ciphering / Integrity Config */

    /* SRB Support - Enable/Disable */

    /* DRB Config */

  },

}

Structure of NB-IoT Cell

This shows the overall configuration file structure for NB-IoT Cell. This is based on enb-nbiot.cfg and you can refer to enb-nbiot.cfg file for the example of detailed parameters. Basically the overall structure of NB-IoT cell configuration is same as LTE cell configuration because NB-IoT is also a type of LTE protocol. There are differences only in terms of detailed configurations  Just try to grasp the big picture of the structure of the configuration file here.

You can describe an NB-IoT cell configuration as an LTE-family hierarchical tree with an NB-IoT-specific cell branch, because NB-IoT follows the LTE-style structure even though many detailed parameters are different. At the top level, the file defines shared eNB/core connectivity settings such as com_addr, RF driver include, mme_list, gtp_addr, and enb_id, which apply to the overall node. Below that, the configuration branches depending on deployment mode: in standalone NB-IoT, the main NB-specific branch is nb_cell_list[] plus nb_cell_default{}; in non-standalone/in-band/guard-band style operation, you may also need cell_list[] to define the associated LTE base cell. The nb_cell_list[] branch contains the actual NB-IoT cell instance(s) (one object in the single-cell case), including PLMN, antenna counts, NB-IoT operation_mode, EARFCN, linkage to a base LTE cell (base_cell_id), and PRB placement (dl_prb, ul_prb), with optional non_anchor_list[] for additional non-anchor NB-IoT carriers. In parallel, nb_cell_default{} provides the shared NB-IoT protocol defaults, including SIB repetition behavior (r_sib1), coverage_levels[] (each level carrying its own NPRACH/msg3/paging/NPDCCH/NPDSCH/NPUSCH-related settings), two_harq_support, and common SIB/SRB settings. The same override rule applies here as in LTE/NR: nb_cell_default{} defines the baseline, and nb_cell_list[] overrides it per NB-IoT cell when the same parameter is explicitly set. In short, the structure is: global eNB settings → optional LTE base-cell branch (cell_list[]) + NB-IoT cell instance branch (nb_cell_list[]) → NB-IoT default template (nb_cell_default{}).

The key points to note here are

{

  /* Enable remote API and Web interface */

  com_addr: "ip",

  /* RF driver configuration. sdr card mapping is configured in the file : rf_driver/config.cfg */

  include "rf_driver/config.cfg",  

 

  mme_list: [   This is the ip address of your LTE core network

    {

      /* address of MME for S1AP connection. Must be modified if the MME runs on a different host. */

      mme_addr: "ip",

    },

  ],

  /* GTP bind address (=address of the ethernet interface connected to the MME). Must be modified if the MME runs on a different host. */

  gtp_addr: "ip", This is the ip address of NIC that is connected to core network

 

  /* high 20 bits of SIB1.cellIdentifier */

  enb_id: 0x1A2D0,

 

  /* list of cells */

  cell_list: [  Configuration for LTE Cells. You only need this block only when the NB IoT Operation mode is NOT standalone mode

  {

    /* Broadcasted PLMN identities */

    plmn_list: [

      "mccmnc",   plmn (mccmnc)

    ],

 

    dl_earfcn: , dl earfcn. ul earfcn is automatically configured if not specified

 

    /* cell ID */

    /* RACH Config applicable only to this cell */

  },

  ], /* cell_list */

 

  nb_cell_list: [  

    {

      plmn_list: [ plmn (mccmnc)

      ],

      n_antenna_dl: ,

      n_antenna_ul: ,

      operation_mode:

      dl_prb:   DL PRB number in the base LTE cell

      ul_prb:   UL PRB number in the base LTE cell

      base_cell_id:,

      operation_mode: NB IoT Operation Mode

      dl_earfcn: , dl earfcn. ul earfcn is automatically configured if not specified

     

      non_anchor_list : [  Non-anchor carriers : dl and ul_prb can be chosen more freely

        {

             dl_prb: ,   DL PRB number in the base LTE cell

             ul_prb: ,   UL PRB number in the base LTE cell

             operation_mode: NB IoT Operation Mode

        },

      ],

 

    },

  ], /* nbcell_list */

 

  /* default cell parameters */

  nb_cell_default: {  Default Configuration for LTE Cells. . This applies to every cell in cell_list[]. If a configuration is not specified in cell_list[], the configuration in this section is used

 

     r_sib1:  number of SIB1 repetitions

    coverage_levels: [  each coverage level corresponds to a NPRACH configuration. Depending on the coverage level, you may need to multiple blocks {  } of the following configurations 

      {

          /* RACH Configuration */

          /* msg3 configuration */

          /* Paging */

          /* NPDCCH User Search Space */

          /* NPDSCH config */

          /* NPUSCH config */

       },

   ];

    two_harq_support : eNB will use two HARQ processes in UL and DL for UE declaring two HARQ process support (UE category NB2 only)

    

    /* SIB Configuration */

    /* SRB configuration */

  },

 

 

Structure of  LTE Carrier Aggregation

This shows the overall configuration file structure for Single LTE Cell. This is based on enb-3cc.cfg and you can refer to enb-3cc.cfg file for the example of detailed parameters.  Just try to grasp the big picture of the structure of the configuration file here.

You can describe LTE Carrier Aggregation (CA) configuration as an LTE multi-cell hierarchical tree built around one shared cell_default{} template and a cell_list[] containing multiple LTE cell instances (for PCC and SCCs). At the top level, the file defines common eNB and core connectivity settings such as com_addr, RF driver include, mme_list, gtp_addr, and enb_id, which apply to the whole eNB node. Below that, the main LTE branch is cell_list[], but unlike single-cell LTE, this array contains multiple cell objects (for example, 3 cells in a 3CC CA setup). Each cell object defines the per-cell identity and frequency settings (such as rf_port, n_id_cell, dl_earfcn) and also contains an important nested branch, scell_list[], which describes how that cell relates to other cells as CA secondary carriers (SCells), including cell_id, cross_carrier_scheduling, scheduling_cell_id, ul_allowed, and rrc_configuration (e.g., initial, measurement, api_only). In parallel, cell_default{} provides the shared LTE protocol and radio defaults for all component carriers, including antenna counts, bandwidth (n_rb_dl), PHY/MAC settings, scheduling/CQI/RI/SRS, power control, security preferences, and SRB/DRB configuration. The key hierarchy rule remains the same: cell_default{} defines the baseline for all LTE cells, while each entry in cell_list[] can override those defaults per component carrier. In short, the structure is: global eNB settings → multi-cell cell_list[] (PCC/SCC cell instances with nested scell_list[] CA relationships) → shared LTE default template cell_default{}.

The key points to note here are

{

  /* Enable remote API and Web interface */

  com_addr: "ip",

  /* RF driver configuration. sdr card mapping is configured in the file : rf_driver/config.cfg */

  include "rf_driver/config.cfg",  

 

  mme_list: [   This is the ip address of your LTE core network

    {

      /* address of MME for S1AP connection. Must be modified if the MME runs on a different host. */

      mme_addr: "ip",

    },

  ],

  /* GTP bind address (=address of the ethernet interface connected to the MME). Must be modified if the MME runs on a different host. */

  gtp_addr: "ip", This is the ip address of NIC that is connected to core network

 

  /* high 20 bits of SIB1.cellIdentifier */

  enb_id: 0x1A2D0,

 

  /* list of cells */

  cell_list: [  Configuration for LTE Cells. In this configuration, you need to configure the multiple blocks of cell configuration that are used for the carrier aggregation. In this example, three cells are configured meaning it is for 3CC CA, but you can remove or add more cells depending on your test requirement

    {  Configuration for the first cell

      rf_port: ,Specify the rf_port (sdr card)  for the first cell

      n_id_cell: ,Physical Cell ID for the first cell

      

    dl_earfcn: ,DL Frequency for the first cell

 

    scell_list: [  Configuration for the cells that are used as secondary cells. You can configure as many as the secondary cell here, but all of the cell should be configured in cell_list. In this example, Refer to this document for further details

      {

        cell_id: ,Cell ID for a secondary cell

        cross_carrier_scheduling: ,enable / disable cross carrier scheduling

        scheduling_cell_id: ,  specify the scheduling cell id when cross carrier scheduling is enabled

        ul_allowed,specify whether UL is allowed for this cell or not

        rrc_configuration ,specify how to trigger carrier aggregation :  initial, measurement, api_only

       

      },

     {

        cell_id: ,Cell ID for a secondary cell

        cross_carrier_scheduling: ,enable / disable cross carrier scheduling

        scheduling_cell_id: ,  specify the scheduling cell id when cross carrier scheduling is enabled

        ul_allowed,specify whether UL is allowed for this cell or not

        rrc_configuration ,specify how to trigger carrier aggregation :  initial, measurement, api_only

       

      },

    ],

  },

    {  Configuration for the second cell

      rf_port: ,Specify the rf_port (sdr card)  for the second cell

      n_id_cell: ,Physical Cell ID for the second cell

      

    dl_earfcn: ,DL Frequency for the second cell

 

    scell_list: [  Configuration for the cells that are used as secondary cells. You can configure as many as the secondary cell here, but all of the cell should be configured in cell_list. In this example, Refer to this document for further details

      {

        cell_id: ,Cell ID for a secondary cell

        cross_carrier_scheduling: ,enable / disable cross carrier scheduling

        scheduling_cell_id: ,  specify the scheduling cell id when cross carrier scheduling is enabled

        ul_allowed,specify whether UL is allowed for this cell or not

        rrc_configuration ,specify how to trigger carrier aggregation :  initial, measurement, api_only

       

      },

     {

        cell_id: ,Cell ID for a secondary cell

        cross_carrier_scheduling: ,enable / disable cross carrier scheduling

        scheduling_cell_id: ,  specify the scheduling cell id when cross carrier scheduling is enabled

        ul_allowed,specify whether UL is allowed for this cell or not

        rrc_configuration ,specify how to trigger carrier aggregation :  initial, measurement, api_only

       

      },

    ],

  },

    {  Configuration for the 3rd cell

      rf_port: ,Specify the rf_port (sdr card)  for the third cell

      n_id_cell: ,Physical Cell ID for the third cell

      

    dl_earfcn: ,DL Frequency for the third cell

 

    scell_list: [  Configuration for the cells that are used as secondary cells. You can configure as many as the secondary cell here, but all of the cell should be configured in cell_list. In this example, Refer to this document for further details

      {

        cell_id: ,Cell ID for a secondary cell

        cross_carrier_scheduling: ,enable / disable cross carrier scheduling

        scheduling_cell_id: ,  specify the scheduling cell id when cross carrier scheduling is enabled

        ul_allowed,specify whether UL is allowed for this cell or not

        rrc_configuration ,specify how to trigger carrier aggregation :  initial, measurement, api_only

       

      },

     {

        cell_id: ,Cell ID for a secondary cell

        cross_carrier_scheduling: ,enable / disable cross carrier scheduling

        scheduling_cell_id: ,  specify the scheduling cell id when cross carrier scheduling is enabled

        ul_allowed,specify whether UL is allowed for this cell or not

        rrc_configuration ,specify how to trigger carrier aggregation :  initial, measurement, api_only

       

      },

    ],

  },

  ], /* cell_list */

 

  /* default cell parameters */

  cell_default: {  Default Configuration for LTE Cells. . This applies to every cell in cell_list[]. If a configuration is not specified in cell_list[], the configuration in this section is used

 

    /* Number of Antenna for DL/UL and Bandwidth*/

    n_antenna_dl: value, number of DL antennas

    n_antenna_ul: value, number of UL antennas

    n_rb_dl: LTE bandwidth in the unit of RBs 

 

    /* phich configuration */

    /* SIB Configuration */

    /* PDSCH dedicated config (currently same for all UEs) */

    /* PRACH Config */

    /* PUCCH dedicated config (currently same for all UEs) */

    /* PUSCH dedicated config (currently same for all UEs) */

    /* Scheduling request period (ms). Must be >= 40 for HD-FDD */

    /* CQI report config */

    /* RI reporting config */

    /* transmission mode */

    /* SRS dedicated config. */

    /* MAC configuration (same for all UEs) */

    /* CPU load limitation */

    /* dynamic power control */

    /* RRC/UP ciphering algorithm preference. EEA0 is always the last. */

    /* RRC integrity algorithm preference. EIA0 is always the last. */

    /* (in ms) send RRC connection release after this time of network inactivity */

    /* SRB configuration */

    /* DRB configuration */

  },

Structure of  LTE Handover

This shows the overall configuration file structure for Handover between LTE Cells. This is based on enb-2cell-ho.cfg  and you can refer to enb-2cell-ho.cfg file for the example of detailed parameters.  Just try to grasp the big picture of the structure of the configuration file here.

You can describe LTE handover configuration as an LTE multi-cell hierarchy focused on neighbor relationships and measurement-based mobility, built around cell_list[] and cell_default{}. At the top level, the file defines common eNB/core settings such as com_addr, RF driver include, mme_list, gtp_addr, and enb_id, which apply to the whole node. Below that, cell_list[] contains multiple LTE cell instances (typically source and target cells), and each cell entry defines its own identity/frequency settings (rf_port, n_id_cell, dl_earfcn) plus a nested ncell_list[] that declares neighbor cells and therefore possible handover targets (using neighbor PCI/cell ID and EARFCN). In parallel, cell_default{} provides the shared LTE radio/protocol defaults (PHY/MAC/SRB/DRB, bandwidth, antenna, scheduling, power control, security, etc.) and also contains the mobility-specific default layer, especially meas_config_desc, meas_gap_config, and ho_from_meas, which control how measurement configuration is generated and whether reported measurements automatically trigger handover. The key hierarchy rule remains the same: cell_default{} defines the baseline behavior, while each cell object in cell_list[] can override it, and the actual handover topology is expressed through each cell’s ncell_list[]. In short, the structure is: global eNB settings → multi-cell cell_list[] (source/target cells with nested neighbor lists) → shared LTE default template cell_default{} including measurement/handover policy.

The key points to note here are

{

  /* Enable remote API and Web interface */

  com_addr: "ip",

  /* RF driver configuration. sdr card mapping is configured in the file : rf_driver/config.cfg */

  include "rf_driver/config.cfg",  

 

  mme_list: [   This is the ip address of your LTE core network

    {

      /* address of MME for S1AP connection. Must be modified if the MME runs on a different host. */

      mme_addr: "ip",

    },

  ],

  /* GTP bind address (=address of the ethernet interface connected to the MME). Must be modified if the MME runs on a different host. */

  gtp_addr: "ip", This is the ip address of NIC that is connected to core network

 

  /* high 20 bits of SIB1.cellIdentifier */

  enb_id: 0x1A2D0,

 

  /* list of cells */

  cell_list: [  Configuration for LTE Cells. In this configuration, you need to configure the multiple blocks of cell configuration that are used for the carrier aggregation. In this example, three cells are configured meaning it is for 3CC CA, but you can remove or add more cells depending on your test requirement

    {  Configuration for the first cell

      rf_port: ,Specify the rf_port (sdr card)  for the first cell

      n_id_cell: ,Physical Cell ID for the first cell

      

    dl_earfcn: ,DL Frequency for the first cell

 

    ncell_list: [   This is the configuration for neghbour cell list. In the context of Handover scenario, this is the place where you specify the destination/target cell

      {

        n_id_cell: ,  Physical Cell ID for the target/destination cell

        dl_earfcn: ,  DL frequency for the target/destination cell

      },

    ],

  },

    {  Configuration for the second cell

      rf_port: ,Specify the rf_port (sdr card)  for the second cell

      n_id_cell: ,Physical Cell ID for the second cell

      

    dl_earfcn: ,DL Frequency for the second cell

 

    ncell_list: [

      {

        n_id_cell: ,  Physical Cell ID for the target/destination cell

        dl_earfcn: ,  DL frequency for the target/destination cell

      },

    ],

  },

  ], /* cell_list */

 

  /* default cell parameters */

  cell_default: {  Default Configuration for LTE Cells. . This applies to every cell in cell_list[]. If a configuration is not specified in cell_list[], the configuration in this section is used

 

    /* Number of Antenna for DL/UL and Bandwidth*/

    n_antenna_dl: value, number of DL antennas

    n_antenna_ul: value, number of UL antennas

    n_rb_dl: LTE bandwidth in the unit of RBs 

 

    /* phich configuration */

    /* SIB Configuration */

    /* PDSCH dedicated config (currently same for all UEs) */

    /* PRACH Config */

    /* PUCCH dedicated config (currently same for all UEs) */

    /* PUSCH dedicated config (currently same for all UEs) */

    /* Scheduling request period (ms). Must be >= 40 for HD-FDD */

    /* CQI report config */

    /* RI reporting config */

    /* transmission mode */

    /* SRS dedicated config. */

    /* MAC configuration (same for all UEs) */

    /* CPU load limitation */

    /* dynamic power control */

    /* RRC/UP ciphering algorithm preference. EEA0 is always the last. */

    /* RRC integrity algorithm preference. EIA0 is always the last. */

    /* (in ms) send RRC connection release after this time of network inactivity */

    /* SRB configuration */

    /* DRB configuration */

 

    meas_config_desc: {   If this is present, and if meas_config object is not present, the eNB will dynamically build the measurement configuration sent to the UE based on the content of this object and the list of neighbour cells defined in ncell_list object.  Refer to this document for the details.  Refer to this tutorial for real test example : Inter Frequency HO, Intra Frequency HO  

      a1_report_type: ,

      a1_rsrp: ,

      a1_hysteresis: ,

      a1_time_to_trigger: ,

      a2_report_type: ,

      a2_rsrp: ,

      a2_hysteresis: ,

      a2_time_to_trigger: ,

      eutra_handover: {   Existance of this configuration indicates this measurement is for Handover  

        a3_report_type: ,

        a3_offset: ,

        hysteresis: ,

        time_to_trigger:

      }

    },

 

    meas_gap_config:   measurement gap configuration  

 

    ho_from_meas: ,   enable / disable to trigger handover when the required measurement report is recieved  Refer to this document for the details.  

  },
© 2025 All rights reserved | Legal notice |