KPI指標(biāo)提升案例

1、起呼問題的處理流程： 信號(hào)快衰造成未接通：【事件描述】國力大酒店3小區(qū)在豐潭路上有快衰現(xiàn)象，在該路段國力大酒店3小區(qū)信號(hào)迅速衰減至-90dBm，造成起呼失敗。信號(hào)快衰導(dǎo)致重選不及時(shí)【解決措施】現(xiàn)場調(diào)整國力大酒店3小區(qū)的機(jī)械下傾角由原來的610【優(yōu)化結(jié)果】調(diào)整之后在豐潭路復(fù)測多次，此問題路段已不會(huì)切至國力大酒店3小區(qū)。調(diào)整后切換關(guān)系圖 跨RNC遷移時(shí)，被叫connect消息沒有直傳導(dǎo)致未接通【事件描述】在中河北路上，主叫呼被叫，被叫響應(yīng)尋呼。22：33：26，被叫向網(wǎng)絡(luò)側(cè)發(fā)起connect消息時(shí)，被叫正在從同發(fā)財(cái)富1小區(qū)跨RNC遷移到文苑賓館2小區(qū)，被叫connect消息不能直傳到CN而導(dǎo)致主叫

2、未接通。被叫路測截圖被叫在源RNC上沒有上報(bào)connect直傳消息，如下：被叫在目標(biāo)RNC上沒有上報(bào)connect直傳消息，如下：【事件原因】 在起呼過程中，主被叫完成RAB建立，但是被叫發(fā)生了跨RNC切換，被叫在目標(biāo)RNC發(fā)出送的connect消息，主叫在源RNC收不到CN下發(fā)的connect消息?！窘鉀Q措施】需針對(duì)RNC邊界進(jìn)行優(yōu)化（也即進(jìn)行LAC區(qū)優(yōu)化）。RNC規(guī)劃的推薦原則：在規(guī)劃RNC區(qū)時(shí)，需要盡可能的利用環(huán)境因素，減少RNC間的信令/數(shù)據(jù)流量，避免出現(xiàn)頻繁的跨RNC間切換。（注：此種情況一定要注意，像杭州一個(gè)RNC一個(gè)MSC出現(xiàn)頻繁的跨RNC重選或切換會(huì)帶來主叫在起呼過程中RAB建

3、立完成發(fā)生切換至另外一個(gè)RNC導(dǎo)致收不到被叫發(fā)送的connect而導(dǎo)致未接通）如果存在兩個(gè)以上的RNC區(qū)，在高話務(wù)的大城市，可以利用市區(qū)中山體、河流等地形因素來作為RNC區(qū)的邊界，減少兩個(gè)RNC區(qū)下不同小區(qū)的交疊深度。如果不存在這樣的地理環(huán)境，RNC區(qū)的劃分盡量不要以街道為界，邊界不要放在話務(wù)量很高的地方（比如商場）。一般要求RNC區(qū)邊界不與街道平行或垂直，而是斜交。在市區(qū)和城郊交界區(qū)域，一般將RNC區(qū)的邊界放在城郊區(qū)域外圍一線話務(wù)量相對(duì)小的基站處，而不是放在話務(wù)密集的城郊結(jié)合部，避免結(jié)合部用戶出現(xiàn)頻繁的跨RNC間切換。 IMSI UNKNOWN IN VLR導(dǎo)致未接通【事件描述】車輛由南向北

4、行駛在豐譚路上，在豐譚路左轉(zhuǎn)至天目山路路口處，主叫UE由亞洲城2(40701)重選至國力大酒店2(40262)，未能及時(shí)進(jìn)行位置更新即起呼，造成CM SERVICE REJECT，cause為IMSI UNKNOWN IN VLR。主叫路測截圖【事件原因】該用戶在其他的Server上做了位置更新，且HLR通知了本Server刪除掉用戶數(shù)據(jù)。由于該用戶沒有在本Server上做位置更新，也就是說，本Server上是沒有該用戶的數(shù)據(jù)的，所以當(dāng)該用戶在本Server上發(fā)起呼叫時(shí)，核心網(wǎng)直接拒掉，拒絕原因值為”IMSI Unknown in VLR”?！窘鉀Q措施】關(guān)于該問題，核心網(wǎng)的MAP功能配置里有個(gè)

