做通信设备认证这个方向久了你会发现一个很有意思的现象圈子里很多工程师都知道设备出厂要拿进网许可但真要问一句进网检验检的是什么、核心网设备到底走哪条认证路径、IMS网元送检时要准备哪些东西多数人只能给个大概。尤其是这两年IMS相关项目明显变多VoLTE/VoNR、应急通信、融合通信这些业务全都压到核心网上进网检验和进网许可认证的关注度一下子又回来了。这篇文章我就基于经手过的项目把IMS设备和核心网的进网检验要求、进网许可认证再完整梳理一遍给新入行的测试工程师、准备送检产品的研发团队和刚接手合规工作的项目经理作个参考。内容不会讲得太教科书更多是我实际跑过流程后提炼出来的要点。1. 进网检验与进网许可认证先把这两件事拆清楚1.1 检验是技术动作认证是行政结果很多人把进网检验和进网许可认证当成同一件事其实这是两个层次。进网检验本质上是技术检验活动检验机构按照既定的技术规范、测试标准对送检设备的性能、协议、业务功能、安全能力进行测试验证最终输出一份检测报告。检验本身解决的是这台设备符不符合技术门槛的问题。进网许可认证则是基于检验结果和文件审核由主管部门作出行政审批决定。通过之后会拿到进网许可证或进网许可批文设备才被允许接入公用电信网使用。在实际操作里这个时间顺序是固定的先送检、拿到合格报告再提交认证申请、完成审核最后发证。但很多团队容易忽略的一点是检验报告并不是认证的唯一依据企业资质、产品一致性、质量体系文件这些都要同步审查。换句话说技术合格只是拿证的必要条件不是充分条件。1.2 哪些设备需要走这条路径不是所有通信设备都要走进网许可。按我的经验需要重点关注的主要是三类第一类是电信终端设备包括手机、固定电话、VoIP终端这些直接面向用户的设备。第二类是无线电通信设备凡是带无线发射模块的基本都要纳入管理。第三类是涉及网间互联或公用电信网接入的网络设备这其中包括了IMS核心网设备、EPC/5GC核心网设备、接入网设备等。你会发现纯粹的内部组网设备、企业自用不接入公网的设备一般不在强制进网许可范围内。但IMS设备比较特殊——它只要承载了公用电信网的VoLTE/VoNR业务就必然涉及网间互联和公网接入所以基本都躲不开这个流程。有一个常见误区是我是做纯软件功能的比如在通用服务器上部署的vIMS是不是不用进网实际看下来只要这个vIMS实例要接入公网并对外提供业务逻辑上仍然要按网络设备对待。具体怎么执行要看产品的落地形态和主管部门的具体分类口径不能自己拍脑袋跳过。1.3 为什么IMS和核心网的进网要求越来越被重视早些年和核心网打交道的人更多关注的是EPC、HSS、PCRF这些网元IMS在当时还不是主角。现在不一样了语音业务全面IP化VoLTE/VoNR成为基础业务IMS从可选组件变成了核心网里天天要用的关键系统。业务地位上来之后检验要求自然跟着变。IMS涉及的协议栈更多SIP信令、Diameter信令、RTP/RTCP媒体流、与PCRF的Rx接口、与HSS的Cx/Sh接口任何一个环节出问题都直接影响用户语音体验。而进网检验的标准也在不断补充针对IMS的功能测试、协议一致性测试、互操作测试项这就让送检的复杂度和工作量明显上升。关注度上升的另一个原因是从业人员的流动。通信行业这几年的新人更多是互联网背景出身对SIP注册流程、TAU信令流程可能反倒不熟悉而进网检验又恰恰最爱在这些基础流程上设卡。后续第4部分会专门讲这几个高频翻车点。2. IMS设备进网检验的项目范围从网元拆到测试项2.1 送检对象怎么划分才算合理IMS不是一个单一设备而是一套网络架构。送到检验机构之后首先要解决的就是以什么为单位送检的问题。常见的做法是按网元功能划分送检单元。比如P-CSCF送检一个单元S-CSCF/I-CSCF送检一个单元HSS送检一个单元MRF送检一个单元。如果产品是软交换形态把多个网元打包在一个集成系统里也可以按系统整体送检但这时候检验范围和测试项会更复杂耗时也更长。我的建议是尽量按最小可独立检验单元来规划送检。这么做的好处是问题定位更精准某一块不合格时不需要整个系统打回重测。缺点是证书可能会分成多张后续维护时要注意对应关系。还有一点要注意的是版本一致性。同一个型号下面可能有多个软件版本同一个软件版本又可能跑在不同硬件平台上。送检时要明确送检样机所代表的软硬件组合而且是代表性组合而不是全家桶。一旦检验通过这个组合就是你后面的质量基线。2.2 检验项目的五个维度IMS设备进网检验的测试项归纳下来基本逃不出五个维度业务功能VoLTE/VoNR通话建立、呼叫保持与恢复、呼叫转接、多方通话、补充业务、紧急呼叫等。这部分是最核心的几乎每一个主流程和补充流程都会被过一遍。协议一致性SIP/RFC 3261及其扩展、SDP offer/answer、IMS相关的3GPP TS 24.229、NAS信令中的IMS相关流程。协议一致性在检验里的权重很高也是最容易抓出问题的地方。互通性IMS网元与终端、与其他核心网网元、与外部PSTN/PLMN网络的互通表现。比如不同终端的SIP消息兼容性、编解码协商、DTMF传输方式等。接口能力Gm接口、Mw接口、Cx接口、Sh接口、Rx接口、Mb接口等各类接口的信令流程以及接口异常处理能力对方网元故障时的表现。安全与EMC设备安全能力、加密算法支持、整机电磁兼容性能、电气安全指标。这是很多纯软团队容易忽略的部分他们总觉得软件产品不用考虑EMC但只要是实际运行的硬件设备这一关就躲不过。这五个维度里业务功能测试的用例数量最多协议一致性测试的通过难度最大安全和EMC反而是相对稳定的只要选型时没过期基本不会出幺蛾子。2.3 协议与接口的抽查重点进网检验不会像实验室开发测试那样把整个协议栈全跑一遍但会挑最有代表性的流程来抽查。以我的观察这几个点被抽中的概率最高第一个是SIP注册和重注册流程。包括初始注册、挑战鉴权401/407、重注册、注销。这个流程是IMS业务的前提任何不规则处理都可能被揪出来。第二个是会话建立的完整信令链。从终端发出INVITE开始经过P-CSCF、S-CSCF到被叫侧振铃、应答、会话建立再到BYE释放。检验时会特别关注早期媒体、183响应、PRACK/ UPDATE这些细节。第三个是紧急呼叫相关的信令流程。紧急呼叫在进网检验中是高优先级项因为它涉及公共安全标准也卡得最严。第四个是Cx接口上的注册和位置管理流程。HSS与S-CSCF之间的UAR/UAA、MAR/MAA等在检验中也是常客尤其是鉴权向量的拉取、漫游场景下的用户路由。需要说明的是不同检验机构的抽测重点会结合送检设备类型和当前技术热点有所调整但这个范围基本覆盖了主要风险点。建议送检之前先按这个范围做一轮内部自查比进实验室再被动发现问题效率高很多。3. 进网许可认证的完整链路申请、送样、测试、审核、拿证3.1 送检前需要准备的核心材料很多项目卡在第一步不是设备不行是材料不行。根据我踩过的坑进网许可认证的材料准备清单至少要覆盖以下几类企业资质类营业执照、相关行业资质文件、质量管理体系证明ISO9001之类的认证通常会被要求提供。产品基础资料设备型号命名规范、产品说明书、硬件组成清单、软件版本说明、关键器件清单。技术文件设备技术规格书、接口规范说明、信令流程文档、组网应用说明。测试与一致性声明企业内部测试报告、与进网检验依据标准相关的符合性声明。授权与承诺文件代理申请授权书如果是代理机构办理、产品质量承诺书。材料方面最常见的坑有两类。一是型号命名冲突同一个产品在不同市场用了不同型号但送检文件的型号和企业其他备案不一致导致审不过。二是技术文件与送检实物不一致比如说明书里写的接口类型和实际样机接口对不上这在现场审核时非常被动。所以我的习惯是送检前专门安排一个人做文件-样机一致性核查把技术文件里的参数逐个对着样机过一遍这个环节省不得。3.2 样机与软件版本的锁定送样不是把设备寄过去就完了最关键的是锁定版本信息。样机上的软件版本号、硬件版本号、Bootloader版本、配置文件版本每一项都要记录清楚并且和送检申请文件里填的内容保持一致。检验机构会对手报版本和实际版本做核对不一致会直接触发退审。版本锁定的另一层含义是测试期间不允许变更。如果测试进行到一半你发现了一个严重bug想升级版本这时候要特别谨慎。要么申请暂停测试、更新送检版本后重新开始要么等当前轮次测完、拿证后再走变更流程。绝对不能做的是偷偷升级样机软件还不报备这属于检验过程中的重大变更一旦发现后果很麻烦。建议团队在送样前就完成内部研发冻结至少冻结出一个稳定分支确保送检期间研发团队不会往这个分支上再加代码。我见过不止一次因为研发顺手合了个patch导致样机软件版本和申请文件不一致的case最后只能重新送样白费两周时间。3.3 测试过程中的质量控制点测试过程通常按项目管理的方式来跟踪但有几个质量节点需要额外关注。第一个节点是预测试结果评审。正式检验前检验机构一般会先做一次摸底或者目击预测试这个阶段发现的问题修复成本最低。别把预测试当走过场认真对待。第二个节点是主测试程中的fail项处理。测试用例fail之后检验机构会给正式报告这个时候需要提交整改说明。整改有两个选择一是修改软件后重新测试相关用例二是维持原样并提交合理说明比如标准解读差异。后者难度比较大除非你非常有把握否则建议直接改。第三个节点是现场审核。检验机构会派人到生产现场核查生产能力、质量保证体系、测试设备校准记录等。这一关不是看你技术多先进而是看你的生产流程是否规范。现场审核最怕的是账实不符台账写了一套流程实际操作又是另一套这种情况很容易被判不合格。整个测试过程建议每天记录项目日志包括当日完成的用例、fail项、与检验机构的沟通结论。这不仅能帮你追踪进度在后续整改和复审时也有据可查。3.4 拿证之后的版本变更合规拿了证书不代表万事大吉。证书对应的是一个特定版本的设备后续如果软件版本升级特别是涉及协议栈、业务逻辑、安全能力这些核心模块变动的升级需要评估是否要重新检验。我遇到过一家做融合通信网关的厂商老版本证书还在有效期内他们升级了底层操作系统版本自认为不影响通信功能就没有报备。后来在一次市场投标中被对手质疑证书有效性虽然最后通过补充测试解决了但整个流程走下来非常被动。我的建议是建立一套版本变更评估清单协议栈变更、操作系统大版本升级、硬件平台变更、核心业务流程调整这四种情况都要触发重新评估。评估结论分两种一种是确认不影响证书覆盖范围保留书面记录另一种是安排变更测试或重新送检不要存在侥幸心理。4. 核心网测试中三个高频翻车场景IMS注册、TAU、终端对接4.1 IMS注册的REGISTER流程为什么容易出问题IMS注册是整个IMS业务的基础也是进网检验里的必考题。但恰恰是这个基础流程很多设备在测试中会栽跟头。常见翻车点有几个第一个是Challenge处理逻辑不对。标准流程里REGISTER请求发出后会收到401或407挑战客户端需要用正确的算法通常是AKAv1-MD5计算响应再发起第二次REGISTER。有些实现在这个环节会写死算法或者对收到的nonce格式解析不严格导致认证失败。测试中表现为终端一直没过鉴权注册不上。第二个是Security Client/Server头字段的协商。3GPP TS 24.229里对Security头的要求很明确但有些实现只处理了sec-agree的某个分支忽略了可选分支导致某些终端兼容不了。第三个是注册过期时间处理不规范。REGISTER里的Expires字段、服务端返回的200 OK里的Expires字段、以及后续重注册的提前量这部分逻辑做不严谨的话会出现用户明明在网却已经被服务端判为离线的诡异问题。针对这个场景我的建议是送检前用至少三款不同厂家的终端做一轮IMS注册测试不要只用自己实验室里那台测试手机。因为不同终端在SIP消息构造上的差异很大服务端容错差的设备很容易在跨终端测试中暴露问题。4.2 TAU流程在跨跟踪区场景下的几个老大难核心网tau是最近搜索热度不低的关键词也确实值得展开聊聊。TAU是EPS移动性管理里的跟踪区更新流程在IMS时代它依然是核心网侧判断用户可达性的重要机制。进网检验涉及TAU相关测试时最容易踩的坑集中在以下几点。一个是GUTI重分配的处理。MME在TAU Accept消息里可以携带新的GUTI但有些核心网实现只做了下发没有处理终端在后续消息里使用新GUTI的情况导致TMSI解析失败、上下文丢失。另一个是跨MME的TAU流程。这时候要发生MME之间的上下文传递如果两个MME的实现来自不同厂商对某些信息元的打包和解析方式不一致就会出现白名单式的互通bug——A厂商的MME和B厂商的MME配合没问题换一个厂商就崩。还有一个是周期性TAU与寻呼冲突。用户处于空闲态时如果周期性TAU定时器和寻呼流程撞在一起某些核心网实现会漏发或者重复发送导致终端状态错乱。TAU流程本身不算复杂但涉及的状态多、交互网元多测试时建议把全网元的日志同步抓取时间对齐到毫秒级否则排查起来会很痛苦。4.3 终端IMS注册失败先别急着查核心网现在搜pixel ims 注册不了pixel ims 注册ims这类关键词的人很多基本都是终端侧的IMS注册问题。做核心网测试的人看到这类问题容易下意识觉得是网络侧不支持但实际排查下来终端侧导致注册失败的原因占了相当大的比例。我总结过几类高频终端侧原因终端IMS配置缺失或错误APN设置里没有IMS APN或者APN类型不带ims导致终端根本没有发起IMS注册的意图。VoLTE开关状态有些终端把VoLTE开关默认关闭或者系统的增强通话模式没有开启表面上看是注册不了实际是终端根本没尝试注册。运营商预设文件与当前SIM不匹配终端内置的运营商配置文件只适配了特定网络换了网络之后配置不生效。这在Pixel这类默认配置比较国际化的设备上尤其常见。SIP鉴权参数异常终端里固化的IMPI/IMPU与网络侧HSS存储不一致导致401挑战永远过不去。所以遇到IMS注册失败我建议排查顺序是终端配置状态 - SIM卡与APN - 终端日志中的REGISTER请求是否存在 - 网络侧是否有401挑战响应 - 挑战计算是否正确 - 最后再怀疑核心网注册流程本身。这个顺序能帮你省掉大量无用功。5. 我从实际项目里总结的几条排障与送检经验5.1 最容易退审的其实不是技术是文档做了这么久认证工作我最大的体会是技术问题通常还有回旋余地文档问题真的是说退就退。最常见的文档问题包括说明书里的功能描述与送检样机实际能力不符、接口定义缺少必填参数说明、信令流程图画得过于简略缺少关键异常分支、关键器件清单里的物料与原厂BOM对不上。这些问题在送检早期一次性解决后面流程会非常顺畅。我的做法是安排一次模拟审查。在正式提交前找一个没有参与这个项目的人拿着送检清单和文档把样机摆在旁边一边看文档一边对样机挑毛病。别人视角能发现很多内部人已经看习惯了的问题。5.2 测试环境与现网环境的差异如何处理进网检验的测试环境通常是一个标准化的实验室环境与现网部署环境多少存在差异。比如实验室用的核心网网元来自不同厂商、IMS呼叫经过的SBC型号可能和你现网不同、甚至传输链路的时延参数都跟现网不一致。遇到测试结果和现网表现不一致怎么办我的经验是先做差异分析而不是急着质疑检验结论。列出现网和实验室环境之间所有可能影响结果的差异点逐项排除最终定位到具体差异之后再和检验机构沟通是否能补充测试或调整测试方法。有几个通用的做法把接口配置参数做标准化对齐尽量让实验室环境和现网在SIP timers、Diameter重传机制这些敏感参数上一致复杂场景在送检前先在自建环境里模拟一遍现场被问起环境差异时准备好一份完整的差异说明文档而不是口头解释。5.3 学会用一套日志把问题讲清楚最后想分享一个很实用的小习惯做核心网设备测试日志是你最重要的沟通语言。我在现场评审和技术答辩时最怕碰到的一种情况是对方说这里有问题但拿不出对应的信令消息。任何问题都要有一套标准的日志表达法先给一条完整信令链路截图标注时间戳再给出关键消息的关键字段解析比如401响应里的nonce、REGISTER里的security-client最后给出对比视角比如标准要求A行为实际实现是B行为。这套方法在进网检验现场同样有效。现场环境紧张沟通窗口短如果你能在半个小时内把问题表达清楚检验工程师也更愿意深入配合你分析。练好这个基本功比背多少测试流程都好用。另外日志的时间同步是个被低估的细节。跨多网元抓包时如果各网元时间不一致前后信令根本对不上。我一般会在测试前统一校准所有设备的NTP时间抓包时也记录本机时间偏移这能让你在排查跨网元问题时省下大量时间。