《3GPP TS 28.312 面向移动网络的意图驱动管理服务》完整自学教程

《3GPP TS 28.312 面向移动网络的意图驱动管理服务》完整自学教程

适合读者 ：零通信基础的小白

学习方式 ：跟着步骤走，每一步都理解后再进入下一步

总览：共6个模块、20节，预计总阅读时间6-8小时

---

模块零：学习之前

0.1 为什么要学这个？

想象一下：

你家有一栋100层的大楼，里面有：

• 10000个房间
• 5000个温度传感器
• 2000个灯光开关
• 1000个门窗传感器
• 来自10个不同厂家的控制系统

现在，你每天都要手动调节每个房间的温度、开关灯、检查门窗。你忙得过来吗？

5G网络就是这样一栋大楼------甚至更复杂。而这篇文档教的，就是怎么让这栋楼学会自己管自己。

0.2 这篇文档在干什么？

一句话：定义了一套方法，让运营商"告诉网络想要什么结果"，而不是"告诉网络具体怎么做"。

传统方式："把基站A的天线角度调到3度，功率调到40W......"
意图方式："我要上海体育馆的5G信号覆盖率达到95%" 

0.3 你需要知道的几个前提

• 不用懂通信原理（我会用日常类比解释）
• 不用懂编程（没有代码）
• 只需要：耐心 + 愿意跟着思路走

0.4 学习建议

每一步 → 读一遍 → 停下来想一下 → 
        问自己"我理解了吗？" → 
        理解了再走下一步

---

模块一：认识意图（最基本的砖块）

第1节：什么是"意图"？

1.1 从生活场景理解

场景：你去餐厅吃饭

有两个点菜方式：

方式A（你教厨师怎么做）：

你：走到第三个灶台，打开蓝色火苗，加热到180度，
    倒15毫升油，油温160度时放入蒜末炒10秒，
    倒入300克牛肉丝翻炒到变色......
厨师：（一脸困惑）

方式B（你告诉厨师要什么）：

你：我要一份黑椒牛柳
厨师：好的，稍等

方式B就是"意图" ------你只告诉对方你想要的结果，不告诉对方怎么实现。

1.2 官方定义

意图(intent)：提供给系统的期望，包括需求、目标和约束条件，而不指定如何实现它们。

拆开看：

• 需求：你想要什么
• 目标：要达成什么指标
• 约束：有什么限制条件
• 不指定如何实现：不说具体操作步骤

1.3 为什么需要意图？

5G网络有多复杂？

项目	数字
一个中型城市基站数量	5000-10000个
每个基站的可调参数	数百到上千个
不同厂商设备	3-5家混用
每天产生的告警	数万条

如果全凭人工：每次调整都要工程师查手册、配参数、测试验证，累死也忙不过来。

所以：让网络理解"要什么"，而不是教它"怎么做"。

本节小结

意图 = 你告诉系统你想要的结果
            ↓
    系统自己想办法实现
            ↓
    你只需要检查结果

---

第2节：三个关键角色------谁在跟谁说话？

2.1 角色图谱

意图驱动管理涉及三个角色，像一条供应链：

通信服务客户（CSC）
  ↑ 说："我要通信服务"
通信服务提供商（CSP）  
  ↑ 说："我需要网络能力"
网络运营商（NOP）
  ↑ 说："我需要配置设备"
网络设备提供商（NEP）

2.2 逐个角色理解

角色1：通信服务客户（CSC）

项目	内容
是什么人	最终用户，比如快递公司、电视台、自动驾驶公司
他们想要什么	通信服务
举个例子	"我要在2026年6月15日，为上海浦东500辆物流车提供实时定位"
他们不关心	网络怎么搭建、基站哪个厂家

你可以把CSC理解为叫外卖的人------他们只关心饭好不好吃、送到没有，不关心厨师怎么炒菜。

角色2：通信服务提供商（CSP）

项目	内容
是什么人	运营商，比如中国移动、AT&T
他们想要什么	网络能力
举个例子	"为417号公路沿线提供车联网服务，同时支持500辆车"
他们不关心	具体哪个基站做这件事

CSP就像餐厅经理------他们知道需要什么菜、什么时候上，但不关心后厨每个灶台怎么用。

角色3：网络运营商（NOP）

项目	内容
是什么人	管网络的人，运营商内部的运维部门
他们想要什么	设备配置
举个例子	"在指定区域提供无线网络服务，满足覆盖和吞吐量要求"
他们不关心	基站内部芯片级参数

NOP就是后厨团队------他们负责实际做菜，但不用管种菜的农民怎么种。

2.3 层层传递的规则

每一层只告诉下一层**"要什么"，不说"怎么做"**：

