卫星移动、小区不动：NTN中的Mapped Cell ID信令与测试实践

上个月做NTN仿真测试时，我盯着一份RRC信令日志看了很久：同一颗卫星过境，手机上驻留的小区号在会话中途换了三次，核心网那边的寻呼范围每次都得重新配置。当时第一反应是切换参数出了问题，但把物理层波束扫描、TA调整和UE位置全部拉出来比对了一遍才发现，根子不在切换，而在“小区ID到底代表什么”。

传统地面蜂窝网络里，小区ID绑定的是固定地理位置。基站不动，小区边界就不动，终端测量、切换、核心网寻呼全部围绕这个固定关系展开。但非地面网络（NTN）完全打破了这条假设：卫星在轨道上跑，覆盖区在地面上“漂”，如果小区ID跟着波束走，终端哪怕站在原地，也会在几分钟内被切换好几个逻辑小区，核心网侧的跟踪区更新、寻呼列表、用户位置上报全部失真。

3GPP在Rel-17引入的Mapped Cell ID（映射小区ID），就是为了把“物理波束产生的小区”和“地面上的逻辑区域”解耦。这个概念被写进了RRC信令，也在SIB里下发，但真正把它读明白、用对、测好的人并不多。这篇文章就从我实际接触到的信令细节出发，把Mapped Cell ID的来龙去脉、信令承载、SSB关联和测试方法整个过一遍，适合做NTN基站、终端协议栈以及测试仪表的朋友参考。

1. 卫星在动、小区却要“不动”：Mapped Cell ID要解决的核心矛盾

1.1 地面网络里小区ID的设计逻辑

在5G地面网络中，一个小区的身份由三样东西共同确定：物理小区ID（PCI）、小区全球标识（NCGI，即PLMN+CellIdentity）以及跟踪区码（TAC）。其中NCGI是唯一且地理绑定的，核心网用这个ID来定位用户、触发寻呼、进行基于位置的计费和策略控制。因为基站固定，所以NCGI和地理区域的关系几乎是静态的，终端在网络里移动时，切换、重选、测量上报的语义都非常清晰：换小区就是换位置。

这套逻辑在宏站、室分、甚至高铁专网里都成立。就算是高铁专网，基站本身也是固定的，只是用户高速移动，小区切换变得更密集，但基站和小区的地图没有动。地面网络从3G到5G，所有移动性机制都没有跳出“小区ID表示固定地理点”这个隐含前提。

1.2 透明转发式卫星让“小区”失去了地理锚点

NTN在Rel-17里定义了两种典型的星上处理模式：透明转发和再生。透明转发模式下，卫星只做变频和转发，基站核心逻辑都在地面信关站（Gateway），空口侧的用户跟一个“远在天上但信号从卫星下来”的基站通信。问题在于，卫星波束投射到地面的footprint是时刻移动的，而且移动速度极快，LEO卫星的波束地面移动速度可以达到每秒好几公里。

假如我们按照地面逻辑，把每个波束定义成一个小区ID，UE静止站在地面上，卫星飞过时，它收到的SSB索引和波束覆盖区域不断变化，于是会不停重选或切换小区。这还不是最糟糕的：核心网会看到同一个用户短时间内从小区A跳到小区B再到小区C，位置上报混乱、寻呼范围飘忽不定，甚至触发一连串不必要的跟踪区更新。对于透明转发架构，地面信关站到卫星再到UE的链路天然带来较大时延和频繁波束切换，如果小区ID不能“钉”在地理上，整个移动性体系都会变成一场灾难。

1.3 从CellIdentity到mappedCellIDList：映射的核心思路

Mapped Cell ID的思路并不复杂：物理波束仍然拥有自己的PCI和CellIdentity，但网络在系统信息里额外下发一个“这张波束覆盖的地理区域对应哪些逻辑小区”的列表。终端在做小区选择、重选、测量报告时，可以采用映射后的逻辑小区ID来上报，而不是被物理波束变化牵着走。

