本發(fā)明涉及無線通信技術(shù)領(lǐng)域，尤其涉及一種?；钕⑻幚矸椒?、裝置、系統(tǒng)和相關(guān)設(shè)備。

背景技術(shù)：

隨著移動互聯(lián)網(wǎng)的發(fā)展，越來越多的“永遠(yuǎn)在線”業(yè)務(wù)應(yīng)運(yùn)而生。實現(xiàn)這種“永遠(yuǎn)在線”體驗的最重要而直接的方法是實施應(yīng)用層周期保活機(jī)制，使得網(wǎng)絡(luò)能夠?qū)崟r地了解應(yīng)用的無線鏈路狀態(tài)(例如，應(yīng)用在線、下線、位于網(wǎng)絡(luò)覆蓋空洞不可達(dá))，從而確定是否有必要/有能力同該應(yīng)用進(jìn)行即時交互；這種類型的應(yīng)用包含新聞更新、聊天信息等。

基于表1所示的參考業(yè)務(wù)評估模型，同時假設(shè)LTE(Long Term Evolution，長期演進(jìn))的RRC((Radio Resource Control，無線資源控制協(xié)議)閑置計時器設(shè)置為5s、用戶每分鐘跨越一個小區(qū)范圍(也就是對于站間距ISD＝500m，用戶的移動速率是30km/h)，得到?；钕⑼渌煌瑯I(yè)務(wù)的信令開銷評估比較，如表2所示。

表1參考業(yè)務(wù)評估模型

表2不同業(yè)務(wù)信令開銷評估表

其中，數(shù)據(jù)信令比(DSR)＝數(shù)據(jù)量/信令開銷，RRC建鏈拆鏈信令開銷(％)＝RRC連接釋放信令(bit)/總信令開銷(bit)，切換信令開銷(％)＝切換信令(bit)/總信令開銷(bit)，RRC維護(hù)信令開銷＝RRC維護(hù)信令(bit)/總信令開銷(％)。

從表2中可以看到：單個?；钕⒌臄?shù)據(jù)信令比為0.1075，即傳輸一份?；顢?shù)據(jù)需要附上10份信令。具體地，如果一個蜂窩范圍內(nèi)有200個用戶需要發(fā)送保活消息，產(chǎn)生的信令開銷大約為2.5個視頻用戶的數(shù)據(jù)傳輸量。特別地，?；钚帕畹拈_銷有90％以上是由RRC的建鏈拆鏈引發(fā)的，這是因為在RRC閑置計時時鐘的控制(用于管理RRC連接狀態(tài)下的用戶在沒有業(yè)務(wù)多長時間之后釋放RRC連接，進(jìn)入到RRC空閑態(tài))下，?；钕⒌臉I(yè)務(wù)特征使得用戶需要不斷同網(wǎng)絡(luò)建鏈拆鏈，引發(fā)大的RRC開銷。?；钕⑦@一業(yè)務(wù)特征一方面容易給造成網(wǎng)絡(luò)信令的擁塞，另一方面加劇終端耗電。

為解決上述問題，3GPP(3rd Generation Partnership Project，第三代合作伙 伴計劃)在R12中展開了“面向MTC((Machine-type Communications，及其類型通信)和小數(shù)據(jù)包優(yōu)化的研究議題”提出：在支持永遠(yuǎn)在線用戶體驗的心跳信息傳輸優(yōu)化方面，建議在網(wǎng)絡(luò)中引入應(yīng)用層次的代理網(wǎng)關(guān)，維護(hù)終端內(nèi)部IP和外部IP的半靜態(tài)/靜態(tài)映射關(guān)系；或者通過應(yīng)用服務(wù)器觸發(fā)核心網(wǎng)元維持而不釋放用戶的PDP(Packet Data Protocol，分組報文協(xié)議)上下文(終端IP地址及其具有特定QoS的邏輯承載)。此外，也有觀點認(rèn)為可以通過CS(Circuit Switched，電路交換)域通知推送信息的到達(dá)，降低應(yīng)用永遠(yuǎn)在線業(yè)務(wù)需求。

如圖1其分別為支撐NAS層傳遞小數(shù)據(jù)包的信令流程示意圖，包括以下步驟：

S11、UE(用戶設(shè)備)向MME(Mobility Management Entity，移動性管理實體)提交小數(shù)據(jù)包處理操作請求。

S12、UE向基站(eNB)發(fā)送隨機(jī)接入請求。

S13、eNB向UE返回隨機(jī)接入響應(yīng)。

S14、UE向eNB發(fā)送RRC連接建立請求。

S15、eNB向UE返回RRC連接建立指示。

S16、UE與eNB建立RRC連接。

S17、eNB向MME發(fā)送UE初始化消息。

其中，攜帶有S-TMSI，KSI、EPS Bear ID，UDP/IP packet。

S18、MME向P-GW/S–GW(分組數(shù)據(jù)網(wǎng)關(guān)/業(yè)務(wù)網(wǎng)關(guān))發(fā)送GTP-U。

其中，攜帶有TEID，UDP/IP packet。

S19、P-GW/S–GW向MME發(fā)送下行數(shù)據(jù)傳輸通知消息。

其中攜帶有Bear ID，UDP/IP response packet。

S110、MME向eNB發(fā)送下行數(shù)據(jù)非接入層傳輸消息。

S111、eNB向UE發(fā)送RRC連接釋放指示。

其中，攜帶有UDP/IP response packet。

如圖2所示，其為改進(jìn)后的傳輸MT數(shù)據(jù)包的信令流程示意圖，包括以下 步驟：

步驟a)、P-GW/S–GW向MME發(fā)送下行數(shù)據(jù)傳輸通知消息。

步驟b1)-步驟b2)MME向eNB發(fā)送paging(尋呼消息)，eNB向UE發(fā)送paging，UE向MME發(fā)送服務(wù)反饋消息。

其中，paging中攜帶有小數(shù)據(jù)包標(biāo)記信息。

步驟c)、MME向eNB發(fā)送下行數(shù)據(jù)非接入層傳輸消息，eNB向UE發(fā)送下行非接入層傳輸消息。

步驟d)、MME向P-GW/S–GW發(fā)送下行數(shù)據(jù)通知確認(rèn)消息。

此外，R12“面向MTC和小數(shù)據(jù)包優(yōu)化的研究議題”議題中提出的依賴NAS(Non-Access Stratum，非接入層)信令來承載小數(shù)據(jù)包的方式也可以應(yīng)用到保活小消息包的傳遞，可以大幅度節(jié)約信令的開銷。但是，該方案需要對現(xiàn)有的LTE終端進(jìn)行較大改動。

盡管3GPP提出的?；顧C(jī)制可以較好解決?；钣|發(fā)消息的開銷問題，但是由于無線鏈路環(huán)境的不可靠性，通過核心網(wǎng)配置維護(hù)用戶連接的方式，并不能真實反映用戶的可達(dá)性。保活信息(無論什么形式存在)依然是需要的、用于保證更高“永遠(yuǎn)在線”體驗。而通過NAS信令傳遞?；钕⒁约捌渌?shù)據(jù)包確實能夠大幅降低信令開銷，估計為將RRC信令開銷從200多字節(jié)減少到50多個字節(jié)，但是其需要對終端進(jìn)行較大改動。

綜上，如何在降低網(wǎng)絡(luò)信令開銷的同時兼容現(xiàn)有的網(wǎng)絡(luò)設(shè)計成為現(xiàn)有技術(shù)亟待解決的技術(shù)問題之一。

技術(shù)實現(xiàn)要素：

本發(fā)明實施例提供一種?；钕⑻幚矸椒?、裝置、系統(tǒng)和相關(guān)設(shè)備，用以在發(fā)送?；钕⑦^程中，降低網(wǎng)絡(luò)信令開銷的同時兼容現(xiàn)有的網(wǎng)絡(luò)設(shè)計。

本發(fā)明實施例提供網(wǎng)絡(luò)側(cè)實施的?；钕⑻幚矸椒?，包括：

在接收到第三方服務(wù)器發(fā)送的?；钣|發(fā)消息時，向用戶設(shè)備UE發(fā)送尋呼 消息；

在接收到所述UE根據(jù)所述尋呼消息發(fā)起的隨機(jī)接入過程中發(fā)送的連接建立請求后，根據(jù)其中攜帶的用戶標(biāo)識確定所述隨機(jī)接入過程為保活尋呼消息觸發(fā)時，向所述UE發(fā)送連接終止消息指示所述UE終止與網(wǎng)絡(luò)側(cè)建立連接，并向所述第三方服務(wù)器發(fā)送?；畲_認(rèn)消息。

其中，所述尋呼消息中攜帶有標(biāo)記所述尋呼消息為保活尋呼消息的標(biāo)記信息。

其中，按照以下過程確定接收到的消息為?；钣|發(fā)消息：

