基站下行傳輸控制方法和系統(tǒng)的制作方法
【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及移動通信技術(shù)領(lǐng)域，特別是涉及一種基站下行傳輸控制方法及裝置。
【背景技術(shù)】
[0002] 在移動通信技術(shù)領(lǐng)域，用戶對數(shù)據(jù)下載業(yè)務有了很大的需求，高速下載也成了 無線通信的標志性需求，然而數(shù)據(jù)業(yè)務下載、上傳離不開TCP(TransmissionControl Protocol，傳輸控制協(xié)議），目前移動通信領(lǐng)域中基站的工作重心在于傳統(tǒng)協(xié)議架構(gòu)下的 數(shù)據(jù)傳輸實現(xiàn)與維護，比如，LTE(LongTermEvolution，3GPP長期演進）制式基站中的 MAC(MediaAccessControl，介質(zhì)訪問控制）、RLC(RadioLinkControl，無線鏈路控制）、 F*DCP(PacketDataConvergenceProtocol，包數(shù)據(jù)集中協(xié)議）等數(shù)據(jù)傳輸協(xié)議，對TCP協(xié) 議層的相關(guān)處理較為薄弱，甚至空白。在某些復雜的網(wǎng)絡環(huán)境中，基站本身對終端用戶數(shù)據(jù) 所涉及的TCP數(shù)據(jù)包關(guān)注不夠，引發(fā)大量數(shù)據(jù)不必要的網(wǎng)絡回傳，造成了網(wǎng)絡帶寬、空口資 源的浪費。同時TCP數(shù)據(jù)嚴格按序傳輸?shù)奶卣饕彩沟媚承┣闆r下，特殊數(shù)據(jù)包更為緊急相 比其他數(shù)據(jù)包，令人遺憾的是大部分基站由于未涉足終端數(shù)據(jù)TCP層的相關(guān)內(nèi)容，也一定 程度致使基站不能及時、優(yōu)先地照顧終端較為迫切的數(shù)據(jù)傳輸需求。
[0003] 現(xiàn)有系統(tǒng)由于并不涉足用戶TCP/IP分組數(shù)據(jù)內(nèi)容，未能代理終端在TCP協(xié)議上提 前回饋服務器應答，也未能掌握用戶傳輸層數(shù)據(jù)動態(tài)，對于網(wǎng)絡丟包等事件未能先于終端 用戶做出反應，造成網(wǎng)絡回傳時間長，重傳速度慢。少數(shù)系統(tǒng)雖然已經(jīng)具備TCP網(wǎng)絡側(cè)代理 功能，但實現(xiàn)方案多為收到下行數(shù)據(jù)包直接提前對服務器應答、提前應答邏輯單一，未能考 慮基站空口質(zhì)量因素，在空口質(zhì)量不佳的場景下，加速而至的下行數(shù)據(jù)在空口傳輸不暢，從 而造成整體傳輸效率低。

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

[0004] 基于此，有必要針對現(xiàn)有技術(shù)傳輸效率低的問題，提供一種基站下行傳輸控制方 法及裝置。
[0005] -種基站下行傳輸控制方法，包括以下步驟：
[0006] 接收服務器發(fā)送的數(shù)據(jù)包，將所述數(shù)據(jù)包存儲在本地緩存中；
[0007] 接收用戶端對序號為N的數(shù)據(jù)包的第一應答包；其中，所述第一應答包為用戶端 對基站發(fā)送的數(shù)據(jù)包的應答；N為正整數(shù)；
[0008] 根據(jù)到用戶端之間的通信鏈路的無線傳輸誤碼率設(shè)置最大提前應答量；其中，所 述最大提前應答量是基站向服務器提前發(fā)送應答包的最大提前量；
[0009] 當本地緩存中的數(shù)據(jù)包的序號連續(xù)且當前提前應答量M小于最大提前應答量時， 向服務器發(fā)送對序號為M+N的數(shù)據(jù)包的第二應答包；其中，所述第二應答包為基站對服務 器發(fā)送的數(shù)據(jù)包的應答;M為正整數(shù)，初值為0 ;
[0010] 當數(shù)據(jù)包的序號不連續(xù)時，每隔一段時間將丟失的數(shù)據(jù)包對應的第二應答包連續(xù) 發(fā)送K次至服務器，直到收到服務器發(fā)送的所述丟失的數(shù)據(jù)包；其中，K為不小于3的整數(shù)。
[0011] -種基站下行傳輸控制系統(tǒng)，包括：
[0012] 第一接收模塊，用于接收服務器發(fā)送的數(shù)據(jù)包，將所述數(shù)據(jù)包存儲在本地緩存中， 并檢測所述數(shù)據(jù)包的序號是否連續(xù)；
[0013] 第二接收模塊，用于接收用戶端對序號為N的數(shù)據(jù)包的第一應答包；其中，所述第 一應答包為用戶端對基站發(fā)送的數(shù)據(jù)包的應答；N為正整數(shù)；
[0014] 提前應答調(diào)整模塊，用于根據(jù)到用戶端之間的通信鏈路的無線傳輸誤碼率設(shè)置 最大提前應答量；其中，所述最大提前應答量是基站向服務器提前發(fā)送應答包的最大提前 量；
[0015] 提前應答模塊，用于當本地緩存中的數(shù)據(jù)包的序號連續(xù)且當前提前應答量M小于 最大提前應答量時，向服務器發(fā)送對序號為M+N的數(shù)據(jù)包的第二應答包；其中，所述第二應 答包為基站對服務器發(fā)送的數(shù)據(jù)包的應答;M為正整數(shù)，初值為0 ;
[0016] 提前重復應答模塊，用于當數(shù)據(jù)包的序號不連續(xù)時，每隔一段時間將丟失的數(shù)據(jù) 包對應的第二應答包連續(xù)發(fā)送K次至服務器，直到收到服務器發(fā)送的所述丟失的數(shù)據(jù)包； 其中，K為不小于3的整數(shù)。
[0017] 上述基站下行傳輸控制方法和系統(tǒng)，根據(jù)到用戶端之間的通信鏈路的無線傳輸誤 碼率設(shè)置系統(tǒng)的最大提前應答量，充分考慮了基站空口質(zhì)量因素，將空口側(cè)無線傳輸與網(wǎng) 絡側(cè)有線傳輸在一定程度上做融合，能夠在空口質(zhì)量不佳的場景下，限制下行數(shù)據(jù)在空口 的傳輸，在空口質(zhì)量較好時加速下行數(shù)據(jù)在空口的傳輸；并通過提前重復應答，優(yōu)先發(fā)送對 丟失數(shù)據(jù)包的請求，能夠及時、優(yōu)先地照顧終端較為迫切的數(shù)據(jù)傳輸需求，從而提高整體傳 輸效率。
【附圖說明】
[0018] 圖1為傳統(tǒng)LTE基站數(shù)據(jù)傳輸架構(gòu)圖；
[0019] 圖2為一個實施例的設(shè)置了TCP代理的基站架構(gòu)圖；
[0020] 圖3為一個實施例的基站下行傳輸控制方法流程圖；
[0021 ] 圖4-a為一個實施例的提前重復應答示意圖；
[0022] 圖4-b為一個實施例的提前應答示意圖；
[0023] 圖5為一個實施例的設(shè)置最大提前應答量的方法流程圖；
[0024] 圖6為一個實施例的接收用戶端對序號為N的數(shù)據(jù)包的第一應答包之后的處理流 程圖；
[0025] 圖7為第一實施例的基站下行傳輸控制系統(tǒng)的結(jié)構(gòu)示意圖；
[0026] 圖8為一個實施例的第二接收模塊的結(jié)構(gòu)示意圖；
[0027] 圖9為一個實施例的提前應答調(diào)整模塊的結(jié)構(gòu)示意圖；
[0028] 圖10為第二實施例的基站下行傳輸控制系統(tǒng)的結(jié)構(gòu)示意圖。
【具體實施方式】
[0029] 下面結(jié)合附圖對本發(fā)明的技術(shù)方案做進一步闡述。
[0030] 為了簡化分析現(xiàn)有移動通信領(lǐng)域基站的現(xiàn)狀，以LTE制式基站為例，其數(shù)據(jù)傳輸 處理大致涉及MAC、RLC、H)CP、S1等主要協(xié)議，其中S1層數(shù)據(jù)形態(tài)銜接網(wǎng)絡數(shù)據(jù)傳輸與基 站內(nèi)部rocp等協(xié)議數(shù)據(jù)處理，數(shù)據(jù)流程涉及的協(xié)議結(jié)構(gòu)如圖i所示。
[0031] 現(xiàn)有的基站下行傳輸控制主要涉及以下協(xié)議：
[0032] 1)S1協(xié)議相關(guān)處理，S1承接基站網(wǎng)絡側(cè)數(shù)據(jù)，基于終端用戶的英特網(wǎng)協(xié)議（IP)數(shù) 據(jù)包，S1添加相應的頭部信息，打包后即發(fā)往網(wǎng)絡側(cè)，反向同理，接收來自網(wǎng)絡側(cè)的數(shù)據(jù)，剔 除S1相應頭部信息，發(fā)往基站下游模塊（PDCP);
[0033] 2)F*DCP協(xié)議相關(guān)處理，分組數(shù)據(jù)匯聚協(xié)議（PacketDataConvergenceProtocol) 層屬于無線接口協(xié)議棧的第二層，處理控制平面的無線資源管理（RRC)消息以及用戶平面 的英特網(wǎng)協(xié)議（IP)包。在用戶平面上，rocp子層得到來自上層的IP數(shù)據(jù)分組包，可以對 IP數(shù)據(jù)分組進行頭壓縮和加密，然后遞交到RLC子層，反向同理，接收來自RLC子層的數(shù)據(jù)， 經(jīng)過頭部解壓縮、解密，還原用戶的英特網(wǎng)協(xié)議（IP)數(shù)據(jù)分組包發(fā)往上游模塊（S1);
[0034] 3)RLC/MAC/PHY協(xié)議相關(guān)處理，LTE基站涉及此三大領(lǐng)域的處理，均為嚴格按照協(xié) 議約束實現(xiàn)，在此不做累述。
[0035] 現(xiàn)有系統(tǒng)具有以下不足：
[0036] (1)現(xiàn)有系統(tǒng)由于并不涉足用戶TCP/IP分組數(shù)據(jù)內(nèi)容，未代理終端在TCP協(xié)議上 提前回饋服務器應答，這方面工作可以減小網(wǎng)絡回傳時間；
[0037] (2)現(xiàn)有系統(tǒng)由于并不涉足用戶TCP/IP分組數(shù)據(jù)內(nèi)容，未能掌握用戶傳輸層數(shù)據(jù) 動態(tài)，對于網(wǎng)絡丟包等事件未能先于終端用戶做出反應，比如基站提前回饋服務器重復應 答，這方面工作可以觸發(fā)快速重傳；