簡介這是面向4G/5G網絡優(yōu)化工程師的VoLTE排障案例聚焦IMS返回503 ServiceUnavailable并導致用戶從5G回落到4G的典型問題。文檔從拉網測試中部分手機呼叫失敗出發(fā)完整呈現了排障流程先跟蹤基站側trace發(fā)現核心網E-RAB SETUP REQUEST中上行請求最大帶寬為88kbps超過基站配置的52kbps上限從而回傳Radio-resource-not-available再經信令確認被叫側R6y日志中的max-requested-bandwidth-ul為88000同時SBC將主叫側INVITE中的SDP帶寬由49kbps改寫為80kbps因配置G711編解碼重算導致專用承載建立失敗。針對該根因文檔給出了華為SBC BCPLC中設置信任終端媒體帶寬為否、確保編解碼轉換后轉發(fā)INVITE不改變帶寬以及針對多方通話等高帶寬業(yè)務將基站QCI1帶寬提升至200kbps等具體調整方案并附有信令參數與關鍵配置截圖便于實際作業(yè)時對照實施。資源為1個docx文檔大小129KB內容聚焦無冗余。已有406人學習下載適合從事5G語音優(yōu)化、核心網與無線側協同排障的工程師查閱。1. 5G網優(yōu)案例IMS直接報503 ServiceUnavailable用戶掉到4G拉網測試最怕的就是這種場景手機明明顯示5G滿格VoLTE呼叫卻直接失敗主叫側收到503 ServiceUnavailable信令里寫著media bearer lost用戶還沒反應過來手機已經悄悄掉到4G。這個案例我在多個項目里見過類似變種根因不是核心網掛了也不是基站故障而是SBC申請帶寬超出基站配置上限導致專用承載建立失敗。對一線網優(yōu)工程師來說這類問題如果不順著信令逐跳排查很容易在E-RAB建立失敗這一步就下了錯誤結論。這篇筆記會把完整的定位思路、參數對應關系和修復方案拆開講透尤其適合剛接觸VoLTE承載優(yōu)化的從業(yè)者照著復現。2. 為什么是503而不是其他錯誤VoLTE呼叫流程與承載建立鏈路2.1 VoLTE呼叫建立從INVITE到專用承載的四次握手VoLTE呼叫不是手機到手機直連而是手機通過基站接入再經過IMS核心網完成呼叫控制。整個過程中QCI1專用承載的建立是關鍵。主叫發(fā)起INVITE請求后IMS核心網側的SBC會與被叫側完成SDP協商隨后通過Rx接口向PCRF發(fā)起AAR請求PCRF再通過Gx接口通知PGW建立專用承載。PGW向基站發(fā)送E-RAB SETUP REQUEST基站為這條承載分配空口資源如果分配成功就返回E-RAB SETUP RESPONSE承載建立完成VoLTE呼叫才能繼續(xù)。整個鏈路可以簡化成下面這張流程對應關系手機 -- RRC -- 基站(enodeb) -- S1-U/S1-MME -- PGW -- Rx -- PCRF -- AAR -- SBC呼叫失敗時隨手抓一條信令看是卡在E-RAB建立前的哪一步。這個鏈路里最容易出問題的節(jié)點有三個SBC的SDP帶寬重算、PCRF與PGW之間的策略下發(fā)、基站側的空口資源分配。本案例的問題出在最后一個節(jié)點根因卻在第一個節(jié)點。如果不把整條鏈路拆開看只盯基站告警大概率會做成調高基站帶寬、問題暫時消失、下次換個場景又復發(fā)的無用功。2.2 503 ServiceUnavailable在VoLTE里的真實含義503 ServiceUnavailable在HTTP協議里表示服務器暫時無法處理請求在VoLTE信令里這個錯誤碼由IMS核心網返回通常意味著媒體面資源沒有準備好。具體到這個案例錯誤原因值攜帶的是media bearer lost說明QCI1專用承載在建立過程中丟失或被釋放。常規(guī)情況下VoLTE呼叫失敗返回的錯誤碼還有480 Temporarily Unavailable、486 Busy Here、580 Precondition Failure等各自對應的場景完全不同。480偏向被叫不可達486是用戶忙580多與SDP預條件不滿足有關。而503加上media bearer lost基本鎖定在媒體承載建立這條路線上需要重點排查空口資源、核心網策略和SBC帶寬計算這三個環(huán)節(jié)。排查時可以做一個快速分流用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直譯過來就是空口資源不可用。很多人看到這個原因值第一反應是基站資源不足直接去查小區(qū)用戶數和PRB利用率。但查了半天用戶數不高PRB利用率也不滿問題依然復現這就說明根本不是真的資源不足而是請求的資源規(guī)格超出了基站允許的范圍。一個典型的信令展示如下E-RAB SETUP RESPONSE E-RAB ID: 1 E-RAB Setup Failed List Cause: Radio-resource-not-available E-RAB Setup List: (0 items)基站返回這個原因值的常見觸發(fā)條件有三個一是小區(qū)上行干擾過高導致可用PRB減少二是請求的GBR帶寬超過了基站側配置的最大帶寬三是QCI1承載數超過小區(qū)配置上限。本案例屬于第二種核心網請求的帶寬是88kbps基站配置的上下行最大帶寬只有52kbps那么無論小區(qū)有多空閑基站都會拒絕這條承載。這種配置型資源不足在信令上看不出小區(qū)擁塞痕跡只能靠對比請求值和配置值來定位這也是很多測試工程師在這個問題上反復卡殼的原因。3. 信令鏈路逐跳拆解從E-RAB SETUP REQUEST到Radio-resource-not-available3.1 基站側Trace為什么請求帶寬88kbps被拒打開基站側Trace找到核心網發(fā)給基站的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說明核心網給出的規(guī)格偏高超出了基站配置。對照基站側配置該小區(qū)上下行最大帶寬均為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帶寬需求會明顯上升。實際規(guī)劃時應按以下邏輯設定基站的最大授權帶寬單路語音總帶寬 ≈ 編碼器速率 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發(fā)來的AAR消息內容生成。也就是說最終讓基站看到多少帶寬取決于SBC在AAR消息里傳輸的帶寬值。如果SBC在轉發(fā)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消息說明問題樣本量不少不同測試點觸發(fā)的概率較高。4. 真正的源頭在SBCINVITE帶寬為何從49變成80kbps4.1 SDP里的B行bAS:49與bAS:80的差異回看主叫側的信令手機發(fā)出的INVITE消息里SDP帶寬行是bAS:49代表應用層帶寬需求為49kbps。但SBC轉發(fā)給被叫側的INVITE里B行變成了bAS:80。這一個數字的變化直接導致后續(xù)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轉發(fā)后的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在轉發(fā)時做了兩件事一是在媒體協商里加入了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要做編解碼轉換時因為媒體面不再只是轉發(fā)而是真正解碼再編碼它會按照轉換后的編碼器類型重新計算帶寬并寫入SDP。在帶寬重算這一步里透傳與轉換兩種模式的差別很大簡要對比如下透傳模式SBC不做編解碼轉換只轉發(fā)RTPSDP帶寬保持終端協商值不變 轉換模式SBC做編解碼轉換RTP終結在SBCSDP帶寬按目標編碼類型重算本案例觸發(fā)的就是轉換模式。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在轉發(fā)INVITE時保留了終端的媒體帶寬信息修改后SBC轉發(fā)的INVITE: maudio 30000 RTP/AVP 0 97 98 bAS:49這樣可以保證AAR消息里的帶寬申請仍以終端上報值為基礎不再因為編碼轉換而翻倍。不過需要注意這種修改會把所有經過該SBC的VoLTE呼叫設為不透傳計費或帶寬信任模式會影響帶寬共享和長期演進規(guī)劃建議在測試驗證后再上生產。5. 排查與避坑抓包、日志解讀與三個隱藏坑5.1 抓包時只看E-RAB消息會錯過真正的源頭現象某次測試從基站側Trace里看到了E-RAB SETUP REQUEST里請求帶寬88kbps、基站返回Radio-resource-not-available于是判斷是基站側QCI1帶寬配置太低直接把基站帶寬調成200kbps結果故障復現用戶仍然聽到呼叫失敗。原因把定位停在基站這一層沒有向上游追溯。真正的問題是SBC側改了SDP帶寬才導致核心網請求的帶寬超標。只調基站屬于治標不治本帶寬申請邏輯沒改換個業(yè)務場景還會超限。解決排查一定要做完整信令鏈路比對從主叫INVITE的SDP、SBC轉發(fā)后的INVITE的SDP、AAR消息里的帶寬值、E-RAB SETUP REQUEST里的帶寬值這四個節(jié)點同時抓取對比每一跳的帶寬變化。哪一跳發(fā)生變化源頭就在哪里再往上追就找到了。5.2 基站的52kbps配置不能綁定單一編碼現象現場部分工程師認為52kbps夠用因為當前手機終端上報的是AMR-WB帶寬需求只有40kbps左右語音質量測試也通過。但加入多方通話或跨網呼叫時SBC一旦啟用G711轉換帶寬直接翻倍到80kbps以上52kbps的授權配額就不夠了。原因52kbps的配置只覆蓋了AMR-WB單編碼場景沒有把編解碼轉換后的G711開銷算進去。SBC加入G711后AAR帶寬請求值已經超過基站授權上限必然被拒。解決按實際業(yè)務場景預留余量。如果SBC可能啟用G711轉換基站側QCI1最大授權帶寬應調整到至少200kbps否則還要反復調參正確做法是直接按多方通話的峰值帶寬需求來規(guī)劃。5.3 日志時間戳不同步信令對不齊現象信令分析時發(fā)現SBC日志和基站日志時間對不上同一通呼叫的INVITE和E-RAB SETUP REQUEST時間戳相差數秒無法判斷到底是先改了SDP還是先觸發(fā)了承載建立失敗。原因不同網元設備的系統時間源不一致SBC可能用NTP同步基站用1588v2同步兩端存在秒級偏差?？缇W元聯合分析時沒有先做時間偏差校正。解決先看每臺設備的NTP同步狀態(tài)再取兩端的同一條標準消息如INVITE的Call-ID或Session ID做時間偏移對齊。更穩(wěn)妥的做法是在測試前就把所有網元時間統一到同一NTP服務器并在抓包時采集GPS時鐘參考這樣聯合分析時不會因為時間錯位誤判事件順序。5.4 改完參數后沒有重新驗證多方通話場景現象把BCPLC參數改成否后單路VoLTE呼叫測試全部通過帶寬請求恢復到49kbps基站側也不再返回Radio-resource-not-available以為問題閉環(huán)了。但后續(xù)在多方通話場景再次出現503用戶從5G掉到4G。原因多方通話的媒體流數量是單路的倍數即使SBC不再重算帶寬多個媒體流疊加后的總帶寬請求也可能超過基站配額。單通測試通過不能代表多方通話場景沒問題。解決在參數修改后做完整的回歸測試至少覆蓋單通、雙通、多方通話三個場景并同時監(jiān)測E-RAB SETUP REQUEST里的帶寬請求值。6. 落地修復與驗證參數配置、回歸測試與信令閉環(huán)確認修復不是簡單地改一個參數就結束需要把SBC側和基站側放在一起調整并驗證整條鏈路的帶寬申請恢復到終端真實需求值。SBC側把BCPLC配置里的信任終端媒體帶寬信息改為否保證轉發(fā)INVITE時保留終端的bAS原始值不做重算?；緜劝裃CI1最大授權帶寬從52kbps調整到200kbps以上以覆蓋多方通話和編碼轉換的峰值需求。兩個改動必須同時生效。# SBC側典型配置示例實際命令以現場設備為準 # 開啟終端帶寬信息信任禁止SBC重新計算 bcplc media bandwidth-mode trust-terminal改完后的信令驗證我一般會強制走一遍完整流程先抓主叫原始INVITE、SBC轉發(fā)后的INVITE和E-RAB SETUP REQUEST三處消息的帶寬值進行對比。如果轉發(fā)后的INVITE仍攜帶bAS:49而不是bAS:80且E-RAB SETUP REQUEST里的max-requested-bandwidth-ul不再超過基站配置值說明核心問題已經消除。驗證目標值 主叫原始INVITE bAS:49 SBC轉發(fā)INVITE bAS:49 AAR帶寬請求值 ≤ 52000 E-RAB SETUP RESPONSE: setup success然后連續(xù)做10次以上的VoLTE呼叫測試不單是單通還要包含多方通話場景確認不再出現503和Radio-resource-not-available用戶也不會在通話失敗后掉到4G。從那以后我每次處理503類的VoLTE失敗案例都會強制把INVITE和E-RAB兩側的信令拉通比對一遍確認帶寬請求值的每一跳來源而不是看到Radio-resource-not-available就直接調基站參數。這套排查習慣幫我擋掉了不少返工希望也能幫到你。本文還有配套的精品資源點擊獲取 5G VoLTE呼叫失敗503：SBC帶寬重算致E-RAB建立被拒
簡介這是面向4G/5G網絡優(yōu)化工程師的VoLTE排障案例聚焦IMS返回503 ServiceUnavailable并導致用戶從5G回落到4G的典型問題。文檔從拉網測試中部分手機呼叫失敗出發(fā)完整呈現了排障流程先跟蹤基站側trace發(fā)現核心網E-RAB SETUP REQUEST中上行請求最大帶寬為88kbps超過基站配置的52kbps上限從而回傳Radio-resource-not-available再經信令確認被叫側R6y日志中的max-requested-bandwidth-ul為88000同時SBC將主叫側INVITE中的SDP帶寬由49kbps改寫為80kbps因配置G711編解碼重算導致專用承載建立失敗。針對該根因文檔給出了華為SBC BCPLC中設置信任終端媒體帶寬為否、確保編解碼轉換后轉發(fā)INVITE不改變帶寬以及針對多方通話等高帶寬業(yè)務將基站QCI1帶寬提升至200kbps等具體調整方案并附有信令參數與關鍵配置截圖便于實際作業(yè)時對照實施。資源為1個docx文檔大小129KB內容聚焦無冗余。已有406人學習下載適合從事5G語音優(yōu)化、核心網與無線側協同排障的工程師查閱。1. 5G網優(yōu)案例IMS直接報503 ServiceUnavailable用戶掉到4G拉網測試最怕的就是這種場景手機明明顯示5G滿格VoLTE呼叫卻直接失敗主叫側收到503 ServiceUnavailable信令里寫著media bearer lost用戶還沒反應過來手機已經悄悄掉到4G。這個案例我在多個項目里見過類似變種根因不是核心網掛了也不是基站故障而是SBC申請帶寬超出基站配置上限導致專用承載建立失敗。對一線網優(yōu)工程師來說這類問題如果不順著信令逐跳排查很容易在E-RAB建立失敗這一步就下了錯誤結論。這篇筆記會把完整的定位思路、參數對應關系和修復方案拆開講透尤其適合剛接觸VoLTE承載優(yōu)化的從業(yè)者照著復現。2. 為什么是503而不是其他錯誤VoLTE呼叫流程與承載建立鏈路2.1 VoLTE呼叫建立從INVITE到專用承載的四次握手VoLTE呼叫不是手機到手機直連而是手機通過基站接入再經過IMS核心網完成呼叫控制。整個過程中QCI1專用承載的建立是關鍵。主叫發(fā)起INVITE請求后IMS核心網側的SBC會與被叫側完成SDP協商隨后通過Rx接口向PCRF發(fā)起AAR請求PCRF再通過Gx接口通知PGW建立專用承載。PGW向基站發(fā)送E-RAB SETUP REQUEST基站為這條承載分配空口資源如果分配成功就返回E-RAB SETUP RESPONSE承載建立完成VoLTE呼叫才能繼續(xù)。整個鏈路可以簡化成下面這張流程對應關系手機 -- RRC -- 基站(enodeb) -- S1-U/S1-MME -- PGW -- Rx -- PCRF -- AAR -- SBC呼叫失敗時隨手抓一條信令看是卡在E-RAB建立前的哪一步。這個鏈路里最容易出問題的節(jié)點有三個SBC的SDP帶寬重算、PCRF與PGW之間的策略下發(fā)、基站側的空口資源分配。本案例的問題出在最后一個節(jié)點根因卻在第一個節(jié)點。如果不把整條鏈路拆開看只盯基站告警大概率會做成調高基站帶寬、問題暫時消失、下次換個場景又復發(fā)的無用功。2.2 503 ServiceUnavailable在VoLTE里的真實含義503 ServiceUnavailable在HTTP協議里表示服務器暫時無法處理請求在VoLTE信令里這個錯誤碼由IMS核心網返回通常意味著媒體面資源沒有準備好。具體到這個案例錯誤原因值攜帶的是media bearer lost說明QCI1專用承載在建立過程中丟失或被釋放。常規(guī)情況下VoLTE呼叫失敗返回的錯誤碼還有480 Temporarily Unavailable、486 Busy Here、580 Precondition Failure等各自對應的場景完全不同。480偏向被叫不可達486是用戶忙580多與SDP預條件不滿足有關。而503加上media bearer lost基本鎖定在媒體承載建立這條路線上需要重點排查空口資源、核心網策略和SBC帶寬計算這三個環(huán)節(jié)。排查時可以做一個快速分流用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直譯過來就是空口資源不可用。很多人看到這個原因值第一反應是基站資源不足直接去查小區(qū)用戶數和PRB利用率。但查了半天用戶數不高PRB利用率也不滿問題依然復現這就說明根本不是真的資源不足而是請求的資源規(guī)格超出了基站允許的范圍。一個典型的信令展示如下E-RAB SETUP RESPONSE E-RAB ID: 1 E-RAB Setup Failed List Cause: Radio-resource-not-available E-RAB Setup List: (0 items)基站返回這個原因值的常見觸發(fā)條件有三個一是小區(qū)上行干擾過高導致可用PRB減少二是請求的GBR帶寬超過了基站側配置的最大帶寬三是QCI1承載數超過小區(qū)配置上限。本案例屬于第二種核心網請求的帶寬是88kbps基站配置的上下行最大帶寬只有52kbps那么無論小區(qū)有多空閑基站都會拒絕這條承載。這種配置型資源不足在信令上看不出小區(qū)擁塞痕跡只能靠對比請求值和配置值來定位這也是很多測試工程師在這個問題上反復卡殼的原因。3. 信令鏈路逐跳拆解從E-RAB SETUP REQUEST到Radio-resource-not-available3.1 基站側Trace為什么請求帶寬88kbps被拒打開基站側Trace找到核心網發(fā)給基站的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說明核心網給出的規(guī)格偏高超出了基站配置。對照基站側配置該小區(qū)上下行最大帶寬均為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帶寬需求會明顯上升。實際規(guī)劃時應按以下邏輯設定基站的最大授權帶寬單路語音總帶寬 ≈ 編碼器速率 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發(fā)來的AAR消息內容生成。也就是說最終讓基站看到多少帶寬取決于SBC在AAR消息里傳輸的帶寬值。如果SBC在轉發(fā)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消息說明問題樣本量不少不同測試點觸發(fā)的概率較高。4. 真正的源頭在SBCINVITE帶寬為何從49變成80kbps4.1 SDP里的B行bAS:49與bAS:80的差異回看主叫側的信令手機發(fā)出的INVITE消息里SDP帶寬行是bAS:49代表應用層帶寬需求為49kbps。但SBC轉發(fā)給被叫側的INVITE里B行變成了bAS:80。這一個數字的變化直接導致后續(xù)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轉發(fā)后的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在轉發(fā)時做了兩件事一是在媒體協商里加入了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要做編解碼轉換時因為媒體面不再只是轉發(fā)而是真正解碼再編碼它會按照轉換后的編碼器類型重新計算帶寬并寫入SDP。在帶寬重算這一步里透傳與轉換兩種模式的差別很大簡要對比如下透傳模式SBC不做編解碼轉換只轉發(fā)RTPSDP帶寬保持終端協商值不變 轉換模式SBC做編解碼轉換RTP終結在SBCSDP帶寬按目標編碼類型重算本案例觸發(fā)的就是轉換模式。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在轉發(fā)INVITE時保留了終端的媒體帶寬信息修改后SBC轉發(fā)的INVITE: maudio 30000 RTP/AVP 0 97 98 bAS:49這樣可以保證AAR消息里的帶寬申請仍以終端上報值為基礎不再因為編碼轉換而翻倍。不過需要注意這種修改會把所有經過該SBC的VoLTE呼叫設為不透傳計費或帶寬信任模式會影響帶寬共享和長期演進規(guī)劃建議在測試驗證后再上生產。5. 排查與避坑抓包、日志解讀與三個隱藏坑5.1 抓包時只看E-RAB消息會錯過真正的源頭現象某次測試從基站側Trace里看到了E-RAB SETUP REQUEST里請求帶寬88kbps、基站返回Radio-resource-not-available于是判斷是基站側QCI1帶寬配置太低直接把基站帶寬調成200kbps結果故障復現用戶仍然聽到呼叫失敗。原因把定位停在基站這一層沒有向上游追溯。真正的問題是SBC側改了SDP帶寬才導致核心網請求的帶寬超標。只調基站屬于治標不治本帶寬申請邏輯沒改換個業(yè)務場景還會超限。解決排查一定要做完整信令鏈路比對從主叫INVITE的SDP、SBC轉發(fā)后的INVITE的SDP、AAR消息里的帶寬值、E-RAB SETUP REQUEST里的帶寬值這四個節(jié)點同時抓取對比每一跳的帶寬變化。哪一跳發(fā)生變化源頭就在哪里再往上追就找到了。5.2 基站的52kbps配置不能綁定單一編碼現象現場部分工程師認為52kbps夠用因為當前手機終端上報的是AMR-WB帶寬需求只有40kbps左右語音質量測試也通過。但加入多方通話或跨網呼叫時SBC一旦啟用G711轉換帶寬直接翻倍到80kbps以上52kbps的授權配額就不夠了。原因52kbps的配置只覆蓋了AMR-WB單編碼場景沒有把編解碼轉換后的G711開銷算進去。SBC加入G711后AAR帶寬請求值已經超過基站授權上限必然被拒。解決按實際業(yè)務場景預留余量。如果SBC可能啟用G711轉換基站側QCI1最大授權帶寬應調整到至少200kbps否則還要反復調參正確做法是直接按多方通話的峰值帶寬需求來規(guī)劃。5.3 日志時間戳不同步信令對不齊現象信令分析時發(fā)現SBC日志和基站日志時間對不上同一通呼叫的INVITE和E-RAB SETUP REQUEST時間戳相差數秒無法判斷到底是先改了SDP還是先觸發(fā)了承載建立失敗。原因不同網元設備的系統時間源不一致SBC可能用NTP同步基站用1588v2同步兩端存在秒級偏差?？缇W元聯合分析時沒有先做時間偏差校正。解決先看每臺設備的NTP同步狀態(tài)再取兩端的同一條標準消息如INVITE的Call-ID或Session ID做時間偏移對齊。更穩(wěn)妥的做法是在測試前就把所有網元時間統一到同一NTP服務器并在抓包時采集GPS時鐘參考這樣聯合分析時不會因為時間錯位誤判事件順序。5.4 改完參數后沒有重新驗證多方通話場景現象把BCPLC參數改成否后單路VoLTE呼叫測試全部通過帶寬請求恢復到49kbps基站側也不再返回Radio-resource-not-available以為問題閉環(huán)了。但后續(xù)在多方通話場景再次出現503用戶從5G掉到4G。原因多方通話的媒體流數量是單路的倍數即使SBC不再重算帶寬多個媒體流疊加后的總帶寬請求也可能超過基站配額。單通測試通過不能代表多方通話場景沒問題。解決在參數修改后做完整的回歸測試至少覆蓋單通、雙通、多方通話三個場景并同時監(jiān)測E-RAB SETUP REQUEST里的帶寬請求值。6. 落地修復與驗證參數配置、回歸測試與信令閉環(huán)確認修復不是簡單地改一個參數就結束需要把SBC側和基站側放在一起調整并驗證整條鏈路的帶寬申請恢復到終端真實需求值。SBC側把BCPLC配置里的信任終端媒體帶寬信息改為否保證轉發(fā)INVITE時保留終端的bAS原始值不做重算?；緜劝裃CI1最大授權帶寬從52kbps調整到200kbps以上以覆蓋多方通話和編碼轉換的峰值需求。兩個改動必須同時生效。# SBC側典型配置示例實際命令以現場設備為準 # 開啟終端帶寬信息信任禁止SBC重新計算 bcplc media bandwidth-mode trust-terminal改完后的信令驗證我一般會強制走一遍完整流程先抓主叫原始INVITE、SBC轉發(fā)后的INVITE和E-RAB SETUP REQUEST三處消息的帶寬值進行對比。如果轉發(fā)后的INVITE仍攜帶bAS:49而不是bAS:80且E-RAB SETUP REQUEST里的max-requested-bandwidth-ul不再超過基站配置值說明核心問題已經消除。驗證目標值 主叫原始INVITE bAS:49 SBC轉發(fā)INVITE bAS:49 AAR帶寬請求值 ≤ 52000 E-RAB SETUP RESPONSE: setup success然后連續(xù)做10次以上的VoLTE呼叫測試不單是單通還要包含多方通話場景確認不再出現503和Radio-resource-not-available用戶也不會在通話失敗后掉到4G。從那以后我每次處理503類的VoLTE失敗案例都會強制把INVITE和E-RAB兩側的信令拉通比對一遍確認帶寬請求值的每一跳來源而不是看到Radio-resource-not-available就直接調基站參數。這套排查習慣幫我擋掉了不少返工希望也能幫到你。本文還有配套的精品資源點擊獲取