企业官网建设流程全解析

1. 从一个掉话案例说起：SRB与DRB到底在干什么

刚入行做网优那会儿，我最怕听到的一句话就是“用户投诉打电话掉线、上网断流”。后台一查信令，十有八九能看到SRB或者DRB相关的异常。很多人对这两个缩写的理解停留在“信令承载”和“数据承载”这种教科书式的定义上，但真到了排查现场，光知道定义根本不够用。你得清楚一条UE从开机到能刷视频，中间SRB1、SRB2、DRB这三条“管道”是怎么一步步搭起来的，哪一步卡住了会出什么现象，这才算真正摸到了门道。

这篇内容我打算把LTE里SRB和DRB承载建立这件事从头到尾捋一遍。核心关键词就是SRB（Signalling Radio Bearer，信令无线承载）和DRB（Data Radio Bearer，数据无线承载），围绕它们的建立流程、参数配置、信令交互、常见故障来展开。适合刚接触LTE信令分析的网优新人，也适合做了几年但一直没系统梳理过承载建立全流程的老手。我会尽量用大白话把3GPP那套流程讲清楚，配上实际排查中踩过的坑和验证过的参数取值，让你看完能直接拿去对照日志分析问题。

先说结论性的认知：SRB是UE和基站之间传“指令”的通道，DRB是传“货物”的通道。没有SRB，UE连入网的门都进不去；没有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建立时还没有加密和完整性保护，因为安全模式还没走。

接下来基站会发起SecurityModeCommand，UE回SecurityModeComplete，这一步激活了AS层的加密和完整性保护。安全激活之后，基站才会在RRCConnectionReconfiguration里带上SRB2的配置，UE应用后回RRCConnectionReconfigurationComplete，SRB2建立完成。SRB2建立的前提是安全已激活，这是硬性约束，因为SRB2上要传NAS信令，必须加密。

注意：SRB2的建立不是必须的。如果UE只是做紧急呼叫或者某些特定场景，网络可能不配置SRB2。但在正常入网流程中，SRB2基本都会建立。

2.3 DRB的建立时机与承载映射关系

DRB的建立时机比较灵活，可以在初始上下文建立时一起配，也可以在后续需要时通过RRCConnectionReconfiguration单独添加。典型流程是：UE通过SRB1完成Attach Request，MME收到后发起Initial Context Setup Request，基站据此在RRCConnectionReconfiguration里同时配置SRB2和DRB。UE应用后回RRCConnectionReconfigurationComplete，DRB建立完成，用户面数据就可以开始传了。

DRB和EPS承载是一一对应的。一个EPS承载有明确的QoS参数（QCI、GBR、AMBR等），基站根据这些参数决定DRB的PDCP、RLC、MAC层配置。比如QCI=1的语音承载，RLC模式通常配UM（非确认模式），因为语音对时延敏感，重传反而有害；QCI=9的普通数据承载，RLC配AM（确认模式），保证可靠性。这种映射关系是网优必须掌握的，配错了直接导致业务体验下降。

3. 信令流程逐条拆解：从RRC连接请求到DRB就绪

3.1 随机接入与SRB0上的第一条消息

UE要发RRCConnectionRequest，前提是先完成随机接入。随机接入分竞争和非竞争两种，初始接入走竞争模式。UE在PRACH上发前导码，基站回RAR（Random Access Response），里面带TA调整量和上行授权。UE拿到授权后在PUSCH上发RRCConnectionRequest，这条消息走SRB0，逻辑信道是CCCH，RLC模式是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的配置相对固定：逻辑信道标识固定为1，RLC模式为AM，PDCP需要配置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-Identity：DRB标识，取值1-32，必须唯一
• pdcp-Config：PDCP层配置，包括SN长度、ROHC、discardTimer等
• rlc-Config：RLC层配置，包括AM/UM模式、SN长度、重传参数等
• logicalChannelIdentity：逻辑信道标识，取值3-10（0-2被SRB占用）
• logicalChannelConfig：逻辑信道优先级、PBR、BSD等

这些参数不是随便配的，要根据QCI来推导。比如QCI=1的语音承载，PDCP SN长度通常12bit，RLC用UM，discardTimer设100ms；QCI=9的网页浏览，PDCP SN长度12bit，RLC用AM，discardTimer设无穷大。配错了会导致吞吐量下降或时延增加。

UE收到RRCConnectionReconfiguration后，应用配置并回RRCConnectionReconfigurationComplete。这条消息走SRB1，表示DRB配置已生效。从这一刻起，用户面数据可以在DRB上传输了。

4. 参数配置实战：从QCI到DRB参数的映射逻辑

4.1 QCI与DRB参数的对应关系

QCI是EPS承载的核心QoS参数，定义了业务的优先级、时延预算、丢包率等。基站根据QCI来决定DRB的PDCP、RLC、MAC层配置。下面这张表是我在实际配置中总结的常用映射关系：

这张表不是死的，不同设备商可能有细微差异，但大方向一致。核心逻辑是：时延敏感的业务用UM，避免重传引入额外时延；可靠性要求高的业务用AM，保证数据不丢。discardTimer的设置也很讲究，设太短会导致包还没传完就被丢弃，设太长会导致拥塞时旧包占用资源。

4.2 逻辑信道优先级与调度策略

逻辑信道优先级（LCP）决定了MAC层在有限的上行授权下，优先传哪个逻辑信道的数据。SRB1的优先级最高，因为信令不能等；SRB2次之；然后是DRB，按QCI排序。实际配置中，SRB1的PBR（Prioritised Bit Rate）通常设无限大，BSD（Bucket 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是12bit，RLC 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，但没收到RRCConnectionSetupComplete，UE侧显示接入失败。排查思路分三步：先看空口质量，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不匹配。比如核心网要求QCI=1，基站配成了QCI=9，结果语音业务被当成数据业务调度，时延飙到几百毫秒。这种问题在跨厂商组网时特别常见，因为不同厂商对QCI的理解可能有偏差。

5.5 常见问题速查表

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是12bit，NR的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规范的实现差异、特定场景下的参数优化、自动化配置工具的开发等。后续有机会再跟大家分享。