2026年8月，生态环境部门一份自行监测视频监控技术要求里，有几句话值得做监控的人读一遍：画面要覆盖关键点位，视频丢失、遮挡镜头、视频断网要能自动报警，在线率与录像完整率要符合管理要求。该标准自2026年10月1日起施行，试运行阶段单台设备在线率与录像完整率不得低于98%，正式运行后月度平均值须保持在95%以上。
这几句话把过去被当成"体验"的事变成了"验收"。画面看不清，是清晰度问题；画面传不回来，是系统不合格。
全景监控的联网压力，不在平均带宽在峰值
以一款公开的5G全景监控机型为例（厂商公开资料，2026年10月查阅）：8颗F1.0镜头拼成360°全景，全景通道最高11040×3616；PTZ通道4K、45倍光变、500米激光补光。机身IP67、-40℃到70℃、最大功耗150W、裸机14.6公斤------这不是机房里的小盒子，是装到户外高点、取电拉线、取网更难的重型设备。
翻成联网语言是三件事：双路主码流同时出流；码率不低，全景按H.265常见16--32Mbps、4K细节8--16Mbps，常态24--48Mbps；安装位置在塔顶或立杆顶端，有线回传的施工成本往往高于设备本身的联网模块成本。全景监控联网的难点，首先在于这个量级下的"持续出流压力"，而不是"信号好不好"。
本地存、按需传，才是算得过来的架构
24Mbps一小时约10.8GB，48Mbps约21.6GB；全程回传一天260--520GB，一个月8--15TB。
数一摆，结论就出来：全景监控的联网不是"一直传"。通行架构是本地存、按需传------录像写进机内卡或站内录像机，上行只跑子码流维持在线，需要调阅时再拉主码流。流量因此分三段：
常态：子码流3056×656、心跳与报警，每月数百MB至数GB。
事件：告警前后一段主码流、抓拍图，单次数十MB至数GB。
调阅：全景或4K主码流实时拉流，按24Mbps计，10分钟约1.8GB。
小套餐不够用，是三件事叠在一起的结果
调阅要实时拉主码流，等不了；事件突发，猜不到；多台同时调阅，排不了队。
按"平均用量"去配连接资源，一定在首次多路调阅时被打满。全景监控联网"不到月底就降速"的感受，多半不是连接本身出了问题，而是配置逻辑把三段流量混成了一段来估。
断网的代价，换了算法
以前的监控断网，是"这段时间没录上"；在在线率与完整率成为考核项的框架下，断网本身就可能构成系统不合格。对集成方而言，这件事落在三处：验收表上的在线率、运维响应时限、下一期的信任成本。一个点位掉线超过约定时长，使用方通常不区分光缆中断还是连接资源受限，只记一个判断：这套监控方案不稳定。
全景监控联网，真正要盯住的是"峰值承载"而非"流量单价"
设备自带5G，是留了插卡位置，不等于联网方案已经成立。落地还要解决三件事：连接资源归谁管理、超量阈值谁监控、异常断网谁先发现。这些不在设备厂商的交付范围内，也不应该被简化为一张"大流量卡"。
从技术架构看，全景监控联网需要对齐的是四件事：
其一，上下行能力对齐业务峰值。 全景双主码流同时出流时，上行占用是叠加的，不是单路码率乘以一个"平均在线比例"。
其二，承载方式要能区分"常态心跳"与"调阅突发"。 常态子码流和事件/调阅主码流如果共用同一条无差别的连接通道，突发流量就会挤占心跳与报警的上行空间。
其三，异常发现机制先于流量成本被考虑。 在线率考核之下，断网是否被及时感知，比每GB单价更直接地影响验收结果。
其四，连接资源的管理颗粒度要落到单设备。 多台全景设备同时运行时，没有单设备的用量可见性，就无法区分"正常事件调阅"与"异常持续回传"。
在线率、录像完整率、断网自动报警，考核的都不是镜头，是链路。5G全景监控把高清画面从高点送回来，而这条链路能不能长期成立，取决于联网架构是按"平均用量"设计的，还是按"峰值场景"设计的。把一张连接资源当耗材去比价，和把它当系统的一部分去设计，会在第一次多路调阅时给出完全不同的答案。