高通平台Modem搜网注册流程：初始化、PLMN/RAT选择与小区搜索-平芜编程栈

简介：一份面向通信协议工程师、Modem 开发与场测分析人员的专题 PPT，聚焦高通平台终端开机后的搜网注册链路。内容按初始化、PLMN 与 RAT 选择、扫频与小区搜索、小区选择、随机接入、RRC 连接建立及注册逐层展开，并结合协议说明、代码路径与真实日志，还原从 SIM 卡就绪、MBN 加载、policyman 决策到驻网成功的完整过程。资源包内仅含 1 个 pptx 文件，大小约 1.59MB，页面以流程拆解和日志摘录为主，便于按阶段对照查阅。该 PPT 已有 5132 人学习，适合需要理解多制式多运营商环境下终端选网行为、排查场测掉网与无服务问题的读者。通过各阶段关键日志与模块职责的对应关系，可帮助读者建立从信令现象回溯到 Modem 内部决策的排错思路，也可作为 5G/4G 搜网注册流程的自学与培训材料。

1. 信号图标亮起之前，modem 已经跑完四个阶段

手机重启或者插拔 SIM 卡之后，状态栏的信号图标通常两三秒就出现了，但这两三秒里，高通平台 modem 侧跑完的是初始化、PLMN 与 RAT 选择、扫频与小区搜索、随机接入与注册一整套流程。这份《高通平台 modem 搜网注册流程》PPT 的价值在于，它把这条链路拆成四个阶段，每个阶段都配了协议条款号、代码文件和函数入口，再加上真机 log 片段——这种三件套对齐的写法，在排查场测掉网、无服务这类问题时特别重要。它不讨论算法层面的优化，只解决一件事：现象出现在哪一步、对应哪个模块、看哪条 log 能确认。适合做 modem 协议栈的、做场测问题分析的，以及从 AP 侧想往底层通信转的工程师；刚接触搜网流程的人能省掉在协议和代码之间来回翻的时间，做过几年的人则能拿到一份「协议顺序 ↔ 代码落点」的对照。

2. 初始化：SIM、MBN、policy 三条线决定终端在哪张网上“起床”

上电到 REG 发出第一条MMR_SIM_AVAILABLE_REQ之前，modem 内部其实有四条线在并行跑：读卡、选 MBN、执行 policy、SD 排 RAT 顺序。这四步谁先谁后并不严格串行，但只要其中一环没跑通，后面的搜网根本不会启动。现场遇到的“插卡无反应”“开机后一直飞行模式样子”，绝大多数都能在这一段找到答案。

2.1 UIM、MCFG、Policyman、SD：四块拼图各管一段

先把职责分清楚，看 log 的时候才不会被满屏的模块名带偏。

模块	输入	输出	log 标签
UIM / MMGSDI	卡槽状态、SIM 卡 EF 文件	SIM available、IMSI	`mmgsdi`、`mmocmmgsdi`
MCFG	IMSI 的 MCC/MNC、MBN 配置表	本次生效的 MBN ID	`MCFG`
Policyman	IMSI PLMN、policy 文件、特性开关	`rat_acq_order`初值、特性使能	`Policy Manager`
SD	policyman 结果 + NV 频段能力 + 协议栈支持	最终 RAT 获取顺序、`sys_mode`	`=SD=`

UIM 这条线负责把“卡存在”变成“卡可用”。卡插入事件只说明物理上有卡，真正可用要等 USIM 应用激活完成，也就是MMGSDI_SUBSCRIPTION_READY_EVT。这两条 log 之间如果相隔很久甚至缺失，问题就不在搜网，而在卡或卡槽。

MCFG 做的是“按运营商选配置”。同一个 modem 二进制在不同运营商网络下要开不同的频段组合、不同的 VoLTE 策略，靠的就是 MBN。它查表的依据是 IMSI 里的 MCC/MNC，所以mcfg_uim.c那行Selecting config using IMSI MCC=... MNC=...是判断 MBN 选对没选对的第一现场。

Policyman 是规则层，决定这次开机允许用哪些 RAT、哪些特性打开。它拿到的 IMSI PLMN 会直接参与后面的 PLMN 优先级判断，输出的rat_acq_order则交给 SD 做进一步裁剪。SD 是最后拍板的那个，它把 policyman 给的顺序、NV 里的频段能力、以及当前实际起来的协议栈三者取交集，排出真正要试的 RAT 顺序。

