Amarisoft

LTE D2C (Direct To Cell)

This tutorial is to show you how to configure and test Direct to Cell in LTE. Direct to Cell represents 'From Satellite directly to Cellular Phone'. The 'Cellular Phone' in this context is just an ordinary commercial mobile hone that you have and it does not need to support any special feature for satellite communication as long as it works with ordinary NR SA in terrestrial network.

Actually Direct To Cell is not the 3GPP based feature like NTN (NB NTN or NR NTN). So the UE is not expected to support any specific features to accommodate this type of connection. So all the functionality to handle such a long delay or doppler shift etc which are present for satellite communication should be implemented by gNB that is sitting on the Satellite. This gNB implementation is mostly up to gNB vendor since the functionality is not specified in 3GPP.

Table of Contents

Introduction

Direct to Cell in LTE represents a transformative approach in wireless communications by enabling standard commercial cellular phones to directly connect to satellites, bypassing the need for specialized satellite-compatible hardware within the user equipment (UE). Unlike traditional satellite communication systems, which often require purpose-built devices or custom firmware, Direct to Cell leverages the existing capabilities of LTE (Long Term Evolution) technology, allowing ordinary mobile devices that function in terrestrial NR SA (New Radio Standalone) environments to seamlessly access satellite-based networks. This innovation is distinct from 3GPP-defined Non-Terrestrial Network (NTN) solutions—such as NB-IoT NTN and NR NTN—because it does not rely on explicit protocol or feature support from the UE. Instead, the responsibility for managing the unique challenges of satellite communication, including long transmission delays and significant Doppler shifts, is handled entirely at the network side by the gNB (Next Generation NodeB) located on the satellite. The design and implementation of these satellite-based gNBs remain largely proprietary, as 3GPP specifications do not standardize the mechanisms for compensating satellite-specific impairments in this context. As a result, Direct to Cell serves as a practical and highly accessible means to extend cellular coverage globally, leveraging the pervasive LTE ecosystem without necessitating changes to end-user devices, and plays a pivotal role in bridging the digital divide in remote or underserved regions.

Summary of the Tutorial

This tutorial details the procedure for configuring and testing Direct to Cell (D2C) functionality with a simulated Low Earth Orbit (LEO) satellite using Amarisoft eNB and UEsim as the Device Under Test (DUT). The focus is on low-layer testing, with minimal IP layer configuration required.

Overall, the methodology emphasizes careful configuration of channel simulation and NTN parameters, verification of physical and logical cell setup, data path validation, and comprehensive monitoring of radio and network layer performance, with comparative analysis between D2C and non-D2C scenarios as well as different DUT types.

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.

In setup [A], the satellite and the space channel are real. The ground station runs Amarisoft Core or a customer core, and the DUT is a commercial UE without any modification.

In setup [B], both the satellite and the space channel are simulated. The ground station is an Amarisoft Callbox running the eNB, and the DUT is Amarisoft UEsim. The satellite link is produced by the channel simulator in the Callbox. That is why CHANNEL_SIM is enabled in the eNB configuration below.

Two D2C setups, real satellite with commercial UE and simulated satellite with UEsim

NOTE : The test configuration in this tutorial is based on the settings illustrated in [B]

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 : D2C with Simulated LEO and UEsim

This is to configure and test Direct to Cell for Simulated LEO using Amarisoft UEsim as DUT.

Configuration

The configuration shown here is common configuration for all the subtests belonging to Test 1

I have used enb-dtc.cfg for eNB. In this configuration, specicialy configured SIB message sib23_rb25_dtc.asn is used.

Callbox config directory with enb.cfg linked to enb-dtc.cfg and sib23_rb25_dtc.asn

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

MME config directory with mme.cfg linked to mme-ims.cfg and ue_db-ims.cfg

On UEsim, I used ue.default.cfg  as it is

UEsim config directory with ue.cfg linked to ue.default.cfg

enb-dtc.cfg  is configured as follows.

