Amarisoft

NR SA NTN (Non Terrestrial Network)

This tutorial is to show you how to configure and test NR NTN.  NTN (Non Terrestrial Network) is a type of network deployment in which some type of non-terrestrial (e.g, satellite or other airborne component).  Overall protocol sequence of NTN is not much different from the existing NR RAN access (LTE NB, LTE, NR), but one major difference is to handle the long propagation delay between the ground components (eNB and/or DUT) and Satellite. There are one major components introduced in 3GPP NR NTN as listed below.

NOTE : This tutorial is only for NR based NTN. For LTE NB based NTN, refer to this note.

There are various different type of NTN deployment in  3GPP TR 38.821. Currently Amarisoft NTN implementation is as shown below.

LTE NB NTN Overview 01

NOTE : This feature is supported from Release 2023-03-30, but it is recommended to use the latest version.

Table of Contents

Introduction

The emergence of Non-Terrestrial Networks (NTN) within the 3GPP New Radio (NR) framework represents a significant advancement in wireless communication, enabling seamless connectivity in environments traditionally underserved by terrestrial infrastructure. NTN leverages non-terrestrial platforms such as satellites or airborne vehicles to extend the reach of 5G NR services to remote, rural, oceanic, and disaster-struck areas where ground-based networks may be impractical or economically unfeasible. Architecturally, NR NTN is designed to integrate with the existing NR Radio Access Network (RAN), preserving core protocol sequences while addressing unique challenges posed by the satellite or aerial link—most notably, the considerable propagation delays between terrestrial entities (e.g., gNB or Device Under Test) and their non-terrestrial counterparts. To accommodate these challenges, 3GPP has introduced enhancements such as additional System Information Blocks (SIBs), specifically tailored to deliver satellite-specific parameters like ephemeris data and default time delay, ensuring robust network synchronization and performance. The implementation of NR NTN, as detailed in 3GPP TR 38.821 and realized in platforms such as Amarisoft, empowers network operators and researchers to evaluate end-to-end NTN scenarios, test protocol adaptations, and validate service reliability under the unique conditions of non-terrestrial environments. This tutorial provides a practical guide to configuring and testing NR NTN deployments, equipping learners with the foundational knowledge and procedural steps necessary to navigate this innovative domain of modern wireless systems.

Summary of the Tutorial

This tutorial describes procedures for low layer testing of NTN (Non-Terrestrial Networks) using Amarisoft eNB and UEsim. It covers two main tests: one with a simulated GEO satellite and another with LEO, focusing on configuration, execution, and troubleshooting steps.

The tutorial emphasizes careful configuration matching, clock synchronization, and robust parameter tuning as essential for successful NTN low layer testing, especially when simulating dynamic satellite environments or integrating with external simulation/hardware components.

Test Setup

Test setup for this tutorial is as shown below.  This is just for low layer testing, you may not need any complicated IP layer setup.

With Amarisoft eNB and UEsim, we can try with following two different setups.  This figure presents two high-level test setups that can be built with Amarisoft eNB and UEsim for satellite-relay style scenarios, mainly to compare a more realistic over-the-air path with a fully simulated lab path. In setup [A], the satellite relay and space channel are treated as real, while the ground station uses an Amarisoft Callbox (eNB) and a real UE on the user side. In setup [B], the satellite relay and space channel are simulated, and both the ground station side and UE side are implemented in the lab using Amarisoft Callbox and Amarisoft UEsim. The key idea is that these two setups let you test similar end-to-end concepts at different levels of realism, cost, and controllability, from field-like validation to fully repeatable lab experimentation.

TestSetup Callbox NTN 01

Key Configuration Parameters

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

Before You Start : Time Synchronization

In NTN (Non-Terrestrial Networks), time synchronization across all communicating entities (satellite, gNB, UE, gateways, and sometimes multiple satellites) is fundamental, not just an implementation detail. This is because time directly maps to distance, frequency, and geometry in NTN.

There are multiple layers of technology required to achieve timing synchronization in NTN systems. These layers span from fine-grained timing, such as GNSS-disciplined clocks, PTP (IEEE 1588), and PHY-level frame alignment, to relatively coarse-grained synchronization, such as system clock alignment across hosts.

Each layer serves a different purpose. Fine-grained timing is mandatory for air-interface operation, including OFDM symbol alignment, timing advance, and Doppler compensation. Coarse-grained timing is mainly used to keep different system components operating on a consistent time reference.

In this section, I focus on one of the base minimum requirements: timing synchronization via NTP. NTP may not be sufficient for NTN PHY operation, but it is still an important prerequisite at the system level. This becomes especially important when testing NTN using Amarisoft Callbox and UE-sim. In such setups, the gNB, UE-sim, channel models, and supporting software often run on separate hosts or containers. If their system clocks are not aligned at least at the NTP level, issues such as inconsistent logs, invalid timing assumptions, and misleading test results can occur.

Enable NTP Client on Fedora Linux (Chrony)

This tutorial explains how to enable and verify NTP time synchronization (client mode) on a Fedora system using chrony, which is the default NTP implementation on Fedora. (NOTE : If you are testing with  Amarisoft Callbox and UEsim, perform this procedure on both Callbox and UEsim)

Prerequisites

Step 1: Install Chrony

Chrony is usually installed by default, but you can ensure it is present:

sudo dnf install -y chrony

Step 2: Enable and Start the Chrony Service

Enable chrony to start at boot and start it immediately:

sudo systemctl enable --now chronyd

Verify the service status:

systemctl status chronyd

You should see the service running (active).

Step 3: Enable NTP via timedatectl

Fedora uses timedatectl to manage system time synchronization.

Enable NTP:

sudo timedatectl set-ntp true

Verify:

timedatectl status

Expected output fields:

System clock synchronized: yes

NTP service: active

Step 4 (Optional): Configure Custom NTP Servers

Edit the chrony configuration file:

sudo nano /etc/chrony.conf

Add or modify NTP servers, for example:

server 0.pool.ntp.org iburst

server 1.pool.ntp.org iburst

server time.google.com iburst

Save the file and restart chrony:

sudo systemctl restart chronyd

