【学习笔记】卫星网络（NTN）的窄带物联网（NB-IoT）研究 -- 3GPP TR 36.763（二）

6 无线层1的问题及相关解决方案

6.1 IoT NTN参考参数

6.2 链路预算分析

6.2.1 链路预算参数

6.2.2.1.1 Set-1

6.2.2.1.2 Set-2

6.2.2.1.3 Set-3

6.2.2.1.4 Set-4

6.2.2.1.5 Set-5

6.3 时间和频率同步增强

6.3.1 GNSS位置固定对UE功耗的影响

6.3.1.1 UE功耗分析假设

6.3.1.2 独立的GNSS模块和IoT模块

6.3.1.3 集成GNSS模块和物联网模块

6.3.1.4 功耗——短暂偶发连接

6.3.1.5 功耗——长连接（例如，基于连续不连续接收，CDRX）

6.3.1.6 其他功耗评估观察

6.3.2 NTN系统信息块（SIB）读取对UE功耗的影响

6.3.3 长PUSCH和PRACH传输

6.3.4 下行链路同步

6.3.5 GNSS测量

6.3.6 PRACH拥塞

6.4 定时关系增强

6.5 HARQ

6.6 针对IoT NTN的具体增强建议

6.6.1 IoT NTN场景

6.6.2 时间和频率同步增强

6.6.3 定时关系增强

6.6.4 HARQ增强

关于卫星网络（NTN）的窄带物联网（NB-IoT）/增强型机器类型通信（eMTC）研究，特别是3GPP TR 36.763文档，随着地面移动通信的发展，虽然人们享受到了便捷的互联网服务，但地球上仍有大量区域缺乏通信手段。特别是在发生自然灾害时，地面移动通信系统可能因断电、断网而无法提供服务。因此，非地面网络（NTN）作为地面移动通信系统的延伸，为偏远地区和应急通信提供了重要解决方案。NTN主要包括卫星通信网络（如LEO、MEO、GEO卫星）和高空/空中平台网络（如飞机、气球、飞艇等）。

3GPP在Release 15至Release 17阶段对NTN进行了深入研究，旨在将卫星通信与移动通信融合，解决无服务或服务不足地区的服务可达性和连续性问题。其中，Release 17阶段完成了NTN的第一个标准，但主要聚焦于NTN接入网的“透明”架构和移动协议的改进。进入Release 18阶段后，3GPP立项了一系列关于NTN的增强研究项目，包括IoT NTN增强等。

卫星网络（NTN）的窄带物联网（NB-IoT）研究 -- 3GPP TR 36.763（一）-CSDN博客https://blog.csdn.net/u011376987/article/details/140996255?spm=1001.2014.3001.5501

卫星网络（NTN）的窄带物联网（NB-IoT）研究 -- 3GPP TR 36.763（二）-CSDN博客https://blog.csdn.net/u011376987/article/details/141310404?spm=1001.2014.3001.5501

卫星网络（NTN）的窄带物联网（NB-IoT）研究 -- 3GPP TR 36.763（三）-CSDN博客https://blog.csdn.net/u011376987/article/details/141333454?spm=1001.2014.3001.5501

卫星网络（NTN）的窄带物联网（NB-IoT）研究 -- 3GPP TR 36.763（四）-CSDN博客https://blog.csdn.net/u011376987/article/details/141352961?spm=1001.2014.3001.5501

标准下载：

卫星网络（NTN）的窄带物联网（NB-IoT）/增强型机器类型通信（eMTC）研究-3GPPTR36.763资源-CSDN文库

6 无线层1的问题及相关解决方案

6.1 IoT NTN参考参数

IoT NTN参考场景参数列于下表6.1-1中：

表6.1-1：IoT NTN参考场景参数

Scenarios	GEO based non-terrestrial access network - scenario A	LEO based non-terrestrial access network -Scenario B & C	MEO based non-terrestrial access network -Scenario D
Orbit type	station keeping a nominally fixed position in terms of elevation/azimuth with respect to a given earth point	circular orbiting at low altitude around the earth	circular orbiting at medium altitude around the earth
Altitude	35,786 km	600 km 1,200 km	10,000 km
Frequency Range	< 6 GHz (e.g. 2 GHz in S band)
Device channel Bandwidth (service link) (NOTE 7)	- NB-IoT 180 kHz (DL), Up to 180 kHz with all permissible smaller resource allocations 1215 kHz, 615 kHz, 315 kHz, 115 kHz, 13.75 kHz (UL) - eMTC: 1080 kHz (DL), Up to 1080 kHz with all permissible smaller resource allocations, including 2180 kHz, 180 kHz, 215 kHz or 315 kHz or 6*15 kHz (UL)
Payload	Transparent type	Transparent Type	Transparent type
Earth-fixed beams	Yes	Scenario B: Yes (steerable beams), see NOTE 1 Scenario C: No (the beams move with the satellite)	Scenario D: The beams move with the satellite
Max beam footprint size (edge to edge) regardless of the elevation angle	3500 km (NOTE 3)	1000 km (NOTE 2)	4018 km
Min Elevation angle for both sat-gateway and C-IoT device	10° for service link and 10° for feeder link	10° for service link and 10° for feeder link	10° for service link and 10° for feeder link
Max distance between satellite and C-IoT device at min elevation angle	40,581 km	1,932 km (600 km altitude) 3,131 km (1,200 km altitude)	14018 km
Max Round Trip Delay (propagation delay only)	541.46ms (service and feeder links)	25.77 ms (600km) (service and feeder links) 41.77 ms (1200km) (service and feeder links)	186.9 ms (service and feeder links)
Max differential delay within a cell	10.3 ms	3.12 ms and 3.18 ms for respectively 600km and 1200km	13.4 ms
Max Doppler shift (earth fixed user equipment) (NOTE 6)	0.93 ppm	24 ppm (600km) 21ppm(1200km)	7.5 ppm
Max Doppler shift variation (earth fixed user equipment) (NOTE 6)	0.000 045 ppm/s	0.27 ppm/s (600km) 0.13 ppm/s (1200km)	0.003 ppm/s
C-IoT device motion on the earth	Min 0 km/s (stationary device), max 120 km/h	Min 0 km/s (stationary device), max 120 km/h	Min 0 km/s (stationary device), max 120 km/h
C-IoT device antenna types	Omnidirectional antenna with 0 dBi TX antenna gain and 0 dBi RX antenna gain (NOTE 4)
C-IoT device max Tx power	UE power class 3 with up to 200 mW (23dBm), UE power class 5 with up to 100 mW (20 dBm)
C-IoT device Noise Figure	Omnidirectional antenna: 7 dB or 9 dB (NOTE 5)
Service link	3GPP defined Narrow Band IoT and eMTC
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: This beam size refers to the Nadir pointing of the satellite. NOTE 3: The Maximum beam footprint 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) or a single wide-beam. NOTE 4: The use of a Circular polarized antenna is optional. NOTE 5: Same Noise Figure of 7 dB as in Release 16 TR 38.821 or 9 dB as in Release 12 TR 36.888 for device can be assumed for link budget. The noise figure is device vendor implementation specific. NOTE 6: Max Doppler shift and Max Doppler shift variation in the absence of any device pre-compensation of satellite Doppler shift on the service link. NOTE 7: System bandwidth is FFS

6.2 链路预算分析

6.2.1 链路预算参数

对于一组通用的链路预算参数，同意采用以下假设：

用户设备（UE）功率等级（PC5=20 dBm）
用户设备（UE）噪声系数（NF=9 dB）
根据RAN1#103e中商定的IoT NTN参考场景参数，NB-IoT和eMTC的信道带宽为：
NB-IoT：180 kHz（下行链路），所有允许的更小资源分配（1215 kHz、615 kHz、315 kHz、115 kHz、1*3.75 kHz）最高可达180 kHz（上行链路）
eMTC：1080 kHz（下行链路），所有允许的更小资源分配（包括2180 kHz、180 kHz、215 kHz、315 kHz或615 kHz）最高可达1080 kHz（上行链路）
其他损耗：

表6.2-1：其他损耗

Other Losses	GEO (35786 km)	LEO (1200 km)	LEO (600 km)	MEO (10000 km)
Scintillation losses	2.2	2.2	2.2	2.2 dB
Atmospheric losses	0.2	0.1	0.1	0.04 dB
Polarization loss	3	3	3	3 dB
Shadow margin	3	3	3	3 dB

