读南山耕夫笔记_一文弄懂5G UE策略

本文主要是介绍读南山耕夫笔记_一文弄懂5G UE策略，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

引子

UE Policy Association 的触发场景和条件

UE Policy 为何物 ?

URSP

优先级

业务描述符(traffic descriptor)

路由选择描述符: 包括 (重要项, 非重要项此处未列出)

UE中如何使用URSP路由数据

URSP规则的匹配过程: 感觉像一个算法

信令流程

ue策略更新有两种场景

流程第一阶段: 触发

流程第二阶段: UE PolicyAssociation的建立

流程第三阶段: UE策略的下发

eps.pcap 分析

引子

1. UE上应用程序的数据 -> PDU Session 如何映射 ?

2. UE 新建立PDU Session 时如何选择切片 ?

3. UE 策略的下发流程 ?

4. UE 策略的更新流程 ?

YYR: 程序是可以串联起来的, 有因就有果；

进入了5G后, UE建立PDU Session时就需要判定用哪个切片, 应用数据如何映射, 每个细节都是问题

UE Policy Association 的触发场景和条件

场景
UE发起初始注册;
HO或移动性过程中, AMF改变, 新AMF选择了新PCF;
EPS->5GS: UE移动到5GS时, AMF和PCF间无UE Policy Association

条件

非漫游下: 注册请求消息中, 如果包含了 UE Policy Container, 则会执行 UE策略关联; 如果未包含, 则AMF根据本地配置决定是否执行 UE策略关联;
漫游下: 需要根据漫游协议来决定;

UE Policy 为何物 ?

ANDSP: Access Network discoveryyand selection policies, 用于UE选择 non-3GPP接入网络
V2XP: R16 新增
URSP: Route Selection Policy, 路由选择策略, 这个是重点 !!!

URSP

整体介绍

指导UE路由上行业务, 就是将 UE上行用户数据和PDU Session进行关联起来的准则

UE触发建立新 PDU Session;
UE将业务路由到一个已建立的PDU Session;
UE将业务路由到non-3GPP接入的PDU Session;

规则特点

可由 UE预配置或 PCF提供, 但 PCF 的优先级高；

可以有1条或多条规则;

如果有多条规则, 则其中只有一条可定义为 缺省URSP规则: 可以匹配上所有业务的业务描述符(traffic des)

规则定义:

由上图可以看出包含3部分(必选)内容, 和其他可选内容 (LY: NTA)

优先级, 业务描述符, 路由选择描述符, 具体：

优先级

数值越小, 优先级越高

业务描述符(traffic descriptor)

包含能够匹配上所有业务的描述符, 或
包含匹配具体的Application des, IP des, Domain des, DNN 等信息的组建

注意: 1. DNN 也可以在路由选择描述符中存在, 但只能二选一;

2. 相同类型的组件, 其中之一匹配上即可; 不同类型的组件, 只有都能匹配上才能使用此URSP规则;

路由选择描述符: 包括 (重要项, 非重要项此处未列出)

优先级
路由选择组件: (Route Selection Compont, UE在创建PDU Session时必须符合下面的条件)
- SSC模式 selection : UE发送的上行数据包使用的 PDU Session 需支持此 SSC 模式
- 网络切片selection : UE发送的上行数据包使用的 PDU Session 需支持此切片
- DNN selection : UE发送的上行数据包使用的 PDU Session 需支持此 DNN
- PDU Session Type selection : 类似上面
- Non-Seamless Offload indication : 应用数据需卸载到 non-3GPP接入, 此组件和 DNN/切片选择互斥 !!!
- Access Type Preference : 3GPP, non-3GPP, multi-access
- Time Window : 一定的时间窗口内有效
- Location Criteria : UE的位置能匹配上时有效
路由选择校验标准

UE中如何使用URSP路由数据

1个PDU会话可以有多条QoS Flow (max 64条);

不同的PDU会话的QFI可以相同, 但同一个会话的QFI不同;

取值范围: PDU会话(1-15), QFI(0-63)

URSP规则的匹配过程: 感觉像一个算法

UE新运行一个应用 -> 根据优先级执行URSP规则的匹配 -> : why 这样做 ? (TD 可以理解, 但RSD 没法被应用直接判断吧 ??? )
有匹配的 URSP规则, 根据其中的 "路由选择描述符(RSD)" 的优先级选择适合的 RSD;
UE比较已建立的 PDU Session 是否能匹配上上面选择的 RSD 中的组件, 匹配规则如下:
- 比较 PDU会话的SSC 和 RSD的 SSC；
- 比较 PDU会话的切片和 RSD的切片;
- ...
匹配结果分析
- 如果UE新启动的应用和现存的一个PDU 会话能够匹配: 把此应用的数据路由到这个 PDU 会话
- 如果UE新启动的应用和现存的多个PDU 会话能够匹配: UE根据自己的配置选择适合的PDU会话
- 如果UE新启动的应用和现存的PDU 会话都不能匹配: 使用 RSD 包含的参数请求 UE的 NAS层触发建立新的 PDU会话
  - 所以说, PDU会话建立时的参数不是凭空来的, 这便是依据 !!!
  - 从 RSD 中可获得的参数有:
    - SSC
    - 一个 S-NSSAI: 如果有的话
    - 一个 DNN: 如果有(并且 traffic des 中没有DNN时)
    - PDU session type
    - 优先的 Access Type OR multi-access
  - 如果PDU会话建立成功:
    - UE的NAS层将建立的PDU会话信息通知给 URSP层,
    - 将PDU addr 等信息通知给更高层
    - 停止为应用程序选择 RSD
  - 如果PDU会话建立失败
    - 采用 RSD 中的其他参数组合重新发起 PDU会话建立流程
    - 如果还失败, 则选择低优先级的 RSD 再尝试
    - 如果还失败, 则使用能匹配 traffic des 的低优先级的 URSp规则中的组合值再建;

信令流程

ue策略更新有两种场景

场景一: 初始注册过程中的触发
- 触发条件: Register Req 中携带 UE Policy Container, 和注册流程一起执行。
场景二: 触发器触发:
- 触发条件: AMF执行 Npcf_UEPolicyControl_CreateReq 后会下发触发器, 后续UE如果满足触发器定义的条件时, 进行UE策略的更新