2.2 对着上电 log 走一遍：从 CARD_INSERTED 到 CM_SIM_AVAILABLE_CNF

把这份材料里的 log 按阶段切开看，逻辑会清楚很多。第一段是卡就绪：

// 1. 卡插入 → USIM 应用就绪 02:42:32.119 [ mmocmmgsdi.c 2072] =MMOC= CARD_INSERTED: Set sim_available_status on sub 0 02:42:32.128 Phonebook Manager/High [ qmi_pbm.c 5580] Card ecc for session type 6: 110,120,119,999,911,122,118,08,000,112 02:42:34.929 [ mmgsdi.c 7938] MMGSDI_SUBSCRIPTION_READY_EVT, app: 0x3, slot: 0x1

CARD_INSERTED到SUBSCRIPTION_READY_EVT中间隔了约 2.8 秒，这段时间是在读卡里的 EF 文件、做鉴权前的准备。如果现场反馈“插卡后要等很久才有信号”，先量这两个时间戳的差值，比盲目怀疑射频有意义得多。中间那两条 ECC 相关的 log 是电话本模块在读紧急号码，和搜网无关，看的时候可以直接跳过。

第二段是 policy 和 MBN：

// 2. Policyman 拿到 IMSI PLMN 并执行 policy 02:42:34.936 Policy Manager/High [ policyman_uim.c 1045] IMSI PLMN: (MCC 460, MNC 1, pcs_incl 0) 02:42:34.939 [ policyman_policy.c 209] subs 0: -------Started executing policy version 1101.2.7 (17720529) 02:42:34.939 [ policyman_policy.c 224] subs 0: ----------- Finished executing policy 1101.2.7 (8 ticks) // 3. MCFG 按 IMSI 选 MBN 02:42:34.935 MCFG/High [ mcfg_uim.c 2379] Selecting config using IMSI MCC=460 MNC=1 02:42:34.949 MCFG/Medium [ mcfg_utils.c 913] Config: C3I_CN-LA-7+7_mode-SDM439 02:42:34.949 [ mcfg_map.c 944] mcfg_print: type 1 sub 0 active len 20 id:54~13 02:42:34.949 MCFG/Medium [ mcfg_utils.c 913] Config: VoLTE-CU

policyman_policy.c那行Finished executing policy ... (8 ticks)里的 tick 数值得留意：8 ticks 说明走的是已缓存的 policy，如果换成几百 ticks，通常意味着 policy 文件被现场改过、这是首次加载，或者文件本身有问题在反复重试。mcfg_map.c打印的id:54~13是配置在 MBN 表里的索引区间，也是 MBN 选错的唯一线索——一旦 VoLTE 起不来又查不到别的原因，就从这两个数字倒推。

第三段是 SIM 可用通知和 SD 决策：

// 4. 通知协议栈 SIM 可用 02:42:35.007 NAS REG/High [ reg_send.c 1953] DS: SUB 1 =REG= MMR_SIM_AVAILABLE_REQ 02:42:35.008 NAS MM/High [ mmsim.c 1621] DS: SUB 1 =MM= SIM IMSI length: 8 02:42:35.018 NAS REG/High [ reg_send.c 857] DS: SUB 1 =REG= CM_SIM_AVAILABLE_CNF // 5. SD 排出 RAT 获取顺序 02:42:35.037 [ sdss.c 55272] =SD= PM -> SD: rat_acq_order for asubs_id 0, num_rat 3 02:42:35.037 [ sdss.c 55288] =SD= rat_acq_order[0]: 9 [1]: 5 [2]: 3 [3]: 0 [4]: 0 [5]: 0 02:42:35.037 [ sdss.c 55167] =SD= adding rat 2 to rat_acq_order index 3 02:42:35.041 [ sdss.c 20499] =SD= ACQ_GWL: sys_mode = 9, acq_reqd = 1 bst_band_cap && band_cap 02:42:35.311 [ sdcmd.c 27555] =SD= Mode 4 not supported on any stack