CSC（客户）：我要服务 → 不关心怎么管
     ↓ （把需求传给CSP）
CSP（运营商）：我需要网络能力 → 不关心具体设备
     ↓ （把需求传给NOP）
NOP（运维）：我需要配置设备 → 不关心芯片级参数
     ↓ （把需求传给设备）
NEP（设备商）：干活

这样做的好处：每层只关心自己的事，不用了解下层的细节。

本节练习

如果你是快递公司老板（CSC），你想让运营商为你提供"双十一期间全国1000辆快递车的实时定位服务"------

1. 你会怎么向CSP说？（一句话）
2. CSP收到后需要做什么？
3. NOP收到后需要做什么？
   思考提示（点击展开）

1. 你说："双十一期间，我需要全国1000辆快递车的实时定位服务，精度10米以内"
2. CSP需要：把这个需求翻译成网络能力需求------"保障全国范围的车联网覆盖"
3. NOP需要：配置基站和核心网参数来实现这个覆盖

---

第3节：意图的结构------它到底长什么样？

3.1 一张图看懂结构

一个意图（Intent）------你对系统提的一个完整需求
│
├── 意图期望（IntentExpectation）------你想要的具体东西（可以有多个）
│   │
│   ├── 期望对象（ExpectationObject）------对谁提要求
│   │   ├── 对象类型：比如"无线网络"、"5G核心网"
│   │   ├── 对象实例：具体哪个网络（如果有编号）
│   │   └── 对象上下文：用条件筛选，比如"在上海浦东"
│   │
│   ├── 期望目标（ExpectationTarget）------要达到什么指标（可以有多个）
│   │   ├── 目标名称：比如"用户下载速度"
│   │   ├── 条件：比如"大于"（也可以小于、等于等）
│   │   └── 值范围：比如"300Mbps"
│   │
│   └── 上下文（Context）------附加条件，比如"只在晚高峰执行"
│
├── 全局上下文 ------ 适用整个意图的条件
│
└── 报告控制 ------ 怎么给我汇报

3.2 一个实例让你看懂

假设运营商想在上海体育馆建5G网络：

意图编号：Intent_1
名称："在上海浦东部署无线网络"

意图期望：
  - 期望ID: "1"
  - 动词: "交付"（是新建还是保障？这里是新建）
  - 期望对象：
      对象类型：无线子网络（RAN）
      对象上下文：
        - 覆盖区域：上海浦东（经纬度坐标）
        - 运营商：中国移动（PLMN=46000）
        - 频段：n39（5G频段）
        - 技术：5G NR
  - 期望目标：
      - 目标1：弱覆盖比例 < 10%（信号<-130dBm算弱）
      - 目标2：平均上行网速 > 100Mbps
      - 目标3：平均下行网速 > 300Mbps

优先级：1（最高）
观察周期：60分钟（每60分钟检查一次结果）

3.3 三个核心组件详解

组件一：期望对象（ExpectationObject）------对谁提要求？

有三种指定方式：

方式	例子	适用场景
按类型	"所有5G基站"	你不知道具体编号
按实例	"浦东新区那个基站"	你知道具体是哪个
按上下文	"上海范围内的所有基站"	用条件筛选

组件二：期望目标（ExpectationTarget）------要求什么指标？

每个目标由三部分组成：

目标 = [目标名称, 条件, 值范围]

例子：
- ["下行吞吐量", "大于", "300Mbps"]
- ["覆盖比例", "大于", "95%"]
- ["延迟", "小于", "10ms"]

条件的各种类型：

条件	含义	数学符号
IS_EQUAL_TO	等于	=
IS_LESS_THAN	小于	<
IS_GREATER_THAN	大于	>
IS_WITHIN_RANGE	在范围内	a,b
IS_OUTSIDE_RANGE	在范围外	(-∞,a)∪(b,∞)
IS_ONE_OF	属于其中之一	∈{a,b,c}

组件三：上下文（Context）------在什么条件下？

有时候你的要求不是全天候的，而是有条件的：

"在晚高峰（18:00-20:00），下载速度要大于50Mbps"
  ↑目标（网速>50Mbps）     ↑上下文（晚高峰）

"在负载超过80%的情况下，切换成功率要大于99%"
  ↑目标（切换成功率）         ↑上下文（高负载）

3.4 一个容易搞混的地方：目标和上下文

目标和上下文的结构一模一样，都是[属性, 条件, 值]。

但语义完全不同：

目标：→ 这是"我要实现的"
     "我要网速达到300Mbps"

上下文：→ 这是"什么条件下"
       "只在晚高峰时段才要求这个网速"

