VDSL Vectoring - Enabled then unconfigured

We are connected to a AIO cab that was installed as part of the Northumberland SEP, our line length is around 450m (16.5dB attenuation).

We were getting a sync speed of around 70Mbps give or take for a while. Then, out of the blue, that suddenly rose to 80Mbps with an attainable of 90+. That seemed awfully high for a line of that length.

I then realised that the vectoring status had changed to 1 (VECT_FULL). There are some properties outside of the village that were due to get their own cabinet I believe, the work started but never seemed to get finished. I wondered whether BT/NCC had decided that vectoring would be enough to get 24Mbps+ to those properties, and decided to enable it for our cab.

Either way, I tend not to check line stats that often but I noticed today that our sync had returned to 67Mbps and that vectoring status was showing 5 (VECT_UNCONFIGURED) again.

Does vectoring work like G.INP in that DLM decides whether it wants to activate it on the line, or will it be activated by default (where available)? We had a power cut a few weeks back, so it may have been that it wasn't activated for the resync - but I can't say for sure. I was more just curious as to whether it would make an appearance again or whether BT had enabled and then disabled vectoring for the cabinet entirely.

Vectoring will eventually be enabled on all FTTC lines as G.Fast is rolled out, as its one of the pre-requisites to the technology.

In reply to a post by Toonshorty:

Does vectoring work like G.INP in that DLM decides whether it wants to activate it on the line, or will it be activated by default (where available)?

No. It won't be controlled on a per-line basis, or by DLM.

In fact,vectoring only has an impact when every line (using the same transmission technology and spectrum) uses vectoring, and that vectoring is controlled by the one DSLAM.

When BT were trialling LR-VDSL, they wanted to use vectoring to improve the speed for the longer lines (or, more accurately, wanted to improve the reliability of keeping a decent speed). To do this, they had to turn on vectoring for everyone - both those on standard VDSL2 profiles, as well as those on the LR profiles.

In reply to a post by AyeUp:

Vectoring will eventually be enabled on all FTTC lines as G.Fast is rolled out, as its one of the pre-requisites to the technology.

The use of vectoring in a VDSL2 cabinet is entirely independent of the use of vectoring within G.Fast. The use of one neither requires nor is required by use of the other.

Obviously vectoring is immaterial if the frequencies used don't overlap - as will be the case for BT, at least at first.

However, vectoring can't help when the transmission systems are entirely dissimilar - which applies to VDSL2 and G.Fast. Heck, they couldn't even make vectoring in VDSL2 17a compatible with vectoring in VDSL2 profile 30a. Instead, they invented a whole new profile - 35b - whose vectoring would be compatible.

Also vectoring will also be no good for us stuck on ECI cabinets because they don't support it.

In reply to a post by AyeUp:

Vectoring will eventually be enabled on all FTTC lines as G.Fast is rolled out, as its one of the pre-requisites to the technology.

G.Fast does need vectoring.
It does NOT mean everyone on VDSL2/FTTC will get vectoring.

I don't expect a single FTTC cabinet to get vectoring because of G.Fast.
Vectoring is only used on BDUK cabinets to help meet properties passed targets.

In reply to a post by simon194:

Also vectoring will also be no good for us stuck on ECI cabinets because they don't support it.

...But won't the hardware in the G.Fast extension pod contain the hardware capable of vectoring? It seems that it must, logically. So, no vectoring for you if your cabinet gets a G.Fast extension pod BUT you remain on your current connection. If your cabinet gets a G.Fast pod and you upgrade to G.Fast, then it'll get taken care of automatically by the pod.

Someone who actually 100% knows needs to confirm or disprove this, though. I suppose the question is "Are G.Fast extension pods completely compatible with ECI DSLAMS?". If the answer is yes, then the above is true.

Edited by deleted (Fri 26-Jan-18 02:37:17)