rat_acq_order数组前三个值是 policyman 给的，后面的adding rat ...是 SD 自己补进去的。数组里的数字是 SD 内部的 RAT 枚举，不同基线取值可能不同，别硬记，对着 SD 头文件比对最稳妥。最后那行Mode 4 not supported on any stack说明这个 RAT 对应的协议栈压根没起来，SD 会直接跳过它，这类 log 出现时不必再往后追这一路的失败原因。

2.3 参数落点表与容易配错的三个位置

初始化阶段真正可能被改动的参数不多，但每改一个都影响后面整条链路：

参数	存放位置	影响范围	配错的表现
MBN ID	MBN 表 +`mcfg_map`	频段组合、VoLTE/VoNR 开关	信号满格但注册被拒、VoLTE 不可用
policy 版本	efs 下 policy 文件	可用 RAT 集合、特性开关	RAT 顺序异常、某制式始终不尝试
频段能力	NV 项（band cap）	SD 排 RAT 和扫频范围	某些频段完全搜不到
acq_db	efs 下搜网数据库	开机首扫的频点	换地区后搜网变慢或失败

改 MBN 是最容易出事的一步。常见做法是先在mcfg_uim的 log 里确认 MCC/MNC 匹配到的配置名，再比对mcfg_map打印的 id 区间是否和设备里激活的列表一致；两边对不上，就不要再往下分析射频了。频段能力那一项出问题时表现很干脆——某个频段在整个 log 里一次都没出现过Acq requested on earfcn，这时候去查 NV，基本一查一个准。

3. PLMN 与 RAT 选择：协议优先级和 REG 模块的函数一一对上

初始化跑完，终端手里有了身份、有了频段能力、有了一份候选 RAT 顺序，接下来要做的是“去哪张网”。这一步在 3GPP 23.122 里写得非常细，而高通平台把它落到 REG 模块的若干个Reg_mode_*.c文件里。把协议条款和函数入口对上，是这份材料最实用的部分之一，也是分析“为什么它偏偏选了这个网”的唯一路径。

3.1 自动模式下的五级 PLMN 顺序

23.122 的 4.4.3.1.1 节给的是固定顺序，从高到低依次尝试：

级别	PLMN 类型	来源	典型触发场景
1	RPLMN	上次注册成功的 PLMN，存在 SIM/NV	正常重启、飞行模式开关
2	HPLMN / EHPLMN	IMSI 里的 MCC/MNC；等效列表	首次插卡、换卡
3	UPLMN	用户自定义，SIM 卡 EF 文件	用户手工设置的优先网
4	OPLMN	运营商自定义，SIM 卡 EF 文件	漫游场景
5	other PLMN	现场扫到的其他网络，按信号质量降序	前四级全失败

这个顺序决定了搜网耗时的下限。RPLMN 命中时几乎不用扫全频段，直接从 acq_db 里取频点就能出结果；一旦落到第 5 级，就要把当前能收到的所有 PLMN 按信号质量排序逐个尝试，慢是必然的。所以现场遇到“换个城市开机特别慢”，先看 log 里走的是第几级，比怀疑硬件靠谱。

EHPLMN 这一级容易被忽略。它和 HPLMN 平级，来自 SIM 卡里的等效列表，跨国运营商的卡经常靠这一级才能正常驻留。查 log 时如果看到PLMN match from EHPLMN list，说明命中的是等效列表而不是 IMSI 里的归属网，这是正常行为，不是配置错误。

3.2 手动模式为什么容易“卡死在 limited service”

手动模式的规则简单得多：用户指定了 PLMN 就只用这个，不指定就用 RPLMN，RPLMN 也是空的才去驻留一个“可接受的小区”拿限制服务。所谓限制服务，就是能打紧急电话、不能正常上网打电话的状态。

问题出在“只用这个”上。自动模式下第一级失败会自动降级到下一级，手动模式不会。用户在网络列表里点了一个当前覆盖很差、或者根本不允许这个卡接入的 PLMN，终端就会一直守在那个 PLMN 上反复尝试，状态栏表现为“无服务”或者只有紧急呼叫。现场反馈这类问题的典型描述是“点了手动选网之后就回不去了”，解决方式也很直接：切回自动，或者重新进网络列表选一个当前信号好的。

还有一种情况是手动选网列表本身为空。列表是靠一次全频段扫描扫出来再上报给 AP 的，如果扫描阶段因为射频或频段配置问题没扫到任何 PLMN，列表就是空的，用户只能看到“搜索中”。这时候要回头查的是扫频那一段的 log，而不是选网逻辑。

