简介：面向5G/移动通信协议开发与Modem调试工程师，这份PPT围绕高通平台开机后的搜网注册流程，按初始化、PLMN/RAT选择、扫频/小区搜索/小区选择、随机接入/RRC连接建立/注册四大部分展开，并结合QMI日志、NAS/MM日志与policyman、SD模块决策输出，解释双卡/多卡、多网多制式环境下终端如何找到并附着到合适网络。对于分析无服务、掉网、异常驻留等场测问题，能提供清晰的排查思路。资源为1个pptx演示文稿，压缩包1.59MB，以流程结构图、阶段划分表和关键日志截图为主，适合在培训或自研学习时快速过一遍完整时序。已有5124人学习下载，适合刚入门Modem协议、或需要系统梳理开机搜网注册全过程的移动通信研发、测试与技术支持人员。

1. 搜网注册：为什么每次开机都是一场系统级的“三权分立”

大多数开发者把搜网注册当成一个动作：开机，信号栏跳出来，完事。但在这套modem协议栈内部，这是一次横跨至少六个模块的接力决策——SIM卡身份、NV/EFS配置、运营商策略、服务决策、PLMN选择、接入层执行，任何一个环节的判断偏差，最终都表现为用户感知的两个字：无服务。反直觉的地方在于：你看到的“信号秒出”，绝大多数时候是历史和位置的功劳，而不是搜网真的变快了。真正从零开始的首次搜网，耗时可能比你想象的长一个量级。搞懂这条链路的底层逻辑，不只是为了看日志，而是为了在掉网、驻留失败、注册被拒这类问题上，能准确判断“是哪一层错了”。

2. 初始化与PLMN/RAT选择：SIM卡、NV、policy和SD模块如何决定注册去向

搜网注册的第一步不是扫频，而是先回答一个问题：你是谁，你属于哪个网络，你能用哪些制式。这个答案由初始化阶段的多模块协作拼出来——SIM卡提供身份，NV/EFS提供平台能力，MBN提供运营商配置，policyman执行策略，SD模块最终给出服务获取的制式优先级。任何一个输入错误，后面所有流程都会在错误的前提上运行。

2.1 初始化链路：从CARD_INSERTED到MMR_SIM_AVAILABLE_REQ的模块接力

上电或插卡后，第一个动作是卡检测。MMGSDI模块会先触发CARD_INSERTED，设置sim_available_status，随后等待USIM应用就绪。这个阶段的关键日志锚点如下：

