简介华为NR(5G)单站验证远程交付工具使用说明书GC平台5G指导书及关联ISDP面向5G网络优化、站点验收及远程交付相关工程技术人员用于指导在GC平台上完成NR单站验证的自动化测试、参数配置、任务创建与报告输出帮助降低现场测试成本、提升交付效率。包体为1个docx文档约525KB内容结构清晰先讲解工参、配置数据、路测数据及其他辅助数据的准备方式再介绍报告输出流程包括数据规格、新建任务、参数设置、选择数据、报告下载及常见QA最后专门说明与ISDP的关联及站点调度、信息模板下载等实操要点。文档还梳理了5G单验平台入口、用户新增、邮件激活、报告输出权限配置等前置步骤便于一线网优人员快速上手。当前已有870人浏览学习适合从事5G单站验证、远程交付及平台管理的工程师按需查阅。1. 被“上站”拖慢的5G交付华为NR单站验证为什么绕不开远程化进入5G NR规模交付阶段后我身边最常见的瓶颈不是设备安装而是“验站”。一个片区一天要新交付十几个站按老办法每个站点派一个调测工程师上站车辆调度、站主协调、等待电梯就耗掉大半天更不谈夜间施工窗口和跨市巡检多个区域并行时人的成本比设备成本更突出项目周期却一点都压不下来。华为NR(5G)单站验证远程交付工具就是奔着这个问题来的把单站验证SSV从“人必须在基站旁边”改成“在办公室通过GC平台下发测试任务、用ISDP跟踪工单状态、由自动化终端执行并按格式回传结果”。这个方向适合5G建设交付、网络优化和运维团队认真评估。下面我把验证维度、平台分工、参数口径和踩坑记录展开讲。2. 先看懂SSV在测什么再谈远程交付GC平台与ISDP的分工2.1 单站验证的四个基础维度接入、时延、覆盖、峰值速率华为交付流程里的单站验证通常是在基站硬件安装和调测完成之后、网络整体优化之前做的一次“入网体检”。SSV名字叫单站实际要验证的不只是这个小区的物理状态而是这个站在无线侧能不能对用户提供预期服务。按验证对象分我一般习惯拆成四个维度接入、时延、覆盖、速率。接入维度验证的是终端能否成功驻留目标小区并完成业务建立重点看随机接入成功率和RRC建立成功率时延维度验证的是从空口同步到用户面首包的时间以及ping业务的往返时延覆盖维度验证的是在扇区正面方向合理距离上RSRP、SINR是否达到规划值常见做法是CQT加短距离DT速率维度验证的是上下行峰值和均值吞吐率这是验收谈判最容易扯皮的指标。这四者的关系是递进的接入失败了后面三项都不用谈时延和覆盖问题又经常反过来解释速率异常所以SSV报告不能只做一张测速表。5G NR相比LTE还多了一组需要验证的关键技术典型如大规模天线波束管理、SSB波束配置、TDD帧结构、上下行解耦等。这些技术的共同特点是它们不光是靠调测能看到结果还需要靠终端上报的信道状态信息、波束测量报告来判断。这组数据正好是远程交付工具在设计上就能自动采集的所以远程SSV在5G时代的可复制性反而比4G时代更强。2.2 远程化能成立的三件事北向可监控、终端可调度、数据可回传远程化“能成立”在我理解里不是开发一个App把现场视频传回来那么简单而是要解决三个基本条件。第一件北向可监控。华为NR基站统一挂在网管系统下面GC平台作为面向无线开站和优化的中间平台可以经由北向接口读到基站的小区状态、发射功率、波束参数、告警和关键话统指标。这一层把“人在现场看到灯板状态”变成了“在平台上看小区状态列表”远程化的前提先立住一半。我会在开站完成后第一时间在GC平台核对小区是否处于ACTIVE状态、SSB功率是否按规划输出、是否有影响业务的告警全部通过再推给下一步。第二件终端可被远程调度。远程SSV所用的自动化测试终端会由测试任务管理器下发脚本执行开关机、驻留、attach、ping、FTP灌包等操作都是按脚本跑不需要人在终端边上按键。终端支持多轮脚本循环也就有了“重试机制”。第三件数据可回传。终端侧日志、GC平台侧话统、射频参数快照会汇总到统一的采集节点再按工单号关联后压缩打包推送给ISDP。只有数据回传这一环闭合了后台工程师才能不看现场视频就写出验收结论。这三个条件看着不复杂工程上却被很基础的约束卡住过。北向接口与网管版本不匹配会导致指标拉取失败传输链路如果只开放了现场到核心网的通道没有开放测试管理节点到自动化终端的通道终端脚本就下发不下去还有一类是被安全策略挡住不同网段之间的端口不通。所以每次远程SSV试点前我会先拉一张网络连通性清单把各节点之间的端口、协议、账号权限扫一遍再谈测试流程设计。2.3 GC平台管网元ISDP管任务交付链路上的两本账在这条交付链路上GC平台和ISDP各自承担的角色很容易被第一次接触远程SSV的人混在一起。我的理解是GC平台管的是网元侧结果ISDP管的是任务侧流程。GC平台更像一个无线网络侧的“工程观察窗口”它负责把基站档案、小区配置、状态、指标从设备侧捞上来以相对标准化的格式呈现。站点名、小区标识、PCI、TAC、频点、带宽、SSB波束、上下行调度信息、话统文件都会在平台上对齐。ISDP则是交付管理侧的工作台它负责工单的创建、审批、执行状态推进、报告回传和整改转派。两个平台的关联键通常就是站点编号和任务编号GC平台生成的结果数据会挂到指定任务下ISDP通过任务号来认领这些数据。从数据流的角度看一次远程SSV的执行是这样的ISDP创建工单时生成任务编号编号传到GC平台作为任务标识GC平台按任务标识下发测试命令给自动化终端终端执行后把结果回传到GC平台的数据目录GC平台按任务编号生成SSV报告数据包ISDP接口拉到数据包并更新工单状态。这套链路里最容易出问题的往往是任务编号在某一步被截断或加了前缀导致两边对不上。所以我在ISDP建单时会特意看一眼任务编号格式是否和GC平台约定一致不一致就在初始阶段修掉这个隐患。团队协作里的常见误区是把这两本账混成一本。比如远程测试已经跑完有人习惯去GC平台翻测速结果而工单状态在ISDP还卡着就打电话催网优。其实两边只要有一个环节没对接比如导出模板的列顺序变了就会造成结果无法回传。这时该查的不是无线而是数据接口。如果团队要把远程SSV规模化我建议先在非热点地区挑两到三个不同站型做试点试点跑通后再铺开。别指望第一个月就压减全部上站次数合理的预期是把远程能完成的那部分测试从现场挪到后台把现场团队的时间真正留给物理核查、天馈整改和复杂故障处理。3. 用GC平台与ISDP跑通第一个远程SSV建单、执行、回传全流程3.1 建站档案在GC平台做四组数据的初始化核查远程SSV的第一个硬条件是平台上有“可连、可查、可管”的站点档案这步通常在GC平台建站时就要完成。我一般会把数据拆成四组工程参数、无线参数、邻区数据、传输参数。工程参数包括站点名称、经纬度、基站型号、BBU/AAU类型无线参数包括小区标识、PCI、TAC、频点、带宽、帧结构邻区数据包括外部小区参数和邻区关系表传输参数包括核心网路由可达性、北向接口地址和数据回传通道配置。因为远程交付没有现场的人来补录这些字段如果在建站时遗漏流程会被迫中断并重新拉现场采集数据。为了减少这种被动我习惯在把表导入平台之前先做一轮Excel逻辑校验PCI是否和邻区冲突、TAC是否和周边规划一致、带宽是否匹配射频通道规格、邻区是否双向都配了、帧结构是否和片区保持一致。校验清单可以做成一张模板直接作为工单附件挂到ISDP里让现场工程师和后台工程师看同一个版本。实践中这步很受团队欢迎因为它把“谁说得对”变成“表上都有”。3.2 创建ISDP远程工单任务包模板与执行策略ISDP端的建单动作本身不复杂在任务中心选择站点、选择SSV模板、填写单站验证类型新建站、扩容站、故障复验再关联GC平台生成的任务编号。真正需要花心思的是“任务包”的绑定关系。ISDP工单并不是一个空表单它要挂一个明确的任务包任务包内包含站点ID、测试脚本ID、下行/上行峰值目标、测试轮次、允许的失败重试次数等字段。我的习惯是分两类建单。一类是全量SSV用于新站入网任务包里放接入、时延、覆盖、速率的全部测试项另一类是复验SSV用于整改后的回归任务包只放上次失败的测试项比如只跑上行吞吐率或只跑接入时延这样不浪费自动化测试资源也不会把旧结论重新翻出来搅乱。ISDP里两个字段我每次都会确认资源模板和执行策略。资源模板决定这次任务由哪台测试终端或哪个远端CPE参与执行策略决定测试是一轮到底还是失败后自动重试两次并保留失败日志。不同站点类型对这两个字段的需求不同建议在团队内部把任务包模板先固化几套别每次临时手工点参数。3.3 执行阶段GC平台状态推进与脚本盯盘任务下发后GC平台侧会按状态机推进初始、小区核查、接入测试、吞吐率测试、指标采集、报告生成。我远程盯盘时的顺序是先看小区状态和发射功率再看SSB波束是否按规划输出然后看测试终端是否成功附着到目标小区最后才看速率类结果。为什么是这个顺序因为前面任何一层失败后面的速率结果都没有意义更重要的是平台显示“小区状态正常”不等于“波束正常”波束正常不等于“终端能驻留”。每一层都要有可验证的数据留下来。执行阶段还有一个我多次碰到的问题任务脚本里配置了失败重试两次但某轮测试第一次就失败重试两次也失败任务状态会退回初始。后台这时以为只是“测试失败”其实终端日志已经把三次失败的原因都打出来了。我现在判断失败时的习惯是每次翻车先打开终端日志和小区话统两个文件而不是直接重复下发任务避免白白给现场增加无效工作量。因为多个站点同时跑的时候盯平台页面盯不过来我加了一个shell盯盘脚本每60秒把关键状态扫一遍#!/bin/bash # remote_ssv_watch.sh # 每60秒检查一次GC平台导出的小区状态CSV输出关键字段并告警异常 CSV_PATH/data/gc_export/ssv_cell_status.csv TARGET_CELL46000-123456-1 # PLMN-站点编号-小区编号 while true; do if [ -f $CSV_PATH ]; then awk -F, -v cell$TARGET_CELL BEGIN{print SSV Cell Status } $2cell { printf [%s] cell%s status%s txPower%s ssbPower%s\n, strftime(%H:%M:%S), $2, $3, $4, $5 if ($3 ! ACTIVE) print 警告: 小区未激活 if ($50 28) print 警告: SSB功率低于28dBm } $CSV_PATH else echo [$(date %H:%M:%S)] 等待GC平台导出文件... fi sleep 60 doneCSV路径和目标小区标识可以按实际工程值替换。awk按逗号分隔字段假设第一列是时间、第二列是小区标识、第三列是状态、第四列是发射功率、第五列是SSB功率。不同版本的GC平台导出模板字段位置可能有差异第一次使用先打印一行列名确认顺序。SSB功率阈值28dBm也不是通用值AAU类型、波束数量、天线增益都会影响以站点规划为准脚本只是给大家一个“自动盯盘”的思路。现实中我习惯用cron或者systemd timer替掉while死循环避免脚本因为机器重启而丢失。远程执行阶段还有一个边界要说明远程交付工具不是全自动无人生产线更像是“带远程控制能力的半自动流水线”。当测试终端异常掉线、AAU告警、传输闪断时仍然需要现场人员配合插拔USB、重启终端或检查馈线。执行阶段我会在ISDP工单里留一个现场联系人并将“需要现场配合”的检查项做成清单而不是等异常出现之后再四处找人。3.4 收尾与异常转派报告、关单、现场整改闭环测试跑完后GC平台会基于汇总数据生成SSV报告草稿ISDP端做复核和审批复核通过后工单关闭数据和报告归档。报告这块有一个细节点GC平台生成的报告草稿默认只带均值、峰值和达标判定不带天线柱式图和信号质量分布图。如果验收方要看覆盖方向性结果我会在ISDP侧关联从DT数据导出的RSRP分布图再一起归档。这步不要等工单快关了才想起来补建单时就在任务包里把“需要关联的附件类型”列出来。对异常项我的动作是在ISDP里创建“整改转派”把失败项的原因描述、失败日志和分析结论挂在工单下转给无线、传输、规划相关责任人。远程SSV最怕的不是出问题而是问题出了没转派、没闭环隔几天再来看发现工单还卡在半路。用工具做交付比传统上站对流程的依赖更重因为人不在现场状态和数据的流转就是唯一线索。4. 验收参数怎么设从无线核查到速率公式远程SSV必须定标再测4.1 无线参数核查表PCI、TAC、频点、SSB波束等关键项远程SSV的验收结论是否可信前提之一是开站参数是否正确。这步必须在建单阶段完成很多速率异常的现场翻车回头去看参数根本不是网络容量不够而是最初的配置就错了。这类问题的根我总结下来最常见的是四个位置PCI、TAC、频点带宽、SSB波束。PCI问题主要是邻区间冲突特别要注意mod3和mod30之间的关系邻区如果不小心用了同一组模余数终端测量会出现明显的干扰特征TAC问题会直接干扰注册和寻呼一个站TAC配错终端在这个区域反复做位置更新失败率立刻凸显出来频点和带宽的问题更隐蔽GSCN、ARFCN、带宽和SSB位置四个参数必须配套只要有一个对不上终端可能压根扫不到信号SSB波束决定初始覆盖方向波束数量、下倾角和功率会影响远点RSRP。这组核查的产出我会整理成一张表格式如下核查项核查内容异常典型表现可执行动作PCI与邻区mod3/mod30冲突同频干扰、切换失败率上升在GC平台修改冲突小区PCITAC与规划值一致注册失败、位置更新频繁重配TAC并核查邻区表频点/带宽GSCN/ARFCN/带宽/SSB位置终端扫描不到SSB重新下发频点配置SSB波束波束数量、功率、下倾角覆盖空洞、远点速率低调整波束场景与功率帧结构时隙配比与片区一致上下行速率失衡、干扰对齐片区统一配比邻区关系外部小区数据一致切换失败、占着小区不放重配外部小区与基线表这张表我在远程建单阶段必看一次也建议ISDP工单把这张表做成必填模板项防止大家都依赖平台默认值跳过人工核查。4.2 下行峰值速率3GPP公式、终端能力折减与验收分档速率指标是SSV报告里最吸引眼球、也最容易被误解的数字。我在远程交付培训里会先带大家算理论峰值公式如下理论峰值速率(Mbps) 资源块数 × 每RB子载波数 × 每时隙符号数 × 下行时隙数 × 流数 × 调制阶数 × 编码效率 × 每秒帧数 / 1e6以NR FR1 100MHz带宽、子载波间隔30kHz为例RB数273每RB子载波数12每时隙符号数14TDD配比7:3即10个时隙里下行7个4流、256QAM即调制阶数8、编码效率0.925、每秒100个无线帧。代入计算273×1232763276×144586445864×7321048再×4流1284192×810273536×0.9259503021×100/1e6950Mbps。也就是说这个配置组合下理论下行峰值在950Mbps上下如果换成8流或更高编码效率会再往上抬。扣掉PDCCH、PSS/SSS、CSI-RS等开销后实际最高值通常还要打一个折扣所以工程验收里常用“商用目标值”和“最低通过值”两级口径而不是直接拿理论极值当门槛。这个公式是3GPP TR38.306的简化几何版目的是告诉大家理论值只提供量级参考真正决定你测不测得过的是终端能力、调度算法和信道质量。远程SSV任务包里填写的下行目标值我习惯按理论值的70%作为商用目标50%作为最低通过线低于最低线就该拉问题单了。要注意终端能力折减4流终端和2流终端测同一个站峰值可能差一半。所以建单时必须把测试终端型号和能力等级记录到ISDP工单里否则同站多次复测的结果没有可比性。第二个超出预期的因素是TDD帧结构和特殊时隙配比。同是7:3配比特殊时隙里下行符号个数不同实际可用下行资源会差一小截另外CQI/RI反馈和MCS调度都受信道环境影响不存在“空口好、速率一定顶格”这回事。远程SSV在速率验收上就是要做对比对比就需要同样的终端、同样的脚本、同样的时隙配比这三样缺一不可。4.3 时延、RRC建立成功率与切换的验收口径速率之外的验收参数远程SSV要给出可比的统计口径。RRC建立成功率在大样本下应高于99%考察多次尝试中RRC连接完成次数的占比随机接入成功率受PRACH根序列和时频资源配置影响单站验证里重点看前导冲突是否异常高时延类指标分两种来定口径空口时延是从调度首传到业务面首包的时延ping时延则包含传输和核心网处理。如果现场给的是“ping核心网网关时延”那我会把目的地址、ping包大小、次数都写清楚避免和“空口时延”混为一谈。移动性验证在单站阶段一般简化成站内切换和到邻区的切换验证重点关注同频与异频切换成功率、切换时延。远程交付在移动性上的边界是我反复提醒的跨站切换和覆盖扫盲是远程工具很难完美覆盖的尤其是跨站邻区无线环境需要路测或现场专项验证。所以我会在SSV工单模板里把“跨站切换验证”标记为现场补充项远程交付只负责站内可自动化部分。几个关键指标的参考口径我列在下面指标口径定义参考阈值初值备注RRC建立成功率RRC成功数/尝试数99%排除拥塞导致的拒绝空口时延调度首传到用户面首包时延20~80ms与UE能力和SCS相关ping时延向核心网网关ping 64字节往返时延视传输距离而定记录目的地址与次数下行峰值速率多轮取最大瞬时值理论值的70%记录MCS/RI/CQI上行峰值速率多轮取最大瞬时值理论值的70%记录终端发射通道数同频切换成功率站内与邻区同频切换成功次数99%记录目标小区标识把验收口径先定清楚远程SSV的结论才是可信、可对比、可追溯的。先定标再测试远程交付才不会变成一个黑匣子。5. 远程SSV的典型翻车现场五个高频问题的现象与处理顺序5.1 终端占用不上目标小区先查PCI/TAC再动功率现象远程SSV任务启动后测试终端一直无法占用目标小区业务建立失败。GC平台上看不到远端打印的驻留成功记录但平台上的小区状态正常、发射功率正常。原因终端扫描到信号却无法驻留通常不是基站“没信号”而是配置层面的冲突或不匹配。邻区的PCI模数冲突会让终端在测量冲突时反复选择失败TAC不一致会让核心网位置更新出错终端在允许接入和拒绝接入之间摇摆。处理顺序先在GC平台核对目标小区频点、带宽和SSB位置再检查邻区关系表里的外部小区参数和TAC最后才轮到射频功率。我见过有人一上来就把波束功率调高试图“加强信号”结果邻区干扰反而变大问题更严重。远程交付里这一条是我用血泪经验反复验证过的配置层的坑永远不要用功率去填。5.2 上行吞吐率腰斩别急着改帧结构先验终端能力现象下行速率接近验收目标上行速率只有理论值的一半左右测速脚本跑了三轮结果都一样。原因典型的是终端没工作在高阶配置。比如终端只支持单发或双发而基站侧按4流配置了上行调度也有可能是上行MCS被调度得很低原因是SRS资源不足导致基站拿不到好的上行信道估计只能保守调度。处理顺序先核对测试终端的能力等级UE category、发射通道数、SRS配置再看话统里上行MCS分布是否集中在高等级然后才考虑是不是帧结构、SRS周期这类网络参数问题。改帧结构要极其谨慎因为任何一个单站的上下行配比变化都会影响与周边站的干扰协调属于“会引起连锁反应的改动”处理顺序上它应该排到最后。5.3 GC平台指标回传中断按北向接口、版本、链路、空间顺序排查现象测试终端和任务脚本都执行完了但GC平台上的状态一直停留在指标采集中报告迟迟不能生成。原因指标回传链路中任一点故障都会造成这种假死状态。常见的是北向接口连接断开、数据模型与网管版本不匹配、传输链路闪断或者采集节点磁盘空间写满。处理顺序先确认北向接口的会话状态再看最近一次成功采集的时间是否与测试时间吻合然后检查GC平台与网管之间网络丢包最后查磁盘空间和中间表空间。这个顺序就是“从连接状态到数据落地”的顺序不要跳步去重启采集服务。很可能重启完接着断根因一直没找到。5.4 ISDP工单卡在执行中两平台状态机对齐的坑现象ISDP工单状态一直停在执行中但GC平台侧测试已完成、报告已生成两边状态对不上。原因两平台状态同步依赖工单号和回传接口。数据文件在回传侧的解析失败会导致ISDP侧始终等不到“回传成功”的标记状态机就不会推进。处理顺序去ISDP回传记录里看最后一条传输记录的错误码。错误码提示解析失败时重点检查GC导出文件格式和ISDP预期模板的字段差异。这类问题有一个典型的诱发时机GC平台版本升级或模板调整之后导出文件多了一列或改了列名ISDP解析器按旧模板对不上列回传就断。处理方案是把导出模板的列名映射表在ISDP侧做一次同步更新并把新旧模板做一次diff测试。5.5 报告达标但现场返修远程工具覆盖不到的物理核查项现象远程SSV各项指标都达标工单关闭后没几天现场反馈某个扇区覆盖空洞、切换失败或上行链路告警。原因远程工具能验证无线侧的数据链路但覆盖不到物理安装质量。比如天线接到哪个馈线口、抱杆朝向是否按设计、合路器和跳线是否接反、防水和接地是否符合要求。天线接反扇区或跳线松动在空口指标上有时表现为一切正常要到业务补盲或干扰排查时才会暴露。处理顺序远程交付不能替代物理核查。在ISDP工单模板里要把“现场核查项”设成独立任务包分配给督导和调测人员包含天线方向、驻波、馈线连接、防雷接地等检查项并强制要求上传照片。远程SSV和现场物理核查是互相补充的两条线不能把远程交付理解成“完全无人化”应该理解成“把数据可远程化的部分收回来把人留在真正需要人的地方”。这条认知到位了远程交付才能少接返修单。6. 把远程SSV做成日常产能用Python脚本批量判读CSV结果远程SSV工具跑通后真正拉开团队差距的是“怎么消化报告数据”。每个站验证结束后平台会导出一份包含多轮测速的结果CSV。一次上百站的批量开通如果我逐个Excel打开看效率低到不敢想。我后来固定下来的做法是用一段Python脚本批量抽取峰值按目标值做达标判断再把结果汇总成一张表。这个习惯也强烈推荐给正在批量交付的团队。#!/usr/bin/env python3 parse_ssv_rate.py CSV路径 下行目标 上行目标 从GC平台导出的吞吐率CSV中提取多轮测试的最大值作为峰值速率 import csv, sys def main(path, dl_target, ul_target): with open(path, newline, encodingutf-8-sig) as f: rows list(csv.DictReader(f)) # 取多轮测速的最大值作为峰值是SSV常用的统计口径 dl max(float(r[DL_Throughput_Mbps]) for r in rows) ul max(float(r[UL_Throughput_Mbps]) for r in rows) # 达标线按商用目标的70%核算 dl_pass dl float(dl_target) * 0.7 ul_pass ul float(ul_target) * 0.7 print(f下行峰值: {dl:.1f} Mbps, 参考值: {dl_target} Mbps, 判定: {达标 if dl_pass else 不达标}) print(f上行峰值: {ul:.1f} Mbps, 参考值: {ul_target} Mbps, 判定: {达标 if ul_pass else 不达标}) print(总体结论:, 达标 if (dl_pass and ul_pass) else 不达标) if __name__ __main__: main(sys.argv[1], sys.argv[2], sys.argv[3])字段名需要跟自己的GC平台导出模板对齐有些版本叫DL_Speed有些叫DL_Throughput_Mbps第一次运行建议先打印一行列名。判定阈值不要写死在代码里而是从命令行传入这样脚本才能在多个站点、多套目标值之间复用。使用这段脚本之后我一般还会抽站点复看每周随机抽一个远程SSV工单把时延、移动性数据从GC平台导出来自己过一遍避免只依赖自动判定把边缘问题漏掉。工具能帮我们省掉重复劳动但网络质量的判断最后还是工程师的责任。这是我目前状态下最顺手的节奏也把这份处理习惯分享出来希望帮到你。本文还有配套的精品资源点击获取 华为NR单站验证远程交付：GC平台与ISDP协同实战解析
简介华为NR(5G)单站验证远程交付工具使用说明书GC平台5G指导书及关联ISDP面向5G网络优化、站点验收及远程交付相关工程技术人员用于指导在GC平台上完成NR单站验证的自动化测试、参数配置、任务创建与报告输出帮助降低现场测试成本、提升交付效率。包体为1个docx文档约525KB内容结构清晰先讲解工参、配置数据、路测数据及其他辅助数据的准备方式再介绍报告输出流程包括数据规格、新建任务、参数设置、选择数据、报告下载及常见QA最后专门说明与ISDP的关联及站点调度、信息模板下载等实操要点。文档还梳理了5G单验平台入口、用户新增、邮件激活、报告输出权限配置等前置步骤便于一线网优人员快速上手。当前已有870人浏览学习适合从事5G单站验证、远程交付及平台管理的工程师按需查阅。1. 被“上站”拖慢的5G交付华为NR单站验证为什么绕不开远程化进入5G NR规模交付阶段后我身边最常见的瓶颈不是设备安装而是“验站”。一个片区一天要新交付十几个站按老办法每个站点派一个调测工程师上站车辆调度、站主协调、等待电梯就耗掉大半天更不谈夜间施工窗口和跨市巡检多个区域并行时人的成本比设备成本更突出项目周期却一点都压不下来。华为NR(5G)单站验证远程交付工具就是奔着这个问题来的把单站验证SSV从“人必须在基站旁边”改成“在办公室通过GC平台下发测试任务、用ISDP跟踪工单状态、由自动化终端执行并按格式回传结果”。这个方向适合5G建设交付、网络优化和运维团队认真评估。下面我把验证维度、平台分工、参数口径和踩坑记录展开讲。2. 先看懂SSV在测什么再谈远程交付GC平台与ISDP的分工2.1 单站验证的四个基础维度接入、时延、覆盖、峰值速率华为交付流程里的单站验证通常是在基站硬件安装和调测完成之后、网络整体优化之前做的一次“入网体检”。SSV名字叫单站实际要验证的不只是这个小区的物理状态而是这个站在无线侧能不能对用户提供预期服务。按验证对象分我一般习惯拆成四个维度接入、时延、覆盖、速率。接入维度验证的是终端能否成功驻留目标小区并完成业务建立重点看随机接入成功率和RRC建立成功率时延维度验证的是从空口同步到用户面首包的时间以及ping业务的往返时延覆盖维度验证的是在扇区正面方向合理距离上RSRP、SINR是否达到规划值常见做法是CQT加短距离DT速率维度验证的是上下行峰值和均值吞吐率这是验收谈判最容易扯皮的指标。这四者的关系是递进的接入失败了后面三项都不用谈时延和覆盖问题又经常反过来解释速率异常所以SSV报告不能只做一张测速表。5G NR相比LTE还多了一组需要验证的关键技术典型如大规模天线波束管理、SSB波束配置、TDD帧结构、上下行解耦等。这些技术的共同特点是它们不光是靠调测能看到结果还需要靠终端上报的信道状态信息、波束测量报告来判断。这组数据正好是远程交付工具在设计上就能自动采集的所以远程SSV在5G时代的可复制性反而比4G时代更强。2.2 远程化能成立的三件事北向可监控、终端可调度、数据可回传远程化“能成立”在我理解里不是开发一个App把现场视频传回来那么简单而是要解决三个基本条件。第一件北向可监控。华为NR基站统一挂在网管系统下面GC平台作为面向无线开站和优化的中间平台可以经由北向接口读到基站的小区状态、发射功率、波束参数、告警和关键话统指标。这一层把“人在现场看到灯板状态”变成了“在平台上看小区状态列表”远程化的前提先立住一半。我会在开站完成后第一时间在GC平台核对小区是否处于ACTIVE状态、SSB功率是否按规划输出、是否有影响业务的告警全部通过再推给下一步。第二件终端可被远程调度。远程SSV所用的自动化测试终端会由测试任务管理器下发脚本执行开关机、驻留、attach、ping、FTP灌包等操作都是按脚本跑不需要人在终端边上按键。终端支持多轮脚本循环也就有了“重试机制”。第三件数据可回传。终端侧日志、GC平台侧话统、射频参数快照会汇总到统一的采集节点再按工单号关联后压缩打包推送给ISDP。只有数据回传这一环闭合了后台工程师才能不看现场视频就写出验收结论。这三个条件看着不复杂工程上却被很基础的约束卡住过。北向接口与网管版本不匹配会导致指标拉取失败传输链路如果只开放了现场到核心网的通道没有开放测试管理节点到自动化终端的通道终端脚本就下发不下去还有一类是被安全策略挡住不同网段之间的端口不通。所以每次远程SSV试点前我会先拉一张网络连通性清单把各节点之间的端口、协议、账号权限扫一遍再谈测试流程设计。2.3 GC平台管网元ISDP管任务交付链路上的两本账在这条交付链路上GC平台和ISDP各自承担的角色很容易被第一次接触远程SSV的人混在一起。我的理解是GC平台管的是网元侧结果ISDP管的是任务侧流程。GC平台更像一个无线网络侧的“工程观察窗口”它负责把基站档案、小区配置、状态、指标从设备侧捞上来以相对标准化的格式呈现。站点名、小区标识、PCI、TAC、频点、带宽、SSB波束、上下行调度信息、话统文件都会在平台上对齐。ISDP则是交付管理侧的工作台它负责工单的创建、审批、执行状态推进、报告回传和整改转派。两个平台的关联键通常就是站点编号和任务编号GC平台生成的结果数据会挂到指定任务下ISDP通过任务号来认领这些数据。从数据流的角度看一次远程SSV的执行是这样的ISDP创建工单时生成任务编号编号传到GC平台作为任务标识GC平台按任务标识下发测试命令给自动化终端终端执行后把结果回传到GC平台的数据目录GC平台按任务编号生成SSV报告数据包ISDP接口拉到数据包并更新工单状态。这套链路里最容易出问题的往往是任务编号在某一步被截断或加了前缀导致两边对不上。所以我在ISDP建单时会特意看一眼任务编号格式是否和GC平台约定一致不一致就在初始阶段修掉这个隐患。团队协作里的常见误区是把这两本账混成一本。比如远程测试已经跑完有人习惯去GC平台翻测速结果而工单状态在ISDP还卡着就打电话催网优。其实两边只要有一个环节没对接比如导出模板的列顺序变了就会造成结果无法回传。这时该查的不是无线而是数据接口。如果团队要把远程SSV规模化我建议先在非热点地区挑两到三个不同站型做试点试点跑通后再铺开。别指望第一个月就压减全部上站次数合理的预期是把远程能完成的那部分测试从现场挪到后台把现场团队的时间真正留给物理核查、天馈整改和复杂故障处理。3. 用GC平台与ISDP跑通第一个远程SSV建单、执行、回传全流程3.1 建站档案在GC平台做四组数据的初始化核查远程SSV的第一个硬条件是平台上有“可连、可查、可管”的站点档案这步通常在GC平台建站时就要完成。我一般会把数据拆成四组工程参数、无线参数、邻区数据、传输参数。工程参数包括站点名称、经纬度、基站型号、BBU/AAU类型无线参数包括小区标识、PCI、TAC、频点、带宽、帧结构邻区数据包括外部小区参数和邻区关系表传输参数包括核心网路由可达性、北向接口地址和数据回传通道配置。因为远程交付没有现场的人来补录这些字段如果在建站时遗漏流程会被迫中断并重新拉现场采集数据。为了减少这种被动我习惯在把表导入平台之前先做一轮Excel逻辑校验PCI是否和邻区冲突、TAC是否和周边规划一致、带宽是否匹配射频通道规格、邻区是否双向都配了、帧结构是否和片区保持一致。校验清单可以做成一张模板直接作为工单附件挂到ISDP里让现场工程师和后台工程师看同一个版本。实践中这步很受团队欢迎因为它把“谁说得对”变成“表上都有”。3.2 创建ISDP远程工单任务包模板与执行策略ISDP端的建单动作本身不复杂在任务中心选择站点、选择SSV模板、填写单站验证类型新建站、扩容站、故障复验再关联GC平台生成的任务编号。真正需要花心思的是“任务包”的绑定关系。ISDP工单并不是一个空表单它要挂一个明确的任务包任务包内包含站点ID、测试脚本ID、下行/上行峰值目标、测试轮次、允许的失败重试次数等字段。我的习惯是分两类建单。一类是全量SSV用于新站入网任务包里放接入、时延、覆盖、速率的全部测试项另一类是复验SSV用于整改后的回归任务包只放上次失败的测试项比如只跑上行吞吐率或只跑接入时延这样不浪费自动化测试资源也不会把旧结论重新翻出来搅乱。ISDP里两个字段我每次都会确认资源模板和执行策略。资源模板决定这次任务由哪台测试终端或哪个远端CPE参与执行策略决定测试是一轮到底还是失败后自动重试两次并保留失败日志。不同站点类型对这两个字段的需求不同建议在团队内部把任务包模板先固化几套别每次临时手工点参数。3.3 执行阶段GC平台状态推进与脚本盯盘任务下发后GC平台侧会按状态机推进初始、小区核查、接入测试、吞吐率测试、指标采集、报告生成。我远程盯盘时的顺序是先看小区状态和发射功率再看SSB波束是否按规划输出然后看测试终端是否成功附着到目标小区最后才看速率类结果。为什么是这个顺序因为前面任何一层失败后面的速率结果都没有意义更重要的是平台显示“小区状态正常”不等于“波束正常”波束正常不等于“终端能驻留”。每一层都要有可验证的数据留下来。执行阶段还有一个我多次碰到的问题任务脚本里配置了失败重试两次但某轮测试第一次就失败重试两次也失败任务状态会退回初始。后台这时以为只是“测试失败”其实终端日志已经把三次失败的原因都打出来了。我现在判断失败时的习惯是每次翻车先打开终端日志和小区话统两个文件而不是直接重复下发任务避免白白给现场增加无效工作量。因为多个站点同时跑的时候盯平台页面盯不过来我加了一个shell盯盘脚本每60秒把关键状态扫一遍#!/bin/bash # remote_ssv_watch.sh # 每60秒检查一次GC平台导出的小区状态CSV输出关键字段并告警异常 CSV_PATH/data/gc_export/ssv_cell_status.csv TARGET_CELL46000-123456-1 # PLMN-站点编号-小区编号 while true; do if [ -f $CSV_PATH ]; then awk -F, -v cell$TARGET_CELL BEGIN{print SSV Cell Status } $2cell { printf [%s] cell%s status%s txPower%s ssbPower%s\n, strftime(%H:%M:%S), $2, $3, $4, $5 if ($3 ! ACTIVE) print 警告: 小区未激活 if ($50 28) print 警告: SSB功率低于28dBm } $CSV_PATH else echo [$(date %H:%M:%S)] 等待GC平台导出文件... fi sleep 60 doneCSV路径和目标小区标识可以按实际工程值替换。awk按逗号分隔字段假设第一列是时间、第二列是小区标识、第三列是状态、第四列是发射功率、第五列是SSB功率。不同版本的GC平台导出模板字段位置可能有差异第一次使用先打印一行列名确认顺序。SSB功率阈值28dBm也不是通用值AAU类型、波束数量、天线增益都会影响以站点规划为准脚本只是给大家一个“自动盯盘”的思路。现实中我习惯用cron或者systemd timer替掉while死循环避免脚本因为机器重启而丢失。远程执行阶段还有一个边界要说明远程交付工具不是全自动无人生产线更像是“带远程控制能力的半自动流水线”。当测试终端异常掉线、AAU告警、传输闪断时仍然需要现场人员配合插拔USB、重启终端或检查馈线。执行阶段我会在ISDP工单里留一个现场联系人并将“需要现场配合”的检查项做成清单而不是等异常出现之后再四处找人。3.4 收尾与异常转派报告、关单、现场整改闭环测试跑完后GC平台会基于汇总数据生成SSV报告草稿ISDP端做复核和审批复核通过后工单关闭数据和报告归档。报告这块有一个细节点GC平台生成的报告草稿默认只带均值、峰值和达标判定不带天线柱式图和信号质量分布图。如果验收方要看覆盖方向性结果我会在ISDP侧关联从DT数据导出的RSRP分布图再一起归档。这步不要等工单快关了才想起来补建单时就在任务包里把“需要关联的附件类型”列出来。对异常项我的动作是在ISDP里创建“整改转派”把失败项的原因描述、失败日志和分析结论挂在工单下转给无线、传输、规划相关责任人。远程SSV最怕的不是出问题而是问题出了没转派、没闭环隔几天再来看发现工单还卡在半路。用工具做交付比传统上站对流程的依赖更重因为人不在现场状态和数据的流转就是唯一线索。4. 验收参数怎么设从无线核查到速率公式远程SSV必须定标再测4.1 无线参数核查表PCI、TAC、频点、SSB波束等关键项远程SSV的验收结论是否可信前提之一是开站参数是否正确。这步必须在建单阶段完成很多速率异常的现场翻车回头去看参数根本不是网络容量不够而是最初的配置就错了。这类问题的根我总结下来最常见的是四个位置PCI、TAC、频点带宽、SSB波束。PCI问题主要是邻区间冲突特别要注意mod3和mod30之间的关系邻区如果不小心用了同一组模余数终端测量会出现明显的干扰特征TAC问题会直接干扰注册和寻呼一个站TAC配错终端在这个区域反复做位置更新失败率立刻凸显出来频点和带宽的问题更隐蔽GSCN、ARFCN、带宽和SSB位置四个参数必须配套只要有一个对不上终端可能压根扫不到信号SSB波束决定初始覆盖方向波束数量、下倾角和功率会影响远点RSRP。这组核查的产出我会整理成一张表格式如下核查项核查内容异常典型表现可执行动作PCI与邻区mod3/mod30冲突同频干扰、切换失败率上升在GC平台修改冲突小区PCITAC与规划值一致注册失败、位置更新频繁重配TAC并核查邻区表频点/带宽GSCN/ARFCN/带宽/SSB位置终端扫描不到SSB重新下发频点配置SSB波束波束数量、功率、下倾角覆盖空洞、远点速率低调整波束场景与功率帧结构时隙配比与片区一致上下行速率失衡、干扰对齐片区统一配比邻区关系外部小区数据一致切换失败、占着小区不放重配外部小区与基线表这张表我在远程建单阶段必看一次也建议ISDP工单把这张表做成必填模板项防止大家都依赖平台默认值跳过人工核查。4.2 下行峰值速率3GPP公式、终端能力折减与验收分档速率指标是SSV报告里最吸引眼球、也最容易被误解的数字。我在远程交付培训里会先带大家算理论峰值公式如下理论峰值速率(Mbps) 资源块数 × 每RB子载波数 × 每时隙符号数 × 下行时隙数 × 流数 × 调制阶数 × 编码效率 × 每秒帧数 / 1e6以NR FR1 100MHz带宽、子载波间隔30kHz为例RB数273每RB子载波数12每时隙符号数14TDD配比7:3即10个时隙里下行7个4流、256QAM即调制阶数8、编码效率0.925、每秒100个无线帧。代入计算273×1232763276×144586445864×7321048再×4流1284192×810273536×0.9259503021×100/1e6950Mbps。也就是说这个配置组合下理论下行峰值在950Mbps上下如果换成8流或更高编码效率会再往上抬。扣掉PDCCH、PSS/SSS、CSI-RS等开销后实际最高值通常还要打一个折扣所以工程验收里常用“商用目标值”和“最低通过值”两级口径而不是直接拿理论极值当门槛。这个公式是3GPP TR38.306的简化几何版目的是告诉大家理论值只提供量级参考真正决定你测不测得过的是终端能力、调度算法和信道质量。远程SSV任务包里填写的下行目标值我习惯按理论值的70%作为商用目标50%作为最低通过线低于最低线就该拉问题单了。要注意终端能力折减4流终端和2流终端测同一个站峰值可能差一半。所以建单时必须把测试终端型号和能力等级记录到ISDP工单里否则同站多次复测的结果没有可比性。第二个超出预期的因素是TDD帧结构和特殊时隙配比。同是7:3配比特殊时隙里下行符号个数不同实际可用下行资源会差一小截另外CQI/RI反馈和MCS调度都受信道环境影响不存在“空口好、速率一定顶格”这回事。远程SSV在速率验收上就是要做对比对比就需要同样的终端、同样的脚本、同样的时隙配比这三样缺一不可。4.3 时延、RRC建立成功率与切换的验收口径速率之外的验收参数远程SSV要给出可比的统计口径。RRC建立成功率在大样本下应高于99%考察多次尝试中RRC连接完成次数的占比随机接入成功率受PRACH根序列和时频资源配置影响单站验证里重点看前导冲突是否异常高时延类指标分两种来定口径空口时延是从调度首传到业务面首包的时延ping时延则包含传输和核心网处理。如果现场给的是“ping核心网网关时延”那我会把目的地址、ping包大小、次数都写清楚避免和“空口时延”混为一谈。移动性验证在单站阶段一般简化成站内切换和到邻区的切换验证重点关注同频与异频切换成功率、切换时延。远程交付在移动性上的边界是我反复提醒的跨站切换和覆盖扫盲是远程工具很难完美覆盖的尤其是跨站邻区无线环境需要路测或现场专项验证。所以我会在SSV工单模板里把“跨站切换验证”标记为现场补充项远程交付只负责站内可自动化部分。几个关键指标的参考口径我列在下面指标口径定义参考阈值初值备注RRC建立成功率RRC成功数/尝试数99%排除拥塞导致的拒绝空口时延调度首传到用户面首包时延20~80ms与UE能力和SCS相关ping时延向核心网网关ping 64字节往返时延视传输距离而定记录目的地址与次数下行峰值速率多轮取最大瞬时值理论值的70%记录MCS/RI/CQI上行峰值速率多轮取最大瞬时值理论值的70%记录终端发射通道数同频切换成功率站内与邻区同频切换成功次数99%记录目标小区标识把验收口径先定清楚远程SSV的结论才是可信、可对比、可追溯的。先定标再测试远程交付才不会变成一个黑匣子。5. 远程SSV的典型翻车现场五个高频问题的现象与处理顺序5.1 终端占用不上目标小区先查PCI/TAC再动功率现象远程SSV任务启动后测试终端一直无法占用目标小区业务建立失败。GC平台上看不到远端打印的驻留成功记录但平台上的小区状态正常、发射功率正常。原因终端扫描到信号却无法驻留通常不是基站“没信号”而是配置层面的冲突或不匹配。邻区的PCI模数冲突会让终端在测量冲突时反复选择失败TAC不一致会让核心网位置更新出错终端在允许接入和拒绝接入之间摇摆。处理顺序先在GC平台核对目标小区频点、带宽和SSB位置再检查邻区关系表里的外部小区参数和TAC最后才轮到射频功率。我见过有人一上来就把波束功率调高试图“加强信号”结果邻区干扰反而变大问题更严重。远程交付里这一条是我用血泪经验反复验证过的配置层的坑永远不要用功率去填。5.2 上行吞吐率腰斩别急着改帧结构先验终端能力现象下行速率接近验收目标上行速率只有理论值的一半左右测速脚本跑了三轮结果都一样。原因典型的是终端没工作在高阶配置。比如终端只支持单发或双发而基站侧按4流配置了上行调度也有可能是上行MCS被调度得很低原因是SRS资源不足导致基站拿不到好的上行信道估计只能保守调度。处理顺序先核对测试终端的能力等级UE category、发射通道数、SRS配置再看话统里上行MCS分布是否集中在高等级然后才考虑是不是帧结构、SRS周期这类网络参数问题。改帧结构要极其谨慎因为任何一个单站的上下行配比变化都会影响与周边站的干扰协调属于“会引起连锁反应的改动”处理顺序上它应该排到最后。5.3 GC平台指标回传中断按北向接口、版本、链路、空间顺序排查现象测试终端和任务脚本都执行完了但GC平台上的状态一直停留在指标采集中报告迟迟不能生成。原因指标回传链路中任一点故障都会造成这种假死状态。常见的是北向接口连接断开、数据模型与网管版本不匹配、传输链路闪断或者采集节点磁盘空间写满。处理顺序先确认北向接口的会话状态再看最近一次成功采集的时间是否与测试时间吻合然后检查GC平台与网管之间网络丢包最后查磁盘空间和中间表空间。这个顺序就是“从连接状态到数据落地”的顺序不要跳步去重启采集服务。很可能重启完接着断根因一直没找到。5.4 ISDP工单卡在执行中两平台状态机对齐的坑现象ISDP工单状态一直停在执行中但GC平台侧测试已完成、报告已生成两边状态对不上。原因两平台状态同步依赖工单号和回传接口。数据文件在回传侧的解析失败会导致ISDP侧始终等不到“回传成功”的标记状态机就不会推进。处理顺序去ISDP回传记录里看最后一条传输记录的错误码。错误码提示解析失败时重点检查GC导出文件格式和ISDP预期模板的字段差异。这类问题有一个典型的诱发时机GC平台版本升级或模板调整之后导出文件多了一列或改了列名ISDP解析器按旧模板对不上列回传就断。处理方案是把导出模板的列名映射表在ISDP侧做一次同步更新并把新旧模板做一次diff测试。5.5 报告达标但现场返修远程工具覆盖不到的物理核查项现象远程SSV各项指标都达标工单关闭后没几天现场反馈某个扇区覆盖空洞、切换失败或上行链路告警。原因远程工具能验证无线侧的数据链路但覆盖不到物理安装质量。比如天线接到哪个馈线口、抱杆朝向是否按设计、合路器和跳线是否接反、防水和接地是否符合要求。天线接反扇区或跳线松动在空口指标上有时表现为一切正常要到业务补盲或干扰排查时才会暴露。处理顺序远程交付不能替代物理核查。在ISDP工单模板里要把“现场核查项”设成独立任务包分配给督导和调测人员包含天线方向、驻波、馈线连接、防雷接地等检查项并强制要求上传照片。远程SSV和现场物理核查是互相补充的两条线不能把远程交付理解成“完全无人化”应该理解成“把数据可远程化的部分收回来把人留在真正需要人的地方”。这条认知到位了远程交付才能少接返修单。6. 把远程SSV做成日常产能用Python脚本批量判读CSV结果远程SSV工具跑通后真正拉开团队差距的是“怎么消化报告数据”。每个站验证结束后平台会导出一份包含多轮测速的结果CSV。一次上百站的批量开通如果我逐个Excel打开看效率低到不敢想。我后来固定下来的做法是用一段Python脚本批量抽取峰值按目标值做达标判断再把结果汇总成一张表。这个习惯也强烈推荐给正在批量交付的团队。#!/usr/bin/env python3 parse_ssv_rate.py CSV路径 下行目标 上行目标 从GC平台导出的吞吐率CSV中提取多轮测试的最大值作为峰值速率 import csv, sys def main(path, dl_target, ul_target): with open(path, newline, encodingutf-8-sig) as f: rows list(csv.DictReader(f)) # 取多轮测速的最大值作为峰值是SSV常用的统计口径 dl max(float(r[DL_Throughput_Mbps]) for r in rows) ul max(float(r[UL_Throughput_Mbps]) for r in rows) # 达标线按商用目标的70%核算 dl_pass dl float(dl_target) * 0.7 ul_pass ul float(ul_target) * 0.7 print(f下行峰值: {dl:.1f} Mbps, 参考值: {dl_target} Mbps, 判定: {达标 if dl_pass else 不达标}) print(f上行峰值: {ul:.1f} Mbps, 参考值: {ul_target} Mbps, 判定: {达标 if ul_pass else 不达标}) print(总体结论:, 达标 if (dl_pass and ul_pass) else 不达标) if __name__ __main__: main(sys.argv[1], sys.argv[2], sys.argv[3])字段名需要跟自己的GC平台导出模板对齐有些版本叫DL_Speed有些叫DL_Throughput_Mbps第一次运行建议先打印一行列名。判定阈值不要写死在代码里而是从命令行传入这样脚本才能在多个站点、多套目标值之间复用。使用这段脚本之后我一般还会抽站点复看每周随机抽一个远程SSV工单把时延、移动性数据从GC平台导出来自己过一遍避免只依赖自动判定把边缘问题漏掉。工具能帮我们省掉重复劳动但网络质量的判断最后还是工程师的责任。这是我目前状态下最顺手的节奏也把这份处理习惯分享出来希望帮到你。本文还有配套的精品资源点击获取