注1：与功率等级PC5（20 dBm）的上行链路（UL）假设相比，功率等级PC3（23 dBm）有3dB的增益。

注2：与噪声系数NF=9 dB的下行链路（DL）相比，噪声系数NF=7 dB有2dB的改善。

注3：采用其他链路预算参数的链路预算不排除在技术报告（TR）中进行记录。

注4：这些参数仅用于链路预算计算。

注5：大气损耗是仰角的函数。

链路预算分析假设卫星参数集1、集2、集3和集4的下行链路（DL）和上行链路（UL）均有3dB的极化损耗。

对于卫星参数集Set-3和Set-4，链路预算计算中使用的3dB波束宽度（HPBW）、中心波束中心仰角和中心波束边缘仰角在表6.2-2和6.2-3中给出。这些参数分别对应于表6.2-6和6.2-7中给出的卫星参数集3和集4。

表6.2-2：链路预算分析的Set-3参数。

SET 3	GEO 35786 km	LEO-1200 km	LEO-600 km
3 dB Beam width (HPBW)	0.735 degree	22.0631 degree	22.0631 degree
Central beam center elevation	20.88 degree	46.05 degree	43.78 degree
Central beam edge elevation	12.5 degree	30 degree	30 degree
Central beam edge satellite-UE distance	40316 km	1998 km	1074 km

表6.2-3：链路预算分析的Set-4参数。

SET 4	LEO-600 km
3 dB Beam width (HPBW)	104.7 degree
Central beam center elevation	90 degree
Central beam edge elevation	30 degree
Central beam edge satellite-UE distance	1076 km

注1：3dB波束宽度（HPBW）已分别包含在TR 38.821表6.1.1.1-1和表6.1.1.1-2中的卫星参数集1和集2中。集1和集2的中心波束中心仰角定义为TR 38.821表6.1.3.2-1中包含的目标仰角。中心波束边缘的卫星-用户设备（UE）距离可以根据中心波束边缘仰角推导出来，因此无需单独列出。

注2：中心波束中心仰角是指波束布局中中心波束的波束中心仰角。

注3：中心波束边缘仰角是指波束布局中中心波束的最小波束边缘仰角。

注4：在采用多波束布局的卫星链路（SLS）评估中，中心波束是为用户设备（UE）提供服务的波束。外围波束的波束中心仰角与中心波束的波束中心仰角不同。在进行干扰建模时，外围波束造成的干扰是通过使用它们各自的波束中心仰角来确定的。

注5：对于多波束卫星小区，最长的波束边缘距离将对应于最外围波束的最小波束边缘仰角，如下图所示。

图6.2-1：物联网非地面网络（IoT NTN）的波束布局和仰角示意图

以下分别列于表6.2-4、6.2-5、6.2-6和6.2-7中的卫星参数集Set-1、Set-2、Set-3和Set-4可用于系统级模拟器校准。

表6.2-4：用于系统级模拟校准的Set 1卫星参数（基于TR 38.821，表6.1.1.1-1）

Satellite orbit		GEO	LEO-1200	LEO-600
Satellite altitude		35786 km	1200 km	600 km
Satellite antenna pattern		Clause 6.4.1 in TR 38.811	Clause 6.4.1 in TR 38.811	Clause 6.4.1 in TR 38.811
Central beam edge elevation		2.3 degrees	26.3 degrees	27.0 degrees
Central beam centre elevation		12.5 degrees	30 degrees	30 degrees
Payload characteristics for DL transmissions
Equivalent satellite antenna aperture (Note 1)	S-band (i.e. 2 GHz)	22 m	2 m	2 m
Satellite EIRP density		59 dBW/MHz	40 dBW/MHz	34 dBW/MHz
Satellite Tx max Gain		51 dBi	30 dBi	30 dBi
3dB beamwidth		0.4011 deg	4.4127 deg	4.4127 deg
Satellite beam diameter (Note 2)		250 km	90 km	50 km
Payload characteristics for UL transmissions
Equivalent satellite antenna aperture (Note1)	S-band (i.e. 2 GHz)	22 m	2 m	2 m
G/T		19 dB K-1	1.1 dB K-1	1.1 dB K-1
Satellite Rx max Gain		51 dBi	30 dBi	30 dBi
NOTE 1: This value is equivalent to the antenna diameter in Sec. 6.4.1 of [9]. 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 [10] dB. NOTE 6: The parameters corresponding to Ka-band for DL and UL in TR 38.821 Table 6.1.1.1-1 were removed.

表6.2-5：用于系统级仿真校准的第2组卫星参数（基于TR 38.821，表6.1.1.1-2）

Satellite orbit		GEO	LEO-1200	LEO-600
Satellite altitude		35786 km	1200 km	600 km
Satellite antenna pattern		Clause 6.4.1 in TR 38.811	Clause 6.4.1 in TR 38.811	Clause 6.4.1 in TR 38.811
Central beam edge elevation		11.0 degrees	22.2 degrees	23.8 degrees
Central beam center elevation		20 degrees	30 degrees	30 degrees
Payload characteristics for DL transmissions
Equivalent satellite antenna aperture (Note 1)	S-band (i.e. 2 GHz)	12 m	1 m	1 m
Satellite EIRP density		53.5 dBW/MHz	34 dBW/MHz	28 dBW/MHz
Satellite Tx max Gain		45.5 dBi	24 dBi	24 dBi
3dB beamwidth		0.7353 degrees	8.8320 degrees	8.8320 degrees
Satellite beam diameter (Note 2)		450 km	190 km	90 km
Payload characteristics for UL transmissions
Equivalent satellite antenna aperture (Note1)	S-band (i.e. 2 GHz)	12 m	1 m	1 m
G/T		14 dB K-1	-4.9 dB K-1	-4.9 dB K-1
Satellite Rx max Gain		45.5 dBi	24 dBi	24 dBi
NOTE 1: This value is equivalent to the antenna diameter in Sec. 6.4.1 of [9]. 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 parameters corresponding to Ka-band for DL and UL in TR 38.821 Table 6.1.1.1-1 were removed.

表6.2-6：用于系统级模拟器校准的第3组卫星参数（基于R1-2101146 - Eutelsat）

Satellite orbit		GEO	LEO-1200	LEO-600
Satellite altitude		35786 km	1200 km	600 km
Central beam edge elevation		12.5 degree	30 degree	30 degree
Central beam center elevation		20.9 degree	46.05 degree	43.78 degree
Payload characteristics for DL transmissions
Equivalent satellite antenna aperture (NOTE 1)	S-band (i.e. 2 GHz)	12 m	0.4m	0.4 m
Satellite EIRP density		59.8 dBW/MHz	33.7 dBW/MHz	28.3 dBW/MHz
Satellite Tx max Gain		45.7 dBi	16.2 dBi	16.2 dBi
3dB beam width (HPBW)		0.7353 degree	22.1 degree	22.1 degree
Satellite beam diameter (NOTE 2)		459km	470 km	234 km
Payload characteristics for UL transmissions
Equivalent satellite antenna aperture (NOTE 1)	S-band (i.e. 2 GHz)	12 m	0.4 m	0.4 m
G/T		16.7dB K-1	-12.8 dB K-1	-12.8 dB K-1
Satellite Rx max Gain		45.7 dBi	16.2 dBi	16.2 dBi
NOTE 1: This value is equivalent to the antenna diameter in Sec. 6.4.1 of TR 38.811 NOTE 2: Satellite beam diameter is at Nadir point NOTE 3: Central beam center elevation is referred to as central beam elevation in TR 38.821 NOTE 4: Central beam edge elevation is the minimum beam edge elevation of the central beam in the beam layout.

表6.2-7：用于系统级模拟器校准的第4组卫星参数（基于R1-2101019 - Thales、Sateliot、Gatehouse）

