衛(wèi)星鏈路傳輸4G網(wǎng)絡(luò)問題研究

岳鸝（工業(yè)和信息化部應(yīng)急通信保障中心）

隨著通信技術(shù)的快速發(fā)展，地面移動的2G、3G通信系統(tǒng)已被4G網(wǎng)絡(luò)所取代，5G技術(shù)也撲面而來。在高新技術(shù)不斷發(fā)展的時代，我們必須把握發(fā)展機遇，加緊創(chuàng)新研究，緊跟時代步伐，做好充分準備?；ヂ?lián)網(wǎng)早已實現(xiàn)衛(wèi)星通信鏈路傳輸，我國為此發(fā)射了“中星16”和“中星18”互聯(lián)網(wǎng)專用衛(wèi)星。由于我國地理條件復(fù)雜，移動地面網(wǎng)絡(luò)覆蓋還存在許多盲區(qū)，給應(yīng)急通信保障帶來許多挑戰(zhàn)。所以我想研究衛(wèi)星鏈路傳輸4G網(wǎng)絡(luò)相關(guān)問題，希望能給有關(guān)應(yīng)用提供參考。

1.4G網(wǎng)絡(luò)特征

為了理清衛(wèi)星信道對4G基站業(yè)務(wù)傳輸影響，我們首先必須了解4G的網(wǎng)絡(luò)傳輸特征，研究其網(wǎng)絡(luò)體系架構(gòu)和通信協(xié)議，再結(jié)合衛(wèi)星通信信道特性，開展針對性的試驗，由此來分析4G基站業(yè)務(wù)通過衛(wèi)星信道傳輸存在的問題。

1.1 4G網(wǎng)絡(luò)的特點

當前，我們正在使用的4G網(wǎng)絡(luò)是從最初的GSM通用無線分組數(shù)據(jù)業(yè)務(wù)和3G移動通信系統(tǒng)演進而來的。國際電信聯(lián)盟規(guī)定4G網(wǎng)絡(luò)標準是符合下行150 Mbps，上行50 Mbps數(shù)據(jù)傳輸速率的通信系統(tǒng)，相對于3G的30Mbps傳輸速率，顯然有了很大的發(fā)展。4G的技術(shù)協(xié)議和網(wǎng)絡(luò)結(jié)構(gòu)與GSM、3G等網(wǎng)絡(luò)相比都發(fā)生了很多變化：一是空中接口技術(shù)演進為LTE，采用正交頻分復(fù)用（OFDM）和多輸入、多輸出（MIMO）作為無線網(wǎng)絡(luò)標準；二是核心網(wǎng)演進為EPC，由信令實體（MME）、服務(wù)網(wǎng)關(guān)（SGW）、PDN網(wǎng)關(guān)（PGW）、策略與計費（PCRF）等網(wǎng)元構(gòu)成,采用全IP分布式的結(jié)構(gòu)，只有分組域，沒有電路域；三是無線接入UTRAN演進為E-UTRAN。E-UTRAN由多個基站（eNodeB）組成，eNodeB除了具有原來3G網(wǎng)絡(luò)中NodeB功能外，還增加了網(wǎng)絡(luò)控制（RNC）功能；eNodeB和eNodeB之間采用網(wǎng)格方式直接相連。正是由于這些特點，從而實現(xiàn)了4G業(yè)務(wù)的高速傳輸和與因特網(wǎng)的深度融合，可為用戶提供高質(zhì)量的語音、數(shù)據(jù)、視頻等豐富多彩的業(yè)務(wù)服務(wù)，極大滿足了用戶隨時隨地、多種方式接入的通信需求。

1.2 4G網(wǎng)絡(luò)架構(gòu)

LTE網(wǎng)絡(luò)結(jié)構(gòu)與3G相比進行了大幅度簡化，使得整個網(wǎng)絡(luò)功能發(fā)生了如下變化：一是控制面與用戶面完全分離，網(wǎng)絡(luò)趨向扁平化；二是兼容3GPP與非3GPP的多種標準接入，并支持用戶在3GPP網(wǎng)絡(luò)和非3GPP網(wǎng)絡(luò)之間的漫游和切換；三是核心網(wǎng)中不再有電路域，EPC成為移動電信業(yè)務(wù)的基本承載網(wǎng)絡(luò)。4G網(wǎng)絡(luò)采用IP RAN作為基站與核心網(wǎng)之間的傳輸承載網(wǎng)絡(luò)，IP RAN中的IP 是指互聯(lián)協(xié)議，RAN是指無線接入網(wǎng)。IP RAN組網(wǎng)方案可以滿足LTE移動網(wǎng)絡(luò)的全IP化和高帶寬等通信要求。目前基于衛(wèi)星信道的IP傳輸技術(shù)也已成熟，利用衛(wèi)星通道實現(xiàn)IP RAN傳輸4G基站業(yè)務(wù)，已有人做過一定的理論研究和實踐探索。因此，本人將對4G基站與EPC核心網(wǎng)接入作進一步研究。

