|
15 年前，連接互聯網最常見的方式是通過模擬調制解調器 (我們常說的貓)經標準電話語音通道發送數據。這種技術采用已經部署的現有標準雙絞電話線，無需對“最后一英里”技術做任何更改，因此對用戶來說這種方式非常廉價，并迅速主導了整個通信市場。不用挖路鋪線,不用改變中心局 (CO),這種方式極具吸引力。 “貓”的峰值速度為 56Kbps。為什么是 56Kbps？為什么不再高點？簡單地說：這在“理論上”是不可能的。這種理論局限為 ADSL 技術的發展提供了空間。 模擬調制解調器使用經 ITU-T 委員會嚴格標準化的已有語音通道。該通道具有限定帶寬（4kHz，包含防護頻帶），進入 Muldex (多路復用器/解復用器) 之前在 CO（中心局）進行硬件濾波。Muldex 是 CO 中與電話連接的設備。 可通過 4kHz 模擬通道傳輸的最大數據速率是多少？這個問題的答案是了解 ADSL 的關鍵。 正確的答案是：“取決于通道的噪聲級。”只要噪聲級足夠低，就能以任意比特率進行傳輸。實際上，Claude E Shannon更精確地將最大比特率以定量方式與給定通道帶寬和噪聲級進行關聯。可以使用 Shannon 的著名公式： 其中： C ：最大比特率，單位：比特/秒(“容量”)； B ：帶寬，單位：Hz； S/N：通道的信噪比。 ITU-T 規定了語音通道的帶寬和噪聲級，限定了雙絞電話線的事實最大比特率——56Kbps 非常接近通道容量。 ADSL 沒有使用標準語音通道，而是使用另一種通道，打破了語音通道的 Shannon (香農)限制。 在電話系統中，每個用戶都通過雙絞線連接中心局，雙絞線的使用時間很短，只在打電話時才會用到，而且僅占用低于 4kHz 的通道帶寬,高于 4kHz 的帶寬顯然未被使用。ADSL 使用未被利用的帶寬，并將低于 4kHz 的通道帶寬預留用作標準語音通道。用戶可以在進行電話語音通話的同時交換數據。 ADSL 通道有多寬，噪聲有多大？這方面并未標準化，這也就是為什么每個 ADSL 調制解調器都會在啟動時測量線路噪聲，然后根據用戶通道情況建立最佳比特率。 每個用戶連接中心局的速度取決于通道本身。用戶可以在家用 ADSL 調制解調器的控制面板上讀出線路速率。 ADSL 的確是個非常好的主意。 它能更好地利用已經埋在地下的線路，無需對最后一英里做任何修改，而原來的電話還能與新技術兼容。用戶只需在家里接一個濾波器(即“分離器”)，用以將電話語音帶寬與 ADSL 帶寬分離。總之，這種方式簡單且便宜。 中心局中每條線路也配有類似的濾波器。該濾波器將語音通道連接到 Muldex，并將線路的高帶寬部分連接到只處理數據的名為 DSLAM（數字用戶線接入多路復用器）的新設備上。電信運營商只需要在每個中心局中靠近每個 Muldex 的位置建立一個 DSLAM，就可向客戶提供 ADSL 服務。 DSLAM 是具有模擬前端的純數據通信設備。它收集來自廣大用戶集的所有 ADSL 數據。所有數據通常會被送到 FPGA，在這里進行處理并匯集到以太網鏈路。 高速以太網鏈路通常連接到互聯網或者經 SDH 或 OTN 傳輸。ADSL 標準一直不斷演變，而用于連接互聯網的 DSLAM 的后側連接根據網絡配置不同可以有多種選擇：以太網、XAUI、SDH 和 OTN 等。 這些是使用 FPGA 的理想條件，因為可建立完全可編程的后側連接，并可利用可編程器件達到不斷發展演變的 ADSL 標準要求。ADSL 架構看起來如此出色，尤其是可以自然地升級電話網絡，很難想象人們還想要什么......但是，ADSL 有局限性。這就是為什么市場會朝著 PON（無源光網絡）技術發展。 ADSL 的局限性依然由香農 (Shannon) 定理決定。使用雙絞線難以使 ADSL 超過 15Mbps。這并非 ADSL 技術本身的限制，而是從用戶到中心局之間平均距離產生的限制。如果想要更快，我們就必須改變“最后一英里”，同時還要最大程度減少改變最后一英里所需的成本。當然，我們可以向每位客戶提供 SDH (傳輸以太網方式)以滿足這些需求，但這種方式太貴了。PON 是解決這個問題的最佳答案，因為該技術能夠在升級成本、性能以及最后一英里最少返工成本之間實現最佳平衡。 我們來看看 PON 的工作原理。 服務提供商將一條光纖通到距離客戶半徑幾百米的“路邊”。并非為每個用戶都提供一條光纖,而是使用一條光纖替代數十條雙絞線。通過無源光纖分配器為每個用戶提供入戶光纖，用戶只能訪問自己的那部分來自中心局的多播數據，并受加密算法限制。 在上行方向(圖1所示)，從每個用戶出來的入戶光纖連接到無源分配器，并被多路復用到連接中心局的單條光纖。中心局內負責從光纖接收數據的設備稱為 OLT（光線路終端）。這種架構與 ADSL 完全不同。PON 的優勢在于街道上的接線盒子是光學原理并且仍然是無源的。盒子中不含有源組件。這是 PON 技術的關鍵優勢：能幫助提供商將維護成本降至最低。 圖 1：PON 上行方向 這種方法的劣勢在于服務提供商必須將原有的雙絞線換成有限數量的光纖。為降低移植成本，不得不以降低性能為代價，在很多國家 PON 都以混合技術的形式搭建。用戶通過 ADSL 連接到街邊的接線盒，但從街邊到 OLT 則通過光學連接。 采用這種混合方案后 ADSL 的速度變快了很多，原因是 DSLAM 距離用戶只有幾百米遠，而不是在中心局內。劣勢在于街邊的混合接線盒現在變成有源的，因為它需要裝載小型 DSLAM。 PON 體現了成本與性能之間的平衡。這并非像老式 56Kbps 調制解調器那樣是技術上的最佳解決方案，但可面向未來擴展。 OLT 還有另一個關鍵技術部件：前端。在上行方向，所有用戶都通過無源光纖分配器連接到同一接收器。因此，用戶必須進行突發傳輸，一次傳輸一批，因為用戶共享一條通向 OLT 的光纖。所有突發傳輸以相同頻率操作，但是采用用戶獨立相位。OLT 接收器在每次突發傳輸開始會重新同步其采樣相位，以正確接收數據。 每次突發在開端前導碼位置有一個特定模式，它能幫助 OLT 鎖定每次突發傳輸。OLT 的前端接收器稱為“BCDR”（突發模式時鐘和數據恢復）單元。 增加前導碼時間可以更容易地設計 BCDR，但較長的前導碼顯然會降低上行帶寬的效率。BCDR 是關鍵的 OLT 組件。它的效率直接影響 PON 線路的上行效率，進而影響 PON 運營商的每比特收入。 對于集成商來說，首要問題是選擇產品。BCDR 只能在 PON 環境中測試，也就是集成商的產品。不可能先開發產品，然后驗證 BCDR。如果在開發周期結束時我們發現 BCDR 沒有達到預期會出現什么情況？ 這就是為什么賽靈思推出以 BCDR 為基礎的框架。連同 BCDR，你可獲得一個具有數據包生成器和數據包校驗器的完整仿真測試平臺，用于證明 BCDR 的正確運行。 除此之外：該開發環境不僅能測試 BCDR；還能給它施壓；發掘其終極性能。以下是一些實例： ● 生成多個 ONU。 ● 可強制讓 ONU 運行在“錘子”模式，即數據包至數據包相位越變始終是 UI 的 0.5%。我們想確保 BCDR 完全不受這種波動的影響。 ● 每次多幀數據包重啟時，錘子模式下生成的所有數據包移動 1 微微秒，以確保 BCDR 的相位檢測器沒有“死”區。鎖定時間必須始終為 32 位——短而且確定。 ● 還可以在 0-8000+ 之間改變數據包前導碼長度，這樣能同時滿足最嚴格的 ITU.T PON 要求和比較寬松的 IEEE PON 要求。 圖2描繪了XAPP1277中與 BCDR 配套提供的仿真環境架構。該仿真環境通過腳本運行，無需編寫代碼便可在數分鐘后看到波形。 圖2：BCDR 配套提供的仿真環境 對于硬件廠商，軟件壓力測試框架是一個非常好的起點。然而，你可能需要看到硬件工作，而這正是第二個 BCDR 框架的工作；該框架使用針對 Kintex UltraScale FPGA 的KCU1250 特性描述套件。該框架在硬件中不斷生成并檢查數據包，以免看到單個比特錯誤或丟失單個數據包。 如何使用演示卡模擬 PON 環境？如何用 1 對 BCDR 進行錘子模式測試？ 上行數據總是以雙倍速率綜合，而且 TX 串行器總是每個上行比特位生成兩個同樣的比特位。這樣，在架構層面，硬件框架可以模擬任意兩個連續數據包之間 0.5UI 的跳變——可在 PON 環境中發生的最差情況。硬件框架通過插入任意兩個數據包之間最差相位階躍，對 BCDR 施壓。 該框架中的負載是被截短的 PRBS，在每個數據包的定界符之后重新開始。如果 BCDR 跳過數據包，你會看到一個負載錯誤；還可在運行中改變前導碼長度。整個硬件測試臺支持腳本編寫，而且集成有 Vivado 硬件分析器，具備一套控制功能。 除了錘子模式測試、錯誤插入和累積以外，還可在運行中更改很多 SerDes 特性和 BCDR 本身的很多特性，例如數字帶寬。對于不熟悉 FPGA 技術的用戶來說，SerDes 配置則是另一個會使他們感到困惑的方面，因此 BCDR 框架提供了使用說明，分步介紹如何配置 SerDes，以幫助用戶設置 PON OLT 界面。圖3顯示了“ GT（千兆位收發器）向導 GUI”示意圖，展示框架如何指導配置，以及如何避免硬件復雜性。 圖3：用于設置多速率 OLT 界面的 SerDes 配置。 這些技術使用戶只需通過 GUI 就能選擇好 BCDR 這樣的復雜產品。原則上，你即使不了解基礎技術細節也能做這些工作。一旦對 BCDR 完成評估，硬件測試臺就會成為啟動真實項目的最佳起點，只需刪除演示數據包生成器/檢查器并用真實的 PON MAC 替代這些模塊，即可嵌入 BCDR。 |
