导语笔者过去几篇围绕硬件演进(固态PA、激励器、DRM链路、Nautel与GatesAir的新动作)讲了发射端的物理形态。这一篇换一个角度往发射端的上游走。国家广播电视总局近期部署的广播电视主流媒体系统性变革引领工程里有一句以科技创新推进数智化转型加快构建IP化、云化、智能化、一体化的综合性技术平台。这句话里的云化、IP化在发射端上游已经有一个跑了两三年的现成样本DAB的头端正在欧洲和澳大利亚批量搬上云这件事还没怎么进入国内同业的讨论。这里所说的云端是字面意思DAB的复用器、音频编码器、监控、数据插入器这些原本一整柜19英寸机架的设备作为软件实例跑在AWS、Azure、OVH这类公有云上输出经过IP网络直连到物理发射台的调制器。国外这两年走的是公有云直连发射台这条路。换到国内信号通路上有安全播出这条线这个形态不会照搬。值得记下来的不只是国外做了什么还有一条分界云放在信号面还是只放在管理面信号通路断了云还能不能自己接着跑。沿着这条分界云化跟安全播出之间到底是什么关系比上不上云本身更值得琢磨。▲图DAB头端的两种部署模式对比。左边是占两到三个19寸机架的物理头端右边是跑在公有云上的软件化头端两侧输出到发射台调制器的协议都是EDI(Encapsulation of DAB Interfaces)。差别在MUX在哪里跑、ETI/EDI流走什么链路。传统 DAB 头端的旧世界先把基线放清楚。一台标准 DAB 头端过去十年的物理形态大体长这样音频编码器把 AES 或 AoIP 流编码成 DAB 的 HE-AAC v2或老式 DAB 的 MPEG Audio Layer II按节目数量配 16 / 32 / 64 路业务复用器(Service Multiplexer)把每路节目的音频包、PAD(节目相关数据)、SLS(电台幻灯片)等装在一起输出 STI 流总复用器(Ensemble Multiplexer)把多路 STI 汇总成一个 DAB Ensemble输出 ETI 流送给发射台数据插入器节目关联数据、TPEG 交通信息、紧急预警包在这里注入监控解码器从 ETI 反向解出来确认头端没出问题管理系统网管、告警、配置同步最简单的小型 DAB 头端占一台 19 寸机架主备双机加冗余电源就是两机架。多 ensemble 的国家级头端(比如英国 BBC、瑞典 SR、丹麦 DR 那种)头端机房本身就是一间专门屋子。ETI 流从头端机房送到发射台传统做法是 E1 或 STM-1 这类电信级电路或者卫星租线。这条链路是 DAB 工程上最贵、最难弹性扩容的部分之一。EDI——让头端可以离开机房的协议让头端能搬上云的协议前提早就埋好了。ETSI 在 2009 年发布过 TS 102 693 标准定义了 EDI(Encapsulation of DAB Interfaces)。EDI 做的事机制上很简单把原本走 E1、同轴、专用串口的 ETI / STI / TII 接口统一打包进 IP 数据报。可以走 UDP(unicast 或 multicast)也可以走 TCP链路质量较差时再叠一层 SRT 抗丢包。工程意义有三层MUX 和调制器之间不再需要专用电信电路两端各连一根普通 IP 出口即可MUX 的位置不再绑定在发射台旁边可以是演播室、数据中心或公有云多个发射台可以共享一个上游 MUX云端 MUX 出一份 EDI 流复制 N 份送到 N 个发射台EDI 协议本身已经成熟很多年。真正让头端上云成为商品的是过去三到五年欧洲几家厂商把整套头端组件重写成可以在虚拟机和容器里跑的软件。四家正在做的厂商Paneda(挪威)挪威本土厂商DAB 头端是主业自报全球有 200 套以上系统在运行。挪威国内最有规模的部署是隧道场景把近 200 个公路隧道装上 Paneda 的 DAB 系统用于本地节目转发和紧急预警插入。国际部署里最大的一笔是 2021 年与澳大利亚 Telstra Broadcast Services 合作的全国 DAB 头端部署整套系统覆盖 ABC 的全国 DAB 网络。云端方案叫 Cloud DAB Head-End按服务订阅月费固定。DABCAST(波兰)波兰技术运营商 BCAST 推出的云端 DAB 平台是欧盟 H2020 计划资助过的项目(项目编号 6842342015 年立项)自我定位是全球首个全云端 DAB 广播服务。复用器作为软件用 CI/CD 方式开发配置走 Infrastructure as Code后端跑在 AWS、Azure、IBM Cloud、OVH 四家公有云上。客户使用方式接近 SaaS浏览器登录虚拟演播室云端 MUX 自动生成 DAB 流输出 EDI 推送到指定的发射台调制器。目标客户写得很明确——中小台、地方台、区域台因为 FM 与 DAB 同播阶段双轨成本翻倍让他们承受不了原来那套机架方案。WorldCast Systems(法国)WorldCast 旗下的 APT 系列做音频和 MPX over IP 编解码起家传统形态是机架式硬件。这几年他们把 APT IP Codec 重写成纯软件 Virtual APT把 SureStream(双流冗余传输)虚拟化成 Virtual SureStreamer。客户可以把云端的 Virtual SureStreamer 当作 STL 中继节点用从演播室或云端 MUX 拉一路音频或 MPX双流复制发到所有发射点。产品组合不止 DABFM MPX over IP 同样支持。Nautel(加拿大)Nautel 主业是发射机这两年把 DAB 头端做成 100% IP 的软件平台可以部署在物理服务器、虚拟机、容器或公有云上。和 NX 系列发射机配套使用时整条链路(头端加发射机)都能远程托管和监控。笔者前几天在《Nautel 2026 三个动作》里提到的 AirWatch365、$299/月软件订阅背后就是这套架构在支撑。谁在用谁没用云端 DAB 头端的客群从来不是国家级旗舰系统。BBC、SR、DR 这类大台的头端仍然是双机房加物理设备加专用骨干网工程上已经稳定运行十几年没有上云动机。实际客户在另一头原本上不起 19 寸机架方案的中小型商业台、覆盖一州一市的区域和地方台、刚拿到牌照想低成本起步的新台以及隧道、体育场、地铁等补盲覆盖类小型部署。挪威隧道、澳大利亚 Telstra 全国网、欧洲十几家中小台过去三四年的实际运行经验大致归纳协议层面已经成熟EDI over IP(必要时叠 SRT)的稳定性足以支撑商业级播出公有云本身的多区域、多可用区可靠性够用瓶颈通常在云到发射台的最后一公里 IP 出口故障模式从头端硬件层面转移到了网络层面(抖动、运营商出口问题)监控和工程响应的方式要跟着换业内常用目标值是 99.9% 可用性。这个数字对中波或短波旗舰台来说不够(旗舰目标通常是 99.99% 甚至 99.999%)但对中小台覆盖区已经够用。对国内同业的参照意义DAB 在中国大陆没有商用部署。国内调频频段的数字标准 CDR 仍在演进。这套云端头端方案不能直接照搬到中国 CDR 台站。但有几个层面是可以参照的。协议解耦的工程思路是中性的。把头端到发射台这一段从专用电路解耦成 IP 链路是任何数字广播标准都可以走的工程路径。CDR 头端到发射台的复用流接口、紧急预警数据流、附属数据通道原理上同样可以走 IP 化的传输方式。从软件化到云化之间只差一层部署位置的选择。SaaS 化的商业模式同样适用于中小台。笔者此前讨论 Nautel 软件订阅时已经触及这条线索发射端的 SaaS(GatesAir 的 AirWatch365、Nautel 的远程托管)和头端的 SaaS(Paneda、DABCAST 的云端订阅)是同一阵风。地方台对一次性设备投入也有财务压力按月订阅模式如果合规允许对地方台不是没有想象空间。卡住国内台站上云的不是技术。卡点至少有三层广电系内网与公有云之间的接入边界按当前监管要求是封闭的节目数据、用户数据、监控数据涉及网络安全与数据出境合规国家级和省级广播应急网络对物理可控性的要求与公有云的运维模式存在差异这三点不是云厂商或者头端厂商能单方面解决的。即使协议层面已经打通、商业化产品也可买落地路径还要等政策环境和合规框架的对接到位。欧洲和澳大利亚的同行能直接走上去是因为他们的监管框架在那条路径上对云原生服务比较友好。把欧澳两年的经验放在一边云端 DAB 头端目前看仍是一种细分市场方案未必会成为全行业的统一路径。它的成立条件比较具体特定客群(中小台与小覆盖部署)加上特定监管环境(对公有云友好)由协议成熟(EDI)和厂商产品化(Paneda 这类)共同推动出来的工程模式。欧洲和澳大利亚走了两年公开的运行数据和案例能支撑一个判断在适用场景里云端头端的可靠性足以承担商业播出。但要搬到中国需要监管、合规、网络架构层面的多个变量同时配合这套配合目前没有出现迹象。