通信技术 on 红旗下的蛋

专场

Sun, 20 Sep 2026 21:45:00 +0000

文化馆换了馆长。

新馆长到任一个月，点了一出戏，不是现成的，是个题。

专场，演给他和他带来的人看。

社长去接活，回来只记住一句：

“看看水平。”

他学这句话的时候，眉头皱了。

我们问社长馆长还说了什么，他说就这一句。

我们问他馆长要什么样的戏，他说他要是问了，就是承认社里没水平。

所以他没问。

社长回来就把活儿压给了导演。

导演问社长，馆长到底想要什么。

社长说：

“你排出来，他看了就知道。”

导演没再问。

后来导演跟我说，他其实也不知道“看看水平”是什么水平。

但他不能跟社长说不知道——

社长已经不知道了，导演再不知道，这活儿就没人接了。

“看看水平”就这样长成了一张单子。

单子是我拟的，拿去给社长勾，勾完就成了“馆长的要求”。

八条。

没有一条是馆长说的，条条是路上怕他的人添的：

导演怕冷，添热闹；

演员怕接不住，添短；

社长怕砸，添稳。

最可笑的是我。

单子是我拟的，却分不清哪句是听来的，哪句是我替他想的。

动笔前我卡了半个月。

写浅了，怕他当我是糊弄；

写深了，怕他当我是显摆。

社长说，你得摸他的耳朵——他爱听什么，不爱听什么。

我问怎么摸。

社长说：

“你写戏的，自己想办法。”

我想了几天，没办法。

他刚调来，镇上没人跟他熟。

后台的老头给了唯一一条：

“馆长看节目，手爱在扶手上打拍子。”

“歌舞队出来的，”老头说，“他听的是板眼，不是词。”

我把这句抄在本子第一页。

排了小一个月。

导演的尺子换了刻度，从前量台上立不立得住，这阵子量馆长爱不爱看。

可一屋子人，谁也没见过他。

排一出给一个没见过的人看的戏，每把尺子上刻的都是同一个人，一个想出来的人。

每过一轮，屋里的把握多一分；

磨到定稿，满屋子只剩我一个人没把握。

因为只有我知道，那个人是想出来的。

社长那阵子老来排练厅。

他不看戏，看导演。

导演说行了，他就点头；

导演皱眉，他就问要不要再改改。

有一回他问我：

“这出戏能不能拿得出手？”

我说能。

他说：

“不是问你，是问馆长。”

我说我不知道馆长要什么。

他说：

“我也不知道，但你不能让馆长觉得我们不知道。”

演出那天，我照旧坐最后一排。

他坐正中间。

从正中间到最后一排，七排椅子。

平时这七排各坐各的，那天我头一回觉得，它们是一串的。

他的后脑勺我盯了全场。

手也确实在打拍子。

可我不知道那拍子是什么意思。

入了戏，还是数还剩几分钟？

该响的包袱，齐齐整整地哑了。

他笑了两回。

一回落在我最板的那段独白上。

我最用力的地方，他没动；

我随口带过的地方，他倒回头跟旁边的人咬了句耳朵。

管灯的说，第三幕他看了表。

掌声很齐，也很客气。

我头一回知道，掌声也能是空的。

散场时社长站在门口送。

馆长握他的手，说了句什么。

社长笑着点头，笑得比平时久。

那天晚上社长喝多了，说了一句：

“他也没说好，也没说不好。”

我问：

“那你笑什么？”

他说：

“我不能不笑。”

之后几天，我收各层的话。

社长说，馆长很满意。

导演说，社长说了，馆长很满意。

后台的老头私下跟我说，中场休息，馆长问过一句：

“后头还有没有？”

这一句，谁也没往上送。

馆长跟社长握手时说的话，三天后传到我这儿，有了三个版本。

我去找社长，要他点戏时的原话。

社长想了半天。

“看看水平”之外，又想起半句：

“前头……老问文化的事。”

这半句，是散场之后才想起来的。

我愣的不是头一句，是这一句。

原来他也是角儿。

他也有他的台，他的观众。

这出戏是演给他看的，更是演给他台上看的——

