3GPP TR 38.821 V16.0.

0 (2019-12)
Technical Report

3rd Generation Partnership Project;

Technical Specification Group Radio Access Network;
Solutions for NR to support non-terrestrial networks (NTN)
(Release 16)

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Release 16 2 3GPP TR 38.821 V16.0.0 (2019-12)

3GPP

Postal address

3GPP support office address

650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet
http://www.3gpp.org

Copyright Notification

No part may be reproduced except as authorized by written permission.

The copyright and the foregoing restriction extend to reproduction in all media.

© 2019, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.

UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association

3GPP
Release 16 3 3GPP TR 38.821 V16.0.0 (2019-12)

Contents
Foreword.....................................................................................................................................................7
1 Scope.................................................................................................................................................9
2 References.........................................................................................................................................9
3 Definitions of terms, symbols and abbreviations............................................................................12
3.1 Terms.........................................................................................................................................................12
3.2 Symbols.....................................................................................................................................................13
3.3 Abbreviations............................................................................................................................................13
4 Non-Terrestrial Networks overview and scenarios.........................................................................15
4.1 Non-Terrestrial Networks overview.........................................................................................................15
4.2 Non-Terrestrial Networks reference scenarios..........................................................................................16
5 NTN-based NG-RAN Architectures...............................................................................................19
5.1 Transparent satellite based NG-RAN architecture....................................................................................19
5.1.1 Overview.............................................................................................................................................19
5.1.2 Detailed description of the architecture...............................................................................................20
5.1.3 NG-RAN impacts................................................................................................................................21
5.2 Regenerative satellite based NG-RAN architectures................................................................................22
5.2.1 gNB processed payload.......................................................................................................................22
5.2.1.1 Overview........................................................................................................................................22
5.2.1.2 Detailed description of the architecture.........................................................................................23
5.2.1.3 NG-RAN impacts..........................................................................................................................24
5.2.2 gNB-DU processed payload................................................................................................................25
5.2.2.1 Overview........................................................................................................................................25
5.2.2.2 Detailed description of the architecture.........................................................................................25
5.2.2.3 NG-RAN impacts..........................................................................................................................27
5.2.3 gNB processed payload based on relay-like architectures (Optional).................................................27
5.3 Multi connectivity involving NTN-based NG-RAN.................................................................................28
5.3.1 Overview.............................................................................................................................................28
5.3.2 Architecture aspects.............................................................................................................................28
5.3.3 NG-RAN impacts................................................................................................................................30
5.4 Service continuity between NTN and Terrestrial Networks.....................................................................31
5.4.1 Scope...................................................................................................................................................32
5.4.2 Reference scenario...............................................................................................................................33
5.4.3 Assumptions........................................................................................................................................33
6 Radio Layer 1 issues and related solutions.....................................................................................34
6.1 Link-Level and System-Level Evaluations...............................................................................................34
6.1.1 System level simulations.....................................................................................................................34
6.1.1.1 Simulation assumptions.................................................................................................................34
6.1.1.2 Calibration results..........................................................................................................................46
6.1.1.3 System Level Simulation Evaluation Results................................................................................48
6.1.2 Link level simulations.........................................................................................................................49
6.1.3 Link Budget Analysis..........................................................................................................................51
6.1.3.1 Link Budget Calculation................................................................................................................51
6.1.3.2 Parameters......................................................................................................................................52
6.1.3.3 Link Budget Results.......................................................................................................................55
6.1.4 Multiple satellites simulation..............................................................................................................57
6.1.4.1 Simulation cases............................................................................................................................57
6.1.4.2 Methodology for multiple satellites simulation.............................................................................57
6.2 Physical layer control procedures.............................................................................................................58
6.2.1 Timing relationships............................................................................................................................58
6.2.1.1 Background....................................................................................................................................59
6.2.1.2 Enhancements................................................................................................................................60
6.2.2 Uplink power control...........................................................................................................................61
6.2.3 AMC and delayed CSI feedback.........................................................................................................61

3GPP
Release 16 4 3GPP TR 38.821 V16.0.0 (2019-12)

6.2.4 Beam management and polarization support......................................................................................63

6.2.5 Impact of feeder link switch................................................................................................................63
6.3 Uplink timing advance/RACH procedure.................................................................................................64
6.3.1 General................................................................................................................................................64
6.3.2 DL synchronization.............................................................................................................................64
6.3.3 Random access....................................................................................................................................64
6.3.4 Maintenance for UL timing advance and frequency synchronization.................................................65
6.4 More delay-tolerant re-transmission mechanisms....................................................................................66
6.4.1 Disabling of HARQ in NR NTN.........................................................................................................66
6.4.2 HARQ Optimization for NR NTN......................................................................................................66
7 Radio protocol issues and related solutions....................................................................................69
7.1 Requirements and key issues....................................................................................................................69
7.1.1 Delay....................................................................................................................................................69
7.2 User plane enhancements..........................................................................................................................70
7.2.1 MAC....................................................................................................................................................70
7.2.1.1 Random Access..............................................................................................................................70
7.2.1.1.1 4-Step RACH Procedure..........................................................................................................70
7.2.1.1.1.1 RACH capacity evaluation.................................................................................................70
7.2.1.1.1.2 4-step RACH enhancements for Non-Terrestrial Networks..............................................71
7.2.1.1.2 2-Step RACH Procedure..........................................................................................................79
7.2.1.1.3 Random access enhancements to address mobility issues.......................................................79
7.2.1.1.4 Co-existence with different random access capabilities..........................................................80
7.2.1.2 Discontinuous Reception (DRX)...................................................................................................80
7.2.1.2.1 DRX enhancements..................................................................................................................82
7.2.1.3 Scheduling Request........................................................................................................................83
7.2.1.4 HARQ............................................................................................................................................83
7.2.1.5 Uplink scheduling..........................................................................................................................84
7.2.1.5.1 Assignment of uplink resources...............................................................................................84
7.2.2 RLC.....................................................................................................................................................85
7.2.2.1 Status Reporting.............................................................................................................................85
7.2.2.2 RLC Sequence Numbers................................................................................................................85
7.2.3 PDCP...................................................................................................................................................87
7.2.3.1 SDU Discard..................................................................................................................................87
7.2.3.2 Reordering and In-order Delivery..................................................................................................87
7.2.3.3 PDCP Sequence Number and Window Size..................................................................................87
7.2.4 SDAP...................................................................................................................................................89
7.3 Control plane enhancements.....................................................................................................................89
7.3.1 Idle mode mobility enhancements.......................................................................................................90
7.3.1.1 General Tracking Area Issues [16]................................................................................................90
7.3.1.2 Moving Tracking Area for NTN LEO, Scenario C2 and D2 [17].................................................91
7.3.1.3 Fixed Tracking Area for NTN LEO, Scenario C2 and D2 [17]....................................................91
7.3.1.3.1 Approach 1: For the case when UE location information is unavailable.................................91
7.3.1.3.2 Approach 2: For the case when UE location information is available.....................................92
7.3.1.3.3 Tracking Area recommendation...............................................................................................92
7.3.1.4 Enhancements to idle/inactive UE mobility procedure.................................................................92
7.3.1.5 Mobility state estimation mechanism............................................................................................93
7.3.1.6 Using ephemeris information and UE location information..........................................................93
7.3.1.7 System information broadcast.......................................................................................................93
7.3.2 Connected mode mobility enhancements............................................................................................93
7.3.2.1 Mobility Challenges for Non-Terrestrial Networks.......................................................................93
7.3.2.1.1 Latency associated with mobility signalling............................................................................93
7.3.2.1.2 Measurement Validity..............................................................................................................94
7.3.2.1.3 Cell overlap and reduced signal strength variation..................................................................95
7.3.2.1.4 Frequent and unavoidable handover........................................................................................95
7.3.2.1.5 Dynamic neighbour cell set......................................................................................................96
7.3.2.1.6 Handover for a large number of UEs.......................................................................................96
7.3.2.1.7 Impact of Propagation Delay Difference on Measurements....................................................98
7.3.2.2 Mobility Enhancements for Non-Terrestrial Networks.................................................................98
7.3.2.2.1 Enhancements to Measurement Configuration/Reporting.......................................................98
7.3.2.2.2 Conditional Handover..............................................................................................................98
7.3.2.2.3 Mobility Configuration..........................................................................................................100

3GPP
Release 16 5 3GPP TR 38.821 V16.0.0 (2019-12)

7.3.2.3 Connected mode mobility for feeder link switch for LEO NTN [18].........................................100
7.3.2.4 Connected mode mobility assumptions.......................................................................................100
7.3.3 Paging issue.......................................................................................................................................100
7.3.3.1 Paging Capacity...........................................................................................................................100
7.3.3.1.1 Paging capacity of non-multibeam cell..................................................................................101
7.3.3.1.2 Example of calculation...........................................................................................................101
7.3.4 Radio Link Monitoring......................................................................................................................103
7.3.5 PLMN identities deployment............................................................................................................103
7.3.6 Ephemeris Data for NTN...................................................................................................................103
7.3.6.1 Representation of Complete Ephemeris Data..............................................................................103
7.3.6.2 Provision and Use of Ephemeris Data.........................................................................................104
7.3.6.3 Updating Stored Ephemeris Data................................................................................................105
7.4 Earth fixed cells vs Earth moving cells...................................................................................................105
8 Issues and related solutions for NG-RAN architecture and interface protocols...........................106
8.1 Tracking area management.....................................................................................................................106
8.1.1 NTN cells are fixed w.r.t the ground.................................................................................................106
8.1.2 NTN cells are moving w.r.t the ground.............................................................................................106
8.1.2.1 Tracking Area defined on satellite...............................................................................................107
8.1.2.2 Tracking Area defined on earth...................................................................................................107
8.2 Registration Update and Paging Handling..............................................................................................107
8.2.1 Option 1: UE is capable to determine its location.............................................................................108
8.2.1.1 Mapping of UE location to gNB list in the AMF........................................................................108
8.2.2 Option 2: UE is not capable to determine its location.......................................................................109
8.2.2.1 Solution 1: Timing window based Registration update and paging............................................109
8.2.2.2 Solution 2: UE assisted TA list report/registration and paging...................................................110
8.2.2.3 Solution 3: Multi-Tracking Area ID based Registration update and paging...............................111
8.2.2.4 Solution 4: UE location determined by NTN based NG-RAN....................................................112
8.3 Connected mode mobility.......................................................................................................................113
8.3.1 Architecture Classification................................................................................................................113
8.3.2 Intra-gNB Mobility ("Monolithic gNB")..........................................................................................114
8.3.3 Intra-DU Mobility.............................................................................................................................114
8.3.4 Intra-gNB/Inter-DU Mobility............................................................................................................114
8.3.5 Inter-gNB Mobility............................................................................................................................114
8.3.5.1 Xn Mobility..................................................................................................................................114
8.3.5.2 Mobility through the 5GC............................................................................................................114
8.3.6 Mobility due to interface change.......................................................................................................115
8.3.6.1 Architecture option with gNB on board satellite.........................................................................115
8.3.6.2 Architecture option with gNB-DU on board satellite..................................................................115
8.3.7 Summary............................................................................................................................................116
8.4 Transport aspects.....................................................................................................................................117
8.4.1 Characteristics of transport links in NTN..........................................................................................117
8.4.1.1 Characteristics of SRI on the feeder link.....................................................................................117
8.4.1.2 Characteristics of Inter Satellite link...........................................................................................118
8.4.1.3 Characteristics of NTN GW........................................................................................................118
8.4.1.4 Ephemeris....................................................................................................................................118
8.4.2 Transporting F1 over the SRI............................................................................................................118
8.4.3 Applicability of Xn to NTNs.............................................................................................................119
8.4.3.1 List of Current Xn Functions.......................................................................................................119
8.4.3.2 Inter-Satellite Xn..........................................................................................................................119
8.4.3.3 On-ground NTN-terrestrial Xn....................................................................................................119
8.4.3.4 Transporting Xn over SRI............................................................................................................119
8.5 Network Identities Handling...................................................................................................................120
8.5.1 General..............................................................................................................................................120
8.5.2 GEO based NTN (Scenario A and B)................................................................................................120
8.5.3 Non-GEO based NTN (Scenario C and D).......................................................................................120
8.5.3.1 Stationary Identifiers on ground..................................................................................................120
8.5.3.2 Moving Identifiers on ground......................................................................................................120
8.5.3.3 Possible Implications on Neighbour Relationships.....................................................................121
8.5.3.4 Possible PCI Conflicts.................................................................................................................121
8.6 User Location..........................................................................................................................................121
8.7 Feeder link switch over...........................................................................................................................122

3GPP
Release 16 6 3GPP TR 38.821 V16.0.0 (2019-12)

8.7.1 Principles...........................................................................................................................................122
8.7.1.1 Transparent Satellite....................................................................................................................122
8.7.1.1.1 Transparent LEO, Architecture Option 1, different gNBs.....................................................122
8.7.1.1.2 Transparent LEO NTN, Architecture Option 1, same gNB...................................................124
8.7.1.2 Regenerative Satellite, Split gNB................................................................................................124
8.7.1.3 Regenerative Satellite, with full gNB on board, Architecture Options 3-5.................................125
8.7.1.3.1 Regenerative LEO NTN with one gNB-DU as payload, Architecture Options 3-5..............126
8.7.1.3.2 Regenerative LEO NTN with two gNBs, or gNB-DUs as payload, Architecture Options 3-5127
8.7.2 Procedures.........................................................................................................................................127
8.7.2.1 Transparent payload case.............................................................................................................127
8.7.2.2 Regenerative payload case (gNB on board)................................................................................128
8.7.2.3 Regenerative payload case (gNB split)........................................................................................129
8.8 Operations & Maintenance (O&M)........................................................................................................130
9 Recommendations on the way forward.........................................................................................130
9.1 Recommendations from RAN1...............................................................................................................130
9.2 Recommendations from RAN2...............................................................................................................131
9.3 Recommendations from RAN3...............................................................................................................132
9.4 Other assumptions...................................................................................................................................133

Annex A: Satellite ephemeris.......................................................................................................134

A.1 Key parameters..............................................................................................................................134
Annex B: KPI and evaluation assumptions................................................................................136
B.1 Key Performance Indicators..........................................................................................................136
B.2 Performance targets for evaluation purposes................................................................................136
Annex C: Regulatory Aspects......................................................................................................138
Annex D (Informative): Change history..................................................................................................140

3GPP
Release 16 7 3GPP TR 38.821 V16.0.0 (2019-12)

Foreword
This Technical Report has been produced by the 3rd Generation Partnership Project (3GPP).

The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:

Version x.y.z

where:

x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

3 or greater indicates TSG approved document under change control.

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.

z the third digit is incremented when editorial only changes have been incorporated in the document.

In the present document, modal verbs have the following meanings:

shall indicates a mandatory requirement to do something

shall not indicates an interdiction (prohibition) to do something

The constructions "shall" and "shall not" are confined to the context of normative provisions, and do not appear in
Technical Reports.

The constructions "must" and "must not" are not used as substitutes for "shall" and "shall not". Their use is avoided
insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced,
non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a
referenced document.

should indicates a recommendation to do something

should not indicates a recommendation not to do something

may indicates permission to do something

need not indicates permission not to do something

The construction "may not" is ambiguous and is not used in normative elements. The unambiguous constructions
"might not" or "shall not" are used instead, depending upon the meaning intended.

can indicates that something is possible

cannot indicates that something is impossible

The constructions "can" and "cannot" are not substitutes for "may" and "need not".

will indicates that something is certain or expected to happen as a result of action taken by an agency
the behaviour of which is outside the scope of the present document

will not indicates that something is certain or expected not to happen as a result of action taken by an
agency the behaviour of which is outside the scope of the present document

might indicates a likelihood that something will happen as a result of action taken by some agency the
behaviour of which is outside the scope of the present document

3GPP
Release 16 8 3GPP TR 38.821 V16.0.0 (2019-12)

might not indicates a likelihood that something will not happen as a result of action taken by some agency
the behaviour of which is outside the scope of the present document

In addition:

is (or any other verb in the indicative mood) indicates a statement of fact

is not (or any other negative verb in the indicative mood) indicates a statement of fact

The constructions "is" and "is not" do not indicate requirements.

3GPP
Release 16 9 3GPP TR 38.821 V16.0.0 (2019-12)

1 Scope

The objectives for this document are, based on the outcomes of the TR 38.811 [2], to study a set of necessary
features/adaptations enabling the operation of the New Radio (NR) protocol in non-terrestrial networks for 3GPP
Release 16 with a priority on satellite access. Access network based on Unmanned Aerial System (UAS) including High
Altitude Platform Station (HAPS) could be considered as a special case of non-terrestrial access with lower
delay/Doppler value and variation rate.

The objectives for the study are the following

● Consolidation of potential impacts on the physical layer and definition of related solutions if needed

● Performance assessment of NR in selected deployment scenarios (LEO based satellite access, GEO based
satellite access) through link level (Radio link) and system level (cell) simulations

● Study and define related solutions if needed on NR related Layer 2 and 3

● Study and define related solutions if needed on RAN architecture and related interface protocols

NOTE: As far as architecture issues are concerned, this TR supersedes TR 38.811 [2]

2 References
The following documents contain provisions, which, through reference in this text, constitute provisions of the present
document.

- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.

- For a specific reference, subsequent revisions do not apply.

- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications"

[2] 3GPP TR 38.811 v15.2.0: "Study on New Radio (NR) to support non-terrestrial networks (Release
15)"

[3] 3GPP TS 38.401: "NG-RAN; Architecture description (Release 15)"

[4] 3GPP TR 38.874: "NR-Study on IAB (Integrated Access and Backhaul)"

[5] 3GPP TS 37.340: "NR; Multi-connectivity; Overall description"

[6] RP-181370: "Study on solutions evaluation for NR to support Non Terrestrial Network"

[7] 3GPP TS 23.501 V15.0.0: "System Architecture for the 5G System"

[8] R3-184403, NR-NTN: "Paging in NGSO Satellite Systems"

[9] 3GPP TS 37.324 V15.0.0: "E-UTRA and NR; Service Data Adaptation Protocol (SDAP)
specification (Release 15)"

[10] AIAA 2006-6753: "Revisiting Spacetrack Report #3 , Models for Propagation of NORAD
Element Sets", David A. Vallado, Paul Crawford, Richard Hujsak, T. S. Kelso, presented at the
AIAA/AAS Astrodynamics Specialist Conference, Keystone, CO, 2006 August 21–24, 2006

3GPP
Release 16 10 3GPP TR 38.821 V16.0.0 (2019-12)

[11] 3GPP TS 38.420: "NG-RAN; Xn general aspects and principles"

[12] 3GPP TS 22.261 "Service requirements for the 5G system; Stage 1 (Release 16)"

[13] 3GPP TR 38.913 "Study on Scenarios and Requirements for Next Generation Access
Technologies; (Release 15)"

[14] 3GPP TR 45.820 "Cellular system support for ultra-low complexity and low throughput Internet of
Things (CIoT) (Release 13)"

[15] R2-1901404 "IoT Device Density Models for Various Environments", Vodafone, submitted to
RAN2#105

[16] R2-1904297 "Tracking Areas Considerations for Non Terrestrial Networks (NTN)", Vodafone,
Submitted to RAN2 #105 bis

[17] R2-1905302, "Tracking area management and update for NTN LEO", Ericsson, ZTE, Thales,
Xian, China, 8-12 April 2019

[18] R2-1905301, "Feeder link switch for transparent and regenerative LEO", Ericsson, InterDigital,
Thales, Xian, China, 8-12 April 2019

[19] Radar System Engineering, Lecture 9, Antennas, Robert M. O'Donnel, IEEE New Hampshire
Section

[20] R1-1913404 "System Level Calibration Results for NTN on DL transmissions", Thales, submitted
to RAN1#99

[21] R1-1913405 "System Level Calibration Results for NTN on UL transmissions", Thales, submitted
to RAN1#99

[22] R1-1911858 "Discussion on performance evaluation for NTN", Huawei, HiSilicon, submitted to
RAN1#99

[23] R1-1913244 "Calibration Results and first System-Level Simulations for NTN", Nomor Research
GmbH, submitted to RAN1#99

[24] R1-1913351 "Link Budget Results for NTN", Thales, submitted to RAN1#99

[25] R1-1904765 "Considerations on the simulation assumption and methodology for NTN", ZTE,
submitted to RAN1#96bis

[26] R2-1814877 "Considerations on NTN deployment scenarios", Nokia, Nokia Shanghai Bell,
submitted to RAN2#103bis

[27] R1-1912610 "System simulation results and link budget for NTN", ZTE, submitted to RAN1#99

[28] R1-1909693 "Simulation Assumptions for Multi Satellite Evaluation", Nokia, Nokia Shanghai
Bell, submitted to RAN1#98

[29] R1-1912123 "Physical layer control procedure in NR-NTN", MediaTek Inc., submitted to
RAN1#99

[30] R1-1912347 "Discussion on physical layer control procedures", Sony, submitted to RAN1#99

[31] R1-1912469 "Physical layer control procedures in NTN", Samsung, submitted to RAN1#99

[32] R1-1912724 "On physical layer control procedures for NTN", Ericsson, submitted to RAN1#99

[33] R1-1913016 "Considerations on Physical Layer Control Procedure in NTN", Nokia, Nokia
Shanghai Bell, submitted to RAN1#99

[34] R1-1912611 "Discussion on the physical control procedure for NTN", ZTE, submitted to
RAN1#99

[35] R1-1911859 "Discussion on physical layer control procedures for NTN", Huawei, HiSilicon,
submitted to RAN1#99

3GPP
Release 16 11 3GPP TR 38.821 V16.0.0 (2019-12)

[36] R1-1907277 "Physical Layer Procedures for NTN", Qualcomm Incorporated, submitted to
RAN1#97

[37] R1-1907028 "On physical layer control procedures for NTN", Panasonic, submitted to RAN1#97

[38] R1-1906324 "Physical layer procedure enhancement for NTN", CATT, submitted for RAN1#97

[39] R1-1906871 "Discussion on the physical control procedure for NTN", ZTE, submitted to
RAN1#97

[40] R1-1912902 "Discussion on beam management and polarization for NTN", Panasonic, submitted
to RAN1#99

[41] R1-1912955 "Physical Layer Procedures for NTN", Qualcomm Incorporated, submitted to
RAN1#99

[42] R1-1912164 "Physical layer control procedure enhancement", CATT, submitted to RAN1#99

[43] R1-1908049 "Discussion on Doppler compensation, timing advance and RACH for NTN",
Huawei, HiSilicon, CAICT, submitted to RAN1#98

[44] R1-1908591 "PRACH design and timing advance", CATT, CAICT, submitted to RAN1#98

[45] R1-1909107 "On frequency compensation, uplink timing and random access in NTN", Ericsson,
submitted to RAN1#98

[46] R1-1909400 "Discussion on the TA and PRACH for NTN", ZTE, submitted to RAN1#98

[47] R1-1910064 "Discussion on Doppler compensation, timing advance and RACH for NTN",
Huawei, HiSilicon, submitted to RAN1#98bis

[48] R1-1909479 "Summary of 7.2.5.3 on UL timing and PRACH for NTN", ZTE, submitted to
RAN1#98

[49] R1-1911284 "Summary of 7.2.5.3 on UL timing and PRACH for NTN", ZTE, submitted to
RAN1#98bis

[50] R1-1913312 "Summary of 7.2.5.3 on UL timing and PRACH for NTN", ZTE, submitted to
RAN1#99

[51] R1-1913017 "Doppler Compensation, Uplink Timing Advance and Random Access in NTN",
Nokia, Nokia Shanghai Bell, submitted to RAN1#99

[52] R1-1912903, "Timing advance and PRACH design for NTN", Panasonic, submitted to RAN1#99

[53] R1-1912212 "On PRACH sequence for NTN", Intel Corporation, submitted to RAN1#99

[54] R1-1912612 "Discussion on the TA and PRACH for NTN", ZTE, submitted to RAN1#99

[55] R1-1912725 "On NTN synchronization, random access, and timing advance", Ericsson, submitted
to RAN1#99

[56] R1-1912956 "RACH Procedure and UL Timing Control for NTN", Qualcomm Incorporated,
submitted to RAN1#99

[57] R1-1912124 "PRACH design for NTN scenario", MediaTek Inc., submitted to RAN1#99

[58] R1-1911860 "Discussion on Doppler compensation, timing advance and RACH for NTN",
Huawei, HiSilicon, submitted to RAN1#99

[59] R1-1912165 "PRACH design and UL timing management", CATT, submitted to RAN1#99

[60] R1-1912349 "Discussion on delay-tolerant HARQ for NTN", Sony, submitted to RAN1#99

[61] R1-1913019 "Considerations on HARQ in NTN", Nokia, Nokia Shanghai Bell, submitted to
RAN1#99

3GPP
Release 16 12 3GPP TR 38.821 V16.0.0 (2019-12)

[62] R1-1912957 "Delay-Tolerant Retransmission Mechanisms for NTN", Qualcomm Incorporated,

submitted to RAN1#99

[63] R1-1912641 "Discussion on more delay-tolerant re-transmission mechanisms for NTN", ETRI,
submitted to RAN1#99

[64] R1-1912125 "Delay-tolerant re-transmission mechanisms in NR-NTN", MediaTek Inc., submitted

to RAN1#99

[65] R1-1912166 "Further consideration on HARQ operation", CATT, submitted to RAN1#99

[66] R1-1912471 "HARQ Procedure in NTN", Samsung, submitted to RAN1#99

[67] R1-1912213, "Discussion on HARQ for NTN", Intel Corporation, submitted to RAN1#99

[68] R1-1912665, "Delay-tolerant HARQ operation for NTN", OPPO, submitted to RAN1#99

[69] R1-1912904, "Discussion on HARQ for NTN", Panasonic, submitted to RAN1#99

[70] R1-1913238, "Discussion on the delay-tolerant HARQ operation for NTN", ZTE, submitted to
RAN1#99

[71] R1-1911861, "Discussion on HARQ for NTN", Huawei, HiSilicon, submitted to RAN1#99

[72] R1-1912726, "On more delay-tolerant re-transmission mechanisms for NTN", Ericsson, submitted
to RAN1#99

[73] R1-1913134, "On more delay tolerant retransmission mechanisms for NTN", Nomor Research
GmbH, submitted to RAN1#99

[74] R2-1916351 "[108#06][NTN] Earth fixed vs. Earth moving cells in NTN LEO", Thales

[75] 3GPP TS 38.321 "NR; Medium Access Control (MAC) protocol specification"

[76] 3GPP TS 38.331 "NR; Radio Resource Control (RRC); Protocol specification"

3 Definitions of terms, symbols and abbreviations

3.1 Terms
For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1].

Availability: % of time during which the RAN is available for the targeted communication. Unavailable
communication for shorter period than [Y] ms shall not be counted. The RAN may contain several access network
components among which an NTN to achieve multi-connectivity or link aggregation.

Feeder link: Wireless link between NTN Gateway and satellite

Geostationary Earth orbit: Circular orbit at 35,786 km above the Earth's equator and following the direction of the
Earth's rotation. An object in such an orbit has an orbital period equal to the Earth's rotational period and thus appears
motionless, at a fixed position in the sky, to ground observers.

Low Earth Orbit: Orbit around the Earth with an altitude between 300 km, and 1500 km.

Medium Earth Orbit: region of space around the Earth above low Earth orbit and below geostationary Earth Orbit.

Minimum Elevation angle: minimum angle under which the satellite or UAS platform can be seen by a terminal.

Mobile Services: a radio-communication service between mobile and land stations, or between mobile stations

3GPP
Release 16 13 3GPP TR 38.821 V16.0.0 (2019-12)

Mobile Satellite Services: A radio-communication service between mobile earth stations and one or more space
stations, or between space stations used by this service; or between mobile earth stations by means of one or more space
stations

Non-Geostationary Satellites: Satellites (LEO and MEO) orbiting around the Earth with a period that varies
approximately between 1.5 hour and 10 hours. It is necessary to have a constellation of several Non-Geostationary
satellites associated with handover mechanisms to ensure a service continuity.

Non-terrestrial networks: Networks, or segments of networks, using an airborne or space-borne vehicle to embark a
transmission equipment relay node or base station.

NTN-gateway: an earth station or gateway is located at the surface of Earth, and providing sufficient RF power and RF
sensitivity for accessing to the satellite (resp. HAPS). NTN Gateway is a transport network layer (TNL) node.

On Board processing: digital processing carried out on uplink RF signals aboard a satellite or an aerial.

On board NTN gNB: gNB implemented in the regenerative payload on board a satellite (respectively HAPS).

On ground NTN gNB: gNB of a transparent satellite (respectively HAPS) payload implemented on ground.

One-way latency: time required to propagate through a telecommunication system from a terminal to the public data
network or from the public data network to the terminal. This is especially used for voice and video conference
applications.

Regenerative payload: payload that transforms and amplifies an uplink RF signal before transmitting it on the
downlink. The transformation of the signal refers to digital processing that may include demodulation, decoding, re-
encoding, re-modulation and/or filtering.

Round Trip Delay: time required for a signal to travel from a terminal to the sat-gateway or from the sat-gateway to
the terminal and back. This is especially used for web-based applications.

Satellite: a space-borne vehicle embarking a bent pipe payload or a regenerative payload telecommunication
transmitter, placed into Low-Earth Orbit (LEO), Medium-Earth Orbit (MEO), or Geostationary Earth Orbit (GEO).

Satellite beam: A beam generated by an antenna on-board a satellite

Service link: Radio link between satellite and UE

Transparent payload: payload that changes the frequency carrier of the uplink RF signal, filters and amplifies it before
transmitting it on the downlink

Unmanned Aircraft Systems: Systems encompassing Tethered UAS (TUA), Lighter Than Air UAS (LTA), Heavier
Than Air UAS (HTA), all operating in altitudes typically between 8 and 50 km including High Altitude Platforms
(HAPs)

User Connectivity: capability to establish and maintain data / voice / video transfer between networks and Terminals

User Throughput: data rate provided to a terminal

3.2 Symbols
Void

3.3 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
TR 21.905 [1].

ECEF Earth-Centered, Earth-Fixed

EIRP Equivalent Isotropic Radiated Power
FAR False Alarm Rate

3GPP
Release 16 14 3GPP TR 38.821 V16.0.0 (2019-12)

FRF Frequency Reuse Factor

FSS Fixed Satellite Services
GEO Geostationary Earth Orbiting
gNB next Generation Node B
GW Gateway
HAPS High Altitude Platform Station
HEO Highly Elliptical Orbiting
ISL Inter-Satellite Links
LEO Low Earth Orbiting
Mbps Mega bit per second
MEO Medium Earth Orbiting
MS Mobile Services
MSS Mobile Satellite Services
NAS-MM Non-Access Stratum Mobility Management
NAS-SM Non-Access Stratum Session Management
NGEO Non-Geostationary Earth Orbiting
NTN Non-Terrestrial Network
RAN Radio Access Network
RTD Round Trip Delay
SNR Signal-to-Noise Ratio
SRI Satellite Radio Interface
TLE Two-Line Element
Rx Receiver
UAS Unmanned Aircraft System
UE User Equipment

3GPP
Release 16 15 3GPP TR 38.821 V16.0.0 (2019-12)

4 Non-Terrestrial Networks overview and scenarios

4.1 Non-Terrestrial Networks overview

A non-terrestrial network refers to a network, or segment of networks using RF resources on board a satellite (or UAS
platform).

The typical scenario of a non-terrestrial network providing access to user equipment is depicted below:

Satellite
(or UAS platform)

Feeder link
Service
link Data
network

Gateway

User
Equipments Beam foot
print

Field of view of the satellite (or UAS platform)

Figure 4.1-1: Non-terrestrial network typical scenario based on transparent payload

Satellite Satellite
(or UAS platform) (or UAS platform)
ISL

Feeder
link
Feeder link
Service (mandatory if no ISL)
link Data
network

Gateway

User
Equipments Beam foot
print

Field of view of the satellite (or UAS platform)

Figure 4.1-2: Non-terrestrial network typical scenario based on regenerative payload

Non-Terrestrial Network typically features the following elements:

- One or several sat-gateways that connect the Non-Terrestrial Network to a public data network

3GPP
Release 16 16 3GPP TR 38.821 V16.0.0 (2019-12)

- a GEO satellite is fed by one or several sat-gateways which are deployed across the satellite targeted
coverage (e.g. regional or even continental coverage). We assume that UE in a cell are served by only one
sat-gateway

- A Non-GEO satellite served successively by one or several sat-gateways at a time. The system ensures
service and feeder link continuity between the successive serving sat-gateways with sufficient time duration
to proceed with mobility anchoring and hand-over

- A Feeder link or radio link between a sat-gateway and the satellite (or UAS platform)

- A service link or radio link between the user equipment and the satellite (or UAS platform).

- A satellite (or UAS platform) which may implement either a transparent or a regenerative (with on board
processing) payload. The satellite (or UAS platform) generate beams typically generate several beams over a
given service area bounded by its field of view. The footprints of the beams are typically of elliptic shape. The
field of view of a satellites (or UAS platforms) depends on the on board antenna diagram and min elevation
angle.

- A transparent payload: Radio Frequency filtering, Frequency conversion and amplification. Hence, the
waveform signal repeated by the payload is un-changed;

- A regenerative payload: Radio Frequency filtering, Frequency conversion and amplification as well as
demodulation/decoding, switch and/or routing, coding/modulation. This is effectively equivalent to having all
or part of base station functions (e.g. gNB) on board the satellite (or UAS platform).

- Inter-satellite links (ISL) optionally in case of a constellation of satellites. This will require regenerative
payloads on board the satellites. ISL may operate in RF frequency or optical bands.

- User Equipment are served by the satellite (or UAS platform) within the targeted service area.

There may be different types of satellites (or UAS platforms) listed here under:

Table 4.1-1: Types of NTN platforms

Typical beam
Platforms Altitude range Orbit
footprint size
Low-Earth Orbit (LEO)
300 – 1500 km 100 – 1000 km
satellite
Circular around the earth
Medium-Earth Orbit
7000 – 25000 km 100 – 1000 km
(MEO) satellite
Geostationary Earth Orbit
35 786 km notional station keeping position fixed in 200 – 3500 km
(GEO) satellite
terms of elevation/azimuth with respect
UAS platform (including
8 – 50 km (20 km for HAPS) to a given earth point 5 - 200 km
HAPS)
High Elliptical Orbit
400 – 50000 km Elliptical around the earth 200 – 3500 km
(HEO) satellite

Typically

● GEO satellite and UAS are used to provide continental, regional or local service.

● a constellation of LEO and MEO is used to provide services in both Northern and Southern hemispheres. In
some case, the constellation can even provide global coverage including polar regions. For the later, this requires
appropriate orbit inclination, sufficient beams generated and inter-satellite links.

HEO satellite systems are not considered in this document.

4.2 Non-Terrestrial Networks reference scenarios

We shall consider in this document non-terrestrial networks providing access to user equipment in six reference
scenarios including

3GPP
Release 16 17 3GPP TR 38.821 V16.0.0 (2019-12)

● Circular orbiting and notional station keeping platforms.

● Highest RTD constraint

● Highest Doppler constraint

● A transparent and a regenerative payload

● One ISL case and one without ISL. Regenerative payload is mandatory in the case of inter-satellite links.

● Fixed or steerable beams resulting respectively in moving or fixed beam foot print on the ground

Six scenarios are considered as depicted in Table 4.2-1 and are detailed in Table 4.2-2.

Table 4.2-1: Reference scenarios

Transparent Regenerative
satellite satellite
GEO based non-terrestrial access network Scenario A Scenario B
LEO based non-terrestrial access
network: Scenario C1 Scenario D1
steerable beams
LEO based non-terrestrial access
network: Scenario C2 Scenario D2
the beams move with the satellite

3GPP
Release 16 18 3GPP TR 38.821 V16.0.0 (2019-12)

Table 4.2-2: Reference scenario parameters

3GPP
Release 16 19 3GPP TR 38.821 V16.0.0 (2019-12)

GEO based non-terrestrial access network LEO based non-terrestrial access

Scenarios
(Scenario A and B) network (Scenario C & D)
notional station keeping position fixed in
Orbit type terms of elevation/azimuth with respect to a circular orbiting around the earth
given earth point
600 km
Altitude 35,786 km
1,200 km
<6 GHz (e.g. 2 GHz)
Spectrum (service link)
>6 GHz (e.g. DL 20 GHz, UL 30 GHz)
Max channel bandwidth 30 MHz for band < 6 GHz
capability (service link) 1 GHz for band > 6 GHz
Scenario C: Transparent (including
Scenario A: Transparent (including radio
radio frequency function only)
frequency function only)
Payload Scenario D: Regenerative
Scenario B: regenerative (including all or
(including all or part of RAN
part of RAN functions)
functions)
Scenario C: No
Inter-Satellite link No Scenario D: Yes/No (Both cases
are possible.)
Scenario C1: Yes (steerable
beams), see note 1
Scenario C2: No (the beams move
with the satellite)
Earth-fixed beams Yes
Scenario D 1: Yes (steerable
beams), see note 1
Scenario D 2: No (the beams move
with the satellite)
Max beam foot print size (edge
to edge) regardless of the 3500 km (Note 5) 1000 km
elevation angle
Min Elevation angle for both sat- 10° for service link and 10° for
10° for service link and 10° for feeder link
gateway and user equipment feeder link
Max distance between satellite
1,932 km (600 km altitude)
and user equipment at min 40,581 km
3,131 km (1,200 km altitude)
elevation angle
Scenario C: (transparent payload:
service and feeder links)
25.77 ms (600km)
Scenario A: 541.46 ms (service and feeder 41.77 ms (1200km)
Max Round Trip Delay
links)
(propagation delay only)
Scenario B: 270.73 ms (service link only) Scenario D: (regenerative payload:
service link only)
12.89 ms (600km)
20.89 ms (1200km)
Max differential delay within a 3.12 ms and 3.18 ms for
10.3 ms
cell (Note 6) respectively 600km and 1200km
Max Doppler shift (earth fixed 24 ppm (600km)
0.93 ppm
user equipment) 21ppm(1200km)
Max Doppler shift variation 0.27ppm/s (600km)
0.000 045 ppm/s
(earth fixed user equipment) 0.13ppm/s(1200km)
User equipment motion on the 500 km/h (e.g. high speed train)
1200 km/h (e.g. aircraft)
earth Possibly 1200 km/h (e.g. aircraft)
Omnidirectional antenna (linear polarisation), assuming 0 dBi
User equipment antenna types Directive antenna (up to 60 cm equivalent aperture diameter in circular
polarisation)
Omnidirectional antenna: UE power class 3 with up to 200 mW
User equipment Tx power
Directive antenna: up to 20 W
Omnidirectional antenna: 7 dB
User equipment Noise figure
Directive antenna: 1.2 dB
Service link 3GPP defined New Radio
3GPP or non-3GPP defined Radio
Feeder link 3GPP or non-3GPP defined Radio interface
interface