Satellite orbit		LEO-600
Satellite altitude		600 km
Central beam edge elevation		30 degree
Central beam center elevation		90 degree
Payload characteristics for DL transmissions
Equivalent satellite antenna aperture (NOTE 1)	S-band (i.e. 2 GHz)	0.097 m
Satellite EIRP density		21.45 dBW/MHz
Satellite Tx max Gain		11 dBi
3dB beam width (HPBW)		104.7 degree
Satellite beam diameter (Note 2)		1700 km
Payload characteristics for UL transmissions
Equivalent satellite antenna aperture (NOTE 1)	S-band (i.e. 2 GHz)	0.097 m
G/T		- 18.6 dB·K-1
Satellite Rx max Gain		11 dBi
NOTE 1: This value is equivalent to the antenna diameter in Sec. 6.4.1 of TR 38.811 NOTE 2: Satellite beam diameter is at Nadir point NOTE 3: Central beam center elevation is referred to as central beam elevation in TR 38.821 NOTE 4: Central beam edge elevation is the minimum beam edge elevation of the central beam in the beam layout.

表6.2-8：用于链路预算和系统级评估的卫星参数集（基于R1-2102750 – HUGUES / Echostar）

	Proposed MEO Scenarios (Set 5)
Satellite orbit	MEO
Satellite altitude	10,000 km
Payload characteristics for DL transmission
Frequency band	S-band (i.e. 2 GHz)
Equivalent satellite antenna aperture (NOTE1)	1.5 m
Satellite EIRP density	45.4 dBW/MHz
Satellite Tx max Gain	28.1 dBi
3dB beamwidth	6.5 degrees
Satellite beam diameter (at nadir pointing)	1140 km
Payload characteristics for UL reception
Frequency band	S-band (i.e. 2 GHz)
Equivalent satellite antenna aperture (NOTE1)	1.5 m
G/T	3.8 dB/K
Satellite Rx max Gain	28.1 dBi
NOTE 1: This value is equivalent to the antenna diameter for the parabolic reflector modelled in Sec. 6.4.1 of TR 38.811. Other antenna models can be considered.

表6.2-9：用于链路预算分析的第五组卫星参数（基于R1-2102750 – HUGUES / Echostar）

Set 5	MEO
3 dB Beam width (HPBW)	6.5 degrees
Central beam center elevation	90 degrees
Central beam edge elevation	81.6 degrees
Central beam edge satellite-UE distance	10042 km

对于中地球轨道（MEO）而言，多普勒频移/变化以及延迟变化均小于低地球轨道（LEO）。中地球轨道的最大延迟小于地球同步轨道（GEO）。针对低地球轨道和地球同步轨道的物联网非地面网络（IoT-NTN）增强功能应足以支持中地球轨道。

注：中地球轨道的参数集仅供信息/参考之用，评估和增强功能主要考虑地球同步轨道和低地球轨道。这些增强功能同样适用于中地球轨道。

6.2.2 链路预算结果总结

在RAN1#104bis-e会议中达成一致，将贡献公司在[26]中提供的链路预算结果总结纳入TR 36.763的技术提案中，并根据需要进行进一步的检查和修订[11]。链路预算结果的总结将与贡献公司保持一致。贡献公司提供的详细链路预算结果已记录在单独的电子表格中[27]。

6.2.2.1 链路预算结果校准

贡献公司：

Huawei	OPPO	Vivo	CATT	MediaTek	Nokia	CMCC	ZTE
Xiaomi	Ericsson	Qualcomm	Apple	Samsung	SONY	Sateliot

观察到OPPO、CATT、华为、Vivo、诺基亚、中国移动、中兴、小米、爱立信、苹果和Sateliot（配置A）在他们的模拟中使用了TR 36.763中约定的链路预算假设，即功率等级PC5（20 dBm）和噪声系数NF=9 dB。而联发科、三星和索尼在模拟中使用了功率等级PC3（23 dBm）和噪声系数NF=7 dB的链路预算假设。

两组结果之间存在3dB的差异，这是由于上行链路（UL）中PC3（23 dBm）和PC5（20 dBm）的不同假设造成的；同时，由于噪声系数（7 dB和9 dB）的不同假设，还存在2dB的差异。为了使假设统一以得出一致的结果，在主持人总结中，我们对所有公司的数据进行了调整，采用了共同的噪声系数和功率等级假设。在必要时，下行链路信噪比（SNR DL）数据调整了2dB，上行链路信噪比（SNR UL）数据调整了3dB。与功率等级PC5（20 dBm）的上行链路假设相比，功率等级PC3（23 dBm）有3dB的增益。与噪声系数NF=9 dB相比，噪声系数NF=7 dB有2dB的增益。我们使用TR 36.763中约定的第一组、第二组、第三组和第四组的中心波束边缘仰角来确定自由空间路径损耗（FSPL）。经过这些调整后，我们发现各贡献公司的结果之间具有合理的一致性。

所有贡献公司都使用了如表所示的约定损耗。

表6.2.2.1-1：卫星损耗

Other Losses	GEO (35786 km)	LEO (1200 km)	LEO (600 km)	MEO (10000 km)
Scintillation losses	2.2 dB	2.2 dB	2.2 dB	2.2 dB
Atmospheric losses	0.2 dB	0.1 dB	0.1 dB	0.04 dB
Polarization loss	3 dB	3 dB	3 dB	3 dB
Shadow margin	3 dB	3 dB	3 dB	3 dB

表6.2.2.1-2：最大自由空间路径损耗

FSPL	GEO (35786 km)	LEO (1200 km)	LEO (600 km)	MEO (10000 km)
Set-1	190.8 dB	165.1 dB	159.7 dB
Set-2	190.6 dB	165.8 dB	160.4 dB
Set-3	190.6 dB	164.5 dB	159.1 dB
Set-4	-	-	159.1 dB
Set-5				178.5 dB

表6.2.2.1-3：链路预算分析案例

Case	Satellite orbit	Satellite parameter set	Central beam center elevation (deg)	Central beam edge elevation (deg)	Frequency Reuse Factor
1	GEO	Set 1	12.5	2.3	1
2	LEO-1200	Set 1	30	26.27	1
3	LEO-600	Set 1	30	26.98	1
4	GEO	Set 2	20	10.95	1
5	LEO-1200	Set 2	30	22.16	1
6	LEO-600	Set 2	30	23.80	1
7	GEO	Set 3	20.88	12.5	1
8	LEO-1200	Set 3	46.05	30	1
9	LEO-600	Set 3	43.78	30	1
10	LEO-600	Set 4	90	30	1
11	MEO-10000	Set 5	90	81.6	1

我们已根据校准电子表格中的条款，捕获并总结了各个公司的校准结果。下面的表格基于电子表格中的校准结果。为了使各贡献公司保持一致，电子表格提供了以下指导：

在链路预算分析中使用上行链路（UL）的功率等级PC3（23 dBm）和下行链路（DL）的噪声系数NF=7 dB。
在电子表格中报告了中心波束边缘的下行链路信噪比（SNR）和上行链路SNR。
当考虑功率等级PC5为20dB时，与PC3相比，将实现较低的载噪比（CNR），并且覆盖范围将受到功率降低的影响。
对于功率等级PC5（20 dBm）和噪声系数NF=9 dB，为了对齐上行链路和下行链路的CNR值，分别增加3dB和2dB。
上行链路CNR包括由于波束边缘的半功率波束宽度（HPBW）定义的波束宽度而产生的额外3dB损耗。
下行链路SNR可能包括由于波束边缘的半功率波束宽度（HPBW）定义的波束宽度而产生的额外3dB损耗；对于SET-1、SET-2、SET-3，在计算电子表格时假设下行链路等效全向辐射功率（EIRP）为波束边缘的EIRP，因此使用0dB额外损耗；对于SET-4，在计算电子表格时假设下行链路EIRP为天底点的EIRP，因此使用3dB额外损耗。

6.2.2.1.1 Set-1

PC3 (23 dBm), NF=7 dB
Cases	EIRP Density	EIRP per spot	DL C/N	G/T	UL C/N 1080 kHz / 360 kHz /180 kHz / 90 kHz / 45 kHz / 30 kHz / 15 kHz / 3.75 kHz
1	59 dBW/MHz	81.6 dBm	-3.3 dB	19 dB/K	-22.0 dB / -17.3 dB / -14.2 dB / -11.2 dB / -8.2 dB / -6.5 dB / -3.5 dB / 2.6 dB
2	40 dBW/MHz	62.6 dBm	3.6 dB	1.1 dB/K	-14.0 dB / -9.3 dB / -6.3 dB / -3.3 dB / -0.3 dB / 1.5 dB / 4.5 dB / 10.5 dB
3	34 dBW/MHz	56.6 dBm	3.0 dB	1.1 dB/K	-8.6 dB / -3.9 dB / -0.9 dB / 2.2 dB / 5.2 dB / 6.9 dB / 9.9 dB / 16.0 dB