他要拿这出戏，回他的台上说事儿。

我们排一个月，是给他备台词。

馆长要什么？

他要的未必是一出多好的戏。

他要的是从这出戏里带走一句话。

但他不能说“我要一句能带回去的话”，那太露。

他只能说“看看水平”。

他心里大概也不知道“水平”长什么样，只知道到时候看见了，他就知道了。

我们排了一个月，他等了一个月。

他比我们还怕这出戏不成——

不成，他回去没法说。

社长要什么？

他要一个能交差的东西。

但他不知道馆长认什么，也不敢问。

他只能一层一层往下压，压到导演，压到我。

他嘴上说“看看水平”，心里想的是：

“别砸在我手里。”

他笑了一晚上，笑到最后腮帮子疼。

这回我大概明白了。

以后再碰到这种专场，我不会先猜他懂多少戏，也不会先猜他喜欢什么。

我只琢磨一件事：

散场之后，他要带哪句话出这个门。

带得走的话是戏钱，剩下的都是白送。

浅和深的死结，也是这么解开的。

头里加一段短的，三句话，把门里的规矩递到门外。

正戏照正戏写，该多深多深，门道埋在底下，遇上内行自己会亮。

再印一份戏单，搁在座位扶手上，看不看随他。

没人翻，它也在；

懂行的翻两页，就知道这出戏底下有东西。

板眼也要清。

戏可以深，几折、每折多大、哪里起哪里落，句句要带数。

下一个专场不知道哪天来。

来之前我备三样。

先打听他从前在哪儿，爱听什么，是从哪儿养出来的。

再要一句原话。

原话是这条路上唯一没被改过的东西。

最后，头里那三句短话，先写出来。

写完这篇，我该去写那三句了。

从“承载”到“服务”：我对传输网络业务化的一点理解

Wed, 16 Sep 2026 16:54:00 +0000

最近参与一个材料的编写，反反复复被灌输“业务网”、“承载”、“客户需求”、“产品”、“能力”这些概念。同一个词，对不同的领导来说，或者概念不同，或者范围不同，搞得拼命去理解一个本以为了解的词的真正含义。不同的章节，用词也随意：有时“能力”和“产品”混着用，有时“承载”一会儿指网络、一会儿指网络干的事。材料改了好几轮，我也被绕了好几轮。刚好有个空隙，索性停下来，先把这些词的定义自己梳理一遍、理解一遍。

先看“承载”。这个词含义应该很清楚：连接业务网元。5G 基站连BBU，OLT 连 BRAS，专线节点之间互联，IDC 之间打通。业务网在上面，传输网在下面；业务负责功能，传输负责连接。传输网回答的问题是：“业务网元之间怎么连？”这就是承载。

网络能力：网络本身能做什么

如果先不管上面的业务，只看传输网自己，会发现它其实有很多“本事”：能建端到端连接，能给不同带宽，能做小颗粒承载，能动态调带宽，能选低时延路径，能做保护和恢复，能给 QoS 保障，还能在光层、电层之间协同调度。

过去习惯把这些叫“传输网的功能”。但换个角度，它们其实是网络自身的能力。承载说的是网络承担什么角色，能力是说这个网络本身到底能做什么？

我暂时把网络能力理解成：网络在技术和资源层面能够执行的基本功能单元，可以被网管系统配置。

网络产品：把能力打包成什么

单个网络域还好，一旦跨域、跨厂商、跨层次，事情就复杂了。比如有人要一条“跨区域 100G 端到端连接”，底层可能经过多个省份、多个网络域、多个厂家。如果每个网络都按自己的方式配，上层系统就得懂下面所有细节，显然不现实。

更合理的方式是：上层只说“我要一条 100G 跨域连接”，下面的编排系统自己去算路径、协同资源、配置设备、开通业务。对上层来说，原来一堆复杂的能力，被打包成了一个简单的东西。

这就是我理解的“网络产品”：把一个或多个网络域中的网络能力组合、抽象、封装，形成一个标准化、可被调用的能力单元。

