做核心网、终端协议栈或者RAN侧调度的朋友大概率都翻过TS 23.501。每次看到第5.7节QoS模型总绕不开一张表5QI到QoS特征的映射5QI to QoS Characteristics mapping。很多初学者拿到这张表的第一反应是“这有什么好讲的不就是一堆数字吗”实际做联调、做测试、做策略配置时才会发现这张表里的每一个字段背后都牵扯着SMF怎么下发Profile、UPF怎么识别转发、gNB怎么算空口时延预算。这一篇就把这张表掰开揉碎把字段含义、分组逻辑、实操中的坑一次说清楚顺便把中英术语对照也一并整理了。1. 这张表在规范里的位置以及为什么它这么重要1.1 5.7.4节的定位QoS模型里的“出厂参数”TS 23.501的5.7节是整个5G QoS模型的骨架里面讲了三件大事QoS Flow的概念、QoS Flow与AN资源和DRBData Radio Bearer数据无线承载的映射规则、以及QoS参数本身的定义。而5.7.4这一小节专门给出了一张“标准化5QI的默认特征表”。这张表做的事情很简单给每个标准化5QI配齐一套出厂默认的QoS特征QoS Characteristics。5QI本身只是一个数字编号它自己不携带时延、优先级这些信息真正承载这些信息的是映射表里那一整行参数。换句话说5QI是钥匙QoS特征表是锁芯通信双方拿着同一个5QI才能解开同一组调度语义。我在接触5G项目初期曾经有个误区以为5QI和QCI一样只要记住“1是语音、6是视频、8是默认”就够了。实际看协议、做测试时才发现光记住业务类型远远不够真正决定一个QoS Flow会被怎么对待的是映射表里那一行的资源类型、优先级、PDB、PER这几个参数。理解这张表等于理解整个5G QoS体系的一半。1.2 为什么3GPP要标准化“5QI特征表”这套机制很多人会问既然一个QoS Flow可以携带具体的QoS参数为什么还要先定义一组标准化5QI直接信令里传具体参数不是更灵活吗理论上是这样但现实中有个很实际的问题跨厂商、跨运营商、跨终端做互通时如果各家各说各话同一个“语音通话业务”在A厂商核心网里优先级是1在B厂商里默认优先级是20那整个行业就没法协同了。于是3GPP把最常见的业务场景固化成有限个5QI每个5QI对应一套默认特征。网络侧和终端侧只需要传递一个整数双方就能对齐一整套调度诉求。这套设计还有一个巧妙之处它是“默认”而不是“强制”。也就是说如果某个场景确实需要对某个特征做定制规范允许在PDU会话建立时显式覆盖Override对应的QoS特征。这一点在实际工程里非常重要后面我在踩坑部分会专门展开。2. 5QI和QoS特征的基本概念以及四个核心字段2.1 5QI它只是索引不是调度参数本身5QI全称是5G QoS Identifier5G QoS标识符在功能上继承了4G时代的QCIQoS Class IdentifierQoS等级标识符。5QI是一个取值范围在1到127之间的整数值其中一部分是标准化值一部分留给运营商自定义。关键是理解它的性质5QI本身不具备调度语义它只是一个索引。真正被SMF、UPF、gNB读懂的是这个索引在映射表里对应的那一组QoS特征。所以当你和别人说“我这个业务用5QI3”其实是在说“请按照23.501表格里5QI3那一行的默认特征来对待这个业务”。在标准里运营商还可以使用标准化的QoS特征自己定义一个运营商专属5QIOperator-specific 5QI这种情况下5QI可能落在保留区间里网络侧需要额外配置对应的特征参数。这种自定义5QI在现网中也不少见后面会提到。2.2 四个核心成员资源类型、默认优先级、PDB、PER打开映射表每行基本都会有这么几个字段需要逐个理解清楚。Resource Type资源类型资源类型决定了一个QoS Flow是被当作GBRGuaranteed Bit Rate保证比特率业务还是Non-GBRNon-Guaranteed Bit Rate非保证比特率业务对待。GBR业务意味着网络需要为该Flow保证一定的带宽资源通常对应实时性要求高的业务Non-GBR则没有硬性带宽保证大家共享资源尽量满足。后面R16还引入了第三类Delay Critical GBR延迟关键型GBR专门服务于URLLC类超低时延场景。区分GBR和Non-GBR在实际配置中的意义很大对于GBR QoS FlowQoS Profile里必须携带GFBRGuaranteed Flow Bit Rate保证流比特率和MFBRMaximum Flow Bit Rate最大流比特率告诉网络这个Flow至少要给多少带宽、最多能用多少带宽。而Non-GBR Flow通常没有这些参数最多挂一套聚合速率限制。Default Priority Level默认优先级映射表里的优先级是一个数值规则是数值越小优先级越高。例如某个5QI的默认优先级是20另一个是80那么在拥塞或资源竞争时前者会被优先保障。但这里有个需要特别注意的细节这个“默认优先级”不等于调度器里的绝对优先级。它更像一个建议权重不同设备厂商在实现gNB调度器时会对这组数值做二次换算。所以不同厂商设备对接时同样一个5QI最终体现出来的调度行为可能会有细微差别这在跨厂商联调时是个常见讨论点。Packet Delay BudgetPDB包延迟预算PDB表示从UE到UPF之间含空口、传输、核心网处理允许的最大时延预算。比如5QI1的PDB为100ms意味着承载语音的包从UE发出到UPF接收整个路径上的时延预算不能超过100ms。PDB是“预算”不是“承诺值”。网络会把PDB作为调度约束条件gNB在空口调度时会根据PDB来分配资源但网络并不保证每个包的时延都能低于这个值。PDB越严格对调度算法的挑战越大所以才会有Delay Critical这类专门为超低PDB设计的资源类型。Packet Error RatePER包错误率PER描述的是在PDB时间窗内允许丢失的数据包比例上限。注意这个“丢包”的含义比较宽泛包括因无线链路误码导致的丢包、因调度不及时导致的晚到丢包也包括被主动丢弃的情况。PER越低说明这个业务对丢包越敏感网络需要投入更多的冗余和保护机制。举个例子5QI1的PER是10^-2意味着语音业务允许1%的包出错或丢失这对语音编解码器来说是能接受的而5QI5的PER是10^-6因为IMS信令一旦出错会造成注册、呼叫控制异常对可靠性要求极高。2.3 表里还有两个附加特征MDBV和Averaging Window除了上面四个经典字段外映射表里还会出现两个附加特征。Default Maximum Data Burst VolumeMDBV默认最大数据突发量MDBV定义了在PDB时间窗口内网络预期能够处理的最大数据突发量单位是字节。这个参数对延迟关键型GBR业务尤其重要因为URLLC场景下很多指令帧很小但要求极短的时延和极高的可靠性MDBV就是为这种突发小包设计的。比如某些5QI的MDBV被定义为160字节或320字节gNB可以根据这个值预留资源确保即使突发小包到来也能在PDB内送达。Default Averaging Window默认平均窗口平均窗口决定了GFBR和MFBR在一个多长的时间窗口内取平均值。比如语音业务的Averaging Window是2000ms意味着GBR速率的统计会被摊到2秒的窗口里而不是要求每一瞬间都精确达到GFBR。这个参数对理解速率保证的粒度很重要尤其是做速率测试时如果测试统计窗口和Averaging Window不一致测试结果会有明显偏差。2.4 表里没有ARP很多人会找错地方读这张映射表时很容易产生一个疑问怎么没有ARPAllocation and Retention Priority分配与保持优先级ARP是QoS Profile里一个重要参数它决定了一个QoS Flow在资源受限时能不能被建立、以及已建立的Flow在资源冲突时会不会被释放。但ARP并不属于“QoS特征”映射表它是在PDU会话建立或QoS Flow建立时由SMF通过信令单独下发的。所以如果你需要一个完整描述QoS Flow的参数集光读5.7.4这张表是不够的还需要结合QoS Profile里的其他字段。这一点在做信令解析时尤其容易混淆。3. 映射表的正确打开方式按资源类型分三组看3.1 GBR组语音、实时视频这类硬保障业务先看最典型的GBR组这些5QI对应呼叫、实时视频、实时游戏等业务网络需要为它们预留资源。以最常见的几个为例注意具体数值请以你所使用版本的规范正文为准我这里只用于讲解5QI1资源类型GBR默认优先级20PDB约100msPER约10^-2。这是语音会话Conversational Voice的默认选择也是VoNR里最常见的5QI。100ms的端到端时延预算对语音业务来说基本够用10^-2的PER也匹配语音编解码的容错范围。5QI2资源类型GBR默认优先级20PDB约150msPER约10^-2。对应会话类视频Conversational Video典型场景是视频通话。相比纯语音视频通话的数据量更大允许的时延也稍微放宽了一点。5QI3资源类型GBR默认优先级30PDB约50msPER约10^-3。对应实时游戏Real Time Gaming这类对时延更敏感的业务50ms的PDB明显比语音更紧张。5QI4资源类型GBR默认优先级50PDB约300msPER约10^-6。对应非会话类视频Buffered Streaming比如用户看在线视频时如果网络状况好可能会选择这类承载它的特点是时延容忍度相对高但丢包容忍度很低因为视频花屏的体验损伤非常大。这组的关键是“保证”只要网络接纳了这个Flow就必须为它预留满足GFBR要求的资源。如果资源不足网络可以拒绝建立或者触发ARP抢占流程。GBR Flow对容量规划的影响很大现网中不会无限制地为所有业务都用GBR。3.2 Non-GBR组互联网、IMS信令这类尽力而为业务Non-GBR组是现网里数量最多的承载类型普通互联网访问、即时消息、文件传输基本都在这一组。5QI5资源类型Non-GBR默认优先级10PDB约100msPER约10^-6。这是IMS信令IMS Signalling专属的5QI在Non-GBR里优先级最高因为呼叫控制信令一旦拥塞所有语音和视频业务都没法建立。5QI6资源类型Non-GBR默认优先级60PDB约300msPER约10^-6。对应视频缓冲、基于TCP的业务等服务类别。这个PDB相对宽松适合对时延不敏感但希望降低丢包的下载类业务。5QI7资源类型Non-GBR默认优先级70PDB约100msPER约10^-3。这个比较特殊PDB很紧但PER相对宽松适合语音、视频交互类业务在非GBR模式下使用。它牺牲了一定的丢包保证换取更低的时延。5QI8和5QI9资源类型Non-GBR默认优先级分别约80和90PDB约300msPER约10^-6两者都是默认承载的典型选择区别在于9的优先级更低。现网中经常把没有特别标识的普通上网流量划到8或9。这组的特点是“尽力而为”网络不为单个Flow预留带宽所有Non-GBR业务共享可用资源。资源充足时体验都不错一旦拥塞低优先级的业务就会先被牺牲。3.3 Delay Critical GBR组URLLC场景下的“新物种”R16之后映射表里多了一类资源类型Delay Critical GBR翻译过来是延迟关键型GBR。这一类的出现是为了支撑URLLCUltra-Reliable Low Latency Communication超可靠低时延通信场景典型如工厂里的运动控制、配电网的差动保护、远程手术等。延迟关键型GBR与普通GBR最大的区别在于它不仅要求保证速率还要求极端严格的时延和可靠性。比如某些5QI的PDB只有10ms甚至5msPER低到10^-5、10^-6。这个量级的时延和可靠性已经不是传统调度策略能做到的需要物理层、MAC层、核心网全链路协同优化。这类5QI还普遍配置了MDBV。为什么因为URLLC的很多业务是小包突发比如一个控制指令可能只有几十字节但它要求“必须在5ms内送达且不能丢”。有了MDBVgNB就知道在PDB内最多需要处理多少数据才能精准预留资源。需要提醒的是延迟关键型GBR的5QI编号和具体特征在不同规范版本中陆续有补充比如82到89这些编号各自对应不同的PDB、PER和MDBV组合。之前看到网上有人把某几个编号的数值直接当成全网通用实际上不同版本是有调整的这一点务必注意。4. 实操中这张表是怎么被用起来的4.1 SMF下发QoS Profile时的“取数”逻辑在实际网络里这张表最先是被SMFSession Management Function会话管理功能用起来的。当UE发起PDU会话建立请求后SMF根据签约数据、AFApplication Function应用功能的策略要求以及本地策略决定这个会话里要建立哪些QoS Flow并为每个Flow构造QoS Profile。构造Profile时SMF会先从映射表里查出对应5QI的默认特征再根据策略决定是否需要覆盖。比如核心网侧某个区域对语音业务有特殊时延要求SMF可以将PDB从表里的100ms调整为80ms并通过信令下发。gNB收到后会按照新的PDB计算空口调度预算而不是死板地套用表里的默认值。这里有个容易踩坑的地方某厂商SMF的实现里“覆盖”逻辑可能只覆盖了部分字段其他字段仍按默认值走。如果策略配置人员以为“覆盖了PDB就等于覆盖了整个特征集”就可能导致最终下发的内容和预期不一致。建议在做配置前先摸清你设备SMF的实现逻辑——哪些字段可以覆盖、哪些不支持避免想当然。4.2 测试工程师怎么利用这张表做用例设计做核心网测试或者端到端测试的兄弟对这张表的使用就更直接了。设计一个QoS相关的测试用例第一步通常就是选一个5QI然后预期对应的QoS特征。比如你想验证“GBR业务在空口拥塞时能否保证GFBR”那就要选一个GBR类的5QI比如5QI1然后构造拥塞场景观察RNISRAN Network Information Service无线接入网信息服务上报、UPF的转发速率、丢包统计是否满足预期。再比如你要做URLLC时延测试那就必须选Delay Critical GBR类的5QI并且要注意MDBV的取值。如果你选了一个不带MDBV特征的普通GBR 5QI空口调度器是不会按URLLC的预留逻辑来做的测试就没法复现出URLLC的效果。另外有个细节很多人会忽略观察QoS Flow是否建立成功时不要只看信令里有没有Indicator还要看gNB返回的响应里是否带上了AN侧的资源信息。AN侧对QoS特征的接收情况往往才是决定业务真实体验的关键。4.3 跨厂商对接时最容易出现偏差的字段跨厂商对接时优先级和PDB这两个字段最容易引发争议。默认优先级在规范里是“default”建议值具体调度算法由厂商实现。A厂商可能拿这个值直接当调度器权重B厂商可能先做一次非线性变换。所以经常出现“同一个5QI在A设备上体验很好在B设备上表现截然不同”的情况。遇到这种问题别急着怀疑映射表先跟对应厂商确认他们对优先级的实现方式。PDB也很敏感因为端到端PDB是UE空口、传输、核心网各段共享的总预算。规范里的PDB是从UE到UPF的整体约束但gNB在空口调度时只能控制空口这一段。如果传输网络时延抖动很大gNB就必须把空口预算压得很紧否则总预算就会超标。跨厂商联测时建议先约定各段时延的分配方案再对齐QoS Profile里的PDB设置否则很容易出现“核心网测出来正常、终端侧体验差”的问题。5. 逐行解读时的常见困惑和排查技巧5.1 “默认特征”不是“始终一致”抓包发现偏差先别判异常前面反复强调过映射表里给的是默认值。如果一个PDU会话建立请求里明确携带了覆盖后的PDB、PER等参数那实际生效的就是覆盖值不是表里的默认值。所以做信令分析时如果看到5QI1的会话PDB是90ms而不是100ms先别急着怀疑设备配置错误。先看QoS Profile里是否显式带了PDB字段。如果带了说明SMF做了覆盖如果没带才需要进一步排查为什么和默认值不一致。这个排查顺序能省下很多冤枉时间。5.2 优先级和PDB不是“越小越好”或“越低越好”刚开始读表时容易产生一种误解优先级越小越好PDB越低越好。实际上在资源有限的情况下优先级高的业务会获得更多资源但同时也意味着其他业务可能被牺牲。PDB过低对调度和传输都是巨大压力如果网络无法满足就会造成大量晚到丢包体验反而更差。因此选5QI的原则应该是“够用就好”而不是“越严格越高级”。语音业务用100ms没问题就别硬改成30msURLLC控制面指令用5ms合适普通视频流就不可能也不应该用这种超低时延特征。5.3 遇到映射表里没有的5QI别蒙先确认是不是运营商自定义标准化5QI只是全集的一部分还有一部分编号留给运营商自定义。如果你在一个现网抓包里看到某个5QI不在你手里的映射表里一种情况是规范版本太旧另一种情况就是运营商自定义5QI。运营商自定义5QI的特征通常会在核心网的配置里体现而不是从规范表里查。SMF侧一般会配置一个“5QI到QoS特征的映射表”或者类似的APIUPF和gNB同样需要同步配置否则这个自定义5QI在网元之间流转时其他网元可能不认识它导致调度行为异常。5.4 查5QI之前先确认你手里的规范版本这是最基础也最容易忽略的问题。5QI映射表在不同Rel版本之间并不是一成不变的。R15时代定义了基本的GBR和Non-GBR 5QIR16引入Delay Critical GBR以及对应的新5QIR17又对部分5QI的特征做了补充或微调。如果你拿着老版本的23.501去查新业务的特征必然查不到或者查到错误结果。我个人习惯是在代码注释或测试文档里标明“QoS特征值参照TS 23.501 Vxx.x.x版”。这样后续维护的人一眼就能知道基准版本不会稀里糊涂拿错表去对参数。6. 分享一个我自己维护速查表的习惯最后分享一个实操习惯维护一张本地速查表把用到的5QI按照资源类型分好组列上优先级、PDB、PER、MDBV、典型场景。平时Review代码、排查信令、设计用例时不用每次翻几百页的规范PDF先看速查表拿不准再回头查原文。表格的列我会设计成这样5QI中英文资源类型默认优先级PDBPER是否含MDBV典型场景1GBR保证比特率20100ms10^-2否语音会话VoNR2GBR20150ms10^-2否视频通话3GBR3050ms10^-3否实时游戏4GBR50300ms10^-6否非会话类视频5Non-GBR非保证比特率10100ms10^-6否IMS信令6Non-GBR60300ms10^-6否视频缓冲、TCP业务7Non-GBR70100ms10^-3否交互类音视频8Non-GBR80300ms10^-6否默认承载9Non-GBR90300ms10^-6否默认承载最低优先级82Delay Critical GBR延迟关键型GBR1910ms10^-4是URLLC离散自动化注意这张表的数值我会定期和手里的最新规范版本比对发现差异立即更新。速查表存在的意义是“方便”不是“替代原文”。万一出现争议永远以规范PDF为准。再补充一个小技巧当你在做信令解析时遇到一个QoS Flow先别急着只看5QI编号把整个QoS Profile完整拉出来看一眼。很多时候问题不是出在5QI选错了而是配套的GFBR、MFBR、ARP、Averaging Window这几个参数配置不合理。5QI决定的只是“这一类业务”的默认特征真正的业务体验往往取决于这些配套参数能不能匹配上业务模型。23.501这张表单看觉得简单真正用起来才会发现它的深度。它把千差万别的业务诉求翻译成了统一的网络参数语言让终端、基站、核心网三个域能够基于一个数字达成共识。做这个行业的手里那本规范可以旧但脑子里的这张表一定要常看常新。每次联调遇到说不清的问题我最后都会回到这张表上问一句我们真的用的是同一套默认特征吗 5QI映射表深度解析：从QoS特征到工程实践
做核心网、终端协议栈或者RAN侧调度的朋友大概率都翻过TS 23.501。每次看到第5.7节QoS模型总绕不开一张表5QI到QoS特征的映射5QI to QoS Characteristics mapping。很多初学者拿到这张表的第一反应是“这有什么好讲的不就是一堆数字吗”实际做联调、做测试、做策略配置时才会发现这张表里的每一个字段背后都牵扯着SMF怎么下发Profile、UPF怎么识别转发、gNB怎么算空口时延预算。这一篇就把这张表掰开揉碎把字段含义、分组逻辑、实操中的坑一次说清楚顺便把中英术语对照也一并整理了。1. 这张表在规范里的位置以及为什么它这么重要1.1 5.7.4节的定位QoS模型里的“出厂参数”TS 23.501的5.7节是整个5G QoS模型的骨架里面讲了三件大事QoS Flow的概念、QoS Flow与AN资源和DRBData Radio Bearer数据无线承载的映射规则、以及QoS参数本身的定义。而5.7.4这一小节专门给出了一张“标准化5QI的默认特征表”。这张表做的事情很简单给每个标准化5QI配齐一套出厂默认的QoS特征QoS Characteristics。5QI本身只是一个数字编号它自己不携带时延、优先级这些信息真正承载这些信息的是映射表里那一整行参数。换句话说5QI是钥匙QoS特征表是锁芯通信双方拿着同一个5QI才能解开同一组调度语义。我在接触5G项目初期曾经有个误区以为5QI和QCI一样只要记住“1是语音、6是视频、8是默认”就够了。实际看协议、做测试时才发现光记住业务类型远远不够真正决定一个QoS Flow会被怎么对待的是映射表里那一行的资源类型、优先级、PDB、PER这几个参数。理解这张表等于理解整个5G QoS体系的一半。1.2 为什么3GPP要标准化“5QI特征表”这套机制很多人会问既然一个QoS Flow可以携带具体的QoS参数为什么还要先定义一组标准化5QI直接信令里传具体参数不是更灵活吗理论上是这样但现实中有个很实际的问题跨厂商、跨运营商、跨终端做互通时如果各家各说各话同一个“语音通话业务”在A厂商核心网里优先级是1在B厂商里默认优先级是20那整个行业就没法协同了。于是3GPP把最常见的业务场景固化成有限个5QI每个5QI对应一套默认特征。网络侧和终端侧只需要传递一个整数双方就能对齐一整套调度诉求。这套设计还有一个巧妙之处它是“默认”而不是“强制”。也就是说如果某个场景确实需要对某个特征做定制规范允许在PDU会话建立时显式覆盖Override对应的QoS特征。这一点在实际工程里非常重要后面我在踩坑部分会专门展开。2. 5QI和QoS特征的基本概念以及四个核心字段2.1 5QI它只是索引不是调度参数本身5QI全称是5G QoS Identifier5G QoS标识符在功能上继承了4G时代的QCIQoS Class IdentifierQoS等级标识符。5QI是一个取值范围在1到127之间的整数值其中一部分是标准化值一部分留给运营商自定义。关键是理解它的性质5QI本身不具备调度语义它只是一个索引。真正被SMF、UPF、gNB读懂的是这个索引在映射表里对应的那一组QoS特征。所以当你和别人说“我这个业务用5QI3”其实是在说“请按照23.501表格里5QI3那一行的默认特征来对待这个业务”。在标准里运营商还可以使用标准化的QoS特征自己定义一个运营商专属5QIOperator-specific 5QI这种情况下5QI可能落在保留区间里网络侧需要额外配置对应的特征参数。这种自定义5QI在现网中也不少见后面会提到。2.2 四个核心成员资源类型、默认优先级、PDB、PER打开映射表每行基本都会有这么几个字段需要逐个理解清楚。Resource Type资源类型资源类型决定了一个QoS Flow是被当作GBRGuaranteed Bit Rate保证比特率业务还是Non-GBRNon-Guaranteed Bit Rate非保证比特率业务对待。GBR业务意味着网络需要为该Flow保证一定的带宽资源通常对应实时性要求高的业务Non-GBR则没有硬性带宽保证大家共享资源尽量满足。后面R16还引入了第三类Delay Critical GBR延迟关键型GBR专门服务于URLLC类超低时延场景。区分GBR和Non-GBR在实际配置中的意义很大对于GBR QoS FlowQoS Profile里必须携带GFBRGuaranteed Flow Bit Rate保证流比特率和MFBRMaximum Flow Bit Rate最大流比特率告诉网络这个Flow至少要给多少带宽、最多能用多少带宽。而Non-GBR Flow通常没有这些参数最多挂一套聚合速率限制。Default Priority Level默认优先级映射表里的优先级是一个数值规则是数值越小优先级越高。例如某个5QI的默认优先级是20另一个是80那么在拥塞或资源竞争时前者会被优先保障。但这里有个需要特别注意的细节这个“默认优先级”不等于调度器里的绝对优先级。它更像一个建议权重不同设备厂商在实现gNB调度器时会对这组数值做二次换算。所以不同厂商设备对接时同样一个5QI最终体现出来的调度行为可能会有细微差别这在跨厂商联调时是个常见讨论点。Packet Delay BudgetPDB包延迟预算PDB表示从UE到UPF之间含空口、传输、核心网处理允许的最大时延预算。比如5QI1的PDB为100ms意味着承载语音的包从UE发出到UPF接收整个路径上的时延预算不能超过100ms。PDB是“预算”不是“承诺值”。网络会把PDB作为调度约束条件gNB在空口调度时会根据PDB来分配资源但网络并不保证每个包的时延都能低于这个值。PDB越严格对调度算法的挑战越大所以才会有Delay Critical这类专门为超低PDB设计的资源类型。Packet Error RatePER包错误率PER描述的是在PDB时间窗内允许丢失的数据包比例上限。注意这个“丢包”的含义比较宽泛包括因无线链路误码导致的丢包、因调度不及时导致的晚到丢包也包括被主动丢弃的情况。PER越低说明这个业务对丢包越敏感网络需要投入更多的冗余和保护机制。举个例子5QI1的PER是10^-2意味着语音业务允许1%的包出错或丢失这对语音编解码器来说是能接受的而5QI5的PER是10^-6因为IMS信令一旦出错会造成注册、呼叫控制异常对可靠性要求极高。2.3 表里还有两个附加特征MDBV和Averaging Window除了上面四个经典字段外映射表里还会出现两个附加特征。Default Maximum Data Burst VolumeMDBV默认最大数据突发量MDBV定义了在PDB时间窗口内网络预期能够处理的最大数据突发量单位是字节。这个参数对延迟关键型GBR业务尤其重要因为URLLC场景下很多指令帧很小但要求极短的时延和极高的可靠性MDBV就是为这种突发小包设计的。比如某些5QI的MDBV被定义为160字节或320字节gNB可以根据这个值预留资源确保即使突发小包到来也能在PDB内送达。Default Averaging Window默认平均窗口平均窗口决定了GFBR和MFBR在一个多长的时间窗口内取平均值。比如语音业务的Averaging Window是2000ms意味着GBR速率的统计会被摊到2秒的窗口里而不是要求每一瞬间都精确达到GFBR。这个参数对理解速率保证的粒度很重要尤其是做速率测试时如果测试统计窗口和Averaging Window不一致测试结果会有明显偏差。2.4 表里没有ARP很多人会找错地方读这张映射表时很容易产生一个疑问怎么没有ARPAllocation and Retention Priority分配与保持优先级ARP是QoS Profile里一个重要参数它决定了一个QoS Flow在资源受限时能不能被建立、以及已建立的Flow在资源冲突时会不会被释放。但ARP并不属于“QoS特征”映射表它是在PDU会话建立或QoS Flow建立时由SMF通过信令单独下发的。所以如果你需要一个完整描述QoS Flow的参数集光读5.7.4这张表是不够的还需要结合QoS Profile里的其他字段。这一点在做信令解析时尤其容易混淆。3. 映射表的正确打开方式按资源类型分三组看3.1 GBR组语音、实时视频这类硬保障业务先看最典型的GBR组这些5QI对应呼叫、实时视频、实时游戏等业务网络需要为它们预留资源。以最常见的几个为例注意具体数值请以你所使用版本的规范正文为准我这里只用于讲解5QI1资源类型GBR默认优先级20PDB约100msPER约10^-2。这是语音会话Conversational Voice的默认选择也是VoNR里最常见的5QI。100ms的端到端时延预算对语音业务来说基本够用10^-2的PER也匹配语音编解码的容错范围。5QI2资源类型GBR默认优先级20PDB约150msPER约10^-2。对应会话类视频Conversational Video典型场景是视频通话。相比纯语音视频通话的数据量更大允许的时延也稍微放宽了一点。5QI3资源类型GBR默认优先级30PDB约50msPER约10^-3。对应实时游戏Real Time Gaming这类对时延更敏感的业务50ms的PDB明显比语音更紧张。5QI4资源类型GBR默认优先级50PDB约300msPER约10^-6。对应非会话类视频Buffered Streaming比如用户看在线视频时如果网络状况好可能会选择这类承载它的特点是时延容忍度相对高但丢包容忍度很低因为视频花屏的体验损伤非常大。这组的关键是“保证”只要网络接纳了这个Flow就必须为它预留满足GFBR要求的资源。如果资源不足网络可以拒绝建立或者触发ARP抢占流程。GBR Flow对容量规划的影响很大现网中不会无限制地为所有业务都用GBR。3.2 Non-GBR组互联网、IMS信令这类尽力而为业务Non-GBR组是现网里数量最多的承载类型普通互联网访问、即时消息、文件传输基本都在这一组。5QI5资源类型Non-GBR默认优先级10PDB约100msPER约10^-6。这是IMS信令IMS Signalling专属的5QI在Non-GBR里优先级最高因为呼叫控制信令一旦拥塞所有语音和视频业务都没法建立。5QI6资源类型Non-GBR默认优先级60PDB约300msPER约10^-6。对应视频缓冲、基于TCP的业务等服务类别。这个PDB相对宽松适合对时延不敏感但希望降低丢包的下载类业务。5QI7资源类型Non-GBR默认优先级70PDB约100msPER约10^-3。这个比较特殊PDB很紧但PER相对宽松适合语音、视频交互类业务在非GBR模式下使用。它牺牲了一定的丢包保证换取更低的时延。5QI8和5QI9资源类型Non-GBR默认优先级分别约80和90PDB约300msPER约10^-6两者都是默认承载的典型选择区别在于9的优先级更低。现网中经常把没有特别标识的普通上网流量划到8或9。这组的特点是“尽力而为”网络不为单个Flow预留带宽所有Non-GBR业务共享可用资源。资源充足时体验都不错一旦拥塞低优先级的业务就会先被牺牲。3.3 Delay Critical GBR组URLLC场景下的“新物种”R16之后映射表里多了一类资源类型Delay Critical GBR翻译过来是延迟关键型GBR。这一类的出现是为了支撑URLLCUltra-Reliable Low Latency Communication超可靠低时延通信场景典型如工厂里的运动控制、配电网的差动保护、远程手术等。延迟关键型GBR与普通GBR最大的区别在于它不仅要求保证速率还要求极端严格的时延和可靠性。比如某些5QI的PDB只有10ms甚至5msPER低到10^-5、10^-6。这个量级的时延和可靠性已经不是传统调度策略能做到的需要物理层、MAC层、核心网全链路协同优化。这类5QI还普遍配置了MDBV。为什么因为URLLC的很多业务是小包突发比如一个控制指令可能只有几十字节但它要求“必须在5ms内送达且不能丢”。有了MDBVgNB就知道在PDB内最多需要处理多少数据才能精准预留资源。需要提醒的是延迟关键型GBR的5QI编号和具体特征在不同规范版本中陆续有补充比如82到89这些编号各自对应不同的PDB、PER和MDBV组合。之前看到网上有人把某几个编号的数值直接当成全网通用实际上不同版本是有调整的这一点务必注意。4. 实操中这张表是怎么被用起来的4.1 SMF下发QoS Profile时的“取数”逻辑在实际网络里这张表最先是被SMFSession Management Function会话管理功能用起来的。当UE发起PDU会话建立请求后SMF根据签约数据、AFApplication Function应用功能的策略要求以及本地策略决定这个会话里要建立哪些QoS Flow并为每个Flow构造QoS Profile。构造Profile时SMF会先从映射表里查出对应5QI的默认特征再根据策略决定是否需要覆盖。比如核心网侧某个区域对语音业务有特殊时延要求SMF可以将PDB从表里的100ms调整为80ms并通过信令下发。gNB收到后会按照新的PDB计算空口调度预算而不是死板地套用表里的默认值。这里有个容易踩坑的地方某厂商SMF的实现里“覆盖”逻辑可能只覆盖了部分字段其他字段仍按默认值走。如果策略配置人员以为“覆盖了PDB就等于覆盖了整个特征集”就可能导致最终下发的内容和预期不一致。建议在做配置前先摸清你设备SMF的实现逻辑——哪些字段可以覆盖、哪些不支持避免想当然。4.2 测试工程师怎么利用这张表做用例设计做核心网测试或者端到端测试的兄弟对这张表的使用就更直接了。设计一个QoS相关的测试用例第一步通常就是选一个5QI然后预期对应的QoS特征。比如你想验证“GBR业务在空口拥塞时能否保证GFBR”那就要选一个GBR类的5QI比如5QI1然后构造拥塞场景观察RNISRAN Network Information Service无线接入网信息服务上报、UPF的转发速率、丢包统计是否满足预期。再比如你要做URLLC时延测试那就必须选Delay Critical GBR类的5QI并且要注意MDBV的取值。如果你选了一个不带MDBV特征的普通GBR 5QI空口调度器是不会按URLLC的预留逻辑来做的测试就没法复现出URLLC的效果。另外有个细节很多人会忽略观察QoS Flow是否建立成功时不要只看信令里有没有Indicator还要看gNB返回的响应里是否带上了AN侧的资源信息。AN侧对QoS特征的接收情况往往才是决定业务真实体验的关键。4.3 跨厂商对接时最容易出现偏差的字段跨厂商对接时优先级和PDB这两个字段最容易引发争议。默认优先级在规范里是“default”建议值具体调度算法由厂商实现。A厂商可能拿这个值直接当调度器权重B厂商可能先做一次非线性变换。所以经常出现“同一个5QI在A设备上体验很好在B设备上表现截然不同”的情况。遇到这种问题别急着怀疑映射表先跟对应厂商确认他们对优先级的实现方式。PDB也很敏感因为端到端PDB是UE空口、传输、核心网各段共享的总预算。规范里的PDB是从UE到UPF的整体约束但gNB在空口调度时只能控制空口这一段。如果传输网络时延抖动很大gNB就必须把空口预算压得很紧否则总预算就会超标。跨厂商联测时建议先约定各段时延的分配方案再对齐QoS Profile里的PDB设置否则很容易出现“核心网测出来正常、终端侧体验差”的问题。5. 逐行解读时的常见困惑和排查技巧5.1 “默认特征”不是“始终一致”抓包发现偏差先别判异常前面反复强调过映射表里给的是默认值。如果一个PDU会话建立请求里明确携带了覆盖后的PDB、PER等参数那实际生效的就是覆盖值不是表里的默认值。所以做信令分析时如果看到5QI1的会话PDB是90ms而不是100ms先别急着怀疑设备配置错误。先看QoS Profile里是否显式带了PDB字段。如果带了说明SMF做了覆盖如果没带才需要进一步排查为什么和默认值不一致。这个排查顺序能省下很多冤枉时间。5.2 优先级和PDB不是“越小越好”或“越低越好”刚开始读表时容易产生一种误解优先级越小越好PDB越低越好。实际上在资源有限的情况下优先级高的业务会获得更多资源但同时也意味着其他业务可能被牺牲。PDB过低对调度和传输都是巨大压力如果网络无法满足就会造成大量晚到丢包体验反而更差。因此选5QI的原则应该是“够用就好”而不是“越严格越高级”。语音业务用100ms没问题就别硬改成30msURLLC控制面指令用5ms合适普通视频流就不可能也不应该用这种超低时延特征。5.3 遇到映射表里没有的5QI别蒙先确认是不是运营商自定义标准化5QI只是全集的一部分还有一部分编号留给运营商自定义。如果你在一个现网抓包里看到某个5QI不在你手里的映射表里一种情况是规范版本太旧另一种情况就是运营商自定义5QI。运营商自定义5QI的特征通常会在核心网的配置里体现而不是从规范表里查。SMF侧一般会配置一个“5QI到QoS特征的映射表”或者类似的APIUPF和gNB同样需要同步配置否则这个自定义5QI在网元之间流转时其他网元可能不认识它导致调度行为异常。5.4 查5QI之前先确认你手里的规范版本这是最基础也最容易忽略的问题。5QI映射表在不同Rel版本之间并不是一成不变的。R15时代定义了基本的GBR和Non-GBR 5QIR16引入Delay Critical GBR以及对应的新5QIR17又对部分5QI的特征做了补充或微调。如果你拿着老版本的23.501去查新业务的特征必然查不到或者查到错误结果。我个人习惯是在代码注释或测试文档里标明“QoS特征值参照TS 23.501 Vxx.x.x版”。这样后续维护的人一眼就能知道基准版本不会稀里糊涂拿错表去对参数。6. 分享一个我自己维护速查表的习惯最后分享一个实操习惯维护一张本地速查表把用到的5QI按照资源类型分好组列上优先级、PDB、PER、MDBV、典型场景。平时Review代码、排查信令、设计用例时不用每次翻几百页的规范PDF先看速查表拿不准再回头查原文。表格的列我会设计成这样5QI中英文资源类型默认优先级PDBPER是否含MDBV典型场景1GBR保证比特率20100ms10^-2否语音会话VoNR2GBR20150ms10^-2否视频通话3GBR3050ms10^-3否实时游戏4GBR50300ms10^-6否非会话类视频5Non-GBR非保证比特率10100ms10^-6否IMS信令6Non-GBR60300ms10^-6否视频缓冲、TCP业务7Non-GBR70100ms10^-3否交互类音视频8Non-GBR80300ms10^-6否默认承载9Non-GBR90300ms10^-6否默认承载最低优先级82Delay Critical GBR延迟关键型GBR1910ms10^-4是URLLC离散自动化注意这张表的数值我会定期和手里的最新规范版本比对发现差异立即更新。速查表存在的意义是“方便”不是“替代原文”。万一出现争议永远以规范PDF为准。再补充一个小技巧当你在做信令解析时遇到一个QoS Flow先别急着只看5QI编号把整个QoS Profile完整拉出来看一眼。很多时候问题不是出在5QI选错了而是配套的GFBR、MFBR、ARP、Averaging Window这几个参数配置不合理。5QI决定的只是“这一类业务”的默认特征真正的业务体验往往取决于这些配套参数能不能匹配上业务模型。23.501这张表单看觉得简单真正用起来才会发现它的深度。它把千差万别的业务诉求翻译成了统一的网络参数语言让终端、基站、核心网三个域能够基于一个数字达成共识。做这个行业的手里那本规范可以旧但脑子里的这张表一定要常看常新。每次联调遇到说不清的问题我最后都会回到这张表上问一句我们真的用的是同一套默认特征吗