The basic idea of NTN is obvious. It is to deliver 5G/NR service via space (satellite) or air (airborne platform) as illlustrated below. Nothing about that idea is new, and satellite operators have been doing it for decades. What is new is doing it with the same air interface and the same core network that a terrestrial cell uses.

What makes NTN hard is not the idea. It is that the air interface was designed around a base station that stays still and stays close. A satellite does neither. It sits hundreds or thousands of kilometres away, and in low orbit it crosses the sky in minutes. Release 17 therefore spends most of its NTN effort on three quantities the UE can no longer measure for itself. Those are how far away the network is, how fast that distance is changing, and where the satellite will be next.

Two radio technologies are covered separately below, and the split matters when reading a log. NR over NTN broadcasts its satellite assistance in SIB19. LTE and NB-IoT over NTN use SIB31 and SIB32 instead. The field names differ between the two, the value ranges differ as well, and a number copied from one into the other will not decode.

• 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
• NTN NR
• NTN LTE NB IoT
• YouTube
• YouTube in Korean
• 3GPP Reference
• Other References

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.

Figure 1. Two satellites are drawn and only one of them is the gNB. The other is a relay, so the picture states the transparent against regenerative payload question without naming it.

• The satellite at the top right is labelled gNB, so in that branch the base station itself is in orbit.
• The satellite at the top left is labelled Relay, and a relay forwards the radio signal rather than terminating the protocol.
• The airship in the middle right is labelled Airborne platform, and it serves the ship drawn below it.
• The dish at the bottom right is the terrestrial station, and it links to the gNB satellite and to the airborne platform.
• The mountain cabin and the island are the two hardest terrestrial cases in the picture, and both reach the network through the relay satellite.
• Every link is drawn as a dashed line, so all of them are radio links.

NOTE : The illustration in Figure 1 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, shown as Figure 2. It shows various different use cases and potential ground-to-airborne connection mechansm.

Figure 2. The altitude axis on the right is what separates the two work items. Everything at 10 km and above falls under the NTN branch, and the drone at 150 m is UAV work instead.

• The bracket across the top reads NTN in a wide sense, and it splits into 3GPP work on NTN on the left and 3GPP work on UAV on the right.
• Three arrows drop out of the NTN branch, onto the satellite network, the high altitude platform station, and the air-to-ground network.
• One arrow drops out of the UAV branch, onto the drone.
• The balloon is labelled High altitude platform station as IMT base station (HIBS), so it is a base station rather than a relay.
• The scale on the right is marked not to scale, and it runs from ground level through 150 m, 10 km, 20 km, and 600 km and above.
• The satellite sits at 600 km and above, the HIBS balloon at 20 km, the aeroplane at 10 km, and the UAV at 150 m.
• The ground row names three settings : Remote drawn as a ship, Rural drawn as a farm, and Urban drawn as a city with a tower.

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). The table below gives that propagation figure for the three orbit classes, and the three rows sit far enough apart that they are really three different design problems.

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

Figure 3. The right hand column is not a sum of the two beside it. It is roughly twice the maximum, because the one-way path counts the ground station to satellite hop as well as the satellite to UE hop.

• The first two numeric columns are the minimum and the maximum UE to satellite delay, both in milliseconds.
• The third column is the one-way maximum propagation delay, also in milliseconds.
• LEO is 3 ms minimum and 15 ms maximum, against a one-way maximum of 30 ms.
• MEO is 27 ms minimum and 43 ms maximum, against a one-way maximum of 90 ms.
• GEO is 120 ms minimum and 140 ms maximum, against a one-way maximum of 280 ms.

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

The spread inside each row drives the design more than the absolute value does. A LEO cell has to work at 3 ms when the satellite is overhead and at 15 ms when it is near the horizon. The distance therefore changes by a factor of five during a single pass. GEO is the opposite case. Its 120 to 140 ms range is wide in milliseconds and narrow as a ratio, so a GEO cell can treat the delay as almost constant.

The NOTE above is the reason SIB19 exists. A UE starting random access has no timing advance yet, and the timing advance field in the random access response cannot express a value this large. The network therefore has to give the UE enough information to compute the delay itself, before the first uplink transmission. That information is the common timing advance in ta-Info-r17 and the satellite position in ephemerisInfo-r17, and both are broadcast rather than sent per UE.

