目录
8.1.2 Release-17时间框架内RAN1建议的总结
关于卫星网络(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)研究-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。