 |
善于提問，勤于回答，你也是專家
|
 |
問題已開啟
(普通問題)
請大蝦們，提供一下WCDMA網(wǎng)絡(luò)端到端業(yè)務(wù)性能優(yōu)化的意見,拜托咯....
提問者: 更多
CDMA
CDMA網(wǎng)絡(luò)
端到端
網(wǎng)絡(luò)
優(yōu)化
業(yè)務(wù)
相關(guān)問題
• 現(xiàn)在還有必要學(xué)GSM和CDMA嗎 2020-09-29
• CDMA2000網(wǎng)絡(luò)中如何有效控制用戶的發(fā)射功率實現(xiàn)具體流程 2020-06-20
• CDMA中的2000是什么意思 2020-05-15
• 華為CDMA主控板登錄不了 2019-11-17
• 聯(lián)通wCDMA專項日常優(yōu)化中興中興資料 2019-10-18
• WCDMA導(dǎo)頻功率是什么 2019-08-13
• WCDMA室內(nèi)分布系統(tǒng)拿什么軟件畫圖 2019-06-12
• 有沒有關(guān)于WCDMA所以資料 2019-05-16
• CDMA2000網(wǎng)絡(luò)中如何有效控制用戶的發(fā)射功率實現(xiàn)具體流程 2020-06-20
• CDMA中的2000是什么意思 2020-05-15
• 華為CDMA主控板登錄不了 2019-11-17
• 聯(lián)通wCDMA專項日常優(yōu)化中興中興資料 2019-10-18
• WCDMA導(dǎo)頻功率是什么 2019-08-13
• WCDMA室內(nèi)分布系統(tǒng)拿什么軟件畫圖 2019-06-12
• 有沒有關(guān)于WCDMA所以資料 2019-05-16
問題答案
( 2 )
這是個系統(tǒng)性的概念@@!建議進行分解，然后結(jié)合你關(guān)注的部分進行分析。比如說，分解為無線接入網(wǎng)、交換網(wǎng)、傳輸幾塊。然后可以考慮指標映射，比如說語音質(zhì)量差，可以分解為信源編碼、信道編碼、覆蓋差、干擾、傳輸過程中的編碼轉(zhuǎn)化幾部分，那么和無線接入網(wǎng)相關(guān)的主要是覆蓋和干擾，再有就是信道編碼部分。大體思路就是總分吧，先找到影響的各個因素、然后映射為可量化的指標或者測量，然后針對某項指標進行提升優(yōu)化。
回答者：
li198207
回答時間：2011-08-24 09:28
14
12
1、應(yīng)用層面優(yōu)化策略
1.1壓縮內(nèi)容
應(yīng)用壓縮技術(shù)可以減少數(shù)據(jù)量，特別是通過瓶頸鏈路的數(shù)據(jù)量。壓縮技術(shù)可以從不同的角度進行分類：從壓縮前后信息量的對比來看，可分為有損失的壓縮（如JPEG、MP3或者AMR）和無損失的壓縮（Huffman編碼或者LZ編碼）；從壓縮的對象來看，可分為頭壓縮和內(nèi)容壓縮，內(nèi)容是待傳數(shù)據(jù)的源頭，更應(yīng)該仔細選擇壓縮方式。
壓縮與解壓縮功能的位置也需要慎重考慮，可以將壓縮和解壓縮功能置放于移動設(shè)備和應(yīng)用服務(wù)器中，也可以將壓縮功能從應(yīng)用服務(wù)器移動到無線接口前的獨立立柜中。后一種方案將給運營商具備較大的靈活性，但此時的可升級性較差。
1.2改進協(xié)議
目前，HTTP協(xié)議是因特網(wǎng)應(yīng)用層所使用的主要協(xié)議之一。其版本對Web頁面訪問速度有一定影響。通常，網(wǎng)站頁面包含多個對象，對HTTP1.0來說，每一個對象都必須用新的TCP連接來打開，由于每個TCP連接至少需要幾秒鐘，并且要經(jīng)過慢啟動后才能達到較高的速度，因而降低了實際傳輸速率。HTTP1.1則允許使用TCP打開多個對象，提高效率。
還可以使用性能增強代理（PEP，PerformanceEnhancingProxies）來改進協(xié)議。PEP是一個新的網(wǎng)絡(luò)實體，旨在通過調(diào)整終端與承載之間協(xié)議或信息提高終端用戶的應(yīng)用性能。通常位于應(yīng)用層或傳輸層：應(yīng)用層PEP功能是緩存、信息壓縮及應(yīng)用層的優(yōu)化，在帶寬較窄和時延較長時效果較好；傳輸層PEP則主要是為了克服TCP自身一些問題。
PEP可以位于網(wǎng)絡(luò)中的不同位置。作為獨立網(wǎng)元時，移動網(wǎng)絡(luò)運營商通常會將它們放置在網(wǎng)關(guān)之后。另外，PEP功能也可以融入現(xiàn)有網(wǎng)元中（如SGSN、BSC），這有助于在網(wǎng)關(guān)、路由器或者無線接入網(wǎng)絡(luò)元素中實現(xiàn)緩沖區(qū)擁塞管理等優(yōu)化方法。同時安全因素也會影響到PEP的位置選擇。因為IPSec的使用是通過在端到端對TCP頭和應(yīng)用數(shù)據(jù)進行封裝來實現(xiàn)的，PEP無法理解封裝之后的數(shù)據(jù)。
2、傳輸層面優(yōu)化策略
TCP是因特網(wǎng)上的主要傳輸協(xié)議，有線網(wǎng)絡(luò)的數(shù)據(jù)包丟失主要是由擁塞引起的，但在無線網(wǎng)絡(luò)中，傳統(tǒng)TCP會將無線信道比特差錯和切換引起的數(shù)據(jù)包丟失誤也歸于擁塞而采取擁塞控制措施，因而無謂降低了端到端吞吐量。本節(jié)主要介紹TCP針對無線環(huán)境的一些改進建議。
2.1IETF對于無線環(huán)境下標準TCP協(xié)議的優(yōu)化建議
IETF提出了一些針對無線環(huán)境的TCP優(yōu)化建議，主要體現(xiàn)在以下6個方面。
2.1.1合適的窗口大小
無線鏈路上的TCP應(yīng)當基于系統(tǒng)可用帶寬時延積（BDP，BandwidthDelayProduct）設(shè)定合適的接收方窗口大小。接收方通知窗口應(yīng)當至少同BDP一樣大，否則接收方的TCP層將對最大可用帶寬造成限制。
通知窗口應(yīng)當盡可能地設(shè)大一些，使得所有的可用帶寬都有可能使用；但如果通知窗口比BDP大太多，也可能因為緩存溢出和隨后的TCP重傳導(dǎo)致性能惡化。因而，通知窗口應(yīng)當比BDP稍大，一方面充分使用容量，另一方面也不會損害到網(wǎng)絡(luò)處理擁塞和丟報恢復(fù)的能力。
2.1.2加大初始窗口
無線鏈路的高時延加大了慢啟動階段持續(xù)時間，主要體現(xiàn)在TCP連接建立時、發(fā)生重傳超時（RTO，RetransmissionTimeout）之后或較長空閑期后重新啟動連接時。借助于大的初始窗口，慢啟動將能更快地將吞吐量抬升至穩(wěn)定狀態(tài)。
2.1.3受限制的傳輸
旨在擁塞窗口較小時改善快速重傳和快速恢復(fù)的性能。如一旦發(fā)送方在等待重傳時尚有未發(fā)送數(shù)據(jù)，那么在收到2個重復(fù)性ACK后就立即發(fā)送新的報文。這樣以來，接收方可以產(chǎn)生第3個（激活快速重傳/快速恢復(fù)所必須的重復(fù)性ACK個數(shù)）重復(fù)性確認來觸發(fā)發(fā)送方的快速重傳或快速恢復(fù)，這就避免了RTO及其后的慢啟動階段。但該選項依賴于軟件實施情況。
2.1.4TCP報文大小
通常，重復(fù)一定次數(shù)的慢啟動過程之后才能達到充分發(fā)揮帶寬資源；無線鏈路的高延遲使得最初幾輪調(diào)整對終端用戶的吞吐量至關(guān)重要。慢啟動階段，發(fā)送方字節(jié)數(shù)的增加是以報文大小為單位的，因而，如果增大最大報文段尺寸（MSS，MaximumSegmentSize），慢啟動階段就可以更快地將吞吐量抬高到充滿帶寬，還能夠提高各層所添加協(xié)議頭的效率、降低往返傳輸?shù)?span lang="EN-US">ACK數(shù)目。但某些時延要求高、又需要快速糾錯的業(yè)務(wù)則適合使用較小的TCP報文段。
2.1.5選擇性確認
TCP連接期間，接收方將最后一個成功接收報文段的序號包含進ACK中，此即累積性確認。一般而言，選擇性ACK（SACK，SelectiveAcknowledgement）則是可選項，它允許接收方向發(fā)送方通知所有數(shù)據(jù)段的傳輸狀態(tài)。這樣，發(fā)送方就可以有選擇地重傳，而不是僅僅重傳第一個丟失分組并等待下一個ACK（一個RTT）來接收新的丟失信息。
在具有較大BDP通道時，SACK更能發(fā)揮作用，有研究結(jié)果表明它適合于具有中等丟失率（低于窗口大小的50%）的長延遲網(wǎng)絡(luò)環(huán)境。這使得SACK比較適合于無線鏈路。但其不足在于它會稍微加大報頭的尺寸（最多增添8byte），且其使用需要客戶機、服務(wù)器兩端的支持。
2.1.6TCP時間戳選項
標準TCP是每個擁塞窗口才測量一次RTT，這可能給RTT的估計帶來偏差，當擁塞窗口增長時尤其如此。無線鏈路特征則要求更準確地估計RTT以便盡可能地減少那些偽超時重傳（spuriousRTO）。
使用時間戳選項時，發(fā)送端可以每發(fā)一個報文段就計算一次RTT，即使是在發(fā)那些重傳的。這一改進使得TCPRTO能夠更快地應(yīng)對時延變化，降低偽超時重傳個數(shù)。然而，使用該選項時需要在TCP報頭添加12byte，同樣要求兩端的支持。
2.2緩存擁塞管理策略
2.2.1隨機早期監(jiān)測
隨機早期檢測（RED，RandomEarlyDetection）是目前研究得最多的主動隊列管理技術(shù)，它采用概率判定機制有選擇地主動丟棄某些分組，利用TCP對發(fā)送速率的自適應(yīng)調(diào)節(jié)能力，讓某些源端降低發(fā)送速率，及時阻止擁塞的惡化，并將平均排隊時延控制在一定范圍內(nèi)。但RED也存在一些缺陷：性能對網(wǎng)絡(luò)狀況和參數(shù)敏感，很難給出優(yōu)化的參數(shù)配置；穩(wěn)定性和公平性也存在一些問題。
2.2.2快速TCP
快速TCP算法是當下行緩存超出一定門限（接近擁塞）時試圖降低下行分組量。通常，上下行業(yè)務(wù)量的不對稱導(dǎo)致下行緩存要比上行緩存先可能擁塞。
一旦上行ACK延遲發(fā)送，TCP發(fā)送方就將等待更長的時間才滑動其傳輸窗口。該機制為下行緩存脫離擁塞機制贏得了時間。同時，由于ACK的延遲，擁塞窗口的增長速度也將降低。
2.2.3窗口調(diào)整
基本思路同快速TCP類似，與延遲ACK不同的是，該方法將降低通知窗口大小，這同樣可以降低傳輸速率。窗口調(diào)整不會像RED那樣有丟包發(fā)生，因而便不存在無意識導(dǎo)致RTO（如同在快速TCP里發(fā)生的那樣）發(fā)生的風(fēng)險。然而，此機制導(dǎo)致處理負擔過重，因為此時TCP報頭應(yīng)當由產(chǎn)生它的網(wǎng)元進行修改。此外，使用IPSec協(xié)議時TCP報頭被保護，也不適用。
2.3數(shù)據(jù)擁塞控制協(xié)議（DCCP）
TCP改進算法很難處理大幅增加的UDP業(yè)務(wù)，這些業(yè)務(wù)產(chǎn)生的數(shù)據(jù)流同樣需要擁塞控制。而互聯(lián)網(wǎng)電話、視頻流和在線游戲等產(chǎn)生的長時間的UDP數(shù)據(jù)量在穩(wěn)定增長。于是，IETF公布了一個新的傳輸層協(xié)議草案——數(shù)據(jù)報擁塞控制協(xié)議（DCCP），它在UDP的基礎(chǔ)上增加了流控和擁塞控制機制，使數(shù)據(jù)報協(xié)議能夠更好地用于流媒體業(yè)務(wù)的傳輸。
2.4頭壓縮技術(shù)
業(yè)務(wù)從傳輸層、IP層、到鏈路層及物理層，每層都會帶來額外的協(xié)議開銷。如典型的TCP協(xié)議頭長20byte，IP協(xié)議頭長20byte，UDP協(xié)議頭長8byte。IP包長480byte。因此，對于TCP/IP協(xié)議開銷引起的效率降低為8.3%，UDP/IP協(xié)議開銷引起的效率降低為5.8%，可見報頭引起的開銷并不很小。
為提高傳輸效率，IETF制定了若干頭壓縮機制，第一個用于低速系列TCP/IP頭壓縮的IETF建議是由Jacobson開發(fā)的。隨后，Degermark給出了IP頭壓縮算法（IPHC，包括UDP/IP以及TCP/IP），被3GPP標準化后用于WCDMA系統(tǒng)中的PDCP層。較先進的頭壓縮技術(shù)還有可靠頭壓縮（ROHC，RobustHeaderCompression）算法。
3、數(shù)據(jù)鏈路層面優(yōu)化策略
RLC層是數(shù)據(jù)鏈路層的重要功能，旨在為用戶和控制數(shù)據(jù)提供分段和重傳業(yè)務(wù)，其設(shè)置對網(wǎng)絡(luò)整體性能（尤其是時延和吞吐量）影響較大。RLC實體共有3種操作模式：確認模式（AM）、非確認模式（UM）和透明模式（TM）。確認模式使用選擇重發(fā)ARQ來保證數(shù)據(jù)傳輸?shù)恼_性，該機制借助于兩個手段，即探詢（Poll）和狀態(tài)報告（Statusreport）。發(fā)送端在協(xié)議數(shù)據(jù)單元（PDU）中有一個探詢比特用于探詢鏈路狀態(tài)，接收端根據(jù)接收情況來設(shè)置探詢比特。若接收端探測到丟失的PDU，就會使用狀態(tài)報告向發(fā)送端報告哪些幀丟失、哪些幀正常。
應(yīng)當精心設(shè)計探詢和狀態(tài)報告的頻率，以實現(xiàn)快速重傳和開銷最小化�？梢酝ㄟ^調(diào)整一些定時器的大小來優(yōu)化狀態(tài)匯報的頻率，一般認為：用于ACK的狀態(tài)匯報消息所占用帶寬不應(yīng)超出可用帶寬的2%。
此外，RLC層支持順序和無序傳遞。在很多情況下，高層協(xié)議能重組PDU的順序。只要知道并可控低層的無序特性，允許使用無序傳遞能節(jié)省接收端RLC的存貯空間。對于有些應(yīng)用，尤其是實時性業(yè)務(wù)，如果亂序問題解決不好，過多的亂序報文會導(dǎo)致很多問題。因此3GPP協(xié)議（23.107）規(guī)定，如PDP類型為IPv4或IPv6，RAB/RBQoS的傳輸順序?qū)傩詰?yīng)當設(shè)置為“否”。
4、端優(yōu)化策略
移 動設(shè)備通常受限于屏幕尺寸、解析度以及色澤深度，并且往往是在嘈雜的環(huán)境中進行操作。這些因素增大了終端用戶感知壓縮過程中信息丟失的可能性。此外，移動 網(wǎng)絡(luò)并不總是清楚信息是傳遞給移動設(shè)備還是諸如連接到移動設(shè)備的筆記本電腦。因此，有必要使用一些先進技術(shù)（如接收分集等）提升終端性能以使用更豐富的數(shù) 據(jù)業(yè)務(wù)。
1.1壓縮內(nèi)容
應(yīng)用壓縮技術(shù)可以減少數(shù)據(jù)量，特別是通過瓶頸鏈路的數(shù)據(jù)量。壓縮技術(shù)可以從不同的角度進行分類：從壓縮前后信息量的對比來看，可分為有損失的壓縮（如JPEG、MP3或者AMR）和無損失的壓縮（Huffman編碼或者LZ編碼）；從壓縮的對象來看，可分為頭壓縮和內(nèi)容壓縮，內(nèi)容是待傳數(shù)據(jù)的源頭，更應(yīng)該仔細選擇壓縮方式。
壓縮與解壓縮功能的位置也需要慎重考慮，可以將壓縮和解壓縮功能置放于移動設(shè)備和應(yīng)用服務(wù)器中，也可以將壓縮功能從應(yīng)用服務(wù)器移動到無線接口前的獨立立柜中。后一種方案將給運營商具備較大的靈活性，但此時的可升級性較差。
1.2改進協(xié)議
目前，HTTP協(xié)議是因特網(wǎng)應(yīng)用層所使用的主要協(xié)議之一。其版本對Web頁面訪問速度有一定影響。通常，網(wǎng)站頁面包含多個對象，對HTTP1.0來說，每一個對象都必須用新的TCP連接來打開，由于每個TCP連接至少需要幾秒鐘，并且要經(jīng)過慢啟動后才能達到較高的速度，因而降低了實際傳輸速率。HTTP1.1則允許使用TCP打開多個對象，提高效率。
還可以使用性能增強代理（PEP，PerformanceEnhancingProxies）來改進協(xié)議。PEP是一個新的網(wǎng)絡(luò)實體，旨在通過調(diào)整終端與承載之間協(xié)議或信息提高終端用戶的應(yīng)用性能。通常位于應(yīng)用層或傳輸層：應(yīng)用層PEP功能是緩存、信息壓縮及應(yīng)用層的優(yōu)化，在帶寬較窄和時延較長時效果較好；傳輸層PEP則主要是為了克服TCP自身一些問題。
PEP可以位于網(wǎng)絡(luò)中的不同位置。作為獨立網(wǎng)元時，移動網(wǎng)絡(luò)運營商通常會將它們放置在網(wǎng)關(guān)之后。另外，PEP功能也可以融入現(xiàn)有網(wǎng)元中（如SGSN、BSC），這有助于在網(wǎng)關(guān)、路由器或者無線接入網(wǎng)絡(luò)元素中實現(xiàn)緩沖區(qū)擁塞管理等優(yōu)化方法。同時安全因素也會影響到PEP的位置選擇。因為IPSec的使用是通過在端到端對TCP頭和應(yīng)用數(shù)據(jù)進行封裝來實現(xiàn)的，PEP無法理解封裝之后的數(shù)據(jù)。
2、傳輸層面優(yōu)化策略
TCP是因特網(wǎng)上的主要傳輸協(xié)議，有線網(wǎng)絡(luò)的數(shù)據(jù)包丟失主要是由擁塞引起的，但在無線網(wǎng)絡(luò)中，傳統(tǒng)TCP會將無線信道比特差錯和切換引起的數(shù)據(jù)包丟失誤也歸于擁塞而采取擁塞控制措施，因而無謂降低了端到端吞吐量。本節(jié)主要介紹TCP針對無線環(huán)境的一些改進建議。
2.1IETF對于無線環(huán)境下標準TCP協(xié)議的優(yōu)化建議
IETF提出了一些針對無線環(huán)境的TCP優(yōu)化建議，主要體現(xiàn)在以下6個方面。
2.1.1合適的窗口大小
無線鏈路上的TCP應(yīng)當基于系統(tǒng)可用帶寬時延積（BDP，BandwidthDelayProduct）設(shè)定合適的接收方窗口大小。接收方通知窗口應(yīng)當至少同BDP一樣大，否則接收方的TCP層將對最大可用帶寬造成限制。
通知窗口應(yīng)當盡可能地設(shè)大一些，使得所有的可用帶寬都有可能使用；但如果通知窗口比BDP大太多，也可能因為緩存溢出和隨后的TCP重傳導(dǎo)致性能惡化。因而，通知窗口應(yīng)當比BDP稍大，一方面充分使用容量，另一方面也不會損害到網(wǎng)絡(luò)處理擁塞和丟報恢復(fù)的能力。
2.1.2加大初始窗口
無線鏈路的高時延加大了慢啟動階段持續(xù)時間，主要體現(xiàn)在TCP連接建立時、發(fā)生重傳超時（RTO，RetransmissionTimeout）之后或較長空閑期后重新啟動連接時。借助于大的初始窗口，慢啟動將能更快地將吞吐量抬升至穩(wěn)定狀態(tài)。
2.1.3受限制的傳輸
旨在擁塞窗口較小時改善快速重傳和快速恢復(fù)的性能。如一旦發(fā)送方在等待重傳時尚有未發(fā)送數(shù)據(jù)，那么在收到2個重復(fù)性ACK后就立即發(fā)送新的報文。這樣以來，接收方可以產(chǎn)生第3個（激活快速重傳/快速恢復(fù)所必須的重復(fù)性ACK個數(shù)）重復(fù)性確認來觸發(fā)發(fā)送方的快速重傳或快速恢復(fù)，這就避免了RTO及其后的慢啟動階段。但該選項依賴于軟件實施情況。
2.1.4TCP報文大小
通常，重復(fù)一定次數(shù)的慢啟動過程之后才能達到充分發(fā)揮帶寬資源；無線鏈路的高延遲使得最初幾輪調(diào)整對終端用戶的吞吐量至關(guān)重要。慢啟動階段，發(fā)送方字節(jié)數(shù)的增加是以報文大小為單位的，因而，如果增大最大報文段尺寸（MSS，MaximumSegmentSize），慢啟動階段就可以更快地將吞吐量抬高到充滿帶寬，還能夠提高各層所添加協(xié)議頭的效率、降低往返傳輸?shù)?span lang="EN-US">ACK數(shù)目。但某些時延要求高、又需要快速糾錯的業(yè)務(wù)則適合使用較小的TCP報文段。
2.1.5選擇性確認
TCP連接期間，接收方將最后一個成功接收報文段的序號包含進ACK中，此即累積性確認。一般而言，選擇性ACK（SACK，SelectiveAcknowledgement）則是可選項，它允許接收方向發(fā)送方通知所有數(shù)據(jù)段的傳輸狀態(tài)。這樣，發(fā)送方就可以有選擇地重傳，而不是僅僅重傳第一個丟失分組并等待下一個ACK（一個RTT）來接收新的丟失信息。
在具有較大BDP通道時，SACK更能發(fā)揮作用，有研究結(jié)果表明它適合于具有中等丟失率（低于窗口大小的50%）的長延遲網(wǎng)絡(luò)環(huán)境。這使得SACK比較適合于無線鏈路。但其不足在于它會稍微加大報頭的尺寸（最多增添8byte），且其使用需要客戶機、服務(wù)器兩端的支持。
2.1.6TCP時間戳選項
標準TCP是每個擁塞窗口才測量一次RTT，這可能給RTT的估計帶來偏差，當擁塞窗口增長時尤其如此。無線鏈路特征則要求更準確地估計RTT以便盡可能地減少那些偽超時重傳（spuriousRTO）。
使用時間戳選項時，發(fā)送端可以每發(fā)一個報文段就計算一次RTT，即使是在發(fā)那些重傳的。這一改進使得TCPRTO能夠更快地應(yīng)對時延變化，降低偽超時重傳個數(shù)。然而，使用該選項時需要在TCP報頭添加12byte，同樣要求兩端的支持。
2.2緩存擁塞管理策略
2.2.1隨機早期監(jiān)測
隨機早期檢測（RED，RandomEarlyDetection）是目前研究得最多的主動隊列管理技術(shù)，它采用概率判定機制有選擇地主動丟棄某些分組，利用TCP對發(fā)送速率的自適應(yīng)調(diào)節(jié)能力，讓某些源端降低發(fā)送速率，及時阻止擁塞的惡化，并將平均排隊時延控制在一定范圍內(nèi)。但RED也存在一些缺陷：性能對網(wǎng)絡(luò)狀況和參數(shù)敏感，很難給出優(yōu)化的參數(shù)配置；穩(wěn)定性和公平性也存在一些問題。
2.2.2快速TCP
快速TCP算法是當下行緩存超出一定門限（接近擁塞）時試圖降低下行分組量。通常，上下行業(yè)務(wù)量的不對稱導(dǎo)致下行緩存要比上行緩存先可能擁塞。
一旦上行ACK延遲發(fā)送，TCP發(fā)送方就將等待更長的時間才滑動其傳輸窗口。該機制為下行緩存脫離擁塞機制贏得了時間。同時，由于ACK的延遲，擁塞窗口的增長速度也將降低。
2.2.3窗口調(diào)整
基本思路同快速TCP類似，與延遲ACK不同的是，該方法將降低通知窗口大小，這同樣可以降低傳輸速率。窗口調(diào)整不會像RED那樣有丟包發(fā)生，因而便不存在無意識導(dǎo)致RTO（如同在快速TCP里發(fā)生的那樣）發(fā)生的風(fēng)險。然而，此機制導(dǎo)致處理負擔過重，因為此時TCP報頭應(yīng)當由產(chǎn)生它的網(wǎng)元進行修改。此外，使用IPSec協(xié)議時TCP報頭被保護，也不適用。
2.3數(shù)據(jù)擁塞控制協(xié)議（DCCP）
TCP改進算法很難處理大幅增加的UDP業(yè)務(wù)，這些業(yè)務(wù)產(chǎn)生的數(shù)據(jù)流同樣需要擁塞控制。而互聯(lián)網(wǎng)電話、視頻流和在線游戲等產(chǎn)生的長時間的UDP數(shù)據(jù)量在穩(wěn)定增長。于是，IETF公布了一個新的傳輸層協(xié)議草案——數(shù)據(jù)報擁塞控制協(xié)議（DCCP），它在UDP的基礎(chǔ)上增加了流控和擁塞控制機制，使數(shù)據(jù)報協(xié)議能夠更好地用于流媒體業(yè)務(wù)的傳輸。
2.4頭壓縮技術(shù)
業(yè)務(wù)從傳輸層、IP層、到鏈路層及物理層，每層都會帶來額外的協(xié)議開銷。如典型的TCP協(xié)議頭長20byte，IP協(xié)議頭長20byte，UDP協(xié)議頭長8byte。IP包長480byte。因此，對于TCP/IP協(xié)議開銷引起的效率降低為8.3%，UDP/IP協(xié)議開銷引起的效率降低為5.8%，可見報頭引起的開銷并不很小。
為提高傳輸效率，IETF制定了若干頭壓縮機制，第一個用于低速系列TCP/IP頭壓縮的IETF建議是由Jacobson開發(fā)的。隨后，Degermark給出了IP頭壓縮算法（IPHC，包括UDP/IP以及TCP/IP），被3GPP標準化后用于WCDMA系統(tǒng)中的PDCP層。較先進的頭壓縮技術(shù)還有可靠頭壓縮（ROHC，RobustHeaderCompression）算法。
3、數(shù)據(jù)鏈路層面優(yōu)化策略
RLC層是數(shù)據(jù)鏈路層的重要功能，旨在為用戶和控制數(shù)據(jù)提供分段和重傳業(yè)務(wù)，其設(shè)置對網(wǎng)絡(luò)整體性能（尤其是時延和吞吐量）影響較大。RLC實體共有3種操作模式：確認模式（AM）、非確認模式（UM）和透明模式（TM）。確認模式使用選擇重發(fā)ARQ來保證數(shù)據(jù)傳輸?shù)恼_性，該機制借助于兩個手段，即探詢（Poll）和狀態(tài)報告（Statusreport）。發(fā)送端在協(xié)議數(shù)據(jù)單元（PDU）中有一個探詢比特用于探詢鏈路狀態(tài)，接收端根據(jù)接收情況來設(shè)置探詢比特。若接收端探測到丟失的PDU，就會使用狀態(tài)報告向發(fā)送端報告哪些幀丟失、哪些幀正常。
應(yīng)當精心設(shè)計探詢和狀態(tài)報告的頻率，以實現(xiàn)快速重傳和開銷最小化�？梢酝ㄟ^調(diào)整一些定時器的大小來優(yōu)化狀態(tài)匯報的頻率，一般認為：用于ACK的狀態(tài)匯報消息所占用帶寬不應(yīng)超出可用帶寬的2%。
此外，RLC層支持順序和無序傳遞。在很多情況下，高層協(xié)議能重組PDU的順序。只要知道并可控低層的無序特性，允許使用無序傳遞能節(jié)省接收端RLC的存貯空間。對于有些應(yīng)用，尤其是實時性業(yè)務(wù)，如果亂序問題解決不好，過多的亂序報文會導(dǎo)致很多問題。因此3GPP協(xié)議（23.107）規(guī)定，如PDP類型為IPv4或IPv6，RAB/RBQoS的傳輸順序?qū)傩詰?yīng)當設(shè)置為“否”。
4、端優(yōu)化策略
移 動設(shè)備通常受限于屏幕尺寸、解析度以及色澤深度，并且往往是在嘈雜的環(huán)境中進行操作。這些因素增大了終端用戶感知壓縮過程中信息丟失的可能性。此外，移動 網(wǎng)絡(luò)并不總是清楚信息是傳遞給移動設(shè)備還是諸如連接到移動設(shè)備的筆記本電腦。因此，有必要使用一些先進技術(shù)（如接收分集等）提升終端性能以使用更豐富的數(shù) 據(jù)業(yè)務(wù)。
回答者：
junorym
回答時間：2011-08-24 12:07
15
11
• 南京華蘇科技有限公司
聘：項目經(jīng)理
需求人數(shù)：2 人 地點：河北省
• 華信咨詢設(shè)計研究院有限公司 聘：唐山中級優(yōu)化工程師
需求人數(shù)：10 人 地點：石家莊市,唐山市
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：長期-石家莊-5G華為后臺
需求人數(shù)：3 人 地點：石家莊市
• 嘉環(huán)科技股份有限公司 聘：湖南電信原廠優(yōu)化招聘
需求人數(shù)：10 人 地點：長沙市,永州市,郴州市,衡陽市
• 福建省鴻官通信工程有限公司 聘：湖南電信原廠優(yōu)化高級
需求人數(shù)：2 人 地點：岳陽市,長沙市
• 成都旗訊通信技術(shù)有限公司 聘：招聘督導(dǎo)、傳輸、維護轉(zhuǎn)網(wǎng)優(yōu)中高級
需求人數(shù)：12 人 地點：寧夏,湖南省,甘肅省,廣西省,青海省
• 廣東南方通信建設(shè)有限公司 聘：海南華為精品網(wǎng)項目
需求人數(shù)：10 人 地點：海南省
• 浙江明訊網(wǎng)絡(luò)技術(shù)有限公司 聘：網(wǎng)優(yōu)工程師（湖南）
需求人數(shù)：0 人 地點：長沙市,湘潭市,邵陽市
• 西安長河通訊有限責任公司 聘：網(wǎng)絡(luò)優(yōu)化工程師
需求人數(shù)：4 人 地點：渭南市,商洛市,漢中市,安康市
• 重慶信科通信工程有限公司 聘：江西電信原廠高級后臺
需求人數(shù)：2 人 地點：九江市
需求人數(shù)：2 人 地點：河北省
• 華信咨詢設(shè)計研究院有限公司 聘：唐山中級優(yōu)化工程師
需求人數(shù)：10 人 地點：石家莊市,唐山市
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：長期-石家莊-5G華為后臺
需求人數(shù)：3 人 地點：石家莊市
• 嘉環(huán)科技股份有限公司 聘：湖南電信原廠優(yōu)化招聘
需求人數(shù)：10 人 地點：長沙市,永州市,郴州市,衡陽市
• 福建省鴻官通信工程有限公司 聘：湖南電信原廠優(yōu)化高級
需求人數(shù)：2 人 地點：岳陽市,長沙市
• 成都旗訊通信技術(shù)有限公司 聘：招聘督導(dǎo)、傳輸、維護轉(zhuǎn)網(wǎng)優(yōu)中高級
需求人數(shù)：12 人 地點：寧夏,湖南省,甘肅省,廣西省,青海省
• 廣東南方通信建設(shè)有限公司 聘：海南華為精品網(wǎng)項目
需求人數(shù)：10 人 地點：海南省
• 浙江明訊網(wǎng)絡(luò)技術(shù)有限公司 聘：網(wǎng)優(yōu)工程師（湖南）
需求人數(shù)：0 人 地點：長沙市,湘潭市,邵陽市
• 西安長河通訊有限責任公司 聘：網(wǎng)絡(luò)優(yōu)化工程師
需求人數(shù)：4 人 地點：渭南市,商洛市,漢中市,安康市
• 重慶信科通信工程有限公司 聘：江西電信原廠高級后臺
需求人數(shù)：2 人 地點：九江市
熱點問題
更多精彩
| 聯(lián)系我們 - 問通信專家 | Powered by MSCBSC 移動通信網(wǎng) © 2006 - |