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