• The ratio matters more than the value : one LEO pass changes the UE to satellite delay by a factor of five, while a GEO cell barely changes at all.
• The one-way figure counts two hops : it is about twice the UE to satellite maximum, because the feeder link down to the ground station is included.
• RAR cannot carry it : even the 3 ms LEO minimum exceeds what the timing advance field of the random access response can express, so the UE has to pre-compensate.
• These are propagation delays only : the end-to-end figures in the next section add 5 ms of network latency on top of them.

Performance Requirements

Delay is only one axis. 22.261 also fixes what throughput a satellite UE should experience, and it does so per scenario rather than per orbit. The seven scenarios differ more than the three orbits do, because a handheld on foot and an aeroplane at 1000 km/h ask the same network for very different things.

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 >

Figure 4. Most cells in this table read TBD or carry square brackets. 22.261 uses brackets for a value that was still open, so the table is closer to a statement of intent than to a set of numbers to design against.

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.

Three qualifications belong with the table, and all three are printed in its own notes. Note 1 says area traffic capacity is averaged over a satellite beam, not over a square kilometre of ground. Note 5 says every value is a target rather than a strict requirement. Note 6 says each value should be analysed independently, so the rows are not a consistent set to be met together.

The summary above reads the bracketed figures as plain numbers. In 22.261 a square bracket marks a value that was still open when the table was written, so those entries are the least settled ones in the table.

• Area traffic capacity is mostly unset : only the pedestrian and the narrowband IoT rows carry a figure, and the other five read TBD in both directions.
• Overall user density is set in the same two rows : pedestrian at 100 per square kilometre and narrowband IoT at 400, with TBD everywhere else.
• Only three rows state an activity factor : pedestrian, vehicular connectivity and narrowband IoT, so user density cannot be turned into an offered load for the rest.
• Two rows are uplink heavy : video surveillance asks 3 Mbit/s up against 0,5 Mbit/s down, and narrowband IoT asks 10 kbit/s up against 2 kbit/s down.

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.

A fourth mechanism belongs on that list, and the example log further down uses it twice. NTN-Config-r17 carries ta-Report-r17, and when SIB19 includes that field the UE reports the timing advance it actually applied. 38.331 ties the reporting to random access for RRC connection establishment, RRC connection resume and RRC connection reestablishment. The call flow below shows TA_REPORT as a MAC CE at step 9 and again at step 16, and that is the network collecting exactly this.

The three fields above arrive in different places, and knowing which is which is worth having clear before reading a log. All three of epochTime-r17, ta-Info-r17 and ephemerisInfo-r17 sit inside NTN-Config-r17. NTN-Config-r17 itself is broadcast in SIB19, and it is also carried in ServingCellConfigCommon when the network sends a dedicated configuration. A UE that has already read SIB19 can therefore be given a corrected set at handover, without waiting for the next SI period.

• Timing is the Release 17 problem, not throughput : all four mechanisms exist so the UE can compute a delay it has no way to measure.
• The UE pre-compensates : ta-Info-r17 and ephemerisInfo-r17 are broadcast so the UE can compute its own advance before the first PRACH.
• K1 was widened rather than replaced : dl-DataToUL-ACK-v1700 adds the 16 to 31 range, and nrofHARQ-ProcessesForPDSCH-v1700 takes the process count to 32.
• Ephemeris changes are invisible to the valueTag : 38.331 excludes ephemerisInfo, epochTime and the ta-Common fields when determining system information change. A UE cannot notice an update from the valueTag in SIB1.

Examples

The listings below come from a live log rather than from a specification, so they show what an NTN attach actually contains. Read them against the call flow table first. The two TA_REPORT steps and the K_OFFSET MAC CE are the parts with no equivalent in a terrestrial attach, and everything else follows the ordinary NB-IoT sequence.

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.

Figure 5. The eNB is on the ground, not on the satellite. The satellite is drawn as a relay, so the protocol terminates at the ground station and the orbit only adds delay.

