5G | ShareTechnote

5G/NR - NTN

NTN (Non Terestrial Network)

The basic idea of NTN is obvious. It is to deliver 5G/NR service via space (satellite) or air (airborne platform) as illlustrated below.

Why NTN ?
Challenges
Delay Requirements
Performance Requirements
How 3GPP is updated to get around the problems and meet the requirements listed above ?
Examples

Example 01 : NB IoT

RRC Parameters (NR)
RRC Parameters (LTE)
RRC Parameters (LTE NB)
Get the Test Procedure and Log / Amarisoft TechAcademy

Why NTN ?

The motivation is obvious as well. If it is realized as expected, it would be able to deliver the 5G service to those places where it is technically very difficult or cost too much to deliver with terrestrial network. Some examples of those places would be a remote area like deep forest that would be too costly with terestrial delivery, or far islands or ship that would be technically almost forbidden in terrestrial connection.

NOTE : The illustration shown above is consolidated representation of various deployment options described in various TRs in the reference section. If you want to get a little bit detailed diagram for each of the deployment plan separately, you may refer to 3GPP TR 38.821 V16.1.0

I found another well summarized illustration from this paper as shown below. It shows various different use cases and potential ground-to-airborne connection mechansm.

There would be no single clear-cut advantage (motivation) of adopting NTN over the existing (conventional) method. Just for brain storming purpose I will just list up all the possible idea that I can collect. Definately there would be more.. and something you don't agree

Wider Ecosystem - Satellites can provide additional capacity and coverage to supplement terrestrial networks, especially in rural or remote areas. New protocols can optimize satellite connectivity within the cellular ecosystem.
Resiliency - Satellite networks are less vulnerable to terrestrial disasters or network outages. Cellular protocols like NTN can integrate satellites seamlessly to improve redundancy.
Seamless Roaming/Handover - Newer LEO satellite constellations promise much lower latency than traditional GEO satellites, approaching terrestrial networks. Optimized cellular protocols can enable seamless roaming and handovers between terrestrial and satellite networks.
Better fit for UE Mobility - Cellular protocols are ideal for connecting users on the move, whether on land, sea, or air. NTN allows mobile users to access satellite networks as just another node in the cellular ecosystem.
Cost - Cellular architecture and protocols can leverage economies of scale from the mobile industry to reduce costs compared to proprietary satellite network approaches.
Standardization and Compatibility - Cellular protocols like NTN can allow satellite networks to leverage existing 3GPP cellular standards and interoperate with terrestrial networks. This avoids fragmentation. By adopting cellular protocols, satellite communications can leverage the extensive work done in standardizing these protocols for global compatibility and interoperability. This means devices designed for terrestrial use can also communicate via satellites without needing significant modifications.

Challenges

I personally am so eager to see this realized because one of those areas shown above is my dream place -:), but there would be many challenges to be overcome. Followings are a short list of those challenges. (NOTE : To foresee on those challenges, I think it would be helpful to investigate on the challenges that the satellite communication systems being depolyed and tested now (as of Feb 2021) and SpaceX Starlink can be a good example since there are so much informations are available. Even though it is not easy to find the details on challenges on the fancy looking system, it would be more helpful as an engineer to look for the challenges and see how those challenges gets resolved).

Latency : One obvious challenge that everybody can easily guess would be the long latency caused by pure physics. There is long distance between ground station/user terminal and the satellite. The speed of light is finite. So it would take a considerable amount of time (delay) for the radio wave to reach the user device. Of course, this latency would very depending on the altitude of the satellite. If the satellite is deployed on GEO(Geostationary Orbit), the delay would be huge. If they are deployed in LEO(Low Earth Orbit), the delay would be low (in some case it can be even shorter than what you experience with WiFi delivered by ground connection), but it would require huge cost to cover the wide area with LEO like StarLink.

Demand on Ground Stations/Integration with terrestrial core : Even though we can put the radio part (e.g, gNB, Relay etc) up in the space, the core network is (should be) on the ground. It mean that the satellite or airborne platform should be connected to ground station at some point. The question is how far it can get connected to the ground station. Obviously there would be a certain limit in distances in which a satellite can reach a ground station. As a result, we would need a lot of ground station as well as satellite if we want to cover wide area. In some cases, it will be very challenging to set a ground station. For example, if we need a satellite covering far in the oscien, how can we setup a ground station that can cover those satellites ? One possible solution for this situation is to make some satellites to get access to the core network indirectly via another sattelite instead of ground station. In order to do this, we would need to make relay networks or mesh networks among the satellites. Of course, theoretically this is possible and most of satellite communication systems put this into account from the design phase. But it would not be easy for implementation in reality (NOTE : This is one of the challenges that Starlink faces at early phase and as of Feb 2021 the communication between satellites is not supported)

Antenna Technology : Intuitively and by experience, we would easily guess that Antenna technology would ge a critical component for this kind of communication system. First how small we can make it ? We may tolerate the necessity of using a large sized dish antenna (i mean large size in comparison to mobile phone antenna), but everybody would like to have a smaller dishes in various reasons. Next, how to change the direction of antenna radiation pattern pointing in line of sight to a satellite ? Two options are considered for this. The first option is to put some mechanical component so that it can change the direction of the dish mechanically (like the dishes used in Starlink system). But it would be difficult to change the direction of the antenna fast enough to handle mobility situation. The second option would be to use phase array antenna by which we can change the direction of radiation pattern electronically. Technically this would be much better than the mechanical method, but cost would be a big issue.