eNB configruation is very similar to the default enb configuration. The important thing is to enable Channel Sim(CHANNEL_SIM = 1). You can set the altitude of the satellite by setting SAT_ALTITUDE.

CHANNEL_SIM has to be 1 to simulate the radio link between the ground station and the satellite. SAT_ALTITUDE is the default altitude of the satellite in meters. It is 1000e3 (1000 km) in this file.

The other defines stay as in the default file. TDD is 0 (FDD), N_RB_DL is 25 (5 MHz), and N_ANTENNA_DL and N_ANTENNA_UL are both 1. NG_ENB is 0, so the cell is not an ng-eNB.

eNB defines with CHANNEL_SIM 1 and SAT_ALTITUDE 1000e3

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 constant delay is applied for simplicity.

This block is in #if CHANNEL_SIM == 1 under rf_ports. For simplicity, only a 1x1 delay channel is configured. channel_dl has one path with type "constant", gain 0 and channel_matrix [[ 1 ]]. noise_level is -40.

The delay of the path is written as 0, but the eNB overwrites it at run time with channel_sim_control in the ntn section. The delay therefore follows the satellite position. rx_ta_offset is set to 100 in this block.

eNB rf_ports channel_dl with a single constant path and rx_ta_offset 100

An LTE FDD band is configured for this tutorial. This is same as the default configuration for most of the sample config file.

Since TDD is 0, the #else branch is used. The active line is dl_earfcn 3350, which is 2680 MHz in Band 7. The other earfcn lines are commented out. The #if TDD == 1 branch and the #if NG_ENB == 1 branch are not used in this test.

The rest of the cell is plmn_list "00101", n_id_cell 1, cell_id 0x01 and tac 0x0001. root_sequence_index is 648. If you change dl_earfcn here, change dl_earfcn on the UE side to the same value.

eNB cell_list with dl_earfcn 3350 for band 7 and root_sequence_index 648

In this test, a specially configured SIB message is used (mainly for setting timer values to accommodate the long distance case). and  you may need to tweak prach_config_index to accommodate the long distance situation.

In sib_sched_list, the SIB2 comes from the file "sib23_rb25_dtc.asn" with si_periodicity 16 frames. This is the specially configured SIB2 for this test. Its timer values are checked in the Log Analysis section.

prach_config_index is 48 in both branches, the N_RB_DL == 6 branch and the #else branch. It is preamble format 3, once every 20 ms. I set it carefully to give the delay tolerance. prach_freq_offset stays at -1, which means automatic. The SIB1 part (q_rx_lev_min -70, p_max 10, si_window_length 40) is the same as in the default file.

eNB cell_default with sib23_rb25_dtc.asn in sib_sched_list and prach_config_index 48

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 eNB) 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. The parameter direct_to_cell indicates this is for Direct to Cell, not for NTN.

default_ephemeris is "leo". default_sma is 6378e3 + SAT_ALTITUDE. It is the distance of the satellite from the center of the earth, so it is about 7378 km with SAT_ALTITUDE 1000e3. default_elevation_offset is 20. It moves the initial elevation away from the zenith position, and a positive value places the satellite after the zenith. min_expected_elevation is 35.

ground_position puts the eNB at latitude 45, longitude 0 and altitude 0. feeder_doppler_compensation is true. channel_sim_control has type "auto_feeder_service_link". In that mode the eNB updates the channel delay with the feeder link plus the service link. That mode needs ue_position, which is latitude 44, longitude 0.5 and altitude 0 here. ue_doppler_shift is true, so the doppler shift of the service link is applied as well.

direct_to_cell is the only Direct to Cell specific part. Its cell_center is at latitude 43, longitude 1 and altitude 5000. Most of the other ntn parameters are the same ones used for NTN. large_freq_shift has prach_range_sc 48, prach_n_acc 1 and ta_tolerance 8. compute_freq_shift is set to true just below the ntn block.

eNB ntn section with default_ephemeris leo and the direct_to_cell cell_center

