單項(xiàng)選擇題當(dāng)PCCPCHRSCP＜-95dBm，且PCCPCHC/I＜-3dB，下述分析思路，哪些是錯(cuò)誤的？（）

A、如果鄰小區(qū)的PCCPCH RSCP>當(dāng)前服務(wù)小區(qū)的PCCPCH RSCP，則說明存在弱覆蓋問題(非切換或重選參數(shù)設(shè)置不當(dāng)引起)或越區(qū)覆蓋問題
B、利用全網(wǎng)拉線圖確定當(dāng)前服務(wù)小區(qū)的位置，從而確定問題區(qū)域是弱覆蓋問題還是越區(qū)覆蓋問題
C、如果鄰小區(qū)的PCCPCH RSCP＞當(dāng)前服務(wù)小區(qū)的PCCPCH RSCP，則說明弱覆蓋問題是由于切換或重選參數(shù)設(shè)置不當(dāng)引起
D、如果沒有鄰區(qū)信息，則說明可能存在鄰區(qū)配置問題，如鄰區(qū)漏配


您可能感興趣的試卷

你可能感興趣的試題

1.單項(xiàng)選擇題對(duì)于掉話前的信令流程的分析思路，下述說法錯(cuò)誤的是（）

A、如果UE在掉話前發(fā)生了切換，并且UE發(fā)送完重配置完成消息后直到掉話前一直沒有收到任何RNC下發(fā)的信令，可能重配置完成消息RNC沒有收到，從而定時(shí)器超時(shí)后釋放鏈路。原因可能是重配置消息的功率太低，造成RNC沒有收到，對(duì)此需要提高“配給Node B的上行目標(biāo)信噪比”
B、如果UE在掉話前發(fā)生了切換，并且UE發(fā)送完重配置完成消息后直到掉話前一直沒有收到任何RNC下發(fā)的信令，可能RNC收到了且下發(fā)了測(cè)量控制消息，但UE沒有收到測(cè)量控制，由于測(cè)量控制消息采用AM模式，需要在一定的時(shí)間內(nèi)收到接收端對(duì)AM模式數(shù)據(jù)的確認(rèn)，最終導(dǎo)致UE的RLC層發(fā)生了RLC不可恢復(fù)錯(cuò)誤
C、如果掉話前發(fā)生了原因?yàn)闊o線鏈路失敗的小區(qū)更新，說明掉話區(qū)域的下行鏈路質(zhì)量惡化，建議針對(duì)覆蓋、干擾、鄰區(qū)漏配等原因進(jìn)行排查
D、如果掉話前網(wǎng)絡(luò)側(cè)信令顯示Node B上報(bào)了無線鏈路失敗指示，則說明Node B出現(xiàn)上行失步，說明掉話區(qū)域的上行鏈路質(zhì)量惡化。建議針對(duì)覆蓋、干擾、鄰區(qū)漏配、功率參數(shù)設(shè)置等問題進(jìn)行排查

2.單項(xiàng)選擇題對(duì)于掉話問題的分析思路，下述說法錯(cuò)誤的是（）

A、檢查掉話點(diǎn)的覆蓋情況，排除覆蓋問題導(dǎo)致的掉話。如果問題區(qū)域存在覆蓋問題，則首先解決覆蓋問題
B、檢查基站、RNC設(shè)備工作狀態(tài)是否正常，是否存在可能影響到業(yè)務(wù)或切換正常進(jìn)行的告警
C、分析掉話前的信令流程，進(jìn)行進(jìn)一步的分析
D、呼叫重建不支持等原因也會(huì)導(dǎo)致掉話的發(fā)生，建議具體的掉話原因直接根據(jù)RNC側(cè)信令跟蹤文件里Iu Release Command消息中攜帶的原因直接判斷

3.單項(xiàng)選擇題關(guān)于上行失步的檢測(cè)及處理,下述說法錯(cuò)誤的是（）