3.3 REG 主流程：从 service request 到 reg_send_mmr_reg_req

REG 模块的入口是它的 main 函数，按 CM 送过来的请求类型分派。开机、无服务恢复这两种场景送过来的都是 service request，统一进reg_state_process_cm_service_req，在这个函数里再按手动/自动分流。PLMN 和 RAT 的选择落点如下：

模式	PLMN 类型	代码文件	入口函数
自动	RPLMN	`Reg_mode_plmn_selection.c`	`start_plmn_selection`
自动	HPLMN / EHPLMN	`Reg_mode_automatic_plmn_selection.c`	`start_automatic_plmn_selection`
自动	UPLMN / OPLMN	`Reg_mode_higher_priority_plmn_selection.c`	`start_higher_priority_plmn_selection`
手动	用户指定	`Reg_mode_manual_plmn_selection.c`	`start_manual_plmn_selection`
降级	任意	同上目录下的 limited 分支	`reg_mode_start_limited_service`

RAT 的选择跟在 PLMN 后面。AP 侧通过 NV 和 efs 文件给出一个 rat list，随 service request 一起传到 REG；自动模式下 REG 会在这个 list 基础上，参考 SIM 卡或 NV 里记录的 RPLMN RAT、HPLMN RAT 重新排一遍，得到最终顺序，然后从第一个开始试。某个 RAT 注册失败就换下一个，直到这个 PLMN 下的所有 RAT 都试完，才回头去试下一个 PLMN。这个“先穷尽 RAT 再换 PLMN”的细节很关键——它解释了为什么有些场景下终端会在一个错误的 PLMN 上耗掉很久。

PLMN 和 RAT 都定下来之后，REG 调reg_send_mmr_reg_req把请求发给 MM 模块，选择阶段到此结束。后面所有关于射频的动作，都是 MM 拿到这个请求之后触发的。

3.4 从 log 里读 RAT 优先级列表

自动模式下最值得盯的一行，是 service request 带进来的 rat list。某海外运营商的测试 log 里能看到这样的组合：rat list 为 9/2/4，分别对应 LTE、CDMA、HDR 三套制式，REG 先按 RPLMN 及其 RAT 定下首选，然后直接把请求发给 MM。看到这行就能预判：如果 LTE 覆盖不好，终端会依次往 CDMA、HDR 退，整个注册耗时会明显拉长。

手动模式的 log 则简单得多，能直接看到用户指定的 PLMN 被原样送进选择流程，没有任何降级分支。两种模式的 log 放在一起对比，能很快判断现场那次搜网到底是自动降级导致的慢，还是手动锁死导致的失败。

4. 扫频、小区搜索与小区选择：LTE 和 WCDMA 两条路径拆开看

MM 收到注册请求后，按initial_rat发rrc_service_req激活对应协议栈，接入层开始干活。这一步是整个流程里最“物理”的部分，也是 log 最密的部分。LTE 和 WCDMA 虽然目标一样——从一个频点找到 PCI/PSC，再判断能不能驻留——但实现路径差别很大，混在一起看容易乱，拆开看反而快。

4.1 LTE 扫频：system scan 与 band scan 的取舍

LTE 的扫频分两种。band scan 是把整个频段按可能的 EARFCN 挨个扫一遍，耗时最长但最全；system scan 是频点扫描，只扫已知的、曾经成功驻留过的频点。后者依赖一个叫 acq_db 的数据库，存在 efs 里，每次找到合适小区就把 PLMN 和频点写进去，下次开机优先扫这些频点。

代码里用枚举区分这两种范围：

typedef enum { SYS_SCAN_SCOPE_NONE = -1, /* 内部使用，不对外 */ SYS_SCAN_SCOPE_FULL_BAND, /* 全频段扫描 */ SYS_SCAN_SCOPE_ACQ_DB, /* 只扫 acq_db 里的频点 */ SYS_SCAN_SCOPE_MAX } sys_scan_scope_e_type;

