5GC基础自学系列 | UE发起的业务请求（Service Request）流程

Posted 2022-04-04 COCOgsta

视频来源：51学通信《5G核心网基础、协议与信令流程》

一边学习一边整理老师的课程内容及试验笔记，并与大家分享，侵权即删，谢谢支持！

---

Service Request（业务请求）流程简介

UE发起的Service Requuest流程的场景（不考虑Non-3GPP场景）：

• 在CM-IDLE态有上行方向信令要发送。【service type=signaling】
• 在CM-IDLE态有上行方向用户面数据要发送。【service type=data】
• 在CM-Connected态有上行方向用户面数据要发送， 但此时关联的PDU会话的用户平面资源没有建立。【service type=data】
• 做为对Paging的响应（当收到网络侧的寻呼请求时）【service type=mobile terminated services】
• 发起紧急业务或紧急业务回落。【service type=emergency或emergency services fallback】

是否一定要CM-IDLE态发起?

答：不是。也可以是CM-Connected状态发起， 用于激活一个用户平面的连接。

这一点和4G不太一样。4G中UE通常要在ECM-Idle状态下发起Service Request流程。

但也有两个例外：

• CSFB
• NB-IOT中的控制面优化方案场景

5GC业务请求流程涉及的规范

5GC业务请求流程涉及的主要规范：

• 23502：流程
• 23501：5GC架构
• 24501：5GCNAS消息
• 29244：PFCP消息
• 38413：NGAP消息
• 29502：SMF服务
• 29518：AMF服务等

3GPP规范中的UE发起的Service Request流程

规范信令流程图中的“小遗憾”

可以看到，规范中描述的UEE发起的Service Request流程是非常复杂的。原因是场景很复杂。

包括：

• UPF的重选
• 多UPF以及和PSA的分离设置等（边缘计算场景）

但实际上至少在5G初期的现网中不会出现这么复杂的场景，要简单很多。因此：从初学者的角度，需要进行定制化学习。

定制化（更符合实际网络）的业务请求流程

基于以上“小遗憾””，对规范中的UE发起的Service Request流程进行了定制化。主要包括：

• 加入场景介绍。并标明了接口的协议和主要消息、参数。
• 结合国内EPC部署经验， 去掉不太可能在5GC中部署或早期部署的流程。使之更接近国内运营商实际网络。

基于3GPP规范的UE发起的Service Request流程的场景如下：

1）广州UE来到了北京，在北京发起了注册流程并成功在北京AMF中完成注册。

2）接下来广州UE发起PDU会话建立流程， 成功建立了一个PDU会话并开始上网。此时UE的CM状态为CM-Connected。

3）广州UE上网累了，没有流量产生。网络侧触发了ANN释放流程，将接入资源和N2的UE上下文释放。该流程完成后， UE状态为CM-IDLE。

4）接下来广州UE又想上网了，发起了接下来本文所描述的Service Request流程。

• 本流程中gNB、AMF、SMF均在拜访地北京， 只有PCF和PDU会话建立流程中的PCF相同， 为归属地广州的。

更常见的UE发起的Service Request流程 - UE要发送上行数据触发

规范中的一些原文（供参考）