 |
善于提問，勤于回答，你也是專家
|
 |
問題已開啟
(普通問題)
如何判斷上行失步還是下行失步
如何判斷無線鏈路失敗是上行問題還是下行問題？cellupdate時如何進行目標小區(qū)的選擇，什么時候選擇本小區(qū)，什么時候選擇其他小區(qū)？
提問者:
• 上行PRB利用率高 2020-07-13
• 上行波形自適應中的snr如何獲得？ 2020-03-07
• 上行干擾怎么解決 2019-10-10
• 哪些上行哪些下行 2019-10-07
• 中國電信集團黨組書記，董事長柯瑞文說，在5G時代，中國電信堅持全網(wǎng)通終端，堅持超級上行（這要全雙工）和wifi6，堅持NSA和SA雙模全網(wǎng)通標準（肯定是Option7x與Option4重了！）。“這個 2019-09-25
• nbiot上行資源調(diào)度用什么仿真軟件啊 2019-05-22
• 聯(lián)通現(xiàn)在用的GL和UL設備，LTE載波的頻率是多少到多少（上行和下行） 2019-04-30
• 知道LTE的下行頻率、頻點信息，能不能知道上行 2018-12-20
• 上行波形自適應中的snr如何獲得？ 2020-03-07
• 上行干擾怎么解決 2019-10-10
• 哪些上行哪些下行 2019-10-07
• 中國電信集團黨組書記，董事長柯瑞文說，在5G時代，中國電信堅持全網(wǎng)通終端，堅持超級上行（這要全雙工）和wifi6，堅持NSA和SA雙模全網(wǎng)通標準（肯定是Option7x與Option4重了！）。“這個 2019-09-25
• nbiot上行資源調(diào)度用什么仿真軟件啊 2019-05-22
• 聯(lián)通現(xiàn)在用的GL和UL設備，LTE載波的頻率是多少到多少（上行和下行） 2019-04-30
• 知道LTE的下行頻率、頻點信息，能不能知道上行 2018-12-20
問題答案
( 1 )
失步的具體表現(xiàn)為不同步的信號將會對相鄰時隙的信號產(chǎn)生干擾，而當相位偏移嚴重使得上行信號在下行時隙發(fā)送（或下行信號在上行時隙發(fā)送）時，則對服務地區(qū)通訊產(chǎn)生嚴重干擾，使該地區(qū)通話質(zhì)量和話務指標下降，譬如：通話時雜音大，下行尋呼響應次數(shù)很低，頻率阻塞率提高等；嚴重時還會造成C-CH丟失時隙、基站Block。
針對上行和下行，失步分為上行鏈路失步和下行鏈路失步兩種。在協(xié)議里面針對上行鏈路失步和下行鏈路失步分別定義了判斷標準：
上行鏈路失步會刪除鏈路，下行失步會cellupdate，而且現(xiàn)在的情況是一般出現(xiàn)了上行失步后基本上都恢復不了，造成UE最終掉話，而下行時刻有時可以通過cellupdate過程恢復。
引起上行和下行鏈路失步的原因又不能簡單地認為是某一方面的問題，而是由于交互作用引起的。
下行失步：主要是基站和終端由于無線環(huán)境不好，原因較多的就是弱覆蓋等因素導致，這個原因值在路測軟件中，和網(wǎng)管跟蹤的信令中都有，主要就是無線環(huán)境不好，干擾，弱覆蓋等。
上行失步：主要是目標小區(qū)上行UPPCH干擾嚴重，或者同時有其他UE的上行同步碰撞，導致和目標小區(qū)的上行同步失�。换驹诮邮盏剑眨诺恼{(diào)度資源信息或釋放非調(diào)度資源通知后，長時間不能為ＵＥ分配調(diào)度資源且無法向ＵＥ發(fā)送ＳＳ命令，而造成的ＵＥ的失步。目標小區(qū)的UPPTS期望接收到的功率設置過小、功率步長設置不合理，可能會導致切換失敗。
上行失步和下行失步
上行失步：基站側(cè)檢測
原因：
1、與目標小區(qū)上行失步：UE收到物理信道重配置消息，由于UP存在干擾或FPACH信道的C/I或信號質(zhì)量較差，UE不能在新小區(qū)建立上行同步，導致幀定時跟蹤出現(xiàn)問題，這樣UE無法在目標小區(qū)正確收發(fā)，發(fā)生切換失敗。如果源小區(qū)的RL沒有刪除，RNC會通過源小區(qū)給UE下發(fā)物理信道重配失�。ɑ騌B重配失�。�，UE回到源小區(qū)，反之則發(fā)生掉話。（上行同步失敗）
2、與目標小區(qū)上行失步：UE已向目標NodeB發(fā)送物理信道重配置（RB重配置）完成信令，但是由于目標小區(qū)NodeB底噪過高，或此時多部UE位于小區(qū)邊緣，且上行發(fā)射功率都被抬升的比較高導致產(chǎn)生較大的上行時隙干擾，使得目標小區(qū)NodeB無法正確解析重配置完成的信令，而引發(fā)物理信道重配置超時。（uncomplete）
判斷標準：
在同步保持階段，NodeB對于物理層兩個連續(xù)同步指示的時間間隔為160ms，NB在收到N_OUTSYNC_IND個連續(xù)失步指示后，將啟動“無線鏈路失敗過程定時器”T_RLFAILURE，在收到N_SYNC_IND個同步狀態(tài)指示后，NodeB將停止和復位T_RLFAILURE，如果T_RLFAILURE超時，NodeB則認為上行無線鏈路失步。（上行失步會刪除鏈路，立即斷開，造成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會啟動相應的無線鏈路失敗等待定時器，定時器超時則發(fā)起Iu Release Request，記為一次掉話。）
引申：
上行失步DPCH陡降的時長：網(wǎng)絡參數(shù)默認值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重配置消息），導致無法切換。
2、與目標小區(qū)下行失步：UE收到物理信道重配置消息（RB重配置消息），由于原小區(qū)或周圍鄰小區(qū)對目標小區(qū)的下行信號有較大的干擾，導致UE無法正確解析目標小區(qū)的下行信號，不能與目標小區(qū)建立同步，而引發(fā)物理信道重配置超時，發(fā)生掉話問題。
（物理信道重配置定時器不是一個3GPP協(xié)議定時器，它是各個廠家可以自己規(guī)定的私有定時器，在PHY RECONFIG 發(fā)送完畢后，RNC開始計時，當收到PHY RECONFIG COMPLETE以后，RNC停止計時。如果RNC超時，則會發(fā)生25.413里面的14號 IU REL REQ的掉話原因（當然，可能各廠家規(guī)定不一樣），也有可能是46號掉話原因。
）
判斷標準：處于CELL_DCH狀態(tài)的UE，連續(xù)接收到來自物理層的N313個連續(xù)”out of sync”指示時，啟動定時器T313，在此過程中若連續(xù)接收到來自物理層的N315個連續(xù)”in sync”指示，T313停止，否則T313超時，視為下行無線鏈路失步。（下行失步主要原因為無線環(huán)境不好，干擾，弱覆蓋等，下行失步會cellupdate，而且一般可以恢復通話正常。）
挽救措施：
UE檢測到下行無線鏈路失步后，做如下處理：
1)UE的RRC層向物理層下發(fā)“P_RRC_PHY_RL_Release_REQ”釋放物理信道資源；
2)同時UE關(guān)閉上下行數(shù)據(jù)，并通過“P_RRC_PHY_CellSearch_REQ”原語讓物理層進行小區(qū)的重搜，此時終端是無法測DPCH_RSCP值的，因此會在終端側(cè)顯示出DPCH陡降現(xiàn)象。
3)在搜到小區(qū)后，UE將在目標小區(qū)上進行CellUpdate，原因為“radio link failure”。如果小區(qū)更新成功，則該次下行無線鏈路失步得到挽救，否則UE發(fā)生掉話。
引申：需要指出的是，各個終端廠家對于UE檢測存在著或多或少的差異，下面列舉的是某芯片廠商處理的情況。
UE的物理層每隔一幀的時間（10ms），進行一次下行無線鏈路的同步情況的監(jiān)測。在具體實施的過程中，UE側(cè)采用滑窗的形式，滑窗的長度為160ms，滑窗每10ms移動一次。
網(wǎng)絡參數(shù)默認值N313=20，T313=3s，由此可以計算出UE收到第一個下行失步指示到DPCH陡降的時間為：DPCH陡降時長=160ms+N313*10ms+T313=3360ms=3.36s
【案例】
案例1：硬切換時下行鏈路失步
UE在做普通語音業(yè)務期間，上報測量報告希望進行切換。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è)務期間，上報測量報告希望進行切換。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è)務期間，上報測量報告希望進行切換。收到RNC下發(fā)的RB重配命令后，UE上報RB重配完成消息。12s后UE進行小區(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ā)生可能性的，而且按照終端和基站設備對DPCH的處理機制也是合理的。
處理建議：
通過以上的分析，可以看到DPCH陡降和上下行無線鏈路失步有很大的關(guā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ā)熱死機而影響測試結(jié)果。
針對上行和下行，失步分為上行鏈路失步和下行鏈路失步兩種。在協(xié)議里面針對上行鏈路失步和下行鏈路失步分別定義了判斷標準：
上行鏈路失步會刪除鏈路，下行失步會cellupdate，而且現(xiàn)在的情況是一般出現(xiàn)了上行失步后基本上都恢復不了，造成UE最終掉話，而下行時刻有時可以通過cellupdate過程恢復。
引起上行和下行鏈路失步的原因又不能簡單地認為是某一方面的問題，而是由于交互作用引起的。
下行失步：主要是基站和終端由于無線環(huán)境不好，原因較多的就是弱覆蓋等因素導致，這個原因值在路測軟件中，和網(wǎng)管跟蹤的信令中都有，主要就是無線環(huán)境不好，干擾，弱覆蓋等。
上行失步：主要是目標小區(qū)上行UPPCH干擾嚴重，或者同時有其他UE的上行同步碰撞，導致和目標小區(qū)的上行同步失�。换驹诮邮盏剑眨诺恼{(diào)度資源信息或釋放非調(diào)度資源通知后，長時間不能為ＵＥ分配調(diào)度資源且無法向ＵＥ發(fā)送ＳＳ命令，而造成的ＵＥ的失步。目標小區(qū)的UPPTS期望接收到的功率設置過小、功率步長設置不合理，可能會導致切換失敗。
上行失步和下行失步
上行失步：基站側(cè)檢測
原因：
1、與目標小區(qū)上行失步：UE收到物理信道重配置消息，由于UP存在干擾或FPACH信道的C/I或信號質(zhì)量較差，UE不能在新小區(qū)建立上行同步，導致幀定時跟蹤出現(xiàn)問題，這樣UE無法在目標小區(qū)正確收發(fā)，發(fā)生切換失敗。如果源小區(qū)的RL沒有刪除，RNC會通過源小區(qū)給UE下發(fā)物理信道重配失�。ɑ騌B重配失�。�，UE回到源小區(qū)，反之則發(fā)生掉話。（上行同步失敗）
2、與目標小區(qū)上行失步：UE已向目標NodeB發(fā)送物理信道重配置（RB重配置）完成信令，但是由于目標小區(qū)NodeB底噪過高，或此時多部UE位于小區(qū)邊緣，且上行發(fā)射功率都被抬升的比較高導致產(chǎn)生較大的上行時隙干擾，使得目標小區(qū)NodeB無法正確解析重配置完成的信令，而引發(fā)物理信道重配置超時。（uncomplete）
判斷標準：
在同步保持階段，NodeB對于物理層兩個連續(xù)同步指示的時間間隔為160ms，NB在收到N_OUTSYNC_IND個連續(xù)失步指示后，將啟動“無線鏈路失敗過程定時器”T_RLFAILURE，在收到N_SYNC_IND個同步狀態(tài)指示后，NodeB將停止和復位T_RLFAILURE，如果T_RLFAILURE超時，NodeB則認為上行無線鏈路失步。（上行失步會刪除鏈路，立即斷開，造成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會啟動相應的無線鏈路失敗等待定時器，定時器超時則發(fā)起Iu Release Request，記為一次掉話。）
引申：
上行失步DPCH陡降的時長：網(wǎng)絡參數(shù)默認值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重配置消息），導致無法切換。
2、與目標小區(qū)下行失步：UE收到物理信道重配置消息（RB重配置消息），由于原小區(qū)或周圍鄰小區(qū)對目標小區(qū)的下行信號有較大的干擾，導致UE無法正確解析目標小區(qū)的下行信號，不能與目標小區(qū)建立同步，而引發(fā)物理信道重配置超時，發(fā)生掉話問題。
（物理信道重配置定時器不是一個3GPP協(xié)議定時器，它是各個廠家可以自己規(guī)定的私有定時器，在PHY RECONFIG 發(fā)送完畢后，RNC開始計時，當收到PHY RECONFIG COMPLETE以后，RNC停止計時。如果RNC超時，則會發(fā)生25.413里面的14號 IU REL REQ的掉話原因（當然，可能各廠家規(guī)定不一樣），也有可能是46號掉話原因。
）
判斷標準：處于CELL_DCH狀態(tài)的UE，連續(xù)接收到來自物理層的N313個連續(xù)”out of sync”指示時，啟動定時器T313，在此過程中若連續(xù)接收到來自物理層的N315個連續(xù)”in sync”指示，T313停止，否則T313超時，視為下行無線鏈路失步。（下行失步主要原因為無線環(huán)境不好，干擾，弱覆蓋等，下行失步會cellupdate，而且一般可以恢復通話正常。）
挽救措施：
UE檢測到下行無線鏈路失步后，做如下處理：
1)UE的RRC層向物理層下發(fā)“P_RRC_PHY_RL_Release_REQ”釋放物理信道資源；
2)同時UE關(guān)閉上下行數(shù)據(jù)，并通過“P_RRC_PHY_CellSearch_REQ”原語讓物理層進行小區(qū)的重搜，此時終端是無法測DPCH_RSCP值的，因此會在終端側(cè)顯示出DPCH陡降現(xiàn)象。
3)在搜到小區(qū)后，UE將在目標小區(qū)上進行CellUpdate，原因為“radio link failure”。如果小區(qū)更新成功，則該次下行無線鏈路失步得到挽救，否則UE發(fā)生掉話。
引申：需要指出的是，各個終端廠家對于UE檢測存在著或多或少的差異，下面列舉的是某芯片廠商處理的情況。
UE的物理層每隔一幀的時間（10ms），進行一次下行無線鏈路的同步情況的監(jiān)測。在具體實施的過程中，UE側(cè)采用滑窗的形式，滑窗的長度為160ms，滑窗每10ms移動一次。
網(wǎng)絡參數(shù)默認值N313=20，T313=3s，由此可以計算出UE收到第一個下行失步指示到DPCH陡降的時間為：DPCH陡降時長=160ms+N313*10ms+T313=3360ms=3.36s
【案例】
案例1：硬切換時下行鏈路失步
UE在做普通語音業(yè)務期間，上報測量報告希望進行切換。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è)務期間，上報測量報告希望進行切換。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è)務期間，上報測量報告希望進行切換。收到RNC下發(fā)的RB重配命令后，UE上報RB重配完成消息。12s后UE進行小區(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ā)生可能性的，而且按照終端和基站設備對DPCH的處理機制也是合理的。
處理建議：
通過以上的分析，可以看到DPCH陡降和上下行無線鏈路失步有很大的關(guā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ā)熱死機而影響測試結(jié)果。
回答者：
OscarDon
回答時間：2013-04-13 13:51
19
19
• 重慶信科通信工程有限公司
聘：南昌電信中興原廠高級
需求人數(shù)：2 人 地點：南昌市
• 嘉環(huán)科技股份有限公司 聘：湖南電信原廠優(yōu)化招聘
需求人數(shù)：10 人 地點：長沙市,永州市,郴州市,衡陽市
• 重慶愛信思科技有限責任公司 聘：初中級OTN/PTN調(diào)測工程師
需求人數(shù)：5 人 地點：唐山市,承德市,張家口市
• 西安中興精誠通訊有限公司 聘：重慶-網(wǎng)優(yōu)高級工程師
需求人數(shù)：2 人 地點：重慶市
• 杭州華星創(chuàng)業(yè)通信技術(shù)股份有限公司 聘：山西移動晉中項目中級前臺
需求人數(shù)：2 人 地點：晉中市
• 北京電旗通訊技術(shù)股份有限公司 聘：網(wǎng)優(yōu)實習生通信應屆生（云南）
需求人數(shù)：1 人 地點：昆明市,思茅市,昭通市
• 南京欣網(wǎng)通信科技股份有限公司 聘：后臺網(wǎng)優(yōu)工程師(J10066)
需求人數(shù)：1 人 地點：榆林市
• 安徽引途科技有限公司 聘：皖北地區(qū)單驗測試工程師
需求人數(shù)：20 人 地點：安徽省
• 浙江明訊網(wǎng)絡技術(shù)有限公司 聘：浙江網(wǎng)絡優(yōu)化工程師
需求人數(shù)：8 人 地點：寧波市,舟山市,湖州市,紹興市
• 西安長河通訊有限責任公司 聘：網(wǎng)絡優(yōu)化工程師
需求人數(shù)：2 人 地點：安康市
需求人數(shù)：2 人 地點：南昌市
• 嘉環(huán)科技股份有限公司 聘：湖南電信原廠優(yōu)化招聘
需求人數(shù)：10 人 地點：長沙市,永州市,郴州市,衡陽市
• 重慶愛信思科技有限責任公司 聘：初中級OTN/PTN調(diào)測工程師
需求人數(shù)：5 人 地點：唐山市,承德市,張家口市
• 西安中興精誠通訊有限公司 聘：重慶-網(wǎng)優(yōu)高級工程師
需求人數(shù)：2 人 地點：重慶市
• 杭州華星創(chuàng)業(yè)通信技術(shù)股份有限公司 聘：山西移動晉中項目中級前臺
需求人數(shù)：2 人 地點：晉中市
• 北京電旗通訊技術(shù)股份有限公司 聘：網(wǎng)優(yōu)實習生通信應屆生（云南）
需求人數(shù)：1 人 地點：昆明市,思茅市,昭通市
• 南京欣網(wǎng)通信科技股份有限公司 聘：后臺網(wǎng)優(yōu)工程師(J10066)
需求人數(shù)：1 人 地點：榆林市
• 安徽引途科技有限公司 聘：皖北地區(qū)單驗測試工程師
需求人數(shù)：20 人 地點：安徽省
• 浙江明訊網(wǎng)絡技術(shù)有限公司 聘：浙江網(wǎng)絡優(yōu)化工程師
需求人數(shù)：8 人 地點：寧波市,舟山市,湖州市,紹興市
• 西安長河通訊有限責任公司 聘：網(wǎng)絡優(yōu)化工程師
需求人數(shù)：2 人 地點：安康市
熱點問題
更多精彩
| 聯(lián)系我們 - 問通信專家 | Powered by MSCBSC 移動通信網(wǎng) © 2006 - |