NR SA NTN (Non Terrestrial Network)


This tutorial is to show you how to configure and test LTE NB 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 LTE 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



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.


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.



Test 1 : NTN with Simulated GEO and UEsim

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



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, 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.

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.

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.

NR SA NTN Test 1 Config 06 r20230512

Then enable sib19 which is to broadcast NTN related information.

NR SA NTN Test 1 Config 07 r20230512

Now as MAC configuration, configure retx_bsr_timer, sr_prohibit_timer, prohibit_phr_timer, sr_trans_max differently based on the type of orbit. The basic idea is to configure these parameters differently based on RTT between the satellite and ground station.

NR SA NTN Test 1 Config 08 r20230512

Then adjust RRC timers t300, t301, t319 appropriately for each orbit type. And then adjust t_PollRetransmit based on the type of the orbit.

NR SA NTN Test 1 Config 09 r20230512

Now for the configurations specific for ntn. The configuration parameter name itself is ntn. In this parameter, you can specify the location of the satellite (i.e, the ephemeris), the location of ground station (i.e, the location of gNB) and ue location. The location of the ground station is specified by the parameter ground_position, the location of UE is specified by the parameter ue_position and the position of the satellite is specified by the parameter default_ephemeris.

NR SA NTN Test 1 Config 10 r20230512


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.

NR SA NTN Test 1 Config 11 r20230512

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)

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


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.

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.

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.

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)

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.

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 to freely 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



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













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. ( )