5G 新QoS流处理
对于反射QoS（reflective QoS），UE基于在DRB内接收的下行分组数据来确定上行中的QoS flow ID到DRB的映射，并应用filter来将上行流映射到DRB。UE“连续”监视下行PDCP分组中的QoS flow ID，并相应地更新上行中的反射QoS flow ID到DRB映射。但是RRC可以配置上行映射。
如果进入上行分组数据与QoS flow ID到DRB的映射不匹配（既不是经配置的也不是经反射QoS确定的），则UE应将该分组映射到PDU会话的默认DRB。
当一个新的QOS流被用于一个UE时，UE应该为这个QOS流配置几个方面：
i.授权：是否允许UE在上行中使用此QOS流/IP流？
ii.映射：上行IP流应该使用什么QOS流，QOS流应该使用哪些DRB？
iii.QOS profile：要求的QOS特征是什么？
在最简单的情况下，当网络想要开始使用具有下行分组的新QOS流时，网络必须预先配置/预授权UE。即依靠reflective QOS：
i.授权：UE在下行中接收到具有特定QOS flow id标记的分组的事实可以被视为允许UE在上行中使用QOS流/IP流的指示。
ii.路由：下行分组将指示将什么IP流添加到QOS流（UL TFT）以及在什么DRB上处理QOS流。
iii.服务质量：如果下行分组是通过某个DRB接收的，并且考虑到DRB表示总QOS（即，延迟、GBR、丢失等），则没有QOS流特定QOS参数来（预）配置UE。将需要向RAN通知QOS profile（因为RAN要建立/配置DRB），但不需要向UE通知QOS profile（UE由RAN配置有包括相关参数的DRB）。
更典型的情况可能是新的QOS流由新IP流的第一个上行分组数据触发。在这种情况下，假设有4种情况：
Case 1：专用QOS流–NAS配置和AS配置
新IP流是（预先）授权的非默认QOS流的UL TFT的一部分
UE配置了QOS流->此非默认QOS流的DRB映射
DRB存在
在这种情况下，有一个完整的（预）配置。UE接收属于非默认QOS流的UL TFT的上行分组，UE可以用非默认QO flow id标记该分组，并在配置的DRB上发送上行分组。
Case 2：专用QOS流–NAS配置和AS未配置
新IP流是（预先）授权的非默认QOS流的UL TFT的一部分
UE未配置QOS流->此非默认QOS流的DRB映射
Case 3：无专用QOS流-允许默认QOS
新IP流是默认QOS流的UL TFT的一部分
UE配置了QOS流->此默认QOS流的DRB映射
DRB存在
在这种情况下，如果UE启动了新的IP流，并且它是默认QOS流的UL TFT的一部分，则将在默认DRB上使用默认QOS flow id发送分组。注意，当检测到该分组时，UP GW可决定该IP流的后续分组应在特定QOS流上处理，并将用特定QOS flow id标记后续下行分组。
Case 4：无专用QOS流-不允许使用默认QOS
新IP流不是任何UL TFT的一部分，即不是默认的UL TFT或非默认QOS流的一部分。
在这种情况下，IP数据包将被丢弃。
这个case 2需要进一步讨论。原则上，可以看到两种可能的处理方法：
Option A：临时使用默认DRB
只要没有为该QOS流配置DRB映射，UE就将分组映射到默认DRB。
预计网络（gNB）在检测到新的QOS流时（可能在建立新的DRB之后）将通过RRC或RQ用适当的映射来配置UE。
Option B：询问AS配置
UE将触发RRC过程以请求获得适当的QOS流->DRB映射
网络将通过配置具有适当QOS流->DRB映射的UE来响应（可能在配置新的DRB之后/同时），之后处理符合case 1的分组数据。
在表1从多个方面比较了这两个选项：
根据表1的分析，认为option B更可取。然而，option A更简单。
将反射式QoS处理作为一个整体来看，当接收到受反射式QoS约束的下行分组时，UE将采取以下两个独立的动作。
Action 1（AS）：
对于接收到的QOS flow id，更新/添加QOS流->DRB映射到接收到下行数据包的DRB。
Action 2（NAS）：
对于接收到的IP流，更新/添加IP流->QOS流映射到接收下行数据包的QOS flow id（可能从一个UL TFT中删除IP流，将IP流添加到另一UL TFT）。
如果每个下行分组都必须考虑用于反映QOS处理，这意味着对于每个接收到的下行分组，UE将必须执行多次查找并可能对表条目进行更新。考虑到NR旨在支持高达20Gbps的下行数据速率，这意味着每秒将有多达160万个IP数据包到达（假设为1500B数据包）。应该清楚的是，对每个接收到的下行分组执行这些动作将给UE带来相当大的处理负担。
对每个下行分组执行这些操作也可以被认为是不必要的。仅当QOS需求发生变化时，才应切换IP流的映射，这对于现有的IP/QOS流来说通常是不太可能的。此外，如果我们假设没有整体PDCP实体来确保按顺序递送，则将QOS流从一个DRB切换到另一个DRA可能会导致按顺序递送。因此，不应过于频繁地更改IP流或QOS流的DRB。
限制反射QOS的UE处理负担的相对简单的解决方案可以通过在下行分组中具有带内标记来实现，以指示UE是否应该/不应该处理用于RQ的分组。只有当存在标记时，UE才必须执行上述动作。
只有RQ动作才需要在下行包中包含QOS flow id。也就是说，如果UE对下行分组没有RQ动作，则没有理由在分组中包括QOS flow id。因此，使用QOS flow id的包含作为分组受RQ处理的指示符似乎很简单。
