- 相關推薦
高速 IP 網絡的輕負荷和快速仿真(一)
高速 IP 網絡的輕負荷和快速仿真
摘要：
網絡路由實現模擬有兩個重要的因素，大小不一的文件和傳輸控制協議，他們分布于會話層。整合兩者的源操作面臨著兩個主要的可測量性問題，其中每個來源所必需的計算資源限制了可被模擬來源的數量，以大容量網絡為內容的離散事件數量導致了過長的模擬時間。我們介紹一種輕巧的路由來源。從統計上來看，它產生的路由類似實際來源產生的路由。與實際來源相類似，它產生很多分布在會話層的文件。然而，它的傳送操作建立于近似傳輸控制協議的假的傳輸控制協議上。P-TCP的稀疏編碼使LWTS相對于現實的路由來源少了50倍。為了解決第二個可量測性問題,我們在傳輸層介紹新奇的抽象化技術: 我們把小包送給一整窗戶傳輸控制協議包的當做一大包。這抽象化造成不連續事件的減少可達到28倍的更快速的模擬。
關鍵詞語：輕負荷業務源，可測量仿真方法論，大范圍可靠性
1介紹
計算機模擬的目標是盡可能的模仿現實。然而，很重要的是為了研究一些特定的系統特點，并且不僅要仔細考慮現實細節，還要用現有的計算資源，在合理的時間內完成模擬。在大多數情況下，兩個目標在相反的兩端。仿真模擬需要特殊的、昂貴的硬件，要求長時間提供穩定的結果。另一方面，任何解決實際限制的承諾一般都要考慮犧牲一些模型的實際細節。
互聯網路由是大范圍的，這是由它自身性質決定的。LRD在路由工程和網絡計算的問題上有很深的影響，從數學的角度看，它意味著路由表明大范圍時間內的相關性，除此之外，特定協議機制和壅塞控制機制提高了在小范圍時間表內復雜結構道具的性能，這是不同于大時間縮放的行為，從觀察的表現要點來看，這些相關結構的最大反映是排隊行為，這巨大的不同于產生于Poisson貨物記憶處理的古典行為結果。因此，在通信網絡仿真的路由中實現大時間和小時間的相關性是很重要的。
LRD 主要地被歸因于會話特性, 或使用者-行為。每個使用者被模擬為開關源，那開狀態表現使用者的下載活動, 而且關狀態表現它的想-時間。開時間是冗長分布的，是因為冗長的網頁造成的。多個不規則碎片在小的時間刻度的結構主要地被歸因于傳輸控制協議記錄。作者介紹的HTTP-TCP的來源包括這些因素，它包括完全落實傳輸控制協議傳送冗長分布于會話層的文件。
然而以實用的方式模擬低速度網絡是有可能的，在高速網絡模擬方法學面對兩個主要可測量問題。如高速的網絡攜帶大量路由，因此,很多的路由來源必須模擬在這樣一個系統上。每個來源對計算機的資源都要求。因此,有限可得的計算機資源限制能被模擬的來源數量。其次，每個來源在模擬的過程中產生若干的不連續的事件。時間越多，模擬的時間越長。這些是與高速網絡的離散事件模擬學密切相關的兩個重要實際的限制。
可量測性議題對HTTP-TCP來源甚至是更嚴重的，它包括一個客戶–服務器的傳輸控制協議對為傳輸控制協議連接：兩者都占據存儲空間而且產生路由。事件被產生用于從服務器到客戶端的數據流同樣用于相反方向的路由確認．大量的不連續的事件減慢模擬。舉例來說,在一個４ＧＢ隨機存取儲存器和一個 1.5Ｇ赫茲處理器的機器上，一總共1.5 Gbps 的路由需要2 – 3個秒的現實路由。同樣，HTTP-TCP來源占據約２０kBytes的模擬器的內存空間。現在的穩定 Linux 核心能存取將近４ＧＢ的存儲器。1 GBytes的存儲空間被用于核心，組件等。因此，我們在剩余的 3 GBytes 存儲器上能最多模擬 150,000來源。當調諧的模擬一個典型的網路使用者，每個來源生產約12 kbps的路由。然后模擬器的能力不超越路由的1.8 Gbps 的模擬。提供這些實際的限制, 現實的小包級的高速網絡的模擬出現被當做一不可能的任務。因此, 一新類型的路由來源要求不僅產生現實的互聯網路由而且解決那有關的可量測性問題。
我們介紹一個新類型的路由來源，它在統計上來看類似被產生的路由被一真正的HTTP-TCP來源產生。我們叫它輕便路由源。就像HTTP-TCP來源，LWTS 是一個開關源。在會話層，它有和HTTP-TCP來源一樣準確相同的結構。因此，它生產和HTTP-TCP來源是完全相似的 LRD 路由。二個來源之間的不同是二個來源傳送數據的方法。我們為網絡模擬的范圍引進一新的傳送模型。我們叫他假- 傳輸控制協議.(P-傳輸控制協議)。這類似于包括真正的占優勢特性TCP傳輸協議。舉例來說慢啟動行為，壅塞避免，快速重傳送和恢復，和一大約的指數背面行為也提到如 Karn's 的運算法則。它合并機制，估計來回時間 (RTT) 分配，這在路由特性中扮演重要角色。它的稀疏編碼的實現主要成份是兩存儲-當作數據庫使用的地圖。一個數據庫跟蹤包損失，每當他們失去一個它直接地被寫入緩沖。
另一個跟蹤端到端得抱延時。P-TCP閱讀這兩張圖而且因此反應, 也就是,它隨著網絡狀態改變自身狀態，形成彈性路由。我們將會在下面的部分解釋它的完整行為以及和真正的TCP顯著的不同。一些技術已經用來加速模擬，他們被分成三組，計算能力，模擬技術和模擬模型。較快速的處理器產生跟強的計算能力。更好的和改良的模擬運算法則改善模擬速度等，重啟動系統裝置探究罕見事件。第三方式是使用較高的層抽象化, 舉例來說,包序列模擬技術模擬了一群緊密地排列得包作為一單獨的包序列，另一種方法是流暢的模擬方法。一個相等的不連續的包模擬器跟蹤所有路由源和網絡序列在物理層的變化，流暢的模擬器處理一組大塊流動包。網絡路由在連續不斷的流之間是被處理過的，一組平常的差別平衡數字的被解決，獲得依賴時間網絡行為的估計，流模擬器的過頭處理遠低于報水平的模擬器是很自然的，因此直接導致更快的模擬，然而，很明顯可以看到，加速模擬是以犧牲細節標準為代價的。
我們采用一個完全新的抽象化策略。我們在傳輸層作抽象，以便能更早修改將大塊數據當作一整窗包來傳送的P-TCP協議，將一整窗當作一小包降低了負載計劃引擎的負載，加速了模擬。這種在窗口水平的抽象世介于包水平和流水平之間的，它不僅合并了會話層的冗長分布文件特性，也保持了TCP協議的關鍵功能。不能推測在建立隊伍后跟著發生包丟失或延時。這種抽象的代價是我們要放棄包水平的細節，在窗水平上模擬，我們相信我們的抽象測率在保證模擬仿真的同時也想留模擬一樣取得了明顯增速。我們將在模擬的幫助下論證這種技術的效用。
我們做了兩項研究。在第一項研究中，我們比較LWTS的離散包版本來源和HTTP-TCP來源。我們將測量和顯示關鍵路由統計的好的匹配，如吞吐量，變化系數，獨立協方差，赫斯特參數。在第二項研究中，我們比較來源的抽象版本和現實來源的產生的路由，我們表示那主要部份路由特性和離散包水平路由的吞吐量，赫斯特參數和平均包延時的良好匹配。這種模擬是實際的到目前為止也是更快的，更輕巧的。
以HTTP-TCP路由為來源的用戶行為模式在第二部分和第三部分已經給出，我們揭示了LWTS 的工作方式和如何處理以上提到的可測量性問題。在第四部分，我們討論模擬建立和結果。
2 HTTP-TCP的來源
我們簡要的討論了HTTP-TCP的來源的細節。讓我們描述網頁服務器上連貫的網頁用戶請求到搭建的時間，HTTP協議在會話層取得申請的網頁然后傳送到TCP上。讓 V代表網頁服務器產生的平決文件的大小，讓 Z代表梅耶對象的平均數目。如果 F 表示平均的網頁然后按規定尺寸制作 F= V Z. TCP 傳送網頁從服務器到用戶。平均網頁傳輸以平均的開時間在會話層被完成。網頁下載之后，用戶在下個申請之前，在平均關閉時間內保持不活動，每個網絡用戶循環經歷著開和關的行為。
HTTP-1.1 被考慮在會議層是因為它的流行。他通過持久穩固的連接傳送文件，這意味著一個單一連接用于傳送一個網頁的所有文件。類似連接的做法在這里不再舉例。在傳輸層，TCP首先通過三次握手建立服務器和客戶之間的連接，然后傳送實際數據，從一包開始，TCP保持在一窗中加倍，直到達到它的極限或有包丟失。前者他會轉到CA階段。對于TCP，接連的兩個創之間的時間是rtt。如果沒有包丟失，連接將會開啟最大壅塞窗，然后維持這窗直到整個的文件傳完。如果有損失傳輸控制協議將會轉變到其他的階段。
如果互聯網路由的主要成分主要由弱的tcp傳輸或“老鼠”， 公平的是只有傳輸控制協議的SS 極限狀態足夠搬運網絡路由的大部分。這是HTTP-TCP模型的基礎。這個模型將會更緊密地模擬現實。然而，模擬的結果表明，這種近四實際上不壞，我們發現中的大部分遵循互聯網絡路由中的現有統計資料。
可以推測，適當大小的網絡在極限狀態時有不可避免的包丟失，作者將在下面闡述HTTP-TCP路由得tp.
N 是必需傳送的一個大小為 F 的平均網頁 RTTs 的平均數字。清楚地來源準時到達
3輕負荷路由來源
為了保持LWTS和HTTP-TCP來源的密切性，在會話層我們準確使用用戶行為，兩種來源在傳輸方式上是不一致的。早些時候P-TCP已經介紹了，它的細節將在下面給出。
象早些時候闡述的那樣，每個用戶請求造成tcp傳輸的網頁產生。Tcp是有確認鎖的。新的報文只有在得到確認響應后才發出。每個包引發一個向相反方向的確認包。這是tcp反饋環的一個主要功能。反饋環另一個主要功能是提供rtt的估計。兩功能都取決于網絡條件。
我們減少反饋環的包確認，用兩個基于軟件的反饋環代替補充相同功能，同時，語音多樣性對ASR系統的進展仍然有很大的影響。在以易變為特征的因素中，詞性和口音是最重要的。前者已經被AD模型所包含。然而，還是有相對較少的關于帶口音的語音識別的研究正在進行，尤其是對那些雖有同樣母語，但由于人們方言的不同而發生了區域性口音變化的語音的研究。
我們減少反饋環的包確認，用兩個基于軟件的反饋環代替來補充相同功能，我們用兩個存儲地圖做數據庫，一個跟蹤包丟失，它叫plm，另一個跟蹤e2e包延時，它叫e2e延時地圖。Plm在隊列丟失包時被直接寫入緩沖。E2EDM被客戶寫入接收包。
每個客戶計算E2E延遲并且把它寫入地圖。在接下來的部分我們將指出LWTS和HTTP-TCP來源的不同之處。
3.1 連接打開和結束
TCP經過三次握手完成連接打開階段的兩個方面（1）40個位信號包（2）從客戶到服務器的網頁請求。第一方面差不多包括在模型中。一個40字節的信號包在連接開始時被送出，他的成功投遞被數據庫PLM確認，在完成一個rtt間隔后，如果包丟失，他將會在RTT間隔之后重新發送和重新檢查是否成功投遞。如果包成功投遞，連接將進入ss階段。
第二個方面我們只是從負指數級的網頁傳送間功能性的移到一個隨機關閉的服務器，這關閉時間的分布的平均價值設置以平均思考時間和關閉時間為準。
我們通過設置最后一個數據報的RST位模擬TCP連接關閉階段，通知客戶端數據傳輸的結束。
3.2暫停和三倍-副本
在P-TCP中沒有定時器，這極大的簡化了協議的執行，這些定時器的基本功能使評估重傳延時，或協議推測包丟失以及將會采取的去處這種情況必須步驟所需的時間。對于P-TCP包丟失直接寫入PLM，信息被協議讀出。這也去除了告訴協議包丟失需重傳的三倍副本機制的需求。
3.3 P- TCP階段
P- TCP由SS,CA,FRR和Exp-BO階段，和TCP思想一致。從SS階段開始，在第一個RTT內傳送一獨立數據包，如果沒有損失，協議將在一個RTT內加倍壅塞窗，直到窗達到極限，這就是指數創增長。然后協議將轉向CA階段，在這一階段，CWND將在窗成功發送或丟失后被一部分填充。這是線性增長。這種增長將一直持續直到達到最大壅塞窗，通常是65,535個字節。如果沒有損失，將一直保持知道網頁傳送終止。
如果沒有包損失，失去包的緩沖將把丟失寫入PLM。在協議發送一窗新的信息包之前，他將讀取數據庫的于特定連接相關的損失。他的兩個操作基于這個信息：(1)一定傳送容量=傳送量+包丟失，網頁量將被重新傳送，(2) 決定下一階段。遵循集中出現的可能：如果再SS中由單一的損失，那下一狀態將是SS,這是個近似。實際的TCP，例如，如果丟失檢測TD機制允許FRR，TCP-RENO將可避免激烈的從SS重復開始的測量，因此將進入CA階段
如果在階段有包損失，Wssth 和 CWND將被減少到正在運轉的CWND的一半最小值是二，下一階段CA。這是FRR的近似。
如果在CA階段有多種損失，那下一階段是SS。這是嚴重擁堵的跡象，因此，P-tcp協議將會徹底降低從SS開始的幾率。
如果在SS階段有多種損失，下一階段是Exp-BO。這是幾種壅塞的跡象。
因為它在相關高損失條件下誘導偽自我模擬的重要性所以包括Exp- BO 階段是確定的。真正的傳輸控制協議把一包并在Karn's 的運算法則決定的RTO內等待確認。如果包傳送不成功，RTO將加倍然后再一次傳這包。協議保持加倍的RTO知道她達到64倍的第一個RTO。這又將包傳送丟失造成的偽自我迷你的幾率降低一半的作用。
我們的執行用確定的RTO來近似。在P-tcp的Exp-BO中，以RTO= 5 * RTT 來計算。這是因為當取道平均rtt值的標準背離rtt.做一個簡單的假設rtt是負指數分布，我們將設
3.4 RTT估算
當客戶受到數據包，會用一種簡單的方法計算E2E延遲，即現有系統的時間與數據包被產生的時間差 ，將這個延遲加倍所以可以估計RTT將這個延遲寫入E2EDM。P-TCP將應用相同的 估計函數應用在真實的TCP-IP協議中。P-TCP讀取數據庫中的內容再調整下次發送的滑動窗口。
3.5 數據提取戰略
數據的提取在運輸層完成， 不是發送離散的數據包在每個時間周期，P-TCP將一整個數據包在一個滑動窗口中一起發送。優點是明顯的：提取的數據會被清晰地在日程表上顯示，因為它將給每個數據包間日程表而不是一G包在每個數據周期。
然而我們將指出一個重要的細節：因為在傳輸層傳輸，因為擁塞，數據隊列會遺失整個滑動窗口，但離散的數據包不會！這樣看起來很極端，我們指出數據包的丟失是相關的。 在丟棄結尾數據類型的路由器中，當滑動窗口中以數據包丟失后，剩下的敞口中的數據包也會一起丟失。我們會進一步產生疑問多少個數據包在突發事件中丟失�；诩兝碚摰慕忉尯茈y給出。然而我們將估計與模擬現實的情況截取數據包的數據段在有突發的遺失發生后。例如：只有完全窗口的一部分數據發生遺失將不會在寄存器中找到那部分數據。這種方法比較現實。詳細的情況可以被得到。我們發現后果并不是想象的那末嚴重。因為我們可以用基于少量的數據流失模式來觀察。所以這種估計并不是沒有事實依據的。然而我們指出，TCP所要做得在相關的數據包丟失以后。
基本的當tcp探測到數據丟失以后它有兩種選擇。如果數據包被成功的發送當一是數據包的意外發生以后，協議會收到兩個獲三個一樣的數據包。這就意味著會產生輕微壅塞，這時TCP會選擇FRR，然而如果兩個連續的數據窗口發生遺失協議會選擇SS。這個估計蘊含了TCP協議防壅塞的思想。
判斷數據傳輸的目的是極其重要的，簡單一些說是解決可觀測性事件用一種模擬仿真的方法。我們主張不要重新設定TCP或獲取TCP的整個反饋循環。這用特性決定了用戶行為將其他傳輸特性整合在了一起。
3.6 LWTS 吞吐模式
我們將TCP的基于結構模式定義在基于段模式之中。協議傳輸平均每個W窗口實時的以R速率傳輸。協議停止傳輸在TCP OFF是間段中，MSS極為最大傳輸數據部分。N的公式如下：
為了估計ss段是否能傳輸平均每個網頁。一下是估計公式：
平均窗口長度W平均網頁傳輸量將為
將RTT定義為協議傳輸在下限之和有
LWTS具有開關結構在傳輸層，在一段內應用開關結構在部分層：直觀地來看有
N是平均的RTT值傳輸平均每個網頁時�，F在公式可以寫為
再做一個微調
還有：
3.7預計的提速
在決定提速量時有三個主要因素。
在不提及現實的HTTP與TCP協議時，假設段到達時我們在服務器產生網頁但僅僅將其傳輸到客戶端。HTTP打開或關閉時和TCP既不產生流量,我們也消除了繁瑣的TCP編碼過程而將其在客戶服務器簡單的編碼。每個客戶服務器將其丟失數據簡單編碼在下一個數據窗口返回。因為這種原因我們不能精確的估計加速量。然而這種估計會發生兩道三次。
去除了確認信息量：數據確認信息在數據包的傳輸中產生的流量和數據出書幾乎相等。所以數據的傳輸速率提高也直觀地展現為確認信息的去除
提�。簲祿䝼鬏數奶崴倭颗c窗口壅塞的程度相關�？梢杂靡幌鹿接嬎�
一個典型的用戶行為如圖表1在給出MSS后平均網頁傳輸可提高到大約42數據包
所以，模擬時間加速了四倍在離散數據包傳輸時。在提取窗口級模擬式可望提速大約28倍。
3.8進一步提速
數據提取戰略將有現實的情況發生改變。因為會遇到光傳輸網絡所附加的傳輸限制。模擬系統的提速量將有防壅塞窗口所來主要決定。具體參數將由國家互聯網來決定。數據傳輸速度會提高100倍當數據流有足夠長和網絡傳輸的丟失足夠小。速度提高速度還取決于數據資源的集成度。
4 總體傳輸的描述與仿真設置
或許精確的計算出因特網的隨機流量是不可能的。然而我們可以根據主要的參數做出判斷，來選區四個主要標志數據傳輸特性的標志，為了做到上述，我們應用了數據包內部到達時間過程。
第一個關鍵數據是TP ,TP描述了數據包的平均數據量與數據包的平均內到達時間。第二個關鍵參數為CV是一個隨機的變量，其定義為傳輸速率背離其應有值的程度。CV標志了平均傳輸過程的一些變化。ACV則可用來觀測相關量的變化 。赫氏參數冊為第四個主要參數。為了形象地描述我們用一些突來表示其概念：
4.1仿真設置及對比HTTP-TCP與LWTS的結果
為了進行仿真我們這部分應用了托勒米仿真器來延續網絡。如圖三為了http-tcp傳輸試驗，示范了仿真結構。我們跟隨表一給出的摘要，用這些數值，我們得到了典型的網絡用戶的tp，他的包延時是12kbps。除了傳輸裝置以外，p-tcp和lwts是相同的
我們推測這種連接不會被現有大容量高速網絡下載，因為tcp正遭受由于連接下載所帶來的壅塞坍塌超過了75%。作為一個最嚴重的例子想定核心連接的利用保持在65-70%，利用的邊緣是50%。將被模擬的源數量被三個網絡服務器均分。
圖2給出了設置TP傳出流量的一些細節。寄存器容量設置為550個數據包。數據包的內部到達時間過程在傳輸數列節點R1將被獲得。這將標志著隊列將數據從服務器傳輸到客戶端確認信息從客戶端到服務器將不從這對數據中傳輸。
冗長行分發數據在我們的模擬中是一個縮冪尾型（TPT）將形成參數1。5
TPT分布將需要大量樣本匯聚。例如:為了達到參數最少需要個樣本。我們的方針有足夠能力提供至少個文件。
4.1.1 吞吐量
如圖4 顯示了TP對比LWTS與HTTP-TCP的傳輸流量。TP隨數據的增加成線性增長模式。例如資源數為N時總的TP約為LWTS顯示了優良的匹配隨著線性的增加。
4.1.2變化的有效性
圖5展示了cv和tp的關系，lwts顯示了cv的很好的匹配，它遵循了已論證的http-tcp路由相同的的趨勢。
4.1.3赫氏參數
在圖六赫氏參數也顯示優良的匹配特性（除了288MBPS這個點，我們還沒有很好地解釋。）這也顯示了H值開始下降的到0。65載有2338個資源時開始穩定。在28Mbps時，向前。為了高速傳輸時數據包的內部到達時間有所需的空間，只有這樣才能使傳輸更加順暢。這是一個比較有趣的結論在分析因特網傳輸路徑時。
4.1.4 自動協方差
選擇分析5682個資源的相關性，發現可以產生大約72mbps的傳輸速率，然后測試cv得知。但當Acv=1時 會誤使我們想象為沒有PLD.這是另外一個比較有趣的結果在我們的實驗中。
圖8 顯示了LWTS的相同的72mbps聚集傳輸結構 。除了在開始的一些微小變化 ，這種變化大概歸因于P-TCP。 這種新的資源產生了相同的PLD行為就像HTTP-TCP資源所產生的一樣。他將持續四個指令周期。LWTS產生與LRD極為匹配的行為。
4.1.5普通包延時
在我們所討論的最后部分我們謹簡單的提及一下。我們將PLD既看作一關也或對參數的匹配 ， 例如，在網關大概傳輸速率為72Mbps時，兩個資源節點產生了大概相同的39s的MPD
然而用另外一種描述方法，我們前面已經討論過在測量因特網傳輸路徑時 ，已用我們的模式來加以說明。 我們用以上來解釋這些現象。
4.1.6模擬設置與對比HTTP-TCP LWTS的資源后的結果
為了這個實驗，我們使用了核心連接能力為C’=50mbps的器件。下載連接能力為，這個結果從表3可以看出。所有的數據顯示為優良的匹配。PLD由赫氏參數給出，因為E2E所產生的冗長型網頁所產生的延遲發生在以上兩種情況。
LWTS的主要目的為解決HTTP-TCP資源畢環操作的可測量性。
速度提高的結果如圖4所示。對350秒的HTTP-TCP仿真 大約用了26分鐘。然而用LWTSs仿真用了56秒。這是大概28倍，這種提高在仿真中顯得很為可觀。這種速度的提高是對某個傳輸的瓶頸的設定改變。然而，很顯然得，相同的數據傳輸速率提高 也可以通過減少路由器中等待數據的長度取得。因為在多重的路由器的情況下離散數據包的傳輸速率被固定下來當離散數據包速率在仿真提高時。
這還將有一個重大的改變在LWTS應用內存時。如圖9給出了解決兩資源對內存需要的想法。HTTP-TCP遵循了一種線性曲線大概為當。就像先前所討論的一樣，我們可以用3GBytes的內存來做構架仿真。這樣就可以使最大1500000mbps 資源一起仿真。作為對比，新資源所需要的內存要遠遠的小，例如需要相同數目的資源僅僅需要60MB內存，遠離這些，對1500000HTTP-TCP的方針將不可能進行。但對新資源就變得可行。
5結論
在這篇論文中，我們展示了一種數據傳輸模式，它不僅應用了因特網傳輸速率的高可靠性，也解決了基于TCP的數據傳輸的可測量性。所有數據實測的結果全部基于現實的因特網。所以我們的仿真緊貼現實。為了顯示HTTP-TCP的傳輸特性，我們的數據都由真實的HTTP-TCP資源所測。我們提供了可代替現有HTTP-TCP的新型資源，我們有理由相信P-TCP從TCP攫取了精髓，可實現網絡輕巧，高速傳輸。這種簡潔的思想和容易的執行方法將會使這個領域成為最具研究潛力的方向！
【高速 IP 網絡的輕負荷和快速仿真(一)】相關文章：
運用傳輸矩陣方法實現傳輸線特異媒質的快速和精確仿真03-07
淺談學校校園網絡IP地址的管理及IP、MAC、端口的綁定畢業論文11-17
SoC設計中IP復用和驗證策略03-07
大規模IP網絡中基于SNMP的網絡拓撲發現方法分析11-30
一種基于SIP和移動IP的切換機制的研究03-07
下一代網絡中的PSTN/ISDN仿真系統03-18