User Terminal Alignment: For end-users, especially non-technical ones, aligning terminals to ensure optimal connectivity can be a significant challenge.

Large Doppler Shift : Usually sattelites and airborne platform in this communication system moves very fast whereas most of user terminal is stationary or moves slowly. It implies there would be huge differences in terms of relative speed between satellites and user terminals. In turn, it mean there would be large doppler shift experienced by the reciever.

Large Delay Spread : In this kind of communication system, the physical distance between the transmitter and the reciever tend to be very far (e.g, ranging from several hundreds of kilometers(LEO) to 36,000 kilometers (GEO)). This would lead to large delay spread.

Competition to other technolgies : Simply put, in terms of business point of view, would it be lucrative enough to invest huge money to compete against existing satellite communication system like Starlink or Kuiper ? (NOTE : There is a company called ASTspaceMobile that claim to provide SpaceMobile service with just a few hundreds LEO satellites for regular mobile phone. But almost no technical details are known as of now (Mar 2021)).

Handover complexity - Handovers between satellite beams/cells and between satellites and terrestrial networks could be complex and require tight coordination. Fast moving LEO satellites complicate this further. Handling handover may be easier (so advantage) in NTN comparing to conventional satellite protocol, but it still be more difficult comparing to terrestrial cellular technology.

Network Management and Traffic Optimization: Managing the traffic over a satellite network is more complex due to variable conditions and the mobility of the satellites themselves.

Power limitations - Satellites and aerial platforms have restrictions on power, antenna sizes, etc which can limit data rates and capacity. Efficient waveforms and modulation are needed.

Scalability: As the number of connected devices continues to grow, NTN systems must be scalable without incurring prohibitive costs or overly complex network management.

On-board Processing Capabilities: Satellites need to have sufficient processing power to handle complex operations, which can be a constraint given the limitations on size, weight, and power.

Launch costs - Getting satellites into orbit is still expensive. Larger constellations could require dozens or even tens of thousand of launches.

Orbit management - Avoiding collisions and managing constellation orbits takes planning, especially with large numbers of satellites. Debris is also concern when the collision happens or when the sattelites got out of life.

User terminal cost - For widespread consumer adoption, low-cost yet high-performance user terminals are needed. Striking the right balance on capabilities could be difficult.

Regulatory hurdles - Getting regulatory approval to launch large constellations and operate seamlessly across many countries can be challenging and time consuming.

Business case - The large upfront capital costs make the business case difficult, especially when competing with expanding terrestrial 5G networks. Return on investment is a question.

Delay Requirements

The total Delay Requirement specified in TS 22.261 is roughly the following value + 5 ms (delay caused by 5G protocol)

< 22.261 (Rel 18) - Table 7.4.1-1: UE to satellite propagation delay >

NOTE : Even the smallest propagation is greater than the max delay that can be covered by TA field of RAR.(Around 2 ms is covered by RAR TA in SCS 15Khz, 1 ms in SCS 30Khz).

Performance Requirements

High lights of Performance Requirements can be summarized as :

GEO satellite access with up to 285 ms end-to-end latency, including a 5 ms assumed network latency.
MEO satellite access with up to 95 ms end-to-end latency, plus a 5 ms network latency.
LEO satellite access with up to 35 ms end-to-end latency, with an additional 5 ms network latency.
Allow for quality of service negotiation to optimize user experience, considering the latency.
Provide high uplink and downlink data rates for satellite UEs.
Ensure communication service availability of at least 99.99%.

More detailed requirement would vary depending on various scenario and UE type which is summarized in following table.

< 22.261 (Rel 18) - Table 7.4.2-1: Performance requirements for satellite access >

The table can be summarized as follows :

Pedestrian: 1 Mbit/s DL, 100 kbit/s UL, with area traffic capacities of 1.5 Mbit/s/km² DL and 150 kbit/s/km² UL, at 100 users/km², and an activity factor of 1.5%.
Public Safety: 3.5 Mbit/s for both DL and UL, other capacities TBD, users moving at 100 km/h.
Vehicular Connectivity: 50 Mbit/s DL, 25 Mbit/s UL, details TBD, with 50% activity factor, speeds up to 250 km/h.
Airplanes Connectivity: 360 Mbit/s per plane DL, 180 Mbit/s UL, with users traveling up to 1000 km/h.
Stationary: 50 Mbit/s DL, 25 Mbit/s UL, activity factor not applicable, stationary users.
Video Surveillance: 0.5 Mbit/s DL, 3 Mbit/s UL, users stationary or moving up to 120 km/h.
Narrowband IoT Connectivity: 2 kbit/s DL, 10 kbit/s UL, with area traffic capacities of 8 kbit/s/km² DL and 40 kbit/s/km² UL, at 400 users/km², activity factor of 1%, at speeds up to 100 km/h.

How 3GPP is updated to get around the problems and meet the requirements listed above ?

