安徽公司QCHAT無線質(zhì)量測評匯報

QCHAT無線質(zhì)量測評匯報安徽無線網(wǎng)絡(luò)優(yōu)化中心二○一一年十月0目錄QCHAT測試情況一QCHAT典型事件分析二QCHAT不同尋呼策略指標對比一哪個模版能準確測出網(wǎng)絡(luò)的真實性能？準備工作測試模板分析測試模版呼叫嘗試次數(shù)（有網(wǎng)）呼叫成功次數(shù)呼叫成功率(%)呼叫間隔45s-呼叫超時5s-通話時長90s-ON634876.19%呼叫間隔45s-呼叫超時15s-通話時長90s-ON635993.65%測試模板的關(guān)鍵要素：呼叫間隔時間通話時長連接超時時間安徽測試模板調(diào)整：為了確保每次呼叫能夠采集QCHAT的完整信令，呼叫間隔由20秒調(diào)整為45秒；鼎利連接超時的定義為主叫終端發(fā)送PPTEVENT到收到TonePlayed的間隔，與QCHAT被叫4.5秒超時的定義不一致（服務(wù)器發(fā)出ANNOUNCE到收到ANNOUNCEACK的間隔），連接超時時間由5秒調(diào)整為15秒。阿朗區(qū)測試情況分析－－滁州DT區(qū)域類型覆蓋率呼叫嘗試次數(shù)呼叫成功次數(shù)呼叫失敗次數(shù)接通率掉話次數(shù)掉話率初始呼叫建立時延（s）呼叫建立初始媒體時延(s)通話中話權(quán)轉(zhuǎn)換時延(s)通話中媒體時延(s)市區(qū)短呼ON92.18%2822671594.68%10.38%1.8581.0560.1480.295短呼OFF92.64%2752552092.73%41.57%2.4571.0440.1050.31長呼ON97.60%880100.00%00.00%1.4280.8230.1030.315長呼OFF97.91%990100.00%222.22%1.7050.9360.1140.32國省道短呼OFF87.22%151144795.36%21.39%1.6741.0420.1310.329長呼OFF95.76%990100.00%00.00%1.2711.0540.4820.33尋呼策略配置：四次尋呼，前兩次為Lastactiveset，后兩次為lastseenRNC，尋呼間隔1.5秒。阿朗區(qū)測試情況分析－－合肥DT區(qū)域類型覆蓋率呼叫嘗試次數(shù)呼叫成功次數(shù)呼叫失敗次數(shù)接通率掉話次數(shù)掉話率初始呼叫建立時延（s）呼叫建立初始媒體時延(s)通話中話權(quán)轉(zhuǎn)換時延(s)通話中媒體時延(s)市區(qū)短呼ON（優(yōu)化前）91.47%3393102991.45%41.29%2.2991.0060.1350.292長呼ON（優(yōu)化前）98.10%13130100.00%00.00%1.6991.260.1010.295短呼ON（優(yōu)化后）91.60%2442331195.49%21.29%2.7460.8920.0910.279長呼ON（優(yōu)化后）97.71%990100.00%00.00%2.0160.9830.2210.289短呼OFF92.20%274269598.18%20.74%2.4050.9680.1260.313長呼OFF98.28%550100.00%00.00%1.8580.9270.1090.341國省道、環(huán)城高速短呼OFF87.21%185178796.22%00.00%2.0950.9830.1010.314長呼OFF97.27%880100.00%112.50%2.6520.9330.0980.326尋呼策略配置：四次尋呼，前兩次為Lastactiveset，后兩次為lastseenRNC，尋呼間隔1秒。QoSLicense配置：優(yōu)化前：RNClicense上限控制數(shù)目是300，每個基站上限控制數(shù)目是12優(yōu)化后：RNClicense上限控制數(shù)目是1000，基站281、62上限控制數(shù)目是14，其它基站12阿朗區(qū)測試情況分析－－六安DT區(qū)域類型覆蓋率呼叫嘗試次數(shù)呼叫成功次數(shù)呼叫失敗次數(shù)接通率掉話次數(shù)掉話率初始呼叫建立時延（s）呼叫建立初始媒體時延(s)通話中話權(quán)轉(zhuǎn)換時延(s)通話中媒體時延(s)市區(qū)短呼OFF（優(yōu)化前）93.03%1471024569.39%00%2.6850.9970.1120.319短呼OFF（優(yōu)化后）94.34%233232199.57%00%2.5460.9770.1020.311短呼ON92.38%2822513189.01%10.40%2.870.9170.1050.282長呼ON97.56%98188.89%112.50%3.2420.9170.0910.283長呼OFF98.34%220100%00%3.961.2240.1070.29國省道短呼OFF91.89%452445798.45%00%1.9740.9750.1020.302長呼OFF96.51%22220100%14.55%2.5190.9140.1010.259尋呼策略配置：優(yōu)化前：四次尋呼，前兩次為Lastactiveset，后兩次為lastseenRNC，尋呼間隔2秒；優(yōu)化前：四次尋呼，前兩次為Lastactiveset，后兩次為lastseenRNC，尋呼間隔1秒；中興區(qū)測試情況分析－－馬鞍山DT區(qū)域類型覆蓋率呼叫嘗試次數(shù)呼叫成功次數(shù)呼叫失敗次數(shù)接通率掉話次數(shù)掉話率初始呼叫建立時延（s）呼叫建立初始媒體時延(s)通話中話權(quán)轉(zhuǎn)換時延(s)通話中媒體時延(s)市區(qū)短呼ON91.56%301294797.67%103.74%1.5971.0540.1060.316短呼OFF93.60%255252398.82%41.59%1.3370.9320.2010.273長呼ON97.14%880100%00%1.1760.2370.0960.237長呼OFF96.70%880100%225.00%1.1120.9440.1210.301國省道短呼OFF94.02%7975494.94%22.67%1.4660.8490.1030.29長呼OFF98.51%440100%125%1.0990.8510.3880.312尋呼策略配置：尋呼次數(shù)：2次；尋呼間隔：1.5秒；尋呼范圍：3級，“鄰區(qū)方式RU有效時間RUNLAvailableTime”與“子網(wǎng)方式RU有效時間RUSNAvailableTime”分別為1秒和10秒。阿朗區(qū)測試情況分析－－CQT區(qū)域QoS類型覆蓋率呼叫嘗試次數(shù)呼叫成功次數(shù)呼叫失敗次數(shù)接通率掉話次數(shù)掉話率初始呼叫建立時延（s）呼叫建立初始媒體時延(s)通話中話權(quán)轉(zhuǎn)換時延(s)通話中媒體時延(s)滁州市區(qū)CQTon94.32%478477199.79%10.21%1.46021.02170.08820.3049合肥市區(qū)CQTon94.78%117911592098.30%20.17%1.6130.9610.0920.296六安市區(qū)CQToff98.57%5005000100.00%00.00%1.3450.9840.1320.309安慶市區(qū)CQTon98.30%598592699.00%101.67%1.3171.0960.0970.306CQT測試整體指標較好，失敗原因與DT測試類似目錄QCHAT測試情況一QCHAT典型事件分析二QCHAT不同尋呼策略指標對比一類型次數(shù)分類占比掉話（共3次）2切換未收到TCA消息66.70%1弱覆蓋(RX≤-90dBm)33.30%呼叫失敗（共85次）54被叫未收到page消息

