简介这是面向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-available3.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是49kbpsSBC重算后变成80kbps最终体现在AAR里变成了88kbps基站拒掉了。上下文里还出现了一个被叫侧日志相关的标记R6y以及一条Ix消息说明问题样本量不少不同测试点触发的概率较高。4. 真正的源头在SBCINVITE带宽为何从49变成80kbps4.1 SDP里的B行bAS:49与bAS:80的差异回看主叫侧的信令手机发出的INVITE消息里SDP带宽行是bAS:49代表应用层带宽需求为49kbps。但SBC转发给被叫侧的INVITE里B行变成了bAS:80。这一个数字的变化直接导致后续AAR带宽申请越变越大最终突破了基站的授权上限。主叫侧原始INVITE: v0 o- 123456 7890 IN IP4 192.168.1.100 cIN IP4 192.168.1.100 maudio 20000 RTP/AVP 97 98 artpmap:97 AMR-WB/16000 bAS:49 SBC转发后的INVITE: v0 o- 123456 7890 IN IP4 192.168.1.101 cIN IP4 192.168.1.101 maudio 30000 RTP/AVP 0 97 98 artpmap:0 PCMU/8000 bAS:80对比两边就能看到SBC在转发时做了两件事一是在媒体协商里加入了G711编码rtpmap:0 PCMU/8000二是根据G711的带宽需求把bAS从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不做编解码转换只转发RTPSDP带宽保持终端协商值不变 转换模式SBC做编解码转换RTP终结在SBCSDP带宽按目标编码类型重算本案例触发的就是转换模式。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: maudio 30000 RTP/AVP 0 97 98 bAS: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时保留终端的bAS原始值不做重算。基站侧把QCI1最大授权带宽从52kbps调整到200kbps以上以覆盖多方通话和编码转换的峰值需求。两个改动必须同时生效。# SBC侧典型配置示例实际命令以现场设备为准 # 开启终端带宽信息信任禁止SBC重新计算 bcplc media bandwidth-mode trust-terminal改完后的信令验证我一般会强制走一遍完整流程先抓主叫原始INVITE、SBC转发后的INVITE和E-RAB SETUP REQUEST三处消息的带宽值进行对比。如果转发后的INVITE仍携带bAS:49而不是bAS:80且E-RAB SETUP REQUEST里的max-requested-bandwidth-ul不再超过基站配置值说明核心问题已经消除。验证目标值 主叫原始INVITE bAS:49 SBC转发INVITE bAS: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就直接调基站参数。这套排查习惯帮我挡掉了不少返工希望也能帮到你。本文还有配套的精品资源点击获取
