企业官网建设流程全解析

简介：这是面向4G/5G网络优化工程师的VoLTE排障案例，聚焦IMS返回503 ServiceUnavailable并导致用户从5G回落到4G的典型问题。文档从拉网测试中部分手机呼叫失败出发，完整呈现了排障流程：先跟踪基站侧trace，发现核心网E-RAB SETUP REQUEST中上行请求最大带宽为88kbps，超过基站配置的52kbps上限，从而回传Radio-resource-not-available；再经信令确认被叫侧R6y日志中的max-requested-bandwidth-ul为88000，同时SBC将主叫侧INVITE中的SDP带宽由49kbps改写为80kbps（因配置G711编解码重算），导致专用承载建立失败。针对该根因，文档给出了华为SBC BCPLC中设置信任终端媒体带宽为否、确保编解码转换后转发INVITE不改变带宽，以及针对多方通话等高带宽业务将基站QCI1带宽提升至200kbps等具体调整方案，并附有信令参数与关键配置截图，便于实际作业时对照实施。资源为1个docx文档，大小129KB，内容聚焦无冗余。已有406人学习下载，适合从事5G语音优化、核心网与无线侧协同排障的工程师查阅。

1. 5G网优案例：IMS直接报503 ServiceUnavailable，用户掉到4G

拉网测试最怕的就是这种场景：手机明明显示5G满格，VoLTE呼叫却直接失败，主叫侧收到503 ServiceUnavailable，信令里写着media bearer lost，用户还没反应过来，手机已经悄悄掉到4G。这个案例我在多个项目里见过类似变种，根因不是核心网挂了，也不是基站故障，而是SBC申请带宽超出基站配置上限，导致专用承载建立失败。对一线网优工程师来说，这类问题如果不顺着信令逐跳排查，很容易在E-RAB建立失败这一步就下了错误结论。这篇笔记会把完整的定位思路、参数对应关系和修复方案拆开讲透，尤其适合刚接触VoLTE承载优化的从业者照着复现。

2. 为什么是503而不是其他错误：VoLTE呼叫流程与承载建立链路

2.1 VoLTE呼叫建立：从INVITE到专用承载的四次握手

VoLTE呼叫不是手机到手机直连，而是手机通过基站接入，再经过IMS核心网完成呼叫控制。整个过程中，QCI1专用承载的建立是关键。主叫发起INVITE请求后，IMS核心网侧的SBC会与被叫侧完成SDP协商，随后通过Rx接口向PCRF发起AAR请求，PCRF再通过Gx接口通知PGW建立专用承载。PGW向基站发送E-RAB SETUP REQUEST，基站为这条承载分配空口资源，如果分配成功就返回E-RAB SETUP RESPONSE，承载建立完成，VoLTE呼叫才能继续。

整个链路可以简化成下面这张流程对应关系：

手机 -- RRC -- 基站(enodeb) -- S1-U/S1-MME -- PGW -- Rx -- PCRF -- AAR -- SBC

呼叫失败时，随手抓一条信令，看是卡在E-RAB建立前的哪一步。

这个链路里最容易出问题的节点有三个：SBC的SDP带宽重算、PCRF与PGW之间的策略下发、基站侧的空口资源分配。本案例的问题出在最后一个节点，根因却在第一个节点。如果不把整条链路拆开看，只盯基站告警，大概率会做成"调高基站带宽、问题暂时消失、下次换个场景又复发"的无用功。

2.2 503 ServiceUnavailable在VoLTE里的真实含义

503 ServiceUnavailable在HTTP协议里表示服务器暂时无法处理请求，在VoLTE信令里，这个错误码由IMS核心网返回，通常意味着媒体面资源没有准备好。具体到这个案例，错误原因值携带的是media bearer lost，说明QCI1专用承载在建立过程中丢失或被释放。

常规情况下，VoLTE呼叫失败返回的错误码还有480 Temporarily Unavailable、486 Busy Here、580 Precondition Failure等，各自对应的场景完全不同。480偏向被叫不可达，486是用户忙，580多与SDP预条件不满足有关。而503加上media bearer lost，基本锁定在媒体承载建立这条路线上，需要重点排查空口资源、核心网策略和SBC带宽计算这三个环节。

排查时可以做一个快速分流，用wireshark打开抓包文件，只看E-RAB相关消息：

# 在wireshark里过滤E-RAB建立相关的Diameter消息 diameter && (diam.cmd.code == 232 || diam.cmd.code == 231)

过滤结果中，重点看E-RAB SETUP REQUEST和E-RAB SETUP RESPONSE这一对消息。

E-RAB SETUP REQUEST里携带的是核心网期望建立的承载参数，包括QCI、ARP、上下行带宽等。E-RAB SETUP RESPONSE如果携带失败原因值，说明基站侧拒绝了承载建立，这时要立刻展开响应消息里的Cause字段，看具体是Radio-resource-not-available还是其他原因。这一步是整个排查的分水岭，原因值不同，接下来往哪个方向查完全不同。