• The satellite on the left of the orbit is labelled Satellite (Relay).
• The dish drawn on the Earth is labelled Ground Station (eNB), so the base station is terrestrial.
• The device at the lower right is labelled IoT Devices.
• Two beams leave the satellite, one down to the ground station and one down to the IoT devices.
• The orbit is drawn as a thin circle well outside the Earth, and the satellite sits on it.

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 {

              0,

              0,

              1

            },

            mnc {

              0,

              1

            }

          },

          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 {

      0,

      0

    },

    nonCriticalExtension {

      nonCriticalExtension {

        nonCriticalExtension {

          nonCriticalExtension {

            schedulingInfoList-v1530 {

              {

              },

              {

                sib-MappingInfo-v1530 {

                  sibType31-NB-r17

                }

              }

            },

            nonCriticalExtension {

              nonCriticalExtension {

                cellAccessRelatedInfo-NTN-r17 {

                  cellBarred-NTN-r17 notBarred

                }

              }

            }

          }

        }

      }

    }

  }

}

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 {

                r1

              },

              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

        }

      }

    }

  }

}

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

          }

        }

      }

    }

  }

}

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

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

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

    }

  }

}

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

          }

        }

      }

    }

  }

}

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

{

  message c1: ueCapabilityEnquiry-r13: {

    rrc-TransactionIdentifier 0,

    criticalExtensions c1: ueCapabilityEnquiry-r13: {

    }

  }

}

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 {

            nonCriticalExtension {

              nonCriticalExtension {

                rlc-Parameters-r15 {

                  rlc-UM-r15 supported

                },

                mac-Parameters-v1530 {

                },

                phyLayerParameters-v1530 {

                  nprach-Format2-r15 supported

                },

                nonCriticalExtension {

                  nonCriticalExtension {

                    mac-Parameters-v1610 {

                    },

                    measParameters-r16 {

                    },

                    nonCriticalExtension {

                      nonCriticalExtension {

                        phyLayerParameters-v1700 {

                        },

                        ntn-Parameters-r17 {

                          ntn-Connectivity-EPC-r17 supported,

                          ntn-TA-Report-r17 supported

                        }

                      }

                    }

                  }

                }

              }

            }

          }

        }

      }

    }

  }

}

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)

Everything NR NTN needs is reachable from one system information block. SIB19 carries NTN-Config-r17, and NTN-Config-r17 carries the epoch time, the common timing advance and the satellite ephemeris. The listings below start there and work downwards, so the first tile is the one to read first. The tiles after the ephemeris types cover the HARQ and PUCCH changes that the long round trip forced.

Following is based on 38.331 v19.3.0 (Release 19)

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-NeighCellConfigListExt-v1720  NTN-NeighCellConfigList-r17             OPTIONAL   -- Need R
    ]],
    [[
    movingReferenceLocation-r18       ReferenceLocation-r17                   OPTIONAL,  -- Need R
    ntn-CovEnh-r18                    NTN-CovEnh-r18                          OPTIONAL,  -- Need R
    satSwitchWithReSync-r18           SatSwitchWithReSync-r18                 OPTIONAL   -- Need R
    ]],
    [[
    refLocList-r19                    RefLocList-r19                          OPTIONAL   -- Need R
    ]]
}
        

Following is based on 38.331 v19.3.0 (Release 19)

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

Following is based on 38.331 v19.3.0 (Release 19)

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
}
        

Following is based on 38.331 v19.3.0 (Release 19)

