相关文章会在公众号同步更新，最近工作忙，更新完公众号后，经常容易忘记再CSDN上再发。公众号上的文章更新的能快一些，各位同学有兴趣可以关注一下。公众号：5G通信大家学
持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导各位同学。如果大家阅读时发现问题，随时留言。
上篇文章发完之后发现对Default QoS Flow的说明还不够全面，仍然有思维漏洞，所以这两天又查阅了大量规范文件和厂家文档，专门介绍一下Default QoS Flow。
5G中对Default QoS Flow的介绍很少，甚至介绍的还有一些歧义，所以这里把各种相关信息汇总到一起，供大家工作时参考。很多内容是根据个人理解总结的，难免会有理解不到位的情况，欢迎留言讨论。
在4G LTE中存在default Bearer的概念，也就是缺省承载或者默认承载。UE附着到网络的时候会直接创建default Bearer，并保持“永久在线”。这里说的永久在线是指核心网连接一直存在，对应的具体内容就是GTP隧道、UE Context等内容都会一直保存在核心网中。无线连接在没有业务发生，计数器超时后，仍然会拆掉连接。4G中，UE的用户面和信令面在附着过程中同时建立了连接。
5G和4G相比，UE的注册过程并不进行用户面连接的创建。如果想进行数据传输还需要单独发起用户面连接建立流程，也就是PDU Session的建立流程。这点是注册过程和4G很不一样的地方地方。当然，5G的注册过程，如果UE有数据传输，也可以在注册过程中直接创建用户面连接。另外，为了便于物联网应用场景的小数据包传输，也可以在信令连接中直接传输用户业务，不需要建立用户面连接。至于为什么5G中又把创建缺省连接的功能去掉。个人理解5G为了满足ToC和ToB多种业务场景，还需要满足每平方公里100万连接的指标。如果要求每注册一个用户都创建一个默认承载，十分消耗资源，设备也基本承受不住这么大的用户量，所以5G中做了灵活处理，默认并不为用户建立类似4G中的默认承载。
在5G 3GPP标准中并没有明确定义default QoS Flow的概念，唯一的一次出现default QoS Flow的概念是在TS 23.501的change history中，如下图：
查询2020-09之前和之后的规范文件，发现出现default QoS Flow的地方也不是介绍QoS Flow的章节，而是在介绍ATSSS功能时出现了这个概念。在R16 g20以后的版本中default QoS Flow的概念就彻底只在change history留有痕迹了。实际上我们在读标准文件的时候，也仍然有default QoS Flow的应用，只是所有的地方都用“QoS Flow associated with the default QoSrule”（翻译成中文就是：关联了default QoS rule的QoS Flow）来进行了替代。至于为什么规范的编写者舍弃了简洁的default QoS Flow概念，使用了冗长的“QoS Flow associated with the default QoS rule”，目前还没有想到。也许使用default QoSFlow的概念，是为了和4G中“alwayson-line”的Default Bearer做一下区别，以示default QoS Flow并不是always on-line意思。
我们先详细分析一下“QoS Flow associated with thedefault QoS rule”的概念，看看从本质上到底说明了什么。TS 23.501的QoS Rule章节提出了这个概念，但是介绍的比较简单，查遍其它的5G规范都没有详细解释“QoS Flow associated with the default QoS rule”的说明。
TS23.501中对QoS Rule的说明有：The UE performs theclassification and marking of UL User plane traffic, i.e. the association of ULtraffic to QoS Flows, based on QoS rules.，说明QoS Rule用于UE对上行业务进行分类，由网络提供给UE或者在开启ReflectiveQoS的情况下由UE自行推导的。QoS Rule包含的关键信息是数据包过滤器（Packet Filter Set）（记得在华为的产品文档中偶然看见过QoS Rule分区上行和下行，写这篇文章时再去查找一直没有找到，不知是否记忆错误）。对于下行业务，UPF使用PDR对数据包进行分类。PDR在规范中区分了上行和下行。对PDR的介绍在后面详细展开，这里不进行详细说明。
Default QoS rule在TS 23.501中的说明如下：A default QoS rule isrequired to be sent to the UE for every PDU Session establishment and it isassociated with a QoS Flow. For IP type PDU Session or Ethernet type PDUSession, the default QoS rule is the only QoS rule of a PDU Session which maycontain a Packet Filter Set that allows all UL packets,and in this case, the highest precedence value shall be used for the QoS rule.从这段说明里可以看出来QoS Rule需要和QoS Flow关联起来，使用QoS Rule中包含的Packet Filter Set对上行数据包进行过滤。也就是说通过Packet Filter Set的数据包在对应的QoS Flow上进行传输。Default QoS rule中包含的是允许所有上行数据包通过的Packet Filter Set，并且Default QoS Rule的优先级值最高，也就是具有最低的优先级，是上行业务的兜底QoS Rule。UE在进行上行数据发送的时候，按照优先级逐一匹配QoS Rule，匹配上相关的QoS Rule后，该数据包就是用这个QoS Rule关联的QoS Flow传输，如果所有其它的QoS Rule都没匹配上，一定会匹配上Default QoS Rule，之后使用其关联的QoS Flow传输该数据包。和我们电脑配置的默认网关的作用类似。
介绍到这我们就知道了“QoS Flow associated with thedefault QoS rule”到底是怎么回事。虽然3GPP规范中没有default QoS Flow的概念，通过上面的介绍可以看出来，与4G相比除了alwayson-line之外，在数据传输方面没有明显的区别。所以后续我们为了叙述方便，仍然使用Default QoS Flow的概念来说明。
在上一篇文章里介绍了SMF对default QoS Flow执行QoS Flow binding的处理原理。为了叙述方便直接使用了default QoSFlow的概念，而没有使用“QoS Flow associated with the default QoSrule”的叙述，对于理解绑定原理不会造成障碍。根据前面的介绍，PCF下发的PCC Rule中包含有"defQosFlowIndication"标记时，表示该PCC Rule需要绑定到default QoS Flow上。这样，default QoS Flow关联的PCC Rule过滤出来的SDF使用default QoS Flow来传输。我们进一步思考一下：包含有"defQosFlowIndication"标记的PCC Rule从规范中理解并不是PCF必须要下发的策略。如果PCF没有下发携带"defQosFlowIndication"标记的PCC Rule，那么随PDU Session的建立而建立的Default QoS Flow，它到底有没有关联的PCC Rule呢？如果default QoS Flow没有安装PCC Rule，那么它是用来传递什么样的SDF的呢？这是我们沿着上篇文章继续深入思考遗留的最大问题。
这两天又把5G相关的3GPP标准基本都翻了翻，确实没有发现Default QoS Flow是否关联PCC Rule（不论是动态还是静态）的说明。因为Default QoS Flow是否关联PCC Rule会涉及到下行数据包的传输问题。如果按照“QoS Flow associated with thedefault QoS rule”的定义，加上QoS Rule是UE用来进行上行业务分类使用的规则，自然可以推导出来Default QoS Flow只用来进行上行数据包传输的结论。但是，我们在TS 24.229中查到Default QoSFlow需要用来传递SIP信令。既然用来传递SIP信令，那么Default QoS Flow一定是双向的，所以根据定义推导出来的Default QoS Flow传输单向业务的结论是错误的。Default QoS Flow对上行业务的处理没有任何异议，规范写的也很清晰。我们只需要讨论Default QoS Flow处理下行业务的原理就行了。有了这个想法就可以得到两个推论：
（1）Default QoSFlow是特殊的QoS Flow，不需要安装PCC Rule即可用来传递下行业务；
（2）Default QoSFlow按照普通QoS Flow对待，必须安装PCC Rule，只是这个PCC Rule是SMF预定义的。这样，即使PCF不下发，SMF也可以自行生成。
我们后面会介绍：UPF在进行下行数据包的分类时使用的是PDR，而PDR是由SMF根据PCC Rule推导出来发送给UPF的。如果PCF没有下发关联Default QoS Flow的PCC Rule，此时，SMF推导PDR的依据就需要考虑了。
上面的两个问题3GPP规范原文已经无法查到了，于是查了一下某设备的产品文档，有一些相关说明：
缺省QoS Flow的建立有两种方法：
（1）同4G场景，至少配置一个SessionRuleAction+DynamicPccRule，且两者的QCI和ARP须对应相等。
（2）仅配置一个DynamicPccRule，且保证该种动作类型中的5QI和ARP与用户上线请求的保持一致，即可完成缺省QoSFlow建立。
并且，文档明确说明：如果对端SMF是该厂家设备，建立Default QoS Flow必须下发动态缺省PCC Rule，否则QoS Flow无法建立成功。
上面说的动态缺省PCC Rule就是我们前面介绍的携带"defQosFlowIndication"标记的PCC Rule。
可以看出来对于该厂家的设备对待DefaultQoS Flow和普通QoS Flow一样，PCF必须下发安装在Default QoS Flow的PCC Rule。因为这部分内容3GPP规范没有明确定义，所以同一厂家的设备统一好实现标准就没问题。如果是不同厂家对接，对于Default QoS Flow的创建就需要注意。最保守的情况就是，不管什么设备PCF全部下发携带"defQosFlowIndication"标记的PCC Rule，这样就可以确保在任何情况下DefaultQoS Flow都可以创建成功。另一个解决办法就是SMF上预定义一个PCC Rule，如果PCF没有下发安装在Default QoS Flow上的PCC Rule，SMF可以使用自身预定义的PCC Rule生成PDR下发给UPF使用，其中包含的数据包过滤器要能匹配上所有的数据包，这样就可以保证UPF不会因为没有匹配的PDR而丢包。
下面看一下现网设备创建default QoS Flow的QoS参数。SMF发送给PCF的Npcf_SMPolicyControlAPI_SmPolicyControlCreate Request消息携带的缺省QoS Flow的信息如下图，可以看出来该用户签约的Default QoS Flow的5QI=9 ：
PCF发送给SMF的Npcf_SMPolicyControlAPI_SmPolicyControlCreateReponse响应消息，如下图，仅包含Session Rule信息：
从上图可以看出来，PCF在响应消息中没有下发PCC Rule，而且Session Rule中的数据PCF已经将UE签约的缺省5QI=9修改为了5QI=6。5QI=6在5G中是视频等大流量业务的标准5QI。因为PCF没有下发Default QoSFlow需要的PCC Rule。按照该设备的产品说明，此时SMF应该无法创建Default QoSFlow。实际上该UE的信令流程是正常执行的。因此，接下来我们看一下PFCP Session Establishment Request消息包含的内容，如下图。如果SMF能够正常创建Default QoSFlow，就会推导PDR发送给UPF。所以查看一下该消息中是否包含过滤器就知道SMF有没有预定义QoS规则。
从PFCP Session Establishment Request消息中可以看出来，SMF下发给UPF的PDR中包含有允许任何数据包通过的SDF Filter，也就是UPF会将UE的任何数据包全部转发。说明SMF在没有收到PCF下发的PCC Rule时也会自行处理，这样就可以保证在任何情况下Default QoS Flow都可以正常建立起来。
最后将DefaultQoS Flow相关的主要知识点总结一下：
（1）目前5G中的Default QoS Flow基本和4G中的缺省承载相同，用于UE所有缺省情况下的业务传输。通常Default QoS Flow是Non-GBR的，但是，也可以根据实际情况通过PCF或者SMF配置，将Default QoS Flow创建为GBR类型。
（2）Default QoS Flow随着PDU Session的建立而建立，通常使用UDM中签约的5QI/ARP值进行创建。PCF和SMF也可以根据具体配置修改UE签约的5QI、ARP、Session-AMBR等参数，最终生成用于创建DefaultQoS Flow的QoS参数。
（3）Default QoSFlow不能使用Reflective QoS功能。
（4）对于非结构化的PDUSession，只有一个Default QoS Flow，并且其关联的QoS Rule不包含Packet Filter Set。
（5）对于非结构化的PDU Session，只能使用缺省的5QI、ARP和Session-AMBR参数（TS 29.513）。
（6）NB-N1模式下UE的PDU Session中只能有一个QoS rule，就是default QoS rule，而且，NB-N1模式也不支持Reflective QoS。
（7）VoNR场景下，只能使用Default QoS Flow进行IMS 信令传输。这个Default QoSFlow是创建到IMS DNN的PDU Session时建立的。对于数据网络的DNN，如：CMNET，会有到CMNET的Default QoS Flow。这点和4G相同。
（8）UE需要使用Default QoS Flow进行SIP信令传递。如果用于SIP信令传递的Default QoS Flow被去激活了，UE需要重新执行初始注册。
（9）UE在创建用于传递SIP信令的PDU Session时，会在PDU SESSIONESTABLISHMENT REQUEST消息的PCO（extended Protocol Configuration Options）中携带IM CN Subsystem Signalling Flag，如下图：
（10）SMF创建普通QoS Flow时会比较从PCF收到的5QI、ARP参数，如果5QI、ARP参数与Default QoS Flow的5QI和ARP不相同，就会创建普通QoSFlow。这也是QoS Flow Binding的基本原理。
