專(zhuān)利名稱(chēng)：：由家用基站網(wǎng)關(guān)觸發(fā)的用戶(hù)遷移方法
技術(shù)領(lǐng)域：
：本發(fā)明涉及移動(dòng)通信，特別涉及家用基站(HomeNodeB)通信系統(tǒng)中用戶(hù)設(shè)備(UserEquipment)的遷移(Relocation)過(guò)程。
背景技術(shù)：
：傳統(tǒng)的遷移過(guò)程由UE的測(cè)量報(bào)告觸發(fā)，無(wú)線(xiàn)網(wǎng)絡(luò)控制器(RNC)通過(guò)對(duì)UE測(cè)量報(bào)告的分析決定是否進(jìn)行切換或者遷移。在HNB系統(tǒng)中，UE的測(cè)量報(bào)告由HNB進(jìn)行分析處理。一種典型的遷移流程為UE從HNB遷移到宏基站，這種遷移叫做OutbandHandover。目前的HNB系統(tǒng)中，由于HGW以及Iu-h接口的增加，用戶(hù)發(fā)生遷移的應(yīng)用場(chǎng)景也相應(yīng)增加了。不但需要傳統(tǒng)的UE測(cè)量上報(bào)觸發(fā)的遷移流程，而且還需要HGW觸發(fā)，由HNB配合完成的遷移流程。例如1)當(dāng)HGW復(fù)位時(shí)，需要通知HNB重新選擇其它HGW，并將現(xiàn)有用戶(hù)遷移到宏基站或其他能夠接受該用戶(hù)的HNB中。2)當(dāng)HGW檢測(cè)到Iu-h接口上行鏈路通信質(zhì)量嚴(yán)重下降時(shí)，需要改進(jìn)現(xiàn)有過(guò)程，觸發(fā)HNB發(fā)起用戶(hù)呼叫的遷徙過(guò)程。3)當(dāng)正在進(jìn)行業(yè)務(wù)的用戶(hù)被管理員從接入控制列表(AccessControlList)中刪除時(shí)，可以將其遷移到宏基站中。在現(xiàn)有的Iu-h或Iu接口中并不存在一種由上一級(jí)節(jié)點(diǎn)發(fā)起的用戶(hù)遷移的流程。
發(fā)明內(nèi)容本發(fā)明的目的是提供一種在HNB系統(tǒng)中由HGW觸發(fā)的用戶(hù)遷移流程，用來(lái)完成HNB新增場(chǎng)景的新需求。為實(shí)現(xiàn)上述目的，一種由家用基站網(wǎng)關(guān)觸發(fā)的用戶(hù)遷移方法，包括步驟家用基站網(wǎng)關(guān)HGW向用戶(hù)設(shè)備所在的家用基站HNB發(fā)送遷移請(qǐng)求消息；HNB觸發(fā)遷移流程，將所述用戶(hù)設(shè)備遷移到其它基站；HNB向HGW發(fā)送所述遷移請(qǐng)求的響應(yīng)消息。本發(fā)明解決了在新增的場(chǎng)景下，麗B系統(tǒng)中由HGW發(fā)起UE遷移的實(shí)現(xiàn)問(wèn)題。這一方案豐富了Iu-h接口，并且有利于提高用戶(hù)通信質(zhì)量，能夠在不同的場(chǎng)景下為用戶(hù)提供連續(xù)的服務(wù)。本發(fā)明實(shí)施方法簡(jiǎn)單有效，對(duì)于增強(qiáng)HNB系統(tǒng)的穩(wěn)定性，提升系統(tǒng)性能有很大促進(jìn)作用。圖l是家用基站系統(tǒng)結(jié)構(gòu)；圖2是HGW復(fù)位引發(fā)的用戶(hù)遷移；圖3是Iu-h接口通信質(zhì)量下降引發(fā)的用戶(hù)遷移；圖4是ACL更新引發(fā)的用戶(hù)遷移；圖5是典型的遷移流程。具體實(shí)施例方式如圖1所示，本發(fā)明設(shè)計(jì)出了一種由家用基站網(wǎng)關(guān)(HomeNodeBGateway)發(fā)起的用戶(hù)由HomeNodeB(以下簡(jiǎn)稱(chēng)麗B)遷移到宏基站的詳細(xì)流程。UserEquipment(以下簡(jiǎn)稱(chēng)UE)通過(guò)位于家庭中的HNB，接入到7號(hào)信令網(wǎng)絡(luò)中，基于HNB和HomeNodeBGateway(以下簡(jiǎn)稱(chēng)HGW)提供的信令承載功能，與核心網(wǎng)(CoreNetwork)節(jié)點(diǎn)SGSN(ServingGPRSSu卯ortingNode)/MSC(MobileSwitchingCenter)發(fā)生信令交互，從而控制和外界的通信。UE和HNB間基于TS25.331協(xié)議，采用傳統(tǒng)的空中接口(UUInterface);HNB和HGW之間采用Iu-home接口，目前Iu-home(以下簡(jiǎn)稱(chēng)Iu-h)接口的控制協(xié)議正在制定中；而HGW和MSC以及SGSN之間，采用基于TS25.413協(xié)議的傳統(tǒng)Iu接口進(jìn)行UE與CoreNetwork之間的信令交互和傳遞。本發(fā)明提出了一種根據(jù)HGW的需求來(lái)觸發(fā)UE進(jìn)行遷移的方法。這種方法能滿(mǎn)足HGW復(fù)位，Iu-h接口通信質(zhì)量下降，以及用戶(hù)被管理員從接入控制列表(以下簡(jiǎn)稱(chēng)ACU中刪除時(shí)的移動(dòng)性需求。從而保證用戶(hù)這些情況下用戶(hù)能夠繼續(xù)使用運(yùn)營(yíng)商提供的服務(wù)，不掉話(huà)。本發(fā)明在Iu-h接口中增加用戶(hù)遷移請(qǐng)求/響應(yīng)消息，由HGW發(fā)送請(qǐng)求消息到各個(gè)HNB中，HNB根據(jù)請(qǐng)求消息內(nèi)容發(fā)起典型的Relocation過(guò)程，完成后向HGW發(fā)送響應(yīng)消息。請(qǐng)求消息的內(nèi)容組成如表l所示。表l用戶(hù)遷移請(qǐng)求消息組成<table>tableseeoriginaldocumentpage5</column></row><table>其中，TransactionID為記錄每一次交互的ID，用于防止發(fā)生重復(fù)處理同一遷移請(qǐng)求；NumberofRelocationUser為本消息指示的需要執(zhí)行遷移的用戶(hù)數(shù)；RelocationUserInformationList為各個(gè)需要進(jìn)行遷移的用戶(hù)信息；UserCallID用于在HNB中唯一標(biāo)識(shí)該用戶(hù)；IMSI是用戶(hù)的國(guó)際移動(dòng)用戶(hù)識(shí)別碼(InternationalMobileSubscriberIdentity);RelocationCause指示遷移原因，目前包括三種可能，如表2所示。表2用戶(hù)遷移原因<table>tableseeoriginaldocumentpage5</column></row><table>用戶(hù)遷移響應(yīng)消息如表3所示。表3用戶(hù)遷移響應(yīng)消息組成<table>tableseeoriginaldocumentpage6</column></row><table>TransactionID與請(qǐng)求消息相對(duì)應(yīng)，NumberofRelocationUser為本消息指示的需要執(zhí)行遷移的用戶(hù)數(shù)；RelocationResultList為各個(gè)需要進(jìn)行遷移的用戶(hù)遷移結(jié)果信息；UserCallID用于在HNB中唯一標(biāo)識(shí)該用戶(hù)；RelocationResult指示遷移結(jié)果，0代表成功，l代表失敗。如果失敗，F(xiàn)ailCause將指示失敗原因。表4用戶(hù)遷移失敗原因<table>tableseeoriginaldocumentpage6</column></row><table>實(shí)施例1)由HGW復(fù)位觸發(fā)的用戶(hù)遷移流程如圖2所示，由于HGW內(nèi)部的軟、硬件異常觸發(fā)或者是來(lái)自外界的需要，例如管理員升級(jí)路由軟件等，可能觸發(fā)HGW的復(fù)位。HGW通過(guò)內(nèi)部軟件的檢測(cè)機(jī)制，前是否有正在進(jìn)行業(yè)務(wù)的用戶(hù)，如果有則構(gòu)造遷移請(qǐng)求消息，填寫(xiě)對(duì)應(yīng)的遷移原因?yàn)镠GW復(fù)位，并記錄下該消息對(duì)應(yīng)的TransactionID，再向該用戶(hù)所在的HNB發(fā)送遷移請(qǐng)求消息，發(fā)送完成后等待該HNB的響應(yīng)消息。HNB在收至ljHGW的遷移請(qǐng)求消息后，首先記錄下該消息的TransactionID，之后判斷某個(gè)用戶(hù)的Relocation的原因是否為HGW復(fù)位，如果是，再通過(guò)用戶(hù)的IMSI，檢查該用戶(hù)是否在本HNB上存在業(yè)務(wù)服務(wù)。如果不存在，則HNB將拒絕這次遷移請(qǐng)求，向HGW發(fā)送響應(yīng)消息指示遷移失敗，在響應(yīng)消息的FailCause中指示失敗原因?yàn)橛脩?hù)不存在業(yè)務(wù)；如果該用戶(hù)在本HNB存在業(yè)務(wù)，則再檢查是否存在可以讓該用戶(hù)進(jìn)行遷移的宏基站。如果有，則發(fā)起典型的Relocation過(guò)程，將用戶(hù)從麗B遷移到宏基站。這可以通過(guò)在家用基站開(kāi)機(jī)注冊(cè)的時(shí)候，網(wǎng)絡(luò)的運(yùn)營(yíng)維護(hù)管理實(shí)體告知家用基站與其處于同覆蓋的宏基站的小區(qū)信息。如果沒(méi)有能夠進(jìn)行遷移的宏基站，則HNB將拒絕這次遷移請(qǐng)求，在響應(yīng)消息的FailCause中指示失敗原因?yàn)闆](méi)有適合遷移的宏基站。對(duì)于其它原因?qū)е碌倪w移請(qǐng)求失敗，在響應(yīng)消息中的FailCause可以指示為HNB內(nèi)部錯(cuò)誤。典型的Relocation過(guò)程可以參考圖5，具體流程描述如下。1〉HNB向SGSN/MSC發(fā)送需求遷移消息。2〉SGSN/MSC向宏無(wú)線(xiàn)網(wǎng)絡(luò)控制器發(fā)送遷移請(qǐng)求消息，要求宏無(wú)線(xiàn)網(wǎng)絡(luò)控制器做好遷移準(zhǔn)備。3>宏無(wú)線(xiàn)網(wǎng)絡(luò)控制器發(fā)起Iu接口用戶(hù)面承載的建立。4〉宏無(wú)線(xiàn)網(wǎng)絡(luò)控制器向SGSN/MSC發(fā)送遷移請(qǐng)求應(yīng)答消息，通知SGSN遷移所需的資源己經(jīng)準(zhǔn)備好，消息中帶有重配置信息，告知麗B具體用無(wú)線(xiàn)承載建立、無(wú)線(xiàn)承載釋放、無(wú)線(xiàn)承載重配置、傳輸信道重配置、物理信道重配置過(guò)程中的哪一個(gè)過(guò)程來(lái)完成伴隨遷移。5>SGSN/MSC向HNB發(fā)送命令遷移消息，通知麗B可以進(jìn)行遷移了。6〉HNB向UE發(fā)送物理信道重配置消息，通知UE新的物理信道參數(shù)(也可能是無(wú)線(xiàn)承載建立、無(wú)線(xiàn)承載釋放、無(wú)線(xiàn)承載重配置、傳輸信道重配置等消息，具體由宏無(wú)線(xiàn)網(wǎng)絡(luò)控制器在之前的應(yīng)答消息中指定)。7〉UE成功地接入到目標(biāo)宏無(wú)線(xiàn)網(wǎng)絡(luò)控制器后，向目標(biāo)宏無(wú)線(xiàn)網(wǎng)絡(luò)控制器發(fā)送物理信道重配置完成消息。此時(shí)切換成功。8>目標(biāo)宏無(wú)線(xiàn)網(wǎng)絡(luò)控制器向SGSN/MSC發(fā)送遷移完成消息，通知SGSN/MSC遷移已成功結(jié)束。9〉SGSN/MSC向原HNB發(fā)送Iu連接釋放命令消息，通知其釋放Iu連接。10〉HNB采用發(fā)起Iu接口用戶(hù)面承載的釋放。11〉HNB向SGSN/MSC發(fā)送Iu釋放完成消息，指示Iu釋放完成。2)Iu-h接口上行鏈路通信質(zhì)量下降引起的用戶(hù)遷移流程在HNB系統(tǒng)中，HNB和核心網(wǎng)之間，電路域用戶(hù)平面承載使用RTP協(xié)議，分組域用戶(hù)平面承載使用GTP協(xié)議。在HNB系統(tǒng)中，RTP和GTP協(xié)議使用IP協(xié)議作為底層傳輸協(xié)議。3GPP規(guī)范要求RTP、GTP報(bào)文的發(fā)送端，發(fā)送報(bào)文時(shí)順序遞增報(bào)文頭序列號(hào)字段。RTP、GTP報(bào)文的接收端可以通過(guò)監(jiān)控RTP、GTP報(bào)文頭中的序列號(hào)域，檢測(cè)鏈路質(zhì)量，丟棄亂序報(bào)文；然而，在HNB系統(tǒng)中，存在的問(wèn)題是下行鏈路，HNB可以通過(guò)監(jiān)控RTP、G丁P報(bào)文頭中的序列號(hào)域，檢測(cè)鏈路通信質(zhì)量，并在鏈路通信質(zhì)量嚴(yán)重下降時(shí)，構(gòu)造RelocationRequired消息，請(qǐng)求核心網(wǎng)發(fā)起遷徙過(guò)程。上行鏈路，核心網(wǎng)卻存在即使監(jiān)測(cè)到鏈路通信質(zhì)量嚴(yán)重下降，也無(wú)法主動(dòng)發(fā)起遷徙過(guò)程的問(wèn)題。因?yàn)檫w徙過(guò)程，必須由源RNC主動(dòng)發(fā)起，而在HNB系統(tǒng)中，源RNC即為HNB，HNB無(wú)法得知上行鏈路通信質(zhì)量嚴(yán)重下降的事實(shí)。參考圖3，HGW在檢測(cè)到Iu-h接口的某個(gè)或某幾個(gè)UE上行鏈路通信質(zhì)量下降時(shí)，構(gòu)造遷移請(qǐng)求消息，填寫(xiě)對(duì)應(yīng)的遷移原因，并記錄下該消息對(duì)應(yīng)的TransactionID，再向該用戶(hù)所在的HNB發(fā)送遷移請(qǐng)求消息，發(fā)送完成后等待該麗B的響應(yīng)消息。HNB在收到HGW的遷移請(qǐng)求消息后，首先記錄下該消息的TransactionID，之后判斷某個(gè)用戶(hù)的Reloation的原因是否為Iu-h接口上行鏈路通信質(zhì)量下降，如果是，再通過(guò)用戶(hù)的IMSI，檢査該用戶(hù)是否在本HNB上存在業(yè)務(wù)服務(wù)。如果不存在，則HNB將拒絕這次遷移請(qǐng)求，向HGW發(fā)送響應(yīng)消息指示遷移失敗，在響應(yīng)消息的FailCause中指示失敗原因?yàn)橛脩?hù)不存在業(yè)務(wù)；如果該用戶(hù)在本麗B存在業(yè)務(wù)，則再檢查是否存在可以讓該用戶(hù)進(jìn)行遷移的宏基站。如果有，則發(fā)起傳統(tǒng)的Relocation過(guò)程，將用戶(hù)從HNB遷移到宏基站。這可以通過(guò)在家用基站開(kāi)機(jī)注冊(cè)的時(shí)候，網(wǎng)絡(luò)的運(yùn)營(yíng)維護(hù)管理實(shí)體告知家用基站與其處于同覆蓋的宏基站的小區(qū)信息。如果沒(méi)有能夠進(jìn)行遷移的宏基站，則麗B將拒絕這次遷移請(qǐng)求，在響應(yīng)消息的FailCause中指示失敗原因?yàn)闆](méi)有適合遷移的宏基站。對(duì)于其它原因?qū)е碌倪w移請(qǐng)求失敗，在響應(yīng)消息中的FailCause可以指示為HNB內(nèi)部錯(cuò)誤。3)ACL更新觸發(fā)的用戶(hù)遷移流程管理員或者授權(quán)用戶(hù)可以發(fā)起對(duì)ACL的維護(hù)，增加或者刪除ACL上的用戶(hù)。在一些時(shí)候，例如朋友來(lái)訪(fǎng)，主人作為授權(quán)用戶(hù)，可能會(huì)將朋友臨時(shí)加入到ACL中，而朋友走后主人又會(huì)將其從ACL中刪除。而刪除此用戶(hù)時(shí)，如果用戶(hù)正在利用主人家的HNB進(jìn)行業(yè)務(wù)，此時(shí)如果管理員或者超級(jí)用戶(hù)將這個(gè)用戶(hù)從ACL中刪除，那么從用戶(hù)的角度出發(fā)，如果周?chē)嬖谀軌蛱峁┓?wù)的宏基站，用戶(hù)的業(yè)務(wù)是不應(yīng)被終止的。此時(shí)合理的處理方法就是將這個(gè)用戶(hù)遷移到宏基站上。參考圖4，管理員或者超級(jí)用戶(hù)，通過(guò)web或者其他方式登錄到HNBConfigurationServer(HCS)，并發(fā)出刪除ACL中用戶(hù)的命令。此時(shí)HCS向HGW發(fā)送ACL更新請(qǐng)求，消息中指示HGW刪除ACL中的用戶(hù)，此時(shí)HGW根據(jù)消息中用戶(hù)的ID(可以是IMSI)先檢查該用戶(hù)是否正在進(jìn)行著業(yè)務(wù)，如果沒(méi)有，則直接更新ACL即可；如果存在業(yè)務(wù)，則此時(shí)HGW會(huì)發(fā)起對(duì)該用戶(hù)的遷移流程。構(gòu)造遷移請(qǐng)求消息，填寫(xiě)對(duì)應(yīng)的遷移原因?yàn)锳CL中用戶(hù)刪除，并記錄下該消息對(duì)應(yīng)的TransactionID，再向該用戶(hù)所在的HNB發(fā)送遷移請(qǐng)求消息，發(fā)送完成后等待該HNB的響應(yīng)消息。HNB在收至UHGW的遷移請(qǐng)求消息后，首先記錄下該消息的TransactionID，之后判斷某個(gè)用戶(hù)的Reloation的原因是否為ACL中用戶(hù)刪除，如果是，再通過(guò)用戶(hù)的IMSI，檢査該用戶(hù)是否在本HNB上存在業(yè)務(wù)服務(wù)。如果不存在，則HNB將拒絕這次遷移請(qǐng)求，向HGW發(fā)送響應(yīng)消息指示遷移失敗，在響應(yīng)消息的FailCause中指示失敗原因?yàn)橛脩?hù)不存在業(yè)務(wù)；如果該用戶(hù)在本HNB存在業(yè)務(wù)，則再檢查是否存在可以讓該用戶(hù)進(jìn)行遷移的宏基站。如果有，則發(fā)起典型的Relocation過(guò)程，將用戶(hù)從HNB遷移到宏基站。這可以通過(guò)在家用基站開(kāi)機(jī)注冊(cè)的時(shí)候，網(wǎng)絡(luò)的運(yùn)營(yíng)維護(hù)管理實(shí)體告知家用基站與其處于同覆蓋的宏基站的小區(qū)信息。如果沒(méi)有能夠進(jìn)行遷移的宏基站，則HNB將拒絕這次遷移請(qǐng)求，在響應(yīng)消息的FailCause中指示失敗原因?yàn)闆](méi)有適合遷移的宏基站。對(duì)于其它原因?qū)е碌倪w移請(qǐng)求失敗，在響應(yīng)消息中的FailCause可以指示為HNB內(nèi)部錯(cuò)誤。權(quán)利要求1.一種由家用基站網(wǎng)關(guān)觸發(fā)的用戶(hù)遷移方法，包括步驟家用基站網(wǎng)關(guān)HGW向用戶(hù)設(shè)備所在的家用基站HNB發(fā)送遷移請(qǐng)求消息；HNB觸發(fā)遷移流程，將所述用戶(hù)設(shè)備遷移到其它基站；HNB向HGW發(fā)送所述遷移請(qǐng)求的響應(yīng)消息。2.根據(jù)權(quán)利要求l所述的方法，其特征在于還包括HGW獲得HGW復(fù)位信息。3.根據(jù)權(quán)利要求l所述的方法，其特征在于還包括步驟HGW獲得Iu-h接口的通信質(zhì)量信息。4.根據(jù)權(quán)利要求l所述的方法，其特征在于還包括步驟HGW獲得接入控制列表更新消息。5.根據(jù)權(quán)利要求l所述的方法，其特征在于所述遷移請(qǐng)求消息中，包含遷移原因。6.根據(jù)權(quán)利要求5所述的方法，其特征在于所述遷移原因包括HGW復(fù)位、Iuh接口通信質(zhì)量下降或接入控制列表更新。7.根據(jù)權(quán)利要求l所述的方法，其特征在于家用基站從網(wǎng)絡(luò)獲得宏基站的信息。8.根據(jù)權(quán)利要求l所述的方法，其特征在于遷移請(qǐng)求消息中包含用戶(hù)設(shè)備標(biāo)識(shí)。全文摘要一種由家用基站網(wǎng)關(guān)觸發(fā)的用戶(hù)遷移方法，包括步驟家用基站網(wǎng)關(guān)HGW向用戶(hù)設(shè)備所在的家用基站HNB發(fā)送遷移請(qǐng)求消息；HNB觸發(fā)遷移流程，將所述用戶(hù)設(shè)備遷移到其它基站；HNB向HGW發(fā)送所述遷移請(qǐng)求的響應(yīng)消息。本發(fā)明解決了在新增的場(chǎng)景下，HNB系統(tǒng)中由HGW發(fā)起UE遷移的實(shí)現(xiàn)問(wèn)題。這一方案豐富了Iu-h接口，并且有利于提高用戶(hù)通信質(zhì)量，能夠在不同的場(chǎng)景下為用戶(hù)提供連續(xù)的服務(wù)。本發(fā)明實(shí)施方法簡(jiǎn)單有效，對(duì)于增強(qiáng)HNB系統(tǒng)的穩(wěn)定性，提升系統(tǒng)性能有很大促進(jìn)作用。文檔編號(hào)H04W36/24GK101674622SQ20081021190公開(kāi)日2010年3月17日申請(qǐng)日期2008年9月9日優(yōu)先權(quán)日2008年9月9日發(fā)明者王伯嶺,賈紅升申請(qǐng)人:三星電子株式會(huì)社;北京三星通信技術(shù)研究有限公司