確定接收到的消息中攜帶有標(biāo)記所述消息為保活觸發(fā)消息的標(biāo)記信息；或者

確定通過預(yù)設(shè)的?；钣|發(fā)消息應(yīng)用程序接口API接收到所述消息；或者

利用深度包檢測DPI技術(shù)確定接收到的消息為?；钣|發(fā)消息。

所述第三方服務(wù)器包括用于維護(hù)用戶狀態(tài)的用戶狀態(tài)服務(wù)器或者提供應(yīng)用的應(yīng)用服務(wù)器。

本發(fā)明實施例提供第一種?；钕⑻幚硌b置，包括：

第一發(fā)送單元，用于在接收到第三方服務(wù)器發(fā)送的?；钣|發(fā)消息時，向用戶設(shè)備UE發(fā)送尋呼消息；

第二發(fā)送單元，用于在接收到所述UE根據(jù)所述尋呼消息發(fā)起的隨機(jī)接入過程中發(fā)送的連接建立請求后，根據(jù)其中攜帶的用戶標(biāo)識確定所述隨機(jī)接入過程為?；顚ず粝⒂|發(fā)時，向所述UE發(fā)送連接終止消息指示所述UE終止與網(wǎng)絡(luò)側(cè)建立連接，并向所述第三方服務(wù)器發(fā)送?；畲_認(rèn)消息。

所述第一發(fā)送單元，具體用于確定接收到的消息中攜帶有標(biāo)記所述消息為保活觸發(fā)消息的標(biāo)記信息時，確定接收到的消息為保活觸發(fā)消息；或者確定通過預(yù)設(shè)的保活觸發(fā)消息應(yīng)用程序接口API接收到的消息為?；钣|發(fā)消息；或者利用深度包檢測DPI技術(shù)確定接收到的消息為?；钣|發(fā)消息。

本發(fā)明實施例提供一種無線接入網(wǎng)絡(luò)設(shè)備，包括上述第一種保活消息處理 裝置。

本發(fā)明實施例提供一種用戶設(shè)備實施的?；钕⑻幚矸椒?，包括：

接收網(wǎng)絡(luò)側(cè)發(fā)送的尋呼消息；

根據(jù)所述尋呼消息向網(wǎng)絡(luò)側(cè)發(fā)起隨機(jī)接入過程中，接收到所述網(wǎng)絡(luò)側(cè)發(fā)送的連接終止消息時，終止與網(wǎng)絡(luò)側(cè)建立連接。

其中，所述尋呼消息中攜帶有標(biāo)記所述尋呼消息為?；顚ず粝⒌臉?biāo)記信。

按照以下方法向網(wǎng)絡(luò)側(cè)發(fā)起隨機(jī)接入：

向所述網(wǎng)絡(luò)側(cè)發(fā)送隨機(jī)接入請求；

接收所述網(wǎng)絡(luò)側(cè)返回的隨機(jī)接入響應(yīng)；

根據(jù)所述隨機(jī)接入響應(yīng)向所述網(wǎng)絡(luò)側(cè)發(fā)送連接建立請求；

接收所述網(wǎng)絡(luò)側(cè)發(fā)送的連接終止消息，其中，所述連接終止消息為所述網(wǎng)絡(luò)側(cè)確定所述隨機(jī)接入過程為所述?；钣|發(fā)消息觸發(fā)時發(fā)送的。

所述連接建立請求中攜帶有用戶標(biāo)識；以及所述?；畲_認(rèn)消息為所述網(wǎng)絡(luò)側(cè)根據(jù)所述用戶標(biāo)識確定所述隨機(jī)接入過程為所述保活觸發(fā)消息觸發(fā)時發(fā)送的。

本發(fā)明實施例提供第二種保活消息處理裝置，包括：

接收單元，用于接收網(wǎng)絡(luò)側(cè)發(fā)送的尋呼消息；

通信單元，用于根據(jù)所述尋呼消息向網(wǎng)絡(luò)側(cè)發(fā)起隨機(jī)接入過程中，接收到所述網(wǎng)絡(luò)側(cè)發(fā)送的連接終止消息時，終止與網(wǎng)絡(luò)側(cè)建立連接。

所述通信單元，包括：

發(fā)送子單元，用于向所述網(wǎng)絡(luò)側(cè)發(fā)送隨機(jī)接入請求；以及在接收子單元接收到所述網(wǎng)絡(luò)側(cè)返回的隨機(jī)接入響應(yīng)后，向所述網(wǎng)絡(luò)側(cè)發(fā)送連接建立請求；

接收子單元，用于接收所述網(wǎng)絡(luò)側(cè)根據(jù)所述隨機(jī)接入響應(yīng)返回的隨機(jī)接入響應(yīng)；以及接收所述網(wǎng)絡(luò)側(cè)發(fā)送的連接終止消息，其中，所述連接終止消息為所述網(wǎng)絡(luò)側(cè)確定所述隨機(jī)接入過程請求為所述?；钣|發(fā)消息觸發(fā)時發(fā)送的。

本發(fā)明實施例提供一種用戶設(shè)備，包括上述第二種?；钕⑻幚硌b置。

本發(fā)明實施例提供一種包括消息處理方法，包括：

向網(wǎng)絡(luò)側(cè)發(fā)送保活觸發(fā)消息；

接收所述網(wǎng)絡(luò)側(cè)返回的保活確認(rèn)消息，所述保活確認(rèn)消息為所述網(wǎng)絡(luò)側(cè)在接收到所述?；钣|發(fā)消息后向用戶設(shè)備UE發(fā)送尋呼消息以及在接收到所述UE根據(jù)所述尋呼消息發(fā)起的隨機(jī)接入過程中發(fā)送的連接建立請求后發(fā)送的，所述?；畲_認(rèn)消息用于指示所述UE終止與網(wǎng)絡(luò)側(cè)建立連接。

向網(wǎng)絡(luò)側(cè)發(fā)送?；钣|發(fā)消息，具體包括：

在向網(wǎng)絡(luò)側(cè)發(fā)送的消息中攜帶標(biāo)記所述消息為?；钣|發(fā)消息的標(biāo)記信息；或者

通過預(yù)設(shè)的?；钣|發(fā)消息應(yīng)用程序接口API向所述網(wǎng)絡(luò)側(cè)發(fā)送所述保活觸發(fā)消息。

本發(fā)明實施例提供第三種保活消息處理裝置，包括：

發(fā)送單元，用于向網(wǎng)絡(luò)側(cè)發(fā)送?；钣|發(fā)消息；

接收單元，用于接收所述網(wǎng)絡(luò)側(cè)返回的?；畲_認(rèn)消息，所述?；畲_認(rèn)消息為所述網(wǎng)絡(luò)側(cè)在接收到所述保活觸發(fā)消息后向用戶設(shè)備UE發(fā)送尋呼消息以及在接收到所述UE根據(jù)所述尋呼消息發(fā)起的隨機(jī)接入過程中發(fā)送的連接建立請求后發(fā)送的，所述保活確認(rèn)消息用于指示所述UE終止與網(wǎng)絡(luò)側(cè)建立連接。

所述發(fā)送單元，具體用于在向網(wǎng)絡(luò)側(cè)發(fā)送的消息中攜帶有標(biāo)記所述消息為保活觸發(fā)消息的標(biāo)記信息；或者用于通過預(yù)設(shè)的?；钣|發(fā)消息應(yīng)用程序接口API向所述網(wǎng)絡(luò)側(cè)發(fā)送所述?；钣|發(fā)消息。

本發(fā)明實施例提供一種服務(wù)器，包括上述第三種保活消息處理裝置。

本發(fā)明實施例提供一種保活消息處理系統(tǒng)，包括上述的無線接入網(wǎng)絡(luò)設(shè)備、用戶設(shè)備和服務(wù)器。

本發(fā)明實施例提供的?；钕⑻幚矸椒ā⒀b置、系統(tǒng)和相關(guān)設(shè)備，當(dāng)網(wǎng)絡(luò)側(cè)接收到第三方服務(wù)器發(fā)送的?；钣|發(fā)消息時，通過尋呼消息觸發(fā)UE發(fā)起隨 機(jī)接入流程，網(wǎng)絡(luò)側(cè)在接收到UE根據(jù)該尋呼消息發(fā)起的隨機(jī)接入過程中發(fā)送的連接建立請求后，根據(jù)其中攜帶的用戶標(biāo)識確定該隨機(jī)接入過程為?；顚ず粝⒂|發(fā)時，向UE發(fā)送連接終止消息指示UE終止與網(wǎng)絡(luò)側(cè)建立連接；并向第三方服務(wù)器發(fā)送?；畲_認(rèn)消息。上述過程中，由于UE并未與網(wǎng)絡(luò)側(cè)真正建立連接，從而節(jié)約了UE與網(wǎng)絡(luò)側(cè)建鏈拆鏈等所需的信令開銷，同時，本發(fā)明實施例提供的方法對UE改動較小，從而能夠兼容現(xiàn)有的網(wǎng)絡(luò)設(shè)計。

