用于umts網(wǎng)絡(luò)中的信令釋放原因指示的方法和系統(tǒng)的制作方法
【專利摘要】一種在用戶設(shè)備和無線網(wǎng)絡(luò)之間處理信令釋放指示原因的方法和系統(tǒng)，所述方法包括步驟：在用戶設(shè)備處監(jiān)視是否應(yīng)當(dāng)向所述無線網(wǎng)絡(luò)發(fā)送信令連接釋放指示；在用戶設(shè)備處將用于所述信令連接釋放指示的原因添加到所述信令連接釋放指示；將所添加的信令連接釋放指示發(fā)送到所述無線網(wǎng)絡(luò)；在所述無線網(wǎng)絡(luò)處接收所述信令連接釋放指示；以及過濾所述原因來確定是否產(chǎn)生告警。
【專利說明】用于UMTS網(wǎng)絡(luò)中的信令釋放原因指示的方法和系統(tǒng)
[0001]本申請(qǐng)是申請(qǐng)?zhí)枮椤?00710137906.8”，申請(qǐng)日為2007年5月16日，發(fā)明名稱為“用于UMTS網(wǎng)絡(luò)中的信令釋放原因指示的方法和系統(tǒng)”之申請(qǐng)的分案申請(qǐng)。
【技術(shù)領(lǐng)域】
[0002]本申請(qǐng)涉及在用戶設(shè)備(UE)和通用陸地?zé)o線接入網(wǎng)絡(luò)(UTRAN)之間的無線電資源控制，具體地，涉及UMTS網(wǎng)絡(luò)中現(xiàn)有信令連接的釋放。
【背景技術(shù)】
[0003]通用移動(dòng)電信系統(tǒng)(UMTS)是用來傳輸文本、數(shù)字語音、視頻和多媒體的基于分組的寬帶系統(tǒng)。它高度支持第三代標(biāo)準(zhǔn)，并通?；趯拵Тa分多址(W-CDMA)。
[0004]在UMTS網(wǎng)絡(luò)中，協(xié)議棧的無線電資源控制(RRC)部分負(fù)責(zé)UE和UTRAN之間無線電資源的分配、配置和釋放。該RRC協(xié)議在3GPP TS25.331規(guī)范中有詳細(xì)描述。UE可以處于的兩種基本模式被定義為“空閑模式”和“UTRA連接模式”。UTRA代表UMTS地面無線接入。在空閑模式下，無論何時(shí)UE想發(fā)送任何用戶數(shù)據(jù)、或者響應(yīng)無論何時(shí)UTRAN或GPRS服務(wù)支持節(jié)點(diǎn)(SGSN)對(duì)UE的尋呼以從外部數(shù)據(jù)網(wǎng)絡(luò)(如推送服務(wù)器)接收數(shù)據(jù)，都需要UE請(qǐng)求RRC連接。在3GPP規(guī)范TS25.304和TS25.331中詳細(xì)描述了空閑和連接模式行為。
[0005]當(dāng)處于UTRA RRC連接模式時(shí)，設(shè)備可以處于四種狀態(tài)中的一種狀態(tài)。這四種狀態(tài)是:
[0006]CELL-DCH:在該狀態(tài)下，給UE在上行和下行鏈路上分配專用信道來交換數(shù)據(jù)。UE必須執(zhí)行如在3GPP25.331中概述的動(dòng)作。
[0007]CELL_FACH:在該狀態(tài)下，不給用戶設(shè)備分配專用信道。相反，使用公共信道來交換少量的突發(fā)數(shù)據(jù)。UE必須執(zhí)行如在3GPP25.331中概述的動(dòng)作，這包括在3GPP TS25.304中定義的小區(qū)選擇過程。
[0008]CELL_PCH:UE使用不連續(xù)接收(DRX)來監(jiān)視廣播消息，并通過尋呼指示符信道(PICH)進(jìn)行尋呼?？梢詻]有上行鏈路活動(dòng)。UE必須執(zhí)行在3GPP25.331中概述的操作，這包括在3GPP TS25.304中定義的小區(qū)選擇過程。在小區(qū)選擇之后，UE必須執(zhí)行CELL UPDATE過程。
[0009]URA_PCH:UE使用不連續(xù)接收(DRX)來監(jiān)視廣播消息，并通過尋呼指示符信道(PICH)進(jìn)行尋呼?？梢詻]有上行鏈路活動(dòng)。UE必須執(zhí)行在3GPP25.331中概述的操作，這包括在3GPP TS25.304中定義的小區(qū)選擇過程。除了 URA UPDATE過程僅僅通過UTRAN注冊(cè)區(qū)域(URA)重選來觸發(fā)之外，該狀態(tài)與CELL_PCH相類似。
[0010]從空閑模式到連接模式及從連接模式到空閑模式的轉(zhuǎn)換都是由UTRAN控制的。當(dāng)空閑模式UE請(qǐng)求RRC連接時(shí)，網(wǎng)絡(luò)決定是將UE轉(zhuǎn)移到CELL_DCH狀態(tài)還是CELL_FACH狀態(tài)。當(dāng)UE處于RRC連接模式時(shí)，網(wǎng)絡(luò)再次決定何時(shí)釋放該RRC連接。在釋放該連接之前或在作為釋放該連接的替代的某些情況下，網(wǎng)絡(luò)還可以將UE從一種RRC狀態(tài)轉(zhuǎn)移到另一種RRC狀態(tài)。這種狀態(tài)轉(zhuǎn)換典型地是由UE和網(wǎng)絡(luò)之間的數(shù)據(jù)活動(dòng)或不活動(dòng)來觸發(fā)的。由于網(wǎng)絡(luò)可能不知道對(duì)于給定應(yīng)用來說UE何時(shí)完成數(shù)據(jù)交換，因此典型地，網(wǎng)絡(luò)保持RRC連接一段時(shí)間，以預(yù)期去往/來自UE的更多數(shù)據(jù)。這樣做典型地降低了呼叫建立以及后續(xù)無線電承載建立的等待時(shí)間。所述RRC連接釋放消息只能由UTRAN發(fā)送。該消息釋放了 UE和UTRAN之間的信號(hào)鏈路連接和所有無線電承載。
[0011]上述問題在于，即使UE上的應(yīng)用程序已經(jīng)完成其數(shù)據(jù)處理并且不期望任何進(jìn)一步的數(shù)據(jù)交換，它仍然等待網(wǎng)絡(luò)將其轉(zhuǎn)移到正確的狀態(tài)。網(wǎng)絡(luò)可能甚至沒有意識(shí)到UE上的應(yīng)用程序已經(jīng)完成其數(shù)據(jù)交換的事實(shí)。例如，UE上的應(yīng)用程序可以使用其自身的基于確認(rèn)的協(xié)議來與連接到UMTS核心網(wǎng)的應(yīng)用服務(wù)器交換數(shù)據(jù)。這種示例的應(yīng)用程序運(yùn)行在UDP /IP上來實(shí)現(xiàn)它們自身的有保證的傳送。在這種情況下，UE知道應(yīng)用服務(wù)器是否已經(jīng)發(fā)送或接收了所有數(shù)據(jù)分組，并且更好地確定是否會(huì)發(fā)生任何進(jìn)一步的數(shù)據(jù)交換，從而決定何時(shí)終止與分組業(yè)務(wù)(PS)域相關(guān)聯(lián)的RRC連接。由于UTRAN控制RRC連接的狀態(tài)何時(shí)變化為不同的狀態(tài)或變化到空閑模式，以及UTRAN不知道UE和外部服務(wù)器之間的數(shù)據(jù)傳送狀態(tài)的事實(shí)，所以UE被迫停留在比其所需的狀態(tài)或模式高的數(shù)據(jù)速率和更強(qiáng)的電池狀態(tài)，從而耗盡了電池壽命。由于不必要地保持占用無線電承載資源，這也導(dǎo)致了網(wǎng)絡(luò)資源的浪費(fèi)。
[0012]解決上述問題的一種方案是讓UE在它認(rèn)識(shí)到完成數(shù)據(jù)處理時(shí)向UTRAN發(fā)送信令釋放指示。依照3GPP TS25.331規(guī)范第8.1.14.3節(jié)，UTRAN 一旦從UE接收到信令釋放指示，就可以釋放該信令連接，從而使得UE轉(zhuǎn)換到空閑模式。上述方案的問題在于，所述信令釋放指示有可能被認(rèn)為是告警。典型地，網(wǎng)絡(luò)只有在發(fā)生GMM業(yè)務(wù)請(qǐng)求失敗、RAU失敗或附著失敗時(shí)才期望信令釋放指示。UE請(qǐng)求信令釋放時(shí)告警的產(chǎn)生導(dǎo)致了網(wǎng)絡(luò)中無效的性能監(jiān)視和告警監(jiān)視。