ServingCellConfigCommon ::=           SEQUENCE {
    physCellId                        PhysCellId                              OPTIONAL,  -- Cond HOAndServCellAdd,
    downlinkConfigCommon              DownlinkConfigCommon                    OPTIONAL,  -- Cond HOAndServCellAdd
    uplinkConfigCommon                UplinkConfigCommon                      OPTIONAL,  -- Need M
    -- ... fields not related to NTN are omitted here ...
    ss-PBCH-BlockPower                INTEGER (-60..50),
    ...,
    [[
    -- Release 16 extension group omitted
    ]],
    [[
    highSpeedConfig-v1700             HighSpeedConfig-v1700                   OPTIONAL,  -- Need R
    channelAccessMode2-r17            ENUMERATED {enabled}                    OPTIONAL,  -- Cond SharedSpectrum2
    discoveryBurstWindowLength-r17    ENUMERATED {ms0dot125, ms0dot25, ms0dot5,
                                                 ms0dot75, ms1, ms1dot25}     OPTIONAL,  -- Need R
    ssb-PositionQCL-r17               SSB-PositionQCL-Relation-r17            OPTIONAL,  -- Cond SharedSpectrum2
    highSpeedConfigFR2-r17            HighSpeedConfigFR2-r17                  OPTIONAL,  -- Need R
    uplinkConfigCommon-v1700          UplinkConfigCommon-v1700                OPTIONAL,  -- Need R
            ntn-Config-r17                    NTN-Config-r17                          OPTIONAL   -- Need R
    ]],
    -- later extension groups omitted
    ...
}
        

Following is based on 38.331 v19.3.0 (Release 19)

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,  s900}          OPTIONAL,  -- Cond SIB19
    cellSpecificKoffset-r17           INTEGER(1..1023)                        OPTIONAL,  -- Need R
    kmac-r17                          INTEGER(1..512)                         OPTIONAL,  -- Need R
    ta-Info-r17                       TA-Info-r17                              OPTIONAL,  -- Need R
    ntn-PolarizationDL-r17            ENUMERATED {rhcp,lhcp,linear}           OPTIONAL,  -- Need R
    ntn-PolarizationUL-r17            ENUMERATED {rhcp,lhcp,linear}           OPTIONAL,  -- Need S
    ephemerisInfo-r17                 EphemerisInfo-r17                        OPTIONAL,  -- Need R
            ta-Report-r17                     ENUMERATED {enabled}                    OPTIONAL,  -- Need R
    ...,
    [[
    ntn-LinearPolarizationDL-r19      ENUMERATED {xlp,ylp}                    OPTIONAL,  -- Need R
    ntn-LinearPolarizationUL-r19      ENUMERATED {xlp,ylp}                    OPTIONAL   -- Need S
    ]]
}
        

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.

Following is based on 38.331 v19.3.0 (Release 19)

EpochTime-r17 ::=                    SEQUENCE {
    sfn-r17                           INTEGER(0..1023),
    subFrameNR-r17                    INTEGER(0..9)
}
        

Following is based on 38.331 v19.3.0 (Release 19)

TA-Info-r17 ::=                      SEQUENCE {
    ta-Common-r17                     INTEGER(0..66485757),
    ta-CommonDrift-r17                INTEGER(-257303..257303)                OPTIONAL,  -- Need R
    ta-CommonDriftVariant-r17         INTEGER(0..28949)                       OPTIONAL   -- Need R
}
        

Following is based on 38.331 v19.3.0 (Release 19)

EphemerisInfo-r17 ::=                CHOICE {
    positionVelocity-r17              PositionVelocity-r17,
    orbital-r17                       Orbital-r17
}
        

Following is based on 38.331 v19.3.0 (Release 19)

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
}
        

Following is based on 38.331 v19.3.0 (Release 19)

Orbital-r17 ::=                      SEQUENCE {
    semiMajorAxis-r17                 INTEGER (0..8589934591),
    eccentricity-r17                  INTEGER (0..1048575),
    periapsis-r17                     INTEGER (0..268435455),
    longitude-r17                     INTEGER (0..268435455),
    inclination-r17                   INTEGER (-67108864..67108863),
    meanAnomaly-r17                   INTEGER (0..268435455)
}
        

Following is based on 38.331 v19.3.0 (Release 19)

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

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

Following is based on 38.331 v19.3.0 (Release 19)