5、選項(xiàng)可以解決此問題：該開關(guān)的說明如下：IFVLRLU 支持主叫無用戶數(shù)據(jù)時(shí)發(fā)起獨(dú)立位置更新操作當(dāng)漫游到本局的移動(dòng)用戶向網(wǎng)絡(luò)發(fā)起主叫業(yè)務(wù)接入請(qǐng)求時(shí)，如果MSOFTX3000在向本局VLR查詢?cè)撘苿?dòng)用戶的用戶數(shù)據(jù)時(shí)發(fā)現(xiàn)該數(shù)據(jù)處于“未證實(shí)”狀態(tài)，該參數(shù)用于指示MSOFTX3000是否重新發(fā)起位置更新操作以獲取用戶數(shù)據(jù)，系統(tǒng)初始設(shè)置值為“不支持”。對(duì)于上述情況下的呼叫，若將該參數(shù)設(shè)為“不支持”，則MSOFTX3000將直接拒絕該移動(dòng)用戶的業(yè)務(wù)接入請(qǐng)求；若將該參數(shù)設(shè)為“支持”，則MSOFTX3000將重新發(fā)起位置更新操作以獲取該移動(dòng)用戶的用戶數(shù)據(jù)、在獲取用戶數(shù)據(jù)后將繼續(xù)接續(xù)本次呼叫。 使用的效果如下：若

6、將該參數(shù)設(shè)為“是”，則當(dāng)移動(dòng)用戶向網(wǎng)絡(luò)發(fā)起位置更新請(qǐng)求時(shí)，如果正常的由HLR執(zhí)行的位置更新操作出現(xiàn)失敗的情況，MSOFTX3000可以直接通過VLR繼續(xù)執(zhí)行位置更新流程。確保了UE進(jìn)行重新登記。即：如果遇到”IMSI Unknown in VLR”的現(xiàn)象，則本次呼叫不會(huì)直接拒絕掉，而是由VLR發(fā)起一次位置更新，位置更新成功后，呼叫繼續(xù)，確保了用戶可以正常接入。 因此，該參數(shù)的修改是可以提高AMR和VP的接通率的。注：此開關(guān)的打開只適用于華為的交換，此開關(guān)的打開可能會(huì)帶來充值出錯(cuò)、串話的問題，此開關(guān)的打開要慎重，此可以在集團(tuán)測試期間打開即可 2/3G位置更新導(dǎo)致主叫未接通【事件描述】測試車輛沿文

7、二西路由西向東行駛，UE在西湖區(qū)政府服務(wù)中心2（頻點(diǎn)：10096 ，擾碼：67）起呼成功，進(jìn)入振鈴狀態(tài)，持續(xù)20秒鐘未與被叫建立通話，導(dǎo)致主叫未接通?！臼录颉客ㄟ^對(duì)主被叫信令分析知，在起呼的過程中，被叫正在從GSM重選回TD，未完成位置區(qū)更新導(dǎo)致收不到網(wǎng)絡(luò)側(cè)下發(fā)的Paging消息導(dǎo)致起呼失敗?！窘鉀Q及規(guī)避措施】1. 增強(qiáng)覆蓋，較小23G重選和切換次數(shù)2. 如果是華為交換可以采取以下的方法來進(jìn)行規(guī)避 將TD同GSM割接到同一個(gè)目標(biāo)交換上（在同一個(gè)MSC下，TD RNC的覆蓋區(qū)域同GSM的BSC覆蓋區(qū)域一致） 打開CN側(cè)軟參P1100 Bit1含義解釋： 控制是否啟動(dòng)位置更新與尋呼同時(shí)進(jìn)行，以