Step 5: Verify Time Synchronization

Check synchronization status:

chronyc tracking

View NTP sources:

chronyc sources -v

A reachable source marked with ^* indicates active synchronization.

Step 6 (Optional): Force Immediate Time Sync

If the system clock is significantly incorrect:

sudo chronyc makestep

Troubleshooting

Check chrony service:

systemctl status chronyd

Check logs:

journalctl -u chronyd

Firewall (normally not required for client mode):

sudo firewall-cmd --list-all

Summary

sudo dnf install -y chrony

sudo systemctl enable --now chronyd

sudo timedatectl set-ntp true

chronyc tracking

Your Fedora system is now configured as an NTP client and will keep accurate time automatically.

Test 1 : NTN with Simulated GEO and UEsim

This is to configure and test NTN for Simulated GEO using Amarisoft UEsim as DUT.

Configuration

The configuration shown here is common configuration for all the subtests belonging to Test 1 and I will not show this configuration repeatedly for every subtest.

I have used gnb-sa-ntn.cfg which is included in the default installation package on Callbox (gNB)

NR SA NTN Test 1 Config 01 r20230512

I am using mme-ims.cfg and ue_db-ims.cfg  as they are.

NR SA NTN Test 1 Config 02 r20230512

On UEsim, I used ue-nr-ntn.cfg which is included in the default installation package on UEsim (NOTE : If you are using the commercial UE as a DUT, you don't need this step. Just make it sure that your UE support UE-assistance-information for release-preference).

NR SA NTN Test 1 Config 03 r20230512

gnb-sa-ntn.cfg  is configured as follows.

In gNB configruation,a single test parameter, NTN_MODE, is used as the top-level selector for satellite orbit type (GEO, MEO, or LEO), and the rest of the test behavior is adjusted from that choice. In the example, GEO is selected, and once that mode is fixed, several timing and retransmission-related parameters are set differently to match the expected propagation characteristics of the selected orbit, such as CSI_SRS_PERIOD, MAX_HARQ, T3XX_TIMER, and SRB_T_POLL_RETX. The figure also shows that CHANNEL_SIM is enabled so the eNB/gNB downlink channel simulator can emulate the satellite link between the ground station and the satellite relay. In other words, the configuration is organized so that one orbit-mode switch drives a consistent set of NTN-tuned radio and protocol parameters, making it easier to run comparable GEO/MEO/LEO tests without manually retuning every value each time.

NR SA NTN Test 1 Config 04 r20230512

Followings are the simplified configuration

#if NTN_MODE == 0

#define CSI_SRS_PERIOD   320

#define MAX_HARQ         2

#define T3XX_TIMER       2000

#define SRB_T_POLL_RETX  800

#elif NTN_MODE == 1

#define CSI_SRS_PERIOD   80

#define MAX_HARQ         5

#define T3XX_TIMER       1000

#define SRB_T_POLL_RETX  150

#else

#define CSI_SRS_PERIOD   40

#define MAX_HARQ         5

#define T3XX_TIMER       1000

#define SRB_T_POLL_RETX  80

#endif

If CHANNEL_SIM is enabled, you can apply various channel profile to simulate the radio link between ground station and satellite. In this test, only awgn is applied.  This setting allows the test setup to simulate the radio link between the ground station and the satellite within the lab. In this example, the downlink channel profile is configured under rf_ports using channel_dl, and the selected channel model is awgn, which applies additive white Gaussian noise to the signal path with a specified noise_level (shown as -50). The key idea is that once channel simulation is turned on, the test can replace the real space channel with a controlled and repeatable emulated channel condition, and in this particular case the scenario is simplified to AWGN-only behavior rather than using more complex fading or propagation models.

NR SA NTN Test 1 Config 05 r20230512

SSB periodicity is adjusted based on orbit type. In this test (with GEO), ssb_period is set to 20. This configuration shows an example of orbit-dependent NR cell parameter tuning in the gNB configuration, specifically for SSB periodicity. The nr_cell_list entry defines the NR cell basics (RF port, cell ID, band, ARFCN, subcarrier spacing, and SSB bitmap), and then uses a conditional block based on NTN_MODE to set ssb_period differently for different orbit types. In the example, when NTN_MODE == 0 (GEO), ssb_period is set to 20, while non-GEO modes use a shorter value (shown as 5) to place SSBs more closely for better UE-side timing estimation. The main idea is that even basic broadcast timing parameters like SSB periodicity may need to be tuned according to orbit characteristics, and the configuration is structured so this can be switched automatically by the same NTN mode selector used elsewhere.

NR SA NTN Test 1 Config 06 r20230512

Then enable sib19 which is to broadcast NTN related information. This example shows the NR cell default configuration section where NTN-related broadcast information is enabled by scheduling SIB19, which is the NR system information block used for NTN-specific information. The example places this under nr_cell_default, alongside general NR defaults such as bandwidth and antenna settings, and then configures system-information scheduling through sib_sched_list, si_window_length, and a dedicated sib19 block. In the shown configuration, sib19 is explicitly enabled with its own si_periodicity and si_value_tag, which means the gNB will periodically broadcast the NTN-related system information needed by the UE. The key idea is that NTN support is not only about radio timing and channel emulation parameters, but also about enabling the correct NR broadcast signaling so the UE can receive NTN-specific system information during cell access and operation.

NR SA NTN Test 1 Config 07 r20230512

Followings are the simplified configuration

sib19: {

    si_periodicity: 16,

    si_value_tag: 0

},

The basic idea is to configure these parameters differently based on RTT between the satellite and ground station. This settings shows the MAC-layer NTN tuning concept in the gNB configuration, where several MAC timers and limits are set differently depending on the selected orbit type (NTN_MODE) so they better match the expected round-trip time between the ground station and the satellite. The configuration uses conditional blocks (for GEO, MEO, and LEO) to assign different values to parameters such as retx_bsr_timer, sr_prohibit_timer, prohibit_phr_timer, and sr_trans_max, while also keeping the rest of the MAC configuration (such as HARQ-related limits and power-reporting behavior) in the same mac_config structure. The main idea is that these MAC behaviors should not use a one-size-fits-all setting in NTN, because GEO, MEO, and LEO have very different delay characteristics, and the timer values need to be scaled so retransmission, scheduling request, and power reporting procedures remain stable and efficient under each orbit’s RTT conditions.

NR SA NTN Test 1 Config 08 r20230512

Followings are the simplified configuration

mac_config: {

    msg3_max_harq_tx: MAX_HARQ,

    ul_max_harq_tx: MAX_HARQ, /* max number of HARQ transmissions for uplink */

    dl_max_harq_tx: MAX_HARQ, /* max number of HARQ transmissions for downlink */

    ul_max_consecutive_retx: MAX_HARQ * 5, /* disconnect UE if reached */

    dl_max_consecutive_retx: MAX_HARQ * 5, /* disconnect UE if reached */

    periodic_phr_timer: 0,

    phr_tx_power_factor_change: "dB3",

    periodic_bsr_timer: 20,

 

    retx_bsr_timer: 2560,

    sr_prohibit_timer: 512,

    prohibit_phr_timer: 500,

    sr_trans_max: 16

},

Then adjust RRC timers t300, t301, t319 appropriately for each orbit type. And then adjust t_PollRetransmit based on the type of the orbit. This setting shows the RRC-layer and SRB-related timer tuning step in the NTN-oriented gNB configuration, where orbit-dependent values defined earlier (through macro-style parameters such as T3XX_TIMER and SRB_T_POLL_RETX) are applied to actual protocol settings. In the timers_and_constants block, the RRC timers t300, t301, and t319 are assigned from T3XX_TIMER, so the same orbit-based timing policy can be consistently reused across multiple RRC procedures. In the srb_config block, t_PollRetransmit for SRB entries is assigned from SRB_T_POLL_RETX, which adjusts SRB retransmission behavior according to the selected orbit type and its RTT characteristics. The key idea is to centralize NTN mode-dependent timing decisions in one define section and then propagate those values into RRC and SRB configuration blocks, making the configuration easier to maintain and less error-prone when switching between GEO, MEO, and LEO tests.

NR SA NTN Test 1 Config 09 r20230512

Now for the configurations specific for ntn. The configuration parameter name itself is ntn. This settings shows the NTN-specific configuration block in the gNB configuration, where the parameter subtree named ntn is used to define orbit-dependent satellite information and the geographic positions needed for NTN operation or emulation. Inside this block, the configuration selects orbit-specific ephemeris behavior (for example geo, meo, or leo) and related timing validity such as ul_sync_validity, typically driven by the same NTN_MODE conditional logic used elsewhere. It then defines the ground station position (ground_position) with latitude, longitude, and altitude, which represents the location of the gNB, and—when channel simulation is enabled—defines the UE position (ue_position) inside the channel simulation control section so service-link delay and Doppler effects can be modeled more realistically. The figure also highlights that in UEsim-based testing, the UE position used here should be consistent with the UE-side configuration, so both ends of the emulated NTN link use the same geographic assumptions. Overall, this block is the place where NTN configuration moves from generic timer tuning into geometry-aware satellite/ground/UE modeling.

NR SA NTN Test 1 Config 10 r20230512

Followings are the simplified configuration

ntn: {

    ul_sync_validity: 240,

    default_ephemeris: "geo",

 

    ground_position: {

        latitude: 48.853,

        longitude: 2.348,

        altitude: 140

    },

 

    channel_sim_control: {

        type: "auto_feeder_service_link",

        ue_position: {

            latitude: 43.295,

            longitude: 5.373,

            altitude: 20

        },

        ue_doppler_shift: true

    },

},

ue-nr-ntn.cfg  is configured as shown below. (NOTE : If you are using the commercial UE as a DUT, you don't need this step. Just make it sure that your UE support UE-assistance-information for release-preference).

In UEsim configuration, you need to enable ntn functionality first by setting ntn:true and then configure the position of the UEsim. The position of UEsim is configured by the parameter ntn_ground_position and the ntn_ground_position on UEsim should match ue_position in gNB settings. This UE simulator configuration enables NTN mode for an NR test cell and sets the UE-side geographic position used for NTN-related delay/Doppler interpretation. At a high level, it defines one NR cell group for UEsim with the basic radio parameters (band, ARFCN, bandwidth, SCS, antenna settings), then explicitly turns on NTN behavior with ntn: true. The key NTN-specific part is ntn_ground_position, which represents the UE (DUT) location in the simulation, and this position should be aligned with the UE location configured on the gNB side (for example, in ntn.channel_sim_control.ue_position) so both ends use the same geometry when emulating the satellite service link.

NR SA NTN Test 1 Config 11 r20230512

Followings are the simplified configuration

cell_groups: [{

    ..

        ntn: true,

 

        ntn_ground_position: {

            latitude: 43.295,

            longitude: 5.373,

            altitude: 20

        },

    }],

}],

