Vectoring question

I was wondering if you have 2 cabinets next to one another with separate VDSL2 equipment but providing FTTC to the same bundle of copper. Would vectoring still be able to work properly?

More specifically, I read that BT were going to start trialling Vectoring after they've moved over to the 17a profile. I'm seriously planning on switching to Digital Region before BT get to my area however. I'm concerned that as more users come onto FTTC my speeds will drop off due to crosstalk and if BT is the only one running/able to run Vectoring, they'll have a *significant* advantage over DRL. What with the SLU pricing mess, it would suck if they can't provide equal service to BT.

I just read the Ericsson document on vectoring - which suggests that there is a significant common part to the cabinet DSLAM functionality to enable this to work. In particular, the transmission of data from the DSLAM is *very* synchronised... but it ought to be possible to synchronise 2 DSLAMs (one twisted pair should be enough)

On the other hand, it doesn't explicitly say that the DSLAM must be in charge of all channels in a bundle - and the back-channel measurement data *could* still function in a standalone way.

Overall, I'm in the middle, but tending towards the "will work" with multipe DSLAMs.

Hope so, it looks like the technology will be essential for me when up to 100Mb speeds are available.

I found this article: Vectored DSL to the Rescue.

It gives a description in something slightly below degree-level physics, but has this to say on the topic of mixing the old & new technology:

Implication #3: Coexistence Among Vectored and Non-Vectored DSL Lines
It is possible that non-vectored and vectored lines share the same binder; for example, if legacy DSLAMs are not replaced as newer vectored DSLAMs are installed. In such cases, the crosstalk generated from the non-vectored lines to the vectored lines cannot be cancelled. If left unmanaged, such crosstalk will reduce the benefits of crosstalk cancellation performed among the vectored lines. The proper management practice is then to reduce the transmitted power levels of the non-vectored lines to a level no higher than what is the minimum required to maintain their service requirements. Any such adjustment of the transmitted power levels must be made on a line-by-line basis, after taking into account the conditions under which each line operates.

Somehow, I don't think Ofcom will let BT reduce power on all their competitior's DSLAMs ...

It still looks to be a beautiful technology boost - a real no-brainer that reinforces justification of the whole FTTC strategy - and might (because it extends the useful life of an FTTC cabinet) make more rural deployments financially viable. On the other hand, it might make some suburban FTTP deployments less viable.

It would be a crying shame if the structure of the UK market meant it couldn't be employed.

Nice article (to the untrained eye).

I can't help wondering how well this clever crosstalk cancellation will work in the presence of wideband RF pollution from intentional RFI sources such as internal powerline Ethernet (Homeplug, BT Vision, etc).

In such a case, the DSLAM has no knowledge of the interfering signal and therefore cannot possibly compensate for its effects, except perhaps by abandoning the use of the affected frequencies (lots of them in the case of Homeplug etc). Which is rather defeating the object, innit.

On the other hand, according to the OSPMAG article, if there is an *external* source of RFI affecting multiple lines similarly, e.g. the usual street light/arc welder problem, the vectoring principle seemingly can spot it and help clean things up, because the interference will affect multiple lines identically.

Jolly clever stuff. I wonder how many MIPS or Megaflops of DSP per line it takes...

"The proper management practice is then to reduce the transmitted power levels of the non-vectored lines to a level no higher than what is the minimum required to maintain their service requirements."

That would have been a good thing to do from day one really, but since "the post-MaxDSL market" seems to prefer "as fast as you can go" to "the contracted speed, with reasonable reliability", it didn't happen.