本發(fā)明的其它特征和優(yōu)點將在隨后的說明書中闡述，并且，部分地從說明書中變得顯而易見，或者通過實施本發(fā)明而了解。本發(fā)明的目的和其他優(yōu)點可通過在所寫的說明書、權(quán)利要求書、以及附圖中所特別指出的結(jié)構(gòu)來實現(xiàn)和獲得。

附圖說明

此處所說明的附圖用來提供對本發(fā)明的進(jìn)一步理解，構(gòu)成本發(fā)明的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當(dāng)限定。在附圖中：

圖1為現(xiàn)有技術(shù)中，支撐NAS層傳遞小數(shù)據(jù)包的信令流程示意圖；

圖2為現(xiàn)有技術(shù)中，改進(jìn)后的傳輸MT數(shù)據(jù)包的信令流程示意圖；

圖3為本發(fā)明實施例中，保活消息處理流程示意圖；

圖4為本發(fā)明實施例中，無線接入網(wǎng)絡(luò)設(shè)備實施?；钕⑻幚淼膶嵤┝鞒淌疽鈭D；

圖5為本發(fā)明實施例中，第一種?；钕⑻幚硌b置的結(jié)構(gòu)示意圖；

圖6為本發(fā)明實施例中，用戶設(shè)備實施保活消息處理的實施流程示意圖；

圖7為本發(fā)明實施例中，第二種?；钕⑻幚硌b置的結(jié)構(gòu)示意圖；

圖8a為本發(fā)明實施例中，用戶狀態(tài)服務(wù)器實施保活消息處理的實施流程示意圖；

圖8b為本發(fā)明實施例中，應(yīng)用服務(wù)器實施保活消息處理的實施流程示意圖；

圖9為本發(fā)明實施例中，第三種?；钕⑻幚硌b置的結(jié)構(gòu)示意圖；

圖10為本發(fā)明實施例中，?；钕⑻幚硐到y(tǒng)的結(jié)構(gòu)示意圖。

具體實施方式

本發(fā)明實施例提供一種通過尋呼觸發(fā)的?；钕⑻幚矸椒?，由服務(wù)器向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送?；钣|發(fā)消息，無線接入網(wǎng)絡(luò)設(shè)備向用戶設(shè)備(UE，UserEquipment)發(fā)送尋呼請求，其中攜帶有該尋呼請求為保活尋呼消息(即由?；钣|發(fā)消息觸發(fā)的尋呼消息)的標(biāo)記信息，當(dāng)用戶設(shè)備接收到尋呼消之后，發(fā)起傳統(tǒng)的隨機(jī)接入流程接入到網(wǎng)絡(luò)中，在此過程中，UE向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送連接建立請求(MT，Mobile Terminate，下行觸發(fā)業(yè)務(wù))時，無線接入網(wǎng)絡(luò)設(shè)備識別出UE下行尋呼是?；顚ず?，發(fā)送連接終止消息，以指示UE終止正在建立的連接。并向第三方服務(wù)器發(fā)送?；畲_認(rèn)消息，完成?；钸^程。

以下結(jié)合說明書附圖對本發(fā)明的優(yōu)選實施例進(jìn)行說明，應(yīng)當(dāng)理解，此處所描述的優(yōu)選實施例僅用于說明和解釋本發(fā)明，并不用于限定本發(fā)明，并且在不沖突的情況下，本發(fā)明中的實施例及實施例中的特征可以相互組合。

如圖3所示，為本發(fā)明實施例提供的?；钐幚硐⒌膶嵤┝鞒淌疽鈭D，可以包括以下步驟：

S31、第三方服務(wù)器向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送?；钣|發(fā)消息。

其中，第三方服務(wù)器可以為運(yùn)營商提供的用于維護(hù)用戶狀態(tài)的用戶狀態(tài)服務(wù)器，也可以為提供應(yīng)用的應(yīng)用服務(wù)器。

較佳的，具體實施時，第三方服務(wù)器在向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送的消息為?；钣|發(fā)消息時，則第三方服務(wù)器可以在發(fā)送的消息中攜帶有標(biāo)記該消息為?；钣|發(fā)消息的標(biāo)記信息；或者，第三方服務(wù)器在向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送?；钣|發(fā)消息時，可以通過預(yù)設(shè)的?；钣|發(fā)消息專用應(yīng)用程序接口(API，Application Programmable Interface)發(fā)送該?；钣|發(fā)消息；當(dāng)然，具體實施時，第三方服務(wù)器還可以以普通消息形式發(fā)送該保活觸發(fā)消息，由無線接入網(wǎng)絡(luò)設(shè) 備接收該?；钣|發(fā)消息的API利用DPI(深度包檢測)等技術(shù)檢測其接收到的消息是否為?；钣|發(fā)消息。

S32、無線接入網(wǎng)絡(luò)設(shè)備向UE發(fā)送尋呼消息。

具體的，無線接入網(wǎng)絡(luò)設(shè)備確定接收到的消息為保活觸發(fā)消息時，向UE發(fā)送尋呼消息。

與第三方服務(wù)器發(fā)送?；钣|發(fā)消息的方式相對應(yīng)，這里無線接入網(wǎng)絡(luò)設(shè)備也可以通過以下三種方式中的任一種確定第三方服務(wù)器發(fā)送的消息為?；钣|發(fā)消息。

第一種確定方式

如果第三方服務(wù)器在發(fā)送的消息中攜帶有標(biāo)記該消息為?；钣|發(fā)消息的標(biāo)記信息時，則無線接入網(wǎng)絡(luò)設(shè)備可以根據(jù)該標(biāo)記信息確定第三方服務(wù)器發(fā)送的消息為?；钣|發(fā)消息。

第二種確定方式

如果第三方服務(wù)器通過?；钣|發(fā)消息專用API發(fā)送消息時，則則無線接入網(wǎng)絡(luò)設(shè)備可以根據(jù)接收到消息的API是否為?；钣|發(fā)消息專用API來判斷第三方服務(wù)器發(fā)送的消息是否為保活觸發(fā)消息。如果判斷出第三方服務(wù)器為通過?；钣|發(fā)消息專用API發(fā)送的消息，則可以確定第三方服務(wù)器發(fā)送的消息為?；钣|發(fā)消息。

第三種確定方式

如果第三方服務(wù)器以普通消息形式發(fā)送保活觸發(fā)消息，則無線接入網(wǎng)絡(luò)設(shè)備可以利用DPI(深度包檢測，Deep Packet Inspecion)技術(shù)檢測其接收到消息是否為保活觸發(fā)消息。

具體實施時，網(wǎng)絡(luò)側(cè)在向UE發(fā)送由?；钣|發(fā)消息觸發(fā)的尋呼消息時，對UE來說可以是透明的，即網(wǎng)絡(luò)側(cè)向UE發(fā)送普通尋呼消息，而在UE根據(jù)尋呼消息在發(fā)起隨機(jī)接入過程中發(fā)送的連接建立請求時，網(wǎng)絡(luò)側(cè)根據(jù)其中攜帶的用戶標(biāo)識識別出該UE為發(fā)送的隨機(jī)接入為保活尋呼消息觸發(fā)時，則向該UE發(fā) 送連接終止消息，指示UE終止與網(wǎng)絡(luò)側(cè)建立。

為了便于描述，本發(fā)明實施例中將由保活觸發(fā)消息觸發(fā)的尋呼消息稱為?；顚ず粝?。

當(dāng)然，無線接入網(wǎng)絡(luò)設(shè)備可以在向UE發(fā)送的尋呼消息中攜帶有標(biāo)記該尋呼消息為?；顚ず粝?即由?；钣|發(fā)消息觸發(fā)的尋呼消息)，以使得用戶識別該尋呼消息為保活尋呼消息。

較佳的，由于?；顚ず粝⒂袝r需要面向大量UE的大范圍尋呼，這種情況下，可以預(yù)先將UE按照用戶標(biāo)識進(jìn)行分組，基于同一組UE進(jìn)行保活尋呼，以節(jié)約尋呼開銷。

S33、UE向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送隨機(jī)接入請求。

具體的，UE根據(jù)接收到的尋呼消息向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送隨機(jī)接入請求。

具體實施時，UE在接收到針對其個體或者針對其所屬廣播標(biāo)識的尋呼消息之后，向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送隨機(jī)接入請求。

S34、無線接入網(wǎng)絡(luò)設(shè)備向該UE發(fā)送隨機(jī)接入響應(yīng)。

具體的，無線接入網(wǎng)絡(luò)設(shè)備接收到UE發(fā)送的隨機(jī)接入請求后，向該UE發(fā)送隨機(jī)接入響應(yīng)。