1.3 4G基站相關(guān)接口

通過對網(wǎng)絡(luò)架構(gòu)的研究，4G基站通常有S1和X2兩種接口，如圖1.1所示。

S1接口：S1接口包括S1-U用戶平面接口和S1-MME控制層接口兩種。S1-U用戶平面接口是用于基站與核心網(wǎng)SGW單元之間的連接，基于GTP傳輸協(xié)議，提供基站和SGW之間的信息傳輸。GTP協(xié)議只對用戶數(shù)據(jù)進行封裝，但不提供數(shù)據(jù)傳輸控制機制；S1-MME控制層接口是用于基站與核心網(wǎng)MME單元之間的連接，S1-MME接口采用流量傳輸協(xié)議SCTP，確?？刂菩帕顢?shù)據(jù)的可靠傳輸。

X2接口：X2主要實現(xiàn)基站之間的互聯(lián)，包括X2-C（控制層）、X2-U（用戶層），分別傳送控制信令及部分用戶數(shù)據(jù)。LTE基站S1和X2接口對于業(yè)務(wù)及信令數(shù)據(jù)的傳遞，采用了不同的協(xié)議標準，其中，業(yè)務(wù)數(shù)據(jù)是基于GTP/UDP傳輸協(xié)議，而信令數(shù)據(jù)是基于SCTP/IP協(xié)議。如S1協(xié)議棧簡圖（圖1.2）所示。

圖1.1 4G基站常見接口

圖1.2 S1接口協(xié)議棧結(jié)構(gòu)

用戶平面接口位于E-NodeB和SGW之間，傳輸網(wǎng)絡(luò)層建立在IP傳輸之上，UDP/IP之上的GTP-U用來攜帶用戶平面的分組數(shù)據(jù)單元，內(nèi)含TCP/UDP承載的應(yīng)用層數(shù)據(jù)。S1控制平面接口位于NodeB和MME之間，傳輸網(wǎng)絡(luò)層是利用IP傳輸，為了可靠傳輸信令消息，在IP層之上添加了SCTP協(xié)議，承載S1-AP應(yīng)用層信令協(xié)議。

由圖1.3我們可以看到用戶業(yè)務(wù)仍然由TCP/UDP承載，但與傳統(tǒng)TCP/IP結(jié)構(gòu)不同的是用戶應(yīng)用層的TCP/UDP由GTPU承載后，再由UDP/IP承載。由此我們可以得到一個由用戶端-核心網(wǎng)-服務(wù)器完整的協(xié)議架構(gòu)示意圖（圖1.4）。

通過對4G網(wǎng)絡(luò)協(xié)議棧的分析，我們可以看到用戶數(shù)據(jù)仍然依托于TCP、UDP協(xié)議，由此我們只需明確TCP、UDP受衛(wèi)星信道的影響即可。

2.衛(wèi)星信道特性分析

2.1 衛(wèi)星通信帶寬資源

衛(wèi)星通信系統(tǒng)主要由通信衛(wèi)星和地球站組成，目前衛(wèi)星通信使用頻率從0.3GHz到300GHz,頻段從UHF、L、S、C、X、Ku、Ka,直到G、R，帶寬資源極其豐富，可滿足各類常規(guī)通信需求。但由于通信衛(wèi)星、衛(wèi)星地球站都存在能力上限，通常情況下，不同頻段的衛(wèi)星通信系統(tǒng)傳輸能力存在一定差異，S頻段單站傳輸速率可達1024Kbps，C頻段單站傳輸速率可達20Mbps，Ku頻段單站傳輸速率可達40Mbps的能力，Ka頻段下行速率可達150Mbps。這與IP RAN提供的GE接入能力相比，差距懸殊較大。

2.2 衛(wèi)星通信鏈路時延

目前，我國的通信衛(wèi)星主要采用GEO衛(wèi)星，GEO衛(wèi)星位于赤道上空距地約35786km的同步軌道上，信號從地面發(fā)射至衛(wèi)星，再經(jīng)衛(wèi)星轉(zhuǎn)發(fā)回到地面，鏈路時延達240ms，加上信號處理時延，則鏈路總時延約為260ms。如果通過GEO搭建衛(wèi)星IP通道，通道PING延時約540-600ms。3GPP對LTE傳輸時延有具體規(guī)定，以S1接口為例，S1-U時延要求最高，時延要求控制在5ms以內(nèi)，S1-MME時延要求較低，一般要求小于100ms?？梢?，衛(wèi)星IP通道時延可能是影響4G基站業(yè)務(wù)傳輸?shù)囊粋€重要原因。