PC5 (20 dBm), NF=9 dB
Cases	EIRP Density	EIRP per spot	DL C/N	G/T	UL C/N 1080 kHz / 360 kHz /180 kHz / 90 kHz / 45 kHz / 30 kHz / 15 kHz / 3.75 kHz
1	59 dBW/MHz	81.6 dBm	-5.3 dB	19 dB/K	-25.0 dB / -20.3 dB / -17.2 dB / -14.2 dB / -11.2 dB / -9.5 dB / -6.5 dB / -0.4 dB
2	40 dBW/MHz	62.6 dBm	1.6 dB	1.1 dB/K	-17.0 dB / -12.3 dB / -9.3 dB / -6.3 dB / -3.3 dB / -1.4 dB / 1.5 dB / 7.5 dB
3	34 dBW/MHz	56.6 dBm	1.0 dB	1.1 dB/K	-11.6 dB / -6.9 dB / -3.9 dB / -0.8 dB / 2.2 dB / 3.9 dB / 6.9 dB / 13.0 dB

6.2.2.1.2 Set-2

PC3 (23 dBm), NF=7 dB
Cases	EIRP Density	EIRP per spot	DL C/N	G/T	UL C/N 1080 kHz / 360 kHz / 180 kHz / 90 kHz / 45 kHz / 30 kHz / 15 kHz / 3.75 kHz
4	53.5 dBW/MHz	76.1 dBm	-8.5 dB	14 dB/K	-26.7 dB / -22.0 dB / -19.0 dB / -16.0 dB / -13.0 dB / -11.2 dB / -8.2 dB / -2.2 dB
5	34 dBW/MHz	56.6 dBm	-3.2 dB	-4.9 dB/K	-20.8 dB / -16.0 dB / -13.0 dB / -10.0 dB / -7.0 dB / -5.2 dB / -2.2 dB / 3.8 dB
6	28 dBW/MHz	50.6 dBm	-3.7 dB	-4.9 dB/K	-15.4 dB / -10.6 dB / -7.6 dB / -4.6 dB / -1.5 dB / 0.2 dB / 3.2 dB / 9.3 dB

PC5 (20 dBm), NF=9 dB
Cases	EIRP Density	EIRP per spot	DL C/N	G/T	UL C/N 1080 kHz / 360 kHz /180 kHz / 90 kHz / 45 kHz / 30 kHz / 15 kHz / 3.75 kHz
4	53.5 dBW/MHz	76.1 dBm	-10.5 dB	14 dB/K	-29.7 dB / -25.0 dB / -22.0 dB / -19.0 dB / -16.0 dB / -14.2 dB / -11.2 dB / -5.2 dB
5	34 dBW/MHz	56.6 dBm	-5.2 dB	-4.9 dB/K	-23.8 dB / -19.0 dB / -16.0 dB / -13.0 dB / -10.0 dB / -8.2 dB / -5.2 dB / 0.8 dB
6	28 dBW/MHz	50.6 dBm	-5.7 dB	-4.9 dB/K	-18.4 dB / -13.6 dB / -10.6 dB / -7.6 dB / -4.5 dB / -2.8 dB / 0.2 dB / 6.3 dB

6.2.2.1.3 Set-3

PC3 (23 dBm), NF=7 dB
Cases	EIRP Density	EIRP per spot	DL C/N	G/T	UL C/N 1080 kHz / 360 kHz / 180 kHz / 90 kHz / 45 kHz /30 kHz / 15 kHz / 3.75 kHz
7	59.8 dBW/MHz	84.4 dBm	-2.2 dB	16.7 dB/K	-24.0 dB / -19.3 dB / -16.3 dB / -13.3 dB / -10.3 dB / -8.5 dB / -5.5 dB / 0.6 dB
8	33.7 dBW/MHz	56.3 dBm	-2.1 dB	-12.8 dB/K	-27.3 dB / -22.5 dB / -19.5 dB / -16.5 dB / -13.5 dB / -11.7 dB / -8.7 dB / -2.7 dB
9	28.3 dBW/MHz	50.9 dBm	-2.1 dB	-12.8 dB/K	-21.9 dB / -17.2 dB / -14.1 dB / -11.1 dB / -8.1 dB / -6.4 dB / -3.3 dB / 2.7 dB

PC5 (20 dBm), NF=9 dB
Cases	EIRP Density	EIRP per spot	DL C/N	G/T	UL C/N 1080 kHz / 360 kHz /180 kHz / 90 kHz / 45 kHz / 30 kHz / / 15 kHz / 3.75 kHz
7	59.8 dBW/MHz	84.4 dBm	-4.2 dB	16.7 dB/K	-27.0 dB / -22.3 dB / -19.3 dB / -16.3 dB / -13.3 dB / -11.5 dB / -8.5 dB / -2.4 dB
8	33.7 dBW/MHz	56.3 dBm	-4.1 dB	-12.8 dB/K	-30.3 dB / -25.5 dB / -22.5 dB / -19.5 dB / -16.5 dB / -14.7 dB / -11.7 dB / -5.7 dB
9	28.3 dBW/MHz	50.9 dBm	-4.1 dB	-12.8 dB/K	-24.9 dB / -20.2 dB / -17.1 dB / -14.1 dB / -11.1 dB / -9.4 dB / -6.3 dB / -0.3 dB

6.2.2.1.4 Set-4

PC3 (23 dBm), NF=7 dB

Cases

EIRP Density

EIRP per spot

DL C/N

G/T

UL C/N

1080 kHz / 360 kHz / 180 kHz / 90 kHz / 45 kHz / 30 kHz / 15 kHz / 3.75 kHz

21.4 dBW/MHz

44 dBm

-12.0 dB

-20.9 dB/K

-27.0 dB / -23.0 dB / -20.0 dB / -16.9 dB / -13.9 dB / -12.2 dB / -9.2 dB / -3.1 dB

PC5 (25 dBm), NF=9 dB

Cases

EIRP Density

EIRP per spot

DL C/N

G/T

UL C/N

1080 kHz / 360 kHz /180 kHz / 90 kHz / 45 kHz / 30 kHz / 15 kHz / 3.75 kHz

21.4 dBW/MHz

44 dBm

-12.0 dB

-20.9 dB/K

-30.0 dB / -26.0 dB / -23.0 dB / -19.9 dB / -16.9 dB / -15.2 dB / -12.2 dB / -6.1 dB

6.2.2.1.5 Set-5

Cases

EIRP Density

EIRP per spot

DL C/N

G/T

UL C/N

1080 kHz / 360 kHz / 180 kHz / 90 kHz / 45 kHz / 30 kHz / 15 kHz / 3.75 kHz

45.4 dBW/MHz

68 dBm

-4.5 dB

3.8 dB/K

-25.0 dB / -19.8 dB / -16.8 dB / -13.8 dB / -10.8 dB / -9.0 dB / -6.0 dB / -0.0 dB

6.3 时间和频率同步增强

研究了与时间和频率同步增强相关的以下几个方面：

初始接入时的GNSS测量窗口。
使用Rel-13 TR 45.820（第5.4条）中的电池寿命方法学，研究GNSS位置固定对UE功耗的潜在影响。
在研究GNSS位置固定对UE功耗的潜在影响时，至少应考虑以下参数：
- GNSS功耗值
- GNSS位置首次定位时间
- NTN系统信息块（SIB）携带卫星星历对以下方面的潜在影响：
  - NB-IoT和eMTC中UE的功耗
  - 卫星位置跟踪的准确性
  - PRACH拥塞
  - 在NB-IoT和eMTC中，UE在(N-)PUSCH上进行长上行链路传输时对卫星延迟和卫星多普勒频移的预补偿。
  - 在NB-IoT和eMTC中，UE在PRACH上进行长上行链路传输时对卫星延迟和卫星多普勒频移的预补偿。

6.3.1 GNSS位置固定对UE功耗的影响

在RAN1#104bis-e会议上达成一致，将基于[12]附录A第5.1条的GNSS位置固定对UE功耗影响的总结纳入TR 36.763的技术提案中，并根据需要进行进一步的检查和修订。附录A中各公司的电池寿命分析已纳入TR 36.763的附件C中。

