[發(fā)明專利]報文處理方法、裝置及系統(tǒng)

在審

• 申請?zhí)枺?/td>: 201410579111.2
• 申請日: 2014-10-24
• 公開（公告）號: CN105591976A
• 公開（公告）日: 2016-05-18
• 發(fā)明（設(shè)計）人: 賀保國;董建軍;武見
• 申請（專利權(quán)）人: 中興通訊股份有限公司
• 主分類號: H04L12/861
• 分類號: H04L12/861
• 代理公司: 北京康信知識產(chǎn)權(quán)代理有限責任公司 11240
• 代理人: 余剛;梁麗超

技術(shù)領(lǐng)域

本發(fā)明涉及通信領(lǐng)域，具體而言，涉及一種報文處理方法、裝置及系統(tǒng)。

背景技術(shù)

LTE的層2用戶面協(xié)議棧由3個子層組成，分為分組數(shù)據(jù)匯聚協(xié)議(Packet DataConvergenceProtocol,簡稱為PDCP)、無線鏈路控制(RadioLinkControl， 簡稱為RLC)和媒體接入控制(MediaAccessControl，簡稱為MAC)。其中PDCP 層主要功能包括頭壓縮、安全性功能(完整性保護和加密)以及對切換時重排序和 重傳的支持，這些功能取決于無線承載。每一無線承載有一個PDCP實體。

PDCP層發(fā)送端處理流程：從上層接收到業(yè)務(wù)數(shù)據(jù)單元(ServiceDataUnit， 簡稱為SDU)后，賦予序列號(SequenceNumber，簡稱為SN)值，如果需要 完保，則執(zhí)行完保處理；如果需要加密，則執(zhí)行加密處理；維護發(fā)送端的序列號 和超幀號(HyperFrameNumber，簡稱為HFN)值，將協(xié)議數(shù)據(jù)單元(ProtocolData Unit，簡稱為PDU)發(fā)送給下層處理。

PDCP層接收端處理流程：從下層接收到協(xié)議數(shù)據(jù)單元PDU，如果需要解密， 執(zhí)行解密處理；如果需要完保，執(zhí)行完保校驗；根據(jù)接收到序列號SN維護本地 的接收序列號SN和超幀號HFN值，將業(yè)務(wù)數(shù)據(jù)單元SDU投遞到高層處理。

隨著LTE的大規(guī)模商用和移動互聯(lián)網(wǎng)的蓬勃發(fā)展，網(wǎng)絡(luò)中的業(yè)務(wù)類型變得 更加的豐富，各種各樣的報文都存在，比如很多的O2O應(yīng)用、如微信、易信， 微博等，還有TCP的ACK反饋報文等，這些報文的特點都是小包，而且是非常 頻繁，數(shù)據(jù)量比較大。

但目前不論是終端側(cè)或者是網(wǎng)絡(luò)側(cè)，PDCP協(xié)議的處理基本上都是類CPU 的芯片，其主要特點是線性處理，小包處理能力較差。而根據(jù)PDCP協(xié)議，高層 的每一個SDU來需要獨立處理，經(jīng)過PDCP協(xié)議處理后形成PDU發(fā)送給低層協(xié) 議棧，如RLC。這樣就會導致終端或者網(wǎng)絡(luò)側(cè)PDCP層處理小報文能力非常差， 而空口帶寬又無法得到足夠的利用。例如FDD20M帶寬小區(qū)，空口能力是 150Mbps，假設(shè)芯片每秒能處理10000個報文，如果每個報文大小是1500字節(jié)， 則流量是110Mbps左右；如果每個報文大小是64字節(jié)，則流量僅僅有5Mbps 左右。當然，考慮到1500字節(jié)和64字節(jié)內(nèi)存處理等因素，可能會更高一些，但 是流量還是非常的低，遠遠沒法滿足真實商用環(huán)境的需求。

對于這種小包的問題，目前的處理方法一般是使用更高速的處理器，更大的 內(nèi)存，但是基本上是治標不治本。

針對相關(guān)技術(shù)中不能解決小報文處理能力較差的問題，目前尚未提出有效的 解決方案。

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

本發(fā)明提供了一種報文處理方法、裝置及系統(tǒng)，以至少解決相關(guān)技術(shù)中不能 解決小報文處理能力較差的問題。

根據(jù)本發(fā)明的一個方面，提供了一種報文處理方法，包括：創(chuàng)建緩存區(qū)，其 中，所述緩存區(qū)用于儲存至少兩個報文；確定在所述緩存區(qū)中用于對所述至少兩 個報文進行組包的組包條件；依據(jù)確定的所述組包條件在所述緩存區(qū)中對所述至 少兩個報文進行處理。

優(yōu)選地，依據(jù)確定的所述組包條件在所述緩存區(qū)中對所述至少兩個報文進行 處理包括：判斷所述至少兩個報文是否滿足所述預定的組包條件；在判斷結(jié)果為 是的情況下，對所述至少兩個報文進行組包，并將組包后的所述至少兩個報文發(fā) 送到分組數(shù)據(jù)聚合協(xié)議PDCP層進行處理。

優(yōu)選地，在判斷所述至少兩個報文是否滿足預定的組包條件之前，還包括： 接收無線鏈路控制RRC發(fā)送的分組數(shù)據(jù)聚合協(xié)議PDCP配置消息，其中，所述 PDCP配置消息中攜帶有用于組包的累計字節(jié)數(shù)閾值和/或用于組包的預定時長； 依據(jù)所述PDCP配置消息確定所述預定的組包條件。

優(yōu)選地，判斷所述至少兩個報文是否滿足預定的組包條件包括以下至少之一： 在所述緩存區(qū)中配置最大累計字節(jié)數(shù)，判斷所述至少兩個報文的總字節(jié)數(shù)是否大 于或等于所述最大累計字節(jié)數(shù)，在判斷結(jié)果為是的情況下，確定對所述至少兩個 報文進行組包；在所述緩存區(qū)中配置等待定時器，判斷緩存所述至少兩個報文中 的第一個報文后等待的時間是否超過等待定時器中預設(shè)的閾值，在判斷結(jié)果為是 的情況下，確定對所述至少兩個報文進行組包。