MM 发给 RRC 的 service request 里会带上scan_scope字段，值为 1 时对应全频段。这个设计的意义在于开机速度：有 acq_db 的情况下，几十毫秒就能锁定频点，不用把整个频段穷举一遍。代价是 acq_db 会“记住”旧信息——换城市之后如果还优先扫旧频点，扫不到才回退全频段，中间的等待就白花了。

4.2 LTE 小区搜索：PSS 定时、SSS 定帧、合成 PCI

频点定下来之后，下一步是在这个频点上找到小区。LTE FDD 的无线帧是 10ms，含 10 个子帧、20 个时隙，每个时隙 7 个符号（常规 CP）。同步信号分两级：

PSS 在子帧 0 和子帧 5 的第一个时隙的最后一个符号上发送，一帧里有两次且完全相同。终端匹配到 PSS，只能确定 5ms 的定时边界，还不知道是帧头还是帧中间。

SSS 紧挨在 PSS 前一个符号，但子帧 0 和子帧 5 上的 SSS 序列不同。终端在 5ms 边界的基础上盲检 SSS，解出来之后既知道这是子帧 0 还是子帧 5，也就确定了 10ms 帧的起点，帧同步完成。

PCI 由两部分拼成：PSS 携带组内 ID（0~2），SSS 携带组 ID（0~167），最终 PCI = 3 × 组 ID + 组内 ID，范围 0~503。log 里看到的physical cell ID 422，反推就是组 ID 140、组内 ID 2。

20:10:27.679 LTE RRC/Low [ lte_rrc_csp.c 6509] CSP: Acq requested on earfcn 41292 20:10:27.720 [C4] 0xB115 LTE LL1 SSS Results EARFCN = 41292 | 0| 6153| 422| Normal| Pre| 826| 243984| 0| 20:10:27.720 LTE ML1/High [ lte_ml1_sm_acq.c 3640] Acq search results for bin 0: 6 cells found 20:10:27.753 LTE RRC/Low [ lte_rrc_csp.c 27463] CSP: Acq succeeded on physical cell ID 422 on earfcn 41292 20:10:27.766 LTE RRC/Low [ lte_rrc_csp.c 29513] CSP: Adding cell to Acq DB

这几行的顺序值得记：先发 Acq 请求，L1 回 SSS 结果（一次可能带出多个候选小区），RRC 挑一个上报成功，最后写进 acq_db。Acq search results for bin 0: 6 cells found说明一次搜索扫出了 6 个候选，最终只有 PCI 422 被选中——选择依据就是后面小区选择那一步。

4.3 WCDMA 扫频：raw scan 定范围，fine scan 定频点

WCDMA 的扫频多一层。acq_db 的逻辑和 LTE 一样，命中就优先扫；没命中走频段扫描，而频段扫描又分粗扫和细扫两步。

raw scan 按固定步长把整个频段大致过一遍，得到一组按信号强度排序的频点；然后以最强的那个频点为中心，在它周围一定范围内做 fine scan，细扫一遍再重新排序，从最好的频点开始做小区搜索。已经扫过的区域会被标记，后续扫描直接 skip 掉，避免重复劳动。

08:32:05.272 WCDMA RRC/High [ rrccspdb.c 3318] WBP: Adding ACQ DB band 16 to prioritized band list 08:32:05.273 WCDMA RRC/High [ rrccspdb.c 2169] Acq DB Freq 10750 NOT scanned. Scan 08:32:05.357 WCDMA L1/High [ srchacq.c 3303] ACQ_CNF: Failure on freq=10750 fail type 0 rxagc = -106 08:32:06.233 WCDMA RRC/High [ rrccspdb.c 3350] LFS_COOS: Exhausted list scan db. 08:32:07.327 WCDMA L1/High [ srchfs.c 1471] SRCH type 0 the raw and fine scan thresholds are -103 and -48 08:32:07.526 WCDMA L1/High [ srchacqproc.c 866] ACQ SUCCESS! FREQ:10700 PSC:100 STTD:0 PROC:0

ACQ_CNF: Failure ... rxagc = -106说明这个频点的接收电平太低，直接判失败，不用再往下做同步。LFS_COOS: Exhausted list scan db是 acq_db 扫完的标志，从这之后才进 raw/fine scan。raw and fine scan thresholds are -103 and -48这两个门限值决定了哪些频点能进候选，现场如果发现某些弱信号小区始终搜不到，先确认这里的门限是不是被改过。