S35、UE向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送連接建立請求。

步驟S35中，UE在向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送的連接建立請求中攜帶自身的用戶標(biāo)識，使得無線接入網(wǎng)絡(luò)設(shè)備可以根據(jù)該用戶標(biāo)識識別出其為保活尋呼消息的目標(biāo)用戶。

S36、無線接入網(wǎng)絡(luò)設(shè)備向UE發(fā)送連接終止消息。

S37、無線接入網(wǎng)絡(luò)設(shè)備向第三方服務(wù)器發(fā)送?；畲_認(rèn)消息。

具體的，無線接入網(wǎng)絡(luò)設(shè)備判斷出UE發(fā)送的連接建立請求為尋呼?；钣|發(fā)消息觸發(fā)時，則向用戶發(fā)送連接終止消息用于指示用戶終止后續(xù)的連接行為。并將保活確認(rèn)消息同步至第三方服務(wù)器。如果無線接入網(wǎng)絡(luò)設(shè)備未在預(yù)設(shè) 時間內(nèi)接收到所述UE發(fā)送的隨機(jī)接入請求，或者第三方服務(wù)器在預(yù)設(shè)時間內(nèi)未接收到?；畲_認(rèn)消息，則認(rèn)為用戶?；钪袛唷?/p>

與步驟S32中無線接入網(wǎng)絡(luò)設(shè)備確定第三方服務(wù)器發(fā)送的消息為?；钣|發(fā)消息的確定方式相對應(yīng)，無線接入網(wǎng)絡(luò)設(shè)備向第三方服務(wù)器發(fā)送?；畲_認(rèn)消息也可以由如下三種實現(xiàn)方式：

實現(xiàn)方式一、

無線接入網(wǎng)絡(luò)設(shè)備向第三方服務(wù)器發(fā)送的保活確認(rèn)消息中攜帶有標(biāo)記該消息為?；畲_認(rèn)消息的標(biāo)記信息，使得第三方服務(wù)器可以根據(jù)該標(biāo)記信息識別出接收到的消息為保活確認(rèn)消息。

實現(xiàn)方式二、

無線接入網(wǎng)絡(luò)設(shè)備通過保活確認(rèn)消息專用API向第三方服務(wù)器反饋?；畲_認(rèn)消息，該?；畲_認(rèn)消息專用API可供第三方服務(wù)器查詢用戶狀態(tài)。第三方服務(wù)器判斷接收到的消息是否為通過?；畲_認(rèn)消息專用API接收到，便可確定接收到的消息是否為?；畲_認(rèn)消息。

實現(xiàn)方式三、

無線接入網(wǎng)絡(luò)設(shè)備以普通的消息形式發(fā)送?；畲_認(rèn)消息，由第三方服務(wù)器接收消息的API利用DPI技術(shù)檢測接收到的消息是否為?；畲_認(rèn)消息即可。

相應(yīng)的，第三方服務(wù)器也可以按照以下三種方式中的任一種確定接收到的消息為?；畲_認(rèn)消息：

方式一、

如果無線接入網(wǎng)絡(luò)設(shè)備在向第三方服務(wù)器發(fā)送的消息中攜帶有標(biāo)記該消息為?；畲_認(rèn)消息的標(biāo)記信息時，第三方服務(wù)器可以根據(jù)該標(biāo)記信息識別出無線接入網(wǎng)絡(luò)設(shè)備發(fā)送的消息為保活確認(rèn)消息。

方式二、

如果無線接入網(wǎng)絡(luò)設(shè)備通過?；畲_認(rèn)消息專用API向第三方服務(wù)器反饋?；畲_認(rèn)消息，則第三方服務(wù)器判斷接收到的消息是否為通過保活確認(rèn)消息專 用API接收到，便可確定接收到的消息是否為保活確認(rèn)消息。

方式三、

如果無線接入網(wǎng)絡(luò)設(shè)備以普通的消息形式發(fā)送?；畲_認(rèn)消息，則第三方服務(wù)器接收到消息的API可以利用DPI技術(shù)檢測收到的消息是否為?；畲_認(rèn)消息。

需要說明的是，無線接入網(wǎng)絡(luò)設(shè)備向UE和第三方服務(wù)器發(fā)送?；畲_認(rèn)消息不分先后，兩者也可以同時執(zhí)行。

S38、UE接收到?；畲_認(rèn)消息后，終止與網(wǎng)絡(luò)側(cè)建立連接。

本發(fā)明實施例提供的保活觸發(fā)消息處理方法，網(wǎng)絡(luò)側(cè)在接收到?；钣|發(fā)消息時，通過?；顚ず粝⒂|發(fā)UE隨機(jī)接入流程，在該UE發(fā)送連接建立請求之后，網(wǎng)絡(luò)側(cè)向UE發(fā)送終止連接的?；畲_認(rèn)消息，由此，UE無須與網(wǎng)絡(luò)側(cè)頻繁的執(zhí)行建鏈拆鏈操作，減少了網(wǎng)絡(luò)信令開銷，且對UE改動較小，因此能夠兼容現(xiàn)有的網(wǎng)絡(luò)設(shè)計。

本發(fā)明實施例提供的尋呼保活處理方法使得網(wǎng)絡(luò)能夠結(jié)合網(wǎng)絡(luò)的狀態(tài)(網(wǎng)絡(luò)忙時和網(wǎng)絡(luò)閑時)以及應(yīng)用對?；畹男枨笥|發(fā)保活行為，一方面，可以保證?；钣|發(fā)消息不會給網(wǎng)絡(luò)造成大的負(fù)擔(dān)，另一方面，使得保活行為按需為下行推送服務(wù)。另外，本發(fā)明實施例提供的尋呼?；钐幚矸椒?，盡可能節(jié)約由于發(fā)送?；钣|發(fā)消息而造成的網(wǎng)絡(luò)信令開銷，另一方面，對于UE改動相對較小，UE只需要識別網(wǎng)絡(luò)最后發(fā)送的?；畲_認(rèn)消息，并根據(jù)?；畲_認(rèn)消息終止與網(wǎng)絡(luò)側(cè)建立的連接。

基于同一發(fā)明構(gòu)思，本發(fā)明實施例分別提供了一種無線接入網(wǎng)絡(luò)側(cè)、UE側(cè)和第三方服務(wù)器側(cè)實施的?；钕⑻幚矸椒?、裝置和設(shè)備以及一種?；钕⑻幚硐到y(tǒng)，由于上述方法、裝置、設(shè)備和系統(tǒng)解決問題的原理與上述的?；钕⑻幚矸椒ㄏ嗨?，因此上述方法、裝置、設(shè)備和系統(tǒng)的實施可以參見方法的實施，重復(fù)之處不再贅述。

如圖4所示，為無線接入網(wǎng)絡(luò)側(cè)實施?；钕⑻幚矸椒ǖ膶嵤┝鞒淌疽鈭D， 可以包括以下步驟：

S41、在接收到第三方服務(wù)器發(fā)送的保活觸發(fā)消息時，向UE發(fā)送尋呼消息。

較佳的，可以在向UE發(fā)送的尋呼消息中攜帶有標(biāo)記所述尋呼消息為?；顚ず粝⒌臉?biāo)記信息。

S42、在接收到UE根據(jù)接收到的尋呼消息發(fā)起的隨機(jī)接入過程中發(fā)送的連接建立請求后，根據(jù)其中攜帶的用戶標(biāo)識確定該隨機(jī)接入過程為?；顚ず粝⒂|發(fā)時，向該UE發(fā)送連接終止消息指示該UE終止與網(wǎng)絡(luò)側(cè)建立連接，并向第三方服務(wù)器發(fā)送保活確認(rèn)消息。

具體實施時，可以按照以下任一方式向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送?；钣|發(fā)消息：

第三方服務(wù)器在向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送?；钣|發(fā)消息時，在發(fā)送的消息中攜帶有標(biāo)記該消息為?；钣|發(fā)消息的標(biāo)記信息；或者，第三方服務(wù)器在需要向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送保活觸發(fā)消息時，可以通過預(yù)設(shè)的?；钣|發(fā)消息專用應(yīng)用程序接口(API，Application Programmable Interface)發(fā)送該?；钣|發(fā)消息；當(dāng)然，具體實施時，第三方服務(wù)器還可以以普通消息形式發(fā)送該?；钣|發(fā)消息，由無線接入網(wǎng)絡(luò)設(shè)備接收該?；钣|發(fā)消息的API檢測其接收到的消息是否為?；钣|發(fā)消息。

相應(yīng)的，步驟S41中，可以按照以下任一方式確定接收到的消息為?；钣|發(fā)消息：

第一種確定方式