3GPP
Release 16 20 3GPP TR 38.821 V16.0.0 (2019-12)

NOTE 1: Each satellite has the capability to steer beams towards fixed points on earth using beamforming
techniques. This is applicable for a period of time corresponding to the visibility time of the satellite
NOTE 2: Max delay variation within a beam (earth fixed user equipment) is calculated based on Min Elevation angle
for both gateway and user equipment
NOTE 3: Max differential delay within a beam is calculated based on Max beam foot print diameter at nadir
NOTE 4: Speed of light used for delay calculation is 299792458 m/s.
NOTE 5: The Maximum beam foot print size for GEO is based on current state of the art GEO High Throughput
systems, assuming either spot beams at the edge of coverage (low elevation).
NOTE 6: The maximum differential delay at cell level has been computed considering the one at beam level for largest
beam size. It does not preclude that cell may include more than one beam when beam size are small or
medium size. However the cumulated differential delay of all beams within a cell will not exceed the
maximum differential delay at cell level in the table above.

The NTN study results apply to GEO scenarios as well as all NGSO scenarios with circular orbit at altitude greater than
or equal to 600 km.

5 NTN-based NG-RAN Architectures

The study has been carried out minimizing the need for new interfaces and protocols in the NG-RAN to support non-
terrestrial networks.

5.1 Transparent satellite based NG-RAN architecture

5.1.1 Overview
The satellite payload implements frequency conversion and a Radio Frequency amplifier in both up link and down link
direction. It corresponds to an analogue RF repeater.

Hence the satellite repeats the NR-Uu radio interface from the feeder link (between the NTN gateway and the satellite)
to the service link (between the satellite and the UE) and vice versa.

The Satellite Radio Interface (SRI) on the feeder link is the NR-Uu. In other words, the satellite does not terminate NR-
Uu.

The NTN GW supports all necessary functions to forward the signal of NR-Uu interface.

Different transparent satellites may be connected to the same gNB on the ground.

Figure 5.1-1: Networking-RAN architecture with transparent satellite

Note: Whilst several gNBs may access a single satellite payload, the description has been simplified to a unique gNB
accessing the satellite payload, without loss of generality.

3GPP
Release 16 21 3GPP TR 38.821 V16.0.0 (2019-12)

5.1.2 Detailed description of the architecture

The architecture of a transparent-satellite based NG-RAN is depicted in the following figure. The mapping to QoS
flows is also highlighted.

Figure 5.1-2: Transparent-satellite based NG-RAN with mapping to QoS flows

UE has access to the 5G system via a 3GPP NR based radio interface.

The user plane protocol stack is described hereafter.

Figure 5.1-3: User plane Protocol stack (Transparent satellite)

3GPP
Release 16 22 3GPP TR 38.821 V16.0.0 (2019-12)

RF processing & Frequency Switching

The user data is transported between the UE and the 5GC, as usual, but via the NTN Gateway.

The control plane protocol stack is described hereafter.

Figure 5.1-4: Control plane Protocol stack (Transparent satellite)

RF processing & Frequency Switching

The NAS (NAS-SM and NAS-MM) signalling from the UE and the NG-AP signalling from the gNB are transported
toward the 5GC and vice versa.

5.1.3 NG-RAN impacts

There is no need to modify the NG-RAN architecture to support transparent satellite access.

NR-Uu timers may have to be extended to cope with the long delay of the feeder link and service link.

In the context of a LEO scenario with ISL, the delay to be considered shall encompass at least the feeder link (SRI) and
one or several ISLs.

Both CP and UP protocol are terminated on the ground.

● With respect to CP, this scenario does not pose any particular issues but the need to adapt to the much longer
roundtrip times of the Uu. This can be addressed by implementation

● Concerning UP, apart from issues arising from the longer roundtrip time for UP packets, the UP protocol itself is
unaffected. The longer delay on the Uu interface will however require more buffering for the UP packets into the
gNB.

3GPP
Release 16 23 3GPP TR 38.821 V16.0.0 (2019-12)

5.2 Regenerative satellite based NG-RAN architectures

5.2.1 gNB processed payload

5.2.1.1 Overview
The NG-RAN logical architecture as described in TS 38.401 is used as baseline for NTN scenarios.

The satellite payload implements regeneration of the signals received from Earth.

● NR-Uu radio interface on the service link between the UE and the satellite

● Satellite Radio Interface (SRI) on the feeder link between the NTN gateway and the satellite.

SRI (Satellite Radio Interface) is a transport link between NTN GW and satellite.

Figure 5.2.1-1: Regenerative satellite without ISL, gNB processed payload

NOTE: The satellite may embark additional traffic routing functions that are out of RAN scope.

The satellite payload also provides Inter-Satellite Links (ISL) between satellites

ISL (Inter-Satellite Links) is a transport link between satellites. ISL may be a radio interface or an optical interface that
may be 3GPP or non 3GPP defined but this is out of the study item scope.

The NTN GW is a Transport Network Layer node, and supports all necessary transport protocols.

3GPP
Release 16 24 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 5.2.1-2: Regenerative satellite with ISL, gNB processed payload

The figure above illustrates that UE served by a gNB on board a satellite could access the 5GCN via ISL.

The gNB on board different satellites may be connected to the same 5GCN on the ground.

If the satellite hosts more than one gNB, the same SRI will transport all the corresponding NG interface instances.

5.2.1.2 Detailed description of the architecture

The architecture of a regenerative-satellite based NG-RAN is depicted on the following figure. The mapping to QoS
flows is also highlighted.

Figure 5.2.1-3: Regenerative satellite based NG-RAN architecture (gNB on board) with QoS flows

The UE user plane protocol stack for a PDU session is described hereafter.

3GPP
Release 16 25 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 5.2.1-4: NG-RAN protocol architecture for regenerative satellite (gNB on board): User Plane

The Protocol stack of the Satellite Radio Interface (SRI) is used to transport the UE user plane between satellite and
NTN-Gateway.

The User PDUs are transported over GTP-U tunnels, as usual, between the 5GC and the on-board gNB, but via the
NTN Gateway.

The UE control plane protocol stack for a PDU session is described hereafter.

Figure 5.2.1-5: NG-RAN protocol architecture for regenerative satellite (gNB on board): Control Plane

The NG-AP is transported over SCTP, between the 5GC and the on board gNB, as usual, but via the NTN Gateway.

The NAS protocol is also transported by the NG-AP protocol, between the 5GC and the on board gNB, via the NTN
Gateway.

5.2.1.3 NG-RAN impacts

3GPP
Release 16 26 3GPP TR 38.821 V16.0.0 (2019-12)

NG Application Protocol timers may have to be extended to cope with the long delay of the feeder link.

NG can experience longer latency (up to several hundreds of ms in case of a GEO satellite) than in terrestrial networks,
and this will affect both CP and UP; this can be addressed by implementation.

In the context of a LEO scenario with ISL, the delay to be considered shall encompass at least the feeder link (SRI) and
one or several ISLs.

5.2.2 gNB-DU processed payload

5.2.2.1 Overview
The NG-RAN logical architecture with CU/DU split as described in TS 38.401 is used as baseline for NTN scenarios.

The satellite payload implements regeneration of the signals received from Earth.

● NR-Uu radio interface on the service link between the satellite and the UE

● Satellite Radio Interface (SRI) on the feeder link between the NTN gateway and the satellite. The SRI transports
the F1 protocol.

The satellite payload may provide inter-satellite links between satellites.

SRI (Satellite Radio Interface) are transport links; the logical interface F1 that they transport are 3GPP-specified.

The NTN GW is a Transport Network Layer node, and supports all necessary transport protocols.

DU on board different satellites may be connected to the same CU on ground.

If the satellite hosts more than one DU, the same SRI will transport all the corresponding F1 interface instances.

Figure 5.2.2-1: NG-RAN with a regenerative satellite based on gNB-DU

5.2.2.2 Detailed description of the architecture

The architecture of a regenerative-satellite based NG-RAN is depicted on the following figures. The mapping to QoS
flows is also highlighted.

The PDCP PDUs (Protocol Data Units) are transported by the SRI protocols stack.

3GPP
Release 16 27 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 5.2.2-2: Regenerative satellite based NG-RAN architecture (gNB-DU on board) with QoS flows

The UE user plane protocol stack for a PDU session is described hereafter.

Figure 5.2.2-3: NG-RAN protocol architecture for regenerative satellite (gNB-DU on board): User
Plane

The Protocol stack of the Satellite Radio Interface (SRI) is used to transport the UE user plane between satellite and
NTN-Gateway.

The User PDUs are transported over GTP-U tunnels between the 5GC and the gNB-CU.

The User PDUs are transported over GTP-U tunnels between the gNB-CU and the on board gNB-DU via the NTN
Gateway.

3GPP
Release 16 28 3GPP TR 38.821 V16.0.0 (2019-12)

The UE control plane protocol stack for a PDU session is described hereafter

Figure 5.2.2-4: NG-RAN protocol architecture for regenerative satellite (gNB-DU on board): Control
Plane

The NG-AP PDUs are transported over SCTP between the 5GC and the gNB-CU.

The RRC PDUs are transported over PDCP over the F1-C protocols stack between the gNB-CU and the on board gNB-
DU, via the NTN Gateway. The F1-C PDUs are transported over SCTP over IP. IP packets are transported over SRI
protocols stack, at the SRI and over any L2/L1 layers at gNB-CU – NTN Gateway interface.

The NAS protocols (NAS-MM, NAS-SM) are also transported by the NG-AP protocol, between the 5GC, gNB-CU and
the on board gNB-DU, via the NTN Gateway.

5.2.2.3 NG-RAN impacts

RRC and other Layer3 processing are terminated in the gNB-CU on ground, and are subject to stricter timing
constraints.

The use of this architecture option for LEO (Low Earth Orbit) systems or even for GEO (Geostationary Earth Orbit)
may impact current F1 implementation (e.g. timer extensions). Such impact for LEO will be much less significant than
for GEO.

In this architecture, all CP interfaces toward terrestrial NG-RAN nodes are terminated on the ground.

● With respect to CP, this scenario does not pose any particular issues apart from the fact that F1AP will need to
adapt to the much longer roundtrip times of the SRI.

● Concerning UP, the instance running over Xn is unaffected by the presence of the NTN, while the instance
running over F1 (transported over the SRI) will need to adapt to the much longer roundtrip times of the SRI.
This, in turn, will require more buffering for the UP packets into the gNB-CU.

5.2.3 gNB processed payload based on relay-like architectures (Optional)

How to apply the Integrated Access and Backhaul (IAB) proposed architecture configuration resulting from the IAB SI
reflected in the TR 38.874 document [4] is for further study.

3GPP
Release 16 29 3GPP TR 38.821 V16.0.0 (2019-12)

5.3 Multi connectivity involving NTN-based NG-RAN

5.3.1 Overview
This clause discusses multi connectivity [5], either for transparent or regenerative NTN-based NG-RAN, and in
combination or not with terrestrial-based NG-RAN (NR or EUTRA). The focus is on dual connectivity with
simultaneous use of two radio access.

This may apply to transparent satellites as well as regenerative satellites with gNB or gNB-DU function on board.

A number of service scenarios as described in TS 22.261 (e.g. user in residential homes, in vehicles, in high speed trains
or on board airplanes), would benefit from the combination of terrestrial and non-terrestrial access to meet the targeted
service performances in terms of data rate and/or reliability.

In underserved areas, the bandwidth provided by a terrestrial based access (e.g. LTE) may be limited at cell edge.
Adding a NTN based NG-RAN will be an enable to achieve the targeted experience data rate.

Under some scenarios such as high speed trains, the service area may not be fully homogeneous along the rail track and
multi connectivity involving NTN-based NG-RAN would enable to provide the targeted reliability.

Hence a UE may be connected and served simultaneously by at least:

● One NTN-based NG-RAN and one terrestrial-based access (NR or EUTRA)

● One NTN-based NG-RAN and another NTN-based NG-RAN

As for terrestrial access, connectivity combining can occur for either the uplink or the downlink or both.

The same gNB could serve NR cells via the terrestrial access network and via the satellite access network (e.g. with
transparent payload on board the satellite).

5.3.2 Architecture aspects

Multi connectivity involving transparent NTN-based NG-RAN

A User Equipment is connected to a 5GCN via simultaneously a transparent NTN-based NG-RAN and a cellular NG-
RAN. We assume that the NTN Gateway is located in the PLMN area of the cellular access network.

gNB

NR-Uu NR-Uu NG
NTN
Gateway 5G CN
Xn N6 Data
UE Network

NR-Uu
NG

gNB

Figure 5.3.2-1: Multi connectivity involving transparent NTN-based NG-RAN and cellular NG-RAN

Both gNB of the NTN-based NG-RAN or the gNB of the cellular NG-RAN could be elected as master node.

3GPP
Release 16 30 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 5.3.2-2: Radio Protocol Architecture for MCG, SCG and split bearers from a UE perspective in
MR-DC with 5GC

Another case to be considered, refers to the combination of two Transparent NTN-based NG-RANs either GEO or LEO
based or a combination of both. This is of interest to provide service to UEs in unserved areas. The LEO NTN-based
NG-RAN featuring relatively low latency can be used to support the delay sensitive traffic while the GEO NTN-based
NG-RAN would provide additional bandwidth to meet the targeted throughput requirements. This is depicted in the
figure below.

gNB

NR-Uu NR-Uu NG
NTN
Gateway 5G CN
Xn N6 Data
UE Network

NR-Uu NG
NR-Uu
NTN
Gateway gNB

Figure 5.3.2-3: Multi connectivity between two transparent NTN-based NG-RAN

Multi connectivity involving regenerative NTN-based NG-RAN (gNB-DU on board)

Another case to be considered, refers to the combination of a regenerative NTN-based NG-RAN (gNB-DU on board)
and a cellular NG-RAN. This is of interest to provide service to UEs in underserved areas. This is depicted in the figure
below.

3GPP
Release 16 31 3GPP TR 38.821 V16.0.0 (2019-12)

gNB- F1 gNB-
DU CU

NR-Uu
SRI NTN NG
Gateway

N6 Data
UE 5G-CN Network

NR-Uu gNB
NG

Figure 5.3.2-4: Multi connectivity involving regenerative NTN-based NG-RAN (gNB-DU) and cellular
NG-RAN

Note that the multi connectivity may also involve two regenerative NTN-based NG-RAN (gNB-DU on board)

Multi connectivity involving regenerative NTN-based NG-RAN (gNB on board)

The combination of two regenerative NTN-based NG-RAN (gNB on board) either GEO or LEO based or a combination
of both with Inter Satellite Links in between is also worth to consider to provide service to UEs in unserved areas. This
is depicted in the figure below.

gNB

NR-Uu NG over SRI NG

NTN
Gateway 5G CN
Xn N6 Data
UE Network

NR-Uu NG
NG over SRI
NTN
gNB
Gateway

Figure 5.3.2-5: Multi connectivity between two regenerative NTN-based NG-RAN (gNB on board)

Note that multi connectivity between regenerative NTN-based NG-RAN (gNB on board) and cellular NG-RAN (NR or
LTE based) is not addressed because the transport of Xn protocol over the Feeder link (based on Satellite Radio
interface) is For Further Study.

5.3.3 NG-RAN impacts

In case of multi-connectivity involving transparent NTN-based NG-RAN (i.e. gNB on the ground), all CP and UP
interfaces toward terrestrial NG-RAN nodes are terminated on the ground.

In case of multi-connectivity involving regenerative NTN-based NG-RAN with gNB-CU on the ground and gNB-DU
on board, all CP interfaces toward terrestrial NG-RAN nodes are terminated on the ground.

3GPP
Release 16 32 3GPP TR 38.821 V16.0.0 (2019-12)

● With respect to CP, this scenario does not pose any particular issues apart from the fact that F1AP will need to
adapt to the much longer roundtrip times of the SRI.

● Concerning UP, the leg running over Xn is unaffected by the presence of the NTN, while the leg running over F1
(transported over the SRI) will need to adapt to the much longer roundtrip times of the SRI. Overall, UP
buffering in the node hosting PDCP will need to compensate for the difference between the two interfaces.
Therefore, there will be an impact on the terrestrial NG-RAN node involved in DC if such NG-RAN node hosts
the PDCP.

In case of multi Connectivity involving regenerative NTN-based NG-RAN with on board gNB, setting up and
maintaining Xn interfaces toward terrestrial gNBs over the feeder link would require all the corresponding traffic (CP
and UP) to be transported over the SRI relevant to the satellite-hosted gNB. This may be a challenge.

Prerequisites for NR-NR DC where both MN and SN are NTN-based are to have at least a partial coverage area
overlap, and to have Xn up and running through the ISL between them. The Xn connection between the satellites will
add to the delay. NR-NR DC involving satellites whose orbital positions are close to one is feasible.

The multi connectivity procedure as defined in [5] may require some adaptations to support:

● Radio access technology featuring extended latency

● Radio access technology possibly suffering from variable latency within the backhaul network (e.g. a Xn
interface crossing multiple satellite located on different orbital plane)

● Differentiated delay between both radio access technology involved

NG-RAN should allow the necessary flexibility to elect as master node either the gNB of the NTN-based NG-RAN or
the gNB of the cellular NG-RAN.

5.4 Service continuity between NTN and Terrestrial Networks

In TS 22.261 (Clause 6.2.3 Service continuity requirements), for a 5G system with satellite access, the following
requirements apply:

- The 5G system shall support service continuity between 5G terrestrial access network and 5G satellite access
networks owned by the same operator or owned by 2 different operators having an agreement.

3GPP
 Release 16 33 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 5.4-1: Typical example of NTN-TN interworking

The NTN and TN could either operate in two different frequency bands (e.g. FR1 vs FR2), or in same frequency band
(e.g. FR1 or FR2).

The NTN reference scenarios as listed in chapter 4.2 considers two types of NTN UEs, a) UE with Omni directional
antenna, b) UE with directive antenna. For the support of NTN-TN service continuity use cases, assumptions on UE
characteristics considering NTN use cases are listed in the below table:

Table 5.4-1: NTN use cases mapped to TN-NTN service continuity use cases and assumptions for
frequency band and UE characteristics

NTN-TN service
NTN Use case Assumptions for UE characteristics
continuity use case
Medium/high The UE is assumed to have TN and NTN connectivity
Stationary UE (eMBB) throughput – TN or capabilities.
Pedestrian UE (eMBB) NTN (LEO) The UE has omni-directional antenna type applicable to both
Low to medium TN and NTN connectivity.
Machine UE (mMTC) throughput NTN The NTN access may operate in frequency bands below or
(GEO) above 6 GHz
Stationary/Vehicular relay
The relay UE is assumed to have TN and NTN connectivity
UE (eMBB)
Medium/high capabilities and provides service to the TN only capable UEs
throughput – TN or outdoor or inside buildings, vehicle or train/airplane,
[Relay UE on vehicles or
NTN (LEO) respectively.
ships
Medium/high The vehicular relay UE can have different antenna types for
Relay UE on high speed
throughput NTN TN and NTN connectivity.
trains
(GEO) The NTN access may operate in frequency bands below or
Relay UE on board
above 6 GHz
airplanes]

5.4.1 Scope
The focus of the NTN-TN service continuity and mobility studies should be on mechanisms to minimize specification
impact for cases where UE's connectivity changes from the NTN to TN ('hand-in') and where UE's connectivity changes
from the TN to NTN ('hand-out'). Coverage mechanisms, including inter-frequency and intra-frequency service

3GPP
Release 16 34 3GPP TR 38.821 V16.0.0 (2019-12)

continuity and mobility mechanisms are to be considered as baseline solutions. The NR Release 15-16 service
continuity and mobility mechanisms shall be considered also for the NTN-TN service continuity and mobility studies.

5.4.2 Reference scenario

It is recommended to use a reference scenario for NTN-TN service continuity and mobility studies, defined as follows:

● A multi-cell TN network-border coverage is available according to an outdoor rural NR scenario (e.g. Table
6.1.3-1 in TR 38.913)

● One NTN LEO satellite provides multi-cell coverage with moving cells on Earth (the satellite NR cells are
modelled according to NTN assumptions, Table 6.1.1-1 & 4 in TR38.821)

● Outdoor handheld (pedestrian) UEs or VSAT (vehicular relay) UEs are capable of TN and NTN connectivity
(for NTN UE use Table 6.1.1-3 in TR 38.821)

5.4.3 Assumptions
The NTN-TN service continuity and mobility mechanisms targeted to minimizing UE power consumption, e.g. DRX
enhancement solutions are only a secondary priority.

The study of dual-connectivity mechanisms between NTN and TN, in the baseline NTN-TN service continuity and
mobility solutions is a secondary priority.

3GPP
Release 16 35 3GPP TR 38.821 V16.0.0 (2019-12)

6 Radio Layer 1 issues and related solutions

6.1 Link-Level and System-Level Evaluations

Both multi-satellite and single satellite simulations should be considered for calibration and performance evaluation.

6.1.1 System level simulations

6.1.1.1 Simulation assumptions

The following tables representing two sets of satellite parameters are considered as the baseline for system level
simulator calibration:

Table 6.1.1.1-1: Set-1 satellite parameters for system level simulator calibration

Satellite orbit GEO LEO-1200 LEO-600

Satellite altitude 35786 km 1200 km 600 km
Satellite antenna pattern Section 6.4.1 in [2] Section 6.4.1 in [2] Section 6.4.1 in [2]
Payload characteristics for DL transmissions
Equivalent satellite
22 m 2m 2m
antenna aperture (Note 1)
Satellite EIRP density 59 dBW/MHz 40 dBW/MHz 34 dBW/MHz
S-band
Satellite Tx max Gain 51 dBi 30 dBi 30 dBi
(i.e. 2 GHz)
3dB beamwidth 0.4011 deg 4.4127 deg 4.4127 deg
Satellite beam diameter
250 km 90 km 50 km
(Note 2)
Equivalent satellite
5m 0.5 m 0.5 m
antenna aperture (Note 1)
Satellite EIRP density 40 dBW/MHz 10 dBW/MHz 4 dBW/MHz
Ka-band
Satellite Tx max Gain 58.5 dBi 38.5 dBi 38.5 dBi
(i.e. 20 GHz for DL)
3dB beamwidth 0.1765 deg 1.7647 deg 1.7647 deg
Satellite beam diameter
110 km 40 km 20 km
(Note 2)
Payload characteristics for UL transmissions
Equivalent satellite
22 m 2m 2m
antenna aperture (Note1) S-band
G/T (i.e. 2 GHz) 19 dB K-1 1.1 dB K-1 1.1 dB K-1
Satellite Rx max Gain 51 dBi 30 dBi 30 dBi
Equivalent satellite
3.33 m 0.33 m 0.33 m
antenna aperture (Note1) Ka-band (i.e. 30
-1 -1
G/T GHz for UL) 28 dB K 13 dB K 13 dB K-1
Satellite RX max Gain 58.5 dBi 38.5 dBi 38.5 dBi
NOTE 1: This value is equivalent to the antenna diameter in Sec. 6.4.1 of [2].
NOTE 2: This beam size refers to the Nadir pointing of the satellite
NOTE 3: All these satellite parameters are applied per beam.
NOTE 4: The EIRP density values are considered identical for all frequency re-use factor options.
NOTE 5: The EIRP density values are provided assuming the satellite HPA is operated with a back-off of [5] dB.

3GPP
Release 16 36 3GPP TR 38.821 V16.0.0 (2019-12)

Table 6.1.1.1-2: Set-2 satellite parameters for system level simulator calibration

Satellite orbit GEO LEO-1200 LEO-600

Satellite altitude 35786 km 1200 km 600 km
Satellite antenna pattern Section 6.4.1 in [2] Section 6.4.1 in [2] Section 6.4.1 in [2]

Payload characteristics for DL transmissions

Equivalent satellite
12 m 1m 1m
antenna aperture (Note 1)
Satellite EIRP density 53.5 dBW/MHz 34 dBW/MHz 28 dBW/MHz
S-band
Satellite Tx max Gain 45.5 dBi 24 dBi 24 dBi
(i.e. 2 GHz)
3dB beamwidth 0.7353 deg 8.8320 deg 8.8320 deg
Satellite beam diameter
450 km 190 km 90 km
(Note 2)
Equivalent satellite
2m 0.2 m 0.2 m
antenna aperture (Note 1)
Satellite EIRP density 32 dBW/MHz 2 dBW/MHz -4 dBW/MHz
Ka-band
Satellite Tx max Gain 50.5 dBi 30.5 dBi 30.5 dBi
(i.e. 20 GHz for DL)
3dB beamwidth 0.4412 deg 4.4127 deg 4.4127 deg
Satellite beam diameter
280 km 90 km 50 km
(Note 2)
Payload characteristics for UL transmissions
Equivalent satellite
12 m 1m 1m
antenna aperture (Note1) S-band
-1
G/T (i.e. 2 GHz) 14 dB K -4.9 dB K-1 -4.9 dB K-1
Satellite Rx max Gain 45.5 dBi 24 dBi 24 dBi
Equivalent satellite
1.33 m 0.13 m 0.13 m
antenna aperture (Note1) Ka-band (i.e. 30
G/T GHz for UL) 20 dB K-1 5 dB K-1 5 dB K-1
Satellite Rx max Gain 50.5 dBi 30.5 dBi 30.5 dBi
NOTE 1: This value is equivalent to the antenna diameter in Sec. 6.4.1 of [2].
NOTE 2: This beam size refers to the Nadir pointing of the satellite
NOTE 3: All these satellite parameters are applied per beam.
NOTE 4: The EIRP density values are considered identical for all frequency re-use factor options.

The following table is agreed for UE characteristics for System Level Simulations

Table 6.1.1.1-3: UE characteristics for system level simulations

Characteristics VSAT (Note 2) Handheld Other (Note 1)

Frequency band Ka band(i.e. 30 GHz UL S band (i.e. 2 GHz) Ka band(i.e. 30 GHz UL
and 20 GHz DL) and 20 GHz DL)
Antenna type and Directional (1, 1, 2) with omni- Directional
configuration Section 6.4.1 of [2] with 60 directional antenna (M,N,P,Mg,Ng) =
cm equivalent aperture element (TBD,TBD,2,1,1); (dV,dH)
diameter = (TBD, TBD)λ with
directional antenna
element (HPBW=65 deg)
Polarisation circular Linear: +/-45°X-pol Linear: +/-45°X-pol
Rx Antenna gain 39.7 dBi 0 dBi per element TBD dBi per element
Antenna temperature 150 K 290 K TBD K
Noise figure 1.2 dB 7 dB TBD dB
Tx transmit power 2 W (33 dBm) 200 mW (23 dBm) [TBD W (TBD dBm)]
Tx antenna gain 43.2 dBi 0 dBi per element TBD dBi per element
NOTE 1: Moving platforms (e.g., aircrafts, vessels), building mounted devices. These values are provided for
information.
NOTE 2: VSAT terminal characteristics could be implemented with phased array antenna

The following table is agreed for the beam layout definition for a single satellite simulation

3GPP
Release 16 37 3GPP TR 38.821 V16.0.0 (2019-12)

Table 6.1.1.1-4: Beam layout definition for single satellite simulation

Scenario Scenario A, C2 and D2

Beam layout definition Baseline: Hexagonal mapping of the beam bore sight directions on UV plane defined in the
satellite reference frame.
Only the 3dB beam width parameters should be used. The beam diameter and beam
spacing values can be computed directly from the 3 dB beam width assumptions and should
be considered as informative.
Number of beams Baseline: 19-beam layout considering wrap-around mechanism (i.e. 18 beams surrounding
the central beam and allocated on 2 distinct "tiers")
UV plane illustration
(extracted from [19])

UV plane convention U axis is defined as the perpendicular line to the satellite-earth line on the orbital plane as
illustrated here after:

The straight line being orthogonal to UV plane is pointing towards the Earth centre.
UV coordinates of the nadir of the reference satellite is (0,0)
Adjacent beam spacing Baseline: Adjacent beam spacing computation based on 3dB beam width of the satellite
on UV plane antenna pattern:
ABS = sqrt(3) x sin(HPBW/2 [rad])
Central beam bore sight Baseline:
direction definition Case 1: Central beam center is considered at nadir point
Case 2: Central beam boresight direction computed based on elevation angle target

3GPP
Release 16 38 3GPP TR 38.821 V16.0.0 (2019-12)

Table 6.1.1.1-5: System Level Simulation assumptions for calibration

3GPP
Release 16 39 3GPP TR 38.821 V16.0.0 (2019-12)

Configuration scenario A, C2 and D2

Frequency band S-band (i.e. 2 GHz) / Ka-band (i.e. 20 GHz DL, 30 GHz UL)
S-band: DL 30 MHz and UL 30 MHz
Maximum Bandwidth per beam Ka-band: DL 400 MHz and UL 400 MHz
(DL + UL) The bandwidth per beam must be adapted based on the frequency factor and
the polarization re-use option considered.
See Table 6.1.1.1-1 and Table 6.1.1.1-2
Satellite characteristics (G/T, EIRP
Note: Same satellite characteristics should be considered for both single and
density, antenna diameter)
multi-satellite simulations
Satellite antenna pattern See section 6.4.1 in [2]: Bessel function
Satellite polarization configuration Circular
For singles satellite simulation: See Table 6.1.1.1-4
Beam layout definition
For multi satellites simulation: FFS

3GPP
Release 16 40 3GPP TR 38.821 V16.0.0 (2019-12)

Option 1: 1

Option 2: 3

Frequency re-use factor

Option 3: 2 if polarization re-use is enabled

Option 1: Disable
Option 2: Enable
Polarization re-use
Note: Polarization re-use should apply only if circular polarization for terminal
antenna is considered
Channel model Large scale model of [2] (Note 2)
Base-line: Rural
Deployment scenarios
Additional deployment scenario results can be provided

3GPP
Release 16 41 3GPP TR 38.821 V16.0.0 (2019-12)

Base-line:
Propagation conditions Clear Sky
Line of sight
UEs outdoor/indoor distribution 100% outdoor distribution for UEs
Base-line for calibration: at least X=10 UEs per beam with uniform distribution in
all the Voronoi cell area associated to each beam.
UE distribution
The cell area associated to a given beam is defined as the Voronoi cell
associated with the corresponding beam centers.
S-band:
Handheld (optional for scenario A)

Ka-band:
UE configuration
VSAT
Others (optional for scenario A)

See Table 6.1.1.1-3

VSAT and Others: Ideal Tracking serving beam;
UE orientation
Handheld: Random
Handover Margin 0 dB
UE attachment RSRP
Base-line: Coupling loss, Geometry
Metrics for calibration Note: Coupling loss is defined as the signal loss from the antenna port to the
antenna port
NOTE 1: Typical impairment values (additional frequency error, SNR loss) due to the feeder link except for delay can
be considered to be negligible. When available, specific values can be considered in the evaluation and
should be reported.
NOTE 2: For the calibration purpose, the ionospheric scintillation loss shall be considered equal to zero (i.e., the UEs
are located between 20 and 60 degrees of latitude). The atmospheric absorptions loss shall be considered.

Traditionally, the wrap around mechanism used in system level simulations refers to a mirroring effect of the
surrounding cells/beams so that the computational load of the simulations can be reduced. However, these types of
schemes are not applicable in NTN context except in the specific case of central beam at nadir (90° elevation).
Therefore, for the evaluation, all the additional surrounding beams should be simulated independently.

As a consequence, a new wrap around mechanism is introduced in case of single satellite simulation for intra-satellite
interference modelling based on additional bore-sight beam directions which should be computed based on the
methodology captured in Table 6.1.1.1-4.

In particular, the following wrap-around mechanism should be adopted for calibration:

● For FRF = 1, two additional tiers of beams are considered in the simulation surrounding the 19-beam layout (cf.
Figure 6.1.1.1-1 – FRF=1).

● For FRF > 1, four additional tiers of beams are considered in the simulation surrounding the 19-beam layout (cf.
Figure 6.1.1.1-1 – FRF=3).

● Considering a UE attached to a beam, in the DL/UL all remaining beams are treated as interference as long as
these beams are sharing the same frequency band/polarization (cf. Figure 6.1.1.1-2).

For the metrics statistic (e.g. coupling loss, geometry), only the UEs placed in the inner-19 beams are considered.

3GPP
Release 16 42 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 6.1.1.1-1: Illustrations of the additional tiers of beams to be wrapped around based on the FRF
configurations

3GPP
Release 16 43 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 6.1.1.1-2: Definition of the interfering beams to be considered

The beam layout parameters captured in the following table are adopted as a starting point for single satellite
simulations.

Table 6.1.1.1-6: Beam layout parameters for single satellite simulation

Scenario Scenario A Scenario C2/D2

Carrier frequency S-band: 2 GHz S-band: 2 GHz
Ka-band: 20 GHz for DL Ka-band: 20 GHz for DL
Adjacent beam spacing S-band: S-band:
(ABS) on UV plane Set 1: ABS = 0.0061 Set 1: ABS = 0.0668
Set 2:ABS = 0.0111 Set 2: ABS = 0.1334
Ka-band: Ka-band:
Set 1: ABS = 0.0027 Set 1: ABS = 0.0267
Set 2: ABS = 0.0067 Set 2: ABS = 0.0667
Satellite location Any position on the geostationary orbit Any position on the LEO orbit
Central beam center Baseline: 45 deg Baseline: 90 deg
elevation angle target
Central beam bore sight Baseline: (0.107,0) Baseline: (0,0)
direction coordinates in UV
plane
Gateway direction Baseline: Same as central beam bore sight direction coordinates in UV plane
coordinates in UV plane Note: Not needed for calibration

For handheld terminal, the following association between antenna port and antenna element is assumed for calibration,
evaluations and link budgets calculation:

3GPP
Release 16 44 3GPP TR 38.821 V16.0.0 (2019-12)

● 1 TX with one antenna element associated to one Tx branch.

● 2 RX with each antenna element associated to one Rx branch.

NOTE: Implementations without the above association can be evaluated in addition

As a consequence, the following considerations are assumed for handheld use cases:

● For downlink transmission, a combination of the two Rx branches allows to prevent depolarization loss. (cf.
Figure 6.1.1.1-3)

● For uplink transmissions,

- A 3dB depolarization loss should be taken into account assuming polarization reuse is applied and satellite
reception implements circular polarization (e.g., when frequency reuse option 3 is considered) (cf. Figure
6.1.1.1-4 – configuration A)

- A 0dB depolarization loss can be assumed when satellite reception implements dual polarization per beam
(e.g., for the frequency reuse 1 and 3 cases) (cf. Figure 6.1.1.1-4 – configuration B)

Figure 6.1.1.1-3: Example of DL RX/TX configuration for handheld use cases

3GPP
Release 16 45 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 6.1.1.1-4: Example of UL RX/TX configurations for handheld use cases

For VSAT use cases, calibration results and link budgets should be computed assuming no depolarization loss.

3GPP
Release 16 46 3GPP TR 38.821 V16.0.0 (2019-12)

Table 6.1.1.1-7: SLS parameters for performance evaluation

Configuration scenario A, C2 and D2

Frequency band Same as in Table 6.1.1.1-5
Maximum Bandwidth per beam
Same as in Table 6.1.1.1-5
(DL + UL)
Satellite characteristics (G/T, EIRP
Same as in Table 6.1.1.1-5
density, antenna diameter)
Satellite antenna pattern Same as in Table 6.1.1.1-5
Satellite polarization configuration Same as in Table 6.1.1.1-5
Beam layout Same as in Table 6.1.1.1-5
Number of beams Same as in Table 6.1.1.1-5
Frequency re-use factor Same as in Table 6.1.1.1-5
Polarization re-use Same as in Table 6.1.1.1-5
Deployment scenarios Same as in Table 6.1.1.1-5
Fast fading model Frequency selective channel model listed in [2]
Propagation conditions Same as in Table 6.1.1.1-5
UEs outdoor/indoor distribution Same as in Table 6.1.1.1-5
UEs coverage distribution Same as in Table 6.1.1.1-5
UE configuration Same as in Table 6.1.1.1-5
UE orientation Same as in Table 6.1.1.1-5
Handover Margin To be reported by the companies
UE attachment RSRP
Receiver type MMSE-IRC
Scheduler To be reported by the companies
Traffic model FTP 3 (see TR 38.802) packet size = 0.5 Mbyte
Channel estimation Realistic
CSI feedback Release 15 (Note 2)
Metrics for performance Baseline: UE throughput (5%, 50%, 95%) at 20% and [50 or 60]% RU (Note 4)
NOTE 1: Typical impairment values (additional frequency error, SNR loss) due to the feeder link except for delay can
be considered to be negligible. When available, specific values can be considered in the evaluation and
should be reported.
NOTE 2: The impact of RTT should be considered for evaluation
NOTE 3: The overhead due to control channel and RS can be reported by the companies [e.g. 4/14]
NOTE 4: The bandwidth used for RU calculation is based on the allocated bandwidth for each beam

The following table captures the impairments introduced on the RF signal due to the satellite payload and movement for
link level simulations.