ue.default.cfg   is configured as shown below. (NOTE : You can skip this part if you are not using Amarisoft UEsim as DUT).

The key point here is that you don't need to configure any specific settings for satellite communication since Direct to Cell is designed to make Satellite communication possible with ordinary UE without any special modification. So in this tutorial, you will see all the configuration on UEsim remain same as in default configuration (ue.default.cfg)

In the UE defines, TDD is 0 (FDD) and CELL_BANDWIDTH is 5 MHz. These match the eNB. N_ANTENNA_DL is 1 and UE_COUNT is 1. CHANNEL_SIM is 0 on the UE side. The satellite channel is simulated only on the eNB side.

UEsim defines with TDD 0, CELL_BANDWIDTH 5 and CHANNEL_SIM 0

Only band and channel (dl_earfcn) is changed to match eNB frequency and band settings.

The default cell configuration is used without modification. With TDD at 0, the #else branch sets dl_earfcn 3350, which is 2680 MHz in Band 7. That is the same value as on the eNB. bandwidth is CELL_BANDWIDTH and n_antenna_ul is 1.

Since CHANNEL_SIM is 0, multi_ue is false and the #if CHANNEL_SIM == 1 blocks are not used. global_timing_advance stays at -1. With -1, the UE uses the timing advance from the first received RAR.

UEsim cell_groups with dl_earfcn 3350 for band 7 in the FDD branch

ue_list configuration is also set to be same as in default.

The default UE configuration is used without modification. The UE has imsi "001010123456789", as_release 13 and ue_category 13. ue_count is UE_COUNT, which is 1. The channel block in #if CHANNEL_SIM == 1 is not used in this test.

UEsim ue_list with default imsi, as_release 13 and ue_category 13

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, band 7(FDD) is used

'cell phy' shows one LTE cell on band 7 with a bandwidth of 5 MHz. The DL ARFCN is 3350 with 1 antenna, SCS 15 and QAM 256. The UL ARFCN is 21350 with QAM 64. 'cell' shows TAC 0x0001, pci 1, prach_seq 648 and PLMN 00101. These values match the cell_list in enb-dtc.cfg.

eNB cell phy and cell output for an LTE band 7 cell with 5 MHz

This is not the mandatory process.. but you may do 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.

eNB console with log bcch=1 followed by log bcch=0

Now start trace logging.

eNB console with the t command started

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)

Before the UE gets scheduled, the eNB prints several PRACH lines. The ta values are large at first (734, 1062, 985 and 1062). They then settle at ta=251 with snr 25.1 to 29.1 dB.

After the attach, UE_ID 6 with RNTI 0042 appears on cell 001. The DL cqi is 15 and the DL mcs is between 21.7 and 26.8. The DL brate is about 1.7k to 4.3k. The UL snr is about 15 dB and pl is 36.

eNB t trace with repeated PRACH lines and UE 6 scheduled at DL mcs 26

Try some data traffic (e.g, ping) to verify the data pipe setup. Check out the ttl time and see if it reflects the long propgation delay

I ran ping 192.168.2.2 from the Callbox to the UEsim. The delay is in the time value of each reply, while ttl stays at 64. The first reply takes 1258 ms and the second 260 ms. After that, the time stays between about 60 ms and 107 ms.

The time also drifts during the run, for example from 65.0 ms down to 59.9 ms and then up to 78.9 ms. The eNB keeps updating the delay as the simulated satellite moves.

ping from Callbox to UEsim 192.168.2.2 over D2C with time around 60 to 100 ms

NOTE : Just for comparison, I did the same test with a commercial UE (One PLUS)

Here I ran ping 192.168.3.2 to the OnePLUS phone. ttl is 255 for this UE. The first reply takes 1056 ms. After that, the time is between 42.1 ms and 109 ms, in the same range as with UEsim.

ping from Callbox to OnePLUS 192.168.3.2 over D2C with time around 50 to 110 ms

NOTE : Just for another comparison, I did the same test with UEsim without applying D2C. You would notice large differences in terms of ttl between with DTC and without DTC.

