一種周期性?；顐鬏敺椒?、設(shè)備及系統(tǒng)的制作方法
【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及無線傳輸領(lǐng)域，尤其涉及一種支持異步資源周期性調(diào)度的?；顐鬏敺?法、設(shè)備及系統(tǒng)。
【背景技術(shù)】
[0002] 隨著移動互聯(lián)網(wǎng)絡(luò)的發(fā)展，越來越多的"永遠(yuǎn)在線"業(yè)務(wù)應(yīng)運而生。實現(xiàn)"永遠(yuǎn)在 線"體驗最重要而直接的方法是實施應(yīng)用層周期保活機制，使得網(wǎng)絡(luò)能夠?qū)崟r地了解應(yīng)用 的無線鏈路狀態(tài)，所謂無線鏈路狀態(tài)包括：應(yīng)用在線、應(yīng)用下線、應(yīng)用位于網(wǎng)絡(luò)覆蓋空洞不 可達等；進一步的，根據(jù)無線鏈路狀態(tài)可確定是否有必要或有能力與該應(yīng)用進行即時交互。 其中，所涉及的應(yīng)用包括新聞、聊天工具等等，"永遠(yuǎn)在線"體驗已經(jīng)成為評價移動用戶體驗 的一項重要指標(biāo)。
[0003] 傳統(tǒng)地，運行在同一個終端上的不同的"永遠(yuǎn)在線"應(yīng)用分別同移動網(wǎng)絡(luò)建立獨 立的?；钸B接，如此，多個程序的保活連接會引發(fā)大量的開銷。目前，針對這個問題，一些 智能終端操作系統(tǒng)提供商已經(jīng)推出了私有的?；罹S護平臺，這種保活維護平臺能夠保證終 端和?；罹S護平臺之間通過單一的保活連接，并由?；罹S護平臺建立終端與應(yīng)用之間的 映射關(guān)系；另外，保活維護平臺開放應(yīng)用程序編程接口（API，Application Programming Interface)，供每個應(yīng)用程序查詢實時狀態(tài)更新，從而將一個終端多個應(yīng)用多個?；钸B接 簡化成為一個終端多個應(yīng)用一個?；钸B接；如果一個終端上有10個"永遠(yuǎn)在線"應(yīng)用，該方 案能夠?qū)⒈；铋_銷降低10倍。
[0004] 但是即便如此，保活消息依然給網(wǎng)絡(luò)造成大量的信令開銷。例如，基于表1給出的 參考業(yè)務(wù)評估模型，假設(shè)長期演進（LTE，Long Term Evolution)的無線資源控制協(xié)議（RRC, Radio Resource Control)閑置計時器設(shè)置為5s、用戶每分鐘跨越一個小區(qū)范圍，即：對于 站間距ISD = 500m，用戶的移動速率是30km/h，得到不同?；钕⑼渌煌瑯I(yè)務(wù)的信令 開銷評估比較，如表2所示。
[0005]

[0009] 表 2
[0010] 表2中，數(shù)據(jù)信令比（DSR)為數(shù)據(jù)量與信令開銷的比值，即：DSR =數(shù)據(jù)量/信令 開銷；RRC建鏈拆鏈信令開銷百分比為RRC連接釋放信令與總信令開銷的比值，即：RRC建 鏈拆鏈信令開銷（％)= RRC連接釋放信令（bit)/總信令開銷（bit);切換信令開銷百分 比為切換信令與總信令開銷的比值，即：切換信令開銷（％)=切換信令（bit)/總信令開 銷（bit) ;RRC維護信令開銷百分比為RRC維護信令與總信令開銷的比值，即：RRC維護信令 開銷=RRC維護信令（bit) /總信令開銷（bit);
[0011] 從表2可以看出，單個保活消息的數(shù)據(jù)信令比為0. 1075，即：傳輸一份保活數(shù)據(jù)需 要傳輸10份信令；根據(jù)這一數(shù)據(jù)，如果說一個蜂窩范圍內(nèi)有200個用戶需要發(fā)送保活消息， 產(chǎn)生的信令開銷大約為2. 5個視頻用戶的數(shù)據(jù)傳輸量。而從表2可知，?；畹男帕铋_銷有 90%以上是由RRC的建鏈拆鏈引發(fā)的，由于RRC閑置計時時鐘用于管理RRC連接狀態(tài)下的 用戶在沒有業(yè)務(wù)多長時間之后釋放RRC連接，進入到RRC空閑態(tài)，因此，在RRC閑置計時時 鐘的控制下，?；顦I(yè)務(wù)的生成特征使得用戶需要不斷同網(wǎng)絡(luò)建鏈拆鏈，進而引發(fā)很大的RRC 開銷。?；钕⑦@一業(yè)務(wù)特征一方面容易給造成網(wǎng)絡(luò)信令的擁塞，另一方面加劇終端耗電。
[0012] 目前，3GPP在R12中展開了"面向MTC和小數(shù)據(jù)包優(yōu)化的研究議題"(Machine_Type and other Mobile Data Applications Communications Enhancements)中提出：在支持 always on用戶體驗的心跳信息傳輸優(yōu)化方面，建議在網(wǎng)絡(luò)中引入應(yīng)用層次的代理網(wǎng)關(guān)，維 護終端內(nèi)部IP和外部IP的半靜態(tài)/靜態(tài)映射關(guān)系；或者，通過應(yīng)用服務(wù)器觸發(fā)核心網(wǎng)元 維持而不釋放用戶的分組數(shù)據(jù)協(xié)議上下文（PDP context)，包括終端IP地址及其具有特定 QoS的邏輯承載。此外，也有觀點認(rèn)為，可以通過電路域（CS)通知推送信息的到達，降低應(yīng) 用always on需求。
[0013] 另外，3GPP在R12 "面向MTC和小數(shù)據(jù)包優(yōu)化的研究議題"議題中提到依賴非接入 層（NAS)信令來承載小數(shù)據(jù)包的方式，也可以應(yīng)用到?；钚∠膫鬏?，可以大幅度節(jié) 約信令的開銷。
[0014] 但是，現(xiàn)有技術(shù)中的技術(shù)方案仍然存在著一些問題：一方面，盡管3GPP提出的保 活機制可以較好解決?；铋_銷問題，但由于無線鏈路環(huán)境的不可靠性，通過核心網(wǎng)配置維 護用戶連接的方式，并不能真實反映用戶的可達性；無論什么形式存在的?；钚畔⒁廊皇?需要的、用于保證更高"永遠(yuǎn)在線"體驗。
[0015] 另一方面，通過NAS信令傳輸?；钜约捌渌?shù)據(jù)包確實有利于大幅降低信令開 銷，預(yù)計能將RRC信令開銷從200多字節(jié)減少到50多個字節(jié)，但是50多個字節(jié)對于RRC來 說，仍然是不小的信令開銷。

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

