PON：数据入户传输的演变

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。