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.