To cope with the issues and to meet the requirement mentioned above, some new features are introduced in 3GPP release 17. In summary, those new features can be summarized as below.

Handling Timing Offset for Long Delay : Additional Timing Address Information elements (ta-Info-r17) are added in SIB 19.
Handling the long delay for HARQ due to long distance between UE and gNB : a New Information Elements (DL-DataToUL-ACK-v1700 ) is added to specify long enough K1 value.

NOTE : To cover all the possible distance between UE and Satellite, the number of HARQ should be very large, but in current extenstion, the max HARQ number is increased only up to 32. Waiting to see the feedback from industry

NOTE : Theoretically increasing K1 is not the only possible solution. We can remove HARQ completely and relay on higher layer for error checking and retransmission. I guess some would be trying this. But removing HARQ completely would be too much impact on protocol since it would impact on signaling message transmission and reception.

Indicating the Position and Motion of the Satellite : For this purpose, a new Information Elements (ephemerisInfo-r17 ) is added and broadcast in SIB 19.

Examples

Example 01 : NB IoT

: This is a sample log from Amarisoft Callbox with NTN for LTE NB IoT. This example is done with a simulated environement for the following setup.

NOTE : If you want to see the contents of full log with Amarisoft Log viewer, go to LogAnalysis section and click on 'Sample Log' in this tutorial of Amarisoft TechAcademy.

Step	Direction	Message / Procedure
1	UE <-- NW	MIB
2	UE <-- NW	SIB1
3	UE <-- NW	SIB2
4	UE <-- NW	SIB31
5	UE --> NW	PRACH
6	UE <-- NW	RAR
7	UE --> NW	RRC Connection Request
8	UE <-- NW	RRC Connection Setup
9	UE --> NW	TA_REPORT (MAC CE)
10	UE --> NW	RRC Connection Setup Complete
11	UE <--> NW	< Authentication and Security >
12	UE <-- NW	K_OFFSET (MAC CE)
13	UE <-- NW	UE Capability Enquiry
14	UE --> NW	UE Capability Information
15	UE <-- NW	Rrc Connection Reconfiguration
16	UE --> NW	TA_REPORT (MAC CE)
17	UE --> NW	Rrc Connection Reonfiguration Complete
18	UE <--> NW	< Attach Complete >

[2] SIB 1

The message summarizes configuration details for an NB-IoT system's SIB1, focusing on parameters relevant to a non-terrestrial network (NTN)

Network Identity: Specifies the MCC (001) and MNC (01), indicating the operator's country and network.
Cell Status: The cell is marked as barred, meaning it's not available for use by ordinary NB-IoT devices (i.e, non-NTN device).
Selection Criteria: Minimum signal levels for cell selection are outlined (-70 dBm for Rx level and -34 dB for quality).
Frequency and Scheduling:

The frequency band indicator is set to 7. (NOTE : Technically you can use any band for this application based on your requirement. But now 3GPP specifies a few specific bands for NB IoT as shown here )
System information is scheduled with different periodicities (rf128 and rf64) and repetition patterns.

NTN Configuration:

There is a provision for sibType31-NB related to NTN in the non-critical extension, indicating support for NTN.
The NTN cell is not barred, suggesting it is available for use