02:42:32.119 [mmocmmgsdi.c 2072] =MMOC= CARD_INSERTED: Set sim_available_status on sub 02:42:32.128 [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 02:42:34.936 [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 02:42:34.939 [policyman_policy.c 224] subs 0: ----------- Finished executing policy 1101.2.7 (8 ticks) 02:42:34.935 [mcfg_uim.c 2379] Selecting config using IMSI MCC=460 MNC=1 02:42:34.949 [mcfg_utils.c 913] Config: C3I_CN-LA-7+7_mode-SDM439

这套日志的顺序本身就说明了依赖关系：MMGSDI先确认USIM应用就绪，policyman才能从卡里读出IMSI并解析出PLMN（MCC 460、MNC 1），之后MCFG拿着这个IMSI去匹配MBN配置，选中的配置名会直接打在日志里（C3I_CN-LA-7+7_mode-SDM439）。MBN在这里扮演的角色，是“运营商级配置文件”——同一套modem软件跑在全球不同网络上，频段组合、VoLTE开关、CA能力、射频校准参数全都不一样，MBN按IMSI做了一次配置下发。加载错MBN，后面可能表现为某个频段扫不到、VoLTE注册被拒，这类问题在分析现场时最容易被误判成射频硬件故障。

policy执行完成后，NAS REG层发出MMR_SIM_AVAILABLE_REQ，MM层确认IMSI合法后回CNF。到这里，身份信息才正式可用。紧接着SD模块开始做服务决策——它输出的rat_acq_order就是后续搜网的制式顺序依据：

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.037 [sdss.c 55167] =SD= adding rat 4 to rat_acq_order index 4 02:42:35.037 [sdss.c 55167] =SD= adding rat 11 to rat_acq_order index 5

rat_acq_order里9代表LTE、5代表WCDMA、3代表GSM，后面又追加了2（1x）、4（HDR）、11（eHRPD）。这份列表的本质是SD模块根据当前可用的接入技术组合给出一个“尝试顺序”，它决定了后续如果第一优先级制式注册失败，下一步该往哪个制式走。

2.2 PLMN选择：3GPP 23.122的优先级顺序与REG模块的函数映射

PLMN选择的规则定义在3GPP 23.122里，不复杂，但顺序的优先级很关键。自动模式下，协议规定的选择顺序是：RPLMN（上次注册的PLMN）→ HPLMN（归属PLMN）→ UPLMN（用户控制的PLMN）→ OPLMN（运营商控制的PLMN）→ Other PLMN/低优先级PLMN。手动模式则完全不同：优先使用用户指定的PLMN；如果没有指定，退回RPLMN；如果RPLMN为空，就驻留一个能接受的小区获取limited service。

高通平台的实现把这些规则映射到了REG模块的具体函数里，入口是reg_state_process_cm_service_req——CM层把不同类型的请求分发给REG，开机或无服务时传的是service request，在该函数下根据手动/自动类型分流：

• RPLMN及RAT：Reg_mode_plmn_selection.c中的start_plmn_selection函数
• HPLMN及RAT：Reg_mode_automatic_plmn_selection.c中的start_automatic_plmn_selection函数
• Preferred PLMN及RAT：Reg_mode_higher_priority_plmn_selection.c中的start_higher_priority_plmn_selection函数
• 手动模式用户指定：Reg_mode_manual_plmn_selection.c中的start_manual_plmn_selection函数
• 其他情况：直接调用reg_mode_start_limited_service获取限制服务

我一般会这么理解这个设计的动机：RPLMN优先于HPLMN，不是一个随意的选择，而是“最快恢复服务”和“归属优先”之间的妥协。RPLMN是上次成功注册的网络，用户大概率还待在同一个位置，优先尝试它是成本最低的路径；只有RPLMN搜不到或注册被拒，才轮到HPLMN。这也解释了为什么换卡后第一次开机总是比平时慢——RPLMN失效，整套选择顺序要从头走一遍。

2.3 RAT选择：NV10、efs文件和SIM卡三方共同拼出的候选列表

选定PLMN之后，要在该PLMN下选RAT。RAT列表的来源是三方的：AP设置的NV10和efs文件共同决定的rat list会随service request一起传到REG模块；自动模式下，REG会在该列表的基础上，再参考SIM卡或NV中保存的rplmn rat或hplmn rat，得到一个最终的顺序列表。刚开始选择列表中的第一个RAT去尝试，注册失败就换第二个，直到该PLMN的所有RAT都试完为止。

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 02:42:35.311 [sdcmd.c 27555] =SD= Mode 2 not supported on any stack

这段日志是RAT选择阶段的真实写照：sys_mode=9即LTE被优先要求，Mode 4（HDR）和Mode 2（1x）因为当前协议栈不支持被直接跳过。选好PLMN和RAT后，REG调用reg_send_mmr_reg_req把请求发到MM模块，搜网的核心接力棒正式交到接入层手里。

在5G NSA/SA叠加的组网环境里，这个RAT list的决策会更复杂——5G偏好设置、ENDC能力开关、运营商配置都会影响最终顺序。常见的情况是：NSA组网下NR不能独立驻留，终端必须先锚定LTE，所以即便用户开了5G开关，rat_acq_order的头部依然是LTE。理解了这个机制，就不会在看到“5G手机搜网先是LTE”时觉得是bug。

3. 扫频与小区搜索：从一段射频信号到锁定一个PCI的物理层机制

选好PLMN和RAT之后，任务变成“在这个制式下找到能用的频点，再锁定一个具体小区”。这一步完全落在接入层：MM收到reg发来的注册请求后，根据initial_rat发送rrc_service_req激活对应协议栈，RRC/RR收到后先激活PDCP/RLC/MAC/PHY，获取频段、CA等能力，然后开始扫频。扫频和小区搜索虽然后台一气呵成，但机制上必须分开看：前者解决“哪个频点值得听”，后者解决“这个频点上的信号到底是谁”。

3.1 LTE扫频：为什么acq_db能显著降低首搜时间

LTE扫频分成两种策略：system scan和band scan。system scan就是频点扫频，每次终端注册或手动搜网时，一旦找到合适小区，会把该频点相关信息（PLMN/freq）保存到efs中的acq_db里；下次开机注册优先使用这些频点搜索小区。band scan则是全频段扫描，作为system scan找不到合适小区时的兜底。

02:41:36.455 [emm_rrc_if.c 552] DS: SUB 1 EMM: Sent LTE_RRC_SERVICE_REQ scan_scope 1

scan_scope参数直接暴露了策略选择，枚举值定义很直白：

typedef enum{ SYS_SCAN_SCOPE_NONE = -1, /* FOR INTERNAL USE ONLY! */ SYS_SCAN_SCOPE_FULL_BAND, /* 全频段扫描 */ SYS_SCAN_SCOPE_ACQ_DB, /* 仅扫描acq_db中的历史频点 */ SYS_SCAN_SCOPE_MAX /* FOR INTERNAL USE ONLY! */ } sys_scan_scope_e_type;

acq_db本质上是“上次成功的位置缓存”。大多数用户的开机地点和上次关机地点一致，优先扫acq_db里的频点就能命中，这就是信号栏“秒出”的真相。但缓存有失效风险：网络重耕、基站搬迁、覆盖优化都会让历史频点失效。acq_db扫完没有合适小区，才落到FULL_BAND全频段扫描，耗时自然上去了。这也是为什么跨省飞行落地后开机，比平时开机要慢——位置变了，acq_db基本全部脱靶。

3.2 LTE小区搜索：PSS确定5ms、SSS确定10ms帧边界的双层同步

从一个频点里的射频信号，到确定具体小区的PCI（物理小区标识），靠的是两级同步。LTE FDD的无线帧长10ms，每帧10个子帧，每个子帧有2个时隙，每个时隙7个符号。PSS（主同步信号）在子帧0和子帧5的第一个时隙的最后一个符号发送——一个系统帧内有2个相同的PSS，所以UE捕获到PSS后，能确定出5ms的timing，但还分不清谁是子帧0、谁是子帧5。

紧接着解SSS（辅同步信号），位置在PSS的前一个符号。关键在于：子帧0和子帧5上的SSS序列是不同的。盲检成功后，UE能区分该SSS位于子帧0还是子帧5，从而确定10ms无线帧的边界，完成帧同步。PSS携带小区组ID（0-2），SSS携带组内物理层ID（0-167），两者组合出完整的PCI，0-503共504个取值。

20:10:27.720 0xB115 LTE LL1 SSS Results EARFCN = 41292 | 0| 6153| 422| Normal| Pre| 826| 243984| | 1| 1842| 418| Normal| Mid| 2137| 244000| | 2| 1487| 421| Normal| Mid| 798| 243984| 20:10:27.720 [lte_ml1_sm_acq.c 3640] Acq search results for bin 0: 6 cells found 20:10:27.753 [lte_rrc_csp.c 27463] CSP: Acq succeeded on physical cell ID 422 on earfcn 41292

这段日志就是两级同步的成果：物理层在EARFCN 41292这个频点上解出了6个候选小区，RRC最终选出PCI 422。之所以设计成PSS+SSS两级而非一次盲检504个PCI，是纯工程考量——一次全搜索的相关运算量在两个数量级以上，而先做3种PSS的粗同步、再做168种SSS的精同步，复杂度显著下降。5G NR保留了同样的PSS/SSS双层同步思想，只是子载波间隔和序列设计更灵活。

3.3 WCDMA扫频与小区搜索：raw scan、fine scan与三步扰码识别

WCDMA的扫频分三层：acq db扫描、raw scan（粗扫）、fine scan（精扫）。raw scan把频段按一定步长粗扫一遍，按信号强度排序，以最强频点为中心，对周围范围再做fine scan；扫过的区域会被跳过，避免重复劳动。fine scan的结果再次按信号强度排序，从第一个频点开始做小区搜索。

08:32:07.327 [srchfs.c 1471] SRCH type 0 the raw and fine scan thresholds are -103 and -48 08:32:07.378 [srchacq.c 3684] ACQ REQ:Rx AGC -76 Chan 10700 band 1024 08:32:07.526 [srchacqproc.c 866] ACQ SUCCESS! FREQ:10700 PSC:100 STTD:0 PROC:0 08:32:07.820 [rrccspdb.c 1641] Updated: PLMN 204-16 freq 10700 scr_code 1600 band 1024 in Acq DB

扫到频点只是拿到了“模拟信号”，要识别出具体小区，WCDMA走的是三步同步：第一步时隙同步——P-SCH信道上每个时隙前256 chips的主同步码是相同的，用本地主同步码做匹配滤波就能找到每个时隙的开头；第二步帧同步和主扰码组识别——64组辅助同步码和64组主扰码组一一对应，在时隙边界捕获S-SCH，15个时隙凑出一个辅助同步码组，检测运算后得到帧边界和对应的主扰码组；第三步主扰码确定——用组内8个主扰码分别与P-CPICH做相关运算，解出小区的主扰码。

WCDMA这套三步走的本质，是把“从512个扰码里找出一个”拆成“先64选1，再8选1”的两级搜索，相关器数量从512路降到72路以内。这和LTE的PSS/SSS双层同步是同一个工程哲学：先粗后精，用廉价操作缩小候选集，再做精确定位。理解这一点，就能明白为什么WCDMA小区搜索在3G时代被称为“三步捕获”——它不是为了教学方便，而是为了在DSP算力有限的年代把搜索成本压到可接受范围。

4. 小区选择、随机接入与RRC连接建立：从驻留到附着的关键一跳

同步过程解出小区之后，终端马上开始接收并解析广播消息，根据解出的信息判断该小区是不是suitable cell。找到了不等于能用——终端还必须驻留到该小区，在公共信道上完成随机接入和RRC连接建立，才能把NAS层的注册请求送进核心网。这一段是“找到网络”和“用上网络”的分水岭。

4.1 小区选择：PLMN匹配、S准则与suitable cell的判定链

小区选择的第一关是PLMN匹配。RRC从广播消息中解析出小区归属的PLMN，和REG层下发的请求PLMN做比较。日志里的体现很直白：

20:10:27.765 [lte_rrc_sib.c 17822] Received ind has SIB1 for phy_cell_id = 422 & freq = 41292 20:10:27.766 [lte_rrc_csp.c 29285] CSP: Received SIB1 20:10:27.766 [lte_rrc_csp.c 16100] CSP: PLMN match from EHPLMN list= MCC: [3 1 0 ] MNC: [1 2 0 ] 20:10:27.766 [lte_rrc_csp.c 16213] CSP: Cell Suitable for EHPLMN/HPMN/REQ PLMN

PLMN匹配通过后进入第二关：S准则。S准则解决“这个小区的信号质量够不够格”的问题，核心变量是Srxlev。日志中能直接看到判决现场：

20:10:27.840 [lte_rrc_csp.c 29095] CSP: q_rxlevmin = -128 qrxlevmin_offset = 0 20:10:27.840 [lte_rrc_csp.c 29106] CSP: p_Max = 27 in SIB1 20:10:27.840 [lte_rrc_csp.c 29158] CSP: Rel9 q_qualmin = -34 q_qualmin_offset = 0 20:10:27.843 [lte_ml1_sm_idle.c 5112] Cell (41292,422) Srxlev 17, rsrp -107 rsrq -15 qrx -128 qrx_off 0 pmax 27 pcomp 4

手算一下：RSRP实测-107dBm，q_rxlevmin是-128dBm，pcomp为4dB，Srxlev = -107 - (-128) - 0 - 4 = 17dB。Srxlev是正值，说明信号电平满足驻留门限。同时q_qualmin还约束了信号质量（RSRQ），防止驻留到“信号强但质量差”的干扰小区。S准则通过后，RRC下发cell select request，物理层配置公共信道，最终驻留：

20:10:27.843 [lte_rrc_csp.c 31559] CSP: Suitable cell 20:10:27.853 [lte_rrc_csp.c 25289] CSP: Camped on physical cell ID 422 on earfcn 41292

这套双门限设计的价值在于：LTE是自干扰系统，RSRP高不一定代表可用。如果在干扰严重的区域只看RSRP，终端会驻留到一个下行信号强但上行完全没法用的小区。加上q_qualmin这个质量门限，等于多了一道防线。

4.2 基于竞争的随机接入：preamble、RAR窗口与功率攀升

驻留成功之后，接入层上报camped指示给非接入层（MM/EMM），MM根据当前状态触发LU/Attach流程。但此时小区只分配了公共信道，注册的OTA消息需要在专用信道上发送——终端和基站交互建立专用信道的过程就是RRC连接建立。而要在公共信道上成功发出RRC连接请求，必须先和基站完成上行同步，这就是随机接入。

LTE随机接入参数全部来自SIB2：最大发射功率、最大传输次数、功率攀升步进、RAR窗口大小。终端初始接入属于基于竞争的随机接入场景。竞争接入的完整流程是：UE发送随机接入preamble → 基站回RAR响应（包含上行授权和TA调整） → UE在授权资源上发MSG3 → 基站回竞争解决消息。日志里能看到发射端的完整参数上下文：

20:10:27.844 [lte_rrc_llcdb.c 7285] Preamble Initial power -110 20:10:27.844 [lte_rrc_llcdb.c 7198] Power ramping step 4 20:10:27.844 [lte_rrc_llcdb.c 7152] Preamble trans max 10 20:10:27.933 [lte_mac_rach.c 693] rach_send_preamble cur_raid=20,pwr_lvl=-110,attemp

我第一次看到preamble初始功率-110dBm时也觉得意外——为什么从这么低的功率开始？原因在于随机接入信道是所有UE共享的，如果大家都按最大功率发射，互相干扰且浪费电量。从低功率开始，收不到RAR就按步进4dB逐次攀升，直到基站能解出preamble为止。这背后是“最小充分功率”原则：用恰好够用的功率完成接入，而不是一上来就满功率轰。这个机制也是排查“随机接入一直失败”问题的重点——很多现场问题不是物理层真故障，而是preamble初功率配置和功升步进搭配不合理，导致重传耗尽trans max。

4.3 RRC连接建立与Attach触发：公共信道到专用信道的切换

随机接入完成上行同步后，终端才能在公共信道上发出RRC连接请求。RRC连接建立的三条消息是RRCConnectionRequest、RRCConnectionSetup、RRCConnectionSetupComplete，成功后网络为终端配置专用信令承载。从MM层视角看，RRC建立成功后才会触发真正的注册流程：

20:10:27.855 [emm_rrc_handler.c 3260] =EMM= RRC_SERVICE_IND - MCC: D1 3, D2 1, D3 0 MNC: D1 1, D2 2, D3 0 20:10:27.862 [emm_utility.c 8776] =EMM= reg allowed - 1 20:10:27.869 [emm_reg_handler.c 3901] MM sent MMR_CAMPED_IND RAT: 2, BAND 40 20:10:27.928 [emm_update_lib.c 1731] =EMM= Start Attach procedure, invalidate the security context

注意最后一行“invalidate the security context”——每次开机首次Attach都没有现成的安全上下文，必须重新协商。这也是为什么开机后的第一次attach明显比后续的TAU慢。RRC连接建立和Attach是两层的事：RRC连接解决的是“接入网层有没有专用信道给你传信令”，Attach解决的是“核心网认不认你这个身份”。先有随机接入，再有RRC连接，最后才有注册消息——这个顺序不能乱，任何一个环节失败，整个搜网注册流程就停在原地。

5. 搜网注册排查：无服务与掉网场景的常见坑与定位方法

分析无服务和掉网问题，最容易犯的错误是直接从射频层开始查。但搜网注册是分层的，每层都有明确的日志锚点——先确认卡和policy层是否就绪，再看PLMN/RAT选择是否正确，然后看扫频和小区搜索有没有结果，最后看随机接入和RRC建立卡在哪一步。以下四个坑是我在实际分析中反复遇到的。

5.1 SIM就绪但迟迟不发起注册：先查policy是否执行完成

现象：日志里MMGSDI_SUBSCRIPTION_READY_EVT已经打印，SIM卡状态正常，但后续始终没有MMR_SIM_AVAILABLE_REQ，终端一直无服务。

原因：卡就绪不代表策略就绪。policyman执行卡住、MBN配置没有正常加载、或者SD模块在等待某个输入时阻塞，都会导致REG收不到SIM available的确认，整个注册流程根本启动不了。

解决：不要急着查射频。先确认日志中policyman_policy.c的Started和Finished两条成对出现，再看MCFG是否打印了正确的config名。如果Finished缺失，说明policy执行异常，需要核对policy版本和SIM卡IMSI是否匹配；如果config名不对，说明MBN选择逻辑出了问题。我一般会先看这两处日志再决定下一步，能过滤掉一大半“假无服务”。

5.2 扫频正常却一直acq failed：频段能力与band gap不匹配

现象：RRC层不断打印“Acq requested on earfcn XXX”，物理层随后返回ACQ_CNF failure或者完全没有SSS结果，终端反复扫同一个频点但始终无果。

原因：扫频请求发出去了，但该频点对应的频段不在射频前端支持范围内，或者NV里的band capability位图缺失。常见于MBN错配——加载了不支持该频段的运营商配置，软件仍按某些条件发起扫描，但物理层根本没有对应的射频通路。

解决：在日志里核对目标EARFCN所属的band和终端的band capability。如果band gap明确不匹配，问题大概率在配置而不是硬件。查MBN加载是否正确、NV中的band支持项是否被意外覆盖。这类问题最容易被误判成“射频摔坏了”，实际上只是配置层的一次错位。

5.3 随机接入反复失败：先查SIB2参数而不是射频

现象：preamble发送后收不到RAR，功率攀升到trans max上限后放弃，终端回到idle重新搜网，周而复始，attach始终起不来。

原因：驻留成功了，但上行链路能力不足。常见原因包括SIB2中配置的preamble初始功率过低、功升步进太小、RAR窗口过短，以及小区选择时q_rxlevmin设置过低导致驻留到实际上行不可用的弱覆盖小区。

解决：先看SIB2下发的那组参数——preamble初功率、power ramping step、trans max、RAR窗口大小，和同小区正常终端的参数做对比。如果参数一致但依然失败，再看上行干扰和TA（时间提前量）是否有异常。随机接入失败的原因大多在参数和覆盖，发生在射频硬件上的概率反而低。

5.4 5G叠加场景：NSA/SA切换时的RAT list顺序问题

现象：5G终端在NSA锚点站覆盖范围内频繁搜网，掉网后恢复耗时明显偏长，或一直停留在LTE上回不到NR。

原因：5G叠加组网下，rat_acq_order不再是一个简单的LTE/WCDMA/GSM序列。5G偏好开关、ENDC能力、运营商策略都会参与RAT排序。NSA组网NR不能独立驻留，必须先锚定LTE再添加NR载波；如果配置允许SA，终端又需要在PLMN选择阶段就识别出支持SA的PLMN。一旦RAT list顺序和实际覆盖不匹配，终端就会在“尝试错误制式→失败→回退”的循环里消耗时间。

解决：先抓SD模块的rat_acq_order日志，确认当前期望的顺序，再对比实际射频环境的覆盖（哪些制式真有信号）。如果期望顺序里排第一的制式在该位置根本没有覆盖，问题不在搜网逻辑，而在配置——需要核对5G偏好设置和运营商MBN中的RAT优先级。分析这类问题要多问一句：“这个顺序是该位置应该有的顺序吗？”

6. 搜网注册的设计取舍：为什么把决策权拆给这么多模块

把搜网注册拆成初始化、PLMN/RAT选择、扫频搜小区、随机接入注册四步，表面看增加了跨模块调用的复杂度，但这套分层设计有它清晰的取舍逻辑：每一层只回答一个问题。SIM卡和policy回答“我是谁”，NV和MBN回答“我能用什么”，SD回答“我优先去哪”，REG回答“按什么顺序试”，接入层回答“怎么找到并登上那个小区”。这样的切分让运营商定制能力停留在配置层而不是代码层——换一个运营商网络的适配工作，从改代码变成了换MBN、调policy，这在量产项目里是决定交付周期的事。

代价也很明显：问题定位必须跨模块追踪。一次无服务，可能是policy没执行完、可能是RAT列表错配、可能是acq_db失效导致全频段扫描超时、也可能是随机接入参数不合理。我早期分析一个掉网问题，花了半天查射频指标，最后发现是policy版本没加载导致SD输出了一个空的服务顺序。从那以后，我每次分析无服务和掉网，都强制自己从头到尾过一遍四步流程——先确认每个环节的日志锚点是否按预期出现，再谈硬件和参数。这套“按链路排查、先证据后结论”的习惯，帮我过滤掉了大量所谓的疑难杂症。希望帮到你。

这份资源里对每一步都附了对应的日志和代码路径，把这篇文章里的判断锚点对照着文档再走一遍，你会对搜网注册这条链路建立起真正端到端的感知。

本文还有配套的精品资源，点击获取