跳转至

深度学习 NTN 专区

笔者接触 NTN 已有一年时间, 现在由于新的项目需要, 得重新学习并更深层次地理解 NTN.

故而有了本文, 作为 "深度学习 NTN" 的读书笔记

NTN: Non-Terrestrial Networks. 非地面网络

注意, 笔者在本文正文开启前需要明确提醒: 本文不适合新手入门的小白, 它适合已经对NTN有一定基础的"初级开发者"

笔者在半年前写过不少 NTN 新手入门向教程, 本文算是 "初级开发者 -> 中级系统研究者" 的一篇教程

  1. 新手入门, 成长为"初级开发者":
    • def(新手): RACH / LEO / NTN 只听过基础名词, 完全不清楚交互步骤和常见状态机
    • def(初级开发者): 熟悉基本 NTN 流程. 可以看懂/初步参与 OpenAirInterface 的活动, 比如看懂部分 Issue/PR 在干啥
    • 这一阶段, 建议参考笔者的另几篇文章入门:
  2. "初级开发者" 转型成为 "中级系统研究者":
    • def(中级系统研究者): 熟悉大部分 OpenAirInterface 模块源码. 能看懂并自行提出 Issue 和 PR
    • 看懂本文基本就差不多了
    • PS: 笔者写本文耗时5天, 这还是在AI辅助的背景下, 因此: 如果想 deep dive NTN 的话, 千万别尝试速通
  3. "中级系统研究者" 进化成为 "高级系统研究者":
    • 不知道. 因为笔者还不是 Senior (很有自知之明...)
Warning

在2026年手写文章变得不太现实, 因此本文使用 claude 和 gemini 进行辅助写作

但笔者全程把关, 并进行了部分客制化修改

NTN 协议知识清单:

  1. 几何与轨道
    • 轨道周期 / 仰角 / 过顶时长
    • TLE
  2. 架构与拓扑
    • REGEN vs TRANS
    • service link / feeder link
    • NTN 架构选项
    • 三种小区几何: earth-fixed / quasi-earth-fixed / earth-moving
    • gNB 是 Mono 还是 Split, 仍未定: 有观点支持 "Rel-19 选择完整 gNB 上星, 拒绝 gNB-DU 切分" 🌟
  3. 同步与时序
    • TA 四项分解: N_TA / N_TA,offset / N_TA,adj^common / N_TA,adj^UE
    • ta-Common / ta-CommonDrift / ta-CommonDriftVariant 三项多项式
    • K_offset
    • 频率/多普勒预补偿
    • GNSS 强依赖
  4. 系统信息与广播
    • SIB19 全字段
      • ntn-Config-r17、t-Service-r17
      • referenceLocation-r17、distanceThresh-r17
      • ephemerisInfo、epochTime、ntn-UlSyncValidityDuration
    • SIB1 部分字段
      • cellBarredNTN (UE 用它隐式判断 TN or NTN)
  5. 定时器与状态机
  6. 随机接入与 MAC
    • PRACH / RAR 窗扩展
    • HARQ 32 进程
    • downlinkHARQ-FeedbackDisabled-r17 Bitmap
    • HARQ mode A/B
    • 盲重传
    • BSR→grant 环受 K_offset 拉长
  7. 移动性管理
    • CHO 及 NTN 特有触发: CondEvent T1(时间)、D1(位置/距离)
    • t-Service 驱动的定时切换
    • earth-moving cell 的 NTN 条件切换
    • idle 态行为: TAC、小区重选、寻呼、RRC_INACTIVE 锚点迁移
  8. RLC / PDCP
    • RLC AM 重建
    • PDCP t-Reordering、discard timer
  9. 核心网与接口
  10. 频谱与 RF
    • FR1-NTN 与 FR2-NTN 的工作频段目前全部是 FDD -> 链路容量

ShareTechnote NTN 专区

原文

https://sharetechnote.com/html/NTN/NTN_WhatIsIt.html

Sec 0: What Is It

alt text

(1) Components:

  • Satellites (GEO, MEO, LEO)
  • High-Altitude Platforms (HAPS)
    • balloons or drones
    • support feeder/service links
  • UAVs (Unmanned Aerial Vehicles)
    • drones
    • as relay nodes
  • Links
    • ISL (Inter-Satellite Link)
    • Feeder Link
      • GS <-> Sat / HAPS
    • Air-to-Ground Link
      • Airplane <-> TN (GS)
    • Service Link
      • UE <-> Sat / HAPS

(2) Use Cases:

  • Direct to UE
    • Ordinary portable devices (e.g, smartphone)
    • 手机直连卫星
  • IoT-NTN
    • Connects IoT devices in remote areas, such as maritime vessels.
    • IoT设备, 常见于远洋航行
  • Air-to-Ground
    • Provides connectivity for airplanes during flights.
  • VSAT (Very Small Aperture Terminal)
    • Used for rural connectivity or mobile stations (e.g., trucks).
    • 小型终端, 比如车载

Sec 1: Why NTN

(1) Motivations: Why choose NTN?

文档里 brainstorm 的内容很广, 笔者就摘要一些"直击命门"的:

  1. Bridging the Connectivity Gap
    • Remote Areas
    • Maritime Coverage
  2. Enhanced Network Resilience
    • Disaster Relief: 紧急情况下的通信服务
    • Network Redundancy: 备用通信路径
    • Enhanced Reliability: TN 的备用通信路径
    • Backup and Redundancy: NTN 可在 TN 发生故障或中断时作为备份
    • Network Flexibility: 快速扩展网络, 为特定事件或情况提供 临时覆盖
  3. Expanding the 5G Ecosystem
    • Ubiquitous Coverage: 陆海空"无缝连接"
    • New Use Cases: 远程医疗、智慧农业、环境监测
  4. Seamless Roaming/Handover: TN/NTN间的过渡应该是无缝衔接的, 而这只有双方都使用相同协议才能实现
    • Low-Latency Satellites: LEO
    • Optimized Protocols: 促进 TN 和 NTN 间流畅无缝的漫游和切换
    • Unified User Experience: 不会遇到中断或需要手动切换网络
The Coverage Argument, in Numbers

alt text

正着读(覆盖)

  • 要盖住澳大利亚 770 万 km², 地面要约 3300 个宏站, 每个都要征地、通电、通传输、修一条路进去
  • LEO 只要同时 10 个波束
  • GEO 一个波束还有富余

所以在沙漠、雨林、公海上, NTN 不是"便宜一点", 而是地面网压根建不起来

反着读(容量)

"The same table read the other way is equally instructive. A terrestrial network re-uses its spectrum at every one of those 3,300 sites, so its aggregate capacity is roughly 3,300 times the per-site capacity. The satellite beam uses its spectrum once across the whole footprint."

  • 地面上: 那 3300 个站里, 每个站都在重复使用同一段频谱
  • 卫星上: 那一个波束, 整块大陆只用了一次频谱

于是单位面积上可用的频谱量差了约四个数量级

NTN 赢在"每单位基础设施覆盖多少面积", 输在"每单位面积能提供多少容量"

这也顺带解释了: 为什么 NTN 从短消息起步、为什么 3GPP 里的速率指标低得可怜、为什么大家拼命把波束做小

为什么 3300 sites -> 3,300x per-site capacity

通信基础小科普

(1) 什么是频谱

无线电波是电磁波, 用频率描述它每秒振荡多少次: 1 Hz = 每秒 1 次,3.5 GHz = 每秒 35 亿次

把所有可用频率排成一条数轴,就是频谱:

  • 几百 kHz 是调幅广播
  • 几百 MHz 到几 GHz 是蜂窝和 WiFi
  • 几十 GHz 是毫米波

这条数轴被各国监管机构切成块分配出去, 每一块就是一个频段

运营商拿到的是数轴上的一段, 比如 3.4–3.5 GHz。这一段的宽度就是 100 MHz, 这是他的"带宽" (这个是频谱带宽, 不是网络带宽)

注意这是一种被行政划分的、有限的、不可再生的资源:

频率越低, 波长越长, 绕射和穿透越好, 传得越远

但低频段早被广播电视之类占满了, 剩下的带宽都很窄

DTC 之所以要抢 700 MHz–2 GHz 这种低频段, 就是为了覆盖, 代价是只能拿到 2×5 或 2×10 MHz 这种很窄的带宽

(2) 频谱与"网络带宽"的大致关系

QPSK 每符号 2 bit, 16QAM 4 bit, 256QAM 8 bit

Text Only
1
2
速率 ≈ 带宽 × 每符号 bit 数
100 MHz × 8 bit/符号 = 800 Mbps

再乘上 MIMO 的空间流数、扣掉信道编码和控制信令的开销, 一个 5G 扇区跑到 1 Gbps 左右就是这么来的

(3) 无线资源是3D的: 频率 / 时间 / 空间

现在回到最开始的问题: 在一个 gNB 覆盖范围内, "土地资源"这个直觉完全正确

LTE/5G NR 用 OFDMA, 把 100 MHz 切成很多窄子载波, 把时间切成很短的时隙, 于是这段频谱变成一张二维网格

alt text

调度器每 1 毫秒决定一次把哪些格子发给哪个用户

一张网格就是一个小区的全部容量

10 个用户同时看视频, 就是瓜分这些格子 (3GPP 里的最小分配单位叫RB, resource block)

在这个层面上, "管子被分掉"的直觉完全对

但是在不同 gNB 之间, 是"非干扰"的关系:

隔壁小区有一张一模一样的网格, 用的是同一段 3.4–3.5 GHz, 但它是独立的一张, 不是从你这张里切走的

原因: 信号功率衰减厉害, 60 km 外那个基站发出的东西传到你这里, 已经掉到"噪声底"以下, 你的接收机根本"听不见"它, 所以它爱怎么用怎么用

维度 怎么分 谁来分
频率 子载波 小区内调度器
时间 时隙 小区内调度器
空间 整张网格复制一份 地理位置,免费

前两维在小区内部分配, 是零和的; 第三维靠距离免费复制, 不是零和的

因此回到最开始问题出发点:

3300 个基站 = 3300 份网格拷贝 = 3300 倍总容量, 而监管机构给你的仍然只有那一段 100 MHz。这就是 3300× 的来源

(2) Where NTN Does Not Make Sense?

事实上, NTN 对很多问题都无法很好地解决, 因此一定要知道 "它的能力边界/适用范围"

下面这些场景, 其实并不太适合 NTN:

  • Dense urban capacity: 城市恰恰是地面资源再利用优势最为显著的地方. 上面那个 3300x 的例子就很直观!
  • Indoor coverage: 卫星链路在室外本就捉襟见肘的情况下，还要承受建筑物穿透损耗...
  • Low latency applications: 延迟极为敏感的应用

TLDR: NTN is not a better network - it is a network that exists where the better one does not.

Sec 2: Challenges of NTN

这一章的信息密度其实不高: 它是一份 2021 年写的开放问题清单, 后来又补了几轮 "现在怎么样了"(2025) 的回顾

(1) List of Challenges

类别 包含哪些 会不会变好
物理 时延、多普勒、小区内差分时延 不会。唯一的旋钮是轨道高度, 而降轨道等于换来更大的星座规模
工程 天线、终端对准、星上处理、功率、切换、地面站、网管、可扩展性 会, 而且已经改善了不少
经济 发射成本、终端成本、商业模式、竞争 部分。可复用火箭把每公斤入轨成本压下来了, 终端成本和商业模式仍是开放问题
监管与环境 频谱协调、轨道管理、碎片 反而变难了

(2) What 3GPP Actually Did About These

"Almost every answer takes the same shape - move the predictable part of the problem out of the closed loop and compute it in advance."

挑战 规范怎么解 具体在做什么
时延撑爆协议定时器 调度偏移 K_offset、K_mac,响应窗和定时器起点外推,HARQ 进程数提到 32 并可逐进程关闭反馈 地面 NR 假定 DCI 授权到 PUSCH 的间隔远小于一个时隙。K_offset 给所有上行调度时序统一加一个偏移,让 gNB 的期望和现实对上。HARQ 那条是典型的带宽时延积问题:25 ms 往返、0.5 ms 时隙,16 个停等进程根本填不满管道,所以要么加到 32,要么干脆关掉反馈、退回 RLC ARQ 或盲重传
同小区内 UE 时延不同 UE 在首次发射之前就用 GNSS 和广播星历自己算出 TA 闭环在这里物理上无法闭合:RAR 里 TA 字段的取值范围只有几百微秒,离 25 ms 差着两个量级;而 3.12 ms 的差分时延又超过 PRACH 的循环前缀。所以网络干脆不去吸收这个扩散,让 UE 自己消掉,gNB 只面对很小的残差
大多普勒 UE 用同一套星历开环预补偿服务链路,馈电链路和载荷本振的那部分由网络侧静默处理 就是我们上一轮说的 ±48 kHz / 15 kHz 子载波间隔的问题。分工很清楚:UE 只管自己到卫星这一段,地面到卫星那一段 UE 根本看不见
切换复杂 移动性从"测量触发"改成"时间和位置触发":带星历的条件切换、t-Service、邻区辅助信息 这是我觉得最漂亮的一处。地面网靠 A3 这类 RSRP 事件被动触发;但卫星运动是完全可预测的,那就没必要等测量 —— 直接按时刻表和地理位置执行。移动性从反应式变成了确定性调度
地面站数量和可达性 两条架构路线:星间链路让卫星够到远处关口站,以及再生载荷让更少的东西需要过馈电链路
星上处理能力受限 Rel-17 直接绕开:只把透明载荷写成规范性内容,gNB 留在地面 代价就是上面那张表里"透明"一列的往返时延要翻倍,因为馈电链路被算进了环路。好处是 gNB 在地上可以随时升级
天线与终端对准 不是靠规范解决的,而是靠限定范围:直连终端在 S 频段对着 0 dBi 手机天线工作,压根不需要对准;Ka 频段留给有方向性的 VSAT 终端
功率受限 靠覆盖增强,以及在 IoT-NTN 场景直接接受极低速率 —— 而不是靠找到更多功率

这些具体机制先不用管, 我们后面会依次解析的~

Sec 3: Tech Requirement

(1) 时延需求是"物理约束", "网络优化"都建立在物理特性上

这是开篇最重要的一个观念:

  • 地面网的时延需求是可以设计去达成的:
    • 嫌慢: 缩队列、把功能下沉到边缘、调度更激进
  • 但卫星链路的时延绝大部分不是网络造成的, 而是距离造成的:
    • 协议里没有任何东西能让它变快

所以当规范给 NTN 写一条时延需求时, 它做的不是"要求系统快", 而是一件更朴素的事:

把几何已经花掉的那笔钱记下来, 然后规定网络最多还能再加多少

物理基础 + 系统优化
轨道 单向最大传播时延 + 假定的 5G 网络时延 = 端到端需求
GEO 280 ms 5 ms 285 ms
MEO 90 ms 5 ms 95 ms
LEO 30 ms 5 ms 35 ms

需求 = 物理 + 一点点余量

那 5 ms 才是真正对系统提出的要求, 前面那一大截只是"base"

(2) 两张重要的表: TS 22.261 + TR 38.821

  1. TS 22.261 (Rel 18) - Table 7.4.1-1: UE to satellite propagation delay
    • alt text
  2. TR 38.821 - Table 7.1-1: NTN scenarios versus delay constraints
    • alt text

上面两张时延表, 乍看重复, 其实回答的是两个问题:

TS 22.261 表 TR 38.821 表
出处 业务需求规范 解决方案研究
视角 用户视角: 你大概要等多久 设计者视角: 你的协议必须扛住什么
内容 只有总量 最小值、最大值、透明/再生之分、时延变化率

TR 38.821 多出来的三样东西, 恰好各自催生了一整套机制:

  1. 最小值和最大值之间的差 = 小区内差分时延
    • 这就是为什么: 单一 RACH 配置不够用, 必须做逐 UE 预补偿
  2. 透明列正好是再生列的两倍
    • 因为弯管载荷把馈电链路塞进了 UE 的无线往返里
    • TRANS/REGEN 载荷类型, 在任何协议工作开始之前, 就已经改变了时延预算
  3. 时延变化率 (LEO 可达 ±93 μs/s)
    • 这就是为什么: Timing Advance 是以带漂移项的多项式形式广播的, 而不是一个值

(3) NTN 下独有的 TA 计算: 开环计算. 而非传统 TN 的字段控制

首先先上结论: 直接基于 TN 的 RAR TA 字段不够, NTN 不准备改变 RAR TA 包的字段格式, 也是新提出并使用一套独有的 TA 计算机制

在 TN 中, RAR Response 里的 TA command 是 12 bit, 取值 0 到 3846, 映射关系是:

Text Only
1
N_TA = TA × 16 × 64 / 2^μ × Tc      (Tc ≈ 0.509 ns)

