There has been a great deal of discussion recently regarding vectoring, a technology that can help extend the lifespan of today’s copper networks by boosting their performance to near fiber speeds.
Historically, copper has been widely deployed globally, much more so than fiber. Vectoring is an important development since the copper infrastructure has always been susceptible to crosstalk--the electromagnetic interference that occurs between adjacent copper pairs. This ‘noise’ degrades the signal that is being transmitted through the wire and ultimately negatively affects the speed and reach of copper networks.
For telcos that are not yet ready to make the move to fiber, the crosstalk limitation puts them at a distinct disadvantage when it comes to deploying the high-speed broadband services that consumers want, and which the cablecos and alternative service providers are more than happy to provide.
That’s where vectoring comes in. The technology mitigates crosstalk interference and thereby improves the rate and range of VDSL2 to fiber-like performance. Vectoring levels the playing field for telcos, enabling them to prolong the life of existing copper networks, deliver even the highest-speed broadband services and stay competitive as they make the transition to fiber.
Problem solved, right? Sorry, not so fast. There are currently two opposing schools of thought when it comes to implementing vectoring in the field. While some telecommunications equipment vendors are touting board-level vectoring systems, others are extolling the benefits of system-level vectoring solutions.
We’ll break it all down and examine several real-life deployment scenarios and provide a head-to-head comparison of the two approaches.
Some vendors have taken a board-level approach to vectoring. In this approach, the VDSL2 line card houses a vectoring engine that controls the vectoring activity on the ports of the card.
This method has a few drawbacks. First, vectoring requires significant processing power and memory resources, and when it is allocated from the card, traffic performance can suffer if the number of ports deployed is not reduced. Second, all pairs in a feeder cable must be connected to the same card. Since feeder cables typically contain 100 or more pairs, this approach is highly impractical. If the pairs are not connected, the vectoring engine misses out on crucial measurements and coding that ensure the efficiency of the vectoring operation. This can also have opex implications; when customers are added or deleted there is significant cable management activity that must take place.
Consider the following deployment scenarios, which illustrate some of the shortcomings of board-level vectoring systems.
Scenario 1: High take-up rate
In this scenario representing a high take-up rate, 100 end-users subscribe to a premium service that is enabled by vectoring, as depicted in Figure 1. Assuming the use of a 48-port VDSL2 line card, board-level vectoring would be enabled only if 48 pairs were utilized in each 100-pair feeder, resulting in a waste of 52 copper pairs.
Scenario 2: Low take-up rate
In this scenario, which demonstrates a low take-up rate, 40 end users subscribe to a premium service enabled by vectoring. Twenty subscribers are from one neighborhood (and feeder cable), and twenty are from another neighborhood, as shown in Figure 2.
Initially, there is no problem managing both cables from a single card. However, as time goes on and new subscribers are added, as illustrated in Figure 3, there are not enough free ports on the card to satisfy demand. A new line card is installed to connect the additional customers, but vectoring no longer works efficiently.
This situation requires that a technician be sent out to the street cabinet to perform cable management activities. The technician realigns the cables with the line cards, but now there are unused line card ports, as shown in Figure 4. The end result is unnecessary capital expenditures.
System-level vectoring is in sharp contrast to board-level systems. In this case, the vectoring engine resides on a dedicated service card that controls the vectoring activity of all the VDSL2 line cards (See Figure 5). This enables any card to be connected to any pair in any feeder, eliminating cable management concerns and saving opex.