專利名稱：一種lte系統(tǒng)中錯(cuò)誤指示的處理方法和裝置的制作方法
一種LTE系統(tǒng)中錯(cuò)誤指示的處理方法和裝置技術(shù)領(lǐng)域
本發(fā)明屬于無(wú)線通訊技術(shù)領(lǐng)域，特別涉及LTE (Long Term Evolution，長(zhǎng)期演進(jìn)) 系統(tǒng)中，eNB (Evolution NodeB，演進(jìn)基站)處理錯(cuò)誤指示(ERRORIndication)的方法和裝置。
背景技術(shù)：
LTE 系統(tǒng)中，eNB 包含了 RNLC(Radio Network Layer-Control Plane，無(wú)線網(wǎng)絡(luò) 層控制面)、RNLU (Radio Network Layer-User Plane，無(wú)線網(wǎng)絡(luò)層用戶面)、MAC (Medium Access Control，媒體接入控制)和PHY(物理層)。RNLC主要針對(duì)的是eNB控制面，主要 用于控制信息、信令的交互，主要包括公用信令和專用信令的傳輸。RNLU主要針對(duì)的是eNB 用戶面，用于空口信令和用戶數(shù)據(jù)的傳輸?shù)取NLU分為DMAC (Destination MAC,目的MAC)、 RLC(Radio Link Control，無(wú)線鏈路控制)、PDCP (Packet Data Convergence Protocol，分 組數(shù)據(jù)匯聚協(xié)議)和GTPU (GPRS Tunnel Protocol User Plane，GPRS隧道協(xié)議用戶面)幾 個(gè)層面，保證數(shù)據(jù)與信令的可靠傳輸。
RLC層位于MAC層之上，為用戶和控制數(shù)據(jù)提供分段和重傳業(yè)務(wù)。每個(gè)RLC實(shí)體 由RRC(Radic) Resource Control，無(wú)線資源控制協(xié)議)配置，并且根據(jù)業(yè)務(wù)類型有三種模 式TM(Transparent Mode，透明模式)模式、UM(Unacknowledged Mode，非確認(rèn)模式)模 式、AM (Acknowledged Mode，確認(rèn)模式)模式。在傳輸過(guò)程中，例如設(shè)置的傳輸模式為AM模 式，即每發(fā)送一包數(shù)據(jù)，需要對(duì)方實(shí)體回復(fù)響應(yīng)ACI^ACKnowledgement，確認(rèn)應(yīng)答)，若未收 到響應(yīng)，則會(huì)重復(fù)發(fā)送該數(shù)據(jù)包，若發(fā)送達(dá)到了最大重傳次數(shù)，則證明對(duì)方實(shí)體出現(xiàn)異常情 況，此時(shí)eNB用戶面向eNB控制面發(fā)送錯(cuò)誤指示信息，指示相關(guān)業(yè)務(wù)發(fā)生異常。
PDCP層在AS (Access Stratum,接入層)協(xié)議棧中的位置位于RLC層之上，受RRC 的調(diào)度和控制，將來(lái)自上層的用戶數(shù)據(jù)傳輸?shù)絉LC子層。PDCP提供給上層的服務(wù)是PDCP SDU(Service Data Unit，服務(wù)數(shù)據(jù)單元)傳遞。每個(gè) PS(Packet Switched Domain，分組 交換域)域的RAB (Radio Access Bearer，無(wú)線接入承載)都和一個(gè)RB (Resource Block, 資源塊)相關(guān)聯(lián)，每個(gè)RB又和一個(gè)PDCP實(shí)體相關(guān)聯(lián)。完整性保護(hù)與完整性保護(hù)驗(yàn)證是由 PDCP層完成的，且是與SRB (Signaling Radio Bearer，信令無(wú)線承載)相關(guān)聯(lián)的。若完整 性保護(hù)或完整性保護(hù)驗(yàn)證發(fā)生異常失敗，則eNB用戶面會(huì)向eNB控制面發(fā)送錯(cuò)誤指示信息， 指示相關(guān)的RAB發(fā)生異常。
eNB用戶面的GTPU收到核心網(wǎng)發(fā)送的錯(cuò)誤指示，比如在發(fā)送數(shù)據(jù)的情況下，eNB向 核心網(wǎng)發(fā)送數(shù)據(jù)，攜帶有源側(cè)即eNB的TEID (Tunneling Endpoint Identif ier，隧道ID)以 及核心網(wǎng)側(cè)的目的隧道ID，核心網(wǎng)在收到該包數(shù)據(jù)后進(jìn)行解析，發(fā)現(xiàn)目的側(cè)的隧道ID在本 地找不到匹配的隧道，此時(shí)核心網(wǎng)就給eNB用戶面發(fā)送一個(gè)錯(cuò)誤指示，eNB用戶面在收到該 消息后，會(huì)向eNB控制面發(fā)送錯(cuò)誤指示信息。
綜上可見(jiàn)，eNB用戶面可能在不同情形下向eNB控制面發(fā)送錯(cuò)誤指示?，F(xiàn)有技術(shù) 中，eNB控制面收到eNB用戶面發(fā)來(lái)的錯(cuò)誤指示消息后，直接進(jìn)行UE(User Equipment，用戶設(shè)備)上下文資源的釋放。這樣的處理不區(qū)分具體發(fā)生錯(cuò)誤的原因與發(fā)生錯(cuò)誤的業(yè)務(wù)類 型，將所有資源釋放，可能導(dǎo)致不需要釋放的資源也被釋放掉，影響用戶的使用感受，也影 響到對(duì)產(chǎn)品本身的滿意度。發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問(wèn)題是提出一種LTE系統(tǒng)中錯(cuò)誤指示的處理方法，采用該方 法可以根據(jù)發(fā)生錯(cuò)誤的業(yè)務(wù)類型合理地釋放相關(guān)資源，避免因釋放掉不該被釋放的資源而 影響產(chǎn)品的使用性能。為此，本發(fā)明還提供一種LTE系統(tǒng)中錯(cuò)誤指示的處理裝置。
為解決上述技術(shù)問(wèn)題，本發(fā)明提出的LTE系統(tǒng)中錯(cuò)誤指示的處理方法，包括如下 步驟
第一步，eNB用戶面檢測(cè)到錯(cuò)誤發(fā)生時(shí)，向eNB控制面發(fā)送錯(cuò)誤指示，其中包含錯(cuò) 誤原因和業(yè)務(wù)識(shí)別信息，所述業(yè)務(wù)識(shí)別信息用于標(biāo)識(shí)發(fā)生異常的業(yè)務(wù)類型；
第二步，eNB控制面收到eNB用戶面發(fā)來(lái)的錯(cuò)誤指示后，根據(jù)業(yè)務(wù)識(shí)別信息判斷出 發(fā)生異常的業(yè)務(wù)類型，然后進(jìn)行相應(yīng)處理。
在上述第一步中，eNB用戶面檢測(cè)到的錯(cuò)誤包括完整性保護(hù)發(fā)生異常失敗、完整性 保護(hù)驗(yàn)證發(fā)生異常失敗、RLC重傳達(dá)到最大次數(shù)以及核心網(wǎng)向eNB用戶面發(fā)送錯(cuò)誤指示等 各種情形，即可能是其中的任何一種。
在上述第二步中，若判斷出發(fā)生異常的業(yè)務(wù)是SRB業(yè)務(wù)，則eNB控制面向核心網(wǎng)發(fā) 送初始用戶設(shè)備上下文資源釋放請(qǐng)求(Initial Ue Context Release Request)，指示需要 進(jìn)行上下文資源的釋放，進(jìn)而釋放RRC和eNB內(nèi)的上下文資源。
在上述第二步中，若判斷出發(fā)生異常的業(yè)務(wù)是DRB業(yè)務(wù)，則eNB控制面向核心網(wǎng) 發(fā)送ERAB(E_UTRAN Radio Access Bearer，演進(jìn)3G無(wú)線接入網(wǎng)絡(luò)無(wú)線接入承載)釋放指 示(ERAB Release hdication)，指示該DRB業(yè)務(wù)的相應(yīng)資源需要釋放，而后eNB與核心網(wǎng) 進(jìn)行各自的資源釋放。進(jìn)一步地，由于默認(rèn)承載對(duì)于eNB內(nèi)是不可見(jiàn)的，因此如果發(fā)生異常 的是默認(rèn)承載，此時(shí)eNB控制面向核心網(wǎng)發(fā)送ERAB Release hdication后，核心網(wǎng)發(fā)現(xiàn) 請(qǐng)求釋放的是默認(rèn)承載，則會(huì)進(jìn)一步給eNB控制面下發(fā)用戶設(shè)備上下文資源釋放命令⑴e Context Release Command)，要求進(jìn)行上下文資源的釋放。
為解決上述技術(shù)問(wèn)題，本發(fā)明提出的LTE系統(tǒng)中錯(cuò)誤指示的處理裝置，包括eNB用 戶面模塊和eNB控制面模塊。所述eNB用戶面模塊用于在檢測(cè)到錯(cuò)誤發(fā)生時(shí)向eNB控制面 模塊發(fā)送錯(cuò)誤指示，該錯(cuò)誤指示包含錯(cuò)誤原因和業(yè)務(wù)識(shí)別信息，其中業(yè)務(wù)識(shí)別信息用于標(biāo) 識(shí)發(fā)生異常的業(yè)務(wù)類型；所述eNB控制面模塊用于收到eNB用戶面模塊發(fā)來(lái)的錯(cuò)誤指示后， 根據(jù)業(yè)務(wù)識(shí)別信息判斷出發(fā)生異常的業(yè)務(wù)類型，然后進(jìn)行相應(yīng)處理。
進(jìn)一步地，所述eNB用戶面模塊包括錯(cuò)誤檢測(cè)單元和錯(cuò)誤指示發(fā)送單元。其中，錯(cuò) 誤檢測(cè)單元用于檢測(cè)發(fā)生錯(cuò)誤的各種情形，并將錯(cuò)誤原因提供給錯(cuò)誤指示發(fā)送單元；錯(cuò)誤 指示發(fā)送單元用于將錯(cuò)誤原因和業(yè)務(wù)識(shí)別信息構(gòu)造成錯(cuò)誤指示并將其發(fā)送給eNB控制面 模塊。
進(jìn)一步地，所述eNB控制面模塊包括錯(cuò)誤指示接收單元、異常業(yè)務(wù)判斷單元和錯(cuò) 誤處理單元。其中，錯(cuò)誤指示接收單元用于接收eNB用戶面模塊發(fā)來(lái)的錯(cuò)誤指示，并將其中 的業(yè)務(wù)識(shí)別信息提供給異常業(yè)務(wù)判斷單元；異常業(yè)務(wù)判斷單元用于根據(jù)業(yè)務(wù)識(shí)別信息判斷出發(fā)生異常的業(yè)務(wù)類型，并將判斷結(jié)果提供給錯(cuò)誤處理單元；錯(cuò)誤處理單元根據(jù)發(fā)生異常 的不同業(yè)務(wù)類型進(jìn)行相應(yīng)的處理。
進(jìn)一步地，當(dāng)異常業(yè)務(wù)判斷單元判斷出發(fā)生異常的業(yè)務(wù)是SRB業(yè)務(wù)時(shí)，所述錯(cuò)誤 處理單元向核心網(wǎng)發(fā)送初始用戶設(shè)備上下文資源釋放請(qǐng)求(Initial Ue Context Release Request)，指示需要進(jìn)行上下文資源的釋放，進(jìn)而釋放RRC和eNB內(nèi)的上下文資源；當(dāng)異常 業(yè)務(wù)判斷單元判斷出發(fā)生異常的業(yè)務(wù)是DRB業(yè)務(wù)時(shí)，所述錯(cuò)誤處理單元向核心網(wǎng)發(fā)送ERAB 釋放指示(ERAB Release hdication)，指示該DRB業(yè)務(wù)的相應(yīng)資源需要釋放，而后eNB與 核心網(wǎng)進(jìn)行各自的資源釋放。進(jìn)一步地，如果發(fā)生異常的是默認(rèn)承載，此時(shí)所述錯(cuò)誤處理 單元向核心網(wǎng)發(fā)送ERAB Release Indication后，核心網(wǎng)發(fā)現(xiàn)請(qǐng)求釋放的是默認(rèn)承載，則 會(huì)給eNB控制面模塊下發(fā)用戶設(shè)備上下文資源釋放命令(Ue Context Release Command), 要求進(jìn)行上下文資源的釋放；如果核心網(wǎng)檢測(cè)到請(qǐng)求釋放的不是默認(rèn)承載，則不下發(fā)化 Context Release Command或ERAB Release Command命令，網(wǎng)絡(luò)層與無(wú)線側(cè)各自釋放相應(yīng) 的承載。
本發(fā)明提供了一種LTE系統(tǒng)中錯(cuò)誤指示的處理方法和裝置，其好處主要在于區(qū) 分了發(fā)生異常的業(yè)務(wù)是SRB業(yè)務(wù)還是DRB業(yè)務(wù)，并相應(yīng)地提供了合理的處理方式，對(duì)不能 正常運(yùn)行的業(yè)務(wù)及時(shí)予以資源釋放，避免了資源的浪費(fèi)或不當(dāng)釋放，保證了 eNB的正常運(yùn) 行，提高了用戶的使用滿意度。此外，本發(fā)明的處理涵蓋了 eNB用戶面的所有發(fā)送ERROR Indication 的原因。


