3GPP TS 28.312 意图驱动管理服务 --- 极详细通俗解读
原文档版本 :Release 19
本文目标 :让哪怕不是通信专业的航空宇航博士也能看懂
阅读前心态:你不需要懂5G协议细节,只需要带着"我想让网络自己干活"的思路来看
一、这篇文档在讲什么?(一句话总结)
这篇文档定义了一套标准,让网络运营商可以"告诉网络想要什么结果",而不需要"告诉网络具体怎么做"。
想象一下:
- 传统方式:你告诉厨师"先切葱花,再热油,放入葱姜蒜,倒入酱油......"(告诉系统每一步怎么做)
- 意图驱动方式:你告诉厨师"我要一盘鱼香肉丝"(告诉系统你想要什么结果)
这篇文档就是电信行业为了能让5G网络"听懂人话"而制定的国际标准。
二、核心概念(最最重要的基础)
2.1 什么是"意图"(Intent)?
定义 :意图就是"你希望网络达到什么状态",不包含如何达到的细节。
一个类比------叫外卖:
- ❌ 传统方式(非意图):你打电话说"请骑车到解放路82号,敲门,把餐放门口,然后按门铃通知我"------你告诉对方每一步怎么做
- ✅ 意图方式:你说"我今晚7点要吃一份宫保鸡丁盖饭"------你只告诉对方你想要的结果
文档里的官方定义:
意图(intent):提供给3GPP系统的期望,包括需求、目标和约束条件,而不指定如何实现它们。
简单说:"说你要什么,别说怎么做。"
2.2 为什么需要意图?(为什么5G需要这套东西?)
5G网络比4G复杂太多太多,几个原因:
- 网络超级复杂:5G有大量基站、天线、核心网设备、边缘计算节点,而且来自不同厂商
- 业务需求多样:自动驾驶需要超低延迟(1毫秒),视频监控需要大带宽,智能电表需要海量连接
- 运营商也想省事:不想每次调整都派工程师去手动配设备
核心驱动力 :电信系统需要能够根据运营商的业务目标和客户的期望来自动调整运行,推动客户从关注"如何做"转向关注"做什么"。
三、三个关键角色(谁在跟谁说话?)
文档定义了三类参与方,就像一个通信产业链的上下游:
3.1 通信服务客户(CSC)
- 角色:最终客户,比如一家快递公司、一个电视台、一家自动驾驶公司
- 他们要什么 :通信服务
- "我要在2026年6月15号到20号,在上海浦东新区为500辆物流车提供实时定位通信服务"
- 他们不关心:网络是怎么搭建的、基站是哪个厂家的
3.2 通信服务提供商(CSP)
- 角色:运营商,比如中国移动、AT&T
- 他们要什么 :网络能力
- "为417号公路沿线提供V2X(车联网)网络服务,同时支持500辆车"
- 他们不关心:具体哪个基站做这件事
3.3 网络运营商(NOP)
- 角色:管网络的人,可能是运营商内部的运维部门
- 他们要什么 :设备配置
- "在指定区域内提供无线网络服务,满足覆盖和吞吐量要求"
- 他们不关心:基站内部芯片级参数
总结关系
CSC(客户)--> 说"我要服务"
↓
CSP(运营商)--> 说"我需要网络能力"
↓
NOP(运维)--> 说"我需要配置设备"
↓
NEP(设备商)--> 干活
每一层都只告诉下一层**"要什么",不说"怎么做"**。
四、意图驱动管理系统的工作流程(一张图看懂)
4.1 完整流程
想象你(消费者)跟一个智能管家(系统)对话:
你:我要一个能覆盖上海体育馆的5G网络
↓
管家:收到!(创建意图记录)
↓
管家:我需要检查一下能不能做到
↓
如果可以:
↓
管家:我开始工作了(自动配置基站、天线等)
↓
管家:搞定!网络已开通(反馈结果)
↓
管家:我会持续监控,如果网络变差了我会自动调整
↓
也可以回来说:对不起,做不到,因为xxx原因
如果你改主意了:
你:我要修改目标,覆盖范围改大一点
↓
管家:好的,重新检查和执行
4.2 六个基本操作(意图生命周期)
这张表告诉你,你对一个"意图"能做什么操作:
| 操作 | 什么意思 | 类比 |
|---|---|---|
| 创建意图 | 提出一个新需求 | "我要一个网络覆盖上海体育馆" |
| 激活意图 | 让一个暂停的需求重新生效 | "之前暂停了,现在继续" |
| 停用意图 | 暂时不执行,但不删除 | "先放着,回头再说" |
| 删除意图 | 彻底取消需求 | "这个需求不要了" |
| 修改意图 | 调整需求内容 | "覆盖范围再大一点" |
| 查询意图 | 查看需求和执行状态 | "我之前提的需求现在怎么样了?" |
五、意图的内容长什么样?(详细拆解)
一个"意图"不是一句话,它是有结构的,就像填表格一样。
5.1 意图的组成结构
一个意图(Intent)包含:
├── 一组意图期望(IntentExpectations)------你想要的东西
│ ├── 期望对象(ExpectationObject)------对谁提要求
│ │ ├── 对象类型(objectType)------比如"无线网络"、"5G核心网"
│ │ ├── 对象实例(objectInstance)------具体哪个网络
│ │ └── 对象上下文(objectContexts)------过滤条件,比如"在上海"
│ ├── 期望目标(ExpectationTargets)------要达到什么指标
│ │ ├── 目标名称(targetName)------比如"用户下载速度"
│ │ ├── 条件(targetCondition)------比如"大于"
│ │ └── 值范围(targetValueRange)------比如"300Mbps"
│ └── 上下文(expectationContexts)------附加条件,比如"晚上8点到10点"
├── 上下文(intentContexts)------全局条件
└── 报告控制(intentReportControl)------怎么给我汇报
5.2 一个具体例子(让你看到底长啥样)
假设一个运营商想在一个区域部署无线网络,他的"意图"大概长这样:
yaml
意图编号: "Intent_1"
名字: "在上海浦东部署无线网络"
期望列表:
- 期望ID: "1"
动词: "交付" # 是交付还是保障
期望对象:
对象类型: "无线子网络"
对象上下文: # 限定在什么范围
- 覆盖区域: 上海浦东的某个多边形区域
- 运营商: "中国移动"
- 频率: "n39频段"
- 无线接入技术: "NR(5G)"
期望目标:
- 目标名称: "弱覆盖比例"
条件: "小于"
值: "10%"
目标上下文:
- 弱信号阈值: "小于-130dBm"
- 目标名称: "平均上行用户吞吐量"
条件: "大于"
值: "100Mbps"
- 目标名称: "平均下行用户吞吐量"
条件: "大于"
值: "300Mbps"
优先级: 1
观察周期: 60分钟
说白了就是一个结构化的需求清单。
六、意图的四个核心组件详解(逐条说明)
6.1 期望对象(ExpectationObject)------对谁提要求?
你总得告诉系统你对什么东西有要求吧?这个就是那个"什么东西"。
可以有三种方式指定:
- 按类型:比如"所有5G基站"(不指定具体哪个)
- 按实例:比如"上海体育馆东侧的那个基站"(指定具体哪个)
- 按上下文:比如"上海浦东新区内的所有基站"(用条件筛选)
6.2 期望目标(ExpectationTarget)------要求什么指标?
这是核心中的核心,就是你要达成的数值目标。
每个目标由三部分组成:
- 目标名称(targetName):指标的名称,比如"下行吞吐量"、"延迟"、"覆盖比例"
- 条件 (targetCondition):比较方式,可以是:
IS_EQUAL_TO= 等于IS_LESS_THAN< 小于IS_GREATER_THAN> 大于IS_WITHIN_RANGE在范围内IS_OUTSIDE_RANGE在范围外- 等等
- 值范围(targetValueRange):具体数值
6.3 上下文(Context)------在什么条件下?
有时候你的要求不是全天候的,而是有条件的。
比如:
- "在晚高峰时段(18:00-20:00),下载速度要大于50Mbps"
- "在负载超过80%的情况下,切换成功率要大于99%"
这里的"晚高峰时段"和"负载超过80%"就是上下文。
重要提示:上下文和目标虽然结构一样(都是<属性, 条件, 值>),但语义不同------目标是"要实现的东西",上下文是"仅在什么条件下实现"。
6.4 选择机制(Selectivity)------当有多个条件时怎么选?
假如你说了多个上下文条件,但并不是所有条件都要同时满足,你可以指定:
| 选择方式 | 含义 | 类比 |
|---|---|---|
ALL_OF |
所有条件都要满足 | "既要......又要......" |
ONE_OF |
满足其中一个即可 | "要么......要么......" |
ANY_OF |
任意一个或多个满足即可 | "随便满足哪个都行" |
七、意图的状态变化(像快递物流追踪一样)
一个意图从提出到完成,会经历一系列状态变化。文档里用了一个状态图来描述:
7.1 七个状态
| 状态 | 含义 | 通俗理解 |
|---|---|---|
| 已确认(ACKNOWLEDGED) | 系统收到了你的意图 | "好的,我收到你的需求了" |
| 合规(COMPLIANT) | 可行性检查通过 | "这个需求我能做到" |
| 已履行(FULFILLED) | 目标达成 | "搞定了,网络已按要求建好/调好" |
| 已挂起(SUSPENDED) | 暂时停止 | "先放一放" |
| 降级(DEGRADED) | 之前做到了,但现在不行了 | "之前是好的,现在网络变差了" |
| 履行失败(FULFILLMENT_FAILED) | 实在做不到 | "这活我干不了" |
| 已终结(TERMINATED) | 需求被删除 | "这个需求取消了" |
7.2 状态变化过程(典型路径)
你提出需求 → 已确认 → 检查可行 → 合规 → 系统干活 → 已履行
↓ ↓ ↓
做不到 ← 不可行 暂停 网络变差
↓ ↓ ↓
履行失败 已挂起 降级
↓ ↓
重新开始 重新开始
八、意图的类型(按用途分类)
文档定义了多种不同类型的"意图期望"(IntentExpectation),覆盖了通信网络的各种场景。
8.1 无线网络期望(Radio Network Expectation)
适用场景:对无线接入网(RAN,也就是基站那部分)提要求
能设哪些目标?
| 目标名称 | 含义 | 通俗理解 |
|---|---|---|
weakRSRPRatioTarget |
弱覆盖比例 | 信号差的地方不能超过多少比例 |
lowSINRRatioTarget |
低信噪比比例 | 干扰大的地方不能太多 |
aveULRANUEThptTarget |
平均上行吞吐量 | 手机上传速度平均多少 |
aveDLRANUEThptTarget |
平均下行吞吐量 | 手机下载速度平均多少 |
lowULRANUEThptRatioTarget |
低上行吞吐量用户比例 | 上传慢的用户不能超过多少比例 |
lowDLRANUEThptRatioTarget |
低下行吞吐量用户比例 | 下载慢的用户不能超过多少比例 |
highUlPrbLoadRatioTarget |
高上行负载比例 | 上行信道太忙不能太多 |
highDlPrbLoadRatioTarget |
高下行负载比例 | 下行信道太忙不能太多 |
rANEnergyConsumptionTarget |
能耗目标 | 省电到多少瓦 |
rANEnergyEfficiencyTarget |
能效目标 | 每瓦电能传多少数据 |
8.2 无线电服务期望(Radio Service Expectation)
适用场景:对"网络即服务"提要求,比如要一个特定网络切片
能设哪些目标?
| 目标名称 | 含义 |
|---|---|
dlThptPerUETarget |
每用户下行吞吐量 |
ulThptPerUETarget |
每用户上行吞吐量 |
dLLatencyTarget |
下行延迟 |
uLLatencyTarget |
上行延迟 |
numberofUEsTarget |
支持的终端数量 |
8.3 5GC网络期望(5GC Network Expectation)
适用场景:对5G核心网提要求
能设哪些目标?
| 目标名称 | 含义 | 类比 |
|---|---|---|
maxNumberofPDUsessionsTarget |
最大PDU会话数 | 最多能同时处理多少个连接 |
maxNumberofRegisteredsubscribersTarget |
最大注册用户数 | 最多能注册多少用户 |
incomingDataTarget |
入向数据量 | 接收数据量 |
outgoingDataTarget |
出向数据量 | 发送数据量 |
8.4 边缘服务支持期望(Edge Service Support Expectation)
适用场景:在网络边缘(靠近用户的地方)部署服务
目标包括:吞吐量、延迟、最大UE数、活动因子、用户速度等
8.5 端到端网络资源优化期望
适用场景:对"整个网络"(从基站到核心网)进行优化
8.6 网络维护期望(Network Maintenance Expectation)
适用场景:软件升级、设备维护
目标包括:维护目标版本、维护时间等
九、协商功能(讨价还价的过程)
有时候,你提出的需求系统不一定能完全满足,这时候就需要"商量"。文档定义了以下几种协商机制:
9.1 可行性检查(Feasibility Check)
通俗理解:在正式干活之前,先问问系统"这活你能干吗?"
流程:
你:我想在西藏无人区部署一个5G基站,达到100Mbps下载速度
系统:让我算算......对不起,那个地方没电没光缆,做不到
系统建议:你可以把目标降到10Mbps,或者换个有基础设施的地方
你:好吧,那我换个地方
9.2 意图探索(Intent Exploration)
通俗理解:你不知道提什么目标合适,让系统给你建议
流程:
你:我想在XX区域部署网络,你觉得能达到什么水平?
系统:根据我的能力,下载速度可以在200Mbps到500Mbps之间
你:好的,那我要400Mbps
9.3 意图履行协商(Fulfilment Negotiation)
通俗理解:需求可行,但有多种实现方式,让用户选
流程:
你:我要省电,能耗降低20%
系统:我有两个方案------
方案A:降低覆盖范围(可能有些地方没信号)
方案B:限制用户数(人多的时候可能连不上)
你觉得哪个更重要?
你:覆盖范围不能丢,选方案B吧
9.4 隐式意图(Implicit Intent)
通俗理解:你没明说但显然在意的事情,系统帮你发现
比如你说"我要省电",但没提"用户能不能正常打电话"。系统会反馈:
"你只说了省电,但省电可能导致覆盖缩小,你是不是也在意覆盖?"
这就是"隐式意图"------你没说出来但系统推测你可能在意的事情。
十、冲突处理(当需求打架的时候)
10.1 三种类型的冲突
| 冲突类型 | 含义 | 例子 |
|---|---|---|
| 目标冲突 | 同一意图中的两个目标互相矛盾 | "既要延迟<1ms,又要覆盖100公里" |
| 期望冲突 | 同一意图中的两个期望互相矛盾 | "既要省电到最低,又要网速最快" |
| 意图冲突 | 两个不同的意图互相矛盾 | 意图A说"把基站1关了省电",意图B说"基站1要保障覆盖" |
10.2 怎么解决?
-
设优先级:你可以告诉系统哪个目标更重要
- 优先级1-100,1最高
- "省电等级8,覆盖等级3"------覆盖比省电重要
-
优先占用:高优先级的意图可以"挤掉"低优先级的
- 比如应急预案的意图来了,日常优化的意图先让路
-
系统推荐:系统告诉你"这俩打架了,建议你把其中一个目标调低"
十一、报告系统(怎么知道干得怎么样?)
系统需要给你反馈,让你知道需求执行得如何。
11.1 六种报告类型
| 报告类型 | 内容 | 通俗理解 |
|---|---|---|
| 意图履行报告 | 状态、目标达成值 | "干得怎么样了?当前网速300Mbps" |
| 意图冲突报告 | 冲突信息 | "你提的A和B两个需求有矛盾" |
| 可行性检查报告 | 可行/不可行 | "这个需求我能不能做到" |
| 意图探索报告 | 探索结果 | "根据我的能力,建议设什么值" |
| 意图履行协商报告 | 协商信息 | "有几个方案你选一个" |
| 意图效用报告 | 效用函数结果 | "综合评分80分" |
11.2 两种订阅方式
| 方式 | 含义 | 类比 |
|---|---|---|
| 显式订阅 | 你主动去订阅报告 | "公众号我关注了,更新了通知我" |
| 隐式订阅 | 创建意图时就自动关联报告 | "下单时就默认给我发物流通知" |
十二、效用函数(量化"满意度")
12.1 什么是效用函数?
官方定义:量化从不同履行水平中获得的满意度或效用的数学表达式。
通俗理解:你告诉系统"什么对你更重要",系统根据这个来算"最优解"。
12.2 举个例子
假设你有两个目标:延迟和吞吐量。你可能觉得:
- 延迟对我非常重要(权重=0.8)
- 吞吐量还行(权重=0.2)
效用函数 U = 0.8 × f(延迟) + 0.2 × f(吞吐量)
系统就会优先保证延迟低,然后再考虑吞吐量。
12.3 为什么需要它?
当没有完美的解决方案 时(比如无法同时满足所有目标),系统需要知道哪个目标更重要,这样才能做出对用户最有利的取舍。
十三、实际应用场景(这些用例都是真实需求)
场景1:在指定区域部署无线网络
用例 :运营商要在某个新开发区建5G网络
意图 :"在上海浦东新区部署RAN网络,频率n39,覆盖面积xx平方公里,平均下载速度>300Mbps"
系统要做的事:找合适的位置、配置基站参数、设置频率、开通小区、验证覆盖
场景2:保障网络覆盖性能
用例 :用户投诉某个区域信号差
意图 :"在上海体育馆区域,弱覆盖比例<10%,信噪比差的比例<5%"
系统要做的事:分析当前覆盖数据、找出弱覆盖区域、调整基站参数(功率、天线角度等)
场景3:保障网络吞吐量性能
用例 :某个区域用户上网慢
意图 :"在XX区域,低吞吐量用户比例<10%,平均吞吐量>100Mbps"
系统要做的事:分析用户吞吐量数据、找原因、调整无线参数
场景4:RAN节能
用例 :半夜基站不需要满功率运行
意图 :"在凌晨1点到5点,RAN能耗<1000瓦,同时保证平均下载速度>100Mbps"
系统要做的事:关闭部分载波、降低功率、同时监控是否影响用户体验
场景5:部署5G核心网
用例 :企业要建一个专网
意图 :"在北京部署5G核心网,包含UPF网元,支持250000个PDU会话"
系统要做的事:配置核心网网元、建立连接、测试
场景6:网络维护(升级)
用例 :设备需要软件升级
意图 :"将版本从v17.4.2升级到v19.1.1,在凌晨2点到6点完成"
系统要做的事:备份、升级、验证、尽量减少对业务的影响
场景7:计划事件保障
用例 :体育赛事期间保障网络
意图 :"在11月1日16:00-20:00,XX体育场区域,支持1000-5000个活跃用户,下载速度>300Mbps"
系统要做的事:提前准备、赛事期间重点保障
场景8:无人机飞行前准备
用例 :无人机起飞前检查网络覆盖
意图 :"在XX空域,确保网络覆盖满足无人机飞行要求"
系统要做的事:检查指定空域的覆盖情况
十四、技术实现层面(软件怎么实现)
14.1 信息模型(数据怎么组织)
文档定义了一套标准的"数据库表结构"(信息对象类IOC):
关键的表有:
- Intent表:存意图的内容(期望列表、上下文、优先级等)
- IntentReport表:存报告信息(履行状态、冲突信息等)
- IntentHandlingFunction表:存"意图处理功能"的能力信息
- IntentUtilityFormula表:存效用函数定义
14.2 API接口(程序员怎么调)
基于RESTful HTTP:
| 操作 | HTTP方法 | URL举例 |
|---|---|---|
| 创建意图 | PUT/POST | /ProvMnS/.../intent=Intent_1 |
| 查询意图 | GET | /ProvMnS/.../intent=Intent_1 |
| 修改意图 | PUT/PATCH | /ProvMnS/.../intent=Intent_1 |
| 删除意图 | DELETE | /ProvMnS/.../intent=Intent_1 |
| 查询报告 | GET | /ProvMnS/.../intentReport=Report_1 |
14.3 YAML示例(看看实际数据长什么样)
一个实际的"创建意图"请求里,数据大概长这样(简化版):
yaml
Intent:
id: "网络覆盖需求-001"
userLabel: "上海浦东网络覆盖"
intentExpectation:
- expectationId: "exp-1"
expectationVerb: "Deliver" # 动词:交付
expectationObject:
objectType: "RAN_SubNetwork"
objectContexts:
- 上下文属性: "CoverageAreaPolygon"
条件: "IS_ALL_OF"
值范围: [经纬度列表...]
- 上下文属性: "PLMN"
条件: "IS_ALL_OF"
值范围: "46000" # 中国移动
- 上下文属性: "RAT"
条件: "IS_ALL_OF"
值范围: "NR" # 5G
expectationTargets:
- 目标名称: "weakRSRPRatio"
条件: "IS_LESS_THAN"
值: "10" # 弱覆盖比例<10%
- 目标名称: "aveDLRANUEthpt"
条件: "IS_GREATER_THAN"
值: "300" # 下行吞吐量>300Mbps
十五、与TM Forum的映射关系
TM Forum(电信管理论坛)也定义了类似的意图模型。这篇文档把它们之间的对应关系做了映射:
| 3GPP术语 | TM Forum术语 |
|---|---|
| IntentExpectation | icm:target |
| expectationTargets | icm:Expectation类的属性 |
| expectationContexts | icm:context |
| 各种报告 | icm:ExpectationReport类的属性 |
简单说:两者说的是同一件事,只是叫法不同。
十六、总结(记住这几句就够了)
- 意图 = 说你要什么,别说怎么做
- 三个角色:CSC(客户)→ CSP(运营商)→ NOP(运维),层层只说"要什么"
- 意图的结构:对什么对象(Object)→ 达成什么目标(Target)→ 在什么条件下(Context)
- 七种状态:已确认→合规→已履行(正常路径),也可能挂起/降级/失败
- 协商机制:先问能不能做(可行性检查)→ 探索什么值合适(探索)→ 多种方案让你选(协商)
- 冲突处理:优先级高的优先,系统会告诉你哪里打架了
- 报告反馈:系统持续汇报"干得怎么样"
- 核心价值 :降低管理复杂性,不需要人知道底层网络细节
用一句话向别人介绍这篇文档:
"这篇3GPP标准定义了一套方法,让运营商只用说'我要什么',系统就能自动搞定5G网络的配置、优化和维护,不需要人知道具体怎么操作。"
附录:高频术语速查表
| 术语 | 缩写 | 通俗含义 |
|---|---|---|
| Intent | - | 意图,你对系统提的需求 |
| Intent Expectation | - | 意图期望,需求的具体条目 |
| Expectation Object | - | 期望对象,你对什么东西提要求 |
| Expectation Target | - | 期望目标,你要达成的指标 |
| Context | - | 上下文,附加的条件限制 |
| MnS Consumer | - | 提需求的人 |
| MnS Producer | - | 执行需求的人/系统 |
| Intent Handling Function | IHF | 意图处理功能,负责处理意图的系统模块 |
| Fulfilment | - | 履行/执行,把需求实现出来 |
| Feasibility Check | - | 可行性检查,看看需求能不能做到 |
| Negotiation | - | 协商,商量着来 |
| Utility Function | - | 效用函数,量化"满意度"的数学公式 |
| RAN | - | 无线接入网,就是基站那部分 |
| 5GC | - | 5G核心网,网络的大脑部分 |
| NR | - | New Radio,5G的无线技术标准 |
| CSC/CSP/NOP | - | 客户/运营商/运维,三个不同的角色 |