目录
I-SMF的引入
TODO
一些关联
UE Policy Association : UE策略关联, 即 SMF <--> PCF 中的 UE 策略的关联, 但UE策略的传递很特别 !!! 参考前文: 读南山耕夫笔记_一文弄懂5G UE策略
SM Policy Association : 会话策略关联, 即 SMF <--> PCF 中的 SM 策略的关联
会话相关数据传递
UE策略中: UE用来为手机应用数据选择 PDU Session, 但一旦选择后, 后续具体应用数据直接使用即可, 后续不再每次都要选择(特殊情况除外);
UDM中的签约数据: SMF选择数据, 会话管理数据;
PCF 动态PCC: req 中带默认Qos, SMF根据 res为UE生成 Qos Rule, 最后发给UE;
UE根据 Qos Rule将业务数据映射到不同的 Qos Flow;
仍有默认 Qos Flow 的概念;
分析一般规律:
- 如果是下载的话, 用 Get 方法, 不会返回 Location;
- 如果是创建某个上下文的话, 会返回 Location, 后续再操纵此上下文时直接使用此 Location;
- 如果是订阅的话
- req中:
- 包含 callbackRefrence uri, 这个是当某个事件触发时调用此 uri (发起请求)
- (可能)包含 monitoredResourceUris: 这个就是之前 get 某个资源时使用的 uri, 这个不是新创建的
- res中:
- 包含 Location: 被订阅者为这次创建的订阅资源 uri, 即创建了一个订阅 上下文, 但何时会用到呢 ? 是不是当修改,删除此订阅时会用到呢 ?
- req中:
下载SMF 选择数据: SMF_SEL
下载SMF UE Context签约数据: UEC_SMF
下载SMF 会话管理 签约数据
订阅SMF签约数据
SM策略关联: SMF <--> PCF
req: 包含 notificationUri, SMF用来接收来自PCF通知的资源URI
res: 包含 Location, 刚刚建立的SM策略上下文
UE策略关联: AMF <--> PCF
和上面类似, 都是req携带callback uri, res中将建立好的策略上下文 uri 放在 Location 中, 但是, UE策略很特别, 南山耕夫已经分析过了, UE策略的修改，更新并不直接从res消息中直接返回给UE, 二必须用单独的消息，因为负责策略的是 PCF , 而不是 AMF !!!
具体参考前文: 读南山耕夫笔记_一文弄懂5G UE策略