PUCCH-Config ::=                     SEQUENCE {
    -- only the Release 17 extension group is shown here
    ...,
    [[
    -- Release 16 extension group omitted
    ]],
    [[
    format0-r17                       SetupRelease { PUCCH-FormatConfig }        OPTIONAL, -- Need M
    format2Ext-r17                    SetupRelease { PUCCH-FormatConfigExt-r17 } OPTIONAL, -- Need M
    format3Ext-r17                    SetupRelease { PUCCH-FormatConfigExt-r17 } OPTIONAL, -- Need M
    format4Ext-r17                    SetupRelease { PUCCH-FormatConfigExt-r17 } OPTIONAL, -- Need M
    ul-AccessConfigListDCI-1-2-r17    SetupRelease { UL-AccessConfigListDCI-1-2-r17 }
                                                                                 OPTIONAL, -- Need M
    mappingPattern-r17                ENUMERATED {cyclicMapping, sequentialMapping}
                                                                                 OPTIONAL, -- Need R
    powerControlSetInfoToAddModList-r17   SEQUENCE (SIZE (1..maxNrofPowerControlSetInfos-r17))
                                          OF PUCCH-PowerControlSetInfo-r17       OPTIONAL, -- Need N
    powerControlSetInfoToReleaseList-r17  SEQUENCE (SIZE (1..maxNrofPowerControlSetInfos-r17))
                                          OF PUCCH-PowerControlSetInfoId-r17     OPTIONAL, -- Need N
    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 }
                                                                                 OPTIONAL, -- Need M
    sps-PUCCH-AN-ListMulticast-r17    SetupRelease { SPS-PUCCH-AN-List-r16 }     OPTIONAL  -- Need M
    ]],
    [[
    -- Release 19 extension group omitted
    ]]
}
        

Following is based on 38.331 v19.3.0 (Release 19)

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. 

Following is based on 38.331 v19.3.0 (Release 19)

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
    ]]
}
        

Following is based on 38.331 v19.3.0 (Release 19)

PDSCH-CodeBlockGroupTransmission ::=  SEQUENCE {
    maxCodeBlockGroupsPerTransportBlock   ENUMERATED {n2, n4, n6, n8},
    codeBlockGroupFlushIndicator          BOOLEAN,
    ...
}
        

Following is based on 38.331 v19.3.0 (Release 19)

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)

The LTE side solves the same problem under different field names, and the differences are easy to miss. Common timing advance is called nta-Common here rather than ta-Common, and the two do not share a granularity. Satellite ephemeris arrives in SIB31 rather than SIB19, and a separate SIB32 carries the list of other satellites. The three listings below follow that order.

Following is based on 36.331 v19.3.0 (Release 19)

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              SystemInformationBlockType1-v1800-IEs   OPTIONAL
}
        

Following is based on 36.331 v19.3.0 (Release 19)

SystemInformationBlockType31-r17 ::=  SEQUENCE {
    servingSatelliteInfo-r17          ServingSatelliteInfo-r17,
    lateNonCriticalExtension          OCTET STRING                            OPTIONAL,
    ...,
    [[
    servingSatelliteInfo-v1820        ServingSatelliteInfo-v1820              OPTIONAL   -- Need OR
    ]],
    [[
    servingSatelliteInfo-v1900        ServingSatelliteInfo-v1900              OPTIONAL   -- Need OR
    ]]
}
        

Following is based on 36.331 v19.3.0 (Release 19)

ServingSatelliteInfo-r17 ::=          SEQUENCE {
    ephemerisInfo-r17                 CHOICE {
        stateVectors                      EphemerisStateVectors-r17,
        orbitalParameters                 EphemerisOrbitalParameters-r17
    },
    nta-CommonParameters-r17          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.

Following is based on 36.331 v19.3.0 (Release 19)

EphemerisStateVectors-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
}
        

Following is based on 36.331 v19.3.0 (Release 19)

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

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

Following is based on 36.331 v19.3.0 (Release 19)

EphemerisOrbitalParameters-r17 ::=    SEQUENCE {
    semiMajorAxis-r17                 INTEGER (0..8589934591),
    eccentricity-r17                  INTEGER (0..1048575),
    periapsis-r17                     INTEGER (0..268435455),
    longitude-r17                     INTEGER (0..268435455),
    inclination-r17                   INTEGER (-67108864..67108863),
    anomaly-r17                       INTEGER (0..268435455)
}
        

Following is based on 36.331 v19.3.0 (Release 19)

