15年前,連接網路最常見的方式是透過類比訊號數據機,經由標準電話語音通道發送資料。由於此技術採用已部署的標準雙絞電話線,且無須在最終端的技術做任何更改,加上價格低廉,因此迅速主導通訊市場。就如同所想像的,無須挖路鋪線或改變電信局,故使此方式更具吸引力!
數據機的最快速度為56Kbps。為何是56Kbps?為何速度無法再更快?簡單來說:這在「理論上」是無法實現的。由於此理論的侷限,為ADSL技術發展提供了更多空間。
類比訊號數據機使用經ITU-T委員會嚴格制訂的標準化現有語音通道。該通道具頻寬限制(4KHz,包含保護頻寬,如圖1),因此在進入Muldex (多工器/解多工器)前,需在電信局進行硬體濾波。而Muldex則是用來連接電信局與電話的設備。
透過4KHz類比頻道傳輸的最大資料速率為何?此問題的答案便是瞭解ADSL的關鍵。
Claude E Shannon於1948年給予正確答案:「取決於通道的雜訊等級」。只要雜訊等級夠低,就能以任意的位元速率進行傳輸。此結果有時會讓我們訝異,然而實際上,Shannon更精確地以量化方式,透過給予最大化的通道頻寬速率與雜訊等級使其進行相連。
ITU-T規範語音通道的頻寬和雜訊等級,並限制雙絞電話線實際的最大位元速率;而56Kbps則相當接近通道容量。
ADSL並未使用標準語音通道,而是透過另一種通道,使其打破語音通道的 Shannon限制。
在電話系統中,每位使用者皆透過雙絞線連接至電信局,而雙絞線的使用時間很短,只在通話時才會用到,並僅佔用低於4KHz的通道頻寬。
而高於4KHz的頻寬顯然未被使用。ADSL使用未被利用的頻寬,並將低於4KHz的通道頻寬留給標準語音通道,讓使用者可在進行電話語音通話的同時交換資料。
ADSL通道有多寬,雜訊有多大?這方面並未標準化,而這也是為什麼每個 ADSL數據機都會在啟動時測量線路雜訊,並根據使用者通道狀況建立最佳位元速率,如圖2所示。
圖2 : 運用4KHz以上的頻寬透過雙絞線傳輸ADSL資料 |
|
每個使用者連接電信局的速度取決於通道本身,而使用者在家可透過ADSL數據機的控制台得知其線路速率。
ADSL是個完美的構想,不僅能善加利用已埋在地下的線路,並在無需對最終端做任何的修改下,使原有的電話還能與新技術相容。使用者僅需在家裡安裝一個濾波器(即「分歧器」),便能將電話語音頻寬與ADSL頻寬分離,而此方式更簡單且便宜。
電信局中的每條線路亦配有類似的濾波器,其可將語音通道連接到Muldex,並將線路的高頻寬部分連接至僅處理資料的新設備上,名為DSLAM(數位用戶線路接取多工器)。電信業者只需在每個接近Muldex位置的電信局中建立一個DSLAM,即可提供ADSL服務。
DSLAM是一台具類比前端的純資料通訊設備,其收集來自廣大使用者的所有ADSL資料,而這些資料通常會被送到FPGA進行處理,並彙整至乙太網路中。
圖3 : ADSL架構可作為以前純語音網路的「升級」版 |
|
高速乙太網路通常連接到網路或經SDH或OTN傳輸。ADSL的標準一直不斷演進,而用於連接網路的DSLAM後端連結則根據不同的網路配置而可有多種選擇,如乙太網路、XAUI、SDH和OTN等。
這些是使用FPGA的理想條件,因其可建立完全可編程設計的後端連接,並利用可編程設計元件,達到不斷演變的ADSL標準。如同賽靈思Vivado設計套件中的IP Catalog進行驗證一樣,僅需點擊按鈕即可在賽靈思FPGA中建立幾乎所有資料的通訊標準。
ADSL架構看起來如此出色,特別是其可以自然地升級電話網絡,但ADSL仍有其侷限性,而人們卻還想有更多的需求,這也是為什麼市場會朝向PON(無源光纖網路)的技術發展。
ADSL的侷限由Shannon理論來決定。若透過雙絞線讓ADSL超過15Mbps是不容易的,這並非為ADSL技術本身的限制,而是從用戶到電信局間的平均距離所產生的限制。若想提升速度,便必須改變最終端,並同時降低改變所需的成本。當然,我們可向每位用戶提供SDH (乙太網路的傳輸方式)以滿足這些需求,但此方式的價格過於昂貴。而PON則是解決此問題的最佳方案,因該技術能在升級成本、效能及最終端往返成本間取得最佳平衡。
以下為PON的詳細工作內容。
電信業者將一條光纖通到距離客戶半徑幾百公尺的「路邊」,且並非提供予每位用戶一條光纖,而是利用一條光纖來代替數十條的雙絞線。透過無源光纖分歧器提供光纖給每位使用家庭,並受加密演算法限制,因此用戶僅能使用來自電信局分配屬於自己的多點傳送資料。
如圖4所示,從每位用戶的家庭光纖連接到無源分歧器,再被連接到電信局的單條光纖上。而電信局內負責從光纖接收資料的設備稱為OLT(光線路終端)。此架構與ADSL截然不同。PON的優勢在於街道上的接線盒是被動式且具光纖功能。PON技術的關鍵優勢是不含主動元件,因此能協助廠商維護成本降至最低。
此方法的缺點在於電信業者必須將原有的雙絞線換成有限數量的光纖。而為了降低更換成本,且不得不降低效能作為代價,因此在許多國家PON多以混合技術的形式搭建。用戶透過ADSL連接到路邊的接線盒,而從路邊到OLT則是透過光學連接。
ADSL可透過採用此混和方案提升速度,原因是DSLAM不在電信局內,而是與用戶僅幾百公尺的距離。唯一的缺點是,在路邊的混和接線盒現在有效是因為安裝小型DSLAM。
PON展現出成本與效能間的平衡,然而這並非像先前56Kbps數據機一般,是技術上的最佳解決方案,但PON在未來將可持續發展。
OLT的前端為其另一個關鍵技術。在上行方向,所有用戶都透過被動式光纖分歧器連接至相同的接收器。由於用戶共用一條通向OLT的光纖,因此必須進行突波,一次傳輸一批。所有突波均在相同頻率下倚賴用戶之階段進行操作。OLT接收器在每次突波開始時,會重新同步其傳輸階段,以正確接收資料。
每次突波前皆有一個特定模式稱之為前導碼,其能協助OLT鎖定每一次的突波。而OLT的前端接收器則稱為「BCDR」(突發式時脈及資料恢復)單元。
增加前導碼時間可更容易地設計BCDR,但較長的前導碼將明顯降低上行頻寬的效率。BCDR是OLT的關鍵元件,其直接影響PON線路的上行效率,並進而影響PON電信業者的每位元收入。
賽靈思的FPGA技術在OLT中相當普遍,不僅如DSLAM般使用在後端,更可運用於前端。透過賽靈思UltraScale All Programmable元件系列提供最全面的BCDR解決方案。這些解決方案可操作於1.25 Gbps和2.5 Gbps之間。每個UltraScale SerDes埠,包含最低速度等級,皆提供此兩種速率,因此,UltraScale元件系列已成為GPON、XGPON 和 NGPON2 OLT的可擴展平台,並具備用於未來設計的附加功能。
具體來說,BCDR採用32位元固定鎖定時間以實現高效能上行通訊,其功能超越ITUT G984、G987和G989的規範。此外,BCDR配有操作說明和附件,以協助用戶解決以下問題:
如何模擬 BCDR?
對於整合型電信業者而言,首要問題是選擇產品。BCDR只能在PON環境中測試,而PON便是整合型電信業者的產品,但不可能先開發產品,再驗證BCDR。若在開發週期結束後才發現BCDR未達預期結果,那麼將會出現何種情況?
這是賽靈思推出以BCDR為基礎架構的原因。連同BCDR,即可獲得一個具有封包產生器和封包檢驗器的完整模擬測試平台,並用其證明BCDR得以正確運行。
此外,該開發環境不僅能測試BCDR,還能加壓於它,並發掘其終極效能。下述為一些實例:
‧ 產生多個ONU
‧ 可強制讓ONU運行於「錘子」模式,使封包至封包的階段始終維持0.5%的UI,以確保BCDR完全不受波動的影響。
‧ 當多幀封包重啟時,錘子模式下產生的所有封包皆需移動1微微秒,以確保BCDR階段檢驗器沒有死角,而鎖定時間則始終維持短且明確的32位元。
‧ 可於0-8K+間更改封包的前導碼長度,如此將能同時滿足最嚴格的ITU.T PON和較寬鬆的IEEE PON要求。
圖5描述XAPP1277 中與BCDR搭配所提供的模擬環境架構。
該模擬環境需透過腳本運行。無需編寫任一行代碼,即可在數分鐘後看到波形。該環境主要提供予想選擇特定產品,但尚未整合該產品的客戶。
對於硬體廠商而言,軟體壓力測試架構便是一個非常好的起點。然而,需看到硬體在作業時,這正是第二個BCDR架構的工作;該架構使用Kintex UltraScale FPGA的KCU1250描述性套件。該架構在硬體中不斷生成並檢驗封包,以避免任何錯誤或丟失任何封包。
如何使用Demo卡模擬PON環境?如何用1個BCDR進行錘子模式測試?
上行資料總以雙倍速率合成,而TX串列器總在每個上行位元產生兩個同樣的位元。如此,在架構層面,硬體架構可在任兩個連續封包之間,模擬一個0.5UI差別,此亦為PON環境中最差的情況。硬體架構透過在任意兩個封包之間,插入一個最差情況,以對BCDR施壓。
該架構中的負載量是被截短的PRBS,其於每個封包的定義後重新開始。若BCDR跳過任何一個封包,將會在負載量上產生錯誤。
同時亦可在運行中更改前導碼長度。
整個硬體測試平台可支援腳本編寫,並將Vivado硬體分析器內建其中,使其具備一套完整的控制功能,如圖6所示:
除了錘子模式測試、錯誤饋入和累積外,亦可在運行中更改很多SerDes和BCDR特性,例如數位頻寬等。
對不熟悉FPGA技術的使用者來說,SerDes配置則是另一個會讓使用者感到困惑的地方。因此BCDR架構提供了使用說明,一步步介紹如何配置SerDes,並說明用戶要如何設置PON OLT介面。圖7顯示「GT(GT收發器)嚮導 GUI」示意圖,展示架構如何指導配置,以及如何避免硬體複雜性:
圖7 : 用於設置多速率OLT介面的SerDes配置。 |
|
這些技術讓使用者僅需透過GUI便能選擇如BCDR般複雜的產品。原則上,即使不瞭解基礎技術細節也能做這些工作。
一旦對BCDR完成評估,硬體測試平台將成為啟動實際項目的最佳起點。僅需刪除Demo封包的產生器/檢驗器,並用真實的PON MAC替代這些模組,即可嵌入BCDR。
(本文作者Paolo Novellini、Antonello Di Fresco任職於Xilinx賽靈思公司)