换句话说，物理小区跟着卫星跑，映射小区跟着地面走。卫星波束中心偏移几百公里时，物理CellIdentity变了，但mappedCellIDList仍然指向同一个地理区域，终端和核心网就不用频繁地重复移动性流程。这对寻呼优化、位置服务、以及和地面网络互操作都有直接价值。

2. RRC信令里的mappedCellIDList：字段、语义与协同参数

2.1 关键信息元素解析

Mapped Cell ID不是一个抽象概念，它实实在在出现在RRC信令里。在TS 38.331定义的无线资源控制消息中，小区接入相关信息（CellAccessRelatedInfo）携带了mappedCellIDList字段。从结构上看，这个列表里的核心元素是MappedCellID，每个元素使用类似CellIdentity的格式来指示一个逻辑小区标识。

我手头没有把完整ASN.1贴出来的必要，但做协议栈的朋友一定见过下面这种简化结构：

-- 仅示意，非完整ASN.1定义 MappedCellIDList ::= SEQUENCE (SIZE (1..maxMappedCellID)) OF MappedCellID MappedCellID ::= CHOICE { cellIdentity CellIdentity, -- 其他扩展形式 ... } CellAccessRelatedInfo ::= SEQUENCE { plmn-IdentityList PLMN-IdentityList, trackingAreaCode TrackingAreaCode OPTIONAL, ranac RANAC OPTIONAL, cellIdentity CellIdentity, mappedCellIDList MappedCellIDList OPTIONAL, ... }

注意一个关键点：mappedCellIDList是可选字段。它不下发时，终端规则退回到传统的地面小区逻辑；它存在时，终端就有了一个“第二身份”可以参与小区选择与上报。这保证了NTN终端遇到地面网络时依然正常工作，也就是从Rel-17开始讨论的“地形兼容”基础。

2.2 为什么映射关系要放在RRC系统消息里而不是NAS

有人会问：Mapped Cell ID既然是给核心网做位置管理用的，为什么不直接放在NAS信令里？答案和空闲态移动性有关。

终端处于RRC_IDLE时，网络无法实时给它下发专用配置。它只能靠广播信息来评估驻留小区是否合适。如果Mapped Cell ID放在NAS消息里，空闲态终端根本拿不到，也就无法在重选时使用映射后的逻辑ID。RRC的SIB机制天然适合这类广播场景，网络可以周期性把当前波束对应的mappedCellIDList广播给所有驻留用户。

另外，RRC重配置消息里也可以携带这个字段。对于已经进入RRC_CONNECTED的终端，当卫星波束发生切换或迁移时，网络可以直接通过RRCReconfiguration更新映射关系，避免终端频繁碰撞物理小区切换逻辑。这也是映射关系主要放在RRC层的原因：既要覆盖空闲态，又要能对连接态做动态控制。

2.3 与cellIdentity、physCellId的关系

我经常看到有人把mappedCellID和CellIdentity搞混，这里要拆清楚。

CellIdentity是物理波束对应的全球小区标识之一部分，和PLMN一起构成NCGI。PCI则是物理层用于区分相邻小区的短标识，可能重复。Mapped Cell ID则是在逻辑地理维度上的映射标识，它不改变PCI配置，也不改变物理波束的CellIdentity，而是新增了一个可以被终端和核心网识别的高层逻辑ID。

再通俗一些：PCI是“这束波的短名”，CellIdentity是“这束波的大名”，Mapped Cell ID是“这片地上的人统一对外用的地址”。卫星移动时，短名和大名可能随波束变化，但地面地址不能一天变好几次。三种标识可以同时存在，作用域完全不同。

2.4 定时提前和星历参数如何配合

Mapped Cell ID要真正起作用，不能只靠一个ID列表。NTN里还有一个非常关键的问题是超长传播时延和多普勒频偏。如果映射出的“逻辑小区”固定了，但终端不知道卫星在哪、不知道当前传播时延是多少，那么逻辑区域做得再准也用不起来。

