目录
8. 后续研究方向的建议
8.1 来自RAN1的建议
8.1.1 针对NR NTN和IoT NTN的共同增强建议
8.1.2 Release-17时间框架内RAN1建议的总结
8.2 来自RAN2的建议
关于卫星网络（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）/增强型机器类型通信（eMTC）研究 -- 3GPP TR 36.763（一）-CSDN博客
https://blog.csdn.net/u011376987/article/details/140996255?spm=1001.2014.3001.5501
【学习笔记】卫星网络（NTN）的窄带物联网（NB-IoT）/增强型机器类型通信（eMTC）研究 -- 3GPP TR 36.763（二）-CSDN博客https://blog.csdn.net/u011376987/article/details/141310404?spm=1001.2014.3001.5501
【学习笔记】卫星网络（NTN）的窄带物联网（NB-IoT）/增强型机器类型通信（eMTC）研究 -- 3GPP TR 36.763（三）-CSDN博客https://blog.csdn.net/u011376987/article/details/141333454?spm=1001.2014.3001.5501
【学习笔记】卫星网络（NTN）的窄带物联网（NB-IoT）/增强型机器类型通信（eMTC）研究 -- 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文库
8. 后续研究方向的建议
8.1 来自RAN1的建议
8.1.1 针对NR NTN和IoT NTN的共同增强建议
在Release 17的时间框架内，NB-IoT和eMTC NTN的时间与频率同步增强可以遵循NTN NR协议作为基线，包括以下内容：
- UE预补偿，包括星历格式（轨道/位置-速度）
- 定时提前TTA公式（定时提前的粒度可能不同）
- 基于其GNSS获取的位置和服务卫星星历，在RRC_IDLE、RRC_INACTIVE和RRC_CONNECTED状态下对UE进行上行同步预补偿
- 在RRC_CONNECTED状态下，结合开放（即UE自主TA估计和公共TA估计）和闭合TA（即接收到的TA命令）控制环路
注1：上述内容需由NR-NTN WI决定
注2：NR NTN WI对UE预补偿的增强不包括针对PUSCH和PRACH长传输的IoT NTN特定方面
注3：NR NTN WI对UE预补偿的增强不包括以下内容：- 对GNSS模块使用的限制，其中未假设GNSS和NTN NB-IoT/eMTC同时运行
- 针对偶发性短传输的上行同步和GNSS测量的IoT NTN有效性计时器方面
NR NTN与IoT NTN在成本、复杂性、功耗和IoT特定场景方面有不同要求。
注4：假设NB-IoT/eMTC地面工作在未增强的情况下具有基线功能，除非发现某些问题需要必要的增强。
8.1.2 Release-17时间框架内RAN1建议的总结
RAN1建议在Rel-17中建立一个IoT NTN工作项目，其范围应包括工作组在相应IoT NTN可行性研究中确定的一系列必要功能。这些必要功能如下所列：
IoT NTN场景：
- 优先考虑Rel-17时间框架内NB-IoT/eMTC的独立部署支持
时间与频率同步增强： - IoT NTN可以遵循NTN NR协议作为UE预补偿、定时提前公式以及开放和闭合定时提前控制环路组合的基线，这些均由NR-NTN WI决定。NR NTN WI对UE预补偿的增强不包括以下内容：
- 对GNSS模块使用的限制，其中未假设GNSS和NTN NB-IoT/eMTC同时运行
- 针对偶发性短传输的上行同步和GNSS测量的IoT NTN有效性计时器方面
- 针对PUSCH和PRACH长传输的IoT NTN特定方面
注1：NR NTN与IoT NTN在成本、复杂性、功耗和IoT特定场景方面有不同要求。
注2：假设NB-IoT/eMTC地面工作在未增强的情况下具有基线功能，除非发现某些问题需要必要的增强。
以下列出了IoT NTN特定的时间与频率同步增强：
- 长PUSCH和PRACH传输增强：分段UE预补偿、新的上行间隙和/或实现解决方案、时间单位和分段持续时间等
- 上行同步的有效性计时器：卫星星历，以及可能的其他方面
- 下行同步增强：新信道栅格，（部分）ARFCN-indication-in-MIB
- GNSS测量：在RRC CONNECTED模式下，针对偶发性短传输的GNSS位置固定的有效性和获取GNSS位置固定的细节、有效性持续时间
定时关系增强：
- NB-IoT/eMTC的定时关系：如TR 36.763第6.6.3条所列
- FDD-HD的上行调度：使用UE特定的TA和/或K_offset来避免FDD-HD中的上下行碰撞
- UE特定TA维护和报告的信令方面，可以减少信令负载的技术以及确定UE特定TA的方法可以在规范阶段决定。
注3：在此工作项目中，对于NB-IoT和eMTC设备，均将UE中的GNSS能力作为工作假设。基于此假设，UE可以估计并预补偿定时和频率偏移，以达到上行传输的足够准确性。未假设GNSS和NTN NB-IoT/eMTC同时运行。
HARQ增强：
- 建议不支持在Rel-17中增加NB-IoT和eMTC在NTN中的HARQ进程数量。
- 从物理层角度来看，对于在Rel-17中禁用NTN IoT的HARQ反馈没有达成共识。建议不支持在Rel-17中禁用NB-IoT和eMTC在NTN中的HARQ反馈。
注4：RAN2同意禁用HARQ反馈不是必要的。
注5：关于RAN1对IoT NTN的建议详情，请参见TR 36.763第6.6条。
8.2 来自RAN2的建议
RAN2建议在相应IoT NTN可行性研究中确定以下必要增强。
总的来说，应遵循以下基线建议：
b1. 支持Rel-16中规定的所有蜂窝IoT功能，除非发现问题。
认为以下增强的支持是必要的：
e1. 支持EPC；
e2. 增强ra-ResponseWindowSize和mac-ContentionResolutionTimer；可以使用NR NTN协议作为基线；
e3. 增强HARQ RTT计时器和UL HARQ RTT计时器；可以使用NR NTN协议作为基线；
e4. 增强sr-ProhibitTimer；可以使用NR NTN协议作为基线；
e5. 增强RLC t-Reordering计时器；可以使用NR NTN协议作为基线；
e6. 提供星历；可以使用NR NTN协议作为基线；
e7. 增强使用地球固定TA概念的跟踪区域管理，考虑硬切换和软切换选项，其中在软切换选项中，网络可能针对每个PLMN广播多个跟踪区域代码；
e8. 支持Rel-16中的遗留小区选择/重选机制，无需重大增强。可以考虑对现有移动性机制进行小幅调整，如新参数值、更改定时等，以适应NTN的功能；
e9. 支持不连续覆盖，而不会导致UE功耗过高和故障/恢复操作过多。如果需要，可以考虑增强现有的节能机制，如DRX、PSM、eDRX、宽松监测和（G）WUS，以支持不连续覆盖；
e10. 支持Rel-16中的遗留切换和RLF/重建机制，无需重大增强。对于eMTC，可以考虑使用Rel-16 LTE CHO程序，而无需重大增强。可以考虑对现有移动性机制进行小幅调整，如新参数值、更改定时等，以适应NTN的功能。
以下额外增强的支持不是必要的，但可以考虑，假设变更较小：
a1. 额外支持5GC；
a2. 增强PDCP丢弃计时器；
a3. 进行调整以在NTN部署中启用对现有功能的支持，例如GEO的EDT、PUR。