6.3.1.1 UE功耗分析假设

TR 45.820第7.2.4.5.2条为能耗模型提供了功耗假设。

表5.4-1：能耗分析的关键输入参数

(1) Battery capacity (Wh)	(2) Battery power during Tx (mW)	(3) Battery power for Rx (mW)	(4) Battery power when Idle but not in PSS (mW)	(5) Battery power in Power Save State (PSS) (mW)	(6) Time between end of IP packet carrying "report" and start of IP packet carrying "ack" on radio (ms)	(7) Number of reports per day
5				[0,015]	1000
For each report (refer to Figure 5.4-1):
(8) Rx time from PSS exit to re-entry into PSS (ms)	(9) Idle time from PSS exit to re-entry into PSS (ms)	(10) Tx time from PSS exit to re-entry into PSS (ms)	(11) Time from last Rx or Tx activity to entry into PSS1 (ms)
			20000

表7.2.4.5-1：功耗假设

Activity	Power consumption (mW)	Comments
TX active	545	Transmitter active at +23 dBm, assuming 44% PA efficiency and 90 mW for other analog and baseband circuitry
RX active	90	Analog RF and digital baseband processing for active receiver
Idle (light sleep)	3	Maintenance of precision oscillator reference for RF synthesizers
Deep Sleep	0.015	Low power crystal, sleep counters and state machine

华为提到了GNSS首次定位时间（TTFF）的冷启动、温启动和热启动条件：

首先是冷启动，此时接收器中没有存储星历信息。用户设备（UE）必须从所有可能的卫星中搜索信号，并且至少需要4颗卫星才能进行定位。因此，持续时间将受到GNSS信号传输速率和接收质量的影响。如果GNSS信号接收过程中没有太多中断，冷启动的持续时间可以从几十秒到十多分钟不等，典型值为30秒。
其次是温启动，该假设基于已经获得了一些星历信息和时钟校正数据。有了这些可用信息，定位时间将缩短到几秒钟。
最后是热启动，该假设基于GNSS接收器具有有效的星历、时钟校正和GNSS时间参考，定位时间可以低至1~2秒。

在电池寿命分析中，各贡献公司在每次上行链路（UL）传输时都进行了GNSS定位修正的假设：

GNSS功耗
集成GNSS和物联网（IoT）模块：
独立的GNSS模块和IoT模块：华为、联发科（100毫瓦）
GNSS定位首次定位时间（TTFF）
热启动：华为（1秒或2秒）
温启动：华为（几秒钟）
冷启动：华为（30秒）

为了比较各贡献公司的电池寿命分析，我们根据报告（2小时和6小时）、数据包大小（50字节）、GNSS定位TTFF（2秒和5秒）以及MCL=154 dB的假设（这决定了接收和发射的活跃时间）对它们的模拟结果进行了逐案对齐。这是为了确保方法的一致性。该方法在能耗模型中包括了设备中的所有传输和接收。

6.3.1.2 独立的GNSS模块和IoT模块

在分析中，对功耗的假设采用了独立的GNSS模块和IoT模块的假设，具体如下：

华为、联发科（100毫瓦）
CATT（216毫瓦）

对于联发科和CATT的模拟结果，我们使用了放大系数2，以提供从1天到12小时的数据，以便与华为的结果对齐。请注意，CATT使用的GNSS模块功耗为216毫瓦；而华为和联发科的数据是基于GNSS模块功耗为100毫瓦的情况下得出的。各公司的结果显示出合理的一致性和观察结果的一致性。在中等的MCL=154 dB条件下，NTN的电池寿命范围在6年到16年之间；电池寿命的减少量在10%到40%之间。

GNSS TTFF (hot start 2s), 2h report
Source	Huawei MCL=154 dB, 105 bytes UL, 320 ms report, GNSS 100 mW	MediaTek MCL=154 dB, 50 bytes UL, 238 ms report, GNSS 100 mW
Total active IoT Rx time	164 ms	371 ms
Total active IoT Tx time	534 ms	335 ms
Battery life (TN)	8.6 years	10.5 years
Battery life (NTN)	6.0 years	6.9 years
Reduction in battery life	30.2 %	34.3 %

GNSS TTFF (warm start 5s), 12h report
Source	Huawei MCL=154 dB, 105 bytes UL, 320 ms report, GNSS 100 mW	MediaTek MCL=154 dB, 50 bytes UL, 238 ms report, GNSS 100 mW	CATT MCL=154 dB, 50 bytes UL, 320 ms report, GNSS 216 mW
Total active IoT Rx time	164 ms	371 ms	641 ms
Total active IoT Tx time	534 ms	335 ms	400 ms
Battery life (TN)	24.3 years	15.6 years	15.6 years
Battery life (NTN)	16.2 years	11.9 years	9.3 years
Reduction in battery life	33.3%	23.7 %	40.4%

6.3.1.3 集成GNSS模块和物联网模块

在分析中，对功耗的假设采用了独立的GNSS模块和物联网模块的假设，具体如下：

爱立信、联发科、诺基亚（37毫瓦）

爱立信观察到，对于eMTC/NB-IoT，电池寿命的减少量取决于上行链路（UL）报告间隔、数据包大小和无线资源控制（RRC）过程，在最大耦合损耗（MCL）为164 dB时，电池寿命的减少量可达约6%，在MCL为144 dB时，减少量可达约17%。联发科贡献的附件A中也有类似的观察结果，即在相似的假设条件下，电池寿命在MCL为164 dB时减少量约为2.6%，在MCL为144 dB时减少量约为11.7%。

GNSS TTFF (hot start 1s), 2h report
Source	MediaTek MCL=154 dB, 50 bytes UL, 238 ms report, GNSS 37 mW	Ericsson MCL=154 dB, 50 bytes UL EDT, 238 ms report, GNSS 37 mW
Total active IoT Rx time	371 ms	-
Total active IoT Tx time	335 ms	-
Battery life (TN, years)	10.5 years	14.6 years
Battery life (NTN, years)	9.5 years	12.9 years
Reduction in battery life	9.5 %	11.6 %

GNSS TTFF (warm start 5s), 24h report
Source	MediaTek MCL=154 dB, 50 bytes UL, 238 ms report, GNSS 37 mW	Ericsson MCL=154 dB, 50 bytes UL EDT, 238 ms report, GNSS 37 mW
Total active IoT Rx time	371 ms	-
Total active IoT Tx time	335 ms	-
Battery life (TN, years)	31.2 years	33.8 years
Battery life (NTN, years)	27.9 years	30.0 years
Reduction in battery life	10.2 %	11.2 %

诺基亚观察到，对于50字节数据包的情况，如果假设GNSS冷启动时间为1秒，则电池寿命减少约2.33%；如果假设GNSS热启动时间为5秒，则电池寿命减少约10.66%。而对于200字节数据包的情况，在冷启动和热启动情况下，电池寿命减少幅度分别为1.1%和5.29%。当GNSS启动时间超过5秒时，电池寿命减少更多。

GNSS TTFF (hot start 1s), 2h report
Source	Nokia	MediaTek
Source	MCL=164 dB, 50 bytes UL, GNSS 37 mW	MCL=164 dB, 50 bytes UL, GNSS 37 mW (integrated)
Total active IoT Rx time	2171 ms	2290 ms
Total active IoT Tx time	2193 ms	2110 ms
Battery life (TN)	2.65 years	2.68 years
Battery life (NTN)	2.59 years	2.61 years
Reduction in battery life	2.33%	2.61%

GNSS TTFF (warm start 5s), 2h report
Source	Nokia	CATT
Source	MCL=164 dB, 50 bytes UL, GNSS 37 mW	MCL=164 dB, 50 bytes UL, GNSS 20 mW
Total active IoT Rx time	2171 ms	3035 ms
Total active IoT Tx time	2193 ms	2560 ms
Battery life (TN)	2.65 years	2.3 years
Battery life (NTN)	2.37 years	2.2 years
Reduction in battery life	10.66%	4.35%