圖1.3 信令與數(shù)據(jù)協(xié)議流程

圖1.4 用戶端-核心網(wǎng)-服務(wù)器完整的協(xié)議架構(gòu)示意圖

2.3 衛(wèi)星信道傳輸4G業(yè)務(wù)試驗

為了驗證衛(wèi)星通信時延對4G業(yè)務(wù)傳輸?shù)挠绊?，我們采用雙向20Mbps衛(wèi)星資源來做4G基站業(yè)務(wù)的傳輸試驗，系統(tǒng)框圖如圖2.1所示。

試驗結(jié)果（參見表2.1）表明：4G業(yè)務(wù)速率無論是10Mbps，還是20Mbps，上行傳輸速率和下行接收速率都在5Mbps左右，若信號不經(jīng)衛(wèi)星鏈路，圖上的兩個調(diào)制解調(diào)器直接連接，上行傳輸速率和下行接收速率與4G業(yè)務(wù)速率基本一致。通過比較，便可發(fā)現(xiàn)衛(wèi)星通信鏈路傳輸4G業(yè)務(wù)存在一個瓶頸，速率只能在5Mbps左右；此時衛(wèi)星中繼帶寬速率為20Mbps、10Mbps，遠大于業(yè)務(wù)測試速率5Mbps。由此可以確定造成業(yè)務(wù)傳輸速率低的主要原因是來自于衛(wèi)星通信信道。而衛(wèi)星通信鏈路與地面?zhèn)鬏斅酚傻淖畲蟛顒e就是存在一定的信號傳輸時延，這也正是4G業(yè)務(wù)傳輸?shù)年P(guān)鍵指標，所以我們要做深入研究。

2.3.1 延時對TCP業(yè)務(wù)影響

由于TCP傳輸協(xié)議采用確認應(yīng)答方式，其數(shù)據(jù)吞吐量不僅取決于信道的傳輸速率，還與數(shù)據(jù)往返時延RTT有關(guān)。在TCP/IP標準中，最大數(shù)據(jù)吞吐量可用下列公式表示：

最大數(shù)據(jù)吞吐量=最大接收窗口/RTT

在TCP/IP協(xié)議中，最大吞吐量不僅僅取決于RTT，還受到擁塞控制算法影響。因此，衛(wèi)星信道所支持的單TCP連接數(shù)據(jù)速率存在一定上限。

為驗證延時對TCP業(yè)務(wù)的影響，我們設(shè)計使用TCP典型應(yīng)用來傳送FTP文件，并進行下載速率測試。測試系統(tǒng)的連接框圖如圖2.2所示，測試數(shù)據(jù)見表2.2。

通過測試我們可以看到無論衛(wèi)星通道速率提高多少，單個TCP連接速率都沒有明顯變化，顯然衛(wèi)星通道延時對TCP業(yè)務(wù)造成了嚴重影響。

2.3.2 延時對UDP業(yè)務(wù)影響

對于UDP協(xié)議來說，因數(shù)據(jù)流沒有采用嚴格的應(yīng)答確認機制，因此不受衛(wèi)星窗口時延限制，在實際應(yīng)用中速率只受衛(wèi)星帶寬影響。

圖2.1 通信衛(wèi)星傳輸4G業(yè)務(wù)系統(tǒng)連接框圖（CPE）

表2.1 測試結(jié)果

圖2.2 延時對TCP影響測試示意圖

表2.2 測試結(jié)果

為驗證上述分析，我們也設(shè)計了一次衛(wèi)星測試。使用H.264高清編碼器輸出IP視頻流。IP視頻流通常采用UDP封裝，在衛(wèi)星接收端使用具備IP解碼功能的解碼器對接收碼流進行解碼，測試系統(tǒng)的連接框圖如圖2.3所示。

測試中使用25Mbps的衛(wèi)星通信資源，分別傳送了25Mbps和16Mbps兩種速率的視頻碼流，通過解調(diào)設(shè)備監(jiān)測碼流情況，用解碼器接收碼流并記錄視頻解碼情況。測試結(jié)果見圖2.4及表2.3。

通過測試結(jié)果可以看到延時對UDP沒有影響。

前面通過對4G網(wǎng)絡(luò)協(xié)議結(jié)構(gòu)和S1結(jié)構(gòu)協(xié)議棧的分析，并結(jié)合針對性試驗，驗證了高延時對TCP應(yīng)用有影響，對UDP沒有影響，由此我們要進一步研究TCP應(yīng)用速率形成機制及其解決辦法。