代入最大值:

  • 15 kHz 子载波间隔: 3846 × 1024 × Tc = 2.003 ms
  • 30 kHz 子载波间隔: 1.002 ms

而 LEO 单向最小时延就有 3 ms, GEO 是 120 ms. 这个字段很明显完全不够用!

这里有两条直观路径:

  1. 加宽它: 完全不行, 很蠢
    • 一个能装下 GEO 的字段, 放在地面场景里荒谬得可笑
  2. 提出新的机制: NTN 下的 TA 开环控制
    • 只剩一条路: 把定时校正的大头从闭环里搬走, 改成 UE 用 GNSS 开环预算
    • 原本 RAR 那个字段只留着修很小的残差

(4) Rel-17 到底改了什么: 几乎没有新空口

这一节会让期待"新链路需要新无线技术"的人, 感到意外与失望...

波形还是同样的 OFDM, 信道编码还是 LDPC 和 Polar, 帧结构一样, 消息名字也和地面小区一模一样

Rel-17 没有设计卫星空口, 它是把现有 NR 空口拿来, 逐项推演"距离从几公里拉到几万公里之后什么会坏", 然后给每一处坏掉的地方加上 minimized patch

这个选择是特意的, 而且直接来自 NTN 存在的理由:

把卫星放进 3GPP 的价值, 就在于结果仍然是同一张网、同样的设备、同样的核心网和同样的签约

所以在 3GPP 中看到关于 NTN 的讨论, 基本上都是一堆偏移量、定时器、有效期和新字段, 而不是一堆新技术:

新场景下的需求是什么 Rel-17 如何解决问题
时延远超 RAR TA 字段能表达的范围 强制 UE 具备 GNSS, 首次发射前自行预补偿 TA
时延的公共部分 UE 不知道 ta-Common 带漂移项和漂移变化项 (SIB19 里的 ta-Info-r17), UE 自己外推而不是等下一条 SIB
TA 过大导致 UL 调度变得非因果 cellSpecificKoffset, 以及用于 MAC CE 生效时刻的 kmac
长往返导致 HARQ 停摆 最多 32 个 PDSCH 进程、NTN 专用的 PDSCH-to-HARQ-ACK 时序 (DL-DataToUL-ACK-v1700)、逐进程关闭反馈(downlinkHARQ-FeedbackDisabled-r17)
响应窗和定时器在回复到达前就 timeout 给 ra-ResponseWindow、msgB-ResponseWindow、ra-ContentionResolutionTimer 加起始偏移,让 UE 不在物理上必定无回复的时段白听
辅助数据随卫星移动而过期 epochTime 加 ntn-UlSyncValidityDuration, 由定时器 T430 强制执行, 超时即判定 UL Sync Failure
doppler 超出接收机捕获范围 UE 用同一套星历预补偿 service link, feeder link 由网络静默处理
小区不断被替换还要保 99.99% 基于时间和位置的移动性, 进行"确定性预计算/连接": t-Service、referenceLocation、distanceThresh、邻区星历
网络不再测量绝对时延 ta-Report, 由 UE 上报自己实际施加了多少 TA

后续版本是延续而不是转向:

  • Rel-18:
    • 把 NTN 扩展到 10 GHz 以上的 FR2-NTN 频段, 改善手持终端覆盖
    • 加入网络验证的 UE 位置
    • 改进 NTN-TN 与 NTN-NTN 移动性管理
  • Rel-19:
    • 继续做 NR-NTN 和 IoT-NTN 增强
    • 透明载荷始终是规范性基线, TR 38.821 里的再生场景只被描述, 没有被 profile

拓展讨论: HARQ 那笔账

作者把自己 2021 年写的两处存疑拿出来复盘, 这一段很有意思, 值得细看

2021年的疑问1: 32 个进程够不够?

HARQ 是逐进程停等的, 所以只有当 进程数 × 时隙长度 ≥ 往返时延 时, 发送才能保持连续

在 15 kHz 配置下, 一个时隙是 1 ms, 所以 32 个进程买到约 32 ms 的流水线深度

对照 TR 38.821 的往返数字:

场景 往返时延 32 进程够吗
LEO 600 km 再生 12.89 ms 够, 甚至只需要 16 个即可
LEO 600 km 透明 25.77 ms 刚好够, 处理时间没有任何余量
LEO 1200 km 透明 41.77 ms 不够
GEO 再生 / 透明 270.73 / 541.46 ms 需要几百个进程, 每个都要占一块软缓冲。手机里做不出来, 做出来也没用

结论: 把进程数提到 32 只救得了 LEO, 而且只是 LEO

还有个细节在支持 32 进程

选 32 不是随意的:

downlinkHARQ-FeedbackDisabled-r17 是一个 BIT STRING (SIZE (32))

一个进程一位, 这两个特性共同定下 32 的

2021年的疑问2: 干脆不要 HARQ, 交给高层重传?

作者当年猜"会有人试", 猜对了, 而且 Rel-17 做的比"去掉"更精细

机制就是 downlinkHARQ-FeedbackDisabled-r17 字段:

逐进程关闭上行 HARQ 反馈, 而不是整个小区关!

关掉反馈的进程永远不等待, 可以立刻复用, 流水线就不会停. 传输的可靠性交给 RLC AM 兜底

做成逐进程而不是全局, 原因是:

这样, 网络可以在承载信令的进程保留反馈, 在承载大块数据的进程关掉, 控制面可靠性不受影响

当然, 这样肯定也会有代价

可靠性上移到 RLC AM, 而 RLC 的重传环路更长, 所以链路自适应必须更保守, 尽量别走到需要重传那一步

这个权衡留给网络逐进程去做! 这就是为什么规范给的是一个 bitmap, 而不是一个"全局开关"

Sec 4: NTN Spectrum

文章内容

(1) FR-1/2 两个频率范围

名称 范围 备注
FR1-NTN 410 – 7125 MHz 被其他规范引用时, 当作 FR1 频段处理
FR2-NTN 17300 – 30000 MHz 被其他规范引用时, 当作 FR2-1 频段处理, 除非另有说明

NTN 频段不是一套平行体系, 而是挂在既有 FR 框架下的!

其他规范里所有按 FR1/FR2 分叉的行为直接复用, 这和上一章 "几乎没有新空口" 是同一个思路

(2) FR1-NTN: 细分成 n256/255/254 三个频段

频段 UL (UE 发) DL (UE 收) 各自带宽 双工
n256 1980 – 2010 MHz 2170 – 2200 MHz 30 MHz FDD
n255 1626.5 – 1660.5 MHz 1525 – 1559 MHz 34 MHz FDD
n254 1610 – 1626.5 MHz 2483.5 – 2500 MHz 16.5 MHz FDD

alt text

编号规则: NTN 卫星频段从 n256 开始倒着往下数。所以下一个新频段会是 n255、n254, 而不是 n257.

注意
  • n255 的 DL 频率低于 UL
    • 这和地面网的习惯相反. 非常例外, 要小心
  • n254 的上下行根本不在同一个波段:
    • 上行在 L 波段 1.6 GHz
    • 下行在 S 波段 2.48 GHz
    • 相隔近 900 MHz. 这在 3GPP 频段里非常罕见!
这三个频段的来源 + 历史包袱

3GPP 没有拿到任何新频谱!

这三个都是 ITU 早就划给移动卫星业务(MSS)的既有分配, 原本就握在 "传统卫星运营商" 手里:

  • n255
    • 是 L 波段 MSS
    • 历史上属于 Inmarsat / Ligado 一系
  • n254
    • 是所谓 Big LEO 频段
    • Globalstar 用的就是它
  • n256
    • 是 2 GHz MSS
    • 历史上归 ICO / TerreStar / EchoStar 一脉

所以, 上述三个频段的怪异形状 (反向双工、上下行跨波段) 不是 3GPP 设计出来的, 是直接继承来的历史包袱

(3) FR2-NTN: 细分成 n512/511/510 三个频段

其实是一个频段被监管切成了三份

频段 上行 下行 适用范围
n512 27500 – 30000 MHz 17300 – 20200 MHz 适用 CEPT ECC Decision (05)01 和 (13)01 的国家
n511 28350 – 30000 MHz 17300 – 20200 MHz 适用 FCC 47 CFR Part 25 的国家
n510 27500 – 28350 MHz 17300 – 20200 MHz 美国的 GS 运营, 且 FCC 规则目前不包含该频段的 ESIM 运行

三个频段的下行完全相同, 只有上行不同!

它们在技术上不是三个频段, 而是同一块 Ka 频谱被不同监管辖区切开!!!

n511 和 n510 拼起来正好等于 n512

n510 那条注释值得留意

ESIM 指运动中的地球站(船舶、飞机、车载)

FCC 规则目前不覆盖这个频段里的 ESIM, 意味着: 这一片只能给固定 GS 用

(4) 注意

  1. 这些全是 service link 频段 (aka. UE-Sat)

    • 指的都是 UE-Sat 这一段
    • feeder link (GS-Sat) 完全不在 3GPP 范围内:
      • 通常跑在 Ka/Q/V 波段, 由卫星运营商 (如 Starlink) 自己定!!!

  2. 上面这张表已经 will be out of dated 了

最新业界进展对齐

本章节直接读完原文, 笔者认为有一处"最需要警惕的地方":

按这张表去理解 Starlink 和 AST 在做的事, 会完全对不上

现在业界实际上存在两条平行的直连路线:

MSS 路线 地面频谱路线
用什么频谱 就是这张表里的 n254/n255/n256 运营商既有的地面移动频段
谁在走 3GPP NTN 规范体系 Starlink×T-Mobile、AST SpaceMobile
优势 监管环境稳定、干扰风险低、有 3GPP 技术规范背书 可以直接复用成熟的地面终端生态
代价 3GPP NTN 仍处早期, 支持这些能力的终端还很少 需要复杂的干扰管理和艰难的监管协调

Starlink Mobile 用的是划给地面移动的频段, 大致在 800–2000 MHz, 以便直接和未改装手机里的 LTE/NR 芯片对话

这套东西在美国靠的是 FCC 的 SCS 框架(允许地面频谱持有者从卫星上使用自己的频谱), 不在这一页的频段表里

Warning

这正好接上 Challenges 那章提到的 "D2C 频谱共存是全新的监管难题"

因为: 卫星波束不会在国界停下, 而地面频谱是按国家划分的

Sec 5: NTN Architecture and Scenario

(1) 架构

NTN 由三段组成:

  • 空间段: Satellite / HAPS
  • 地面段: NTN Gateway / gNB / 5GC
  • 用户段: 手机 / VSAT / 中继终端

三段之间靠两条主链路连接:

  • 服务链路 (service link):
    • Satellite <-> UE
    • 用 NR 空口
  • 馈电链路 (feeder link):
    • Satellite <-> Gateway
  • 再生星座还可以加星间链路 ISL

(2) 两种模式: TRANS vs REGEN

两者本质上只差一件事：gNB 在地面还是在星上

透明 (TRANS / Bent-pipe)

  • 卫星只做变频和放大，相当于挂在天上的射频拉远头
    • 馈电链路上传的就是 NR 波形本身，所以 UE 的空口要跨服务和馈电两段，时延翻倍（GEO 往返 541 ms）
    • 馈电链路的带宽必须装下所有波束的总带宽
  • 好处是: 卫星简单，gNB 在地面可以随时升级

再生 (REGEN)

  • 卫星自己解调解码，本身就是基站
    • 空口只到卫星为止，时延减半（GEO 往返 271 ms）
    • 馈电链路传的是核心网流量
    • 带宽只需匹配实际吞吐，而且可以用 ISL
  • 代价是: 星上复杂，硬件发射后就冻结了
规范进度
  • Rel-17/18 只规范了透明模式
  • Rel-19 引入了再生载荷, 做法是把完整的 gNB 放到卫星上

(3) Earth-fixed vs Earth-moving 波束/小区

这个选择决定: 小区是固定在地面上，还是以约 6.9 km/s 的速度扫过地面

Earth-fixed (GEO 天然如此)

  • 卫星转动波束, 一直盯住同一块区域
    • 在 UE 看来小区不动, 移动性接近地面网络
  • 但 LEO 只能盯住一个地方几分钟, 之后整个小区要切到下一颗星
    • 这叫 "准地面固定小区" (quasi-Earth-fixed cell)
  • 切换时刻可以由星历算出来, 所以用基于时间的条件切换

Earth-moving

  • 天线不转, 载荷最简单! 但小区自己在移动
    • 静止的 UE 大约每两分半钟也要切换一次
  • 同一颗星的相邻波束 RSRP 差不多!!!
    • RSRP 分辨不出该切到哪个, 只能靠位置或时间来触发
  • 跟踪区码也要随小区扫过而变化

适用场景: 固定小区适合宽带和语音, 移动小区适合 IoT 和短消息

(4) REGEN Function Split

"gNB 上星" 有两种做法:

  • 整机上星: 整个 gNB 都放在卫星上
  • 只放 DU:
    • DU（PHY/MAC/RLC）上星
    • CU（PDCP/SDAP/RRC）留在地面
    • 两者之间走 F1 接口

看看二者的 Trade-Off:

整机上星:

  • RRC 在轨决策，信令不用下地
  • 每颗星都是一个独立基站:
    • 星间切换是基站之间的切换
    • 需要 ISL 来传 Xn 接口信令
  • 星上负担重

只放 DU:

  • 星上负担轻
  • 挂在同一个 CU 下的星间切换只是换 DU，信令轻
    • 核心网也只看到少数几个 gNB
  • 代价是:
    • 每条 RRC 消息都要多跨一次馈电链路
    • CU-DU 连接不稳定

(5) Feeder Link Switch-over and Service Link Switch

在 LEO 场景下，链路两端都在换，而且两种切换都可预测:

服务链路 (Service Link) 切换:

  • UE 从一颗星换到下一颗，相当于 NTN 版的切换
  • 星历已知，所以用基于时间或位置的条件切换
    • 所需的星历信息由 SIB19 广播

馈电链路 (Feeder Link) 切换:

  • Satellite 看不到当前 Gateway 了，要换一个网关
    • 地面网络里没有对应的情况
  • 透明模式下很麻烦:
    • gNB 在网关后面! 如果换网关, 就基本等于换 gNB
    • 即使没有任何 UE 移动，小区也会变
  • 再生模式下温和:
    • gNB 跟着卫星走，只需迁移回传链路
    • 如果两个网关有短暂重叠，UE 可以完全无感
  • 有 ISL 时:
    • 流量可以经邻星转到有网关可见的那颗星，这是装 ISL 的主要理由

Sec 6: RACH in NTN

这一部分原文讲解的非常不清晰, 甚至全网我也没看到能"深入浅出讲解 NTN 机制及其设计原理"的文章.

因此, 在广泛搜集、整理完 RACH 部分后, 笔者决定在这里重写一份:

侧重点: LEO + TRANS + "UE 已知 GNSS"

每个步骤的写法:

  • 问题是什么
    • 跟地面网络差别在哪?
    • 为什么不能直接复用地面网络的机制?
  • NTN 准备如何解决（方法论）
  • NTN 实际如何解决（方法科普）
Warning

这一部分 非常 非常 非常 重要!

甚至可以毫不夸张的说: 看完这一部分, 后面的 Sec 7 + 8 应该可以轻松过~

预备知识 1: 为什么上行信号要"对表"

(1) 5G 的上行是集中调度的时分复用，不像 Wi-Fi 那样谁空闲谁发:

时间被切成等长的时隙（slot）, 由 gNB 规定每个 UE 在哪个时隙、哪段频率上发送

gNB 同时接收很多 UE 的信号，要求它们都恰好在时隙边界到达

如果某个 UE 的信号晚到，就会拖进下一个时隙，和别人的信号叠在一起，谁都解不出来

Tip

可以类比成一条共享总线上的 TDMA:

接收端按固定节拍取数据，发送端离得越远，就必须越早发

(2) 容错空间非常小, 因此会有 CP 这个设计:

每个符号前面有一小段保护间隔，叫循环前缀（CP）

到达时间的偏差只要落在 CP 以内就能容忍

普通数据符号的 CP 只有约 4.7 微秒

(3) TA（Timing Advance，定时提前） 就是 UE 需要提前发送的时间量

它等于往返时延，而不是单程时延，原因:

  • UE 没有独立的时间基准!
    • UE 的"时钟"是从 gNB 的下行信号里恢复出来的
  • 下行信号到达 UE 时已经晚了一个单程时延 d，所以:
    • UE 认为的 "0 时刻"，实际是 gNB 的 d 时刻
  • UE 按自己的钟发出的信号，还要再走 d 才能到 gNB，前后一共晚了 2d

所以: TA ≈ 2d = RTT

预备知识 2: 随机接入（RACH）是什么