My comment wasn't anything to so with G.Fast I was just commenting on no vectoring for us connected to ECI cabinets and will continue to miss out on such things.I assume that G.Inp and lower SNRM aren't coming to ECI cabs anytime soon either.

Yes they are. The only electrical connection between the pods and and DSLAM is the 48V DC power supply.

In reply to a post by witchunt:

Yes they are. The only electrical connection between the pods and and DSLAM is the 48V DC power supply.

I�m 100% �in the know� and this is correct. Think of the G.fast pod as being a separate thing completely.

Post deleted by witchunt

You misunderstand how this works and how it's deployed.
Vdsl2 has its own vectoring
G.Fast has its own vectoring.
Neither work with each other. They are completely different technologies run from separate cabinets.
The G.Fast pod is bolted to the PCP, not to the fibre cabinet.
They don't talk to each other and only share a power supply.

A G.Fast pod with vectoring being added to your PCP will not randomly give vectoring to the FTTC cabinet, or any of its users.
Vectoring is entirely optional on VDSL2/FTTC
It is mandatory on G.Fast.

edit: a little more on the technology.

Vectoring units are integrated with their DSLAMs. It receives information from all the modems connected to the DSLAM measuring the crosstalk/noise/interference each line receives. It then performs a massive amount of computer processing and fancy algorithms to work out how best to reduce this. It seems "anti-phase signals" to cancel out the crosstalk signals. This results in almost no noise on a line. This allows more bits/tones to be used which increases sync.

As the G.Fast DSLAM and the VDSL2 DSLAM are completely independent there's no way for some form of cross-vectoring to work. It might not even be technically possible as they are 2 very different forms of DSL.
VDSL2 (along with all its ADSL predecessors) use something called Frequency Division Duplex.
G.Fast uses Time Division Duplex.

Edited by j0hn83 (Fri 26-Jan-18 16:10:49)

In reply to a post by j0hn83:

You misunderstand how this works and how it's deployed.
Vdsl2 has its own vectoring
G.Fast has its own vectoring.
Neither work with each other. They are completely different technologies run from separate cabinets.
The G.Fast pod is bolted to the PCP, not to the fibre cabinet.

The last line is the only bit I forgot about - I understood the rest, I was agreeing with you all. I don't see how it could have been interpreted differently. I was trying to clear up the confusion that someone else had about G.Fast adding vectoring to the rest of their DSLAM (and like I said, I made the mistake of thinking that the G.Fast pod was connected to the DSLAM in that post... which probably led to all the confusion actually, sorry).

Ironically, the original post was about an AIO cab!

Edited by deleted (Sat 27-Jan-18 22:57:49)

Thanks to a faulty slow cooker, we had a couple of power cuts over the weekend. I checked DSLStats this evening to see if that had caused problems with DLM and the opposite seems to have occurred.

Sync has returned to 79987/19999 with an attainable rate of 98632/22206, which considering the 400m line length is pretty respectable. As you might expect with those speeds, vectoring is also showing as 1 (VECT_FULL) again.

So no idea what caused it to switch off initially, but it must still be activated at the cabinet anyway and a re-sync has enabled it on the line again.

In reply to a post by j0hn83:

Vectoring units are integrated with their DSLAMs. It receives information from all the modems connected to the DSLAM measuring the crosstalk/noise/interference each line receives. It then performs a massive amount of computer processing and fancy algorithms to work out how best to reduce this. It seems "anti-phase signals" to cancel out the crosstalk signals. This results in almost no noise on a line. This allows more bits/tones to be used which increases sync.

Correct, and this is why it takes longer for modems to resync with the cabinet.

In reply to a post by Toonshorty:

So no idea what caused it to switch off initially, but it must still be activated at the cabinet anyway and a re-sync has enabled it on the line again.

Sounds like the router was at fault then. It is highly unlikely that vectoring would�ve been turned off, normally once it�s activated, it is for good.

Edited by deleted (Mon 05-Feb-18 21:49:22)