3.TCP加速技術(shù)研究

TCP（Transmission Control Protocol 傳輸控制協(xié)議）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。在簡化的計算機網(wǎng)絡(luò)OSI模型中，TCP完成傳輸層所指定的功能，與用戶數(shù)據(jù)協(xié)議UDP是同一層內(nèi)，使用不同傳輸協(xié)議；在因特網(wǎng)協(xié)議族（Internet protocol suite）中，TCP是位于IP層之上、應(yīng)用層之下的中間層。不同主機的應(yīng)用層之間經(jīng)常需要可靠的、像管道一樣的連接，但IP層不提供這樣的流機制，只提供包交換。

3.1 擁塞控制

如果發(fā)送端發(fā)送的速度較快，接收端接收到數(shù)據(jù)后處理的速度較慢，而接收緩沖區(qū)的大小是固定的，就會丟失數(shù)據(jù)。TCP協(xié)議通過“滑動窗口（SlidingWindow）”機制解決這一問題。到目前為止，TCP 擁塞控制技術(shù)已經(jīng)歷了兩代技術(shù)演進：一次是 Loss-based (基于丟包的擁塞判斷及處理)，即以丟包來判斷擁塞并調(diào)整傳輸速率；一次是 Delay-based(基于延遲的擁塞判斷及處理)，即以往返延遲(Round Trip Time)變化來判斷擁塞并調(diào)整傳輸速率。無論是 Loss-based 還是 Delay-based，TCP 加速技術(shù)都采用靜態(tài)算法,即基于對互聯(lián)網(wǎng)流量模型的假設(shè)為前提，采用固定的擁塞判斷及恢復(fù)機制。但隨著網(wǎng)絡(luò)的發(fā)展，流量特征變得越來越復(fù)雜，并難以預(yù)測。因此，Loss-based和 Delay-based 的TCP 加速技術(shù)，通常只在前提假設(shè)成立的特定網(wǎng)絡(luò)場景下有效，并且隨著傳輸?shù)倪M行，網(wǎng)絡(luò)路徑特征發(fā)生變化，效果也會起伏不定，有時甚至出現(xiàn)異常情況。

3.2 速率及其影響因素

圖2.3 延時對UDP影響測試示意圖

圖2.4 25Mbps衛(wèi)星通道下的不同速率碼流流量圖

表2.3 25Mbps衛(wèi)星通道下的不同速率傳輸碼流對照

TCP是一個滑動的窗口協(xié)議，即一個TCP連接的發(fā)送端在某個時刻能發(fā)多少數(shù)據(jù)是由滑動窗口控制的，而滑動窗口的大小實際上是由兩個窗口共同決定的。一個是接收端的通告窗口。這個窗口數(shù)值存在TCP協(xié)議頭部信息中，會隨著數(shù)據(jù)的ACK包發(fā)至發(fā)送端，這個值表示的是在接收端的TCP協(xié)議緩存中還有多少剩余空間，發(fā)送端必須保證發(fā)送的數(shù)據(jù)不超過這個剩余空間，以免造成緩沖區(qū)溢出。這個窗口是接收端用來進行流量控制的，在傳輸過程中，通告窗口大小與接收端的進程快慢有關(guān)。另一個窗口是發(fā)送端的擁塞窗口(Congestion window)，由發(fā)送端維護這個值，在協(xié)議頭部信息中沒有，滑動窗口的大小就是通告窗口和擁塞窗口的最小值。所以擁塞窗口也可看作是發(fā)送端用來進行流量控制的窗口?；瑒哟翱诘淖筮呇叵蛴乙苿臃Q為窗口合攏，發(fā)生在發(fā)送的數(shù)據(jù)被確認時，即此時數(shù)據(jù)已被接收端收到，不會被重傳，可以從發(fā)送端的發(fā)送緩存中清除；滑動窗口的右邊沿向右移動稱為窗口張開，發(fā)生在接收進程從接收端協(xié)議緩存中取出數(shù)據(jù)的時間。隨著發(fā)送端不斷收到的被發(fā)送數(shù)據(jù)的ACK包，根據(jù)ACK包中的確認序號和通告窗口大小使滑動窗口得以不斷的合攏和張開，形成滑動窗口的向前滑動。如果接收進程一直不取數(shù)據(jù)，則會出現(xiàn)0窗口現(xiàn)象，即滑動窗口左邊沿與右邊沿重合，此時窗口大小為0，就無法再發(fā)送數(shù)據(jù)。

3.2.1 帶寬

帶寬是指單位時間內(nèi)從發(fā)送端到接收端所能通過的“最高數(shù)據(jù)率”，是一種硬件限制。TCP發(fā)送端和接收端的數(shù)據(jù)傳輸數(shù)率不可能超過兩點間的帶寬限制。