8、提高尋呼成功率。如果位置更新失敗、或者是位置更新過程有手機(jī)發(fā)送的follow on消息，則尋呼失敗。 =0： 啟動(dòng)。 =1： 不啟動(dòng)。 默認(rèn)值：1。應(yīng)用場景 場景1：當(dāng)手機(jī)在進(jìn)行位置更新，這個(gè)時(shí)候該手機(jī)做被叫；設(shè)置該該軟參bit1值為1，則該手機(jī)做被叫失敗，呼叫不能接通；設(shè)置該軟參bit1值為0，MSC Server會(huì)在手機(jī)位置更新完成后，下尋呼接通呼叫。 場景2：當(dāng)手機(jī)做被叫時(shí)，開始位置更新。設(shè)置該軟參bit1值為1，則該手機(jī)做被叫失敗，呼叫不能接通。設(shè)置該軟參bit1值為0，MSC Server會(huì)在手機(jī)位置更新完成后，下尋呼接通呼叫。 設(shè)置該軟參bit1值為0，能提高尋呼成功率。 注：手機(jī)

9、發(fā)送follow on 的場景是用戶在按鍵撥號(hào)的時(shí)候，手機(jī)自動(dòng)發(fā)起位置更新。這個(gè)時(shí)候手機(jī)會(huì)發(fā)送 follow on 消息，通知MSC Server ，讓后續(xù)的呼叫接通。修改腳本：修改P1100 Bit1為0MOD MSFP: ID=P1100, MODTYPE=P1, BIT=1, BITVAL=0; 2、針對(duì)3G位置區(qū)增加尋呼策略功能說明：目前現(xiàn)網(wǎng)2G尋呼策略為尋呼2次，間隔4S，而3G向2G進(jìn)行小區(qū)重選過程中，重選時(shí)間較長，超過4S，導(dǎo)致第一次尋呼無響應(yīng)，此時(shí)可適當(dāng)增加第一次尋呼時(shí)長解決，修改為6S。修改腳本：增加3G位置區(qū)尋呼策略ADD PGCTRL: LAI=46000D505, TY

10、PE=ALL, TIMES=2, FIRSTD=6, SECONDD=4, IMSI=FIRST-0&SECOND-0, ALLRAN=FIRST-0&SECOND-0; UPPCH存在干擾導(dǎo)致起呼失敗【事件描述】現(xiàn)場工程師在路測過程中，發(fā)現(xiàn)某個(gè)小區(qū)無法正常建立業(yè)務(wù)；該小區(qū)在多次呼叫中，均失敗，從前臺(tái)路測儀看，UE上報(bào)4條 RRC CONNECT REQUEST消息后接收系統(tǒng)消息，后臺(tái)信令跟蹤沒有任何信令?！臼录颉?從現(xiàn)場的測試反饋來看，起呼失敗的原因?yàn)閁E發(fā)送的RRC CONNECT REQUEST RNC收不到，導(dǎo)致起呼失敗，從現(xiàn)場判斷初步懷疑是UP收到干擾，從后臺(tái)查詢?cè)撔^(qū)的UPPC

11、H ISCP 為92dbm，存在一定的干擾。UP存在干擾導(dǎo)致UE無法同NODEB進(jìn)行上行同步,，雖然路測儀上出現(xiàn)RRC CONNECT REQUEST消息，是UE L3吐在路測儀上的，實(shí)際是沒有發(fā)送的。上行同步的流程如下： 【解決及規(guī)避措施】 采用upshifting 技術(shù)，將UP位置從“0”調(diào)整為“22”。修改命令：MOD UPPCH UP位置調(diào)整后，通過查詢UPPCH ISCP為108dbm,現(xiàn)場測試起呼正常。 上行ISCP設(shè)置較小導(dǎo)致起呼失敗【事件描述】現(xiàn)場工程師在路測過程中，發(fā)現(xiàn)在某小區(qū)下信號(hào)質(zhì)量良好（PCCPCH RSCP = -65dbm,C/I=10db）起呼過程中RRC連接建立

