GPON系统的组网模式和当前设备的组网能力Word文件下载.docx
《GPON系统的组网模式和当前设备的组网能力Word文件下载.docx》由会员分享，可在线阅读，更多相关《GPON系统的组网模式和当前设备的组网能力Word文件下载.docx（9页珍藏版）》请在冰点文库上搜索。
OLT针对每个T-Cont进行上行调度。
为保证各种业务的上行QoS，一般的思路是把业务流先映射到GEMPort，然后再把所有的GEMPort映射到不同的T-Cont。
这样可以针对不同的业务流进行上行带宽的保证。
在EPON系统中，上行业务的调度只有LLID的概念（LLID等同于GPON系统的T-Cont），OLT针对每个LLID进行上行带宽的分配。
对于ONU内各种业务，由ONU根据OLT分配的总带宽，进行本地的业务流调度，实现QoS保证。
也就是说，GPON的上行业务调度比EPON更精细、更灵活。
从上面分析可以看出，就业务承载能力而言，GPON的优势在于上行业务的承载。
结合支撑GPON现场试验的相关工作，我们根据“光进铜退”的总体思路，重点针对FTTB/C的组网模式进行了分析。
参考目前EPON系统中每个PON口接入512个用户（实际上GPON下行带宽比EPON高1.3倍左右，可以接入1000个用户）的规划，规划每个GPONOLT也覆盖512个用户。
对于GPON系统的而言，有如下几种业务流承载方式：
模式一：
每用户的每种业务都映射一个独立的GEMPort，并映射到一个独立的T-Cont。
OLT可以针对每个用户的每个业务进行上行业务调度。
这种模式能最充分的发挥其灵活的业务流隔离和完善的基于T-Cont的上行业务QoS保证能力。
其原理如下图所示：
对于FTTB/C场景，按照每个PON口覆盖512个用户、每个用户至少4个业务类型计算，需要OLT的每个PON口至少支持2048个GEMPort和2048个T-Cont;
对于FTTHONU需要支持至少4个GEMPort和4个T-Cont；
对于FTTBONU需要支持至少“端口数×
4”个GEMPort和“端口数×
4”个T-Cont（典型的16个FE口的MDU需要支持64个GEMPort和64个T-Cont）。
这种模式下，由于每个用户的每个业务都映射到独立的GEMPort，所以OLT对用户业务的定位、控制和管理易于实现。
目前的主流设备在GEMPort和T-Cont的支持能力上还不能满足这种模式的需求。
模式二：
每用户的上网（HSI）业务都映射一个独立的GEMPort，并映射到一个独立的T-Cont；
每个用户的IPTV业务都映射到一个独立的GEMPort，但所有用户的IPTVGEMPort映射到同一个IPTVT-Cont；
每个用户的VoIP业务都映射到一个独立的GEMPort，但所有用户的VoIPGEMPort映射到同一个VoIPT-Cont；
其他业务也可以采取与IPTV或VoIP相同的映射方式。
OLT可以针对每个用户的上网业务和所有用户的IPTV、VoIP业等务进行上行业务调度。
这种模式能够保证OLT对每个用户的上网业务带宽进行精确调度，而对于相对可控制的自营业务（IPTV和VoIP），OLT仅对所有用户共享的IPTV/VoIP业务上行带宽进行调度。
对于FTTB/C场景，按照每个PON口覆盖512个用户、每个用户至少4个业务类型计算，需要OLT的每个PON口至少支持2048个GEMPort和512＋3×
64=704个T-Cont;
4”个GEMPort和“端口数+3”个T-Cont（典型的16个FE口的MDU需要支持64个GEMPort和19个T-Cont）。
模式三：
每用户的每种业务（上网、IPTV、VoIP及其他）都映射到一个独立的GEMPort，每个ONU上的所有用户的相同类型的业务流映射到同一个T-Cont。
这种模式下每个ONU上最少只有4个T-Cont，即HIST-Cont、IPTVT-Cont、VoIPT-Cont、otherT-Cont。
OLT仅对所有用户共享的HIS/IPTV/VoIP业务上行带宽进行调度，而无法保证OLT对每个用户的上网业务带宽进行精确调度。
对特定业务类型（特别是上网业务）中各个用户的带宽分配只能ONU的本地调度（如采用WRR算法），业务调度的颗粒度与EPON系统没有明显区别。
这种模式无法对用户的每条业务流做到精细化的管理。
对于FTTB/C场景，按照每个PON口覆盖512个用户、每个用户至少4个业务类型计算，需要OLT的每个PON口至少支持2048个GEMPort和4×
64＝256个T-Cont;
4”个GEMPort和4个T-Cont（典型的16个FE口的MDU需要支持64个GEMPort和4个T-Cont）。
目前的部分主流厂商的OLT设备或ONU设备在GEMPort和T-Cont的支持能力上能够满足这种模式的需求，但没有厂商能够OLT和ONU均满足上述要求。
模式四：
各用户的上网业务映射到各自独立的GEMPort，所有用户的上网GEMPort映射到同一个HIST-Cont。
一个ONU上所有用户的IPTV业务流映射同一个IPTVGEMPort并映射到同一个IPTVT-Cont；
VoIP和其他自营业务的映射模式与IPTV业务相同。
这种模式下每个ONU上最少只有4个T-Cont和“端口数＋3”个GEMPort。
OLT仅对所有用户共享的HSI/IPTV/VoIP业务上行带宽进行调度，而无法保证OLT对每个用户的HIS/IPTV/VoIP/其他自营业务带宽进行精确调度，也不能对每个用户的IPTV/VoIP/其他自营业务进行精确标识。
对于FTTB/C场景，按照每个PON口覆盖512个用户、每个用户至少4个业务类型计算，需要OLT的每个PON口至少支持512＋3×
64＝704个GEMPort和4×
对于FTTBONU需要支持至少“端口数＋3”个GEMPort和4个T-Cont（典型的16个FE口的MDU需要支持19个GEMPort和4个T-Cont）。
目前的部分主流厂商的OLT设备和ONU设备在GEMPort和T-Cont的支持能力上能够满足这种模式的需求，部分厂商的OLT不能满足上述要求。
不支持的厂商计划在下一个版本达到上述要求。
模式五：
ONU上所有用户的特定业务映射到一个GEMPort并映射到一个T-Cont，即：
所有用户的上网业务映射到一个HISGEMPort并映射到同一个HIST-Cont。
所有用户的IPTV业务流映射同一个IPTVGEMPort并映射到同一个IPTVT-Cont；
VoIP和其他自营业务的映射模式与HIS和IPTV业务相同。
这种模式下每个ONU上最少只有4个T-Cont和4个GEMPort。
OLT仅对所有用户共享的HSI/IPTV/VoIP业务上行带宽进行调度，而无法保证OLT对每个用户的HSI/IPTV/VoIP/其他自营业务带宽进行精确调度，也不能对每个用户的HIS/IPTV/VoIP/其他自营业务进行精确标识。
对特定业务类型（特别是上网业务）中各个用户的带宽分配只能ONU的本地调度（如采用WRR算法），业务调度的颗粒度与多LLID的EPON系统没有区别。
对于FTTB/C场景，按照每个PON口覆盖512个用户（1：
64分光）、每个用户至少4个业务类型计算，需要OLT的每个PON口至少支持4×
64＝256个GEMPort和4×
对于FTTHONU和FTTBONU的GEMPort和T-Cont的支持能力均较低，仅需要支持至少4个GEMPort和4个T-Cont。
目前的所有主流厂商的OLT设备和ONU设备在GEMPort和T-Cont的支持能力上均能够满足这种模式的需求（参见后面的表格）。
但这种模式使得GPON在业务流隔离和上行QoS调度方面的优势完全丧失。
属最差的模式。
模式六：
ONU上每个用户（也就是每个以太网UNI端口）对应于一个T-Cont。
每个用户的每种业务映射到一个GEMPort，每个用户的所有业务都映射到一个T-Cont，即：
每个用户的上网业务、IPTV业务、VoIP业务和其他自营业务分别映射到各自独立的GEMPort，该用户的所有业务GEMPort映射到同一个T-Cont（用户n）。
OLT仅对每个用户的包括HSI/IPTV/VoIP等所有业务的总上行带宽进行调度，而无法保证OLT对每个用户的HSI/IPTV/VoIP/其他自营业务带宽进行精确调度，但不能对每个用户的HIS/IPTV/VoIP/其他自营业务进行精确标识。
同一个用户内上行多业务之间的QoS由ONU的本地调度（如采用WRR算法）解决。
512＝2048个GEMPort和512个T-Cont。
对于FTTHONU，仅需要支持至少4个GEMPort和1个T-Cont；
对于FTTBONU，需要支持至少“用户端口数×
4”个GEMPort和“用户端口数”个T-Cont。
这种模式以用户为单位进行上行带宽的调度，也具有一定的合理性。
目前GPON设备厂商对产品的设计主要面向的是FTTH场景下的业务应用，对于FTTB/C场景应用的需求考虑得不够，无法满足对每用户每业务流的精确管理，无法发挥GPON技术的优势。
目前的GPON组网只能选择模式四和模式五（模式四部分厂商不满足）。
模式六在厂商设备进一步提高后也具有应用的可行性。
另外，模式一和模式二对OLT的T-Cont/GEMPort的处理能力要求很高，如果要达到1K以上的T-Cont数量，OLT芯片的复杂度成几何级数上升，技术上能否实现有待论证。
升级会员 