專利名稱：小區(qū)更新的實(shí)現(xiàn)方法
技術(shù)領(lǐng)域：
本發(fā)明涉及寬帶碼分多址(WCDMAWideband Code Division MultipleAccess)系統(tǒng)，特別是關(guān)于WCDMA系統(tǒng)的小區(qū)更新的實(shí)現(xiàn)方法。
背景技術(shù)：
對(duì)于WCDMA系統(tǒng)中處于小區(qū)_尋呼信道(CELL_PCH，為移動(dòng)用戶所處的一種狀態(tài))或小區(qū)_向前接入信道(CELL_FACH，為移動(dòng)用戶所處的一種狀態(tài))狀態(tài)的用戶終端(UE)，當(dāng)已經(jīng)建立無線資源控制(RRCRadio Resource Control)連接并且用戶終端的小區(qū)位置為通用陸地?zé)o線接入網(wǎng)(UTRANUniversalTerrestrial Radio Access Network)所知的情況下，小區(qū)更新就是更新網(wǎng)絡(luò)側(cè)用戶終端小區(qū)級(jí)位置信息的過程。
參考圖1，是現(xiàn)有技術(shù)WCDMA系統(tǒng)中小區(qū)更新流程的示意圖。該WCDMA系統(tǒng)中小區(qū)更新的流程包括以下步驟步驟一、UE向無線網(wǎng)絡(luò)控制器(RNCRadio Network Controller)發(fā)送小區(qū)更新(CELL UPDATE)消息；步驟二、RNC向UE返回小區(qū)更新確認(rèn)(CELL UPDATE CONFIRM)消息；步驟三、UE將根據(jù)CELL UPDATE CONFIRM消息中的相關(guān)信元向RNC傳送應(yīng)答消息。
上述小區(qū)更新的詳細(xì)過程可以參見3GPP TS25331協(xié)議中“Cell and URAupdate procedures”章節(jié)的描述。
在該小區(qū)更新的流程中，會(huì)存在小區(qū)更新重發(fā)的機(jī)制。小區(qū)更新重發(fā)具體的說就是UE發(fā)送CELL UPDATE消息后會(huì)啟動(dòng)T302定時(shí)器設(shè)定時(shí)鐘周期，當(dāng)該時(shí)鐘周期內(nèi)收到CELL UPDATE CONFIRM消息后停止T302定時(shí)器；但是當(dāng)T302定時(shí)器超時(shí)，即該時(shí)鐘周期內(nèi)未收到CELL UPDATE CONFIRM消息時(shí)，若V302＜＝N302則UE重發(fā)CELL UPDATE消息，若V302＞N302則UE進(jìn)入空閑模式，其中V302表示發(fā)送CELL UPDATE消息的次數(shù)，N302表示CELL UPDATE消息重發(fā)的最大次數(shù)。
在RNC接收到多個(gè)CELL UPDATE消息后，RNC同樣也會(huì)返回相同數(shù)目的CELL UPDATE CONFIRM消息，如圖2所示。由于RNC可以并行發(fā)起多個(gè)消息類型相同的RRC過程，因此在UE和RNC之間的下行的消息中將攜帶無線資源控制事務(wù)標(biāo)識(shí)(RRC TRANSACTION ID)，將該多個(gè)并行發(fā)起的RRC過程區(qū)分開。該RRC TRANSACTION ID和消息類型一起，在某一個(gè)時(shí)間點(diǎn)上唯一地標(biāo)識(shí)一個(gè)RNC和UE之間的下行RRC過程。對(duì)于小區(qū)更新消息，不管是不是重發(fā)的消息，RNC在給UE返回應(yīng)答消息CELL UPDATE CONFIRM時(shí)，都會(huì)將RRC TRANSACTION ID遞增。
按照小區(qū)更新重發(fā)機(jī)制的規(guī)定，UE發(fā)送第一個(gè)CELL UPDATE消息之后，必須等待T302定時(shí)器超時(shí)才可以重發(fā)CELL UPDATE消息，這樣，在T302定時(shí)器的合理配置下，可以確保UE發(fā)送CELL UPDATE消息后，RNC有足夠的時(shí)間返回CELL UPDATE CONFIRM消息。
但是，在實(shí)際中發(fā)現(xiàn)有些UE并不遵循小區(qū)更新重發(fā)機(jī)制的規(guī)定，UE會(huì)在發(fā)送第一個(gè)CELL UPDATE消息之后，在T302定時(shí)器超時(shí)之前，重發(fā)CELLUPDATE消息。在時(shí)鐘周期內(nèi)，UE重發(fā)CELL UPDATE消息的具體流程的說明參考圖3和圖4，圖3是從RNC側(cè)說明在時(shí)鐘周期內(nèi)UE重發(fā)CELL UPDATE消息實(shí)現(xiàn)小區(qū)更新的具體流程圖，圖4是從UE側(cè)說明在時(shí)鐘周期內(nèi)UE重發(fā)CELL UPDATE消息實(shí)現(xiàn)小區(qū)更新的具體流程圖。
圖3中，從RNC側(cè)說明在時(shí)鐘周期內(nèi)UE重發(fā)CELL UPDATE消息實(shí)現(xiàn)小區(qū)更新的具體流程包括以下步驟1)UE發(fā)起小區(qū)更新過程，向RNC發(fā)送CELL UPDATE消息；2)隨后RNC返回CELL UDPATE CONFIRM消息，其攜帶的RRCTRANSACTION ID為1；3)在T302定時(shí)器超時(shí)之前，UE向RNC重發(fā)CELL UPDATE消息；4)RNC返回RRC TRANSACTION ID為2的CELL UPDATE CONFIRM消息；
5)UE收到了RRC TRANSACTION ID為1的CELL UPDATE CONFIRM消息后，發(fā)送RRC TRANSACTION ID為1的UTRAN移動(dòng)性信息確認(rèn)(UTRAN MOBILITY INFORMATION CONFIRM)消息給RNC，此時(shí)UE側(cè)小區(qū)更新流程結(jié)束。
但是，在步驟4)中RNC已發(fā)出RRC TRANSACTION ID為2的CELLUPDATE CONFIRM消息，因此在之后的時(shí)間RNC只等待接收并且處理RRCTRANSACTION ID為2的UTRAN MOBILITY INFORMATION CONFIRM消息；當(dāng)在步驟5)中RNC收到RRC TRANSACTION ID為1的UTRANMOBILITY INFORMATION CONFIRM消息時(shí)，由于RRC TRANSACTION ID不匹配，RNC將該消息丟棄。之后RNC仍在等待UE返回RRC TRANSACTIONID為2的UTRAN MOBILITY INFORMATION CONFIRM消息，但是由于在步驟5)后，UE側(cè)的小區(qū)更新流程已經(jīng)結(jié)束，UE不會(huì)再發(fā)出相應(yīng)的消息了，因此RNC會(huì)等不到RRC TRANSACTION ID為2的UTRAN MOBILITYINFORMATION CONFIRM消息，于是流程失敗，RNC發(fā)送IU接口釋放請(qǐng)求(IU RELEASE REQUEST)消息，隨后RNC接管UE失敗，UE掉話。
圖4中，從UE側(cè)說明在時(shí)鐘周期內(nèi)UE重發(fā)CELL UPDATE消息實(shí)現(xiàn)小區(qū)更新的具體流程包括以下步驟1)UE發(fā)起小區(qū)更新過程，向RNC發(fā)送CELL UPDATE消息；2)在T302定時(shí)器超時(shí)之前，UE向RNC重發(fā)CELLUPDATE消息；3)隨后RNC返回CELL UDPATE CONFIRM消息，其攜帶的RRCTRANSACTION ID為1；4)UE收到CELL UPDATE CONFIRM消息，發(fā)送RRC TRANSACTION ID為1的UTRAN MOBILITY INFORMATION CONFIRM消息，此時(shí)UE側(cè)小區(qū)更新流程結(jié)束；5)RNC回復(fù)RRC TRANSACTION ID為2的CELL UPDATE CONFIRM消息給UE。
在步驟5)后，RNC會(huì)在等待UE返回RRC TRANSACTION ID為2的UTRAN MOBILITY INFORMATION CONFIRM消息，但是由于在步驟4)后，UE側(cè)的小區(qū)更新流程已經(jīng)結(jié)束，UE不會(huì)再發(fā)出相應(yīng)的消息了，因此RNC會(huì)等不到RRC TRANSACTION ID為2的UTRAN MOBILITY INFORMATIONCONFIRM消息，于是流程失敗，RNC發(fā)送IU RELEASE REQUEST消息，隨后RNC接管UE失敗，UE掉話。
發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問題是提供一種小區(qū)更新的實(shí)現(xiàn)方法，其可解決現(xiàn)有技術(shù)小區(qū)更新過程中掉話的問題。
為解決上述技術(shù)問題，本發(fā)明的目的是通過以下技術(shù)方案實(shí)現(xiàn)的。
一種小區(qū)更新的實(shí)現(xiàn)方法，其包括以下步驟A)用戶終端發(fā)送小區(qū)更新請(qǐng)求；B)無線網(wǎng)絡(luò)控制器接收到所述的小區(qū)更新請(qǐng)求后，向所述用戶終端返回小區(qū)更新確認(rèn)；C)用戶終端根據(jù)所述確認(rèn)向無線網(wǎng)絡(luò)控制器傳送應(yīng)答消息，無線網(wǎng)絡(luò)控制器接收該應(yīng)答消息，接管用戶終端，完成小區(qū)更新過程；其中在一個(gè)小區(qū)更新流程中，無線網(wǎng)絡(luò)控制器返回的小區(qū)更新確認(rèn)攜帶的標(biāo)識(shí)相同。
所述步驟A)中，用戶終端發(fā)送第一個(gè)小區(qū)更新請(qǐng)求時(shí)設(shè)定時(shí)鐘周期，在所述時(shí)鐘周期內(nèi)用戶終端重發(fā)小區(qū)更新請(qǐng)求。
用戶終端可一次或多次重發(fā)小區(qū)更新請(qǐng)求。
所述應(yīng)答消息是UTRAN移動(dòng)性信息確認(rèn)消息、物理信道重配置完成消息、傳輸信道重配置完成消息、無線承載釋放完成消息或者無線承載重配完成消息之中一種或任意組合。
所述步驟B)中，所述標(biāo)識(shí)為無線資源控制事務(wù)標(biāo)識(shí)，所述無線資源控制事務(wù)標(biāo)識(shí)可將多個(gè)并行發(fā)起的無線資源控制過程區(qū)分。
由于在同一個(gè)小區(qū)更新流程中，無線網(wǎng)絡(luò)控制器始終返回相同事務(wù)標(biāo)識(shí)的確認(rèn)信息，因此當(dāng)用戶終端在同一個(gè)小區(qū)更新流程中多次重發(fā)小區(qū)更新請(qǐng)求時(shí)，無線網(wǎng)絡(luò)控制器與用戶終端也始終使用相同的事務(wù)標(biāo)識(shí)進(jìn)行信令交換。換而言之，即使無線網(wǎng)絡(luò)控制器已經(jīng)根據(jù)用戶終端重復(fù)發(fā)出的小區(qū)更新請(qǐng)求，多次發(fā)出更新確認(rèn)，由于其始終返回相同事務(wù)標(biāo)識(shí)的確認(rèn)信息，因此UE根據(jù)無線網(wǎng)絡(luò)控制器之前發(fā)出的更新確認(rèn)而返回的應(yīng)答消息能夠與無線網(wǎng)絡(luò)控制器當(dāng)前發(fā)出的更新確認(rèn)匹配。無線網(wǎng)絡(luò)控制器根據(jù)接收到的應(yīng)答消息接管用戶終端，成功完成小區(qū)更新的操作。因此本發(fā)明成功地解決了現(xiàn)有技術(shù)中小區(qū)更新過程中用戶終端掉話的問題。
圖1是現(xiàn)有技術(shù)WCDMA系統(tǒng)中小區(qū)更新流程的示意圖。
圖2是UE重發(fā)CELL UPDATE消息時(shí)，小區(qū)更新流程示意圖。
圖3是現(xiàn)有技術(shù)從RNC側(cè)說明在同一小區(qū)更新流程內(nèi)UE重發(fā)CELLUPDATE消息時(shí)，小區(qū)更新的具體流程圖。
圖4是現(xiàn)有技術(shù)從UE側(cè)說明在同一小區(qū)更新流程內(nèi)UE重發(fā)CELLUPDATE消息時(shí)，小區(qū)更新的具體流程圖。
圖5是本發(fā)明從RNC側(cè)說明在同一小區(qū)更新流程內(nèi)UE重發(fā)CELLUPDATE消息時(shí)，小區(qū)更新的具體流程圖。
圖6是本發(fā)明從UE側(cè)說明在同一小區(qū)更新流程內(nèi)UE重發(fā)CELL UPDATE消息時(shí)，小區(qū)更新的具體流程圖。
具體實(shí)施例方式
以下結(jié)合附圖和具體實(shí)施方式
，進(jìn)一步說明本發(fā)明。
在WCDMA系統(tǒng)中，小區(qū)更新的流程包括以下步驟步驟一、UE向無線網(wǎng)絡(luò)控制器(RNCRadio Network Controller)發(fā)小區(qū)更新(CELL UPDATE)消息；步驟二、RNC向UE返回小區(qū)更新確認(rèn)(CELL UPDATE CONFIRM)消息；步驟三、UE將根據(jù)CELL UPDATE CONFIRM消息中的相關(guān)信元向RNC傳送應(yīng)答消息。
在步驟三中，該應(yīng)答消息可以為以下消息的一種或任意組合①UTRAN移動(dòng)性信息確認(rèn)消息(UTRAN MOBILITY INFORMATIONCONFIRM)；②物理信道重配置完成消息(PHYSICAL CHANNELRECONFIGURATION COMPLETE)；③傳輸信道重配置完成消息(TRANSPORT CHANNELRECONFIGURATION COMPLETE)；④無線承載釋放完成消息(RADIO BEARER RECONFIGURATIONCOMPLETER)；⑤無線承載重配完成消息(RADIO BEARER RELEASE COMPLETE)。
該UE發(fā)送應(yīng)答消息后，UE側(cè)已完成小區(qū)更新過程，當(dāng)RNC接收到該應(yīng)答消息后會(huì)正式接管該UE，完成小區(qū)更新。
本發(fā)明的小區(qū)更新的實(shí)現(xiàn)方法，其包括以下步驟A)UE發(fā)送小區(qū)更新請(qǐng)求；B)RNC接收到所述的小區(qū)更新請(qǐng)求后，向UE返回小區(qū)更新確認(rèn)；C)UE根據(jù)所述確認(rèn)向RNC傳送應(yīng)答消息，RNC接收該應(yīng)答消息，接管UE，完成小區(qū)更新過程；其中在一個(gè)小區(qū)更新流程中，RNC返回的小區(qū)更新確認(rèn)攜帶的標(biāo)識(shí)相同。
由于在同一個(gè)小區(qū)更新流程中，RNC始終返回相同事務(wù)標(biāo)識(shí)的確認(rèn)信息，因此當(dāng)UE在同一個(gè)小區(qū)更新流程中多次重發(fā)小區(qū)更新請(qǐng)求時(shí)，RNC與UE也始終使用相同的事務(wù)標(biāo)識(shí)進(jìn)行信令交換。換而言之，即使RNC已經(jīng)根據(jù)UE重復(fù)發(fā)出的小區(qū)更新請(qǐng)求，多次發(fā)出更新確認(rèn)，由于其始終返回相同事務(wù)標(biāo)識(shí)的確認(rèn)信息，因此UE根據(jù)RNC之前發(fā)出的更新確認(rèn)而返回的應(yīng)答消息能夠與RNC當(dāng)前發(fā)出的更新確認(rèn)匹配。RNC根據(jù)接收到的應(yīng)答消息接管UE，成功完成小區(qū)更新的操作。因此本發(fā)明成功地解決了現(xiàn)有技術(shù)中小區(qū)更新過程中UE掉話的問題。
參閱圖5和圖6，圖5是從RNC側(cè)說明同一小區(qū)更新流程內(nèi)UE重發(fā)CELLUPDATE消息時(shí)小區(qū)更新的具體流程圖，圖6是從UE側(cè)說明UE重發(fā)CELLUPDATE消息時(shí)小區(qū)更新的具體流程圖。
圖5中，從RNC側(cè)說明UE重發(fā)CELL UPDATE消息時(shí)小區(qū)更新的具體流程包括以下步驟1)處于CELL_PCH或CELL_FACH狀態(tài)的UE通過無線資源控制(RRC)協(xié)議向RNC發(fā)送CELL UPDATE消息；2)隨后RNC返回CELL UDPATE CONFIRM消息，該CELL UDPATECONFIRM消息攜帶的標(biāo)識(shí)為1；3)UE向RNC重發(fā)CELL UPDATE消息；4)RNC再次返回CELL UPDATE CONFIRM消息，該CELL UDPATECONFIRM消息攜帶的標(biāo)識(shí)同樣為1；5)UE收到了標(biāo)識(shí)為1的CELL UPDATE CONFIRM消息后，通過無線資源控制(RRC)協(xié)議過程發(fā)送標(biāo)識(shí)為1的應(yīng)答消息給RNC，此時(shí)UE側(cè)完成小區(qū)更新過程。
在步驟1)中，用戶終端發(fā)送第一個(gè)CELL UPDATE消息時(shí)設(shè)定時(shí)鐘周期，步驟3)中用戶終端在所述時(shí)鐘周期內(nèi)重發(fā)CELL UPDATE消息。
步驟2)、步驟4)及步驟5)中，CELL UDPATE CONFIRM消息和應(yīng)答消息中攜帶的標(biāo)識(shí)均為RRC TRANSACTION ID。該RRC TRANSACTION ID可將該多個(gè)并行發(fā)起的RRC過程區(qū)分開。該RRC TRANSACTION ID和消息類型一起，在某一個(gè)時(shí)間點(diǎn)上可唯一地標(biāo)識(shí)一個(gè)RNC和UE之間的下行RRC過程。
步驟3)中，UE可一次或多次向RNC重發(fā)CELL UPDATE消息，發(fā)送CELLUPDATE消息的次數(shù)滿足V302＜＝N302即可，其中V302表示發(fā)送CELLUPDATE消息的次數(shù)，N302表示CELL UPDATE消息重發(fā)的最大次數(shù)。
步驟5)中，該應(yīng)答消息可以為以下消息的一種①UTRAN移動(dòng)性信息確認(rèn)消息；②物理信道重配置完成消息；③傳輸信道重配置完成消息；
④無線承載釋放完成消息；⑤無線承載重配完成消息。
在步驟2)和步驟4)中RNC兩次發(fā)出RRC TRANSACTION ID均為1的CELL UPDATE CONFIRM消息，在之后的時(shí)間RNC等待接收并處理RRCTRANSACTION ID為1的UTRAN MOBILITY INFORMATION CONFIRM消息；當(dāng)在步驟5)中，UE發(fā)出UTRAN MOBILITY INFORMATION CONFIRM消息后，UE側(cè)完成小區(qū)更新過程；RNC收到RRC TRANSACTION ID為1的該消息后，接管UE，成功完成小區(qū)更新的過程。因此解決了現(xiàn)有技術(shù)中小區(qū)更新過程中UE掉話的問題。
圖6中，從UE側(cè)說明UE重發(fā)CELL UPDATE消息實(shí)現(xiàn)小區(qū)更新的具體流程包括以下步驟1)UE發(fā)起小區(qū)更新過程，通過無線資源控制(RRC)協(xié)議向RNC發(fā)送CELLUPDATE消息；2)UE向RNC重發(fā)CELL UPDATE消息；3)隨后RNC返回CELL UDPATE CONFIRM消息，該CELL UDPATECONFIRM消息攜帶的標(biāo)識(shí)為1；4)UE收到該CELL UPDATE CONFIRM消息，發(fā)送標(biāo)識(shí)為1的應(yīng)答消息，此時(shí)UE側(cè)小區(qū)更新流程結(jié)束；5)RNC返回標(biāo)識(shí)為1的CELL UPDATE CONFIRM消息給UE。
在步驟1)中，用戶終端發(fā)送第一個(gè)CELL UPDATE消息時(shí)設(shè)定時(shí)鐘周期，步驟2)中用戶終端在所述時(shí)鐘周期內(nèi)重發(fā)CELL UPDATE消息。
步驟2)、步驟4)及步驟5)中，CELL UDPATE CONFIRM消息和應(yīng)答消息中攜帶的標(biāo)識(shí)均為RRC TRANSACTION ID。該RRC TRANSACTION ID可將該多個(gè)并行發(fā)起的RRC過程區(qū)分開。該RRC TRANSACTION ID和消息類型一起，在某一個(gè)時(shí)間點(diǎn)上可唯一地標(biāo)識(shí)一個(gè)RNC和UE之間的下行RRC過程。
步驟2)中，UE可一次或多次向RNC重發(fā)CELL UPDATE消息，發(fā)送CELLUPDATE消息的次數(shù)滿足V302＜＝N302即可，其中V302表示發(fā)送CELLUPDATE消息的次數(shù)，N302表示CELL UPDATE消息重發(fā)的最大次數(shù)。
步驟4)中，該應(yīng)答消息可以為以下消息的一種①UTRAN移動(dòng)性信息確認(rèn)消息；②物理信道重配置完成消息；③傳輸信道重配置完成消息；④無線承載釋放完成消息；⑤無線承載重配完成消息。
在步驟3)中RNC發(fā)出RRC TRANSACTION ID均為1的CELL UPDATECONFIRM消息，在之后的時(shí)間RNC等待接收并處理RRC TRANSACTION ID為1的UTRAN MOBILITY INFORMATION CONFIRM消息；當(dāng)在步驟4)中，UE發(fā)出UTRAN MOBILITY INFORMATION CONFIRM消息后，UE側(cè)完成小區(qū)更新過程；RNC收到RRC TRANSACTION ID為1的該消息后，接管UE，成功完成小區(qū)更新的過程。因此解決了現(xiàn)有技術(shù)中小區(qū)更新過程中UE掉話的問題。
以上對(duì)本發(fā)明所提供的小區(qū)更新的實(shí)現(xiàn)方法。本文中應(yīng)用了特定個(gè)例對(duì)本發(fā)明的原理及實(shí)施方式進(jìn)行了闡述，以上實(shí)施例的說明只是用于幫助理解本發(fā)明的方法及其核心思想；同時(shí)，對(duì)于本領(lǐng)域的一般技術(shù)依據(jù)本發(fā)明的思想，在特定實(shí)施方式及應(yīng)用范圍上均會(huì)有改變之處，綜上所述，本說明書內(nèi)容不應(yīng)理解為對(duì)本發(fā)明的限制。
權(quán)利要求
1.一種小區(qū)更新的實(shí)現(xiàn)方法，其包括以下步驟A)用戶終端發(fā)送小區(qū)更新請(qǐng)求；B)無線網(wǎng)絡(luò)控制器接收到所述的小區(qū)更新請(qǐng)求后，向所述用戶終端返回小區(qū)更新確認(rèn)；C)用戶終端根據(jù)所述確認(rèn)向無線網(wǎng)絡(luò)控制器傳送應(yīng)答消息，無線網(wǎng)絡(luò)控制器接收該應(yīng)答消息，接管用戶終端，完成小區(qū)更新過程；其特征在于在一個(gè)小區(qū)更新流程中，無線網(wǎng)絡(luò)控制器返回的小區(qū)更新確認(rèn)攜帶的標(biāo)識(shí)相同。
2.如權(quán)利要求1所述的小區(qū)更新的實(shí)現(xiàn)方法，其特征在于所述步驟A)中，用戶終端發(fā)送第一個(gè)小區(qū)更新請(qǐng)求時(shí)設(shè)定時(shí)鐘周期，在所述時(shí)鐘周期內(nèi)用戶終端重發(fā)小區(qū)更新請(qǐng)求。
3.如權(quán)利要求2所述的小區(qū)更新的實(shí)現(xiàn)方法，其特征在于用戶終端可一次或多次重發(fā)小區(qū)更新請(qǐng)求。
4.如權(quán)利要求1至3任一項(xiàng)所述的小區(qū)更新的實(shí)現(xiàn)方法，其特征在于所述應(yīng)答消息是UTRAN移動(dòng)性信息確認(rèn)消息、物理信道重配置完成消息、傳輸信道重配置完成消息、無線承載釋放完成消息或者無線承載重配完成消息之中一種或任意組合。
5.如權(quán)利要求1所述的小區(qū)更新的實(shí)現(xiàn)方法，其特征在于所述步驟B)中，所述標(biāo)識(shí)為無線資源控制事務(wù)標(biāo)識(shí)，所述無線資源控制事務(wù)標(biāo)識(shí)可將多個(gè)并行發(fā)起的無線資源控制過程區(qū)分。
全文摘要
本發(fā)明公開一種小區(qū)更新的實(shí)現(xiàn)方法，其包括以下步驟A)用戶終端發(fā)送小區(qū)更新請(qǐng)求；B)無線網(wǎng)絡(luò)控制器接收到所述的小區(qū)更新請(qǐng)求后，向所述用戶終端返回小區(qū)更新確認(rèn)；C)用戶終端根據(jù)所述確認(rèn)向無線網(wǎng)絡(luò)控制器傳送應(yīng)答消息，無線網(wǎng)絡(luò)控制器接收該應(yīng)答消息，接管用戶終端，完成小區(qū)更新過程；其中在一個(gè)小區(qū)更新流程中，無線網(wǎng)絡(luò)控制器返回的小區(qū)更新確認(rèn)攜帶的標(biāo)識(shí)相同。
文檔編號(hào)H04W60/04GK1968518SQ20061008374
公開日2007年5月23日 申請(qǐng)日期2006年6月1日 優(yōu)先權(quán)日2006年6月1日
發(fā)明者徐宏偉, 徐曉琳, 段忠毅 申請(qǐng)人:華為技術(shù)有限公司