用於umts網絡中的信令釋放原因指示的方法和系統的製作方法

2023-08-04 10:22:46

專利名稱：用於umts網絡中的信令釋放原因指示的方法和系統的製作方法
技術領域：
本申請涉及在用戶設備(UE)和通用陸地無線接入網絡(UTRAN)之間的無線電資源控制，具體地，涉及UMTS網絡中現有信令連接的釋放。
背景技術：
通用移動電信系統(UMTS)是用來傳輸文本、數字語音、視頻和多媒體的基於分組的寬帶系統。它高度支持第三代標準，並通常基於寬帶碼分多址(W-CDMA)。
在UMTS網絡中，協議棧的無線電資源控制(RRC)部分負責UE和UTRAN之間無線電資源的分配、配置和釋放。該RRC協議在3GPP TS 25.331規範中有詳細描述。UE可以處於的兩種基本模式被定義為「空閒模式」和「UTRA連接模式」。UTRA代表UMTS地面無線接入。在空閒模式下，無論何時UE想發送任何用戶數據、或者響應無論何時UTRAN或GPRS服務支持節點(SGSN)對UE的尋呼以從外部數據網絡(如推送伺服器)接收數據，都需要UE請求RRC連接。在3GPP規範TS 25.304和TS 25.331中詳細描述了空閒和連接模式行為。
當處於UTRA RRC連接模式時，設備可以處於四種狀態中的一種狀態。這四種狀態是CELL-DCH在該狀態下，給UE在上行和下行鏈路上分配專用信道來交換數據。UE必須執行如在3GPP 25.331中概述的動作。
CELL_FACH在該狀態下，不給用戶設備分配專用信道。相反，使用公共信道來交換少量的突發數據。UE必須執行如在3GPP 25.331中概述的動作，這包括在3GPP TS 25.304中定義的小區選擇過程。
CELL_PCHUE使用不連續接收(DRX)來監視廣播消息，並通過尋呼指示符信道(PICH)進行尋呼。可以沒有上行鏈路活動。UE必須執行在3GPP 25.331中概述的操作，這包括在3GPP TS 25.304中定義的小區選擇過程。在小區選擇之後，UE必須執行CELL UPDATE過程。
URA_PCHUE使用不連續接收(DRX)來監視廣播消息，並通過尋呼指示符信道(PICH)進行尋呼。可以沒有上行鏈路活動。UE必須執行在3GPP 25.331中概述的操作，這包括在3GPP TS 25.304中定義的小區選擇過程。除了URA UPDATE過程僅僅通過UTRAN註冊區域(URA)重選來觸發之外，該狀態與CELL_PCH相類似。
從空閒模式到連接模式及從連接模式到空閒模式的轉換都是由UTRAN控制的。當空閒模式UE請求RRC連接時，網絡決定是將UE轉移到CELL_DCH狀態還是CELL_FACH狀態。當UE處於RRC連接模式時，網絡再次決定何時釋放該RRC連接。在釋放該連接之前或在作為釋放該連接的替代的某些情況下，網絡還可以將UE從一種RRC狀態轉移到另一種RRC狀態。這種狀態轉換典型地是由UE和網絡之間的數據活動或不活動來觸發的。由於網絡可能不知道對於給定應用來說UE何時完成數據交換，因此典型地，網絡保持RRC連接一段時間，以預期去往/來自UE的更多數據。這樣做典型地降低了呼叫建立以及後續無線電承載建立的等待時間。所述RRC連接釋放消息只能由UTRAN發送。該消息釋放了UE和UTRAN之間的信號鏈路連接和所有無線電承載。
上述問題在於，即使UE上的應用程式已經完成其數據處理並且不期望任何進一步的數據交換，它仍然等待網絡將其轉移到正確的狀態。網絡可能甚至沒有意識到UE上的應用程式已經完成其數據交換的事實。例如，UE上的應用程式可以使用其自身的基於確認的協議來與連接到UMTS核心網的應用伺服器交換數據。這種示例的應用程式運行在UDP/IP上來實現它們自身的有保證的傳送。在這種情況下，UE知道應用伺服器是否已經發送或接收了所有數據分組，並且更好地確定是否會發生任何進一步的數據交換，從而決定何時終止與分組業務(PS)域相關聯的RRC連接。由於UTRAN控制RRC連接的狀態何時變化為不同的狀態或變化到空閒模式，以及UTRAN不知道UE和外部伺服器之間的數據傳送狀態的事實，所以UE被迫停留在比其所需的狀態或模式高的數據速率和更強的電池狀態，從而耗盡了電池壽命。由於不必要地保持佔用無線電承載資源，這也導致了網絡資源的浪費。
解決上述問題的一種方案是讓UE在它認識到完成數據處理時向UTRAN發送信令釋放指示。依照3GPP TS 25.331規範第8.1.14.3節，UTRAN一旦從UE接收到信令釋放指示，就可以釋放該信令連接，從而使得UE轉換到空閒模式。上述方案的問題在於，所述信令釋放指示有可能被認為是告警。典型地，網絡只有在發生GMM業務請求失敗、RAU失敗或附著失敗時才期望信令釋放指示。UE請求信令釋放時告警的產生導致了網絡中無效的性能監視和告警監視。

發明內容
因此，本申請提供了一種用於處理在用戶設備和無線網絡之間的信令釋放指示原因的方法，包括步驟在用戶設備處監視是否應當向無線網絡發送信令連接釋放指示；在用戶設備處，將信令連接釋放指示的原因添加到信令連接釋放指示中；將所添加的信令連接釋放指示發送到無線網絡；在無線網絡處接收所述信令連接釋放指示；以及過濾所述原因來確定是否產生告警。
本申請還提供了一種適於處理信令釋放指示原因的系統，該系統包括用戶設備，該用戶設備具有無線電子系統，包括適於與UMTS網絡通信的無線電設備；無線電處理器，具有數位訊號處理器，並適於與所述無線電子系統交互；存儲器；用戶接口；處理器，適於運行用戶應用程式並與存儲器、無線電設備和用戶接口交互、以及適於運行應用程式，所述用戶設備的特徵在於具有裝置，用於監視是否應當向無線網絡發送信令連接釋放指示；將用於信令連接釋放指示的原因添加到所述信令連接釋放指示；以及將所添加的信令連接釋放指示發送到所述無線網絡；以及適用於與所述用戶設備通信的無線網絡，所述無線網絡進一步的特徵在於裝置，用於接收所述信令連接釋放指示；以及過濾所述原因以確定是否產生告警。
本申請還提供了一種在用戶設備上處理信令釋放指示原因以改進無線網絡處的告警跟蹤的方法，該方法包括步驟監視是否應當向無線網絡發送信令連接釋放指示；將用於信令連接釋放指示的原因添加到信令連接釋放指示；以及將所添加的信令連接釋放指示發送到無線網絡，其中，所述無線網絡具有所述信令連接釋放指示原因的指示。
本申請還提供了一種便於用戶設備釋放信令連接的裝置。檢查器配置用來檢查是否應當發送信令連接釋放指示。信令連接釋放指示發送器配置用來響應檢查器的應當發送所述信令連接釋放指示的指示，來發送信令連接釋放指示。所述信令連接釋放指示包括信令釋放指示原因欄位。
本申請還提供了一種用來針對信令連接釋放指示進行操作的網絡裝置。檢驗器配置用於檢驗信令連接釋放指示的信令釋放指示原因欄位。該檢驗器檢查所述信令釋放指示原因欄位是否指示異常狀況。告警發生器配置用來如果檢驗器的檢驗確定了所述信令釋放指示原因欄位指示異常狀況，則可選擇地產生告警。
本申請還提供了一種用戶設備，適於在UMTS網絡中提供信令釋放指示原因，所述用戶設備具有無線電子系統，包括適於與UMTS網絡通信的無線電設備；無線處理器，具有數位訊號處理器並適於與所述無線電子系統交互；存儲器；用戶接口；處理器，適於運行用戶應用程式並與存儲器、無線電設備和用戶接口交互、以及適於運行應用程式，所述用戶設備的特徵在於具有裝置，用於監視是否應當向無線網絡發送信令連接釋放指示；將用於信令連接釋放指示的原因添加到所述信令連接釋放指示中；以及將所添加的信令連接釋放指示發送到無線網絡，其中，所述無線網絡具有信令連接釋放指示原因的指示。


