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.
-
Context of Direct to Cell in LTE
- Direct to Cell enables ordinary commercial mobile phones to connect directly to satellites using standard LTE protocols.
- The technology extends LTE connectivity beyond terrestrial boundaries, reducing the necessity for specialized satellite-capable handsets.
- Unlike 3GPP-defined NTN solutions, Direct to Cell is not based on standardized features or message structures for satellite support within the UE.
-
Relevance and Importance of the Tutorial
- This tutorial provides step-by-step guidance on configuring and validating Direct to Cell connectivity in LTE networks.
- Understanding how to implement and test this technology is essential for network engineers, system integrators, and researchers interested in expanding coverage to remote or underserved areas using existing mobile devices.
- The tutorial highlights architectural considerations and best practices for adapting LTE infrastructure to operate efficiently in satellite environments.
-
Learning Outcomes
- Gain a comprehensive understanding of the Direct to Cell concept and its distinction from standardized NTN architectures.
- Learn how gNBs on satellites compensate for satellite-specific challenges such as increased latency and Doppler effects.
- Acquire practical skills for configuring, deploying, and testing LTE Direct to Cell connections.
- Develop insight into the broader significance of Direct to Cell in expanding mobile connectivity and its implications for the future of wireless communication.
-
Prerequisite Knowledge and Skills
- Familiarity with LTE network architecture, including the roles of UE, eNB/gNB, and the core network.
- Basic understanding of radio access technologies and satellite communication fundamentals.
- Experience with LTE configuration, network testing, and troubleshooting tools is beneficial for hands-on sections.
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.
-
Test Setup:
- The SIM card supplied with the system is used as-is.
- Two different setups are possible with Amarisoft eNB and UEsim, but the configuration is based on the [B] setup as illustrated.
-
Key Configuration Parameters:
- Critical parameters include satellite, ground station, and UE locations (using default_ephemeris, ground_position, and ue_position), channel simulation settings, timing advance, Doppler compensation, frequency settings, and band/channel configuration. All these are set primarily under the ntn parameter group.
- No special satellite configuration is needed for the UE, since Direct to Cell is designed for operation with standard UE.
-
Test 1: D2C with Simulated LEO and UEsim
-
Configuration Steps:
- eNB: Use
enb-dtc.cfgwith Channel Simulation enabled (CHANNEL_SIM = 1). SAT_ALTITUDE is set to define satellite altitude. - Only constant delay is applied in the channel profile for simplicity.
- LTE FDD band (e.g., Band 7) is used; ensure band and channel (dl_earfcn) match between eNB and UE.
- SIB message is specially configured to accommodate longer propagation delays (e.g., timer values, RACH configuration).
- NTN-specific settings: Satellite, ground station, and UE locations are configured under the ntn section using appropriate parameters.
-
UEsim: Use the default configuration file (
ue.default.cfg). No special configuration is required for satellite operation, except to match band and channel to the eNB. - UE list configuration remains as default.
- eNB: Use
-
Test Execution Steps:
- Start the LTE service on the callbox and verify cell configuration using the 'cell phy' and 'cell' commands.
- Optionally, enable and then disable BCCH logging to capture SIB messages at the start.
- Begin trace logging.
- Power on the UE on UEsim (or commercial phone if used as DUT).
- Wait for the DUT to complete the initial attach process.
- Generate data traffic (e.g., ping) to verify data connectivity. Check for expected TTL values reflecting long propagation delay.
- Comparative tests can be performed using a commercial UE and/or with D2C disabled to observe differences, especially in TTL values.
-
Log Analysis and Monitoring:
- Use WebGUI to monitor the real-time positions of eNB and UE, and check satellite visibility (elevation and distance values).
- If position values (Azimuth or Elevation) turn orange, this indicates loss of satellite visibility and connection drop.
- No significant differences in signaling between D2C and standard terrestrial communications, except for adjustments in RACH configuration and timers for long delay.
- Special RACH procedure: Multiple consecutive RACH attempts (4 in this example) are used to handle large propagation delay. The eNB is modified to send multiple RAR messages per PRACH occasion.
- Verify that the attach process completes successfully.
- Check throughput by running continuous ping and monitoring data flow.
- Monitor SNR plots and compare signal quality over the test period (noting connection type: conductive with UEsim, radiative with commercial UE).
- Review DL CQI plots for signal quality as perceived by the UE.
- Inspect Timing Advance (TA) command values to assess propagation delay handling. Comparative analysis can be performed with and without D2C enabled.
-
Configuration Steps:
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.
- 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.
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.

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
- use_state_vectors
- eci_reference
- ground_position
- n_ta_common
- n_ta_drift
- n_ta_drift_var
- n_ta_common_offset
- feeder_doppler_compensation
- feeder_dl_freq
- feeder_ul_freq
- large_freq_shift
- direct_to_cell
- channel_sim_control
- type
- ue_position
- ue_doppler_shift
- ue_dl_freq
- ue_ul_freq
- feeder_doppler_shift
- ue_dl_attenuation
- ue_dl_gain_offset
- ul_sync_validity
- k_offset
- k_mac
- dynamic_k_offset
- reference_location
- t_service
- neighbour_cells
- rat_type
- t318
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.

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

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

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.

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.

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.

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.

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.

ue.default.cfg is configured as shown below. (
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.

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.

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.

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.

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.
![]()
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. (
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.

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.

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.

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.

Log Analysis
Following is the log snapshot that are involved in communication with NTN.
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.
- Elevation
- DtC value in Distance on UE pannel
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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.