Table 6.1.1.1-8: Impairments due to satellite payload and satellite movement

S-band Ka-band

Phase noise model (Note 2) Optional Phase noise profile according to

TR38.803

On-board oscillator long-term drift [0.5] ppm [0.5] ppm

(Note 3)

Max Doppler shift (Note 1) Scenario A: 0.15 ppm

Scenario C2/D2:

● 1200 km: 20 ppm

● 600 km: 24 ppm

Max Doppler shift if pre/post Scenario A: n/a

compensation mechanism is assumed
at satellite payload side Scenario C2/D2:

● Satellite alt. = 1200 km

- beam diameter = 90 km (Set 1 - S-band): 0.91 ppm

3GPP
Release 16 47 3GPP TR 38.821 V16.0.0 (2019-12)

- beam diameter = 40 km (Set 1 - Ka-band): 0.40 ppm

- beam diameter = 190 km (Set 2 - S-band): 1.91 ppm

- beam diameter = 90 km (Set 2 - Ka-band): 0.91ppm

- beam diameter = 1000 km (Max beam foot print size): 9.17ppm

● Satellite alt. = 600 km

- beam diameter = 50 km (Set 1 - S-band): 1.05 ppm

- beam diameter = 20 km (Set 1 - Ka-band): 0.42 ppm

- beam diameter = 90 km (Set 2 - S-band): 1.88 ppm

- beam diameter = 50 km (Set 2 - Ka-band): 1.05 ppm

- beam diameter = 1000 km (max beam foot print size): 15.82 ppm

Max Doppler rate Scenario A: n/a

Scenario C2/D2:

● 0.09 ppm/s for 1200 km satellite altitude

● 0.27 ppm/s for 600 km satellite altitude

NOTE 1: Min. Elevation angle for both sat- user equipment is equal to 10 degree.
NOTE 2: For regenerative scenario, this can be considered as the phase noise model for the gNB. For transparent
scenarios, it should be considered as an additional phase noise w.r.t the phase noise generated by the gNB
and the UE.
NOTE 3: These values are provided for information only and have not been considered in Radio Layer 1 analysis for
the following reasons: 1) In the cases where transparent satellite payload are considered, it is assumed that
the gNB can detect the frequency shift due to on -board oscillator long-term drift and compensate for it. 2) In
the cases where regenerative satellite payload are considered, it is assumed that the on -board oscillator drift
is sufficiently decreased to become negligible.

3GPP
Release 16 48 3GPP TR 38.821 V16.0.0 (2019-12)

Table 6.1.1.1-9: List of calibration study cases

Case Satellite orbit Satellite Central beam Terminal Frequency Frequency/

parameter set elevation Band Polarization
Reuse
1 GEO Set 1 45 deg VSAT Ka-band Option 1
2 GEO Set 1 45 deg VSAT Ka-band Option 2
3* GEO Set 1 45 deg VSAT Ka-band Option 3
4* GEO Set 1 45 deg Handheld S-band Option 1
5* GEO Set 1 45 deg Handheld S-band Option 2
6 LEO-600 Set 1 90 deg VSAT Ka-band Option 1
7 LEO-600 Set 1 90 deg VSAT Ka-band Option 2
8* LEO-600 Set 1 90 deg VSAT Ka-band Option 3
9 LEO-600 Set 1 90 deg Handheld S-band Option 1
10 LEO-600 Set 1 90 deg Handheld S-band Option 2
11* LEO-1200 Set 1 90 deg VSAT Ka-band Option 1
12* LEO-1200 Set 1 90 deg VSAT Ka-band Option 2
13* LEO-1200 Set 1 90 deg VSAT Ka-band Option 3
14 LEO-1200 Set 1 90 deg Handheld S-band Option 1
15 LEO-1200 Set 1 90 deg Handheld S-band Option 2
16** GEO Set 2 45 deg VSAT Ka-band Option 1
17** GEO Set 2 45 deg VSAT Ka-band Option 2
18** GEO Set 2 45 deg VSAT Ka-band Option 3
19** GEO Set 2 45 deg Handheld S-band Option 1
20** GEO Set 2 45 deg Handheld S-band Option 2
21** LEO-600 Set 2 90 deg VSAT Ka-band Option 1
22** LEO-600 Set 2 90 deg VSAT Ka-band Option 2
23** LEO-600 Set 2 90 deg VSAT Ka-band Option 3
24** LEO-600 Set 2 90 deg Handheld S-band Option 1
25** LEO-600 Set 2 90 deg Handheld S-band Option 2
26** LEO-1200 Set 2 90 deg VSAT Ka-band Option 1
27** LEO-1200 Set 2 90 deg VSAT Ka-band Option 2
28** LEO-1200 Set 2 90 deg VSAT Ka-band Option 3
29** LEO-1200 Set 2 90 deg Handheld S-band Option 1
30** LEO-1200 Set 2 90 deg Handheld S-band Option 2
NOTE 1: no star = 1st priority, * = second priority scenario, ** = third priority scenario
NOTE 2: Only 1st priority cases will be considered for calibration phase 1

6.1.1.2 Calibration results

Based on System Level Simulation assumptions for calibration described in Table 6.1.1.1-5, the results of CL,
Geometry SIR and Geometry SINR simulated on DL and UL transmissions are reported in Table 6.1.1.2-1 and Table
6.1.1.2-2. These results are representative of the average performance reported by the different companies in [20] [21].

3GPP
Release 16 49 3GPP TR 38.821 V16.0.0 (2019-12)

Table 6.1.1.2-1: Calibration results on DL transmissions

DL Coupling Loss DL Geometry SIR DL Geometry SINR

@5% @50% @95% @5% @50% @95% @5% @50% @95%
SC1 109.3 113.6 117.9 -3.0 -1.0 1.2 -3.2 -1.2 1.0
SC2 109.2 113.6 118.0 8.4 9.0 9.2 5.5 7.4 8.4
SC3 109.3 113.7 118.0 9.7 10.0 10.2 6.0 8.1 9.2
SC4 138.0 140.3 142.5 -3.1 -1.1 1.1 -4.0 -2.1 -0.1
SC5 138.0 140.3 142.5 8.0 8.9 9.2 1.5 3.3 4.9
SC6 96.2 97.5 98.9 -3.0 -1.1 1.1 -3.2 -1.2 0.8
SC7 96.2 97.5 98.9 8.3 9.0 9.2 6.6 7.6 7.8
SC8 96.2 97.5 98.9 9.7 9.9 10.1 7.5 8.1 8.5
SC9 123.7 125.3 127.0 -3.0 -1.1 1.1 -3.1 -1.1 1.0
SC10 123.7 125.3 127.0 8.3 9.0 9.2 7.3 8.2 8.5
SC11 102.2 103.5 105.0 -3.0 -1.1 1.1 -3.2 -1.2 0.8
SC12 102.2 103.5 105.0 8.3 9.0 9.2 6.6 7.6 7.8
SC13 102.2 103.5 105.0 9.7 9.9 10.1 7.5 8.1 8.5
SC14 129.8 131.3 133.0 -3.0 -1.1 1.1 -3.1 -1.1 1.0
SC15 129.8 131.4 133.0 8.3 9.0 9.2 7.3 8.2 8.5
SC16 117.3 121.7 126.0 -3.0 -1.0 1.2 -4.3 -2.2 0.0
SC17 117.3 121.7 126.0 8.3 9.0 9.2 -0.3 3.2 6.0
SC18 117.4 121.8 126.1 9.7 10.0 10.1 -0.2 3.4 6.4
SC19 143.4 145.8 148.1 -3.1 -1.1 1.0 -5.9 -4.0 -2.1
SC20 143.4 145.8 148.1 8.3 9.1 9.5 -3.3 -1.2 0.9
SC21 100.3 105.5 111.1 -3.0 -1.1 1.1 -4.5 -2.3 -0.1
SC22 100.3 105.5 111.1 8.3 9.0 9.2 -1.3 3.4 6.4
SC23 100.4 105.6 111.1 9.7 9.9 10.1 -1.2 3.5 6.9
SC24 129.8 131.5 133.3 -3.0 -1.0 1.2 -3.3 -1.4 0.7
SC25 129.8 131.5 133.3 8.3 8.9 9.3 5.0 6.2 6.9
SC26 106.1 111.6 117.3 -3.0 -1.1 1.1 -4.6 -2.3 0.0
SC27 106.1 111.6 117.2 8.3 9.0 9.2 -1.4 3.3 6.5
SC28 106.2 111.6 117.3 9.7 9.9 10.1 -1.4 3.5 7.0
SC29 135.8 137.6 139.4 -3.0 -1.0 1.2 -3.3 -1.4 0.7
SC30 135.8 137.6 139.4 8.3 8.9 9.3 5.0 6.2 6.9
NOTE: Geometry SINR = -10log10(I/C + N/C), where C, I and N equals the carrier, interferer and noise power levels
measured over the configured signal bandwidth.

3GPP
Release 16 50 3GPP TR 38.821 V16.0.0 (2019-12)

Table 6.1.1.2-2: Calibration results on UL transmissions

UL Coupling Loss UL Geometry SIR UL Geometry SINR

@5% @50% @95% @5% @50% @95% @5% @50% @95%
SC1 109.2 113.5 117.8 -6.9 -1.3 4.4 -7.0 -1.5 1.0
SC2 109.2 113.5 117.8 3.6 8.3 12.9 3.1 7.6 12.2
SC3 109.2 113.5 117.8 4.5 9.3 14.1 3.5 8.1 12.7
SC4 137.9 140.2 142.5 -4.6 -1.0 3.3 -9.8 -7.3 -5.0
SC5 138.0 140.3 142.5 8.0 8.9 9.2 1.5 3.3 4.9
SC6 96.1 97.4 98.8 -3.9 -1.1 2.6 -3.9 -1.1 2.6
SC7 96.1 97.4 98.8 6.1 8.3 10.4 6.1 8.3 10.4
SC8 96.1 97.4 98.8 6.9 9.3 11.6 6.9 9.3 11.5
SC9 123.7 125.3 127.1 -4.0 -0.8 3.2 -4.1 -1.1 2.7
SC10 123.7 125.4 127.1 6.9 9.0 11.1 5.2 7.1 9.0
SC11 102.2 103.4 104.8 -4.0 -1.1 2.6 -4.0 -1.2 2.5
SC12 102.2 103.4 104.8 5.9 8.2 10.4 5.9 8.2 10.3
SC13 102.2 103.4 104.8 6.7 9.2 11.6 6.7 9.2 11.5
SC14 129.7 131.4 133.1 -4.0 -0.8 3.2 -4.5 -1.7 1.5
SC15 129.7 131.4 133.1 6.9 9.0 11.1 2.3 4.1 5.8
SC16 117.2 121.5 125.8 -6.7 -1.2 4.5 -7.6 -2.6 2.5
SC17 117.2 121.5 125.8 3.7 8.3 12.9 0.9 5.3 9.6
SC18 117.2 121.5 125.8 4.5 9.3 14.1 0.3 4.7 9.0
SC19 143.4 145.7 148.1 -4.6 -0.9 3.5 -13.9 -11.6 -9.3
SC20 143.4 145.7 148.1 6.3 9.1 11.8 -13.6 -11.2 -8.9
SC21 100.1 105.4 111.0 -8.3 -1.6 4.9 -8.3 -1.6 4.9
SC22 100.1 105.4 111.0 2.2 8.0 13.7 2.1 7.9 13.7
SC23 100.1 105.4 111.0 3.0 9.0 14.9 3.0 8.9 14.8
SC24 129.8 131.5 133.4 -3.9 -0.7 3.5 -4.5 -1.6 1.7
SC25 129.8 131.6 133.4 7.1 9.3 11.6 2.1 4.0 5.9
SC26 106.0 111.4 117.1 -8.5 -1.6 5.0 -8.5 -1.7 4.9
SC27 106.0 111.4 117.1 2.0 8.0 13.9 1.9 7.9 13.8
SC28 106.0 111.4 117.1 2.9 9.0 15.1 2.7 8.7 14.8
SC29 135.8 137.6 139.5 -4.0 -0.7 3.5 -6.0 -3.6 -1.2
SC30 135.8 137.6 139.5 7.2 9.4 11.7 -2.8 -0.9 0.9
NOTE: Geometry SINR = -10log10(I/C + N/C), where C, I and N equals the carrier, interferer and noise power levels
measured over the configured signal bandwidth.

6.1.1.3 System Level Simulation Evaluation Results

Two companies have provided DL user throughput performance results based on single satellite SLS assumptions, see
Section 6.1.1.1.

One source provided results for 8 different study cases for 20% and ~50% target resource utilization (RU), see Table
6.1.1.3-1 Additional assumptions are 10UEs per cell, proportional fair scheduling. LOS probability is according to
Table 6.6.1-1 in TR 38.811. The used deployment scenario is rural. The number of HARQ processes is assumed to be
RTT/T_slot.

Table 6.1.1.3-1: SLS UE throughput performance in Mbit/s [22]

GEO, Ka-band LEO-600, Ka-band LEO-600, S-band LEO-1200, S-band

Study case 1 2 6 7 9 10 14 15
RU=20% 5% 0.96 0.48 2.04 1.02 0.11 0.03 0.11 0.05
50% 2.7 2.05 4.08 2.78 0.31 0.15 0.3 0.19
95% 4.93 3.9 6.43 4.7 0.52 0.34 0.52 0.41
RU~50% 5% 5.34 4.03 6.91 4.76 0.44 0.3 0.4 0.31
50% 8.53 6.61 10.03 7.75 0.74 0.58 0.78 0.6
95% 11.99 9.99 13.7 11.22 1.09 0.88 1.09 0.9

One source provided results for LEO-1200 S-Band with no frequency reuse (Study case 14) with 20% resource
utilization, see Table 6.1.1.3-2. Additional assumptions are 10UEs per cell, proportional fair scheduling and 16 parallel
HARQ processes. LOS probability is according to Table 6.6.1-1 in TR 38.811. The used deployment scenario is rural.

3GPP
Release 16 51 3GPP TR 38.821 V16.0.0 (2019-12)

Table 6.1.1.3-2: SLS UE throughput performance in Mbit/s [23]

LEO-1200, S-band
Study case 14
RU=20% 5% 0.2
50% 0.31
95% 0.44

6.1.2 Link level simulations

The following table provides the LLS parameters for DL synchronization performance evaluation

Table 6.1.2-1: LLS parameters for DL synchronization evaluation

S-band Ka-band
Carrier Frequency 2 GHz 20 GHz
For GEO (optional):
Baseline TDL/CDL model in [2], with delay/angular scaling factors equals to the mean
delay/angular spread and mean K factor for suburban LOS elevation angle 10 deg
Channel Model
For LEO:
Baseline TDL/CDL model in [2], with delay/angular scaling factors equals to the mean
delay/angular spread and mean K factor for suburban LOS elevation angle [30] deg
Subcarrier Spacing(s) 15kHz, 30kHz 120kHz, 240kHz
DL RS SSB
Antenna Configuration
1Tx 1Tx
at the TRP (satellite)
Antenna Configuration (1, 1, 2) with omni-directional antenna VSAT with 60 cm equivalent aperture
at the UE element diameter
UE speed 3 km/h 0 km/h, 1200 km/h
For GEO (optional): 10°,
UE elevation angle
For LEO: 30°
UE crystal accuracy: 10 ppm
Satellite: oscillator accuracy values provided in Table 6.1.1.1-8
Doppler shift in channel due to satellite movement: max. Doppler shift values provided in Table
6.1.1.1-8
Doppler shift in channel due to UE movement: max. value to be computed based on the UE speed
and the elevation angle
Note 1: The final frequency offset is computed as follows

where:
denotes the final frequency offset in Hz
Frequency Offset
denotes the UE crystal accuracy in ppm
denotes Doppler shift due to satellite movement in ppm. Pre/post Doppler shift
compensation can be assumed.
denotes the Doppler shift due to UE movement in ppm
denotes the carrier frequency used on the service Down Link in Hz
A uniform distribution in [ - FO max value, + FO max value] shall be assumed.
Note 2: Doppler spectrum on Rayleigh fading taps based on Jake model should be considered in
addition to Doppler shift (see section 6.9.2 in [2])
Note 3: For a Rayleigh fading tap a minimum Doppler of 1 Hz should be considered.
Frequency drift [Doppler rate values provided in Table 6.1.1.1-8]
S-band phase noise modelling (optional)
Phase noise model
Ka-band phase noise modelling: phase noise profile according to TR38.803.
One-shot initial cell detection accuracy of PCID;
CDF of timing and frequency residual offset at SNIR point corresponding to 90% likelihood
Metrics
for one-shot detection accuracy of cell ID.
Note 4: FAR of PCID detection requirement = 1%
NOTE: The SNR range to be evaluated should be based on the link budget analysis for each channel

3GPP
Release 16 52 3GPP TR 38.821 V16.0.0 (2019-12)

The following table provides the LLS parameters for PRACH performance evaluation.

Table 6.1.2-2: LLS parameters for PRACH performance evaluation

Configuration
S-band Ka-band
s
Carrier
2 GHz 30 GHz
Frequency
Baseline TDL/CDL-D model in [2], with delay/angular scaling factors equals to the mean
Channel
delay/angular spread and mean K factor for suburban at corresponding elevation angle for each case
Model
Antenna
Configuration 1 Rx 1 Rx
at the TRP 2 Rx optional 2 Rx optional
(satellite)
Antenna
Omni-directional antenna with single linearly polarized VSAT with 60 cm equivalent aperture
Configuration
antenna element diameter
at the UE
Doppler shift in channel due to satellite movement; max. Doppler shift values provided in Table
6.1.1.1-8
Doppler shift in channel due to UE movement; max. value to be computed based on the UE speed
and the elevation angle
Residual frequency offset after synchronization: [0.1] ppm
Note 1: In case the network performs both pre and post common Doppler shift compensation, the
final frequency offset is computed as follow:

where
FO denotes the final frequency offset in Hz
Frequency RO denotes the residual frequency offset after synchronization in ppm
Offset
DS sat
denotes the residual Doppler shift due to satellite movement in ppm after common Doppler
compensation
DSUE
denotes the Doppler shift due to UE movement in ppm
f service,UL
denotes the central frequency used on the service Up Link in Hz

A uniform distribution in [ - FO max value, + FO max value] shall be assumed

Note 2: Doppler spectrum on Rayleigh fading taps based on Jake model should be considered in
addition to Doppler shift (see section 6.9.2 in [2])
Note 3: For a Rayleigh fading tap a minimum Doppler of 1 Hz should be considered.
UE speed 3 km/h 0 km/h, 1000 km/h
A uniform distribution in [0 max differential delay] shall be assumed.
Note 1: Ideal common delay compensation is assumed.
Timing Offset Note 2: The maximal differential delay values that should be supported for NTN are provided in Table
4.2-2. The max differential delays expected for specific cases can be computed based on the half
power beam width and the target elevation angle.
Phase noise S-band phase noise modelling (optional)
model Ka-band phase noise modelling: phase noise profile according to in TR38.803.
PRACH Each company should provide details on configuration (i.e. format, SCS, N_CS, …). New formats are
design not precluded.
PRACH detection rate, FAR (Based on the preamble pool size is not less than 64), CDF of estimation
Metric
error for frequency/timing,
Receiver Companies are encouraged to report the receiver for PRACH detection.

3GPP
Release 16 53 3GPP TR 38.821 V16.0.0 (2019-12)

Table 6.1.2-3: PRACH study cases

UL Frequency offset (Both

Differential delay S- and Ka-band) Beam Set at
Elevation angle
(with compensation of satellite
common Doppler)
Case 1 90 degree for LEO Small Large Set-2
Case 2 45 degree for LEO Medium Medium Set-2
10 degree for GEO and 30
Case 3 Large Small Set-2
degree for LEO
With both open loop timing and
Case 4 Small Small Set-2
frequency compensation
NOTE 1: As the baseline, the number of UEs that simultaneously access the network in a single random access
occasion (RO) is 2. The two UEs may have different timing offsets/Doppler, which are randomly picked within
the [0 Max_differential_delay]/[-max_UL_frequency_offset max_UL_frequency_offset] per case;
NOTE 2: Fixed power offset between UEs is 3dB.
NOTE 3: The SINR of the stronger UE for simulation is based on the SNR from link budget (with bandwidth for UL =
1MHz for VSAT in Ka, and Handheld for S) with additional offset of [-6-10 log10(Bandwidth [MHz])] dB) per
case where the -6 dB degradation is introduced as additional margin.

The following table provides the LLS parameters for data transmission performance evaluation.

Table 6.1.2-4: LLS parameters for data transmission performance evaluation

Parameters S-band Ka-band

Carrier frequency 2 GHz DL 20 GHz, UL 30 GHz
Channel coding
NR channel coding
scheme
Subcarrier spacing 15 kHz, 30 kHz 60 kHz, 120 kHz
Channel estimation Realistic estimation
Residual Frequency error after DL synchronisation: [0.1] ppm assuming UL pre-
Frequency offset
compensation
Frequency drift [Doppler rate values provided in Table 6.1.1.1-8]
Option 1: drift pre-compensation is assumed
Frequency tracking
Option 2: no pre-compensation is assumed
UE speed 3 km/h 0 km/h, 1000 km/h
For GEO (optional):
Baseline TDL/CDL model in [2], with delay/angular scaling factors equals to the mean
delay/angular spread and mean K factor based on the selected channel conditions. These
parameters should be provided by the companies.
Channel model
For LEO:
Baseline TDL/CDL model in [2], with delay/angular scaling factors equals to the mean
delay/angular spread and mean K factor based on the selected channel conditions. These
parameters should be provided by the companies.
Satellite antenna
1Tx/Rx 1Tx/Rx
configuration
UE antenna (1, 1, 2) with omni-directional antenna element VSAT with 60 cm equivalent aperture
configuration diameter
S-band phase noise modelling (optional)
Phase noise Model
Ka-band phase noise modelling: phase noise profile according to TR 38.803
Metrics BLER, Throughput

HPA non-linearity modelling is not considered as part of the baseline for link level simulations.

PAPR optimizations for downlink channels are not necessary to be specified for NTN at least for Rel-17.

6.1.3 Link Budget Analysis

6.1.3.1 Link Budget Calculation

3GPP
Release 16 54 3GPP TR 38.821 V16.0.0 (2019-12)

Carrier-to-noise-and-interference ratio (CNIR) of transmission link between satellite and UE can be derived by carrier-
to-noise ratio (CNR) and carrier-to-interference ratio (CIR) as follows

(6.1.3.1-1)

The formula for CNR calculation is

(6.1.3.1-2)

where EIRP is effective isotropic radiated power (EIRP), is antenna-gain-to-noise-temperature, is Boltzmann

constant and equals to -228.6 dBW/K/Hz, is free space path loss, is atmospheric path loss due to gases and
rain fades, is shadowing margin, is scintillation loss, is additional loss, for example degradation
due to feeder links in case of non-regenerative systems, and is channel bandwidth.

Antenna-gain-to-noise-temperature can be derived by [2]

(6.1.3.1-3)

where is receive antenna gain, is noise figure, is ambient temperature and is antenna temperature. Receive
antenna gain can be obtained by

(6.1.3.1-4)

where is receive antenna element gain, is the number of receive antenna elements, is polarization loss,
is the antenna aperture efficiency (a dimensionless parameter with typical values for parabolic antennas from 0.55 to
0.70), D is the equivalent antenna diameter, and is the wavelength.

EIRP can be calculated by

(6.1.3.1-5)

where is antenna transmit power, is cable loss, and is transmit antenna gain and can be derived by

(6.1.3.1-6)

where is transmit antenna element gain and is the number of transmit antenna elements.

6.1.3.2 Parameters
The parameter configuration for link budget analysis is listed in Table 6.1.3.2-1.

3GPP
Release 16 55 3GPP TR 38.821 V16.0.0 (2019-12)

Table 6.1.3.2-1: Parameter configuration for link budget analysis

Parameters Notes
Carrier frequency 2 GHz for DL and UL (S-band),
20 GHz for DL and 30 GHz for UL (Ka-band)
System bandwidth 30 MHz (S-band), 400 MHz (Ka-band)
Channel bandwidth DL: system bandwidth/ frequency reuse factor
UL:
UL in S-band (handheld UE): 360 kHz
Otherwise: system bandwidth/ frequency reuse factor
Note: The UL bandwidth may be a challenge.
Satellite altitude 600 km, 1200 km, 35786 km
Target elevation angle 30 (LEO), 12.5 (GEO-Set 1) , 20° (GEO –Set 2)
Atmospheric loss Equation (6.6-8) in [2]
Shadowing margin 0 dB for VSAT as terminal and 3 dB for others
Scintillation loss Section 6.6.6 in [2]
A
Ionospheric loss: IS = 2.2 dB (note 1)
Tropospheric loss: Table 6.6.6.2.1-1 of [2]
Additional loss 0 dB
Clear sky conditions Yes
Frequency reuse factor 1, 2, 3
Average CIR within a satellite beam Based on single satellite system-level calibration methodology, statistics for
based on logarithmic mean average CIR are only collected for the UEs located in the central beam of the
19-beamlayout. The central beam boresight direction is computed based on
the target elevation angle assumption. When the generated beam has a
partial or full coverage outside the earth, it is discarded.

For DL calibration, CIR is computed by averaging CIR over UEs randomly

distributed over the reference beam (UE distribution assumption of Table
6.1.1.1-5). (See Figure 6.1.3.2-1 for UE bandwidth allocation, and Figure
6.1.1.1-1 and Figure 6.1.1.1-2 for beam deployment).

For UL calibration, For Handheld device, the channel bandwidth is 360 kHz.
For VSAT, the channel bandwidth equals the system bandwidth allocated to
each beam divided by 10.
The devices in one beam are allocated on adjacent frequency resources.
The same resource allocation is assumed for all the beams.
CIR is computed by averaging over 10 simultaneously transmitting UEs
randomly distributed over the reference beam (UE distribution assumption of
Table 6.1.1.1-5). (See Figure 6.1.3.2-2 for UE bandwidth allocation, and
Figure 6.1.1.1-1 and Figure 6.1.1.1-2 for beam deployment)
The averaging should be performed over multiple realizations.
Satellite antenna polarization Circular polarization
Polarization reuse Enable if frequency reuse factor = 2 is considered.
Terminal type Ka-band: VSAT
S band: (M, N, P) = (1,1,2)
Free space path loss Equation (6.6-2) in [2]
Terminal RF parameters Table 6.1.1-3
Satellite RF parameters Set-1 in Table 6.1.1-1 and Set-2 in Table 6.1.1-2
Polarization loss The considerations of Section 6.1.1.1 on Polarization loss apply.
Outcome CNIR
NOTE 1: Based on P3 curve for 1% of time from Figure 6.6.6.1.4-1 of [2] after frequency scaling.
AIS  Pfluc @ 4GHz  0.5 1.5 / 2  1.1  0.5 1.5 / 2  2.2
dB

3GPP
Release 16 56 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 6.1.3.2-1: Illustration of UE bandwidth allocation in DL calibration

Figure 6.1.3.2-2: Illustration of UE bandwidth allocation in UL calibration

3GPP
Release 16 57 3GPP TR 38.821 V16.0.0 (2019-12)

6.1.3.3 Link Budget Results

3GPP
Release 16 58 3GPP TR 38.821 V16.0.0 (2019-12)

Table 6.1.3.3-1: Link budgets results

3GPP
Release 16 59 3GPP TR 38.821 V16.0.0 (2019-12)

Shadow fading margin [dB]

Free space path loss [dB]

Atmospheric loss [dB]

Scintillation Loss [dB]

Additional losses [dB]

Polarization loss [dB]
Transmission mode

Bandwidth [MHz]
Frequency [GHz]

TX: EIRP [dBm]

RX: G/T [dB/T]

CNR [dB]
Case

SC1 DL 20.0 96.0 15.9 400.0 210.6 1.2 0.0 1.1 0.0 0.0 11.6
UL 30.0 76.2 28.0 400.0 214.1 1.1 0.0 1.1 0.0 0.0 0.5
SC2 DL 20.0 91.2 15.9 133.3 210.6 1.2 0.0 1.1 0.0 0.0 11.6
UL 30.0 76.2 28.0 133.3 214.1 1.1 0.0 1.1 0.0 0.0 5.2
SC3 DL 20.0 93.0 15.9 200.0 210.6 1.2 0.0 1.1 0.0 0.0 11.6
UL 30.0 76.2 28.0 200.0 214.1 1.1 0.0 1.1 0.0 0.0 3.5
SC4 DL 2.0 103.8 -31.6 30.0 190.6 0.2 3.0 2.2 0.0 0.0 0.0
UL 2.0 23.0 19.0 0.4 190.6 0.2 3.0 2.2 0.0 0.0 -10.9
SC5 DL 2.0 99.0 -31.6 10.0 190.6 0.2 3.0 2.2 0.0 0.0 0.0
UL 2.0 23.0 19.0 0.4 190.6 0.2 3.0 2.2 0.0 0.0 -10.9
SC6 DL 20.0 60.0 15.9 400.0 179.1 0.5 0.0 0.3 0.0 0.0 8.5
UL 30.0 76.2 13.0 400.0 182.6 0.5 0.0 0.3 0.0 0.0 18.4
SC7 DL 20.0 55.2 15.9 133.3 179.1 0.5 0.0 0.3 0.0 0.0 8.5
UL 30.0 76.2 13.0 133.3 182.6 0.5 0.0 0.3 0.0 0.0 23.1
SC8 DL 20.0 57.0 15.9 200.0 179.1 0.5 0.0 0.3 0.0 0.0 8.5
UL 30.0 76.2 13.0 200.0 182.6 0.5 0.0 0.3 0.0 0.0 21.4
SC9 DL 2.0 78.8 -31.6 30.0 159.1 0.1 3.0 2.2 0.0 0.0 6.6
UL 2.0 23.0 1.1 0.4 159.1 0.1 3.0 2.2 0.0 0.0 2.8
SC10 DL 2.0 74.0 -31.6 10.0 159.1 0.1 3.0 2.2 0.0 0.0 6.6
UL 2.0 23.0 1.1 0.4 159.1 0.1 3.0 2.2 0.0 0.0 2.8
SC11 DL 20.0 66.0 15.9 400.0 184.5 0.5 0.0 0.3 0.0 0.0 9.1
UL 30.0 76.2 13.0 400.0 188.0 0.5 0.0 0.3 0.0 0.0 13.0
SC12 DL 20.0 61.2 15.9 133.3 184.5 0.5 0.0 0.3 0.0 0.0 9.1
UL 30.0 76.2 13.0 133.3 188.0 0.5 0.0 0.3 0.0 0.0 17.8
SC13 DL 20.0 63.0 15.9 200.0 184.5 0.5 0.0 0.3 0.0 0.0 9.1
UL 30.0 76.2 13.0 200.0 188.0 0.5 0.0 0.3 0.0 0.0 16.0
SC14 DL 2.0 84.8 -31.6 30.0 164.5 0.1 3.0 2.2 0.0 0.0 7.2
UL 2.0 23.0 1.1 0.4 164.5 0.1 3.0 2.2 0.0 0.0 -2.6
SC15 DL 2.0 80.0 -31.6 10.0 164.5 0.1 3.0 2.2 0.0 0.0 7.2
UL 2.0 23.0 1.1 0.4 164.5 0.1 3.0 2.2 0.0 0.0 -2.6
SC16 DL 20.0 88.0 15.9 400.0 210.4 0.8 0.0 0.5 0.0 0.0 4.8
UL 30.0 76.2 20.0 400.0 213.9 0.7 0.0 0.5 0.0 0.0 -6.3
SC17 DL 20.0 83.2 15.9 133.3 210.4 0.8 0.0 0.5 0.0 0.0 4.8
UL 30.0 76.2 20.0 133.3 213.9 0.7 0.0 0.5 0.0 0.0 -1.6
SC18 DL 20.0 85.0 15.9 200.0 210.4 0.8 0.0 0.5 0.0 0.0 4.8
UL 30.0 76.2 20.0 200.0 213.9 0.7 0.0 0.5 0.0 0.0 -3.3
SC19 DL 2.0 98.3 -31.6 30.0 190.4 0.1 3.0 2.2 0.0 0.0 -5.2
UL 2.0 23.0 14.0 0.4 190.4 0.1 3.0 2.2 0.0 0.0 -15.7
SC20 DL 2.0 93.5 -31.6 10.0 190.4 0.1 3.0 2.2 0.0 0.0 -5.2
UL 2.0 23.0 14.0 0.4 190.4 0.1 3.0 2.2 0.0 0.0 -15.7
SC21 DL 20.0 52.0 15.9 400.0 179.1 0.5 0.0 0.3 0.0 0.0 0.5
UL 30.0 76.2 5.0 400.0 182.6 0.5 0.0 0.3 0.0 0.0 10.4
SC22 DL 20.0 47.2 15.9 133.3 179.1 0.5 0.0 0.3 0.0 0.0 0.5
UL 30.0 76.2 5.0 133.3 182.6 0.5 0.0 0.3 0.0 0.0 15.1
SC23 DL 20.0 49.0 15.9 200.0 179.1 0.5 0.0 0.3 0.0 0.0 0.5
UL 30.0 76.2 5.0 200.0 182.6 0.5 0.0 0.3 0.0 0.0 13.4
SC24 DL 2.0 72.8 -31.6 30.0 159.1 0.1 3.0 2.2 0.0 0.0 0.6
UL 2.0 23.0 -4.9 0.4 159.1 0.1 3.0 2.2 0.0 0.0 -3.2
SC25 DL 2.0 68.0 -31.6 10.0 159.1 0.1 3.0 2.2 0.0 0.0 0.6
UL 2.0 23.0 -4.9 0.4 159.1 0.1 3.0 2.2 0.0 0.0 -3.2
SC26 DL 20.0 58.0 15.9 400.0 184.5 0.5 0.0 0.3 0.0 0.0 1.1
UL 30.0 76.2 5.0 400.0 188.0 0.5 0.0 0.3 0.0 0.0 5.0

3GPP
Release 16 60 3GPP TR 38.821 V16.0.0 (2019-12)

SC27 DL 20.0 53.2 15.9 133.3 184.5 0.5 0.0 0.3 0.0 0.0 1.1
UL 30.0 76.2 5.0 133.3 188.0 0.5 0.0 0.3 0.0 0.0 9.8
SC28 DL 20.0 55.0 15.9 200.0 184.5 0.5 0.0 0.3 0.0 0.0 1.1
UL 30.0 76.2 5.0 200.0 188.0 0.5 0.0 0.3 0.0 0.0 8.0
SC29 DL 2.0 78.8 -31.6 30.0 164.5 0.1 3.0 2.2 0.0 0.0 1.2
UL 2.0 23.0 -4.9 0.4 164.5 0.1 3.0 2.2 0.0 0.0 -8.6
SC30 DL 2.0 74.0 -31.6 10.0 164.5 0.1 3.0 2.2 0.0 0.0 1.2
UL 2.0 23.0 -4.9 0.4 164.5 0.1 3.0 2.2 0.0 0.0 -8.6
NOTE: The link budget calculations including CIR and CINR results contributed by the companies
are available in [24].

6.1.4 Multiple satellites simulation

6.1.4.1 Simulation cases

For multiple satellites simulation, the cases defined for single satellite in Table 6.1.1.1-9 can be reused. Prioritization on
the LEO can be considered for multiple satellites simulation.

6.1.4.2 Methodology for multiple satellites simulation

To emulate the effects of multiple satellites, the following two options can be considered:

● Option-1: simulation based on the reference constellation

In this option, as mentioned in [22][25][26], a reference constellation should be defined to construct the satellite and
beam layout as shown in Figure 6.1.4.2-1, with corresponding parameters, e.g., number of orbit/satellites, number of
beam illustrated in Figure 6.1.4.2-2. Detailed parameters can be determined jointly with consideration on the RF
characteristic of beams together with design principle for constellation, e.g., how to achieve global coverage.
Furthermore, the simulated area must be defined, because the coverage of the constellation depends on where on earth
users are located.

Figure 6.1.4.2-1: Illustration of exemplified satellite constellation

3GPP
Release 16 61 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 6.1.4.2-2: Illustration of parameters for satellite constellation (e.g., polar orbit with clock-wise
movement)

● Option-2: simulation based on the regional beam layouts for multiple satellites

In this option, as mentioned in [27], regional beam layout for multiple satellites can be constructed as shown in Figure
6.1.4.2-3, e.g., beam with same colour belong to single satellite. Fixed orbit inclination can be assumed for simplicity
and additional parameters, e.g., number of orbit, satellite per orbit, are introduced to enable the flexibility on the
coverage for the overall beam layout. Reuse of the same satellite RF parameters as the single satellite simulation is
feasible. Instead of using 7 satellites, a simpler scenario focused on throughput can also be constructed using 3 satellites
as outlined in [28].

a: Illustration of 7 satellites b: Illustration of beams for 7 satellites

Figure 6.1.4.2-3: Illustration of regional beam layouts for multiple satellites

6.2 Physical layer control procedures

6.2.1 Timing relationships
The propagation delays in terrestrial mobile systems are usually less than 1 ms. In contrast, the propagation delays in
NTN are much longer, ranging from several milliseconds to hundreds of milliseconds depending on the altitudes of the
spaceborne or airborne platforms and payload type in NTN. Dealing with such long propagation delays requires
modifications of many timing aspects in NR from physical layer to higher layers, including the timing advance (TA)
mechanism.

In an NTN, a UE may need to apply a large TA value that leads to a large offset in its DL and UL frame timing. Figure
6.2.1-1 illustrates a scenario, where the UE applies a large TA and gNB's DL and UL frame timing are aligned. Another

3GPP
Release 16 62 3GPP TR 38.821 V16.0.0 (2019-12)

solution proposed does not need the alignment between gNB's DL and UL frame, illustrated in Figure 6.2.1-2, where
the UE applies a UE specific differential TA and a common TA offset in the gNB's DL and UL frame timing exists.
However, for the solution illustrated in Figure 6.2.1-2, additional complexity is needed at network side to manage
corresponding scheduling timing for this scenario. Various NR physical layer timing relationships need to be enhanced
to cope with the large offset in the UE's DL and UL frame timing.