63.53%10未收到TCA消息

11.76%6弱覆蓋(RX≤-90dBm)7.06%6基站拒絕QOS請求

7.06%4導頻污染

4.71%3AN拒絕Connection請求

3.53%1connection建立時間過長

1.18%1超過最大用戶接入數(shù)

1.18%失敗原因最多的為被叫尋呼不到，經(jīng)過尋呼策略優(yōu)化后，QoSOFF情況下已解決，但QoSON的情況仍有出現(xiàn)，正在進一步分析優(yōu)化中。典型事件分析分布－－六安類型次數(shù)分類占比掉話（共6次）3SINR值連續(xù)4s低于-7dB，終端切換至1x50.00%2子網(wǎng)邊界處，導頻污染嚴重，基站側(cè)下發(fā)close，導致掉話33.33%1EVDO掉線（systermlost）導致掉話16.67%呼叫失?。ü?3次）8SINR值連續(xù)4s低于-7dB，終端切換至1x34.78%7導頻污染嚴重導致被叫Connection建立失敗30.44%3被叫未收到尋呼消息13.04%3尋呼過晚導致未接通13.04%2基站拒絕QOS請求8.70%在QoSLicense優(yōu)化后，失敗原因最多的為由于DO信號質(zhì)量問題切換至1X以及導頻污染。典型事件分析分布－－合肥類型次數(shù)分類占比掉話（共9次）9SINR值連續(xù)4s低于-7dB，終端切換至1x100%呼叫失?。ü?2次）16SINR值連續(xù)4s低于-7dB，終端切換至1x38.10%13尋呼過晚30.95%4AN對被叫EVDO請求未做任何響應(yīng)9.52%4AN拒絕被叫Connection請求9.52%3被叫未收到尋呼消息，主叫提示被叫不在服務(wù)區(qū)7.14%1被叫未收到TCA2.38%1子網(wǎng)邊界導致呼叫失敗

