NR SA NTN (Non Terrestrial Network)

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.

• SIM Card used in this tutorial is the one delivered with the system as it is.
• If you want to change the configuration, The tutorial Configuration Guide would help

With Amarisoft eNB and UEsim, we can try with following two different setups.

Key Configuration Parameters

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

• ntn : In this link, you can find the descriptions for all the parameters below.
• ephemeris
• eccentricity
• inclination
• semi_major_axis
• longitude
• periapsis
• anomaly
• epoch
• use_state_vectors
• ground_position
• same_as_ap_position
• latitude
• longitude
• altitude
• n_ta_common
• n_ta_drift
• n_ta_drift_var
• channel_sim_control
• type
• ue_position
• latitude
• longitude
• altitude
• ue_doppler_shift
• ul_sync_validity
• k_offset
• dynamic_k_offset
• rat_type

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)

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

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

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.

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.

SSB periodicity is adjusted based on orbit type. In this test (with GEO), ssb_period is set to 20.

Then enable sib19 which is to broadcast NTN related information.

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.

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

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.

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.

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)

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.

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.

Now start trace logging.

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

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)

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.

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.

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.

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)

After the connection is established, gNB would re adjust timing advance periodically to maintain the connection by sending Timing Advance MAC CE.

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.

• Clock synchronization issues, see above
• Difference in satellite propagation model between eNB/UE and 3rd party channel simulator. To have better result, it is important to use a recent TLE file (less than a day), especially if the orbit altitude is low.
• There can be a lot of frequency translation units if the satellite links are over Ka/Ku band and each of these can add a frequency error. When using high frequency links, a small ppm error gives a rather larger frequency error in Hz

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

            }

          }

        }

      }

    }

  }

}

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 )