目录
7.3.2.2 窄带物联网非地面网络（NB-IoT NTN）的连接模式移动性
7.3.2.3 增强型机器类型通信非地面网络（eMTC NTN）的连接模式移动性
关于卫星网络（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增强等。
7 无线协议问题及其解决方案
7.1 要求和关键问题
7.1.1 延迟
下表根据TR 38.821 [3]进行了修改，以确定需要考虑的最恶劣情况物联网非地面网络（IoT NTN）场景。
表7.1-1：非地面网络（NTN）场景与延迟约束，来源[3]
| NTN scenarios | GEO transparent payload | LEO transparent payload |
| Satellite altitude | 35786 km | 600 km |
| Relative speed of Satellite with respect to earth | negligible | 7.56 km per second |
| Min elevation for both feeder and service links | 10° for service link and 10° for feeder link | |
| Typical Min / Max NTN beam footprint diameter (Note 2) | 100 km / 3500 km | 50 km / 1000 km |
| Maximum propagation delay contribution to the Round Trip Delay on the radio interface between the gNB and the UE | 541.46ms (Worst case) | 25.77ms |
| Minimum propagation delay contribution to the Round Trip Delay on the radio interface between the gNB and the UE | 477.48ms | 8ms |
| Maximum Delay variation seen by the UE (Note 3) | Negligible | Up to +/- 40 µs/sec (Worst case) |
| NOTE 1: The beam footprint diameter is 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: Speed of light used for delay calculation is 299792458 m/s. | ||
7.2 用户平面增强
7.2.1 MAC
7.2.1.1 概述
非地面网络（NTN）中MAC计时器过期所面临的挑战在物联网NTN中依然存在，且高RTT是主要原因[18]。以下条款摘自TR 38.821 [3]，并针对物联网操作进行了适当修改。
7.2.1.2 随机接入
随机接入（RA）响应窗口增强
问题陈述
发送随机接入前导（Msg1）后，用户设备（UE）会监控物理下行控制信道（PDCCH）以接收随机接入响应（RAR）消息（Msg2）。RA响应窗口在前导传输后的一定时间间隔开始。如果在此窗口期间未收到有效响应，则会传输新的前导。如果传输了多个前导而未在RA响应窗口期间收到有效响应，则会向上层指示随机接入问题。
在NTN中，传播延迟更大，因此UE无法在指定的地面通信时间间隔内接收到RAR消息。因此，应修改RA响应窗口的开始时间以支持物联网NTN。
解决方案概述
与NR NTN [3]类似，可以调整偏移量以延迟物联网NTN的RA响应窗口的开始[10]。如果RA响应窗口的开始时间得到准确补偿且不需要重复扩展，则无需为物联网NTN扩展ra-ResponseWindowSize。
争用解决计时器增强
问题陈述
当UE发送RRC连接请求（Msg3）时，它会监控Msg4以解决可能的随机接入争用。mac-ContentionResolutionTimer在Msg3传输后开始。mac-ContentionResolutionTimer的最大可配置值足够大，可以覆盖NTN中的往返延迟。然而，为了节省UE功率，应修改mac-ContentionResolutionTimer的开始时间以支持NTN。
解决方案概述
与NR NTN [3]类似，引入偏移量以延迟物联网NTN的mac-ContentionResolutionTimer的开始[18]。
7.2.1.3 不连续接收（DRX）
问题陈述
不连续接收（DRX）通过减少PDCCH监控时间来节省UE电池。多个RRC可配置参数用于配置DRX。[15, TS36.331]
HARQ RTT计时器是MAC实体预期进行HARQ重传之前的最小持续时间。UL HARQ RTT计时器与DL HARQ RTT计时器相同，只是用于上行链路。如果物联网NTN支持HARQ，则应修改DL HARQ RTT计时器和UL HARQ RTT计时器的处理方式以支持物联网NTN。
与NR NTN [3]类似，无需修改与DRX相关的其他计时器即可支持物联网NTN。
解决方案概述
由于NR NTN [3]中MAC计时器过期所面临的挑战在物联网NTN中依然存在，因此可以假设将NR NTN中DL HARQ RTT计时器和UL HARQ RTT计时器的开始时间的相同解决方案作为基线来支持物联网NTN [18]。
7.2.1.4 调度请求
问题陈述
UE可以使用调度请求（SR）来从eNB请求用于新传输或更高优先级传输的UL-SCH资源。SR传输由RRC配置。当禁止计时器（sr-ProhibitTimer）处于活动状态时，不会启动进一步的SR。对于eMTC，sr-ProhibitTimer最晚在7个SR周期后过期；对于NB-IoT，则在7个NPRACH机会后过期[15]。sr-ProhibitTimer过期后，将启动SR。对于GEO系统，由于RTT较大，值范围可能不足。
解决方案概述
将修改sr-ProhibitTimer以包含更大的值以支持物联网NTN。可以考虑与NR NTN对齐。
7.2.1.5 HARQ
注：HARQ的MAC技术规范[20]变更和其他信令方面的细节将在工作项目阶段进行讨论。
7.2.1.6 上行链路调度
当数据到达缓冲区时的典型过程是触发缓冲区状态报告，如果UE没有任何用于传输BSR的上行链路资源，则UE将继续进行调度请求以请求资源。由于调度请求只是告诉网络UE需要调度的指示，因此网络将不知道调度UE所需资源的全部范围，因此首先网络可能会用足够大的授权来调度UE以发送BSR，以便网络可以更准确地调度UE。
在非地面网络中，此过程的缺点是，从数据到达UE侧缓冲区直到它可以被适当调度并获得适合数据的资源，至少需要两个往返时间。由于较大的传播延迟，这可能会变得非常大。基于这些原因，讨论了一些针对NR NTN的UL调度增强。然而，与NR NTN不同，至少对于NB-IoT NTN，不需要UL调度增强来减少延迟，因为延迟不是物联网设备的关键性能要求[18]。
7.2.1.7 预配置上行链路资源
可以向pur-ResponseWindowTimer的开始添加一个偏移量。如果UE-gNB RTT准确补偿了pur-ResponseWindowTimer的开始，则无需扩展pur-ResponseWindowTimer的值范围。
7.2.2 RLC
7.2.2.1 重排序计时器
问题陈述
AM和UM模式都使用t-Reordering计时器来控制RLC等待区间，以便在将缺失数据视为丢失并将任何接收到的数据传递给PDCP层之前，对乱序的MAC数据进行处理。t-Reordering计时器可以配置为0至1600ms之间的固定值[15]。较大的传播延迟可能会对t-Reordering计时器产生影响。
解决方案概述
将扩展RLC t-Reordering计时器的值范围以支持物联网NTN。
7.2.2.2 RLC序列号
在NB-IoT中，RLC序列号（SN）大小为AM模式的7位和UM模式的5位。在eMTC中，指定了10位和16位作为UM和AM SN字段长度的最大值[8]。无线电承载所需的序列号空间取决于要支持的数据速率、重传时间（即RTT、重传次数和调度延迟）以及RLC SDU的平均大小。由于物联网NTN的数据速率显著低于NR NTN，因此无需为物联网NTN扩展RLC SN长度。
7.2.3 PDCP
7.2.3.1 丢弃计时器
当丢弃计时器对PDCP SDU过期或状态报告确认成功交付时，发送PDCP实体应丢弃PDCP SDU[17]。对于eMTC，丢弃计时器可以配置为最多1500ms；对于NB-IoT，可以配置为最多81920ms，或者可以通过选择无穷大而关闭。丢弃计时器主要反映属于服务的数据包的QoS要求。
注：如果对工作项目阶段的技术规范影响最小，可以考虑增强PDCP丢弃计时器。
7.2.3.2 PDCP序列号
在NB-IoT中，PDCP序列号（SN）大小为7位。在eMTC中，PDCP SN字段长度的最大可能值为18位[9]。由于物联网NTN的数据速率显著低于NR NTN，因此无需为物联网NTN扩展PDCP SN长度。
7.3 控制平面增强
7.3.1 空闲模式移动性增强
7.3.1.1 跟踪区域
问题陈述
如38.821 [17]所述，卫星可能提供非常大的小区，覆盖数百公里，因此会导致较大的跟踪区域。在这种情况下，跟踪区域更新（TAU）最少，但由于它与跟踪区域内的设备数量有关，因此寻呼负载可能很高。
移动小区以及因此移动的跟踪区域将难以在网络中管理，因为TAU和寻呼信令负载之间的对比将过于极端，无法找到实用的折衷方案。
一方面，小的跟踪区域会导致位于两个TA之间的边界处的UE进行大量的TAU信令，如图7.3.1.1-1所示。
图7.3.1.1-1：移动小区和小跟踪区域导致大量TAU信令
另一方面，宽跟踪区域会导致卫星波束中的寻呼负载增加，如图7.3.1.1-2所示。
图7.3.1.1-2：移动小区和宽跟踪区域导致更高的寻呼负载
然而，必须调整跟踪区域的大小以最小化TAU，因为与网络上的寻呼相比，TAU的信令更为密集。
在实际跟踪区域设计中，影响性能和容量的一个标准是MME/AMF平台的限制能力和无线信道容量。
乒乓效应会产生过多的TAU，可以通过确保相邻小区之间有10-20%的重叠，以及特别是在小区/跟踪区域边缘向用户设备（UE）适当分配跟踪区域标识（TAI）列表来最小化这种效应。
为了避免由卫星运动触发的UE频繁执行TAU，跟踪区域被设计为固定在地面上（即地球固定TA，类似于非地面网络（NR NTN））。对于非地面网络低轨卫星（NTN LEO），这意味着当小区扫过地面时，广播的跟踪区域代码（即TAC）会发生变化，当小区到达下一个计划的地球固定跟踪区域位置时。当小区波束进入下一个计划跟踪区域的区域时，eNB广播的TAC需要更新。当UE检测到其进入了一个不在其之前在网络中注册的跟踪区域列表中的跟踪区域时，将触发移动性注册更新过程。
图7.3.1.1-3：LEO移动波束实时更新TAC和PLMN ID的示例
如图7.3.1.1-3所示，网络根据星历实时更新广播的TAC，并确认广播的TAC与卫星波束覆盖的地理区域相关联。UE监听TAI = PLMN ID + TAC，并根据广播的TAC和PLMN ID确定当其移出注册区域时是否触发注册区域更新过程。
用于更新物联网非地面网络（IoT NTN）广播TAC的两个信令选项如下所述：
（1）“硬切换”选项：
每个PLMN，一个小区只广播一个TAC。新的TAC替换旧的TAC，在边界区域可能会有一些波动。如图7.3.1.1-4所示，从T1到T3，UE将看到其TAC变化，如TAC-2 -> TAC-1 -> TAC-2。
图7.3.1.1-4：边界区域的TAC波动
（2）“软切换”选项：
每个PLMN，一个小区可以广播多个TAC。该小区在其系统信息中除了旧的TAC之外还添加新的TAC，随后移除旧的TAC。如果存在一系列跟踪区域，则当小区扫过地面时，TA列表增加一个TAC并移除一个旧TAC。这也减少了位于边界区域的UE发生的TAU数量。然而，对于“软切换”选项，一个小区广播的TAC越多，其经历的寻呼负载就越重，这通常会导致小区之间的寻呼负载分布显著不平衡。因此，在网络规划和实施中，需要在寻呼负载和软切换启用的实际TA区域波动的平衡之间进行权衡。
注：对于TA处理，细节预计在工作项目阶段确定，例如UE更新/重新读取系统信息的要求。
7.3.1.2 使用卫星辅助信息和UE位置信息
除了广播系统信息中包含的物理小区标识（PCI）和频率信息外，还可以使用卫星辅助信息（例如星历信息）和UE位置信息来帮助物联网非地面网络（IoT NTN）中的UE执行测量和小区选择/重选[3][10]。
卫星辅助信息（例如星历信息）可以以节能的方式用于处理覆盖空洞或不连续的卫星覆盖。对于UE，它应该能够基于卫星辅助信息预测不连续的覆盖。在可能/合理的范围内，预期UE在没有卫星覆盖的情况下不会尝试驻留或连接。在可能/合理的范围内，预期网络不会尝试联系没有覆盖的UE。
注1：预期的要求是UE和网络在UE唤醒和可达（例如，用于寻呼）时是同步的。
注2：可以使用系统信息（SI）消息为物联网非地面网络（IoT NTN）提供卫星辅助信息。
7.3.1.3 增强UE空闲模式移动性
将重用为窄带物联网（NB-IoT）/增强型机器类型通信（eMTC）指定的小区选择/重选机制作为基线[19]。如果适用于物联网非地面网络（IoT NTN），则考虑非地面网络（NR NTN）中小区选择/重选程序的增强[8][18]。
注：假设现有的Qoffset参数可用于TN和IoT NTN之间的小区重选。
7.3.1.4 进一步增强系统信息获取
对于一些物联网UE，预期基于多个小区中提供的相同系统信息（SI）的增强可以带来功耗方面的益处。
7.3.2 连接模式移动性增强
7.3.2.1 概述
与非地面网络（NR NTN）类似[8]，对于低轨卫星非地面网络（LEO NTN），移动性管理过程应考虑卫星的运动，而对于地球同步轨道非地面网络（GEO NTN），则需要考虑大的传播延迟。
7.3.2.2 窄带物联网非地面网络（NB-IoT NTN）的连接模式移动性
窄带物联网（NB-IoT）没有定义连接模式移动性过程。当窄带物联网（NB-IoT）UE超出源小区的服务覆盖时，它会经历无线链路失败（RLF）。这会触发UE执行无线资源控制（RRC）连接重建。
无线链路失败（RLF）和RRC连接重建过程，如Release 16中所述，被用作窄带物联网非地面网络（NB-IoT NTN）的基线。如果适用，可以考虑Release-17的增强功能，以减少RRC重建所需的时间。可以进一步考虑一些小的增强功能，例如通过使用卫星辅助（星历）信息。
7.3.2.3 增强型机器类型通信非地面网络（eMTC NTN）的连接模式移动性
增强型机器类型通信非地面网络（eMTC NTN）在连接模式移动性方面面临的挑战与非地面网络（NR NTN）中的连接模式移动性问题相似。这些包括（1）与切换信令相关的高延迟，（2）测量有效性，（3）频繁切换，（4）动态邻小区列表，（5）大量UE的切换，以及（6）传播延迟差异对测量的影响[8][18]。
如Release 16中所述，无线链路失败（RLF）和RRC连接重建过程被用作增强型机器类型通信非地面网络（eMTC NTN）的基线。可以进一步考虑一些小的增强功能。
条件切换（CHO）可以用于移动小区和固定小区场景。以Release-16中定义的条件切换（CHO）过程和执行条件为基线，并考虑以下因素：
- 现有的用于CHO的测量框架（例如测量配置、执行）是基线。
- 可以使用适用于增强型机器类型通信（eMTC）的现有测量标准和事件来用于物联网非地面网络（IoT NTN）。支持新的测量类型将需要理由，但并不排除，例如为了增强覆盖。
- 可以引入基于时间或定时器以及基于位置的CHO触发事件，与现有的Release-16基于CHO测量的事件相结合，用于移动小区和固定小区场景。不排除支持新的触发事件。
- 增强型机器类型通信非地面网络（eMTC NTN）中条件切换（CHO）的增强应基于非地面网络（NR NTN）中条件切换（CHO）的增强。
注1：物联网非地面网络（IoT NTN）的条件切换（CHO）不适用于连接到5GC的E-UTRA（在Release-16中也有类似的限制）。
7.3.3 寻呼容量
考虑到附件B.2中捕获的物联网非地面网络（IoT NTN）设备密度目标，评估了寻呼容量及其对跟踪区域大小的影响。
为了确定寻呼容量，考虑了以下参数和配置可能性，适用于长期演进机器类型通信（LTE-M）和窄带物联网（NB-IoT）[13]：
- N_PO，每个寻呼帧的寻呼次数，由RRC参数nB确定（最大值为4）。
- N_PF，每秒配置的寻呼帧数，由配置的寻呼周期确定。
- N_carriers，载波数量，由RRC参数paging-narrowBands-r13（对于LTE-M）和maxNonAnchorCarriers-NB-r14（对于NB-IoT）确定。
- Wcarrier，窄带物联网（NB-IoT）的载波寻呼权重。为了评估的目的，寻呼负载在载波之间均匀分布。
- N_records，寻呼消息中的记录数（最多16条记录）。
- A_paging=A×M，其中A_paging是寻呼区域，A是小区面积，M是跟踪区域中的小区数量。小区的面积可以大致计算为A=(3√3)/2 R^2，其中R是六边形区域的较大半径。
- N_pages，UE每秒的平均寻呼尝试次数。
- NO_Traffic，小区中具有网络发起流量的UE的比例（参见注1）。
- D_UE，每平方公里的UE密度。
注1：TR 45.820 [4]第5.2条（容量评估方法）中使用的流量模型将用户设备（UE）群体分为80%的设备用于周期性移动自主报告应用类型，20%用于网络命令应用类型（NO_Traffic=0.2）。
尽管窄带物联网（NB-IoT）和LTE-M在实际应用中的工作方式存在一些差异，但对于基于标准可配置的分页容量而言，它们通常可以由相同的参数进行控制。在评估中，我们仅从覆盖范围的角度考虑平均用户设备（UE），因此不包括深度覆盖范围内的UE百分比等因素。
LTE-M/NB-IoT小区每秒可分页的最大用户设备（UE）数量的计算方法如下：
寻呼信道负载表示为：
假设一个用户设备（UE）仅在跟踪区域中的一个小区内进行寻呼，那么可实现的UE密度为：
对于寻呼尝试次数N_pages，我们考虑了TR 45.820 [4]条款E.2.3中给出的流量模型，该模型表明周期性到达时间间隔的分布为：40%的UE具有1天的到达时间间隔，40%的UE具有2小时的到达时间间隔，15%的UE具有1小时的到达时间间隔，5%的UE具有30分钟的到达时间间隔。平均每个UE，这意味着每秒的寻呼尝试次数N_pages=1.2963*10^(-4)。
4372
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