Figure 6.2.1-1: An illustration of large TA in NTN that results in a large offset in the UE's DL and UL
frame timing

Figure 6.2.1-2: An illustration of TA in NTN that results in a large offset in the gNB's DL and UL frame
timing

6.2.1.1 Background
The existing NR timing relationships are described as follows.

● PDSCH reception timing: When the UE is scheduled to receive PDSCH by a DCI, the DCI indicates the slot

offset among other things. The slot allocated for the PDSCH is , where is the slot with
the scheduling DCI, is based on the numerology of PDSCH, and and are the subcarrier
spacing configurations for PDSCH and PDCCH, respectively. The value of is in the range of 0, …, 32.

● Transmission timing for PUSCH scheduled by DCI: When the UE is scheduled to transmit PUSCH by a DCI,

the DCI indicates the slot offset among other things. The slot allocated for the PUSCH is ,
where is the slot with the scheduling DCI, is based on the numerology of PUSCH, and and
are the subcarrier spacing configurations for PUSCH and PDCCH, respectively. The value of is in the range
of 0, …, 32.

● Transmission timing for PUSCH scheduled by RAR grant: With reference to slots for a PUSCH transmission
scheduled by a RAR UL grant, if a UE receives a PDSCH with a RAR message ending in slot for a

3GPP
Release 16 63 3GPP TR 38.821 V16.0.0 (2019-12)

corresponding PRACH transmission from the UE, the UE transmits the PUSCH in slot , where
and are provided in TS 38.214.

● Transmission timing for HARQ-ACK on PUCCH: With reference to slots for PUCCH transmissions, for a
PDSCH reception ending in slot or a SPS PDSCH release through a PDCCH reception ending in slot , the
UE provides corresponding HARQ-ACK information in a PUCCH transmission within slot , where is
a number of slots and is indicated by the PDSCH-to-HARQ-timing-indicator field in the DCI format, if present,
or provided by dl-DataToUL-ACK. corresponds to the last slot of the PUCCH transmission that overlaps
with the PDSCH reception or with the PDCCH reception in case of SPS PDSCH release.

● MAC CE action timing: When the HARQ-ACK corresponding to a PDSCH carrying a MAC-CE command is
transmitted in slot , the corresponding action and the UE assumption on the downlink configuration indicated
by the MAC-CE command shall be applied starting from the first slot that is after slot
, where denotes the number of slots per subframe for subcarrier spacing
configuration .

● Transmission timing for CSI on PUSCH: The transmission timing of CSI on PUSCH follows the general
transmission timing for DCI scheduled PUSCH.

● CSI reference resource timing: The CSI reference resource for a CSI report in uplink slot is defined by a

single downlink slot , where . Here, and are the subcarrier spacing
configurations for DL and UL, respectively. The value of depends on the type of CSI report and is
defined in TS 38.214.

● Aperiodic SRS transmission timing: If a UE receives a DCI triggering aperiodic SRS in slot n, the UE

transmits aperiodic SRS in each of the triggered SRS resource set(s) in slot , where k is
configured via higher layer parameter slotOffset for each triggered SRS resources set and is based on the
subcarrier spacing of the triggered SRS transmission, and are the subcarrier spacing configurations
for triggered SRS and PDCCH carrying the triggering command respectively.

The existing NR timing definitions involving DL-UL timing interaction may not hold when there is a large offset in the
UE's DL and UL frame timing in NTN. Thus, the timing relationships need to be enhanced.

6.2.1.2 Enhancements
The PDSCH reception timing is defined solely from DL timing perspective. It is not impacted by the large offset in the
UE's DL and UL frame timing and thus enhancement is not needed.

The other timing relationships described in Section 6.2.1.1involve DL-UL timing interaction and thus need to be
enhanced for NTN. The enhancement can be to introduce an offset and applying it to modify the relevant timing
relationships.

● For the transmission timing of DCI scheduled PUSCH (including CSI on PUSCH), the slot allocated for the

PUSCH can be modified to be .

● For the transmission timing of RAR grant scheduled PUSCH, the UE transmits the PUSCH in slot
.

● For the transmission timing of HARQ-ACK on PUCCH, the UE provides corresponding HARQ-ACK
information in a PUCCH transmission within slot .

● For the MAC CE action timing, the corresponding action and the UE assumption on the downlink configuration
indicated by the MAC-CE command shall be applied starting from the first slot that is after slot
, where the value of may depend on NTN UE
capability and may not necessarily be equal to . How to determine the value of is for further study.

3GPP
Release 16 64 3GPP TR 38.821 V16.0.0 (2019-12)

● For the CSI reference resource timing, the CSI reference resource is given in the downlink slot
.

● For the transmission timing of aperiodic SRS, the UE transmits aperiodic SRS in each of the triggered SRS

resource set(s) in slot .

The values of may be different for each of the identified timing relationships that need to be modified for NTN.

The values of can be per beam or per-cell. It is for further study whether is derived from broadcast
information or is signalled by higher layers. The possibility of extending the range K 1 and/or K2 beyond what is
supported in NR Rel-15 can be further discussed when the specifications are developed.

6.2.2 Uplink power control

The following uplink power control solutions were discussed during the study item phase:

● One source [29] proposed beam-specific configuration for power control parameter and common
parameter for all beams;

● Two sources ([30] and [31]) proposed UE prediction of its own transmission power using other available
information such as satellite ephemeris and UE trajectory

● One source ([32]) proposed adaptive uplink power control based on adaptive UE configuration of Layer 3 filter
coefficients (i.e., configuring multiple Layer 3 filter coefficients and letting UE select one of the Layer 3 filter
coefficients based on measured RSRP).

● One source [33] proposed that UE can be configured with different uplink power control parameters such as P0
and alpha parameters for disabled and enabled HARQ processes.

● One source [31] proposed that the transmission power of different UEs can be adjusted as a group with a
reference UE transmission power. In addition, the source proposed a mechanism to disable closed loop power
control.

The above optimizations were discussed without any convergence one particular solution. As a result, it was concluded
that NR Release-15 power control schemes can be used for NTN.

6.2.3 AMC and delayed CSI feedback

Two sources ([32] and [34]) contributed link-level simulation results to show the effect of increased CSI feedback delay
(i.e., CSI aging) on throughput performance. The observations from these results are summarized below:

● Observation 1: For NTN-TDL-C (LOS) channel model, the two sources ([32] and [34]) show that the
performance loss due to CSI aging is low to marginal. For instance, at an SNR of 10 dB at a UE speed of 3
km/hr,

- Source 1 [32] results show that there is a throughput loss of around 10% as the feedback delay increases from
6 ms to 40 ms, and

- Source 2 [34] results show that the spectral efficiency degrades by around 12% as the feedback delay
increases from 6 ms to 46 ms.

● Observation 2: For NTN-TDL-A (NLOS) channel model, the two sources ([32] and [34]) show that the
performance loss is more significant. For instance, at an SNR of 10 dB at a UE speed of 3 km/hr,

- Source 1 [32] results show that there is a throughput loss of around 38% as the feedback delay increases from
6 ms to 40 ms, and

- Source 2 [34] results show that the spectral efficiency degrades by around 28% as the feedback delay
increases from 6 ms to 46 ms.

3GPP
Release 16 65 3GPP TR 38.821 V16.0.0 (2019-12)

● Observation 3: For NTN-TDL-A (NLOS) channel model, Source 1 [32] shows that the performance loss
saturates beyond a certain feedback delay for a given UE speed. For instance, the throughput loss saturates
beyond 40 ms feedback delay at a UE speed of 3 km/hr.

● Observation 4: For both NTN-TDL-C (LOS) and NTN-TDL-A (NLOS) channel models, Source 1 [32] shows
that with a UE speed of 30 km/hr, there is almost no observable performance loss as the feedback delay increases
from 6 ms to 201 ms.

Based on the above results from the two sources ([32] and [34]), it is concluded that the performance loss due to
increased CSI feedback delay depends on both the channel conditions as well as the UE speed:

● In LOS conditions, results from two sources show that the performance loss due to CSI aging is low to marginal
at a UE speed of 3 km/hr.

● In NLOS conditions, results from two sources show that the performance loss due to CSI aging is significant at a
UE speed of 3 km/hr.

● In both LOS and NLOS conditions, results from one source show that there is no observable performance loss
due to CSI aging at a UE speed of 30 km/hr.

One solution to address the issue of performance losses due to CSI aging that was evaluated is based on CSI reporting
with channel averaging to capture the long-term fading. This solution was evaluated by two sources ([32] and [34]) to
show the effect of channel averaging on the performance when there is large CSI feedback delay. The evaluations
results show the following observation:

● At 3 km/hr UE speed with ideal channel estimation, channel averaging to capture long-term fading does not
improve throughput compared to the case with no channel averaging.

Based on the above results, the following is concluded regarding the effect of channel averaging on the performance
when there is large CSI feedback delay:

Based on results from two sources ([32] and [34]), channel averaging to capture long-term fading does not improve
throughput compared to the case with no channel averaging at a UE speed of 3 km/hr with ideal channel estimation.

A second solution to address the issue of performance losses due to CSI aging that was evaluated is uses CSI
prediction-based link adaptation. Two sources ([35] and [34]) provided additional simulation results to show the effect
of CSI prediction on throughput performance. These evaluations show the following observation:

● Performance gains can be achieved with the introduction of CSI feedback with prediction when compared to CSI
feedback without prediction.

- For NTN-TDL-A (NLOS) channel model, Source 2 [34] results show that the spectral efficiency can be
improved by 10% at an SNR of 10 dB and a UE speed of 3 km/hr.

- For NTN-TDL-B (NLOS) channel model, Source 3 ([35]) results show a 10% throughput improvement at an
SNR of 10 dB and a UE speed of 3 km/hr.

During discussions related to prediction-based CSI, some sources were of the view that this can be achieved via
implementation without any specification impact. One source was of the view that prediction-based CSI may involve
specification impact (e.g., UE reports additional parameters, e.g., variant rate of CQI, in CSI). Based on the above
results, the following is concluded regarding the effect of prediction-based CSI on the performance when there is large
CSI feedback delay:

Based on results from two sources under NLOS conditions, CSI prediction improves throughput compared to the case
with no CSI prediction.

● CSI prediction can be achieved via implementation and there is no consensus on specification changes with
respect to CSI prediction enhancements for NTN.

A few other solutions were discussed but there were no evaluation results available for these solutions. The solutions
without evaluation results are given below:

● Introduction of finer granularity of CQI to allow more accurate choice of MCS on a stable LoS channel proposed
by two sources ([36] and [37]).

3GPP
Release 16 66 3GPP TR 38.821 V16.0.0 (2019-12)

● Introduction of new BLER targets for CQI reporting in order to limit number of retransmissions and thereby
latency proposed by three sources ([38], [39] and [36]).

● Application of a lower modulation order and coding rate than that based on the reported CQI values by the gNB
to guarantee the reliability at the potential cost of spectrum efficiency [31], [33]

● Introduction of a CQI report disabling mechanism based on certain conditions such as satellite and/or UE
location and speed, channel condition, etc. For example, if the distance between the UE and the satellite is very
large and/or the propagation delay is larger than a certain threshold, CQI reporting is disabled [31].

Based on the results and discussion, the following is concluded for AMC and delayed CSI feedback:

The CSI framework specified in NR Rel-15 can be used for NTN link adaptation at least for LOS scenarios. Further
optimizations were discussed without any convergence on particular solutions.

6.2.4 Beam management and polarization support

The proposals for beam management in NTN that were discussed during study phase are summarized below:

● Two sources ([40], [34]) proposed that for frequency reuse 1, rel-15 beam management can be used. For
frequency reuse > 1, it was proposed that two Rel-15 based schemes are possible: (1) where one BWP is used for
each satellite beam (proposed in [40] and [34]), and (2) where one component carrier is used per satellite beam
(proposed in [40]).

● One source [41] proposed to consider additional beam management CSI-RS configurations to support different
satellite implementation needs.

● One source [42] proposed to introduce a mechanism where the both the Uplink and Downlink BWPs are
switched simultaneously using a single DCI to support fast satellite beam switching.

● One source [29] proposed that the concept of BWP can be used for frequency resource allocation among NTN
beams, and that the network may configure a specific active BWP for UEs in a beam.

● One source [35] proposed to increase the number of BWPs for NTN.

The proposed solutions for beam management for NTN were quite diverse and convergence to one particular solution
was not possible at the conclusion of the study phase. Hence, the following conclusion was drawn for NTN beam
management:

The rel-15/16 beam management and BWP operation are considered as baseline for NTN. Beam management and BWP
operation for NTN with frequency reuse should be discussed further when specifications are developed.

Note that service link switching is seen as a part of beam management mechanism in NR NTN.

Another issue raised several sources is on polarization mode configuration/signalling. In NTN networks, neighbouring
cells may use different polarization modes (RHCP and LHCP) to mitigate inter-cell interference. Furthermore, there
may be UEs with different antenna types. Some UEs may be equipped with linearly polarized antennas, while some
other UEs may be equipped with circularly polarized antennas. Three sources ([32], [35], and [40]) proposed that it is
beneficial to signal the polarization mode for NTN in certain scenarios (particularly when the UE is capable of
differentiating RHCP and LHCP with the circularly or linearly polarized antennas). Based on the discussion, the
following is concluded:

Signalling of polarization mode is beneficial for NTN in certain scenarios. Whether to support the signalling can be
discussed further when specifications are developed.

6.2.5 Impact of feeder link switch

For the issue of feeder link switch and its potential impact on PHY layer procedures, the following conclusion is made:

Impacts of feeder link switch on physical layer procedures can be further discussed when specifications are developed.

3GPP
Release 16 67 3GPP TR 38.821 V16.0.0 (2019-12)

6.3 Uplink timing advance/RACH procedure

6.3.1 General
The following aspects have been studied based on NR Rel-15/16 design:

1) DL synchronization via SSB

2) Random access via PRACH

3) Maintenance for UL timing advance and frequency synchronization

The evaluations and analysis are conducted considering on characteristics of satellite communication systems, e.g.,
possibly large cell coverage and high Doppler. Meanwhile, the impacts due to some typical implementations in existing
satellite systems, e.g., partial frequency pre-compensation for DL and timing post-compensation at satellite network
side, are also taken into account. According to the corresponding results, solutions and conclusions along with some
observations are presented.

6.3.2 DL synchronization
According to the simulation assumptions in Table 6.1.2-1, the performance evaluation on the DL synchronization
performance is conducted. The corresponding results from [43], [44], [45], [46], [47] are summarized in [48]. It is
observed that for DL initial synchronization, robust performance can be provided by the SSB design in Rel-15 in case
of GEO and LEO with beam specific pre-compensation of common frequency shift, e.g., conducted with respect to the
spot beam center at network side, respectively.

However, for the LEO without pre-compensation of the frequency offset, additional complexity is needed at UE
receiver to achieve robust DL initial synchronization performance based on Rel-15 SSB. No further enhancement on the
SSB is needed.

Additionally, w.r.t the performance on the DL timing/frequency tracking, no issues have been identified based on Rel-
15/16 NR design. Potential optimization can be further considered in potential normative phase if necessary.

6.3.3 Random access

According to the simulation assumptions in Table 6.1.2-2, the performance of Rel-15 PRACH design is verified in
several typical scenarios for NTN as listed in Table 6.1.2-3.

Based on the results summarized in [49], [50], it is observed that with assumption on pre-compensation of timing and
frequency offset (e.g., if UE knowledge of geo-location of the UE at the requisite level of accuracy is available) at UE
side for UL transmission, existing Rel-15 PRACH formats and preamble sequences can be reused. The necessity of
additional enhancements, e.g., repetitions and/or larger sub-carrier spacing, to ensure UL coverage can be further
discussed in the normative work.

However, in case pre-compensation of timing and frequency offset is not performed at UE side for UL transmission,
enhanced PRACH formats and/or preamble sequences should be supported with following options:

● Option-1: A single Zadoff-Chu sequence based on larger SCS, repetition number. Additional usage of CP and
Ncs can be further determined in normative work [51], [52], [53], [54].

● Option-2: A solution based on multiple Zadoff-Chu sequences with different roots [54], [55], [56]

● Option-3: Gold/m-sequence as preamble sequence with additional process, e.g., modulation and transform
precoding [57], [51]

● Option-4: A single Zadoff-Chu sequence with combination of scrambling sequence [58], [59], [51]

Further discussions to down select these candidates are needed in the normative work.

3GPP
Release 16 68 3GPP TR 38.821 V16.0.0 (2019-12)

6.3.4 Maintenance for UL timing advance and frequency synchronization

With consideration on the larger cell coverage, long round trip time (RTT) and high Doppler, enhancements are
considered to ensure the performance for timing and frequency synchronization for UL transmission.

Figure 6.3.4-1: Illustration of the TA components in NTN (For simplicity, TA offset is not
plotted.)

For the timing advance (TA) in the initial access and the subsequent TA maintenance, the following solutions are
identified with an illustration of the definition of terminology given in Figure 6.3.4-1:

● Option 1: Autonomous acquisition of the TA at UE with UE known location and satellite ephemeris.

In this way, the required TA value for UL transmission including PRACH can be calculated by the UE. The
corresponding adjustment can be done, either with UE-specific differential TA or full TA (consisting of UE
specific differential TA and common TA).
W.r.t the full TA compensation at the UE side, both the alignment on the UL timing among UEs and DL and UL
frame timing at network side can be achieved. However, in case of satellite with transparent payload, further
discussion on how to handle the impact introduced by feeder link will be conducted in normative
work. Additional needs for the network to manage the timing offset between the DL and UL frame timing can be
considered, if impacts introduced by feeder link is not compensated by UE in corresponding compensation.
W.r.t the UE specific differential TA only, additional indication on a single reference point should be signalled to
UEs per beam/cell for achieving the UL timing alignment among UEs within the coverage of the same beam/cell.
Timing offset between DL and UL frame timing at the network side should also be managed by the network
regardless of the satellite payload type.
With concern on the accuracy on the self-calculated TA value at the UE side, additional TA signalling from
network to UE for TA refinement, e.g., during initial access and/or TA maintenance, can be determined in the
normative work.
● Option 2: Timing advanced adjustment based on network indication

In this way, the common TA, which refers to the common component of propagation delay shared by all UEs
within the coverage of same satellite beam/cell, is broadcasted by the network per satellite beam/cell. The
calculation of this common TA is conducted by the network with assumption on at least a single reference point
per satellite beam/cell.
The indication for UE-specific differential TA from network as the Rel-15 TA mechanism is also needed. For
satisfying the larger coverage of NTN, extension of value range for TA indication in RAR, either explicitly or
implicitly, is identified. Whether to support negative TA value in corresponding indication will be determined in
the normative phase.
Moreover, indication of timing drift rate, from the network to UE, is also supported to enable the TA adjustment
at UE side.

3GPP
Release 16 69 3GPP TR 38.821 V16.0.0 (2019-12)

For calculation of common TA in the above two options, single reference point per beam is considered as the baseline.
Whether and how to support the multiple reference points can be further discussed in the normative work.

For the UL frequency compensation, at least for LEO system, the following solutions are identified with consideration
on the beam specific post-compensation of common frequency offset at the network side:

● Option-1: Both the estimation and pre-compensation of UE-specific frequency offset are conducted at the UE
side. The acquisition of this value can be done by utilizing DL reference signals, UE location and satellite
ephemeris.

● Option-2: The required frequency offset for UL frequency compensation at least in LEO systems is indicated by
the network to UE. The acquisition on this value can be done at the network side with detection of UL signals,
e.g., preamble.

Indication of compensated frequency offset values by the network is also supported in case that compensation of the
frequency offset is conducted by the network in the uplink and/or the downlink respectively. However, indication of
Doppler drift rate is not necessary.

The detailed signalling design for the above enhancements will be determined in the normative work.

6.4 More delay-tolerant re-transmission mechanisms

Two main aspects of more delay-tolerant re-transmission mechanisms have been studied

● Disabling of HARQ in NR NTN

● HARQ optimization in NR-NTN

HARQ Round Trip Time in NR is of the order of several milliseconds. The propagation delays in NTN are much
longer, ranging from several milliseconds to hundreds of milliseconds depending on the satellite orbit. The HARQ RTT
can be much longer in NTN. It was identified early in the study phase that there would be a need to discuss potential
impact and solutions on HARQ procedure. RAN1 has focussed on physical layer aspects while RAN2 has focused on
MAC layer aspects.

6.4.1 Disabling of HARQ in NR NTN

RAN2 made recommendation in Section 7.2.1.4 HARQ. It was discussed that when UL HARQ feedback is disabled,
there could be issues if (i) MAC CE and RRC signalling are not received by UE, or (ii) DL packets not correctly
received by UE for a long period of time without gNB knowing it.

The following were discussed without convergence on the necessity of introducing such solutions for NTN when
HARQ feedback is disabled

● Indicate HARQ disabling via DCI in new/re-interpreted field [60], [61]

● New UCI feedback for reporting DL transmission disruption and or requesting DL scheduling changes [62], [63]

The following possible enhancements for slot-aggregation or blind repetitions were considered. There is no
convergence on the necessity of introducing such enhancements for NTN.

● Greater than 8 slot-aggregation [64]

● Time-interleaved slot aggregation [65]

● New MCS table [66]

6.4.2 HARQ Optimization for NR NTN

Solutions to avoid reduction in peak data rates in NTN were discussed. One solution is to increase the number of HARQ
processes to match the longer satellite round trip delay to avoid stop-and-wait in HARQ procedure. Another solution is
to disable UL HARQ feedback to avoid stop-and-wait in HARQ procedure and rely on RLC ARQ for reliability. The

3GPP
Release 16 70 3GPP TR 38.821 V16.0.0 (2019-12)

throughput performance for both types of solutions was evaluated at link level and system level by several contributing
companies.

The observations from the evaluations performed on the effect of the number of HARQ processes on performance are
summarized as follows:

● Three sources [72][64][70] provided link-level simulations of throughput versus SNR with the following
observations:

- One source simulated with a TDL-D suburban channel with elevation angle of 30 degrees with BLER target
of 1% for RLC ARQ with 16 HARQ processes, and BLER targets 1% and 10% with 32/64/128/256 HARQ
processes. There was no observable gain in throughput with increased number of HARQ processes compared
to RLC layer re-transmission with RTT in {32, 64, 128, 256} ms.

- One source simulated with a TDL-D suburban channel with elevation angle of 30 degrees with BLER targets
of 0.1% for RLC ARQ with 16 HARQ processes, and BLER targets 1% and 10% with 32 HARQ processes.
An average throughput gain of 10% was observed with 32 HARQ processes compared to RLC ARQ with 16
HARQ processes with RTT = 32 ms.

- One source provides the simulation results in following cases with RTT = 32 ms, e.g., assuming BLER
targets at 1% for RLC ARQ with 16 HARQ processes, BLER targets 1% and 10% with 32 HARQ processes.
There is no observable gain in throughput with 32 HARQ processes compared to RLC ARQ with 16 HARQ
processes in case that channel is assumed as TDL-D with delay spread/ K-factor taken from system channel
model in suburban scenario with elevation angle 30. Performance gain can be observed with other channels,
especially, up to 12.5% spectral efficiency gain is achieved in case that channel is assumed as TDL-A in
suburban with 30° elevation angle. Moreover, simulation based on the simulation with consideration on other
scheduling operations: (i) additional MCS offset, (ii) MCS table based on lower efficiency (iii) slot
aggregation with different BLER targets are conducted. Significant gain can be observed with enlarging the
HARQ process number.

● One source [73] provided system level simulations for LEO=1200 km with 20% resource utilisation, 16 and 32
HARQ processes, 15 and 20 UEs per cell, proportional fair scheduling, and no frequency re-use. The spectral
efficiency gain per user with 32 HARQ processes compared to 16 HARQ processes depends on the number of
UEs. With 15 UEs per beam, an average spectral efficiency gain of 12% at 50% per centile is observed. With 20
UEs per cell there is no observable gain.

The following options were considered with no convergence on which option to choose:

● Option 1: Keep 16 HARQ process IDs and rely on RLC ARQ for HARQ processes with UL HARQ feedback
disabled via RRC

● Option 2: Greater than 16 HARQ process IDs with UL HARQ feedback enabled via RRC with following
consideration

- UE capability if greater than 16 HARQ process IDs

- Keep 4-bit HARQ process ID field in DCI

The following solutions were considered for greater than 16 HARQ processes keeping the 4-bit HARQ process ID field
in DCI:

● Slot number based [62], [67], [68], [60], [69]

● Virtual process ID based with HARQ re-transmission timing restrictions [61]

● Reuse HARQ process ID within RTD (time window) [69]

● Re-interpretation of existing DCI fields with assistance information from higher layers [70]

One source also considered solutions where the HARQ process ID field is increased beyond 4 bits [65]

With regards to HARQ enhancements for soft buffer management and stop-and-wait time reduction, the following
options were considered with no convergence on which, if any, of the options, to choose:

3GPP
Release 16 71 3GPP TR 38.821 V16.0.0 (2019-12)

● Option 1: Pre-active/pre-emptive HARQ to reduce stop-and-wait time [71], [66]

● Option 2: Enabling / disabling of HARQ buffer usage configurable on a per UE and per HARQ process [67],
[64], [69]

● Option 3: HARQ buffer status report from the UE [67]

The number of HARQ processes with additional considerations for HARQ feedback, HARQ buffer size, RLC feedback,
and RLC ARQ buffer size should be discussed further when specifications are developed.

3GPP
Release 16 72 3GPP TR 38.821 V16.0.0 (2019-12)

7 Radio protocol issues and related solutions

7.1 Requirements and key issues

7.1.1 Delay
In order to reduce the standardization work, the table here below identifies the worst case NTN scenarios to be
considered for the delay constraint.

Table 7.1-1: NTN scenarios versus delay constraints, Source [2]

NTN scenarios A B C1 C2 D1 D2
GEO transparent GEO regenerative LEO transparent LEO regenerative payload
payload payload payload
Satellite altitude 35786 km 600 km
Relative speed of
Satellite with respect to negligible 7.56 km per second
earth
Min elevation for both
10° for service link and 10° for feeder link
feeder and service links
Typical Min / Max NTN
beam foot print diameter 100 km / 3500 km 50 km / 1000 km
(note 1)
Maximum propagation
delay contribution to the
541.46 ms (Worst
Round Trip Delay on the 270.73 ms 25.77 ms 12.89 ms
case)
radio interface between
the gNB and the UE
Minimum propagation
delay contribution to the
Round Trip Delay on the 477.48 ms 238.74 ms 8 ms 4 ms
radio interface between
the gNB and the UE
Maximum Delay
variation as seen by the Up to +/- 40 µs/sec
Negligible Up to +/- 20 µs/sec
UE (Worst case)
(note 2)
NOTE 1: The beam foot print diameter are indicative. The diameter depends on the orbit, earth latitude, antenna design,
and radio resource management strategy in a given system.
NOTE 2: The delay variation measures how fast the round trip delay (function of UE-satellite-NTN gateway distance)
varies over time when the satellite moves towards/away from the UE. It is expressed in µs/s and is negligible
for GEO scenario
NOTE 3: Void
NOTE 4: Speed of light used for delay calculation is 299792458 m/s.

When several non-terrestrial network scenarios feature a maximum in terms of delay constraints, it is sufficient to study
only one of these scenarios.

● NTN Scenario based on GEO with transparent payload for RTD and delay difference constraints

● NTN Scenario based on LEO with transparent payload and moving beams for the delay variation related
constraint

As per the duplex mode:

● Down-prioritize TDD in this study item

● There is no TDD-specific timing requirements and solutions on layer 2 due to propagation delay.

3GPP
Release 16 73 3GPP TR 38.821 V16.0.0 (2019-12)

7.2 User plane enhancements

7.2.1 MAC

7.2.1.1 Random Access

7.2.1.1.1 4-Step RACH Procedure

7.2.1.1.1.1 RACH capacity evaluation

The Physical Random Access Channel (PRACH) uses Slotted Aloha as access method. The PRACH preamble collision
probability between contending system access attempts on a PRACH radio resource is calculated as:

Where M is the number of configured access opportunities per second, and is the random access arrival rate per
second.

The random access capacity can be calculated by looking at the random access opportunities, the collision probability
supported, the frequency used for frequent multiplexing and how many preambles that are configured for each random
access opportunities.

If we denote the maximum number of PRACH opportunities per second as , which is given by the PRACH
configuration, such as preamble format, PRACH configuration index as well as whether the spectrum is paired/unpaired
and whether it is for FR1 or FR2, as shown in Table 6.3.3.2-2 to Table 6.3.3.2-4 in [TS 38.211].

Furthermore the PRACH occasions may be frequency multiplexed by up to different locations in frequency for
the same PRACH occasion in time. Then the M as mentioned above is computed as:

Where is the number of configured preambles available, where the maximum value is 64.

The number of the random access arrival rate per second supported is thus:

The supported user densities UE density is thus given by:

As an example, for PRACH configuration 27 the slots that are available in an SFN are the slots 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
giving 1000 PRACH opportunities per second. In the table below some more examples are given for FR1 paired:

Note that all the PRACH format used in the calculation are given as an example and it is up to RAN1 to discuss and
decide the applicable PRACH format in NTN.

Table 7.2.1.1.1.1-1: Examples of PRACH configuration for PR1 paired

Freq range and Preamble PRACH Config Index PRACH opportunities per second ( )
config format
FR1 paired 0 0 6,25
FR1 paired 0 21 200
FR1 paired 0 27 1000
FR1 paired 2 41 100

3GPP
Release 16 74 3GPP TR 38.821 V16.0.0 (2019-12)

Given the collision rate being 0.01, the number of configured preambles for CBRA being 56, preamble format 0,
PRACH config index 27, we get the following as an example:

Table 7.2.1.1.1.1-2: Supported UE density for typical GEO and LEO cell

Coverage (km2) RACH per second per UE Supported UE

density
650000 (hex with r=500km) 1.157 * 10-5 (= 1 time per day per UE) ~596 UE/km2
650000 2.78 * 10-4 (= 1 time per hour per UE) ~25 UE/km2
650000 0.0017 (= 1 time per 10 min per UE) ~4 UE/km2
GEO
162500 (hex with r=250km) 1.157 * 10-5 (= 1 time per day per UE) ~2383 UE/km2
162500 2.78 * 10-4 (= 1 time per hour per UE) ~99 UE/km2
162500 0.0017 (= 1 time per 10 min per UE) ~16 UE/km2
26000 (hex with r=100km) 1.157 * 10-5 (= 1 time per day per UE) ~14893 UE/km2
26000 2.78 * 10-4 (= 1 time per hour per UE) ~620 UE/km2
26000 0.0017 (= 1 time per 10 min per UE) ~101 UE/km2
LEO
6500 (hex with r=50km) 1.157 * 10-5 (= 1 time per day per UE) ~59571 UE/km2
6500 2.78 * 10-4 (= 1 time per hour per UE) ~2479 UE/km2
6500 0.0017 (= 1 time per 10 min per UE) ~405 UE/km2

7.2.1.1.1.2 4-step RACH enhancements for Non-Terrestrial Networks

Enhancement to preamble detection

Problem Statement

In NTN, differential delay could be experienced by two UEs within the same cell. As a result, the preambles sent by
different UEs in the same RACH occasion (RO) may reach the network at different time. As shown in Figure
7.2.1.1.1.2-1, to make sure the network can receive preambles from all the UEs, the preamble receiving window should
start from [RO timing + minimum one way delay * 2] and end with [RO timing +maximum one way delay * 2].

Figure 7.2.1.1.1.2-1: Preamble receiving window in NTN

When a preamble is received, the network needs to know which RO the preamble is related to in order to estimate the
accurate timing advance. If the RO periodicity is not long enough, as shown in Figure 7.2.1.1.1.2-2, the preamble
receiving windows for two consecutive ROs maybe overlapped with each other, making it difficult for the network to
link the received preamble to the corresponding RO.

3GPP
Release 16 75 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 7.2.1.1.1.2-2: Ambiguity on preamble reception at the network side

Possible solutions:

1) Proper PRACH configuration in the time domain. The interval between two consecutive RO should be larger
than 2 * the maximum delay difference within the cell.

2) Preamble division. Preambles should be divided into groups and mapped to different RO, such that ROs with
timing separation less than 2 * maximum delay difference are always assigned with different groups of
preambles.

Frequency hopping can also be studied, e.g., network uses frequency hopping of preambles to identify the RO based on
the specific frequency band in which the preamble is received.

Solutions related to 2-step RACH can also be studied when the 2-step RACH procedure is more stable. For the case
when 2-step RACH is used, assistance information, e.g., SFN index can be included in MsgA to help network link the
received preamble to the corresponding RO.

Based on the current specs, the ambiguity of preamble reception can only be avoided by solution (1), i.e. proper
configuration of RACH resource, in which case the time interval between two consecutive RO is larger than the
maximum delay difference*2 within the cell.

The typical cell size and the corresponding maximum delay difference*2 are given as follows:

Table 7.2.1.1.1.2-1: Maximum delay difference*2 for typical GEO and LEO cell

Typical cell size Maximum delay difference*2

1000 km 6.44ms
GEO
500km 3.26ms
LEO600:1.306ms
200 km
LEO1200: 1.308ms
LEO
LEO600: 0.654ms
100 km
LEO1200:0.654ms

Referring to Table 6.3.3.2-2 to Table 6.3.3.2-3 in TS 38.211, only limited PRACH configuration can meet the
requirement on RO interval at time domain, which can significantly impact the RACH density to be supported in time
domain.

For a typical GEO cell (1000km in size), the time interval between two consecutive RO should be larger than 6.44ms.
For a typical GEO cell (500km in size), the time interval between two consecutive RO should be larger than 3.26ms.
While for a typical LEO cell (200km or 100km in size), the time interval between two consecutive RO should be larger
than 1.308ms and 0.654ms, respectively. Examples of potential PRACH configurations for a typical GEO or LEO cell
are given as follows:

Note that all the PRACH format used in the calculation are given as an example and it is up to RAN1 to discuss and
decide the applicable PRACH format in NTN.

3GPP
Release 16 76 3GPP TR 38.821 V16.0.0 (2019-12)

Table 7.2.1.1.1.2-2: Examples of feasible PRACH configurations for a typical GEO or LEO cell

PRACH opportunities per second (

Freq range Preamble PRACH
Cell size
and config format Config Index )
FR1 paired 0 16 100
1000km FR1 paired 1 44 100
FR1 paired 2 58 100
GEO
FR1 paired 0 19 200
500km FR1 paired 1 47 200
FR1 paired 3 78 200
FR1 paired 0 25 500
200km
FR1 paired 3 84 500
LEO
FR1 paired 0 27 1000
100km
FR1 paired 3 86 1000

Given the collision rate being 0.01, the number of configured preambles for CBRA being 56, preamble format 0,
PRACH config index 8, we get the following as an example:

Table 7.2.1.1.1.2-3: Supported UE density for typical GEO and LEO cell when the time interval
between two consecutive RO is larger than the maximum delay difference*2 within the cell

Coverage (km2) RACH per second per UE Supported UE density

650000 (hex with r=500km) 1.157 * 10-5 (= 1 time per day per UE) ~60 UE/km2
650000 2.78 * 10-4 (= 1 time per hour per UE) ~2 UE/km2
650000 0.0017 (= 1 time per 10 min per UE) ~0 UE/km2
GEO
162500 (hex with r=250km) 1.157 * 10-5 (= 1 time per day per UE) ~477 UE/km2
162500 2.78 * 10-4 (= 1 time per hour per UE) ~20 UE/km2
162500 0.0017 (= 1 time per 10 min per UE) ~3 UE/km2
26000 (hex with r=100km) 1.157 * 10-5 (= 1 time per day per UE) ~7446 UE/km2
26000 2.78 * 10-4 (= 1 time per hour per UE) ~310 UE/km2
26000 0.0017 (= 1 time per 10 min per UE) ~51 UE/km2
LEO
6500 (hex with r=50km) 1.157 * 10-5 (= 1 time per day per UE) ~59571 UE/km2
6500 2.78 * 10-4 (= 1 time per hour per UE) ~2479 UE/km2
6500 0.0017 (= 1 time per 10 min per UE) ~405 UE/km2

Enhancement to random access response window

Problem Statement

After transmitting the Random Access Preamble (Msg1), the UE monitors the PDCCH for the Random Access
Response (RAR) message (Msg2). The response window (ra-ResponseWindow) starts at a determined time interval
after the preamble transmission. If no valid response is received during the ra-ResponseWindow, a new preamble is
sent. If more than a certain number of preambles have been sent, a random access problem will be indicated to upper
layers. [75]

In terrestrial communications, the RAR is expected to be received by the UE within a few milliseconds after the
transmission of the corresponding preamble. In NTN the propagation delay is much larger and therefore, so the RAR
cannot be received by the UE within the specified time interval specified for terrestrial communications. Therefore, the
behaviour of ra-ResponseWindow should be modified to support NTN.

Possible Solution

Introduce an offset for the start of the ra-ResponseWindow for NTN. The offset shall be configurable to accommodate
different scenarios.

In addition to delaying the start of ra-ResponseWindow, it is worth considering whether an extension of ra-
ResponseWindow is necessary to support NTN. In NTN the propagation delay is much larger than in terrestrial
networks. Therefore, the RAR cannot be received by the UE within the time interval, of ra-ResponseWindow, having
values specific to terrestrial networks.

For UE with location information, if the exact round trip delay can be estimated as an offset to delay the ra-
ResponseWindow, there appears to be no need for extending the ra-ResponseWindow.

3GPP
Release 16 77 3GPP TR 38.821 V16.0.0 (2019-12)

For UE without location information, the exact round trip delay cannot be computed to deduct the accurate offset of the
ra-ResponseWindow.

