專利名稱：一種實(shí)現(xiàn)無(wú)線網(wǎng)絡(luò)控制器協(xié)作尋呼的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及無(wú)線尋呼，尤指一種實(shí)現(xiàn)無(wú)線網(wǎng)絡(luò)控制器(RNC)協(xié)作尋呼的方法。
背景技術(shù)：
在寬帶碼分多址(WCDMA)系統(tǒng)中，核心網(wǎng)(CN)從邏輯上分為電路交換(CS)域和分組交換(PS)域。移動(dòng)交換中心(MSC)/拜訪位置寄存器(VLR)是CS域的功能節(jié)點(diǎn)，GPRS服務(wù)支持節(jié)點(diǎn)(SGSN)是PS域的功能節(jié)點(diǎn)，MSC/VLR與SGSN之間可以通過Gs接口相連接，MSC/VLR與SGSN之間也可以不相連。MSC/VLR、SGSN分別通過Iu_CS接口、Iu_PS接口與RNC相連。
在CS域中，當(dāng)公共電話交換網(wǎng)(PSTN)呼叫用戶設(shè)備(UE)或UE呼叫UE時(shí)，網(wǎng)絡(luò)側(cè)需要對(duì)被叫UE發(fā)送尋呼(Paging)消息，被叫UE收到尋呼消息并接入網(wǎng)絡(luò)之后，才可以進(jìn)入呼叫狀態(tài)；在PS域中，如果被叫UE建立了PS域業(yè)務(wù)，呼叫來(lái)自CS域時(shí)，網(wǎng)絡(luò)側(cè)需要在給被叫UE發(fā)送數(shù)據(jù)前，向UE發(fā)送尋呼消息。
現(xiàn)有技術(shù)中，將MSC/VLR與SGSN之間相連，即存在Gs接口對(duì)應(yīng)的網(wǎng)絡(luò)運(yùn)營(yíng)模式稱為模式I；將MSC/VLR與SGSN之間不相連，即不存在Gs接口時(shí)對(duì)應(yīng)的網(wǎng)絡(luò)運(yùn)營(yíng)模式稱為模式II。
當(dāng)網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式I時(shí)，需要進(jìn)行CS域的尋呼時(shí)，如果Gs接口正常，MSC/VLR就將尋呼消息經(jīng)Gs接口先發(fā)送給SGSN，再由SGSN經(jīng)SGSN與RNC之間的Iu_PS接口轉(zhuǎn)發(fā)給RNC，而不是直接通過MSC/VLR與RNC之間的Iu_CS接口發(fā)送給RNC；需要進(jìn)行PS域的尋呼時(shí)，直接由SGSN經(jīng)Iu_PS接口向RNC轉(zhuǎn)發(fā)尋呼消息即可。
當(dāng)網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式II時(shí)，如果UE建立了PS域業(yè)務(wù)，呼叫來(lái)自CS域，MSC/VLR與SGSN相互不知道對(duì)方是否與UE建立了連接，所以在尋呼之前，需要經(jīng)過一個(gè)協(xié)作尋呼過程，以確定采取什么尋呼類型以便能成功完成尋呼。
在WCDMA系統(tǒng)中，有兩種尋呼類型尋呼類型1(Paging Type 1)當(dāng)UE沒有專用邏輯信道(DCCH)可用時(shí)，RNC通過尋呼信道(PCH)向UE發(fā)送尋呼類型1尋呼消息，尋呼類型1適用于處于閑置(IDLE)狀態(tài)、小區(qū)PCH(CELL_PCH)狀態(tài)和注冊(cè)區(qū)PCH(URA_PCH)狀態(tài)的UE。
尋呼類型2(Paging Type 2)當(dāng)UE有可用的DCCH信道時(shí)，RNC通過DCCH信道向UE發(fā)送尋呼類型2尋呼消息，尋呼類型2適用于處于小區(qū)FACH(CELL_FACH)狀態(tài)和小區(qū)DCH(CELL_DCH)狀態(tài)的UE。當(dāng)UE處于CELL_FACH或CELL_DCH狀態(tài)時(shí)，UE不會(huì)偵聽PCH信道，所以這兩種狀態(tài)的UE是收不到從PCH信道發(fā)送的尋呼類型1消息的。
為了保證尋呼的正確完成，RNC在接收到尋呼消息后，會(huì)根據(jù)尋呼消息中攜帶的協(xié)作尋呼指示(Non Searching Indication)信元的取值判定是否進(jìn)行協(xié)作尋呼。圖1是現(xiàn)有技術(shù)實(shí)現(xiàn)RNC協(xié)作尋呼的流程圖，具體實(shí)現(xiàn)包括以下步驟步驟100～步驟101判斷接收到的尋呼消息中是否包含Non SearchingIndication信元，若包含，則進(jìn)入步驟102；若不包含，則進(jìn)入步驟103。
在第三代合作伙伴技術(shù)規(guī)范25413(3GPP TS 25413)協(xié)議中指出，NonSearching Indication信元是用于指示RNC是否需要執(zhí)行協(xié)作尋呼的可選信元，該Non Searching Indication信元是一個(gè)枚舉類型的信元，可能的取值為non-searching和searching兩種。若尋呼消息中不包含該信元，則RNC需要執(zhí)行協(xié)作尋呼；若尋呼消息中包含該信元，協(xié)議中沒有具體說明NonSearching Indication信元取值為non-searching或searching時(shí)RNC是否應(yīng)該執(zhí)行協(xié)作尋呼，目前的處理是Non Searching Indication信元取值為non-searching時(shí)，不執(zhí)行協(xié)作尋呼；Non Searching Indication信元取值為searching時(shí)，執(zhí)行協(xié)作尋呼。
步驟102判斷Non Searching Indication信元的取值是否為執(zhí)行協(xié)作尋呼，若是，則進(jìn)入步驟103；否則進(jìn)入步驟105。
本步驟中，按照對(duì)3GPP TS 25413協(xié)議中Non Searching Indication信元描述的理解進(jìn)行判斷是否需要執(zhí)行尋呼，即若Non Searching Indication信元取值為searching，則執(zhí)行協(xié)作尋呼；若Non Searching Indication信元取值為non-searching，則不執(zhí)行協(xié)作尋呼。
步驟103以尋呼消息中的全球移動(dòng)用戶標(biāo)識(shí)(IMSI)為索引在RNC的IMSI標(biāo)識(shí)與通用陸地?zé)o線接入網(wǎng)臨時(shí)標(biāo)識(shí)(U-RNTI)映射關(guān)系數(shù)據(jù)庫(kù)中查找對(duì)應(yīng)的U-RNTI標(biāo)識(shí)，若查找到該U-RNTI標(biāo)識(shí)，則進(jìn)入步驟104；否則，進(jìn)入步驟105。
這里需要說明的是，當(dāng)某個(gè)UE在通用陸地?zé)o線接入網(wǎng)(UTRAN)中建立一個(gè)CS或者PS業(yè)務(wù)時(shí)，RNC會(huì)給該UE分配一個(gè)U-RNTI標(biāo)識(shí)，RNC使用U-RNTI標(biāo)識(shí)唯一地標(biāo)識(shí)一個(gè)UE。
每個(gè)接入RNC的UE都帶有IMSI標(biāo)識(shí)，IMSI標(biāo)識(shí)是CN用來(lái)標(biāo)識(shí)UE的一個(gè)號(hào)碼，當(dāng)UE接入RNC后，RNC需要建立一個(gè)IMSI標(biāo)識(shí)與U-RNTI標(biāo)識(shí)映射關(guān)系的全局?jǐn)?shù)據(jù)庫(kù)，該數(shù)據(jù)庫(kù)以IMSI為索引對(duì)應(yīng)該UE在RNC中U-RNTI標(biāo)識(shí)，而U-RNTI標(biāo)識(shí)在數(shù)據(jù)庫(kù)中對(duì)應(yīng)該UE在RNC中的上下文，該上下文是用于保存該UE相關(guān)信息的。每個(gè)UE的上下文中都會(huì)保存這個(gè)UE的IMSI標(biāo)識(shí)、U-RNTI標(biāo)識(shí)、UE當(dāng)前所處的位置信息、UE當(dāng)前使用的專用邏輯信道信息、UE當(dāng)前的無(wú)線資源控制層(RRC)連接狀態(tài)等信息。
RRC連接狀態(tài)中存儲(chǔ)了UE當(dāng)前的連接狀態(tài)，比如IDLE狀態(tài)、CELL PCH狀態(tài)、URA PCH狀態(tài)、CELL_FACH狀態(tài)或CELL_DCH狀態(tài)等。
步驟104根據(jù)U-RNTI標(biāo)識(shí)對(duì)應(yīng)的上下文，查找UE當(dāng)前的RRC連接狀態(tài)，若UE處于IDLE狀態(tài)，則進(jìn)入步驟105；若UE處于CELL_PCH狀態(tài)，則進(jìn)入步驟106；若UE處于URA_PCH狀態(tài)，則進(jìn)入步驟107；若UE處于CELL_FACH或CELL_DCH狀態(tài)，則進(jìn)入步驟108。
本步驟中，通過查找UE在RNC的上下文中的RRC連接關(guān)系，得到UE當(dāng)前所處的狀態(tài)后，對(duì)尋呼UE的尋呼類型做出選擇。
步驟105RNC在尋呼消息的尋呼區(qū)域中發(fā)送尋呼類型1消息尋呼UE。
本步驟中，尋呼區(qū)域是CN在尋呼消息中指定的區(qū)域。
步驟106RNC在UE當(dāng)前駐留的小區(qū)中發(fā)送尋呼類型1消息尋呼UE。
本步驟中，UE當(dāng)前駐留的小區(qū)信息存在于該UE在RNC的上下文中。
步驟107RNC在UE當(dāng)前駐留的注冊(cè)區(qū)所包含的小區(qū)中發(fā)送尋呼類型1消息尋呼UE。
本步驟中，UE當(dāng)前駐留的注冊(cè)區(qū)所包含的小區(qū)信息存在于該UE在RNC中的上下文中。
步驟108RNC在UE當(dāng)前使用的專用邏輯信道中發(fā)送尋呼類型2消息尋呼UE。
本步驟中，UE當(dāng)前使用的專用邏輯信道信息存在于該UE在RNC中的上下文中。
上述步驟100～步驟102是RNC判決是否執(zhí)行協(xié)作尋呼的過程，步驟103～步驟108是協(xié)作尋呼過程，以上是現(xiàn)有技術(shù)實(shí)現(xiàn)RNC協(xié)作尋呼的方法流程。
從總體來(lái)看，現(xiàn)有技術(shù)的處理沒有考慮當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式，而是單純地按照協(xié)議規(guī)定對(duì)尋呼消息中是否包含Non Searching Indication信元以及該信元的取值來(lái)判決是否執(zhí)行協(xié)作尋呼，而在3GPP TS 25413協(xié)議中對(duì)NonSearching Indication信元的描述比較模糊，可操作性較差。這樣，現(xiàn)有技術(shù)實(shí)現(xiàn)RNC協(xié)作尋呼的方法在實(shí)際應(yīng)用中會(huì)出現(xiàn)兩個(gè)問題(1)網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式II時(shí)，由于MSC/VLR與SGSN之間不存在Gs接口，在尋呼UE之前，需要經(jīng)過一個(gè)協(xié)作尋呼過程，以確定采取什么尋呼類型以便能成功完成尋呼。但應(yīng)用現(xiàn)有技術(shù)的處理方法，如果尋呼消息中包含Non Searching Indication信元，但該信元的取值是non-searching時(shí)，按照現(xiàn)有技術(shù)的處理方法，是不需要執(zhí)行協(xié)作尋呼的，而只是簡(jiǎn)單地在尋呼消息的尋呼區(qū)域中發(fā)送尋呼類型1消息來(lái)尋呼UE。如果此時(shí)UE處于CELL_FACH或CELL_DCH狀態(tài)，由于該UE是不偵聽PCH信道的，所以這樣的處理，會(huì)造成對(duì)UE的尋呼失敗。
(2)網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式I時(shí)，如果MSC/VLR與SGSN之間的Gs接口異常，即尋呼消息來(lái)自MSC/VLR的Iu_CS接口，而且此時(shí)尋呼消息中Non Searching Indication信元的取值為non-searching，應(yīng)用現(xiàn)有技術(shù)的處理方法，如步驟102所示，是不需要執(zhí)行協(xié)作尋呼的，而只是簡(jiǎn)單地在尋呼消息的尋呼區(qū)域中發(fā)送尋呼類型1消息來(lái)尋呼UE。同樣，這樣的處理很可能會(huì)造成尋呼失敗。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種實(shí)現(xiàn)RNC協(xié)作尋呼的方法，該方法可操作性強(qiáng)，能夠提高對(duì)UE尋呼的成功率。
為達(dá)到上述目的，本發(fā)明的技術(shù)方案具體是這樣實(shí)現(xiàn)的一種實(shí)現(xiàn)無(wú)線網(wǎng)絡(luò)控制器RNC協(xié)作尋呼的方法，核心網(wǎng)CN向RNC發(fā)起尋呼用戶終端UE的尋呼消息，該尋呼消息中包含指定的尋呼區(qū)域，該方法包括以下步驟A.判斷當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式，若當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式I，則進(jìn)入步驟B；若當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式II，則進(jìn)入步驟C；B.判斷接收到的尋呼消息是否來(lái)自移動(dòng)交換中心MSC/拜訪位置寄存器VLR，若是來(lái)自MSC/VLR，則進(jìn)入步驟C；否則，判斷所述尋呼消息中是否含有協(xié)作尋呼指示信元，若不包含，則進(jìn)入步驟C；若包含，則判斷該協(xié)作尋呼指示信元的取值是否為執(zhí)行協(xié)作尋呼，若是，則進(jìn)入步驟C；否則，在指定的尋呼區(qū)域中發(fā)送尋呼類型1消息后結(jié)束當(dāng)前處理流程；C.RNC執(zhí)行協(xié)作尋呼，確定UE所在位置及尋呼UE的尋呼類型。
步驟B中，所述判斷尋呼消息是否來(lái)自MSC/VLR的方法為判斷所述尋呼消息是否為通過MSC/VLR與RNC之間的接口發(fā)送給RNC的，若是，則該尋呼消息來(lái)自MSC/VLR；否則，該尋呼消息不是來(lái)自MSC/VLR的。
步驟A之前，該方法還包括當(dāng)UE在通用陸地?zé)o線接入網(wǎng)UTRAN中建立CS或PS業(yè)務(wù)時(shí)，RNC分配給所述UE一個(gè)用于唯一標(biāo)識(shí)UE的U-RNTI標(biāo)識(shí)；當(dāng)所述UE接入RNC時(shí)，RNC以CN用來(lái)標(biāo)識(shí)UE的全球移動(dòng)用戶標(biāo)識(shí)IMSI為索引，建立IMSI標(biāo)識(shí)與所述U-RNTI標(biāo)識(shí)映射關(guān)系的全局?jǐn)?shù)據(jù)庫(kù)。
所述IMSI標(biāo)識(shí)與U-RNTI標(biāo)識(shí)映射關(guān)系的全局?jǐn)?shù)據(jù)庫(kù)中，所述UE的U-RNTI標(biāo)識(shí)對(duì)應(yīng)UE在接入RNC時(shí)，在RNC中建立的用于保存所述UE相關(guān)信息的上下文。
所述保存在上下文中的所述UE相關(guān)信息包括所述UE的IMSI標(biāo)識(shí)、U-RNTI標(biāo)識(shí)、UE當(dāng)前所處位置信息、UE當(dāng)前使用的專用邏輯信道信息、UE當(dāng)前的無(wú)線資源控制層RRC連接狀態(tài)信息。
步驟C中，所述確定UE所在位置及尋呼UE的尋呼類型的方法為查找所述U-RNTI標(biāo)識(shí)對(duì)應(yīng)的所述上下文中RRC連接狀態(tài)信息，若UE處于閑置狀態(tài)，則在所述尋呼消息中指定的尋呼區(qū)域中發(fā)送所述尋呼類型1消息后結(jié)束當(dāng)前處理流程；若UE處于小區(qū)PCH狀態(tài)，則查找所述上下文中保存的UE當(dāng)前所處位置信息，確定UE當(dāng)前駐留的小區(qū)信息并在UE當(dāng)前駐留的小區(qū)中發(fā)送尋呼類型1消息后結(jié)束當(dāng)前處理流程；
若UE處于注冊(cè)區(qū)PCH狀態(tài)，則查找所述上下文中保存的UE當(dāng)前所處位置信息，確定UE當(dāng)前駐留的注冊(cè)區(qū)所包含的小區(qū)信息并在UE當(dāng)前駐留的注冊(cè)區(qū)所包含的小區(qū)中發(fā)送尋呼類型1消息后結(jié)束當(dāng)前處理流程；若UE處于小區(qū)FACH狀態(tài)或小區(qū)DCH狀態(tài)，則查找所述上下文中保存的UE當(dāng)前使用的專用邏輯信道信息，并在UE當(dāng)前使用的專用邏輯信道中發(fā)送尋呼類型2消息后結(jié)束當(dāng)前處理流程。
由上述技術(shù)方案可見，本發(fā)明根據(jù)網(wǎng)絡(luò)運(yùn)營(yíng)模式，將實(shí)現(xiàn)RNC協(xié)作尋呼的方法分為兩大部分如果當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式II，則RNC必須執(zhí)行協(xié)作尋呼過程。
如果當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式是模式I，則對(duì)尋呼消息的來(lái)源進(jìn)行判斷，若尋呼消息是經(jīng)Iu_CS接口發(fā)送到RNC的，說明此時(shí)Gs接口異常，則需要執(zhí)行協(xié)作尋呼；若尋呼消息是經(jīng)Gs接口發(fā)送到RNC的，則RNC判斷接收到的尋呼消息中是否包含Non Searching Indication信元，若不包含，則需要執(zhí)行協(xié)作尋呼；若包含，則按照現(xiàn)有技術(shù)對(duì)協(xié)議中Non Searching Indication信元描述的理解進(jìn)行判決是否需要執(zhí)行協(xié)作尋呼。
從本發(fā)明方案可以看出，在當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式II時(shí)，是必須執(zhí)行協(xié)作尋呼的，這樣避免了現(xiàn)有技術(shù)方法中的第一個(gè)問題，更大程度地保證了尋呼的成功率；在當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式I時(shí)，當(dāng)Gs接口出現(xiàn)異常時(shí)，無(wú)論尋呼消息中是否包含Non Searching Indication信元，必須執(zhí)行協(xié)作尋呼，這樣的處理避免了現(xiàn)有技術(shù)方法中的第二個(gè)問題，同樣最大程度地保證了尋呼的成功率。