如果第三方服務(wù)器在發(fā)送的消息中攜帶有標(biāo)記該消息為保活觸發(fā)消息的標(biāo)記信息時，則無線接入網(wǎng)絡(luò)設(shè)備可以根據(jù)該標(biāo)記信息確定第三方服務(wù)器發(fā)送的消息為保活觸發(fā)消息。

第二種確定方式

如果第三方服務(wù)器通過?；钣|發(fā)消息專用API發(fā)送消息時，則則無線接入 網(wǎng)絡(luò)設(shè)備可以根據(jù)接收到消息的API是否為?；钣|發(fā)消息專用API來判斷第三方服務(wù)器發(fā)送的消息是否為?；钣|發(fā)消息。如果判斷出第三方服務(wù)器為通過?；钣|發(fā)消息專用API發(fā)送的消息，則可以確定第三方服務(wù)器發(fā)送的消息為?；钣|發(fā)消息。

第三種確定方式

如果第三方服務(wù)器以普通消息形式發(fā)送保活觸發(fā)消息，則無線接入網(wǎng)絡(luò)設(shè)備可以利用DPI(深度包檢測，Deep Packet Inspecion)技術(shù)檢測其接收到消息是否為?；钣|發(fā)消息。

無線接入網(wǎng)絡(luò)設(shè)備在向UE發(fā)送的尋呼消息中攜帶有標(biāo)記該尋呼消息為保活尋呼消息(即由?；钣|發(fā)消息觸發(fā)的尋呼消息)。較佳的，由于?；顚ず粝⒂袝r需要面向大量UE的大范圍尋呼，這種情況下，可以預(yù)先將UE按照用戶標(biāo)識進(jìn)行分組，基于同一組UE進(jìn)行?；顚ず?，以節(jié)約尋呼開銷。

UE在接收到針對其個體或者針對其所屬廣播標(biāo)識的保活尋呼消息之后，向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送隨機(jī)接入請求。無線接入網(wǎng)絡(luò)設(shè)備接收到UE發(fā)送的隨機(jī)接入請求后，向該UE發(fā)送隨機(jī)接入響應(yīng)。UE在向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送的連接建立請求中攜帶自身的用戶標(biāo)識，使得無線接入網(wǎng)絡(luò)設(shè)備可以根據(jù)該用戶標(biāo)識識別出其為?；顚ず粝⒌哪繕?biāo)用戶。這樣，無線接入網(wǎng)絡(luò)設(shè)備判斷出UE發(fā)送的連接建立請求為尋呼?；钣|發(fā)消息觸發(fā)時，則向UE發(fā)送連接終止消息用于指示UE終止后續(xù)的連接行為，并向第三方服務(wù)器發(fā)送保活確認(rèn)消息。如果無線接入網(wǎng)絡(luò)設(shè)備未在預(yù)設(shè)時間內(nèi)接收到所述UE發(fā)送的隨機(jī)接入請求，或者第三方服務(wù)器在預(yù)設(shè)時間內(nèi)未接收到?；畲_認(rèn)消息，則認(rèn)為用戶?；钪袛?。

與上述無線接入網(wǎng)絡(luò)設(shè)備確定第三方服務(wù)器發(fā)送的消息為?；钣|發(fā)消息的確定方式相對應(yīng)，無線接入網(wǎng)絡(luò)設(shè)備向第三方服務(wù)器發(fā)送?；畲_認(rèn)消息也可以由如下三種實現(xiàn)方式：

實現(xiàn)方式一、

無線接入網(wǎng)絡(luò)設(shè)備向第三方服務(wù)器發(fā)送的保活確認(rèn)消息中攜帶有標(biāo)記該消息為?；畲_認(rèn)消息的標(biāo)記信息，使得第三方服務(wù)器可以根據(jù)該標(biāo)記信息識別出接收到的消息為?；畲_認(rèn)消息。

實現(xiàn)方式二、

無線接入網(wǎng)絡(luò)設(shè)備通過把?；畲_認(rèn)消息專用API向第三方服務(wù)器反饋?；畲_認(rèn)消息，該保活確認(rèn)消息專用API可供第三方服務(wù)器查詢用戶狀態(tài)。第三方服務(wù)器判斷接收到的消息是否為通過?；畲_認(rèn)消息專用API接收到，便可確定接收到的消息是否為?；畲_認(rèn)消息。

實現(xiàn)方式三、

無線接入網(wǎng)絡(luò)設(shè)備以普通的消息形式發(fā)送?；畲_認(rèn)消息，由第三方服務(wù)器接收消息的API利用DPI技術(shù)檢測接收到的消息是否為?；畲_認(rèn)消息即可。

需要說明的是，無線接入網(wǎng)絡(luò)設(shè)備向UE和第三方服務(wù)器發(fā)送?；畲_認(rèn)消息不分先后，兩者也可以同時執(zhí)行。

如圖5所示，為本發(fā)明實施例提供的第一種?；钕⑻幚硌b置的結(jié)構(gòu)示意圖，包括：

第一發(fā)送單元51，用于在接收到第三方服務(wù)器發(fā)送的保活觸發(fā)消息時，向UE發(fā)送尋呼消息；

第二發(fā)送單元52，用于在接收到所述UE根據(jù)所述尋呼消息發(fā)起的隨機(jī)接入過程中發(fā)送的連接建立請求后，根據(jù)其中攜帶的用戶標(biāo)識確定所述隨機(jī)接入過程為保活尋呼消息觸發(fā)時，向所述UE發(fā)送連接終止消息指示所述UE終止與網(wǎng)絡(luò)側(cè)建立連接，并向所述第三方服務(wù)器發(fā)送?；畲_認(rèn)消息。

其中，第一發(fā)送單元51，可以用于確定接收到的消息中攜帶有標(biāo)記該消息為保活觸發(fā)消息的標(biāo)記信息時，確定接收到的消息為保活觸發(fā)消息；或者確定通過預(yù)設(shè)的?；钣|發(fā)消息應(yīng)用程序接口API接收到的消息為保活觸發(fā)消息；或者利用深度包檢測DPI技術(shù)確定接收到的消息為保活觸發(fā)消息。

為了描述的方便，以上各部分按照功能劃分為各模塊(或單元)分別描述。 當(dāng)然，在實施本發(fā)明時可以把各模塊(或單元)的功能在同一個或多個軟件或硬件中實現(xiàn)。具體實施時，本發(fā)明實施例提供的第一種?；钣|發(fā)消息處理裝置可以設(shè)置于無線接入網(wǎng)絡(luò)設(shè)備。

如圖6所示，為本發(fā)明實施例提供的UE側(cè)實施?；钕⑻幚矸椒ǖ膶嵤┝鞒淌疽鈭D，可以包括以下步驟：

S61、接收網(wǎng)絡(luò)側(cè)發(fā)送的尋呼消息。

較佳的，網(wǎng)絡(luò)側(cè)可以在該尋呼消息中攜帶有標(biāo)記所述尋呼消息為保活尋呼消息的標(biāo)記信息。

具體實施時，網(wǎng)絡(luò)側(cè)在接收到第三方服務(wù)器發(fā)送的?；钣|發(fā)消息時，向UE發(fā)送尋呼消息。

S62、根據(jù)尋呼消息向網(wǎng)絡(luò)側(cè)發(fā)起隨機(jī)接入過程中，接收到網(wǎng)絡(luò)側(cè)發(fā)送的連接終止時，終止與網(wǎng)絡(luò)側(cè)建立連接。

較佳的，UE可以按照以下步驟向網(wǎng)絡(luò)側(cè)發(fā)起隨機(jī)接入：

步驟一、UE向網(wǎng)絡(luò)側(cè)發(fā)送隨機(jī)接入請求。

步驟二、UE接收網(wǎng)絡(luò)側(cè)返回的隨機(jī)接入響應(yīng)。

步驟三、UE根據(jù)接收到的隨機(jī)接入響應(yīng)向網(wǎng)絡(luò)側(cè)發(fā)送連接建立請求。

步驟四、UE接收網(wǎng)絡(luò)側(cè)發(fā)送的連接終止消息。

其中，連接終止消息為網(wǎng)絡(luò)側(cè)確定本次隨機(jī)接入過程為保活尋呼消息觸發(fā)時發(fā)送的。

具體的，UE根據(jù)接收到的尋呼消息向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送隨機(jī)接入請求。無線接入網(wǎng)絡(luò)設(shè)備接收到UE發(fā)送的隨機(jī)接入請求后，向該UE發(fā)送隨機(jī)接入響應(yīng)。UE向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送連接建立請求。UE在向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送的連接建立請求中攜帶自身的用戶標(biāo)識，使得無線接入網(wǎng)絡(luò)設(shè)備可以根據(jù)該用戶標(biāo)識識別出其為?；顚ず粝⒌哪繕?biāo)用戶。無線接入網(wǎng)絡(luò)設(shè)備判斷出UE發(fā)送的連接建立請求為尋呼?；钣|發(fā)消息觸發(fā)時，則向用戶發(fā)送連接終止消息用于指示用戶終止后續(xù)的連接行為。UE接收到連接終止消息后，終止 與網(wǎng)絡(luò)側(cè)建立連接。