Figure 7.2.1.1.1.2-3 illustrates a worst case in which a UE with minimum one way transmission delay and a UE with
maximum one way transmission delay (e.g. locates at cell edge) initiate random access using the same time-frequency
resource.

Figure 7.2.1.1.1.2-3: RAR window in NTN

Assuming the configured offset to delay the start of the RAR window equals to 2 * minimum delay and neglecting the
process delay between reception of preamble and transmission of RA Response at gNB side, it can be observed that the
RAR monitoring duration shall cover at least 2 * maximum differential delay. Otherwise RAR for UE will fall out of
RAR window. The maximum differential delay is defined as maximum one way delay minus minimum one way delay.
Furthermore, time flexibility is required for the NW to schedule the RARs which means several milliseconds should be
added on top of the 2 * maximum differential delay.

Note that the maximum differential delay within one cell is 10.3ms for GEO and 3.18ms for LEO. For GEO case, 2 *
maximum differential delay = 20.6ms > 10ms. For LEO, 2 * maximum differential delay = 6.36 ms < 10 ms. Thus, for
UE without location information, extension of the ra-ResponseWindow is required and can be applied in both GEO and
LEO.

When the ra-ResponseWindow is extended, including LSBs of SFN in Msg2 can be a baseline in NTN. Whether to
modify the RA-RNTI calculation formula or define some parameters in the formula can be discussed in WI phase.

Enhancement to contention resolution timer

Problem Statement

When the UE sends an RRC Connection Request (Msg3), it will monitor for Msg4 in order to resolve a possible
random-access contention. The ra-ContentionResolutionTimer starts after Msg3 transmission. The maximum
configurable value of ra-ContentionResolutionTimer is large enough to cover the Round Trip Delay in NTN. However,
to save UE power, the behavior of ra-ContentionResolutionTimer should be modified to support NTN.

Possible Solution

Introduce an offset for the start of the ra-ContentionResolutionTimer for NTN.

Enhancement to timing advance

Problem Statement

3GPP
Release 16 78 3GPP TR 38.821 V16.0.0 (2019-12)

Timing Advance (TA) is used to adjust the uplink frame timing relative to the downlink frame timing. As shown in
Figure 7.2.1.1.1.2-4 (b), the DL and UL timing is aligned at gNB with timing advance. The timing advance is twice the
value of the propagation delay. Different UEs usually have different timing advance.

Figure 7.2.1.1.1.2-4: Timing alignment at gNB side

The timing advance is derived from the UL received timing and sent by the gNB to the UE. UE uses the timing advance
to advance/delay its timings of transmissions to the gNB so as to compensate for propagation delay and thus time align
the transmissions from different UEs with the receiver window of the gNB. There are two possible ways for gNB to
provide timing advance to UE:

(1) Initial timing advance during random access procedure: gNB derives the timing advance by measuring the
received random access preamble and sends the value to UE via the Timing Advance Command field in MAC RAR
[75].

R Timing Advance Command Oct 1

Timing Advance Command UL Grant Oct 2

UL Grant Oct 3

UL Grant Oct 4

UL Grant Oct 5

Temporary C-RNTI Oct 6

Temporary C-RNTI Oct 7

Figure 7.2.1.1.1.2-5: MAC RAR

In NR, Uplink frame number for transmission from the UE shall start before the start of the
corresponding downlink frame at the UE [TS 38.213].

3GPP
Release 16 79 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 7.2.1.1.1.2-6: Uplink-downlink timing relation

is provided in SIB1 with the following possible values:

n-TimingAdvanceOffset ENUMERATED { n0, n25600, n39936 } OPTIONAL, -- Need S

In case of random access response, a timing advance command, for a TAG indicates values by index values
of = 0, 1, 2, ... , 3846, where an amount of the time alignment for the TAG with SCS of kHz is
. is defined in [TS 38.211] and is relative to the SCS of the first uplink transmission from
the UE after the reception of the random access response.

, where Hz and
.

The maximum timing advance in NR which can be compensated during initial access is calculated in the following
Table.

Table 7.2.1.1.1.2-4: Maximum timing advance compensated during initial access for different SCS

SCS = kHz Maximum timing advance

compensated during initial
access
0 15 2ms
1 30 1ms
2 60 0.5ms
3 120 0.27ms
4 240 0.15ms

(2) Timing advance refinement in RRC_CONNECTED: gNB derives the timing advance by measuring the UL
transmission and refines the timing advance via the Timing Advance Command MAC CE.

TAG ID Timing Advance Command Oct 1

Figure 7.2.1.1.1.2-7: Timing Advance Command MAC CE

The timing advance command, , for a TAG indicates adjustment of a current value, , to the new
value, , by index values of = 0, 1, 2,..., 63, where for a SCS of kHz,
[ TS 38.213].

The maximum timing advance which can be adjusted via Timing Advance Command is calculated in the following
table:

3GPP
Release 16 80 3GPP TR 38.821 V16.0.0 (2019-12)

Table 7.2.1.1.1.2-5: Maximum timing advance adjusted via Timing Advance Command

Fehler! Es ist
nicht möglich,
durch die
Bearbeitung
von
SCS = Fehler! Es ist
Feldfunktionen
nicht möglich, durch
Objekte zu
die Bearbeitung von Maximum timing advance compensated via
erstellen.Fehler
Feldfunktionen Timing Advance Command
! Es ist nicht
Objekte zu erstellen.
möglich, durch
kHz
die Bearbeitung
von
Feldfunktionen
Objekte zu
erstellen.
0 15 0.017ms
1 30 0.008ms
2 60 0.004ms
3 120 0.002ms
4 240 0.001ms

As mentioned above, the timing advance is twice the propagation delay. In NTN, the maximum round trip delay is
541.46ms for GEO and 25.77ms for LEO. The timing advance in NR as calculated in Table 7.2.1.1.1.2-1 and Table
7.2.1.1.1.2-2 is far from sufficient. Solutions for both UE with and without GNSS-capabilities should be considered.

Possible Solutions

As shown in Figure 7.2.1.1.1.2-8, the value of common TA is determined by d0 for regenerative payload and d0+d0_F
for bent-pipe payload while the value of UE specific TA is determined by d1-d0.

Figure 7.2.1.1.1.2-8: Common TA and UE specific TA calculation

For UE without location information, broadcasting a common TA for NTN or extending the value range of the existing
TA offset broadcast in system information is the baseline for initial timing advance during random access procedure in
NTN. Compensating the common TA at network side by implementation can be discussed in WI phase. The UE
specific TA is compensated via Timing Advance Command field in random access response.

For UE with location information, the following framework should be considered as a baseline for UE to perform initial
timing advance during 4-step random access procedure:

3GPP
Release 16 81 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 7.2.1.1.1.2-9: Framework on 4-step random access procedure for UE with location information

1) Estimation and application of the timing advance with respect to the satellite before UE sending Msg1 (i.e.
random access preamble) to the network. The details are to be decided during the work item phase, but examples
of how this can be achieved:

a. For regenerative architecture: the satellite position could be needed for UE to estimate the UE-to-satellite
delay. For acquiring the satellite position, the position may either be acquired through satellite ephemeris or
broadcasted in System Information.

b. For transparent architecture: the estimation is a bit more involved as the delay that needs to be estimated is
between the UE and the gNB interface on the ground. Some options are:

i. To broadcast the position of the satellite along with the delay from satellite to gateway where the gNB
interface is situated.

ii. Signal ephemeris along with gateway position to the UE.

iii. Signal the feeder link delay or to have the gNB to compensate feeder link delay so that UE only estimates
the service link delay.

2) In Msg2, when the UE receives the RAR, it applies a timing advance correction for the UE-based estimation.
Since the UE is now estimating the timing advance the UE may now both under- and overestimate the timing
advance, there may need to be some adjustments of the timing advance to deal with this.

3) The network schedules Msg3 without knowing the absolute value of the timing advance. This can be solved by
for instance:

c. Using the maximum propagation delay of the cell to schedule the UE.

d. Using maximum differential delay

4) Network receives Msg3 and gets to know the timing advance of the UE. At this point both UE and network are
both aware of the UE-specific timing advance.

For UE with location information, another option is that UE only compensates its specific TA when sending msg1,
where UE specific TA is determined by d1-d0. Network compensates the common TA, where the common TA is
determined by the distance between a reference point and the gNB. d1, d0 and the reference point are illustrated in
figure 7.2.1.1.1.2-8 for regenerative payload.

Broadcasting the delays in case of moving cells efficiently and avoid frequent updates will be considered during the
work item phase.

3GPP
Release 16 82 3GPP TR 38.821 V16.0.0 (2019-12)

7.2.1.1.2 2-Step RACH Procedure

2-step random access procedure, which can be helpful in mitigating the impact of the transmission delay, has been
identified to be beneficial in NTN. The following figure givens an example of 2-step RACH procedure. The MsgA of
the 2-step RACH includes a preamble on PRACH and a payload on PUSCH. After MsgA transmission, the UE
monitors for a response from the network within a configured window. If contention resolution is received successfully
in MsgB, it ends the random access procedure.

Figure 7.2.1.1.2-1: Example of 2-step RACH

The main challenge for UE with location information to perform initial timing advance during 4-step random access
procedure is that the network has to schedule Msg3 without knowing the absolute value of the initial timing advance
applied at the UE side. As a sequence, the network may have to schedule UE using the maximum propagation delay of
the cell. While in 2-step random access procedure, UE can include some assistance information in the PUSCH payload
for network to know the value of TA applied by UE. The following framework should be considered as a baseline for
UE to perform initial timing advance during 2-step random access procedure:

Figure 7.2.1.1.2-2: Framework on 2-step random access procedure for UE with location information

1. UE estimate and apply the initial timing advance before transmission of MsgA. UE will include assistance
information in the PUSCH payload for network to know the value of initial timing advance applied by UE.

2. If contention resolution is successful UE apply a timing advance correction for the UE-based estimation in
MsgB. By this time, both UE and network is aware of the final UE specific timing advance.

7.2.1.1.3 Random access enhancements to address mobility issues

3GPP
Release 16 83 3GPP TR 38.821 V16.0.0 (2019-12)

● RACH back-off indication: A back-off indication may be provided in the HO command message, with back-
off achieved via random number generation within an interval, or via explicit setting of different back-off
indications in the RACH sync reconfiguration message.

● RACH-less HO: Based on satellite ephemeris and UE location, the UE can estimate the required TA value of
the target gNB enabling the UE to perform RACH-less handover. The feasibility of this solution given the large
propagation delay and possible uncertainties in satellite/UE position can be discussed in WI phase.

● 2-step RACH: The agreements of the 2-step RACH WI will be used as baseline, and further enhancements for
NTN may be considered.

7.2.1.1.4 Co-existence with different random access capabilities

Problem Statement

If there are both UEs that have GNSS and non-GNSS capabilities and given that the random access scheme for these
might be different, then it should be possible for the network to separate the resources and control access to the network
given that the random access procedures and the resource may look very different.

Possible Solution

One possible solution is for the network to be able to configure separate resources and differentiate these based on
GNSS capabilities.

7.2.1.2 Discontinuous Reception (DRX)

Problem Statement

The Discontinuous Reception (DRX) supports UE battery saving by reducing the PDCCH monitoring time. Several
RRC configurable parameters are used to configure DRX. [75][TS38.331]

A modification of drx-LongCycleStartOffset, drx-StartOffset, drx-ShortCycle, drx-ShortCycleTimer, drx-

onDurationTimer, drx-SlotOffset and drx-InactivityTimer is not needed to support NTN for the reason that the timer
values were inspected to accommodate the RTD of NTN system.

drx-HARQ-RTT-TimerDL is the minimum duration before a downlink assignment for HARQ retransmission is expected
by the MAC entity. In terrestrial communications this is configurable in the range of a few ms, which is too small for a
communication-link with a satellite. drx-HARQ-RTT-TimerUL is the same as drx-HARQ-RTT-TimerDL just for the
uplink.[75][TS38.331]

If HARQ is supported by NTN, the handling of drx-HARQ-RTT-TimerDL and drx-HARQ-RTT-TimerUL, should be

modified to support NTN.

drx-RetransmissionTimerDL presents the maximum time until a downlink retransmission is received. The timer starts
latest after 4ms after the corresponding transmission. During this timer runs, the UE monitors the PDCCH. drx-
RetransmissionTimerUL is the same as drx-RetransmissionTimerDL just for the uplink.[75][TS38.331]

A modification of drx-RetransmissionTimerDL and drx-RetransmissionTimerUL is not needed to support NTN.

Possible Solution

If HARQ is feedback is enabled by NTN, an offset is added for drx-HARQ-RTT-TimerDL and drx-HARQ-RTT-
TimerUL to support NTN.

Problem Statement

If HARQ feedback is disabled or enabled for only a certain number of HARQ process IDs, according to [75], the UE
might be forced to monitor the PDCCH for retransmission opportunities that never will happen and thus waste energy
that reduces the battery lifetime.

Possible Solution

3GPP
Release 16 84 3GPP TR 38.821 V16.0.0 (2019-12)

A simple solution for the feedback to the transmission of DL TBs is to confirm that the current implementation of the
specification [75] does not start the drx-HARQ-RTT-TimerDL if HARQ feedback is disabled.

A simple solution for the transmission of UL TBs is to agree to have an addition to the specification [75] that the UE
should only start the drx-HARQ-RTT-TimerUL if HARQ feedback is enabled for the corresponding HARQ process. The
exact formulation can be discussed in WI phase.

Problem Statement

In NTN with long propagation delays, the UE should avoid monitoring the PDCCH and thus save energy when nothing
will be received due to long RTTs, see Figure 7.2.1.2-1. When DRX is configured, the UE is either in Active time and
continuously monitor the PDCCH, or, it is in non-Active time and allowed to save energy by not monitoring the
PDCCH. The Active time occasions are mainly controlled by network configurations but at some occasions the UE
enters Active time without the control of the network, e.g. after:

- Sending a Scheduling Request

- Replying to the RAR in Contention-Free Random Access

In both these cases, the UE would have to monitor the PDCCH for at least one RTT before any type of response is
possible to be received.

Figure 7.2.1.2-1: Example of UE-initiated active period time after sending SR

Possible Solution

A possible solution to save battery is to allow UE to discontinuously monitor the PDCCH during this time. It should
however be noted that the network may schedule the UE directly after one of the cases above. The exact details should
be discussed during the work phase.

On DRX after SR, as an example:

● UE starts offset to trigger the start of DRX active time after sending SR request on PUCCH, thus UE would not
be required to monitor SR response (i.e PDCCH) while offset is running.

The details should be addressed during the work item phase, but some examples of the case of replying to the RAR in
Contention-Free Random Access:

● the gNB may include an offset to trigger the start DRX Active time via RAR:

● The UE may have an RTT-variable configured.

3GPP
Release 16 85 3GPP TR 38.821 V16.0.0 (2019-12)

7.2.1.2.1 DRX enhancements

Problem Statement

If HARQ is disabled and HARQ blind (re)transmissions are used then the DRX procedures may have some impact, see
Figure 7.2.1.2-2.

gNB

UE
NACK NACK NACK ACK

drx-InactivityTimer (awake)

Figure 7.2.1.2-2: Example of blind HARQ (re)transmissions during drx-InactivityTimer

Possible Solution

One possible solution is to start the drx-RetransmissionTimer upon network scheduling via PDCCH so that UE can
sleep in between blind HARQ (re)transmissions.

Some possible solutions to this are:

● On drx-InactivityTimer:

- Use legacy drx-InactivityTimer in order to give gNB time to schedule blind HARQ (re)transmissions.

- Use a dedicated drx-InactivityTimer for blind HARQ (re)transmissions.

● Start of drx-RetransmissionTimerDL may have a different set of solutions:

- Can be started when the UE receives a PDCCH scheduling data.

- Can be scheduled by PDCCH, where the details can be discussed during a work-item phase.

● Start of drx-RetransmissionTimerUL should also be considered.

Problem Statement

After RTT milliseconds, as seen from the UE, the network is allowed to reuse HARQ process IDs and could start
sending DCI allocations to the UE. Since this period of time rarely will coincide with the active time of the UE DRX
cycle, the network will likely need to delay any transmission to the first available onDuration period after that RTT ms
have elapsed, introducing an extra delay on top of that introduced by the RTT of the NTN, see Figure 7.2.1.2-3.

Possible Solution/Option

This extra delay can be avoided by allowing the UE to leave its DRX state at the time when the first possible DCI could
be received on PDCCH.

Some options on this could be:

3GPP
Release 16 86 3GPP TR 38.821 V16.0.0 (2019-12)

● A longer value of drx-InactivityTimer can be configured for sufficient time for monitoring the new
transmissions. And if the NW consider there is no transmission expected, it can send UE into DRX by DRX
command to stop the monitoring of PDCCH.

● Short DRX cycle can be configured in the first few RTTs to monitor the PDCCH for new transmission and re-
transmissions, and a long DRX will be used after expiration of short DRX.

● UE could enter active time and start monitoring the PDCCH after RTT milliseconds from the oldest not yet
acknowledged transport block.

● UE could start the drx-RetransmissionTimerDL regardless of whether the data was successfully decoded or not.

NW ready to NW needs to delay packet until

send new TB first available onDuration after RTT
New DL Data onDuration
Delay due
to DRX
UE Monitors
PDCCH in Vain

drx-InactivityTimer DRX cycles

The UE should wake

RTT up here

Figure 7.2.1.2-3: Unnecessary monitoring of PDCCH and extra delay due to HARQ stalling

7.2.1.3 Scheduling Request

Problem Statement

A UE can use a Scheduling Request (SR) to request UL-SCH resources from the gNB for a new transmission or a
transmission with a higher priority. SR transmission is configured by RRC. During the prohibit timer (sr-ProhibitTimer)
is active, no further SR is initiated. [75] The sr-ProhibitTimer will at latest expire after 128ms [76] and initiate a SR.
For GEO systems the value range is not sufficient because the RTD is larger.

The sr-ProhibitTimer should be modified to support NTN.

Possible Solution

The value range of sr-ProhibitTimer should be extended to support NTN.

7.2.1.4 HARQ
The MAC sublayer supports error correction and/or repetition through HARQ as in NR Release 15. The HARQ
functionality ensures delivery between peer entities at Layer 1.

For NTN the network could disable uplink HARQ feedback for downlink transmission at the UE receiver e.g. to
support long propagation delays. Even if HARQ feedback is disabled, the HARQ processes are still configured.
Enabling / disabling of HARQ feedback is a network decision signalled semi-statically to the UE by RRC signalling.
The enabling / disabling of HARQ feedback for downlink transmission should be configurable on a per UE and per
HARQ process basis via RRC signalling.

For NTN the network could disable HARQ uplink retransmission at the UE transmitter. Even if HARQ uplink
retransmissions are disabled, the HARQ processes are still configured. The enabling / disabling of HARQ uplink
retransmission could be configurable on a per UE, per HARQ process and per LCH basis. Details can be decided in a
normative phase. And the LCP impact caused by disabling the HARQ uplink retransmission configuration can be
discussed in the WI phase.

3GPP
Release 16 87 3GPP TR 38.821 V16.0.0 (2019-12)

The network criteria of enabling / disabling HARQ feedback are not specified. Examples for possible criteria are
latency or throughput service requirements, transmission roundtrip time etc. Other criteria are not excluded. Semi-
Persistent Scheduling should to be supported for HARQ processes with enabled and disabled HARQ feedback. Details
can be decided in the WI phase.

Multiple transmissions of the same TB in a bundle (e.g. MAC schedules packets in a bundle with pdsch-
AggregationFactor > 1 in downlink and pusch-AggregationFactor > 1 in the uplink) according to NR Rel.15 are
possible and might be useful to lower the residual BLER, particularly in case HARQ feedback is disabled. Soft
combining of multiple transmissions according to NR Rel.15 is supported in the receiver. Multiple transmissions of the
same TB (e.g. MAC schedules the same TB on the same HARQ process without the NDI being toggled) are possible
and might also be useful to lower the residual BLER, particularly in case HARQ feedback is disabled. For the uplink
this behaviour can be realised within the Rel.15 specification, minor changes on the UE procedure might be needed for
the downlink transmission. Soft combining of multiple transmissions of the same TB by the MAC scheduler (e.g. MAC
schedules the same TB on the same HARQ process without the NDI being toggled) according to NR Rel.15 is
supported in the receiver.

If the feedback is disabled for a selective number (i.e. not all) of HARQ processes, the configuration parameters for
different HARQ processes may need to be different.

7.2.1.5 Uplink scheduling

7.2.1.5.1 Assignment of uplink resources

Problem Statement

The typical procedure when data arrives in the buffer is to trigger a Buffer Status Report and if the UE does not have
any uplink resources for transmitting the BSR, the UE will go on to do a Scheduling Request to ask for resources. Since
the scheduling request is only an indication telling the network that the UE requires scheduling, the network will not
know the full extent of the resources required to schedule the UE, thus first the network may typically schedule the UE
with a grant large enough to send a BSR so that the network may schedule the UE more accordingly as seen in Figure
7.2.1.5-1.

Figure 7.2.1.5-1: Scheduling of UE transmission

In non-terrestrial networks the drawback of this procedure is that it would take at least 2 Round-trip times from data
arriving in the buffer at the UE side until it can be properly scheduled with resources that would fit the data and the
required QoS. Due to the large propagation delays this may become prohibitively large.

Possible Solutions/options

In order to mitigate the problem there may be a number of possible solutions. In Table 7.2.1.5-1 some different options
in terms of their pros, cons and delays have been characterized. However the feasibility of the solutions has not been
discussed in detail and will be addressed during the work item phase.

3GPP
Release 16 88 3GPP TR 38.821 V16.0.0 (2019-12)

Table 7.2.1.5-1: Scheduling enhancement options

Scheduling option Pros Cons Delays*

- Low resource overhead - Large delays At least 2 RTTs of
SR-BSR procedure
required delay
- Potentially low resource - Still takes 2 RTTs before UE has the 1 – 2 RTTs
overhead BSR
Sending large grant
- Might be a waste in terms of
in response to SR
resources since network is still not
aware of the buffer situation of the UE
Configured grant - Low latency with right - Large overhead 0 – 1 RTT**
configuration - Trade-off between latency and
overhead
BSR-indication in - Low latency with correct - Large spec-impact 1 RTT
SR configuration - Resource overhead impact unclear,
larger than SR
BSR over 2-step - Low latency - RACH resources required 0 – 1 RTT**
random access - Low overhead
* the number of RTTs before full scheduling based on BSR can begin.
** if configured grant/2-step allocation is large enough and data can be transmitted in the grant.

7.2.2 RLC

7.2.2.1 Status Reporting

Problem Statement

A status report can be triggered by the polling procedure or by detection of reception failure of an AMD PDU which is
indicated by the expiration of t-Reassembly. This timer is started when an AMD PDU segment is received from lower
layer, is placed in the reception buffer, at least one byte segment of the corresponding SDU is missing and the timer is
not already running. The procedure to detect loss of RLC PDUs at lower layers by expiration of timer t-Reassembly is
used in RLC AM as well as in RLC UM. [TS 38.322] The timer t-Reassembly can be configured by fixed values
between 0 and 200ms [76]. For the terrestrial case this timer covers the largest time interval in which the individual
segments of the corresponding SDU have to arrive out of order at the receiver due to SDU segmentation and/or HARQ
retransmissions before a status report and consequently an ARQ-retransmission is triggered. If HARQ is supported by
NTN, an extension of the t-Reassembly timer could become necessary, because then the timer should cover the
maximum time allowed for HARQ transmission which will probably be a value larger than the RTD.

If HARQ is supported by NTN, the timer t-Reassembly should be modified to support NTN.

Possible Solution

If HARQ is supported by NTN, the value range of t-Reassembly should be extended to support NTN.

One possible solution to extend t-Reassembly would be to consider the UE-specific round-trip delay, RTD, the number
of allowed HARQ-retransmission attempts nrof_HARQ_retrans, as well as a configurable offset to account for possible
delays on UE and network-side, scheduling_offset:

t-Reassembly = RTD * nrof_HARQ_retrans + scheduling_offset

This would ensure that the HARQ delay can be correctly accounted for reassembling.

No modification of the t-PollRetransmit timer and of the t-statusProhibit timer are needed to support NTN.

7.2.2.2 RLC Sequence Numbers

3GPP
Release 16 89 3GPP TR 38.821 V16.0.0 (2019-12)

Problem statement

12bit and 18bit are specified as possible RLC AM sequence number (SN) field length in NR [TS 38.322]. The
maximum AM_Window_Size results in 131 072.

The sequence number space needed for a radio bearer depends on the data rate that is to be supported, the
retransmission time (i.e the RTD, the number of retransmissions and the scheduling delay) as well as the average size of
the RLC SDUs.

The basic formula for calculating the supportable RLC bit rate for one radio bearer is

RLC_data_rate = RLC_SDU_size ∙ 2 ^ (SN_length -1) / RetransmissionTime,

For selecting reasonable values:

● RLC_SDU_size depends entirely on the specific traffic and it is difficult to give a good estimate for a typical
SDU size. For continuous data, it is probably more likely that the RLC SDUs are bigger rather than small. Sizes
of 500 and 1500 Bytes are considered here.

● SN_length: Selecting the SN field length depends on the application, but for continuous and high-rate
applications, the SN field length should be chosen to be large.

● RetransmissionTime: In RLC, the retransmission time of RLC SDUs is dependent on the time that it takes for the
transmitting RLC entity to retransmit an RLC SDU when it is lost. RLC retransmissions are based on RLC status
reporting and these need to be scheduled the way any data need to be scheduled, thus the retransmission time
may be difficult to characterize. One simplification for the retransmission time would be retransmissionTime =
(RTD ∙ (maxRetxThreshold+1). With RTD = (25.77 ms, 541.46 ms) and maxRetxThreshold = (1, 4) we get
retransmission times (51.54 ms, 128.85 ms, 1082.92 ms, 2707.3 ms) which rounded up to account for scheduling
delays become (75 ms, 150 ms, 1.5 s, 3.0 s).

● RTD depends on the considered scenario. In GEO satellite systems 541.46ms is assumed as maximum RTD for
the transparent architecture, while in LEO satellite systems with transparent architecture 25.77 ms is assumed.

● maxRetxThreshold: In NTN, HARQ may be disabled and therefore retransmissions in the RLC layer are
essential for a reliable communication link. Nevertheless, the latency as seen by the core network or the
application becomes extremely large if too many retransmissions are being configured. The maximum number of
RLC retransmissions in NTN will be limited by interactions with higher layer and will be smaller compared to
terrestrial networks. 1 or 4 RLC retransmissions are considered here.

Table 7.2.2.2-1 and Table 7.2.2.2-2 presents supportable RLC bit rates for different sets of parameter, for GEO satellite
systems and LEO satellite systems, respectively.

Table 7.2.2.2-1: Supportable RLC bit rates for GEO satellite systems with transparent architecture

RLC_SDU_size SN_length RTD maxRetxThreshold RetransmissionTime RLC_data_rate

500Byte 18 541.46 ms 1 1.5 s 350 Mbps
1500Byte 18 541.46 ms 1 1.5 s 1 049 Mbps
500Byte 18 541.46 ms 4 3.0 s 175 Mbps
1500Byte 18 541.46 ms 4 3.0 s 524 Mbps

Table 7.2.2.2-2: Supportable RLC bit rates for LEO satellite systems with transparent architecture

RLC_SDU_size SN_length RTD maxRetxThreshold RetransmissionTime RLC_data_rate

500Byte 18 25.77 ms 1 75.0 ms 6 991 Mbps
1500Byte 18 25.77 ms 1 75.0 ms 20 972 Mbps
500Byte 18 25.77 ms 4 150.0 ms 3 495 Mbps
1500Byte 18 25.77 ms 4 150.0 ms 10 486 Mbps

Considering Table B.2-1, it is observed that the airplanes connectivity which targets an experience data rate of 360
Mbps for DL is the most challenging usage scenario for NTN in terms of data rate.

3GPP
Release 16 90 3GPP TR 38.821 V16.0.0 (2019-12)

Assuming a retransmission time of 3.0 s or 1.5 s, which represents a GEO satellite system with transparent architecture
and an RLC SDU size of 500 Byte, the NTN targeted experience data rate for usage scenario airplanes connectivity
cannot be achieved.

Assuming a retransmission time of 150 ms, which represents a LEO satellite system with transparent architecture and
an RLC SDU size of 500 Byte or larger the NTN targeted experience data rate can be achieved for the considered usage
scenarios.

Possible Solution

There are three options identified to cope with this limitation:

Option 1: The current specification is applied for NTN without any changes. The targeted experience data rate
for usage scenario airplanes connectivity may at least temporarily not be supported for the above
mentioned configurations of RLC SDU size, RLC SN field length and maximum number of RLC
retransmissions in case of GEO satellite systems with transparent architecture.

Option 2: Extending the RLC SN length.

Option 3: Reducing the delays that it takes to perform an RLC retransmission.

7.2.3 PDCP

7.2.3.1 SDU Discard

Problem Statement

The transmitting PDCP entity shall discard the PDCP SDU when the discardTimer expires for a PDCP SDU or when a
status report confirms the successful delivery [TS 38.322]. The discardTimer can be configured between 10 ms and
1500 ms or can be switched off by choosing infinity [76].

The discardTimer mainly reflects the QoS requirements of the packets belonging to a service. However, by choosing the
expiration time of the discardTimer or the QoS requirements, the RTD as well as the number of retransmissions on RLC
layer and/or HARQ shall be considered. By increasing the expiration time of discardTimer, one should keep in mind
that extended timer values will increase the amount of required memory for the buffer.

Modification of the discardTimer can be discussed in the WI phase.

7.2.3.2 Reordering and In-order Delivery

Problem Statement

In order to detect loss of PDCP Data PDUs, there is the timer t-Reordering which is started or reset when a PDCP SDU
is delivered to upper layers [TS 38.322]. The maximum configurable expiration time is 3000 ms [76]. This might limit
the overall number of retransmissions of the RLC AM ARQ protocol for NTN.

Modification of the t-Reordering timer can be discussed in the WI phase.

7.2.3.3 PDCP Sequence Number and Window Size

Problem statement

12bit and 18bit are specified as possible PDCP sequence number (SN) field length in NR [TS 38.323]. Resulting in a
maximum of 262 144 different SNs or a Window_Size of 131 072.

The sequence number space needed for a radio bearer depends on the data rate that is to be supported, the
retransmission time as well as the average size of the PDCP SDUs.

The basic formula for calculating the supportable PDCP bit rate for one radio bearer is

PDCP_data_rate = PDCP_SDU_size ∙ 2 ^ (pdcp-SN-Size -1) / PDCP_RetransmissionTime,

For selecting reasonable values:

3GPP
Release 16 91 3GPP TR 38.821 V16.0.0 (2019-12)

● PDCP_SDU_size: As the RLC_SDU_size, it depends entirely on the specific traffic and it is difficult to give a
good estimate for a typical SDU size. For continuous data, it is probably more likely that the PDCP SDUs are
bigger rather than small. In general, PDCP packets might be larger than RLC packets because of possible
segmentation in RLC layer, however, for large data rate it is assumed that they are in the same range as
RLC_SDU_size. Sizes of 500 and 1500 Bytes are considered here.

● pdcp-SN-Size: Selecting the SN field length depends on the application, but for continuous and high-rate
applications, the SN field length should be chosen to be large.

● PDCP_RetransmissionTime is the time seen by the PDCP layer between creation of the packet and registration
of successful or failed transmission. If HARQ is disabled, it mainly depends on the RLC RetransmissionTime.
(75ms, 150ms, 1.5s, 3.0s) are considered here. These numbers result from a round trip delay of RTD = (25.77ms,
541.46ms) and RLC maxRetxThreshold = (1,4), see section 7.2.2.2

Table 7.2.3.3-1 and Table 7.2.3.3-2 presents supportable PDCP bit rates for different sets of parameter, for GEO
satellite systems and LEO satellite systems, respectively.

Table 7.2.3.3-1: Supportable PDCP bit rates for GEO satellite systems with transparent architecture

PDCP_SDU_size pdcp-SN-Size PDCP_RetransmissionTime PDCP_data_rate

500 Byte 18 1.5 s 350 Mbps
1500 Byte 18 1.5 s 1049 Mbps
500 Byte 18 3.0 s 175 Mbps
1500 Byte 18 3.0 s 524 Mbps

Table 7.2.3.3-2: Supportable PDCP bit rates for LEO satellite systems with transparent architecture

PDCP_SDU_size pdcp-SN-Size PDCP_RetransmissionTime PDCP_data_rate

500 Byte 18 75 ms 6991 Mbps
1500 Byte 18 75 ms 20972 Mbps
500 Byte 18 150 ms 3495 Mbps
1500 Byte 18 150 ms 10486 Mbps

Considering Table B.2-1, it is observed that the airplanes connectivity which targets an experience data rate of 360
Mbps for DL is the most challenging usage scenario for NTN in terms of data rate.

Assuming a PDCP retransmission time of 3.0 s or 1.5 s, which represents a GEO satellite system with transparent
architecture and a PDCP SDU size of 500 Byte, the NTN targeted experience data rate for usage scenario airplanes
connectivity cannot be achieved.

Assuming a PDCP retransmission time of 150 ms, which represents a LEO satellite system with transparent architecture
and an RLC SDU size of 500 Byte or larger the NTN targeted experience data rate can be achieved for the considered
usage scenarios.

Possible Solution

There are three options identified to cope with this limitation:

Option 1: The current specification is applied for NTN without any changes. The targeted experience data rate
for usage scenario airplanes connectivity may at least temporarily not be supported for the above
mentioned configurations of PDCP SDU size, PDCP SN field length and maximum number of RLC
retransmissions in case of GEO satellite systems with transparent architecture.

Option 2: Extending the PDCP SN length.

Option 3: Reducing the delays that it takes to perform retransmissions.

3GPP
Release 16 92 3GPP TR 38.821 V16.0.0 (2019-12)

7.2.4 SDAP
The SDAP layer is responsible for the mapping between QoS flows and DRBs [9]. It is not affected by the large round
trip delays (RTD) occurring in NTN. There are no modifications needed in the SDAP layer to support non-terrestrial
networks.

7.3 Control plane enhancements

Satellite beams or satellites are not considered to be visible from UE perspective in NTN. This does not preclude
differentiating at the PLMN level the type of network (e.g. NTN vs. terrestrial).

NOTE: Rel-15 definitions are considered as a baseline for NTN

Figure 7.3-1: Options for PCI mapping into satellite beams

Both options a) same PCI for several satellite beams and b) one PCI per satellite beam, can be considered in NTN. A
satellite beam can consist of one or more SSB beams. One cell (PCI) can have maximum of L SSB beams, where L can
be 4, 8 or 64 depending on the band.

Similar to TN, one or several SSB index can be used per PCI to separate SSB transmission on different beams.

In TN, the mapping of antenna ports or physical beams to SSB index is left for implementation. In NTN, the association
between satellite beams and SSBs index is left for implementation (i.e. it will not be specified).

Two different type of UE categories are supported by NTN: 1) with GNSS support, 2) without GNSS support.

The use of satellite ephemeris, time and UE location can be used in RAN for mobility purposes.

As per tracking area:

3GPP
Release 16 93 3GPP TR 38.821 V16.0.0 (2019-12)

● For GEO, the current tracking area management is assumed as a baseline

● For LEO with moving beams study fixed and moving tracking area solutions

7.3.1 Idle mode mobility enhancements

7.3.1.1 General Tracking Area Issues [16]

Satellites may provide very large cells, covering hundreds of kilometres, and consequently would lead to large tracking
areas. In this scenario the tracking area updates (TAUs) are minimal, however the paging load could be high because it
then relates to the number of devices in the tracking area.

Moving cells and consequently moving tracking areas would be difficult to manage in the network as the contrast
between the TAU and the paging signalling load would be too extreme to find a practical compromise.

On one hand, small tracking Areas would lead to massive TAU signalling for UE at the boundary between 2 TAs as
illustrated in figure 7.3.1.1-1.

Figure 7.3.1.1-1: Moving Cells and Small tracking Areas leading to massive TAU signalling

On the other hand, wide tracking Areas would lead to high paging load in the satellite beams as illustrated in Figure
7.3.1.1-2.

Figure 7.3.1.1-2: Moving Cells and wide tracking Areas leading to higher Paging load

However, Tracking areas must be dimensioned to minimise the TAUs as this is more signalling-intensive than paging
on the network.

In practical tracking area design, one of the criteria affecting the performance and capacity is the limiting capabilities of
MME/AMF platforms and the radio channel capacity.

3GPP
Release 16 94 3GPP TR 38.821 V16.0.0 (2019-12)

Ping-pong effect generating excessive TAU, and it can be minimised by ensuring 10-20% overlaps between the
adjacent cells and appropriate allocation of TAI List to UEs especially at the edge of cells/TAs.

7.3.1.2 Moving Tracking Area for NTN LEO, Scenario C2 and D2 [17]
Moving tracking area means that the tracking area sweeps over the ground as the cells move. Due to high speed
movement of satellite, the satellite beam and therefore the cell providing coverage for an earth stationary UE will be
changed frequently. As a result, a stationary UE would have to keep performing Registration area update (can also be
called as tracking area update, i.e. TAU) in RRC_IDLE state. For each Registration area update, the UE needs to initiate
connection with the network. For Rel-15 NR this requires 4-steps of the random access procedure followed by some
RRC message exchange over the service link. This can become a non-acceptable overhead if all IDLE mode UEs in the
registration area need to perform tracking area update (TAU) frequently as the LEO satellite passes by. If the
geographical area covered by the Registration area is large, this issue may become slightly less severe. However, size of
the Registration area and paging capacity forms a trade-off as the UE may need to be paged via all cells belonging to
the Registration area and thus the paging capacity may become an issue when network initiated calls arrive.

7.3.1.3 Fixed Tracking Area for NTN LEO, Scenario C2 and D2 [17]

7.3.1.3.1 Approach 1: For the case when UE location information is unavailable

