简介一份面向矿业智能化与数字化转型从业者、5G解决方案规划人员的46页演示文稿集中探讨5G技术如何支撑智慧矿山网络建设。内容先分析矿山多类业务对通信的需求指出传统短距无线、工业无线、蜂窝网络在带宽、时延、连接可靠性与成本上的不足再围绕“三化融合”梳理智能化、信息化、自动化协同的矿山生产管理层级并给出5G在超高清视频回传、AR/VR远程维修、精准定位、无人驾驶、巡检机器人等场景中的应用框架。包体为1个PPT类型文件共46页可编辑演示文档整包约23.91MB适合直接用于方案构思和汇报讲解。目前已有76人浏览学习可供煤矿智能化项目立项前期的产品经理、售前工程师、通信网络规划人员以及矿山企业管理人员参考。通过该PPT可快速获得智慧矿山典型业务对网络指标的要求、5G关键使能技术配置思路以及矿山机器人、智能采煤等典型应用脉络有助于形成清晰的汇报材料或方案初稿。1. 5G赋能智慧矿山到底在赋能什么46页PPT之外的三张网上个月去一个露天矿看到无人驾驶矿卡在采场里停下了。调度员打电话说“网络波动了一下”车就自己刹停了后面的车堵了一串。那台矿卡装了5G CPE、配了毫米波雷达和激光雷达算法也早就验证过了但让它停下的偏偏是最后那段无线链路。也是那一刻我才想明白5G赋能智慧矿山很少卡在算法、设备和PPT上卡的是那根看不见的“空中网线”到底能不能扛住矿区环境。46页PPT只是把愿景讲清楚真正要落地的是三张逻辑网络一张给远程控制和无人驾驶的低时延高可靠网一张给高清视频回传的高带宽网还有一张给传感器和海量终端接入的广连接网。这篇笔记就按“选型→部署→应用→排障→运维”的顺序把这几张网怎么搭、参数怎么设、坑在哪讲清楚适合矿方信息口的人、运营商做5G to B交付的工程师以及做智慧矿山总集成的项目团队。2. 智慧矿山的5G专网选型独立专网、公网专用还是混合组网2.1 三张网的需求拆解控制、视频、传感器各吃什么带宽做方案第一步不是选设备而是把业务流量拆开。矿上的典型业务有三大类。第一类是远程控制类和无人驾驶特征是“小包、高频、对时延极敏感”比如矿卡的位置、速度、刹车指令一包只有几百字节但要求端到端时延在20毫秒以内可靠性要做到99.99%。这类业务跑在公网互联网链路上是不可能达标的必须走专网或专用切片。第二类是视频回传和AI巡检特征是“大包、连续、以上行为主”。井下或采场的高清摄像头一路跑4~8Mbps1080P/H.265编码一个中型露天矿三四十路视频汇聚上行就要吃掉200~300Mbps。注意这里说的是上行不是下行。很多人规划带宽只问“下行多少”结果视频一开上行先炸。第三类是传感器和人员定位特征是“连接数多、单连接速率低”井下环境监测、边坡位移、人员标签这些终端一个基站可能挂几百个但每个只偶发几十字节。这三类业务如果混在一张网里跑就会出现视频把上行堵满、控制指令跟着抖动的局面。所以做5G网络架构设计时第一件事就是把这三类业务从逻辑上分离。常见做法是分成三个切片或者至少做独立的QoS队列和带宽保障。矿方在和运营商谈方案时不要只听“我们建了5G基站”要明确问“控制业务和视频业务的隔离是怎么做的靠什么参数保证”2.2 三种组网方式选型SA核心网与UPF下沉是关键5G在矿区的组网不只是“建几个基站”那么简单。按核心网和用户面部署位置主流有三种方式。第一种是独立专网把完整的5G核心网、用户面功能UPF全部下沉到矿区机房矿区内部数据不出矿时延最低安全性最高但建设和运维成本也最高。第二种是公网专用利用运营商公网基站把UPF下沉到矿区或就近的地市机房数据流在本地卸载成本和建设周期适中是目前最常见的接入方式。第三种是混合组网控制业务走本地专网切片视频和普通数据走公网通道。选择时主要看三个条件矿区面积、业务敏感度和投资预算。井工矿和大型露天矿方圆几公里甚至几十平方公里适合独立专网或UPF下沉到矿中小矿区、改造项目适合公网专用如果只是先试点无人驾驶可以先用混合组网跑通业务流程再慢慢扩容。但不管选哪种有一点是共同的必须基于SA架构也就是5G独立组网。NSA那种“5G基站4G核心网”的双连接方案控制面还挂在LTE上时延和切片能力都受限做远程遥控和无人驾驶根本不现实。记住谈方案时先确认一句话“这个项目是不是SA组网核心网能不能下沉到矿区或本地机房。”2.3 网络切片与MEC把5G网络架构从“能用”变成“够用”网络切片是5G赋能智慧矿山区别于4G的核心能力。简单说切片就是在一张物理5G网络上切出多条逻辑网络每条逻辑网络可以有不同的时延、带宽、优先级。矿区场景里最常见的划分是URLLC切片给远程控制、无人驾驶和紧急停机eMBB切片给视频回传和AI巡检mMTC切片给传感器和定位标签。配置切片后即使视频流量把网络打满控制指令仍然优先排队空口资源优先分配给它。另一块是MEC边缘计算。视频和AI业务如果全部回传云端时延和带宽都扛不住。把MEC部署在矿区机房摄像头视频流直接卸载到本地边缘节点做推理既能压缩回传带宽又能把AI识别时延控制在几十毫秒内。实际部署中UPF和MEC一般放在一起数据面同机房处理控制面和网管仍由运营商维护。在矿区的网络拓扑里UPF的虚拟IPVIP就是“本地断网逃生门”这条IP做得好不好直接决定后面排障效率。3. 从PPT到井下5G专网的现场部署与设备配置3.1 井下勘测先行覆盖设计与天线选型参数很多项目翻车都是从“PPT上画了个圈现场直接立杆”开始的。矿区无线环境跟城市完全不一样露天矿是开阔空间但粉尘大、大型机械遮挡多井下巷道是狭长空间弯道多、墙壁粗糙信号反射和绕射规律跟自由空间差别很大。常见做法是进场前先做射线追踪仿真把巷道的宽度、弯道角度、支护材质输进去预算出每个区域的参考信号接收功率RSRP和信噪比再带着仿真结果到现场实测。仿真不能省但也不能迷信现场总有些仿真算不出来的死角。天线选型有几个关键参数要确认。井下通常选矿用隔爆型RRU加定向天线或漏缆露天矿用室外型AAU安装在采场边坡、排土场或立柱上。覆盖半径不是固定的露天矿一般200~500米一个扇区井下直线巷道可以做到300~800米但岔路口和弯道内侧往往要单独补点否则会出现“直线上满格转弯就掉线”的情况。天线口功率也要注意井下受防爆和电磁辐射规范限制一般不会像室外那样开到满功率设计时要留出至少10dB的链路余量避免雨季煤尘和粉尘造成额外损耗。设备安装这块我一般会建议把基站的安装位置、天线朝向、馈线走向、取电位置全部画成一张施工图再配上安装验收表。现场施工队伍往往只看天馈安装高度不太注意朝向角等网络开通后才发现覆盖偏了返工成本极高。安装完必须做驻波比测试正常范围应该小于1.5驻波比超过2基本就是天馈系统有问题。3.2 基站部署与参数配置用华为5G网管核对小区对应框号基站物理安装只是第一步真正决定网络质量的是参数配置。开站时至少要核对这几类参数PCI物理小区标识、TAC跟踪区码、邻区关系、小区频点、发射功率、上下行时隙配比。这些参数在网管平台上一目了然但最容易踩坑的是“小区对应框号”这层映射。尤其是用华为5G网管的时候后台看到的是一个小区名比如“矿东_1小区”物理上它可能落在BBU的某块板卡上通过某个光口连到井下或采场的某个RRU/AAU。查小区对应的框号、板卡槽位和光口号目的就是确认“逻辑小区与实际设备位置一一对应”否则开站后发现覆盖方向和规划完全相反就是光口接错了。参数配置常见做法是先在网管上把基站的传输IP、管理IP、基带板槽位录进去再按规划批量下发小区参数。替换和扩容时也要走同一套流程新小区开起来后立刻做邻区核对和切换测试别让矿卡在采场边缘切不过去。井下基站还要特别注意TAC规划。同一片区域的基站尽量分配同一个TAC否则矿车每跨一个站就触发一次位置更新核心网信令压力大也可能引起待机卡寻呼失败。时隙配比是井下和露天矿差异最大的一项。井下视频回传需求大通常把上下行时隙配比调到3:1甚至更偏上行如果站址靠近办公区Office业务以下行为主配比又要调回来。这个参数在5G网络架构里叫“时隙格式”配置前先统计这个站下的业务比例再决定配比不能全矿一刀切。3.3 CPE接入与业务IP化矿卡、摄像头、传感器的接入方式终端接入是项目交付最容易拖期的环节。无人驾驶矿卡上一般装的是车载CPE5G模组这类设备要求支持SA模式、支持网络切片还要做好天线安装位置验证——车体是金属结构CPE天线装在车顶和装在驾驶室后窗效果差很多。安装后要做移动性测试让矿卡按真实作业路径跑一圈看切换是否掉链子。远控室的视频解码画面卡顿往往不是平台的问题而是CPE在矿区高速移动过程中跨基站切换时丢了包。摄像头和传感器则推荐直接接入CPE或工业网关尽量走有线到网关再通过5G上行避免每个摄像头都插一张SIM卡。摄像头如果直接插卡一旦网络波动视频流重连机制五花八门排障时非常痛苦。常见做法是矿区建一个本地视频接入网段摄像头汇聚到工业交换机再挂5G CPE这样摄像头只面对内网IP网络切换对它透明。IP化规划也要提前做。给每类业务划分独立的VLAN和IP网段控制网段、视频网段、传感器网段分开视频网段用大带宽切片控制网段用高优先级切片。这样后续做流量统计和故障定位只需要看哪一段网段拥塞省去抓包猜业务的时间。4. 5G在智慧矿山的应用落地无人驾驶、远程遥控与AI视频4.1 无人驾驶矿卡时延20ms的端到端实现无人驾驶矿卡对网络的要求是“低时延高可靠连续覆盖”。控制指令从调度中心下发到矿卡要经过核心网、传输网、基站空口再到车载CPE全链路端到端时延要求20ms以内空口丢包率要控制在0.1%以下。早期很多项目用普通运维测试工具APPPing一个公网IP延迟二三十毫秒就开始怀疑5G不行。其实问题出在测试方式上应该从矿区MEC机房到车载CPE做背靠背测试而不是去ping公网。做无人驾驶业务时网络侧我会重点调三个地方。第一给控制业务建独立切片空口优先级设为最高第二开启基站的调度器优化让URLLC业务的无线资源优先分配第三把UPF下沉到矿区本地保证控制流量不出园。在运营商的网管上这三项分别对应切片模板选择、QoS流优先级、UPF本地分流配置。任何一个环节没打通都会体现在矿卡“该停不停、该走不走”的异常上。不要忽略车端的网络冗余。矿卡本身要有“网络降级”的逻辑不能一断网就急刹常见做法是设两级阈值信号RSRP低于一定值先减速、超过一定时间再停车并让车辆在无网状态下靠惯性缓行到安全位置。这是车辆和网络两侧的联调工作网络侧再稳定也要给车端留足容错。4.2 远程遥控与视频回传上行带宽怎么算远程遥控场景比如挖掘机、钻机、井下铲运机对带宽的需求更直接。一套远程遥控系统至少要回传两路视频来一路主视角高清1080P一路环境视角标清甚至720P。按H.265编码算主视角4~8Mbps环境视角2~3Mbps控制指令只占很小带宽。但要注意视频回传是实时上行流一旦上行带宽不足最先表现出来的就是操作手那边画面模糊或卡顿随后误操作风险升高。带宽计算要按“同时工作设备数”算而不是按“在线设备数”算。比如矿区计划部署20台远程遥控设备实际同一时间最多12台在作业那就按12台×单台上行8Mbps96Mbps来规划上行带宽。如果摄像头还叠加了AI识别AI拉流会增加一路视频拷贝带宽预算要再放大20%~30%。4G时代远程遥控做不好很大原因就是上行带宽不够5G的eMBB切片能解决带宽但能不能持续稳定不拥塞靠的还是前面说的带宽规划。实测方法上可以在真机上用网管流量统计看UPF侧的上行吞吐更直接的办法是从业务侧逐台设备拉视频流逐个确认码率是否达到设计值。这里提供一个用ffprobe批量探测摄像头码率的脚本import subprocess import json def probe_rtsp(rtsp_url, timeout10): cmd [ ffprobe, -v, error, -select_streams, v:0, -show_entries, streamcodec_name,width,height,bit_rate, -of, json, rtsp_url ] try: out subprocess.run(cmd, capture_outputTrue, timeouttimeout, textTrue) data json.loads(out.stdout) stream data[streams][0] return { codec: stream.get(codec_name), resolution: f{stream.get(width)}x{stream.get(height)}, bitrate_kbps: round(int(stream.get(bit_rate, 0)) / 1000) } except Exception as e: return {error: str(e)} if __name__ __main__: urls [ rtsp://192.168.10.20:554/stream1, rtsp://192.168.10.21:554/stream1, ] for url in urls: print(url, probe_rtsp(url))逻辑说明脚本逐路连接摄像头的RTSP地址用ffprobe读取视频流编码格式和实时码率。跑一遍就能看到每路视频码率是否在预期区间比如H.265、1080P、码率4~8Mbps。如果某一路码率异常高或为0说明编码参数或网络链路有问题。参数说明rtsp_url是摄像头地址timeout10表示单路探测超时10秒防止某路摄像头无响应卡住整个巡检进程。跑完要对照带宽预算例如预算96Mbps实测全部设备码率总和为78Mbps可以接受如果发现某台设备码率飙到20Mbps要回查摄像头编码配置。4.3 5GAI视频巡检边缘推理的落地AI视频巡检皮带撕裂检测、人员违规识别、边坡裂缝监测是智慧矿山的高频需求但它对网络的消耗很多人没算明白。以1080P摄像头为例一路视频流4~8Mbps如果20路视频全部回传云端做推理上行带宽吃掉近150Mbps云推理的时延还不可控。常见做法是用MEC做就近推理摄像头视频流在矿区本地边缘节点解码、抽帧、推理只把识别结果和告警截图传回调度平台。这样部署后网络侧要关心的就变成两件事一是MEC节点到摄像头的带宽是否足够二是MEC到调度平台的告警链路是否可靠。前者用上一条的码率探测脚本验证后者建议给告警消息走独立QoS通道避免和视频大流量抢带宽。推理模型本身不在网络团队职责范围内但网络工程师要能给算法团队提供“干净”的视频流——不能让视频在传输链路里出现丢包、乱序导致画面花屏、跳帧否则模型检测率再高也白搭。5. 井下5G部署避坑从勘测到运维的5条踩坑记录5.1 基站时钟失锁井下GPS信号弱导致的随机断连现象井下基站开通初期网络在凌晨四点左右出现大量用户掉线持续十几分钟自动恢复。基站日志里频繁出现“时钟失锁”“同步异常”的告警。原因井下基站的同步信号依赖GPS授时天线但天线安装在井口或地面馈线过长、接头老化或角度不对导致GPS信号电平过低凌晨卫星分布变化时彻底失锁整个小区的用户面直接中断。很多现场勘查漏掉了对GPS天线安装位置的验证只看了基站侧告警。解决先用网管查基站的同步状态和卫星接收电平确认GPS天线实际收到的卫星数量和数据质量再检查馈线接头有没有进水或松动。如果井下条件实在收不到GPS改用IEEE1588PTP同步方案靠核心网侧的时钟源在传输网里传递时间同步信号就不依赖卫星了。这个坑在井工矿尤其常见设计阶段就要把同步方案定下来别等开站后才补。5.2 上行带宽规划失衡视频回放时把网络打爆现象远程遥控和AI视频业务开通后局部基站频繁拥塞调度中心画面卡顿而运营商网管显示下行带宽利用率很低。原因只按下行流量规划带宽没算视频回传的上行量。矿区视频流是上行为主而基站空口资源里上行时隙本来就少多路视频一旦同时工作上行资源瞬间被占满控制指令跟着排队拥塞、掉线全来了。解决先把全站业务分成“上行敏感”和“下行敏感”两类按实测码率算出总上行需求再倒推时隙配比和载波带宽。5G在矿区最好用TDD的3:1甚至更偏上行的时隙配比并给视频业务做限速单路摄像头限到8Mbps防止单台设备把整站的资源吃光。规划时你可以反直觉地算一次——矿区的5G网络行星是“上行”而不是“下行”。5.3 漏缆接头进水驻波比异常引发的间歇性弱覆盖现象井下某段巷道信号时好时坏矿车走到同一个岔路口就掉线但基站无告警后台数据也没有明显异常。原因井下用漏缆做连续覆盖时接头或分段器做在排水沟上方长期受潮进水天馈线驻波比升高但没有达到硬告警阈值导致漏缆辐射效率下降覆盖距离缩短。岔路口正好处在覆盖边缘于是每次到那都掉线。解决用天馈线测试仪俗称扫频仪对漏缆逐段做驻波比测试定位异常接头重新做防水密封并调整安装高度避开积水区。这一条建议列入季度巡检项目别等用户报障才查。驻波比数值是玄学吗不是超过1.5就该清理接头超过2基本直接换件。5.4 切片配了却在终端侧空转URSP规则没对现象网管侧切片配置齐全优先级也设了但矿卡的控制业务仍然和视频业务抢带宽时延没有保障。后台看切片利用率只有0。原因5G网络切片不只在网络侧配置终端侧也要按URSP规则把特定应用映射到对应切片。矿卡的CPE如果没导入URSP规则或者版本不支持DNN切片组合业务流量会全部默认走普通切片网络侧再优化也白搭。这是最典型的“网络侧黑匣子”问题你以为配置下发了实际终端根本没跟着走。解决先查CPE模组型号确认其支持的5G标准版本和切片能力再通过CPE的管理接口下发URSP策略指定控制业务走URLLC切片、视频业务走eMBB切片。最后在网管侧做一次业务验证看切片激活用户数是否上涨。如果终端型号不支持切片只能退而求其次用QoS流优先级做“软切片”效果差一档但至少业务可控。5.5 核心网单点故障UPS掉电等于全矿停产现象矿区市电波动机房UPS电池耗尽后本地核心网设备掉电所有井下基站同时脱管矿方调度大屏全红业务中断超过两小时。原因独立专网和UPF下沉方案把核心网放到矿侧却只依赖聊胜于无的普通电源没做双路市电UPS油机的分级供电。矿区电网质量比城市差电压暂降频繁核心网设备对电源连续性要求极高一掉电就是全矿业务归零。解决把核心网和UPF机房划为一级负荷配置双路市电、大容量UPS和自动启动的柴油发电机并加装电源监控远程就能看到电池健康度和负载。更完善的做法是设计“降级模式”当矿区核心网失联时基站自动回退到运营商公网可用模式至少保留语音和基本数据通信能力给现场应急处置留条活路。这块预算看着高但比起一次停产造成的损失不值一提。6. 让5G专网持续好用验收清单与一个巡检脚本6.1 验收不能只看RSRPSLA分层验收清单做了那么多项目我总结下来5G专网验收至少有五个维度必须逐项测缺一个都是在给后期埋雷。覆盖指标选矿区全部作业区域包括井下的关键点位测RSRP和SINR不能只看“有没有信号”要求RSRP大于-105dBm、SINR大于5dB才算及格。时延指标从MEC机房到车载CPE和终端分别测控制业务的端到端时延目标20ms以内。带宽指标用视频码率探测脚本逐路验证摄像头、CPE的实际上行吞吐。可靠性指标连续7天统计控制业务的丢包率要求在0.1%以下。移动性指标让测试车沿真实作业路线跑统计切换成功率和切换时延。每一项都要有记录、有签名不能拿网管的一个平均值应付。6.2 一个巡检脚本持续记录时延、抖动与丢包运维阶段我习惯放一个简单脚本在MEC或核心网侧持续向关键业务IP发起探测发现丢包或时延波动就写日志并告警。这样可以避免靠“用户报障才排查”把故障发现从被动变成主动#!/bin/bash VIP192.168.88.1 # MEC/UPF的关键业务虚拟IP按实际填写 LOG/var/log/5g_check.log WARN/var/log/5g_check.warn while true; do TIME$(date %Y-%m-%d %H:%M:%S) RESULT$(ping -c 10 -i 0.2 -q $VIP | tail -1) if echo $RESULT | grep -q 0.0% packet loss; then echo $TIME OK $RESULT $LOG else echo $TIME WARN $RESULT $WARN fi sleep 60 done逻辑说明脚本每60秒向核心网业务IP发起一次10包的快速ping间隔0.2秒约2秒完成一次。如果全部无丢包记录为正常一旦有丢包立刻追加到独立告警日志里。这样时间粒度足够细又不至于把日志刷爆。参数说明VIP按你的核心网设备地址改可以用UPF的虚拟IP也可以用车载终端IP-c 10是探测10个包-i 0.2是包间隔200毫秒这个间隔接近真实控制业务的消息频率sleep 60是每分钟一轮日常巡检够了高压期可以改30。脚本不复杂但它能让你在采场出问题之前先发现问题。我做矿上项目最深的教训是把“网络正常”等同于“网管页面没有红色告警”。真实矿区网络从来不是被一个故障打趴的而是被那些时好时坏的驻波比、偶尔丢一包的切换、不起眼的时钟失锁慢慢拖垮的。专网验收的那几天永远是最干净的真正见真章的是三个月后的雨季和极寒天气。把这些巡检、验收和SLA基线做在前面后续才不会天天被调度电话叫醒。希望帮到你。本文还有配套的精品资源点击获取
5G赋能智慧矿山：专网建设、无人驾驶与切片配置实战指南
简介一份面向矿业智能化与数字化转型从业者、5G解决方案规划人员的46页演示文稿集中探讨5G技术如何支撑智慧矿山网络建设。内容先分析矿山多类业务对通信的需求指出传统短距无线、工业无线、蜂窝网络在带宽、时延、连接可靠性与成本上的不足再围绕“三化融合”梳理智能化、信息化、自动化协同的矿山生产管理层级并给出5G在超高清视频回传、AR/VR远程维修、精准定位、无人驾驶、巡检机器人等场景中的应用框架。包体为1个PPT类型文件共46页可编辑演示文档整包约23.91MB适合直接用于方案构思和汇报讲解。目前已有76人浏览学习可供煤矿智能化项目立项前期的产品经理、售前工程师、通信网络规划人员以及矿山企业管理人员参考。通过该PPT可快速获得智慧矿山典型业务对网络指标的要求、5G关键使能技术配置思路以及矿山机器人、智能采煤等典型应用脉络有助于形成清晰的汇报材料或方案初稿。1. 5G赋能智慧矿山到底在赋能什么46页PPT之外的三张网上个月去一个露天矿看到无人驾驶矿卡在采场里停下了。调度员打电话说“网络波动了一下”车就自己刹停了后面的车堵了一串。那台矿卡装了5G CPE、配了毫米波雷达和激光雷达算法也早就验证过了但让它停下的偏偏是最后那段无线链路。也是那一刻我才想明白5G赋能智慧矿山很少卡在算法、设备和PPT上卡的是那根看不见的“空中网线”到底能不能扛住矿区环境。46页PPT只是把愿景讲清楚真正要落地的是三张逻辑网络一张给远程控制和无人驾驶的低时延高可靠网一张给高清视频回传的高带宽网还有一张给传感器和海量终端接入的广连接网。这篇笔记就按“选型→部署→应用→排障→运维”的顺序把这几张网怎么搭、参数怎么设、坑在哪讲清楚适合矿方信息口的人、运营商做5G to B交付的工程师以及做智慧矿山总集成的项目团队。2. 智慧矿山的5G专网选型独立专网、公网专用还是混合组网2.1 三张网的需求拆解控制、视频、传感器各吃什么带宽做方案第一步不是选设备而是把业务流量拆开。矿上的典型业务有三大类。第一类是远程控制类和无人驾驶特征是“小包、高频、对时延极敏感”比如矿卡的位置、速度、刹车指令一包只有几百字节但要求端到端时延在20毫秒以内可靠性要做到99.99%。这类业务跑在公网互联网链路上是不可能达标的必须走专网或专用切片。第二类是视频回传和AI巡检特征是“大包、连续、以上行为主”。井下或采场的高清摄像头一路跑4~8Mbps1080P/H.265编码一个中型露天矿三四十路视频汇聚上行就要吃掉200~300Mbps。注意这里说的是上行不是下行。很多人规划带宽只问“下行多少”结果视频一开上行先炸。第三类是传感器和人员定位特征是“连接数多、单连接速率低”井下环境监测、边坡位移、人员标签这些终端一个基站可能挂几百个但每个只偶发几十字节。这三类业务如果混在一张网里跑就会出现视频把上行堵满、控制指令跟着抖动的局面。所以做5G网络架构设计时第一件事就是把这三类业务从逻辑上分离。常见做法是分成三个切片或者至少做独立的QoS队列和带宽保障。矿方在和运营商谈方案时不要只听“我们建了5G基站”要明确问“控制业务和视频业务的隔离是怎么做的靠什么参数保证”2.2 三种组网方式选型SA核心网与UPF下沉是关键5G在矿区的组网不只是“建几个基站”那么简单。按核心网和用户面部署位置主流有三种方式。第一种是独立专网把完整的5G核心网、用户面功能UPF全部下沉到矿区机房矿区内部数据不出矿时延最低安全性最高但建设和运维成本也最高。第二种是公网专用利用运营商公网基站把UPF下沉到矿区或就近的地市机房数据流在本地卸载成本和建设周期适中是目前最常见的接入方式。第三种是混合组网控制业务走本地专网切片视频和普通数据走公网通道。选择时主要看三个条件矿区面积、业务敏感度和投资预算。井工矿和大型露天矿方圆几公里甚至几十平方公里适合独立专网或UPF下沉到矿中小矿区、改造项目适合公网专用如果只是先试点无人驾驶可以先用混合组网跑通业务流程再慢慢扩容。但不管选哪种有一点是共同的必须基于SA架构也就是5G独立组网。NSA那种“5G基站4G核心网”的双连接方案控制面还挂在LTE上时延和切片能力都受限做远程遥控和无人驾驶根本不现实。记住谈方案时先确认一句话“这个项目是不是SA组网核心网能不能下沉到矿区或本地机房。”2.3 网络切片与MEC把5G网络架构从“能用”变成“够用”网络切片是5G赋能智慧矿山区别于4G的核心能力。简单说切片就是在一张物理5G网络上切出多条逻辑网络每条逻辑网络可以有不同的时延、带宽、优先级。矿区场景里最常见的划分是URLLC切片给远程控制、无人驾驶和紧急停机eMBB切片给视频回传和AI巡检mMTC切片给传感器和定位标签。配置切片后即使视频流量把网络打满控制指令仍然优先排队空口资源优先分配给它。另一块是MEC边缘计算。视频和AI业务如果全部回传云端时延和带宽都扛不住。把MEC部署在矿区机房摄像头视频流直接卸载到本地边缘节点做推理既能压缩回传带宽又能把AI识别时延控制在几十毫秒内。实际部署中UPF和MEC一般放在一起数据面同机房处理控制面和网管仍由运营商维护。在矿区的网络拓扑里UPF的虚拟IPVIP就是“本地断网逃生门”这条IP做得好不好直接决定后面排障效率。3. 从PPT到井下5G专网的现场部署与设备配置3.1 井下勘测先行覆盖设计与天线选型参数很多项目翻车都是从“PPT上画了个圈现场直接立杆”开始的。矿区无线环境跟城市完全不一样露天矿是开阔空间但粉尘大、大型机械遮挡多井下巷道是狭长空间弯道多、墙壁粗糙信号反射和绕射规律跟自由空间差别很大。常见做法是进场前先做射线追踪仿真把巷道的宽度、弯道角度、支护材质输进去预算出每个区域的参考信号接收功率RSRP和信噪比再带着仿真结果到现场实测。仿真不能省但也不能迷信现场总有些仿真算不出来的死角。天线选型有几个关键参数要确认。井下通常选矿用隔爆型RRU加定向天线或漏缆露天矿用室外型AAU安装在采场边坡、排土场或立柱上。覆盖半径不是固定的露天矿一般200~500米一个扇区井下直线巷道可以做到300~800米但岔路口和弯道内侧往往要单独补点否则会出现“直线上满格转弯就掉线”的情况。天线口功率也要注意井下受防爆和电磁辐射规范限制一般不会像室外那样开到满功率设计时要留出至少10dB的链路余量避免雨季煤尘和粉尘造成额外损耗。设备安装这块我一般会建议把基站的安装位置、天线朝向、馈线走向、取电位置全部画成一张施工图再配上安装验收表。现场施工队伍往往只看天馈安装高度不太注意朝向角等网络开通后才发现覆盖偏了返工成本极高。安装完必须做驻波比测试正常范围应该小于1.5驻波比超过2基本就是天馈系统有问题。3.2 基站部署与参数配置用华为5G网管核对小区对应框号基站物理安装只是第一步真正决定网络质量的是参数配置。开站时至少要核对这几类参数PCI物理小区标识、TAC跟踪区码、邻区关系、小区频点、发射功率、上下行时隙配比。这些参数在网管平台上一目了然但最容易踩坑的是“小区对应框号”这层映射。尤其是用华为5G网管的时候后台看到的是一个小区名比如“矿东_1小区”物理上它可能落在BBU的某块板卡上通过某个光口连到井下或采场的某个RRU/AAU。查小区对应的框号、板卡槽位和光口号目的就是确认“逻辑小区与实际设备位置一一对应”否则开站后发现覆盖方向和规划完全相反就是光口接错了。参数配置常见做法是先在网管上把基站的传输IP、管理IP、基带板槽位录进去再按规划批量下发小区参数。替换和扩容时也要走同一套流程新小区开起来后立刻做邻区核对和切换测试别让矿卡在采场边缘切不过去。井下基站还要特别注意TAC规划。同一片区域的基站尽量分配同一个TAC否则矿车每跨一个站就触发一次位置更新核心网信令压力大也可能引起待机卡寻呼失败。时隙配比是井下和露天矿差异最大的一项。井下视频回传需求大通常把上下行时隙配比调到3:1甚至更偏上行如果站址靠近办公区Office业务以下行为主配比又要调回来。这个参数在5G网络架构里叫“时隙格式”配置前先统计这个站下的业务比例再决定配比不能全矿一刀切。3.3 CPE接入与业务IP化矿卡、摄像头、传感器的接入方式终端接入是项目交付最容易拖期的环节。无人驾驶矿卡上一般装的是车载CPE5G模组这类设备要求支持SA模式、支持网络切片还要做好天线安装位置验证——车体是金属结构CPE天线装在车顶和装在驾驶室后窗效果差很多。安装后要做移动性测试让矿卡按真实作业路径跑一圈看切换是否掉链子。远控室的视频解码画面卡顿往往不是平台的问题而是CPE在矿区高速移动过程中跨基站切换时丢了包。摄像头和传感器则推荐直接接入CPE或工业网关尽量走有线到网关再通过5G上行避免每个摄像头都插一张SIM卡。摄像头如果直接插卡一旦网络波动视频流重连机制五花八门排障时非常痛苦。常见做法是矿区建一个本地视频接入网段摄像头汇聚到工业交换机再挂5G CPE这样摄像头只面对内网IP网络切换对它透明。IP化规划也要提前做。给每类业务划分独立的VLAN和IP网段控制网段、视频网段、传感器网段分开视频网段用大带宽切片控制网段用高优先级切片。这样后续做流量统计和故障定位只需要看哪一段网段拥塞省去抓包猜业务的时间。4. 5G在智慧矿山的应用落地无人驾驶、远程遥控与AI视频4.1 无人驾驶矿卡时延20ms的端到端实现无人驾驶矿卡对网络的要求是“低时延高可靠连续覆盖”。控制指令从调度中心下发到矿卡要经过核心网、传输网、基站空口再到车载CPE全链路端到端时延要求20ms以内空口丢包率要控制在0.1%以下。早期很多项目用普通运维测试工具APPPing一个公网IP延迟二三十毫秒就开始怀疑5G不行。其实问题出在测试方式上应该从矿区MEC机房到车载CPE做背靠背测试而不是去ping公网。做无人驾驶业务时网络侧我会重点调三个地方。第一给控制业务建独立切片空口优先级设为最高第二开启基站的调度器优化让URLLC业务的无线资源优先分配第三把UPF下沉到矿区本地保证控制流量不出园。在运营商的网管上这三项分别对应切片模板选择、QoS流优先级、UPF本地分流配置。任何一个环节没打通都会体现在矿卡“该停不停、该走不走”的异常上。不要忽略车端的网络冗余。矿卡本身要有“网络降级”的逻辑不能一断网就急刹常见做法是设两级阈值信号RSRP低于一定值先减速、超过一定时间再停车并让车辆在无网状态下靠惯性缓行到安全位置。这是车辆和网络两侧的联调工作网络侧再稳定也要给车端留足容错。4.2 远程遥控与视频回传上行带宽怎么算远程遥控场景比如挖掘机、钻机、井下铲运机对带宽的需求更直接。一套远程遥控系统至少要回传两路视频来一路主视角高清1080P一路环境视角标清甚至720P。按H.265编码算主视角4~8Mbps环境视角2~3Mbps控制指令只占很小带宽。但要注意视频回传是实时上行流一旦上行带宽不足最先表现出来的就是操作手那边画面模糊或卡顿随后误操作风险升高。带宽计算要按“同时工作设备数”算而不是按“在线设备数”算。比如矿区计划部署20台远程遥控设备实际同一时间最多12台在作业那就按12台×单台上行8Mbps96Mbps来规划上行带宽。如果摄像头还叠加了AI识别AI拉流会增加一路视频拷贝带宽预算要再放大20%~30%。4G时代远程遥控做不好很大原因就是上行带宽不够5G的eMBB切片能解决带宽但能不能持续稳定不拥塞靠的还是前面说的带宽规划。实测方法上可以在真机上用网管流量统计看UPF侧的上行吞吐更直接的办法是从业务侧逐台设备拉视频流逐个确认码率是否达到设计值。这里提供一个用ffprobe批量探测摄像头码率的脚本import subprocess import json def probe_rtsp(rtsp_url, timeout10): cmd [ ffprobe, -v, error, -select_streams, v:0, -show_entries, streamcodec_name,width,height,bit_rate, -of, json, rtsp_url ] try: out subprocess.run(cmd, capture_outputTrue, timeouttimeout, textTrue) data json.loads(out.stdout) stream data[streams][0] return { codec: stream.get(codec_name), resolution: f{stream.get(width)}x{stream.get(height)}, bitrate_kbps: round(int(stream.get(bit_rate, 0)) / 1000) } except Exception as e: return {error: str(e)} if __name__ __main__: urls [ rtsp://192.168.10.20:554/stream1, rtsp://192.168.10.21:554/stream1, ] for url in urls: print(url, probe_rtsp(url))逻辑说明脚本逐路连接摄像头的RTSP地址用ffprobe读取视频流编码格式和实时码率。跑一遍就能看到每路视频码率是否在预期区间比如H.265、1080P、码率4~8Mbps。如果某一路码率异常高或为0说明编码参数或网络链路有问题。参数说明rtsp_url是摄像头地址timeout10表示单路探测超时10秒防止某路摄像头无响应卡住整个巡检进程。跑完要对照带宽预算例如预算96Mbps实测全部设备码率总和为78Mbps可以接受如果发现某台设备码率飙到20Mbps要回查摄像头编码配置。4.3 5GAI视频巡检边缘推理的落地AI视频巡检皮带撕裂检测、人员违规识别、边坡裂缝监测是智慧矿山的高频需求但它对网络的消耗很多人没算明白。以1080P摄像头为例一路视频流4~8Mbps如果20路视频全部回传云端做推理上行带宽吃掉近150Mbps云推理的时延还不可控。常见做法是用MEC做就近推理摄像头视频流在矿区本地边缘节点解码、抽帧、推理只把识别结果和告警截图传回调度平台。这样部署后网络侧要关心的就变成两件事一是MEC节点到摄像头的带宽是否足够二是MEC到调度平台的告警链路是否可靠。前者用上一条的码率探测脚本验证后者建议给告警消息走独立QoS通道避免和视频大流量抢带宽。推理模型本身不在网络团队职责范围内但网络工程师要能给算法团队提供“干净”的视频流——不能让视频在传输链路里出现丢包、乱序导致画面花屏、跳帧否则模型检测率再高也白搭。5. 井下5G部署避坑从勘测到运维的5条踩坑记录5.1 基站时钟失锁井下GPS信号弱导致的随机断连现象井下基站开通初期网络在凌晨四点左右出现大量用户掉线持续十几分钟自动恢复。基站日志里频繁出现“时钟失锁”“同步异常”的告警。原因井下基站的同步信号依赖GPS授时天线但天线安装在井口或地面馈线过长、接头老化或角度不对导致GPS信号电平过低凌晨卫星分布变化时彻底失锁整个小区的用户面直接中断。很多现场勘查漏掉了对GPS天线安装位置的验证只看了基站侧告警。解决先用网管查基站的同步状态和卫星接收电平确认GPS天线实际收到的卫星数量和数据质量再检查馈线接头有没有进水或松动。如果井下条件实在收不到GPS改用IEEE1588PTP同步方案靠核心网侧的时钟源在传输网里传递时间同步信号就不依赖卫星了。这个坑在井工矿尤其常见设计阶段就要把同步方案定下来别等开站后才补。5.2 上行带宽规划失衡视频回放时把网络打爆现象远程遥控和AI视频业务开通后局部基站频繁拥塞调度中心画面卡顿而运营商网管显示下行带宽利用率很低。原因只按下行流量规划带宽没算视频回传的上行量。矿区视频流是上行为主而基站空口资源里上行时隙本来就少多路视频一旦同时工作上行资源瞬间被占满控制指令跟着排队拥塞、掉线全来了。解决先把全站业务分成“上行敏感”和“下行敏感”两类按实测码率算出总上行需求再倒推时隙配比和载波带宽。5G在矿区最好用TDD的3:1甚至更偏上行的时隙配比并给视频业务做限速单路摄像头限到8Mbps防止单台设备把整站的资源吃光。规划时你可以反直觉地算一次——矿区的5G网络行星是“上行”而不是“下行”。5.3 漏缆接头进水驻波比异常引发的间歇性弱覆盖现象井下某段巷道信号时好时坏矿车走到同一个岔路口就掉线但基站无告警后台数据也没有明显异常。原因井下用漏缆做连续覆盖时接头或分段器做在排水沟上方长期受潮进水天馈线驻波比升高但没有达到硬告警阈值导致漏缆辐射效率下降覆盖距离缩短。岔路口正好处在覆盖边缘于是每次到那都掉线。解决用天馈线测试仪俗称扫频仪对漏缆逐段做驻波比测试定位异常接头重新做防水密封并调整安装高度避开积水区。这一条建议列入季度巡检项目别等用户报障才查。驻波比数值是玄学吗不是超过1.5就该清理接头超过2基本直接换件。5.4 切片配了却在终端侧空转URSP规则没对现象网管侧切片配置齐全优先级也设了但矿卡的控制业务仍然和视频业务抢带宽时延没有保障。后台看切片利用率只有0。原因5G网络切片不只在网络侧配置终端侧也要按URSP规则把特定应用映射到对应切片。矿卡的CPE如果没导入URSP规则或者版本不支持DNN切片组合业务流量会全部默认走普通切片网络侧再优化也白搭。这是最典型的“网络侧黑匣子”问题你以为配置下发了实际终端根本没跟着走。解决先查CPE模组型号确认其支持的5G标准版本和切片能力再通过CPE的管理接口下发URSP策略指定控制业务走URLLC切片、视频业务走eMBB切片。最后在网管侧做一次业务验证看切片激活用户数是否上涨。如果终端型号不支持切片只能退而求其次用QoS流优先级做“软切片”效果差一档但至少业务可控。5.5 核心网单点故障UPS掉电等于全矿停产现象矿区市电波动机房UPS电池耗尽后本地核心网设备掉电所有井下基站同时脱管矿方调度大屏全红业务中断超过两小时。原因独立专网和UPF下沉方案把核心网放到矿侧却只依赖聊胜于无的普通电源没做双路市电UPS油机的分级供电。矿区电网质量比城市差电压暂降频繁核心网设备对电源连续性要求极高一掉电就是全矿业务归零。解决把核心网和UPF机房划为一级负荷配置双路市电、大容量UPS和自动启动的柴油发电机并加装电源监控远程就能看到电池健康度和负载。更完善的做法是设计“降级模式”当矿区核心网失联时基站自动回退到运营商公网可用模式至少保留语音和基本数据通信能力给现场应急处置留条活路。这块预算看着高但比起一次停产造成的损失不值一提。6. 让5G专网持续好用验收清单与一个巡检脚本6.1 验收不能只看RSRPSLA分层验收清单做了那么多项目我总结下来5G专网验收至少有五个维度必须逐项测缺一个都是在给后期埋雷。覆盖指标选矿区全部作业区域包括井下的关键点位测RSRP和SINR不能只看“有没有信号”要求RSRP大于-105dBm、SINR大于5dB才算及格。时延指标从MEC机房到车载CPE和终端分别测控制业务的端到端时延目标20ms以内。带宽指标用视频码率探测脚本逐路验证摄像头、CPE的实际上行吞吐。可靠性指标连续7天统计控制业务的丢包率要求在0.1%以下。移动性指标让测试车沿真实作业路线跑统计切换成功率和切换时延。每一项都要有记录、有签名不能拿网管的一个平均值应付。6.2 一个巡检脚本持续记录时延、抖动与丢包运维阶段我习惯放一个简单脚本在MEC或核心网侧持续向关键业务IP发起探测发现丢包或时延波动就写日志并告警。这样可以避免靠“用户报障才排查”把故障发现从被动变成主动#!/bin/bash VIP192.168.88.1 # MEC/UPF的关键业务虚拟IP按实际填写 LOG/var/log/5g_check.log WARN/var/log/5g_check.warn while true; do TIME$(date %Y-%m-%d %H:%M:%S) RESULT$(ping -c 10 -i 0.2 -q $VIP | tail -1) if echo $RESULT | grep -q 0.0% packet loss; then echo $TIME OK $RESULT $LOG else echo $TIME WARN $RESULT $WARN fi sleep 60 done逻辑说明脚本每60秒向核心网业务IP发起一次10包的快速ping间隔0.2秒约2秒完成一次。如果全部无丢包记录为正常一旦有丢包立刻追加到独立告警日志里。这样时间粒度足够细又不至于把日志刷爆。参数说明VIP按你的核心网设备地址改可以用UPF的虚拟IP也可以用车载终端IP-c 10是探测10个包-i 0.2是包间隔200毫秒这个间隔接近真实控制业务的消息频率sleep 60是每分钟一轮日常巡检够了高压期可以改30。脚本不复杂但它能让你在采场出问题之前先发现问题。我做矿上项目最深的教训是把“网络正常”等同于“网管页面没有红色告警”。真实矿区网络从来不是被一个故障打趴的而是被那些时好时坏的驻波比、偶尔丢一包的切换、不起眼的时钟失锁慢慢拖垮的。专网验收的那几天永远是最干净的真正见真章的是三个月后的雨季和极寒天气。把这些巡检、验收和SLA基线做在前面后续才不会天天被调度电话叫醒。希望帮到你。本文还有配套的精品资源点击获取