如果無線接入網(wǎng)絡(luò)設(shè)備未在預(yù)設(shè)時間內(nèi)接收到UE發(fā)送的隨機(jī)接入請求，則認(rèn)為用戶?；钪袛?。

如圖7所示，為本發(fā)明實施例提供的第二種?；钕⑻幚硌b置的結(jié)構(gòu)示意圖，包括：

接收單元71，用于接收網(wǎng)絡(luò)側(cè)發(fā)送的尋呼消息；

通信單元72，用于根據(jù)該尋呼消息向網(wǎng)絡(luò)側(cè)發(fā)起隨機(jī)接入過程中，接收到所述網(wǎng)絡(luò)側(cè)發(fā)送的連接終止消息時，終止與網(wǎng)絡(luò)側(cè)建立連接。

較佳的，通信單元72可以包括：

發(fā)送子單元，用于向所述網(wǎng)絡(luò)側(cè)發(fā)送隨機(jī)接入請求；以及在接收子單元接收到所述網(wǎng)絡(luò)側(cè)返回的隨機(jī)接入響應(yīng)后，向所述網(wǎng)絡(luò)側(cè)發(fā)送連接建立請求；

接收子單元，用于接收所述網(wǎng)絡(luò)側(cè)根據(jù)所述隨機(jī)接入響應(yīng)返回的隨機(jī)接入響應(yīng)；以及接收所述網(wǎng)絡(luò)側(cè)發(fā)送的連接終止消息，其中，所述連接終止消息為所述網(wǎng)絡(luò)側(cè)確定所述隨機(jī)接入過程為所述?；钣|發(fā)消息觸發(fā)時發(fā)送的。

為了描述的方便，以上各部分按照功能劃分為各模塊(或單元)分別描述。當(dāng)然，在實施本發(fā)明時可以把各模塊(或單元)的功能在同一個或多個軟件或硬件中實現(xiàn)。具體實施時，本發(fā)明實施例提供的第二種?；钕⑻幚硌b置可以設(shè)置于用戶設(shè)備中。

如圖8a所示，為本發(fā)明實施例提供的用戶狀態(tài)服務(wù)器實施?；钕⑻幚矸椒ǖ膶嵤┝鞒淌疽鈭D，可以包括以下步驟：

S81、用戶狀態(tài)服務(wù)器向網(wǎng)絡(luò)側(cè)發(fā)送?；钣|發(fā)消息。

具體實施時，用戶狀態(tài)服務(wù)器可以按照以下任一方式向網(wǎng)絡(luò)側(cè)的無線接入網(wǎng)絡(luò)設(shè)備發(fā)送?；钣|發(fā)消息：

用戶狀態(tài)服務(wù)器在向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送?；钣|發(fā)消息時，在發(fā)送的消息中攜帶有標(biāo)記該消息為?；钣|發(fā)消息的標(biāo)記信息；或者，用戶狀態(tài)服務(wù)器在需要向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送保活觸發(fā)消息時，可以通過預(yù)設(shè)的保活觸發(fā)消息 專用應(yīng)用程序接口(API，Application Programmable Interface)發(fā)送該?；钣|發(fā)消息；當(dāng)然，具體實施時，用戶狀態(tài)服務(wù)器還可以以普通消息形式發(fā)送該?；钣|發(fā)消息，由無線接入網(wǎng)絡(luò)設(shè)備接收該?；钣|發(fā)消息的API檢測其接收到的消息是否為保活觸發(fā)消息。

S82、用戶狀態(tài)服務(wù)器接收網(wǎng)絡(luò)側(cè)返回的?；畲_認(rèn)消息。

其中，?；畲_認(rèn)消息為網(wǎng)絡(luò)側(cè)在接收到?；钣|發(fā)消息后向UE(用戶設(shè)備)發(fā)送尋呼消息以及在接收到所述UE根據(jù)所述尋呼消息發(fā)起的隨機(jī)接入過程中發(fā)送的連接建立請求后發(fā)送的，所述?；畲_認(rèn)消息用于指示所述UE終止與網(wǎng)絡(luò)側(cè)建立連接。

具體實施時，與用戶狀態(tài)服務(wù)器發(fā)送?；钣|發(fā)消息的方式相對應(yīng)，網(wǎng)絡(luò)側(cè)的無線接入網(wǎng)絡(luò)設(shè)備也可以通過以下三種方式中的任一種確定用戶狀態(tài)服務(wù)器發(fā)送的消息為?；钣|發(fā)消息。

第一種確定方式

如果用戶狀態(tài)服務(wù)器在發(fā)送的消息中攜帶有標(biāo)記該消息為?；钣|發(fā)消息的標(biāo)記信息時，則無線接入網(wǎng)絡(luò)設(shè)備可以根據(jù)該標(biāo)記信息確定用戶狀態(tài)服務(wù)器發(fā)送的消息為?；钣|發(fā)消息。

第二種確定方式

如果用戶狀態(tài)服務(wù)器通過?；钣|發(fā)消息專用API發(fā)送消息時，則則無線接入網(wǎng)絡(luò)設(shè)備可以根據(jù)接收到消息的API是否為?；钣|發(fā)消息專用API來判斷用戶狀態(tài)服務(wù)器發(fā)送的消息是否為?；钣|發(fā)消息。如果判斷出用戶狀態(tài)服務(wù)器為通過?；钣|發(fā)消息專用API發(fā)送的消息，則可以確定用戶狀態(tài)服務(wù)器發(fā)送的消息為?；钣|發(fā)消息。

第三種確定方式

如果用戶狀態(tài)服務(wù)器以普通消息形式發(fā)送?；钣|發(fā)消息，則無線接入網(wǎng)絡(luò)設(shè)備可以利用DPI(深度包檢測，Deep Packet Inspecion)技術(shù)檢測其接收到消息是否為?；钣|發(fā)消息。

無線接入網(wǎng)絡(luò)設(shè)備確定接收到的消息為?；钣|發(fā)消息時，向UE發(fā)送尋呼消息。無線接入網(wǎng)絡(luò)設(shè)備可以在向UE發(fā)送的尋呼消息中攜帶有標(biāo)記該尋呼消息為?；顚ず粝?即由?；钣|發(fā)消息觸發(fā)的尋呼消息)。

較佳的，由于?；顚ず粝⒂袝r需要面向大量UE的大范圍尋呼，這種情況下，可以預(yù)先將UE按照用戶標(biāo)識進(jìn)行分組，基于同一組UE進(jìn)行保活尋呼，以節(jié)約尋呼開銷。UE根據(jù)接收到的保活尋呼請求向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送隨機(jī)接入請求。無線接入網(wǎng)絡(luò)設(shè)備接收到UE發(fā)送的隨機(jī)接入請求后，向該UE發(fā)送隨機(jī)接入響應(yīng)。UE向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送連接建立請求。UE在向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送的連接建立請求中攜帶自身的用戶標(biāo)識，使得無線接入網(wǎng)絡(luò)設(shè)備可以根據(jù)該用戶標(biāo)識識別出其為?；顚ず粝⒌哪繕?biāo)用戶。無線接入網(wǎng)絡(luò)設(shè)備判斷出UE發(fā)起的隨機(jī)接入為尋呼?；钣|發(fā)消息觸發(fā)時，則向UE發(fā)送連接終止消息用于指示用戶終止后續(xù)的連接行為。并向用戶狀態(tài)服務(wù)器發(fā)送?；畲_認(rèn)消息。如果無線接入網(wǎng)絡(luò)設(shè)備未在預(yù)設(shè)時間內(nèi)接收到所述UE發(fā)送的隨機(jī)接入請求，或者用戶狀態(tài)服務(wù)器在預(yù)設(shè)時間內(nèi)未接收到?；畲_認(rèn)消息，則認(rèn)為用戶?；钪袛唷?/p>

與無線接入網(wǎng)絡(luò)設(shè)備確定用戶狀態(tài)服務(wù)器發(fā)送的消息為?；钣|發(fā)消息的確定方式相對應(yīng)，無線接入網(wǎng)絡(luò)設(shè)備向用戶狀態(tài)服務(wù)器發(fā)送保活確認(rèn)消息也可以由如下三種實現(xiàn)方式：

實現(xiàn)方式一、

無線接入網(wǎng)絡(luò)設(shè)備向用戶狀態(tài)服務(wù)器發(fā)送的?；畲_認(rèn)消息中攜帶有標(biāo)記該消息為?；畲_認(rèn)消息的標(biāo)記信息，使得用戶狀態(tài)服務(wù)器可以根據(jù)該標(biāo)記信息識別出接收到的消息為?；畲_認(rèn)消息。

