【学习笔记】卫星网络（NTN）的窄带物联网（NB-IoT）/增强型机器类型通信（eMTC）研究 -- 3GPP TR 36.763（二）

关于卫星网络（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（二）-LMLPHP

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

6.1 IoT NTN参考参数

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

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

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：其他损耗

注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参数。

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

注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：对于多波束卫星小区，最长的波束边缘距离将对应于最外围波束的最小波束边缘仰角，如下图所示。

【学习笔记】卫星网络（NTN）的窄带物联网（NB-IoT）/增强型机器类型通信（eMTC）研究 -- 3GPP TR 36.763（二）-LMLPHP

图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）

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

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

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

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

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

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

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

6.2.2 链路预算结果总结

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

6.2.2.1 链路预算结果校准

贡献公司：

观察到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：卫星损耗

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

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

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

在链路预算分析中使用上行链路（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.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：能耗分析的关键输入参数

表7.2.4.5-1：功耗假设

【学习笔记】卫星网络（NTN）的窄带物联网（NB-IoT）/增强型机器类型通信（eMTC）研究 -- 3GPP TR 36.763（二）-LMLPHP

华为提到了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%之间。

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%。

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

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发射）。

【学习笔记】卫星网络（NTN）的窄带物联网（NB-IoT）/增强型机器类型通信（eMTC）研究 -- 3GPP TR 36.763（二）-LMLPHP

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

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

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

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

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

【学习笔记】卫星网络（NTN）的窄带物联网（NB-IoT）/增强型机器类型通信（eMTC）研究 -- 3GPP TR 36.763（二）-LMLPHP

图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的必要功能。

瑶光守护者