將參考附圖來更好地理解本申請，其中圖1是顯示RRC狀態和轉換的框圖；圖2是顯示各種UMTS小區和URA的UMTS網絡的示意圖；圖3是顯示RRC連接建立過程各個階段的框圖；圖4A是由UTRAN根據當前方法啟動的在CELL_DCH連接模式狀態和空閒模式之間的典型轉換的框圖；圖4B是顯示使用信令釋放指示在CELL_DCH狀態連接模式轉換到空閒模式的典型轉換的框圖；圖5A是由UTRAN啟動的在CELL_DCH不活動到CELL_FACH不活動到空閒模式轉換的典型轉換的框圖；圖5B是使用信令釋放指示在CELL_DCH不活動和空閒模式之間的典型轉換的框圖；圖6是UMTS協議棧的框圖；圖7是可以與本方法結合使用的典型UE；圖8是與本方法和系統結合使用的典型網絡；圖9是顯示在UE處增加用於信令連接釋放指示原因的步驟的流程圖；以及圖10是顯示了UE接收到具有原因的信令連接釋放指示時所採取的步驟的流程圖。
具體實施例方式
本系統和方法提供了從RRC連接模式轉換到電池更有效狀態或模式的系統和方法，同時在信令釋放指示的原因是UE空閒轉換請求時，確保了網絡不會將信令釋放指示視為告警。具體地，本方法和裝置提供了轉換，所述轉換基於UE啟動對於特定核心網絡域的信令連接終止、或者指示UTRAN應當發生從一種連接狀態至另一種狀態的轉換。下面將根據UMTS的典型實現方式進行描述。然而，應該明白，本發明的教導類似地可應用於其它無線電通信系統。
具體地，如果UE上的應用程式確定處理數據交換，那麼它可以將「完成」指示發送到UE軟體的「RRC連接管理器「組件。RRC連接管理器跟蹤所有的現有應用程式(包括在一個或多個協議上提供業務的那些應用程式)、關聯分組數據協議(PDP)上下文、關聯分組交換(PS)無線電承載和關聯電路交換(CS)無線電承載。PDP上下文是運行在UMTS核心網絡上的UE和PDN(公共數據網絡)之間的邏輯關聯。在UE上的一個或多個應用程式(例如，電子郵件應用程式或瀏覽器應用程式)可以與一個PDP上下文相關聯。在某些情況下，UE上的一個應用程式與一個基本PDP上下文相關聯，而多個應用程式可以與第二PDP上下文聯繫在一起。RRC連接管理器從UE上同時活躍的不同應用程式接收「完成」指示。例如，用戶可以在瀏覽網頁的同時從推送伺服器接收電子郵件。在電子郵件應用程式發送了確認之後，電子郵件應用程式指示已經完成了數據處理，然而，瀏覽器應用程式可能不會發送該指示。基於來自活躍應用程式的這種指示的合成狀態，UE軟體可以決定在可以啟動核心網絡分組業務域的信令連接釋放之前應該等待多久。這種情況下，可以引入延遲來確保該應用程式真正完成數據交換並且不需要RRC連接。所述延遲可以基於業務量歷史和/或應用程式簡檔而動態變化。無論何時RRC連接管理器以某些可能性確定沒有應用程式期望交換任何數據，可以發送用於合適域(例如，PS域)的信令連接釋放指示過程。可選地，它可以將連接模式內的狀態轉換請求發送給UTRAN。
上述決定還可以考慮網絡是否支持URA_PCH狀態和到該狀態的轉換行為。
UE啟動的到空閒模式的轉換可以從RRC連接模式的任何狀態發生，並以網絡釋放該RRC連接並轉移到空閒模式結束。本領域熟練技術人員將理解，處於空閒模式的UE比處於連接狀態的UE需要少得多的電池強度。
然而，信令釋放指示的發送會使網絡認為已發生告警。在信令釋放指示是RRC確定不期望業務量的結果的情況下，在優選實施例中，網絡可以區分信令釋放指示是與異常狀況相反的所請求空閒轉換的結果的事實。這種區分允許諸如關鍵性能指示符(KPI)的指示符更加精確，從而改善了性能監視和告警監視。
本方法允許UE向現有信令釋放指示添加提供信令釋放指示原因的欄位。然後，網絡可以使用所添加的欄位來從由於UE不再期望進一步的數據而請求進入到空閒狀態的情形中過濾出真正的告警狀況。這提高了告警和性能監視的效率，同時仍然允許UE通過更加迅速地轉移到空閒模式來節省電池資源。
本申請因此提供了一種用於處理在用戶設備和無線網絡之間的信令釋放指示原因的方法，包括步驟在用戶設備處監視是否應當向無線網絡發送信令連接釋放指示；在用戶設備處，將信令連接釋放指示的原因添加到信令連接釋放指示中；將所添加的信令連接釋放指示發送到無線網絡；在無線網絡處接收所述信令連接釋放指示；以及過濾所述原因來確定是否產生告警。
本申請還提供了一種適於處理信令釋放指示原因的系統，該系統包括用戶設備，該用戶設備具有無線電子系統，包括適於與UMTS網絡通信的無線電設備；無線電處理器，具有數位訊號處理器，並適於與所述無線電子系統交互；存儲器；用戶接口；處理器，適於運行用戶應用程式並與存儲器、無線電設備和用戶接口交互、以及適於運行應用程式，所述用戶設備的特徵在於具有裝置，用於監視是否應當向無線網絡發送信令連接釋放指示；將用於信令連接釋放指示的原因添加到所述信令連接釋放指示；以及將所添加的信令連接釋放指示發送到所述無線網絡；以及適用於與所述用戶設備通信的無線網絡，所述無線網絡進一步的特徵在於裝置，用於接收所述信令連接釋放指示；以及過濾所述原因以確定是否產生告警。
本申請還提供了一種在用戶設備上處理信令釋放指示原因以改進無線網絡處的告警跟蹤的方法，該方法包括步驟監視是否應當向無線網絡發送信令連接釋放指示；將用於信令連接釋放指示的原因添加到信令連接釋放指示；以及將所添加的信令連接釋放指示發送到無線網絡，其中，所述無線網絡具有所述信令連接釋放指示原因的指示。
本申請還提供了一種便於用戶設備釋放信令連接的裝置。檢查器配置用來檢查是否應當發送信令連接釋放指示。信令連接釋放指示發送器配置用來響應檢查器的應當發送所述信令連接釋放指示的指示，來發送信令連接釋放指示。所述信令連接釋放指示包括信令釋放指示原因欄位。
本申請還提供了一種用來基於信令連接釋放指示進行操作的網絡裝置。檢驗器配置用於檢驗信令連接釋放指示的信令釋放指示原因欄位。該檢驗器檢查所述信令釋放指示原因欄位是否指示異常狀況。告警發生器配置用來如果檢驗器的檢驗確定了所述信令釋放指示原因欄位指示異常狀況，則可選擇地產生告警。
本申請還提供了一種用戶設備，適於在UMTS網絡中提供信令釋放指示原因，所述用戶設備具有無線電子系統，包括適於與UMTS網絡通信的無線電設備；無線處理器，具有數位訊號處理器並適於與所述無線電子系統交互；存儲器；用戶接口；處理器，適於運行用戶應用程式並與存儲器、無線電設備和用戶接口交互、以及適於運行應用程式，所述用戶設備的特徵在於具有裝置，用於監視是否應當向無線網絡發送信令連接釋放指示；將用於信令連接釋放指示的原因添加到所述信令連接釋放指示中；以及將所添加的信令連接釋放指示發送到無線網絡，其中，所述無線網絡具有信令連接釋放指示原因的指不。
現在參考圖1。圖1是表示UMTS網絡中協議棧的無線電資源控制部分的各種模式和狀態的框圖。具體地，RRC可以處於RRC空閒狀態110或RRC連接狀態120。
本領域普通技術人員將理解，UMTS網絡由兩種基於陸地的網絡段構成。它們是核心網(CN)和通用陸地無線接入網(UTRAN)(如圖8所示)。核心網負責數據呼叫的交換和路由以及到外部網絡的數據連接，而UTRAN處理所有的無線電相關功能。
在空閒模式110，無論何時需要在UE和網絡之間交換數據，UE都必須請求RRC連接來建立無線電資源。這可以是UE上的應用程式請求連接來發送數據的結果，或者是UE監視尋呼信道以指示UTRAN或SGSN是否已經尋呼UE來從諸如推送伺服器的外部數據網絡接收數據的結果。此外，UE還在任何需要發送諸如位置區域更新的移動性管理信令消息的時候請求RRC連接。
一旦UE已經發送請求給UTRAN來建立無線電連接，UTRAN就選擇將要處於的RRC連接狀態。具體來說，RRC連接模式120包括四個獨立狀態。它們是CELL_DCH狀態122，CELL_FACH狀態124、CELL_PCH狀態126和URA_PCH狀態128。
從空閒模式110，RRC連接狀態可以進入小區專用信道(CELL_DCH)狀態122，或者可以進入小區前向接入信道(CELL_FACH)狀態124。
在CELL_DCH狀態122，給UE的上行和下行鏈路分配專用信道以交換數據。由於該狀態具有分配給UE的專用物理信道，因此，該狀態典型地從UE需要最多的電池功率。
可選地，UTRAN可以從空閒模式110轉移到CELL_FACH狀態124。在CELL_FACH狀態，不給UE分配專用信道。相反，使用公共信道以少量突發數據來發送信令。然而，UE仍然不得不繼續監視FACH，因此消耗電池功率。
在RRC連接模式120內，RRC狀態可以在UTRAN的判斷下進行改變。具體來說，如果在特定的時間量內沒有檢測到數據活動、或者檢測到數據吞吐量低於某一閾值，那麼UTRAN可以將RRC狀態從CELL_DCH狀態122轉移到CELL_FACH狀態124、CELL_PCH狀態126或URA_PCH狀態128。類似地，如果檢測到有效載荷超過特定閾值，那麼RRC狀態可以從CELL_FACH 124轉移到CELL_DCH 122。
從CELL_FACH狀態124，如果在一些網絡中的特定時間內沒有檢測到數據活動，那麼UTRAN可以將RRC狀態從CELL_FACH狀態124轉移到尋呼信道(PCH)狀態。這可以是CELL_PCH狀態126或URA_PCH狀態128。
從CELL_PCH狀態126或URA_PCH狀態128，UE必須轉移到CELL_FACH狀態124，以便啟動更新過程來請求專用信道。這是UE控制的唯一狀態轉換。
CELL_PCH狀態126和URA_PCH狀態128使用不連續接收周期(DRX)來監視廣播消息，並通過尋呼指示符信道(PICH)進行尋呼。可以沒有上行鏈路活動。
CELL_PCH狀態126和URA_PCH狀態128之間的不同在於，如果UE當前的UTRAN註冊區域(URA)並非處於當前小區中呈現的URA標識列表中，那麼URA_PCH狀態只觸發URA更新過程。具體來說，參考圖2，圖2顯示了不同UMTS小區210、212和214的示意圖。如果重新選擇到CELL_PCH狀態，那麼所有這些小區都需要小區更新過程。然而，在UTRAN註冊區域內，每個小區將處於相同的UTRAN註冊區域220內，因此，當在URA_PCH模式下在210、212和214之間移動時不觸發URA更新過程。
從圖2中可以看出，其他小區218處於URA220的外部，並且可以是單獨的URA或者非URA的一部分。
本領域熟練技術人員將明白，從電池壽命考慮，與上面的狀態相比，空閒狀態提供最低的電池使用。具體來說，由於UE只需間隔地監視尋呼信道，因此無線電設備並不需要連續處於打開狀態，但是需要周期性地喚醒。對此的折中是延遲發送數據。然而，如果這種延遲不是太大，那麼處於空閒模式以及節省電池電量的優點將超過連接延遲的缺點。
再次參考圖1。不同的UMTS基礎運營商基於不同的標準在狀態122、124、126和128之間轉移。下面概述典型的基礎結構。
在第一典型基礎結構中，RRC直接在空閒模式和Cell_DCH狀態之間轉移。在Cell_DCH狀態下，如果檢測到兩秒中沒有活動，RRC狀態就改變到Cell_FACH狀態124。如果，在Cell_FACH狀態124中檢測到10秒鐘沒有活動，那麼RRC狀態就改變到PCH狀態126。在Cell_PCH狀態126中沒有活動達到45分鐘將導致RRC狀態返回到空閒模式110。
在第二典型基礎結構中，RRC轉換可以依據有效載荷閾值在空閒模式110和連接模式120之間發生。在第二基礎結構中，如果有效載荷低於特定閾值，那麼UTRAN就將RRC狀態轉移到CELL_FACH狀態124。相反，如果數據超過特定有效載荷閾值，那麼UTRAN就將RRC狀態轉移到CELL_DCH狀態122。在第二基礎結構中，如果在CELL_DCH狀態122檢測到兩分鐘沒有活動，那麼UTRAN就將RRC狀態轉移到CELL_FACH狀態124。在CELL_FACH狀態124中5分鐘沒有活動之後，UTRAN就將RRC階段轉移到CELL_PCH狀態126。在CELL_PCH狀態126，在返回到空閒模式110之前，需要兩個小時不活動。
在第三典型基礎結構中，空閒模式和連接模式120之間的轉移總是轉移到CELL_DCH狀態122。在CELL_DCH狀態122中5秒鐘沒有活動之後，UTRAN將RRC狀態轉移到CELL_FACH狀態124。在CELL_FACH狀態124中30秒不活動將導致返回到空閒模式110。
在第四典型基礎結構中，RRC從空閒模式到連接模式直接轉換成CELL_DCH狀態122。在第四典型基礎結構中，CELL_DCH狀態122包括兩個子狀態。第一子狀態包括具有高數據速率的子狀態，第二子狀態包括較低的數據速率，但是仍然處於CELL_DCH狀態內。在第四典型基礎結構中，RRC從空閒模式110直接轉換到高數據速率的CELL_DCH子狀態。在10秒不活動之後，RRC狀態轉換到低數據速率CELL_DCH狀態。從低數據CELL_DCH狀態122開始17秒沒有活動將導致RRC狀態改變到空閒模式110。
上述四種典型基礎結構顯示了不同UMTS基礎結構廠商如何實現這些狀態。正如本領域熟練技術人員將理解的那樣，在每種情況下，如果花費在交換實際數據(例如電子郵件)上的時間明顯比停留在CELL_DCH或CELL_FACH狀態所需的時間短，那麼這將導致不必要的電流消耗，這將使得在諸如UMTS的更新一代網絡中的用戶體驗比在諸如GPRS的現有網絡中更差。
另外，雖然從電池壽命角度來說，CELL_PCH狀態比CELL_FACH狀態更佳，但是，在CELL_PCH狀態中的DRX周期典型地被設定為比空閒模式110更低的值。因此，在CELL_PCH狀態下，需要比在空閒模式下更頻繁地喚醒UE。
具有與空閒狀態的DRX周期類似的DRX周期的URA_PCH狀態可能是電池壽命和連接延遲之間的最佳折中。然而，目前在UTRAN中並不支持URA_PCH。因此，從電池壽命角度考慮，在完成數據交換的應用程式之後，希望能夠儘可能快地轉換到空閒模式。
現在參考圖3。當從空閒模式轉換到連接模式時，需要作出各種信令和數據連接。參考圖3，需要執行的第一項是RRC連接建立。如上所述，該RRC連接建立只能由UTRAN拆斷。
一旦完成RRC連接建立310，就開始信令連接建立312。
一旦完成信令建立312，就開始加密和完整性建立314。一旦完成這些，也就完成了無線承載建立316。此時，可以在UE和UTRAN之間交換數據。
通常，類似以相反的順序來完成拆斷連接。拆斷無線承載建立316，然後拆斷RRC連接建立310。此時，RRC轉移到空閒模式110，如圖1所示那樣。
雖然目前的3GPP規範並不允許UE釋放RRC連接或指示它對於RRC狀態的偏好，但是對於諸如分組交換應用程式使用的分組交換(PS)域之類的特定核心網絡域來說，UE還是可以指示信令連接的終止。根據3GPP TS 25.331的第8.1.14.1節，由UE使用信令連接釋放指示過程來指示UTRAN已經釋放其信令連接中的其中一個。該過程也可以進而啟動RRC連接釋放過程。
因此，停留在目前的3GPP規範內，可以基於信令連接建立312的拆斷來啟動信令連接釋放。拆斷信令連接建立312是UE的能力之內的事情，因此，根據該規範，這進而「可以」啟動RRC連接釋放。
正如本領域普通技術人員應當理解到的那樣，如果信令連接建立312被拆斷，那麼UTRAN在拆斷了信令連接建立312之後，將會需要清除解密和完整性建立312、無線承載建立316。
如果信令連接建立312被拆斷，那麼典型地由當前廠商基礎結構的網絡來拆斷RRC連接建立。
通過使用上面的過程，如果UE確定其處理數據交換，例如，如果向UE軟體的「RRC連接管理器」組件提供了交換數據完成的指示，那麼RRC連接管理器可以確定是否拆斷信令連接建立312。例如，在設備上的電子郵件應用程式發送以下指示它已經從推送郵件伺服器接收了所述電子郵件確實由推送伺服器接收到的確認。RRC管理器可以跟蹤所有現有的應用程式、關聯的PDP上下文、關聯的PS無線電承載和關聯的電路交換(CS)無線電承載。在此情況下，可以引入延遲來確保應用程式真正完成了數據交換，而且甚至在已經發送了「完成」指示之後，不再需要RRC連接。這種延遲等同於與應用程式相關聯的不活動超時。每個應用程式都可以具有自己的不活動超時。例如，電子郵件應用程式可以具有5秒的不活動超時，而處於活動狀態的瀏覽器應用程式可以具有60秒的超時。基於來自有效應用程式的所有這些指示的綜合狀態，UE軟體確定在它可以啟動適合核心網絡(例如PS域)的信令連接釋放之前應當等待多久。
基於業務量模式歷史和/或應用程式簡檔，可以使不活動超時是動態的。
無論何時RRC連接管理器以某些可能性確定沒有應用程式期望交換數據，它都可以發送用於合適域的信令連接釋放指示過程。
上述由UE啟動的到空閒模式的轉換可以在如圖1所示的RRC連接模式120的任何階段發生，並使網絡釋放RRC連接並以轉移到空閒模式110為結束，如圖1所示。這也可以應用在UE在語音呼叫期間執行任何分組數據業務時。在這種情況下，僅釋放PS域，而CS域仍保持連接。
從網絡觀點來考慮，上面的問題在於，由UE發送的信令釋放指示被解譯為告警。在信令網絡釋放是由於應用程式定時器到期而不再期望數據所引起的UE的明確動作結果的情況下，由上述指示引起的告警曲解了性能和告警指示。關鍵性能指示符可能因此而改變，從而導致效率降低。
優選地，可以在信令連接釋放指示中添加原因來向UTRAN指示該指示的理由。在優選實施例中，所述原因可以是以下指示異常狀況引起的指示、或作為請求空閒轉換的結果而由UE啟動的指示。其他正常(即，非異常)處理也可以導致信令連接釋放指示的發送。
在另一優選實施例中，不同的超時會引起要為異常狀況發送的信令連接指示。下面定時器的示例不是獨佔性的，其他定時器或異常狀況也是可以的。例如，10.2.47 3GPP TS 24.008規定定時器T3310為