This part of the UEsim configuration defines the UE profile and capability settings used for the NTN test. It specifies the subscriber identity and key (imsi, K), then sets as_release: 17 so the simulated UE advertises Release 17 capability, which is required for NTN support. It also sets the UE category as NR and specifies the APN to be used for the data session (for example, ntn-internet). The important operational point is that the APN configured here must match an APN entry configured in the Callbox core (mme.cfg / pdn_list) so PDN/PDU session establishment can succeed during the test.. (NOTE : Make it sure that the apn name you specified here is configured in mme configuration in callbox)

NR SA NTN Test 1 Config 11 r20230513

Perform the Test

Run lte service on callbox and then check 'cell phy' and 'cell' command. Make it sure that cell is configured as you intended.

This step is a post-configuration verification on the Amarisoft Callbox to confirm that the NTN test cell is running with the intended radio parameters. After starting the LTE service, the cell phy and cell commands are used to inspect the active cell’s PHY-level and logical cell settings, such as NR band, bandwidth, ARFCN, antenna configuration, SCS, SSB ARFCN/SCS, PCI, TAC, and PLMN. In the example, the output confirms an NR cell on band n256, which is used here because it is a 3GPP NTN-related band, while the note also clarifies that the practical choice of band can depend on the equipment capabilities and test purpose. The main idea is to validate that the live runtime configuration matches the intended test configuration before proceeding with UE attach and NTN behavior testing..

