一種周期性保活傳輸方法、設備及系統(tǒng)的制作方法
【技術領域】
[0001] 本發(fā)明涉及無線傳輸領域，尤其涉及一種支持異步資源周期性調度的?；顐鬏敺?法、設備及系統(tǒng)。
【背景技術】
[0002] 隨著移動互聯(lián)網絡的發(fā)展，越來越多的"永遠在線"業(yè)務應運而生。實現(xiàn)"永遠在 線"體驗最重要而直接的方法是實施應用層周期保活機制，使得網絡能夠實時地了解應用 的無線鏈路狀態(tài)，所謂無線鏈路狀態(tài)包括：應用在線、應用下線、應用位于網絡覆蓋空洞不 可達等；進一步的，根據(jù)無線鏈路狀態(tài)可確定是否有必要或有能力與該應用進行即時交互。 其中，所涉及的應用包括新聞、聊天工具等等，"永遠在線"體驗已經成為評價移動用戶體驗 的一項重要指標。
[0003] 傳統(tǒng)地，運行在同一個終端上的不同的"永遠在線"應用分別同移動網絡建立獨 立的?；钸B接，如此，多個程序的?；钸B接會引發(fā)大量的開銷。目前，針對這個問題，一些 智能終端操作系統(tǒng)提供商已經推出了私有的?；罹S護平臺，這種?；罹S護平臺能夠保證終 端和?；罹S護平臺之間通過單一的?；钸B接，并由保活維護平臺建立終端與應用之間的 映射關系；另外，?；罹S護平臺開放應用程序編程接口（API，Application Programming Interface)，供每個應用程序查詢實時狀態(tài)更新，從而將一個終端多個應用多個?；钸B接 簡化成為一個終端多個應用一個?；钸B接；如果一個終端上有10個"永遠在線"應用，該方 案能夠將?；铋_銷降低10倍。
[0004] 但是即便如此，?；钕⒁廊唤o網絡造成大量的信令開銷。例如，基于表1給出的 參考業(yè)務評估模型，假設長期演進（LTE，Long Term Evolution)的無線資源控制協(xié)議（RRC, Radio Resource Control)閑置計時器設置為5s、用戶每分鐘跨越一個小區(qū)范圍，即：對于 站間距ISD = 500m，用戶的移動速率是30km/h，得到不同?；钕⑼渌煌瑯I(yè)務的信令 開銷評估比較，如表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ù)，如果說一個蜂窩范圍內有200個用戶需要發(fā)送?；钕?， 產生的信令開銷大約為2. 5個視頻用戶的數(shù)據(jù)傳輸量。而從表2可知，保活的信令開銷有 90%以上是由RRC的建鏈拆鏈引發(fā)的，由于RRC閑置計時時鐘用于管理RRC連接狀態(tài)下的 用戶在沒有業(yè)務多長時間之后釋放RRC連接，進入到RRC空閑態(tài)，因此，在RRC閑置計時時 鐘的控制下，?；顦I(yè)務的生成特征使得用戶需要不斷同網絡建鏈拆鏈，進而引發(fā)很大的RRC 開銷。?；钕⑦@一業(yè)務特征一方面容易給造成網絡信令的擁塞，另一方面加劇終端耗電。
[0012] 目前，3GPP在R12中展開了"面向MTC和小數(shù)據(jù)包優(yōu)化的研究議題"(Machine_Type and other Mobile Data Applications Communications Enhancements)中提出：在支持 always on用戶體驗的心跳信息傳輸優(yōu)化方面，建議在網絡中引入應用層次的代理網關，維 護終端內部IP和外部IP的半靜態(tài)/靜態(tài)映射關系；或者，通過應用服務器觸發(fā)核心網元 維持而不釋放用戶的分組數(shù)據(jù)協(xié)議上下文（PDP context)，包括終端IP地址及其具有特定 QoS的邏輯承載。此外，也有觀點認為，可以通過電路域（CS)通知推送信息的到達，降低應 用always on需求。
[0013] 另外，3GPP在R12 "面向MTC和小數(shù)據(jù)包優(yōu)化的研究議題"議題中提到依賴非接入 層（NAS)信令來承載小數(shù)據(jù)包的方式，也可以應用到?；钚∠膫鬏?，可以大幅度節(jié) 約信令的開銷。
[0014] 但是，現(xiàn)有技術中的技術方案仍然存在著一些問題：一方面，盡管3GPP提出的保 活機制可以較好解決?；铋_銷問題，但由于無線鏈路環(huán)境的不可靠性，通過核心網配置維 護用戶連接的方式，并不能真實反映用戶的可達性；無論什么形式存在的保活信息依然是 需要的、用于保證更高"永遠在線"體驗。
[0015] 另一方面，通過NAS信令傳輸保活以及其它小數(shù)據(jù)包確實有利于大幅降低信令開 銷，預計能將RRC信令開銷從200多字節(jié)減少到50多個字節(jié)，但是50多個字節(jié)對于RRC來 說，仍然是不小的信令開銷。

【發(fā)明內容】

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