UE 刚开机时，网络还不认识它，没有给它分配任何资源或地址，它只能靠"抢"来发出第一条消息

这个过程叫随机接入，形式上很像 TCP 握手加上 slotted ALOHA 的冲突处理，一共四步:

  • Msg1：发送前导码（preamble）
    • 前导码不是带头部的数据包，而是一段事先约定好的特殊波形
      • gNB 靠模式匹配就能认出它，还能测出它到达的精确时刻
    • UE 从 64 种前导码里随机挑一个发出去，相当于"敲门"
    • 允许敲门的时间点是周期性的固定时隙，叫 RO（RACH Occasion）
  • Msg2：随机接入响应（RAR）
    • gNB 回复"我听到了第 X 号前导码"，同时下发三样东西:
      • 该 UE 应该使用的 TA
      • 下一步发送要用的上行资源，叫授权（grant）
      • 一个临时 ID，类似 DHCP 临时分配的地址
  • Msg3：连接请求
    • UE 用分到的资源发送连接请求，里面带着自己的身份标识
  • Msg4：竞争解决
    • 如果两个 UE 恰好挑了同一个前导码，它们会收到同一个 RAR，并在同一块资源上发 Msg3
      • 而: gNB 最多只能解出其中一个
    • Msg4 会回显 gNB 解出的那个身份标识:
      • 回显的是谁，谁就赢了
      • 另一个 UE 重新来过

地面网络中的 TA 是在 Msg1 这一步由 gNB 测出来的:

  • UE 不做任何补偿，直接发前导码
  • gNB 看它比 RO 起点晚了多少，就得到了这个 UE 的 RTT
  • 再通过 Msg2 告诉 UE

后面 NTN 的所有改动, 都是因为上述做法在 LEO 下失效了

TLDR: RACH 分成四步

alt text

  • Step 1: Initial TA Estimation
    • UE Timing Advance Estimation and Application
  • Step 2: TA Correction
    • Timing Advance Correction via Msg2
  • Step 3: Scheduling with Uncertainty
    • Scheduling of Msg3
  • Step 4: Final Synchronization

第 1 步: 接入前的准备

(1) 问题

时延问题: 地面 UE 不需要知道自己离基站多远，因为网络会在 Msg1 时替它测出来

LEO 下这个测量做不了（原因见第 2 步），所以 UE 必须在第一次发送之前，就自己知道该用多大的 TA

频率问题: 卫星以约 7.56 km/s 的速度运动，信号会产生多普勒频移

  • 在 2 GHz 频段、600 km 轨道下，频偏最高约 48 kHz
  • 5G 信号由许多间隔 15 或 30 kHz 的子载波并排组成
    • 48 kHz 的频偏相当于整体错开了一两个子载波，gNB 按标准频率去解调，完全对不上
  • 地面 UE 移动慢，多普勒小到可以忽略，所以地面网络没有这个问题

(2) 思路

卫星轨道可以精确预测。只要 UE 知道自己在哪、卫星在哪，就能直接算出两者的距离（得到时延）和相对速度（得到频偏），不需要测量

因此，不用 ping，直接根据基于几何坐标算出 RTT

(3) 实际做法

[3.1] 两端的位置从哪来

  • UE 的位置: 来自 GNSS（GPS、北斗等）
    • 这正是 Rel-17 强制要求 NTN 终端必须具备 GNSS 的原因
  • 卫星的位置: gNB 在广播消息 SIB19 里下发星历
    • SIB 是基站周期性广播的系统信息，相当于 beacon("信标")，UE 不需要建立连接就能收到
      • SIB19 是专门为 NTN 新增的一块
    • 星历就是卫星的轨道参数，作用类似 TLE，并附带一个参考时刻（epochTime）
      • UE 据此可以 "外推" 出: 卫星在任意时刻的位置和速度

[3.2] 时延分两段计算

透明载荷下，信号的路径是 UE → 卫星 → GW → gNB，时延可以拆成两段:

路段 特点 由谁计算 名称
service link (UE↔Sat) 每个 UE 位置不同，时延也不同; 单程约 2 ms（卫星在头顶）到 6.4 ms（卫星在低仰角） UE 自己算 UE-specific TA
feeder link (Sat↔gNB) 同一颗卫星下的所有 UE 都一样 (都是同一个sat-gNB链路); UE 不知道网关在哪，且网关还会切换 网络算好后在 SIB19 广播 Common TA

两段相加就是:

TA 总量 = UE-specific TA + Common TA

LEO 600 km 透明架构下，这个值最大约 26 ms

严格来说

Common TA 描述的是卫星到某个 "参考点"(Reference Point, RP) 的时延

这个参考点不一定在 gNB!

此时网络会再用一个叫 K_mac 的参数补上差值

理解主线时, 把参考点当作 gNB 就行. 不用纠结!

[3.3] 频偏:

UE 根据 卫星相对自己的速度 算出多普勒频移，发送时主动把频率反向调好，让信号到达卫星时正好落在标准频率上

这叫: 频率预补偿

两个配套设计
  • 漂移率:
    • 卫星和网关之间的距离也在变化，所以 Common TA 会随时间改变
    • SIB19 除了给出当前值，还给出它的变化率
    • UE 可以在两次读取广播之间自行外推，不必频繁重读
  • 有效期:
    • 外推的误差会随时间累积，所以这些信息有"有效期"
    • UE 用定时器 T430 来计时:
      • 一旦过期，UE 就认为自己"上行失步": 必须停止发送，重新读取 SIB19
      • 可以类比缓存的 TTL
Danger

这也就是为什么:

alt text

Msg1 开始之前, 叫做 UE estimates and applies TA

第 2 步: Msg1 - 发送前导码

(1) 问题

地面的做法是 UE 不做补偿直接发送，由 gNB 测量到达时间

这个方法能成立，依赖两个前提：

  1. 同一个 RO 里，远近不同的 UE 的前导码到达时间差，不超过前导码的 CP
    1. 前导码的 CP 比数据符号长得多，常用的格式约 0.1 ms
    2. 对应的地面小区半径上限约 15 km
  2. 这个到达时间差远小于相邻 RO 之间的间隔
    1. 否则 gNB 分不清某个前导码属于哪个 RO

在 LEO 下，这两个前提都不成立：

  • 绝对时延太大
    • RTT 高达约 26 ms，前导码可能迟到好几个 RO 周期
    • gNB 会把它当成后面某个 RO 发来的，从而算出错误的 TA
  • 时延差也太大
    • 即使 gNB 知道大家整体都晚了约 26 ms，一个 LEO 小区的尺寸动辄几十到几百公里
      • 小区内不同位置的 RTT 差仍在毫秒级
    • 例如 200 km 的小区约为 1.3 ms，是 0.1 ms CP 的十几倍，前导码依然检测不出来
    • 这个时延差大约等于 2 × 小区直径 / 光速，主要由小区大小决定

(2) 思路

把"测量时延"的责任从网络转移给 UE

UE 在第 1 步已经算出了自己的 TA，发送前导码时就直接提前这么多

这样无论 UE 位于小区的哪个位置，它的前导码到达 gNB 时都应该正好对齐 RO 边界

(3) 实际做法

  • UE: 按 TA 总量提前发送，频率也已经做过预补偿
    • 前导码本身的格式和地面网络完全相同
  • gNB:
    • 沿用地面的检测方法，测量前导码比 RO 边界早或晚了多少

这个测出来的偏差就是残差 (\(T_{Scheduled} \minus T_{UE to gNB arrival}\)):

  • UE 自己的估算不可能完全准确:
    • GNSS 定位有误差，星历外推也有误差
    • 补偿之后剩下的那一点偏差，就叫残差
  • 残差远小于 CP，所以地面的前导码格式和检测方法可以直接复用
  • 类比:
    • UE 靠 GPS 完成粗同步，gNB 负责最后的精细校准
这一步带来根本变化
  • 在 TN 里，gNB 从前导码中测到的是 UE 的完整 RTT
  • 在 NTN 下，gNB 只能测到残差，UE 的完整时延它再也看不到了

这个副作用在第 4 步处理，这里先埋下伏笔

为什么 gNB 只能测到残差

因为 gNB 无法知道前导码是什么时候发出的，它只能看到前导码比约定时刻晚到了多少

在 LEO 下，UE 已经按自己算出的时延提前发送了，这个"晚到多少"里就只剩 UE 没算准的那一点。

UE 到底提前了多少，前导码里没有写，gNB 也算不出来

(1) gNB 实际能测的是什么

前导码只是一段约定好的波形，没有包头，也没有发送时间戳

gNB 手里只有两个信息:

  • 这个 RO（允许发前导码的时刻）本该从哪一刻开始，这是 gNB 自己定的
    • 即: 前文提到的 $\(T_{Scheduled}\)
  • 前导码实际在哪一刻到达

(2) LEO: 每个 UE 私下提前了不同的量

假设同一小区里有两个 UE。网络广播的 Common TA 为 8 ms，两个 UE 的估算都比真实值短了 0.01 ms：

UE-A（离卫星近） UE-B（离卫星远）
真实往返时延 18.00 ms 19.20 ms
UE 自己算出并提前的量 17.99 ms 19.19 ms
gNB 测到的值 0.01 ms 0.01 ms

两个 UE 的真实时延差了 1.2 ms，但在 gNB 看来完全一样，都是"晚到 0.01 ms"

时延的大头在发送前已经被 UE 自己的提前量抵消掉了，gNB 从到达时刻上看不出任何痕迹

Tip

这就像会议约定 9:00 开始，每个人根据自己的路程提前出发

主持人只能看到谁准点、谁晚到一分钟，看不出张三路上走了一小时还是十分钟

(3) 更准确地说，看不到的是哪一部分

TA 由两部分组成:

  • Common TA（馈电链路部分）
    • 这是 gNB 自己在 SIB19 里广播的，它自己当然知道
  • UE-specific TA（服务链路部分）
    • 由 UE 的位置决定，gNB 不知道

所以准确的说法是: gNB 看不到每个 UE -> Sat 的那段时延

(4) 所以才需要 TA Report

详见第 4 步

既然 gNB 测不出来，就只能让 UE 主动上报!

UE 在 Msg3 里附带 TA Report, 告诉 gNB "我提前了 X".

这样 gNB 就能恢复完整时延:

完整时延 = 上报的提前量 X + 测到的残差

Msg3 是正常的数据传输，有载荷空间，所以能放下这个数值。前导码则放不下

第 3 步: Msg2 - 等待 RAR

(1) 问题

地面上:

UE 发完 Msg1 后，会立即打开一个接收窗口（ra-ResponseWindow）等待 RAR，窗口最长 10 ms

这是因为地面的 RTT 不到 1 ms，回复几乎马上就到

在 LEO 下:

RAR 最早也要经过一个 RTT（约 26 ms）才能到达

如果照搬地面做法，窗口在回复到来之前就关闭了，UE 会误以为接入失败

为什么不直接把窗口拉长:

窗口打开期间，UE 必须一直开着接收机，在每个时隙里去检测下行控制信道（PDCCH，gNB 用来下发调度信息的信道），看有没有发给自己的消息

这相当于忙轮询（busy polling），非常耗电

而前 26 ms 内回复在物理上根本不可能到达，这段时间的监听纯属浪费

(2) 思路

UE 已经知道自己的 RTT（就是它的 TA），真正不确定的只有残差

所以窗口不需要加宽，只要整体往后平移一个 RTT 就够了

(3) 实际做法

  • UE:
    • 发完 Msg1 后, 先等待一段"UE 到 gNB 的 RTT 估计值" (约等于它 当前的 TA 总量)
    • 然后再打开正常长度的接收窗口
  • gNB:
    • 回复的 RAR 内容和地面网络一样
    • 其中的 TA command 在 LEO 下, 只用来修正第 2 步测到的残差, 因此数值很小
    • 这个来自 gNB 的残差, 也叫做修正量
  • UE:
    • 收到 RAR 后，把这个修正量叠加到自己的 TA 上
Danger

这也就是为什么:

alt text

Msg2 结束, 叫做 correction of TA

第 4 步: Msg3 - 发送连接请求

(1) 问题

Problem 1: 因果性被破坏

5G 上行授权的时间规则是：gNB 在下行第 n 个时隙发出授权，要求 UE 在上行第 n+K 个时隙发送。这里的 K 是一个很小的固定偏移，只有几个时隙（1 个时隙 = 1 ms）。UE 实际发送的时刻，还要比这个时隙再提前 TA。

  • 地面网络:
    • TA 最多约 2 ms，而 K 有好几毫秒，所以 UE 收到授权后还有时间准备发送
    • 时序没问题
  • LEO: TA 约 26 ms，远大于 K
    • 例如 K = 4 ms、TA = 26 ms 时，UE 需要在 n + 4 − 26 = n − 22 ms 发送
    • 也就是说: UE 得在收到授权的 22 ms 之前就开始发, 而这是不可能的!!!

Problem 2: 网络看不到 UE 的真实时延

经过第 2 步，gNB 只知道每个 UE 的残差，不知道完整时延。但网络在很多地方需要这个信息。例如下面要介绍的 Koffset 是按小区里最坏的情况设置的，对离卫星近的 UE 来说过于保守，会白白增加调度时延。

(2) 思路

  • 解决因果性 (Problem 1):
    • 给所有 "收到授权 → 上行发送" 的时间关系，统一加上一个足够大的偏移
    • 以保证: UE 一定是先收到授权、再发送
    • 上面那个 n + 4 − 26 就是个很直观的例子
  • 解决信息缺失 (Problem 2):
    • 网络测不到，就让 UE 主动上报

(3) 实际做法

采用 Koffset:

  • SIB19 广播一个小区级偏移 cellSpecificKoffset
    • 它的取值不小于 小区内可能出现的最大 TA
  • 之后所有上行调度时刻都变为 n + K + Koffset
    • 沿用上面的例子: 取 Koffset = 30 ms
    • 发送时刻 = n + 4 + 30 − 26 = n + 8 ms
    • 使得: 发生在收到授权之后, 因果性恢复
  • 这条规则不只作用于 Msg3
    • 连接建立之后，所有上行调度和反馈的时间关系都要加上 Koffset

采用 TA 上报:

  • 如果网络开启了该功能:
    • UE 会在 Msg3 里附带一条 TA Report MAC CE，把自己当前使用的 TA 告诉 gNB
    • MAC CE 是 MAC 层的控制字段，可以理解为夹带在数据里的一小段控制信息
  • 网络由此重新获得这个 UE 的完整时延:
    • 完整时延 = UE 上报的提前量 + 第 2 步测到的残差
  • 进入连接态后:
    • gNB 可以给这个 UE 单独下发一个更小的 Koffset，减少不必要的等待
    • 当然, 这属于后续优化了, 跟主线没关系
Danger

这也就是为什么:

alt text

Msg3 结束, 叫做 Network receives the UE-specific full TA

第 5 步: Msg4 - 等待竞争解决

(1) 问题

地面上: UE 发完 Msg3 后，会立即启动竞争解决定时器，在定时器运行期间等待 Msg4，超时就判定失败

在 LEO 下: Msg4 同样至少要经过一个 RTT 才能到达，这会让 UE 陷入两难:

  • 如果定时器按地面的值配置，前 26 ms 会被 RTT 白白耗掉，容易被误判为超时
  • 如果把定时器配得很长，UE 又要长时间忙轮询，耗电严重

(2) 思路

和上面第 3 步完全相同: 不拉长，而是平移!

(3) 实际做法

UE 发完 Msg3 后，先等待一个 RTT 估计值，再启动定时器，定时器的长度保持正常值

收到 Msg4 后，UE 核对其中回显的身份标识，如果一致，就表示接入成功，进入连接态

第 6 步: 连接后保持上行同步

(1) 问题

地面 UE 移动缓慢，TA 变化也慢，gNB 偶尔下发一条 TA 调整命令就能跟上，这是一种闭环控制

LEO 卫星始终在高速运动，时延的变化率最高约 ±93 微秒/秒。而数据符号的 CP 只有约 4.7 微秒，不到 0.1 秒累积的偏差就会超出容忍范围

如果完全依赖 gNB 下发命令来追踪:

  • 命令必须发得非常频繁，信令开销很大
  • 每条命令本身还要经过一个 RTT 才能生效，天然滞后，根本跟不上

(2) 思路

可预测的大部分变化由 UE 开环自行跟踪，不可预测的小误差交给网络闭环修正

这和接入阶段的分工是一致的

(3) 实际做法

  • UE:
    • 持续用 GNSS 和星历重新计算 UE-specific TA 和频率预补偿
    • 用 SIB19 给出的漂移率外推 Common TA
    • 同时监视 T430，有效期一到就停止上行发送，重新读取 SIB19
  • gNB:
    • 照常用 TA command 修正残差. 下发告诉 UE "修正量"