3.2.2 時延

時延RTT即Round Trip Time，表示從發(fā)送端到接收端的往返時間，TCP在數(shù)據(jù)傳輸過程中會對RTT進行采樣（即對發(fā)送的數(shù)據(jù)包及其ACK的時間差進行測量，并根據(jù)測量值更新RTT值），TCP根據(jù)得到的RTT值更新RTO值，即Retransmission TimeOut，就是重傳間隔，發(fā)送端對每個發(fā)出的數(shù)據(jù)包進行計時，如果在RTO時間內(nèi)沒有收到所發(fā)數(shù)據(jù)包對應(yīng)的ACK，則表示任務(wù)數(shù)據(jù)包丟失，將重傳數(shù)據(jù)。一般RTO值都比采樣得到的RTT值要大。

3.2.3 帶寬時延乘積：

帶寬與時延的乘積，即帶寬×RTT，實際上等于兩倍發(fā)送端到接收端單向通道的數(shù)據(jù)容積。單向通道可看成是一條單行道馬路，帶寬就是馬路的車道數(shù)，路上跑的汽車就是數(shù)據(jù)，只不過這里所有汽車的速率都是一樣的。那么單向通道的數(shù)據(jù)容積就是這條單行道上擺滿車，一共可以擺多少輛。這里順便介紹發(fā)送時延和傳播時延的差別，單位數(shù)據(jù)量發(fā)送時延是由帶寬決定的。以馬路來類比，假如有10輛車，如果車道數(shù)為1，那么這10輛車只能按首尾相接的順序上路，從第一輛車的車頭到最后一輛車的車尾可以看作是發(fā)送時延，此時就是10輛車的車長，如果把車道數(shù)改成10，那么這10輛車可以并排上路，發(fā)送時延就變成了一輛車的車長了，由此可見，帶寬越大，則發(fā)送時延越短。傳播時延則是由電的傳播速度（是個常量）以及發(fā)送和接收端線路的物理長度決定的。比如從美國到中國，傳播時延就很大，如果在一個局域網(wǎng)內(nèi)部，傳播時延就很小。因為發(fā)送時延主要與數(shù)據(jù)量大小有關(guān)系，所以RTT只考慮傳播時延。

由此可以看出，假設(shè)Tr是一個定值，那么決定TCP速率的唯一因素就是TCP的滑動窗口大小?，F(xiàn)在再考慮帶寬限制，前面說過當馬路上擺滿車的時候，就無法再往里放車了，同理，TCP發(fā)送端在Tr/2時間內(nèi)，能往通道上放的數(shù)據(jù)量為 V×Tr/2，當V×Tr/2≤B×Tr/2時，單向通道容積不構(gòu)成瓶頸，速率的限制主要來源于窗口大小限制。而當V×Tr/2＞B×Tr/2時，則就受到容積限制，即此時速率限制來源于帶寬限制。把V×Tr/2≤B×Tr/2和V×Tr/2＞B×Tr/2兩邊的Tr/2約掉，再把V=W/Tr代入，則可以得到 ：

W≤B×Tr 或 W＞B×Tr

B×Tr就是帶寬時延乘積，取W為TCP能支持窗口的最大值Wmax，當Wmax ≤ B×Tr時，此時發(fā)送和接收端之間的通道就是所謂的長粗管道，即帶寬時延乘積大的通道。因此，在W＜B×Tr時，影響TCP發(fā)送數(shù)據(jù)速率的最直接的因素是滑動窗口的大小，TCP的流量控制策略（比如超時窗口設(shè)置為1，重復(fù)ACK時窗口減半）最終都是通過控制窗口大小來控制速率；而慢啟動，擁塞避免這些流量控制算法，實際上就是控制窗口增長方式的算法，也是控制加速度大小。當W＞B×Tr時，則影響速率的因素就是帶寬和時延了。

3.3 加速技術(shù)介紹

TCP加速指的是通過一組優(yōu)化技術(shù)，使TCP在通過Internet傳輸數(shù)據(jù)的性能更高，且不需要修改具體應(yīng)用。目前主流TCP加速技術(shù)主要包括雙邊TCP優(yōu)化和單邊TCP優(yōu)化兩種。

3.3.1 雙邊TCP加速

