5G QoS控制原理专题详解-QoS控制原理(1)

相关文章会在公众号同步更新。公众号：5G通信大家学

持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导各位同学。如果大家阅读时发现问题，随时留言。

从本篇开始继续整理5G QoS控制原理部分的内容，虽然稀稀拉拉的写了一些，但是都很分散，逻辑性还不够清晰，还在不断的调整补充当中，很多内容每读一遍都会有新的收获，内容也随时在更新补充。可能有的内容已经发过了，后续也会再更新。等详解系列的所有内容都整理完了，再统一发一下。

5G QoS控制原理专题详解 第（5） 部分的主要内容是：SDF的QoS控制。虽然我们从常见的材料可以看到，5G的QoS控制分为3个粒度：业务数据流、QoS Flow和PDU Session。但是我们在TS 23.501、TS 23.503等规范中都没有直接发现针对业务数据流粒度的控制原理说明。反倒在TS 23.501中明确说明：5G中区分QoS服务的最细粒度是QoS Flow。基本各个规范对QoS控制也都是针对QoS Flow说明的，但是在Stage 3阶段的规范中，PCC Rule的策略数据又都是针对SDF的，PCF下发的策略数据都没有直接针对QoS Flow的，这样就对我们理解QoS控制的三个粒度造成了很大的困扰。（对于业务量的统计，5G的最细粒度是SDF级别，也就是说UM数据可以针对SDF统计，自然在QoS Flow和PDU Session粒度级别只需要取和计算即可，很简单。）

所以，在SDF和QoS Flow的QoS控制部分有很多说明文字是根据个人的理解写出来的，有可能存在理解偏差。如果各位同学有疑问，欢迎随时在文末留言，互相探讨。

3.1.3 QoS 控制原理

本章介绍5G QoS控制原理，主要的控制部分在SMF、gNB和UE中，UPF只是根据SMF生成的控制数据执行相应的操作而已，没有控制权。5GS对QoS的控制需要分别对下行和上行进行分析。下行方向重点理解SMF如何生成控制数据，及如何指导UPF实现业务控制。理解这部分知识要分清业务数据SDF、QoS Flow和PDU Session具体是什么。下行方向SMF生成的QoS控制数据主要是对UPF到gNB之间的业务进行质量控制。之后，需要gNB完成QoS Flow和无线承载之间的映射，这里会涉及SDAP协议。至于空口的业务质量受环境影响就比较大了，和核心网的QoS控制原理关系并不强。在手机UE侧主要完成上行业务的控制。我们前面介绍的UE策略是完成业务数据到PDU Session之间的映射。这里QoS Flow的映射就需要UE根据网络下发的QoS策略数据来完成。UE参与度比较大QoS控制是Reflective QoS，此时，UE需要参与QoS策略数据的推导。这里就会涉及到N3接口上用户面数据包携带的Reflective QoS的控制参数，这部分内容是4G没有的。

我们后面的介绍逻辑基本就是按照下行数据包的流动方向，从SMF、gNB到UE进行介绍。之后再按照数据包的上行方向进行介绍，顺便把UE的Reflective QoS介绍一下。这样5G系统内的QoS控制原理就理解的比较全面而且深入了。整体来讲内容又多又杂，有些理解起来又比较抽象。

在本专题的最后，计划介绍一下数据包在5G系统外和5G系统内是如何映射的，比如UPF从N6接口收到一个数据包，那么UPF是如何把这个数据包映射到对应的PDU Session上的。这部分内容探讨的成分更多一些，3GPP中相应的很容也很简略，和不同厂家的设备实现关系比较强。

5G QoS控制模型，如下图：

从上面的5G QoS控制模型图可以看出来：

（1）一个PDU Session对应N3/N9接口的一个隧道；

（2）多个QoS Flow共享同一个隧道。这里说的隧道从细节上说就是分配的TEID是不是一个，如果在单独下行或者上行的某个逻辑接口上占用了两个TEID就认为是两个隧道。

（3）QoS Flow和无线承载（Radio Bearer）不是一一对应的关系。

（4）“一个DNN最多可以建立几个PDU Session”，和具体的SMF实现有关。在华为设备上有相应的参数可以控制的。一般来讲到一个DNN通常只建立一个PDU Session。

5G中对QoS的控制分为三个层次，按照粒度从细到粗，分为：

（1）Service Data Flow level（业务数据流级别）

SDF级别的QoS控制适用于IP类型或者Ethernet类型的业务数据流，直接使用PCC Rule来进行业务数据流级别的QoS控制。在应用程序没有提供具体指示信息的情况下，一个PDU Session内可以使用多个PCCRule，实现不同的授权QoS（authorisedQoS）。

（2）QoSFlow level（QoS Flow级别）

3GPP规范中，PCF没有对QoS Flow级别的QoS控制参数进行直接下发。QoS Flow级别的QoS参数是基于SDF的QoS进行控制的。SMF基于QoS Flow关联的PCC Rule来确定授权的QoS（authorizedQoS）。当QoS Flow被删除或者QoS Flow要求的GFBR不能得到保证（或重新得到保证）时需要向PCF发送通知（5G的QNC特性）。

（3）PDUSession level（PDU Session级别）

PCF可以为IP、Ethernet、unstructured类型的PDU Session提供授权的Session-AMBR值、默认5QI/ARP组合。PCF也可以在特定时间点请求更改authorized Session-AMBR值。

