城域网核心服务以及接入传输服务基于静态设置的固定带宽容器，这些容器位于STS-N层或VT-N层(由SONET定义)，以及AU-N层或TU-N层(由SDH定义)。
在城域网核心和接入网络中部署的设备是基于能够在容量为51.84Mbit/s(STS-1)或155.52Mbit/s (AU-4)的最小容器中交叉连接用户服务的架构。然而，服务提供商所提供的能够创造收入的业务则基于速率较低的 T1、E1以及新兴的10/100M以太网服务，这些服务通常无法高效映射到更大的SONET/SDH容器中。
利用基于SONET的VT1.5 (1.728Mbit/s)容器或者基于SDH的TU-12(2.304Mbit/s)容器(见表1)能够实现集合与交叉连接，借此高效管理T1(1.544 Mbit/s)、E1(2.048 Mbit/s)或者10/100M以太网服务。这些速率较低的容器最初用来使基于PDH的业务映射至SONET/SDH网络。除此之外，STS/AU和VT/TU级出现的技术(比如虚拟级联和LCAS)可以实现灵活的带宽管理，进而通过这些固定净荷容器机制实现高效的10/100M以太网服务。
尽管VT和TU自从SONET/SDH问世以来便已定义，然而，在整个网络提供VT/TU支持，以确保高效映射、交叉连接并集合低速服务是不切实际的，而且成本极其高昂。最近的技术进步有助于缓解网络级、网元级和硅晶片级的高容量VT/TU交叉连接所面临的重重困难，但无法彻底克服这些困难。 本文从网络级展开，旨在深入分析VT/TU交换对所有三个层级的影响。
网络级问题
在网络级实现VT/TU级交叉连接，可能导致带宽管理以及自动保护交换和Transmux功能出现问题。在设计时，让系统有效地解决这些问题需要花费极高的成本，因此服务提供商必须了解每一步，简单的升级不能完全解决问题。
在整个城域网中的分插多路复用器(ADM)内实现VT/TU级合并以及交叉连接支持是很困难的。网元无法以较低的成本、功耗和较小的占位面积切实可行地支持大容量VT/TU交叉连接。系统级功能(比如带宽设置以及报警监控等)也很难在VT/TU级操作、并在未集中分布的网络中进行管理。
到目前为止，城域网主要采用ADM，借助点对点及环形架构予以实现，能够疏导至STS/AU级。很大一部分VT/TU级交叉连接出现在数字交叉连接系统(DCS)中，此类系统集中分布在城域网核心。
对于传统的网络拓扑学而言，在特定的城域网中，希望在两个站点之间连接，T1线路的客户需要在每个站点都设置独立的T1线路，每个站点都要求回连至城域网外部的DCS，以便完成服务连接。在接入环状网专用于支持回程连接的应用中，这样做可能导致带宽陷入困境而无法使用。
除此之外，还必须考虑更加精细的带宽管理。支持大量分布式网络元素所必需的软件复杂程度和功能都有所增加。在集中式DCS中，带宽设置、测试接入以及告警监控比大量分布式网元中的相应过程易于管理。
尽管如此，随着运营商要求更多VT/TU级支持那些靠近城域网接入的网元，新兴的发展趋势则是分布式解决方案。
更高容量的VT/TU交叉连接的额外激励因素便是支持Transmux的需求。Transmux是一种完成基于PDH的低速支路(通过不同映射从网络的每一端进入网络的T1)连接过程。
例如，在一端，T1通过M13 多路复用器被多路复用至DS3，然后被映射至STS-1。在其他端，T1被直接映射至VT1.5，然后通过纯粹的SONET网元被映射至STS-1。为了实现互连，这两种信号必须在同一点分离为原始的T1格式。
APS要求
除了需要Transmux功能之外，运营商还需要在VT/TU层实现分布式自动保护交换(APS)，以便保持99.999%的可靠性。APS适用于VT/TU层，由单向路径切换环(UPSR)定义，在SONET标准的Telcordia GR-1400-Core和子网连接保护(SNCP)、以及SDH标准的ITU-T G.841和 ETSI TS 101 009中均有所描述。深入评论APS架构已超出文本的范畴，但有必要重点指出同VT/TU处理相关的若干关键问题。
APS可以提供一种机制，帮助系统从网元(设备保护)的故障中自动恢复。APS能够应用于更高的STS/AU层或者更低的VT/TU层，具体视所采用的标准以及网络类型而定。
目前，大部分ADM都可以在STS/AU层支持UPSR或者SNCP，通过软件提供实施APS切换所必需的大部分算法。硬件具备故障检测功能，并且支持最终的切换事件，软件实际上是用于读取检测到的故障、解释信息和生成经过修改的交叉连接状态，然后将新的配置写入硬件。这是一种软件和处理器密集型的解决方案。
对于低容量VT/TU交叉连接而言，上文所述的传统APS方法通常都是可以管理的。然而，随着服务提供商向容量更高的VT/TU交叉连接演进，在这些标准设定的性能范围内应用传统的APS模式开始变得不合时宜。
尽管设备保护不存在任何时间限制，但网络标准为设施的保护规定了50ms的时间限制。网络必须在这一时间框架内检测并重新配置所有连接。
冲破50ms的桎梏
对于那些在STS/AU层监控信号的低速光纤链路(OC-3/STM-1以及OC-12/STM-4)而言，基于软件的APS解决方案可以通过经济、高效的硬件予以实现。随着城域网中的高速光纤信号(OC-48/STM-16以及OC-192/STM-64)不断激增，以软件为中心的APS解决方案需要功能更为强大的控制面板解决方案。
例如，支持OC-12上行链路信号的网元可以为该链路处理12路STS-1，在此，每路STS-1必须作为完全不同的独立实体受到监控和操控。标准规定，如果光纤被切断，所有受保护的链路必须在50ms内恢复正常，因此每个适用的STS-1都必须实现广泛的性能监控。
在支持分布式VT/TU交叉连接网络时，问题进一步复杂化。每路低阶支路都必须独立受到监控。每个VT/TU实体所必需的处理能力类似于每个STS或AU实体所需的能力，然而，所处理的独立实体的数量同 STS/AU层相比增加不少。
在以往的OC-192实例中，5376路独立的VT可以在50ms内在APS事件中实现监控和交叉连接。除此之外，如果ADM支持OC-48和OC-192这两种信号的环通，所处理的VT和TU的集合容量便会增长到无法管理的水平。这就需要新技术分担那些在STS/AU或VT/TU层支持APS的高容量网元中软件和控制单元的负荷。
网元级问题
在设计新一代ADM以便在VT/TU层支持集合与交叉连接时，OEM厂商面临着众多挑战。本文主要论述四种挑战：1. 集中式而非服务器卡设计；2. VT/TU指针处理器的位置；3. 高阶成帧器受到的影响；4. 支持虚拟级联对10/100M以太网的影响。
目前的城域接入以及核心ADM仅支持STS/AU层的交叉连接，运营商对于更换整套网元并不感兴趣。为了满足分布式VT/TU支持的新型需求，OEM厂商必须在无需升级机架的情况下实施解决方案。存在着两种选择: 一是利用新的交叉连接卡更换现有的中央STS/AU 交叉连接卡，前者可以同时在STS/AU层和VT/TU层支持整理疏导功能；二是保持现有STS/AU交叉连接卡的完整，并在平台中添加VT/TU服务器卡。在这两种情况中，目标都是在支持VT和TU交叉连接的同时保持相同的总STS/AU交叉连接容量。在选择一中，添加VT/TU支持可以大大增加芯片数量、动力和板卡空间。选择二更为理想化，机架中未被使用的插槽或者以前并未使用的插槽可以分配至VT/TU交叉连接服务器卡。在这种情况下，任何包含低阶VT/TU业务的高阶STS/AU业务都被以STS/AU梯度选择性地导入新的服务器卡，VT和TU根据需求实现交叉连接，然后它们被发送回高阶交叉连接。
这种新增的VT/TU交叉连接功能具有非常低廉的成本。插槽必需为新型VT/TU交叉连接服务器卡提供空间，现有STS/AU交叉连接的带宽(10%~25%)必须专用于这种新卡。例如，目前投入使用的容量为160 G STS/AU的ADM可以通过底板向新型“单臂” VT/TU疏导卡分配16 G~40 G的带宽。
指向正确位置
在向平台提供VT/TU交叉连接支持的过程中，下一个挑战便是低阶指针处理器的位置。SONET/SDH标准的核心前提是为同步框架定义一种机制，例如T1和E1。
对于包含VT或TU的业务而言，在连接平台交叉连接卡之前，低阶指针处理是强制性要求。在STS和AU通过网络时，指针可以单独调整每个容器的位置。当所有容器在同一交叉连接点会聚时，它们无法正确定位。
为了成功实现连接，承载VT和TU的所有容器必须通过系统的重新定位容器的低阶指针处理器。在平台中定位低阶指针处理存在两种选择：在线路卡中或者在交叉连接卡中。
可用的功率和空间以及原有架构受到的影响可用来确定低阶指针处理器的位置。无需重新设计现有板卡以支持新的低阶指针处理器。该方案可以支持VT/TU交叉连接的特定容量，比如10Gbit~50Gbit。
当VT/TU交叉连接的容量超过10Gbit~50Gbit的范围时，每