12、出現(xiàn)大量的超時(shí)，從路測儀上看UE發(fā)送RRC connect complete后直解接收系統(tǒng)消息導(dǎo)致RRC建立失敗，從后臺(tái)的信令跟蹤看，RNC沒有收到UE發(fā)送的RRC connect complete?！臼录治觥?從現(xiàn)象看，是NODEB無法解調(diào)UE發(fā)送的RRC connect complete消息，初步懷疑是該小區(qū)上行存在干擾或上行發(fā)射功率過小。 后臺(tái)查詢?cè)撔^(qū)TS1、TS2的上行ISCP為109dbm，正常不存在干擾。 通過現(xiàn)場的撥測發(fā)現(xiàn)，UE在發(fā)送在RRC connect complete消息是UE的發(fā)射功率為35dbm，發(fā)射功率過小。 上行開環(huán)功率計(jì)算UE的發(fā)射功率的公式如下：UE的初始

13、發(fā)射功率initialSIRtarget + UL_ISCP + UL_Margin + Lpccpch(路損)通過后臺(tái)的查詢LDM中ISCP測量是關(guān)閉，在計(jì)算上行初始發(fā)身功率時(shí)采用后臺(tái)上行ISCP設(shè)置，查詢得默認(rèn)ISCP =-1000dbm,UL_Margin =3db,Lpccpch 115，通過查看參數(shù)設(shè)置上行的ISCP設(shè)置過小【解決及規(guī)避措施】通過前期的測試上行ISCP一般設(shè)置為90dbm，最好是打開LDM中上行ISCP的測量（命令：ADD CELLLDM），打開測量計(jì)算上行的發(fā)射功率更加準(zhǔn)確一點(diǎn)，通過參數(shù)調(diào)整后，現(xiàn)場撥測起呼成功率為100?！究偨Y(jié)】 針對(duì)接通率指標(biāo)的提升，有以下幾個(gè)問

14、題需要注意： LAC區(qū)、RNC邊界的合理劃分 良好的覆蓋（包括切換合理），盡量較少23G的互操作次數(shù)和重選次數(shù) 上行功控參數(shù)的合理設(shè)置 空口質(zhì)量良好（PCCPCH -90dbm,C/I 0），杜絕緊密鄰區(qū)出現(xiàn)同頻 故障站點(diǎn)的及時(shí)排障現(xiàn)網(wǎng)中造成掉話的主要原因包括：弱覆蓋導(dǎo)致的掉話、切換失敗導(dǎo)致的掉話（尤其是同頻切換）、異系統(tǒng)切換失敗導(dǎo)致的掉話、干擾掉話（包括系統(tǒng)內(nèi)、系統(tǒng)間干擾）、鄰區(qū)漏配、SRB復(fù)位等原因掉話分析流程如下： 未及時(shí)重選導(dǎo)致掉話【事件描述】時(shí)間：20：20：12，UE由南向北行駛在石祥路上時(shí)，右轉(zhuǎn)到上塘路時(shí)，剛好完成上次呼叫，UE沒有重選至G網(wǎng)小區(qū)重選到瓜山造紙3小區(qū)，而選到信號(hào)較

15、差的名城左岸1小區(qū)后起呼，被叫UE在收到尋呼消息時(shí),PCCPCH RSCP在-105dbm左右,C/I-10db。被叫UE掉話?！臼录颉縐E因?yàn)闆]能由G網(wǎng)小區(qū)重選到最佳T小區(qū)，導(dǎo)致UE占用信號(hào)較弱小區(qū)起呼，導(dǎo)致掉話。 (UE占用G網(wǎng)小區(qū)，重選到T網(wǎng)前) （UE由G網(wǎng)重選回T網(wǎng)，沒能重選到最佳的小區(qū)）【解決措施】通過調(diào)整覆蓋避免重選后占用小區(qū)信號(hào)過弱 release-due-to-utran-generated-reason導(dǎo)致掉話【事件描述】11:26:45，UE由西向東行駛在鳳起路上，UE占用五鑫大酒店3小區(qū)信號(hào)，切換到1小區(qū)后，主叫UE掉話。【事件原因】查看RNC側(cè)信令 IU-rele