NR SA NTN Test 1 Run 01 r20230512

This is not the mandatory process.. but I did this to collect SIB message in the log for a few seconds at the beginning. I did bcch=1 and after a few seconds did bcch=0.

LTE NB NTN Test 1 Run 02

Now start trace logging.

LTE NB NTN Test 1 Run 03

Power on UE on UEsim (If your DUT is a commercial phone, turn on the phone)

NR SA NTN Test 1 Run 04

Wait until the DUT complete the initial attach. (NOTE : If you are using a commercial UE and/or real satellite, you may need to do some additional troubleshooting for this step to work through)

NR SA NTN Test 1 Run 05

Log Analysis

Following is the log snapshot that are involved in communication with NTN.

Sample Log

First check SIB1 and see if the timers are configured as you intended and the cell is properly broadcasting about NTN supportability. The timers you need to check is t300,t301 and t319 in ue-TimersAndConstraints and the NTN supportability can be checked by the IE cellBarredNTN. Check the ue-TimersAndConstants fields (specifically t300, t301, and t319 ) to verify they match the orbit-tuned values you configured. At the same time, you confirm NTN support signaling by checking the cellBarredNTN information element, which indicates whether NTN access is barred or allowed for the cell. The key idea is to verify not just the config file values, but the actual broadcasted RRC content seen by the UE, ensuring the NTN-capable cell is advertising the intended behavior before attach and service testing.

NR SA NTN Test 1 Log 01 r20230512

Now check if SIB19 is transmitted and  ntn-Config IE is populated as you intended. The important information in this SIB is ta-Common and ephemrisInfo. Check that SIB19 is present, then look inside ntn-Config for the key NTN fields -- especially ta-Common (within the TA-related common information) and ephemerisInfo -- because these carry the timing and orbit-related information the UE needs for NTN operation. The main idea is to verify that enabling sib19 in configuration resulted in the correct broadcast NTN assistance information, not just that the scheduler is configured to send it.

NR SA NTN Test 1 Log 02 r20230512

With powering on UE and UE is doing the initial attach, check UE capability information and make it sure that the UE support ntn. If the UE capability information message contains the IE ntn-Parameters, it mean the UE support NTN. Look for the presence of the ntn-Parameters information element. If ntn-Parameters appears in the decoded UE capability message, it indicates the UE is advertising NTN support (Release 17 NTN-related capability) to the network. The key idea is to verify the UE’s declared capability at signaling level before interpreting later attach, registration, or data-session behavior as NTN-related success or failure.

NR SA NTN Test 1 Log 03 r20230512

At the lower layer log, confirm that RACH process went through. (NOTE : If you are testing NTN with real UE and real satellite, this step would be the first step that causes a lot of trouble and require troubleshooting). Confirm that the UE successfully completed the RACH procedure, which is the first critical gateway into the cell before higher-layer attach signaling can proceed. In the lower-layer logs, you check the sequence from PRACH detection to RAR (Random Access Response) and subsequent scheduling/UL transmissions, making sure the network responded correctly and the UE moved forward into RRC setup rather than stalling at random access. This is especially important in NTN testing because long delay, Doppler, and timing uncertainty can make the random access process much more fragile than in terrestrial scenarios. When testing with a real UE and a real satellite link, this is often the first stage where significant troubleshooting is required, so confirming a clean RACH flow is a major milestone before investigating higher-layer issues.

NR SA NTN Test 1 Log 04 r20230512

After the connection is established, gNB would re adjust timing advance periodically to maintain the connection by sending Timing Advance MAC CE.  After the UE connection is established, the gNB continues to maintain uplink timing alignment by periodically sending Timing Advance (TA) MAC Control Elements. In the MAC logs, these appear as TAG updates (for example, TAG:0 ta=...), and the repeated entries show that the network is actively refreshing the UE’s timing advance rather than leaving it fixed after random access. The spacing of these updates is tied to timing-related MAC behavior and practical link conditions, and in this example the periodicity is around the configured/default alignment-maintenance timescale (highlighted in the log view). The key point is that a successful NTN connection is not only about completing attach; it also requires ongoing timing maintenance, and periodic TA MAC CE transmission is a strong sign that the gNB is sustaining the link after access and setup.

NR SA NTN Test 1 Log 05 r20230512

Test 2 : NTN with LEO

This part is intended as a troubleshooting guide for all the issues you can encounter when testing LEO (Low Earth Orbit). Most of the difficulties come from the fact that a satellite in low earth orbit will move very quickly relative to the surface of the earth.

With generated satellite and embedded simulator

Performing a test with Amarisoft embedded channel simulator will remove most of the difficulties. You can use the standard configuration gnb-sa-ntn.cfg and set the macro NTN_MODE to 2.

At startup, the eNB will generate a satellite directly over the eNB position, and rapidly moving to the east from there on. You will have around 5 minutes during which the simulated satellite is visible to perform the test.

You can adjust the default_elevation_offset parameter to instantiate the satellite before or after its zenith pass if you want to experiment with a longer test duration or on the opposite to quickly simulate the behaviour when the satellite goes beyond visibility

On the UE side, the most important thing to check is that the clock is synchronized with the one on eNB. A few seconds difference will already mean that the satellite position estimation will be off and the connection may not suceed.

Of course, as with GEO testing, the UE position also needs to match the position specified by the parameter ue_position of the gNB NTN channel simulator

With a 3rd party external simulator or a real satellite

Most issues will arise when testing with an external channel simulator, here are the most obvious ones, and how to mitigate them

Clock synchronization

With an external channel simulator, you have now three devices that need to be perfectly in sync: The gNB, the channel simulator and the UE.

You will also use ephemeris from a real satellite with a TLE file, instead of the 'default_ephemeris' so there will be only a few passes per day, on precise timing : This is not convenient for testing. So, you need to have the ability tofreely change the clock on the three devices in order to replay a given pass without restriction.

One solution is to set one component of the system, eg the channel simulator, as an NTP server. And setup NTP client on eNB and UE side to fetch the date and time from the channel simulator.

