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