{

message c1: systemInformationBlockType1-r13: {

hyperSFN-MSB-r13 '01'H,

cellAccessRelatedInfo-r13 {

plmn-IdentityList-r13 {

{

plmn-Identity-r13 {

mcc {

mnc {

}

cellReservedForOperatorUse-r13 notReserved

}

trackingAreaCode-r13 '0002'H,

cellIdentity-r13 '1A2D102'H,

cellBarred-r13 barred,

intraFreqReselection-r13 allowed

cellSelectionInfo-r13 {

q-RxLevMin-r13 -70,

q-QualMin-r13 -34

p-Max-r13 10,

freqBandIndicator-r13 7,

schedulingInfoList-r13 {

{

si-Periodicity-r13 rf128,

si-RepetitionPattern-r13 every2ndRF,

sib-MappingInfo-r13 {

si-TB-r13 b208

{

si-Periodicity-r13 rf64,

si-RepetitionPattern-r13 every4thRF,

sib-MappingInfo-r13 {

si-TB-r13 b256

}

si-WindowLength-r13 ms160,

systemInfoValueTagList-r13 {

nonCriticalExtension {

schedulingInfoList-v1530 {

{

sib-MappingInfo-v1530 {

sibType31-NB-r17

}

nonCriticalExtension {

cellAccessRelatedInfo-NTN-r17 {

cellBarred-NTN-r17 notBarred

}

[3] SIB 2

This message configures the radio resource configuration for NB-IoT, with a focus on common settings and NTN adjustments:

RACH Configuration: Details on Random Access Channel (RACH) settings for coverage enhancement (CE) devices.
BCCH and PCCH: Broadcast Control Channel and Paging Control Channel configurations.
NPRACH Settings: Parameters for Narrowband Physical Random Access Channel, such as periodicity and power levels.
NPDSCH & NPUSCH: Configuration for downlink and uplink shared channels in NB-IoT.
Uplink Power Control: Power settings for uplink transmissions.
NTN Common Configuration: Settings specific to NTN, including timing advance reporting and t318.

ta-Report-r17 : enable/disable UE specific TA report,
t318-r17 : Radio Link Failure (RLF) related timer

UE Timers and Constants: Various timers and constants that control UE behavior.
Frequency Information: Additional spectrum emission parameters.
Time Alignment Timer: Set to infinity, which affects the timing alignment for the UE.

{

message c1: systemInformation-r13: {

criticalExtensions systemInformation-r13: {

sib-TypeAndInfo-r13 {

sib2-r13: {

radioResourceConfigCommon-r13 {

rach-ConfigCommon-r13 {

preambleTransMax-CE-r13 n10,

powerRampingParameters-r13 {

powerRampingStep dB2,

preambleInitialReceivedTargetPower dBm-104

rach-InfoList-r13 {

{

ra-ResponseWindowSize-r13 pp5,

mac-ContentionResolutionTimer-r13 pp32

}

bcch-Config-r13 {

modificationPeriodCoeff-r13 n64

pcch-Config-r13 {

defaultPagingCycle-r13 rf128,

nB-r13 oneT,

npdcch-NumRepetitionPaging-r13 r1

nprach-Config-r13 {

nprach-CP-Length-r13 us66dot7,

nprach-ParametersList-r13 {

{

nprach-Periodicity-r13 ms80,

nprach-StartTime-r13 ms32,

nprach-SubcarrierOffset-r13 n0,

nprach-NumSubcarriers-r13 n12,

nprach-SubcarrierMSG3-RangeStart-r13 twoThird,

maxNumPreambleAttemptCE-r13 n10,

numRepetitionsPerPreambleAttempt-r13 n1,

npdcch-NumRepetitions-RA-r13 r8,

npdcch-StartSF-CSS-RA-r13 v4,

npdcch-Offset-RA-r13 zero

}

npdsch-ConfigCommon-r13 {

nrs-Power-r13 -15

npusch-ConfigCommon-r13 {

ack-NACK-NumRepetitions-Msg4-r13 {

dmrs-Config-r13 {

threeTone-CyclicShift-r13 0,

sixTone-CyclicShift-r13 0

ul-ReferenceSignalsNPUSCH-r13 {

groupHoppingEnabled-r13 FALSE,

groupAssignmentNPUSCH-r13 0

}

uplinkPowerControlCommon-r13 {

p0-NominalNPUSCH-r13 -80,

alpha-r13 al1,

deltaPreambleMsg3-r13 0

ntn-ConfigCommon-r17 {

ta-Report-r17 enabled,

t318-r17 ms2000

}

ue-TimersAndConstants-r13 {

t300-r13 ms2500,

t301-r13 ms2500,

t310-r13 ms200,

n310-r13 n6,

t311-r13 ms10000,

n311-r13 n5

freqInfo-r13 {

additionalSpectrumEmission-r13 1

timeAlignmentTimerCommon-r13 infinity

}

[4] SIB 31

The message configures parameters for satellite communication in a non-terrestrial network (NTN):

Ephemeris Information: Specifies orbital parameters like the semi-major axis, eccentricity, periapsis, longitude, inclination, and anomaly of the satellite. Check out here for further details
NTA Common Parameters: Includes a network timing area (NTA) common parameter value. Check out here for further details
UL Sync Validity: Defines the uplink synchronization validity duration. Check out here for further details
K-Offset: Provides an offset value, possibly related to timing or frequency corrections. Check out here for further details

{

message c1: systemInformation-r13: {

criticalExtensions systemInformation-r13: {

sib-TypeAndInfo-r13 {

sib31-v1700: {

servingSatelliteInfo-r17 {

ephemerisInfo-r17 orbitalParameters: {

semiMajorAxis-r17 8394210402,

eccentricity-r17 0,

periapsis-r17 0,

longitude-r17 242097885,

inclination-r17 0,

anomaly-r17 193139

nta-CommonParameters-17 {

nta-Common-r17 7776350

ul-SyncValidityDuration-r17 s240,

k-Offset-r17 1023

}

[5] PRACH

Message: n_init=8 ta=25 snr=41.3 cfg_id=0 n_rep=1 n_sf=6 n_sc_start=0

[6] RAR

Message: RAR: rapid=8

Data:

rapid=8

ta=25

ul_grant:

sc_spacing=1

i_sc=0

i_delay=0

i_rep=0

mcs=2

reserved=0x0

tc-rnti=0x0101

[7] Rrc Connection Request

The message is an RRC (Radio Resource Control) Connection Request for NB-IoT

UE Identity: A unique random value assigned to the UE for this transaction.
Establishment Cause: Indicates the reason for the request is mobile originating signalling.
MultiTone Support: Shows that the UE supports multi-tone operation for NPUSCH (Narrowband Physical Uplink Shared Channel).
Early Contention Resolution: A feature enabled to resolve contention earlier in the process.
CQI for NPDCCH: The IE CQI-NPDCCH-NB represents the downlink channel quality measurement of the NB-IoT carrier where the random access response is received. The codepoints for the CQI-NPDCCH measurements are according to the mapping table in TS 36.133. The value noMeasurements indicates no measurement reporting.

{

message c1: rrcConnectionRequest-r13: {

criticalExtensions rrcConnectionRequest-r13: {

ue-Identity-r13 randomValue: '2D1318AD6C'H,

establishmentCause-r13 mo-Signalling,

multiToneSupport-r13 true,

earlyContentionResolution-r14 TRUE,

cqi-NPDCCH-r14 noMeasurements,

spare '00000000000000000'B

}

[8] Rrc Connection Setup

The message is an RRC Connection Setup for NB-IoT

SRB Configuration: Setup for Signaling Radio Bearers with AM RLC configuration, including retransmission and threshold parameters.
MAC Configuration: Includes UL-SCH configuration for Buffer Status Reporting and a dedicated Time Alignment Timer set to infinity. It would be important to adjust these timer value according to the distance and channels between UE and satellite.
Physical Configuration: Specifies NPDCCH (Narrowband Physical Downlink Control Channel) configurations such as the number of repetitions, start subframe, and offset.

{

message c1: rrcConnectionSetup-r13: {

rrc-TransactionIdentifier 0,

criticalExtensions c1: rrcConnectionSetup-r13: {

radioResourceConfigDedicated-r13 {

srb-ToAddModList-r13 {

{

rlc-Config-r13 explicitValue: am: {

ul-AM-RLC-r13 {

t-PollRetransmit-r13 ms6000,

maxRetxThreshold-r13 t32

dl-AM-RLC-r13 {

}

logicalChannelConfig-r13 explicitValue: {

priority-r13 1

}

mac-MainConfig-r13 explicitValue-r13: {

ul-SCH-Config-r13 {

periodicBSR-Timer-r13 pp16,

retxBSR-Timer-r13 pp64

timeAlignmentTimerDedicated-r13 infinity

physicalConfigDedicated-r13 {

npdcch-ConfigDedicated-r13 {

npdcch-NumRepetitions-r13 r8,

npdcch-StartSF-USS-r13 v4,

npdcch-Offset-USS-r13 zero

}

[12] K_OFFSET (MAC CE)

Message: K_OFFSET=63 LCID:3 len=2 LCID:3 len=41 PAD: len=3

[13] UE Capability Enquiry

{

message c1: ueCapabilityEnquiry-r13: {

rrc-TransactionIdentifier 0,

criticalExtensions c1: ueCapabilityEnquiry-r13: {

}

[14] UE Capability Information

The message is an RRC UE Capability Information message for NB-IoT:

Access Stratum Release: Indicates support for Release 17.
UE Category: The UE is categorized as NB1, with mention of a later category NB2.
Multiple DRBs: Indicates support for multiple Data Radio Bearers.
PDCP Parameters: Specifies supported ROHC profiles and a maximum number of ROHC context sessions.
PHY Layer Parameters: Shows support for multi-tone operation.
RF Parameters: Lists supported bands and mentions power class support.
Radio Paging Info: Reiterates the UE category as NB1.
Extensions: Include further capabilities like UM RLC, NPRACH Format 2, and NTN parameters indicating support for non-terrestrial network connectivity and timing advance reporting.

ntn-Connectivity-EPC-r17
ntn-TA-Report-r17

{

message c1: ueCapabilityInformation-r13: {

rrc-TransactionIdentifier 0,

criticalExtensions ueCapabilityInformation-r13: {

ue-Capability-r13 {

accessStratumRelease-r13 rel17,

ue-Category-NB-r13 nb1,

multipleDRB-r13 supported,

pdcp-Parameters-r13 {

supportedROHC-Profiles-r13 {

profile0x0002 TRUE,

profile0x0003 FALSE,

profile0x0004 TRUE,

profile0x0006 FALSE,

profile0x0102 FALSE,

profile0x0103 FALSE,

profile0x0104 FALSE

maxNumberROHC-ContextSessions-r13 cs12

phyLayerParameters-r13 {

multiTone-r13 supported

rf-Parameters-r13 {

supportedBandList-r13 {

{

band-r13 7,

powerClassNB-20dBm-r13 supported

}

ue-RadioPagingInfo-r13 {

ue-Category-NB-r13 nb1

nonCriticalExtension {

ue-Capability-ContainerExt-r14 {

ue-Category-NB-r14 nb2,

rf-Parameters-v1430 {

nonCriticalExtension {

rlc-Parameters-r15 {

rlc-UM-r15 supported

mac-Parameters-v1530 {

phyLayerParameters-v1530 {

nprach-Format2-r15 supported

nonCriticalExtension {

mac-Parameters-v1610 {

measParameters-r16 {

nonCriticalExtension {

phyLayerParameters-v1700 {

ntn-Parameters-r17 {

ntn-Connectivity-EPC-r17 supported,

ntn-TA-Report-r17 supported

}

[15] Rrc Connection Reonfiguration

This message is an RRC Connection Reconfiguration for NB-IoT, which includes:

DRB Configuration: Sets up a Data Radio Bearer with PDCP configuration, including an infinite discard timer and no header compression.
RLC Configuration: Specifies the parameters for the AM RLC in both uplink and downlink. It would be important adjust these timers according to the distance and channel condition between UE and satellite

t-PollRetransmit-r13 ms6000,
maxRetxThreshold-r13 t32

Logical Channel: Assigns a logical channel identity and sets its priority.
MAC Configuration: Time alignment timer is set to infinity and includes a threshold for time alignment offset. It would be important adjust these timers according to the distance and channel condition between UE and satellite

timeAlignmentTimerDedicated-r13 infinity,
offsetThresholdTA-r17 setup: ms1

{

message c1: rrcConnectionReconfiguration-r13: {

rrc-TransactionIdentifier 0,

criticalExtensions c1: rrcConnectionReconfiguration-r13: {

dedicatedInfoNASList-r13 {

'278D2415C2010742013E0...'H

radioResourceConfigDedicated-r13 {

drb-ToAddModList-r13 {

{

eps-BearerIdentity-r13 5,

drb-Identity-r13 1,

pdcp-Config-r13 {

discardTimer-r13 infinity,

headerCompression-r13 notUsed: NULL

rlc-Config-r13 am: {

ul-AM-RLC-r13 {

t-PollRetransmit-r13 ms6000,

maxRetxThreshold-r13 t32

dl-AM-RLC-r13 {

}

logicalChannelIdentity-r13 4,

logicalChannelConfig-r13 {

priority-r13 13

}

mac-MainConfig-r13 explicitValue-r13: {

timeAlignmentTimerDedicated-r13 infinity,

offsetThresholdTA-r17 setup: ms1

}

RRC Parameters (NR)

SIB19-r17 ::= SEQUENCE {

ntn-Config-r17 NTN-Config-r17 OPTIONAL, -- Need R

t-Service-r17 INTEGER (0..549755813887) OPTIONAL, -- Need R

referenceLocation-r17 ReferenceLocation-r17 OPTIONAL, -- Need R

distanceThresh-r17 INTEGER(0..65525) OPTIONAL, -- Need R

ntn-NeighCellConfigList-r17 NTN-NeighCellConfigList-r17 OPTIONAL, -- Need R

lateNonCriticalExtension OCTET STRING OPTIONAL,

...

}

NTN-NeighCellConfigList-r17 ::= SEQUENCE (SIZE(1..maxCellNTN-r17)) OF NTN-NeighCellConfig-r17

NTN-NeighCellConfig-r17 ::= SEQUENCE {

ntn-Config-r17 NTN-Config-r17 OPTIONAL, -- Need R

carrierFreq-r17 ARFCN-ValueNR OPTIONAL, -- Need R

physCellId-r17 PhysCellId OPTIONAL -- Need R

}

DownlinkConfigCommon ::= SEQUENCE {

frequencyInfoDL FrequencyInfoDL OPTIONAL, -- Cond InterFreqHOAndServCellAdd

initialDownlinkBWP BWP-DownlinkCommon OPTIONAL, -- Cond ServCellAdd

...,

[[

ntn-Config-r17 NTN-Config-r17 OPTIONAL, -- Need R

initialDownlinkBWP-RedCap-r17 BWP-DownlinkCommon OPTIONAL -- Need R

]]

}

NTN-Config-r17 ::= SEQUENCE {

epochTime-r17 EpochTime-r17 OPTIONAL, -- Need R

ntn-UlSyncValidityDuration-r17 ENUMERATED{ s5, s10, s15, s20, s25, s30, s35,

s40, s45, s50, s55, s60, s120, s180, s240} OPTIONAL, -- Need R

cellSpecificKoffset-r17 INTEGER(0..1023) OPTIONAL, -- Need R

kmac-r17 INTEGER(0..512) OPTIONAL, -- Need R

ta-Info-r17 TAInfo-r17 OPTIONAL, -- Need R

ntn-PolarizationDL-r17 ENUMERATED {rhcp,lhcp,linear} OPTIONAL, -- Need R

ntn-PolarizationUL-r17 ENUMERATED {rhcp,lhcp,linear} OPTIONAL, -- Need R

ephemerisInfo-r17 EphemerisInfo-r17 OPTIONAL, -- Need R

...

}

kmac : K_mac is a scheduling offset provided by network if downlink and uplink frame timing are not aligned at gNB. It is needed for UE action and assumption on downlink configuration indicated by a MAC-CE command in PDSCH [see TS 38.2xy]. If the field is absent UE assumes value 0. For the reference subcarrier spacing value for the unit of K_mac in FR1, a value of 15 kHz is used. The unit of K_mac is number of slots for a given subcarrier spacing.

EpochTime-r17 ::= SEQUENCE {

sfn-r17 INTEGER(0..1023),

subFrameNR-r17 INTEGER(0..9)

}

TAInfo-r17 ::= SEQUENCE {

ta-Common-r17 INTEGER(0..66485757),

ta-CommonDrift-r17 INTEGER(-261935..261935) OPTIONAL, -- Need R

ta-CommonDriftVariant-r17 INTEGER(0..29470) OPTIONAL -- Need R

}

EphemerisInfo-r17 ::= CHOICE {

positionVelocity-r17 PositionVelocity-r17,

orbital-r17 Orbital-r17

}

PositionVelocity-r17 ::= SEQUENCE {

positionX-r17 PositionStateVector-r17,

positionY-r17 PositionStateVector-r17,

positionZ-r17 PositionStateVector-r17,

velocityVX-r17 VelocityStateVector-r17,

velocityVY-r17 VelocityStateVector-r17,

velocityVZ-r17 VelocityStateVector-r17

}

Orbital-r17 ::= SEQUENCE {

semiMajorAxis-r17 INTEGER (0..8589934591),

eccentricityE-r17 INTEGER (0..524287),

periapsis-r17 INTEGER (0..16777215),

longitude-r17 INTEGER (0..2097151),

inclinationI-r17 INTEGER (-524288..524287),

meanAnomalyM-r17 INTEGER (0..16777215)

}

PositionStateVector-r17 ::= INTEGER (-3355432..33554431)

VelocityStateVector-r17 ::= INTEGER (-131072..131071)

PUCCH-Config ::= SEQUENCE {

...

secondTPCFieldDCI-1-1-r17 ENUMERATED {enabled} OPTIONAL, -- Need R

secondTPCFieldDCI-1-2-r17 ENUMERATED {enabled} OPTIONAL, -- Need R

dl-DataToUL-ACK-r17 SetupRelease { DL-DataToUL-ACK-r17 } OPTIONAL, -- Need M

dl-DataToUL-ACK-DCI-1-2-r17 SetupRelease { DL-DataToUL-ACK-DCI-1-2-r17} OPTIONAL,--Need M

ul-AccessConfigListDCI-1-1-r17 SetupRelease { UL-AccessConfigListDCI-1-1-r17 } OPTIONAL,

--Need M

...

schedulingRequestResourceToAddModListExt-v1700 SEQUENCE (SIZE (1..maxNrofSR-Resources))

OF SchedulingRequestResourceConfigExt-v1700

OPTIONAL, -- Need N

dmrs-BundlingPUCCH-Config-r17 SetupRelease { DMRS-BundlingPUCCH-Config-r17 }

OPTIONAL, -- Need M

dl-DataToUL-ACK-v1700 SetupRelease { DL-DataToUL-ACK-v1700 } OPTIONAL, -- Need M

dl-DataToUL-ACK-MulticastDCI-Format4-1-r17 SetupRelease

{ DL-DataToUL-ACK-MulticastDCI-Format4-1-r17 }

}

DL-DataToUL-ACK-r17 ::= SEQUENCE (SIZE (1..8)) OF INTEGER (-1..127)

DL-DataToUL-ACK-v1700 ::= SEQUENCE (SIZE (1..8)) OF INTEGER (16..31)

DL-DataToUL-ACK-DCI-1-2-r17 ::= SEQUENCE (SIZE (1..8)) OF INTEGER (0..127)

UL-AccessConfigListDCI-1-2-r17 ::= SEQUENCE (SIZE (1..16)) OF INTEGER (0..15)

NOTE : (Based on 38.331)

DL-DataToUL-ACK-r17, DL-DataToUL-ACK-v1700, DL-DataToUL-ACK-DCI-1-2-r17, UL-AccessConfigListDCI-1-2-r17

List of timing for given PDSCH to the DL ACK (see TS 38.213, clause 9.1.2). The field dl-DataToUL-ACK applies to DCI format 1_1 and the field dl-DataToUL-ACK-DCI-1-2 applies to DCI format 1_2 (see TS 38.212 clause 7.3.1 and TS 38.213 clause 9.2.3). The dl-DataToUL-ACK-v1700 is applicable for NTN and dl-DataToUL-ACKr17 is applicable for up to 71 GHz. If dl-DataToUL-ACK-r16 or dl DataToUL-ACK-r17 or dl-DataToUL-ACK-v1700 is signalled, UE shall ignore the dl-DataToUL-ACK (withoutsuffix). The value -1 corresponds to "inapplicable value" for the case where the A/N feedback timing is not explicitly included at the time of scheduling PDSCH. The fields dl-DataToUL-ACK-r17 and dl-DataToUL-ACK-DCI-1-2-r17 are only applicable for SCS of 480 kHz or 960 kHz.

PDSCH-ServingCellConfig ::= SEQUENCE {

codeBlockGroupTransmission SetupRelease { PDSCH-CodeBlockGroupTransmission }

OPTIONAL, -- Need M

xOverhead ENUMERATED { xOh6, xOh12, xOh18 } OPTIONAL, -- Need S

nrofHARQ-ProcessesForPDSCH ENUMERATED {n2, n4, n6, n10, n12, n16} OPTIONAL, -- Need S

pucch-Cell ServCellIndex OPTIONAL, -- Cond SCellAddOnly

...,

[[

maxMIMO-Layers INTEGER (1..8) OPTIONAL, -- Need M

processingType2Enabled BOOLEAN OPTIONAL -- Need M

]],

[[

pdsch-CodeBlockGroupTransmissionList-r16 SetupRelease {

PDSCH-CodeBlockGroupTransmissionList-r16 }

OPTIONAL -- Need M

]],

[[

downlinkHARQ-FeedbackDisabled-r17 SetupRelease { DownlinkHARQ-FeedbackDisabled-r17 }

OPTIONAL, -- Need M

nrofHARQ-ProcessesForPDSCH-v1700 ENUMERATED {n32} OPTIONAL -- Need R

]]

}

PDSCH-CodeBlockGroupTransmission ::= SEQUENCE {

maxCodeBlockGroupsPerTransportBlock ENUMERATED {n2, n4, n6, n8},

codeBlockGroupFlushIndicator BOOLEAN,

...

}

PDSCH-CodeBlockGroupTransmissionList-r16 ::= SEQUENCE (SIZE (1..2))

OF PDSCH-CodeBlockGroupTransmission

DownlinkHARQ-FeedbackDisabled-r17 ::= BIT STRING (SIZE (32))

downlinkHARQ-FeedbackDisabled ; Used to disable the DL HARQ feedback, sent in the uplink, per HARQ process ID. The first/leftmost bit corresponds to HARQ process ID 0, the next bit to HARQ process ID 1 and so on. Bits corresponding to HARQ process IDs that are not configured shall be ignored. The bit(s) set to one identify HARQ processes with disabled DL HARQ feedback and the bit(s) set to zero identify HARQ processes with enabled DL HARQ feedback.

RRC Parameters (LTE)

SystemInformationBlockType1-v1700-IEs ::= SEQUENCE {

cellAccessRelatedInfo-NTN-r17 SEQUENCE {

cellBarred-NTN-r17 ENUMERATED {barred, notBarred},

plmn-IdentityList-v1700 PLMN-IdentityList-v1700 OPTIONAL -- Need OR

} OPTIONAL, -- Need OR

nonCriticalExtension SEQUENCE {} OPTIONAL

}

SystemInformationBlockType31-r17 ::= SEQUENCE {

servingSatelliteInfo-r17 ServingSatelliteInfo-r17,

lateNonCriticalExtension OCTET STRING OPTIONAL,

...

}

ServingSatelliteInfo-r17 ::= SEQUENCE {

ephemerisInfo-r17 CHOICE {

stateVectors EphemerisStateVectors-r17,

orbitalParameters EphemerisOrbitalParameters-r17

nta-CommonParameters-17 SEQUENCE {

nta-Common-r17 INTEGER (0..8316827) OPTIONAL, -- Need OP

nta-CommonDrift-r17 INTEGER (-261935..261935) OPTIONAL, -- Need OP

nta-CommonDriftVariation-r17 INTEGER (0..29479) OPTIONAL -- Need OP

ul-SyncValidityDuration-r17 ENUMERATED {s5, s10, s15, s20, s25, s30, s35, s40,

s45, s50, s55, s60, s120, s180, s240, s900},

epochTime-r17 SEQUENCE {

startSFN-r17 INTEGER (0..1023),

startSubFrame-r17 INTEGER (0..9)

} OPTIONAL, -- Need OP

k-Offset-r17 INTEGER (0..1023),

k-Mac-r17 INTEGER (1..512) OPTIONAL, -- Need OP

...

}

Detailed meaning of the IEs based on 36.331 are as follows :

nta-Common : Network-controlled common TA( for the details, see TS 36.213). Unit of μs. Step of 32.55208 ×10-3 μs. Actual value = field value * 32.55208 ×10-3. If the field is absent, the UE uses the (default) value of 0.
nta-CommonDrift : Drift rate of the common TA, see TS 36.213. Unit of μs/s. Step of 0.2 ×10-3 μs/s. Actual value = field value * 0.2 ×10-3. If the field is absent, the UE uses the (default) value of 0.
nta-CommonDriftVariation : Drift rate variation of the common TA, see TS 36.213. Unit of μs/s2. Step of 0.2 ×10-4 μs/s2. Actual value = field value * 0.2 ×10-4. If the field is absent, the UE uses the (default) value of 0.
k-Offset : Scheduling offset used in the timing relationships in NTN, see TS 36.213. Unit in ms.
k-Mac : Scheduling offset used when downlink and uplink frame timing are not aligned at the eNB, see TS 36.213. Unit in ms. If the field if absent, the UE uses the (default) value of 0.
epochTime : Epoch time of the satellite ephemeris data and common TA parameters, see TS 36.213. The reference point for epoch time of the serving satellite ephemeris and Common TA parameters is the uplink time synchronization reference point.epochTime is the starting time of a DL subframe indicated by startSFN and startSubframe. If the field is absent, the UE uses the starting time of the DL subframe corresponding to the end of the SI window during which the SI message carrying SIB31 is transmitted. E-UTRAN always includes epochTime when SystemInformationBlockType31 is provided through dedicated signalling.
orbitalParameters : Instantaneous values of the satellite orbital parameters. The signalled values are only valid for the duration as defined by ul-SyncValidationDuration and epochTime.
stateVectors : Instantaneous values of the satellite state vectors. The signalled values are only valid for the duration as defined by ul-SyncValidationDuration and epochTime.
ul-SyncValidationDuration : Validity duration of the satellite ephemeris data and common TA parameters, i.e. maximum time during which the UE can apply the satellite ephemeris without acquiring new satellite ephemeris, see TS 36.213. Unit in second. Value s5 corresponds to 5 seconds, value s10 corresponds to 10 seconds and so on.