如果你不把上下文明确标出来，系统可能会误解。比如你说"切换失败率<2%，负载>80%"，如果不指明"负载>80%"是上下文，系统会以为你要求"同时满足两个条件"------既要有高负载又要切换失败率低，这根本不可能。

3.5 选择机制------多个条件怎么选？

如果你指定了多个上下文条件，可以用选择机制说明它们的关系：

选择方式	含义	类比
ALL_OF	所有条件必须同时满足	"既要是周末，又要是晚上"
ONE_OF	满足其中一个就行	"要么周六，要么周日"
ANY_OF	任意一个或多个满足都行	"周末有空就行"

本节练习

请你为以下需求填空，构建一个意图的结构：
需求：在XX大学校区部署5G网络，要求覆盖率达到98%以上，学生下载速度不低于200Mbps。只在晚上6点到11点的高峰时段要求这个速度。

意图
├── 意图期望
│   ├── 期望对象
│   │   ├── 对象类型：__________
│   │   └── 对象上下文：XX大学校区
│   ├── 期望目标1：
│   │   ├── 目标名称：覆盖率
│   │   ├── 条件：__________
│   │   └── 值范围：__________
│   ├── 期望目标2：
│   │   ├── 目标名称：下行下载速度
│   │   ├── 条件：__________
│   │   └── 值范围：__________
│   └── 上下文：
│       ├── 属性：时间段
│       └── 值范围：__________

参考答案（点击展开）

• 对象类型：无线子网络（RAN）
• 目标1条件：大于
• 目标1值范围：98%
• 目标2条件：大于
• 目标2值范围：200Mbps
• 上下文值范围：18:00-23:00

---

模块二：意图的流程（从生到死）

第4节：六个操作------你能对意图做什么？

4.1 操作总览

你对一个意图可以做的六件事：

操作	英文	做什么	生活类比
创建	Create	提出新需求	下订单
查询	Query	查看状态	查物流
修改	Modify	改需求内容	改订单
激活	Activate	让暂停的恢复	快递入仓后再发出
停用	Deactivate	暂停但不删除	快递暂存仓库
删除	Delete	彻底取消	取消订单

4.2 逐个理解

创建（Create）

• 做什么：你把意图的内容（期望、目标、上下文）发给系统
• 系统怎么做：创建一个意图记录
• 返回什么：一个意图编号（类似订单号）
• 类比：你在淘宝下单，系统生成一个订单号

查询（Query）

• 做什么：你想知道之前提的需求怎么样了
• 系统怎么做：返回意图的内容和当前状态
• 返回什么：意图的所有信息和当前状态
• 类比：你查物流，看到"已发货"、"运输中"、"已签收"

修改（Modify）

• 做什么：你改主意了，想调整需求
• 系统怎么做：更新意图的内容，重新检查可行性
• 返回什么：确认修改成功
• 类比：你在淘宝改地址、改数量

激活（Activate）

• 做什么：让一个暂时停掉的意图重新开始工作
• 系统怎么做：将状态从"停用"改为"激活"，重新开始执行
• 类比：你把暂存在仓库的包裹重新发出去

停用（Deactivate）

• 做什么：暂时停止执行，但不删除，以后可以恢复
• 系统怎么做：停止执行，把意图标记为"停用"
• 类比：你的包裹到了中转站，先放一放不发

删除（Delete）

• 做什么：彻底取消这个需求
• 系统怎么做：删除所有相关记录
• 返回什么：确认删除
• 类比：取消订单

本节练习

1. 你创建了一个意图要求"保障XX体育场网络"，但演唱会取消了。你该用什么操作？
2. 三个月后，同一个体育场又有演唱会了。你该用什么操作？
3. 你创建了一个意图，想看看系统执行到哪一步了。你该用什么操作？
   答案（点击展开）

1. 删除（彻底取消这个需求）
2. 创建（提一个新需求，旧的已经删了）
3. 查询（查看状态）

---

第5节：七种状态------意图的"一生"

5.1 状态总览

一个意图从创建到终结，会经历七种状态：

     ┌─────────────────────────────────────────┐
     │             创建意图请求                  │
     │                   ↓                      │
     │         ACKNOWLEDGED（已确认）            │
     │                   ↓                      │
     │            可行性检查                      │
     │          ┌────┴────┐                     │
     │          ↓         ↓                     │
     │    COMPLIANT   FULFILLMENT_FAILED         │
     │    （合规）     （履行失败）               │
     │          ↓                               │
     │     开始执行                              │
     │          ↓                               │
     │    FULFILLED（已履行）                    │
     │          ↓                               │
     │    （可能会）→ DEGRADED（降级）            │
     │          ↓                               │
     │    SUSPENDED（已挂起）← 也可以直接挂起     │
     │          ↓                               │
     │    TERMINATED（已终结）                   │
     └─────────────────────────────────────────┘