A、在同步保持階段，NodeB在收到"無線鏈路失步指示次數(shù)"個(gè)失步指示后，將啟動(dòng)"無線鏈路失效定時(shí)器
B、在收到"無線鏈路同步指示次數(shù)"個(gè)同步狀態(tài)指示，NodeB將停止和復(fù)位"無線鏈路失效定時(shí)器
C、如果"無線鏈路失效定時(shí)器"超時(shí)，基站物理層向基站高層匯報(bào)失步?；靖邔油ㄟ^NBAP協(xié)議,向RNC發(fā)送"RADIO LINK RESTORE FAILURE"消息
D、RNC收到"RADIO LINK RESTORE FAILURE"消息,啟動(dòng)"收到RL失敗等待定時(shí)器

4.單項(xiàng)選擇題UE在GSM網(wǎng)絡(luò)做數(shù)據(jù)業(yè)務(wù)，當(dāng)從GSM重選到TD網(wǎng)絡(luò)時(shí)，下述說法錯(cuò)誤的是：（）

A、由于現(xiàn)在實(shí)現(xiàn)的原因，不是UE在GSM網(wǎng)絡(luò)上發(fā)測(cè)量報(bào)告，然后網(wǎng)絡(luò)觸發(fā)UE 小區(qū)改變命令，然后UE重選到TD網(wǎng)絡(luò)
B、由于現(xiàn)在實(shí)現(xiàn)的原因，UE通過測(cè)量的方式?jīng)Q定重選到TD網(wǎng)絡(luò)，與idle模式下重選相似，故RRC connection request的原因是系統(tǒng)間小區(qū)重選，而不是系統(tǒng)間小區(qū)改變，所以，從整個(gè)信令流程已無法判斷與idle時(shí)重選的異同
C、由于現(xiàn)在實(shí)現(xiàn)的原因，通過RA和LA更新后，收到網(wǎng)絡(luò)側(cè)MODIFY PDP CONTEXT REQUEST (NETWORK TO MS DIRECTION)和UE回MODIFY PDP CONTEXT ACCEPT消息
D、首先，由BSS向UE發(fā)送RR-Cell Change Order 消息，UE接收到該消息后執(zhí)行向TD-SCDMA的小區(qū)重選過程，與目標(biāo)RN核心網(wǎng)建立信令連接，并觸發(fā)路由區(qū)更新過程。其中，在RRC Connection Establishment 過程中，“Establishment cause”IE為Inter-RAT cell change order，并具有較高的優(yōu)先級(jí)。

5.單項(xiàng)選擇題關(guān)于重定位過程有關(guān)定時(shí)器的描述，下述說法錯(cuò)誤的是：（）

A、SRNC重定位準(zhǔn)備定時(shí)器超時(shí)處理策略:SRNC重定位準(zhǔn)備定時(shí)器超時(shí)(SRNC在該定時(shí)器超時(shí)前未收到CN下發(fā)的Relocation Command或Relocation Preparation Failure),SRNC上報(bào)Relocation Cannel給CN,同時(shí)開啟SRNC重定位取消定時(shí)器。
B、SRNC重定位定時(shí)器超時(shí)處理策略:SRNC重定位定時(shí)器超時(shí)(SRNC在該定時(shí)器超時(shí)前未收到CN下發(fā)的Iu Release Command或UE上報(bào)的RB Relocation Failure),CN下發(fā)Iu Release Request給SRNC,同時(shí)開啟SRNC重定位取消定時(shí)器。
C、SRNC重定位取消定時(shí)器超時(shí)處理策略:SRNC重定位取消定時(shí)器超時(shí)(SRNC在該定時(shí)器超時(shí)前未收到CN下發(fā)的Relocation Cannel ACK),SRNC上報(bào)Iu Release Request給CN釋放鏈路。
D、TRNC目標(biāo)側(cè)等待UU側(cè)重定位完成定時(shí)器超時(shí)處理策略: TRNC目標(biāo)側(cè)等待UU側(cè)重定位完成定時(shí)器超時(shí)(TRNC在該定時(shí)器超時(shí)前未收到UE上發(fā)的RB Reconfiguration Complete或CN下發(fā)的Iu Release Command),TRNC上報(bào)Iu Release Request給CN釋放鏈路。