圖1是UE、eNB和MME的接口關(guān)系圖2是eNB控制面與用戶面接口關(guān)系圖3是本發(fā)明錯(cuò)誤指示提示SRB業(yè)務(wù)發(fā)生異常的處理過(guò)程圖4是本發(fā)明錯(cuò)誤指示提示DRB業(yè)務(wù)發(fā)生異常之一的處理過(guò)程圖5是本發(fā)明錯(cuò)誤指示提示DRB業(yè)務(wù)發(fā)生異常之二的處理過(guò)程圖6是本發(fā)明錯(cuò)誤指示的處理裝置結(jié)構(gòu)示意圖。
具體實(shí)施方式
為更進(jìn)一步闡述本發(fā)明為達(dá)成預(yù)定目的所采取的技術(shù)手段及功效，以下結(jié)合附圖 及實(shí)施例，對(duì)本發(fā)明提出的LTE系統(tǒng)中錯(cuò)誤指示的處理方法和裝置詳細(xì)說(shuō)明如下。
圖 1 是 UE、eNB 禾Π MME (Mobility Management Entity，移動(dòng)性管理實(shí)體)的接口 關(guān)系圖。在LTE系統(tǒng)中，eNB與UE之間通過(guò)Uu接口進(jìn)行信息交互；eNB與MME之間通過(guò)Sl 接口進(jìn)行信息交互，MME是核心網(wǎng)的一個(gè)實(shí)體。
參見(jiàn)圖2，eNB 控制面與 eNB 用戶面通過(guò) RUDP(Reliable User Datagram I^otocol，可靠用戶數(shù)據(jù)報(bào)協(xié)議)鏈路進(jìn)行信息交互。
實(shí)施例1
本實(shí)施例是說(shuō)明當(dāng)完整性保護(hù)失敗或完整性保護(hù)驗(yàn)證失敗或RLC重傳達(dá)到最大 次數(shù)時(shí)，eNB用戶面向eNB控制面發(fā)送錯(cuò)誤指示，指示相應(yīng)的SRB業(yè)務(wù)發(fā)生異常，eNB控制面 的處理流程，如圖3所示。eNB用戶面上報(bào)的錯(cuò)誤指示包含業(yè)務(wù)識(shí)別信息與發(fā)生異常的原因，業(yè)務(wù)識(shí)別信息用以指示發(fā)生異常的業(yè)務(wù)類型。
步驟300，eNB用戶面檢測(cè)到PDCP層面發(fā)生了完整性保護(hù)失敗或完整性保護(hù)驗(yàn)證 失敗或RLC重傳達(dá)到最大次數(shù)，向eNB控制面發(fā)送Error Indication，其中包含了指示發(fā)生 異常的業(yè)務(wù)類型的業(yè)務(wù)識(shí)別信息與錯(cuò)誤原因；
步驟301，eNB控制面收到eNB用戶面發(fā)來(lái)的Error Indication后，根據(jù)業(yè)務(wù)識(shí) 別信息進(jìn)行判斷，判斷出發(fā)生異常的業(yè)務(wù)屬于SRB業(yè)務(wù)，即信令業(yè)務(wù)發(fā)生異常失敗，可能是 SRBl或SRB2業(yè)務(wù)；
步驟302，由于eNB控制面判斷出是SRB業(yè)務(wù)發(fā)生異常，所以向核心網(wǎng)發(fā)送初始用 戶設(shè)備上下文資源釋放請(qǐng)求(Initial Ue Context Release Request)，請(qǐng)求核心網(wǎng)下發(fā)初 始用戶設(shè)備上下文資源釋放命令(Initial Ue Context Release Command)；
步驟303，核心網(wǎng)向eNB控制面下發(fā)初始用戶設(shè)備上下文資源釋放命令；
步驟304，eNB控制面向UE發(fā)送RRC釋放命令，指示RRC的釋放；
步驟305，eNB控制面刪除eNB用戶面的有關(guān)實(shí)體；
步驟306，eNB控制面指示eNB內(nèi)上下文資源的釋放。
至此，對(duì)于Error hdication指示SRB發(fā)生異常的處理完成。
實(shí)施例2
本實(shí)施例是說(shuō)明當(dāng)RLC重傳達(dá)到最大重傳次數(shù)時(shí)，eNB用戶面向eNB控制面發(fā)送 錯(cuò)誤指示，指示相應(yīng)的DRB業(yè)務(wù)發(fā)生異常，eNB控制面的處理步驟，如圖4所示。
步驟400，eNB用戶面檢查到RLC重傳達(dá)到了最大重傳次數(shù)時(shí)，向eNB控制面發(fā)送 Error Indication，指示相應(yīng)的業(yè)務(wù)發(fā)生錯(cuò)誤，并指示錯(cuò)誤原因；
步驟401，eNB控制面收到eNB用戶面發(fā)來(lái)的Error Indication，根據(jù)其中的業(yè)務(wù) 識(shí)別信息判斷出發(fā)生異常的業(yè)務(wù)是DRB業(yè)務(wù)；
步驟402，由于eNB控制面判斷出是DRB業(yè)務(wù)發(fā)生異常，所以向核心網(wǎng)發(fā)送ERAB Release Indication，指示該DRB業(yè)務(wù)發(fā)生異常，需要釋放相應(yīng)的資源；
步驟403，根據(jù) 3GPP TS36-413 協(xié)議，eNB 控制面發(fā)送 ERAB Release Indication 后，不再等待ERAB Release Command消息，由核心網(wǎng)與eNB各自釋放相應(yīng)的DRB業(yè)務(wù)資源；
步驟404，eNB控制面向UE發(fā)送RRC Reconfiguration消息，進(jìn)行RRC重配置；
步驟405，UE 向 eNB 控制面回復(fù) RRC Reconfiguration Complete 消息，指示 UE RRC重配置完成。
至此，在RLC重傳達(dá)到最大重傳次數(shù)的情況下，對(duì)于Error Indication指示DRB 發(fā)生異常的處理完成。
這里需要說(shuō)明的是，默認(rèn)承載對(duì)于eNB來(lái)說(shuō)是不可見(jiàn)的，即eNB不能區(qū)分專用承 載與默認(rèn)承載，因此若默認(rèn)承載發(fā)生異常，如RLC重傳達(dá)到最大重傳次數(shù)等，eNB用戶面向 eNB控制面發(fā)送該業(yè)務(wù)的錯(cuò)誤指示，eNB控制面將需要釋放的業(yè)務(wù)上報(bào)至核心網(wǎng)，核心網(wǎng)需 判斷該業(yè)務(wù)是默認(rèn)承載還是專用承載。若是默認(rèn)承載，核心網(wǎng)需要向無(wú)線側(cè)eNB控制面下 Shitial Ue Context Release Command命令，要求釋放初始用戶設(shè)備上下文資源，而后 eNB控制面指示UE釋放RRC，再刪除eNB用戶面的有關(guān)實(shí)體，以及指示eNB內(nèi)上下文資源的 釋放，如圖4中虛線框部分所示。
實(shí)施例3
eNB用戶面向核心網(wǎng)發(fā)送數(shù)據(jù)時(shí)，如ping包，會(huì)攜帶有源側(cè)即eNB的隧道ID，還有 核心網(wǎng)側(cè)的目的隧道ID，核心網(wǎng)在收到該包數(shù)據(jù)后進(jìn)行解析，發(fā)現(xiàn)目的側(cè)的隧道ID在本地 找不到匹配的隧道，此時(shí)核心網(wǎng)就給eNB用戶面發(fā)送一個(gè)Error hdication。本實(shí)施例是 說(shuō)明核心網(wǎng)GTPU發(fā)生異常，向eNB用戶面發(fā)送了 Error Indication時(shí)，eNB用戶面與eNB 控制面的處理過(guò)程。
步驟500，核心網(wǎng)GTPU檢測(cè)到隧道ID錯(cuò)誤，向eNB用戶面發(fā)送Error Indication, 指示相關(guān)業(yè)務(wù)的隧道ID異常，如本地不存在匹配的隧道；
步驟501，eNB用戶面收到核心網(wǎng)發(fā)來(lái)的錯(cuò)誤指示，本地組織消息，向eNB控制面發(fā) 送Error Indication，指示發(fā)生異常的業(yè)務(wù)；
步驟502，eNB控制面收到eNB用戶面發(fā)來(lái)的Error Indication，根據(jù)其中的業(yè)務(wù) 識(shí)別信息判斷出發(fā)生異常的業(yè)務(wù)是DRB業(yè)務(wù)；
步驟503，由于eNB控制面判斷出是DRB業(yè)務(wù)發(fā)生異常，所以向核心網(wǎng)發(fā)送ERAB釋 放指示(ERAB Release hdication)，指示該DRB業(yè)務(wù)發(fā)生異常，需要釋放相應(yīng)的資源；
步驟504，eNB、核心網(wǎng)各自釋放相應(yīng)的DRB業(yè)務(wù)資源；
步驟505，eNB控制面向UE發(fā)送RRC重配置消息(RRC Reconf iguration)，進(jìn)行RRC重配置；
步驟506，UE向eNB控制面回復(fù)RRC重配置完畢消息(RRC Reconfiguration Complete)，指示UE RRC重配置完成。
至此，在核心網(wǎng)向eNB用戶面發(fā)送Error Indication的情況下，對(duì)于eNB用戶面 發(fā)送Error Indication指示DRB發(fā)生異常的處理完成。
需要進(jìn)一步說(shuō)明的是，eNB用戶面向eNB控制面發(fā)送該業(yè)務(wù)的錯(cuò)誤指示，eNB控 制面將需要釋放的業(yè)務(wù)上報(bào)至核心網(wǎng)，核心網(wǎng)需判斷該業(yè)務(wù)是默認(rèn)承載還是專用承載。 若是默認(rèn)承載，核心網(wǎng)需要向無(wú)線側(cè)eNB控制面下發(fā)初始用戶設(shè)備上下文資源釋放命令 (Initial Ue Context Release Command)，要求釋放初始用戶設(shè)備上下文資源，而后eNB控 制面指示UE釋放RRC，再刪除eNB用戶面的有關(guān)實(shí)體，以及指示eNB內(nèi)上下文資源的釋放， 如圖5中虛線框部分所示。
實(shí)施例4
參見(jiàn)圖6，本實(shí)施例錯(cuò)誤指示的處理裝置包括eNB用戶面模塊和eNB控制面模塊。 所述eNB用戶面模塊用于在檢測(cè)到錯(cuò)誤發(fā)生時(shí)向eNB控制面模塊發(fā)送錯(cuò)誤指示，該錯(cuò)誤指 示包含錯(cuò)誤原因和業(yè)務(wù)識(shí)別信息，其中業(yè)務(wù)識(shí)別信息用于標(biāo)識(shí)發(fā)生異常的業(yè)務(wù)類型；所述 eNB控制面模塊用于收到eNB用戶面模塊發(fā)來(lái)的錯(cuò)誤指示后，根據(jù)業(yè)務(wù)識(shí)別信息判斷出發(fā) 生異常的業(yè)務(wù)類型，然后進(jìn)行相應(yīng)處理。
所述eNB用戶面模塊進(jìn)一步包括錯(cuò)誤檢測(cè)單元和錯(cuò)誤指示發(fā)送單元。其中，錯(cuò)誤 檢測(cè)單元用于檢測(cè)發(fā)生錯(cuò)誤的各種情形，并將錯(cuò)誤原因提供給錯(cuò)誤指示發(fā)送單元；錯(cuò)誤指 示發(fā)送單元用于將錯(cuò)誤原因和業(yè)務(wù)識(shí)別信息構(gòu)造成錯(cuò)誤指示并將其發(fā)送給eNB控制面模 塊。
所述eNB控制面模塊進(jìn)一步包括錯(cuò)誤指示接收單元、異常業(yè)務(wù)判斷單元和錯(cuò)誤處 理單元。其中，錯(cuò)誤指示接收單元用于接收eNB用戶面模塊發(fā)來(lái)的錯(cuò)誤指示，并將其中的業(yè) 務(wù)識(shí)別信息提供給異常業(yè)務(wù)判斷單元；異常業(yè)務(wù)判斷單元用于根據(jù)業(yè)務(wù)識(shí)別信息判斷出發(fā)生異常的業(yè)務(wù)類型，并將判斷結(jié)果提供給錯(cuò)誤處理單元；錯(cuò)誤處理單元根據(jù)發(fā)生異常的不 同業(yè)務(wù)類型進(jìn)行相應(yīng)的處理。
當(dāng)異常業(yè)務(wù)判斷單元判斷出發(fā)生異常的業(yè)務(wù)是SRBl或SRB2的業(yè)務(wù)時(shí)，所述錯(cuò)誤 處理單元向核心網(wǎng)發(fā)送初始用戶設(shè)備上下文資源釋放請(qǐng)求(Initial Ue Context Release Request)，指示需要進(jìn)行上下文資源的釋放，進(jìn)而釋放RRC和eNB內(nèi)的上下文資源；當(dāng)異常 業(yè)務(wù)判斷單元判斷出發(fā)生異常的業(yè)務(wù)是DRB業(yè)務(wù)時(shí)，所述錯(cuò)誤處理單元向核心網(wǎng)發(fā)送ERAB 釋放指示(ERAB Release hdication)，指示該DRB業(yè)務(wù)的相應(yīng)資源需要釋放，而后eNB與 核心網(wǎng)進(jìn)行各自的資源釋放。
進(jìn)一步地，如果發(fā)生異常的是默認(rèn)承載，此時(shí)所述錯(cuò)誤處理單元向核心網(wǎng)發(fā)送 ERAB Release Indication后，核心網(wǎng)發(fā)現(xiàn)請(qǐng)求釋放的是默認(rèn)承載，則會(huì)給eNB控制面模塊 下發(fā)用戶設(shè)備上下文資源釋放命令(Ue Context Release Command)，要求進(jìn)行上下文資源 的釋放。
通過(guò)上述具體實(shí)施方式
的說(shuō)明，當(dāng)可對(duì)本發(fā)明為達(dá)成預(yù)定目的所采取的技術(shù)手段 及功效得以更加深入且具體的了解，然而具體實(shí)施方式
及所附圖示僅是提供參考與說(shuō)明之 用，并非用來(lái)對(duì)本發(fā)明加以限制。
權(quán)利要求
1.一種LTE系統(tǒng)中錯(cuò)誤指示的處理方法，其特征在于包括如下步驟第一步，演進(jìn)基站(eNB)用戶面檢測(cè)到錯(cuò)誤發(fā)生時(shí)，向eNB控制面發(fā)送錯(cuò)誤指示，其中 包含錯(cuò)誤原因和業(yè)務(wù)識(shí)別信息，所述業(yè)務(wù)識(shí)別信息用于標(biāo)識(shí)發(fā)生異常的業(yè)務(wù)類型；第二步，eNB控制面收到eNB用戶面發(fā)來(lái)的錯(cuò)誤指示后，根據(jù)業(yè)務(wù)識(shí)別信息判斷出發(fā)生 異常的業(yè)務(wù)類型，然后進(jìn)行相應(yīng)處理。
2.根據(jù)權(quán)利要求1所述的錯(cuò)誤指示的處理方法，其特征在于，在所述第二步中，若判斷 出發(fā)生異常的業(yè)務(wù)是信令無(wú)線承載(SRB)業(yè)務(wù)，則eNB控制面向核心網(wǎng)發(fā)送初始用戶設(shè)備 上下文資源釋放請(qǐng)求，指示需要進(jìn)行上下文資源的釋放，進(jìn)而釋放RRC和eNB內(nèi)的上下文資 源。
3.根據(jù)權(quán)利要求1所述的錯(cuò)誤指示的處理方法，其特征在于，在所述第二步中，若判斷 出發(fā)生異常的業(yè)務(wù)是數(shù)據(jù)無(wú)線承載(DRB)業(yè)務(wù)，則eNB控制面向核心網(wǎng)發(fā)送演進(jìn)3G無(wú)線接 入網(wǎng)絡(luò)無(wú)線接入承載(ERAB)釋放指示，指示該DRB業(yè)務(wù)的相應(yīng)資源需要釋放，而后eNB與 核心網(wǎng)進(jìn)行各自的資源釋放。
4.根據(jù)權(quán)利要求3所述的錯(cuò)誤指示的處理方法，其特征在于，若發(fā)生異常的是默認(rèn)承 載，在eNB控制面向核心網(wǎng)發(fā)送ERAB釋放指示后，核心網(wǎng)進(jìn)一步給eNB控制面下發(fā)用戶設(shè) 備上下文資源釋放命令，要求進(jìn)行上下文資源的釋放。
5.根據(jù)權(quán)利要求1或2所述的錯(cuò)誤指示的處理方法，其特征在于具體包括如下步驟 步驟300，eNB用戶面檢測(cè)到分組數(shù)據(jù)匯聚協(xié)議(PDCP)層面發(fā)生了完整性保護(hù)失敗或完整性保護(hù)驗(yàn)證失敗或無(wú)線鏈路控制(RLC)重傳達(dá)到最大次數(shù)，向eNB控制面發(fā)送錯(cuò)誤指 示；步驟301，eNB控制面收到eNB用戶面發(fā)來(lái)的錯(cuò)誤指示后，根據(jù)業(yè)務(wù)識(shí)別信息判斷出發(fā) 生異常的業(yè)務(wù)屬于SRB業(yè)務(wù)；步驟302，eNB控制面向核心網(wǎng)發(fā)送初始用戶設(shè)備上下文資源釋放請(qǐng)求，請(qǐng)求核心網(wǎng)下 發(fā)初始用戶設(shè)備上下文資源釋放命令；步驟303，核心網(wǎng)向eNB控制面下發(fā)初始用戶設(shè)備上下文資源釋放命令； 步驟304，eNB控制面向用戶設(shè)備(UE)發(fā)送RRC釋放命令，指示RRC的釋放； 步驟305，eNB控制面刪除eNB用戶面的有關(guān)實(shí)體； 步驟306，eNB控制面指示eNB內(nèi)上下文資源的釋放。
6.根據(jù)權(quán)利要求1或3所述的錯(cuò)誤指示的處理方法，其特征在于具體包括如下步驟 步驟501，eNB用戶面檢查到RLC重傳達(dá)到了最大重傳次數(shù)或者收到核心網(wǎng)發(fā)來(lái)的錯(cuò)誤指示，向eNB控制面發(fā)送錯(cuò)誤指示；步驟502，eNB控制面收到eNB用戶面發(fā)來(lái)的錯(cuò)誤指示，根據(jù)業(yè)務(wù)識(shí)別信息判斷出發(fā)生 異常的業(yè)務(wù)是DRB業(yè)務(wù)；步驟503，eNB控制面向核心網(wǎng)發(fā)送ERAB釋放指示，指示該DRB業(yè)務(wù)發(fā)生異常需要釋放 相應(yīng)的資源；步驟504，eNB、核心網(wǎng)各自釋放相應(yīng)的DRB業(yè)務(wù)資源；步驟505，eNB控制面向UE發(fā)送RRC重配置消息，進(jìn)行RRC重配置；步驟506，UE向eNB控制面回復(fù)RRC重配置完畢消息，指示UE RRC重配置完成。
7.根據(jù)權(quán)利要求6所述的錯(cuò)誤指示的處理方法，其特征在于，如果核心網(wǎng)判斷出發(fā)生異常的業(yè)務(wù)是默認(rèn)承載，在所述步驟506之后，核心網(wǎng)向無(wú)線側(cè)eNB控制面下發(fā)初始用戶設(shè) 備上下文資源釋放命令，要求釋放初始用戶設(shè)備上下文資源，而后eNB控制面指示UE釋放 RRC，再刪除eNB用戶面的有關(guān)實(shí)體，以及指示eNB內(nèi)上下文資源的釋放。
8.一種LTE系統(tǒng)中錯(cuò)誤指示的處理裝置，其特征在于包括eNB用戶面模塊和eNB控制 面模塊；所述eNB用戶面模塊用于在檢測(cè)到錯(cuò)誤發(fā)生時(shí)向eNB控制面模塊發(fā)送錯(cuò)誤指示，該錯(cuò) 誤指示包含錯(cuò)誤原因和業(yè)務(wù)識(shí)別信息，其中業(yè)務(wù)識(shí)別信息用于標(biāo)識(shí)發(fā)生異常的業(yè)務(wù)類型；所述eNB控制面模塊用于收到eNB用戶面模塊發(fā)來(lái)的錯(cuò)誤指示后，根據(jù)業(yè)務(wù)識(shí)別信息 判斷出發(fā)生異常的業(yè)務(wù)類型，然后進(jìn)行相應(yīng)處理。
9.根據(jù)權(quán)利要求8所述的錯(cuò)誤指示的處理裝置，其特征在于，所述eNB用戶面模塊包括 錯(cuò)誤檢測(cè)單元和錯(cuò)誤指示發(fā)送單元；其中，錯(cuò)誤檢測(cè)單元用于檢測(cè)發(fā)生錯(cuò)誤的各種情形，并 將錯(cuò)誤原因提供給錯(cuò)誤指示發(fā)送單元；錯(cuò)誤指示發(fā)送單元用于將錯(cuò)誤原因和業(yè)務(wù)識(shí)別信息 構(gòu)造成錯(cuò)誤指示并將其發(fā)送給eNB控制面模塊；所述eNB控制面模塊包括錯(cuò)誤指示接收單元、異常業(yè)務(wù)判斷單元和錯(cuò)誤處理單元；其 中，錯(cuò)誤指示接收單元用于接收eNB用戶面模塊發(fā)來(lái)的錯(cuò)誤指示，并將其中的業(yè)務(wù)識(shí)別信 息提供給異常業(yè)務(wù)判斷單元；異常業(yè)務(wù)判斷單元用于根據(jù)業(yè)務(wù)識(shí)別信息判斷出發(fā)生異常的 業(yè)務(wù)類型，并將判斷結(jié)果提供給錯(cuò)誤處理單元；錯(cuò)誤處理單元根據(jù)發(fā)生異常的不同業(yè)務(wù)類 型進(jìn)行相應(yīng)的處理。
10.根據(jù)權(quán)利要求9所述的錯(cuò)誤指示的處理裝置，其特征在于，當(dāng)異常業(yè)務(wù)判斷單元判 斷出發(fā)生異常的業(yè)務(wù)是SRB業(yè)務(wù)時(shí)，所述錯(cuò)誤處理單元向核心網(wǎng)發(fā)送初始用戶設(shè)備上下文 資源釋放請(qǐng)求，指示需要進(jìn)行上下文資源的釋放，進(jìn)而釋放RRC和eNB內(nèi)的上下文資源；當(dāng)異常業(yè)務(wù)判斷單元判斷出發(fā)生異常的業(yè)務(wù)是DRB業(yè)務(wù)時(shí)，所述錯(cuò)誤處理單元向核心 網(wǎng)發(fā)送ERAB釋放指示，指示該DRB業(yè)務(wù)的相應(yīng)資源需要釋放，而后eNB與核心網(wǎng)進(jìn)行各自 的資源釋放。
全文摘要
本發(fā)明公開(kāi)了一種LTE系統(tǒng)中錯(cuò)誤指示的處理方法和裝置。所述處理方法包括(1)eNB用戶面檢測(cè)到錯(cuò)誤發(fā)生時(shí)，向eNB控制面發(fā)送錯(cuò)誤指示，其中包含錯(cuò)誤原因和業(yè)務(wù)識(shí)別信息；(2)eNB控制面收到eNB用戶面發(fā)來(lái)的錯(cuò)誤指示后，根據(jù)業(yè)務(wù)識(shí)別信息判斷出發(fā)生異常的業(yè)務(wù)類型，然后進(jìn)行相應(yīng)處理。所述處理裝置包括eNB用戶面模塊和eNB控制面模塊。本發(fā)明區(qū)分了發(fā)生異常的業(yè)務(wù)是SRB業(yè)務(wù)還是DRB業(yè)務(wù)，并相應(yīng)地提供了合理的處理方式，對(duì)不能正常運(yùn)行的業(yè)務(wù)及時(shí)予以資源釋放，避免了資源的浪費(fèi)或不當(dāng)釋放，保證了eNB的正常運(yùn)行，提高了用戶的使用滿意度。
文檔編號(hào)H04L1/16GK102036261SQ200910177268
公開(kāi)日2011年4月27日 申請(qǐng)日期2009年9月28日 優(yōu)先權(quán)日2009年9月28日
發(fā)明者梁潔 申請(qǐng)人:中興通訊股份有限公司