實現(xiàn)方式二、

無線接入網(wǎng)絡(luò)設(shè)備通過把保活確認(rèn)消息專用API向用戶狀態(tài)服務(wù)器反饋?；畲_認(rèn)消息，該?；畲_認(rèn)消息專用API可供用戶狀態(tài)服務(wù)器查詢用戶狀態(tài)。用戶狀態(tài)服務(wù)器判斷接收到的消息是否為通過?；畲_認(rèn)消息專用API接收到， 便可確定接收到的消息是否為?；畲_認(rèn)消息。

實現(xiàn)方式三、

無線接入網(wǎng)絡(luò)設(shè)備以普通的消息形式發(fā)送?；畲_認(rèn)消息，由用戶狀態(tài)服務(wù)器接收消息的API利用DPI技術(shù)檢測接收到的消息是否為?；畲_認(rèn)消息即可。

相應(yīng)的，用戶狀態(tài)服務(wù)器也可以按照以下三種方式中的任一種確定接收到的消息為?；畲_認(rèn)消息：

方式一、

如果無線接入網(wǎng)絡(luò)設(shè)備在向用戶狀態(tài)服務(wù)器發(fā)送的消息中攜帶有標(biāo)記該消息為保活確認(rèn)消息的標(biāo)記信息時，用戶狀態(tài)服務(wù)器可以根據(jù)該標(biāo)記信息識別出無線接入網(wǎng)絡(luò)設(shè)備發(fā)送的消息為?；畲_認(rèn)消息。

方式二、

如果無線接入網(wǎng)絡(luò)設(shè)備通過?；畲_認(rèn)消息專用API向用戶狀態(tài)服務(wù)器反饋保活確認(rèn)消息，則用戶狀態(tài)服務(wù)器判斷接收到的消息是否為通過?；畲_認(rèn)消息專用API接收到，便可確定接收到的消息是否為?；畲_認(rèn)消息。

方式三、

如果無線接入網(wǎng)絡(luò)設(shè)備以普通的消息形式發(fā)送?；畲_認(rèn)消息，則用戶狀態(tài)服務(wù)器接收到消息的API可以利用DPI技術(shù)檢測收到的消息是否為?；畲_認(rèn)消息。

以上為第三方服務(wù)器為由運(yùn)營商提供的用于維護(hù)用戶狀態(tài)的用戶狀態(tài)服務(wù)器實施本發(fā)明實施例提供的?；钣|發(fā)消息處理方法的實施流程示意圖。

具體實施時，第三方服務(wù)器還可以為提供應(yīng)用的應(yīng)用服務(wù)器，其實施發(fā)明實施例提供的?；钣|發(fā)消息處理方法的流程與上述用戶狀態(tài)服務(wù)器實施保活觸發(fā)消息處理方法類似，可以包括以下步驟：

如圖8b所示，為本發(fā)明實施例提供的應(yīng)用服務(wù)器實施?；钣|發(fā)消息處理方法的實施流程示意圖，可以包括以下步驟：

S801、應(yīng)用服務(wù)器向網(wǎng)絡(luò)側(cè)發(fā)送?；钣|發(fā)消息。

具體實施時，應(yīng)用服務(wù)器可以按照以下任一方式向網(wǎng)絡(luò)側(cè)的無線接入網(wǎng)絡(luò)設(shè)備發(fā)送保活觸發(fā)消息：

應(yīng)用服務(wù)器在向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送消息時，如果該消息為保活觸發(fā)消息，則應(yīng)用服務(wù)器可以在發(fā)送的消息中攜帶有標(biāo)記該消息為保活觸發(fā)消息的標(biāo)記信息；或者，

應(yīng)用服務(wù)器在需要向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送?；钣|發(fā)消息時，可以通過預(yù)設(shè)的?；钣|發(fā)消息專用應(yīng)用程序接口(API，Application Programmable Interface)發(fā)送該?；钣|發(fā)消息；

當(dāng)然，具體實施時，應(yīng)用服務(wù)器還可以以普通消息形式發(fā)送該?；钣|發(fā)消息，由無線接入網(wǎng)絡(luò)設(shè)備接收該?；钣|發(fā)消息的API檢測其接收到的消息是否為保活觸發(fā)消息。

S802、應(yīng)用服務(wù)器接收網(wǎng)絡(luò)側(cè)返回的?；畲_認(rèn)消息。

其中，?；畲_認(rèn)消息為網(wǎng)絡(luò)側(cè)在接收到保活觸發(fā)消息后向UE(用戶設(shè)備)發(fā)送尋呼消息以及在接收到所述UE根據(jù)所述尋呼消息發(fā)起的隨機(jī)接入過程中發(fā)送的連接建立請求后發(fā)送的，所述?；畲_認(rèn)消息用于指示所述UE終止與網(wǎng)絡(luò)側(cè)建立連接。

具體實施時，與應(yīng)用服務(wù)器發(fā)送保活觸發(fā)消息的方式相對應(yīng)，網(wǎng)絡(luò)側(cè)的無線接入網(wǎng)絡(luò)設(shè)備也可以通過以下三種方式中的任一種確定應(yīng)用服務(wù)器發(fā)送的消息為?；钣|發(fā)消息。

第一種確定方式

如果應(yīng)用服務(wù)器在發(fā)送的消息中攜帶有標(biāo)記該消息為?；钣|發(fā)消息的標(biāo)記信息時，則無線接入網(wǎng)絡(luò)設(shè)備可以根據(jù)該標(biāo)記信息確定應(yīng)用服務(wù)器發(fā)送的消息為保活觸發(fā)消息。

第二種確定方式

如果應(yīng)用服務(wù)器通過保活觸發(fā)消息專用API發(fā)送消息時，則則無線接入網(wǎng)絡(luò)設(shè)備可以根據(jù)接收到消息的API是否為保活觸發(fā)消息專用API來判斷應(yīng)用服 務(wù)器發(fā)送的消息是否為?；钣|發(fā)消息。如果判斷出應(yīng)用服務(wù)器為通過?；钣|發(fā)消息專用API發(fā)送的消息，則可以確定應(yīng)用服務(wù)器發(fā)送的消息為?；钣|發(fā)消息。

第三種確定方式

如果應(yīng)用服務(wù)器以普通消息形式發(fā)送保活觸發(fā)消息，則無線接入網(wǎng)絡(luò)設(shè)備可以利用DPI(深度包檢測，Deep Packet Inspecion)技術(shù)檢測其接收到消息是否為?；钣|發(fā)消息。

無線接入網(wǎng)絡(luò)設(shè)備確定接收到的消息為?；钣|發(fā)消息時，向UE發(fā)送尋呼消息。無線接入網(wǎng)絡(luò)設(shè)備在向UE發(fā)送的尋呼消息中攜帶有標(biāo)記該尋呼消息為?；顚ず粝?即由?；钣|發(fā)消息觸發(fā)的尋呼消息)。較佳的，由于?；顚ず粝⒂袝r需要面向大量UE的大范圍尋呼，這種情況下，可以預(yù)先將UE按照用戶標(biāo)識進(jìn)行分組，基于同一組UE進(jìn)行?；顚ず?，以節(jié)約尋呼開銷。UE根據(jù)接收到的保活尋呼請求向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送隨機(jī)接入請求。無線接入網(wǎng)絡(luò)設(shè)備接收到UE發(fā)送的隨機(jī)接入請求后，向該UE發(fā)送隨機(jī)接入響應(yīng)。UE向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送連接建立請求。UE在向無線接入網(wǎng)絡(luò)設(shè)備發(fā)送的連接建立請求中攜帶自身的用戶標(biāo)識，使得無線接入網(wǎng)絡(luò)設(shè)備可以根據(jù)該用戶標(biāo)識識別出其為?；顚ず粝⒌哪繕?biāo)用戶。無線接入網(wǎng)絡(luò)設(shè)備判斷出UE發(fā)送的連接建立請求為尋呼保活觸發(fā)消息觸發(fā)時，則向用戶發(fā)送連接終止消息用于指示用戶終止后續(xù)的連接行為。并向應(yīng)用服務(wù)器發(fā)送?；畲_認(rèn)消息。如果無線接入網(wǎng)絡(luò)設(shè)備未在預(yù)設(shè)時間內(nèi)接收到所述UE發(fā)送的隨機(jī)接入請求，或者應(yīng)用服務(wù)器在預(yù)設(shè)時間內(nèi)未接收到?；畲_認(rèn)消息，則認(rèn)為用戶保活中斷。

與無線接入網(wǎng)絡(luò)設(shè)備確定應(yīng)用服務(wù)器發(fā)送的消息為?；钣|發(fā)消息的確定方式相對應(yīng)，無線接入網(wǎng)絡(luò)設(shè)備向應(yīng)用服務(wù)器發(fā)送?；畲_認(rèn)消息也可以由如下三種實現(xiàn)方式：