总结 RACH: TN 与 NTN

alt text

地面网络 LEO NTN
时延信息从哪来 gNB 在 Msg1 测出 UE 用 GNSS + 星历自算 UE-specific TA (服务链路); 网络广播 Common TA (馈电链路部分)
gNB 从前导码测到什么 完整 RTT 只有残差
何时开始等回复 发完立即开窗、立即启动定时器 先等一个 RTT，再开窗、再启动定时器
上行调度时刻 n + K n + K + Koffset
网络如何得知 UE 时延 自己测出 UE 主动上报（TA Report）
连接后如何保持同步 gNB 闭环命令 UE 开环自算为主，gNB 闭环修正残差
常见错误原因

官网里的这部分总结归纳还挺好的

建议熟悉一下这些常见 error 的类型, 自己推测一下原因。然后再对照它的答案

个人认为: 很有利于巩固对上述 Msg1-4 全过程交互的理解

alt text

Sec 7: NTN TA - Timing Synchronization

Tip

在深刻理解完上述 Sec 6 后, 本章应该易如反掌.

笔者在这里采用 "Go Through" + "Philosophy rather than Techniques" 的方式展开本章的撰写.

每个步骤的写法:

  • 问题是什么
    • 跟地面网络差别在哪?
    • 为什么不能直接复用地面网络的机制?
  • NTN 准备如何解决（方法论）
  • NTN 实际如何解决（方法科普）

预备知识: LEO 的时延难在哪

(1) TA 回顾 (详见 Sec 6 预备知识 1):

  • 5G 上行是集中调度的时分复用: gNB 要求所有 UE 的信号恰好在时隙边界到达
  • 容错空间只有一个 CP（循环前缀），普通数据符号的 CP 约 4.7 微秒
  • 所以 UE 要提前发送，提前量叫 TA: TA ≈ RTT

(2) "时延"其实是三个问题，后面每个机制都对应其中一个:

子问题 LEO 600 km 的表现 对应机制
绝对时延大 透明载荷 RTT 最大 25.77 ms，全小区基本共有 Common TA、K_offset、K_mac、关闭 HARQ 反馈
每个 UE 不同 同一小区内 RTT 差最大 3.12 ms，约 660 个 CP UE 自己算的 UE-specific TA, 这正是 GNSS 必须有的原因
时延一直在变 RTT 变化率最高 ±93 µs/s, UE 不动也一样 广播 Common TA 的变化率，并设有效期

(3) 一次过境的真实数字:

原文举的例子是: 550 km 轨道、约 2.2 GHz 载波，卫星几乎从头顶飞过

  • 可见时长: 约 12 分钟，仰角从 0° 升到接近 90° 再降回 0°
  • 距离与时延: UE 到卫星的距离从 2,704 km 降到 552 km 再升回去
    • service link RTT 相应从约 18 ms 降到 3.7 ms 再升回去
    • 同一颗卫星、同一条链路，6 分钟内 RTT 变化约 14 ms
  • 多普勒频偏: 卫星接近时约 +51 kHz，在头顶时为 0，远离时约 −51 kHz

TLDR: TA 的完整生命周期

  • 第 1 步: 网络侧定好参考点（RP），决定时延怎么切分
  • 第 2 步: gNB 广播 SIB19，把会变的时延作为"轨迹"下发
  • 第 3 步: UE 本地计算 TA 和频率预补偿
  • 第 4 步: 随机接入，网络修正残差并拿回绝对时延
  • 第 5 步: 调度，K_offset 与 K_mac
  • 第 6 步: 数据传输，HARQ
  • 第 7 步: 连接态，持续跟踪时延
  • 第 8 步: 换星，提前准备下一颗卫星的参数
贯穿全节的分工原则
  • 大而可预测的时延和频偏: UE 开环自算
  • 剩下的小残差: gNB 沿用地面网络的闭环机制修正
  • 大时延带来的时序问题: 把时间关系整体往后平移

第 1 步: 网络侧定好"参考点", 决定时延怎么切分

(1) 问题

地面网络只有 UE 和 gNB 两个端点，TA 由 gNB 直接测出来，不存在"切分"问题

LEO 透明载荷下，信号路径是 UE → Sat → GW → gNB，由此带来两个麻烦:

  • UE 能算出自己到卫星的距离，但==不知道 GW 在哪、feeder link 怎么走==，没法自己算出全程时延
  • 不同部署方式下（TRANS/REGEN、gNB 与 GW 是否同址），"UE 该补偿到哪里为止"各不相同
    • 如果每种架构各写一套规则，规范会很乱

(2) 思路

在路径上定义一个位置可调的 参考点（Reference Point, RP），以它为界把总时延切成两段:

  • UE 负责自己能算的那段
  • 其余部分由网络负责，并告知 UE
Tip

可以类比为: 把端到端 RTT 拆成"接入段"和"骨干段"

客户端自己测接入段，运营商公布骨干段

(3) 实际做法

  • RP 不是设备，只是一个时间上的定义
    • 在这个点上，上行帧和下行帧的时间是对齐的
    • 那个位置没有任何硬件
  • UE 从不被告知 RP 在哪
    • 它只收到 Common TA，即 RP 到卫星的往返时延
    • RP 的位置，反过来由这个数值隐含确定
  • UE 负责的永远只有 service link（UE↔Sat），卫星另一侧的所有时延都由网络告知
部署方式 RP 位置 Common TA UE 使用的 TA 总量（最坏情况）
600 km 透明，gNB 与 GW 同址 GW / gNB feeder link RTT，12.89 ms 12.89 + 12.89 = 25.77 ms
600 km 再生（gNB 在星上） 卫星 0（该字段可以不发） 12.89 ms
补充
  • gNB 与 GW 不同址时（例如一个 gNB 经地面网络连接多个 GW）:
    • RP 到 gNB 之间还有一段纯地面时延，用参数 K_mac 表示（见第 5 步）
    • 同址时 K_mac = 0
  • 移动 RP 不会让时延消失，只是在 UE 和网络之间重新分配工作
    • 再生载荷下 feeder link 依然存在，只是被移到了 UE 的时间计算 之外，由网络自己处理

第 2 步: gNB 广播 SIB19, 把会变的时延作为"轨迹"下发

(1) 问题

地面网络不需要广播任何时延信息

LEO 下网络必须告诉全小区两样东西:

  • 卫星在哪: UE 算 service link 时延要用
  • Common TA: UE 算 TA 总量要用

难点是: 这两样都在持续变化

  • 卫星每秒飞 7.56 km，Common TA 也随之改变，单个数值一两秒就过时了
  • 而 SIB 是周期性广播的，不可能每个时隙都发一次

(2) 思路

不发某一时刻的"采样值"，而是发 一条可以外推的轨迹:

  • 当前值、变化率、变化率的变化率
  • 再加上一个时间戳和一个有效期

原理很简单:

alt text

Tip

类比 NTP: 同时给出时钟偏差和频率漂移，接收方在两次同步之间自己推算

有效期则相当于 TTL

(3) 实际做法

[3.1] SIB19 中与时延相关的字段