为此，Rel-17 NTN引入了针对非地面网络的专用系统信息块（通常被称为SIB19），里面携带了星历参数、公共定时提前（common TA）、UTC参考时间等。SSB里也可能携带用于多普勒预补偿的辅助信息。Mapped Cell ID和这些参数配合的典型场景是：终端先读取SIB1里的mappedCellIDList，知道自己在哪个逻辑区域；再读取SIB19里的星历和公共TA，计算出精确的上行发送时刻；然后网络再下发或计算UE特定TA偏差。整个流程里，Mapped Cell ID解决的是“身份与位置”的问题，TA和星历解决的是“时间与频率”的问题，两者缺一不可。

3. NTN的SSB Case K与波束映射：Mapped Cell ID怎么和同步信号绑定

3.1 Case K到底指什么

5G NR的SSB（同步信号块）在地面网络里有一系列编号：Case A、Case B、Case C对应FR1，Case D、Case E对应FR2等。不同case决定了SSB的子载波间隔、时域符号位置以及在一个SSB burst set里的可容纳波束数量。

到了NTN场景，卫星覆盖范围动辄数百公里，传播时延大，多普勒频偏高，原来的case在时频结构上并不能完美适配。于是3GPP讨论过支持更灵活的SSB调度，有些资料里提到的“NTN SSB Case K”，指的就是针对非地面网络传播环境优化的SSB时分复用/频分复用结构，核心目的是在足够大的覆盖范围内仍然让终端快速完成同步、读取MIB/SIB，并获得可靠的波束与映射小区信息。

需要说明的是，具体到某个release最终落地了哪种case、参数如何组合，要严格对照3GPP的TS 38.213和TS 38.331的版本更新。但不管编号怎么变，设计逻辑是清楚的：NTN场景需要更大时延容限、更重的多普勒预补偿、更强的波束扫描计划，所以SSB的时域位置和发送周期会被重新设计，让UE在已知星历和公共TA的情况下能准确接收。

3.2 一个波束对应一个映射还是一组映射

Mapped Cell ID和SSB索引之间存在多对多关系。卫星一个宽波束可能覆盖多个地面区域，而地面上一个逻辑区域也可能被多个相邻波束重叠覆盖。所以网络侧并不会简单画等号：一个SSB索引只映射一个mappedCellID，而是下面几种可能：

• 单波束单映射：最简单，适合小波束、窄覆盖的高通量卫星；
• 单波束多映射：一个宽波束覆盖多个地理分区，终端根据自身定位或者测量结果，从列表里选择合适的mappedCellID去驻留；这种方式对于在大覆盖范围内区分地面规则区域很有用；
• 多波束单映射：多个相邻波束服务同一个地理逻辑区域，用于提高边缘覆盖可靠性，此时Mapped Cell ID保持稳定，物理波束切换不会触发逻辑小区变化，非常省信令。

我在做仿真时觉得，单波束多映射最考验协议栈实现。终端怎么从多个映射里选择正确的ID？一般会结合自己的地理位置（GNSS定位）或者接收到的波束信息，再匹配SIB里广播的区域边界条件。如果实现得不好，可能出现终端选了一个映射ID但实际定时提前不匹配的情况，导致上行信号到达卫星的时间不在网络期望窗口内。

3.3 SSB周期对映射发现和信令开销的影响

Mapped Cell ID要生效，终端得先读到SIB1。而SIB1是跟随SSB调度传输的，SSB的周期和波束数量直接决定了终端能否快速获取映射ID。

假设SSB周期是20ms，波束数量是8个，那么一个完整的波束扫描要160ms。如果卫星覆盖范围极大、波束数量多，SSB周期又太长，终端首次接入的体验会明显变慢。反过来，如果SSB周期太短，对于高轨卫星那种超远距离场景，终端可能还没完全处理完上一个同步信号，下一个又来了，处理能力和功耗都吃不消。