GNSS TTFF (warm start 5s), 24h report
Source	Nokia	MediaTek	CATT
Source	MCL=164 dB, 50 bytes UL, GNSS 37 mW	MCL=164 dB, 50 bytes UL, GNSS 37 mW (integrated)	MCL=164 dB, 50 bytes UL, GNSS 20 mW
Total active IoT Rx time	2171 ms	2290 ms	3035 ms
Total active IoT Tx time	2193 ms	2110 ms	2560 ms
Battery life (TN)	18.01 years	18.12 years	16.6 years
Battery life (NTN)	16.87 years	16.95 years	16.0 years
Reduction in battery life	6.33%	6.46%	3.61%

6.3.1.4 功耗——短暂偶发连接

高通公司考虑了物联网用户设备（IoT UE）每隔8小时、24小时等传输一次负载的情况；在传输负载后，UE的连接被释放，并返回到深度睡眠模式，直到下一次传输之前。全球导航卫星系统（GNSS）首次定位时间（TTFF）假设为2秒。一个典型的非地面网络（NTN）上的窄带物联网（NB-IoT）场景（例如，针对第二组设置的良好覆盖低地球轨道卫星）对应于下行链路信噪比（SNR）（对于15 kHz的1个物理资源块（PRB）接收）为0 dB，上行链路SNR（对于15 kHz的1个PRB传输）为-5 dB（用户设备以最大功率20 dBm发射）。

图3：非地面网络（NTN）上物联网（IoT）的短暂偶发传输。

在所研究的短暂偶发连接场景下，每次连接前的全球导航卫星系统（GNSS）定位大约消耗了用户设备（UE）总可用能量的34%。

对于在短暂偶发连接范式下运行的移动UE（如跟踪设备等），在基于GNSS的上行链路预补偿的Release 17假设范围内，由于GNSS导致的功耗惩罚无法显著减轻。然而，对于固定UE（如智能电表等），这些UE可以通过更加宽松的GNSS定位计划（例如，根据设置每周或每月定位一次）来节省功耗。

6.3.1.5 功耗——长连接（例如，基于连续不连续接收，CDRX）

高通公司考虑了长连接的情况。物联网UE在连接模式下可能会持续更长时间，而不是上述的短暂偶发连接。这可以通过连续不连续接收（CDRX）来实现，在较长的连接期间，UE可以发送或接收更大的有效载荷。

图4：非地面网络（NTN）上物联网（IoT）的连接模式不连续接收（DRX）长连接。

在每次上行链路传输时机之前进行全球导航卫星系统（GNSS）定位（在没有其他机制的情况下，这可能是维持上行链路同步精度在指定范围内的必要措施）会导致GNSS定位约占用户设备（UE）总功耗的45%。虽然我们可以为固定UE在一定程度上缓解这一问题，但对于移动UE（尤其是高速移动的UE），如果没有其他针对连接模式同步的增强措施，我们可能无法避免GNSS定位对UE功耗的影响。

在所研究的长连接场景中，采用连接模式DRX（DRX周期为~10秒），在没有针对上行链路同步的额外增强措施的情况下，每次上行链路传输前的GNSS定位大约消耗了UE总可用能量的45%。这对于无法依赖先前获取的GNSS定位的移动UE尤其如此。

6.3.1.6 其他功耗评估观察

联发科观察到，当电池寿命在1年左右时，电池寿命减少的幅度一般在1%到3%之间；而当电池寿命在10年或更长时间时，电池寿命减少的幅度最大可达30%到68%。对GNSS的冷启动（1秒）和热启动（5秒、30秒）进行了模拟。

爱立信观察到，在最大耦合损耗（MCL）为164 dB时，电池寿命减少幅度可达约6%，而在MCL为144 dB时，减少幅度可达约17%，这取决于上行链路（UL）报告间隔、数据包大小和无线资源控制（RRC）过程。

联发科观察到，在固定物联网传感器场景中，或者在资产跟踪/车队管理中，如果GNSS位置在应用层可用，那么对电池寿命的影响为0%。这是因为用户设备（UE）要么是固定位置的（仅在安装时获取一次GNSS位置），要么UE需要将GNSS位置包含在报告中。

CATT观察到，在每小时传输200字节数据的情况下，电池寿命可超过1年；在每小时传输50字节数据且功率为216 mW的情况下，电池寿命可超过2年；在每天传输50字节或200字节数据且GNSS功耗为20 mW的集成架构中，电池寿命可超过10年。

诺基亚观察到，对于50字节的数据包，如果假设GNSS冷启动为1秒，则电池寿命减少约2.33%，如果假设GNSS热启动为5秒，则减少约10.66%。对于200字节的数据包，在冷启动和热启动情况下，减少幅度分别为1.1%和5.29%。GNSS启动时间超过5秒时，电池寿命减少更多。

爱立信建议RAN1讨论并同意物联网非地面网络（IoT NTN）电池寿命评估的假设条件，如MCL、发射功率、带宽和噪声系数。

中国移动通信集团公司（CMCC）和APT提议，将研究GNSS位置固定对UE功耗的潜在影响作为次要任务。

基于贡献公司的观察结果如下：

使用相似的报告间隔、数据包大小、GNSS首次定位时间（TTFF）和功耗及MCL假设时，贡献公司得出了一致的观察结果。
对于固定物联网传感器场景或GNSS位置在应用层可用的资产跟踪/车队管理场景，对电池寿命的影响为0%。
在物联网设备非固定位置且GNSS位置在应用层不可用的情况下，基于贡献公司的观察结果如下：在MCL为164 dB时，电池寿命减少约6%；在MCL为144 dB时，减少约17%，这取决于UL报告间隔、数据包大小和RRC过程，以及GNSS TTFF冷启动为1秒、热启动为5秒，且GNSS功耗为37 mW（集成物联网和GNSS模块）。
当电池寿命约为1年时，电池寿命减少约1%到3%；当电池寿命约为10年或更长时，减少约30%到68%，这取决于GNSS TTFF冷启动为1秒、热启动为5秒，且GNSS功耗为37 mW（集成物联网和GNSS模块）或100 mW（单独的物联网和GNSS模块）。
对于50字节的数据包，如果假设GNSS冷启动为1秒，则电池寿命减少约2.33%；如果假设GNSS热启动为5秒，则减少约10.66%。对于200字节的数据包，在冷启动和热启动情况下，减少幅度分别为1.1%和5.29%。GNSS启动时间超过5秒时，电池寿命减少更多。
对于短暂的偶发连接，每次连接前进行GNSS定位会消耗UE总可用能量的34%；在采用连接模式不连续接收（DRX，DRX周期为~10秒）的长连接中，每次上行链路传输前进行GNSS定位会消耗UE总可用能量的约45%。
在216 mW功耗下，每小时传输200字节数据可支持超过1年的电池寿命；在每小时传输50字节数据的情况下可支持超过2年的电池寿命；在20 mW GNSS功耗的集成架构中，每天传输50字节或200字节数据可支持超过10年的电池寿命。

使用Rel-13 TR 45.820（第5.4条）进行的电池寿命评估表明，总体而言，GNSS的影响可能是中等至显著的，但在显著减少的情况下，仍允许电池寿命达到数年。结果表明，缓解GNSS导致的功耗可能是一个值得研究的领域，如果NTN物联网的目标是与蜂窝物联网相当的10年或更长的高电池寿命，那么这一领域的研究将非常有益。基于贡献公司的评估表明，在最坏情况下，即假设每次上行链路传输前都需要进行GNSS定位时，NTN物联网的电池寿命足以支持一个可行的解决方案。在典型的物联网应用中，对于固定物联网传感器或在应用层可用GNSS位置的场景，对电池寿命的影响为0%。

6.3.2 NTN系统信息块（SIB）读取对UE功耗的影响

对于短暂的偶发连接用例，读取包含卫星星历信息的SIB所需的功耗并不显著。

注意：对于此结论，假设UE在连接模式下不需要读取广播SIB以获取卫星星历信息。

6.3.3 长PUSCH和PRACH传输

对于长PUSCH，每N个时间单位进行一次UE预补偿是基线解决方案。

预补偿在N个时间单位的一个块内保持不变。
关于N的定义和值的进一步研究待定（FFS）。

对于长PRACH，每N个时间单位进行一次UE预补偿也是基线解决方案。

预补偿在N个时间单位的一个块内保持不变。
关于N的定义和值的进一步研究待定（FFS）。

对于具有重复次数R>1的上行链路传输，需要进行规范更改。

对于分段UE预补偿，可以进一步讨论以下问题：