【發(fā)明內(nèi)容】

[0013]因此，本申請(qǐng)?zhí)峁┝艘环N用于處理在用戶設(shè)備和無線網(wǎng)絡(luò)之間的信令釋放指示原因的方法，包括步驟:在用戶設(shè)備處監(jiān)視是否應(yīng)當(dāng)向無線網(wǎng)絡(luò)發(fā)送信令連接釋放指示；在用戶設(shè)備處，將信令連接釋放指示的原因添加到信令連接釋放指示中；將所添加的信令連接釋放指示發(fā)送到無線網(wǎng)絡(luò)；在無線網(wǎng)絡(luò)處接收所述信令連接釋放指示；以及過濾所述原因來確定是否產(chǎn)生告警。
[0014]本申請(qǐng)還提供了一種適于處理信令釋放指示原因的系統(tǒng)，該系統(tǒng)包括:用戶設(shè)備，該用戶設(shè)備具有:無線電子系統(tǒng)，包括適于與UMTS網(wǎng)絡(luò)通信的無線電設(shè)備；無線電處理器，具有數(shù)字信號(hào)處理器，并適于與所述無線電子系統(tǒng)交互；存儲(chǔ)器；用戶接口 ；處理器，適于運(yùn)行用戶應(yīng)用程序并與存儲(chǔ)器、無線電設(shè)備和用戶接口交互、以及適于運(yùn)行應(yīng)用程序，所述用戶設(shè)備的特征在于具有裝置，用于:監(jiān)視是否應(yīng)當(dāng)向無線網(wǎng)絡(luò)發(fā)送信令連接釋放指示；將用于信令連接釋放指示的原因添加到所述信令連接釋放指示；以及將所添加的信令連接釋放指示發(fā)送到所述無線網(wǎng)絡(luò)；以及適用于與所述用戶設(shè)備通信的無線網(wǎng)絡(luò)，所述無線網(wǎng)絡(luò)進(jìn)一步的特征在于:裝置，用于接收所述信令連接釋放指示；以及過濾所述原因以確定是否產(chǎn)生告警。
[0015]本申請(qǐng)還提供了一種在用戶設(shè)備上處理信令釋放指示原因以改進(jìn)無線網(wǎng)絡(luò)處的告警跟蹤的方法，該方法包括步驟:監(jiān)視是否應(yīng)當(dāng)向無線網(wǎng)絡(luò)發(fā)送信令連接釋放指示；將用于信令連接釋放指示的原因添加到信令連接釋放指示；以及將所添加的信令連接釋放指示發(fā)送到無線網(wǎng)絡(luò)，其中，所述無線網(wǎng)絡(luò)具有所述信令連接釋放指示原因的指示。
[0016]本申請(qǐng)還提供了一種便于用戶設(shè)備釋放信令連接的裝置。檢查器配置用來檢查是否應(yīng)當(dāng)發(fā)送信令連接釋放指示。信令連接釋放指示發(fā)送器配置用來響應(yīng)檢查器的應(yīng)當(dāng)發(fā)送所述信令連接釋放指示的指示，來發(fā)送信令連接釋放指示。所述信令連接釋放指示包括信令釋放指示原因字段。
[0017]本申請(qǐng)還提供了 一種用來針對(duì)信令連接釋放指示進(jìn)行操作的網(wǎng)絡(luò)裝置。檢驗(yàn)器配置用于檢驗(yàn)信令連接釋放指示的信令釋放指示原因字段。該檢驗(yàn)器檢查所述信令釋放指示原因字段是否指示異常狀況。告警發(fā)生器配置用來:如果檢驗(yàn)器的檢驗(yàn)確定了所述信令釋放指示原因字段指示異常狀況，則可選擇地產(chǎn)生告警。
[0018]本申請(qǐng)還提供了一種用戶設(shè)備，適于在UMTS網(wǎng)絡(luò)中提供信令釋放指示原因，所述用戶設(shè)備具有:無線電子系統(tǒng)，包括適于與UMTS網(wǎng)絡(luò)通信的無線電設(shè)備；無線處理器，具有數(shù)字信號(hào)處理器并適于與所述無線電子系統(tǒng)交互；存儲(chǔ)器；用戶接口 ；處理器，適于運(yùn)行用戶應(yīng)用程序并與存儲(chǔ)器、無線電設(shè)備和用戶接口交互、以及適于運(yùn)行應(yīng)用程序，所述用戶設(shè)備的特征在于具有:裝置，用于監(jiān)視是否應(yīng)當(dāng)向無線網(wǎng)絡(luò)發(fā)送信令連接釋放指示；將用于信令連接釋放指示的原因添加到所述信令連接釋放指示中；以及將所添加的信令連接釋放指示發(fā)送到無線網(wǎng)絡(luò)，其中，所述無線網(wǎng)絡(luò)具有信令連接釋放指示原因的指示。
【專利附圖】