2.38%失敗原因最多的為由于DO信號質(zhì)量問題切換至1X以及尋呼過晚。典型事件分析分布－－滁州類型次數(shù)分類占比掉話（共19次）7AN下發(fā)connectionclose36.84%4異頻切換

21.05%4鄰區(qū)漏配

21.05%2無主導頻

10.53%2跨省切換

10.53%呼叫失?。ü?4次）5被叫未收到尋呼消息

35.71%4跨省市切換

28.57%2異頻切換

14.29%2無主導頻

14.28%1connection建立時間過長

7.14%異常事件主要為掉話，其中基站主動下發(fā)ConnectionClose的占比較大，目前，正在進一步分析中。典型事件分析分布－－馬鞍山1、SINR值連續(xù)4s低于-7dB，終端切換至1x導致掉話本地網(wǎng)：合肥發(fā)生次數(shù)：3（全部發(fā)生在OFF）問題描述：起呼或通話中，SINR值連續(xù)4s低于-7dB，繼而切換至1X上。問題分析：問題路段一般接收電平良好（RxAGC>-75dBm），但SINR值很低（普遍低于-7dBm），存在較強的導頻污染。解決辦法：針對SINR值進行優(yōu)化。具體影響：造成呼叫失敗或掉話。影響指數(shù)：★★★★★合肥典型事件分析－－掉話問題描述：MS由西向東行駛，RXAGC=-88.35dBm，SINR=-11dB，終端切換至1x上，導致掉話。問題分析：圖中所圈基站（站名：金牛）沒有DO載波，導致該路段EVDO覆蓋較差。解決方法：增加金牛站的EVDO載波。合肥典型事件分析－－掉話2、子網(wǎng)邊界處，導頻污染嚴重，基站側(cè)下發(fā)close，導致掉話發(fā)生次數(shù)：2（全部發(fā)生在ON）問題描述：處于子網(wǎng)邊界，呼叫過程中有發(fā)生跨子網(wǎng)切換，導頻污染嚴重，AN下發(fā)ConnectionClose斷開Connection，導致掉話。問題分析：首先終端處于子網(wǎng)邊界，跨子網(wǎng)切換時先要斷開Connection易造成掉話；其次問題路段導頻污染也較為嚴重。解決辦法：優(yōu)化子網(wǎng)邊界，減小子網(wǎng)間的重疊覆蓋；針對導頻污染進行優(yōu)化。具體影響：造成呼叫失敗或掉話。影響指數(shù)：★★★★★合肥典型事件分析－－掉話問題描述：問題路段處于ColorCode2和4的交界處，導頻污染較為嚴重，主被叫起呼前后都發(fā)生了的Session切換。合肥典型事件分析－－掉話合肥典型事件分析－－掉話3、信號質(zhì)量差，EVDO掉線導致掉話發(fā)生次數(shù)：1（發(fā)生在OFF）問題分析：無線信號質(zhì)量差（SINR<-4dB），終端搜索不到EVDO導頻，導致掉話（Reason：systermlost）。解決辦法：針對無線參數(shù)SINR值進行優(yōu)化。具體影響：造成EVDO掉線。影響指數(shù)：★★合肥典型事件分析－－掉話問題描述：MS由西向東行駛，在該路段發(fā)生EVDO掉線（Reason：systemlost）。問題分析：該路段PN228和PN315之間存在干擾，信號較差，SINR值=-4.54dB，導致終端接收不到EVDO前向消息而掉線。解決辦法：調(diào)整天饋，針對SINR值進行優(yōu)化。合肥典型事件分析－－掉話合肥典型事件分析－－呼叫失敗1、SINR值連續(xù)4s低于-7dB，終端切換至1x導致掉話發(fā)生次數(shù)：8（在OFF發(fā)生6次，ON發(fā)生2次）問題描述：起呼或通話中，SINR值連續(xù)4s低于-7dB，繼而切換至1X上。問題分析：問題路段一般接收電平良好（RxAGC>-75dBm），但SINR值很低（普遍低于-7dBm），存在較強的導頻污染。解決辦法：針對SINR值進行優(yōu)化。具體影響：造成呼叫失敗或掉話。影響指數(shù)：★★★★★問題描述：