In order not to have TAU performed frequently by the UE triggered by the satellite motion, the tracking area may be
designed to be fixed on ground. For NTN LEO, this implies that while the cells sweep on the ground, the tracking area
code (i.e. TAC) broadcasted is changed when the cell arrives to the area of next planned earth fixed tracking area
location.

The TAC, or a list of TACs, broadcasted by the gNB needs to be updated as the gNB enters to the area of next planned
tracking area. When the UE detects entering a tracking area that is not in the list of tracking areas that the UE previously
registered in the network, a mobility registration update procedure will be triggered.

Figure 7.3.1.3.1-1: An example of updating TAC and PLMN ID in real-time for scenario C2 and D2

As shown in Figure 7.3.1.3.1-1, network update the broadcast TAC in real time according to the ephemeris and confirm
the broadcast TAC is associated with the geographical area covered by the satellite beam. UE listens to
TAI = PLMN ID + TAC and determines to trigger registration area update procedure based on the broadcast TAC and
PLMN ID when it moves out of the registration area.

This approach allows to use Rel-15 NR network procedures and can be applied to UE with or without location
information.

Two possible options should be studied to update the broadcast TAC:

"hard switch" option: one cell broadcast only one TAC per PLMN. The new TAC replaces the old TAC and there may
be some fluctuation at the border area. As shown in Figure 7.3.1.3.1-2, the UE will see its TAC changing like TAC-2->
TAC-1-> TAC-2 from T1 to T3.

3GPP
Release 16 95 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 7.3.1.3.1-2: TAC fluctuation at the border area

"soft switch" option: one cell can broadcast more than one TACs per PLMN. The cell adds the new TAC in its system
information in addition to the old and removes the old a bit later. If there is a chain of TAs, the TA list adds one TA
more and removes one old while the cell sweeps the ground. This also reduces the amount of TAUs for UEs that happen
to be located at the border area. However, for the "soft switch" option, the more TACs a cell broadcast, the heavier
paging load it experiences, which usually leads to a significant imbalance distribution of paging load among cells. Thus,
there is a trade-off between paging load and balancing the fluctuation of actual TA area enabled by the soft switch to be
considered in network planning and implementation.

In some area, the gNB may not be able to provide NTN service and thus not broadcast TAC(s).

7.3.1.3.2 Approach 2: For the case when UE location information is available

One possible solution is to divide the earth into a lot of geographical areas and each geographical area is mapped to a
certain TAC. During initial registration, UE derives the TAC based on its location information (the mapping rule
between the geographical area and the TAC value is kept both on UE side and network side), forms the TAI based on
the derived TAC and broadcast PLMN ID and reports the TAI to network via Registration Request message. The AMF
confirms the reported TAI and includes a TAI list as a registration area the UE is registered to in the Registration
Accept message.

When UE moves to a new geographical area, UE derives the TAC based on the location information and forms the TAI
based on the derived TAC and PLMN ID. If UE detects entering a tracking area that is not in the list of tracking areas
that the UE previously registered to, a mobility registration update procedure will be triggered. UE reports the TAI
derived by itself to network via Registration Request message. The AMF confirms the reported TAI and include a new
TAI list for the UE in the Registration Accept message. The UE, upon receiving a Registration Accept message, shall
delete its old TAI list and store the received TAI list.

7.3.1.3.3 Tracking Area recommendation

Fixed Tracking Area is recommended for the WI phase

7.3.1.4 Enhancements to idle/inactive UE mobility procedure

For the idle/inactive mode UE procedures in NTN, NR mechanism in TN system is regarded as the baseline. Regarding
the adaptation of existing procedures, followings issues were considered.

● For too frequent SI update issue, no problematic case was identified. This issue can be solved by network
implementation.

● Under earth-fixed tracking area mechanism, cells sweeping the Earth do not cause heavy signalling burden
because of frequent TAU for the LEO satellites.

● For UEs with low transmission power camping on the cell with high altitude issue, if UE is able to identify GEO
cell, it can be left for UE implementation to avoid this issue and no additional mechanism is needed.

3GPP
Release 16 96 3GPP TR 38.821 V16.0.0 (2019-12)

7.3.1.5 Mobility state estimation mechanism

For GEO satellites, the cell coverage is very large so that UE's mobility will happen very rare. For LEO satellites, the
UE's speed can be ignored compared to the speed of LEO satellites. Therefore, as use case of MSE is not clear in both
GEO and LEO case, the MSE mechanism for NTN usage is left for implementation decision.

7.3.1.6 Using ephemeris information and UE location information

Ephemeris information and UE location information can be used to help UEs perform measurement and cell
selection/reselection, in addition to PCI and frequency information included in the broadcast system information. How
to deliver and utilize the information can be defined in the WI phase.

7.3.1.7 System information broadcast

As LEO satellites are moving in predictable path, so their neighbour cell list is also predictable. The neighbour cell list
can be provided via broadcast system information, as is currently done in NR.

7.3.2 Connected mode mobility enhancements

For GEO NTN, mobility management procedures require adaptations to accommodate large propagation delay. In
particular radio link management may require specific configuration.

For LEO NTN, mobility management procedures should be enhanced to take into account satellite movement related
aspects such as measurement validity, UE velocity, movement direction, large and varying propagation delay and
dynamic neighbour cell set.

7.3.2.1 Mobility Challenges for Non-Terrestrial Networks

7.3.2.1.1 Latency associated with mobility signalling

Propagation delay in NTN is orders of magnitude higher than terrestrial systems, introducing additional latency to
mobility signalling such as measurement reporting, reception of the HO command, and HO request/ACK (if the target
cell originates from a different satellite).

The basic handover procedure is illustrated in Figure 7.3.2.1.1-1, and the processing delay in both gNB side and UE
side are marked.

3GPP
Release 16 97 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 7.3.2.1.1-1: Handover procedure

The service interruption time is defined in TR 36.881 by the time between when the UE stops transmission/reception
with the source gNB and the time when target gNB resumes transmission/reception. The interruption time is however
different regarding to uplink and downlink.

For the downlink the interruption time can be defined as the time from network sending RRCReconfiguration with sync
(Step 3) until the target gNB receives the RRCReconfigurationComplete (Step 6). Since the gNB cannot send more data
after step 3, and it can continue after it receives RRCReconfigurationComplete. For the uplink, the UE can potentially
continue sending data to the source gNB until RRCReconfiguration with sync is received, the interruption time can be
defined as the time from UE receiving RRCReconfiguration with sync (Step 3) until the target gNB receives the
RRCReconfigurationComplete (Step 6).

Without considering latencies such as RRC processing delay and UE retuning its frequency circuits (which is smaller
than the RTT), the interruption time would be 2 RTT (about 1080ms) for downlink and 1.5 RTT (about 810ms) for
uplink.

GEO scenarios are characterized by much larger propagation delay than LEO, however the latter requires consideration
of satellite movement. To avoid extended service interruption, latency associated with mobility signalling should be
addressed with high priority in both cases. Solutions developed may apply to both scenarios.

NOTE: Although such latency may result in a service interruption, it does not necessarily mean the UE will miss
the HO command.

7.3.2.1.2 Measurement Validity

Extending Rel-15 measurement-based mobility mechanisms to NTN may introduce the risk of outdated measurements
given sufficient delay between transmission of the measurement report and reception of the HO command. The
measurements may no longer be valid, possibly leading to an incorrect mobility action e.g. early/late handover.

Although LEO scenarios exhibit less propagation delay, satellite movement may have an impact on measurement
validity. Satellite ephemeris and/or UE location may be beneficial in addressing this challenge.

3GPP
Release 16 98 3GPP TR 38.821 V16.0.0 (2019-12)

Measurement validity is not anticipated to be a challenge in GEO scenarios given the large cell size/overlap, small
signal variation, and relatively low UE mobility. GEO scenarios may thus be addressed by suitable configuration using
exiting Rel-15 mechanisms.

7.3.2.1.3 Cell overlap and reduced signal strength variation

In terrestrial systems, a UE can determine it is near a cell edge due to a clear difference in RSRP as compared to cell
center. Such an effect may not be as pronounced in non-terrestrial deployments, resulting in a small difference in signal
strength between two beams in a region of overlap. As the Rel-15 handover mechanism is based on measurement events
(e.g. A3), the UE may thus have difficulty distinguishing the better cell.

gNB NTN gNB

Far-UE Far-UE

Near-UE Near-UE

Received signal strength Received signal strength

(a) Distance (b) Distance

Figure 7.3.2.1.3-1: A sketch of near-far effect in different scenarios: (a) Terrestrial Network; (b) NTN

To avoid an overall reduction in HO robustness due to the UE ping-ponging between cells, this challenge should be
addressed with high priority for both GEO and LEO scenarios.

Location information and/or satellite ephemeris would be useful in addition to measurement results, and solutions may
apply to both scenarios.

7.3.2.1.4 Frequent and unavoidable handover

Satellites in non-GEO orbits move with high speed relative to a fixed position on earth, leading to frequent and
unavoidable handover for both stationary and moving UEs. This may result in significant signalling overhead and
impact power consumption, as well as exacerbating other potential challenges related to mobility e.g. service
interruption due to signalling latency.

For a UE travelling at a constant speed and direction, the maximum time it can remain connected to a cell is
approximated by dividing the cell diameter by UE speed. For NTN LEO deployments, the cell size is divided by the
relative speed between the satellite and the UE, where a UE moving in the same direction as the satellite subtracts from
the relative speed, and a UE moving in the opposite direction increases relative speed, described by the equation below:

The scenario of cell diameter = one 50 km diameter beam will represent the lower bound (i.e. worst-case scenario for
HO frequency), and cell diameter = 1000 km will be taken as the upper bound (i.e. best-case scenario for HO
frequency).

Substituting reference values from 4.2-2 and 7.1-1 into the above equation, the maximum time a UE can remain in an
NTN cell (i.e. the UE connects immediately at cell edge and leaves at the opposite cell edge) for the min/max cell
diameter and relative speed is listed in the table below:

3GPP
Release 16 99 3GPP TR 38.821 V16.0.0 (2019-12)

Table 7.3.2.1.4-1: Time to HO for min/max cell diameter and varying UE speed

Cell Diameter Size (km) UE Speed (km/hr) Satellite Speed (km/s) Time to HO (s)
+500 6.49
-500 6.74
50 (lower bound) +1200 6.33
- 1200 6.92
Neglected 6.61
7.56 (NOTE 1)
+500 129.89
-500 134.75
1000 (upper bound) +1200 126.69
- 1200 138.38
Neglected 132.28

Neglecting UE movement, a UE served by an NTN LEO cell of diameter 50 km and 1000 km may remained connected
for a maximum of 6.61 seconds and 132.38 seconds respectively due to satellite movement. Considering UE movement,
this will vary by approximately +/- 4%. By neglecting satellite speed and setting UE speed to 500 km/hr as per table
7.1-1, this is equivalent to a terrestrial UE being served by a cell diameter ranging from approximately 0.918 km
(NOTE 2) to 18.39 km.

From the above analysis, it is concluded that HO frequency in LEO NTN can be similar to that experienced by a
terrestrial UE on a high-speed train, however this represents a worst-case scenario and is not indicative of a typical
terrestrial network. It is not anticipated that frequent HO will occur in GEO due to large cell size limiting the impact of
UE speed. It is further assumed in LEO scenarios UE speed is a negligible factor in HO frequency given the relative
speed of the satellite, and this will principally be an issue for LEO with moving beams.

NOTE 1: This value may need to be updated further pending clarification from satellite companies (e.g. if this is the
ground speed, and what altitude this value corresponds to).

NOTE 2: it is assumed that this is the minimum cell diameter possible (i.e. the UE travels directly through the full
cell diameter). Should the UE only travel through an edge portion of the coverage the cell must be larger.

7.3.2.1.5 Dynamic neighbour cell set

In non-GEO deployments satellites constantly move with respect to a fixed point on earth. Such movement may have
several implications to the UE, such as how long a candidate cell will remain valid.

Given the deterministic movement of satellites in LEO, the network may be able to compensate for the changing cell set
via existing Rel-15 mechanisms, possibly with the aid of UE location.

As GEO satellites are relatively static, dynamic neighbour cell set is not anticipated to be a challenge.

[NOTE: Enhancements, if developed, should be coordinated with cell selection/re-selection in the

IDLE/INACTIVE section]

7.3.2.1.6 Handover for a large number of UEs

Considering the large cell size of non-terrestrial networks, many devices may be served within a single cell. Depending
on constellation assumptions (e.g. propagation delay and satellite speed) and UE density, a potentially very large
number of UEs may need to perform HO at a given time, leading to possibly large signalling overhead and service
continuity challenges.

Though the actual number of UEs performing HO at a given time will vary based on UE density, a general
approximation can be made by observing the time it takes for the cell to move completely out of the original footprint
("c)" in Figure 7.3.2.1.6-1), at which point all UEs served in the cell at time T ("a)") must be handed over to a new cell.
Dividing the total number of connected UEs by the time it takes for the cell to perform this transition can thus provide a
general approximation of the average rate UEs must hand-out of a cell for a given cell diameter.

3GPP
Release 16 100 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 7.3.2.1.6-1: Transition of UEs as a cell moves completely out of original coverage area

However, as UEs are "handing-out" from the area no longer served by the cell, other UEs are also "handing-in" from the
new area of coverage (as shown in "b)"). Assuming for simplicity a relatively uniform distribution of UEs, the rate of
UEs leaving the cell will be approximately equal to the rate of UEs entering the cell. Therefore, the total mobility for
the cell (hand-in + hand-out) will be approximately 2x the rate of hand-out.

Figure 7.3.2.1.6-2: Comparison of Area requiring UEs to "hand-in" vs. "hand-out" of a cell

For the values provided in Table 7.3.2.1.6-1, the maximum number of UEs possible with the current maximum C-RNTI
value (i.e. 65519) (NOTE 1) will remain connected to the cell at all times (e.g. the rate of UEs leaving a cell is equal to
the rate of UEs entering a cell) to estimate the worst-case scenario, and UE movement is neglected.

Table 7.3.2.1.6-1: Average HO rate for a given cell diameter, assuming 65519 connected UEs (NOTE 1)

Cell Diameter Approximate Average UE Satellite Time to HO Average Average HO

(km) Cell Area (km2) density speed all UEs in cell "hand-out" Rate (in+out)
(UE/km2) (km/s) (s) rate (UE/s) (UEs/s)
50 1964 33.36 6.61 9912 19824
100 7854 8.34 13.23 4952 9904
7.56
250 49087 1.33 33.07 1981 3962
(NORE 2)
500 196000 0.33 66.14 991 1982
1000 785000 0.08 132.28 495 990

It is anticipated that the continuous movement of satellites in LEO scenarios with moving beams is the main challenge
to be addressed with priority, and that the GEO scenario will not be greatly affected due to the large cell size/overlap
and low relative UE speed.

NOTE 1: The above analysis assumes the current maximum C-RNTI value (i.e. 65519 connected UEs). This
analysis may be updated should the C-RNTI value be modified in NTN (e.g. to accommodate higher
average UE densities for large cell diameters).

NOTE 2: This value may need to be updated further pending clarification from satellite companies (e.g. if this is the
satellite speed on the ground, and what altitude this value corresponds to).

FFS: An analysis of "Peak HO rate" e.g. should the satellite move over a small area with many UEs, and how the HO
rate would change considering steerable satellite beams.

3GPP
Release 16 101 3GPP TR 38.821 V16.0.0 (2019-12)

7.3.2.1.7 Impact of Propagation Delay Difference on Measurements

Consider a UE served by a LEO satellite S1, however also within coverage of an incoming LEO satellite S2. The UE
should perform measurements of the neighbouring cells originating from S2 for mobility purposes based on the
measurement configuration provided to the UE, however the propagation delay difference from the UE to satellite S1
and the UE to satellite S2 may vary significantly.

If the SMTC measurement gap configuration does not consider the propagation delay difference, the UE may miss the
SSB/CSI-RS measurement window and will thus be unable to perform measurements on the configured reference
signals. This challenge is captured for both GEO and LEO scenarios, and is to be addressed with priority for LEO
scenarios.

FFS: The scale of this problem in GEO given the stationary nature of GEO satellites.

7.3.2.2 Mobility Enhancements for Non-Terrestrial Networks

7.3.2.2.1 Enhancements to Measurement Configuration/Reporting

● Conditional triggering of measurement reporting: The triggering of measurement reporting can be based on UE
location. This may be based on UE location vs a reference location, or a combination of location and
RSRP/RSRQ.

● Inclusion of location information in the measurement report: Location information may be piggy backed onto the
measurement report to provide the network additional information when determining whether to HO. Additional
design considerations (e.g. signalling overhead impacts and potential privacy concerns) can be addressed in a
work item phase.

● Network compensation of propagation delay difference between satellites: The network can compensate for
propagation delay differences in the UE measurement window, e.g. via system information, or in a UE specific
manner via dedicated signalling. Other solutions to this issue are not precluded.

7.3.2.2.2 Conditional Handover

● Measurement-based triggering: Agreements in the mobility enhancements WI are to be taken as baseline.
Configuration of triggering thresholds and/or which measurement events to use as triggers should consider the
NTN environment e.g. the small variation of the cell quality measured in cell center and at cell edge in NTN.

● Location (UE and Satellite) triggering: additional triggering conditions based on UE and satellite location can be
considered in NTN and may be considered independently or jointly with another trigger (e.g. measurement
based). Location-based conditional HO in LEO scenarios should consider deterministic satellite movement. For
example, the location triggering condition may be expressed as distance between the UE and the satellite.

● Time(r)-based triggering: Several triggering conditions considering the time a region is served can be
considered. This may be based on UTC time, or a timer-based solution, and may be considered independently or
jointly with another trigger (e.g. measurement based). Time-based conditional HO in LEO scenarios should
consider deterministic satellite movement.

● Timing advance value based triggering: additional triggering conditions based on timing advance value to the
target cell can be considered in NTN and may be considered independently or jointly with another trigger.

● Elevation angles of source and target cells based triggering: additional triggering conditions based on elevation
angles of source and target cells can be considered in NTN and may be considered independently or jointly with
another trigger.

3GPP
Release 16 102 3GPP TR 38.821 V16.0.0 (2019-12)

Table 7.3.2.2.2-1: Pros and Cons of the different triggering conditions

3GPP
Release 16 103 3GPP TR 38.821 V16.0.0 (2019-12)

Triggering Advantages Disadvantages

Method
Measurement- ● Less specification impact (i.e. similar to ● Would require neighbouring cell
based terrestrial network); lists, which may be difficult given the
fast-moving nature of LEO satellites
● Is supported in Rel-16 mobility or under inconsistent/deviating cell
enhancements WI; coverage;

● Relies on UE estimates and established ● Small RSRP/RSRQ variation in

channel estimation techniques; regions of cell overlap and
propagation delay may make
● Is based on receiving power and cell measurement-based triggering (e.g.
quality. A3 events) unreliable;

● May be difficult to ensure UE

performs handover to a specific
country.

Location-based ● Useful when cell boundaries are ● The UE may trigger HO to an

dispersed/undefined; unavailable cell (e.g. the NTN cell
has deviated or is inconsistent,
● Can enable mandatory HO based on UE under varying channel conditions, or
location; if the network sets the wrong
triggering condition);
● A precise trigger as UE location can be
known with a degree of accuracy; ● Some UEs may not have positioning
capability.
● Able to predict/pre-emptively configure
triggering condition using satellite ● UE must continuously track the
ephemeris and deterministic satellite satellites trajectory, and the network
movement; will need up-to-date UE location
information which may introduce
● Would be useful to overcome issue of high overhead.
small RSRP/RSRQ variation in regions of
cell overlap;

● UE may need to perform fewer

measurements for HO purposes.

● Since timing advance is derived based on

the distance between UE and the satellite,
configuring the distance as a triggering
condition directly can help reduce
complexity and power consumption in the
UE side in calculating the timing advance.

Time/Timer-based ● Can be useful to maintain service ● The UE may trigger HO to an

continuity if UE loses terrestrial coverage; unavailable cell (e.g. the NTN cell
has deviated or is inconsistent,
● Can enable mandatory HO based on varying channel conditions, or if the
timing; network sets the wrong triggering
condition);
● Network can configure different timing
lengths to mitigate possible RACH ● Depending on the accuracy of the
congestion; ephemeris data and mobility of the
UE, this may not be an accurate
● Can work with satellite ephemeris and trigger which could, e.g. result in
exploit the deterministic movement of early/late HO;
satellites;
● Maintaining multiple timers for every
● UE may need to perform fewer UE could introduce high overhead.
measurements for HO purposes.

Timing advance ● Timing advance based triggering fits well ● Requires GNSS capable UEs.
value based for the issue where UE needs to pre- Support for this needs to be
triggering compensate time when sending the RACH explicitly added as not part of Rel-
preamble in order the target cell to receive 16.
the preamble properly.

3GPP
Release 16 104 3GPP TR 38.821 V16.0.0 (2019-12)

● Further, due to small difference to

RSRP/RSRQ values between overlapping
cells, timing advance based triggering may
provide better accuracy for the triggering
point.

Elevation angles of ● Beneficial for handover regions that are ● UE needs to evaluate elevation
source and target irregular shaped angle based on UE location and
cells based satellite ephemeris data
triggering:

7.3.2.2.3 Mobility Configuration

Broadcast configuration: common signalling in the HO configuration (e.g. T304 and spCellConfigCommon) can be
broadcast, possibly via SIB. Although some mobility information common to all UEs may be broadcast, further
evaluation on impact to signalling overhead is required given HO command is UE specific and requires dedicated
signalling.

The following criteria can to be used as baseline to evaluate the impact/benefit of broadcast signalling:

1) Will enough UEs share the same value of common signalling to justify broadcasting values vs. dedicated
signalling?

2) Will these values remain valid for long enough such that they will not require frequent modification (either via
dedicated signalling or updated broadcast message) thus reducing signalling overhead savings?

3) How long will it take for the UE to receive the minimum required information for NTN access?

Further analysis may be performed to identify other possible signalling applicable to broadcast transmission (e.g.
common delay, other parameters of the RRCReconfiguration message), whether certain areas of the network are more
suitable to broadcast signalling (e.g. at the edge of coverage between terrestrial and non-terrestrial), or whether typical
HO configurations (possibly with additional delta configuration) can be provided via an index. All signalling between
the UE, source, and target gNB should be considered in evaluation.

7.3.2.3 Connected mode mobility for feeder link switch for LEO NTN [18]
Connected mode mobility for feeder link switch, or due to interface change, from the network perspective is captured in
Sections 8. 6 and 8.7. From Uu perspective, there is difference between Architecture Option 1 that is transparent
payload and Architecture Options 2-5 (listed in Section 8.7.1) that are regenerative payload. For further details, see Sec.
8.3.1.

7.3.2.4 Connected mode mobility assumptions

RAN2 will prioritize analysis of mobility challenges/enhancements for transparent GEO (A) and LEO with moving
beam (C2, D2) architectures during the study item phase.

NOTE 1: Only cell level mobility is considered from a RAN2 perspective

NOTE 2: Additional scenarios may be considered pending outcome of NTN study in RAN1.

7.3.3 Paging issue

7.3.3.1 Paging Capacity

Following parameters should be considered for calculation of paging capacity

- Paging Frames (PF) per second:

- Paging Occasions (PO) per PF:

3GPP
Release 16 105 3GPP TR 38.821 V16.0.0 (2019-12)

- Maximum number of paging records in paging message:

- User density (UEs/km2)

- Satellite beam diameter: in km

- NO_Traffic: fraction of UEs in the cell with network originated traffic

- Arrival session or call rate: average requested paging occasions per hour and per UE

- Number of cells in per tracking area: M

7.3.3.1.1 Paging capacity of non-multibeam cell

In a non-multibeam scenario 4 out of 10 subframes per PF can be used for paging that is there can be at most 4 PO per
PF. A paging message can only be sent in a PO. The paging message can at most include 32 paging records in the
paging message where each paging record includes the UE identities of the UEs being paged. The theoretical paging
capacity as maximum number of UEs paged per second in an NR non-multibeam cell is thus limited by:

As each RF can be configured to be a PF, the resulting maximum paging capacity with 100 PF per second is thus
PO per second. This implies that theoretically, an NR cell can page UEs per second, or
equivalently, more than 46 Million UEs per hour .

The supported paging capacity should be compared with the required paging per cell, which can be calculated as:

If the tracking area is larger than one cell and the base station needs to blindly page all the UEs that it want to reach in
all cells, then in the worst case the required arrival rate would be:

The paging capacity should also be considered together with the cell's capacity to support UEs accessing the cell. After
being paged, the UE accesses the cell using a random-access procedure which starts by the UE transmitting a random-
access preamble on the physical random-access channel (PRACH). PRACH capacity is calculated in Section X.

7.3.3.1.2 Example of calculation

Given the cell area of a hexagonal cell has a radius of r as in Figure 1, the cell area can be expressed as

. If the cell area is an ellipsoid the area can be expressed as . For

example, for the cell radius of r = 250km, the area is A = 163 000km2.

3GPP
Release 16 106 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 7.3.3-1: Area of a hexagonal cell with radius r

Some examples of the paging channel load which is calculated as

can be seen in Table 7.3.3.1-1
with different deployments.

Table 7.3.3.1-1: Paging channel loads for a given arrival session rate and UE density

UE density Arrival session M r [km] Paging channel load

[UE/km2] rate
4, 100, 32 400 1 per hour 1 250 141%
4, 100, 32 400 1 per 24 hours 1 250 5%
4, 100, 32 20 1 per hour 1 250 7%
4, 100, 32 20 1 per 24 hours 1 250 0,25%

Furthermore the supported UE density given the UE arrival session rate per UE, which is highly dependent on the size
of the beam, can be calculated by:

Table 7.3.3.1-2: Supported UE densities for a given arrival session rate

Arrival session rate M r [km] UE density [UE/km2]

4, 100, 32 1 per hour 1 250 ~280
4, 100, 32 1 per 24 hours 1 250 ~6780

One can also compare the paging capacity requirements scale with the TA size and different arrival rates, in the worst
case considering that UE does not know where any of the UEs are located and thus pages the same IDs across the whole
tracking area:

In the Figure 7.3.3-2 and Figure 7.3.3-3 the required paging capacity is shown if the cell is circular with a radius of 200
km and 500 km, the UE density is 620 UE/km2, and arrival session rate is 1/24*x, where x is 0.2 and 0.5 leading to
arrival session rate of 0.008 and 0.021.

3GPP
Release 16 107 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 7.3.3-2: Paging capacity requirement in LEO scenario

Figure 7.3.3-3: Paging capacity requirement in GEO scenario

7.3.4 Radio Link Monitoring

Void

7.3.5 PLMN identities deployment

Deployment of PLMNs with specific PLMN IDs for NTN cells and TN cells, or between different type of NTN
platforms (GEO or LEO), is considered as a preferred option, however the configuration of common PLMN identities is
not precluded.

7.3.6 Ephemeris Data for NTN

7.3.6.1 Representation of Complete Ephemeris Data

Ephemeris data contains the information about the orbital trajectories of artificial satellites as described in Annex A.
There are different possible representations of ephemeris data. One possibility is to use orbital parameters, e.g. semi-
major axis, eccentricity, inclination, right ascension of the ascending node, argument of periapsis, mean anomaly at a
reference point in time, and the epoch. The first five parameters can determine an orbital plane, and the other two

3GPP
Release 16 108 3GPP TR 38.821 V16.0.0 (2019-12)

parameters are used to determine exact satellite location at a time. A description table for the orbital parameters and the
corresponding illustrations are as below.

Table 7.3.6.1-1: Essential Elements of Ephemeris

Orbital plane Square root of semi major axis（semi-major axis）

parameters Eccentricity（eccentricity）
Inclination angle at reference time（inclination）
Longitude of ascending node of orbit plane（right ascension of the
ascending node）
Argument of perigee（argument of periapsis）
Satellite level Mean anomaly at reference time（true anomaly and a reference point in
parameters time）
Ephemeris reference time（the epoch）

NOTE: True anomaly is the actual measured angle in the orbital plane between the vector extending from the
focus to the point of periapsis and the vector extending from the focus to the object's actual position.
Mean anomaly is the angle between the periapsis point and the imagined position of an object for the
same elapsed time since periapsis for a circular orbit around the same body with the same orbital position.
The key difference is that mean anomaly always increases linearly with time. The true anomaly, in
general, does not, except if the orbital is circular, in which case the mean anomaly and true anomaly are
almost identical. True and mean anomaly can be linked together thanks to the eccentric anomaly.

Perigee
Satellite

Orbit Plane
Equator Plane

Ascending Node

Essential Parameters for Ephemeris

Figure 7.3.6-1: Satellite Orbit and Keplerian Elements

Another possible option is to provide the location of the satellite in coordinates (x, y, z), e.g. ECEF coordinates. For
anything else than GEO, additionally a velocity vector (vx, vy, vz) and again a reference point in time are needed.

NOTE::It seems that this option has the drawback that – for LEO satellites – it prevents the UE from extrapolating the
satellite track for more than a very short time into the future. Since a LEO satellite moves very fast, the given position
(x, y, z) may be outdated in a short period of time. And since the satellite moves in an elliptical orbit, providing a
velocity vector (vx, vy, vz) does not help much; so it remains to be studied the required accuracy –to determine the
satellite location with acceptable precision. As a result, the satellite would need to provide (e.g. broadcast) an updated
location very often, about every few minutes. Furthermore, for the same reason it is unclear how to pre-provision a UE
with ephemeris information in coordinates.

7.3.6.2 Provision and Use of Ephemeris Data

In all cases, the minimum representation needs at least seven double-precision floating point numbers, plus some
overhead. This means that, for satellite networks with many satellites, the ephemeris data can be quite substantial. The
exact data size for a LEO network depends on the number of satellites, which may be several hundreds, and the
accuracy of which the ephemeris parameters are represented.

3GPP
Release 16 109 3GPP TR 38.821 V16.0.0 (2019-12)

In a satellite network, the orbits of all satellites are however not independent, as several satellites typically share a
common orbital plane. To reduce the amount of data needed, the ephemeris data could provide information not for
every single satellite, but only for the common orbital planes. Even for a network with 100 orbital planes, the ephemeris
data would then amount to only a few kB. The ephemeris data may be provisioned a file containing the ephemeris data
in the uSIM of the UE or directly in UE itself.

As mentioned above, the size of the ephemeris data can be quite substantial for networks with many satellites, and
easily exceeds the capacity of a uSIM which is one way for pre-provisioning the ephemeris data, which typically is 128
kB. The ephemeris data file on the uSIM may thus contain only information about the orbital planes. In this case, the
ephemeris data would not provide the location of a specific satellite but describe an arc in the sky above the UE which
the UE would need to scan for a satellite. According to the definitions of orbital parameters, the first five parameters,
i.e. semi-major axis, eccentricity, inclination, right ascension of the ascending node, argument of periapsis, are used to
determine the elliptical orbit. So these parameters can be provisioned to UE as baseline ephemeris data.

These baseline ephemeris data or orbital planes may be indexed and further quantized and sub-indexed. The indexes can
then be used in RRC in an efficient way to point to stored ephemeris data. The UE can be given information about
ephemeris data of other cells by using the ephemeris plane information. For example, when a UE is asked to do RRM
measurements, the UE is given the index of the orbital plane where the cell to be measured can be found.

With the help of ephemeris data, a UE may search for the first NTN cell it could connect to. After detecting PSS/SSS
(SSB) of a cell broadcasted by a satellite, the UE may be able to read the initial system information of that cell. Ideally,
before attempting to access the cell, the UE knows the RTT well enough to be able to do random access. For this, the
initial system information may need to contain further ephemeris information on the exact location of the cell (or the
satellite broadcasting the cell). This information can be given with respect to the orbital plane that the UE already has
information about.

Considering that the orbit-plane level orbital parameters are not sufficient to derive the satellite position while the
satellite level orbital parameters is more helpful for UE to search for the first NTN cell and perform initial access, it is
worthwhile evaluating some other solutions to provide satellite level orbital parameters. In addition to the first five
orbital parameters for orbital plane, the other two orbital parameters including mean anomaly at a reference point in
time and the epoch are used to determine the exact satellite location at a time.

As mentioned above, the main concern for proving the satellite level orbital parameters is about the size of such
information. However, there is no need for a UE to store orbital parameters for all the satellites. If the orbital parameters
per satellite are pre-provisioned, UE only needs to store the ephemeris data for the satellites that may serve UE Another
possible solution to address the size concern of the satellite level orbital parameters is to broadcast the orbital
parameters of the serving satellite and several neighbouring satellites which will be sufficient for initial access and
mobility handling at UE side. Thus, the following solutions can be considered to provide orbital parameters per satellite:

● Pre-provision satellite level orbital parameters for all the satellites that may serve the UE in uSIM/UE and the
ephemeris data for each satellite can be linked to a satellite ID or index. Broadcast the satellite ID or index of the
serving satellite in system information so that UE is able to find the corresponding detailed ephemeris data stored
in uSIM to derive the position coordinates of the serving satellite. The satellite ID or index of neighbour
satellites can also be provided to UE via system information or dedicated RRC signalling to assist mobility
handling.

● Broadcast satellite level orbital parameters of the serving satellite in system information and UE will derive the
position coordinates of the serving satellite. The ephemeris data of the neighbouring satellites can also be
provided to UE via system information or dedicated RRC signalling.. In case the baseline orbital plane
parameters are provisioned in uSIM/UE, only mean anomaly at a reference point in time and the epoch need to
be broadcasted to UE, in this way signalling overhead can be reduced significantly.

7.3.6.3 Updating Stored Ephemeris Data

For the solutions in which the orbital parameters for the common orbit planes or for all the satellites that may serve the
UE are pre-provisioned, the accuracy of the prediction of a satellite orbit or the satellite position decreases the further in
the future one tries to extend the prediction. It might thus be needed to update the ephemeris data stored in the UE. The
validity time of stored ephemeris data might depend on the orbital parameters of the NTN satellite, and on the required
accuracy of its prediction. Since the validity time determines the frequency of the updates, it should be studied further.

The main purpose of the ephemeris data provided by network is to provide the UE with ephemeris data for initial
access, e.g. if it is expected to be switched off for a longer time; or in other words, as a replacement for the data stored
in the UE. As such, it may also contain information on orbital plane level or on satellite level.

3GPP
Release 16 110 3GPP TR 38.821 V16.0.0 (2019-12)

The UE should always use the most current ephemeris data. Once the UE has obtained new ephemeris data, the
parameters stored in the UE are thus obsolete and should no longer be used or be overwritten with the newer values.
Every parameter in the UE has an associated priority statement. By giving the parameters in the UE lower priority, the
UE can be prevented from using the obsolete values stored in the UE.

7.4 Earth fixed cells vs Earth moving cells

Compared to LEO based Earth moving cells scenario where cells are moving on the ground, LEO based Earth fixed
cells scenario refer to NTN that provide cells fixed with respect to a certain location on the Earth during a certain time
duration. This can be achieved with NTN platforms generating steerable beams which footprint is fixed on the ground.

The same solutions identified for Earth moving cell scenario can also be applied for Earth fixed cell scenario, however
whether specific solutions are necessary (or preferred) for each scenario can be further evaluated in the normative phase
(See [74]).

8 Issues and related solutions for NG-RAN architecture

and interface protocols

8.1 Tracking area management

The concept of Registration and Tracking areas pertains in the context of Non-Terrestrial networks, and is similar to NR
based cellular system in following aspects:

● a tracking area corresponds to a fixed geographical area.

● tracking areas (TA) is utilized for UE access control, location registration, paging and mobility management.

● a registration area encompasses one or several tracking areas.

The objective is to track the UE, in order to minimize the use of radio resources for paging.

8.1.1 NTN cells are fixed w.r.t the ground

For scenarios A, B, C1 and D1, the NTN cells are fixed on the ground. Hence a tracking area may correspond to one or
several NTN cells. The 3GPP-defined tracking area management and paging procedures can apply as is. In case of C1
and D1, the LEO satellites generate beams with temporary Earth fixed footprints. In other words, the beam footprints
are stationary over a given NTN cell on ground for a certain amount of time before they change their focus area over
another NTN cell. It is possible the assign each NTN cell to a tracking area. This requires the satellite to change the
broadcasted tracking area code between two successive NTN cells covered.

NOTE 1: For scenarios C1, the TA list and paging messages could be sent by the same gNB to the NTN cell via all
satellites covering this NTN cell.

NOTE 2: For scenarios D1, the TA list and paging messages could be sent by the gNB on board all satellites
covering this NTN cell.

8.1.2 NTN cells are moving w.r.t the ground

For scenarios C2 and D2, the NTN cells move on the ground as the satellites move on their orbital planes. This requires
some adaptations to the TA management and paging procedure.

Hence we shall focus the study on scenario C2 and D2 for the idle/inactive mode mobility.

It is worth noting that, as long as the TA is always uniquely coupled with the relevant cell(s), it may still be possible to
apply legacy core network procedures (e.g. paging) even to a moving TA. In such case, however, it seems beneficial to
differentiate such a TA from a fixed / "non-NTN" TA. In principle, this could be done by reserving a range of

3GPP
Release 16 111 3GPP TR 38.821 V16.0.0 (2019-12)

identifier(s) for TAs associated with NTN moving cells. However, this might restrict the possible TA address space and
might not be desirable from the operator's point of view.

Another alternative would be to extend the TAC IE signalled over NGAP and XnAP with a TA Type IE, defined as e.g.
ENUMERATED (NTN, NTN with moving cells, ...) so that the receiving node can identify that the cells associated
with this TA are related to a NTN, and/or are not stationary with respect to the ground. Alternatively, this indication
may be at cell level or gNB level.

The non-terrestrial and terrestrial networks could be assigned either same or different PLMNs.

● In case of two different PLMNs for terrestrial and non-terrestrial networks, both tracking area layouts can be
independently defined preventing overlaps between tracking areas of a given layout. This would be in line with
the current definition of TAs.