应用新预补偿时子帧边界处的相位不连续性。
由于分段期间的延迟/频率漂移率导致的相干时间限制。
不同定时提前（TA）分段之间的信号重叠。

关于长传输期间是否需要更频繁的新上行链路间隙、是否可以通过实现来调整采样频率以避免新上行链路间隙以及N的值和时间单位是什么，可以进一步在规范阶段进行研究。

建议网络配置上行链路同步有效性定时器（例如，用于卫星星历和可能的其他方面）。

关于何时设置/重置定时器、定时器持续时间和定时器到期时UE的行为等详细信息，可以在规范阶段进行讨论。

6.3.4 下行链路同步

对于Rel-17时间框架内的下行链路同步，应考虑以下内容：

新的信道光栅，步长增加到大于100 kHz。
MIB中的部分ARFCN指示。

6.3.5 GNSS测量

对于短暂的偶发传输：

空闲UE从空闲DRX/PSM唤醒，接入网络，进行短暂的上行链路和/或下行链路通信，然后返回空闲状态。
在接入网络之前，UE获取GNSS位置固定，并在传输数据包时无需重新获取GNSS位置固定。

关于短暂传输的持续时间、GNSS位置的获取和GNSS位置的有效期等详细信息，可以在规范阶段进行讨论。

假设GNSS位置固定在一段时间X内有效，对于处于RRC_CONNECTED状态的UE，以下情况适用：

由于UE速度引起的TA误差满足RAN4中定义的要求。
由于UE速度引起的多普勒频移误差满足RAN4中定义的要求。

关于GNSS位置固定的有效性和在RRC_CONNECTED模式下获取GNSS位置固定的详细信息、X的值等，可以进一步在规范阶段进行讨论。

关于对现有闭环TA维护机制的潜在影响，可以进一步在规范阶段进行讨论。

注意：在规范工作阶段，RAN4将定义详细要求。

6.3.6 PRACH拥塞

结论是，在Release-17时间框架内，不再进一步研究潜在的RACH拥塞问题。

6.4 定时关系增强

研究了与定时关系增强相关的以下几个方面，以检查是否需要进行增强以及增强是否有益：

对于NB-IoT：

NPDCCH到NPUSCH格式1
RAR授权到NPUSCH格式1
NPDSCH到NPUSCH格式2上的HARQ-ACK
NPDCCH命令到NPRACH
定时提前命令激活
FFS：其他NB-IoT定时关系

对于eMTC：

MPDCCH到PUSCH
RAR授权到PUSCH
PDCCH命令到PRACH
MPDCCH到计划的上行链路SPS
PDSCH到PUCCH上的HARQ-ACK
CSI参考资源定时
MPDCCH到非周期SRS
定时提前命令激活
FFS：MPDCCH命令到PRACH
FFS：其他eMTC定时关系

研究了往返时延（RTD，影响TA）对HD-FDD上行链路-下行链路定时关系的影响。

关于Koffset的以下方面未进行研究，但可以至少依赖NR NTN工作项[7]中做出的决定：

系统信息中的显式或隐式指示

除了定时提前命令激活外，研究未发现其他需要通过MAC控制元素（CE）激活/去激活的IoT-NTN配置及其定时关系。

研究了由于需要进行GNSS测量以实现时间和频率同步而对IoT-NTN的任何定时关系的影响。

以下NB-IoT定时关系需要增强，以实现IoT NTN的基本最小功能：

NPDCCH到NPUSCH格式1
RAR授权到NPUSCH格式1
NPDSCH到NPUSCH格式2上的HARQ-ACK
定时提前命令激活
FFS：NPDCCH命令到NPRACH
FFS：其他NB-IoT定时关系

基于在NR NTN中采用的通过例如Koffset扩展定时关系的方法，应作为增强NB-IoT在IoT NTN中定时关系的起点。考虑到IoT NTN，可以进一步讨论详细情况。

以下eMTC定时关系需要增强，以实现IoT NTN的基本最小功能：

MPDCCH到PUSCH
RAR授权到PUSCH
MPDCCH到计划的上行链路SPS
PDSCH到PUCCH上的HARQ-ACK
CSI参考资源定时
MPDCCH到非周期SRS
定时提前命令激活
FFS：MPDCCH命令到PRACH
FFS：其他eMTC定时关系

基于在NR NTN中采用的通过例如Koffset扩展定时关系的方法，应作为增强eMTC在IoT NTN中定时关系的起点。考虑到IoT NTN，可以进一步讨论详细情况。

结论是，Rel-16中对eMTC和NB-IoT定时关系的描述通常不考虑TA。

注意：随着eMTC和NB-IoT在NTN上的工作进一步推进，可能会发现此规则的例外情况。

eNB可以使用特定于UE的TA和/或K_offset在其调度中避免FDD-HD中的UL-DL冲突。

NR NTN的RAR窗口偏移值、用于其计算的参数以及这些参数如何配置或发信号通知一起构成了IoT NTN的起点。

讨论了Rel-17 IoT中涉及特定于UE的TA维护和报告的信令方面，以及减少信令负载的技术。讨论了报告特定于UE的TA的机制和其他确定特定于UE的TA的方法。关于这些方面的决策可以在后续规范阶段做出。

从物理层的角度讨论了Rel17 IoT NTN中是否需要特定于UE的K偏移，但未达成共识。这个问题可以在未来的规范阶段进一步讨论。

6.5 HARQ

对于NTN IoT，潜在的HARQ增强需要考虑IoT设备的主要特性，包括低复杂度、低成本、低功耗和低吞吐量，以及IoT服务的关键要求，包括扩展覆盖范围、延迟容忍和不频繁的数据传输，以及对大规模通信的支持。

预计通过NTN运行的IoT UE的峰值吞吐量不会超过通过TN运行的IoT UE的峰值吞吐量。

研究了与HARQ增强相关的以下几个方面：

在GEO卫星场景中是否会发生HARQ停滞
必要性、潜在好处和/或缺点
- 增加HARQ进程对吞吐量、延迟、功耗和复杂性的影响
- 禁用NB-IoT的HARQ反馈
- 禁用eMTC的HARQ反馈
- 其他潜在的HARQ反馈机制
- 减少PDCCH监测
- 覆盖范围增强
- 具有多个HARQ进程的上行链路传输间隙
- 在服务小区更改中保持HARQ进程连续性
- 多个传输块调度
- 吞吐量增强

建议在Rel-17中不支持为NTN中的NB-IoT和eMTC增加HARQ进程数。

讨论了在服务小区更改中保持HARQ进程连续性：

如果NTN IoT中存在大量重复，则UL/DL传输的持续时间可能会超过UE进行小区重选或切换所需的时间间隔。这对于LEO卫星尤其可能是一个问题，因为其移动性高。一些重复可能无法在小区更改发生前传输，这将导致资源浪费。从不同小区组合重复是一个潜在的解决方案。RAN1尚未达成共识以在Rel-17中推荐解决方案。

讨论了吞吐量增强：

讨论了在NB-IoT中，在接收NPDSCH和发送HARQ ACK之间的时间段内启用PDCCH监测以提高吞吐量。RAN1尚未达成共识以在Rel-17中推荐增强吞吐量的解决方案。

讨论了禁用HARQ反馈：

讨论了禁用下行链路传输的HARQ反馈。这有利于UE功耗和延迟。禁用下行链路传输的HARQ反馈可以改善NTN中的上行链路吞吐量，因为上行链路中将有更多资源可用。如果禁用HARQ反馈，则由于缺乏反馈，下行链路传输的第一层可靠性可能会降低。
禁用下行链路传输的HARQ反馈可以缓解由于NTN中RTT较大而导致的NB-IoT的HARQ停滞问题，并有利于UE功耗和延迟。
当不禁用HARQ反馈时，将始终需要上行链路资源用于HARQ ACK反馈。考虑到IoT UE的HD-FDD处理，始终启用的HARQ ACK反馈将影响DL调度和资源分配在时间域中的影响，以及DL吞吐量/数据速率的影响，特别是对于上行链路中耦合损耗较大，需要大量重复的情况。
结论是，从物理层的角度来看，在Rel-17中对于NTN IoT禁用HARQ反馈没有达成共识。

讨论了PDCCH监测：