【附圖說明】
[0019]將參考附圖來更好地理解本申請(qǐng)，其中:
[0020]圖1是顯示RRC狀態(tài)和轉(zhuǎn)換的框圖；
[0021]圖2是顯示各種UMTS小區(qū)和URA的UMTS網(wǎng)絡(luò)的示意圖；
[0022]圖3是顯示RRC連接建立過程各個(gè)階段的框圖；
[0023]圖4A是由UTRAN根據(jù)當(dāng)前方法啟動(dòng)的在CELL_DCH連接模式狀態(tài)和空閑模式之間的典型轉(zhuǎn)換的框圖；
[0024]圖4B是顯示使用信令釋放指示在CELL_DCH狀態(tài)連接模式轉(zhuǎn)換到空閑模式的典型轉(zhuǎn)換的框圖；
[0025]圖5A是由UTRAN啟動(dòng)的在CELL_DCH不活動(dòng)到CELL_FACH不活動(dòng)到空閑模式轉(zhuǎn)換的典型轉(zhuǎn)換的框圖；
[0026]圖5B是使用信令釋放指示在CELL_DCH不活動(dòng)和空閑模式之間的典型轉(zhuǎn)換的框圖；
[0027]圖6是UMTS協(xié)議棧的框圖；
[0028]圖7是可以與本方法結(jié)合使用的典型UE ；
[0029]圖8是與本方法和系統(tǒng)結(jié)合使用的典型網(wǎng)絡(luò)；
[0030]圖9是顯示在UE處增加用于信令連接釋放指示原因的步驟的流程圖；以及
[0031]圖10是顯示了 UE接收到具有原因的信令連接釋放指示時(shí)所采取的步驟的流程圖。
【具體實(shí)施方式】
[0032]本系統(tǒng)和方法提供了從RRC連接模式轉(zhuǎn)換到電池更有效狀態(tài)或模式的系統(tǒng)和方法，同時(shí)在信令釋放指示的原因是UE空閑轉(zhuǎn)換請(qǐng)求時(shí)，確保了網(wǎng)絡(luò)不會(huì)將信令釋放指示視為告警。具體地，本方法和裝置提供了轉(zhuǎn)換，所述轉(zhuǎn)換基于UE啟動(dòng)對(duì)于特定核心網(wǎng)絡(luò)域的信令連接終止、或者指示UTRAN應(yīng)當(dāng)發(fā)生從一種連接狀態(tài)至另一種狀態(tài)的轉(zhuǎn)換。下面將根據(jù)UMTS的典型實(shí)現(xiàn)方式進(jìn)行描述。然而，應(yīng)該明白，本發(fā)明的教導(dǎo)類似地可應(yīng)用于其它無線電通信系統(tǒng)。
[0033]具體地，如果UE上的應(yīng)用程序確定處理數(shù)據(jù)交換，那么它可以將“完成”指示發(fā)送到UE軟件的“RRC連接管理器“組件。RRC連接管理器跟蹤所有的現(xiàn)有應(yīng)用程序(包括在一個(gè)或多個(gè)協(xié)議上提供業(yè)務(wù)的那些應(yīng)用程序)、關(guān)聯(lián)分組數(shù)據(jù)協(xié)議(TOP)上下文、關(guān)聯(lián)分組交換(PS)無線電承載和關(guān)聯(lián)電路交換(CS)無線電承載。PDP上下文是運(yùn)行在UMTS核心網(wǎng)絡(luò)上的UE和H)N(公共數(shù)據(jù)網(wǎng)絡(luò))之間的邏輯關(guān)聯(lián)。在UE上的一個(gè)或多個(gè)應(yīng)用程序(例如，電子郵件應(yīng)用程序或?yàn)g覽器應(yīng)用程序)可以與一個(gè)PDP上下文相關(guān)聯(lián)。在某些情況下，UE上的一個(gè)應(yīng)用程序與一個(gè)基本PDP上下文相關(guān)聯(lián)，而多個(gè)應(yīng)用程序可以與第二 PDP上下文聯(lián)系在一起。RRC連接管理器從UE上同時(shí)活躍的不同應(yīng)用程序接收“完成”指示。例如，用戶可以在瀏覽網(wǎng)頁的同時(shí)從推送服務(wù)器接收電子郵件。在電子郵件應(yīng)用程序發(fā)送了確認(rèn)之后，電子郵件應(yīng)用程序指示已經(jīng)完成了數(shù)據(jù)處理，然而，瀏覽器應(yīng)用程序可能不會(huì)發(fā)送該指示?；趤碜曰钴S應(yīng)用程序的這種指示的合成狀態(tài)，UE軟件可以決定在可以啟動(dòng)核心網(wǎng)絡(luò)分組業(yè)務(wù)域的信令連接釋放之前應(yīng)該等待多久。這種情況下，可以引入延遲來確保該應(yīng)用程序真正完成數(shù)據(jù)交換并且不需要RRC連接。所述延遲可以基于業(yè)務(wù)量歷史和/或應(yīng)用程序簡檔而動(dòng)態(tài)變化。無論何時(shí)RRC連接管理器以某些可能性確定沒有應(yīng)用程序期望交換任何數(shù)據(jù)，可以發(fā)送用于合適域(例如，PS域)的信令連接釋放指示過程?？蛇x地，它可以將連接模式內(nèi)的狀態(tài)轉(zhuǎn)換請(qǐng)求發(fā)送給UTRAN。
[0034]上述決定還可以考慮網(wǎng)絡(luò)是否支持URA_PCH狀態(tài)和到該狀態(tài)的轉(zhuǎn)換行為。
[0035]UE啟動(dòng)的到空閑模式的轉(zhuǎn)換可以從RRC連接模式的任何狀態(tài)發(fā)生，并以網(wǎng)絡(luò)釋放該RRC連接并轉(zhuǎn)移到空閑模式結(jié)束。本領(lǐng)域熟練技術(shù)人員將理解，處于空閑模式的UE比處于連接狀態(tài)的UE需要少得多的電池強(qiáng)度。
[0036]然而，信令釋放指示的發(fā)送會(huì)使網(wǎng)絡(luò)認(rèn)為已發(fā)生告警。在信令釋放指示是RRC確定不期望業(yè)務(wù)量的結(jié)果的情況下，在優(yōu)選實(shí)施例中，網(wǎng)絡(luò)可以區(qū)分信令釋放指示是與異常狀況相反的所請(qǐng)求空閑轉(zhuǎn)換的結(jié)果的事實(shí)。這種區(qū)分允許諸如關(guān)鍵性能指示符(KPI)的指示符更加精確，從而改善了性能監(jiān)視和告警監(jiān)視。
[0037]本方法允許UE向現(xiàn)有信令釋放指示添加提供信令釋放指示原因的字段。然后，網(wǎng)絡(luò)可以使用所添加的字段來從由于UE不再期望進(jìn)一步的數(shù)據(jù)而請(qǐng)求進(jìn)入到空閑狀態(tài)的情形中過濾出真正的告警狀況。這提高了告警和性能監(jiān)視的效率，同時(shí)仍然允許UE通過更加迅速地轉(zhuǎn)移到空閑模式來節(jié)省電池資源。
[0038]本申請(qǐng)因此提供了一種用于處理在用戶設(shè)備和無線網(wǎng)絡(luò)之間的信令釋放指示原因的方法，包括步驟:在用戶設(shè)備處監(jiān)視是否應(yīng)當(dāng)向無線網(wǎng)絡(luò)發(fā)送信令連接釋放指示；在用戶設(shè)備處，將信令連接釋放指示的原因添加到信令連接釋放指示中；將所添加的信令連接釋放指示發(fā)送到無線網(wǎng)絡(luò)；在無線網(wǎng)絡(luò)處接收所述信令連接釋放指示；以及過濾所述原因來確定是否產(chǎn)生告警。
[0039]本申請(qǐng)還提供了一種適于處理信令釋放指示原因的系統(tǒng)，該系統(tǒng)包括:用戶設(shè)備，該用戶設(shè)備具有:無線電子系統(tǒng)，包括適于與UMTS網(wǎng)絡(luò)通信的無線電設(shè)備；無線電處理器，具有數(shù)字信號(hào)處理器，并適于與所述無線電子系統(tǒng)交互；存儲(chǔ)器；用戶接口 ；處理器，適于運(yùn)行用戶應(yīng)用程序并與存儲(chǔ)器、無線電設(shè)備和用戶接口交互、以及適于運(yùn)行應(yīng)用程序，所述用戶設(shè)備的特征在于具有裝置，用于:監(jiān)視是否應(yīng)當(dāng)向無線網(wǎng)絡(luò)發(fā)送信令連接釋放指示；將用于信令連接釋放指示的原因添加到所述信令連接釋放指示；以及將所添加的信令連接釋放指示發(fā)送到所述無線網(wǎng)絡(luò)；以及適用于與所述用戶設(shè)備通信的無線網(wǎng)絡(luò)，所述無線網(wǎng)絡(luò)進(jìn)一步的特征在于:裝置，用于接收所述信令連接釋放指示；以及過濾所述原因以確定是否產(chǎn)生告警。
[0040]本申請(qǐng)還提供了一種在用戶設(shè)備上處理信令釋放指示原因以改進(jìn)無線網(wǎng)絡(luò)處的告警跟蹤的方法，該方法包括步驟:監(jiān)視是否應(yīng)當(dāng)向無線網(wǎng)絡(luò)發(fā)送信令連接釋放指示；將用于信令連接釋放指示的原因添加到信令連接釋放指示；以及將所添加的信令連接釋放指示發(fā)送到無線網(wǎng)絡(luò)，其中，所述無線網(wǎng)絡(luò)具有所述信令連接釋放指示原因的指示。
[0041]本申請(qǐng)還提供了一種便于用戶設(shè)備釋放信令連接的裝置。檢查器配置用來檢查是否應(yīng)當(dāng)發(fā)送信令連接釋放指示。信令連接釋放指示發(fā)送器配置用來響應(yīng)檢查器的應(yīng)當(dāng)發(fā)送所述信令連接釋放指示的指示，來發(fā)送信令連接釋放指示。所述信令連接釋放指示包括信令釋放指示原因字段。
[0042]本申請(qǐng)還提供了 一種用來基于信令連接釋放指示進(jìn)行操作的網(wǎng)絡(luò)裝置。檢驗(yàn)器配置用于檢驗(yàn)信令連接釋放指示的信令釋放指示原因字段。該檢驗(yàn)器檢查所述信令釋放指示原因字段是否指示異常狀況。告警發(fā)生器配置用來:如果檢驗(yàn)器的檢驗(yàn)確定了所述信令釋放指示原因字段指示異常狀況，則可選擇地產(chǎn)生告警。
[0043]本申請(qǐng)還提供了一種用戶設(shè)備，適于在UMTS網(wǎng)絡(luò)中提供信令釋放指示原因，所述用戶設(shè)備具有:無線電子系統(tǒng)，包括適于與UMTS網(wǎng)絡(luò)通信的無線電設(shè)備；無線處理器，具有數(shù)字信號(hào)處理器并適于與所述無線電子系統(tǒng)交互；存儲(chǔ)器；用戶接口 ；處理器，適于運(yùn)行用戶應(yīng)用程序并與存儲(chǔ)器、無線電設(shè)備和用戶接口交互、以及適于運(yùn)行應(yīng)用程序，所述用戶設(shè)備的特征在于具有:裝置，用于監(jiān)視是否應(yīng)當(dāng)向無線網(wǎng)絡(luò)發(fā)送信令連接釋放指示；將用于信令連接釋放指示的原因添加到所述信令連接釋放指示中；以及將所添加的信令連接釋放指示發(fā)送到無線網(wǎng)絡(luò)，其中，所述無線網(wǎng)絡(luò)具有信令連接釋放指示原因的指示。
[0044]現(xiàn)在參考圖1。圖1是表示UMTS網(wǎng)絡(luò)中協(xié)議棧的無線電資源控制部分的各種模式和狀態(tài)的框圖。具體地，RRC可以處于RRC空閑狀態(tài)110或RRC連接狀態(tài)120。
[0045]本領(lǐng)域普通技術(shù)人員將理解，UMTS網(wǎng)絡(luò)由兩種基于陸地的網(wǎng)絡(luò)段構(gòu)成。它們是核心網(wǎng)(CN)和通用陸地?zé)o線接入網(wǎng)(UTRAN)(如圖8所示)。核心網(wǎng)負(fù)責(zé)數(shù)據(jù)呼叫的交換和路由以及到外部網(wǎng)絡(luò)的數(shù)據(jù)連接，而UTRAN處理所有的無線電相關(guān)功能。
[0046]在空閑模式110，無論何時(shí)需要在UE和網(wǎng)絡(luò)之間交換數(shù)據(jù)，UE都必須請(qǐng)求RRC連接來建立無線電資源。這可以是UE上的應(yīng)用程序請(qǐng)求連接來發(fā)送數(shù)據(jù)的結(jié)果，或者是UE監(jiān)視尋呼信道以指示UTRAN或SGSN是否已經(jīng)尋呼UE來從諸如推送服務(wù)器的外部數(shù)據(jù)網(wǎng)絡(luò)接收數(shù)據(jù)的結(jié)果。此外，UE還在任何需要發(fā)送諸如位置區(qū)域更新的移動(dòng)性管理信令消息的時(shí)候請(qǐng)求RRC連接。
[0047]一旦UE已經(jīng)發(fā)送請(qǐng)求給UTRAN來建立無線電連接，UTRAN就選擇將要處于的RRC連接狀態(tài)。具體來說，RRC連接模式120包括四個(gè)獨(dú)立狀態(tài)。它們是CELL_DCH狀態(tài)122，CELL_FACH 狀態(tài) 124、CELL_PCH 狀態(tài) 126 和 URA_PCH 狀態(tài) 128。
[0048]從空閑模式110，RRC連接狀態(tài)可以進(jìn)入小區(qū)專用信道(CELL_DCH)狀態(tài)122，或者可以進(jìn)入小區(qū)前向接入信道(CELL_FACH)狀態(tài)124。
[0049]在CELL_DCH狀態(tài)122，給UE的上行和下行鏈路分配專用信道以交換數(shù)據(jù)。由于該狀態(tài)具有分配給UE的專用物理信道，因此，該狀態(tài)典型地從UE需要最多的電池功率。
[0050]可選地，UTRAN可以從空閑模式110轉(zhuǎn)移到CELL_FACH狀態(tài)124。在CELL_FACH狀態(tài)，不給UE分配專用信道。相反，使用公共信道以少量突發(fā)數(shù)據(jù)來發(fā)送信令。然而，UE仍然不得不繼續(xù)監(jiān)視FACH，因此消耗電池功率。
[0051]在RRC連接模式120內(nèi)，RRC狀態(tài)可以在UTRAN的判斷下進(jìn)行改變。具體來說，如果在特定的時(shí)間量內(nèi)沒有檢測(cè)到數(shù)據(jù)活動(dòng)、或者檢測(cè)到數(shù)據(jù)吞吐量低于某一閾值，那么UTRAN可以將RRC狀態(tài)從CELL_DCH狀態(tài)122轉(zhuǎn)移到CELL_FACH狀態(tài)124、CELL_PCH狀態(tài)126或URA_PCH狀態(tài)128。類似地，如果檢測(cè)到有效載荷超過特定閾值，那么RRC狀態(tài)可以從CELL_FACHl24 轉(zhuǎn)移到 CELL_DCH122。
[0052]從CELL_FACH狀態(tài)124，如果在一些網(wǎng)絡(luò)中的特定時(shí)間內(nèi)沒有檢測(cè)到數(shù)據(jù)活動(dòng)，那么UTRAN可以將RRC狀態(tài)從CELL_FACH狀態(tài)124轉(zhuǎn)移到尋呼信道(PCH)狀態(tài)。這可以是CELL_PCH 狀態(tài) 126 或 URA_PCH 狀態(tài) 128。
[0053]從CELL_PCH 狀態(tài) 126 或 URA_PCH 狀態(tài) 128，UE 必須轉(zhuǎn)移到 CELL_FACH 狀態(tài) 124，以便啟動(dòng)更新過程來請(qǐng)求專用信道。這是UE控制的唯一狀態(tài)轉(zhuǎn)換。
[0054]CELL_PCH狀態(tài)126和URA_PCH狀態(tài)128使用不連續(xù)接收周期(DRX)來監(jiān)視廣播消息，并通過尋呼指示符信道(PICH)進(jìn)行尋呼?？梢詻]有上行鏈路活動(dòng)。
[0055]CELL_PCH狀態(tài)126和URA_PCH狀態(tài)128之間的不同在于，如果UE當(dāng)前的UTRAN注冊(cè)區(qū)域(URA)并非處于當(dāng)前小區(qū)中呈現(xiàn)的URA標(biāo)識(shí)列表中，那么URA_PCH狀態(tài)只觸發(fā)URA更新過程。具體來說，參考圖2，圖2顯示了不同UMTS小區(qū)210、212和214的示意圖。如果重新選擇到CELL_PCH狀態(tài)，那么所有這些小區(qū)都需要小區(qū)更新過程。然而，在UTRAN注冊(cè)區(qū)域內(nèi)，每個(gè)小區(qū)將處于相同的UTRAN注冊(cè)區(qū)域220內(nèi)，因此，當(dāng)在URA_PCH模式下在210、212和214之間移動(dòng)時(shí)不觸發(fā)URA更新過程。
[0056]從圖2中可以看出，其他小區(qū)218處于URA220的外部，并且可以是單獨(dú)的URA或者非URA的一部分。
[0057]本領(lǐng)域熟練技術(shù)人員將明白，從電池壽命考慮，與上面的狀態(tài)相比，空閑狀態(tài)提供最低的電池使用。具體來說，由于UE只需間隔地監(jiān)視尋呼信道，因此無線電設(shè)備并不需要連續(xù)處于打開狀態(tài)，但是需要周期性地喚醒。對(duì)此的折中是延遲發(fā)送數(shù)據(jù)。然而，如果這種延遲不是太大，那么處于空閑模式以及節(jié)省電池電量的優(yōu)點(diǎn)將超過連接延遲的缺點(diǎn)。
[0058]再次參考圖1。不同的UMTS基礎(chǔ)運(yùn)營商基于不同的標(biāo)準(zhǔn)在狀態(tài)122、124、126和128之間轉(zhuǎn)移。下面概述典型的基礎(chǔ)結(jié)構(gòu)。
[0059]在第一典型基礎(chǔ)結(jié)構(gòu)中，RRC直接在空閑模式和Cell_DCH狀態(tài)之間轉(zhuǎn)移。在Cell_DCH狀態(tài)下，如果檢測(cè)到兩秒中沒有活動(dòng)，RRC狀態(tài)就改變到Cell_FACH狀態(tài)124。如果，在Cell_FACH狀態(tài)124中檢測(cè)到10秒鐘沒有活動(dòng)，那么RRC狀態(tài)就改變到PCH狀態(tài)126。在Cell_PCH狀態(tài)126中沒有活動(dòng)達(dá)到45分鐘將導(dǎo)致RRC狀態(tài)返回到空閑模式110。
[0060]在第二典型基礎(chǔ)結(jié)構(gòu)中，RRC轉(zhuǎn)換可以依據(jù)有效載荷閾值在空閑模式110和連接模式120之間發(fā)生。在第二基礎(chǔ)結(jié)構(gòu)中，如果有效載荷低于特定閾值，那么UTRAN就將RRC狀態(tài)轉(zhuǎn)移到CELL_FACH狀態(tài)124。相反，如果數(shù)據(jù)超過特定有效載荷閾值，那么UTRAN就將RRC狀態(tài)轉(zhuǎn)移到CELL_DCH狀態(tài)122。在第二基礎(chǔ)結(jié)構(gòu)中，如果在CELL_DCH狀態(tài)122檢測(cè)到兩分鐘沒有活動(dòng)，那么UTRAN就將RRC狀態(tài)轉(zhuǎn)移到CELL_FACH狀態(tài)124。在CELL_FACH狀態(tài)124中5分鐘沒有活動(dòng)之后，UTRAN就將RRC階段轉(zhuǎn)移到CELL_PCH狀態(tài)126。在CELL_PCH狀態(tài)126，在返回到空閑模式110之前，需要兩個(gè)小時(shí)不活動(dòng)。
[0061]在第三典型基礎(chǔ)結(jié)構(gòu)中，空閑模式和連接模式120之間的轉(zhuǎn)移總是轉(zhuǎn)移到CELL_DCH狀態(tài)122。在CELL_DCH狀態(tài)122中5秒鐘沒有活動(dòng)之后，UTRAN將RRC狀態(tài)轉(zhuǎn)移到CELL_FACH狀態(tài)124。在CELL_FACH狀態(tài)124中30秒不活動(dòng)將導(dǎo)致返回到空閑模式110。
[0062]在第四典型基礎(chǔ)結(jié)構(gòu)中，RRC從空閑模式到連接模式直接轉(zhuǎn)換成CELL_DCH狀態(tài)122。在第四典型基礎(chǔ)結(jié)構(gòu)中，CELL_DCH狀態(tài)122包括兩個(gè)子狀態(tài)。第一子狀態(tài)包括具有高數(shù)據(jù)速率的子狀態(tài)，第二子狀態(tài)包括較低的數(shù)據(jù)速率，但是仍然處于CELL_DCH狀態(tài)內(nèi)。在第四典型基礎(chǔ)結(jié)構(gòu)中，RRC從空閑模式110直接轉(zhuǎn)換到高數(shù)據(jù)速率的CELL_DCH子狀態(tài)。在10秒不活動(dòng)之后，RRC狀態(tài)轉(zhuǎn)換到低數(shù)據(jù)速率CELL_DCH狀態(tài)。從低數(shù)據(jù)CELL_DCH狀態(tài)122開始17秒沒有活動(dòng)將導(dǎo)致RRC狀態(tài)改變到空閑模式110。
[0063]上述四種典型基礎(chǔ)結(jié)構(gòu)顯示了不同UMTS基礎(chǔ)結(jié)構(gòu)廠商如何實(shí)現(xiàn)這些狀態(tài)。正如本領(lǐng)域熟練技術(shù)人員將理解的那樣，在每種情況下，如果花費(fèi)在交換實(shí)際數(shù)據(jù)(例如電子郵件)上的時(shí)間明顯比停留在CELL_DCH或CELL_FACH狀態(tài)所需的時(shí)間短，那么這將導(dǎo)致不必要的電流消耗，這將使得在諸如UMTS的更新一代網(wǎng)絡(luò)中的用戶體驗(yàn)比在諸如GPRS的現(xiàn)有網(wǎng)絡(luò)中更差。
[0064]另外，雖然從電池壽命角度來說，CELL_PCH狀態(tài)比CELL_FACH狀態(tài)更佳，但是，在CELL_PCH狀態(tài)中的DRX周期典型地被設(shè)定為比空閑模式110更低的值。因此，在CELL_PCH狀態(tài)下，需要比在空閑模式下更頻繁地喚醒UE。
[0065]具有與空閑狀態(tài)的DRX周期類似的DRX周期的URA_PCH狀態(tài)可能是電池壽命和連接延遲之間的最佳折中。然而，目前在UTRAN中并不支持URA_PCH。因此，從電池壽命角度考慮，在完成數(shù)據(jù)交換的應(yīng)用程序之后，希望能夠盡可能快地轉(zhuǎn)換到空閑模式。
[0066]現(xiàn)在參考圖3。當(dāng)從空閑模式轉(zhuǎn)換到連接模式時(shí)，需要作出各種信令和數(shù)據(jù)連接。參考圖3，需要執(zhí)行的第一項(xiàng)是RRC連接建立。如上所述，該RRC連接建立只能由UTRAN拆斷。
[0067]一旦完成RRC連接建立310，就開始信令連接建立312。
[0068]一旦完成信令建立312，就開始加密和完整性建立314。一旦完成這些，也就完成了無線承載建立316。此時(shí)，可以在UE和UTRAN之間交換數(shù)據(jù)。
[0069]通常，類似以相反的順序來完成拆斷連接。拆斷無線承載建立316，然后拆斷RRC連接建立310。此時(shí)，RRC轉(zhuǎn)移到空閑模式110，如圖1所示那樣。
[0070]雖然目前的3GPP規(guī)范并不允許UE釋放RRC連接或指示它對(duì)于RRC狀態(tài)的偏好，但是對(duì)于諸如分組交換應(yīng)用程序使用的分組交換(PS)域之類的特定核心網(wǎng)絡(luò)域來說，UE還是可以指示信令連接的終止。根據(jù)3GPP TS25.331的第8.1.14.1節(jié)，由UE使用信令連接釋放指示過程來指示UTRAN已經(jīng)釋放其信令連接中的其中一個(gè)。該過程也可以進(jìn)而啟動(dòng)RRC連接釋放過程。[0071]因此，停留在目前的3GPP規(guī)范內(nèi)，可以基于信令連接建立312的拆斷來啟動(dòng)信令連接釋放。拆斷信令連接建立312是UE的能力之內(nèi)的事情，因此，根據(jù)該規(guī)范，這進(jìn)而“可以”啟動(dòng)RRC連接釋放。
[0072]正如本領(lǐng)域普通技術(shù)人員應(yīng)當(dāng)理解到的那樣，如果信令連接建立312被拆斷，那么UTRAN在拆斷了信令連接建立312之后，將會(huì)需要清除解密和完整性建立312、無線承載建立316。
[0073]如果信令連接建立312被拆斷，那么典型地由當(dāng)前廠商基礎(chǔ)結(jié)構(gòu)的網(wǎng)絡(luò)來拆斷RRC連接建立。
[0074]通過使用上面的過程，如果UE確定其處理數(shù)據(jù)交換，例如，如果向UE軟件的“RRC連接管理器”組件提供了交換數(shù)據(jù)完成的指示，那么RRC連接管理器可以確定是否拆斷信令連接建立312。例如，在設(shè)備上的電子郵件應(yīng)用程序發(fā)送以下指示:它已經(jīng)從推送郵件服務(wù)器接收了所述電子郵件確實(shí)由推送服務(wù)器接收到的確認(rèn)。RRC管理器可以跟蹤所有現(xiàn)有的應(yīng)用程序、關(guān)聯(lián)的PDP上下文、關(guān)聯(lián)的PS無線電承載和關(guān)聯(lián)的電路交換(CS)無線電承載。在此情況下，可以引入延遲來確保應(yīng)用程序真正完成了數(shù)據(jù)交換，而且甚至在已經(jīng)發(fā)送了“完成”指示之后，不再需要RRC連接。這種延遲等同于與應(yīng)用程序相關(guān)聯(lián)的不活動(dòng)超時(shí)。每個(gè)應(yīng)用程序都可以具有自己的不活動(dòng)超時(shí)。例如，電子郵件應(yīng)用程序可以具有5秒的不活動(dòng)超時(shí)，而處于活動(dòng)狀態(tài)的瀏覽器應(yīng)用程序可以具有60秒的超時(shí)。基于來自有效應(yīng)用程序的所有這些指示的綜合狀態(tài)，UE軟件確定在它可以啟動(dòng)適合核心網(wǎng)絡(luò)(例如PS域)的信令連接釋放之前應(yīng)當(dāng)?shù)却嗑谩?br> [0075]基于業(yè)務(wù)量模式歷史和/或應(yīng)用程序簡檔，可以使不活動(dòng)超時(shí)是動(dòng)態(tài)的。
[0076]無論何時(shí)RRC連接管理器以某些可能性確定沒有應(yīng)用程序期望交換數(shù)據(jù)，它都可以發(fā)送用于合適域的信令連接釋放指示過程。
[0077]上述由UE啟動(dòng)的到空閑模式的轉(zhuǎn)換可以在如圖1所示的RRC連接模式120的任何階段發(fā)生，并使網(wǎng)絡(luò)釋放RRC連接并以轉(zhuǎn)移到空閑模式110為結(jié)束，如圖1所示。這也可以應(yīng)用在UE在語音呼叫期間執(zhí)行任何分組數(shù)據(jù)業(yè)務(wù)時(shí)。在這種情況下，僅釋放PS域，而CS域仍保持連接。
[0078]從網(wǎng)絡(luò)觀點(diǎn)來考慮，上面的問題在于，由UE發(fā)送的信令釋放指示被解譯為告警。在信令網(wǎng)絡(luò)釋放是由于應(yīng)用程序定時(shí)器到期而不再期望數(shù)據(jù)所引起的UE的明確動(dòng)作結(jié)果的情況下，由上述指示引起的告警曲解了性能和告警指示。關(guān)鍵性能指示符可能因此而改變，從而導(dǎo)致效率降低。
[0079]優(yōu)選地，可以在信令連接釋放指示中添加原因來向UTRAN指示該指示的理由。在優(yōu)選實(shí)施例中，所述原因可以是以下指示:異常狀況引起的指示、或作為請(qǐng)求空閑轉(zhuǎn)換的結(jié)果而由UE啟動(dòng)的指示。其他正常(S卩，非異常)處理也可以導(dǎo)致信令連接釋放指示的發(fā)送。
[0080]在另一優(yōu)選實(shí)施例中，不同的超時(shí)會(huì)引起要為異常狀況發(fā)送的信令連接指示。下面定時(shí)器的示例不是獨(dú)占性的，其他定時(shí)器或異常狀況也是可以的。例如，10.2.473GPPTS24.008規(guī)定定時(shí)器T3310為:
[0081]
【權(quán)利要求】
1.一種方法，包括: 響應(yīng)于來自用戶設(shè)備“UE”的上層的對(duì)不再期望數(shù)據(jù)的指示，將信令連接釋放指示消息中的原因設(shè)置為UE請(qǐng)求分組交換“PS”數(shù)據(jù)會(huì)話結(jié)束； 使用確認(rèn)模式“AM”無線鏈路控制“RLC”在專用控制信道“DCCH”上從所述用戶設(shè)備向無線網(wǎng)絡(luò)發(fā)送信令連接釋放消息，所述信令連接釋放消息包括針對(duì)網(wǎng)絡(luò)控制轉(zhuǎn)換的原因；以及 從所述無線網(wǎng)絡(luò)接收狀態(tài)轉(zhuǎn)換消息。
2.根據(jù)權(quán)利要求1所述的方法，還包括: 確定在所述UE處沒有應(yīng)用程序期望發(fā)送或接收數(shù)據(jù)。
3.根據(jù)權(quán)利要求1所述的方法，其中，所述原因是所述信令連接釋放指示消息的信息元素。
4.根據(jù)權(quán)利要求1所述的方法，還包括: 在所述UE處從特定核心網(wǎng)絡(luò)域的上層接收釋放或中止信令連接的請(qǐng)求。
5.根據(jù)權(quán)利要求1所述的方法，其中，所述無線網(wǎng)絡(luò)包括通用陸地?zé)o線接入網(wǎng)絡(luò)“UTRAN”。
6.根據(jù)權(quán)利要求1所述的方法，其中，所述無線網(wǎng)絡(luò)是通用移動(dòng)電信系統(tǒng)“UMTS”網(wǎng)絡(luò)。
7.根據(jù)權(quán)利要求1所述的方法，其中，在用戶設(shè)備定時(shí)器到期之后發(fā)送所述信令連接釋放指示消息。
8.根據(jù)權(quán)利要求1所述的方法，其中，所述網(wǎng)絡(luò)控制轉(zhuǎn)換是從第一無線資源控制“RRC”狀態(tài)到節(jié)約電池的RRC狀態(tài)或模式的轉(zhuǎn)換。
9.根據(jù)權(quán)利要求8所述的方法，其中，所述第一RRC狀態(tài)是以下各項(xiàng)之一:小區(qū)專用信道“ CELL_DCH”狀態(tài)、小區(qū)前向接入信道“ CELL_FACH”狀態(tài)、小區(qū)尋呼信道“ CELL_PCH”狀態(tài)以及UTRAN注冊(cè)區(qū)域?qū)ず粜诺馈癠RA_PCH”狀態(tài)。
10.根據(jù)權(quán)利要求8所述的方法，其中，所述節(jié)約電池的RRC狀態(tài)或模式是以下各項(xiàng)之一:小區(qū)前向接入信道“ CELL_FACH”狀態(tài)、小區(qū)尋呼信道“ CELL_PCH”狀態(tài)、UTRAN注冊(cè)區(qū)域?qū)ず粜诺馈癠RA_PCH”狀態(tài)以及空閑模式。
11.根據(jù)權(quán)利要求1所述的方法，其中，所述指示基于來自UE應(yīng)用程序的指示的合成狀態(tài)。
12.根據(jù)權(quán)利要求1所述的方法，其中，在延遲之后執(zhí)行發(fā)送所述信令連接釋放指示消息。
13.根據(jù)權(quán)利要求12所述的方法，其中，所述延遲基于一個(gè)或多個(gè)應(yīng)用程序超時(shí)。
14.根據(jù)權(quán)利要求1所述的方法，還包括: 響應(yīng)于接收到所述狀態(tài)轉(zhuǎn)換消息，所述UE從第一無線資源控制“RRC”狀態(tài)轉(zhuǎn)換到節(jié)約電池的RRC狀態(tài)或模式。
15.根據(jù)權(quán)利要求14所述的方法，其中，所述第一RRC狀態(tài)是以下各項(xiàng)之一:小區(qū)專用信道“CELL_DCH”狀態(tài)、小區(qū)前向接入信道“CELL_FACH”狀態(tài)、小區(qū)尋呼信道“CELL_PCH”狀態(tài)以及UTRAN注冊(cè)區(qū)域?qū)ず粜诺馈癠RA_PCH”狀態(tài)。
16.根據(jù)權(quán)利要求14所述的方法，其中，所述節(jié)約電池的RRC狀態(tài)或模式是以下各項(xiàng)之一:小區(qū)前向接入信道“ CELL_FACH”狀態(tài)、小區(qū)尋呼信道“ CELL_PCH”狀態(tài)、UTRAN注冊(cè)區(qū)域?qū)ず粜诺馈癠RA_PCH”狀態(tài)以及空閑模式。
17.根據(jù)權(quán)利要求1所述的方法，其中，所述狀態(tài)轉(zhuǎn)換消息是用于從第一無線資源控制“RRC”狀態(tài)轉(zhuǎn)換到節(jié)約電池的RRC狀態(tài)或模式的消息。
18.根據(jù)權(quán)利要求17所述的方法，其中，所述第一RRC狀態(tài)是以下各項(xiàng)之一:小區(qū)專用信道“CELL_DCH”狀態(tài)、小區(qū)前向接入信道“CELL_FACH”狀態(tài)、小區(qū)尋呼信道“CELL_PCH”狀態(tài)以及UTRAN注冊(cè)區(qū)域?qū)ず粜诺馈癠RA_PCH”狀態(tài)。
19.根據(jù)權(quán)利要求17所述的方法，其中，所述節(jié)約電池的RRC狀態(tài)或模式是以下各項(xiàng)之一:小區(qū)前向接入信道“ CELL_FACH”狀態(tài)、小區(qū)尋呼信道“ CELL_PCH”狀態(tài)、UTRAN注冊(cè)區(qū)域?qū)ず粜诺馈癠RA_PCH”狀態(tài)以及空閑模式。
20.一種用戶設(shè)備“UE”，具有無線子系統(tǒng)、適于與存儲(chǔ)器、所述無線子系統(tǒng)、以及用戶界面交互的處理器，所述UE被配置為: 響應(yīng)于來自所述 UE的上層的指示，將信令連接釋放指示消息中的原因設(shè)置為UE請(qǐng)求分組交換“PS”數(shù)據(jù)會(huì)話結(jié)束； 使用確認(rèn)模式“AM”無線鏈路控制“RLC”在專用控制信道“DCCH”上向無線網(wǎng)絡(luò)發(fā)送所述信令連接釋放指示消息，所述信令連接釋放指示消息包括針對(duì)網(wǎng)絡(luò)控制轉(zhuǎn)換的原因；以及 從所述無線網(wǎng)絡(luò)接收狀態(tài)轉(zhuǎn)換消息。
21.根據(jù)權(quán)利要求20所述的UE，其中，所述UE被配置為:確定在所述UE處沒有應(yīng)用程序期望發(fā)送或接收數(shù)據(jù)。
22.根據(jù)權(quán)利要求20所述的UE，其中，所述原因是所述信令連接釋放指示消息的信息元素。
23.根據(jù)權(quán)利要求20所述的UE，還被配置為:從特定核心網(wǎng)絡(luò)域的上層接收釋放或中止信令連接的請(qǐng)求。
24.根據(jù)權(quán)利要求20所述的UE，其中，所述無線網(wǎng)絡(luò)是通用陸地?zé)o線接入網(wǎng)絡(luò)“UTRAN”。
25.根據(jù)權(quán)利要求24所述的UE，其中，所述延遲基于一個(gè)或多個(gè)應(yīng)用程序超時(shí)。
26.根據(jù)權(quán)利要求20所述的UE，其中，所述無線網(wǎng)絡(luò)是通用移動(dòng)電信系統(tǒng)“UMTS”網(wǎng)絡(luò)。
27.根據(jù)權(quán)利要求20所述的UE，其中，在用戶設(shè)備定時(shí)器到期之后發(fā)送所述信令連接釋放指示消息。
28.根據(jù)權(quán)利要求20所述的UE，其中，所述網(wǎng)絡(luò)控制轉(zhuǎn)換是從第一無線資源控制“RRC”狀態(tài)到節(jié)約電池的RRC狀態(tài)或模式的轉(zhuǎn)換。
29.根據(jù)權(quán)利要求20所述的UE，其中，所述第一RRC狀態(tài)是以下各項(xiàng)之一:小區(qū)專用信道“ CELL_DCH”狀態(tài)、小區(qū)前向接入信道“ CELL_FACH”狀態(tài)、小區(qū)尋呼信道“ CELL_PCH”狀態(tài)以及UTRAN注冊(cè)區(qū)域?qū)ず粜诺馈癠RA_PCH”狀態(tài)。
30.根據(jù)權(quán)利要求20所述的UE，其中，所述節(jié)約電池的RRC狀態(tài)或模式是以下各項(xiàng)之一:小區(qū)前向接入信道“CELL_FACH”狀態(tài)、小區(qū)尋呼信道“CELL_PCH”狀態(tài)、UTRAN注冊(cè)區(qū)域?qū)ず粜诺馈癠RA_PCH”狀態(tài)以及空閑模式。
31.根據(jù)權(quán)利要求20所述的UE，其中，所述指示基于來自UE應(yīng)用程序的指示的合成狀態(tài)。
32.根據(jù)權(quán)利要求20所述的UE，其中，在延遲之后執(zhí)行發(fā)送所述信令連接釋放指示消息。
33.根據(jù)權(quán)利要求20所述的UE，還被配置為:響應(yīng)于接收到所述狀態(tài)轉(zhuǎn)換消息，從第一無線資源控制“RRC”狀態(tài)轉(zhuǎn)換到節(jié)約電池的RRC狀態(tài)或模式。
34.根據(jù)權(quán)利要求33所述的UE，其中，所述第一RRC狀態(tài)是以下各項(xiàng)之一:小區(qū)專用信道“ CELL_DCH”狀態(tài)、小區(qū)前向接入信道“ CELL_FACH”狀態(tài)、小區(qū)尋呼信道“ CELL_PCH”狀態(tài)以及UTRAN注冊(cè)區(qū)域?qū)ず粜诺馈癠RA_PCH”狀態(tài)。
35.根據(jù)權(quán)利要求33所述的UE，其中，所述節(jié)約電池的RRC狀態(tài)或模式是以下各項(xiàng)之一:小區(qū)前向接入信道“CELL_FACH”狀態(tài)、小區(qū)尋呼信道“CELL_PCH”狀態(tài)、UTRAN注冊(cè)區(qū)域?qū)ず粜诺馈癠RA_PCH”狀態(tài)以及空閑模式。
36.根據(jù)權(quán)利要求20所述的UE，其中，所述狀態(tài)轉(zhuǎn)換消息是用于從第一無線資源控制“RRC”狀態(tài)轉(zhuǎn)換到節(jié)約電池的RRC狀態(tài)或模式的消息。
37.根據(jù)權(quán)利要求36所述的UE，其中，所述第一RRC狀態(tài)是以下各項(xiàng)之一:小區(qū)專用信道“ CELL_DCH”狀態(tài)、小區(qū)前向接入信道“ CELL_FACH”狀態(tài)、小區(qū)尋呼信道“ CELL_PCH”狀態(tài)以及UTRAN注冊(cè)區(qū)域?qū)ず粜诺馈癠RA_PCH”狀態(tài)。
38.根據(jù)權(quán)利要求36所述的UE，其中，所述節(jié)約電池的RRC狀態(tài)或模式是以下各項(xiàng)之一:小區(qū)前向接入信道“ CELL_FACH”狀態(tài)、小區(qū)尋呼信道“ CELL_PCH”狀態(tài)、UTRAN注冊(cè)區(qū)域?qū)ず粜诺馈癠RA_PCH”狀態(tài)以及空閑模式。
39.一種用于在無線網(wǎng)絡(luò)處處理信令連接釋放指示消息的方法，所述方法包括: 使用確認(rèn)模式“AM”無線鏈路控制“RLC”在專用控制信道“DCCH”上從用戶設(shè)備“UE”接收針對(duì)所述UE的網(wǎng)絡(luò)控制轉(zhuǎn)換的所述信令連接釋放消息，所述信令連接釋放指示消息具有被設(shè)置為UE請(qǐng)求分組交換“PS”數(shù)據(jù)會(huì)話結(jié)束的原因，反映了來自所述UE的上層的對(duì)在所述UE處不再期望數(shù)據(jù)的指示；以及基于所述原因來發(fā)起狀態(tài)轉(zhuǎn)換。
40.根據(jù)權(quán)利要求39所述的方法，其中，所述原因是所述信令連接釋放指示消息的信^窗、。
41.根據(jù)權(quán)利要求39所述的方法，其中，發(fā)起狀態(tài)轉(zhuǎn)換包括:向所述UE發(fā)送狀態(tài)轉(zhuǎn)換消息。
42.一種用于處理信令連接釋放指示消息的無線網(wǎng)絡(luò)設(shè)備，所述網(wǎng)絡(luò)設(shè)備被配置為: 使用確認(rèn)模式“AM”無線鏈路控制“RLC”在專用控制信道“DCCH”上從用戶設(shè)備“UE”接收針對(duì)所述UE的網(wǎng)絡(luò)控制轉(zhuǎn)換的所述信令連接釋放消息，所述信令連接釋放指示消息具有被設(shè)置為UE請(qǐng)求分組交換“PS”數(shù)據(jù)會(huì)話結(jié)束的原因，反映了來自所述UE的上層的對(duì)在所述UE處不再期望數(shù)據(jù)的指示；以及基于所述原因來發(fā)起狀態(tài)轉(zhuǎn)換。
43.根據(jù)權(quán)利要求42所述的網(wǎng)絡(luò)設(shè)備，其中，所述原因是所述信令連接釋放指示消息的信息元素。
44.根據(jù)權(quán)利要求42所述的網(wǎng)絡(luò)設(shè)備，還被配置為:向所述UE發(fā)送狀態(tài)轉(zhuǎn)換消息。
【文檔編號(hào)】H04W76/06GK103619071SQ201310421418
【公開日】2014年3月5日 申請(qǐng)日期:2007年5月16日 優(yōu)先權(quán)日:2006年5月17日
【發(fā)明者】穆罕默德·哈立德·伊斯蘭, 杰弗里·維爾塔南 申請(qǐng)人:黑莓有限公司