MS由南向北行駛，SINR值連續(xù)4s低于-7dB，終端切換至1x。問題分析：該路段導頻污染嚴重。解決辦法：逆時針調(diào)整PN255方位角15度，并適當增大其發(fā)射功率；適當降低PN87和PN423的發(fā)射功率。合肥典型事件分析－－呼叫失敗2、導頻污染嚴重導致被叫Connection建立失敗發(fā)生次數(shù)：7（發(fā)生在OFF4次，ON3次）問題描述：信號質(zhì)量較差（SINR<-6dB），扇區(qū)用戶<10。被叫收到尋呼消息后發(fā)送RU+CR，但未收到Ack，Connection建立失敗。問題分析：一是AN可能未收到被叫發(fā)送的RU+CR，二是AN收到后未做任何響應(yīng)（這種可能性較?。?。解決辦法：優(yōu)化問題路段無線覆蓋，對問題路段進行復測重現(xiàn)，如繼續(xù)出現(xiàn)則需結(jié)合RNC進行分析。具體影響：造成呼叫失敗。影響指數(shù)：★★★★★合肥典型事件分析－－呼叫失敗問題描述：MS由西向東行駛，被叫收到尋呼消息后隨即發(fā)送RU+CR，但AN未作任何響應(yīng)。問題分析：一是AN可能未收到被叫發(fā)送的RU+CR，二是AN收到后未做任何響應(yīng)（這種可能性較?。?。解決辦法：調(diào)整PN441天饋，并適當增大PN441的發(fā)射功率，使其成為該路段主導頻。對問題路段進行復測重現(xiàn)，如繼續(xù)出現(xiàn)則需結(jié)合RNC進行分析。合肥典型事件分析－－呼叫失敗3、被叫未收到尋呼消息發(fā)生次數(shù)：3（ON發(fā)生2次，OFF發(fā)生1次）問題描述：信號較差，被叫未收到尋呼消息。問題分析：一種可能是AN下發(fā)了尋呼消息，但被叫未收到，這需要優(yōu)化問題路段的信號質(zhì)量；另一種可能是AN并沒有下發(fā)尋呼消息（可能性較?。?，這要結(jié)合RNC進行分析。解決辦法：對問題路段進行無線優(yōu)化，再進行復測重現(xiàn)，如果再次出現(xiàn)需結(jié)合RNC進行分析。具體影響：造成呼叫失敗。影響指數(shù)：★★合肥典型事件分析－－呼叫失敗問題描述：主叫起呼后隨即建立了EVDOConnection,但被叫一直未收到尋呼消息。問題分析：問題路段處于315省道上，信號質(zhì)量較差。一種可能是AN下發(fā)了尋呼消息，但被叫未收到，這需要優(yōu)化問題路段的信號質(zhì)量；另一種可能是AN并沒有下發(fā)尋呼消息（可能性較小），這要結(jié)合RNC進行分析。解決辦法：針對該路段無線覆蓋進行優(yōu)化，增加PN294發(fā)射功率。對問題路段進行復測，如果重現(xiàn)則需結(jié)合RNC進行分析。合肥典型事件分析－－呼叫失敗4、尋呼過晚發(fā)生次數(shù)：3（在OFF發(fā)生1次，ON發(fā)生2次）問題描述：從主叫起呼（發(fā)送DOS消息）到被叫收到尋呼消息超過5-6s，平臺即判為未接通。問題分析：阿朗的尋呼策略是前兩次都是“Lastactiveset”，第三次才開始“LastseenRNC”，每次時間間隔1s。考慮到系統(tǒng)和空口時延，如果被叫離開了“Lastactiveset”，被叫接收到尋呼消息的時間有可能超過5s。解決辦法：修改阿朗的第二次尋呼為“LastseenRNC”。具體影響：造成呼叫失敗。影響指數(shù)：★★★★★合肥典型事件分析－－呼叫失敗問題描述：主叫于9：28：56.879發(fā)送RU+CR+DOS，但被叫于9：29：05.716才收到尋呼消息問題分析：被叫最近一次發(fā)送RU在09：26：23.704，“Lastactiveset”是PN213和PN45。而從9：28：56.879(主叫起呼時間)后，被叫就一直占用PN402。前兩條尋呼消息都下發(fā)去了PN213和PN45，被叫只能接收到第三條尋呼消息“LastseenRNC”。解決辦法：更改阿朗設(shè)備的第二條尋呼消息為“LastseenRNC”。合肥典型事件分析－－呼叫失敗合肥典型事件分析－－呼叫失敗5、AN拒絕終端QOS請求發(fā)生次數(shù)：2（全部發(fā)生在ON）問題描述：無線環(huán)境一般或較差，AN拒絕了終端的QOS請求。問題分析：基站QOSlicence不足。解決辦法：增加問題基站的QOSlicence。影響指數(shù)：★★合肥典型事件分析－－呼叫失敗問題描述：主叫起呼發(fā)起RU+CR+DOS+RR（QOS請求），AN下發(fā)了Ack消息，隨后下發(fā)ReservationReject+Connectiondeny拒絕了主叫的QOS請求。問題分析：首先PN9的QOS權(quán)限不足；其次，PN9和PN372存在導頻干擾。解決辦法：檢查并增加“安徽醫(yī)科大學新區(qū)北側(cè)”的QOS權(quán)限；針對PN9和PN372之間的干擾進行優(yōu)化。合肥典型事件分析－－呼叫失敗開啟QOS時接通率較低，29次呼叫失敗中有19次發(fā)生在開發(fā)區(qū)，具有一定區(qū)域集中性。經(jīng)過省網(wǎng)優(yōu)中心、高通公司、阿朗公司的共同分析，確定問題原因是QoSLicense問題，詳見案例。合肥典型事件分析－－QoSLicense目錄QCHAT測試情況一QCHAT典型事件分析二QCHAT不同尋呼策略指標對比一尋呼策略－－阿朗（2/2）尋呼次數(shù)：可設(shè)定，最多8次對于BE尋呼，Lastactiveset和lastseenRNC最多各4次；對于QoS尋呼，activeset和RNC尋呼的次數(shù)無限制，但總的尋呼次數(shù)是8次。尋呼范圍：theLastActiveSet或theLastSeenRNC對于BE尋呼，順序上默認Lastactiveset尋呼總是先于lastseenRNC，除非不選擇進行activeset尋呼。對于基于Qos的尋呼，在網(wǎng)管設(shè)置上沒有先后順序的限制，