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