[0016] 有鑒于此，本發(fā)明實施例期望提供一種周期性?；顐鬏敺椒?、設(shè)備及系統(tǒng)，能夠極 大節(jié)約?；钚畔⒁l(fā)的信令開銷。
[0017] 本發(fā)明實施例提供了一種周期性?；顐鬏敺椒?，所述方法包括：
[0018] 與網(wǎng)絡(luò)側(cè)進行上行同步，向網(wǎng)絡(luò)側(cè)發(fā)起?；钯Y源調(diào)度請求；其中，所述保活資源調(diào) 度請求中包括用戶標(biāo)識、周期性保活調(diào)度請求指示以及對?；钪芷诘呐渲眯枨螅?br>[0019] 接收網(wǎng)絡(luò)側(cè)根據(jù)所述用戶標(biāo)識、周期性?；钫{(diào)度請求指示為用戶設(shè)備分配的用于 傳輸?；钕⒌谋；钯Y源，以及網(wǎng)絡(luò)側(cè)根據(jù)所述對?；钪芷诘呐渲眯枨髮τ脩粼O(shè)備進行的 保活周期配置；
[0020] 根據(jù)所述?；钪芷谂渲茫{(diào)用所述分配的用于傳輸?；钕⒌谋；钯Y源周期性進 行?；罡隆?br>[0021] 上述方案中，所述接收網(wǎng)絡(luò)側(cè)分配的用于傳輸?；钕⒌谋；钯Y源包括但不限 于：接收網(wǎng)絡(luò)側(cè)分配的用于傳輸?；钕⒌挠脩魧俚姆歉偁庪S機接入導(dǎo)頻資源。
[0022] 上述方案中，所述調(diào)用所述分配的用于傳輸?；钕⒌谋；钯Y源周期性進行?；?更新包括：調(diào)用分配的用于傳輸?；钕⒌挠脩魧俚姆歉偁庪S機接入導(dǎo)頻資源使用單比 特信息進行保活更新。
[0023] 上述方案中，所述方法還包括：當(dāng)確定用戶設(shè)備失去同步或用戶設(shè)備移動出當(dāng)前 小區(qū)時，用戶設(shè)備與網(wǎng)絡(luò)側(cè)重新同步，并接收網(wǎng)絡(luò)側(cè)新分配的用于傳輸?；钕⒌谋；钯Y 源。
[0024] 本發(fā)明實施例還提供了一種周期性?；顐鬏敺椒?，所述方法包括：
[0025] 與用戶設(shè)備進行同步，接收用戶設(shè)備發(fā)送的?；钯Y源調(diào)度請求；其中，所述?；钯Y 源調(diào)度請求中包括用戶標(biāo)識、周期性?；钫{(diào)度請求指示以及對?；钪芷诘呐渲眯枨螅?br>[0026] 根據(jù)所述用戶標(biāo)識、周期性保活調(diào)度請求指示為用戶設(shè)備分配用于傳輸?；钕?的保活資源，根據(jù)所述對?；钪芷诘呐渲眯枨鬄橛脩粼O(shè)備進行的?；钪芷谂渲?，并將所述 保活資源以及?；钪芷谂渲眯畔l(fā)送到用戶設(shè)備；
[0027] 接收用戶設(shè)備發(fā)起的?；罡虏⑼ㄖ接脩魻顟B(tài)服務(wù)器。
[0028] 上述方案中，所述為用戶設(shè)備分配用于傳輸保活消息的?；钯Y源包括但不限于： 為用戶設(shè)備分配用于傳輸保活消息的用戶專屬的非競爭隨機接入導(dǎo)頻資源。
[0029] 本發(fā)明實施例又提供了一種周期性?；顐鬏敺椒?，所述方法包括：
[0030] 用戶設(shè)備與網(wǎng)絡(luò)側(cè)進行上行同步，向網(wǎng)絡(luò)側(cè)發(fā)起?；钯Y源調(diào)度請求；其中，所述保 活資源調(diào)度請求中包括用戶標(biāo)識、周期性保活調(diào)度請求指示以及對保活周期的配置需求；
[0031] 根據(jù)所述用戶標(biāo)識、周期性保活調(diào)度請求指示為用戶設(shè)備分配用于傳輸?；钕?的保活資源，根據(jù)所述對?；钪芷诘呐渲眯枨鬄橛脩粼O(shè)備進行的保活周期配置；
[0032] 根據(jù)所述保活周期配置，調(diào)用所述分配的用于傳輸保活消息的?；钯Y源周期性進 行保活更新；
[0033] 將所述?；罡峦ㄖ接脩魻顟B(tài)服務(wù)器。
[0034] 上述方案中，所述為用戶設(shè)備分配用于傳輸?；钕⒌谋；钯Y源包括但不限于： 為用戶設(shè)備分配用于傳輸?；钕⒌挠脩魧俚姆歉偁庪S機接入導(dǎo)頻資源。
[0035] 上述方案中，所述調(diào)用所述分配的用于傳輸?；钕⒌谋；钯Y源周期性進行?；?更新包括：調(diào)用分配的用于傳輸保活消息的用戶專屬的非競爭隨機接入導(dǎo)頻資源使用單比 特信息進行?；罡?。
[0036] 上述方案中，所述方法還包括：當(dāng)確定用戶設(shè)備失去同步或用戶設(shè)備移動出當(dāng)前 小區(qū)時，用戶設(shè)備與網(wǎng)絡(luò)側(cè)重新同步，并接收網(wǎng)絡(luò)側(cè)新分配的用于傳輸保活消息的?；钯Y 源。
[0037] 本發(fā)明實施例還提供了一種周期性?；顐鬏斢脩粼O(shè)備，所述用戶設(shè)備包括：同步 模塊、請求發(fā)送模塊、資源接收模塊、?；罡履K，其中，
[0038] 所述同步模塊，用于與網(wǎng)絡(luò)側(cè)進行上行同步；
[0039] 所述請求發(fā)送模塊，用于向網(wǎng)絡(luò)側(cè)發(fā)起?；钯Y源調(diào)度請求；其中，所述?；钯Y源調(diào) 度請求中包括用戶標(biāo)識、周期性?；钫{(diào)度請求指示以及對?；钪芷诘呐渲眯枨?；
[0040] 所述資源接收模塊，用于接收網(wǎng)絡(luò)側(cè)根據(jù)所述用戶標(biāo)識、周期性保活調(diào)度請求指 示為用戶設(shè)備分配的用于傳輸?；钕⒌谋；钯Y源，以及網(wǎng)絡(luò)側(cè)根據(jù)所述對?；钪芷诘呐?置需求對用戶設(shè)備進行的保活周期配置；
[0041] 所述保活更新模塊，用于根據(jù)所述保活周期配置，調(diào)用所述分配的用于傳輸保活 消息的?；钯Y源周期性進行保活更新。
[0042] 上述方案中，所述資源接收模塊接收網(wǎng)絡(luò)側(cè)分配的用于傳輸?；钕⒌谋；钯Y源 包括但不限于：接收網(wǎng)絡(luò)側(cè)分配的用于傳輸?；钕⒌挠脩魧俚姆歉偁庪S機接入導(dǎo)頻資 源。
[0043] 上述方案中，所述?；罡履K調(diào)用所述分配的用于傳輸保活消息的?；钯Y源周 期性進行?；罡掳ǎ赫{(diào)用所述用于傳輸?；钕⒌挠脩魧俚姆歉偁庪S機接入導(dǎo)頻資 源使用單比特信息進行?；罡?。
[0044] 上述方案中，所述同步模塊還用于確定用戶設(shè)備失去同步或用戶設(shè)備移動出當(dāng)前 小區(qū)時，與網(wǎng)絡(luò)側(cè)重新同步；所述資源接收模塊還用于接收網(wǎng)絡(luò)側(cè)新分配的用于傳輸?；?消息的?；钯Y源。
[0045] 本發(fā)明實施例又提供了一種周期性保活傳輸網(wǎng)絡(luò)設(shè)備，所述網(wǎng)絡(luò)設(shè)備