雙邊TCP優(yōu)化是指在TCP連接的兩端部署硬件設(shè)備或安裝軟件，TCP透明代理工作在TCP連接的兩端，兩個代理之間通常使用UDP或其它自定義協(xié)議進行工作。2002年前后，美國的一些創(chuàng)業(yè)公司開始嘗試解決這一問題，通過將傳統(tǒng)TCP傳輸協(xié)議轉(zhuǎn)換成更適合鏈路情況的私有協(xié)議來提高應(yīng)用數(shù)據(jù)在廣域網(wǎng)上的傳輸效率，突破了TCP的技術(shù)瓶頸。這項技術(shù)被稱為“TCP加速”。由于轉(zhuǎn)換過的私有協(xié)議無法與傳統(tǒng)TCP協(xié)議互通，這些解決方案都要求在連接的兩端同時部署支持同樣私有協(xié)議的加速設(shè)備。這種雙邊部署TCP加速技術(shù)對企業(yè)不同分支的遠程文件傳輸、遠端連接的各類企業(yè)應(yīng)用起到了很好的效果。于是，有許多分支機構(gòu)的大企業(yè)通過在每個分支機構(gòu)部署TCP加速產(chǎn)品來提高網(wǎng)間帶寬的利用率。

3.3.1.1 TCP透明代理的工作原理

透明代理與TCP連接的兩端分別進行交互，這樣就把端到端的TCP控制分割成幾部分，并根據(jù)各部分的丟包、延時情況進行不同的優(yōu)化，從而提高TCP的性能。TCP加速的核心思想就是采用透明代理的方式，將TCP一端連接終結(jié)，然后重新發(fā)起一個連接到TCP的另外一端。這樣，兩端的數(shù)據(jù)包都被緩存在兩端的TCP加速器上，TCP加速器之間的數(shù)據(jù)發(fā)送由TCP加速器進行控制。在實際使用過程中，TCP協(xié)議的兩端與軟件或硬件設(shè)備在一個局域網(wǎng)內(nèi)，兩個透明代理設(shè)備之間是廣域網(wǎng)鏈路，通常具有一定的丟包、延時，會造成TCP性能下降，所以在這兩個透明代理之間，通常將協(xié)議轉(zhuǎn)換為UDP協(xié)議或其它自定義協(xié)議，這些協(xié)議本身可以完全按照自己的要求進行控制，達到提高TCP性能的效果；同時，雙邊TCP加速還可以引入壓縮、緩存等技術(shù)進一步提高TCP性能。

雙邊TCP優(yōu)化比較適用于公司具有多個分支機構(gòu)的情況，在這種情況下，TCP連接的兩端通常比較容易控制，比較容易安裝硬件設(shè)備或軟件客戶端。

3.3.2 單邊TCP加速

單邊TCP加速只在TCP的一端部署軟件或設(shè)備，達到提升TCP性能的目標。單邊TCP加速的一個基本要求就是經(jīng)過透明代理出去的協(xié)議必須是TCP協(xié)議。單邊TCP加速的透明代理，在WAN一側(cè)運行的是一個與標準TCP兼容，且性能提高的TCP。絕大多數(shù)的單邊TCP加速，都是在通過改進TCP的擁塞控制算法來進行的。與雙邊TCP相比，單邊TCP優(yōu)化的適應(yīng)性更廣，且更靈活。例如只要在服務(wù)器端進行了TCP加速，所有訪問此服務(wù)器的客戶端都會受益，并且不需要客戶端安裝任何軟件或部署硬件設(shè)備。這樣，就更加適用于服務(wù)器的訪問對象不固定的情況。

我們研究TCP首部結(jié)構(gòu)、TCP連接的建立與斷開、TCP的速率形成機制及其影響因素，同時還研究了常見TCP加速技術(shù)。目的是將TCP加速技術(shù)能應(yīng)用到4G網(wǎng)絡(luò)之中。

4.衛(wèi)星4G加速方案研究

通過對4G系統(tǒng)的深入了解，我們發(fā)現(xiàn)4G業(yè)務(wù)速率受限是由于延時對TCP業(yè)務(wù)影響造成的，而在針對TCP加速方面有很多方法可以解決延時帶來的問題，于是我們嘗試提出了幾種4G網(wǎng)絡(luò)加速方案。

4.1 加速方案一

本方案是一個雙邊加速方案，通過在衛(wèi)星通道兩側(cè)部署加速設(shè)備來實現(xiàn)將衛(wèi)星通道“透明化”，通過“欺騙”方式使得TCP算法對衛(wèi)星時延“視而不見”。

4.1.1 方案介紹

如圖4.1所示，在衛(wèi)星通信鏈路S1通道兩端分別串入加速設(shè)備A、B，加速設(shè)備能夠識別解析S1中的TCP數(shù)據(jù)包，將原有TCP連接分割成三段：服務(wù)器---A，A---B，B---用戶。加速器A、B通過對TCP連接的分割實現(xiàn)對服務(wù)器和用戶的欺騙，服務(wù)器將A‘誤認為’是用戶，用戶將B‘誤認為’是服務(wù)器，而服務(wù)器與用戶的RTT測量會變得很短，由此可以完成消除時延對TCP連接的影響。

