專利名稱：業(yè)務(wù)請求過程中的異常處理方法及用戶設(shè)備的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，具體而言，涉及一種業(yè)務(wù)請求過程中的異常處理方法及 用戶設(shè)備。
背景技術(shù)：
3GPP演進(jìn)的分組系統(tǒng)(Evolved Packet System,簡稱為EPS)由演進(jìn)的陸地?zé)o線 接入網(wǎng)(Evolved UMTS Terrestrial Radio Access Network,簡稱為 EUTRAN)和 EPS 核心網(wǎng) (Evolved Packet Core,簡稱為 EPC)組成。從功能的角度來說，EPC包含移動性管理實體(Mobile Management Entity，簡 稱為MME)、業(yè)務(wù)網(wǎng)關(guān)(Service-Gateway，簡稱為S-GW)和分組數(shù)據(jù)網(wǎng)網(wǎng)關(guān)(Packet data-Gateway,簡稱為P-GW)三部分；EUTRAN則由演進(jìn)的基站(evolved Node-B，簡稱 為eNB)組成，eNB主要負(fù)責(zé)無線通信、無線通信管理、和移動性上下文的管理。用戶設(shè)備(User Equipment,簡稱為UE)與eNB之間的消息為空口消息，eNB 與MME之間的消息稱為Sl 口消息。對MME而言，UE附著到網(wǎng)絡(luò)期間的連接狀態(tài)有 兩種IDLE (空閑態(tài))和CONNECT (連接態(tài))。在IDLE狀態(tài)下，eNB內(nèi)沒有UE上下 文，UE和MME之間沒有信令鏈接，在空口及Sl 口上也不存在任何用戶面無線承載及 Sl承載，因而，也不能傳遞數(shù)據(jù)；在CONNECT狀態(tài)下，eNB有UE上下文，MME知 道UE當(dāng)前服務(wù)eNB的ID，UE與MME之間存在信令鏈接，在空口及Sl 口上至少存在 一個用戶面無線承載及相應(yīng)Sl承載，可以傳遞數(shù)據(jù)或信令。當(dāng)UE處于IDLE狀態(tài)時，如果UE有上行數(shù)據(jù)或信令需要傳輸，或者 UE收到MME的尋呼消息，則需要發(fā)起業(yè)務(wù)請求過程。該過程由UE的非接入 層(Non-Access Stratum,簡稱為NAS)的演進(jìn)的分組系統(tǒng)移動性管理(EPS Mobility Management,簡稱為EMM)子層發(fā)起，業(yè)務(wù)請求消息(SERVICE REQUEST)發(fā)出后， 會啟動定時器T3417，EMM狀態(tài)由EMM-REGISTERED態(tài)(即，注冊態(tài))躍遷到 EMM-SERVICE-REQUEST-INITIATED態(tài)(即，業(yè)務(wù)請求發(fā)起態(tài))。關(guān)于業(yè)務(wù)請求過 程，3GPP TS 24.301協(xié)議(NAS協(xié)議)有很詳細(xì)的描述，在此不再贅述。正常情況下，在UE的非接入層(NAS)發(fā)起該過程后，UE的接入層會首先完成 隨機(jī)接入及無線資源控制(Radio Resource Control，簡稱為RRC)連接建立過程(UE的連 接狀態(tài)轉(zhuǎn)入CONNECT態(tài))，接著UE接入層會收到eNB發(fā)來的RRC連接重配消息(RRC Connection Reconfiguration)，完成用戶面無線承載的建立。當(dāng)NAS收到底層用戶面無線 承載建立完成指示時，認(rèn)為業(yè)務(wù)請求過程完成，則停止定時器T3417，EMM狀態(tài)返回注 冊態(tài)。在進(jìn)行業(yè)務(wù)請求過程期間，會出現(xiàn)多種異常情況，現(xiàn)有技術(shù)中基本上都進(jìn)行了 描述，并提出了對應(yīng)處理方法。然而，存在這樣一種異常情況，即，UE在RRC連接 建立成功之后，業(yè)務(wù)請求過程結(jié)束之前，收到了 eNB發(fā)來的RRC連接釋放消息(RRC ConnectionRelease),針對該異常情況及NAS層的處理措施，現(xiàn)有技術(shù)方案中均未予以描述，從而導(dǎo)致系統(tǒng)的可控性、容錯能力、穩(wěn)定性及安全性降低，應(yīng)該予以完善。