16、ase，其原因值為：release-due-to-utran-generated-reason。主叫UE圖RNC信令圖 先報(bào)1g后報(bào)2a導(dǎo)致掉話【事件描述】1:24:57，車輛由西向東行駛在機(jī)場高速上，車輛路過寧新村基站，主叫占用寧新村3(52252)進(jìn)行起呼，起呼時(shí)RSCP=-75，RAB指配完成后，RSCP=-96，同頻切換至較遠(yuǎn)的新中村1(2888)，造成掉話?！臼录颉?g切換判決先于2A發(fā)送，導(dǎo)致首先觸發(fā)1g事件未至最優(yōu)小區(qū)寧新村2(42252)。UE測試圖【解決措施】1，更換同頻小區(qū)的頻點(diǎn)2，調(diào)整1g事件觸發(fā)門限為8 23G切換失敗 LAC漏配導(dǎo)致2G3G互操作中2G到3G PS

17、域業(yè)務(wù)切換失敗問題分析【事件描述】在某TD商用網(wǎng)與GSM網(wǎng)絡(luò)互操作測試中，我們發(fā)現(xiàn)在某一基站下，2G到3G網(wǎng)絡(luò)的重選和3G到2G的重選，以及3G到2G的PS域業(yè)務(wù)的切換都成功了，但是在2G到3G的PS域業(yè)務(wù)切換中發(fā)生了異常。測試所用的手機(jī)為大唐DT8120，軟件為NTASProfessionalTester2.2.0.630版。經(jīng)檢查，軟件和手機(jī)功能正常，排除設(shè)備問題。因此懷疑網(wǎng)絡(luò)參數(shù)配置問題?！臼录颉?.首先我們要了解在PS域業(yè)務(wù)切換過程中，終端在收到切換命令后，使用重選過程來輔助PS業(yè)務(wù)的切換，之后進(jìn)行相應(yīng)的位置區(qū)更新和路由區(qū)更新，最后進(jìn)行用戶面的業(yè)務(wù)恢復(fù)。2.在軟件信令圖中我們看到了

18、LocationUpdatingAccept，說明位置區(qū)更新成功，由于位置區(qū)更新是在目標(biāo)MSC中進(jìn)行，所以我們排除3GMSC中參數(shù)配置錯(cuò)誤的可能性。3.之后UE目標(biāo)RNC、核心網(wǎng)建立信令連接，并觸發(fā)路由區(qū)更新。此時(shí)發(fā)生路由區(qū)更新失敗，路由區(qū)更新是3G-SGSN與UE之間建立的，因此我們問題定位在3GSGSN核心網(wǎng)側(cè)?！窘鉀Q措施】與3GSGSN工程師溝通后確認(rèn)3G漏配了對(duì)應(yīng)2G鄰區(qū)的LAC導(dǎo)致身份認(rèn)證操作失敗，路由區(qū)更新被拒絕，3GSGSN補(bǔ)全數(shù)據(jù)配置后路由區(qū)更新成功。 2G鄰區(qū)中頻點(diǎn)配置錯(cuò)誤導(dǎo)致TD至G網(wǎng)無法切換【事件描述】在簇18進(jìn)行PS業(yè)務(wù)2G3G互操作測試時(shí)，在TD信號(hào)已達(dá)到-95dB以下時(shí)，網(wǎng)絡(luò)側(cè)已下發(fā)3A測量控制，但手機(jī)遲遲不發(fā)3A測量報(bào)告，依然無法切換?！臼录颉?、開始出現(xiàn)此現(xiàn)象時(shí)在路測軟件上沒有看到2G鄰區(qū)，立即聯(lián)系后臺(tái)維護(hù)人員，經(jīng)確認(rèn)，鄰區(qū)已添加；行駛十幾米后，路測軟件和手機(jī)顯示確有2G鄰區(qū)。2、嘗試在旁邊的另外一個(gè)小區(qū)進(jìn)行相同測試，問題依然存在，排除是偶然現(xiàn)象的可能；3、后來發(fā)現(xiàn)一個(gè)規(guī)律，在路測軟件上顯示的2G鄰區(qū)只有一個(gè)，且頻點(diǎn)一直是9