这里有个有意思的现象：能力和产品的定义，其实是被网络边界决定的。如果整条链路就在同一个厂家、同一个网络域内，网管开一条电路，能力几乎就是产品，两者基本等同。只有跨省、跨域、跨厂商，封装和抽象才真正显示出价值。所以这两个概念有时一样有时不同。

TM Forum：一个可以参照的现成框架

查了些资料才知道，这个思路在 TM Forum（电信管理论坛）那里已经有成熟的框架。

它的核心是把网络世界分成三层：

• Resource（资源） ：物理/逻辑的设备、波道、连接
• Service（服务） ：对资源的技术性配置组合，面向网络的技术视角
• Product（产品） ：面向客户的销售视角，含价格、SLA、合同条款

每一层又分规格和实例：规格进目录、可以定价上架，实例才是真正交付和运行的东西。

配套的运营架构叫 ODA，由老的 eTOM（流程）、SID（信息）、TAM（应用）三大框架收敛而来，思路是把运营系统拆成标准化“积木块”，块之间用统一编号的 Open API 通信——比如 TMF620 产品目录、TMF633 服务目录、TMF641 服务订单、TMF622 产品订单。

我的理解和 TMF 的对应

对照下来，大致是这样：

我的理解	含义	TMF 对应
承载	网络承担的角色	Resource（资源层）
能力	网络能做什么	分散在 Resource 和 Service 之中
网络产品	把能力打包成什么	Service 规格（进服务目录）
网络服务/商品	客户可以买到什么	Product 规格 + 定价（进产品目录）

TMF 的 “Service” 对应我说的“网络产品”，TMF 的 “Product” 对应我说的“网络服务/商品”，正好错位半层，不过知道就行了，我也不必改正我的说法。

至于“能力”，TMF 没有单独设一层。这让我意识到，“能力”更像一个视角而不是层级——同一个网络功能，站在网络侧看是能力，被参数化、封装之后，就是产品。一句话概括三层的“用户”： 能力是给系统调的，产品是给订单用的，服务是给客户签的 。

网络服务：客户最终买到的是什么

有了“跨域 100G 连接”，是不是就已经是业务了？我觉得还不能这么简单说。客户真正买的，通常不是抽象的“能力”，而是一条可以签合同的专线。

专线要成为可销售的商品，还需要很多网络之外的东西：客户受理、订单、资源确认、开通、交付、SLA、计费、故障处理、运维保障。这正是 TMF 里 Service 和 Product 的分界：技术规格在服务目录里，加上定价和商务条款进入产品目录，才真正进入运营商的业务体系。

承载并没有消失

写到这里，有一点我觉得特别重要：这并不是说“承载不重要了”。

无论能力、产品还是服务，最底层仍然是传输网的连接和承载能力。没有这些，后面的东西都不存在。真正变化的不是“传输网不再承载”，而是：传输网除了承载，自身的能力开始被显性化、抽象化和产品化。

过去的关系是：业务提出连接需求 → 传输网负责承载。现在可能逐渐变成：业务提出意图 → 网络提供能力 → 能力组合成产品 → 产品再变成服务。

所以我更愿意把“传输网络业务化”理解成：在继续做好承载的基础上，网络自身的连接、调度和保障能力开始被抽象、封装、编排，并逐渐以产品和服务的形式向上提供。

只是我目前的一个理解

说到底，这篇文章不是要给这几个概念下标准定义。同一个词，不同人理解本来就不一样，不同企业、不同系统、不同业务体系里更是如此。

我现在暂时把它们理解成：

• 承载：网络承担的角色（TMF 的 Resource）
• 能力：网络能做什么（视角，而非独立层级）
• 产品：把能力打包成什么（TMF 的 Service）
• 服务：让客户可以买到什么（TMF 的 Product）

也许还不够严谨，但把这几个概念分开、再挂到 TMF 的框架上，以后读相关文档、想传输网怎么建、怎么开放、怎么支撑新业务，好像都比以前清楚了一些。

顺带记一笔：GSMA / Linux Foundation 的 CAMARA 项目（TM Forum 参与 API 规范）正在做网络能力开放，比如应用按需申请时延/带宽等级的 QoD API，算是“能力产品化”的最新实践，闲了可以去看看。