發(fā)明內(nèi)容
針對現(xiàn)有技術(shù)中未提供在UE進(jìn)行業(yè)務(wù)請求過程期間出現(xiàn)RRC連接釋放的異常 情況時的處理方法的問題而提出本發(fā)明，為此，本發(fā)明的主要目的在于提供一種業(yè)務(wù)請 求過程異常處理方法及用戶設(shè)備，以解決上述問題至少之一。為了實現(xiàn)上述目的，根據(jù)本發(fā)明的一個方面，提供了一種業(yè)務(wù)請求過程中的異 常處理方法，用于用戶設(shè)備UE的非接入層NAS發(fā)起業(yè)務(wù)請求過程中。根據(jù)本發(fā)明的業(yè)務(wù)請求過程中的異常處理方法包括在UE接收到來自基站eNB 的RRC連接釋放消息后，UE放棄業(yè)務(wù)請求過程。優(yōu)選地，放棄業(yè)務(wù)請求過程包括將UE的NAS的演進(jìn)的分組系統(tǒng)移動性管理 EMM子層的狀態(tài)轉(zhuǎn)為注冊態(tài)，停止預(yù)設(shè)定時器，釋放所有為業(yè)務(wù)請求過程分配的資源。優(yōu)選地，預(yù)設(shè)定時器包括定時器T3417。優(yōu)選地，在UE接收到來自基站eNB的RRC連接釋放消息之前，上述方法還包 括eNB在預(yù)定時間未接收到來自移動性管理實體MME的初始上下文建立請求消息的情 況下，向UE發(fā)送RRC連接釋放消息。 優(yōu)選地，在UE接收到來自基站eNB的RRC連接釋放消息之前，上述方法還包 括eNB在滿足預(yù)定失敗條件的情況下，向UE發(fā)送RRC連接釋放消息，其中，預(yù)定失 敗條件包括以下至少之一eNB內(nèi)部配置UE的安全參數(shù)失敗、eNB獲取UE的能力信息 失敗、eNB發(fā)至UE的RRC重配消息丟失、eNB未收到RRC重配完成消息。為了實現(xiàn)上述目的，根據(jù)本發(fā)明的另一個方面，提供了一種UE。根據(jù)本發(fā)明的UE包括接收模塊，用于接收來自eNB的RRC連接釋放消息； 異常處理模塊，用于放棄業(yè)務(wù)請求過程。優(yōu)選地，異常處理模塊包括狀態(tài)轉(zhuǎn)換子模塊，用于將NAS的EMM子層的狀 態(tài)轉(zhuǎn)為注冊態(tài)；定時器停止子模塊，用于停止預(yù)設(shè)定時器；資源釋放子模塊，用于釋放 所有為業(yè)務(wù)請求過程分配的資源。優(yōu)選地，預(yù)設(shè)定時器包括定時器T3417。優(yōu)選地，接收模塊用于接收eNB在預(yù)定時間未接收到來自MME的初始上下文建 立請求消息的情況下發(fā)送至接收模塊的RRC連接釋放消息。優(yōu)選地，接收模塊用于接收eNB在滿足預(yù)定失敗條件的情況下發(fā)送至接收模塊 的RRC連接釋放消息，其中，預(yù)定失敗條件包括以下至少之一eNB內(nèi)部配置UE的安 全參數(shù)失敗、eNB獲取UE的能力信息失敗、eNB發(fā)至UE的RRC重配消息丟失、eNB 未收到RRC重配完成消息。通過本發(fā)明，在UE進(jìn)行業(yè)務(wù)請求過程中接收到RRC連接釋放消息的情況下， 放棄該業(yè)務(wù)請求過程，解決了未提供在UE進(jìn)行業(yè)務(wù)請求過程期間出現(xiàn)RRC連接釋放的 異常情況時的處理方法的問題，改善了現(xiàn)有技術(shù)方案中關(guān)于業(yè)務(wù)請求過程異常處理的不 完善之處，使得處理流程更完善合理，提高了系統(tǒng)的可控性、容錯能力、穩(wěn)定性和安全 性。附圖說 明此處所說明的附圖用來提供對本發(fā)明的進(jìn)一步理解，構(gòu)成本申請的一部分，本 發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當(dāng)限定。在附圖 中