4.1.2 方案分析

基于TCP/IP的雙邊加速辦法已經(jīng)非常普遍，本方案實現(xiàn)難點在于對S1通道內(nèi)TCP數(shù)據(jù)的識別，因S1內(nèi)的TCP數(shù)據(jù)包是由GTP—UDP—IP承載，雖然識別復(fù)雜程度發(fā)生很大變化，但GTP、UDP均為成熟可測量格式，所以TCP識別完全可行，目前也有相關(guān)技術(shù)可以借鑒。

本方案投入成本可控，僅為兩臺加速器，設(shè)備操作也不復(fù)雜，加速效果明顯，部署迅速，同時對4G網(wǎng)絡(luò)沒有任何影響。本方案僅用于單個衛(wèi)星4G基站的加速，如果衛(wèi)星中繼網(wǎng)絡(luò)需要拓展，必須要增加更多的加速器接入，才能滿足要求。

4.2 加速方案二

本方案采取單邊加速策略，在ECP與互聯(lián)網(wǎng)之間接入代理服務(wù)器，通過代理服務(wù)器完成對衛(wèi)星通道延時的識別、適配等，從而實現(xiàn)用戶速率的提升。

4.2.1 方案介紹

圖4.1 雙邊加速方案示意圖

圖4.2 核心網(wǎng)側(cè)加速服務(wù)器方案示意圖

如圖4.2所示，在EPC與互聯(lián)網(wǎng)間架設(shè)代理服務(wù)器，代理服務(wù)器將原有TCP連接分為兩段：服務(wù)器----代理服務(wù)器，代理服務(wù)器----用戶。在功能實現(xiàn)上，代理服務(wù)器無需具備穿透S1尋找TCP的能力，因為核心網(wǎng)與互聯(lián)網(wǎng)通道就是IP通道，代理服務(wù)器可以在IP通道上輕松識別TCP數(shù)據(jù)包，輕松實現(xiàn)對TCP連接的修改工作。代理服務(wù)器面對服務(wù)器時，由于鏈路延時處于理想范圍，業(yè)務(wù)速率不受影響。代理服務(wù)器面對用戶時，由于衛(wèi)星鏈路延時大，此時服務(wù)器可通過調(diào)整擁塞控制算法忽略衛(wèi)星鏈路時延造成的影響。

4.2.2 方案分析

加速服務(wù)器因為位于核心網(wǎng)側(cè)，利用位置優(yōu)勢可以取得更高速率等級的服務(wù)。同時代理服務(wù)器還可以對整個4G網(wǎng)絡(luò)用戶進行速率優(yōu)化工作，提高4G網(wǎng)絡(luò)的用戶感知。由于4G網(wǎng)絡(luò)規(guī)模龐大、用戶復(fù)雜，代理服務(wù)器在面對衛(wèi)星4G用戶時，需要具備識別、管理、處理等能力，因此需要在網(wǎng)絡(luò)規(guī)劃、服務(wù)器配置上做很多工作。

4.3 加速方案三

本方案采取單邊加速策略，在基站和EPC間部署代理服務(wù)器，通過代理服務(wù)器實現(xiàn)對用戶業(yè)務(wù)的加速。

4.3.1 方案介紹

如圖4.3所示，在EPC與基站間架設(shè)代理服務(wù)器，代理服務(wù)器將原有TCP連接分為兩段：服務(wù)器——代理服務(wù)器，代理服務(wù)器——用戶。在功能實現(xiàn)上，由于代理服務(wù)器位于S1通道上，所以代理服務(wù)器須具備穿透S1尋找TCP的能力，實現(xiàn)對TCP連接的修改工作。代理服務(wù)器面對服務(wù)器時，由于鏈路延時處于理想范圍，業(yè)務(wù)速率不受影響。代理服務(wù)器面對用戶時，由于衛(wèi)星鏈路引入高延時，此時服務(wù)器通過調(diào)整擁塞控制算法，可忽略衛(wèi)星鏈路延時造成的影響，保證用戶速率的正常。

4.3.2 方案分析

加速服務(wù)器位于基站與核心網(wǎng)間，通過代理模式對TCP鏈路進行加速，在與用戶側(cè)鏈接中通過算法調(diào)整，來對抗衛(wèi)星延時影響。代理服務(wù)器需要具備穿透S1解析GTP尋找TCP數(shù)據(jù)包的能力，雖然目前沒有相關(guān)產(chǎn)品，但是技術(shù)上是完全可行的。

通過對三種衛(wèi)星4G基站加速方案的分析，使我們對加速機制、實現(xiàn)難點，各種方案的優(yōu)缺點都有了一定的了解，為我們后續(xù)應(yīng)用提供參考。