所以做NTN系统设计时，需要把SSB周期、波束数、mappedCellIDList长度、终端移动速度这几件事放在一起权衡。通常建议在初始接入阶段用较短的SSB周期做快速小区搜索，进入稳态后再用较长的周期降低干扰和功耗。这也直接影响SIB1里映射列表的更新频率，频繁更新会占用宝贵的空口资源，但映射变化不及时又会造成终端驻留到已经不合理的逻辑区域，两边都要照顾。

4. 从驻留到切换：Mapped Cell ID参与的信令流程拆解

4.1 初始接入：读取SIB1、匹配映射、选择驻留小区

终端开机做小区搜索时，第一步是检测SSB并读取MIB，然后读取SIB1。SIB1里除了PLMN列表、跟踪区码、CellIdentity之外，如果存在mappedCellIDList，终端就会获得当前波束可用的逻辑映射ID。

实际接入流程中，终端会这样做：

1. 检测到满足信号质量阈值的SSB索引；
2. 读取SIB1，获取PLMN、TAC、cellIdentity和mappedCellIDList；
3. 把PLMN和SIM卡里的配置做匹配；
4. 如果配置了mappedCellIDList，则选择一个合法的mappedCellID作为本次驻留的“逻辑驻留小区”；
5. 发起RRCSetupRequest，上报携带的逻辑小区信息。

很多测试朋友喜欢在这一步抓RRCSetupRequest，看看UE上报的是物理小区还是映射小区。这里标准允许终端在建立了RRC连接后，通过RRCSetupComplete里带上的selectedPLMN-Identity等信息，让网络知道它最终选择了哪个PLMN和区域。映射ID参与的具体位置在不同厂商实现里有差异，但这不代表没有作用。

4.2 切换与小区重选：用映射ID减少无效移动性信令

在传统地面网络里，UE只要跨过小区边界，就要触发测量上报、切换准备、切换执行等一整套RRC信令。NTN场景如果照搬这套逻辑，卫星波束在地面快速移动会让UE频繁“跨小区”，信令风暴几乎是必然的。

引入Mapped Cell ID之后，网络可以把地理位置稳定的逻辑小区作为移动性锚点。UE测量到的物理波束虽然变了，但只要映射ID没变，就不一定需要触发小区切换。这样一来，卫星移动、波束铺展变化都尽可能被映射关系“隔离”在底层，高层看到的还是同一个逻辑小区。只有当映射ID确实变了，比如从一颗卫星交接到另一颗卫星，或者从NTN接入切换到地面小区时，才发生真正的移动性信令。

在切换命令里，Mapped Cell ID同样有用。网络可以在RRCReconfiguration里携带目标小区的mappedCellIDList，让UE提前知道目标波束覆盖哪些逻辑区域，减少切换后的重新搜索和PLMN匹配开销。这对LEO卫星之间频繁波束交接非常关键。

4.3 与5G核心网的交互：AMF寻呼、N2位置上报

映射ID的作用不只在空口。5G核心网的AMF需要知道UE在哪个跟踪区，才能精准寻呼。如果mappedCellIDList能和跟踪区绑定好，AMF就可以按照逻辑区域而不是物理波束来管理寻呼列表。此时，即使卫星波束在地面移动，NTN基站（通常通过地面信关站与核心网相连）上报的用户位置也可以保持相对稳定，避免AMF频繁更新UE位置上下文。

在N2接口上，用户位置信息的IE可能携带小区ID以及附加的位置字段。实际组网时，需要把Mapped Cell ID和允许的TAI列表对齐，否则核心网会认为UE进入了未注册位置，导致注册更新风暴。这个点我在测试中见过：网络侧把mappedCellIDList配置好了，但AMF里的TAI列表没同步扩，结果UE一注册就被拒绝，反复搜索驻留。

4.4 和地面网络的互操作性

大家经常问“5G基站向下兼容4G吗”，这个问题放在地面网络回答起来很简单，但放到NTN和地面网络的互操作就复杂了。NTN小区需要知道自己周边有哪些地面小区，终端也需要在卫星覆盖和地面覆盖之间平滑移动。Mapped Cell ID在这里扮演的是“翻译层”：卫星波束映射的逻辑区域，可以提前配置成与地面小区的跟踪区一致，这样UE从NTN重选到地面小区时，核心网看到的跟踪区变化是连续、可预测的。如果让物理CellIdentity直接参与互操作，卫星一移动，整个区域映射就要重写，几乎不可维护。