● In case of a shared PLMN, the operator is responsible for defining tracking areas and assigning the TAIs to be
used by the terrestrial network, and to be used by the non-terrestrial network. Overlapping between these
tracking areas are possible.

The main idea is to decouple the TA management from the NTN cell pattern. In that case, registration and tracking
areas are arbitrary geographical areas defined by the operator. (FFS)

It is assumed that not all UEs are capable of positioning.

The following applies to scenarios C2 and D2.

8.1.2.1 Tracking Area defined on satellite

In this option, a NTN cell only have one TAI per PLMN ID, i.e. same as terrestrial cell. This also allows the gNB to
reuse current NGAP procedure, i.e. the INITIAL UE MESSAGE contains one TAI of the serving cell.

In Scenario C2 and D2, when the LEO satellite moves, the coverage of the TAI also changes. A stationary UE may see
the TAI keeps changing. Some solutions were described in the Section 8.3. Similar issue is also discussed in SA2, and
the related proposals are also captured in SA2 TR23.737, Solution #7.

8.1.2.2 Tracking Area defined on earth

In this option, it keeps the principle that the TAI is related to a specific geographical area, but a NTN cell may have to
broadcast multiple TAIs per PLMN ID, which does not align with the principle that a cell only have one TAI per PLMN
ID.

When the NTN cell covers multiple Tracking Areas (either fully, or partially), the NTN cell will broadcast all related
TAIs. From a UE perspective, the UE recognizes the Tracking Area by the TAI broadcasted over the air. The
"observed" Tracking Area by the UE keeps changing. The following aspects need to be further considered.

Which TAI is to be provided to CN on NG interface?

During the Initial UE Message procedure, the UE's location, i.e. TAI+CGI, is provided to the CN. When a NTN cell
broadcast multiple TAIs, one option is provide all TAIs to the AMF. The AMF may have difficulty to provide an
effective Registration Area to the UE. The other option is to only provide one TAI to the AMF. The gNB need to
determine which TAI is to be provided to the AMF when a NTN cell broadcast multiple TAIs.

How to enforce a regional/country policy?

If UE's location can be determined during (or before) the registration procedure, the NG-RAN node provide the UE's
location to the network during the registration, and the regional/country policy will be enforced. Otherwise, as soon as
the UE enters in connected mode, the network will be able to determine its location and regional/country policy will be
enforced.

8.2 Registration Update and Paging Handling

In Non-Terrestrial non-GEO Network, the satellites moves across the geographical area of interest, its antenna beams
will cover different portions of that area.

3GPP
Release 16 112 3GPP TR 38.821 V16.0.0 (2019-12)

In a NTN beam with a foot print moving on earth, a fixed association between the non-GEO NTN beam and TAI would
lead to moving TAIs on ground. In terrestrial RANs the geographical area for tracking the UE, also called Tracking
Area (TA) is associated to the TAI broadcasted by the RAN.

As in the terrestrial RAN, there is no one-to-one correspondence between moving NTN beams and geo-area on Earth,
i.e., the TAIs broadcasted by the Non-GEO satellite will sweep over Earth. A stationary UE will see different NTN
beams/TAIs over the time. With current Registration Update procedure, the stationary UE has to keep performing
Registration Updates upon the change of NTN beam. This brings a challenge to current Registration Update and Paging.
In the following, we study possible solutions based on whether the UE can determine its location or not.

8.2.1 Option 1: UE is capable to determine its location

In the following it is assumed that the UE has the capability to determine its location (e.g. by GNSS). In this case the
satellite can page the UE based on UE's location information.

In terrestrial network, the AMF is in charge of mapping a tracking area where the UE is located to determine the list of
gNBs that pages the UE. In NTN, one can use the UE location to do an equivalent mapping and determine the list of
gNBs that page the UE.

The mapping could be made in the AMF. For this, the AMF is made aware of UE location, along with some assistance
information, e.g. UE type or UE speed information. AMF has also to be aware of satellite ephemeris.

Alternatively, this mapping could be made in the RAN. When a UE has to be paged, the AMF determines the RAN
access node(s) where to send the paging message from the TAI as usual. The NTN based NG- RAN can then select the
satellite beams where to broadcast the paging from its knowledge of UE last location and satellites ephemeris. However
this raises several issues as paging failure coordination between RAN and CN and Idle UE context management in
RAN, and would require further studies.

8.2.1.1 Mapping of UE location to gNB list in the AMF

The example procedure for UE location based paging could be illustrated by the figure below:

Figure 8.2.1.1-1: UE location based paging (example)

● Step 1: UE report the location info to gNB1, the report may also include some assistance info such as UE type,
speed info, more details need to be further studied.

● Step 2: Upon receiving of the UE location report, gNB1 forwards the location info and the assistance info if have
to AMF.

3GPP
Release 16 113 3GPP TR 38.821 V16.0.0 (2019-12)

● Step 3: AMF stores the UE location info, the assistance info if any, and also the corresponding time stamp. The
information is kept in AMF when UE is released to Idle.

● Step 4: When AMF wants to page the UE, it selects the gNB(s) which could cover the UE location according to
the stored info and ephemeris.

● Step 5: AMF sends the Paging message to the selected gNB(s), including the location info and the assistance info
if any. Upon reception of the Paging message, the gNB may decide which satellite(s) or beam(s) to be paged and
page the UE accordingly.

NOTE: If the location based paging is failed, AMF may extend the paging area and re-send the UE according to
its paging policy, e.g. re-send the paging in the whole registration area of the UE.

8.2.2 Option 2: UE is not capable to determine its location

In the following, it is assumed that the UE has no capability to determine its location. Four potential solutions have been
identified.

8.2.2.1 Solution 1: Timing window based Registration update and paging

This solution assumes moving identifiers on ground.

The satellite can page the UE based on RA.

The following is one possible solution (details may be refined).

In this option, the Tracking Area is associated with the timing information for how long it is valid related to a geo-area.
For example, a geo-area will be served by NTN beam#1 with TAC#1 during 10:01 – 10:10, NTN beam#2 with TAC#2
during 10:11 – 10:20, etc. an example call flow is shown as below:

3GPP
Release 16 114 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 8.2.2-1: UE Registration procedure (example)

● Step 1: at 10:05, UE initiates Registration procedure. The REGISTRATION REQUEST message is sent to
AMF. Just like normal initial access, the CU provides the TAC#1 to AMF with current NGAP procedure.

● Step 2: AMF replies with REGISTRATION ACCEPT message. The AMF determines the UE's location will be
covered by TAC#1 during 10:01-10:10, TAC#2 during 10:11-10:20, etc. The determination is based on

- The ephemeris information of the satellites, i.e. the information as to which NTN beam covers a specific
location.

- The location of the UE, in terms of TAC/NTN beam ID of UE's current or last 3GPP access. The UE may
include its location information in the NAS REGISTRATION REQUEST message, or other NAS message.

The determination may be performed by querying a database.

The REGISTRATION ACCEPT message includes enhanced Registration Area information, consisting of a list of
TAIs with timing information (in this example, AMF would like the UE to initiate a Registration Update 10-min
later)

+ TAC#1 with (10:05 – 10:10)

+ TAC#2 with (10:11 – 10:15)

Later, UE enters RRC_IDLE.

Case 0: UE did not move during 10:05 – 10:11

3GPP
Release 16 115 3GPP TR 38.821 V16.0.0 (2019-12)

● At 10:11, NTN beam#1 moved out of the UE's area. The UE's area is now covered by NTN beam#2 with
TAC#2. The UE detected the TAC of the serving cell is changed to TAC#2. UE checks the TAC#2 against the
enhanced Registration Area received in Step 2 (see Figure 8.2.2-1). TAC#2 is in the Registration Area assigned
by the AMF in the REGISTRATION ACCEPT message (Step 2), and the timing information match (i.e. TAC#2
only for 10:11-10:15), this means the UE is still in the Registration Area, thus no need to perform Registration
Update.

NOTE: This reuses the current Registration Update trigger.

Case 1: at 10:12, the UE is paged.

● Step 3 (see Figure 8.2.2-1): at 10:12, a DL data is received for the UE. AMF determines the target tracking area
based on the UE's last location (i.e. TAC#1 at 10:05), and the Tracking area information for this area (i.e.
TAC#1 during 10:01-10:10, and TAC#2 during 10:11-10:20). In this example, AMF knows the UE's last
location and will be served by NTN beam#2 with TAC#2 during 10:11-10:20. AMF sends the Paging message
with TAC#2 to the NG-RAN.

Normal Service Request procedure is performed.

Case 2: at 10:13, the UE move out of the Registration Area

● Step 4 (see Figure 8.2.2-1): at 10:13, the UE detects current NTN beam broadcasting TAC#1. Even TAC#1 is in
the Registration Area assigned by the AMF in the REGISTRATION ACCEPT message (Step 2), but the timing
information does not match (i.e. TAC#1 only for 10:01-10:10, but not for 10:13), this means the UE is moving
out of current Registration Area. So the UE initiates a Registration Update procedure.

Advantage for this option is:

● Reuse current Registration Update trigger, i.e. TS23.501, "perform Mobility Registration Update procedure if the
current TAIs of the serving cell (see TS 37.340 [31]) is not in the list of TAIs that the UE has received from the
network;"

● Reuse current TAC broadcast mechanism, i.e. NTN beam always broadcasts the same TAC.

● Less changes to RAN and CN.

8.2.2.2 Solution 2: UE assisted TA list report/registration and paging

This solution assumes stationary identifiers on ground.

The satellite pages the UE based on RA, i.e. TAI list.

The following is one potential solution. (Details may be refined)

In this option, the TAI is broadcast in system information in NTN cell based on fixed TA planning area on ground:

Step 1: Setup a fixed TA map on the Earth's surface.

Step 2: Dynamically update the broadcast TAI according to the satellite's position.

Step 3: UE monitors and reports list of received broadcast TAIs for registration procedure.

Step 4: During the registration procedure, AMF provides a TAI list to the UE, which defines the UE-specific
registration area used for paging.

Step 5: UE measures and records the observed TAI list of the best cells with respect to time.

Step 6: UE compares the TAI list assigned by AMF with the observed TAI from Step 5 and determines whether it is
still within the registration area or not (details may be refined).

Step 7: If UE concludes that it has left the registration area, it initiates the Registration Update procedure and reports
the observed TAI list to AMF by which AMF may assign a new UE-specific TAI list. The determination of the
observed TAI list in UE including adding or deleting a TAI is possible alternative.

8.2.2.3 Solution 3: Multi-Tracking Area ID based Registration update and paging

3GPP
Release 16 116 3GPP TR 38.821 V16.0.0 (2019-12)

Instead of broadcasting a single TAI, the satellite could broadcast a list of TAIs of covered TAs, in order to allow for
TAs to be a subset of the satellite beam coverage area. The satellite could then adopt the list of TAIs with respect to its
beam coverage area. In case of transparent satellites, the gNB on the ground may be preconfigured with the list of TAIs
to be used. In case of regenerative satellites, the network node on the satellite may be preconfigured with the list of
TAIs to be used, for example by using validity time window information for each TAI list entry in a similar manner as
described in 8.3.2.1.

The advantage of this approach is that the Tracking Area (TA) definition as non-overlapping areas on the ground is still
valid and the current paging mechanisms can be reused.

Figure 8.2.2-3 shows an example with countries that are equivalent to tracking areas. Four TAs are defined: TA1:
Germany, TA2: Austria, TA3: Switzerland and TA4 Liechtenstein (Note that it is also possible to define multiple TAs
per country). Three satellites (red, green and blue) are covering parts of the area shown as red beam, green beam and
blue beam. In the top figure the red satellite broadcasts three TAIs, i.e. TAI2, TAI3 and TAI4 as its beam footprint is
covering TA2, TA3, and TA4. Similarly, the green satellite broadcasts TAI1 and TAI3, while the blue satellite
broadcasts TAI1, TAI2, TAI3 and TAI4. The bottom figure shows the same TAs, while the satellites and their
respective coverage areas moved. Hence, the list of broadcasted TAIs for the red and green satellites changed, but
stayed the same for the blue satellite.

In the example, a UE located in Austria (TAI2), would be paged within both blue and red satellite beams according to
the upper figure. According to the lower figure, it would be paged within both blue and green satellite beams.

3GPP
Release 16 117 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 8.2.2-3: Illustration of the solution using country areas as exemplary tracking areas (two
exemplary time instances are shown from top to bottom)

8.2.2.4 Solution 4: UE location determined by NTN based NG-RAN

The earth footprint of a satellite beam depends on the satellite altitude and the elevation angle, but may be quite large
compared to usual terrestrial cell size. Hence, the trade-off between TA size and registration update is different for NTN
compared to terrestrial networks.

3GPP
Release 16 118 3GPP TR 38.821 V16.0.0 (2019-12)

When a UE registers initially, or makes registration area updates, or switches to connected mode, the NTN based NG-
RAN gets a UE location inform, from serving beam identification for example. A periodic registration area update
could be sufficient to track a UE in idle mode, the RA update periodicity being tuned according to UE type or observed
mobility behaviour.

Moreover, the RAN could have other means to locate a UE.

Hence, even if the UE is not capable to determine its location on its own, it could be assumed that the RAN has a
knowledge of UE location. Then paging methods based on UE location knowledge can apply.

8.3 Connected mode mobility

There are different types of hand-overs in Non-Terrestrial networks:

● Intra-satellite hand-over (between cells served by same satellite)

● Inter-satellite hand-over (between cells served by different satellite)

● Inter-access hand-over (between cellular and satellite access)

There can be some variants depending on whether the satellite is transparent or regenerative (gNB or partial gNB on
board the satellite)

The table identifies the applicable NG-RAN hand-over procedures for each of the NTN hand-over scenarios.

Table 8.3-1: NG-RAN procedures versus NTN hand-over scenarios

NTN Hand-over scenarios Transparent satellite Regenerative satellite (gNB Regenerative satellite
on board) (gNB-DU on board)
Intra satellite hand-over Intra-gNB handover intra gNB hand-over Intra-gNB-CU
procedure procedure Mobility/Intra-gNB-DU
or Inter-gNB handover handover or Inter-gNB-CU
procedure handover (See clause
8.2.1.2 in TS 38.401)
Inter satellite hand-over Inter-gNB handover inter gNB hand-over Intra-gNB-CU Mobility/
procedure or Intra-gNB procedure (See clause Inter-gNB-DU Mobility or
handover procedure (See 9.2.3 in TR 38.300) Inter-gNB-CU handover
clause 9.2.3 in TR 38.300) (See clause 8.2.1.1 in TS
38.401)
Inter access hand-over Inter AMF/UPF hand-over Intra-gNB handover
procedure or Intra procedure
AMF/UPF hand-over or Inter-gNB handover
procedure (out of RAN procedure
scope)

In each case, the relevant mobility procedures may require some adaptations to accommodate the extended latency of
satellite access.

An inter-access hand-over (between cellular and satellite access) is considered by utilizing an inter gNB procedure via
the 5GCN (e.g. for Satellite with on board processed payload) or via the Xn (e.g. for satellite with transparent payload).

It is assumed that not all UEs are capable of positioning.

8.3.1 Architecture Classification

In the following sections, the architecture options previously described will be referred to as follows:

1) Transparent based non-terrestrial access network (Sec. 5.1);

2) Regenerative satellite and split gNB (Sec. 5.2.2);

3) Regenerative satellite and on-board gNB(s) (Sec. 5.2.1);

4) Regenerative satellite with Inter-Satellite Links (ISLs), gNB processed payload (Sec. 5.2.1);

3GPP
Release 16 119 3GPP TR 38.821 V16.0.0 (2019-12)

5) gNB processed payload, Relay-like architecture (Sec. 5.2.3).

8.3.2 Intra-gNB Mobility ("Monolithic gNB")

In this case, all necessary signalling is confined to within the gNB, with no signalling impact on NG or Xn. For the case
of "monolithic" gNB, this is supported without any standards impact by Architectures 1, 3, 4, and 5.

8.3.3 Intra-DU Mobility

In this case, all necessary signalling is confined to within the DU, with no signalling impact on F1. This is supported by
Architecture 2 without any standards impact.

8.3.4 Intra-gNB/Inter-DU Mobility

This is supported by current inter-DU mobility. In Architecture option 2, the F1 signalling is transferred over SRI.

Single logic DU across multiple satellites is precluded.

8.3.5 Inter-gNB Mobility

8.3.5.1 Xn Mobility
For Architectures 1 and 2, Xn interfaces (if present) are terminated at the ground station; in these cases, Xn mobility is
possible without any standards impact.

There is no Xn in Architecture 3, so in this case it is not possible to support Xn mobility.

For Architecture 4, Xn mobility is only possible between satellite-hosted gNBs.

Some further observations should be made on the issue of Xn mobility involving NTNs. In current NG-RAN
specifications, Xn mobility is the mechanism of choice when moving between neighbour cells, ensuring the best
performance and with minimal core network involvement thanks to the use of a "horizontal" interface, Xn. When
considering NTNs, the concept of neighbour cells is going to be different, and at least two different cases should be
considered:

1) Two "neighbour" cells belonging to NTNs;

2) Two "neighbour" cells, of which one is served by a terrestrial RAN, and the other by an NTN.

For the first case, if the two cells are served by two different logical nodes (e.g. satellites) within the NTN, it seems
possible to set up Xn and use it for Xn mobility. This is indeed the case with Arch. 4, in which Xn would be transported
on ISLs.

For the second case, the Xn-based mobility is only possible if an Xn exists between the NTN gNB and terrestrial gNB.

Architecture 5 (relay-like, Xn is terminated in the satellite but goes through the NTN-donor) seems to suffer from this
problem. Therefore, in theory Arch. 5 supports Xn mobility between satellite-gNBs and terrestrial gNBs, but its
performance seems questionable due to the above observations.

8.3.5.2 Mobility through the 5GC

In Architectures 1 and 2, NG is terminated at the ground station; in these cases, mobility through the CN is supported
without any standards impact.

In Architectures 3, 4 and 5, NG is terminated at the satellite, so NG traffic needs to be transported over the SRI:
mobility through the CN is possible.

3GPP
Release 16 120 3GPP TR 38.821 V16.0.0 (2019-12)

8.3.6 Mobility due to interface change

In this case, the UE mobility (hand-over) is due to the change of the interface, for example, when the satellite moves out
of the coverage of current radio network node on the ground, and the UE connects to either a new radio network node
on the ground or a new network node on board the satellite.

● In Architecture Option 1, 3, 4 and 5, this means the change of AMF.

● In Architecture Option 2, this means the change of gNB-CU.

Due to the change of interface, all UEs need to be handover to new network node (i.e. AMF in Architecture Option 1, 3,
4 and 5, gNB-CU in Option 2). Handover all connected UEs in a short period can cause significant signalling load.
Further study is needed.

For Mobility due to interface change, it may cause significant signalling load in all architecture options. Further study is
needed.

8.3.6.1 Architecture option with gNB on board satellite

To mitigate the signalling load issue during the mobility due to NG interface change, a possible option is the Satellite
implements two logical gNBs (e.g. gNB1 and gNB2). gNB1 connect to AMF1, and gNB2 connect to AMF2. gNB1 and
gNB2 can share the same resource and UE context.

Since gNB1 and gNB2 are collocated in the same satellite and can share the resource, it can be assumed that same
resource is used to serve the UE when the UE is handover from gNB1 to gNB2. So it may be possible to avoid the
Handover Resource Allocation procedure. Current Handover Resource Allocation procedure allows the target AMF to
update some UE context, e.g. the NG-U UL F-TEID. If Handover Resource Allocation procedure is not performed, the
updated UE context may need to be sent from AMF to gNB1, then to gNB2 via an interface on board the satellite.

Using AMF re-allocation might be another option.

This clause illustrated one possible option to mitigate the interface change with high load management, other
implementation are not precluded.

8.3.6.2 Architecture option with gNB-DU on board satellite

To mitigate the signalling load issue during the mobility due to F1 interface change, a possible option is the satellite
implements 2 logical DUs (e.g. DU1 and DU2). DU1 connect to CU1, and DU2 connect to CU2. DU1 and DU2 can
share the same resource and UE context.

Since DU1 and DU2 are collocated in the same satellite and can share the same resource, it can be assumed that the
same resource keeps serving the UE when it is handover from DU1 to DU2. In that way it may be possible to avoid the
F1 UE Context Setup procedure during inter-DU handover. Current F1 UE Context Setup procedure allows the target
CU to update some F1AP UE context, e.g. gNB-CU UE F1AP ID, etc. If F1 UE Context Setup procedure is not
performed, the updated F1AP UE context may need to be sent from CU to DU1, then to DU2 via an interface on board
the satellite.

One possible call flow is shown as below.

3GPP
Release 16 121 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 8.3-1: CU change example

● DU1 setup F1 with CU1. DU2 setup F1 with CU2. UEs are served by DU1/CU1.

● Step 1: CU1 determines the need to initiate handover preparation procedure for all connected UEs. CU1 send Xn
Handover Request message to CU2. The Xn Handover Request message includes an indication that the handover
is triggered due to CU switch, and a container for UE F1AP context. By this indication, CU2 will not send F1AP
UE CONTEXT REQUEST to target DU.

● Step 2: The Xn Handover Request Acknowledge message includes a container for the updated F1AP context,
e.g. CU2 may allocate a new gNB-CU UE F1AP ID.

● Step 3: CU1 forward the RRC Reconfiguration message to DU1. CU1 also include the new updated F1AP
context. By implementation method, DU2 know the F1AP context to be used with CU2.

● Step 4: DU1 forward the RRC Reconfiguration message to UE

● Step 5: UE send RRC Reconfiguration Complete message to DU2

● Step 6: DU2 forward the RRC Reconfiguration Complete message to CU2. The normal handover procedure
continues.

This clause illustrated one possible option to mitigate the interface change with high load management, other
implementation are not precluded.

8.3.7 Summary
The table below summarises the applicability of hand-over procedures for different NTN architectures.

3GPP
Release 16 122 3GPP TR 38.821 V16.0.0 (2019-12)

Table 8.3-2: Mobility support for the various NTN architectures

Arch. 1 Arch. 2 Arch. 3 Arch. 4 Arch. 5

Intra-gNB mobility Supported, no Does not apply Supported, no Supported, no Supported, no
("monolithic" gNB) standards impact standards standards standards
impact impact impact
Intra-DU mobility Does not apply Supported, no Does not apply Does not apply Does not apply
standards
impact
Inter-DU mobility Does not apply Supported, no Does not apply Does not apply Does not apply
standards
impact
Xn mobility Supported, no Supported, no Depends on Xn Supported if Xn Possible in
standards impact standards over SRI, no exists theory, but
impact standards performance
impact seems
questionable
Mobility through the Supported, no Supported, no Supported, no Supported, no Supported, no
5GC standards impact standards standards standards standards
impact impact impact impact

8.4 Transport aspects

In the transparent case, a NTN GW connects directly to one or several satellites via SRI. In the regenerative case, a
NTN GW can directly connect to one or several satellites via SRI, or indirectly connect to one or several satellites via
ISL. Hence the NG protocol is transported over SRI, and may also be transported over ISL.

A gNB is connected to the 5GCN. The transport of this logical interface can be realized over SRI and possibly over ISL.

The satellite may embark additional transport routing functions that are out of RAN scope.

SRI transports 3GPP-RAN specified protocols i.e., transmits the NG interface signalling packets.

ISL can transport:

● Xn interface signalling packets and enable coordination between gNBs on board adjacent satellites, and
especially to support UE mobility, from a source gNB to a target gNB.

● Data packets, in case traffic functions are hosted on board the satellites.

● NG interface signalling packets

● F1 interface signalling packets

8.4.1 Characteristics of transport links in NTN

8.4.1.1 Characteristics of SRI on the feeder link

Transport over SRI may be subject to the following constraints:

1) Much longer propagation delay with respect to terrestrial transport links – the typical length for an Earth-satellite
link can go from a few thousands of km (LEO scenario) to several tens of thousands of km (GEO scenario) .
Hence the one way delay over the SRI ranges from 6 ms (LEO at 600 km and 10° elevation) to ~136 ms (GEO at
35788 km and 10° elevation);

2) Possibly higher outage probability with respect to terrestrial transport links when the SRI operates at mm-wave,
which is heavily impacted by atmospheric propagation impairments (e.g. rain attenuation). However this is
mitigated through Uplink power control, Adaptive Coding and Modulation and/or space diversity schemes.
Typically a feeder link is dimensioned to provide availability up to 99.999% with site diversity;

3) The SRI may become unavailable

3GPP
Release 16 123 3GPP TR 38.821 V16.0.0 (2019-12)

a. due to atmospheric attenuation when SRI operates at mm-wave

b. when the satellite disappears below the horizon in LEO constellation

Therefore mobility management is typically activated to ensure a seamless service continuity and 0 ms interruption
time, as described in Section 8.4.1.3.

In the transparent payload case,

● a GEO or a LEO satellite can be connected to several NTN-GW at a given time. Each NTN-GW will address
different radio resources of the satellite.

● a feeder link switch over can be performed using two distinct radio resources simultaneously to ensure a packet
loss less switch over. This procedure is network originated.

In the regenerative payload case,

● a LEO satellite can be connected to only one NTN-GW at a time except during feeder link switch over to ensure
a seamless service continuity following the make before break approach.

● a feeder link switch over can be based on a make before break strategy to obtain a loss less switch over. This is
transparent to the UE for layer 3 and below NG-RAN procedures. This procedure is network originated.

8.4.1.2 Characteristics of Inter Satellite link

In the LEO case, the one-way ISL propagation delay is constellation specific. Values around 10ms may be considered
as typical.

Inter Satellite Links in LEO constellations typical feature an availability probability of 99.999%.

8.4.1.3 Characteristics of NTN GW

In the case of transparent satellite, the NTN GW supports all necessary functions to forward the signal of NR-Uu
interface.

In the case of regenerative satellite, the NTN GW is a Transport Network Layer node, and supports all necessary
transport protocols, e.g. the NTN GW acts as an IP router. The SRI provides IP trunk connections between the NTN
GW and the Satellite to transport respectively NG or F1 interfaces.

8.4.1.4 Ephemeris
Satellite ephemeris information may be used to predict feeder link switchover occurrences, mobility management events
(idle and connected mode), radio resource management, as well as pre/post compensation of common delay/Doppler
shift/variation in NTN based NG-RAN.

The satellite ephemeris information may also be beneficial to 5GC, e.g. mobility management.

There may be an OAM requirement to configure the satellite ephemeris information in the RAN and CN. The
ephemeris information can be expressed in an ASCII file using Two-Line Element (TLE) format, which is a de facto
standard.

8.4.2 Transporting F1 over the SRI

According to the definitions given in TS 38.401 [3], the CU hosts the RRC, SDAP and PDCP protocols, and the DU
hosts RLC, MAC and PHY layers; the CU controls the operation of one or more DUs. When F1 is transported over the
SRI, the above functionality may be subject to the following constraints as described in 8.4.1.1.

Long propagation delay might be addressed by setting appropriate timers (up to implementation) so that operation in the
various protocol layers is not disrupted by the NTN use case. However, the fact that RRC is terminated in the CU poses
an additional criticality: if the CU is on the ground, the roundtrip time for a single RRC message between the UE and
the CU corresponds to twice the Earth-satellite link (the RRC message travels through Uu over the NR air interface and
then, transported over F1, through the SRI). Regardless of whether current NR RRC can withstand this additional

3GPP
Release 16 124 3GPP TR 38.821 V16.0.0 (2019-12)

constraint, this might put any NTN architecture based on CU-DU split (described in Sec. 5.3.2) at a disadvantage with
respect to all others in terms of RRC latency.

The impact of outage probability might be analysed by comparing the typical maximum outage duration for an Earth-
satellite link at mm-wave frequency band with the time it takes for a CU to declare a UE "lost" and start removing the
context (typically less than a minute). In case of an SRI outage, this will negatively impact the CU operation.

In addition, the fact that there are two Earth-satellite paths involved between the CU and the UE, may also negatively
impacts all CU-DU-split-based architecture options with respects to all others also in terms of outage: the outage
probability of these architectures depends on the combined outage probability on both links. This will depend on the
performance of the SRI.

Using multiple Earth-satellite links to transport the same F1 interface by exploiting SCTP multi-homing, or multiple
SCTP associations between CU and DU, might possibly mitigate the SRI unavailability due to outage or gateway
switching at the cost of additional latency. This would be a trade-off between link outage de-correlation and added
latency: the further apart the Earth stations are, the more the link outages would de-correlate, thereby decreasing the
combined link outage, but the total distance to the CU (hence the F1 latency) would increase, thereby increasing
latency.

8.4.3 Applicability of Xn to NTNs

8.4.3.1 List of Current Xn Functions

There was no contributions highlighting a restriction against the list of function supported in TS 38.420 [11] during the
Study item.

8.4.3.2 Inter-Satellite Xn
UE mobility management for inter-satellite Xn seems beneficial, of course under the assumption that both satellite-
gNBs connect to the same AMF pool. Purely from an architecture point of view, NR-NR DC is not precluded (with one
satellite acting as Master and the other as Secondary), although further analysis would be needed (e.g. on RRC aspects,
out of RAN3 scope) before concluding that NR-NR DC is supported. Energy saving is also not precluded purely from
an architecture point of view, although in this case there seems to be some benefit, with one satellite notifying another
of cell activation/deactivation as part of e.g. constellation reconfiguration.

Xn-U functions are applicable to mobility and DC, so the same considerations apply.

From the above it descends that inter-satellite Xn seems beneficial, although further analysis may be needed to assess
the feasibility of NR-NR DC in such a scenario.

From topology point of view, the Inter-Satellite Xn may be conveyed directly over ISL or via SRI.

8.4.3.3 On-ground NTN-terrestrial Xn

This would support Xn-based UE mobility and NR-NR DC features between on ground NTN gNB and a terrestrial
gNB, requires that both types of gNB connects to the same AMF pool.

Another feature is the support of Earth-satellite cell activation/deactivation notification over Xn. For example, a
terrestrial gNB may notify a satellite covering the same area that it is switching off one or more of its cells, and the
satellite may decide to "take over" the corresponding coverage area, and vice versa.

However the benefits of these features was not evaluated.

8.4.3.4 Transporting Xn over SRI

Transporting Xn over an Earth-satellite link between on board NTN gNB and terrestrial gNB has challenges, but it can
be configured if the transport performance of SRI allows so.

For example, in a LEO scenario, when a satellite moves below the horizon, all its Xn interfaces to terrestrial gNBs will
become unavailable, and this may trigger subsequent actions at application protocol and/or SCTP level in the relevant
terrestrial gNBs. The opposite will happen when the satellite appears at the horizon: Xn setups may be triggered to

3GPP
Release 16 125 3GPP TR 38.821 V16.0.0 (2019-12)

some terrestrial gNBs. This creates a technical issue, as it will lead to CP signalling surges corresponding to changes in
visibility of the LEO satellites.

Furthermore depending on the outage performance of the SRI, Xn may become unavailable for some periods of time.
This may trigger interface re-establishment toward all corresponding terrestrial gNBs, generating CP signalling surges
at every outage event. This would happen for all Xn interface terminated in the on board NTN -gNB impacted by the
outage event.

Therefore the benefit of this configuration was not evaluated.

8.5 Network Identities Handling

8.5.1 General
One of the most basic assumptions in the design of terrestrial radio access networks is that the RAN is stationary, and
the UE moves. All network design choices, from physical layer parameters to network identities, have been specified
with the above assumption in mind. When studying NTNs, however, the RAN is not necessarily stationary any more,
depending on the type of satellite system (e.g. GEO vs. non-GEO). Examples of geometrical coverages of a satellite are
given in [TR 22.822 Rel-16].

8.5.2 GEO based NTN (Scenario A and B)

Geostationary satellites are closer to the case of terrestrial RAN since they do not move with respect to their
geographical coverage area. As far as network identities are concerned (e.g. gNB IDs, cell IDs, TAC, etc.), they do not
seem to pose any additional issues with respect to the case of terrestrial RAN.

8.5.3 Non-GEO based NTN (Scenario C and D)

Non-GEO satellites (LEO, MEO and HEO), on the other hand, may provide additional challenges, because their
coverage may move due to their orbital movement. One of the consequences, for example, is that mobility actions by
the network will result from the combination of satellite movement and UE movement.

As the satellite moves across the geographical area of interest, its satellite beams will cover different portions of that
area. The following scenarios could be envisaged for associating logical network identifiers to physical satellite beams:

1) The association between physical satellite beams and logical cells is continuously reconfigured so that the same
gNB ID, cell ID and TAC are always associated to the same geographical area ("Stationary identifiers on
ground");

2) The association between physical satellite beams and logical cells is fixed, so that the gNB ID, cell ID and TAC
follow the satellite beam(s) and "sweep" across the coverage area ("Moving identifiers on ground").

Notice that in both cases the required configuration is internal to the gNB (satellite system) serving the concerned cells.

In both cases, once the satellite moves out of coverage (e.g. below the horizon), the corresponding cell network
identifier(s) will become unavailable in the coverage area. This may trigger multiple NG and/or Xn setup or
configuration update procedures toward the rest of the RAN. This may be critical when comparing the different
architecture options. Ephemeris information could assist decisions to trigger interface setup and/or configuration
updates.

8.5.3.1 Stationary Identifiers on ground

A stationary UE on the ground will always be covered by the same cell identifiers in the same position (similarly to the
terrestrial network scenario). This is only possible for earth-fixed beams. Depending on how closely the granularity of
the satellite beams enables to contour the desired coverage area, there could be slight variations in coverage. However,
apart from the frequent NG and/or Xn setup or configuration update, it seems there would be no other impact.

8.5.3.2 Moving Identifiers on ground

3GPP
Release 16 126 3GPP TR 38.821 V16.0.0 (2019-12)

A stationary UE on the ground will be covered by different cell identifiers in the same position, according to the
satellite motion. The moving satellite is likely to provide multiple cells, which will all move together; therefore, their
respective neighbour relations will remain unchanged with respect to the satellite motion. However relative position
between satellites may vary so that PCI confusion is possible. If the same frequency is used by the NTN and Terrestrial
Network at a given location, then this may cause PCI confusion as well.

8.5.3.3 Possible Implications on Neighbour Relationships

One aspect to further consider is what happens with respect to fixed (e.g. terrestrial) RAN nodes: in principle, the
neighbour relation between two cells belonging to respectively a fixed RAN and a moving RAN or to two different
moving RAN keeps changing reusing current mechanisms such as e.g. ANR between a fixed RAN and a moving RAN.

8.5.3.4 Possible PCI Conflicts

Moving cells can create PCI conflicts, namely PCI collisions (when two cells with the same PCI become direct
neighbours) and PCI confusion (when two cells with same PCI become neighbours of one cell). The result of those PCI
conflicts can be radio link failures (PCI collision) or handover failures (PCI confusion). Unfortunately, it is not always
possible to detect that the root cause of those failures were a PCI problem, and not another mobility problem. PCI
problems can be avoided by two principle methods

● If there are less cells than PCIs, then we can certainly assign unique PCIs. Similarly, if we can partition the cells
into groups, where we can guarantee that groups are sufficiently spatially separated, we can partition the PCIs
appropriately and assign unique PCIs within the groups.

● In case it is difficult to assign unique PCIs within the groups, it may require to regularly verify whether the PCI
allocation is still appropriate and re-plan PCIs otherwise. For NTN architecture with gNB-CU on ground, the Xn
interface can help the gNB-CU to detect the PCI collision and the PCI confusion. For NTN architecture option
with gNB on satellite, the Xn over ISL or Xn over SRI, is needed for satellite gNB to detect the PCI collision
and the PCU confusion.

In some scenarios, the NTN cell may need to change PCI. For example, in case a gNB-CU change with gNB-DU
on satellite, the NTN cell may have to change PCI in order to force a handover procedure, which is used to
reconfigure the UE with new parameters generated by the new gNB-CU. In these scenarios, a NTN cell may
need to be preconfigured with multiple PCIs, i.e. to be used with different gNB-CUs. Alternatively, the gNB-CU
may reconfigure the new PCI.

Existing Xn interface and F1 interface can be reused for distributed PCI selection and PCI reconfiguration.

8.6 User Location

A non-terrestrial network may provide global, or multi-country coverage. This imposes new challenges as compared to
the terrestrial networks. For example, different policies may apply in different countries. The policies are enforced
while the UE is in RRC CONNECTED mode.

The coverage area of one satellite beam may cover (parts of or) more than one country at times, while the satellite field
of view may be larger than a country.

The User Location Information, i.e. NTN cell id, may not provide sufficient accuracy to the network to ensure that the
right, country-specific policies can be applied. A more accurate UE location determination scheme for RRC
CONNECTED UE may be needed to enforce country-specific policies.

When the UE cannot report the exact position information for some reason, such as GPS loss or do not have position
capability, the national granularity can be obtained from the PLMN of the terrestrial network. For example, the UE can
read and report the surrounding cells PLMN.

The UE location information could be report by several ways:

● Option 1: the UE can report the location information to the AMF through the NAS message, e.g. during the
Registration Procedure;

● Option 2: Upon the reception of the UE's location information from the UE, the gNB forwards it to the AMF. In
this manner, the network side can control the UE report more strictly.

3GPP
Release 16 127 3GPP TR 38.821 V16.0.0 (2019-12)

8.7 Feeder link switch over

8.7.1 Principles
During NTN operation, it may become necessary to switch the feeder link (SRI) between different NTN GWs toward
the same satellite. This may be due to e.g. maintenance, traffic offloading, or (for LEO) due to the satellite moving out
of visibility with respect to the current NTN GW. The switchover should be performed without causing service
disruption to the served UEs. This can be done in different ways according to the NTN architecture option deployed.

8.7.1.1 Transparent Satellite

8.7.1.1.1 Transparent LEO, Architecture Option 1, different gNBs

Figure 8.7.1.1-1: Feeder link switch for transparent LEO NTN