定時器T3310該定時器被用於指示附著失敗。附著失敗可能是網絡的結果，或者可能是例如衝突或較差射頻(RF)之類的RF問題。
附著嘗試可以發生多次，而附著失敗是由預定次數的失敗或明確拒絕所產生的。
3GPP的10.2.47的第二定時器是定時器T3330，規定為

定時器T3330該定時器用來指示路由區域更新失敗。一旦定時器到期，就可以多次請求進一步的路由區域更新，並且路由區域更新失敗是由預定次數的失敗或明確拒絕所產生的。
3GPP的10.2.47的第三定時器是定時器T3340，規定為


定時器T3340該定時器用於指示GMM業務請求失敗。一旦定時器到期，可以發起多次進一步的GMM業務請求，並且GMM業務請求失敗是由從預定次數的失敗或明確拒絕所產生的。
因此，代替局限於異常狀況的信令釋放指示原因和UE的釋放，信令釋放指示原因還可以包括與哪個定時器失敗是由於異常狀況而發生故障有關的信息。信令連接釋放指示可以構造為

信令連接釋放指示該消息由UE使用來向UTRAN指示釋放現有的信令連接。信令釋放指示原因的添加允許UTRAN或其他網絡元件接收該信令釋放指示的原因，而無論是否是由於異常狀況以及該異常狀況是什麼。因此，進而允許啟動RRC連接釋放過程。
在一種實現方式中，UE在從特定CN(核心網絡)域的上層接收到釋放或中止、信令連接的請求時，如果對於以IE(信息元素)「CN域標識」來識別的特定CN域，存在如在變量(例如，變量ESTABLISHED_SIGNALING_CONNECTIONS)中識別的信令連接，那麼UE就發起信令連接釋放指示過程。如果該變量不識別任何現有的信令連接，那麼以另一方式中止對於該特定CN域的信令連接的任何正在進行的建立。以及，當在Cell_PCH或URA_PCH狀態下啟動了信令連接釋放指示過程時，UE使用原因「上行鏈路數據傳輸」來執行小區更新過程。以及，當小區更新過程成功完成時，UE繼續進行後面的信令連接釋放指示過程。
即，UE將IE「CN域標識」設置為由上邏輯層指示的值。IE的值向與信令連接關聯的CN域指示上層正指示要釋放的關聯信令連接。如果CN域標識被設定為PS域，並且如果上層指示啟動該請求的原因，那麼就相應地設定IE「信令釋放指示原因」。UE進一步從變量「established_signaling_connectinons」中移除具有由上層指示的標識的信令連接。以及，UE使用AM RLC來傳輸與例如DCCH有關的信令連接釋放指示消息。一旦RLC確認成功傳送了所述釋放指示消息，該過程就結束。
根據本公開的實施例，還使用了IE「信令釋放指示原因」。例如，使用現有的消息定義來調整釋放原因。上層釋放原因消息被構造為，例如

