【文章內(nèi)容簡介】 是無效值0x44，因此會被BSC 拒掉。通過和之前的原網(wǎng)呼叫跟蹤記錄對比，發(fā)現(xiàn)原網(wǎng)在GPM中始終會攜帶業(yè)務(wù)選項，而華為對于缺省的語音業(yè)務(wù)是不攜帶業(yè)務(wù)選項的。這樣做是符合協(xié)議的，但由于現(xiàn)網(wǎng)的部分手機不符合協(xié)議，因此會返回?zé)o效的業(yè)務(wù)選項，導(dǎo)致被叫響應(yīng)被拒絕。通過修改軟參，要所有GPM都攜帶業(yè)務(wù)選項，該問題解決?！窘Y(jié)論】 對于無法做主叫、被叫這樣的問題，最有用的手段就是跟蹤信令，通過信令分析問題出現(xiàn)的環(huán)節(jié)。對于非空口的原因，就需要分析信令中的字段內(nèi)容是否正常，如果是搬遷項目，最直接的辦法就是對比原網(wǎng)的信令內(nèi)容，這樣能夠很快的發(fā)現(xiàn)類似的兼容性問題。（徐斌斌）【案例索引關(guān)鍵詞】 硬指配、呼叫嘗試次數(shù)【案例描述】I國搬遷項目中，許多多載波邊界站點開啟了硬指配功能，而且空閑時手機只在基本載波上駐留，接入后才可能會被指配到疊加載波上。割接后話統(tǒng)顯示硬指配站點的基本載波呼叫嘗試次數(shù)遠小于疊加載波載波，客戶對此提出疑議，認為我們的硬指配算法有問題，無法達到負荷均衡的目的。【處理過程】選取一個三載波站，該站的2載波為基本載波，第3載波為疊加載波。分析該站話統(tǒng)，發(fā)現(xiàn)的確2載波的呼叫嘗試次數(shù)只有200次，但第3載波的呼叫嘗試次數(shù)有1000多次。Reliance 項目典型案例總結(jié)（第四期）2022418 第 20 頁, 共 117 頁分析該站實際的話務(wù)情況，發(fā)現(xiàn)3個載波Walsh話務(wù)量基本相當(dāng)。從總的TCH請求次數(shù)來看，2載波的次數(shù)略多于第3載波。實際上該站旁邊是2載波站，因此2載波的軟切換話務(wù)量較高，這點從TCH軟切換請求次數(shù)就可以看到，2載波的軟切換請求次數(shù)遠高于第3載波。由于該站開啟了硬指配功能，又由于2載波有很多軟切換過來的呼叫因此負荷較高，因此從該站接入的新呼叫大部分都被指配到了第3載波上。而我們的話統(tǒng)統(tǒng)計呼叫嘗試時，是按指配頻點統(tǒng)計的，而不是用戶實際發(fā)起接入嘗試的頻點，因此從話統(tǒng)中的疊加載波的呼叫嘗試次數(shù)會高于基本載波。向客戶提交了說明后，得到了客戶的認可。第3載波的呼叫嘗試次數(shù)是2載波的10倍Reliance 項目典型案例總結(jié)（第四期）2022418 第 21 頁, 共 117 頁【結(jié)論】1. 華為的“呼叫嘗試次數(shù)”指標(biāo)，在硬指配打開后，會統(tǒng)計到被指配的目標(biāo)載頻上，而不是用戶實際接入的的頻點。這一點在話統(tǒng)分析時要注意。2. 打開硬指配算法后，由于呼叫會被指配到負荷低的載頻上以達到負荷均衡的目的，此時接入嘗試次數(shù)并不能正確反映話務(wù)量和負荷的分布，對于負荷均衡，需要分析各載頻的負荷和話務(wù)量指標(biāo)。 CE 資源池配置解決載波間 CE 分配問題（徐斌斌）【案例索引關(guān)鍵詞】呼叫建立失敗 CE不足【案例描述】I國搬遷項目中，某BSC下24號站晚忙時出現(xiàn)大量CE 資源不足的呼建失敗。【處理過程】分析發(fā)現(xiàn)該站打開了硬指配，由于用戶分布較近，載頻負荷不高，因此大部分用戶都在基本載波呼叫，導(dǎo)致忙時發(fā)生CE 擁塞。通過降低硬指配門限，情況略有改善，但無法根除。BS工程師發(fā)現(xiàn)目前的配置是每塊信道板單獨配置為1個資源池，載波間 CE無法共享。因此通過配置每2塊信道板為1個資源池，使各載波資源共享。問題基本解決。由于2載波為基本載波，話務(wù)量較高，4載波為疊加載波，話務(wù)量較低。為了有效實現(xiàn)CE資源池的作用，將 3載波的兩塊信道板配置成一個CE 資源池，4載波的兩塊信道板配置成一個CE資源池?！窘Y(jié)論】1. 目前華為的硬指配算法只能保證負荷均衡，對于這種話務(wù)高但負荷很低的場景，硬指配算法無法保證載波間資源占用率的均衡。通常情況下只能關(guān)閉硬指配算法。2. 但對于非要使用硬指配的場景，可以通過配置載波間共享CE的資源池配置方法來解決該問題。 一個 BTS 的指標(biāo)突然變差的解決偶然方法（田延峰）【現(xiàn)象描述】 一個BTS的指標(biāo)突然變差，話務(wù)量 4Erl，全天主被叫指標(biāo)全部變差。具體現(xiàn)象為：由于CS TCH Signaling Exchange Failures原因造成的呼建成功率全天Reliance 項目典型案例總結(jié)（第四期）2022418 第 22 頁, 共 117 頁20~90%不定；掉話率（Too many Erasure frames）在5% 以上；軟切換和更軟切換失敗由于Radio interface abnormal的原因成功率只有50~90%；前向FER在7% 左右，反向FER正常；【問題分析】 周圍相鄰站沒有異常； 排除了基站告警及各種硬件原因, 重起基站，沒有效果。 排除所有無線參數(shù)原因，并且把增強指標(biāo)的各種參數(shù)修改到最大，效果不大?！咎幚泶胧吭趪L試了各種方法都無法解決的情況下，把業(yè)務(wù)鏈路刪除，重新添加后，問題解決?！?A1 接口失敗問題 (鄧楊)【現(xiàn)象描述】 Kanpur BSC1 和 Kanpur BSC2 呼建成功率突然下降，存在大量A口失敗，這兩個BSC掛在Kanpur MSC1下面。【問題分析】1. 檢查兩個 BSC 的 A 口配置，均正常。2. 查看修改記錄，未對全網(wǎng)作參數(shù)修改。3. 將問題提交研發(fā)，最后定位出是 MSC 的一個網(wǎng)口突然激活，該網(wǎng)口激活后由于在 BSC 這邊找不到相應(yīng)的單板，故導(dǎo)致大量 A 口失敗?！咎幚泶胧縉 側(cè)將該網(wǎng)口關(guān)閉后，A 口失敗現(xiàn)象消失，呼建成功率恢復(fù)正常。【問題總結(jié)】對于整個 MSC 出現(xiàn) A 口失敗的現(xiàn)象，及時與 N 側(cè)聯(lián)系，讓 N 側(cè)檢查 MSC 的配置，因為整個 MSC 都出現(xiàn)問題的情況，一般都是 N 側(cè)那邊出了問題?！癆1 Interface Failures”的問題（李瑞昕）【問題現(xiàn)象】分析某局話統(tǒng)時，發(fā)現(xiàn)呼叫建立失敗中有大量“A1 Interface Failures”，且數(shù)量波動很大，有時候幾萬次，有時候幾千次，每天幾千上萬次的A1接口失敗是不正常的，在正常的網(wǎng)絡(luò)中該值應(yīng)該很少，甚至是0。Reliance 項目典型案例總結(jié)（第四期）2022418 第 23 頁, 共 117 頁Time(day)CS Attempts[Times]CS Call Setup Success Ratio[%]CS A1 Interface Failures[Times]CS Call Resource Allocation Failures[Times]CS Reverse TCH Preamble Acquisition Failures[Times]CS TCH Signaling Exchange Failures[Times]20221211 6789710 11116 20938 48619 1522920221212 7128360 23333 31243 50814 1429120221213 7270820 23596 41252 53213 1435120221214 7240830 17815 39705 52820 1516720221215 6951010 17790 23061 49201 1413220221216 6576080 16184 13670 45675 1228720221217 6730540 16279 16899 47592 1376320221218 6834780 19271 65823 47602 1283620221219 6178004 6778 5998 42103 11882【分析思路】利用CBSSSTAR分析BSC日志，發(fā)現(xiàn)失敗都是 0x2704，也就是等待MSC 指配請求超時：查看0x2704失敗的框分布，扇區(qū)分布，時間分布和IMSI分布都沒有集中在個別對象上，其中失敗最多的前幾個IMSI，每天都有50次以上的失敗，明顯存在異常。于是在BSC維護臺上跟蹤失敗最多的前10個IMSI 的用戶接口信令進行分析。分析失敗最多的IMSI：404001062467315的信令發(fā)現(xiàn)，該用戶的登記有時候成功，有時候被拒絕，拒絕原因是“illegalMS”；Reliance 項目典型案例總結(jié)（第四期）2022418 第 24 頁, 共 117 頁另外，當(dāng)作為被叫時，BSC會收到 2條尋呼響應(yīng)，并都發(fā)給了MSC ，有時候收到MSC的指配請求：有時候收到“N_DISCONNECT_IND ”：詳細分析登記和尋呼響應(yīng)的里的消息字段發(fā)現(xiàn)，同一個IMSI有兩個ESN，可見這是一個孖機，一個ESN是合法的，一個是非法的，因此登記的時候，只有合法的那個手機能夠成功：Reliance 項目典型案例總結(jié)（第四期）2022418 第 25 頁, 共 117 頁當(dāng)作被叫時，兩個手機收到尋呼消息后都會發(fā)尋呼響應(yīng)，因此BSC會收到2條尋呼響應(yīng)。至于為什么有時候被叫成功，有時候被叫被拒，經(jīng)過對比發(fā)現(xiàn)，如果是非法手機的尋呼響應(yīng)先收到，則MSC就會拒絕，而如果是先收到的是合法手機的， MSC就會發(fā)指配請求，呼叫建立成功。但是不管是成功還是失敗，BSC 都上報了2 條尋呼響應(yīng)，但是只收到一次MSC的響應(yīng)，因此都會統(tǒng)計一次“等待指配請求超時”。利用CBSSTAR 的“CSL 數(shù)據(jù)分析”功能分析0x2704失敗較多的一些IMSI，基本上都是一個IMSI 對應(yīng)2個ESN，其中一個IMSI （404001056000000 ）更是有多達18個ESN：由此可見，這個網(wǎng)絡(luò)中的孖機非常多，這些孖機可以造成相當(dāng)數(shù)量的“0x2704”失敗。Reliance 項目典型案例總結(jié)（第四期）2022418 第 26 頁, 共 117 頁（注：之所以每天有上萬次失敗，后來分析發(fā)現(xiàn)還有承載網(wǎng)有擁塞和傳輸?shù)膯栴}，因此每天的失敗次數(shù)波動很大，另外還有非華為 HLR有時候不給 MSC回響應(yīng)等，這里不再分析。）【處理措施】使用BSC的過濾非法手機功能（命令： ADD BLACKLISTESN），把已知的非法ESN輸入黑名單后，再跟蹤信令分析，BSC 只會收到1次尋呼響應(yīng)，都來自合法的ESN，但是只能是發(fā)現(xiàn)一個手動屏蔽一個。（邸玉波）【現(xiàn)象描述】I國項目中，監(jiān)控話統(tǒng)指標(biāo)發(fā)現(xiàn)一個兩載波站其中有一個載扇沒有話務(wù)?！締栴}分析及處理措施】檢查配置（DSP RES），發(fā)現(xiàn)其中一個載扇是被閉掉的，立即解開，但是發(fā)現(xiàn)還是不能建立起來，之后便開始檢查發(fā)射功率，VSWR，RSSI以及告警等均未發(fā)現(xiàn)異常，之后便檢查CP 板，發(fā)現(xiàn) CCPM的版本是QCK3CCPM,并檢查了基站的配置，發(fā)現(xiàn)最大小區(qū)半徑是40KM，將其改為20KM，問題解決?！締栴}總結(jié)】QCK3CCPM 該類型的芯片（6700芯片），如果最大小區(qū)半徑配置為40KM，最多只能支持5個載扇同時工作。所以需要將小區(qū)半徑修改為20Km。 用戶接入 Reliance 的網(wǎng)絡(luò)造成的 A1 接口失?。ㄛ∮癫ǎ粳F(xiàn)象描述】I國項目中，分析話統(tǒng)時發(fā)現(xiàn)在某一時段總有上百次的A 口失敗?！締栴}分析及處理措施】分析Runlog 發(fā)現(xiàn)，存在大量的等待指配請求超時的失敗，Reliance 項目典型案例總結(jié)（第四期）2022418 第 27 頁, 共 117 頁發(fā)現(xiàn)主要集中在某一個IMSI上，并在維護臺跟蹤，跟了好長時間沒有發(fā)現(xiàn)消息上來，并想主動給該用戶打電話跟蹤，于是查到該號碼為9229462022，并撥打該號碼回訪，但是發(fā)現(xiàn)還是沒有消息上來，詢問客戶得知該用戶是TATA的用戶，但并不清楚為什么會接到Reliance的網(wǎng)絡(luò)下面來，因為兩家運營商使用不同的頻點。于是將該用戶加入到我們黑名單，命令：ADD BLACKLISTESN: ESN=xxxxxxxxxx。使該用戶不能接入到我們的網(wǎng)絡(luò)，問題解決。 A1 接口失?。ㄠ嶊希粳F(xiàn)象描述】O地區(qū)共有4個BSC分掛在兩個MSC上，其中MSC3最先開起來，MSC4在之后兩個月左右才開起來，待MSC3下面的兩個BSC開了約30個BTS后每天統(tǒng)計 KPI發(fā)現(xiàn)MSC4下面的兩個BSC的呼叫建立成功率較低，其中 A1接口失敗次數(shù)較多而 MSC3下面的兩個BSCA1接口失敗次數(shù)基本沒有，如下圖所示：Reliance 項目典型案例總結(jié)（第四期）2022418 第 28 頁, 共 117 頁 圖：A1 接口失敗BSC 對比圖【問題分析】1 由于兩個 MSC 對比現(xiàn)象比較明顯，首先檢查 BSC A 口配置有無問題。2 聯(lián)系 N 側(cè)工程師檢查兩個 MSC 的參數(shù)配置是否相同確認沒有問題。3 核查 MSC4 失敗全天失敗次數(shù)分布發(fā)現(xiàn)基本出現(xiàn)在忙時，檢查 MSC 鏈路狀態(tài)發(fā)現(xiàn)忙時 HWMSC 到 LUMSC 的局間鏈路占用量為 100%，察看兩個 MSC 的鏈路配置發(fā)現(xiàn) MSC3 的局間鏈路配了 21 條均可用，而 MSC4 的局間鏈路配置了 17 條但是其中 9 條處于不可用狀態(tài)，懷疑由于局間鏈路較少導(dǎo)致忙時用戶打出局電話鏈路擁塞無鏈路資源造成 A 接口失敗?！咎幚泶胧客苿泳址皆黾?0條MSC4到朗訊局間鏈路并整改9條不可用鏈路為可用后問題解決。【案例小結(jié)】該案例中查詢局間鏈路命令為“DSP OFCTKC ”，然后輸入GMSC 和鏈路類型如下圖： 圖：查詢局間鏈路方法輸入后會顯示鏈路狀態(tài)如下圖：Reliance 項目典型案例總結(jié)（第四期）2022418 第 29 頁, 共 117 頁圖：鏈路狀態(tài)示圖A接口失敗原因可能性較多，應(yīng)首先抓住問題出現(xiàn)的特點進行查詢分析