圖1是根據(jù)本發(fā)明實施例的業(yè)務(wù)請求過程中的異常處理方法的流程圖；圖2是根據(jù)本發(fā)明實例1的業(yè)務(wù)請求過程中的異常處理方法的詳細(xì)流程圖；圖3是根據(jù)本發(fā)明實例2的業(yè)務(wù)請求過程中的異常處理方法的詳細(xì)流程圖；圖4是根據(jù)本發(fā)明實例3的業(yè)務(wù)請求過程中的異常處理方法的詳細(xì)流程圖；圖5是根據(jù)本發(fā)明實施例的用戶設(shè)備的結(jié)構(gòu)框圖；圖6是根據(jù)本發(fā)明實施例的異常處理模塊的詳細(xì)結(jié)構(gòu)框圖。
具體實施例方式功能概述考慮到現(xiàn)有技術(shù)中存在的問題，本發(fā)明實施例提供了一種業(yè)務(wù)請求過程中的異 常處理方案，該方案的處理原則為在UE接收到來自基站eNB的RRC連接釋放消息 后，UE放棄業(yè)務(wù)請求過程。該方案改善了現(xiàn)有技術(shù)方案中關(guān)于業(yè)務(wù)請求過程異常處理的 不完善之處，使得處理流程更完善合理，提高了系統(tǒng)的可控性、容錯能力、穩(wěn)定性和安 全性。下文中將參考附圖并結(jié)合實施例來詳細(xì)說明本發(fā)明。需要說明的是，在不沖突 的情況下，本申請中的實施例及實施例中的特征可以相互組合。方法實施例根據(jù)本發(fā)明的實施例，提供了 一種業(yè)務(wù)請求過程中的異常處理方法，用于UE的 非接入層NAS發(fā)起業(yè)務(wù)請求過程中，圖1是根據(jù)本發(fā)明實施例的業(yè)務(wù)請求過程中的異常 處理方法的流程圖，如圖1所示，該方法包括如下的步驟S102至步驟S106:步驟S102，eNB在預(yù)定時間未接收到來自移動性管理實體MME的上下文建立 請求消息的情況下，向UE發(fā)送RRC連接釋放消息，或者，eNB在滿足預(yù)定失敗條件的 情況下，向UE發(fā)送RRC連接釋放消息，其中，預(yù)定失敗條件包括以下至少之一eNB 內(nèi)部配置UE的安全參數(shù)失敗、eNB獲取UE的能力信息失敗、eNB發(fā)至UE的RRC重 配消息丟失、eNB未收到RRC重配完成消息。步驟S104，UE接收到來自基站eNB的RRC連接釋放消息。步驟S106，UE放棄業(yè)務(wù)請求過程，其中，放棄業(yè)務(wù)請求過程包括將UE的非 接入層NAS的演進(jìn)的分組系統(tǒng)移動性管理EMM子層的狀態(tài)轉(zhuǎn)為注冊態(tài)，停止預(yù)設(shè)定時 器，釋放所有為業(yè)務(wù)請求過程分配的資源。上述預(yù)設(shè)定時器可以包括定時器T3417。下面將結(jié)合實例對本發(fā)明實施例的實現(xiàn)過程進(jìn)行詳細(xì)描述。實例1以下結(jié)合業(yè)務(wù)請求過程，詳細(xì)說明本發(fā)明實施例提供的方法，圖2是根據(jù)本發(fā) 明實例1的業(yè)務(wù)請求過程中的異常處理方法的詳細(xì)流程圖，該方法具體包括以下步驟 S202至步驟S206的處理步驟S202，UE在IDLE態(tài)時有上行數(shù)據(jù)或信令要傳輸，或者在IDLE態(tài)下收到了尋呼消息，則UE的NAS層EMM子層發(fā)起業(yè)務(wù)請求過程，該過程具體為發(fā)送業(yè)務(wù) 請求消息(SERVICE REQUEST)，啟動定時器T3417，EMM狀態(tài)由注冊態(tài)躍遷進(jìn)入業(yè)務(wù)
請求發(fā)起態(tài)。步驟S204，UE的接入層收到該上行NAS消息，即，業(yè)務(wù)請求消息，進(jìn)行隨機(jī) 接入過程和RRC連接建立過程，并把該上行NAS消息攜帶在空口消息RRC鏈接建立完 成(RRC Connection Setup Complete)消息內(nèi)發(fā)送至eNB，此時，UE的連接狀態(tài)已由IDLE 態(tài)轉(zhuǎn)入CONNECT態(tài)。步驟S206，UE收到RRC連接釋放消息(RRC Connection Release)，則放棄業(yè)務(wù) 請求過程，停止定時器T3417，EMM狀態(tài)轉(zhuǎn)為注冊態(tài)，同時本地釋放所有為該流程所分 配的資源。實例2 在該實例中，以eNB發(fā)出初始UE消息(InitialUEMessage)后在預(yù)定時間內(nèi)未接 收到來自MME的初始上下文建立請求消息(Initial Context Setup Request)而引起eNB定
時器超時，導(dǎo)致RRC鏈接被釋放的過程為例，描述了本發(fā)明實施例提供的方法，圖3是 根據(jù)本發(fā)明實例2的業(yè)務(wù)請求過程中的異常處理方法的詳細(xì)流程圖。該方法包括以下步 驟S302至步驟S308的處理步驟S302，UE的非接入層NAS發(fā)起業(yè)務(wù)請求過程，啟動定時器T3417，EMM
狀態(tài)躍遷進(jìn)入業(yè)務(wù)請求發(fā)起態(tài)，接入層收到業(yè)務(wù)請求消息后馬上進(jìn)行隨機(jī)接入和RRC連 接建立過程，并在空口 RRC連接建立完成消息中攜帶業(yè)務(wù)請求消息并發(fā)送至eNB。步驟S304，eNB把業(yè)務(wù)請求消息攜帶在Sl消息初始UE消息中發(fā)給MME，并 啟動相關(guān)定時器。步驟S306，eNB未收到預(yù)期的初始上下文建立請求消息，定時器超時，發(fā)送 RRC連接釋放消息至UE。步驟S308，UE-NAS收到RRC連接釋放消息，放棄業(yè)務(wù)請求過程，停止定時器 T3417，EMM狀態(tài)轉(zhuǎn)入注冊態(tài)，同時釋放為該流程所分配的所有資源。實例3在該實例中，eNB收到了初始上下文建立請求消息，繼而進(jìn)行UE與eNB之間的 安全模式控制流程及重配流程，在該過程中，發(fā)生了 eNB內(nèi)部配置UE的安全參數(shù)等失敗 或者RRC重配消息丟失或者沒收到RRC重配完成消息而導(dǎo)致RRC連接異常釋放。圖4 是根據(jù)本發(fā)明實例3的業(yè)務(wù)請求過程中的異常處理方法的詳細(xì)流程圖。該方法包括以下 步驟S402至步驟S410的處理步驟S402，UE非接入層NAS發(fā)起業(yè)務(wù)請求過程，啟動定時器T3417，EMM的
狀態(tài)躍遷進(jìn)入業(yè)務(wù)請求發(fā)起態(tài)，接入層收到業(yè)務(wù)請求消息后馬上進(jìn)行隨機(jī)接入和RRC連 接建立，并在RRC連接建立完成消息中攜帶業(yè)務(wù)請求消息并發(fā)送至eNB。步驟S404，eNB把業(yè)務(wù)請求消息攜帶在Sl 口初始UE消息中發(fā)給MME。步驟S406，eNB收到MME發(fā)來的Sl消息上下文建立請求，根據(jù)實際情況選擇 是否需要獲取UE能力信息，然后進(jìn)行安全模式控制流程。步驟S408，eNB獲取UE的能力信息失敗、eNB內(nèi)部配置UE的安全參數(shù)失敗、 eNB發(fā)給UE的RRC重配消息丟失或者沒收到RRC重配完成消息等原因?qū)е翿RC鏈接被釋放。步驟S410，UE-NAS收到RRC連接釋放消息，放棄業(yè)務(wù)請求過程，停止定時器 T3417，EMM狀態(tài)轉(zhuǎn)入注冊態(tài)，同時釋放為該流程所分配的所有資源。裝置實施例根據(jù)本發(fā)明的實施例，提供了一種用戶設(shè)備，圖5是根據(jù)本發(fā)明實施例的用戶 設(shè)備的結(jié)構(gòu)框圖，如圖5所示，該UE包括接收模塊52，用于接收來自eNB的RRC連 接釋放消息；異常處理模塊54，連接于接收模塊52，用于放棄業(yè)務(wù)請求過程。上述接收模塊52用于接收eNB在預(yù)定時間未接收到來自MME的初始上下文建 立請求消息的情況下發(fā)送至接收模塊的RRC連接釋放消息，或者，用于接收eNB在滿足 預(yù)定失敗條件的情況下發(fā)送至接收模塊的RRC連接釋放消息，其中，預(yù)定失敗條件包括 以下至少之一 eNB獲取UE的能力信息失敗、eNB內(nèi)部配置UE的安全參數(shù)失敗、eNB 發(fā)至UE的RRC重配消息丟失、eNB未收到RRC重配完成消息。圖6是根據(jù)本發(fā)明實施例的異常處理模塊的詳細(xì)結(jié)構(gòu)框圖，如圖6所示，異常處 理模塊54包括狀態(tài)轉(zhuǎn)換子模塊62，用于將NAS的EMM子層的狀態(tài)轉(zhuǎn)為注冊態(tài)；定 時器停止子模塊64，用于停止預(yù)設(shè)定時器，其中，預(yù)設(shè)定時器包括定時器T3417;資源 釋放子模塊66，用于釋放所有為業(yè)務(wù)請求過程分配的資源。需要說明的是，在上述各實例中，以定時器T3417為例進(jìn)行了說明，但在實際 應(yīng)用中，需要停止的定時器由業(yè)務(wù)請求過程中啟動的定時器的種類決定，本發(fā)明對此不 作限定。通過本發(fā)明實施例提供的技術(shù)方案，能夠改善現(xiàn)有技術(shù)方案中關(guān)于業(yè)務(wù)請求過 程異常處理的不完善之處，使得處理流程更完善合理，提高了系統(tǒng)的可控性、容錯能 力、穩(wěn)定性和安全性。 需要說明的是，在附圖的流程圖示出的步驟可以在諸如一組計算機(jī)可執(zhí)行指令 的計算機(jī)系統(tǒng)中執(zhí)行，并且，雖然在流程圖中示出了邏輯順序，但是在某些情況下，可 以以不同于此處的順序執(zhí)行所示出或描述的步驟。顯然，本領(lǐng)域的技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或各步驟可以用通 用的計算裝置來實現(xiàn)，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所 組成的網(wǎng)絡(luò)上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將 它們存儲在存儲裝置中由計算裝置來執(zhí)行，或者將它們分別制作成各個集成電路模塊， 或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明不限制 于任何特定的硬件和軟件結(jié)合。以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領(lǐng)域的 技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的 任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種業(yè)務(wù)請求過程中的異常處理方法，用于用戶設(shè)備UE的非接入層NAS發(fā)起業(yè) 務(wù)請求過程中，其特征在于，所述方法包括在所述UE接收到來自基站eNB的RRC連接釋放消息后，所述UE放棄業(yè)務(wù)請求過程。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述放棄業(yè)務(wù)請求過程包括將所述 UE的NAS的演進(jìn)的分組系統(tǒng)移動性管理EMM子層的狀態(tài)轉(zhuǎn)為注冊態(tài)，停止預(yù)設(shè)定時 器，釋放所有為所述業(yè)務(wù)請求過程分配的資源。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述預(yù)設(shè)定時器包括定時器T3417。
4.根據(jù)權(quán)利要求1所述的方法，其特征在于，在所述UE接收到來自基站eNB的RRC 連接釋放消息之前，所述方法還包括所述eNB在預(yù)定時間未接收到來自移動性管理實體MME的初始上下文建立請求消息 的情況下，向所述UE發(fā)送所述RRC連接釋放消息。
5.根據(jù)權(quán)利要求1所述的方法，其特征在于，在所述UE接收到來自基站eNB的RRC 連接釋放消息之前，所述方法還包括所述eNB在滿足預(yù)定失敗條件的情況下，向所述UE發(fā)送所述RRC連接釋放消息， 其中，所述預(yù)定失敗條件包括以下至少之一所述eNB內(nèi)部配置所述UE的安全參數(shù)失 敗、所述eNB獲取所述UE的能力信息失敗、所述eNB發(fā)至所述UE的RRC重配消息丟 失、所述eNB未收到RRC重配完成消息。
6.—種UE，其特征在于，包括接收模塊，用于接收來自eNB的RRC連接釋放消息；異常處理模塊，用于放棄業(yè)務(wù)請求過程。
7.根據(jù)權(quán)利要求6所述的UE，其特征在于，所述異常處理模塊包括狀態(tài)轉(zhuǎn)換子模塊，用于將NAS的EMM子層的狀態(tài)轉(zhuǎn)為注冊態(tài)；定時器停止子模塊，用于停止預(yù)設(shè)定時器；資源釋放子模塊，用于釋放所有為所述業(yè)務(wù)請求過程分配的資源。
8.根據(jù)權(quán)利要求7所述的UE，其特征在于，所述預(yù)設(shè)定時器包括定時器T3417。
9.根據(jù)權(quán)利要求6所述的UE，其特征在于，所述接收模塊用于接收所述eNB在預(yù)定 時間未接收到來自MME的初始上下文建立請求消息的情況下發(fā)送至所述接收模塊的所述 RRC連接釋放消息。
10.根據(jù)權(quán)利要求6所述的UE，其特征在于，所述接收模塊用于接收所述eNB在滿 足預(yù)定失敗條件的情況下發(fā)送至所述接收模塊的所述RRC連接釋放消息，其中，所述預(yù) 定失敗條件包括以下至少之一所述eNB內(nèi)部配置所述UE的安全參數(shù)失敗、所述eNB 獲取所述UE的能力信息失敗、所述eNB發(fā)至所述UE的RRC重配消息丟失、所述eNB 未收到RRC重配完成消息。
全文摘要
本發(fā)明公開了一種業(yè)務(wù)請求過程中的異常處理方法及用戶設(shè)備。該方法包括在UE接收到來自基站eNB的RRC連接釋放消息后，UE放棄業(yè)務(wù)請求過程。該用戶設(shè)備包括接收模塊，用于接收來自eNB的RRC連接釋放消息；異常處理模塊，用于放棄業(yè)務(wù)請求過程。本發(fā)明解決了未提供在UE進(jìn)行業(yè)務(wù)請求過程期間出現(xiàn)RRC連接釋放的異常情況時的處理方法的問題，改善了現(xiàn)有技術(shù)方案中關(guān)于業(yè)務(wù)請求過程異常處理的不完善之處，使得處理流程更完善合理，提高了系統(tǒng)的可控性、容錯能力、穩(wěn)定性和安全性。
文檔編號H04W88/02GK102026407SQ20091017612
公開日2011年4月20日 申請日期2009年9月21日 優(yōu)先權(quán)日2009年9月21日
發(fā)明者張亞明 申請人:中興通訊股份有限公司