别被这个图吓到。我们用快递物流来理解：

5.2 快递类比法

状态	含义	像什么？
ACKNOWLEDGED	系统收到你的需求了	商家已接单
COMPLIANT	可行性检查通过	仓库已备货
FULFILLED	目标达成了	已签收
SUSPENDED	暂时停止执行	包裹暂存
DEGRADED	之前做到了现在不行了	签收后发现东西坏了
FULFILLMENT_FAILED	实在做不到	商家通知缺货
TERMINATED	需求被删除了	订单取消

5.3 逐个理解

1. ACKNOWLEDGED（已确认）

• 什么时候发生：你提交创建请求后
• 什么意思：系统收到了你的需求，给你确认
• 下一步去哪：系统检查可行性
• 生活类比：你下单→卖家说"收到订单了"

2. COMPLIANT（合规）

• 什么时候发生：系统检查可行后
• 什么意思：系统判断"这个需求我能做到"
• 下一步去哪：开始干活，最终实现目标
• 生活类比：卖家说"有货，可以发"

3. FULFILLED（已履行）

• 什么时候发生：系统认为目标已达成
• 什么意思：你的需求被满足了
• 下一步去哪：系统继续监控（可能会DEGRADED）
• 生活类比：快递已签收

4. SUSPENDED（已挂起）

• 什么时候发生：你或系统决定暂停
• 什么意思：暂时停止，不删除
• 下一步去哪：可以激活恢复执行，也可以删除
• 生活类比：包裹先放驿站不送

5. DEGRADED（降级）

• 什么时候发生：之前已履行，但后来变差了
• 什么意思：比如之前网速达标，现在网络恶化了
• 下一步去哪：可以修改意图，系统也可能自动恢复
• 生活类比：东西到了但发现损坏了

6. FULFILLMENT_FAILED（履行失败）

• 什么时候发生：系统判定完全做不到
• 什么意思：系统告诉你"这活干不了"
• 下一步去哪：你可以修改意图（降低要求）或删除
• 生活类比：卖家说"这货停产了，发不了"

7. TERMINATED（已终结）

• 什么时候发生：你删除了意图
• 什么意思：一切结束
• 下一步去哪：没了，结束
• 生活类比：订单取消，退款完成

5.4 一个完整的例子

你：我要在XX区建5G网络，网速>300Mbps
    ↓
系统：收到 → ACKNOWLEDGED
    ↓
系统：检查可行性......有足够资源 → COMPLIANT
    ↓
系统：开始配置基站、调参数......
    ↓
系统：部署完成，测试通过 → FULFILLED
    ↓
（三个月后）
    ↓
系统：发现这个区域用户暴增，网速掉到200Mbps → DEGRADED
    ↓
系统：尝试优化（调整参数）
    ↓
系统：网速恢复到300Mbps → FULFILLED

本节练习

请将以下事件按正确的顺序排列：

A. 系统检查后认为可行

B. 你删除意图

C. 你创建意图

D. 系统完成部署

E. 系统确认收到

F. 网络变差，系统报告降级
答案（点击展开）

C（创建）→ E（已确认）→ A（合规）→ D（已履行）→ F（降级）→ B（删除）

---

模块三：协商与冲突（当事情没那么顺利时）

第6节：可行性检查------先问问能不能做

6.1 为什么需要它？

省事。在正式干活之前，先问系统"这活能接吗？"

不检查就干活：
你：建个基站
系统：好！开工！......啊，资源不够，白干了
你：......

先检查再干活：
你：建个基站
系统：我先算算......不行，资源不够。
        建议你把目标降低或者换个地方
你：好吧我改一下

6.2 怎么做？

流程很简单：

你：提交意图（标记为"仅检查"）
    ↓
系统：分析资源、能力
    ↓
系统：返回结果
      ├── 可行：可以继续
      └── 不可行：告诉原因和建议

关键 ：这个过程中，网络不会被实际改变。系统只是"纸上谈兵"地评估一下。

6.3 检查不通过会怎样？

系统会返回：

1. 不可行的原因（比如"资源不足"、"与其他意图冲突"）
2. 修改建议（比如"建议降低到200Mbps"）

然后你可以：

• 修改意图再试
• 挂起或删除

本节小结

可行性检查 = 先问系统"能干吗？"再动手
             省得白费功夫
             不会实际改变网络

---

第7节：意图探索------让系统推荐最佳值

7.1 为什么需要它？

你不知道设什么目标值合适，让系统帮你推荐。

你：在XX区域部署网络，我该设多大网速？
系统：根据现有资源，200-500Mbps都可以
你：那我要400Mbps

7.2 两种探索场景

场景1：探索单个目标的最佳值

