mdip 和bus討論的都是新版本的上行失步機制問題，他們的回復(fù)不同點在于mdip多了個c步中：
C——經(jīng)過RLRSTRTMR+T302×N302，的等待時長。原來我跟bush對上行失步的處理過程看法是一樣的，但參看了網(wǎng)上另一篇讀文后，我覺得mdip的過程更準(zhǔn)確：

http://labs.chinamobile.com/mblog/7671_88609

但對于樓主理解的“RNC收到該消息后，即啟動RLRSTRMR，若RLRSTRTMR超時仍沒有收到NodeB發(fā)出的RL Restore，則再啟動N302×T302；若RNC依舊沒有收到NodeB發(fā)出的RL Restore，則最終RNC向NodeB發(fā)出的RL DEL�！畱�(yīng)該是樓主理解錯誤，這個等待時長應(yīng)該不分兩次執(zhí)行的。新的問題在于NODEB向RNC發(fā)送RL Failure Indication原語后，基本可以確定上行失步，為什么要等待RLRSTRTMR+T302×N302的時長再關(guān)閉下行發(fā)射讓UE觸發(fā)CELLUPDATE?上述連接中也沒給出具體的說法，也查不到相關(guān)細(xì)致說明，于是有如下猜想：由于T302×N302恰好是CellUpdate的時長，之所以RNC在收到NODEB上行失步指示后會做RLRSTRTMR+T302×N302的等待時長，1是因為可能在接下來的時間，仍可能收到nodeb的RL Restore Indication原語；2更可能是因為考慮到上下行均失步的問題，設(shè)想當(dāng)UE上下行均出現(xiàn)失步，一般來說下行失步觸發(fā)cellUpdate的時間更短些，如果UE上下行均失步了，那么UE很可能因為下行失步已經(jīng)發(fā)起了CELLUPDATE，那么RNC也就沒有必要及時向NodeB發(fā)送RL Del，要求NodeB關(guān)閉下行鏈路功率，以強迫UE進(jìn)行CellUpdate了，于是，在收到NODEB的上行失步原語后，作一個'常量+隨機形式“的等待。

以上觀點屬個人觀點，回帖的意義在于：
1。加強學(xué)習(xí)交流。
2。把此貼頂上去。
3。期待高手解答。