I've never been a real advocate for G.fast. The deployment model that they decided to use was detrimental to having ultrafast coverage other than for perhaps up to ~60% premises. Of course, this figure would be subject to a reasonable amount of variation, though I imagine they were only ever going to deploy G.fast to higher density areas (where a good amount of premises should be able to receive ultrafast speeds of 100 Mbps or more).
VDSL utilising up to 35 MHz (whether that would be SuperVector or VPlus, though the latter probably less so as it is nothing something compatible with any existing hardware) should have been the intermediate plan since it should allow for subscribers at up to twice the distance from the cabinet compared to G.fast obtain 100 Mbps. I haven't managed to take the time to understand every aspect about Huawei's SuperVector technology, but what I do know is:
- It is compatible with MA5603T
- It can co-exist with existing 17a profile
- It can provide 100 Mbps downstream up to around 700m
However, it is not clear (perhaps I have missed something/I do not understand entirely):
- What the maximum subscriber density is (in terms of ports)
- What sort of cabinet hardware upgrades would be necessary
- Whether changes would need to be made to the backhaul to accomodate increased bandwidth
Anyway, this is coming from someone who has no experience with DSLAMs or network engineering, so a lot of this could be wrong. Perhaps it is completely uneconomical to consider, and perhaps because it has never really been publicly noted that there has been thought put into the potentiality of rolling it out then maybe no testing was ever done, and Openreach would need to spend perhaps the best part of a year testing it alongside existing hardware, etc. (which in that time they may as well just commit to G.fast and FTTP rollouts where appropriate).
In reference to SuperVector, someone could do some reading here (
http://support.huawei.com/enterprise/en/doc/EDOC1000137144) if they were interested.
The above is not to say that I wouldn't like to have G.fast, because that's not true. I would benefit greatly from having it since I have a somewhat short loop. There is at least one cabinet which has a G.fast pod on, but it is not mine (which needs a re-shell) and this latest news may even mean that I won't get it despite showing as planned on the checker previously (before planned G.fast records were mass-removed). Though I shall cross my fingers and hope that it will come anyway.