實現(xiàn)方式一、

無線接入網(wǎng)絡(luò)設(shè)備向應(yīng)用服務(wù)器發(fā)送的?；畲_認(rèn)消息中攜帶有標(biāo)記該消 息為保活確認(rèn)消息的標(biāo)記信息，使得應(yīng)用服務(wù)器可以根據(jù)該標(biāo)記信息識別出接收到的消息為?；畲_認(rèn)消息。

實現(xiàn)方式二、

無線接入網(wǎng)絡(luò)設(shè)備通過把保活確認(rèn)消息專用API向應(yīng)用服務(wù)器反饋?；畲_認(rèn)消息，該?；畲_認(rèn)消息專用API可供應(yīng)用服務(wù)器查詢用戶狀態(tài)。應(yīng)用服務(wù)器判斷接收到的消息是否為通過保活確認(rèn)消息專用API接收到，便可確定接收到的消息是否為?；畲_認(rèn)消息。

實現(xiàn)方式三、

無線接入網(wǎng)絡(luò)設(shè)備以普通的消息形式發(fā)送?；畲_認(rèn)消息，由應(yīng)用服務(wù)器接收消息的API利用DPI技術(shù)檢測接收到的消息是否為?；畲_認(rèn)消息即可。

相應(yīng)的，應(yīng)用服務(wù)器也可以按照以下三種方式中的任一種確定接收到的消息為?；畲_認(rèn)消息：

方式一、

如果無線接入網(wǎng)絡(luò)設(shè)備在向應(yīng)用服務(wù)器發(fā)送的消息中攜帶有標(biāo)記該消息為保活確認(rèn)消息的標(biāo)記信息時，應(yīng)用服務(wù)器可以根據(jù)該標(biāo)記信息識別出無線接入網(wǎng)絡(luò)設(shè)備發(fā)送的消息為?；畲_認(rèn)消息。

方式二、

如果無線接入網(wǎng)絡(luò)設(shè)備通過保活確認(rèn)消息專用API向應(yīng)用服務(wù)器反饋?；畲_認(rèn)消息，則應(yīng)用服務(wù)器判斷接收到的消息是否為通過?；畲_認(rèn)消息專用API接收到，便可確定接收到的消息是否為?；畲_認(rèn)消息。

方式三、

如果無線接入網(wǎng)絡(luò)設(shè)備以普通的消息形式發(fā)送?；畲_認(rèn)消息，則應(yīng)用服務(wù)器接收到消息的API可以利用DPI技術(shù)檢測收到的消息是否為?；畲_認(rèn)消息。

如圖9所示為本發(fā)明實施例提供的第三種?；钕⑻幚硌b置的結(jié)構(gòu)示意圖，可以包括：

發(fā)送單元91，用于向網(wǎng)絡(luò)側(cè)發(fā)送?；钣|發(fā)消息；

接收單元92，用于接收所述網(wǎng)絡(luò)側(cè)返回的保活確認(rèn)消息.

其中，所述保活確認(rèn)消息為所述網(wǎng)絡(luò)側(cè)在接收到所述?；钣|發(fā)消息后向用戶設(shè)備UE發(fā)送尋呼消息以及在接收到所述UE根據(jù)所述尋呼消息發(fā)起的隨機(jī)接入過程中發(fā)送的連接建立請求后發(fā)送的。

具體實施時，發(fā)送單元91，可以用于在向網(wǎng)絡(luò)側(cè)發(fā)送?；钣|發(fā)消息時，在發(fā)送的消息中攜帶有標(biāo)記所述消息為?；钣|發(fā)消息的標(biāo)記信息；或者用于通過預(yù)設(shè)的保活觸發(fā)消息API向所述網(wǎng)絡(luò)側(cè)發(fā)送所述?；钣|發(fā)消息。

為了描述的方便，以上各部分按照功能劃分為各模塊(或單元)分別描述。當(dāng)然，在實施本發(fā)明時可以把各模塊(或單元)的功能在同一個或多個軟件或硬件中實現(xiàn)。具體實施時，本發(fā)明實施例提供的第三種保活觸發(fā)消息處理裝置可以設(shè)置于用戶狀態(tài)服務(wù)器或者應(yīng)用服務(wù)器中，由用戶狀態(tài)服務(wù)器或者應(yīng)用服務(wù)器向無線接入網(wǎng)絡(luò)設(shè)備查詢用戶狀態(tài)。

如圖10所示，為本發(fā)明實施例提供的保活消息處理系統(tǒng)的結(jié)構(gòu)示意圖，包括上述的無線接入網(wǎng)絡(luò)設(shè)備101，用戶設(shè)備102和第三方服務(wù)器103。

其中，無線接入網(wǎng)絡(luò)設(shè)備101中設(shè)置有本發(fā)明提供的第一種?；钕⑻幚硌b置，用戶設(shè)備102中設(shè)置有本發(fā)明提供的第二種保活消息處理裝置，第三方服務(wù)器103中設(shè)置有本發(fā)明提供的第三種?；钕⑻幚硌b置。

本發(fā)明實施例提供的?；钕⑻幚矸椒?、裝置、系統(tǒng)和相關(guān)設(shè)備，當(dāng)網(wǎng)絡(luò)側(cè)接收到第三方服務(wù)器發(fā)送的?；钣|發(fā)消息時，通過尋呼消息觸發(fā)UE發(fā)起隨機(jī)接入流程，網(wǎng)絡(luò)側(cè)在接收到UE根據(jù)該尋呼消息發(fā)起的隨機(jī)接入過程中發(fā)送的連接建立請求后，根據(jù)其中攜帶的用戶標(biāo)識確定該隨機(jī)接入過程為保活尋呼消息觸發(fā)時，向UE發(fā)送連接終止消息指示UE終止與網(wǎng)絡(luò)側(cè)建立連接，并向第三方服務(wù)器發(fā)送?；畲_認(rèn)消息。上述過程中，由于UE并未與網(wǎng)絡(luò)側(cè)真正建立連接，從而節(jié)約了UE與網(wǎng)絡(luò)側(cè)建鏈拆鏈等所需的信令開銷，同時，本發(fā)明實施例提供的方法對UE改動較小，從而能夠兼容現(xiàn)有的網(wǎng)絡(luò)設(shè)計。

本領(lǐng)域內(nèi)的技術(shù)人員應(yīng)明白，本發(fā)明的實施例可提供為方法、系統(tǒng)、或計 算機(jī)程序產(chǎn)品。因此，本發(fā)明可采用完全硬件實施例、完全軟件實施例、或結(jié)合軟件和硬件方面的實施例的形式。而且，本發(fā)明可采用在一個或多個其中包含有計算機(jī)可用程序代碼的計算機(jī)可用存儲介質(zhì)(包括但不限于磁盤存儲器、CD-ROM、光學(xué)存儲器等)上實施的計算機(jī)程序產(chǎn)品的形式。

本發(fā)明是參照根據(jù)本發(fā)明實施例的方法、設(shè)備(系統(tǒng))、和計算機(jī)程序產(chǎn)品的流程圖和/或方框圖來描述的。應(yīng)理解可由計算機(jī)程序指令實現(xiàn)流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結(jié)合。可提供這些計算機(jī)程序指令到通用計算機(jī)、專用計算機(jī)、嵌入式處理機(jī)或其他可編程數(shù)據(jù)處理設(shè)備的處理器以產(chǎn)生一個機(jī)器，使得通過計算機(jī)或其他可編程數(shù)據(jù)處理設(shè)備的處理器執(zhí)行的指令產(chǎn)生用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。

這些計算機(jī)程序指令也可存儲在能引導(dǎo)計算機(jī)或其他可編程數(shù)據(jù)處理設(shè)備以特定方式工作的計算機(jī)可讀存儲器中，使得存儲在該計算機(jī)可讀存儲器中的指令產(chǎn)生包括指令裝置的制造品，該指令裝置實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。

這些計算機(jī)程序指令也可裝載到計算機(jī)或其他可編程數(shù)據(jù)處理設(shè)備上，使得在計算機(jī)或其他可編程設(shè)備上執(zhí)行一系列操作步驟以產(chǎn)生計算機(jī)實現(xiàn)的處理，從而在計算機(jī)或其他可編程設(shè)備上執(zhí)行的指令提供用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。

盡管已描述了本發(fā)明的優(yōu)選實施例，但本領(lǐng)域內(nèi)的技術(shù)人員一旦得知了基本創(chuàng)造性概念，則可對這些實施例做出另外的變更和修改。所以，所附權(quán)利要求意欲解釋為包括優(yōu)選實施例以及落入本發(fā)明范圍的所有變更和修改。

顯然，本領(lǐng)域的技術(shù)人員可以對本發(fā)明進(jìn)行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動和變型在內(nèi)。