字段 含义 要点
ephemerisInfo 卫星星历 位置和速度向量 / TLE
ta-Common Common TA 的常数项 参考时刻的值 (\(f(t_1)\))
ta-CommonDrift 一阶项: 每秒变化多少 带正负号，因为卫星可能在接近或远离；范围约 ±51.5 µs/s (\(f'(t_1)\))
ta-CommonDriftVariant 二阶项: 变化率本身的变化 保证外推在整次过境期间都够准 (\(f''(t_1)\))
epochTime 上述所有值对应的参考时刻 多项式和星历外推的时间原点 (\(t_1\))
ntn-UlSyncValidityDuration 有效期 可选 5 s 到 900 s，LEO 通常取短值

[3.2] 怎么用

UE 以 epochTime 为起点，把常数项、一阶项和二阶项组成的二阶多项式代入经过的时间，就能算出任意时刻的 Common TA

星历也同样从 epochTime 开始外推

有效期是安全锁，不是性能参数

过期后，UE 不能再认为自己处于上行同步状态

必须停止发送，重新获取 SIB19

第 3 步: UE 本地计算 TA 和频率预补偿

(1) 问题

时延方面:

  • 地面 UE 的 TA 由网络从前导码测出，再用 RAR 里的 TA 命令告诉 UE
  • LEO 下这条路走不通:
    • 一是前导码不做预补偿就检测不到（见 Sec 6）
    • 二是 RAR 里的 TA 命令只有 12 比特，在 15 kHz 子载波间隔下最大只能表示约 2 ms，装不下 25.77 ms

频率方面:

  • 地面网络的相对运动来自 UE 自己
    • 高铁时速 500 km 也只有约 0.46 ppm（2 GHz 下约 930 Hz）
    • 这种运动网络无法预测，只能靠接收机闭环跟踪
  • LEO 卫星一开始就带着 24 ppm（约 48 kHz）的频偏
    • 是 15 kHz 子载波间隔的三倍多，而常规同步算法能纠正的范围只有几 kHz

(2) 思路

大而可预测的部分由 UE 开环自算，小残差留给原有的闭环机制

  • 卫星轨迹是已知的，所以时延和频偏的大部分，都能由 UE 根据"我在哪、卫星在哪"直接算出
  • 网络只修正剩下的小误差

这样 TA 命令的字段不用加宽，地面网络的信令格式可以原样复用

(3) 实际做法

[3.1] TA 公式（TS 38.213）

\[T_{TA} = (N_{TA} + N_{TA,offset} + N_{TA,adj^{common}} + N_{TA,adj^{UE}}) \times T_c\]

其中 Tc 是 NR 的基本时间单位，约 0.509 纳秒

项 谁决定 覆盖什么 地面 NR 是否有
N_TA 网络，通过 RAR 和 TA 命令下发 闭环残差，即 UE 自己没算准的部分 有
N_TA,offset 按频段固定 收发切换的时间余量，与距离无关 有
N_TA,adj^common 网络定义，UE 用 SIB19 的多项式外推 RP 到卫星，全小区共有 NTN 新增 (common TA)
N_TA,adj^UE UE 自己，用 GNSS 和星历计算 UE 到卫星，每个 UE 各不相同 NTN 新增 (UE-specific TA)
  • 公式中的 TA command 属于 MAC CE, 即 MAC 层的带内控制消息
  • NTN 对 TA 的全部改动就是后两项，前两项的机制原封不动

[3.2] 频率预补偿

  • UE 负责 service link:
    • UE 算出自己与卫星的相对速度 v，按 "频偏 = v / c × 载频" 得到 service link 的多普勒频移
    • 发送上行信号时, 反向调整频率
  • 网络负责 feeder link:
    • feeder link 的多普勒和卫星转发器的频率误差由网络处理
    • 因为 UE 既不知道 GW 位置，也不知道星上振荡器的状态
  • 分工与时延一致: UE 管 service link，网络管卫星另一侧

第 4 步: 随机接入, 网络修正残差并拿回绝对时延

这一步的细节见 Sec 6，这里只从 TA 的角度看每个阶段"谁知道什么"

(1) 问题

UE 做了预补偿之后，gNB 从前导码里只能测到残差，看不到 UE 的完整时延

但网络做调度时需要这个值

(2) 思路

网络测不到，就让 UE 主动上报

(3) 实际做法

  • Msg1: UE 按 TA 总量提前发送
    • 此时只有 UE 知道自己的 TA，而且只是近似值
  • Msg2: gNB 用 TA command 修正残差
    • 但仍不知道 UE 的 TA 绝对值
  • Msg3: UE 上报之前，网络只能按小区内的最坏情况来调度
    • 如果开启了 ta-Report:
      • UE 会在 Msg3 里上报自己实际使用的 TA，从此双方掌握同一个值
      • After UE 最开始的近似值 + gNB 残差修正, 这个 TA 就是真实的了

第 5 步: 调度, K_offset 与 K_mac

(1) 问题

[1.1] K_offset 要解决的是: 因果性问题

  • 地面规则是: gNB 在第 n 个时隙发出授权，UE 在第 n+K 个时隙发送，实际发送时刻再提前 TA
    • 地面的 TA 远小于一个时隙，所以没有问题:
      • n+K-TA > n. 时序没问题
  • LEO 下 TA 约 26 ms:
    • 按 UE 提前后的时间轴，"第 n+K 个时隙"可能早于 UE 收到授权的时刻
    • n+K-TA < n. 出现时序问题!!!
    • 等于是在要求 UE 在收到命令之前就执行命令

[1.2] K_mac 要解决的是: 生效时刻的歧义问题

  • 当 RP 不在 gNB 时，gNB 自己的上行时间轴和下行时间轴会错开一段
  • 这时像 "MAC CE 在第几个时隙生效" 这样的规则，就说不清以哪条时间轴为准

(2) 思路

给所有"下行命令 → 上行动作"的时间关系统一加上足够大的偏移: 保证命令先到达、动作后执行

Tip

类比: 流水线里下发"在 T 时刻执行"的指令，T 必须晚于"当前时刻 + 指令传输时间"

(3) 实际做法

[3.1] K_offset（cellSpecificKoffset）

项目 内容
单位与范围 以 15 kHz 子载波间隔的时隙为单位，1 个时隙 = 1 ms，取值 1 到 1023
下限 不小于"service link RTT + Common TA"，即 UE 的最大 TA。600 km 透明载荷至少需要 26 个时隙
  • K_offset 是小区级参数
    • 它只能按波束边缘(最坏情况)的 UE 来设置
    • 因此: 对波束中心的 UE 来说过于保守
  • 网络通过 ta-Report 得知某个 UE 的真实时延后，可以单独给它下发一个更小的 UE 级 K_offset
    • 这属于后续优化，我们这里聚焦主线，就不展开了

[3.2] K_mac

项目 内容
含义 约等于 RP 到 gNB 的往返时延
何时需要 只在 gNB 处上下行帧时间不对齐（即 RP 不在 gNB）时下发；不下发时 UE 按 0 处理
作用对象 MAC CE 动作的生效时刻，以及 RAR / MsgB 接收窗口的起点
常见取值 TRANS 且 gNB 与 GW 同址时为 0; 再生载荷的 gNB 就在 RP 上，也为 0

第 6 步: 数据传输, HARQ

(1) 问题

[1.1] HARQ 是什么

物理层之上的快速重传机制，可以理解为: 带"软合并"（把多次收到的出错副本合起来解码）的链路层 ARQ

  • 每个 HARQ 进程是一个停等（stop-and-wait）通道
    • 发出一个数据块后，必须等 ACK/NACK 回来才能再用这个进程
  • 多个进程并行工作，相当于一个大小为 N 的滑动窗口
  • 要让数据流不断档，必须满足: 进程数 × 时隙长度 ≥ HARQ 往返时间

[1.2] 为什么是"进程数 × 时隙长度 ≥ HARQ 往返时间"

  • N: 进程数
  • R: HARQ 往返，单位是时隙
    • 从数据发出到 gNB 拿到反馈、可以复用该进程所经过的时隙数

简化为: 只看一个 UE，gNB 每个时隙给它发一块数据

  • 时隙 0 到 N−1: P1 到 PN 依次发出，全部进入等待
  • 时隙 N: 需要一个空闲进程，而最早空出的 P1 要到时隙 R 才可用
    • N ≥ R: P1 已空出，数据流不断档
    • N < R: 每 R 个时隙中有 R−N 个无进程可用，只能空等，模式以 R 为周期重复

结论: 该 UE 的时隙利用率 = min(1, N/R)

例如 N = 4、R = 6 时，每 6 个时隙里 4 个在发、2 个空等，利用率约 67%:

alt text

例如 N = 16、R = 26 时:

alt text

例如 N = 32、R = 26 时:

alt text

这下应该很好理解 进程数 × 时隙长度 ≥ HARQ 往返时间 了🚀

Tip

窗口不够用时发送方只能空等, 这和 TCP 在窗口受限时吞吐上不去 是同一个道理

(2) 思路

有两条路:

  • 把窗口开大:
    • 增加进程数 (16 -> 32 -> ...)
  • 窗口仍不够时，干脆不等反馈:
    • 关闭反馈后进程发完立即可复用，相当于 R 变成了 0
    • 可靠性交给更上层

(3) 实际做法

  • 扩大窗口: Rel-17 把下行 HARQ 进程数上限从 16 提高到 32
    • 同时扩展了下行数据到 HARQ 反馈之间允许的时间间隔
  • 下行不等反馈: 可以按进程关闭 HARQ 反馈，进程发完立即可复用
    • 丢失的数据改由 RLC AM 重传
    • RLC AM 是更上层的可靠传输机制，相当于"关掉链路层 ARQ，靠上层重传"
  • 上行: 定义了 HARQ mode A 和 mode B，可按进程配置
    • mode B 允许在上一次传输的 RTT 还没过完时，就再次调度同一个进程
反馈开启 反馈关闭
进程复用 等 ACK/NACK 回来才能复用 立即复用
丢包由谁恢复 HARQ，速度快，还有软合并 RLC AM，速度慢，没有软合并
调制编码 可以激进，首次传输出错的代价小 必须保守，或者直接盲目重复发送
适用场景 RTT 较短的场景（LEO，尤其是再生载荷） RTT 较长、吞吐优先的场景
Warning

关闭反馈并不会让链路更可靠! 只是把可靠性交给了更慢的上层环路，代价要付两次:

  • 调制编码必须更保守
  • 一旦出错，恢复时延更长

所以规范把选择权留给网络，按进程配置

第 7 步: 连接态, 持续跟踪时延

(1) 问题

地面 UE 的 TA 变化很慢，gNB 偶尔下发一条 TA 命令就能跟上

LEO 下 RTT 变化率最高达 ±93 µs/s，而数据符号的 CP 只有 4.7 µs:

不到 0.1 秒累积的偏差，就会超出容忍范围

(2) 思路

与第 3 步相同:

大部分变化由 UE 开环跟踪，残差由网络闭环修正，再用有效期兜底

这样一来，大部分工作都是 双方各自在本地计算. 不需要逐次交互，只保留少量单向、按需触发的信令!!!

本地计算为什么能保持一致?
  • 输入和公式相同:
    • 开环部分用的是同一份广播参数（SIB19）和同一套公式
    • UE 自己算就行，不需要每次和 gNB 核对
  • gNB 不需要知道 UE 此刻算出的具体值:
    • 它只看结果，也就是 UE 的上行信号到达得准不准
  • 到达时刻可以顺便测:
    • gNB 从 UE 正常发送的上行数据和参考信号里就能测出到达时刻，不需要额外信令

(3) 实际做法

[3.1] 哪些本地做、哪些要信令

动作 在哪里做 是否需要信令
重算 UE-specific TA、频率预补偿 UE 本地 不需要，输入是 GNSS 和已收到的星历
外推 Common TA UE 本地 不需要逐次信令，多项式系数来自已收到的 SIB19
刷新星历和 Common TA 系数 网络广播，UE 接收 广播，单向，不针对某个 UE；有效期到之前 UE 要主动去读
测量上行到达时刻的偏差 gNB 本地 不需要，利用 UE 正常的上行传输来测
修正残差 gNB → UE (偏差变大时) 需要: TA 命令 MAC CE，夹带在下行数据里，UE 不用专门回复
上报 TA 的变化 UE → gNB 可选: 网络配置门限（offsetThresholdTA）后，UE 的 TA 变化超过门限就发一次 TA Report
下发 UE 级 K_offset gNB → UE (偏差变大时) 偶尔: MAC CE

[3.2] 两个环

alt text

大头交给开环，闭环只负责残差，所以信令量和地面网络差不多

[3.3] 两个"保鲜"定时器，各管一边

  • timeAlignmentTimer（地面网络就有）: 管闭环部分的新鲜度
    • 每收到一条 TA 命令就重启
    • 超时后 UE 认为上行失步，需要重新随机接入
  • T430（NTN 新增）: 管开环输入的新鲜度，从 epochTime 开始计有效期
    • 到期前 UE 必须拿到新的 SIB19
    • 否则超时后必须停止上行发送，重新读取 SIB19
Danger

如果没及时刷新 SIB19，典型现象是: 连接能用几十秒，然后反复掉线

第 8 步: 换星, 提前准备下一颗卫星的参数

(1) 问题

  • LEO 一颗卫星只能服务一个区域几分钟
    • 换星意味着星历和 Common TA 全部改变，整套开环计算都要重来
  • 如果切换之后才去读新小区的 SIB19，会凭空多出一段中断
    • 而这次切换本可完全预知

(2) 思路

既然切换时刻可以预测，就提前把下一颗卫星的参数发给 UE，让 UE 在切换前就算好

(3) 实际做法

  • ntn-NeighCellConfigList: 在 SIB19 中广播邻区（即下一颗卫星）辅助信息
    • UE 可以对还没切过去的卫星预先算好时延
  • t-Service: 当前小区停止服务本区域的时刻，相当于准地面固定小区的"到期时间"
    • 它是按时间触发的计划性切换的依据，不必等信号变差再靠测量触发
Note

个人认为 ntn-NeighCellConfigList 和 t-Service 这两个参数非常重要!!!

总结: 谁负责什么

问题 UE 网络
service link 时延 用 GNSS 和星历实时计算（N_TA,adj^UE） —
feeder link 时延 按多项式外推 广播 Common TA 及其变化率
残差 叠加网络下发的调整量 本地测量到达偏差，下发闭环 TA 命令
service link 多普勒 上行预补偿 —
feeder link 多普勒、转发器频偏 — 自行处理
大 TA 导致的调度因果性 所有上行时序加上 K_offset 配置 K_offset；得知真实时延后可下发 UE 级 K_offset
HARQ 窗口不够 — 扩到 32 个进程，按进程关闭反馈
信息过期 有效期一到就停止发送 在有效期内刷新 SIB19
换星 提前算好目标卫星的参数 广播邻星信息和 t-Service

Sec 8: Frequency Compensation

前一节讲的是时间(信号晚到多久), 这一节是它在频率域的"孪生问题":

卫星运动太快，UE 收到的载频不等于网络发出的载频，网络收到的载频也不等于 UE 发出的载频

侧重点: LEO + TRANS + "UE 已知 GNSS"

本节和 Sec 7（TA）共用同一套几何计算和辅助信息，重叠的部分只简单带过

每个步骤的写法:

  • 问题是什么
    • 跟地面网络差别在哪?
    • 为什么不能直接复用地面网络的机制?
  • NTN 准备如何解决（方法论）
  • NTN 实际如何解决（方法科普）

预备知识: 为什么频率也要"对准"

(1) 5G 用的是 OFDM（正交频分复用）:

一个信号由许多很窄的子载波并排组成，相邻子载波的间隔叫 SCS（子载波间隔），常见的有 15 / 30 / 120 kHz

接收端按一张固定的频率网格，去取每个子载波上的数据

只有频率完全对准网格时，子载波之间才互不干扰，这叫"正交"

Tip

可以类比成一排紧挨着的信道:

每个信道只在自己的位置上取数，整排一旦错位，每个信道都会混进邻居的内容

(2) 频率没对准的后果:

  • 网格错位后，每个子载波的能量会泄漏到相邻子载波上，叫 ICI（子载波间干扰）
    • ICI 表现为一层噪声底，而且会和信号一起放大，所以加大发射功率也没用
  • 如果偏差达到一个 SCS 以上，接收端连信号在哪都对不上
和 Sec 7 完全对称

Sec 7: UE 没有独立的时间基准，"时钟"是 从下行信号里恢复 出来的

本节: UE 也没有独立的频率基准，"频率"同样是 从下行信号里恢复 出来的

(4) 多普勒频移的计算:

Text Only
1
f_d = (v_rel / c) × f_c
  • v_rel:
    • UE 与卫星沿视线方向的相对速度，不是卫星的轨道速度
  • f_c:
    • 载波频率
  • 同样的运动，载频越高，频偏越大（成正比）

TLDR: 频率补偿的完整流程

  • 第 1 步: 拆账，频率误差有四个来源，按"谁能知道"分给 UE 和网络
  • 第 2 步: 网络侧静默补偿 feeder link 和星上转发器的误差
  • 第 3 步: UE 开机找小区，为什么不能直接靠 AFC 跟踪
  • 第 4 步: UE 读 SIB19，算出 service link 多普勒
  • 第 5 步: UE 上行发送，做显式预补偿，而不是跟着下行走
  • 第 6 步: 连接态，残差只能靠 UE 自己的跟踪环
  • 第 7 步: 换星，提前算好下一颗卫星的多普勒
方法论

和 Sec 7 一样: 开环把误差拉进可处理的范围，闭环把它保持在范围内

不同的是: 频率上的闭环只在 UE 本地，网络没有任何纠正命令

第 1 步: 频率误差的四个来源

(1) 问题

地面网络: 频偏只有 UE 本振误差和 UE 自身运动两项，量级几百 Hz，UE 的 AFC 一把就吸收了，不需要任何分工

LEO 透明载荷下，信号要经过 UE ↔ Sat ↔ GW 两段链路，还要在星上变频一次:

所谓"多普勒"，其实是四个来源 (见下表) 的叠加，而且没有任何一方能看到全部

(2) 思路

和 Sec 7 的时延切分完全一样: 按"谁掌握计算所需的信息"来分账

(3) 实际做法

来源 在哪里产生 典型大小（LEO，S 频段） 谁来补偿 为什么是它
service link 多普勒 UE 与卫星的相对运动 最高约 48 kHz UE 只有 UE 知道自己的位置，卫星速度又通过星历广播给了它；波束内每个 UE 的值都略有不同
feeder link 多普勒 卫星与 GW 的相对运动 与 service link 同量级 网络 UE 不知道 GW 在哪、feeder link 怎么走、当前用的是哪个 GW，原理上就算不出来
星上转发器本振误差 卫星上负责变频的振荡器 取决于硬件实现 网络 这是载荷硬件的属性，UE 看不见，也无从得知
UE 本振误差 UE 自己振荡器的精度和漂移 约 0.1 ppm，2 GHz 下约 200 Hz UE 和地面网络一样，由 UE 的 AFC 锁到下行上解决
为什么这样分

UE 管 service link, 网络管卫星另一侧. 和 Sec 7 的时延分工一模一样

这不是巧合: UE 手里只有 GNSS 和广播星历，恰好够算 service link 的几何，别的都算不了

卫星另一侧的一切，无论时间还是频率，对 UE 都不可见

Tip

UE 本振那一项看起来可以忽略（200 Hz 对 48 kHz）

但把 service link 多普勒预补偿掉之后，它反而会成为主要残差之一（见第 6 步）

频率补偿真正的问题往往不是"能不能去掉多普勒"，而是"去掉之后还剩多少"

(1) 问题

地面网络没有 feeder link，也没有星上变频

透明载荷的卫星是模拟转发器，只变频和放大，不解调:

  • feeder link 上的频偏、星上本振的误差，都会被原样转发到 service link 上，最后落到 UE 头上
  • 而 UE 对这两项一无所知（见第 1 步）

(2) 思路

对波束内所有 UE 都相同的部分，由网络在信号发出之前一次性消掉

feeder link 是波束内所有 UE 共用的，所以它的误差正好属于"公共部分"

(3) 实际做法

[3.1] feeder link 多普勒

  • GW 发送时做预补偿，接收时做后补偿
  • GW 自己的位置固定且已知，卫星星历也已知
    • 两端都是确定的，算起来比 UE 还容易

[3.2] 星上转发器频率误差

  • 在地面监测一路经过星上转发的参考信号，按观测到的偏差进行修正

[3.3] 最终效果

  • GW 对发射信号做"预失真":
    • 信号经过 feeder link 多普勒、星上变频和星上本振误差之后，到达卫星另一侧时正好落在标称载频上
  • UE 收到的 DL 信号里:
    • 只剩 service link 多普勒（加上 UE 自己的本振误差）
  • 没有任何广播字段告诉 UE 这件事，对 UE 来说这部分误差根本不存在
Tip

类比透明代理: 中间环节替你处理掉了一部分问题，端侧完全感知不到

和时间上的做法有何不同?
  • 时间上: SIB19 会把公共部分（Common TA）广播给 UE，由 UE 叠加进 TA
  • 频率上: SIB19 里没有对应的"公共多普勒"字段. 公共部分全部由网络自己吸收

总原则是: 所有 UE 相同的部分均分给网络处理, UE-Specific 的部分只能留给 UE

第 3 步: UE 开机找小区, 为什么不能直接靠 AFC 跟踪

(1) 问题

地面网络: UE 开机后搜索同步信号（PSS/SSS，基站周期发送的已知波形，相当于小区的"信标"），锁上之后 AFC 接管，几百 Hz 的频偏不成问题

AFC

AFC（Automatic Frequency Control，自动频率控制）是接收机里的一个反馈控制环:

它不断测量 "收到的信号频率" 和 "自己本振的频率" 差多少，再把本振往消除这个差值的方向调，直到两者对齐

LEO 的问题在于时序: AFC 只能在锁上信号之后才开始工作，而多普勒在 UE 收到第一个采样时就已经存在

初始同步在不做额外假设检验的情况下，能吸收的频偏大约只有半个 SCS:

SCS 初始同步大约能吸收 该配置常见频段的 LEO 多普勒 倍数
15 kHz 约 7.5 kHz 约 52 kHz（n256 下行） 大 7 倍
30 kHz 约 15 kHz 约 52 kHz（n256 下行） 大 3.5 倍
120 kHz 约 60 kHz 约 450 kHz（FR2-NTN 下行） 大 7.5 倍

原始多普勒是捕获范围的好几倍，按地面的方式直接搜，UE 可能根本找不到小区

(2) 思路

存在 "🐔生🥚" 和 "🥚生🐔" 的问题: UE 第一次找到小区之前，还读不到这个小区的星历

因此: 大头不能靠测, 只能靠算!

(3) 实际做法

目标: 把频偏从几十 kHz 压到初始同步能吸收的范围（几 kHz）以内

规范只规定结果、不规定方法! 这一步属于 UE 的实现，常见办法有:

  • 在更宽的频率范围内做多假设搜索（原文提到的"额外假设检验"）
    • 代价是更慢、更耗电
  • 使用 UE 之前存下的星历
  • 网络侧先对下行的公共部分做一部分预补偿（例如按波束中心）
    • 这是研究阶段讨论过的选项

(1) 问题

LEO 下:

  • 频偏的大头来自卫星运动，整次过境从 +51 kHz 连续变到 −51 kHz
    • 动态时变. 不是一个常数
  • 波束内每个 UE 的几何略有不同，值也略有不同
  • 所以必须由每个 UE 自己算，而且要持续地算

(2) 思路

复用 Sec 7 的输入: 做一次几何计算，同时读出"距离"和"距离的变化率"

(3) 实际做法

[3.1] 输入

  • UE 的位置和速度: 来自 GNSS（NTN 接入本来就要求有效定位）
  • 卫星的位置和速度: 来自 SIB19 的 ephemerisInfo
    • 形式是 位置和速度向量(positionVelocity) 或 TLE(orbital)
    • 速度信息是关键: 只有位置的星历够算时延，但算不了多普勒
  • 公共时间基准: epochTime，保证两组坐标对应同一时刻

原理也是跟 Sec 7 中描述的一样!

[3.2] 计算

  • 算出 UE 与卫星的相对速度向量
  • 投影到视线方向，得到 v_rel
  • 代入 f_d = (v_rel / c) × f_c
  • 上行和下行分别算
    • FDD（频分双工）的上下行用两段不同的频率，频偏也不同
    • 例如 n254: 下行 59.8 kHz，上行 38.8 kHz

[3.3] 一次几何，两份修正

从几何里读出 物理量 用途
到卫星的距离 service link 传播时延 TA 中的 N_TA,adj^UE（Sec 7）
距离的变化率 视线方向相对速度 本节的多普勒预补偿

第 5 步: UE 上行发送, 做显式预补偿

(1) 问题

LEO 下这样做，误差会翻倍

假设卫星正在接近，多普勒为 +f_d（此处忽略上下行载频不同带来的比例差）:

Text Only
1
2
下行: 卫星发 f_DL ──(+f_d)──> UE 收到 f_DL + f_d，AFC 把本振锁到这里
上行: UE 按这个基准发 f_UL + f_d ──(+f_d)──> 卫星收到 f_UL + 2·f_d

"跟着下行走"的结果不是误差为 0, 而是约 2 倍多普勒!

  • 地面网络的 f_d 最多几百 Hz，翻倍也无所谓
  • LEO 下 48 kHz 会变成 96 kHz

(2) 思路

上行修正不能从下行推出来，只能从几何算出来，而且方向与多普勒相反

(3) 实际做法

[3.1] 修正量

  • UE 的目标: 信号到达卫星时, 正好落在标称上行频率 f_UL 上
  • 所以 UE 的实际发射频率应为: f_UL − f_d
    • 相对于"跟着下行"的基准，相当于再往反方向拉约 2 x f_d

[3.2] 符号随过境翻转

  • 卫星接近时: f_d 为正，UE 往低调
  • 卫星远离时: f_d 为负，UE 往高调
  • 预补偿的范围必须覆盖正负两个方向的全部摆幅，不能只覆盖一边

第 6 步: 连接态, 残差只能靠 UE 自己

(1) 问题

[1.1] 网络不会帮你纠错

  • 时间上: gNB 能测出 UE 上行的时间偏差，并通过 TA 命令纠正（Sec 7）
  • 频率上: NR 里没有"频率调整命令"
    • 地面网络从来不需要: UE 锁住下行就足够准
    • NTN 沿用了这个空缺! 选择让 UE 自己算，而不是新增一条命令
  • 后果: UE 的多普勒算错了，协议里没有任何机制会告诉它

[1.2] 预补偿永远不完美

  • 剩下的残差会造成 ICI（见预备知识 1）
  • 多普勒还在持续变化: 600 km、2 GHz 下约 540 Hz/s，过顶时变化最快

(2) 思路

开环把误差从几十 kHz 拉进范围，UE 本地的跟踪环把它保持在范围内

不新增任何网络侧命令!

Warning

这一点跟上一节的 TA 网络侧残差补偿 完全不同, 值得注意!

NTN 标准协议竟然放任 "允许基础误差", 而不采用对应机制, 很值得小心

这点让笔者有点疑惑🤔 或许是出于成本之类的因素考量吧...

(3) 实际做法

[3.1] 精度要求: 其实很宽松

常用经验值: 残差控制在 SCS 的 1%–2% 以内，ICI 就可以忽略

[3.2] 真正的下限: UE 自己的本振

把 0.1 ppm 的本振精度换算成 Hz，再和 1% SCS 的预算比一比:

频段中心 0.1 ppm 对应 SCS 1% 预算 仅本振就占 SCS 的
1,542 MHz（n255 下行） 154 Hz 15 kHz 150 Hz 1.0%
2,185 MHz（n256 下行） 219 Hz 15 kHz 150 Hz 1.5%
2,185 MHz（n256 下行） 219 Hz 30 kHz 300 Hz 0.7%
2,492 MHz（n254 下行） 249 Hz 15 kHz 150 Hz 1.7%
18,750 MHz（FR2-NTN 下行） 1,875 Hz 120 kHz 1,200 Hz 1.6%
28,750 MHz（n512 上行） 2,875 Hz 120 kHz 1,200 Hz 2.4%

还没算多普勒，本振误差自己就已经基本吃掉了整个 1% 预算

由此得到两个结论:

  • 1% 只是经验值，不是硬门槛
    • ICI 是逐渐恶化的，不会断崖式失效，实际系统在几个百分点下也能工作
  • 一次性预补偿永远不够
    • 残差的下限由 UE 硬件决定，算不掉
    • 所以 UE 必须用常规的跟踪环持续跟踪残差

[3.3] 持续更新

  • UE 随时间用星历外推卫星的位置和速度，持续重算 f_d
  • 有效期到期前必须重读 SIB19，否则停止上行发送（同 Sec 7 第 7 步）
本节最重要的结论

NTN 频率补偿的难点: 不在于算得多精，而在于两件事

  • 必须在接收机开始工作 之前 完成
  • 算错了, 协议里 没有任何东西 会告诉 UE

只要 GNSS 定位和星历有效，精度自然够用

第 7 步: 换星, 提前算好下一颗卫星的多普勒

(1) 问题

LEO 换星后，卫星的速度方向和几何全部改变，多普勒的大小和符号都可能突变。如果切换后才去读新小区的 SIB19 再算，就会重演第 3 步"找不到"的问题

(2) 思路

切换时刻可以预测，那就提前拿到下一颗卫星的星历，提前算好

(3) 实际做法

  • ntn-NeighCellConfigList:
    • SIB19 中每个邻区的 NTN 配置，包含该邻区卫星的星历
  • UE 在切换前就能算出目标卫星的多普勒，切换那一刻，修正量已经准备好了
    • 切换时刻本身怎么确定（t-Service 等），见 Sec 7 第 8 步

总结 1: 时间与频率的不对称

时间（Sec 7） 频率（本节）
由什么决定 到卫星的距离 距离的变化率
最坏情况 低仰角，卫星最远 也是低仰角，但原因是视线速度最大
何时为 0 从不为 0 卫星最接近时，并在过境中途变号
同一小区内 UE 之间差多少 差很多，毫秒级 小得多，同一波束内几何相近
是否随载频变化 否，1 微秒在哪个频段都是 1 微秒 是，成正比；Ka 频段约为 S 频段的 10 倍
UE 负责的部分 N_TA,adj^UE，用 GNSS + 星历算 service link 多普勒，用同一套输入算
网络负责的部分 以 ta-Common 等字段广播给 UE，由 UE 叠加 网络自己静默处理，UE 完全不知道
SIB19 里有没有"公共"字段 有: ta-Common、ta-CommonDrift、ta-CommonDriftVariant 没有
网络闭环纠正 有: RAR 中的 TA 命令、TA 命令 MAC CE 没有，NR 不存在频率调整命令
UE 是否上报 是，开启 ta-Report 时 否
算错了怎么办 网络测出偏差，用下一条 TA 命令纠正 UE 只能靠自己的跟踪环发现并修正

总结 2: 相关参数

字段 提供什么 在频率补偿中的作用
ephemerisInfo（positionVelocity 或 orbital） 卫星位置和速度 核心输入；速度部分是算多普勒的前提，只有位置的星历只能算时延
epochTime 星历对应的时刻（以帧号 SFN 和子帧表示） 让 UE 先把星历外推到当前时刻，再算 v_rel
ntn-UlSyncValidityDuration 辅助信息可以用多久 频率估计和时延估计一起过期
ntn-PolarizationDL / ntn-PolarizationUL service link 的极化方式（右旋、左旋或线极化） 不属于频率补偿，但同在 NTN 配置里，UE 收发之前同样必需
ntn-NeighCellConfigList 各邻区的 NTN 配置，包含星历 换星前预先算好目标卫星的多普勒
Tip

极化: 电磁波的振动方向，收发两端必须匹配

R17/18/19 规范与版本

[1] 各文档分别讲什么

  • TR 38.811: 刻画各类轨道的多普勒特性，确定系统要面对的量级
  • TR 38.821: 研究补偿方案，确定 UE 与网络的分工
  • TS 38.300: 规范性描述
    • 有效 GNSS 定位和星历的 UE，预补偿 service link 多普勒
    • feeder link 多普勒和转发器频率误差由网络处理
  • TS 38.101-5: 射频指标，即 UE 实际必须达到的频率误差，测试时量的就是它
    • 具体数值以最新版本为准，加入 FR2-NTN 后有所扩展

[2] 版本演进

  • Rel-17: 首个 NR-NTN 规范，只支持透明载荷和 FR1-NTN，强制 UE 具备 GNSS
    • 这正是整套预补偿方案能够成立的前提
  • Rel-18: 扩展到 10 GHz 以上的 FR2-NTN，绝对频偏约放大 10 倍
  • Rel-19 及以后: 持续增强，"UE 管 service link、网络管其余部分"这一分工保持不变

Sec 9: NTN RRC Parameters

Cheat Sheet

全部字段以 ASN.1 原型呈现，注释 = 该字段的含义 / 关键数值 / 缺省行为

来源: TS 36.331 (LTE / NB-IoT)、TS 38.331 (NR)

简介 ASN.1

ASN.1（Abstract Syntax Notation One，抽象语法标记一）是一种用于定义 通信协议数据结构 的标准化描述语言

它规定"消息包含哪些字段、字段是什么类型、取值范围是什么、哪些字段可选", 但通常不直接描述字段的业务含义

Part 1 - NTN LTE (TS 36.331)

容器: SIB1-v1700（接入控制） / SIB31（服务星） / SIB32（卫星时刻表）

(1) SIB1 扩展: NTN 接入控制

ASN.1
1
2
3
4
5
6
7
8
-- ═══════════ SIB1 扩展: NTN 接入控制 ═══════════
SystemInformationBlockType1-v1700-IEs ::= SEQUENCE {
    cellAccessRelatedInfo-NTN-r17     SEQUENCE {
        cellBarred-NTN-r17                ENUMERATED {barred, notBarred},         -- NTN 专用禁止位；与普通 cellBarred 独立，用来只放行 NTN 终端
        plmn-IdentityList-v1700           PLMN-IdentityList-v1700   OPTIONAL      -- 补充 PLMN 列表；一个 NTN 小区可跨多国多运营商
    }                                                               OPTIONAL,     -- Need OR
    nonCriticalExtension              SEQUENCE {}                   OPTIONAL
}

(2) SIB1 扩展: NTN 接入控制

ASN.1
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
-- ═══════════ SIB31: 服务星辅助信息（仅 NTN 小区广播）═══════════
SystemInformationBlockType31-r17 ::= SEQUENCE {
    servingSatelliteInfo-r17          ServingSatelliteInfo-r17,                   -- 当前服务星的全部辅助数据
    lateNonCriticalExtension          OCTET STRING                  OPTIONAL,
    ...
}

ServingSatelliteInfo-r17 ::= SEQUENCE {
    ephemerisInfo-r17                 CHOICE {                                    -- 星历，两种等价写法二选一
        stateVectors                      EphemerisStateVectors-r17,              --   算得快 / 过期快
        orbitalParameters                 EphemerisOrbitalParameters-r17          --   算得慢 / 过期慢
    },
    nta-CommonParameters-17           SEQUENCE {                                  -- 公共 TA 三件套（RP↔卫星往返，UE 自己算不出）
        nta-Common-r17                    INTEGER (0..8316827)      OPTIONAL,     -- 值
        nta-CommonDrift-r17               INTEGER (-261935..261935) OPTIONAL,     -- 一阶导
        nta-CommonDriftVariation-r17      INTEGER (0..29479)        OPTIONAL      -- 二阶导
    },
    ul-SyncValidityDuration-r17       ENUMERATED {s5, s10, s15, s20, s25, s30,    -- 星历+公共TA 的保质期（秒），从 epochTime 起算；到期禁止上行
                                                  s35, s40, s45, s50, s55, s60,   --   5~60s 密集档 = LEO
                                                  s120, s180, s240, s900},        --   s900 = GEO；★强制字段，不可省
    epochTime-r17                     SEQUENCE {                                  -- 上面这些数字"什么时候为真"
        startSFN-r17                      INTEGER (0..1023),                      --   系统帧号；1024 帧 = 10.24 s 一循环
        startSubFrame-r17                 INTEGER (0..9)                          --   子帧号，1 ms 一格
    }                                                               OPTIONAL,     -- 专用信令下发时必须带
    k-Offset-r17                      INTEGER (0..1023),                          -- 上行调度偏移；用来恢复时序因果性；小区级，按波束边缘配；★强制
    k-Mac-r17                         INTEGER (1..512)              OPTIONAL,     -- MAC CE 生效偏移；仅当 eNB 侧 DL/UL 帧定时不对齐时用
    ...
}

(3) Ephemeris:

ASN.1
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
-- ═══════════ 形式一: 状态矢量（ECEF）═══════════
EphemerisStateVectors-r17 ::= SEQUENCE {
    positionX-r17                     PositionStateVector-r17,                    -- ECEF X 坐标
    positionY-r17                     PositionStateVector-r17,                    -- ECEF Y 坐标
    positionZ-r17                     PositionStateVector-r17,                    -- ECEF Z 坐标
    velocityVX-r17                    VelocityStateVector-r17,                    -- ECEF X 向速度
    velocityVY-r17                    VelocityStateVector-r17,                    -- ECEF Y 向速度
    velocityVZ-r17                    VelocityStateVector-r17                     -- ECEF Z 向速度
}

PositionStateVector-r17 ::= INTEGER (-33554432..33554431)
VelocityStateVector-r17 ::= INTEGER (-131072..131071)

-- ═══════════ 形式二: TLE ═══════════
EphemerisOrbitalParameters-r17 ::= SEQUENCE {
    semiMajorAxis-r17                 INTEGER (0..8589934591),                    -- 半长轴 a
    eccentricity-r17                  INTEGER (0..1048575),                       -- 偏心率 e
    periapsis-r17                     INTEGER (0..268435455),                     -- 近地点幅角 ω
    longitude-r17                     INTEGER (0..268435455),                     -- 升交点赤经 Ω
    inclination-r17                   INTEGER (-67108864..67108863),              -- 倾角 i
    anomaly-r17                       INTEGER (0..268435455)                      -- 平近点角 M: 卫星此刻走到轨道哪；★NR 侧叫 meanAnomaly-r17
}

(4) SIB32: 卫星时刻表(不连续覆盖用)

ASN.1
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
-- ═══════════ SIB32: 卫星时刻表(不连续覆盖用) ═══════════
SystemInformationBlockType32-r17 ::= SEQUENCE {
    satelliteInfoList-r17             SatelliteInfoList-r17         OPTIONAL,     -- 一张"哪颗星、什么时候来、照哪块地"的表
    lateNonCriticalExtension          OCTET STRING                  OPTIONAL,
    ...
}

SatelliteInfoList-r17 ::= SEQUENCE (SIZE (1..maxSat-r17)) OF SatelliteInfo-r17     -- maxSat-r17 数值见 36.331

SatelliteInfo-r17 ::= SEQUENCE {
    satelliteId-r17                   INTEGER (0..255),                           -- 列表内部标识: 把 "星历/时间/足迹" 绑到同一颗星 (本卫星全部信息)
    serviceInfo-r17                   SEQUENCE {
        tle-EphemerisParameters-r17       TLE-EphemerisParameters-r17 OPTIONAL,   -- TLE 星历，配 SGP4；适合后面提及的 NB-IoT 的"睡多久"场景
        t-ServiceStart-r17                TimeOffsetUTC-r17           OPTIONAL    -- 这颗星"开始"服务的时刻
    },
    footprintInfo-r17                 SEQUENCE {                                  -- 覆盖足迹：UE 用 GNSS 比一下就知道自己在不在里面
        referencePoint-r17                SEQUENCE {
            longitude-r17                     INTEGER (-131072..131071),          -- 参考点经度
            latitude-r17                      INTEGER (-131072..131071)           -- 参考点纬度
        }                                                             OPTIONAL,
        elevationAngles-r17               SEQUENCE {
            elevationAngleRight-r17           INTEGER (-14..14),                  -- 右侧仰角边界
            elevationAngleLeft-r17            INTEGER (-14..14)       OPTIONAL    -- 左侧仰角边界
        }                                                             OPTIONAL,
        radius-r17                        INTEGER (1..256)            OPTIONAL    -- 足迹半径（单位见 36.331）
    }
}

Part 2 - NTN NR (TS 38.331)

容器: SIB19（广播） / NTN-NeighCellConfig（邻星） / ServingCellConfigCommon v1700（专用信令）

(1) SIB19: NTN 系统信息块

ASN.1
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
-- ═══════════ SIB19: NTN 系统信息块 ═══════════
SIB19-r17 ::= SEQUENCE {
    ntn-Config-r17                    NTN-Config-r17                OPTIONAL,     -- "当前服务星"的全部辅助数据 (下面会详细展开)
    t-Service-r17                     INTEGER (0..549755813887)     OPTIONAL,     -- 本小区"停止"服务本Cell的时刻；"计划性换星"的依据
    referenceLocation-r17             ReferenceLocation-r17         OPTIONAL,     -- 准地面固定小区的中心点
    distanceThresh-r17                INTEGER (0..65525)            OPTIONAL,     -- 距中心多远才开始做基于位置的测量；用于省电机制
    ntn-NeighCellConfigList-r17       NTN-NeighCellConfigList-r17   OPTIONAL,     -- 邻星辅助信息（换星前预计算）
    lateNonCriticalExtension          OCTET STRING                  OPTIONAL,
    ...,
    [[
    ntn-NeighCellConfigListExt-v1720  NTN-NeighCellConfigList-r17   OPTIONAL      -- 邻星列表扩展
    ]]
}

ReferenceLocation-r17 ::= OCTET STRING

NTN-NeighCellConfigList-r17 ::= SEQUENCE (SIZE (1..maxCellNTN-r17))
                                    OF NTN-NeighCellConfig-r17

NTN-NeighCellConfig-r17 ::= SEQUENCE {
    ntn-Config-r17                    NTN-Config-r17                OPTIONAL,     -- 该"邻星"的辅助数据
    carrierFreq-r17                   ARFCN-ValueNR                 OPTIONAL,     -- 邻区载频
    physCellId-r17                    PhysCellId                    OPTIONAL      -- 邻区物理小区 ID
}

maxCellNTN-r17  INTEGER ::= 4                                                      -- ★硬上限：一次最多只能给 4 个邻区提供辅助信息

(2) NTN-Config: 全部辅助数据(一个类型，三处复用).

非常非常重要!

ASN.1
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
-- ═══════════ NTN-Config: 全部辅助数据（一个类型，三处复用）═══════════
NTN-Config-r17 ::= SEQUENCE {
    epochTime-r17                     EpochTime-r17                 OPTIONAL,     -- 所有外推的时间原点；基准在 RP 上
    ntn-UlSyncValidityDuration-r17    ENUMERATED { s5, s10, s15, s20, s25, s30,   -- 星历+公共TA 保质期（秒）；驱动定时器 T430，到期视为上行失步
                                                   s35, s40, s45, s50, s55, s60,  --   短档=LEO，s900=GEO
                                                   s120, s180, s240, s900 }
                                                                    OPTIONAL,     -- Cond SIB19：只有广播时必须带（邻区/专用信令可省）
    cellSpecificKoffset-r17           INTEGER (1..1023)             OPTIONAL,     -- 上行调度偏移；小区级，按波束边缘配
    kmac-r17                          INTEGER (1..512)              OPTIONAL,     -- MAC CE 生效偏移；仅当 gNB 侧 DL/UL 不对齐时用；缺省 0
    ta-Info-r17                       TA-Info-r17                   OPTIONAL,     -- 公共 TA 三件套 (见下)
    ntn-PolarizationDL-r17            ENUMERATED {rhcp,lhcp,linear} OPTIONAL,     -- 下行极化
    ntn-PolarizationUL-r17            ENUMERATED {rhcp,lhcp,linear} OPTIONAL,     -- 上行极化
    ephemerisInfo-r17                 EphemerisInfo-r17             OPTIONAL,     -- 星历 (见下)
    ta-Report-r17                     ENUMERATED {enabled}          OPTIONAL,     -- 开关型: 让 UE 上报自己预补偿的 TA (review: Msg3)
    ...                                                                           --   在 SIB19 = 覆盖建立/恢复/重建；在专用 SCCC = 覆盖 reconfig-with-sync
}

EpochTime-r17 ::= SEQUENCE {
    sfn-r17                           INTEGER (0..1023),                          -- 系统帧号（LTE 侧叫 startSFN）
    subFrameNR-r17                    INTEGER (0..9)                              -- 子帧号（LTE 侧叫 startSubFrame）
}

TA-Info-r17 ::= SEQUENCE {                                                        -- ★类型名带连字符，承载它的字段叫 ta-Info-r17
    ta-Common-r17                     INTEGER (0..66485757),                      -- 公共 TA
    ta-CommonDrift-r17                INTEGER (-257303..257303)     OPTIONAL,     -- 一阶导
    ta-CommonDriftVariant-r17         INTEGER (0..28949)            OPTIONAL      -- 二阶导
}

(3) Ephemeris:

ASN.1
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
-- ═══════════ 星历: 与 LTE 仅类型名不同 ═══════════
EphemerisInfo-r17 ::= CHOICE {
    positionVelocity-r17              PositionVelocity-r17,                       -- = LTE 的 EphemerisStateVectors
    orbital-r17                       Orbital-r17                                 -- = LTE 的 EphemerisOrbitalParameters
}

PositionVelocity-r17 ::= SEQUENCE {
    positionX-r17                     PositionStateVector-r17,                    -- ECEF X
    positionY-r17                     PositionStateVector-r17,                    -- ECEF Y
    positionZ-r17                     PositionStateVector-r17,                    -- ECEF Z
    velocityVX-r17                    VelocityStateVector-r17,                    -- ECEF Vx
    velocityVY-r17                    VelocityStateVector-r17,                    -- ECEF Vy
    velocityVZ-r17                    VelocityStateVector-r17                     -- ECEF Vz
}

Orbital-r17 ::= SEQUENCE {
    semiMajorAxis-r17                 INTEGER (0..8589934591),                    -- 半长轴 a
    eccentricity-r17                  INTEGER (0..1048575),                       -- 偏心率 e
    periapsis-r17                     INTEGER (0..268435455),                     -- 近地点幅角 ω
    longitude-r17                     INTEGER (0..268435455),                     -- 升交点赤经 Ω
    inclination-r17                   INTEGER (-67108864..67108863),              -- 倾角 i，±90°
    meanAnomaly-r17                   INTEGER (0..268435455)                      -- 平近点角 M；★LTE 侧叫 anomaly-r17
}

PositionStateVector-r17 ::= INTEGER (-33554432..33554431)
VelocityStateVector-r17 ::= INTEGER (-131072..131071)

(4) 专用信令里 ntn-Config 的真实位置:

ASN.1
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
ServingCellConfigCommon ::= SEQUENCE {
    physCellId                        PhysCellId                    OPTIONAL,
    downlinkConfigCommon              DownlinkConfigCommon          OPTIONAL,
    uplinkConfigCommon                UplinkConfigCommon            OPTIONAL,
    n-TimingAdvanceOffset             ENUMERATED {n0,n25600,n39936} OPTIONAL,     -- N_TA,offset：本小区所有上行的固定偏移，单位 T_c(≈0.509 ns)
    ...                                                                           -- 其余 Rel-15/16 字段省略
    ...,
    [[                                                                            -- v1700 扩展组
    uplinkConfigCommon-v1700          UplinkConfigCommon-v1700      OPTIONAL,
    ntn-Config-r17                    NTN-Config-r17                OPTIONAL      -- ★ntn-Config 在这里，不在 DownlinkConfigCommon
    ]],
    ...
}

DownlinkConfigCommon ::= SEQUENCE {                                                -- 对照组：这里面没有任何 NTN 字段
    frequencyInfoDL                   FrequencyInfoDL               OPTIONAL,
    initialDownlinkBWP                BWP-DownlinkCommon            OPTIONAL,
    ...,
    [[
    initialDownlinkBWP-RedCap-r17     BWP-DownlinkCommon            OPTIONAL
    ]]
}

(5) HARQ 反馈时序 (长 RTT 适配):

非常非常重要!

ASN.1
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
-- ═══════════ HARQ 反馈时序 ═══════════
PUCCH-Config ::= SEQUENCE {
    ...
    dl-DataToUL-ACK-r17               SetupRelease { ...-r17 }         OPTIONAL,
    dl-DataToUL-ACK-DCI-1-2-r17       SetupRelease { ...-DCI-1-2-r17 } OPTIONAL,
    ul-AccessConfigListDCI-1-2-r17    SetupRelease { ...-DCI-1-2-r17 } OPTIONAL,
    ul-AccessConfigListDCI-1-1-r17    SetupRelease { ...-DCI-1-1-r17 } OPTIONAL,
    ...
    dl-DataToUL-ACK-v1700             SetupRelease { ...-v1700 }       OPTIONAL,  -- ★NTN 用的就是这个
    ...
}

DL-DataToUL-ACK-r16            ::= SEQUENCE (SIZE (1..8))  OF INTEGER (-1..15)     -- 地面基线；-1 = 不适用
DL-DataToUL-ACK-r17            ::= SEQUENCE (SIZE (1..8))  OF INTEGER (-1..127)    -- 给最高 71 GHz 的地面场景，非 NTN；-1 = 不适用
DL-DataToUL-ACK-v1700          ::= SEQUENCE (SIZE (1..8))  OF INTEGER (16..31)     -- ★NTN 专用；下限是 16 不是 0 —— 用取值范围声明"答复不可能快"
DL-DataToUL-ACK-DCI-1-2-r17    ::= SEQUENCE (SIZE (1..8))  OF INTEGER (0..127)     -- DCI format 1_2 对应的时序表
UL-AccessConfigListDCI-1-2-r17 ::= SEQUENCE (SIZE (1..16)) OF INTEGER (0..15)      -- 共享频谱信道接入配置（DCI 1_2）
UL-AccessConfigListDCI-1-1-r17 ::= SEQUENCE (SIZE (1..3))  OF INTEGER (0..2)       -- 共享频谱信道接入配置（DCI 1_1）
-- 优先级：r16/r17/v1700 任一被下发 → UE 忽略无后缀的 dl-DataToUL-ACK

(6) HARQ 进程数与逐进程关反馈:

非常非常重要!

ASN.1
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
-- ═══════════ HARQ 进程数与逐进程关反馈 ═══════════
PDSCH-ServingCellConfig ::= SEQUENCE {
    codeBlockGroupTransmission        SetupRelease { PDSCH-CBGT }      OPTIONAL,  -- CBG 重传；NTN 里价值放大（少重传=少花一个 RTT）
    xOverhead                         ENUMERATED {xOh6,xOh12,xOh18}    OPTIONAL,
    nrofHARQ-ProcessesForPDSCH        ENUMERATED {n2,n4,n6,n10,n12,n16}OPTIONAL,  -- 地面基线：最多 16 个进程
    pucch-Cell                        ServCellIndex                    OPTIONAL,
    ...,
    [[
    maxMIMO-Layers                    INTEGER (1..8)                   OPTIONAL,
    processingType2Enabled            BOOLEAN                          OPTIONAL
    ]],
    [[
    pdsch-CodeBlockGroupTransmissionList-r16
                                      SetupRelease { ...-r16 }         OPTIONAL
    ]],
    [[                                                                            -- Rel-17：NTN 的两件套
    downlinkHARQ-FeedbackDisabled-r17 SetupRelease { ...-r17 }         OPTIONAL,  -- 逐进程关闭上行 HARQ 反馈
    nrofHARQ-ProcessesForPDSCH-v1700  ENUMERATED {n32}                 OPTIONAL   -- 进程数上限提到 32
    ]]
}

DownlinkHARQ-FeedbackDisabled-r17 ::= BIT STRING (SIZE (32))                       -- 最左位=进程 0；置 1 = 该进程"关闭"反馈，置 0 = 保留
                                                                                   -- ★32 进程只覆盖 32 ms RTT，GEO 541 ms 差一个量级 → 必须靠关反馈解流水线

PDSCH-CodeBlockGroupTransmission ::= SEQUENCE {
    maxCodeBlockGroupsPerTransportBlock ENUMERATED {n2,n4,n6,n8},                  -- 一个 TB 切成几个码块组
    codeBlockGroupFlushIndicator        BOOLEAN,                                  -- 是否要求接收端清空已缓存软比特
    ...
}

PDSCH-CodeBlockGroupTransmissionList-r16 ::= SEQUENCE (SIZE (1..2))                -- 最多 2 套，用于同时构造两个 HARQ-ACK 码本
                                    OF PDSCH-CodeBlockGroupTransmission

Part 3 - NTN NB-IoT (TS 36.331)

要点:

  • 几乎不需要任何新字段，直接复用 LTE 的类型
  • 差异只在外壳与部署假设

(1) SIB31-NB: 服务星辅助信息

ASN.1
1
2
3
4
5
6
7
8
9
-- ═══════════ SIB31-NB: 服务星辅助信息 ═══════════
SystemInformationBlockType31-NB-r17 ::= SEQUENCE {
    servingSatelliteInfo-r17          ServingSatelliteInfo-r17,                   -- ★与 LTE SIB31 完全相同
    lateNonCriticalExtension          OCTET STRING                  OPTIONAL,
    ...,
    [[
    servingSatelliteInfo-v1820        ServingSatelliteInfo-v1820    OPTIONAL      -- Rel-18 扩展（与 Store-and-Forward 机制相关）
    ]]
}

(2) SIB32-NB: 卫星时刻表

非常非常重要!

ASN.1
1
2
3
4
5
6
-- ═══════════ SIB32-NB: 卫星时刻表 ═══════════
SystemInformationBlockType32-NB-r17 ::= SEQUENCE {
    satelliteInfoList-r17             SatelliteInfoList-r17         OPTIONAL,     -- ★与 LTE SIB32 完全相同
    lateNonCriticalExtension          OCTET STRING                  OPTIONAL,
    ...
}

(3) SIB1-NB 扩展: NTN 接入控制

ASN.1
1
2
3
4
5
6
-- ═══════════ SIB1-NB 扩展: NTN 接入控制 ═══════════
cellAccessRelatedInfo-NTN-r17 {
    cellBarred-NTN-r17,
    plmn-IdentityList-v1700
}
--   结构与逻辑同 Part 1 的 SIB1-v1700：用扩展组挡住老终端，同时放行 NTN 终端

(4) NB-IoT NTN 能力与专用配置

Text Only
1
2
3
4
5
6
7
8
9
-- ═══════════ NB-IoT NTN 能力与专用配置 ═══════════

ntn-Parameters-r17            NB-IoT 侧的 NTN 能力容器
  ntn-Connectivity-EPC-r17    能在 NTN 场景下用 EPC 方式连接；EPC 就是 CoreNet
  ntn-ScenarioSupport-r17     gso / ngso，与 NR 同名同义

NTN 专用配置
  ta-Report-r17               UE 上报自己的 TA 预补偿量（作用同 NR 的 ta-Report）
  t318-r17                    NTN 下新增/重新取值的定时器

NB-IoT 的典型 UE 流程（SIB32 的真正用途）

  1. 有覆盖时读到 SIB32
  2. tle-EphemerisParameters + SGP4 → 算出未来数小时各星轨迹
  3. footprintInfo → 判断"它走到那里时我在不在覆盖里"
  4. t-ServiceStart → 确认那时它确实在提供服务
  5. 得到下一次机会的绝对时刻 → 关射频、定闹钟、睡过去
  6. 到点醒来直接同步，不盲搜
NB-IoT 与 LTE 的真实差异 (不在字段, 在用法)
  • 字段层面:
    • 零差异: SIB31-NB / SIB32-NB 直接引用 ServingSatelliteInfo-r17 / SatelliteInfoList-r17
  • 外壳层面:
    • SIB 编号带 -NB、承载在 BCCH-NB、SI 窗口更长重复次数更多
    • 后者直接影响 epochTime 缺省规则的实际时间精度
  • 部署层面:
    • LTE 覆盖可不连续，NB-IoT NTN 通常不连续 → SIB32 从"锦上添花"变成"核心机制"
Warning

精度换有效期：TLE 公里级精度对"决定什么时候醒"完全够用

3GPP 官方 NTN 技术页

原文

https://www.3gpp.org/technologies/ntn-overview

来源: 3GPP Deep Dive, Non-Terrestrial Networks (NTN)（by Joern Krause, 3GPP MCC）

本章范围: 仅 LEO/NGSO; 终端具备 GNSS

这页的真实结构

大半篇幅是工作项目编年史与 TR 编号索引，技术干货只在两处：概念地基和 Rel-17 机制

三条最值得记的结论：

  • Rel-17 由三条硬假设撑起: 透明载荷 + UE 必备 GNSS + Earth-fixed Tracking Area
  • Rel-18 在这三条之上做增强, Rel-19 正在逐条拆掉它们
  • 全部机制的出发点只有一条: 长时延与快变多普勒, 必须在接入之前就被消化掉

基础概念

(1) Payload 类型: 决定 gNB 位置

  • Transparent / bent-pipe（透明转发）:
    • 星上只做变频、滤波、放大，等价于==模拟 RF 中继==
    • 此时 NTN Gateway 侧才是 gNB，卫星只是远端射频头
  • Regenerative（再生式）:
    • 星上具备解调/译码、交换/路由、编码/调制
    • gNB 在星上. Gateway 退化为连向核心网的路由器
  • 硬约束:
    • 使用 ISL 必须是 regenerative
    • 而 Rel-17/18 只支持 transparent, regenerative 要到 Rel-19

(2) 链路命名

  • Service link（服务链路）：
    • 卫星 ↔ UE
  • Feeder link（馈电链路）= SRI（Satellite Radio Interface）：
    • 卫星 ↔ NTN Gateway
  • ISL：星间链路

(3) 波束类型

(4) 架构: CU/DU 分离与两类切换

CU/DU split: DU 上星、CU 在地面

  • feeder link 上跑 F1 协议
  • RRC 等 L3 处理留在地面 CU
  • 多颗星的 DU 可挂同一个地面 CU

因此有额外时延代价

NGSO 绕地快于自转，必然产生两类切换
  • Service link switch：更换服务卫星
  • Feeder link switch：把馈电链路从源 Gateway 切到目标 Gateway，属==传输网层（TNL）过程==，支持硬切与软切

Rel-17: 真正落地的机制

前提假设（限定得很死）:

  1. 仅 transparent payload
  2. FR1 FDD（410 MHz–7125 MHz），新增 n255（L 波段）/ n256（S 波段）
  3. 手持终端 power class 3
  4. UE 具备 GNSS
  5. earth-fixed tracking area

第 1 步: 接入前的上行同步预补偿 (RAN1)

(1) 问题

TN 里 UE 不需要任何几何知识：先发 RACH preamble，由 gNB 估出定时偏移再下发 TA。NTN 里时延与多普勒==在随机接入发生之前就已超出空口容限==，preamble 根本检测不出来——"先接入、再校正"的顺序在 NTN 走不通。

(2) 思路

把校正提前到接入之前，由 UE 依据几何信息自行计算。

(3) 实际做法

  1. 网络在每个 NTN 小区广播 星历（ephemeris）+ common TA 参数
  2. UE 接入前必须同时持有三样东西:
    • 有效 GNSS 位置、星历、common TA
    • 随后用 "common TA + 自身位置 + 卫星位置与速度" 自主预补偿 TA 与多普勒频偏
    • 在连接态持续更新
  3. 失效即静默:
    • GNSS 位置或星历任一失效，UE 直接停止与网络通信，直到两者都恢复
  4. 责任边界:
    • UE 只负责 service link 的瞬时多普勒
    • feeder link 的多普勒留给网络实现自行处理，不在标准范围内
  5. UE 可被配置:
    • 初始接入或连接态上报 TA
    • 连接态支持触发式上报 (节约资源)

第 2 步: 调度时序关系的偏移修正 (RAN1)

(1) 问题

TA 只对齐 UE 的发射时刻，不改变协议里写死的调度时序关系（例如收到下行授权后第几个时隙发上行）。这些时序假定 RTT 远小于时隙尺度；NTN 的 RTT 横跨多个时隙，时序关系整体失效。

(2) 思路

给时序关系加可配置偏移，把长 RTT 显式建模进协议。

(3) 实际做法

偏移量 含义
Common TA 参考点（RP）到 NTN payload 的 RTT
K_offset ≈ service link RTT + common TA
k_mac ≈ 参考点（RP）到 gNB 的 RTT

第 3 步: HARQ (RAN1)

(1) 问题

HARQ 进程需等反馈才能复用，长 RTT 下全部进程卡在等待态（HARQ stalling），基站发不出新数据。

(2) 思路

要么不等反馈，要么把并行进程数加够。

(3) 实际做法

  • 关闭 HARQ 反馈，由 RLC 层 ARQ 重传兜底（GSO 类系统的典型选择）
  • 进程数增至 32（NGSO 类系统的典型选择）
  • 两者可组合使用

第 4 步: 移动性与测量 (RAN2)

(1) 问题

TN 切换依赖信号强度变化。NTN 中波束重叠区信号强度变化极小、切换极其频繁（卫星在动）、且不同卫星来的小区之间存在传播时延差，测量窗口本身都对不齐，强度判决不再可用。

(2) 思路

改用卫星场景下天然确定的时间与几何信息做判决，并让测量配置能容纳时延差。

(3) 实际做法

  1. 切换命令携带服务小区与邻区的星历，供 UE 接入目标小区

  2. CHO 触发条件扩为三类:

    • event A4（测量类）、time-based、location-based
    • 后两者必须与一个测量类条件一起配置，不能单独使用
    • location = UE 到参考位置的距离；time = 从 T1（绝对时刻）起、持续 T2 的时间窗

  3. 测量配置:

    • 每载波可并行配置多个 SMTC（SSB 测量时序配置），依据传播时延差与星历
    • 连接态由网络控制调整（可用 UE 辅助信息）
    • 空闲/非激活态由 UE 依据自身位置与卫星辅助信息自行调整

  4. NTN↔TN 切换双向支持(hand-in/hand-out)，但不要求 UE 同时连接两者; 也可支持不同轨道之间的切换

    • 这个点信息量很大!!!
    • hand-in / hand-out 是从地面网视角命名: hand-in = NTN → TN; hand-out = TN → NTN
      • 典型场景: User 从市区（TN 覆盖）走到荒漠（只有 NTN）触发 hand-out; 再走回来触发 hand-in
    • "不要求同时连接两者" 说的是终端能力下限:
      • UE 必须能在 NTN 和 TN 之间切换! 但不强制要求它同时维持两条活跃连接
      • Rel-16 的研究阶段（TR 38.821）认真讨论过 multi-connectivity: 一个 UE 同时挂 NTN + TN，或同时挂两个 NTN，用来提升速率和可靠性
      • 但同时收发两条链路: 意味着终端要有两套独立的射频通道，工作在差异很大的频段上，成本和功耗都上一个台阶
      • 所以 Rel-17 规范化时把它降级了: 多连接不是必选项，硬切换（一次只连一个）才是必需!
    • "不同轨道之间的切换" 是可选项:
      • 含义: Cross-orbit Switching 指在基于不同轨道的接入之间移动. GSO ↔ NGSO，或者不同高度的 NGSO 之间（比如 550 km 的星座切到 1200 km 的星座）
      • 不同轨道的 RTT、多普勒变化率、各类定时器取值差出一个数量级。UE 换轨道等于把第 1、2 步里那套参数（common TA、K_offset、k_mac、定时器）整体换一套，几乎相当于接入一个完全不同的部署

  5. Tracking Area 对应固定地理区域:

    • 一个 NTN 小区可按 PLMN 广播多个 TAC，降低小区边缘（尤其 earth-moving 覆盖）的信令负荷
    • TAC 变更由网络控制，不一定与波束实际照射时刻严格同步

第 5 步: 位置、小区标识与跨国监管 (RAN2/RAN3)

(1) 问题

NTN 单小区可覆盖大片大陆、跨越多国，而同一 NTN RAN 可能连接多国核心网。 服务小区粒度不足以满足公共预警、紧急呼叫、合法监听的属地监管要求 —— 这是 TN 里根本不存在的问题。

(2) 思路

  • 让 UE 报位置
  • 让小区标识与地理区域解耦
  • 让 gNB 按国家挑 AMF

(3) 实际做法

这一部分实际上还是未定式 :)

  1. UE 粗位置上报：网络请求时、AS 安全建立后，UE 上报 GNSS 坐标(精度约 2 km)

  2. Mapped Cell ID：

    • 上报核心网的 Cell Identity 是映射过的（与轨道类型、服务链路类型无关），用于寻呼优化、Area of Interest、公共预警，也用于切换消息中标识目标小区
    • 映射关系在 RAN 与 CN 预配置，gNB 依据 UE 位置信息构造

  3. 跨国 AMF 重选：

    • gNB 若发现 UE 所在国家与服务 AMF 服务国家不符，应发起 NG handover 换 AMF，或发起 UE 上下文释放请求

  4. O&M 必须下发：星历、epoch time、NTN Gateway 位置，以及支持 feeder/service link 切换所需的参数

演进主线

Release 性质 产出
Pre-R15 卫星仅用于定位（GNSS） —
R15 首个 RAN 研究项 TR 38.811：信道模型适配 + 部署场景
R16 系统侧 FS_5GSAT（TR 22.822）+ 无线侧研究 TR 38.821：架构方案 + RAN1/2/3 规范化建议
R17 首个含规范性要求的版本（ASN.1 2022-06 冻结） RAN 侧 NR_NTN_solutions；系统侧落到 TS 23.501/502/503
R18 增强 R17 (补丁) 覆盖增强、网络验证 UE 位置、>10 GHz、不连续覆盖、卫星回传
R19 下一步 (真前瞻) regenerative payload、S&F、UE-卫星-UE、GNSS-independent
Rel-18 要点
  • 网络验证 UE 位置：定义 UE/gNB 的 Rx/Tx 时间测量来验证 UE 自报位置，目标精度 5–10 km（约等于地面宏小区直径）。动因即第 5 步的属地监管问题
  • 覆盖增强：Msg4 HARQ-ACK 的 PUCCH 重复；PUSCH DMRS bundling，使 UE 在 定时漂移 下仍保持相位连续性
  • 移动性：TN 侧 SIB19 携带 NTN 邻区参数；SAN 广播地面 TN 区域列表及频率信息；satellite switch with re-sync
  • 频段：新增 n254（UL 1610–1626.5 L 波段 / DL 2483.5–2500 S 波段）；FR1 增加 30 MHz 信道带宽（对齐 ITU IMT-2020 卫星评估假设）
  • 不连续覆盖（SA2）：星座初期部署或掉星导致 UE 只在特定时间地点有覆盖 → 移动性管理、寻呼增强、省电、UE 不可达时段的确定与协调，以及大量 UE 同时恢复覆盖引发的信令过载处理
  • 卫星回传：多跳 ISL 的时延/带宽/乱序问题; 星上 UPF 做边缘计算与本地数据交换
Rel-19 前瞻设计非常重要
  1. REGEN Payload 正式进入架构: gNB/5GS 部分上星
  2. Store & Forward: UE 在卫星覆盖下通信时 不要求馈电链路同时在线, 面向时延容忍 IoT
  3. UE-Sat-UE 直接通信: 不绕地面网，省回传、降时延
  4. GNSS-independent 运行 + 卫星接入下的定位增强: 直接解绑第 1 步的"UE 必备 GNSS"硬假设

另: RAN 侧 Ph3 还包括下行覆盖增强、FR1 上行容量/吞吐增强、MBS 广播服务区域信令、NR NTN 支持 RedCap

IoT-NTN 旁注

NB-IoT/eMTC over NTN 是 Rel-17 起的并行线，原则是 "以 NR NTN 为基线"尽量复用

两点差别:

  1. 不假设 GNSS 与 NTN 收发可同时运行（需要 GNSS 测量间隙）
  2. NTN-IoT 侧 Rel-17 就考虑了不连续覆盖; 而 NTN-NR 侧到 Rel-18 才做

Satellite direct to device: 4G or 3GPP NTN?

Ericsson《Satellite direct to device: 4G or 3GPP NTN?》

原文

https://www.ericsson.com/en/reports-and-papers/ericsson-technology-review/articles/satellite-direct-to-device-communication

卫星直连终端（D2D）：unmodified 4G 与 3GPP NTN

来源：Ericsson Technology Review（2025-12-11）

TLDR

两条路线的全部差异来自同一个分水岭：时延与多普勒由谁补偿

  • unmodified 4G：网络侧补
    • 代价全部压回星座、波束、轨道设计，换来存量手机即可用
  • 3GPP NTN：UE 侧补（GNSS 定位 + 广播星历）
    • 用一条新 SIB 换回整个系统设计的自由度，代价是要等 Rel-17 之后的芯片

前置

LEO 参数与两种频谱模型

LEO：高度 < 2,000 km，速度约 7.8 km/s。地面网络"时延小、发射端不动"两个前提被同时打破。

模型 A — 地面移动频谱（MNO–SNO 合作）：这些频段 ITU 未划给卫星，合法性只来自少数国家的国内新规或 ITU RR 第 4.4 条，均为 不干扰、不受保护。必须设排除区（覆盖内主动静默的区域），粒度约等于一个点波束，一开就吃掉大片覆盖。WRC-27 议题 1.13 在讨论 700–2700 MHz 新增 MSS 划分，但即便通过，地面业务仍然优先。

模型 B — MSS 频谱（L/S 波段）：国际划分成熟、共存规则清晰、干扰管理简单，Rel-17 起写入 NTN 规范。代价是终端渗透率低。

四个技术关口

按 UE 从接入到保活的时间顺序 排列。后三步在 4G 路线的所有麻烦，都能追溯到第 1 步根因。

第 1 步：上行预补偿（时延与多普勒）

(1) 问题

地面空口容限是按"基站不动、UE 慢速"设计的。LEO 往返上千公里、以 7.8 km/s 掠过，时延与多普勒频移（收发端相对运动导致的频率偏移）双双超限。

超限不是性能下降，是基站解调不出上行，根本连不上。

(2) 思路

在信号发出前把已知的时延和频偏预先减掉（pre-compensation）。分歧只在于谁来算。

(3) 实际做法

[3.1] 4G — 网络侧补：

卫星用星历（ephemeris = 卫星位置 + 速度矢量）按波束统一补偿。但时延/频偏取决于用户在波束内的具体位置，一次补偿只有一组参数，只能对一个参考点最优，离参考点越远残差越大。

[3.2] NTN — UE 侧补（Rel-17）：

UE 先用 GNSS 定位（接入前的强制前提）→ 卫星经新增 SIB广播星历 → UE 自行算出定时与频率修正量并预补偿到上行。

残差落回地面 NR 的原有容限，波束足印从被空口倒逼的约束变成自由变量。

仅 Rel-17+ 芯片支持。

第 2 步：随机接入（Random Access）

(1) 问题

RA 是 UE 建立上行同步的第一个动作：发送 preamble（前导序列），基站据此估计定时偏移。此时 UE 还没有任何网络校正，对残差的容忍度全链路最低

残差把波形畸变到检测不出，就是反复接入失败，业务完全建立不起来。

(2) 思路

残差必须在 整个波束覆盖内 合规，而非平均合规。

(3) 实际做法

[3.1] 4G — 只能调系统参数，项项有代价

手段 代价
缩小波束足印 天线更大 → 成本与集成复杂度上升；同样覆盖需更多波束/卫星
限制波束指向 单星覆盖缩小 → 需要更大星座
频段、轨道高度 基本调不动，受监管约束且直接影响路损

各参数互相牵制! 最终容易落到 sub-optimal 系统设计

[3.2] NTN

问题在第 1 步已消解，RA 无需任何卫星专用处理。

第 3 步：HARQ 重传

(1) 问题

HARQ 工作在 stop-and-wait 模式：一个进程必须等反馈回来才能复用。

LTE 上限 16 个进程: 当 RTT > 进程数 × 时隙长度，所有进程卡在等反馈，基站发不出新数据（HARQ stalling）。

进程数是协议硬上限，不可配。

(2) 思路

要么把 RTT 压进协议限制，要么拆掉 stop-and-wait 的约束本身。

(3) 实际做法

  • 4G:

    1. 压 RTT → 反过来==约束轨道高度与仰角==
    2. 关掉 HARQ 改用 RLC ARQ（上层基于序列号与状态报告的重传）→ 时延与开销上升、吞吐下降

  • NTN:

    1. 进程数 16 → 32
    2. 支持 按进程单独关闭 HARQ 反馈，长 RTT 业务走 RLC ARQ，其余照常，不必一刀切

第 4 步：移动性

(1) 问题

地面切换靠源/目标小区的信号强度差判决。卫星场景下 小区直径远小于轨道高度，星到小区内各点距离几乎相同，路损均匀 → 没有强度梯度。

不是测不准，是被测量本身不再携带位置信息。

(2) 思路

放弃"用信号强度推断位置"，改用卫星场景下天然确定的信息：轨道可预测、波束落点已知。

(3) 实际做法

  • 4G

    • 只能沿用强度判决 → 切换与重选可靠性下降，原文未给出补救

  • NTN — 增强 CHO

    • 条件切换: 网络预下发目标与触发条件，UE 自行判决执行
      • 时间触发：网络给定时间窗，到点执行 → 适用 卫星切换，接替时刻可由轨道精确算出
      • 位置触发：UE 估计自身相对源/目标小区参考点的位置 → 适用 相邻小区间移动

演进与结论

Rel-17 之后 / 6G

方向是: GNSS-independent 运行

IoT-NTN 的补偿思路与 NR-NTN 一致: 额外增加 GNSS 测量传输间隙（部分终端无法同时运行 GNSS 与 NTN）

6G: 从一开始内建 NTN! 两项关键能力。不依赖 GNSS 的运行 + 多 RAT 频谱共享（平滑迁移）

维度 unmodified 4G 3GPP NTN
补偿责任 网络侧! 对单一参考点最优 UE 侧! GNSS + 星历自补偿
终端生态 成熟，存量手机即可用 需 Rel-17 之后新芯片
网络设计自由度 低，仅 LEO 可支撑 高，可适配多种星座
频谱 地面移动频段，不干扰不受保护 MSS，国际框架成熟
定位 短期务实解 长期、面向未来
结论

unmodified 4G 把非地面信道的全部代价压在网络侧与星座设计上——波束必须小、轨道必须低、HARQ 必须让步、切换失去判决依据； 唯一但决定性的优势是: 存量终端即可用。

3GPP NTN 把补偿责任移交给具备 GNSS 的 UE，用一条 SIB 换回整个系统设计的自由度，代价是等待终端生态成熟。

IEEE ComSoc NTN

原文

https://techblog.comsoc.org/category/non-terrestrial-network-ntn/

TBD. Still working in process. (2026-0918)

两本好书

(1) 3GPP‐based Non‐Terrestrial Networks in 5G and 6G: Expanding the Frontiers of Wireless Communications

https://onlinelibrary.wiley.com/doi/book/10.1002/9781394203413

TBD. Still working in process. (2026-0918)

(2) 5G Non-Terrestrial Networks: Technologies, Standards, and System Design

https://ieeexplore.ieee.org/book/10402577

TBD. Still working in process. (2026-0918)

论文与产品

看一万遍, 不如对着源码跑一遍

(1) Amarisoft NR SA NTN: 传送门

详细内容笔者在 Amarisoft专题 集中展开!

(2) 5G NR NTN From Early Results to the Road Ahead: 传送门

(3) 5G NR NTN - Open Challenges for Full-Stack Protocol Design: 传送门

(4) 5G NR NTN Link-to-System Simulation in ns-3-NTN: 传送门

在 SIGCOMM LEO-NET Workshop (2026) 中详细展开!

(5) OAI NTN: 传送门