2.3 承载建立失败：E-RAB SETUP RESPONSE里的失败原因值

本案例在E-RAB SETUP RESPONSE消息里携带的是Radio-resource-not-available，直译过来就是空口资源不可用。很多人看到这个原因值，第一反应是基站资源不足，直接去查小区用户数和PRB利用率。但查了半天，用户数不高，PRB利用率也不满，问题依然复现，这就说明根本不是真的资源不足，而是请求的资源规格超出了基站允许的范围。

一个典型的信令展示如下：

E-RAB SETUP RESPONSE E-RAB ID: 1 E-RAB Setup Failed List Cause: Radio-resource-not-available E-RAB Setup List: (0 items)

基站返回这个原因值的常见触发条件有三个：一是小区上行干扰过高导致可用PRB减少，二是请求的GBR带宽超过了基站侧配置的最大带宽，三是QCI1承载数超过小区配置上限。本案例属于第二种，核心网请求的带宽是88kbps，基站配置的上下行最大带宽只有52kbps，那么无论小区有多空闲，基站都会拒绝这条承载。这种"配置型资源不足"在信令上看不出小区拥塞痕迹，只能靠对比请求值和配置值来定位，这也是很多测试工程师在这个问题上反复卡壳的原因。

3. 信令链路逐跳拆解：从E-RAB SETUP REQUEST到Radio-resource-not-available

3.1 基站侧Trace：为什么请求带宽88kbps被拒

打开基站侧Trace，找到核心网发给基站的E-RAB SETUP REQUEST消息，里面有一条关键字段：上行请求最大带宽max-requested-bandwidth-ul。这个值以bps为单位，案例中显示为0x157c0，换算成十进制是88000，也就是88kbps。

E-RAB SETUP REQUEST e-RAB ID: 1 qCI: 1 e-RAB Level QoS Parameters gbr-UL: 88000 gbr-DL: 88000 maxRequestedBandwidth-UL: 88000 maxRequestedBandwidth-DL: 88000

这三个参数需要分开理解。GBR是保证比特率，VoLTE语音一般不会太高；maxRequestedBandwidth是最大请求带宽，理论上应该覆盖编码器峰值速率加IP/RTP/UDP头开销。案例里GBR和maxRequestedBandwidth都是88000，说明核心网给出的规格偏高，超出了基站配置。

对照基站侧配置，该小区上下行最大带宽均为52kbps。这个配置值通常是基站侧针对QCI1承载设置的Max Authorized Bandwidth参数。当请求值大于配置值时，基站的准入控制逻辑直接判定不满足条件，返回Radio-resource-not-available，过程短平快，不涉及任何拥塞判断。

基站日志里能看到对应的拒绝记录，搜索关键字时可以关注以下字段：

# 基站的实时日志，按E-RAB建立失败过滤 tail -f log/gcell_erab.log | grep -i "radio-resource-not-available"

如果日志里同时出现了请求带宽和配置带宽的对比输出，马上能看到88和52的差异。这一步基本就能确认到底是不是配置型拒绝。

3.2 52kbps从哪里来：基站侧QCI1带宽配置逻辑

很多现场工程师会有疑问：VoLTE带宽需求不是固定的吗？为什么基站要限制在52kbps？这个值通常和现场采用的语音编码策略有关。如果部署的是AMR-NB，带宽需求相对较小；如果部署了AMR-WB或EVS，带宽需求会明显上升。

实际规划时应按以下逻辑设定基站的最大授权带宽：

单路语音总带宽 ≈ 编码器速率 + RTP头开销 + IP头开销 + 传输开销

以AMR-WB 23.85kbps为例，加上RoHC未开启时的IP/RTP/UDP头开销，单路承载速率需求大概在40到50kbps左右，所以很多早期基站配置取52kbps作为单用户授权上限。但这个配置有个前提：SBC不会在协商后重新计算并抬升带宽。一旦SBC加入了G711编码，单路带宽需求就会跳到80kbps以上，52kbps的配置直接失去合理性。

3.3 Diameter信令里的带宽值：max-requested-bandwidth-ul到底是谁填的

max-requested-bandwidth-ul是一个Diameter AVP，由PCRF或PGW根据SBC发来的AAR消息内容生成。也就是说，最终让基站看到多少带宽，取决于SBC在AAR消息里传输的带宽值。如果SBC在转发INVITE时修改了SDP的B行值，AAR消息里的带宽值也会跟着变，最终在E-RAB SETUP REQUEST里体现出来。

从SBC侧抓包可以看到被叫侧AAR消息的关键字段：

