【正文】 值，正常，排查干擾因素；檢查PN復(fù)用情況，發(fā)現(xiàn)該站附近有兩個(gè)基站（BTS ID分別為391和493）PN復(fù)用，距離小于10Km。將其中一個(gè)基站修改PN后（注意：三個(gè)扇區(qū)的PN都要修改，另外修改完畢后要復(fù)位基站），掉話(huà)率下降到2％左右。進(jìn)一步檢查鄰區(qū)，發(fā)現(xiàn)一個(gè)距該基站58km 處PN為204的一個(gè)基站（BTS ID為290）與之配置了鄰區(qū)關(guān)系，且優(yōu)先級(jí)為2，不符合正常配置原則；而該基站附近七八公里的一個(gè)基站（BTS ID為391）的1扇區(qū)PN也為204。在鄰區(qū)列表中將290基站刪除，添加391基站，修改后掉話(huà)率下降到1％左右。 【建議總結(jié)】本案例中有兩個(gè)主要原因，一是PN復(fù)用，二是鄰區(qū)錯(cuò)配。掉話(huà)率非常高的情況下，需要優(yōu)先檢查這兩個(gè)方面。 新開(kāi)站 PN 復(fù)用距離不足導(dǎo)致周邊站點(diǎn)掉話(huà)率惡化（李向陽(yáng)）【現(xiàn)象描述】Reliance 項(xiàng)目典型案例總結(jié)（第四期）2022418 第 36 頁(yè), 共 117 頁(yè)147站開(kāi)通后，該區(qū)域站點(diǎn)掉話(huà)率上升【問(wèn)題分析及處理措施】1．查看該區(qū)域站點(diǎn)告警和傳輸: 無(wú)2．檢查分析該區(qū)域站點(diǎn)連續(xù)幾天的話(huà)統(tǒng)數(shù)據(jù), 找出KPI惡化的時(shí)間點(diǎn)3．檢查該時(shí)間點(diǎn)前后有何操作, 查詢(xún)知在147，148號(hào)新站開(kāi)通后，該區(qū)域掉話(huà)率上升4．檢查該區(qū)域的搜索窗和鄰區(qū)配置, ，發(fā)現(xiàn)補(bǔ)配鄰區(qū)添加失敗，現(xiàn)象為“The neighbor carriers of Samefrequency exist duplicated PN with Idle HO relation. Operation failed”此處表明在配置的鄰區(qū)關(guān)系有兩個(gè)載頻PN相同。5．檢查該區(qū)域的PN復(fù)用使用Mapinfo地圖檢查，發(fā)現(xiàn)新開(kāi)站147號(hào)站和未開(kāi)通的75號(hào)站的PN皆為“111/279/447”。【解決方案amp。總結(jié)】修改75 號(hào)站點(diǎn)PN ，重新添加鄰區(qū)，問(wèn)題解決；在制作鄰區(qū)腳本時(shí)，一般參照Mapinfo地圖或APUS制作鄰區(qū)列表，這里可能將未開(kāi)通的站點(diǎn)配為鄰區(qū)。這里需要注意幾點(diǎn)：Reliance 項(xiàng)目典型案例總結(jié)（第四期）2022418 第 37 頁(yè), 共 117 頁(yè)1. 由于站點(diǎn)一般在深夜開(kāi)通，本地 RF 工程師往往將腳本發(fā)送給 B 側(cè)進(jìn)行添加，由于印度人的特性，往往不對(duì)結(jié)果進(jìn)行監(jiān)控（耳提面命多次，希望渺茫），同樣 B 側(cè)本地工程師只負(fù)責(zé)腳本的添加，不關(guān)注運(yùn)行結(jié)果；針對(duì)此項(xiàng)，最好讓 RF 工程師運(yùn)行RF 腳本，并每次保存運(yùn)行結(jié)果，并檢查；2. 由于 B 側(cè)工程師常常下發(fā)一片區(qū)域的 BTS 腳本（這些站點(diǎn)可能很長(zhǎng)一段時(shí)間都不會(huì)開(kāi)通），所以依靠 Nastar 無(wú)法保證 PN 復(fù)用檢查結(jié)果的可靠性，應(yīng)結(jié)合站點(diǎn)信息表和 Mapinfo 地圖進(jìn)行檢查。 利用 PSMM 優(yōu)化鄰區(qū)不當(dāng)導(dǎo)致高掉話(huà)率（剛偉）【現(xiàn)象描述】客戶(hù)投訴TN circle Tirunevelli BSC 1下的283號(hào)基站（S111）掉話(huà)率很高，忙時(shí)三載扇的平均掉話(huà)率達(dá)到10%以上，有的扇區(qū)甚至高達(dá) 25%?！締?wèn)題分析】分析話(huà)統(tǒng)數(shù)據(jù)，Nastar顯示掉話(huà)原因都為 “Too many Erasure frames”，即空口原因引起的，排除了設(shè)備故障、傳輸?shù)绕渌蛩?。于是，我們首先分析該基站的參?shù)配置、PN復(fù)用等情況，均未發(fā)現(xiàn)異常；用M2022查詢(xún)整月數(shù)據(jù)，發(fā)現(xiàn)之前該基站掉話(huà)率一直屬正常范圍，只是從當(dāng)月8號(hào)下午突然惡化，如圖：按小時(shí)匯總8號(hào)的數(shù)據(jù)，發(fā)現(xiàn)下午7點(diǎn)左右掉話(huà)率突然升高。Reliance 項(xiàng)目典型案例總結(jié)（第四期）2022418 第 38 頁(yè), 共 117 頁(yè)開(kāi)始懷疑可能是周邊新開(kāi)站對(duì)其指標(biāo)產(chǎn)生的影響，可是查詢(xún)后并未發(fā)現(xiàn)當(dāng)時(shí)周邊有新開(kāi)基站。后在維護(hù)臺(tái)查詢(xún)8號(hào)下午的操作記錄，發(fā)現(xiàn)下午6點(diǎn)左右該基站有修改鄰區(qū)的操作，(后來(lái)證實(shí)為本地員工利用PSMM消息對(duì)該基站進(jìn)行了鄰區(qū)優(yōu)化)。深入檢查所配鄰區(qū)關(guān)系，發(fā)現(xiàn)： 冗余鄰區(qū)較多，3 載扇平均鄰區(qū)數(shù)目都在 25 個(gè)以上。 鄰區(qū)配置錯(cuò)誤，結(jié)合地理化顯示來(lái)看：283的α扇區(qū)本應(yīng)配272α為鄰區(qū)，可是根據(jù) Nastar的自動(dòng)優(yōu)化結(jié)果卻配置了距離100千米以外的另一扇區(qū)為鄰區(qū)，而且優(yōu)先級(jí)很高（該扇區(qū)PN與 272α 扇區(qū)PN相同）；同樣，本應(yīng)配置547β為鄰區(qū)的β扇區(qū)，也錯(cuò)誤的配置了相距40多千米另一扇區(qū)（該扇區(qū) PN與547β的PN 相同）。所以判斷是鄰區(qū)優(yōu)化不當(dāng)造成該基站掉話(huà)率飆升?！咎幚泶胧?6日15時(shí)重新優(yōu)化鄰區(qū)，掉話(huà)率立即恢復(fù)正常，問(wèn)題得到解決。Reliance 項(xiàng)目典型案例總結(jié)（第四期）2022418 第 39 頁(yè), 共 117 頁(yè)【問(wèn)題總結(jié)】在利用PSMM 消息進(jìn)行鄰區(qū)優(yōu)化時(shí)，一定不能完全照搬Nastar自動(dòng)生成的優(yōu)化結(jié)果。因?yàn)镻SMM 消息只上報(bào) PN時(shí)延而不包括扇區(qū)信息（即只認(rèn)PN 不認(rèn)扇區(qū)），所以Nastar在處理PSMM消息時(shí)會(huì)按照上報(bào)的PN 在鄰區(qū)列表中尋找相匹配的扇區(qū)，而當(dāng)鄰區(qū)列表中沒(méi)有與之相對(duì)應(yīng)的扇區(qū)信息時(shí)，則會(huì)在整個(gè)BSC 下的小區(qū)列表中重新尋找。這時(shí)如果BSC 下該P(yáng)N存在復(fù)用時(shí)，Nastar則會(huì)“隨機(jī) ”（算法未知）指定為某一扇區(qū)，從而可能造成優(yōu)化結(jié)果的錯(cuò)誤。從實(shí)際結(jié)果看，經(jīng)常會(huì)出現(xiàn)相距上百千米的兩扇區(qū)被認(rèn)定為需要互配鄰區(qū)的情況。如果按照此錯(cuò)誤信息進(jìn)行鄰區(qū)優(yōu)化，則會(huì)造成大量掉話(huà)。所以我們?cè)诶肞SMM做鄰區(qū)優(yōu)化時(shí)，一定要結(jié)合著MapInfo的地理化顯示同步進(jìn)行。另外，我們?cè)谔幚矶ㄎ粏?wèn)題時(shí)有時(shí)想的過(guò)于復(fù)雜，卻忽略了最基本的問(wèn)題，但往往就是因?yàn)橐恍┛此坪?jiǎn)單、基本的事情沒(méi)有做好，而產(chǎn)生了很多“疑難雜癥”。所以我們?cè)谄綍r(shí)工作時(shí)要盡量把簡(jiǎn)單的問(wèn)題處理好，減少那些不必要的麻煩。 直放站參數(shù)不合理導(dǎo)致掉話(huà)率高（徐斌斌）【案例索引關(guān)鍵詞】 掉話(huà) 直放站 反向增益 CHR【案例描述】I國(guó)搬遷項(xiàng)目中，某BSC下1號(hào)站2扇區(qū)掉話(huà)率高，調(diào)整鄰區(qū)、導(dǎo)頻增益、切換參數(shù)、搜索窗等均無(wú)效?！咎幚磉^(guò)程】先是通過(guò)調(diào)整鄰區(qū)、導(dǎo)頻增益、切換參數(shù)、搜索窗等手段進(jìn)行優(yōu)化，均無(wú)效。Reliance 項(xiàng)目典型案例總結(jié)（第四期）2022418 第 40 頁(yè), 共 117 頁(yè)通過(guò)CHR分析，發(fā)現(xiàn)該扇區(qū)的掉話(huà)大部分為反向受限。分析該扇區(qū)接有直放站，而且主集RSSI和分集RSSI均為105dBm左右，過(guò)于正常。因此懷疑是直放站前反向增益不平衡造成反向掉話(huà)高。通知局方，提高了直放站的反向增益，該站掉話(huà)率得到改善。從CHR分析，反向掉話(huà)大幅度減少?！窘Y(jié)論】Nastar的CHR分析功能中，能夠分析掉話(huà)是前向鏈路還是反向鏈路的原因，對(duì)于直放站下的反向掉話(huà)，調(diào)整其反向增益是常用的手段之一。 124 基站無(wú)法與周邊基站軟切換導(dǎo)致掉話(huà)率高問(wèn)題（姜偉）【現(xiàn)象描述】124基站各扇區(qū)掉話(huà)率均較高，在5％以上。【問(wèn)題分析及處理】在分析PSMM數(shù)據(jù)時(shí)發(fā)現(xiàn)，124基站BAM配置優(yōu)先級(jí)比較高的鄰區(qū)沒(méi)有切換，而一些優(yōu)先級(jí)比較低的鄰區(qū)切換次數(shù)反而較多。是否是鄰區(qū)優(yōu)先級(jí)配置不合理呢？結(jié)合地圖分析發(fā)現(xiàn)：鄰區(qū)優(yōu)先級(jí)配置基本合理，確實(shí)是本基站與周邊一圈基站（均已開(kāi)通）在PSMM里面均沒(méi)有切換次數(shù)，而相隔較遠(yuǎn)的基站切換次數(shù)反而較多。檢查話(huà)統(tǒng)發(fā)現(xiàn)該基站各載扇的軟切換次數(shù)遠(yuǎn)大于更軟切換次數(shù)，說(shuō)明是有軟切換的，而且軟切換成功率都在99％以上。檢查時(shí)鐘，該基站狀態(tài)為L(zhǎng)ocked，偶爾有“Communication Link Between BCKM Satellite Card and BCKM Disconnected”的告警。疑惑不解，到現(xiàn)場(chǎng)路測(cè)，發(fā)現(xiàn)現(xiàn)象如下：Reliance 項(xiàng)目典型案例總結(jié)（第四期）2022418 第 41 頁(yè), 共 117 頁(yè) 在基站附近Markov呼叫時(shí)FER正常，如果是時(shí)鐘異常的話(huà)，一般來(lái)說(shuō)Markov呼叫的FER會(huì)較高。 無(wú)法與周邊基站進(jìn)行軟切換。會(huì)瞬間FER升高到100％直至掉話(huà)。掉話(huà)前無(wú)任何PSMM上報(bào)。掉話(huà)后搜到其他基站強(qiáng)導(dǎo)頻并可正常上網(wǎng)。 從周邊基站往本基站亦無(wú)法切換，仍然是沒(méi)有任何PSMM上報(bào)。 測(cè)試了多個(gè)基站均如此。由于有時(shí)鐘方面的告警，所以雖然Markov呼叫正常，但仍重點(diǎn)往時(shí)鐘方面考慮處理。主備倒換BCKM無(wú)效。復(fù)位基站無(wú)效。不得已，遠(yuǎn)端用命令下電重啟基站解決。之后觀(guān)察掉話(huà)率由5％以上降低到1％以下，路測(cè)時(shí)可以正常切換，PSMM 里面看也可以與周邊基站正常切換。【問(wèn)題總結(jié)】目前遇到的不能切換的問(wèn)題五花八門(mén)，即使話(huà)統(tǒng)里面有軟切換且成功率很高，也不一定路測(cè)時(shí)就可以正常切換，需要仔細(xì)檢查。Reliance 項(xiàng)目典型案例總結(jié)（第四期）2022418 第 42 頁(yè), 共 117 頁(yè)3 切換問(wèn)題總結(jié) BSC 間軟切換與呼叫遷移案例分析(王一兵)【現(xiàn)象描述】Raipur BSC1下屬 BTS402掉話(huà)率非常高，其中Sector1和Sector2的掉話(huà)率分別為6％和3％。從話(huà)統(tǒng)分析掉話(huà)原因，除了通常掉話(huà)原因CS Call Drops (Too many Erasure frames)之外，還有CS Call Drops (A2 interface abnormal)，即A2 接口不正常導(dǎo)致的掉話(huà)，次數(shù)是Too many Erasure frames的兩倍。BtsIdCellIdSectorIdCarrierIdPNAFRCNTime(hour)CS Call Drop Ratio[%]CS Call Drops (Too many Erasure frames)[Times]CS Call Drops (A2 interface abnormal)[Times]40240211225410 20221113 19:00:00 23 340240212225451 20221113 19:00:00 14 1940240213225369 20221113 19:00:00 8 2040240221393410 20221113 19:00:00 16 2740240222393451 20221113 19:00:00 13 2340240223393369 20221113 19:00:00 13 45【問(wèn)題分析】BTS402處于Raipur兩個(gè)BSC邊界，與另一個(gè)BSC 之間是A3A7軟切換。查看InterBS Soft HO Success Ratio[%]，成功率在 97％以上，沒(méi)有問(wèn)題。繼續(xù)分析話(huà)統(tǒng)，發(fā)現(xiàn)有許多BSC間硬切換請(qǐng)求，這些硬切換請(qǐng)求全部都失敗，失敗次數(shù)與A2 接口不正常導(dǎo)致的掉話(huà)次數(shù)相當(dāng)?？梢?jiàn)BSC間硬切換失敗是 A2接口掉話(huà)的主要原因。BtsIdCellIdSectorIdCarrierIdPNAFRCNTime(hour)CS Call Drops (A2 interface abnormal)[Times]InterBS Outgoing Hard HO Requests[Times]InterBS Outgoing Hard HO Failures (Other causes)[Times]40240211225410 20221113 19:00:00 3 3 340240212225451 20221113 19:00:00 19 24 2440240213225369 20221113 19:00:00 20 22 2240240221393410 20221113 19:00:00 27 29 2940240222393451 20221113 19:00:00 23 22 2240240223393369 20221113 19:00:00 45 47 47BSC間硬切換實(shí)際上就是呼叫遷移。下面簡(jiǎn)單介紹一下從BSC 間軟切換到BSC間呼叫Reliance 項(xiàng)目典型案例總結(jié)（第四期）2022418 第 43 頁(yè), 共 117 頁(yè)遷移的原理及過(guò)程。BSC通過(guò)A3A7鏈路實(shí)現(xiàn)BSC間軟切換。當(dāng)源BSC 收到的PSMM消息中包含目標(biāo)BSC的PN時(shí)，源BSC 通過(guò)A7鏈路向目標(biāo)BSC申請(qǐng)切換資源。目標(biāo) BSC準(zhǔn)備好切換資源，并建立與源BSC間的A3鏈路，通過(guò)A3 鏈路把信號(hào)傳送到源BSC 。在軟切換狀態(tài)，幀合并和解碼功能均在源BSC實(shí)現(xiàn)，目標(biāo)BSC只是提供無(wú)線(xiàn)鏈路。當(dāng)源BSC無(wú)線(xiàn)信號(hào)變?nèi)鯐r(shí)，需要釋放掉源 BSC的無(wú)線(xiàn)資源和 BSC資源，把所有呼叫資源轉(zhuǎn)移到目標(biāo)BSC。這一過(guò)程叫做呼叫遷移。呼叫遷移過(guò)程需要 MSC的參與，源BSC向MSC發(fā)送硬切換請(qǐng)求，MSC再通知目標(biāo)BSC建立呼叫資源，并向源BSC發(fā)送切換完成消息。再回到這個(gè)案例，從Runlog中看， BTS402掉話(huà)原因是MSC_REL_EQUIPMENT_FAIL（Case ：0x120），是MSC在指配鏈路時(shí)失敗。綜合以上分析可以得出結(jié)論，BTS402的A2 接口掉話(huà)是在呼叫遷移過(guò)程中的掉話(huà)?！窘鉀Q方案】在兩個(gè)BSC邊界路測(cè)，跟蹤呼叫遷移信令，經(jīng)定位后確認(rèn)原因是N 側(cè)和B 側(cè)使用的A2P承載格式不一致導(dǎo)致。N 側(cè)使用的是標(biāo)準(zhǔn)承載格式，這也是Reliance客戶(hù)所要求的，而B(niǎo)側(cè)使用的是華為私有格式，由于格式不一樣最終導(dǎo)致MSC在鏈路指配時(shí)失敗。源BSC呼叫資源已經(jīng)釋放，目標(biāo)BSC呼叫資源建立失敗，因此導(dǎo)致 BSC間硬切換掉話(huà)。將B側(cè)使用的A2P承載格式改為標(biāo)準(zhǔn)格式后， BSC間硬切換成功率升至70％以上，