上说所说的授权QoS或者授权Session-AMBR是指UE可以合法使用的QoS控制参数，也就是经过PCF授权使用的。

下面针对这三种级别的QoS控制分别详解，来看看他们是如何实现的。

3.1.3.1 SDF的QoS控制

根据3.1.1.2 FlowDescription小节的叙述，基本就可以知道在5G中对于业务数据流的QoS控制是如何执行的。PCF下发给SMF的SMPolicyDecision中包含有qosDecs字段，其中包含QoSData数据。PCC Rule使用refQosData直接引用这些QoSData。这样就完成了SDF和QoS数据的关联，也就是说PCC Rule中的QoS数据直接作用在业务数据流SDF上。

SMPolicyDecision中包含QoSData数据的关系如下图：

对于GBR类型的5QI（包括GBR type或者delay critical GBR type），PCF会设置7个参数：GBR 5QI或者delay critical GBR5QI、arp、maxbrUl（max bandwidth inuplink）、maxbrDl （max bandwidth in downlink）、gbrUl（guaranteed bandwidth inuplink）、gbrDl（guaranteed bandwidth in downlink）、qnc（GBR不能保证或者重新得到保证时发送通知）。

对于non-GBR类型的5QI，PCF会设置4个参数：authorized non-GBR 5QI、ARP、maxbrUl、maxbrDl。

当PCF使用了标准的5QI，但是该5QI对应的Priority Level、Averaging Window、Maximum Data Burst Volume属性又不同于标准值时，PCF需要单独设置相应的属性值并下发给SMF。对于其它非标准及非预定义的5QI，PCF需要通过信令明确下发该5QI对应的QoS特性参数（QoS Characteristics）。

当5QI=1时，也就是对于IMS语音业务，如果前期已经协商好支持RAN-Support-Info特性，PCF还会下发maxPacketLossRateUl或者maxPacketLossRateDl参数。

虽然对于SDF，PCF通过PCC Rule明确下发了相应的QoS参数，即：PCC Rule引用的refQosData，但是实际上在UPF执行QoS控制时，是借助QoS Flow来实现QoS控制的。PCC Rule引用的QoS参数只用来执行QoS Flow的绑定作用，并不直接使用它进行QoS控制。也就是说，虽然5G中区分了三个级别的QoS控制，但实际上这三个级别是互相影响的，尤其是SDF和QoSFlow之间，是互相成全的关系，并不是孤立进行QoS控制的。在TS23.501中明确说明：QoS Flow是PDU会话中区分QoS服务的最细粒度。看起来和TS 23.503中的三个级别的QoS控制相矛盾，在我们后面弄懂他们之间是如何互相利用、互相影响的原理就会明白原因了。对于PDU Session级别的QoS控制相对比较容易理解，毕竟有单独的Session-AMBR。

3.1.3.2 QoS Flow的QoS控制

PCF没有直接给SMF下发QoS Flow的QoS控制参数，那么QoS Flow的QoS参数是如何推导出来的呢？这就会涉及QoS Flowbinding的概念，它对于SMF推导QoS Flow的控制参数非常重要。

实际上QoS Flow的QoS参数，即：QoS Profile。最开始生成时，是根据触发SMF新建QoS Flow的那个Service Data Flow的PCC Rule来推导的，后续随着该QoS Flow上绑定的PCC Rule增多，会同步修改该QoS Flow的QoS Profile。

3.1.3.2.1 QoS Flow Binding

3.1.3.2.1.1 QFI的分配

对于Non-GBR类型的QoS Flow，如果使用了标准的5QI或者预配置的5QI，并且5QI的值小于64（即：取值范围0～63），那么SMF可以直接使用5QI的值当作该QoS Flow的QFI。在PDU Session建立/修改，以及PDU Session的用户面激活时，SMF会通过AMF的N2接口将ARP和QFI发送给NG-RAN。

在其它场景下，对于GBR和Non-GBR QoS Flow，SMF可以动态指定QFI。5QI的值可以是标准化的、预配置的或者动态指定的。QoS profile和QoS Flow的QFI可以在PDU Session建立/修改及PDU Session的用户面激活时，SMF会通过AMF的N2接口发送给NG-RAN。

注：

上面两段话是TS 23.501的直接翻译。看起来没有什么问题，但细想起来，实际上疏漏了反射QoS的场景。当QoS Flow没有开启反射QoS时，上面的两段说法并没有什么问题。当QFI在0～63范围之内时，SMF发送给NG-RAN的是ARP和QFI，不需要发送QoS Profile。因为从3.1.1.9小节QoS Profile的介绍中可以看出来，Non-GBR QoSFlow的QoS Profile在没有开启反射QoS时，只有5QI、ARP两个参数，而5QI可以通过QFI直接推导出来。于是，对于Non-GBR QoSFlow，NG-RAN可以得到完整的QoS Profile。但是当开启了反射QoS时，对于QFI在0～63范围内时，SMF还需要补充下发RQA参数，这点大家不要忘记了。

当QFI的取值大于63时，就需要发送完整的QoS Profile和QFI了，这就无所谓QFI推导5QI和反射QoS的问题了，所有参数都是信令发送的。

另外，对于Non-3GPP接入，缺省的ARP参数可

以配置在AN上。