測試鏈路自適應策略的IP分析技術(shù)

鏈路自適應（也稱(chēng)為調度），首先是作為3GPP協(xié)議下HSDPA技術(shù)的一個(gè)特點(diǎn)推出的，它是手機無(wú)線(xiàn)網(wǎng)絡(luò )分配射頻資源的一種方法。采用這樣方法，基站采用的射頻協(xié)議在每個(gè)傳輸時(shí)間間隔（TTI）為下行鏈路傳輸提供數據及為上行鏈路傳輸分配資源（見(jiàn)圖1）。

　　圖1：每個(gè)TTI必須執行的處理功能。

　　由于TTI可短至1ms， 該調度技術(shù)提供了極大靈活性，以將流量路由和吞吐率與可用資源匹配起來(lái)。它是高通量、穩定和有效利用帶寬的關(guān)鍵。然而，鏈路自適應實(shí)施中的一個(gè)根本問(wèn)題一直困擾著(zhù)手機設備的發(fā)展：常規的測試設置無(wú)法充分查明并定位鏈路自適應方法在工作中出現的錯誤和失敗。本文提出了一種測試設置，它能以精準到具體TTI的水平檢測并定位調度錯誤。

　　測試鏈路自適應的常規策略

　　傳統上，功能和性能測試是協(xié)議和系統驗證過(guò)程中兩個(gè)截然不同的部分。調度通常包括在功能測試部分，而該功能同時(shí)也對性能（數據吞吐量）有根本性的影響。

　　傳統的功能測試方法產(chǎn)生巨量的日志記錄（log），因為每個(gè)TTI（也即每1ms）調度軟件都接收輸入并做出決策。這意味著(zhù)，日志分析既繁瑣又耗時(shí)，因此并不進(jìn)行該工作。相反，鏈路自適應通常是采用簡(jiǎn)單但有限配置（與滿(mǎn)足覆蓋現實(shí)使用各可能情況的要求有相當差距）實(shí)施的功能測試。

　　鏈路自適應的性能測試是通過(guò)測量數據吞吐量實(shí)現的。因鏈路自適應功能測試的范圍有限，所以必須等到性能測試開(kāi)始，才可進(jìn)行完整的功能驗證。顯而易見(jiàn)，這通常處在項目開(kāi)發(fā)的后期。在很多時(shí)候，鏈路自適應存在的性能問(wèn)題，與功能上的錯誤息息相關(guān)。如果這些功能問(wèn)題是在性能測試過(guò)程中發(fā)現的，則必須對這些問(wèn)題予以糾錯，這可能意味著(zhù)必須對設備的某些部分進(jìn)行重新設計并重新進(jìn)行部分驗證。因此，精準的性能測試數據就成為一種寶貴資源，它使開(kāi)發(fā)工程師能集中精力在確實(shí)較勁的地方調試差錯并反復驗證。

　　不幸的是，今天的常規性能測試設置提供的輸出非常不精確。它們包括運行于PC或UNIX工作站上的服務(wù)器應用和撥號PC上運行的客戶(hù)端應用。服務(wù)器和客戶(hù)端應用實(shí)現數據通信協(xié)議（如FTP傳輸）、進(jìn)行測量并提供結果。

　　問(wèn)題是，Windows或Unix操作系統（OS）一般提供的計時(shí)精度約為500ms。真實(shí)情況是，Windows應用中數據包的實(shí)際傳輸通常使用NDIS技術(shù)，它具有優(yōu)于Windows本身的計時(shí)精度，但對這些傳輸的測量受操作系統的影響。

　　更糟的是，即使這種數百毫秒水平粗放的計時(shí)精度，操作系統或計算機制造商也不能保證。因為L(cháng)TE（以及HSPA和HSPA+的一些配置）的TTI為1ms，顯然，基于Windows的應用可能提供的數據流通量不會(huì )超過(guò)OSI堆棧應用層面的總吞吐量水平。所以，精準到具體TTI的功能問(wèn)題的詳細定位信息就不可能提供。為找出有助于調試吞吐量問(wèn)題的這類(lèi)信息，研究一個(gè)簡(jiǎn)化的例子就很有幫助（見(jiàn)圖2）。

　　圖2：包重傳造成的后果是降低了數據吞吐率。

　　例如通過(guò)基站傳輸的一個(gè)IP數據流。采用鏈路自適應，調度器采用最大和最小的可用塊大??；每一塊大小都傳輸相同的塊數。如果我們分別采用256bit和7，480bit作為最小和最大傳輸塊（TBS），這就將實(shí)現約1，948，000bps（也即約2Mbps）的總數據吞吐量。（為簡(jiǎn)單起見(jiàn)，計算中，這個(gè)例子沒(méi)包括協(xié)議報頭；并且選定的IP報頭和數據大小都假定為128bit。）

　　想象一下，下一次實(shí)施相同測量的情況，射頻協(xié)議的性能已經(jīng)惡化（可能是由于協(xié)議軟件性能的下降），導致每個(gè)第三大的數據包都傳丟了。射頻協(xié)議棧必須重發(fā)丟失的數據包，這將使數據吞吐量降低至約1，504，000bps（約1.5Mbps）。這就比第一次測量降低了25％。

　　使用常規性能測試設置，工程師不會(huì )了解吞吐量降低的原因或故障所在，他們看到的只是吞吐率。但若測量系統能提供精準計時(shí)，則只需測量數據包延遲便很容易找出問(wèn)題。