相关文章会在公众号同步更新。公众号：5G通信大家学
持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导网友。
在介绍完流程详解后，会整理专题内容，比如切片、服务发现、QoS流端到端的映射等内容，各位同学不仅可以纵向学习知识点，横向也会将知识关联起来，达到深入理解灵活运用的目的。
-------------------------------------------------------------------------
整个5G中最复杂的部分就是会话控制，也就是会话策略的控制、QoS的控制，我们在作设备数据配置时，这部分的数据也是最复杂的，涉及到各种引用关系。
介绍完1.3.2.3.7b小节后，深感如果不能细致理解5GS中会话的控制原理，只是把相关信令字段解释一下，对于我们理解5G的会话控制并没有什么帮助，反倒是被各种名词、各种信息搞得云山雾罩、焦头烂额，理不清头绪。
我们在看一些信令分析手册时也会发现，虽然手册把各个字段都介绍了，但好像对于我们理解技术原理并没有什么帮助，还是不知道他们在5G中具体的应用场景，或每个字段代表的更深层的意义。也不知道在5G中各个网元AMF、SMF、UPF、PCF，甚至UE对会话的控制都做了什么工作，他们之间是如何协调配合的，是通过什么信息，把各个网元的处理功能关联起来的。
所以这里加入5G QoS原理专题介绍，以期深入细致的分析5G QoS的控制原理，彻底弄明白信令中携带的各个字段起到了什么作用。
目前各个小节还在不断的编写修改中，已经写了50多页，还有很多章节在调整编写，预计还需要50页以上的篇幅才能把5G的会话控制彻底分解完成。后续对于5G会话相关的信令流程，我们只需要对照信令流程文件看一下关键点基本就能理解了。
下面是编写的部分章节内容目录，各个章节还在不断调整中，没有最终定稿。
SMF请求PCF为PDU会话建立SM策略。之后，SMF会根据从PCF得到会话决策信息（即：SM Policy Decision，详见1.3.2.3.7b小节的介绍）。所谓的决策信息就是经过PCF授权的策略控制信息，后面统称为策略控制信息，不再具体说明是经过PCF授权过的策略控制信息。实际上，没有PCF授权过的策略也没有什么意义。
SMF收到这些策略控制信息后，根据其中的信息执行相关动作：
（1）将业务数据流（SDF）和QoS Flow绑定起来；
（2）根据PCC规则推导UPF使用的控制规则信息，并发送给UPF；
（3）推导QoS Rule发送给UE，用于UE控制上行业务；
（4）推导QoS Profile发送给RAN，用于gNB执行QoS控制；
（5）如果UE使用多接入（MA）业务，还会推导ATSSS rules；
（6）如果相关事件发生时（哪些事件需要SMF关注，PCF会在策略控制信息中下发给SMF），SMF会和PCF进行消息交互执行相关控制。
本专题就是对上面介绍的这些内容分别详解，彻底弄明白SMF、UPF、NG-RAN、UE在5GS中是如何相互配合、执行QoS控制的。
为了便于理解后面的内容先介绍一下本专题涉及到的基本概念。在3GPP规范TS 23.501中都可以直接找到定义的原文，这里只是为了方便理解做一下解释性或者补充性的说明，大部分内容都是直接翻译的3GPP文档。
3.1.1.1 Packet Filter Set
Packet Filter Set在我们后面介绍的PDR和QoS Rule中会作为基础部件来使用，用于识别数据流，也就是说，通过使用Packet Filter Set，会将满足某些匹配特性的数据包放在同一个数据流中，起到了数据包分类的作用。
一个Packet Filter Set可以包含多个Packet Filter。每个Packet Filter适用于下行数据包、上行数据包或者双向数据包。
5G定义了两种类型的Packet Filter Set，即：IP Packet FilterSet、Ethernet Packet Filter Set，分别适用于IP类型的PDU Session和以太网类型的PDU Session。Packet Filter可以有多个匹配数据包的字段，这些字段可以组合使用，当某个字段不存在时，默认认为是可以匹配上所有的数据包。
（1）IP Packet Filter Set
- 源/目的IP地址或IPv6前缀（可以和掩码组合使用）
- 源/目的端口号（可以是端口范围）
- 协议号或者Next header类型（IPv6）
- Type of Service (TOS)(IPv4) / Traffic class (IPv6)及掩码
- Flow Label (IPv6).
- Security parameter index（适用于IPsec）.
- Packet Filter direction（过滤器适用的数据包方向）
（2）Ethernet Packet Filter Set
- 源/目的MAC地址（可以是MAC地址的范围）
- Ethertype（指明三层协议的数据类型）
- Customer-VLAN tag(C-TAG) and/or Service-VLAN tag (S-TAG) VID
- Customer-VLAN tag(C-TAG) and/or Service-VLAN tag (S-TAG) PCP/DEI
- IP Packet Filter Set（如果三层是IP数据包时，会包含该字段）
- Packet Filter direction（过滤器适用的数据包方向）
3.1.1.2 Flow Description
Flow-Description是一种IPFilterRule类型的数据，定义了IP数据流的包过滤器，详见TS 29.214的5.3.8章节。引用的内容就是3.1.1.1中介绍的IP Packet FilterSet。主要包括：
- 动作（action）：可以是permit或者deny。
- 方向（Direction）：可以取值in或者out。in表示上行IP数据流，out表示下行IP数据流；
- 协议号或者指示该字段不用于过滤数据包：取值“ip”
- 源IP地址/端口号
- 目的IP地址/端口号
下面是从PFCP SessionEstablishment Request消息中截图的FlowDescription信息，共参考：
注：
any：标识IP地址：0.0.0.0/0
assigned：表示UE的IP地址。
3.1.1.3 Ethernet Flow Description
Ethernet FlowDescription包含的内容基本同3.1.1.1中Ethernet Packet Filter Set。所不同的是以太网MAC地址没有掩码的概念，所以除了EthernetPacket Filter Set外，还可能包含：源MAC地址结束地址（srcMacAddrEnd）、目的MAC地址结束地址（destMacAddrEnd），用于表示一个MAC地址的范围。其数据类型定义在TS 29.514中，可以参看。
3.1.1.4 Service data flow filter
UPF中用于识别数据包流的一组数据包头的参数。这个概念的重点在于是用于识别数据包流。实际上用到的参数和3.1.1.1小节介绍的数据包的过滤器是一样的。在3.1.1.2小节中的截图就是一个业务数据流过滤器，其中包含有Flow Description。
3.1.1.5 Service data flow template
PCC Rule中的一组业务数据流过滤器或者PCC Rule中的应用程序标识（applicationidentifier，用于识别SMF或者UPF中配置的application detectionfilter）称为业务数据流模板（service dataflow remplate）。也就是说业务数据流模板使用了一个或者多个上面介绍的业务数据流过滤器。比如：我们定义了一个只允许某个音乐网站的数据包通过的过滤器，当我们在用手机看网页的时候，同时进行在线听音乐或者下载文件，从网络上来的各种数据包全都混在一起，这些所有的数据包通过一个业务数据流模板，从模板出来的只剩下该音乐网站的数据（从模板出来的数据流，就是下面介绍的业务数据流），这就是业务数据流模板的作用，实际上起作用的是模板中的业务数据流过滤器。我们在看3GPP时，虽然有业务数据流模板的概念，但更多的是使用业务数据流过滤器的概念。
3.1.1.6 Service data flow
承载在UPF上的、匹配上业务数据流模板的一组数据包流。
3.1.1.7 QoS Flow
5G中的QoS Flow和4G中的承载类似，也分为：保证比特速率的GBR QoS Flow和不保证比特速率的Non-GBR QoSFlow。
QoS Flow是PDU Session中QoS差异化服务的最细粒度。一个PDU Session中同一条QoS Flow中的用户业务具有相同的QoS服务等级，如调度、准入控制等。
QoS Flow ID（QFI）用来识别一个QoS Flow。在同一个PDU Session中，QFI是唯一的，取值范围：0～63。QFI承载在N3、N9口的GTP数据包的包头部分。QFI适用于所有的PDU Session类型（IP类型、以太网类型、非结构化类型等）。QFI可以动态分配，也可以和5QI取值相同，具体他们的分配方法在后面章节会有说明。
QoS Flow由SMF进行控制，可以预先进行配置，或通过PDUSession Establishment/ PDU Session Modification进行创建。
注：
（1）上面所有的PDU Session，一般一个DNN会创建一个PDU Session，比如UE既连接CMNET上网，又开通了VONR业务，此时网络会创建两个PDU Session，对应哦在gNB和UPF之间的接口也会有两个隧道。
（2）预先配置的QoS Flow，在其它3GPP文档中也没有看到明确说明具体是怎么回事。个人理解应该是网络中没有部署PCF场景，或者作为PCF故障时的容灾配置，可能会出现预先配置的QoS Flow。乍一看，貌似预配置的QoS Flow好像很难理解，就像河流一样，都是先开挖才能有河流，而预配置的QoS Flow，是不用挖，直接就有河流了，理解起来有点困难。其实TS 23.501中所说的：预先配置的QoS Flow，实际上在设备实现时，只
是SMF根据UDM中的签约数据和本地配置的数据预先生成一组QoS参数，再分配一个QFI，关联上这一组QoS参数，认为一个预配置的QoS Flow就诞生了。也就是说预配置的QoS Flow在实体上，只是一组可见的QoS参数。这样，SMF根据这一组预配置的参数就可以生成PDR、QoS Profile等，可以顺利保证QoS Flow的创建和业务的传输流程正常进行，否则，UE的业务请求就会被网络拒绝。
从上面一段就可以看出来，QoS Flow看起来是一个有形的一条数据流，实际上物理上只是一个QFI和其关联的一组QoS参数。
QoS Flow的特点：
（1）具有一个QoS Profile
QoS Profile由SMF推导，由SMF发送给AN或者预先配置在AN（gNB）中。
（2）一个或多个QoS Rule及QoS Rule关联的QoS Flow级别的QoS参数（可选）
QoS Rule由SMF通过AMF发送给UE或者UE利用Reflective QoS特性自行推导QoS Rule。
（3）一个或者多个上行和下行PDR
SMF提供给UPF相关的PDR。
上面这个三个QoS Flow的特点，也是我们后面重点研究的。5G的QoS控制和这三个特点密切相关，这三点互相配合共同实现了5G QoS控制。
PDU Session还需要建立一个关联default QoS Rule的QoS Flow，并且在PDU Session的生命期中一直存在。该QoS Flow是non-GBR类型的。这个QoS Flow就是我们平时所说的缺省QoS Flow，但是规范中没有明确进行定义，只是我们说起来方便。default QoS Flow的说法只在TS 23.501的修订说明中发现了一次。
注：
在“gNB中预定义QoS profile”的进一步说明在3GPP规范中暂时还没有找到，待后续找到相关的进一步说明和应用时再进行补充。个人理解，即使是预定义QoS Profile，也需要通过信令上报给SMF，否则如果gNB中定义的QoS Profile和SMF中定义的或者PCF定义的不一致时，会出现QoS控制的混乱。
