 |
善于提問(wèn)，勤于回答，你也是專(zhuān)家
|
 |
問(wèn)題已開(kāi)啟
(普通問(wèn)題)
如何判斷上行失步還是下行失步
如何判斷無(wú)線鏈路失敗是上行問(wèn)題還是下行問(wèn)題？cellupdate時(shí)如何進(jìn)行目標(biāo)小區(qū)的選擇，什么時(shí)候選擇本小區(qū)，什么時(shí)候選擇其他小區(qū)？
提問(wèn)者:
• 上行PRB利用率高 2020-07-13
• 上行波形自適應(yīng)中的snr如何獲得？ 2020-03-07
• 上行干擾怎么解決 2019-10-10
• 哪些上行哪些下行 2019-10-07
• 中國(guó)電信集團(tuán)黨組書(shū)記，董事長(zhǎng)柯瑞文說(shuō)，在5G時(shí)代，中國(guó)電信堅(jiān)持全網(wǎng)通終端，堅(jiān)持超級(jí)上行（這要全雙工）和wifi6，堅(jiān)持NSA和SA雙模全網(wǎng)通標(biāo)準(zhǔn)（肯定是Option7x與Option4重了！）�！斑@個(gè) 2019-09-25
• nbiot上行資源調(diào)度用什么仿真軟件啊 2019-05-22
• 聯(lián)通現(xiàn)在用的GL和UL設(shè)備，LTE載波的頻率是多少到多少（上行和下行） 2019-04-30
• 知道LTE的下行頻率、頻點(diǎn)信息，能不能知道上行 2018-12-20
• 上行波形自適應(yīng)中的snr如何獲得？ 2020-03-07
• 上行干擾怎么解決 2019-10-10
• 哪些上行哪些下行 2019-10-07
• 中國(guó)電信集團(tuán)黨組書(shū)記，董事長(zhǎng)柯瑞文說(shuō)，在5G時(shí)代，中國(guó)電信堅(jiān)持全網(wǎng)通終端，堅(jiān)持超級(jí)上行（這要全雙工）和wifi6，堅(jiān)持NSA和SA雙模全網(wǎng)通標(biāo)準(zhǔn)（肯定是Option7x與Option4重了！）�！斑@個(gè) 2019-09-25
• nbiot上行資源調(diào)度用什么仿真軟件啊 2019-05-22
• 聯(lián)通現(xiàn)在用的GL和UL設(shè)備，LTE載波的頻率是多少到多少（上行和下行） 2019-04-30
• 知道LTE的下行頻率、頻點(diǎn)信息，能不能知道上行 2018-12-20
問(wèn)題答案
( 1 )
失步的具體表現(xiàn)為不同步的信號(hào)將會(huì)對(duì)相鄰時(shí)隙的信號(hào)產(chǎn)生干擾，而當(dāng)相位偏移嚴(yán)重使得上行信號(hào)在下行時(shí)隙發(fā)送（或下行信號(hào)在上行時(shí)隙發(fā)送）時(shí)，則對(duì)服務(wù)地區(qū)通訊產(chǎn)生嚴(yán)重干擾，使該地區(qū)通話質(zhì)量和話務(wù)指標(biāo)下降，譬如：通話時(shí)雜音大，下行尋呼響應(yīng)次數(shù)很低，頻率阻塞率提高等；嚴(yán)重時(shí)還會(huì)造成C-CH丟失時(shí)隙、基站Block。
針對(duì)上行和下行，失步分為上行鏈路失步和下行鏈路失步兩種。在協(xié)議里面針對(duì)上行鏈路失步和下行鏈路失步分別定義了判斷標(biāo)準(zhǔn)：
上行鏈路失步會(huì)刪除鏈路，下行失步會(huì)cellupdate，而且現(xiàn)在的情況是一般出現(xiàn)了上行失步后基本上都恢復(fù)不了，造成UE最終掉話，而下行時(shí)刻有時(shí)可以通過(guò)cellupdate過(guò)程恢復(fù)。
引起上行和下行鏈路失步的原因又不能簡(jiǎn)單地認(rèn)為是某一方面的問(wèn)題，而是由于交互作用引起的。
下行失步：主要是基站和終端由于無(wú)線環(huán)境不好，原因較多的就是弱覆蓋等因素導(dǎo)致，這個(gè)原因值在路測(cè)軟件中，和網(wǎng)管跟蹤的信令中都有，主要就是無(wú)線環(huán)境不好，干擾，弱覆蓋等。
上行失步：主要是目標(biāo)小區(qū)上行UPPCH干擾嚴(yán)重，或者同時(shí)有其他UE的上行同步碰撞，導(dǎo)致和目標(biāo)小區(qū)的上行同步失敗；基站在接收到ＵＥ的調(diào)度資源信息或釋放非調(diào)度資源通知后，長(zhǎng)時(shí)間不能為ＵＥ分配調(diào)度資源且無(wú)法向ＵＥ發(fā)送ＳＳ命令，而造成的ＵＥ的失步。目標(biāo)小區(qū)的UPPTS期望接收到的功率設(shè)置過(guò)小、功率步長(zhǎng)設(shè)置不合理，可能會(huì)導(dǎo)致切換失敗。
上行失步和下行失步
上行失步：基站側(cè)檢測(cè)
原因：
1、與目標(biāo)小區(qū)上行失步：UE收到物理信道重配置消息，由于UP存在干擾或FPACH信道的C/I或信號(hào)質(zhì)量較差，UE不能在新小區(qū)建立上行同步，導(dǎo)致幀定時(shí)跟蹤出現(xiàn)問(wèn)題，這樣UE無(wú)法在目標(biāo)小區(qū)正確收發(fā)，發(fā)生切換失敗。如果源小區(qū)的RL沒(méi)有刪除，RNC會(huì)通過(guò)源小區(qū)給UE下發(fā)物理信道重配失敗（或RB重配失�。�，UE回到源小區(qū)，反之則發(fā)生掉話。（上行同步失�。�
2、與目標(biāo)小區(qū)上行失步：UE已向目標(biāo)NodeB發(fā)送物理信道重配置（RB重配置）完成信令，但是由于目標(biāo)小區(qū)NodeB底噪過(guò)高，或此時(shí)多部UE位于小區(qū)邊緣，且上行發(fā)射功率都被抬升的比較高導(dǎo)致產(chǎn)生較大的上行時(shí)隙干擾，使得目標(biāo)小區(qū)NodeB無(wú)法正確解析重配置完成的信令，而引發(fā)物理信道重配置超時(shí)。（uncomplete）
判斷標(biāo)準(zhǔn)：
在同步保持階段，NodeB對(duì)于物理層兩個(gè)連續(xù)同步指示的時(shí)間間隔為160ms，NB在收到N_OUTSYNC_IND個(gè)連續(xù)失步指示后，將啟動(dòng)“無(wú)線鏈路失敗過(guò)程定時(shí)器”T_RLFAILURE，在收到N_SYNC_IND個(gè)同步狀態(tài)指示后，NodeB將停止和復(fù)位T_RLFAILURE，如果T_RLFAILURE超時(shí)，NodeB則認(rèn)為上行無(wú)線鏈路失步。（上行失步會(huì)刪除鏈路，立即斷開(kāi)，造成UE最終掉話。）
挽救措施：
NodeB檢測(cè)到上行無(wú)線鏈路失步后，做如下處理：
1)NodeB向RNC上發(fā)“Radio link failure indication”，指示同步失敗。（NodeB——RNC）
2)NodeB停發(fā)下行數(shù)據(jù)，目的是讓UE下行失步，來(lái)上發(fā)CellUpdate。（注：此時(shí)會(huì)在終端側(cè)顯示出DPCH陡降現(xiàn)象。）
3)RNC啟動(dòng)“收到RL失敗等待定時(shí)器”。在該定時(shí)器超時(shí)前，如果未收到“Radio link restore”則RNC釋放鏈路，并記為無(wú)線鏈路失敗的掉話。（NodeB——RNC）
（注釋?zhuān)荷闲惺Р叫枰緛?lái)檢測(cè)，也有類(lèi)似于UE側(cè)的定時(shí)器和計(jì)數(shù)器，一旦發(fā)現(xiàn)上行失步，則NodeB會(huì)上報(bào)RL Failure Indication（NBAP信令）給RNC，同時(shí)RNC會(huì)啟動(dòng)相應(yīng)的無(wú)線鏈路失敗等待定時(shí)器，定時(shí)器超時(shí)則發(fā)起Iu Release Request，記為一次掉話。）
引申：
上行失步DPCH陡降的時(shí)長(zhǎng)：網(wǎng)絡(luò)參數(shù)默認(rèn)值N_OUTSYNC_IND =20，T_RLFAILURE =5s。由此可以計(jì)算出，從第一上行失步開(kāi)始到DPCH陡降的最短時(shí)間為：DPCH陡降時(shí)長(zhǎng)=20*160ms+5000ms =8200ms =8.2s
下行失步：UE側(cè)檢測(cè)
原因：
1、與源小區(qū)下行失步：UE已發(fā)測(cè)量報(bào)告，但由于下行失步，收不到原小區(qū)DPCH數(shù)據(jù)，即收不到物理信道重配置信令（或RB重配置消息），導(dǎo)致無(wú)法切換。
2、與目標(biāo)小區(qū)下行失步：UE收到物理信道重配置消息（RB重配置消息），由于原小區(qū)或周?chē)徯^(qū)對(duì)目標(biāo)小區(qū)的下行信號(hào)有較大的干擾，導(dǎo)致UE無(wú)法正確解析目標(biāo)小區(qū)的下行信號(hào)，不能與目標(biāo)小區(qū)建立同步，而引發(fā)物理信道重配置超時(shí)，發(fā)生掉話問(wèn)題。
（物理信道重配置定時(shí)器不是一個(gè)3GPP協(xié)議定時(shí)器，它是各個(gè)廠家可以自己規(guī)定的私有定時(shí)器，在PHY RECONFIG 發(fā)送完畢后，RNC開(kāi)始計(jì)時(shí)，當(dāng)收到PHY RECONFIG COMPLETE以后，RNC停止計(jì)時(shí)。如果RNC超時(shí)，則會(huì)發(fā)生25.413里面的14號(hào) IU REL REQ的掉話原因（當(dāng)然，可能各廠家規(guī)定不一樣），也有可能是46號(hào)掉話原因。
）
判斷標(biāo)準(zhǔn)：處于CELL_DCH狀態(tài)的UE，連續(xù)接收到來(lái)自物理層的N313個(gè)連續(xù)”out of sync”指示時(shí)，啟動(dòng)定時(shí)器T313，在此過(guò)程中若連續(xù)接收到來(lái)自物理層的N315個(gè)連續(xù)”in sync”指示，T313停止，否則T313超時(shí)，視為下行無(wú)線鏈路失步。（下行失步主要原因?yàn)闊o(wú)線環(huán)境不好，干擾，弱覆蓋等，下行失步會(huì)cellupdate，而且一般可以恢復(fù)通話正常。）
挽救措施：
UE檢測(cè)到下行無(wú)線鏈路失步后，做如下處理：
1)UE的RRC層向物理層下發(fā)“P_RRC_PHY_RL_Release_REQ”釋放物理信道資源；
2)同時(shí)UE關(guān)閉上下行數(shù)據(jù)，并通過(guò)“P_RRC_PHY_CellSearch_REQ”原語(yǔ)讓物理層進(jìn)行小區(qū)的重搜，此時(shí)終端是無(wú)法測(cè)DPCH_RSCP值的，因此會(huì)在終端側(cè)顯示出DPCH陡降現(xiàn)象。
3)在搜到小區(qū)后，UE將在目標(biāo)小區(qū)上進(jìn)行CellUpdate，原因?yàn)椤皉adio link failure”。如果小區(qū)更新成功，則該次下行無(wú)線鏈路失步得到挽救，否則UE發(fā)生掉話。
引申：需要指出的是，各個(gè)終端廠家對(duì)于UE檢測(cè)存在著或多或少的差異，下面列舉的是某芯片廠商處理的情況。
UE的物理層每隔一幀的時(shí)間（10ms），進(jìn)行一次下行無(wú)線鏈路的同步情況的監(jiān)測(cè)。在具體實(shí)施的過(guò)程中，UE側(cè)采用滑窗的形式，滑窗的長(zhǎng)度為160ms，滑窗每10ms移動(dòng)一次。
網(wǎng)絡(luò)參數(shù)默認(rèn)值N313=20，T313=3s，由此可以計(jì)算出UE收到第一個(gè)下行失步指示到DPCH陡降的時(shí)間為：DPCH陡降時(shí)長(zhǎng)=160ms+N313*10ms+T313=3360ms=3.36s
【案例】
案例1：硬切換時(shí)下行鏈路失步
UE在做普通語(yǔ)音業(yè)務(wù)期間，上報(bào)測(cè)量報(bào)告希望進(jìn)行切換。4.5s后UE小區(qū)搜索，讀取系統(tǒng)消息，并做CellUpdate試圖挽救（此過(guò)程在圖中沒(méi)有顯示出來(lái)）。DPCH陡降發(fā)生時(shí)，UE已經(jīng)處于讀取系統(tǒng)消息的時(shí)間。
終端在15：51：09.814發(fā)送測(cè)量報(bào)告，在等了4.5秒后，在15：51：14.314 DPCH發(fā)生陡降，讀取系統(tǒng)消息，并試圖做小區(qū)更新。因此從時(shí)長(zhǎng)的角度來(lái)看，終端是下行鏈路失步。
案例2：切換時(shí)上行鏈路失步
UE在做普通語(yǔ)音業(yè)務(wù)期間，上報(bào)測(cè)量報(bào)告希望進(jìn)行切換。8.5s后UE收到RNC下發(fā)的RRC連接釋放消息，UE發(fā)送RRC連接釋放完成消息，然后UE讀取系統(tǒng)消息。DPCH陡降發(fā)生時(shí)，UE已經(jīng)處于讀取系統(tǒng)消息的時(shí)間。
終端在00：52：25.842發(fā)送測(cè)量報(bào)告，在等了將近8.7秒后，在00：52：34.532 DPCH發(fā)生陡降。因此從時(shí)長(zhǎng)的角度來(lái)看，終端是上行鏈路失步。
案例3：切換時(shí)上行鏈路失步
UE在做普通語(yǔ)音業(yè)務(wù)期間，上報(bào)測(cè)量報(bào)告希望進(jìn)行切換。收到RNC下發(fā)的RB重配命令后，UE上報(bào)RB重配完成消息。12s后UE進(jìn)行小區(qū)搜索，讀取系統(tǒng)消息。DPCH陡降發(fā)生時(shí)，UE已經(jīng)處于讀取系統(tǒng)消息的時(shí)間。
終端在23：03：06.873發(fā)送RB重配完成命令，在等了將近9秒后，在23：03：15.763 DPCH發(fā)生陡降，而后轉(zhuǎn)入空閑態(tài)，并試圖做小區(qū)更新。因此從時(shí)長(zhǎng)的角度來(lái)看，終端是上行鏈路失步。
總之，DPCH陡降在上下行鏈路失步時(shí)，是有很大發(fā)生可能性的，而且按照終端和基站設(shè)備對(duì)DPCH的處理機(jī)制也是合理的。
處理建議：
通過(guò)以上的分析，可以看到DPCH陡降和上下行無(wú)線鏈路失步有很大的關(guān)系，進(jìn)而又和切換過(guò)程中的問(wèn)題有著直接的聯(lián)系，因此對(duì)DPCH陡降現(xiàn)象處理建議為：
1.先理順切換關(guān)系，排除同頻干擾，保證無(wú)線環(huán)境正常；
2.另可通過(guò)調(diào)整上行的SIR Target和DPCH的發(fā)射功率來(lái)改善上下行鏈路質(zhì)量；
3.再一個(gè)就是調(diào)整Uu口定時(shí)器參數(shù)，無(wú)線鏈路失步后，釋放時(shí)間由T313、N313、N315 N_OUTSYNC_IND、T_RLFAILURE等參數(shù)控制。
4.關(guān)注UE，避免測(cè)試時(shí)間過(guò)長(zhǎng)發(fā)熱死機(jī)而影響測(cè)試結(jié)果。
針對(duì)上行和下行，失步分為上行鏈路失步和下行鏈路失步兩種。在協(xié)議里面針對(duì)上行鏈路失步和下行鏈路失步分別定義了判斷標(biāo)準(zhǔn)：
上行鏈路失步會(huì)刪除鏈路，下行失步會(huì)cellupdate，而且現(xiàn)在的情況是一般出現(xiàn)了上行失步后基本上都恢復(fù)不了，造成UE最終掉話，而下行時(shí)刻有時(shí)可以通過(guò)cellupdate過(guò)程恢復(fù)。
引起上行和下行鏈路失步的原因又不能簡(jiǎn)單地認(rèn)為是某一方面的問(wèn)題，而是由于交互作用引起的。
下行失步：主要是基站和終端由于無(wú)線環(huán)境不好，原因較多的就是弱覆蓋等因素導(dǎo)致，這個(gè)原因值在路測(cè)軟件中，和網(wǎng)管跟蹤的信令中都有，主要就是無(wú)線環(huán)境不好，干擾，弱覆蓋等。
上行失步：主要是目標(biāo)小區(qū)上行UPPCH干擾嚴(yán)重，或者同時(shí)有其他UE的上行同步碰撞，導(dǎo)致和目標(biāo)小區(qū)的上行同步失敗；基站在接收到ＵＥ的調(diào)度資源信息或釋放非調(diào)度資源通知后，長(zhǎng)時(shí)間不能為ＵＥ分配調(diào)度資源且無(wú)法向ＵＥ發(fā)送ＳＳ命令，而造成的ＵＥ的失步。目標(biāo)小區(qū)的UPPTS期望接收到的功率設(shè)置過(guò)小、功率步長(zhǎng)設(shè)置不合理，可能會(huì)導(dǎo)致切換失敗。
上行失步和下行失步
上行失步：基站側(cè)檢測(cè)
原因：
1、與目標(biāo)小區(qū)上行失步：UE收到物理信道重配置消息，由于UP存在干擾或FPACH信道的C/I或信號(hào)質(zhì)量較差，UE不能在新小區(qū)建立上行同步，導(dǎo)致幀定時(shí)跟蹤出現(xiàn)問(wèn)題，這樣UE無(wú)法在目標(biāo)小區(qū)正確收發(fā)，發(fā)生切換失敗。如果源小區(qū)的RL沒(méi)有刪除，RNC會(huì)通過(guò)源小區(qū)給UE下發(fā)物理信道重配失敗（或RB重配失�。�，UE回到源小區(qū)，反之則發(fā)生掉話。（上行同步失�。�
2、與目標(biāo)小區(qū)上行失步：UE已向目標(biāo)NodeB發(fā)送物理信道重配置（RB重配置）完成信令，但是由于目標(biāo)小區(qū)NodeB底噪過(guò)高，或此時(shí)多部UE位于小區(qū)邊緣，且上行發(fā)射功率都被抬升的比較高導(dǎo)致產(chǎn)生較大的上行時(shí)隙干擾，使得目標(biāo)小區(qū)NodeB無(wú)法正確解析重配置完成的信令，而引發(fā)物理信道重配置超時(shí)。（uncomplete）
判斷標(biāo)準(zhǔn)：
在同步保持階段，NodeB對(duì)于物理層兩個(gè)連續(xù)同步指示的時(shí)間間隔為160ms，NB在收到N_OUTSYNC_IND個(gè)連續(xù)失步指示后，將啟動(dòng)“無(wú)線鏈路失敗過(guò)程定時(shí)器”T_RLFAILURE，在收到N_SYNC_IND個(gè)同步狀態(tài)指示后，NodeB將停止和復(fù)位T_RLFAILURE，如果T_RLFAILURE超時(shí)，NodeB則認(rèn)為上行無(wú)線鏈路失步。（上行失步會(huì)刪除鏈路，立即斷開(kāi)，造成UE最終掉話。）
挽救措施：
NodeB檢測(cè)到上行無(wú)線鏈路失步后，做如下處理：
1)NodeB向RNC上發(fā)“Radio link failure indication”，指示同步失敗。（NodeB——RNC）
2)NodeB停發(fā)下行數(shù)據(jù)，目的是讓UE下行失步，來(lái)上發(fā)CellUpdate。（注：此時(shí)會(huì)在終端側(cè)顯示出DPCH陡降現(xiàn)象。）
3)RNC啟動(dòng)“收到RL失敗等待定時(shí)器”。在該定時(shí)器超時(shí)前，如果未收到“Radio link restore”則RNC釋放鏈路，并記為無(wú)線鏈路失敗的掉話。（NodeB——RNC）
（注釋?zhuān)荷闲惺Р叫枰緛?lái)檢測(cè)，也有類(lèi)似于UE側(cè)的定時(shí)器和計(jì)數(shù)器，一旦發(fā)現(xiàn)上行失步，則NodeB會(huì)上報(bào)RL Failure Indication（NBAP信令）給RNC，同時(shí)RNC會(huì)啟動(dòng)相應(yīng)的無(wú)線鏈路失敗等待定時(shí)器，定時(shí)器超時(shí)則發(fā)起Iu Release Request，記為一次掉話。）
引申：
上行失步DPCH陡降的時(shí)長(zhǎng)：網(wǎng)絡(luò)參數(shù)默認(rèn)值N_OUTSYNC_IND =20，T_RLFAILURE =5s。由此可以計(jì)算出，從第一上行失步開(kāi)始到DPCH陡降的最短時(shí)間為：DPCH陡降時(shí)長(zhǎng)=20*160ms+5000ms =8200ms =8.2s
下行失步：UE側(cè)檢測(cè)
原因：
1、與源小區(qū)下行失步：UE已發(fā)測(cè)量報(bào)告，但由于下行失步，收不到原小區(qū)DPCH數(shù)據(jù)，即收不到物理信道重配置信令（或RB重配置消息），導(dǎo)致無(wú)法切換。
2、與目標(biāo)小區(qū)下行失步：UE收到物理信道重配置消息（RB重配置消息），由于原小區(qū)或周?chē)徯^(qū)對(duì)目標(biāo)小區(qū)的下行信號(hào)有較大的干擾，導(dǎo)致UE無(wú)法正確解析目標(biāo)小區(qū)的下行信號(hào)，不能與目標(biāo)小區(qū)建立同步，而引發(fā)物理信道重配置超時(shí)，發(fā)生掉話問(wèn)題。
（物理信道重配置定時(shí)器不是一個(gè)3GPP協(xié)議定時(shí)器，它是各個(gè)廠家可以自己規(guī)定的私有定時(shí)器，在PHY RECONFIG 發(fā)送完畢后，RNC開(kāi)始計(jì)時(shí)，當(dāng)收到PHY RECONFIG COMPLETE以后，RNC停止計(jì)時(shí)。如果RNC超時(shí)，則會(huì)發(fā)生25.413里面的14號(hào) IU REL REQ的掉話原因（當(dāng)然，可能各廠家規(guī)定不一樣），也有可能是46號(hào)掉話原因。
）
判斷標(biāo)準(zhǔn)：處于CELL_DCH狀態(tài)的UE，連續(xù)接收到來(lái)自物理層的N313個(gè)連續(xù)”out of sync”指示時(shí)，啟動(dòng)定時(shí)器T313，在此過(guò)程中若連續(xù)接收到來(lái)自物理層的N315個(gè)連續(xù)”in sync”指示，T313停止，否則T313超時(shí)，視為下行無(wú)線鏈路失步。（下行失步主要原因?yàn)闊o(wú)線環(huán)境不好，干擾，弱覆蓋等，下行失步會(huì)cellupdate，而且一般可以恢復(fù)通話正常。）
挽救措施：
UE檢測(cè)到下行無(wú)線鏈路失步后，做如下處理：
1)UE的RRC層向物理層下發(fā)“P_RRC_PHY_RL_Release_REQ”釋放物理信道資源；
2)同時(shí)UE關(guān)閉上下行數(shù)據(jù)，并通過(guò)“P_RRC_PHY_CellSearch_REQ”原語(yǔ)讓物理層進(jìn)行小區(qū)的重搜，此時(shí)終端是無(wú)法測(cè)DPCH_RSCP值的，因此會(huì)在終端側(cè)顯示出DPCH陡降現(xiàn)象。
3)在搜到小區(qū)后，UE將在目標(biāo)小區(qū)上進(jìn)行CellUpdate，原因?yàn)椤皉adio link failure”。如果小區(qū)更新成功，則該次下行無(wú)線鏈路失步得到挽救，否則UE發(fā)生掉話。
引申：需要指出的是，各個(gè)終端廠家對(duì)于UE檢測(cè)存在著或多或少的差異，下面列舉的是某芯片廠商處理的情況。
UE的物理層每隔一幀的時(shí)間（10ms），進(jìn)行一次下行無(wú)線鏈路的同步情況的監(jiān)測(cè)。在具體實(shí)施的過(guò)程中，UE側(cè)采用滑窗的形式，滑窗的長(zhǎng)度為160ms，滑窗每10ms移動(dòng)一次。
網(wǎng)絡(luò)參數(shù)默認(rèn)值N313=20，T313=3s，由此可以計(jì)算出UE收到第一個(gè)下行失步指示到DPCH陡降的時(shí)間為：DPCH陡降時(shí)長(zhǎng)=160ms+N313*10ms+T313=3360ms=3.36s
【案例】
案例1：硬切換時(shí)下行鏈路失步
UE在做普通語(yǔ)音業(yè)務(wù)期間，上報(bào)測(cè)量報(bào)告希望進(jìn)行切換。4.5s后UE小區(qū)搜索，讀取系統(tǒng)消息，并做CellUpdate試圖挽救（此過(guò)程在圖中沒(méi)有顯示出來(lái)）。DPCH陡降發(fā)生時(shí)，UE已經(jīng)處于讀取系統(tǒng)消息的時(shí)間。
終端在15：51：09.814發(fā)送測(cè)量報(bào)告，在等了4.5秒后，在15：51：14.314 DPCH發(fā)生陡降，讀取系統(tǒng)消息，并試圖做小區(qū)更新。因此從時(shí)長(zhǎng)的角度來(lái)看，終端是下行鏈路失步。
案例2：切換時(shí)上行鏈路失步
UE在做普通語(yǔ)音業(yè)務(wù)期間，上報(bào)測(cè)量報(bào)告希望進(jìn)行切換。8.5s后UE收到RNC下發(fā)的RRC連接釋放消息，UE發(fā)送RRC連接釋放完成消息，然后UE讀取系統(tǒng)消息。DPCH陡降發(fā)生時(shí)，UE已經(jīng)處于讀取系統(tǒng)消息的時(shí)間。
終端在00：52：25.842發(fā)送測(cè)量報(bào)告，在等了將近8.7秒后，在00：52：34.532 DPCH發(fā)生陡降。因此從時(shí)長(zhǎng)的角度來(lái)看，終端是上行鏈路失步。
案例3：切換時(shí)上行鏈路失步
UE在做普通語(yǔ)音業(yè)務(wù)期間，上報(bào)測(cè)量報(bào)告希望進(jìn)行切換。收到RNC下發(fā)的RB重配命令后，UE上報(bào)RB重配完成消息。12s后UE進(jìn)行小區(qū)搜索，讀取系統(tǒng)消息。DPCH陡降發(fā)生時(shí)，UE已經(jīng)處于讀取系統(tǒng)消息的時(shí)間。
終端在23：03：06.873發(fā)送RB重配完成命令，在等了將近9秒后，在23：03：15.763 DPCH發(fā)生陡降，而后轉(zhuǎn)入空閑態(tài)，并試圖做小區(qū)更新。因此從時(shí)長(zhǎng)的角度來(lái)看，終端是上行鏈路失步。
總之，DPCH陡降在上下行鏈路失步時(shí)，是有很大發(fā)生可能性的，而且按照終端和基站設(shè)備對(duì)DPCH的處理機(jī)制也是合理的。
處理建議：
通過(guò)以上的分析，可以看到DPCH陡降和上下行無(wú)線鏈路失步有很大的關(guān)系，進(jìn)而又和切換過(guò)程中的問(wèn)題有著直接的聯(lián)系，因此對(duì)DPCH陡降現(xiàn)象處理建議為：
1.先理順切換關(guān)系，排除同頻干擾，保證無(wú)線環(huán)境正常；
2.另可通過(guò)調(diào)整上行的SIR Target和DPCH的發(fā)射功率來(lái)改善上下行鏈路質(zhì)量；
3.再一個(gè)就是調(diào)整Uu口定時(shí)器參數(shù)，無(wú)線鏈路失步后，釋放時(shí)間由T313、N313、N315 N_OUTSYNC_IND、T_RLFAILURE等參數(shù)控制。
4.關(guān)注UE，避免測(cè)試時(shí)間過(guò)長(zhǎng)發(fā)熱死機(jī)而影響測(cè)試結(jié)果。
回答者：
OscarDon
回答時(shí)間：2013-04-13 13:51
19
19
• 浙江省郵電工程建設(shè)有限公司
聘：網(wǎng)優(yōu)日常租賃人員
需求人數(shù)：2 人 地點(diǎn)：煙臺(tái)市
• 成都旗訊通信技術(shù)有限公司 聘：【聯(lián)通項(xiàng)目】招督導(dǎo)、維護(hù)轉(zhuǎn)網(wǎng)優(yōu)
需求人數(shù)：12 人 地點(diǎn)：河北省,遼寧省,吉林省,黑龍江,內(nèi)蒙古
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：LTE/5G網(wǎng)絡(luò)中高級(jí)優(yōu)化工程師
需求人數(shù)：2 人 地點(diǎn)：上海市
• 北京宜通華瑞科技有限公司 聘：電信原廠優(yōu)化高級(jí)（江西急聘）
需求人數(shù)：5 人 地點(diǎn)：南昌市
• 西安中興精誠(chéng)通訊有限公司 聘：重慶-網(wǎng)優(yōu)高級(jí)工程師
需求人數(shù)：2 人 地點(diǎn)：重慶市
• 廣東世炬網(wǎng)絡(luò)科技股份有限公司 聘：網(wǎng)管運(yùn)維工程師
需求人數(shù)：2 人 地點(diǎn)：云南省
• 嘉環(huán)科技股份有限公司 聘：網(wǎng)優(yōu)前臺(tái)RF工程師-高級(jí)
需求人數(shù)：2 人 地點(diǎn)：河源市
• 南京華蘇科技有限公司 聘：濟(jì)南省移動(dòng)高端-材料輸出高手優(yōu)先
需求人數(shù)：1 人 地點(diǎn)：濟(jì)南市
• 北京電旗通訊技術(shù)股份有限公司 聘：山東濱州電信
需求人數(shù)：3 人 地點(diǎn)：濱州市
• 廣東華訊工程有限公司 聘：廣東移動(dòng)維護(hù)支撐
需求人數(shù)：2 人 地點(diǎn)：廣州市
需求人數(shù)：2 人 地點(diǎn)：煙臺(tái)市
• 成都旗訊通信技術(shù)有限公司 聘：【聯(lián)通項(xiàng)目】招督導(dǎo)、維護(hù)轉(zhuǎn)網(wǎng)優(yōu)
需求人數(shù)：12 人 地點(diǎn)：河北省,遼寧省,吉林省,黑龍江,內(nèi)蒙古
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：LTE/5G網(wǎng)絡(luò)中高級(jí)優(yōu)化工程師
需求人數(shù)：2 人 地點(diǎn)：上海市
• 北京宜通華瑞科技有限公司 聘：電信原廠優(yōu)化高級(jí)（江西急聘）
需求人數(shù)：5 人 地點(diǎn)：南昌市
• 西安中興精誠(chéng)通訊有限公司 聘：重慶-網(wǎng)優(yōu)高級(jí)工程師
需求人數(shù)：2 人 地點(diǎn)：重慶市
• 廣東世炬網(wǎng)絡(luò)科技股份有限公司 聘：網(wǎng)管運(yùn)維工程師
需求人數(shù)：2 人 地點(diǎn)：云南省
• 嘉環(huán)科技股份有限公司 聘：網(wǎng)優(yōu)前臺(tái)RF工程師-高級(jí)
需求人數(shù)：2 人 地點(diǎn)：河源市
• 南京華蘇科技有限公司 聘：濟(jì)南省移動(dòng)高端-材料輸出高手優(yōu)先
需求人數(shù)：1 人 地點(diǎn)：濟(jì)南市
• 北京電旗通訊技術(shù)股份有限公司 聘：山東濱州電信
需求人數(shù)：3 人 地點(diǎn)：濱州市
• 廣東華訊工程有限公司 聘：廣東移動(dòng)維護(hù)支撐
需求人數(shù)：2 人 地點(diǎn)：廣州市
熱點(diǎn)問(wèn)題
更多精彩
| 聯(lián)系我們 - 問(wèn)通信專(zhuān)家 | Powered by MSCBSC 移動(dòng)通信網(wǎng) © 2006 - |