你把某个目标的值留空，系统帮你填：

你的意图：
  - 覆盖区域：XX
  - 目标：下行网速 = ？（你留空了）
  
系统返回：
  - 推荐值：300Mbps
  - 推荐依据：当前资源可支持

场景2：探索多个目标的最佳组合

你有多个目标，彼此冲突，让系统推荐平衡方案：

你的意图：
  - 区域：XX
  - 目标1：省电 = ？（留空）
  - 目标2：网速 = ？（留空）

系统返回：推荐两种组合
  组合A：省电20%，网速200Mbps
  组合B：省电10%，网速400Mbps

本节小结

意图探索 = 你不知道怎么设值，让系统推荐
           系统只是算，不会真改网络

---

第8节：四个履行协商场景

8.1 场景一：检查可履行结果

需求可行，但系统可以有多种实现方式。系统把各种可能性列给你看。

你的需求：省电20%

系统算了三种结果：
  结果A：省电20%，覆盖缩小5%
  结果B：省电15%，覆盖不变  
  结果C：省电25%，覆盖缩小10%

你：我选结果B，覆盖不能丢

注意：每个结果都可能对其他正在运行的意图产生影响，系统会告诉你这些"相对影响"。

8.2 场景二：检查最佳可能结果

你指定某个指标，让系统算它"最好能到多少"。

你：在目前条件下，下行网速最高能到多少？
系统：最优情况下可达500Mbps
你：好，那就定500Mbps

分为两种请求：

• 指定特定目标："只告诉我网速最好能到多少"
• 评估所有目标："把所有指标的最佳值都列出来"

8.3 场景三：生产者推荐

系统尝试执行后发现做不到，反过来给你建议。

系统：你要的500Mbps我试了，做不到
系统建议：
  - 你可以把目标降到400Mbps
  - 或者多增加一个基站

你：那降到400Mbps吧

系统也可以在你已经表达过"偏好"的前提下，只针对特定属性给出修改建议。

8.4 场景四：消费者选方案

需求可行，有多种方案，系统让你选。

系统：你的需求有多种方案------
  方案A：覆盖好，但耗电高
  方案B：省电，但覆盖差一些
  方案C：两者平衡

你：我选A，覆盖最重要

你可以按以下方式告诉系统你的偏好：

• 直接选方案："我要方案A"
• 设权重："覆盖权重0.8，省电权重0.2"
• 满意度评分："方案A我打90分，方案B打60分"

8.5 还有一个特殊机制：隐式意图

这不属于协商，但跟协商有关。

问题：你只说了A，但做A会影响B，而B你其实也在意。

你：我要省电（只说了这个）
系统：好的，但省电可能会缩小覆盖。
       你是不是也在意覆盖？
你：对，覆盖不能降！
系统：明白了，那我会平衡省电和覆盖。

隐式意图 = 系统发现你没说但很可能在意的事情，主动告诉你。

---

第9节：冲突------当需求打架的时候

9.1 先理清一个关键区别

很多初学者分不清"期望"和"目标"。记住：

一个意图
  │
  └── 意图期望（完整的需求条目）
        │
        └── 期望目标（条目里的具体指标）

一个类比------点套餐：

你点"鱼香肉丝套餐"（这是一个意图）
  │
  ├── 期望1："主菜------鱼香肉丝"
  │     ├── 目标1：肉丝量 ≥ 200克
  │     └── 目标2：辣度 = 微辣
  │
  └── 期望2："汤------紫菜蛋花汤"
        ├── 目标1：温度 ≥ 70°C
        └── 目标2：盐度 < 5克

9.2 三种冲突

目标冲突：同一个期望内部的两个目标互相矛盾。

例子：同一个意图期望中
  - 目标A：延迟 < 1ms（超低延迟）
  - 目标B：覆盖 100公里（超远覆盖）
  
问题：低延迟和小覆盖通常是一起的，远覆盖和高延迟是一起的。
      这两个目标在物理上互相矛盾。

期望冲突：同一个意图内部的两个期望互相矛盾。

例子：同一个意图中
  - 期望1：最省电
  - 期望2：网速最快

问题：要省电就得降低功率，降低功率网速就慢。
      这两个期望互相矛盾。

意图冲突：两个不同的意图互相矛盾。

例子：
  意图A说：把基站1关掉，省电
  意图B说：基站1必须满功率运行，保障覆盖

问题：两个意图对着干。

9.3 怎么解决？

方法1：设优先级

优先级1-100，1最高。

你告诉系统：
  - 覆盖等级 3（很重要）
  - 省电等级 8（不太重要）

冲突时，系统优先保障覆盖。

方法2：优先占用

高优先级的意图可以直接"挤掉"低优先级的。