Figure 8.7.1.1-1 shows the feeder link switch for transparent LEO. As seen from the figure, in the transparent case the
gNB is on earth thus there will be a switch from gNB1 to gNB2. If the satellite can be served by one feeder link at a
time it means that with Rel-15 NR assumptions the RRC connection for all UEs served by the gNB1 (via GW1) needs
to be dropped. After gNB2 (via GW2) takes over, the UEs may be able to find the reference signals corresponding to
gNB2 and perform initial access on a cell belonging to gNB2.

Figure 8.7.1.1-2 shows one possible solution to enable service continuity for feeder link switch. At time T1, the satellite
is approaching the geographical location where the transition to be served by next GW will happen. At time T1.5, the
satellite is served by two GWs and at time T2 the transition to next GW is finished.

Figure 8.7.1.1-2: Feeder link switch over for LEO transparent satellite with two feeder links serving
the satellite during the switch

3GPP
Release 16 128 3GPP TR 38.821 V16.0.0 (2019-12)

Assuming two feeder link connections serving via the same satellite during the transition (time T1.5 in Figure 8.7.1.1-
2), there exists a HO based solution that should be feasible with Rel-15 or close to Rel-15 assumptions. This assumes
that it is possible to represent cells of two different gNBs over a given area via the same satellite but via different NTN-
GWs. The two gNBs may utilize different radio resources of the transparent satellite to ensure both gNBs are visible to
the UE (overlapping coverage areas) simultaneously. During the switch, the gNB2 which serves the satellite via GW2
may start transmitting the CD-SSBs of its cells on synchronization raster points that are different from those of the
gNB1. UEs could be have a HO from PCI belonging to gNB1 to PCI belonging to gNB2. This could be a blind HO
(network decision without measurement) or assisted with measurements. Alternatively, the gNB1 may be present for a
first time-period and configure a conditional handover to the gNB2, after which the gNB2 is available for a second
time-period where the UEs can then perform the radio handover. Furthermore, the mobility solution may need to also
mitigate for the fact that the UEs may observe very similar RSRP/RSRQ of the service links, provided by the source
and target gNBs, because the reference signals are transmitted from the same satellite. One solution may be left to
network implementation, e.g. setting proper event A5 thresholds for conditional handover to enable handover, or to rely
on radio propagation time instead or in combination with the RSRP/RSRQ radio measurements. Relying on radio
propagation time includes to take the RTT experienced by the UE into account in handover decisions. Either as
condition in CHO or in network HO decision.

Figure 8.7.1.1-3 shows another possible solution to enable service continuity for feeder link switch. At time T1, the
satellite stops to transfer the signalling from the serving GW1. At time T2, the satellite starts to transfer the signalling
from the target GW2.

Figure 8.7.1.1-3: Feeder link switch over for LEO transparent satellite with one feeder links serving
the satellite during the switch

Assuming only one feeder link connection serving via the same satellite is applicable during the transition, which means
the signal of the serving cell will be not available during time T1 to time T2. To make the UE access to the serving cell
again, two potential options are listed below:

Solution 1: Feeder link hard switch procedure is based on accurate time control

Assuming the old feeder link serves the satellite until to T1 and the new feeder link begins to serve the satellite from T2.
This assumes that the cells of the source gNB(s) are represented over a given area at any time before T1, and the new
cells of the target gNB(s) are represented from time T2.

As there's no overlap of source cells and target cells from the gNB(s) located at the old and the new NTN GWs, the
switch over relies on accurate time control. The handover command should be sent to all the UEs before T1, e.g. CHO.
The UE should not initiate the handover procedure immediately upon receiving the Handover Command, instead, UE
should initiate the handover procedure after T2, and thus an activation time should be included in the handover
command to all the connected UEs.

Solution 2: Feeder link hard switch procedure is based on conditional RRC re-establishment

Considering the large cell size of NTN, it might be an extremely difficult problem for gNB1 to send HO commands to a
large number of UEs respectively in a short time. A part of UEs may not be able to perform HO in time, as a result,
radio link failure may be detected and then UEs initiate the RRC reestablishment procedure. It will take a long time to
restore RRC connection, which may involve RLF detection, cell selection and potential reestablishment failure, as a
result it has an influence on the service continuity. Thus it may be beneficial for network to provide assistance
information (e.g. next cell identity and/or reestablishment conditions) to trigger UE RRC reestablishment instead.
Besides, the assistance information can be sent to UE via SIB instead of dedicated signalling respectively, as a result,
the signalling overhead caused by the large number of UEs can be effectively reduced.

3GPP
Release 16 129 3GPP TR 38.821 V16.0.0 (2019-12)

How to enable cells of two gNB via the transparent LEO satellite can be defined in the WI phase.

8.7.1.1.2 Transparent LEO NTN, Architecture Option 1, same gNB

It is also possible the transparent satellite is served before and after the feeder link switch by the same gNB. In this case,
both feeder links are connected to the same gNB, but through different NTN-GWs.

Assuming two feeder link connections serving via the same satellite during the transition, it could be possible for the
gNB to keep the DL reference signals and to keep the cell "alive".

Note: In this case, it may be possible to not to need a HO if the security keys of gNB can be kept but there may merely
be an interruption, or slight discontinuity in DL transmissions. It should be also noted that the need for reconfiguration
with sync(HO), or without sync, depends on whether gNB configuration remain the same or not during the switch.

Assuming only one feeder link connection serving via the same satellite during the transition, the satellite will need to
first stop relaying using the feeder link connection with the NTN-GW1 and then start relaying using the target NTN-
GW2. In this scenario the cell cannot be kept "alive" without interruption and there will be a discontinuity in DL
transmissions as illustrated in Figure 8.7.1.1-4.

For Feeder link hard switch, the solutions captured in 8.7.1.1.1 in different gNBs scenario can be also applied to this
same gNB scenario.

Figure 8.7.1.1-4: Using 1 gNB and 2 feeder links in a transparent satellite

At time A) the gNB A is connected with the source NTN-GW and serving the UE. At time B) the gNB A is serving
users via the target NTN-GW.

The switchover relies on the temporary overlap of cells from the gNBs located at the old and the new NTN GWs. The
UEs are then handed over from the old to the new gNB, before the old gNB detaches from the satellite. It is a
prerequisite that the cells from the new gNB are seen as neighbours by the old gNB, hence Xn needs to be up and
running between the two gNBs. Furthermore, the whole process (from UEs measuring the new cells to handover
completion) needs to take place before the old gNB detaches from the satellite (potentially critical for the LEO case).

It may be beneficial for the two gNBs to exchange information at Xn Setup and/or NG-RAN Node Configuration
Update about the satellite(s) potentially involved, for example:

● A list of satellites to which the gNB connects;

● For each satellite in the list, an ID, a list of cell(s) from the gNB which is served through the satellite, and the
ephemeris data for the satellite.

8.7.1.2 Regenerative Satellite, Split gNB

3GPP
Release 16 130 3GPP TR 38.821 V16.0.0 (2019-12)

The switchover can be supported for this architecture option only if the gNB-CU on the ground is centralized. In this
case, both NTN GWs are part of the TNL transporting the F1 interface between the gNB-DU on the satellite and the
centralized gNB-CU. The switchover is then equivalent to adding/removing an SCTP association between the CU and
the DU. According to current specifications, this is triggered from the gNB-CU.

Option A: The DU may signal, at F1 Setup and/or DU Configuration Update, the relevant satellite information (e.g.
satellite ID, ephemeris data); the CU may take it into consideration when configuring the TNL.

Option B: The CU may take into consideration, the relevant satellite information (e.g. satellite ID, ephemeris data)
when configuring the TNL transporting the F1 interface.

8.7.1.3 Regenerative Satellite, with full gNB on board, Architecture Options 3-5
In this architecture option, the full gNB is onboard of the satellite as payload. If we consider the LEO case, from Uu
perspective, this case is considerably simpler than the transparent LEO NTN as the Uu is only transmitted via service
link as compared to being transmitted via service and feeder links. The feeder link switch can be transparent at Uu
interface as long as the security keys of the gNB can be preserved. Figure 8.7.1.3-1 depicts the situation.

Figure 8.7.1.3-1: Feeder link switch over for regenerative LEO with full gNB as payload with two
feeder links serving the satellite during the switch

The other situation, when using full gNB and one feeder link during the switch entails there will be a break in satellite –
NTN GW connectivity, when the feeder link is switched from the source NTN GW to the target NTN GW. To
smoothen the feeder link switch, the configuration of transport association for the target NTN-GW feeder link may be
signalled before the source NTN-GW feeder link breaks. In principle, the gNB may continue to broadcast system
information while the switch is ongoing, but refrain from scheduling any users, since the feeder link connectivity to
Earth is not available. In this way, the cell(s) will not disappear from UE perspective. If the AMF does not change, the
switch is transparent to the UEs except for a U-plane delay, because cell ID, MIB, SI remains the same. Figure 8.7.1.3-2
depicts this situation.

3GPP
Release 16 131 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 8.7.1.3-2: Feeder link switch over for regenerative LEO with full gNB as payload with two
feeder links serving the satellite during the switch

Figure 8.7.1.3-3: Feeder link switch over for regenerative LEO with full-gNB as payload with one
feeder link serving the satellite during the switch

8.7.1.3.1 Regenerative LEO NTN with one gNB-DU as payload, Architecture Options 3-5
In case of having a CU-DU split with one DU on the satellite, while the CU is on the ground and one feeder link, the
same gNB-CU may be connected to both the source and the target NTN GW the F1 may be re-routed to the target NTN
GW at a specific point in time. In this case the switch may be transparent to the UEs except a user-plane delay. The
gNB-DU may continue to broadcast system information, but not schedule UEs. Note that the gNB CU refers to a
combination of gNB CU user plane or gNB CU control plane.

3GPP
Release 16 132 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 8.7.1.3.1-1: Using 1 gNB-DU on the satellite and 1 feeder link

At time A) the gNB-DU is connected with the source NTN-GW and serving the UE. At time B) the feeder link switch is
taking place and the gNB-DU is not connected with any NTN-GW. The gNB-DU may still broadcast system
information to the UE. At time C) the gNB-DU is serving users via the target NTN-GW. In case the gNB-DU connect
to a new gNB-CU at time C) the UE would need to perform a handover or cell reselection.

If the gNB-CU is changed the gNB-DU will initiate the F1 setup procedure to connect with the next gNB-CU (note a
gNB-DU can only connect to one gNB-CU at a time and thus the connection with the current gNB-CU must first be
terminated). When the connection between the new gNB-CU and the gNB-DU is established through the target NTN
GW the cell ID, MIB, and SI will need to be updated to reflect the new gNB-CU configuration. This will imply a drop
of the connection for all UEs in the coverage area, who can reconnect to the new gNB-CU after the switch. The scenario
is illustrated in Figure 8.7.1.4-1

If the gNB-CU is changed the UEs will be disconnected with RLF, because a HO requires both source to target CU to
communicate with the DU on the satellite, and this is not possible because a DU can only be connected to one CU at a
time.

In this case, both NTN GWs are part of the TNL transporting the F1 interface between the gNB on the satellite and the
AMF. The switchover is then equivalent to adding/removing an SCTP association between the gNB and the AMF.
According to current specifications, this is triggered from the AMF. The gNB may signal, at NG Setup and/or RAN
Configuration Update, the relevant satellite information (e.g. satellite ID, ephemeris data); the AMF may take it into
consideration when configuring the TNL.

8.7.1.3.2 Regenerative LEO NTN with two gNBs, or gNB-DUs as payload, Architecture
Options 3-5
Having two gNB-DUs with individual feeder link connections entails the UEs may perform intra-gNB-CU inter-gNB-
DU mobility (in case the gNB-CU does not change). This is significantly faster than a gNB-CU change, which
corresponds to a regular gNB-gNB handover, but also includes F1 communication and the related delays.

8.7.2 Procedures

8.7.2.1 Transparent payload case

The switchover may be predictable (e.g. based on the LEO satellite ephemeris information and NTN GWs location) or
event-triggered (e.g. for maintenance). In this case, it could be beneficial to introduce a dedicated, non-UE-associated
Xn procedure (Satellite Connection Request) to signal from the old to the new gNB that it should connect to the
specified satellite, optionally including the list of cells served through the satellite.

3GPP
Release 16 133 3GPP TR 38.821 V16.0.0 (2019-12)

Figure 8.7.2.1-1: Feeder link switch over procedure for transparent LEO satellite (Scenario C2)

This above described procedure allows a soft switch procedure.

Alternatively, a hard switch procedure could be considered to allow for no simultaneous connectivity between satellite
and the 2 NTN-GWs.

This would require to prepare and execute the hand-over precisely using ephemeris data and accurate time information.

8.7.2.2 Regenerative payload case (gNB on board)

As the LEO satellite moves out a specific geographic area, the satellite may be out of the serving area of the NTN
Gateway, and needs to connect to a new NTN Gateway. There are two further cases:

Case 1: the satellite remains in the coverage area of current AMF.

To use the new NTN Gateway for the SCTP with the current AMF, the satellite/gNB has to use a new IP address
that is anchored in the NTN Gateway. The satellite/gNB could use the multiple TNLAs by adding the new SCTP
IP address then remove the old SCTP IP address. This may results the termination of the existing STCP, and setup
a new SCTP using the new IP address. Alternatively, the satellite/gNB may use Mobile IP, or Proxy Mobile IP to
maintain the SCTP with the current AMF using the current IP address. The NG interface remains unaffected after
the satellite/gNB connects to current AMF via the new NTN Gateway.

=> Considering that NTN-GW is transport network node, this case can be supported by existing NG procedure
(set-up, configuration update, etc..) without modification

3GPP
Release 16 134 3GPP TR 38.821 V16.0.0 (2019-12)

Case 2: the satellite moves into a coverage of a new AMF.

The satellite/gNB need to setup the connection with a new AMF.

How to handle the NG connection with the old AMF?

There is no NG release procedure. It is unclear whether the gNB/AMF can use the indication from the SCTP
layer, e.g. the satellite/gNB initiates a SCTP Shutdown before it leaves the old AMF. This should be treated
differently than the abnormal case, e.g. satellite/gNB lost the connection with the AMF due to bad satellite
radio connection. Since the satellite/gNB will connect to the same AMF in the near future, there may be no
need to release the NG.

=> Therefore we may enhance the NG procedure for example the satellite/gNB and AMF may suspend the
NG interface and keep the application level configuration data when the satellite/gNB leaves, then resume
the NG interface when the satellite/gNB connects to the same AMF later.

How to setup the NG connection with the new AMF?

A gNB can setup NG connection with multiple AMFs. So it is possible that the satellite/gNB setup the NG
with the new AMF, while still keep the NG with the old AMF.

=> No impact to NG procedure is expected

8.7.2.3 Regenerative payload case (gNB split)

As the LEO satellite moves out of a specific geographic area, the satellite/gNB-DU loose the connection with current
NTN Gateway, and needs to connect to a new NTN Gateway. There are two further cases:

Case 1: the satellite remains in the coverage area of current gNB-CU.

To use the new NTN Gateway for the SCTP with the current gNB-CU, the satellite/gNB-DU has to use a new IP
address that is anchored in the NTN Gateway. The satellite/gNB-DU could use the multiple TNLAs by adding the
new SCTP IP address then remove the old SCTP IP address. This may results the termination of the existing
STCP, and setup a new SCTP using the new IP address. Alternatively, the satellite/gNB-DU may use Mobile IP, or
Proxy Mobile IP to maintain the SCTP with the current gNB-CU using the current IP address. The F1 interface
remains unaffected after the satellite/gNB-DU connects to current gNB-CU via the new NTN Gateway.

=> Considering that NTN-GW is transport network node, this case can be supported by existing F1 procedure
(set-up, configuration update, etc..) without modification

Case 2: the satellite moves into a coverage of a new gNB-CU.

The satellite/gNB-DU need to setup the new F1 with the new gNB-CU. There are some issues that need to be
further studied:

Issue 1: How to handle the F1 connection with the old gNB-CU?

There is no F1 release procedure. It is unclear whether the gNB-CU/DU can use the indication from the SCTP
layer, e.g. the satellite/gNB-DU initiates a SCTP Shutdown before it leaves the old gNB-CU. This should be
treated differently than the abnormal case, e.g. satellite/gNB-DU lost the connection with the gNB-CU due to
bad satellite radio connection. Since the satellite/gNB-DU will connect to the same CU in the near future, there
may be no need to release the F1. Instead, the satellite/gNB-DU and gNB-CU may suspend the F1 interface
and keep the application level configuration data when the satellite/gNB-DU leaves, then resume the F1
interface when the satellite/gNB-DU connects to the same gNB-CU later.

=> Therefore we may enhance the F1 procedure for example the satellite/gNB-DU and CU may suspend the
F1 interface and keep the application level configuration data when the satellite/gNB-DU leaves, then
resume the F1 interface when the satellite/gNB-DU connects to the same CU later.

Issue 2: how to setup the F1 connection with the new gNB-CU?

According to current F1AP, one DU can only connect to one CU. It is not possible for the DU to setup the F1
with the new CU, while still keep the F1 with the old CU. One possibility is to have 2 DUs on the satellite.
While the 1st DU connects to the old gNB-CU, the 2nd DU setup the connection with the new gNB-CU.

3GPP
Release 16 135 3GPP TR 38.821 V16.0.0 (2019-12)

=> No impact to F1 procedure is expected

8.8 Operations & Maintenance (O&M)

The Non-Terrestrial Networks architecture shall fulfil the O&M requirements on transport of O&M information
between the Management System on the ground and Non-Terrestrial Node(s) on the satellite.

If possible, the software (or upgrade) should be ensured.

Referring to the architecture scenarios clause 8.3.1:

Table 8.8-1: O&M support for the various architectures

Arch. 1 Arch. 2 Arch. 3 Arch. 4 Arch. 5

Transport of O&M Supported, no Supported, no Supported, no Supported, no Does not apply
information standards standards standards standards
impact impact impact impact
– – – –
Minimum Full O&M Full O&M Full O&M
(Alarm)
Hardware Not supported Not supported Not supported Not supported Not supported
maintenance
Software Supported Supported Supported Supported Not supported
maintenance

NOTE: the hardware maintenance and the software maintenance in case of Arch.1 should be rare.

9 Recommendations on the way forward

9.1 Recommendations from RAN1

Based on the evaluation results of this study, it can be concluded that:

● Class 3 UE can be served by LEO and GEO in S-band with appropriate beam layout (including potential
frequency reuse and/or polarization reuse).

● Other UE (e.g. VSAT and phase array) with high TX/RX antenna gains can be served by LEO and GEO in both
S-band and Ka-band with appropriate beam layout (including potential frequency reuse and/or polarization
reuse)

Existing Rel-15 and Rel-16 NR functionalities form a very good basis for supporting NTN scenarios (LEO and GEO).

There are however issues due to long propagation delays, large Doppler effects, and moving cells in NTN. To address
the identified issues, for a potential normative phase, it is proposed to focus on the following:

● Timing relationship enhancements

● Enhancements on UL time and frequency synchronization

● Enhancement on the PRACH sequence and/or format in the case pre-compensation of timing and frequency
offset is not done at UE side

In addition, the following topics should be discussed when specifications are developed:

● Beam management and BWP operation for NTN with frequency reuse.

- Including signalling of polarization mode

● Feeder link switch impact on physical layer procedures in case of LEO scenarios

3GPP
Release 16 136 3GPP TR 38.821 V16.0.0 (2019-12)

● Number of HARQ process with additional considerations such as HARQ feedback/buffer size and RLC ARQ
feedback/buffer size in the case of LEO and GEO scenarios

● Support of enabling / disabling of HARQ feedback.

In addition, discussions identified in clauses 6.2 to 6.4 of the document without conclusions, can be continued.

PAPR optimizations for downlink channels are not necessary to be specified for NTN at least for Rel-17.

9.2 Recommendations from RAN2

Based on the study performed, Rel.15 and NR can support NTN scenarios with enhancements identified below to be
considered as part of the normative work.

In general,

● Offset based solutions for timer adaptations are preferred to support all NTN scenarios.

● Earth fixed tracking area is recommended.

The Rel-15's user plane procedures apply to NTN with enhancements to the following features

● MAC

- Random access:

• Definition of an offset for the start of the ra-ResponseWindow for NTN and extension of the ra-
ResponseWindow duration to support UE without location information.

• Introduction of an offset for the start of the ra-ContentionResolutionTimer to resolve Random access
contention

• Solutions for resolving preamble ambiguity and extension of RAR window.

• Adaptations for UEs with GNSS capabilities; timing advance and msg3 scheduling.

- Timing advance: TA calculation and signaling adaptation to deal with NTN maximum round trip delay in
LEO and GEO scenarios for UE with and without UE location information.

- DRX:

• If HARQ feedback is enabled, an offset should be added for drx-HARQ-RTT-TimerDL and drx-HARQ-
RTT-TimerUL.

• If HARQ is turned off per HARQ process, adaptions in HARQ procedure may be required

• Options for UE power saving for SR and CFRA can be discussed during work item phase

- Scheduling Request: Extension of the value range of sr-ProhibitTimer

- HARQ

• enabling / disabling of uplink HARQ feedback for downlink transmission at the UE receiver should be
configurable per UE and per HARQ process.

• enabling / disabling of HARQ uplink retransmission should be configurable per UE or per HARQ
process. The LCP impact caused by disabling the HARQ uplink retransmission configuration and its
impact on UE's uplink transmission should be discussed in the work item phase.

• Multiple transmission of the same TB to lower residual BLER should also be configured.

● RLC

- Status reporting: Extension of the value range of t-Reassembly

3GPP
Release 16 137 3GPP TR 38.821 V16.0.0 (2019-12)

- Sequence Numbers: extension of the SN space only for GEO scenarios will be discussed during the work
item phase

● PDCP

- SDU discard: Extension of the value range of discardTimer will be discussed during the work item phase.

- Sequence Numbers: extension of the SN space for GEO scenarios will be discussed during the work item
phase.

The Rel-15's control plane procedures apply to NTN with enhancements to the mobility management procedures when
considering Earth moving beam footprint option.

● Idle mode:

- Definition of additional assistance information for cell selection/reselection (e.g. using UE location
information, satellite Ephemeris information)

- Use earth-fixed tracking area to avoid frequent TAU

- NTN cell specific information in SIB

● Connected mode:

- Definition of schemes to reduce service interruption during Hand-Over due to large propagation delay
(especially in the case of GEO transparent)

- Definition of schemes to tackle frequent handover and high handover rate due to satellite movement (e.g.
LEO NTN)

- Definition of schemes to improve handover robustness due to small signal strength variation in regions of
beam overlap

- Definition of schemes to compensate for propagation delay differences in the UE measurement window
between cells originating from different satellites, especially for LEO NTN

● Other mobility enhancements:

- Additional CHO triggering conditions (e.g. location/time based), and adaptation of measurement-based
thresholds and events to the NTN environment.

- Possible enhancements to mobility configuration (e.g. to support broadcast configuration)

- Enhancements to measurement configuration/reporting (e.g. pre-triggering based solutions)

- Service continuity for mobility from TN to NTN and from NTN to TN systems

The Rel-16's user plane 2 step RACH procedure can be considered during the WI phase with possible enhancements:

● The required adaptations will be discussed during the WI phase, such as inclusion of assistance information, e.g.,
SFN index, in MsgA etc.

● The trade-off between latency gain and UL overhead impact caused in NTN scenarios by the introduction of 2-
step RACH procedure can be further discussed during the normative work.

The same solutions identified for Earth moving cell scenario can also be applied for Earth fixed cell scenario, however
whether specific solutions are necessary (or preferred) for each scenario can be further evaluated in the normative
phase.

9.3 Recommendations from RAN3

There are no showstoppers to support any identified architecture options in clause 8:

● Transparent satellite based NG-RAN architecture

3GPP
Release 16 138 3GPP TR 38.821 V16.0.0 (2019-12)

● Regenerative satellite based NG-RAN architectures

The Regenerative satellite based NG-RAN architectures with gNB processed payload based on relay-like architecture
was not studied due to the pending work on IAB support (WI IAB_NR).

For a potential normative phase, it is proposed to focus on the following

● GEO based satellite access with transparent payloads

● LEO based satellite access with transparent or regenerative payloads

No specific issues have been identified to support the split regenerative payload case (gNB-DU on board) ; some
protocol adaptation may be needed in a potential normative phase.

In case, the architecture option based on relay-like architecture (IAB) needs to be supported in non-terrestrial networks,
further study will be needed.

9.4 Other assumptions

The NTN study results apply to GEO scenarios as well as all NGSO scenarios with circular orbit at altitude greater than
or equal to 600 km.

For other NTN scenarios with orbits less than 600 km as UAS (including HAPS) scenario, no specific analyses have
been performed during this study item. However, considering the characteristics of UAS such as delay (altitude),
footprint size (differential delay) and Doppler identified in this study item, the same enhancements as LEO may be
applicable for UAS because their values and variation rates are lower than LEO. The enhancements for LEO are not
necessarily required for UAS scenarios when delay, footprint and Doppler can be similar or equivalent values with
those of terrestrial network, but the detailed conditions were not discussed in this study item, as well.

3GPP
Release 16 139 3GPP TR 38.821 V16.0.0 (2019-12)

Annex A: Satellite ephemeris

A.1 Key parameters

Key parameters of orbital mechanics of all commercial satellites are publicly available from multiple sources. This
information is called ephemeris, which is used by astronomers to describe the location and orbital behaviour of stars and
any other astronomic bodies.

Typically, ephemeris is expressed in an ASCII file using Two-Line Element (TLE) format. The TLE data format
encodes a list of orbital elements of an Earth-orbiting object in two 70-column lines. The contents of the TLE table are
reproduced below.

Table A.1-1: First line of the ephemeris

Field Columns Content

1 01–01 Line number (1)
2 03–07 Satellite number
3 08–08 Classification (U=Unclassified)
4 10–11 International Designator (Last two digits of launch year)
5 12–14 International Designator (Launch number of the year)
6 15–17 International Designator (piece of the launch)
7 19–20 Epoch Year (last two digits of year)
8 21–32 Epoch (day of the year and fractional portion of the day)
9 34–43 First Time Derivative of the Mean Motion divided by two
10 45–52 Second Time Derivative of Mean Motion divided by six (decimal point assumed)
11 54–61 BSTAR drag term (decimal point assumed)
12 63–63 The number 0 (originally this should have been "Ephemeris type")
13 65–68 Element set number. Incremented when a new TLE is generated for this object.
14 69–69 Checksum (modulo 10)

Table A.1-2: Second line of the ephemeris

Field Columns Content

1 01–01 Line number (2)
2 03–07 Satellite number
3 09–16 Inclination (degrees)
4 18–25 Right ascension of the ascending node (degrees)
5 27–33 Eccentricity (decimal point assumed)
6 35–42 Argument of perigee (degrees)
7 44–51 Mean Anomaly (degrees)
8 53–63 Mean Motion (revolutions per day)
9 64–68 Revolution number at epoch (revolutions)
10 69–69 Checksum (modulo 10)

The TLE format is an expression of mean orbital parameters "True Equator, Mean Equinox", filtering out short term
perturbations.

From its TLE format data, the SGP4 (Simplified General Propagation) model [10] is used to calculate the location of
the space object revolving about the earth in True Equator Mean Equinox (TEME) coordinate. Then it can be converted
into the Earth-Centered, Earth-Fixed (ECEF) Cartesian x, y, z coordinate as a function of time.

The instantaneous velocity at that time can also be obtained. In ECEF coordinate, z-axis points to the true North, while
x axis and y axis intersects 0-degres latitude and longitude respectively as illustrated below.

3GPP
Release 16 140 3GPP TR 38.821 V16.0.0 (2019-12)

Figure A.1-1: Earth-Centered, Earth-Fixed (ECEF) coordinates in relation to latitude and longitude
(source https://en.wikipedia.org/wiki/ECEF)

An example of ephemeris converted into ECEF format for the Telestar-19 satellite is shown below as an example
below.

Epoch (day, hr, min, X[km] Y[km] Z[km] dX/dt[km/s] dY/dt[km/s] dZ/dt [km/s]
sec)

2018-10-26 19151.529 -37578.251 17.682 -0.00151 -0.00102 -0.00106

02:00:00.000

2018-10-26 19151.073 -37578.556 17.359 -0.00152 -0.00101 -0.00109

02:05:00.000

2018-10-26 19150.614 -37578.855 17.029 -0.00154 -0.00099 -0.00112

02:10:00.000

2018-10-26 19150.150 -37579.151 16.690 -0.00155 -0.00098 -0.00114

02:15:00.000

Given a specific point in time, it is straightforward to calculate the satellite location by interpolation. The example given
above refers to a geosynchronous (GEO) satellite, in which the epoch interval is 5 minutes. For LEO satellites, the
intervals may be much shorter, on the order of seconds.

3GPP
Release 16 141 3GPP TR 38.821 V16.0.0 (2019-12)

Annex B: KPI and evaluation assumptions

B.1 Key Performance Indicators

KPIs defined in TR38.913 are considered.

B.2 Performance targets for evaluation purposes

This table includes performance values that may be used for theoretical analysis or simulations.

The values relate to targeted performances, but should not be considered as strict requirements.

3GPP
Release 16 142 3GPP TR 38.821 V16.0.0 (2019-12)

Table B.2-1: Non-Terrestrial network target performances per usage scenarios

3GPP
Release 16 143 3GPP TR 38.821 V16.0.0 (2019-12)

Experience Overall
Activity
Usage data rate UE Max UE UE
factor Environment Sources
scenarios (note 2) density speed categories
(note 3)
DL UL per km2
Data rate => see 7.10.1
"extreme coverage
2 60 Extreme performance" in [13];
Pedestrian 100 1,50% 3 km/h Handheld
Mbps kbps coverage Activity factor: see table
6.1.6-1 "extreme rural"
in [13]
NGMN
(https://www.ngmn.org/)
Pedestrian 2 250 Extreme project on Extreme
100 1,50% 3 km/h Handheld
2 Mbps kbps coverage Long-Range
Communications for
Deep Rural Coverage
Along roads in
Vehicular 50 25 Vehicular data rate and activity
TBD N.A. 250 km/h low population
connectivity Mbps Mbps mounted factor in TS 22.261[12]
density areas
Data rate =>assuming
per end-user 50/25
Mbps data rate and an
50 25 Extreme Building average of 5 end-user
Stationary TBD N.A. 0 km/h
Mbps Mbps coverage mounted devices per stationary
UE) rate and 20%
activity factor per end-
user device
Data rate =>assuming
per end-user 15/7.5
Mbps data rate and
20% activity factor per
Airplanes 360 180 1 000 Airplane end-user devices (See
TBD N.A. Open area
connectivity Mbps Mbps km/h mounted [12]);
number of users per
airplane: average
aircraft size (assuming
120 users per plane)
Device density => [15] ;
IoT Data rate and activity
2 10 Extreme
connectivity 400 1,00% 0 km/h IoT factor => derived from
kbps kbps coverage
(note 4) [14] annex E.2 "Traffic
models for Cellular IoT"
Section 7.1 of TS
22.280
(To the extent feasible,
it is expected that the
end user's experience is
similar regardless if the
Public 3.5 3.5 MCX Service is used
TBD N.A 100 km/h Open area Handheld
Safety Mbps Mbps with a 3GPP network or
based on the use of a
ProSe direct
communication path.
Covers pedestrian
speed through medium
vehicular speeds.)

3GPP
Release 16 144 3GPP TR 38.821 V16.0.0 (2019-12)

Section 7.1 of TS
22.280
(To the extent feasible,
it is expected that the
end user's experience is
Public 3.5 3.5 Vehicle
TBD N.A 250 km/h Open area similar regardless if the
Safety Mbps Mbps mounted
MCX Service is used
with a 3GPP network or
based on the use of a
ProSe direct
communication path.)

NOTE 1: Void

NOTE 2: As defined in [12]

NOTE 3: As defined in [12]

NOTE 4: This refers to low power wide area service capability

NOTE 5: This does not preclude the definition of performance parameters for other usage scenarios in future stages

Signalling (control plane) and data (User plane) interruption time should be made as much as possible equivalent as in
terrestrial systems except in the case of handover between satellite and terrestrial access. In the latter case, this
interruption time will depend on the satellite orbit.

Annex C: Regulatory Aspects

In the ITU Radio Regulations (ITU, 2016) the interference to any GEO network caused by a NGSO system is strictly
constrained. One restriction to the system is that a NGSO system shall not cause unacceptable interference into any
GEO network in the fixed satellite service for uplink and downlink in the same frequency (in-line interference), shown
in Figure C-1. For that reason, (ITU, 2016) limits the maximum equivalent power flux densities (EPFD) of the NGSO
system to values which are not sufficient to enable satellite communication.

This document will focus on both the service uplink from the UE to the NGSO system (interfering the receiver on board
of a GEO satellite) and the service downlink from the NGSO system to the UE (interfering a GEO receive station on
earth).

3GPP
Release 16 145 3GPP TR 38.821 V16.0.0 (2019-12)

Figure C-1: In-line interference caused by NGSO systems (MEO or LEO)

Service uplink from UE to NGSO satellite:

Satellite specific user terminals are partly equipped with a dish antenna to reach high signal gains, due to its high
directivity. Especially for frequencies in the FR2 and the use of satellite specific user terminals on ground with high
directive antennas the problem of in-line interference arises for the service uplink in satellite system.

We look at a scenario in which the UE uses a directive antenna to communicate with a NGSO satellite. It may further be
able to track the movement of the NGSO satellite with its antenna. Given the high directivity it is possible that the UE
will glare a GEO satellite that is located in the same direction as the NGSO from the UE's perspective. As the uplink
transmission power could exceed the ITU regulatory constraints for in-line interference of the protected GEO satellites,
this issue has to be addressed already in the initial and random access phase. In the following we assume that the UE is
aware of its position as well as the network.

The problem with a heavy deployment of NGSO systems arises with so-called in-line interference. This type of
interference occurs, whenever a NGSO satellite crosses the line of sight path of an Earth station and a GEO satellite as
depicted in Figure C-1.

To avoid that the cell of the NGSO satellite has to be switched off completely, only the UE's with highly directive
antennas, which are pointing towards the GEO satellite should be disabled or hand over to other NGSO satellites.

Service downlink from NGSO satellite to UE:

In this case, the downlink signal from a NGSO satellite is interfering a GEO receive station on earth. The satellite beam
pointing towards the GEO ground station has either to be steered to another direction or has to be switched off
completely. The GEO receive station especially for FR2 are already deployed and protected by ITU regulations.

As a conclusion, in-line interference between NGSO and GSO satellite systems might occur especially when highly
directive antennas are used in NTN scenarios and solutions to comply with the ITU regulatory constraints for in-line
interference shall be specified for both uplink and downlink.

3GPP
Release 16 146 3GPP TR 38.821 V16.0.0 (2019-12)

Annex D (Informative):
Change history
Change history
Date Meeting TDoc CR Rev Cat Subject/Comment New
version
2018-08 RAN3#101 R3-185304 Skeleton TR 0.0.0
2018-08 RAN3#101 R3-185333 Agreed version including pCRs of R3-184522, R3-185235, R3- 0.1.0
185310
2018-10 RAN3#101 R3-186269 Agreed version including pCRs of R2-1815953, R3-186257, R3- 0.2.0
bis, 186112, R3-186214
RAN2#103
bis
2018-11 RAN3#102 R3-187281 Agreed version including pCRs of R3-187113, R3-187193, R3- 0.3.0
, 187195, R3-187196, R3-187273, R2-1816538, R2-1818514
RAN2#104
2019-03 RAN3#103 R3-191167 Agreed version including pCRs of R2-1900564, R2-1902554, R3- 0.4.0
, 191023, R3-191025, R3-191026, R3-191027, R3-191029, R3-
RAN2#105 191030, R3-191031, R3-191032, R3-191146
2019-04 RAN3#103 R3-192186 Agreed version including pCRs of R2-1905297, R3-191276, R3- 0.5.0
bis, 191631, R3-192103, R3-192110, R3-192111, R3-192113, R3-
RAN2#105 192115, R3-192170, R3-192169, R3-192119, R3-192171, R3-
bis, 192121, R3-192117
RAN1#96bi
s
2019-04 Post R3-192189 Removal of R3-192117 changes1. Corrections of chapter 5 headers 0.6.0
RAN3#103 numbering. Corrections of chapter 8 headers numbering
bis
2019-05 RAN3#104 R3-193293 Agreed version including pCRs of R3-192758, R3-193207, R3- 0.7.0
, 193208, R3-193209, R3-193212, R3-193216, R3-193277, R3-
RAN2#106 193287, R3-192783, R3-193182, R3-193049, R3-193217, R3-
, RAN1#97 193218, R2-1906302, R2-1907970, R2-1908243, R1-1907836
2019-09 RAN3#105 R3-194796 Agreed version including Agreements of Chairman's notes of 0.8.0
,RAN2#10 RAN1#98 as well as pCRs of R2-1910685, R2-1911748
7,
RAN1#98
2019-10 RAN3#105 R3-196330 Agreed version including Agreements of Chairman's notes of 0.9.0
bis,RAN2# RAN1#98bis as well as pCRs of R2-1913969, R2-1914055, R2-
107bis, 1914056, R2-1914069, R2-1914070, R2-1914194, R2-1914196, R2-
RAN1#98bi 1914198
s
2019-12 RAN3#106 R3-197795 pCRs of R1-1913436, R1-1913455, R1-1913426, R1-1913402, R1- 0.10.0
,RAN2#10 1913427, R1-1913260, R2-1914721, R2-1916376, R2-1916386, R2-
8, 1916392, R2-1916393, R2-1916396, R3-197002, R2-1916414, R2-
RAN1#99 1916415, R2-1916469, R2-1916351
2019-12 RAN#86 RP-192504 TR Submission to TSG RAN plenary for approval 1.0.0
2019-12 RAN#86 RP-193062 Corrections to TP implementation 1.1.0
2019-12 RAN#86 TR approved by TSG RAN plenary 16.0.0

1 TDOC agreed unseen at RAN3#103bis but not uploaded on time during the meeting!

3GPP