SystemInformationBlockType32-r17 ::=  SEQUENCE {
    satelliteInfoList-r17             SatelliteInfoList-r17                   OPTIONAL,  -- Need OR
    lateNonCriticalExtension          OCTET STRING                            OPTIONAL,
    ...,
    [[
    satelliteInfoList-v1800           SatelliteInfoList-v1800                 OPTIONAL   -- Need OR
    ]],
    [[
    satelliteInfoList-v1830           SatelliteInfoList-v1830                 OPTIONAL   -- Need OR
    ]]
}
        

Following is based on 36.331 v19.3.0 (Release 19)

SatelliteInfoList-r17 ::=             SEQUENCE (SIZE (1..maxSat-r17)) OF SatelliteInfo-r17
        

Following is based on 36.331 v19.3.0 (Release 19)

SatelliteInfo-r17 ::=                 SEQUENCE {
    satelliteId-r17                   INTEGER (0..255),
    serviceInfo-r17                   SEQUENCE {
        tle-EphemerisParameters-r17       TLE-EphemerisParameters-r17         OPTIONAL,  -- Need OR
        t-ServiceStart-r17                TimeOffsetUTC-r17                   OPTIONAL   -- Need OR
    },
    footprintInfo-r17                 SEQUENCE {
        referencePoint-r17                SEQUENCE {
            longitude-r17                     INTEGER (-131072..131071),
            latitude-r17                      INTEGER (-131072..131071)
        }                                                                     OPTIONAL,  -- Need OR
        elevationAngles-r17               SEQUENCE {
            elevationAngleRight-r17           INTEGER (-14..14),
            elevationAngleLeft-r17            INTEGER (-14..14)               OPTIONAL   -- Need OP
        }                                                                     OPTIONAL,  -- Need OR
        radius-r17                        INTEGER (1..256)                    OPTIONAL   -- Need OR
    }
}

TLE-EphemerisParameters-r17 ::=       SEQUENCE {
    inclination-r17                   INTEGER (0..2097151),
    argumentPerigee-r17               INTEGER (0..4194303),
    rightAscension-r17                INTEGER (0..4194303),
    meanAnomaly-r17                   INTEGER (0..4194303),
    eccentricity-r17                  INTEGER (0..16777215),
    meanMotion-r17                    INTEGER (0..17179869183),
    bStarDecimal-r17                  INTEGER (-99999..99999),
    bStarExponent-r17                 INTEGER (-9..9),
    epochStar-r17                     INTEGER (-1048575..1048575)
}
        

RRC Parameters (NB IoT)

NB-IoT over NTN reuses the LTE structure almost entirely, and that is why this section holds one listing rather than ten. SystemInformationBlockType32-NB-r17 has the same shape as its LTE counterpart and points at the same SatelliteInfoList-r17. The serving satellite parameters a UE needs sit in SIB31, and NB-IoT does define its own numbering for that one. Step 4 of the call flow shows it being read.

SIB31-NB is the block step 4 of the call flow reads, and it is the one the page did not show. It reuses ServingSatelliteInfo-r17 directly, so the serving satellite parameters an NB-IoT UE decodes are the same structure an LTE UE decodes.

Following is based on 36.331 v19.3.0 (Release 19)

SystemInformationBlockType31-NB-r17 ::=       SEQUENCE {
    servingSatelliteInfo-r17          ServingSatelliteInfo-r17,
    lateNonCriticalExtension          OCTET STRING                            OPTIONAL,
    ...,
    [[
    servingSatelliteInfo-v1820        ServingSatelliteInfo-v1820              OPTIONAL   -- Need OR
    ]],
    [[
    servingSatelliteInfo-v1900        ServingSatelliteInfo-v1900              OPTIONAL   -- Need OR
    ]]
}
        

SIB32-NB is the neighbour list, and it is the block the NB-IoT numbering does change.

Following is based on 36.331 v19.3.0 (Release 19)

SystemInformationBlockType32-NB-r17 ::=       SEQUENCE {
    satelliteInfoList-r17             SatelliteInfoList-r17                   OPTIONAL,  -- Need OR
    lateNonCriticalExtension          OCTET STRING                            OPTIONAL,
    ...,
    [[
    satelliteInfoList-v1800           SatelliteInfoList-v1800                 OPTIONAL   -- Need OR
    ]],
    [[
    satelliteInfoList-v1830           SatelliteInfoList-NB-v1830              OPTIONAL   -- Need OR
    ]]
}