AAR (Diameter Credit-Control) avp: max-requested-bandwidth-ul (66) value: 88000

这个值最直接地揭示了问题的来源：SBC申请的带宽是88kbps，超出了基站的授权上限。所以问题链条其实是"主叫SDP是49kbps，SBC重算后变成80kbps，最终体现在AAR里变成了88kbps，基站拒掉了"。上下文里还出现了一个被叫侧日志相关的标记R6y，以及一条Ix消息，说明问题样本量不少，不同测试点触发的概率较高。

4. 真正的源头在SBC：INVITE带宽为何从49变成80kbps

4.1 SDP里的B行：b=AS:49与b=AS:80的差异

回看主叫侧的信令，手机发出的INVITE消息里SDP带宽行是b=AS:49，代表应用层带宽需求为49kbps。但SBC转发给被叫侧的INVITE里，B行变成了b=AS:80。这一个数字的变化，直接导致后续AAR带宽申请越变越大，最终突破了基站的授权上限。

主叫侧原始INVITE: v=0 o=- 123456 7890 IN IP4 192.168.1.100 c=IN IP4 192.168.1.100 m=audio 20000 RTP/AVP 97 98 a=rtpmap:97 AMR-WB/16000 b=AS:49 SBC转发后的INVITE: v=0 o=- 123456 7890 IN IP4 192.168.1.101 c=IN IP4 192.168.1.101 m=audio 30000 RTP/AVP 0 97 98 a=rtpmap:0 PCMU/8000 b=AS:80

对比两边就能看到，SBC在转发时做了两件事：一是在媒体协商里加入了G711编码（rtpmap:0 PCMU/8000），二是根据G711的带宽需求把b=AS从49改成了80。

为什么SBC会主动加G711呢，核心原因是该厂商SBC的C20版本默认启用了编解码转换，也就是transcoding模式。SBC认为对端网络的编解码配置可能不兼容AMR-WB，就会在媒体面做一次语音编解码转换，把AMR-WB转成G711以便和传统PSTN网络互通。而G711是64kbps的裸语音编码，加上IP/RTP/UDP开销，应用层带宽在80kbps左右，所以SBC根据编码协议重新计算了SDP的B行，从49调整为80kbps。

4.2 SBC编解码转换的带宽重算逻辑

SBC修改B行的逻辑，本质上是根据媒体协商的结果重新估算RTP媒体流的带宽需求。不同编码类型的带宽参数不同：G711A/U在净负荷64kbps，加上包头开销在80kbps上下；AMR-WB 23.85kbps，加上开销在40kbps上下；AMR-NB 12.2kbps，总带宽更低。SBC要做编解码转换时，因为媒体面不再只是转发而是真正解码再编码，它会按照转换后的编码器类型重新计算带宽并写入SDP。

在带宽重算这一步里，透传与转换两种模式的差别很大，简要对比如下：

透传模式：SBC不做编解码转换，只转发RTP，SDP带宽保持终端协商值不变 转换模式：SBC做编解码转换，RTP终结在SBC，SDP带宽按目标编码类型重算

本案例触发的就是转换模式。SBC把AMR-WB转成G711后，B行带宽从49kbps变成80kbps，带宽申请一路传导到基站侧。如果SBC配置的是透传模式，即信任终端媒体带宽信息，那么B行会保持49不变，AAR带宽申请也会维持在50kbps左右，基站52kbps的授权上限就不会被突破。

4.3 BCPLC参数：信任终端媒体带宽信息改为否

SBC上有一个关键参数控制着这种行为，即BCPLC配置里的"信任终端媒体带宽信息"，在英文界面中通常对应Trust Terminal Media Bandwidth或类似名称。默认值是是，也就是SBC信任终端在SDP里上报的带宽，不主动修改B行。但当该参数配置为否时，SBC放弃信任终端上报值，改为按自身策略计算带宽填入SDP，这样出现G711编码时，带宽被抬升到80kbps也就成了必然结果。

把该参数改为否以后，SBC在转发INVITE时保留了终端的媒体带宽信息：

修改后SBC转发的INVITE: m=audio 30000 RTP/AVP 0 97 98 b=AS:49

这样可以保证AAR消息里的带宽申请仍以终端上报值为基础，不再因为编码转换而翻倍。不过需要注意，这种修改会把所有经过该SBC的VoLTE呼叫设为不透传计费或带宽信任模式，会影响带宽共享和长期演进规划，建议在测试验证后再上生产。

5. 排查与避坑：抓包、日志解读与三个隐藏坑

5.1 抓包时只看E-RAB消息会错过真正的源头

现象：某次测试，从基站侧Trace里看到了E-RAB SETUP REQUEST里请求带宽88kbps、基站返回Radio-resource-not-available，于是判断是基站侧QCI1带宽配置太低，直接把基站带宽调成200kbps，结果故障复现，用户仍然听到呼叫失败。