Timing and frequency errors

Errors between the calculation performed on eNB side, UE side and channel simulator will in the end gives some errors on the eNB UL side: The timing and frequency of the UL signal received from the UE will be off.

The main causes for these errors will be :

By carefully configuring the setup, these errors can be minimized but the eNB still needs to be robust to unforeseen errors.

Concerning the timing robustness, it is best to use PRACH format 1 (prach_configuration_index from 28 to 52), which has the biggest cyclic prefix. Since the timing inaccurracy can occur in both directions, it is advised to set rx_ta_offset in the middle of the PRACH reception window.

Concerning the UL frequency robustness, the problem is that NR (and OFDM protocol in general) are very sensitive to frequency error, and there is no builtin mechanism in the NR protocol to signal the UE of a frequency error.

So the eNB needs to rely on an ad-hoc solution to estimate the frequency error based on signal received from the UE and correct them. Note that this solution will only work if all the UE<->eNB links will share the same kind of frequency errors.

The large_freq_shift configuration object is used to estimate the frequency error seen on the PRACH signals. The gNB will perform some measurements on the first PRACH (and discard them) before applying a frequency correction and resuming normal PRACH operations.

Putting it all together

Here are the relevant parameters of the configuration file that need to be present and/or tuned depending on how the integration is going :

  rx_ta_offset: 650,                    // Middle of the timing reception window of the PRACH
  [...]
  nr_cell_list: [
  {
    [...]
    root_sequence_index: 12,            // This root sequence index give consistent results when signal frequency is off
    compute_freq_shift: true,           // Necessary for the large_freq_shift feature
    prach: {
      prach_config_index: 40,           // PRACH format 1, once every 2 frames
      zero_correlation_zone_config: 0,  // Maximum timing error tolerance
      ra_response_window: 10,
      ssb_per_prach_occasion: 1,
      cb_preambles_per_ssb: 8,
      [...]
    },
    [...]
    ntn: {
      large_freq_shift: {
        prach_range_sc: 128,            // Maximum frequency error correction in PRACH SCS unit. (Here 128*1.25KHz = 160 kHz)
        prach_n_acc: 5,                 // Number of PRACH to accumulate before estimating the frequency offset
        ta_tolerance: 8,                // TA range below which PRACH are considered coming from the same UE
        average_mode: true,             // Averaging strategy to determine the frequency error based on the prach_n_acc PRACHs : average or mode
      },
      [...]
    }

Test 3 : NTN to TN Handover

This is to configure and test Handover from NTN to TN cell using Amarisoft UEsim as DUT. Overall scenario is illustrated as below. The UE (UEsim) establish the initial attach to NTN cell and switch (Handover) to TN Cell (i.e, gNB cell on the ground) as the satellite moves away from NTN gNB.

Configuration

The configuration shown here is common configuration for all the subtests belonging to Test 1 and I will not show this configuration repeatedly for every subtest.

I have used gnb-sa-tn-ntn-ho.cfg which is included in the default installation package on Callbox (gNB)

NR SA NTN Test 1 Config 01 r20230512

I am using mme-ims.cfg and ue_db-ims.cfg  as they are.

NR SA NTN Test 1 Config 02 r20230512

On UEsim, I used ue-nr-tn-ntn-ho.cfg which is included in the default installation package on UEsim (NOTE : If you are using the commercial UE as a DUT, you don't need this step. Just make it sure that your UE support UE-assistance-information for release-preference).

NR SA NTN Test 1 Config 03 r20230512

gnb-sa-tn-ntn-ho.cfg  is configured as follows.

In gNB configruation, specify satellite orbit first with the test parameter NTN_MODE. You can select the type among GEO, MEO, LEO. In this test, GEO is selected.  Once this parameter (NTN_MODE) is specified, various other test parameters are configured based on the selected NTN_MODE. CSI_SRS_PERIOD, MAX_HARQ, T3XX_TIMER, SRB_T_POLL_RETX are the parameters configured differently based on NTN_MODE. And CHANNEL_SIM is enabled to simulate the radio link between the ground station and satellite.  Once NTN_MODE is selected, orbit-specific values such as CSI/SRS period, maximum HARQ retransmissions, RRC timer base (T3XX_TIMER), and SRB t-PollRetransmit are assigned using conditional defines so the rest of the configuration can reuse them consistently. In short, this block acts as the central NTN profile switchboard that sets orbit-aware timing and retransmission behavior before those values are consumed in MAC/RRC/cell configuration later in the file.

NR SA NTN Test 1 Config 04 r20230512

If CHANNEL_SIM is enabled, you can apply various channel profile to simulate the radio link between ground station and satellite. In this test, only awgn is applied.  This configuration block enables the built-in channel simulator on the gNB side so the test can emulate the radio link between the ground station and satellite without using a real satellite path. When CHANNEL_SIM is enabled, a channel model is attached to the RF port configuration (rf_ports), and in this example the downlink channel profile is set to AWGN with a specified noise level (noise_level: -50). The main idea is that this provides a controlled baseline NTN test environment: the NTN procedures and timing behavior can be validated first with a simple impairment model before moving to more complex channel profiles or real over-the-air/satellite conditions.

NR SA NTN Test 1 Config 05 r20230512

The first cell (the cell mapped to rf_port 0) is configured for ntn cell. NTN mode is set to GEO in this test and SIB19 is transmitted to broadcast ephemeris information of the cell. In this cell, the TN cell (cell_id 2) is configured as a neighbour cell(a handover destination candidates for this test). The nr_cell_list entry defines the cell identity, RF mapping, and radio parameters (band/ARFCN/SCS/SSB settings), and it also sets the SSB periodicity according to the selected orbit profile (GEO in this case). The plmn_list section defines the served PLMN/TAC and slice information, while the ntn block provides the NTN-specific parameters such as the default ephemeris type (geo), ground station position, and UE position (used especially when channel simulation is enabled to emulate feeder/service-link behavior and Doppler). In addition, the sib19 scheduling section is enabled so the gNB actually broadcasts NR NTN system information (including NTN configuration/ephemeris-related content) over the air. Overall, this is the core cell-level setup that turns a normal NR cell into an NTN test cell, combining radio settings, NTN geometry, and SIB19 broadcast configuration.

Followings are the simplified configuration

nr_cell_list: [

  {

    rf_port: 0,

    cell_id: 0x01,

 

    band: 256,

    dl_nr_arfcn: 437000,

    ssb_subcarrier_spacing: 15,

    subcarrier_spacing: 30,

    ssb_pos_bitmap: "1000",

 

    ssb_period: 20, /* GEO */

 

    n_id_cell: 500,

 

    plmn_list: [

      {

        tac: 100,

        plmn: "00101",

        reserved: false,

        nssai: [

          { sst: 1 },

        ],

      },

    ],

 

    ncell_list: [

      {

        cell_id: 2, /* TN neighbour / HO target candidate for this test */

      },

    ],

  },

],

 

ntn: {

  ul_sync_validity: 900,

  default_ephemeris: "geo",

 

  ground_position: {

    latitude: 48.853,

    longitude: 2.348,

    altitude: 140,

  },

 

  channel_sim_control: {

    type: "auto_feeder_service_link",

    ue_position: {

      latitude: 43.295,

      longitude: 5.373,

      altitude: 20,

    },

    ue_doppler_shift: true,

  },

},

 

nr_cell_default: {

  sib_sched_list: [

    {

      filename: "sib2_nr.asn",

      si_periodicity: 16,

    },

  ],

  si_window_length: 40,

  sib19: {

    si_periodicity: 16,

    si_value_tag: 0,

  },

},

The cell mapped to rf_port1 is configured for the regular NR Cell (TN Cell).  In this cell, the NTN cell (cell_id 1) is configured as a neighbour cell(a handover destination candidates for this test). In this setup, this cell acts as the normal serving NR cell, while the NTN cell (cell_id 1) is added in ncell_list as a neighbor cell / handover candidate. So the purpose of this block is to define the TN cell’s radio parameters (band/ARFCN/SCS/SSB), broadcast identity (PLMN/TAC), and neighbor relationship toward the NTN cell for mobility testing.

Followings are the simplified configuration

{

  rf_port: 1,

  cell_id: 0x02,

 

  // TN cell radio configuration

  band: 7,

  dl_nr_arfcn: 536000,

  ssb_subcarrier_spacing: 15,

  subcarrier_spacing: 15,

  ssb_pos_bitmap: "1000",

 

  // Cell identity / SSB

  n_id_cell: 501,

  ssb_period: 20,

 

  // Broadcast PLMN / TAC / slice info

  plmn_list: [

    {

      tac: 200,

      plmn: "00101",

      reserved: false,

      nssai: [

        { sst: 1 }

      ]

    }

  ],

 

  // Neighbor cell list (NTN cell as HO candidate)

  ncell_list: [

    { cell_id: 1 }

  ]

}

The default cell configuration (nr_cell_dfault) is very similar to regular NR to NR cell configuration except some specific configurations for NTN cell.  This nr_cell_default block is basically the common NR baseline configuration shared by both a regular TN cell and an NTN cell, and then you add or override a few NTN-specific items where needed. In other words, most of the PHY/MAC/PUSCH behavior is still standard NR, so the same default structure is reused. The difference is that for NTN testing, some parameters are tuned to better tolerate long delay, larger timing uncertainty, and satellite-specific operating conditions. In the setup shown below, the pusch section is a good example of this approach: it keeps normal NR uplink settings (MCS tables, Msg3-related parameters, power-related settings, rank limits, TA update behavior), while adding an optional orbit/band-specific adjustment such as n_harq_process under #if NTN_FR2. So the idea is not to create a completely different nr_cell_default, but to start from regular NR defaults and selectively patch only the parameters that need NTN-aware behavior.

In MAC configuration (mac_config), various harq configurations (msg3_max_harq_tx, ul_max_harq_tx,  dl_max_harq_tx) and retransmission configurations (ul_max_consecutive_retx,dl_max_consecutive_retx) are configured to accommodate the propagation dely of the NTN cell. In addition, some mac layer timers (retx_bsr_timer, sr_prohibit_timer, prohibit_phr_timer) are configured differently depending on the orbits of the satellite.  This mac_config section is where the NTN cell is tuned so that MAC behavior can tolerate the much larger propagation delay of satellite links. The HARQ-related parameters such as msg3_max_harq_tx, ul_max_harq_tx, and dl_max_harq_tx are set to allow enough retransmission opportunities, and the consecutive retransmission limits (ul_max_consecutive_retx, dl_max_consecutive_retx) are also scaled so the UE is not disconnected too aggressively in a long-RTT environment. In addition to HARQ, MAC timers such as retx_bsr_timer, sr_prohibit_timer, and prohibit_phr_timer are adjusted by orbit type (NTN_MODE for GEO/MEO/LEO), because each orbit has a different expected RTT and timing behavior. As a result, GEO uses the longest timer values, while MEO and LEO use progressively shorter values. The same orbit-dependent idea is also applied to timers_and_constants (t300, t301, t319) so the RRC procedures remain stable and do not timeout prematurely under NTN propagation delay.

Followings are the simplified configuration

/* Simplified parameter setting (GEO example) */

 

mac_config: {

  /* HARQ / retransmission robustness for NTN */

  msg3_max_harq_tx: 2,

  ul_max_harq_tx: 2,

  dl_max_harq_tx: 2,

  ul_max_consecutive_retx: 10,   /* = MAX_HARQ * 5 */

  dl_max_consecutive_retx: 10,   /* = MAX_HARQ * 5 */

 

  /* Common MAC settings */

  periodic_phr_timer: 0,

  phr_tx_power_factor_change: "dB3",

  periodic_bsr_timer: 20,

 

  /* GEO-specific timers (long RTT) */

  retx_bsr_timer: 2560,

  sr_prohibit_timer: 512,

  prohibit_phr_timer: 500,

  sr_trans_max: 16

},

 

timers_and_constants: {

  /* GEO-specific RRC timers */

  t300: 2000,

  t301: 2000,

  t319: 2000

},

 

srb_config: [

  {

    id: 1,

    t_PollRetransmit: 800

  },

  {

    id: 2,

    t_PollRetransmit: 800

  }

],

Then measurement configuration (meas_config_desc) should be configured to trigger the handover based on radio channel condition.  It defines how the gNB evaluates radio quality and when it should trigger handover measurement reporting from the UE. It sets threshold-based events (A1/A2) to indicate when the serving cell is good enough or becoming weak, and it also defines the A3-based NR handover condition that compares the neighbor cell against the serving cell. In practice, this is the policy that tells the UE when to start reporting, what metric to use (here RSRP), and how stable the condition must be (hysteresis and time-to-trigger) before the report is considered valid. The meas_gap_config part defines the measurement gap pattern so the UE has time to measure the neighbor frequency/cell reliably during connected mode.

Followings are the simplified configuration

/* Measurement configuration to trigger HO based on radio condition */

meas_config_desc: {

  a1_report_type: "rsrp",

  a1_rsrp: -60,

  a1_hysteresis: 10,

  a1_time_to_trigger: 100,

 

  a2_report_type: "rsrp",

  a2_rsrp: -70,

  a2_hysteresis: 0,

  a2_time_to_trigger: 100,

 

  nr_handover: {

    a3_report_type: "rsrp",

    a3_offset: 6,

    hysteresis: 0,

    time_to_trigger: 100

  },

 

},

 

meas_gap_config: {

  pattern_id: 0

},

ue-nr-tn-ntn-ho.cfg  is configured as shown below. (NOTE : If you are using the commercial UE as a DUT, you don't need this step. Just make it sure that your UE support UE-assistance-information for release-preference).

In UEsim configuration, you need to enable ntn functionality first by setting ntn:true and then configure the position of the UEsim. The position of UEsim is configured by the parameter ntn_ground_position and the ntn_ground_position on UEsim should match ue_position in gNB settings.

UEsim is configured with two RF chains (rf_port 0 and 1). The first RF chain (rf_port 0) is mapped to NTN Cell and the second RF chain (rf_port 1) is mapped to TN cell. This UEsim configuration defines a dual-cell NR test setup where one UE instance is prepared to interact with two different cells at the same time, using two separate RF chains. At the top level, the cell_groups block sets the group as NR, enables multi-UE support, and provides the UE ground position, which is important for NTN-related delay and Doppler modeling consistency. Inside the cells array, each entry represents one RF-chain-to-cell mapping: the first cell (rf_port: 0) is configured for the NTN cell (band 256), and the second cell (rf_port: 1) is configured for the terrestrial NR cell (band 7). Each cell entry carries its own frequency and SSB-related parameters (dl_nr_arfcn, ssb_nr_arfcn, SCS settings), so UEsim can synchronize and operate against both links correctly in the same scenario, which is useful for NTN/TN mobility or handover validation.

Followings are the simplified configuration

cell_groups: [{

  group_type: "nr",

  multi_ue: true,

  cell_sync: false,

 

  ground_position: {

    latitude: 43.2947,

    longitude: 5.37306,

    altitude: 20

  },

 

  cells: [

    { /* NTN cell on RF port 0 */

      rf_port: 0,

      bandwidth: CELL_BANDWIDTH,

      band: 256,

      dl_nr_arfcn: 437000,

      ssb_nr_arfcn: 436850,

      ssb_subcarrier_spacing: 15,

      subcarrier_spacing: 15,

      n_antenna_dl: N_ANTENNA_DL,

      n_antenna_ul: 1

    },

 

    { /* TN cell on RF port 1 */

      rf_port: 1,

      bandwidth: CELL_BANDWIDTH,

      band: 7,

      dl_nr_arfcn: 536000,

      ssb_nr_arfcn: 535970,

      ssb_subcarrier_spacing: 15,

      subcarrier_spacing: 15,

      n_antenna_dl: N_ANTENNA_DL,

      n_antenna_ul: 1

    }

  ]

}]

Then you need to set as_release 17 since NTN is supported from release 17 and specify the apn name that you want to use for this test. (NOTE : Make it sure that the apn name you specified here is configured in mme configuration in callbox) . The key point is that the UE capability is set to as_release: 17, because NTN support is handled from Rel-17. It also sets the UE category to NR (ue_category: "nr") and defines the APN (apn) that the UE will request during PDU session setup. That APN name must match an APN configured on the Callbox core side (MME/Core config), otherwise the attach/session setup may fail even if radio connection succeeds. The imsi and K identify the test subscriber, and the optional tun_setup_script (commented in this example) can be enabled if you want UEsim to create a TUN interface for user-plane traffic testing.

NR SA NTN Test 1 Config 11 r20230513

Perform the Test

Run lte service on callbox and then check 'cell phy' and 'cell' command. Make it sure that cell is configured as you intended. In this test, n256 is used because it is the band allocated for NTN by 3GPP, but in terms of the equipment capability it can support any band for NTN test.

NR SA NTN Test 1 Run 01 r20230512

This is not the mandatory process.. but I did this to collect SIB message in the log for a few seconds at the beginning. I did bcch=1 and after a few seconds did bcch=0.

LTE NB NTN Test 1 Run 02

Now start trace logging.

LTE NB NTN Test 1 Run 03

Power on UE on UEsim (If your DUT is a commercial phone, turn on the phone)

NR SA NTN Test 1 Run 04

Wait until the DUT complete the initial attach. (NOTE : If you are using a commercial UE and/or real satellite, you may need to do some additional troubleshooting for this step to work through)

NR SA NTN Test 1 Run 05

Once UEsim is in connection with NTN cell, reduce the cell power to trigger the handover . This step is a practical way to force the UE to leave the NTN cell and move to the neighbor TN cell for handover verification. After the UE is stably connected on the NTN cell, the Callbox command cell_gain 1 -14 is used to reduce the transmit power of the NTN cell (cell ID 1 in this example) by 14 dB. As the NTN serving cell signal quality drops, the UE measurements cross the handover thresholds configured earlier, and the handover procedure is triggered toward the target cell. In the trace, you can see the UE context move from the original cell to the target cell, which confirms that the measurement configuration and neighbor-cell settings are working together correctly. The exact gain reduction needed is not fixed; it depends on RF conditions, channel simulation settings, fading/noise, and relative power balance between the NTN and TN cells.

Log Analysis

Following is the log snapshot that are involved in communication with NTN and Handover to TN cell.

Sample Log

First thing to note is measurement configurations to detect appropriate channel condition to complete the handover.

RRC Reconfiguration message configures two measurement objects. It configures two measurement object - measObjectId 1 for an NTN cell (measObjectNR) with frequency 436580 (ssbFrequency) and measObjectId 2 for a terrestrial TN cell (measObjectNR) with frequency 359700 (ssbFrequency). Each object includes SSB subcarrier spacing (ssbSubcarrierSpacing), periodicity/offset (periodicityAndOffset), reference signal config (referenceSignalConfig), and frequency band indicators (freqBandIndicatorNR).

It configures two measurement report objects (reportConfigToAddModList) - reportConfigId 1 for Event A2 (eventTriggered → eventId: eventA2), including threshold RSRP (a2-Threshold-rsrp), hysteresis (hysteresis), report interval (reportInterval), and report quantity (reportQuantityCell). It also lists reportConfigId 2 for Event A3 (eventTriggered → eventId: eventA3), including offset RSRP (a3-Offset-rsrp), report interval (reportInterval), report amount (reportAmount), and reporting cells (maxReportCells).

The same message configures the association between a measurement object and a reporting event. In the section measIdToAddModList, entry measId 1 links measurement object 1 (measObjectId 1, corresponding to the NTN cell) with report configuration 1 (reportConfigId 1, corresponding to Event A2). This enables measurement of the NTN cell under the Event A2 reporting condition.

When the condition is met, gNB configures another measurement item : entry measId 2 which links measurement object 2 (measObjectId 2, corresponding to the TN cell) with report configuration 2 (reportConfigId 2, corresponding to Event A3). This enables measurement of the TN cell under the Event A3 reporting condition.

A Measurement Report (measurementReport) sent by the UE after Event A2 was triggered. The report contains the field measResults contains measId 1 (linked to Event A2), and measResultServingMOList includes serving cell results. Within it, measResultServingCell reports PCI (physCellId 500) with measurement values of rsrp, rsrq, and sinr.

After the first expected measurement report, gNB send RRC Reconfiguration (rrcReconfiguration) that configures both a new reporting event and a measurement gap. In reportConfigToAddModList, reportConfigId 1 is defined for Event A1 (eventId: eventA1) with threshold RSRP (a1-Threshold-rsrp), hysteresis (hysteresis), reporting interval (reportInterval), and report quantity (reportQuantityCell). Below, in measGapConfig, the field gapUE with setup specifies measurement gaps, including gapOffset 16, mgta ms8, and related parameters, enabling the UE to perform inter-frequency/inter-RAT measurements.

When the certain radio condition is met, the UE send Measurement Report (measurementReport) for Event A3. In the measurement report, measResults contains measId 2 (linked to Event A3). The field measResultServingMOList reports serving cell results (servCellId 0, physCellId 500) with measurements value of rsrp, rsrq, sinr. Additionally, measResultNeighCells (measResultListNR) reports a neighboring cell (physCellId 501) with values of rsrp, rsrq, sinr. This indicates the UE is evaluating handover conditions by comparing serving and neighbor cell quality.

On the reception of the expected measurement report, gNB sends RRC Reconfiguration (rrcReconfiguration) that triggers a handover. In the message, the target cell is identified by physCellId 501, which corresponds to the terrestrial TN cell. The configuration includes downlinkConfigCommon with carrier frequency (frequencyInfoDL), absoluteFrequencySSB , subcarrierSpacing , and carrierBandwidth . This indicates the UE is instructed to hand over from its current serving cell(NTN cell) to the new physical cell ID 501 on the TN network.

Test 4 : Conditional Handover

Amarisoft support Conditional Handover for NTN as well. CHO for NTN is covered in a separate tutorial referenced below

 

RRC / NAS Signaling

SIB19 (NR)

: This is SIB19 containing ephemeris

{

  message c1: systemInformation: {

    criticalExtensions systemInformation: {

      sib-TypeAndInfo {

        sib19-v1700: {

          ntn-Config-r17 {

            ntn-UlSyncValidityDuration-r17 s240,

            cellSpecificKoffset-r17 520,

            ta-Info-r17 {

              ta-Common-r17 62210800

            },

            ephemerisInfo-r17 orbital-r17: {

              semiMajorAxis-r17 8394210402,

              eccentricity-r17 0,

              periapsis-r17 0,

              longitude-r17 248299011,

              inclination-r17 0,

              meanAnomaly-r17 533258

            }

          }

        }

      }

    }

  }

}

 

FAQ

I am putting a list of frequently asked questions and answers that would help everybody.

 

[Q1] why we need channel simulator ?

[A1] It is necessary to simulate the constantly changing real time position of the satellite

 

[Q2] do we always need to use the channel simulator ?

[A2] Yes for MEO or LEO in which delay and doppler varies relatively in large scale. Maybe optional to GEO in which delay and doppler does not vary widely. (NOTE : You may use the internal channel simulator at the testing phase in quick and easy way, but you can also use an external satellite channel simulator as well).

 

[Q3] What is the maximum delay simulated by Amarisoft Channel Simulator ?

[A3] Up to several seconds. The maximum value will depend on the sample rate, the value is max_delay in s = 2.147e9 / (sample_rate in Hz). In NB-IoT, for example, the sample rate is usually 1.92 MHz, so the max_delay is around 1118 seconds.

 

[Q4] What is the minimum configurable altitude of a satellite ?

[A4] The 3GPP encoding for the semi-major axis has a minimum of 6500 km, so a minimum of 122(=6500-6378) km altitude, where 6378 is the radius of the earth

 

[Q5] For ue_position, ground_position, we allow the altitude with the range of -1000m to 20km, what is the reason to allow negative values ?

[A5] It is to configure altitude below sea level. (https://en.wikipedia.org/wiki/List_of_places_on_land_with_elevations_below_sea_level )

 

 

 

 

© 2025 All rights reserved | Legal notice |