应急预案来了（优先级1）：
  占用基站资源
  
日常优化意图（优先级5）：
  被挤掉，暂停执行

方法3：系统推荐

系统告诉你哪两个需求冲突了，建议你怎么改。

系统：你的"省电"和"覆盖"冲突了
系统建议：你可以把省电目标从降低30%改为降低15%

本节练习

判断以下属于哪种冲突：

1. 一个意图中，要求"延迟<1ms"和"覆盖100公里"
2. 一个意图中，要求"最省电"和"网速最快"
3. 意图A要求"关基站A"，意图B要求"基站A满功率"
   答案（点击展开）

1. 目标冲突（同一个期望内部的两个目标）
2. 期望冲突（同一个意图内部的两个期望）
3. 意图冲突（两个不同的意图）

---

模块四：掌握细节（深入理解）

第10节：六种报告------怎么知道干得怎么样？

10.1 报告总览

系统需要给你反馈，一共六种报告：

报告类型	告诉你什么	生活类比
履行报告	目标达成没有？当前值是多少？	"快递到哪了？当前在XX中转站"
冲突报告	你的需求跟别的需求打架了	"你的订单和另一个订单冲突"
可行性检查报告	你的需求能不能做到？	"这个地址能送到吗？"
探索报告	系统推荐的最佳值是多少？	"这个产品的建议配置是什么？"
协商报告	有几个方案，你选哪个？	"有标准版和Pro版，您选哪个？"
效用报告	综合满意度评分	"综合评分85分"

10.2 履行报告的详细结构

履行报告是最重要的报告，它会告诉你：

意图履行状态（整体）：已履行/未履行
  └── 每个期望的履行结果：
        ├── 期望ID
        ├── 该期望的状态
        └── 每个目标的履行结果：
              ├── 目标名称（比如"下行吞吐量"）
              ├── 目标状态（已达成/未达成）
              └── 当前实际值（比如"350Mbps"）

10.3 两种订阅方式

方式	怎么做	类比
显式订阅	你主动创建一个订阅对象	你关注了公众号，有更新通知你
隐式订阅	创建意图时就默认关联报告	下单时默认勾选了"物流通知"

10.4 隐式订阅的优点

你可以在创建意图时，直接在意图里指定：

我想收到什么报告：只收"履行报告"和"冲突报告"
什么条件下发：当某个目标未达成时
多久报告一次：每60分钟

这样就省去了单独去订阅的步骤。

---

第11节：效用函数------量化"满意度"

11.1 为什么需要它？

当没有完美方案 时（比如无法同时满足所有目标），系统需要知道哪个目标对你更重要。

11.2 什么是效用函数？

效用函数：量化你从不同结果中获得的满意度的数学公式。

用大白话说：你告诉系统"什么更重要"，系统就算出"怎么做最好"。

11.3 一个具体的例子

假设你有两个目标：

目标	单位	你的重视程度
延迟	毫秒	非常重要（权重0.7）
吞吐量	Mbps	还行（权重0.3）

效用函数可以是：

U = 0.7 × f(延迟) + 0.3 × f(吞吐量)

系统面对两个方案时：

方案	延迟	吞吐量	效用得分
A	5ms	500Mbps	0.7×90 + 0.3×80 = 87分
B	20ms	800Mbps	0.7×60 + 0.3×95 = 70.5分

系统会选方案A，因为综合效用得分更高。

11.4 效用函数的组成

组件	含义	例子
变量	衡量什么	延迟、吞吐量、能耗
权重	重要性	延迟=0.7，吞吐量=0.3
函数	怎么计算	线性、对数等
结果	得分	0-100

11.5 怎么使用效用函数

系统会公开自己支持哪些效用函数。你可以：

1. 引用已有的：用系统预定义的函数
2. 自己定义：在意图里写你自己的函数

本节练习

你有一个意图包含两个目标：覆盖面积和信号质量。

你觉得覆盖面积比信号质量重要一倍。

请给这两个目标分配权重。
答案（点击展开）

覆盖面积权重：0.67（或2/3）

信号质量权重：0.33（或1/3）

（重要一倍 = 覆盖的权重是信号的两倍，且总和为1）

---

模块五：九种实际应用场景

第12节：场景总览

文档定义了九种具体的意图类型，覆盖了通信网络的各个场景：

编号	场景	意图动词	一句话
1	交付无线网络	Deliver	"在这个区域建5G网络"
2	交付无线电服务	Deliver	"在这个区域提供通信服务"
3	交付边缘服务	Deliver	"在网络边缘部署服务"
4	保障覆盖性能	Ensure	"信号覆盖要达标"
5	保障吞吐量性能	Ensure	"网速要够快"
6	端到端网络优化	(优化)	"整个网络优化"
7	RAN节能	Ensure	"基站要省电"
8	交付5GC核心网	Deliver	"建个5G核心网"
9	网络维护	Maintain	"升级设备软件"

