決了 UTRAN(通用移動通信系統(tǒng)陸地?zé)o線接入網(wǎng))側(cè)掉話后再次起呼失敗的問題。
[0055]本發(fā)明實施例針對實際應(yīng)用情況提供了兩種應(yīng)對措施，第一種:接收核心網(wǎng)下發(fā)的攜帶原因值為一自定義值的Iu連接釋放指令的步驟包括:接收節(jié)點B上報的無線鏈路失敗的報告；根據(jù)所述無線鏈路失敗的報告確定與節(jié)點B連接的終端進行語音業(yè)務(wù)時，向核心網(wǎng)上報原因值為所述自定義值的Iu連接釋放請求；接收核心網(wǎng)根據(jù)所述Iu連接釋放請求下發(fā)的攜帶原因值為所述自定義值的Iu連接釋放指令。
[0056]進一步的，所述方法還包括:根據(jù)所述無線鏈路失敗的報告確定與節(jié)點B連接的終端沒有進行語音業(yè)務(wù)時，向所述節(jié)點B下發(fā)無線鏈路激活指令，以使所述節(jié)點B去激活無線鏈路，進而觸發(fā)所述終端發(fā)起小區(qū)更新或者掉線定時器能夠超時觸發(fā)掉線。
[0057]第二種:接收核心網(wǎng)下發(fā)的攜帶原因值為一自定義值的Iu連接釋放指令的步驟包括:接收核心網(wǎng)根據(jù)終端上報的呼叫管理服務(wù)請求，確定該請求中移動標(biāo)志的Iu連接已經(jīng)存在且建立原因為所述終端進行語音業(yè)務(wù)時，下發(fā)的攜帶原因值為所述自定義值的Iu連接釋放指令。
[0058]進一步的，所述方法還包括:接收核心網(wǎng)根據(jù)所述終端上報的呼叫管理服務(wù)請求，確定該請求中移動標(biāo)志的Iu連接不存在時，下發(fā)的建立呼叫管理服務(wù)的第一指令；接收核心網(wǎng)根據(jù)所述終端上報的呼叫管理服務(wù)請求，確定該請求中建立原因不是所述終端進行語音業(yè)務(wù)時，下發(fā)的建立呼叫管理服務(wù)的第二指令。其中，第一指令和第二指令相同，可以是進入呼叫管理服務(wù)建立過程中的鑒權(quán)、安全模式命令、身份認證等指令。
[0059]下面對本發(fā)明實施例提供的所述無線網(wǎng)絡(luò)控制器與核心網(wǎng)間拆除鏈路的方法進行舉例說明。
[0060]如圖2所示的典型故障信令,序號9-10:Paging Response (尋呼響應(yīng))可以看出這是一個被叫通話。解析該信令，可以看到攜帶的Mobile ID如圖3所示。
[0061]在圖4中，序號43-46:語音電話接通。序號47 =Node B(節(jié)點B)檢測到連續(xù)上行失步的時間超過某個閥值后，就會觸發(fā)上報Rad1 Link Failure Indicat1n (無線鏈路失敗指示)給RNC。每個廠家對于觸發(fā)Rad1 Link Failure Indicat1n定時器定義不一樣。序號 48:Node B 上報 Rad1 Link Failure Indicat1n 觸發(fā) RNC 下發(fā) Rad1 LinkActivat1n Command(無線鏈路激活指令)給Node B,指示Node B關(guān)閉下行發(fā)射。
[0062]由于網(wǎng)絡(luò)側(cè)的下行發(fā)射被關(guān)掉，引起終端探測不到下行鏈路，從而引起終端判斷下行失敗，停止在老的鏈路上的發(fā)送，使得UE通過小區(qū)更新(Cell Update)，重新選擇無線質(zhì)量更佳的小區(qū)，該小區(qū)有可能是源小區(qū)，也有可能是其它小區(qū)。在本案例中，UE選擇的就是另外的小區(qū)(Cell ID = 29223)，如圖5所示，其中，序號97-98:UE在新的小區(qū)(Cell ID = 29223)發(fā)起語音呼叫業(yè)務(wù)，發(fā)送CM Service Request,原因值是OriginalConversat1nal Call (原始通話呼叫)，攜帶的 Mobile ID(92232494)與上面 PagingResponse 中的一樣。序號 101-102:核心網(wǎng)拒絕該CM Service Request0CM Service Reject的原因是:Message not compatible with the protocol state,如圖 6 所不。
[0063]具體原因分析:上行失步后，RNC釋放通話的定時器(實際上就是掉話定時器)在現(xiàn)網(wǎng)配置下，為15.25秒鐘。對于不同的廠家該掉話定時器的計算方式不一樣。但無論如何，都是設(shè)置得大于O的，從7、8秒鐘到十幾秒鐘的都有。
[0064]RNC 指不 Node B 停止下行發(fā)射后(Rad1 Link Activat1n Command), UE 的通話實際已經(jīng)中止，時間點10:00:12:821(序號:48)。
[0065]UE小區(qū)更新到其它小區(qū)再次發(fā)起CM Service Request (CS語音呼叫)，時間點10:00:19:371(序號:97)。
[0066]兩個時間點之間(掉話與再次發(fā)起CS語音呼叫之間)相隔約7秒鐘，遠遠小于RNC釋放通話定時器15.25秒鐘。在定時器超時前，RNC是不會發(fā)起Iu Release Request(Iu釋放請求)，因此RNC與CN之間的Iu連接仍然保持。當(dāng)核心網(wǎng)收到CM Service Request后，核心網(wǎng)發(fā)現(xiàn)其攜帶的Mobile ID早已存在Iu連接,就會拒絕該次CM Service Request,拒絕的原因是Message not compatible with the protocol state,從而造成CS語音電話的未接通。
[0067]本發(fā)明實施例在3GPP協(xié)議規(guī)范的基礎(chǔ)上，提供一種新的算法流程，去避免此類故障的發(fā)生，提升客戶的語音接通感知。
[0068]首先,自定義一個新的Iu Release Request的Cause (原因值)。根據(jù)3GPPTS25.413 中 9.2.1.4(RANAP 協(xié)議)規(guī)范，Iu Release Request 的原因值分為standard(標(biāo)準)和 non-standard(非標(biāo)準)兩種，其中序號 1-128、257_512 是 standard,而序號129-256是non-standard,可以留給主設(shè)備廠家自己定義。
[0069]本發(fā)明實施例選擇129-256中的其中I個序號(協(xié)議規(guī)范序號256是不能用的)，新增一個Cause值,定義為:remove-MobileID(本發(fā)明實施例中的自定義值)，然后為攜帶cause 值為 remove-MobilelD 的 Iu Release Request 提供對應(yīng)的信令流程。
[0070]按照現(xiàn)有流程，當(dāng)RNC上報Iu Release Request給CN之后，會先觸發(fā)CN下發(fā)Iu Release Command, RNC和CN之間完成Iu連接的拆線；接著RNC下發(fā)RRC Connect1nRelease (RRC連接釋放)，UE與RNC之間完成RRC連接拆除；最后RNC下發(fā)Rad1 LinkDelet1n Request (無線鏈路拆除請求)，指示NodeB完成物理鏈路的拆除,如圖7所示。
[0071]本發(fā)明實施例提供的信令流程是，如果RNC上報攜帶原因值為remove-MobilelD的Iu Release Request, CN下發(fā)的Iu Release Command中攜帶的原因也為remove-MobilelD。當(dāng) RNC 收到 CN下發(fā)的原因值為 remove-MobilelD 的 Iu Release Command后，RNC不進行RRC連接和物理鏈路拆除的相關(guān)操作，RNC和CN之間只完成Iu連接的拆除。
[0072]本發(fā)明實施例針對以上兩個信令和流程的定義提供兩種具體的算法，第一種，如圖8所示:
[0073]步驟81 =RNC收到Node B上報的Rad1 Link Failure后，判斷UE是否進行CS語音業(yè)務(wù)。是的話，進入步驟82;否的話，進入步驟85。
[0074]步驟82:RNC 向 CN 上報原因值為 remove-MobilelD 的 Iu Release Request。
[0075]步驟83:CN 向 RNC 下發(fā)攜帶原因值為 remove-MobilelD 的 Iu Release Command。
[0076]步驟84:RNC與CN之間進行Iu連接拆除，但RNC不進行RRC連接和物理鏈路拆除的相關(guān)操作，隨后，在掉話定時器超時之前，即便UE重新發(fā)起CM Service Request,也不會被CN拒絕。
[0077]步驟85:RNC 向 Node B 下發(fā) Rad1 Link Activat1n Commando
[0078]步驟86:Node B 在收到 RNC 下發(fā)的 Rad1 Link Activat1n Command 后，去激活無線鏈路，觸發(fā)UE發(fā)起小區(qū)更新流程、或者掉話(線)定時器超時觸發(fā)掉話(線)。
[0079]第二種，如圖9所示:
[0080]步驟91:CN收到UE上報的CM Service Request,解析其中的Mobile ID和Establishment Cause (CM Service Request 是 UE 發(fā)給 CN,中間經(jīng)過 RNC,但是 RNC 只是中間做一個透傳，不做任何處理)。
[0081]步驟92:CN判斷是否該Mobile ID的Iu連接是否已經(jīng)存在。是的話，進入步驟
93;否的話，進入步驟96。
[0082]步驟93:C