1. 从一个掉话案例说起SRB与DRB到底在干什么刚入行做网优那会儿我最怕听到的一句话就是“用户投诉打电话掉线、上网断流”。后台一查信令十有八九能看到SRB或者DRB相关的异常。很多人对这两个缩写的理解停留在“信令承载”和“数据承载”这种教科书式的定义上但真到了排查现场光知道定义根本不够用。你得清楚一条UE从开机到能刷视频中间SRB1、SRB2、DRB这三条“管道”是怎么一步步搭起来的哪一步卡住了会出什么现象这才算真正摸到了门道。这篇内容我打算把LTE里SRB和DRB承载建立这件事从头到尾捋一遍。核心关键词就是SRBSignalling Radio Bearer信令无线承载和DRBData Radio Bearer数据无线承载围绕它们的建立流程、参数配置、信令交互、常见故障来展开。适合刚接触LTE信令分析的网优新人也适合做了几年但一直没系统梳理过承载建立全流程的老手。我会尽量用大白话把3GPP那套流程讲清楚配上实际排查中踩过的坑和验证过的参数取值让你看完能直接拿去对照日志分析问题。先说结论性的认知SRB是UE和基站之间传“指令”的通道DRB是传“货物”的通道。没有SRBUE连入网的门都进不去没有DRB用户能注册上但上不了网。两者建立的先后顺序、触发条件、参数约束构成了整个LTE连接建立的核心骨架。理解了这套骨架你看任何一条RRC信令都能迅速定位它在整个流程中的位置。2. 承载体系全景拆解SRB和DRB的角色分工2.1 为什么LTE要设计两种承载这个问题得从LTE的设计哲学说起。LTE把控制面和用户面彻底分开了控制面走信令用户面走数据两者对传输的要求完全不同。信令的特点是量小但要求绝对可靠丢一个包可能导致整个流程失败数据的特点是量大且对时延敏感偶尔丢几个包靠重传就能补回来。如果混在一条承载上传要么信令被大数据包堵住要么为了保信令可靠而牺牲数据效率。所以3GPP干脆设计了SRB专门跑信令DRB专门跑数据各司其职。SRB又细分为SRB0、SRB1、SRB2三条。SRB0是“默认通道”UE还没跟网络建立任何专属关系时就用它走的是CCCH逻辑信道传的是RRC连接请求这类最基础的消息。SRB1是第一条专属信令通道走DCCH逻辑信道RRC连接建立完成后就有了后续的RRC重配、安全模式命令都走它。SRB2是在安全激活之后才建立的用来传NAS层信令优先级比SRB1低因为它的消息没那么紧急。DRB则是用户面通道可以有多个每个对应一个EPS承载承载不同的QoS业务。2.2 SRB0/SRB1/SRB2的建立时序与触发条件这三条SRB不是同时建立的有严格的先后顺序。UE开机后先做小区搜索和随机接入然后在SRB0上发RRCConnectionRequest。基站收到后如果同意接入就回RRCConnectionSetup这条消息里包含了SRB1的配置。UE收到后应用配置在SRB1上回RRCConnectionSetupComplete这时候SRB1就算建好了。注意SRB1建立时还没有加密和完整性保护因为安全模式还没走。接下来基站会发起SecurityModeCommandUE回SecurityModeComplete这一步激活了AS层的加密和完整性保护。安全激活之后基站才会在RRCConnectionReconfiguration里带上SRB2的配置UE应用后回RRCConnectionReconfigurationCompleteSRB2建立完成。SRB2建立的前提是安全已激活这是硬性约束因为SRB2上要传NAS信令必须加密。注意SRB2的建立不是必须的。如果UE只是做紧急呼叫或者某些特定场景网络可能不配置SRB2。但在正常入网流程中SRB2基本都会建立。2.3 DRB的建立时机与承载映射关系DRB的建立时机比较灵活可以在初始上下文建立时一起配也可以在后续需要时通过RRCConnectionReconfiguration单独添加。典型流程是UE通过SRB1完成Attach RequestMME收到后发起Initial Context Setup Request基站据此在RRCConnectionReconfiguration里同时配置SRB2和DRB。UE应用后回RRCConnectionReconfigurationCompleteDRB建立完成用户面数据就可以开始传了。DRB和EPS承载是一一对应的。一个EPS承载有明确的QoS参数QCI、GBR、AMBR等基站根据这些参数决定DRB的PDCP、RLC、MAC层配置。比如QCI1的语音承载RLC模式通常配UM非确认模式因为语音对时延敏感重传反而有害QCI9的普通数据承载RLC配AM确认模式保证可靠性。这种映射关系是网优必须掌握的配错了直接导致业务体验下降。承载类型逻辑信道传输内容建立时机安全要求SRB0CCCHRRC连接请求/建立随机接入后无SRB1DCCHRRC信令RRC连接建立建立时无后续激活SRB2DCCHNAS信令安全激活后必须加密DRBDTCH用户数据初始上下文建立或后续重配必须加密3. 信令流程逐条拆解从RRC连接请求到DRB就绪3.1 随机接入与SRB0上的第一条消息UE要发RRCConnectionRequest前提是先完成随机接入。随机接入分竞争和非竞争两种初始接入走竞争模式。UE在PRACH上发前导码基站回RARRandom Access Response里面带TA调整量和上行授权。UE拿到授权后在PUSCH上发RRCConnectionRequest这条消息走SRB0逻辑信道是CCCHRLC模式是TM透明模式因为这时候还没有任何RLC实体配置。RRCConnectionRequest里最关键的是UE身份标识和建立原因。身份标识可能是S-TMSI如果UE之前注册过或随机数首次接入。建立原因决定了基站后续的处理策略比如mo-Signalling表示UE要发信令mo-Data表示要发数据mt-Access表示响应寻呼。这个原因值在排查时很有用如果看到大量mt-Access失败可能是寻呼配置有问题。3.2 RRC连接建立与SRB1配置解析基站收到RRCConnectionRequest后如果决定接纳就回RRCConnectionSetup。这条消息里包含radioResourceConfigDedicated其中srb-ToAddModList就是SRB1的配置。SRB1的配置相对固定逻辑信道标识固定为1RLC模式为AMPDCP需要配置SN长度通常12bit和头压缩协议ROHC可选。基站还会分配初始的MAC层参数比如BSR配置、PHR配置等。UE收到RRCConnectionSetup后应用配置并回RRCConnectionSetupComplete。这条消息走SRB1里面携带了NAS层的Attach Request或Service Request。从这一刻起SRB1正式可用后续所有RRC信令都走SRB1。这里有个细节RRCConnectionSetupComplete里还带了UE的PLMN选择和注册的MME信息如果这些信息跟基站预期不符可能导致后续流程失败。3.3 安全模式激活SRB2建立的前置条件安全模式激活是承载建立流程中的一个关键转折点。基站发SecurityModeCommand里面包含加密算法和完整性保护算法。UE收到后根据自身能力和网络配置选择算法回SecurityModeComplete。这一步完成后AS层的加密和完整性保护就生效了。注意SecurityModeCommand本身是完整性保护但未加密的SecurityModeComplete是既加密又完整性保护的。安全激活之后SRB2才能建立。为什么因为SRB2上要传NAS信令NAS信令包含用户身份、位置等敏感信息必须加密。如果安全没激活就建SRB2等于把用户隐私暴露在空中接口上。所以3GPP规定SRB2的建立必须在安全模式完成之后。实际排查中如果看到SRB2建立失败先检查SecurityModeComplete有没有正常发出和收到。3.4 RRC重配与DRB添加的完整参数树DRB的添加通常通过RRCConnectionReconfiguration消息下发。这条消息里drb-ToAddModList包含了DRB的完整配置包括drb-IdentityDRB标识取值1-32必须唯一pdcp-ConfigPDCP层配置包括SN长度、ROHC、discardTimer等rlc-ConfigRLC层配置包括AM/UM模式、SN长度、重传参数等logicalChannelIdentity逻辑信道标识取值3-100-2被SRB占用logicalChannelConfig逻辑信道优先级、PBR、BSD等这些参数不是随便配的要根据QCI来推导。比如QCI1的语音承载PDCP SN长度通常12bitRLC用UMdiscardTimer设100msQCI9的网页浏览PDCP SN长度12bitRLC用AMdiscardTimer设无穷大。配错了会导致吞吐量下降或时延增加。UE收到RRCConnectionReconfiguration后应用配置并回RRCConnectionReconfigurationComplete。这条消息走SRB1表示DRB配置已生效。从这一刻起用户面数据可以在DRB上传输了。4. 参数配置实战从QCI到DRB参数的映射逻辑4.1 QCI与DRB参数的对应关系QCI是EPS承载的核心QoS参数定义了业务的优先级、时延预算、丢包率等。基站根据QCI来决定DRB的PDCP、RLC、MAC层配置。下面这张表是我在实际配置中总结的常用映射关系QCI业务类型PDCP SNRLC模式RLC SNdiscardTimer逻辑信道优先级1语音12bitUM5bit100ms22视频通话12bitUM5bit150ms35IMS信令12bitAM10bit无穷17视频流12bitAM10bit300ms49普通数据12bitAM10bit无穷5这张表不是死的不同设备商可能有细微差异但大方向一致。核心逻辑是时延敏感的业务用UM避免重传引入额外时延可靠性要求高的业务用AM保证数据不丢。discardTimer的设置也很讲究设太短会导致包还没传完就被丢弃设太长会导致拥塞时旧包占用资源。4.2 逻辑信道优先级与调度策略逻辑信道优先级LCP决定了MAC层在有限的上行授权下优先传哪个逻辑信道的数据。SRB1的优先级最高因为信令不能等SRB2次之然后是DRB按QCI排序。实际配置中SRB1的PBRPrioritised Bit Rate通常设无限大BSDBucket Size Duration也设很大确保信令随时能发。DRB的PBR和BSD要根据GBR和AMBR来算。比如一个GBR承载PBR至少设成GBR值BSD设成GBR乘以典型时延。非GBR承载的PBR可以设小一点靠动态调度来满足。这里有个经验PBR设得太小会导致低优先级业务饿死设得太大又会导致高优先级业务被挤占。我一般建议PBR按QCI的典型速率来设BSD设成PBR的2-3倍。4.3 参数配置的常见误区与验证方法最常见的误区是PDCP SN长度和RLC SN长度不匹配。PDCP SN是12bitRLC SN是10bit这是标准配置。但有人为了追求低时延把PDCP SN改成7bit结果导致重排序窗口太小高速场景下频繁触发重传。还有人把RLC UM模式的SN设成5bit结果语音业务在弱覆盖下丢包率飙升。验证参数配置是否正确最直接的方法是抓空口日志看RRCConnectionReconfiguration里的实际取值。另一个方法是做业务验证语音业务看MOS分和时延数据业务看吞吐量和时延。如果MOS分低于3.5先检查RLC模式是不是配成了AM如果吞吐量上不去检查PDCP SN长度和discardTimer。提示参数配置没有“万能值”必须结合具体场景调整。密集城区和农村广覆盖的参数策略完全不同前者重容量后者重覆盖。5. 典型故障排查实录SRB/DRB建立失败的六种场景5.1 SRB1建立失败RRCConnectionSetupComplete未收到这是最常见的接入失败场景。现象是基站发了RRCConnectionSetup但没收到RRCConnectionSetupCompleteUE侧显示接入失败。排查思路分三步先看空口质量RSRP和SINR是否满足解调要求再看随机接入是否成功Msg3的TA是否合理最后看基站侧是否收到了Msg5但解码失败。我遇到过一种情况UE发了RRCConnectionSetupComplete但基站侧解码失败原因是UE的发射功率不足。这时候要检查preambleInitialReceivedTargetPower和powerRampingStep配置确保UE有足够的功率爬升空间。还有一种情况是Msg4的竞争解决没完成UE认为随机接入失败根本没发Msg5。5.2 SRB2建立失败安全模式未完成SRB2建立失败通常伴随SecurityModeComplete丢失。排查时先看SecurityModeCommand是否发出再看UE是否回了SecurityModeComplete。如果UE没回可能是UE不支持网络选择的加密算法。这时候要检查UE能力上报里的加密算法列表确保网络选择的算法在UE支持范围内。另一种情况是SecurityModeComplete发了但基站没收到原因可能是空口质量差导致解码失败。这时候要结合上行BLER来判断如果BLER高于10%基本可以确定是覆盖问题。解决办法是调整天线倾角或功率改善上行覆盖。5.3 DRB建立失败RRC重配未完成DRB建立失败的现象是基站发了RRCConnectionReconfiguration但没收到RRCConnectionReconfigurationComplete。排查时先看这条消息里是否同时包含了SRB2和DRB的配置如果SRB2配置有问题UE可能直接忽略整条消息。再看DRB参数是否合法比如逻辑信道标识是否冲突、RLC SN长度是否超出范围。我踩过一个坑DRB的logicalChannelIdentity配成了2跟SRB2冲突了。UE收到后直接认为配置非法回了RRCConnectionReconfigurationFailure。后来查3GPP 36.331才知道逻辑信道标识0-2是预留给SRB的DRB只能用3-10。这种低级错误在手工配置时很容易犯现在我都用工具自动校验。5.4 承载建立成功但业务不通用户面配置问题有时候信令流程全走通了SRB和DRB都建好了但用户就是上不了网。这时候要查用户面配置GTP-U隧道是否建立、TEID是否匹配、S1-U接口是否正常。我遇到过S1-U的TEID配错的情况基站和SGW各说各话数据包全丢了。排查方法是抓S1-U接口的GTP-U报文看TEID是否一致。还有一种情况是DRB的QoS参数跟核心网下发的EPS承载QoS不匹配。比如核心网要求QCI1基站配成了QCI9结果语音业务被当成数据业务调度时延飙到几百毫秒。这种问题在跨厂商组网时特别常见因为不同厂商对QCI的理解可能有偏差。5.5 常见问题速查表故障现象可能原因排查方法解决措施RRCConnectionSetupComplete未收到覆盖差、功率不足、竞争解决失败查RSRP/SINR、查Msg3 TA、查Msg4调整功率参数、优化覆盖SecurityModeComplete未收到算法不匹配、空口解码失败查UE能力、查上行BLER调整算法优先级、改善覆盖RRCConnectionReconfigurationComplete未收到参数非法、SRB2配置冲突查逻辑信道标识、查RLC参数修正参数、重新配置承载建立但业务不通TEID不匹配、QoS不匹配抓S1-U报文、对比QoS参数修正TEID、对齐QoSSRB2建立失败安全未激活、SRB2配置缺失查SecurityMode流程、查RRC重配确保安全先激活DRB建立失败逻辑信道冲突、PDCP/RLC参数错误查logicalChannelIdentity、查SN长度修正参数、自动校验5.6 独家避坑技巧第一个技巧抓信令时一定要同时抓空口和S1接口单看一侧很容易误判。比如空口看到RRCConnectionReconfigurationComplete发了但S1接口看到Initial Context Setup Response没回问题就在基站内部处理。第二个技巧排查承载建立问题时先确认UE侧的信令日志。UE侧日志能看到基站看不到的信息比如UE为什么没回某条消息。我习惯用QXDM或者类似工具抓UE侧日志跟基站侧日志对齐时间戳两边一对比问题基本就定位了。第三个技巧参数配置变更后一定要做回归测试。我见过太多“改了一个参数导致全网接入失败”的案例。变更前先在实验室验证变更后先在小范围试点确认没问题再推广。6. 进阶话题双连接与载波聚合下的承载管理6.1 双连接场景下的SRB/DRB分布在双连接EN-DC或NR-DC场景下SRB和DRB的分布变得更复杂。SRB通常锚定在MeNB主基站保证信令的稳定性DRB可以分流到SgNB辅基站提升吞吐量。这时候承载建立流程涉及两个基站的协调X2/Xn接口的信令交互成为关键。实际排查中双连接下的承载建立失败往往出在X2接口。比如SgNB Addition Request发了但没收到Response或者Response里带的DRB配置跟MeNB预期不符。这时候要抓X2接口的信令看两个基站之间的参数协商是否一致。我遇到过SgNB不支持某个QCI的情况导致DRB建立失败后来在MeNB侧做了QCI映射才解决。6.2 载波聚合下的逻辑信道映射载波聚合场景下逻辑信道到传输载波的映射需要额外配置。SRB通常映射到主载波保证信令的可靠性DRB可以映射到辅载波利用更大的带宽。配置时要注意逻辑信道优先级和载波容量的匹配避免高优先级业务被映射到容量小的载波上。这里有个经验载波聚合下的DRB建立失败很多时候是因为辅载波的配置没同步。比如辅载波还没激活基站就急着配DRB映射到辅载波结果UE侧无法应用配置。解决办法是先激活辅载波再配DRB映射。这个顺序在3GPP里没有强制规定但实际实现中必须遵守。6.3 未来演进方向与兼容性考量从LTE到5G NR承载体系的基本框架没变但细节有差异。NR的SRB增加了SRB3用于在SgNB上直接传RRC信令DRB的QoS模型从QCI演进到5QI参数更丰富。做LTE网优的人转做NR时这些差异要特别注意。兼容性方面LTE和NR的互操作要求承载能平滑切换。比如UE从LTE切换到NR时SRB和DRB的配置要能无缝迁移。这要求两个制式的参数配置保持一致否则切换时会出现承载重建失败。我在实际测试中遇到过LTE的PDCP SN是12bitNR的PDCP SN是18bit切换时PDCP实体需要重配如果配置不当会导致数据丢失。提示做互操作测试时重点验证承载切换的完整性和数据连续性。建议用FTP下载业务做背景切换过程中观察速率是否掉零。7. 个人实操体会与建议干了这么多年网优我对SRB和DRB承载建立最大的体会是信令流程是骨架参数配置是血肉故障排查是灵魂。骨架搭不好后面全白搭血肉配不对业务体验差灵魂不到位问题永远找不到根因。给新人的建议是先把3GPP 36.331和36.323这两份规范啃透特别是RRCConnectionReconfiguration和PDCP/RLC的配置部分。规范看起来枯燥但每一条都有实际意义。我当年就是靠反复读规范才搞懂了为什么SRB2必须在安全激活后建立为什么RLC UM模式不适合传信令。给老手的建议是别迷信经验多动手验证。我见过太多人凭经验配参数结果在新场景下翻车。每次配置变更前先在实验室用UE模拟器跑一遍完整流程确认没问题再上现网。现网变更时先选一个基站试点观察24小时再推广。最后分享一个小技巧排查承载建立问题时养成“从后往前”的习惯。先看业务是否通再看DRB是否建好再看SRB是否建好最后看随机接入是否成功。这样能快速缩小问题范围避免在无关的环节浪费时间。我靠这个方法把平均故障定位时间从2小时缩短到了30分钟以内。这个领域还有很多细节值得深挖比如不同厂商对3GPP规范的实现差异、特定场景下的参数优化、自动化配置工具的开发等。后续有机会再跟大家分享。
区域求和原理与工程实践)