圖1是現(xiàn)有技術(shù)實(shí)現(xiàn)RNC協(xié)作尋呼的流程圖；圖2是本發(fā)明實(shí)現(xiàn)RNC協(xié)作尋呼的流程圖。
具體實(shí)施例方式
本發(fā)明的核心思想是通過對(duì)當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式的判斷、對(duì)尋呼消息的來(lái)源，即尋呼消息是來(lái)自MSC還是SGSN的判斷、以及對(duì)尋呼消息中NonSearching Indication信元取值的判斷，綜合考慮是否需要執(zhí)行協(xié)作尋呼，避免了由于對(duì)協(xié)議中Non Searching Indication信元描述的簡(jiǎn)單理解而導(dǎo)致尋呼失敗的問題，提高了對(duì)UE尋呼的成功率。
為使本發(fā)明的目的、技術(shù)方案及優(yōu)點(diǎn)更加清楚明白，以下參照附圖并舉較佳實(shí)施例，對(duì)本發(fā)明進(jìn)一步詳細(xì)說明。
圖2是本發(fā)明實(shí)現(xiàn)RNC協(xié)作尋呼的流程圖，具體包括以下步驟步驟200～步驟201RNC接收到尋呼消息后，判斷當(dāng)前的網(wǎng)絡(luò)運(yùn)營(yíng)模式，若當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式II，則進(jìn)入步驟205；若當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式I，則進(jìn)入步驟202。
本步驟中，RNC根據(jù)本地?cái)?shù)據(jù)庫(kù)中預(yù)存的網(wǎng)絡(luò)運(yùn)營(yíng)模式數(shù)據(jù)確定當(dāng)前的網(wǎng)絡(luò)運(yùn)營(yíng)模式。其中，網(wǎng)絡(luò)運(yùn)營(yíng)模式數(shù)據(jù)如何存入RNC本地?cái)?shù)據(jù)庫(kù)，以及如何根據(jù)數(shù)據(jù)庫(kù)中的數(shù)據(jù)確定網(wǎng)絡(luò)運(yùn)營(yíng)模式的過程均屬于現(xiàn)有技術(shù)。
步驟202判斷當(dāng)前尋呼消息是否來(lái)自MSC/VLR，若是，則進(jìn)入步驟205；否則，進(jìn)入步驟203。
本步驟中，若尋呼消息是通過MSC/VLR與RNC之間的Iu_CS接口發(fā)送給RNC的，則該尋呼消息來(lái)自CN中CS域的MSC/VLR，而此時(shí)網(wǎng)絡(luò)運(yùn)營(yíng)模式處于模式I，說明Gs接口異常；若尋呼消息是通過SGSN與RNC之間的Iu_PS接口發(fā)送給RNC的，則該尋呼消息來(lái)自CN中PS域的SGSN或者該尋呼消息來(lái)自CS域，且是從CS域中的MSC/VLR經(jīng)Gs接口發(fā)送給PS域的SGSN后再經(jīng)Iu_PS接口發(fā)送給RNC的，此時(shí)說明Gs接口正常。
步驟203判斷接收到的尋呼消息中是否包含Non Searching Indication信元，若包含，則進(jìn)入步驟204；若不包含，則進(jìn)入步驟205。
步驟204判斷Non Searching Indication信元的取值是否為執(zhí)行協(xié)作尋呼，若是，則進(jìn)入步驟205；否則進(jìn)入步驟207。
步驟205以尋呼消息中的IMSI標(biāo)識(shí)為索引在RNC的IMSI U-RNTI映射關(guān)系數(shù)據(jù)庫(kù)中查找對(duì)應(yīng)的U-RNTI標(biāo)識(shí)，若查找到該U-RNTI標(biāo)識(shí)，則進(jìn)入步驟206；否則，進(jìn)入步驟207。
步驟206根據(jù)U-RNTI標(biāo)識(shí)對(duì)應(yīng)的上下文，查找UE當(dāng)前的RRC連接狀態(tài)，若UE處理IDLE狀態(tài)，則進(jìn)入步驟207；若UE處于CELL_PCH狀態(tài)，則進(jìn)入步驟208；若UE處于URA_PCH狀態(tài)，則進(jìn)入步驟209；若UE處于CELL_FACH或CELL_DCH狀態(tài)，則進(jìn)入步驟210。
本步驟中，通過對(duì)UE在RNC中的上下文中的RRC連接關(guān)系，得到UE當(dāng)前所處的狀態(tài)后，通過協(xié)作尋呼處理，對(duì)UE的尋呼類型做出選擇。
步驟207RNC在尋呼消息的尋呼區(qū)域中發(fā)送尋呼類型1消息尋呼UE后結(jié)束當(dāng)前處理流程。
本步驟中，尋呼區(qū)域是CN在尋呼消息中指定的區(qū)域。
步驟208RNC在UE當(dāng)前駐留的小區(qū)中發(fā)送尋呼類型1消息尋呼UE后結(jié)束當(dāng)前處理流程。
本步驟中，UE當(dāng)前駐留的小區(qū)信息存在于該UE在RNC中的上下文中。
步驟209RNC在UE當(dāng)前駐留的注冊(cè)區(qū)所包含的小區(qū)中發(fā)送尋呼類型1消息尋呼UE后結(jié)束當(dāng)前處理流程。
本步驟中，UE當(dāng)前駐留的注冊(cè)區(qū)所包含的小區(qū)信息存在于該UE在RNC中的上下文中。
步驟210RNC在UE當(dāng)前使用的專用邏輯信道中發(fā)送尋呼類型2消息尋呼UE。
本步驟中，UE當(dāng)前使用的專用邏輯信道信息存在于該UE在RNC中的上下文中。
上述本發(fā)明方法中，首先，步驟200～步驟204是RNC判決是否執(zhí)行協(xié)作尋呼的過程，該判決過程充分考慮了可能導(dǎo)致尋呼失敗的原因，并對(duì)這些原因進(jìn)行分析判斷從步驟200～步驟201可以看出，在當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式II時(shí)，是必須執(zhí)行協(xié)作尋呼的，這樣避免了現(xiàn)有技術(shù)方法中的第一個(gè)問題，更大程度地保證了尋呼的成功率；從步驟202～步驟204可以看出，在當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式I時(shí)，當(dāng)Gs接口異常時(shí)，無(wú)論尋呼消息中是否包含Non Searching Indication信元，必須執(zhí)行協(xié)作尋呼，這樣的處理避免了現(xiàn)有技術(shù)方法中的第二個(gè)問題，同樣最大程度地保證了尋呼的成功率。
之后，再執(zhí)行步驟205～步驟210的協(xié)作尋呼過程，該協(xié)作尋呼過程的處理方法與現(xiàn)有技術(shù)步驟103～步驟108的處理方法完全一致。
以上所述，僅為本發(fā)明的較佳實(shí)施例而已，并非用于限定本發(fā)明的保護(hù)范圍。
權(quán)利要求
1.一種實(shí)現(xiàn)無(wú)線網(wǎng)絡(luò)控制器RNC協(xié)作尋呼的方法，核心網(wǎng)CN向RNC發(fā)起尋呼用戶終端UE的尋呼消息，該尋呼消息中包含指定的尋呼區(qū)域，其特征在于，該方法包括以下步驟A.判斷當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式，若當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式I，則進(jìn)入步驟B；若當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式為模式II，則進(jìn)入步驟C；B.判斷接收到的尋呼消息是否來(lái)自移動(dòng)交換中心MSC/拜訪位置寄存器VLR，若是來(lái)自MSC/VLR，則進(jìn)入步驟C；否則，判斷所述尋呼消息中是否含有協(xié)作尋呼指示信元，若不包含，則進(jìn)入步驟C；若包含，則判斷該協(xié)作尋呼指示信元的取值是否為執(zhí)行協(xié)作尋呼，若是，則進(jìn)入步驟C；否則，在指定的尋呼區(qū)域中發(fā)送尋呼類型1消息后結(jié)束當(dāng)前處理流程；C.RNC執(zhí)行協(xié)作尋呼，確定UE所在位置及尋呼UE的尋呼類型。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟B中，所述判斷尋呼消息是否來(lái)自MSC/VLR的方法為判斷所述尋呼消息是否為通過MSC/VLR與RNC之間的接口發(fā)送給RNC的，若是，財(cái)該尋呼消息來(lái)自MSC/VLR；否則，該尋呼消息不是來(lái)自MSC/VLR的。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟A之前，該方法還包括當(dāng)UE在通用陸地?zé)o線接入網(wǎng)UTRAN中建立CS或PS業(yè)務(wù)時(shí)，RNC分配給所述UE一個(gè)用于唯一標(biāo)識(shí)UE的U-RNTI標(biāo)識(shí)；當(dāng)所述UE接入RNC時(shí)，RNC以CN用來(lái)標(biāo)識(shí)UE的全球移動(dòng)用戶標(biāo)識(shí)IMSI為索引，建立IMSI標(biāo)識(shí)與所述U-RNTI標(biāo)識(shí)映射關(guān)系的全局?jǐn)?shù)據(jù)庫(kù)。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述IMSI標(biāo)識(shí)與U-RNTI標(biāo)識(shí)映射關(guān)系的全局?jǐn)?shù)據(jù)庫(kù)中，所述UE的U-RNTI標(biāo)識(shí)對(duì)應(yīng)UE在接入RNC時(shí)，在RNC中建立的用于保存所述UE相關(guān)信息的上下文。
5.根據(jù)權(quán)利要求4所述的方法，其特征在于，所述保存在上下文中的所述UE相關(guān)信息包括所述UE的IMSI標(biāo)識(shí)、U-RNTI標(biāo)識(shí)、UE當(dāng)前所處位置信息、UE當(dāng)前使用的專用邏輯信道信息、UE當(dāng)前的無(wú)線資源控制層RRC連接狀態(tài)信息。
6.根據(jù)權(quán)利要求4所述的方法，其特征在于，步驟C中，所述確定UE所在位置及尋呼UE的尋呼類型的方法為查找所述U-RNTI標(biāo)識(shí)對(duì)應(yīng)的所述上下文中RRC連接狀態(tài)信息，若UE處于閑置狀態(tài)，則在所述尋呼消息中指定的尋呼區(qū)域中發(fā)送所述尋呼類型1消息后結(jié)束當(dāng)前處理流程；若UE處于小區(qū)PCH狀態(tài)，則查找所述上下文中保存的UE當(dāng)前所處位置信息，確定UE當(dāng)前駐留的小區(qū)信息并在UE當(dāng)前駐留的小區(qū)中發(fā)送尋呼類型1消息后結(jié)束當(dāng)前處理流程；若UE處于注冊(cè)區(qū)PCH狀態(tài)，則查找所述上下文中保存的UE當(dāng)前所處位置信息，確定UE當(dāng)前駐留的注冊(cè)區(qū)所包含的小區(qū)信息并在UE當(dāng)前駐留的注冊(cè)區(qū)所包含的小區(qū)中發(fā)送尋呼類型1消息后結(jié)束當(dāng)前處理流程；若UE處于小區(qū)FACH狀態(tài)或小區(qū)DCH狀態(tài)，則查找所述上下文中保存的UE當(dāng)前使用的專用邏輯信道信息，并在UE當(dāng)前使用的專用邏輯信道中發(fā)送尋呼類型2消息后結(jié)束當(dāng)前處理流程。
全文摘要
本發(fā)明公開了一種實(shí)現(xiàn)無(wú)線網(wǎng)絡(luò)控制器(RNC)協(xié)作尋呼的方法，該方法通過對(duì)當(dāng)前網(wǎng)絡(luò)運(yùn)營(yíng)模式的判斷、對(duì)尋呼消息的來(lái)源的判斷、以及尋呼消息中的協(xié)作尋呼指示信元取值的判斷，綜合考慮是否需要執(zhí)行協(xié)作尋呼，可操作性強(qiáng)，避免了由于對(duì)協(xié)議中協(xié)作尋呼指示信元描述的簡(jiǎn)單理解而導(dǎo)致尋呼失敗的問題，提高了對(duì)UE尋呼的成功率。
文檔編號(hào)H04W68/00GK1838823SQ200510058909
公開日2006年9月27日 申請(qǐng)日期2005年3月24日 優(yōu)先權(quán)日2005年3月24日
發(fā)明者劉霞玲, 段忠毅 申請(qǐng)人:華為技術(shù)有限公司