原因：把定位停在基站这一层，没有向上游追溯。真正的问题是SBC侧改了SDP带宽，才导致核心网请求的带宽超标。只调基站属于治标不治本，带宽申请逻辑没改，换个业务场景还会超限。

解决：排查一定要做完整信令链路比对，从主叫INVITE的SDP、SBC转发后的INVITE的SDP、AAR消息里的带宽值、E-RAB SETUP REQUEST里的带宽值这四个节点同时抓取，对比每一跳的带宽变化。哪一跳发生变化，源头就在哪里，再往上追就找到了。

5.2 基站的52kbps配置不能绑定单一编码

现象：现场部分工程师认为52kbps够用，因为当前手机终端上报的是AMR-WB，带宽需求只有40kbps左右，语音质量测试也通过。但加入多方通话或跨网呼叫时，SBC一旦启用G711转换，带宽直接翻倍到80kbps以上，52kbps的授权配额就不够了。

原因：52kbps的配置只覆盖了AMR-WB单编码场景，没有把编解码转换后的G711开销算进去。SBC加入G711后，AAR带宽请求值已经超过基站授权上限，必然被拒。

解决：按实际业务场景预留余量。如果SBC可能启用G711转换，基站侧QCI1最大授权带宽应调整到至少200kbps，否则还要反复调参，正确做法是直接按多方通话的峰值带宽需求来规划。

5.3 日志时间戳不同步，信令对不齐

现象：信令分析时发现SBC日志和基站日志时间对不上，同一通呼叫的INVITE和E-RAB SETUP REQUEST时间戳相差数秒，无法判断到底是先改了SDP还是先触发了承载建立失败。

原因：不同网元设备的系统时间源不一致，SBC可能用NTP同步，基站用1588v2同步，两端存在秒级偏差。跨网元联合分析时没有先做时间偏差校正。

解决：先看每台设备的NTP同步状态，再取两端的同一条标准消息（如INVITE的Call-ID或Session ID）做时间偏移对齐。更稳妥的做法是在测试前就把所有网元时间统一到同一NTP服务器，并在抓包时采集GPS时钟参考，这样联合分析时不会因为时间错位误判事件顺序。

5.4 改完参数后没有重新验证多方通话场景

现象：把BCPLC参数改成否后，单路VoLTE呼叫测试全部通过，带宽请求恢复到49kbps，基站侧也不再返回Radio-resource-not-available，以为问题闭环了。但后续在多方通话场景再次出现503，用户从5G掉到4G。

原因：多方通话的媒体流数量是单路的倍数，即使SBC不再重算带宽，多个媒体流叠加后的总带宽请求也可能超过基站配额。单通测试通过不能代表多方通话场景没问题。

解决：在参数修改后做完整的回归测试，至少覆盖单通、双通、多方通话三个场景，并同时监测E-RAB SETUP REQUEST里的带宽请求值。

6. 落地修复与验证：参数配置、回归测试与信令闭环确认

修复不是简单地改一个参数就结束，需要把SBC侧和基站侧放在一起调整，并验证整条链路的带宽申请恢复到终端真实需求值。

SBC侧，把BCPLC配置里的信任终端媒体带宽信息改为否，保证转发INVITE时保留终端的b=AS原始值，不做重算。基站侧，把QCI1最大授权带宽从52kbps调整到200kbps以上，以覆盖多方通话和编码转换的峰值需求。两个改动必须同时生效。

# SBC侧典型配置示例（实际命令以现场设备为准） # 开启终端带宽信息信任，禁止SBC重新计算 bcplc media bandwidth-mode trust-terminal

改完后的信令验证，我一般会强制走一遍完整流程：先抓主叫原始INVITE、SBC转发后的INVITE和E-RAB SETUP REQUEST，三处消息的带宽值进行对比。如果转发后的INVITE仍携带b=AS:49而不是b=AS:80，且E-RAB SETUP REQUEST里的max-requested-bandwidth-ul不再超过基站配置值，说明核心问题已经消除。

验证目标值： 主叫原始INVITE b=AS:49 SBC转发INVITE b=AS:49 AAR带宽请求值 ≤ 52000 E-RAB SETUP RESPONSE: setup success

然后连续做10次以上的VoLTE呼叫测试，不单是单通，还要包含多方通话场景，确认不再出现503和Radio-resource-not-available，用户也不会在通话失败后掉到4G。从那以后，我每次处理503类的VoLTE失败案例，都会强制把INVITE和E-RAB两侧的信令拉通比对一遍，确认带宽请求值的每一跳来源，而不是看到Radio-resource-not-available就直接调基站参数。这套排查习惯帮我挡掉了不少返工，希望也能帮到你。

本文还有配套的精品资源，点击获取