第13节：场景详解

场景1：交付无线网络

背景：在新开发区新建5G覆盖

意图内容：

动词：Deliver（交付）
对象：无线子网络（RAN）
对象上下文：
  - 覆盖区域：上海浦东（多边形坐标）
  - 运营商：中国移动（PLMN=46000）
  - 频段：n39
  - 技术：5G NR
目标：
  - 弱覆盖比例 < 10%
  - 低信噪比比例 < 5%
  - 上行平均吞吐量 > 100Mbps
  - 下行平均吞吐量 > 300Mbps

系统会做什么：

1. 分析指定区域中已有的基站
2. 生成新基站的配置参数
3. 部署和配置基站
4. 验证覆盖是否达标
5. 给你报告结果

场景2：交付无线电服务

背景：运营商给客户提供一个"网络服务套餐"（Network as a Service）

意图内容：

动词：Deliver
对象：无线电服务
目标：
  - 每用户下行吞吐量 > 30Mbps
  - 每用户上行吞吐量 > 10Mbps
  - 下行延迟 < 25ms
  - 上行延迟 < 15ms
  - 最多支持40个用户
上下文：
  - 服务时间：2023-05-06 14:11 到 2023-05-07 14:11

场景3：交付边缘服务

背景：把计算服务部署到靠近用户的地方（边缘计算）

意图内容：

动词：Deliver
对象：边缘服务支持
对象上下文：
  - 边缘位置：上海（具体坐标）
  - 覆盖区域：跟踪区7
目标：
  - 每用户下行吞吐量 > 30Mbps
  - 每用户上行吞吐量 > 10Mbps
  - 延迟 < 25ms
  - 最多40个用户

场景4：保障覆盖性能

背景：用户投诉信号差，保障覆盖质量

意图内容：

动词：Ensure（保障）
对象：无线网络（SubNetwork_1）
目标：
  - 弱覆盖比例 < 10%
  - 低信噪比比例 < 5%
上下文：
  - 覆盖区域：特定多边形
  - 技术：5G NR

系统会做什么：

1. 采集覆盖数据（RSRP等）
2. 识别弱覆盖区域
3. 分析原因（天线角度？功率？）
4. 调整配置参数
5. 持续监控，如果又变差就再次优化

场景5：保障吞吐量性能

背景：用户上网慢

意图内容：

动词：Ensure
对象：无线网络
目标：
  - 低上行吞吐量（<50Mbps）用户比例 < 10%
  - 低下行吞吐量（<200Mbps）用户比例 < 5%
  - 平均上行吞吐量 > 100Mbps
  - 平均下行吞吐量 > 300Mbps

场景6：端到端网络优化

背景：对全网（基站+核心网）进行优化

特点：这里的目标没有严格定义，留给具体实现去决定。你可以给不同目标设优先级。

场景7：RAN节能

背景：基站耗电大，晚上人少时可以省电

意图内容：

动词：Ensure
对象：无线网络
目标：
  - RAN能耗 < 1000瓦
  - RAN能效 > 400000
  - 上行吞吐量 > 100Mbps
  - 下行吞吐量 > 300Mbps（5G）/ 100Mbps（4G）
上下文：
  - 节能时段：凌晨1点-5点

系统会做什么：

1. 分析当前能耗和流量
2. 决定关闭部分载波
3. 监控对网速的影响
4. 在节能和用户体验之间找平衡

场景8：交付5GC核心网

背景：企业要建一个专用5G核心网

意图内容：

动词：Deliver
对象：5G核心网子网络
对象上下文：
  - 位置：北京
  - 包含网元：UPF
  - 运营商：46000
目标：
  - 最大PDU会话数 < 250000
  - 最大注册用户数 < 2500

系统会做什么：

1. 分析是新建还是重用现有网络
2. 生成配置参数
3. 配置核心网网元
4. 测试验证

场景9：网络维护

背景：设备需要软件升级

意图内容：

动词：Maintain（维护）
对象：子网络
对象上下文：
  - 当前版本：17.4.2
  - 网元类型：UPF
  - 位置：慕尼黑
目标：
  - 目标版本：19.1.1
上下文：
  - 维护时间：凌晨2点-6点

---

模块六：巩固与提升

第14节：技术实现------系统怎么实现的

如果你好奇"系统内部是怎么实现的"，这一节简单介绍。

14.1 信息模型（数据怎么组织）

文档定义了几种"数据表"（称为IOC，信息对象类）：