在該示例中，T3310，T3330和T3340的到期與先前識別的相應編號的定時器的到期相對應。在一種實施方式中，儘管所期望的結果與由原因值所識別的結果相對應，但是可以將原因值設定為「UE請求PS數據會話結束」而不是「UE請求空閒轉換」，以便為UTRAN提供針對狀態轉換的決定。對於信令連接釋放指示的擴展優選、但不是必須是非臨界擴展。
現在參考圖9。圖9是典型UE監視是否發送用於各種域(例如PS或CS)的信令連接釋放指示的流程圖。該過程在步驟910開始。
UE轉換到步驟912來檢查是否存在異常狀況。例如，這種異常狀況可以包括如上所述的定時器T3310、定時器T3320或定時器T3340到期。如果這些定時器到期了特定的預定次數，或者如果基於這些定時器的任何一個的到期而接收到明確的拒絕，那麼UE就繼續到步驟914來發送信令連接釋放指示。向信令連接釋放指示消息添加信令釋放指示原因欄位。信令釋放指示原因欄位包括至少信令釋放指示是基於異常狀況或狀態的；以及優選實施例包括超時而導致異常狀況的特定定時器。
相反，如果在步驟912UE發現不存在異常狀況，那麼UE就繼續到步驟920來檢查在UE中是否期望其他的數據。如上所述，這可以包括在發送電子郵件和在UE接收回對電子郵件發送的確認時。UE確定不期望其他數據的其他示例對於本領域熟練技術人員來說是已知的。
如果在步驟920，UE確定完成了數據傳送(或在完成呼叫的電路交換域的情況下)，UE繼續到步驟922，在此，UE發送已添加了信令釋放指示原因欄位並包括UE請求空閒轉換的事實的信令連接釋放指示。
從步驟920開始，如果數據沒有完成，那麼UE就返回並繼續在步驟912中檢查是否存在異常狀況，以及在步驟920中檢查數據是否完成。
一旦在步驟914或922中發送了信令連接釋放指示，那麼該過程就繼續到步驟930，並結束。
UE包括例如可以由通過UE微處理器工作執行應用程式或算法或通過硬體實現的功能單元，它們形成了檢查器和信令連接釋放指示發送器。檢查器配置用來檢查是否應當發送信令連接釋放指示。以及，信令連接釋放指示發送器配置用來響應檢查器的應當發送信令連接釋放指示的指示，而發送該信令連接釋放指示。所述信令連接釋放指示包括信令釋放指示原因欄位。
作為替代，在一種實施方式中，網絡隱含地知道定時器的到期，以及UE不需要發送指示該定時器到期的原因值。也就是說，定時器針對網絡的認證而開始計時。定義原因代碼，並由網絡將該原因代碼提供給UE。由UE使用這些原因代碼來啟動定時器。以及，由於網絡早先發送的原因代碼使定時器開始計時，所以網絡隱含地知道定時器後續的到期原因。因此，UE不需要發送指示定時器到期的原因值。
參考圖10，當網絡元件在步驟1010接收信令連接釋放指示時，網絡單元在步驟1014檢查信令釋放指示原因欄位，並在步驟1016檢查該原因是否是異常原因或者是否是由於UE請求空閒轉換而導致的。如果在步驟1016，信令連接釋放指示是異常原因，那麼網絡節點就繼續到步驟1020，在此，出於性能監視和告警監視的目的而標記告警。所述關鍵性能指示符可以被適當地更新。
相反，如果在步驟1016，信令連接釋放指示原因不是異常狀況的結果，或者換句話說，是UE請求空閒轉換的結果，那麼網絡節點就繼續到步驟1030，在此，不產生告警，並可以根據性能統計量來過濾所述指示，從而防止性能統計量偏移。從步驟1020或步驟1030，網絡節點前進到步驟1040結束該過程。
信令釋放指示原因欄位的接收和檢查導致了網絡單元啟動RRC連接釋放過程。以及，結束分組交換數據連接。
本領域熟練技術人員將理解，步驟1020可以用來進一步區分各種告警狀況。例如，T3310到期可以用來保持第一組統計量，而T3330到期可以用來保持第二組統計量。步驟1020可以區分異常狀況原因，從而允許網絡運營商更有效地跟蹤性能。
所述網絡包括例如可以通過處理器的操作、或通過形成檢驗器和告警產生器的硬體實現所執行應用程式或算法而實現的功能單元。所述檢驗器配置用來檢驗信令連接釋放指示的信令釋放指示原因欄位。所述檢驗器檢查所述信令釋放指示原因欄位是否指示異常狀況。所述告警產生器配置用來在檢驗器的檢驗確定了所述信令釋放指示原因欄位指示異常狀況時可選擇地產生告警。
在一種實施方式中，一旦接收到所述信令連接釋放指示，所述UTRAN就轉發所接收的原因，並從上層請求釋放該信令連接。然後，所述上層可以啟動所述信令連接的釋放。所述IE信令釋放指示原因指示UE的上層原因來觸發UE的RRC以發送消息。所述原因可以是異常上層過程的結果。通過IE的成功接收來確保消息原因的區別。
一種可能的情形包括在RLC確認成功傳遞了信令連接釋放指示消息之前，在信令無線電承載RB2上重新建立RLC實體的傳輸側。例如，在發生這種情況時，UE在信令無線電承載RB2上，通過使用AM RLC，在上行鏈路DCCH上重傳所述信令連接釋放指示消息。在RLC確認成功傳遞了信令連接釋放指示消息之前發生從UTRAN過程的性能到進入-RAT的切換時，UE在新的RAT內中止所述信令連接。
再次參考圖1，在某些情況下，可能更希望處於連接模式狀態URA_PCH而不是空閒模式。例如，如果需要連接到CELL_DCH或CELL_FACH連接模式狀態的延遲更低，那麼優選處於連接模式PCH狀態。有兩種方式完成該過程。首先是通過改變3GPP規範來允許UE請求UTRAN將它轉移到特定狀態，在本例中是URA_PCH狀態128。
可選地，RRC連接管理器可以考慮諸如RRC連接當前處於何種狀態之類的其他因素。例如，如果RRC連接處於URA_PCH狀態，那麼它可以確定不需要移動到空閒模式110，因而不啟動信令連接釋放過程。
參考圖4。圖4A顯示了根據以上的基礎結構「四」示例的當前UMTS實現方式。如圖4所示，橫軸代表時間。
UE開始於RRC空閒狀態110，並基於需要傳輸的本地數據和從UTRAN接收的尋呼來開始建立RRC連接。
如圖4A所示，首先發生RRC連接建立310，並且在此期間，RRC狀態是連接狀態410。
接著，發生信令連接建立312、加密和完整性建立314、以及無線電承載建立316。在此期間，RRC狀態是CELL_DCH狀態122。如圖4A所示，在本例中，從RRC空閒模式移動到建立無線電承載時的時間大約為兩秒。
接著交換數據。在圖4A的示例中，該過程是在2到4秒中完成的，並且由步驟420示出。
在步驟420交換數據之後，除了所需要的間歇RLC信令PDU之外沒有數據交換，因此在大約10秒之後，網絡重新配置無線電承載以移動到較低的數據速率DCH狀態。該過程在步驟422和424中示出。
在所述較低數據速率DCH狀態中，17秒鐘之內什麼也沒有接收到，此時，在步驟428由網絡釋放RRC連接。
一旦在步驟428啟動RRC連接，那麼RRC狀態前進到斷開狀態430大約40毫秒，此後，UE處於RRC空閒狀態110。
仍然如圖4A所示那樣，示出了RRC處於CELL_DCH狀態122期間內的UE電流消耗。如看到的那樣，在CELL_DCH狀態的整個持續時間內，電流消耗大約為200到300毫安。在斷開和空閒狀態期間，假設DRX周期為1.28秒，那麼使用的電流大約為3毫安。然而，在電池上將以200到300毫安流出35秒的電流消耗。
現在參考圖4B。圖4B使用了上面相同的典型基礎結構「四」，只是現在實現了信令連接釋放。
如圖4B所示，發生相同的建立步驟310、312、314和316，這在RRC空閒狀態110和RRC CELL_DCH狀態122之間轉移時花費了相同的時間量。
此外，在圖4B中也進行了用於圖4A典型電子郵件的RRC數據PDU交換，並且這大約花費2到4秒。
在圖4B示例中，UE具有應用程式特定的不活動超時，這在圖4B的示例中為2秒，並且由步驟440示出。在RRC連接管理器確定在特定時間量內處於不活動之後，在步驟442中UE釋放信令連接建立，並在步驟428中由網絡釋放RRC連接。
如圖4B所示，在CELL_DCH步驟122期間的電流消耗仍然大約為200到300毫安。然而，連接時間只有大約8秒。本領域熟練技術人員將理解到，移動停留在小區DCH狀態122明顯較短的時間量對於總是處於打開狀態的UE設備來說會明顯地省電。
現在參考圖5。圖5顯示了使用上面指示為基礎結構「三」的基礎結構的第二示例。參考圖4A和4B，發生了大約花費2秒的連接建立。這需要RRC連接建立310、信令連接建立312、加密和完整性建立314和無線電承載建立316。
在該建立期間，UE使用RRC空閒模式110和CELL_DCH狀態122之間的RRC狀態連接步驟410，從RRC空閒模式110轉移到CELL_DCH狀態122。
如圖4A所示，在圖5A中，發生了RLC數據PDU交換，並在圖5A的示例中花費2到4秒。
根據基礎結構三，除了所需要的間歇RLC信令PDU之外，RLC信令PDU交換在步驟422中沒有接收數據因而有5秒的空閒，此時，無線電承載重新配置所述網絡以從CELL_DCH狀態122轉移到CELL_FACH狀態124。這在步驟450中完成。
在CELL_FACH狀態124中，RLC信令PDU交換發現在預定時間量(在這個示例中，是30秒)內除了所需要的間歇RLC信令PDU之外沒有數據，此時在步驟428中由網絡執行RRC連接釋放。
如在圖5A中看出的那樣，這使RRL狀態轉移到空閒模式110。
如在圖5A中進一步看出的那樣，在DCH模式期間的電流消耗處於200和300毫安之間。當轉移到CELL_FACH狀態124時，電流消耗降低到大約120到180毫安。在釋放了RRC連接並且RRC轉移到空閒模式110之後，電量消耗大約為3毫安。
在圖5A的示例中，作為CELL_DCH狀態122或CELL_FACH狀態124的UTRA RRC連接模式狀態持續大約40秒。
現在參考圖5B。圖5B顯示了與圖5A相同的基礎結構「三」，具有大約2秒的相同連接時間來實現RRC連接建立310、信令連接建立312、加密完整性建立314和無線電承載建立316。此外，RLC數據PDU交換420花費大約2到4秒。
參考圖4B，UE應用程式在步驟440檢測到特定的不活動超時，此時由UE啟動信令連接釋放指示過程，並作為結果，由網絡在步驟448中釋放RRC連接。
進一步可以在圖5B中看出，RRC開始於空閒模式110，移動到CELL_DCH狀態122，而不繼續到CELL_FACH狀態。
在圖5B中還將看出，在RRC階段處於CELL_DCH狀態122的時間(根據圖5的示例，大約為8秒)，電流消耗大約為200到300毫安。
因此，在圖4A和4B與圖5A和5B之間的比較表明電流消耗量明顯減少，從而大大延長了電池壽命。本領域熟練技術人員將理解，上述情況還可用於當前3GPP規範的上下文中。
現在參考圖6。圖6示出了UMTS網絡的協議棧。
從圖6可以看出，UMTS包括CS控制平面610、PS控制平面611和PS用戶平面630。
在這三個平面內，存在非接入層(NAS)部分614和接入層部分616。
在CS控制平面610中的NAS部分614包括呼叫控制(CC)618、增值業務(SS)620、和短消息業務(SMS)622。
在PS控制平面611中的NAS部分614包括移動性管理(MM)和GPRS移動性管理(GMM)626。還包括SM/RABM 624和GSMS 628。
CC 618提供了電路交換業務的呼叫管理信令。SM/RABM 624的會話管理部分提供了PDP上下文激活、去激活和修改。SM/RABM 624還提供了服務質量協商。
SM/RABM 624的RABM部分的主要功能是用來將PDP上下文連接到無線接入承載。因此，SM/RABM 624負責無線電承載的建立、修改和釋放。
在接入層616中的CS控制面610和PS控制面611處於無線電資源控制(RRC)617的上面。
PS用戶平面630中的NAS部分614包括應用層638、TCP/UDP層636和PDP層634。例如，PDP層634可以包括網際網路協議(IP)。
在PS用戶平面630中的接入層616包括分組數據會聚協議(PDCP)632。PDCP 632被設計用來使得WCDMA協議適用於在UE和RNC之間執行TCP/IP協議(如在圖8中所見)，並可選地用於IP業務流協議報頭壓縮和解壓縮。
UMTS無線鏈路控制(RLC)640和媒體接入控制(MAC)層650形成了UMTS無線接口的數據鏈路子層，並駐留在RNC節點和用戶設備上。
層1(L1)UMTS層(物理層660)處於RLC/MAC層640和650下面。該層是用於通信的物理層。
雖然上面可以在各種行動裝置上實現，但是下面根據圖7概述了一種行動裝置的示例。現在參考圖7。
UE1100優選地是具有至少語音和數據通信能力的雙路無線通信設備。UE 1100優選地具有與網際網路上的其他計算機系統通信的能力。依據所提供的確切功能，例如，可以將無線電設備稱為數據消息收發設備、雙路尋呼機、無線電子郵件設備、具有數據消息收發能力的蜂窩電話、無線網際網路家電、或數據通信設備。
在UE 1100能夠進行雙路通信的情況下，將結合通信子系統1111，該通信子系統1111包括接收機1112和發射機1114、以及關聯組件，如一個或多個優選為嵌入或內置的天線元件1116和1118、本地振蕩器(LOs)1113、以及諸如數位訊號處理器(DSP)1120的處理模塊。對於通信領域普通技術人員來說，很明顯通信子系統1111的特定設計將依賴於所述設備意欲工作的通信網絡。例如，UE 1100可以包括設計用來在GPRS網絡或UMTS網絡內工作的通信子系統1111。
網絡接入要求也將依據網絡1119的類型而變化。例如，在UMTS和GPRS網絡中，網絡接入與UE 1100的訂戶或用戶相關聯。例如，GPRS行動裝置因此需要用戶識別模塊(SIM)卡，以便在GPRS網絡中工作。在UMTS中，需要USIM或SIM。在CDMA中，需要RUIM卡或模塊。在此，這些都稱作UIM接口。如果沒有有效的UIM接口，行動裝置將不能充分工作。本地或非網絡通信功能、以及諸如緊急呼叫之類的合法需要功能(如果有)是可用的，但是行動裝置1100將不能執行任何涉及在網絡1100上通信的其他功能。UIM接口1144通常類似於在其中可以插入或拆卸象盤或PCMCIA卡那樣的卡的卡槽。所述UIM卡可以具有大約64K的內存，並具有很多密鑰配置1151，以及諸如標識和用戶相關信息之類的其它信息1153。
當所需的網絡註冊或激活過程已經完成時，UE 1100可以在網絡1119上發送和接收通信信號。由天線1116通過通信網絡1119接收的信號被輸入到接收機1112，接收機1112可以執行普通接收機功能，例如信號放大、下變頻、濾波、信道選擇等、以及在圖7所示的示例系統中的模數(A/D)轉換。所接收信號的A/D轉換允許更複雜的通信功能，例如在DSP 1120中執行的解調和解碼。以類似的方式，處理要發射的信號，包括例如DSP 1120的調製和編碼，並被輸入到發射機1114進行數模轉換、上變頻、濾波、放大和在通信網絡1119上通過天線1118發射。DSP 1120不但處理通信信號，而且還提供對接收機和發射機的控制。例如，可以通過在DSP 1120中實現的自動增益控制算法，來適應性地控制對於應用到接收機1112和發射機1114的通信信號的增益。
網絡1119還可以與多個系統進行通信，包括伺服器1160和其他元件(沒有示出)。例如，網絡1119可以與企業系統和網絡客戶端系統通信以便使用各種業務級別來容納各種客戶。
UE 1100優選地包括用於控制設備整體運行的微處理器1138。通過通信子系統1111執行包括至少數據通信的通信功能。微處理器1138還與其他設備子系統交互，例如顯示器1122、快閃記憶體1124、隨機訪問存儲器(RAM)1126、輔助輸入/輸出(I/O)子系統1128、串行埠1130、鍵盤1132、揚聲器1134、麥克風1136、短距離通信子系統1140和通常標識為1142的任何其他設備子系統。
圖7所示的某些子系統執行通信相關功能，而其他子系統可以提供「駐留」或設備上功能。可以注意到，某些子系統(例如鍵盤1132和顯示器1122)既可以用於諸如輸入文本消息以在通信網絡上傳輸之類的通信相關功能，也可以用於諸如計算器或任務列表之類的設備駐留功能。
由微處理器1138使用的作業系統軟體優選地存儲在諸如快閃記憶體1124之類的永久存儲器中，作為替代，這還可以是只讀存儲器(ROM)或類似的存儲器元件(沒有示出)。本領域熟練技術人員將理解，作業系統、具體的設備應用程式或其中的部分可以被暫時加載到諸如RAM1126之類的易失性存儲器中。所接收的通信信號也可以存儲在RAM1126中。另外，唯一的標識符也優選地存儲在只讀存儲器中。
如所示的那樣，快閃記憶體1124可以被分割成用於電腦程式1158和程序數據存儲器1150、1152、1154和1156的不同區域。這些不同的存儲器類型指示了每種程序可以針對它們的數據存儲需求來分配快閃記憶體1124的一部分。除了作業系統功能之外，微處理器1138優選地還能夠執行行動裝置上的軟體應用程式。在製造期間，通常將在UE 1100中安裝用來控制基本操作的預定應用程式組，例如包括至少數據和語音通信應用程式。優選的軟體應用程式可以是具有組織和管理與行動裝置用戶相關的數據項目的能力的個人信息管理器(PIM)應用程式，例如電子郵件、日曆事件、語音郵件、約會和任務項目等，但不局限於此。實際上，在行動裝置上一個或多個存儲器可用，以便存儲PIM數據項目。這種PIM應用程式將優選地具有經由無線網絡1119發送和接收數據項目的能力。在優選實施例中，PIM數據項目經由無線網絡1119與所存儲的、或同主機計算機系統相關聯的行動裝置用戶相應數據項目進行無縫地集成、同步和更新。可以通過網絡1119、輔助I/O子系統1128、串行埠1130、短程通信子系統1140或任何其他合適的子系統1142，將其他的應用程式載入到行動裝置1100中，並可以被用戶安裝在RAM 1126中，或優選地安裝在非易失性存儲器(沒有示出)中以便由微處理器1138執行。應用程式安裝中的這種靈活性增強了設備的功能性，並可以提供增強的設備上功能、通信相關功能、或兩者。例如，安全通信應用程式能夠進行電子商務功能和要使用UE1100執行的其他這種金融業務。然而根據上面的描述，這些應用程式在許多情況下需要由載體批准。
在數據通信模式中，諸如文本消息或網頁下載之類的接收信號將由通信子系統1111處理，並被輸入到微處理器1138，微處理器1138優選地對接收信號進行進一步處理以輸出給顯示器1122，或可選地輸出給輔助I/O設備1128。UE 1100的用戶還可以使用鍵盤1132(優選地，完整的字母數字鍵盤或電話類型的小鍵盤)與顯示器1122和可能的輔助I/O設備1128結合來編輯數據項目，例如電子郵件消息。所編輯的項目然後可以通過通信子系統1111在通信網絡上傳輸。
對於語音通信來說，除了接收信號優選地被輸出到揚聲器1134、以及用於傳輸的信號將通過麥克風1136產生之外，UE 1100的所有操作都是相似的。也可以在UE 1100上實現可選的語音或音頻I/O子系統，例如語音消息記錄子系統。雖然語音或音頻信號輸出優選地主要是通過揚聲器1134來完成的，但是也可以使用顯示器1122來提供例如對主叫方標識、語音呼叫持續時間、或其他語音呼叫相關信息的指示。
圖7中的串行埠1130通常將在個人數字助理(PDA)類型的行動裝置中實現，希望該行動裝置與用戶的臺式計算機(沒有示出)同步。這種埠1130能夠使用戶通過外部設備或軟體應用程式來設置偏好，並能夠通過向UE 1100提供信息或軟體下載、而不是通過無線通信網絡來擴展行動裝置1100的能力。例如，可選的下載路徑可以用來將加密密鑰通過直接因而可靠可信的連接加載到設備上，從而能夠確保安全設備通信。
可選地，串行埠1130可以用於其他通信，並可以包括作為通用串行總線(USB)埠。接口與串行埠1130相關聯。
諸如短程通信子系統的其他通信子系統1140是其他可選組件，它可以提供在UE 1100和不同系統或設備之間的通信，這不必需要相同的設備。例如，子系統1140可以包括紅外設備和關聯電路和組件或BluetoothTM通信模塊來提供與類似功能的系統和設備之間的通信。
現在參考圖8。圖8是包括通過無線通信網絡通信的UE 802的通信系統800的框圖。
UE 802與多個節點B 806的其中一個進行無線通信。每個節點B806負責空中接口處理和一些無線資源管理功能。節點B 806提供了類似於GSM/GPRS網絡中的基站收發信機的功能。
圖8的通信系統800中示出的無線鏈路代表一個或多個不同的信道，典型地為不同射頻(RF)信道，以及在無線網絡和UE 802之間使用的關聯協議。在UE 802和節點B 806之間使用Uu空中接口。
RF信道是必須節約的有限資源，典型地，這是由於總帶寬的限制和UE 802有限的電池電量。本領域熟練技術人員將理解，實際應用中的無線網絡依據網絡覆蓋的期望整體區域而包括成百上千的小區。所有的相關組件可以通過多個交換機和路由器(沒有示出)連接，並通過多個網絡控制器來控制。
每個節點B 806與無線網絡控制器(RNC)810通信。RNC 810負責控制它的區域內的無線電資源。一個RNC 810控制多個節點B806。
UMTS網絡中的RNC 810提供了等同於GSM/GPRS網絡中基站控制器(BSC)功能的功能。然而，RNC 810包括更多智能技術，例如包括不涉及MSC和SGSN的自動切換管理。
在節點B 806和RNC 810之間使用的接口是Iub接口808。如在3GPP TS 25.433 V3.11.0(2002-09)和3GPP TS 25.433 V5.7.0(2004-01)中定義的那樣，主要使用NBAP(節點B應用程式部分)信令協議。
通用陸地無線接入網絡(UTRAN)820包括RNC 810、節點B 806和Uu空中接口804。
電路交換業務被路由到移動交換中心(MSC)830。MSC 830是做出呼叫、從用戶或從PSTN(沒有示出)中提取或接收數據的計算機。
在RNC 810和MSC 830之間的業務使用Iu-CS接口828。Iu-CS接口828是用來在UTRAN 820和核心語音網絡之間執行(典型地)語音業務和信令的電路交換連接。所使用的主要信令協議是RANAP(無線接入網絡應用程式部分)。RANAP協議用於在核心網絡821和UTRAN 820之間的UMTS信令，核心網絡821可以是MSC 830或SSGN 850(下面更詳細定義)。RANAP協議是在3GPP TS 25.413V3.11.1(2002-09)和TS25.413 V5.7.0(2004-01)中定義的。
對於所有向網絡運營商註冊的UE 802來說，永久數據(例如，UE 102的用戶簡檔)以及臨時數據(例如UE 802的當前位置)被存儲在歸屬位置寄存器(HLR)838中。在對UE 802進行語音呼叫的情況下，查詢HLR 838來確定UE 802的當前位置。MSC 830的訪問位置寄存器(VLR)836負責位置區域組，並存儲當前處於其負責區域內的移動臺的數據。這包括了已經從HLR 838傳輸到VLR 836以更快接入的永久性移動臺數據部分。然而，MSC 830的VLR 836也可以分配和存儲本地數據，例如臨時標識。UE 802還在系統接入時由HLR838進行認證。
分組數據通過GPRS業務支持節點(SGSN)850進行路由。SGSN850是在GPRS/UMTS網絡中的RNC和核心網絡之間的網關，並負責數據分組自和至它的地理服務區域內的UE的傳送。Iu-PS接口848用於RNC 810和SGSN 859之間，並作為用來在UTRAN 820和核心數據網絡之間傳送(典型地)數據業務和信令的分組交換連接。所使用的主要信令協議是RANAP(如上面描述)。
SSGN 850與GPRS網關支持節點(GGSN)860進行通信。GGSN860是UMTS/GPRS網絡和其他諸如網際網路或專用網之間的接口。GGSN 860通過Gi接口連接到公共數據網絡PDN 870。
本領域熟練技術人員將理解，所述無線網絡可以連接到其他系統，可能包括其他網絡，在圖8中沒有明確示出。即使沒有要實際的分組數據交換，網絡通常也將在正在運行的基礎上傳輸尋呼和系統信息中的至少某類。雖然網絡由許多部分構成，但是這些部分都一起工作，從而在無線鏈路上產生特定行為。
在此所描述的實施例是具有與本申請的技術要素相對應的要素的結構、系統或方法的示例。該書面描述能夠使本領域熟練技術人員製造並使用具有同樣與本發明技術要素相對應的可選要素的實施例。因此，本申請的技術旨在保護的範圍包含不同於在此所描述的本申請技術的其他結構、系統或方法，並進一步包括與在此描述的本申請技術具有非實質不同的其他結構、系統或方法。
權利要求
1.一種用於處理用戶設備和無線網絡之間的信令釋放指示原因的方法，包括步驟a.在用戶設備處監視是否應當向所述無線網絡發送信令連接釋放指示；b.在用戶設備處將用於所述信令連接釋放指示的原因添加到所述信令連接釋放指示；c.將所添加的信令連接釋放指示發送到所述無線網絡；d.在所述無線網絡處接收所述信令連接釋放指示；以及e.過濾所述原因來確定是否產生告警。
2.根據權利要求1所述的方法，其中，所述原因是異常狀況。
3.根據權利要求2所述的方法，其中，所述異常狀況是定時器到期。
4.根據權利要求3所述的方法，其中，從由附著失敗定時器、路由區域更新定時器和GMM業務請求定時器構成的組中選擇所述定時器。
5.根據權利要求1所述的方法，其中，所述原因是用戶設備請求結束PS數據會話從而轉換到空閒模式的請求。
6.根據權利要求1所述的方法，其中，所述過濾步驟在所述原因為異常狀況時產生告警。
7.根據權利要求1所述的方法，其中，所述過濾步驟在所述原因是用戶設備的空閒轉換請求時，忽略所述信令連接釋放指示。
8.一種適於處理信令釋放指示原因的系統，所述系統包括a.用戶設備，所述用戶設備具有無線電子系統，包括適於與網絡通信的無線電設備；無線電處理器，具有數位訊號處理器，並適於與所述無線電子系統交互；存儲器；用戶接口；處理器，適於運行用戶應用程式並與所述存儲器、無線電設備和用戶接口交互、以及適於運行應用程式，所述用戶設備特徵在於具有裝置，所述裝置用於i.監視是否應當向所述無線網絡發送信令連接釋放指示；ii.將用於所述信令連接釋放指示的原因添加到所述信令連接釋放指示；以及iii.將所添加的信令連接釋放指示發送到所述無線網絡；以及b.適於與所述用戶設備通信的無線網絡，所述無線網絡進一步特徵在於裝置，所述裝置用於i.接收所述信令連接釋放指示；以及ii.過濾所述原因以確定是否產生告警。
9.根據權利要求8所述的系統，其中，所述原因是異常狀況。
10.根據權利要求9所述的系統，其中，所述異常狀況是定時器到期。
11.根據權利要求10所述的系統，其中，從由附著失敗定時器、路由區域更新定時器和GMM業務請求定時器構成的組中選擇所述定時器。
12.根據權利要求11所述的系統，其中，所述原因是用戶設備請求結束PS數據會話從而轉換到空閒模式的請求。
13.根據權利要求8所述的系統，其中，所述用於過濾的裝置適於在所述原因為異常狀況時產生告警。
14.根據權利要求8所述的系統，其中所述用於過濾的裝置適於在所述原因是用戶設備的空閒轉換請求時，忽略所述信令連接釋放指示。
15.一種用於在用戶設備上處理信令釋放指示原因以改進無線網絡處的告警跟蹤的方法，包括步驟a.監視是否應當向所述無線網絡發送信令連接釋放指示；b.將用於所述信令連接釋放指示的原因添加到所述信令連接釋放指示；以及c.發送添加了所述原因的所添加信令連接釋放指示，從而請求識別出了所述信令連接釋放指示原因的信令連接釋放。
16.根據權利要求15的方法，其中，所述原因是異常狀況。
17.根據權利要求16的方法，其中，所述異常狀況是定時器到期。
18.根據權利要求17的方法，其中，從由附著失敗定時器、路由區域更新定時器和GMM業務請求定時器構成的組中選擇所述定時器。
19.根據權利要求15的方法，其中，所述原因是用戶設備請求結束PS數據會話並轉換到空閒模式的請求。
20.一種適於在網絡中提供信令釋放指示原因的用戶設備，所述用戶設備具有無線電子系統，包括適於與所述網絡通信的無線電設備；無線處理器，具有數位訊號處理器並適於與所述無線電子系統交互；存儲器；用戶接口；處理器，適於運行用戶應用程式並與所述存儲器、無線電設備和用戶接口交互、以及適於運行應用程式，所述用戶設備特徵在於具有裝置，所述裝置用於a.監視是否應當向無線網絡發送信令連接釋放指示；b.將用於信令連接釋放指示的原因添加到所述信令連接釋放指示；以及c.發送包括所述原因的所添加信令連接釋放指示，從而識別所述信令連接釋放指示的原因以及所述信令連接釋放指示。
21.一種便於用戶設備釋放信令連接的裝置，所述裝置包括a.檢查器，配置用來檢查是否應當發送信令連接釋放指示；以及b.信令連接釋放指示發送器，配置用來響應所述檢查器的應當發送所述信令連接釋放指示的指示，來發送信令連接釋放指示，所述信令連接釋放指示包括包含有信令釋放指示原因欄位的信令釋放指示。
22.根據權利要求21所述的裝置，其中，所述檢查器進一步配置用來檢查在發送所述信令連接釋放指示之後、以及在確認傳送了所述信令連接釋放指示之前，是否需要用戶設備的信令連接。
23.根據權利要求22的裝置，其中，所述信令連接釋放指示發送器進一步配置用來重新傳輸所述信令連接釋放指示。
24.一種用於基於信令連接釋放指示進行操作的網絡裝置，所述網絡裝置包括a.檢驗器，配置用來檢驗所述信令連接釋放指示的信令釋放指示原因欄位，以檢查所述信令釋放指示原因欄位是否指示異常狀況；以及b.告警產生器，配置用來如果所述檢驗器的檢驗確定了所述信令釋放指示原因欄位指示所述異常狀況，則可選擇地產生告警。
25.根據權利要求24所述的網絡裝置，其中，所述網絡裝置包括邏輯層，其中所述檢驗器包含在邏輯層的第一層中，所述檢驗器進一步配置用來向邏輯層的第二層請求信令連接釋放。
全文摘要
一種在用戶設備和無線網絡之間處理信令釋放指示原因的方法和系統，所述方法包括步驟在用戶設備處監視是否應當向所述無線網絡發送信令連接釋放指示；在用戶設備處將用於所述信令連接釋放指示的原因添加到所述信令連接釋放指示；將所添加的信令連接釋放指示發送到所述無線網絡；在所述無線網絡處接收所述信令連接釋放指示；以及過濾所述原因來確定是否產生告警。
文檔編號H04B7/26GK101080102SQ20071013790
公開日2007年11月28日 申請日期2007年5月16日 優先權日2006年5月17日
發明者穆罕默德·哈立德·伊斯蘭, 傑弗裡·維爾塔南 申請人:捷訊研究有限公司