5. 测试札记：从信令日志里读懂Mapped Cell ID

5.1 测试环境怎么搭

Mapped Cell ID的验证需要信令级仿真，最简单的方案是用OpenAirInterface的NTN分支或者商业协议栈仿真器。如果想控制变量，推荐先跑纯软件仿真：模拟一个低轨卫星的星历，让波束footprint周期性扫过一片区域，终端模型放在一个固定经纬度，观察它是否始终驻留在同一个映射小区。

如果手头有真实终端和带NTN功能的测试基站，那就更直接了。把基站配置成透明转发模式，下发mappedCellIDList，然后用终端信令仪表抓RRC日志。要注意的是，很多现网终端默认关闭GNSS，而NTN场景下GNSS定位信息对卫星接入合法性判断有很大影响，测试前要确认终端是否开启并上报定位信息。

5.2 典型日志字段如何解读

一份正常的NTN接入日志，通常会包含以下字段：

看日志的时候，最容易忽略的是epochTime。Mapped Cell ID是地理逻辑概念，但卫星位置是随时间变化的。如果终端和基站使用不同步的星历参考时间，计算出的footprint位置会偏，映射ID的实际含义就会偏移。我习惯把手机上的UTC时间、日志里的epochTime和SSB的时间戳统一校准，再判断映射ID是否合理。

5.3 排查过的两个典型异常

先说映射列表为空导致的搜网失败。有一次终端无论怎么扫描SSB，都无法驻留。日志里SIB1收到了，但mappedCellIDList是空的，终端按地面小区逻辑来判断，发现跟踪区和PLMN不匹配，直接判为禁止驻留。后来查下来是网络侧配置工具漏配了映射列表。这个问题的排查关键，就是清楚SIB1里到底有没有携带映射字段，以及终端的驻留判定是否把空映射当成非法场景。

另一个典型异常是单波束多映射时的重选乒乓。一个宽波束映射了两个相邻逻辑区域，终端在两个映射ID之间反复切换，每次切换都触发跟踪区更新。解决办法是调整映射列表的优先级和信号质量偏移，让终端选择其中一个作为“主映射”，另一个只有当主映射信号恶化到门限以下才启用。这个思路和地面小区里的重选偏置很像，只是这里的“信号”要换成综合逻辑区域规则后的结果。

5.4 实战中的一些经验

抓信令日志时，我建议用Wireshark加RRC解析插件，先把NAS和RRC消息过滤出来，再按键值比对mappedCellIDList。不要只看厂商的界面摘要，很多厂商只显示cellIdentity，映射字段在详情页深层，容易被忽略。

另外，做测试矩阵时一定要覆盖“卫星波束移动前、移动中、移动后”三个窗口。移动前，终端应驻留旧映射ID；移动中，映射ID切换最好发生在无线链路故障之前，避免掉线；移动后，终端应稳定驻留新映射ID，并完成核心网位置更新。把这三个窗口对应的信令时间戳标出来，基本就能评估Mapped Cell ID的切换是否干净。

最后再提一个容易被坑的点：有些测试仪表只支持标准的SSB Case A/B，不支持NTN扩展的SSB Case K。跑仿真之前先确认仪表固件和协议栈版本，否则抓出来的SSB时域位置跟标准对不上，后续所有信令时序分析都会跑偏。我吃过一次亏，仿真半小时没发现是SSB承载配置错了，还以为Mapped Cell ID的问题，换了最新固件才恢复正常。

Mapped Cell ID并不是一个让你“改几个字段就能跑通”的简单功能，它涉及空口同步、RRC状态管理、核心网位置管理还有和地面网络的互操作，每一层都有细节。如果这篇文章能帮你在信令日志里少走一些弯路，那我的测试就没白做。