Without D2C, the first reply takes 1048 ms. The next ones are between 18.3 ms and 45.4 ms, and from icmp_seq=15 the time stays at 37.2 to 37.3 ms. With D2C the time was about 60 ms to 100 ms and changed over time.

ping from Callbox to UEsim 192.168.2.2 without D2C with time around 37 ms

Log Analysis

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

Sample Log

While the test is running, you can check out the position of eNB and UE in real time with WebGUI.  While running, select [ENB] tab and hit [NTN] button and you see the view as shown below.

[eNB] pannel shows the sky view of eNB (sky view from eNB) and [UE] pannel shows the sky view of UE (sky view from UE). When the following value goes negative, satellite link gets disconnected since the satellite is not obserbable from UE.

The [ENB] tab and the [NTN] button are in the top bar of the WebGUI. The map shows the eNB, the UE and the satellite with their coordinates. In this run, the satellite is at elevation 38.20 deg and azimuth 89.30 deg from the eNB, and the distance is 1484.1 km.

From the UE, the elevation is 39.28 deg and the azimuth is 83.16 deg. The UE distance is 1458.8 km with DtC +23.42. The DL doppler is -41.23 kHz (DtC -1.428) and the UL doppler is -39.38 kHz (DtC -1.364). One UE is connected at this point, and the cell PHY DL bitrate is 3.33 Kbps.

WebGUI ENB NTN view with satellite map and eNB and UE sky views

NOTE : When any of the position value (Azimuth or Elevation) turns into orange, it indicates the satellite is invisible from the UE and commication gets disconnected.

In this view, the satellite has moved to 42.664, 22.947. From the eNB, the elevation is 18.68 deg and the distance is 2209.0 km. From the UE, the elevation is 19.33 deg and the distance is 2173.8 km with DtC +37.08. Both elevation values are in orange. The UE list is empty and the cell bitrate is 0 bps.

WebGUI ENB NTN view with elevation shown in orange after the link is lost

You may check out overall signaling sequence and details, in Direct to Cell there is almost no differences in signaling side from what you see regular communication (i.e, terrestrial communication). But there would be some tweakings of SIB parameters related to RACH configuration and timers to handle the long propation delay between the UE and Satellite.

In SIB2, prach-ConfigIndex is 48 with rootSequenceIndex 648. This is the prach_config_index from enb-dtc.cfg. rach-ConfigCommon has numberOfRA-Preambles n4, preambleTransMax n20, ra-ResponseWindowSize sf10 and mac-ContentionResolutionTimer sf64.

SIB2 rach-ConfigCommon and prach-ConfigIndex 48 in the decoded SIB message

The timers are in ue-TimersAndConstants further down in the same SIB2. t300, t301 and t310 are all ms1000. n310 is n6, t311 is ms10000 and n311 is n5. timeAlignmentTimerCommon is sf1920. These are the timer values in sib23_rb25_dtc.asn set for the long distance case.

SIB2 ue-TimersAndConstants with t300, t301 and t310 at ms1000

Then it would be good idea to check out the details on RACH. You would see 4 consetive RACH procedure going on here. This is a special modification on eNB to handle the large propagation delay during the RACH process. It is a kind of modification on the PRACH to be able to send the RAR to a future PRACH request : In LTE you cannot have less than 4 CBRA preamble so for one PRACH I send 4 RAR messages for each preamble

In this run, the PRACH is sequence_index=3 with ta=225 and freq_shift=-3541.4. After the accumulation is done with ta_ref=225, the eNB prints "DTC: 4 UEs to instantiate". MAC then allocates four new UEs (UE ID 1 to 4). The RAR carries rapid=0, rapid=1, rapid=2 and rapid=3.

The later PRACH lines with sequence_index 1 and 0 are marked "DTC: ignored due to link latency". Only UE ID 1 sends a Msg3 with crc=OK, and it carries the RRC connection request. The PUSCH of UE ID 2, 3 and 4 fails with crc=FAIL, and those UEs are freed. UE ID 1 then gets the contention resolution (UECRI) and the RRC connection setup.