表名	存什么
Intent	意图本身（期望列表、上下文、优先级等）
IntentReport	报告的各类信息
IntentHandlingFunction	意图处理功能的能力信息
IntentUtilityFormula	效用函数定义

14.2 API接口（程序员怎么调用）

基于HTTP RESTful API：

操作	HTTP方法	URL示例
创建意图	PUT/POST	.../intent=Intent_1
查询意图	GET	.../intent=Intent_1
修改意图	PUT/PATCH	.../intent=Intent_1
删除意图	DELETE	.../intent=Intent_1
查询报告	GET	.../intentReport=Report_1

14.3 YAML实例

一个真实的创建意图请求数据：

Intent:
  id: 'Intent_1'
  userLabel: 'Radio_Network_Deliver'
  intentExpectation:
    - expectationId: '1'
      expectationVerb: 'Deliver'
      expectationObject:
        objectType: 'RAN_SubNetwork'
        objectContexts:
          - contextAttribute: 'CoverageAreaPolygon'
            contextCondition: 'IS_ALL_OF'
            contextValueRange:
              - latitude: '31.2696'
                longitude: '121.6322'
          # ...更多坐标点
          - contextAttribute: 'PLMN'
            contextCondition: 'IS_ALL_OF'
            contextValueRange: '46000'
      expectationTargets:
        - targetName: 'WeakRSRPRatio'
          targetCondition: 'IS_LESS_THAN'
          targetValueRange: '10'

---

第15节：完整流程图（综合回顾）

创建意图的完整流程

你（MnS Consumer）                    系统（MnS Producer）            网络设备
     │                                      │                          │
     │ 1. 提交创建意图请求                    │                          │
     │─────────────────────────────────────> │                          │
     │                                      │ 2. 创建意图记录           │
     │                                      │──────────────────>        │
     │ 3. 返回意图编号                       │                          │
     │<───────────────────────────────────── │                          │
     │                                      │ 4. 可行性检查             │
     │                                      │──┐                        │
     │                                      │  │ 分析资源、能力         │
     │                                      │<─┘                        │
     │                                      │                          │
     │         ┌──── 如果可行 ────┐          │                          │
     │         ↓                  ↓          │                          │
     │ 5a. 执行配置                 5b. 报告失败                        │
     │     │                      │          │                          │
     │ 6. 持续监控                 │          │                          │
     │     │                      │          │                          │
     │ 7. 调整优化                 │          │                          │
     │     │                      │          │                          │
     │ 8. 通知你结果               │          │                          │
     │<───────────────────────────           │                          │

---

第16节：术语速查表（随时查阅）

术语	缩写	通俗含义
Intent	-	意图，你对系统提的需求
Intent Expectation	-	意图期望，需求的具体条目
Expectation Object	-	期望对象，你对什么东西提要求
Expectation Target	-	期望目标，你要达成的指标
Context	-	上下文，附加的条件限制
MnS Consumer	-	提需求的人
MnS Producer	-	执行需求的系统
Intent Handling Function	IHF	处理意图的系统模块
Fulfilment	-	履行，把需求实现出来
Feasibility Check	-	可行性检查，看看能不能做到
Negotiation	-	协商，商量着来
Degradation	-	降级，之前做到了现在不行了
Utility Function	-	效用函数，量化满意度
RAN	-	无线接入网，就是基站那部分
5GC	-	5G核心网，网络的大脑
NR	-	5G无线技术标准
CSC	-	通信服务客户
CSP	-	通信服务提供商
NOP	-	网络运营商
Selectivity	-	选择机制，多个条件怎么选
Conflict	-	冲突，需求打架
Implicit Intent	-	隐式意图，你没说但系统猜到的
Observation Period	-	观察周期，多久检查一次结果

---

附录：自学路线图

建议学习顺序

模块一：认识意图（第1-3节）
  → 理解基本概念
  → 预计30-40分钟
  
模块二：意图的流程（第4-5节）
  → 理解六种操作和七种状态
  → 预计30-40分钟

模块三：协商与冲突（第6-9节）
  → 理解协商的六个场景
  → 理解三种冲突
  → 预计40-50分钟

模块四：掌握细节（第10-11节）
  → 理解六种报告
  → 理解效用函数
  → 预计20-30分钟

模块五：实际应用（第12-13节）
  → 理解九个真实场景
  → 预计20分钟

模块六：巩固提升（第14-16节）
  → 了解技术实现
  → 复习回顾
  → 预计15分钟

学习方法建议

1. 每次学一个模块，不要一次学完
2. 每节学完后，做一遍节末练习
3. 遇到不懂的术语，翻到术语速查表
4. 用类比帮助记忆：把技术概念映射到日常场景
5. 带着问题回头看：如果某个概念混淆了，回到原文对应章节