The reuse goes further than the block name suggests. SatelliteInfoList-r17 is the LTE type itself, not an NB-IoT copy of it, so the satellite list an NB-IoT UE reads has the same encoding as the one an LTE UE reads. Only the outer system information block differs, and it differs because NB-IoT numbers its blocks separately.

The two Release 18 extension groups are worth noticing for a different reason. The first one points at the shared SatelliteInfoList-v1800. The second points at SatelliteInfoList-NB-v1830, and that type is NB-IoT specific. The reuse therefore stops partway through Release 18, so a decoder written against the Release 17 shape alone will not follow it.

• The satellite list is shared : SatelliteInfoList-r17 is the same type in SIB32 and in SIB32-NB, so one decoder covers both.
• The serving satellite is somewhere else : SIB32 lists other satellites, and the parameters for the satellite currently serving the UE are in SIB31.
• Release 18 splits the two apart : SatelliteInfoList-NB-v1830 is NB-IoT specific, so the shared shape does not continue through the whole of Release 18.

YouTube

• Beginners: Non Terrestrial Networks (NTN)  
• R&S Thirty - Five: Non-terrestrial networks NTN - Rohde Schwarz (2020)
• Webinar: The road ahead for satellite based Non-Terrestrial Networks (NTN) - Rohde Schwarz
• Aerial Access Networks for 6G: From UAV, HAP, to Satellite Communication Networks
• Non-Terrestrial Networks (NTN): The Next 20 Years -- Prof. Halim Yanikomeroglu, 04 June 2020
• Satellite for 5G
• Satellite Cellular Backhaul
• Non-Terrestrial Networks: 5G-Advanced and Beyond - Commonwealth Cyber Initiative (2021)
• WEBINAR | Unified Software Defined Satellite Ground Solution – Magic of AI and 5G - SpaceBridge (2022)
• 6G-NTN: Perspectives and Challenges - 5G Forum (2022)
• Integration of Satellite in 5G Network Part 1/2 - 5G Mobile Communications (2022)
• Integration of Satellite in 5G Network Part 2/2 - 5G Mobile Communications (2022)
• Thinknet 6G NTN 2022: Non-Terrestrial Networks evolving towards 6G (R&S) - Bayern Innovative GmbH (2022)
• 3GPP NTN standardization: past, current and future - 5G Forum (2022)
• SATCOM and Non-terrestrial Network Design - Matlab (2023)
• GSA Snapshot: 5G NTN and satellite connectivity - Global mobile Suppliers Association (GSA) (2023)

YouTube in Korean

• 위성을 연결하고 6G로 도약하는 5G NTN을 소개합니다! - 5G NTN(Non-Terrestrial Networks) 기술 소개 - TalkIT (2023)

3GPP Reference

The two study items below came first, and they are the ones to read for background rather than for field definitions. 38.811 sets the scenarios and the channel model. 38.821 turns those into the solutions that Release 17 went on to adopt.

[1] 3GPP TR 38.811 : Study on New Radio (NR) to support non-terrestrial networks

[2] 3GPP TR 38.821 :  Solutions for NR to support non-terrestrial networks (NTN)

[3] 3GPP TR 23.737 - Study on architecture aspects for using satellite access in 5G

[4] RP-193234 : Solutions for NR to support non-terrestrial networks (NTN)

[5] TS 22.261 : Service requirements for the 5G system; Stage 1 (Release 18)

Other References

These sit outside 3GPP, so they carry the parts the specifications leave out : orbital mechanics, constellation design, and the commercial case. The first entry is a calculator rather than a paper, and it is the quickest way to sanity check an ephemeris.

[1] Orbit of a satellite Calculator

[2] LEO Small-Satellite Constellations for 5G and Beyond-5G Communications

[3] Satellite Communications in the New Space Era: A Survey and Future Challenges

[4] Assessing satellite-terrestrial integration opportunities in the 5G environment  

[5] Satellite and Terrestrial Network for 5G

[6] Application of 5G new radio for satellite links with low peak-to-average power ratios

[7] 5G from Space: An Overview of 3GPP Non-Terrestrial Networks