5.單衛(wèi)星4G基站加速試驗與測試

針對上面提出的三種加速方案，我們嘗試采用第一種方案對衛(wèi)星4G基站進行了加速測試。

5.1 加速方案鏈路連接

本次測試方案使用第一種加速方法，即雙邊加速，通過使用專用的S1加速設(shè)備完成S1通道中的TCP加速工作。我們利用載波疊加、高階調(diào)制搭建了一條雙向20Mbps的衛(wèi)星IP通道，4G基站先通過加速設(shè)備再經(jīng)過衛(wèi)星通道與EPC網(wǎng)絡(luò)連接，反向通道類似。經(jīng)過對加速器參數(shù)配置后，整個4G基站就具備開通測試環(huán)境（參見圖5.1）。

圖4.3 基站側(cè)加速服務(wù)器方案示意圖

圖5.1 全通路加速測試技術(shù)方案及參數(shù)

表5.1 不同衛(wèi)星通道速率下的加速測試結(jié)果

5.2 測試數(shù)據(jù)分析

通過以上測試結(jié)果（表5.1），我們可以看到業(yè)務(wù)速率在加速前后效果變化明顯，加速前速率受限于5Mbps，加速后上下行速率基本達到衛(wèi)星通道上限?？梢娂铀倌芙鉀Q延時引起的速率受限問題。

6.多4G基站加速方案研究

在實現(xiàn)單個衛(wèi)星4G基站加速之后，我們又考慮如何利用寬帶衛(wèi)星網(wǎng)實現(xiàn)多4G基站加速工作。

6.1 加速方案介紹

如圖6.1所示，目前的寬帶衛(wèi)星VSAT網(wǎng)絡(luò)都是基于IP通道技術(shù)實現(xiàn)各種數(shù)據(jù)業(yè)務(wù)傳輸?shù)?，這種IP通道性能也適用于4G基站的回傳，而結(jié)合衛(wèi)星寬帶VSAT技術(shù)來傳輸4G基站業(yè)務(wù)，既可確保功能實現(xiàn)，又能綜合利用衛(wèi)星帶寬，提高頻帶利用率。組網(wǎng)方案如圖6.1所示。

與傳統(tǒng)的單個衛(wèi)星4G基站接入相比，我們每增加一個基站，就可節(jié)省一個衛(wèi)星站，因為我們采用了1：N的衛(wèi)星站拓撲結(jié)構(gòu)。當然，在實現(xiàn)衛(wèi)星4G接入的同時我們?nèi)匀幻媾R4G業(yè)務(wù)加速的問題。

如果我們?nèi)匀徊捎秒p邊加速技術(shù)，在衛(wèi)星通道兩側(cè)添加加速設(shè)備，那么我們每增加1個4G基站，我們便需要額外增加2臺加速設(shè)備，顯然這會大大增加接入成本，于是采用單邊加速策略成為一個性價比很高的解決辦法，如圖6.3所示。

在主站與EPC網(wǎng)絡(luò)接口間添加加速服務(wù)器（代理服務(wù)器），即上面介紹的第三種加速方案。通過以上加速方法，我們既可以實現(xiàn)對4G業(yè)務(wù)的加速，又可減少設(shè)備投入，降低成本，可見在多4G基站與衛(wèi)星鏈路接入時，這種加速方案更優(yōu)于其他兩種加速方案。

6.2 應(yīng)用展望

目前，我們只基于C、Ku兩個頻段的衛(wèi)星通信系統(tǒng)，驗證10Mbps左右衛(wèi)星組網(wǎng)的傳輸能力，但在國際上商用Ka頻段衛(wèi)星通信業(yè)務(wù)已經(jīng)發(fā)展到100Mbps至1Gbps量級的衛(wèi)星組網(wǎng)通信能力。2017年4月，我國發(fā)射的“中星16號”高通量衛(wèi)星，這是我國首顆Ka頻段互聯(lián)網(wǎng)衛(wèi)星，下行速率也進入百兆以上速率時代。隨著各頻段衛(wèi)星通信系統(tǒng)的發(fā)展運用，高鐵、飛機、輪船等移動載體上的4G基站與衛(wèi)星通信組網(wǎng)方式相結(jié)合將成為性價比最高的解決方案。

可見本文創(chuàng)新性提出的加速及接入方案對未來應(yīng)用所起的作用和意義。

圖6.1 寬帶衛(wèi)星VSAT網(wǎng)絡(luò)示意圖

圖6.2 結(jié)合寬帶VSAT網(wǎng)的多4G基站接入方案

圖6.3 多衛(wèi)星4G接入加速方案