eNB PHY and MAC log with one PRACH instantiating four UEs and four RAPIDs in one RAR

Now confirm that entire attach process gets completed

The sequence is the same as on a terrestrial cell. RRC connection request and setup are followed by authentication, NAS and RRC security mode, and UE capability enquiry. Attach accept comes in the RRC connection reconfiguration, and the UE sends Attach complete.

Later in this log, the RRC connection is released and the UE is paged. It comes back as UE ID 12 with a new RRC connection and a Service request. This is the UE ID used in the plots below.

RRC and NAS log of the attach from RRC connection request to Attach complete

Check out throughput and see if you are getting expected throughput. In this test, I did continous ping to check if end to end data pipe is working OK.

Click Analytics and select the Throughput tab. The traffic is ping only, and the rates stay below about 17 Kbps. The PHY UL and PHY DL rates run from about 23:25:15 to 23:26:00.

WebGUI Analytics Throughput tab with the PHY and IP rates of the ping traffic

Then check SNR to check the radio link quality over the course of the test. (NOTE : Connection between eNB and UEsim is via RF cable (i.e, conductive connection))

In the SNR tab for UE ID 12, the PUCCH snr stays at about 40 dB. The PUSCH snr moves between about 20 dB and 34 dB, and the SRS snr is around 17 dB. UL data and UL control EPRE stay at about -90 dBm.

Around 23:26:00, all SNR values drop below 0 dB. The EPRE values fall to between -133 dBm and -152 dBm at the same time.

WebGUI SNR plot for UE 12 over D2C with UEsim

NOTE : For comparative purpose, I captured the same plot with a commercial UE (OnePLUS) as shown below ((NOTE : Connection between eNB and UE is via Antenna (i.e, radiative connection))

With the OnePLUS phone (UE ID 28), the PUSCH snr is about 20 dB to 26 dB and the SRS snr is about 13 dB. The PUCCH snr jumps between 0 dB and 39 dB. The EPRE values move between about -91 dBm and -112 dBm.

WebGUI SNR plot for the OnePLUS UE over D2C

NOTE : As a reference, I captured the same plot with a UEsim without application of D2C as shown below

Without D2C (UE ID 2), the PUCCH snr stays at about 45 dB, the PUSCH snr at about 38 dB and the SRS snr at about 32 dB. The EPRE values are flat, just above -91 dBm. There is one short dip in the middle, and the values drop only at the very end of the plot.

WebGUI SNR plot for UEsim without D2C

You can check out the signal quality percieved by UE from DL CQI plot

The DL CQI is in the CQI tab of Analytics. It stays at 15 from 23:24:48 until about 23:26:00. After that, it drops and moves between about 4 and 8.

WebGUI DL CQI plot staying at 15 then dropping near the end

If you magnify TA command value in [Time/Freq] tab, you would see a pattern as shown below. ((NOTE : Connection between eNB and UEsim is via RF cable (i.e, conductive connection))

For UE ID 12, the TA command value moves between about 0 and 3 during most of the run. Around 23:26:00, it drops to about -6.5 and then stays between 0 and -5.

WebGUI Time/Freq TA plot for UE 12 over D2C with UEsim

NOTE : For comparative purpose, I captured the same plot with a commercial UE (OnePLUS) as shown below ((NOTE : Connection between eNB and UE is via Antenna (i.e, radiative connection))

With the OnePLUS phone (UE ID 28), the TA command value is always 0 or positive. It moves between 0 and about 2.4 with frequent peaks.

WebGUI Time/Freq TA plot for the OnePLUS UE over D2C

NOTE : As a reference, I captured the same plot with a UEsim without application of D2C as shown below

Without D2C (UE ID 2), the TA command value stays flat at 0 for the whole run. It drops to about -3.5 only at the very end of the plot.

WebGUI Time/Freq TA plot for UEsim without D2C