讨论了在发送PUSCH后一段时间内指示ACK/NACK的PDCCH的监测。不在发送PUSCH后一段时间内监测PDCCH的原因是UE节电。
- 当UE配置有一个HARQ进程时，讨论了UE是否可以在发送PUSCH后停止PDCCH监测，因为直到一个RTT之后才会收到新授权，或者UE不能停止PDCCH监测，因为可以在一个RTT之前收到新授权和/或UE可能需要监视DCI以进行其他调度分配，例如寻呼、系统信息等。
- 当UE配置有两个（或更多）HARQ进程时，是否在发送PUSCH后一段时间内停止监视PDCCH还需要考虑两个HARQ进程的相对时序。
RAN1指出，减少PDCCH监测与DRX密切相关，因此应在RAN1和RAN2中讨论。

对于NTN中的NB-IoT和eMTC，RAN1得出结论，在Rel-17中，增强Rel-16中在发送PUSCH后指示ACK/NACK的PDCCH监测程序不是NTN IoT的必要功能。

附加反馈报告

讨论了UE报告附加信息（例如，告知网络已发送足够数量的重复次数的时间信息、请求的重复次数、基于BLER的触发或反馈捆绑、缓冲区状态、启用/禁用HARQ反馈等）。

结论是，在Rel-17中，报告附加反馈不是NTN IoT的必要功能。

6.6 针对IoT NTN的具体增强建议

6.6.1 IoT NTN场景

在Rel-17时间框架内，优先支持NB-IoT/eMTC的独立部署。

6.6.2 时间和频率同步增强

在Release 17时间框架内对NB-IoT/eMTC时间和频率同步增强的建议：

长PUSCH和PRACH传输增强：
- 对于重复次数R>1的上行链路传输，需要进行规范更改。
- 对于PUSCH和PRACH上的长传输，每N个时间单位进行一次分段UE预补偿，其中预补偿在N个时间单位的一个块内保持不变。
- 对于分段UE预补偿，可以进一步讨论如何处理以下问题：
  - 应用新预补偿时子帧边界处的相位不连续性。
  - 由于分段期间的延迟/频率漂移率导致的相干时间限制。
  - 不同TA分段之间的信号重叠。
- 在规范阶段可以进一步研究：（i）在长传输期间是否需要更频繁的新上行链路间隙；（ii）是否可以通过实现调整采样频率来避免新上行链路间隙；（iii）N的值和时间单位是什么，以及分段UE预补偿的时间单位是什么。
DL同步增强：
- 在规范阶段应考虑以下内容：
  - 步长增加到大于100 kHz的新信道光栅。
  - MIB中的部分ARFCN指示。
GNSS测量：
- 对于短暂的偶发传输：
  - 空闲UE从空闲DRX/PSM唤醒，接入网络，进行短暂的上行链路和/或下行链路通信，然后返回空闲状态。
  - 在接入网络之前，UE获取GNSS位置固定，并且无需为数据包传输重新获取GNSS位置固定。
  - 关于短暂传输的持续时间、GNSS位置的获取和GNSS位置的有效性的详细信息可以在规范阶段进行讨论。
  - 假设GNSS位置固定在一段时间X内有效，对于处于RRC_CONNECTED状态的UE，以下情况适用：
    - 由于UE速度引起的TA误差满足RAN4中定义的要求。
    - 由于UE速度引起的多普勒频移误差满足RAN4中定义的要求。
  - FFS：在RRC_CONNECTED模式下，GNSS位置固定的有效性和获取GNSS位置固定的详细信息、X的值。
  - FFS：对现有闭环TA维护机制的潜在影响。
  - 注意：在规范工作阶段，RAN4将定义详细要求。

6.6.3 定时关系增强

对于IoT NTN的基本最小功能，以下NB-IoT定时关系需要增强：

NPDCCH到NPUSCH格式1
RAR授权到NPUSCH格式1
NPDSCH到NPUSCH格式2上的HARQ-ACK
定时提前命令激活
FFS：NPDCCH命令到NPRACH
FFS：其他NB-IoT定时关系

对于IoT NTN的基本最小功能，以下eMTC定时关系需要增强：

MPDCCH到PUSCH
RAR授权到PUSCH
MPDCCH到计划的上行链路SPS
PDSCH到PUCCH上的HARQ-ACK
CSI参考资源定时
MPDCCH到非周期SRS
定时提前命令激活
FFS：MPDCCH命令到PRACH
FFS：其他eMTC定时关系

基于在NR NTN中采用的扩展定时关系（例如，通过Koffset）的增强应作为IoT NTN中增强eMTC定时关系的起点。考虑到IoT NTN，可以进一步讨论详细情况。

特定于UE的TA和/或K_offset可以由eNB在其调度中使用，以避免FDD-HD中的UL-DL冲突。

结论是，Rel-16中对eMTC和NB-IoT定时关系的描述通常不考虑TA。

注意：随着eMTC和NB-IoT在NTN上的工作进一步推进，可能会发现此规则的例外情况。

讨论了涉及Rel-17 IoT中特定于UE的TA维护和报告的信令方面，以及减少信令负载的技术。讨论了报告特定于UE的TA的机制和其他确定特定于UE的TA的方法。关于这些方面的决策可以在后续规范阶段做出。

从物理层的角度讨论了Rel17 IoT NTN中是否需要特定于UE的K偏移，但未达成共识。这个问题可以在未来的规范阶段进一步讨论。

6.6.4 HARQ增强

建议在Rel-17中不支持为NTN中的NB-IoT和eMTC增加HARQ进程数。

结论是，从物理层的角度来看，在Rel-17中对于NTN IoT禁用HARQ反馈没有达成共识。建议在Rel-17中不支持禁用NTN中NB-IoT和eMTC的HARQ反馈。

讨论了禁用下行链路传输的HARQ反馈。这有利于UE功耗和延迟。禁用下行链路传输的HARQ反馈可以改善NTN中的上行链路吞吐量，因为上行链路中将有更多资源可用。如果禁用HARQ反馈，则由于缺乏反馈，下行链路传输的第一层可靠性可能会降低。因此，可能需要更多的UL资源用于RLC状态报告，这可能会部分消耗由于禁用HARQ反馈而获得的UL资源。
根据一些公司的观点，禁用下行链路传输的HARQ反馈可以缓解由于NTN中RTT较大而导致的NB-IoT的HARQ停滞问题，并有利于UE功耗和延迟。
讨论了缓解当前规范中已支持的由于NTN中RTT较大而导致的潜在吞吐量/延迟损失的方法。eNB可以通过为给定的HARQ进程调度新的DL TB（而不等待接收该HARQ进程的先前TB HARQ ACK/NACK），即使UE为该HARQ进程上调度的TB发送了HARQ ACK，也能确保eMTC的DL吞吐量得到改善。这显著减轻了吞吐量/延迟损失。UE仍然需要始终发送HARQ-ACK（虽然不再用于物理层确认的主要目的，但可能具有次要好处，例如链路自适应方面），因此需要比禁用反馈的情况下更多的UE功耗。
当不禁用HARQ反馈时，将始终需要上行链路资源用于HARQ ACK反馈。考虑到IoT UE的HD-FDD处理，始终启用的HARQ ACK反馈将影响DL调度和资源分配在时间域中的影响，以及DL吞吐量/数据速率的影响，特别是对于上行链路中耦合损耗较大，需要大量重复的情况。
讨论了发送PUSCH后指示ACK/NACK的PDCCH的监测。发送PUSCH后不监测PDCCH的原因是UE节电。
- 当UE配置有一个HARQ进程时，讨论了UE是否可以在发送PUSCH后停止PDCCH监测，因为直到一个RTT之后才会收到新授权，或者UE不能停止PDCCH监测，因为可以在一个RTT之前收到新授权和/或UE可能需要监视DCI以进行其他调度分配，例如寻呼、系统信息等。
- 当UE配置有两个（或更多）HARQ进程时，是否在发送PUSCH后一段时间内停止监视PDCCH还需要考虑两个HARQ进程的相对时序。
指出减少PDCCH监测与DRX密切相关，因此应在RAN1和RAN2中讨论。
对于NTN中的NB-IoT和eMTC，RAN1得出结论，在Rel-17中，增强Rel-16中在发送PUSCH后指示ACK/NACK的PDCCH监测程序不是NTN IoT的必要功能。