Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2

Author Topic: Openreach Extend G.fast Pilot to 1 Million UK Premises  (Read 1810 times)

gt94sss2

  • Reg Member
  • ***
  • Posts: 671
Openreach Extend G.fast Pilot to 1 Million UK Premises
« on: August 17, 2017, 11:48:26 AM »

Quote
Openreach has today announced that their pilot of 330Mbps capable hybrid fibre G.fast broadband technology is being significantly expanded to include 26 new locations across the United Kingdom (1 million premises by the end of 2017). Various areas from Liverpool to Cardiff are on the list.

Full list at http://www.ispreview.co.uk/index.php/2017/08/openreach-extend-330mbps-g-fast-broadband-pilot-1-million-uk-premises.html
Logged

Bowdon

  • Content Team
  • Kitizen
  • *
  • Posts: 1250
Re: Openreach Extend G.fast Pilot to 1 Million UK Premises
« Reply #1 on: August 17, 2017, 11:50:27 AM »

http://www.ispreview.co.uk/index.php/2017/08/openreach-extend-330mbps-g-fast-broadband-pilot-1-million-uk-premises.html

Quote
http://www.ispreview.co.uk/index.php/2017/08/openreach-extend-330mbps-g-fast-broadband-pilot-1-million-uk-premises.html

Quote
G.fastís 26 New Pilot Locations

Armley
Bath Kingsmead
Bishops Stortford
Brierley Hill
Brighton Hove
Chorlton
Eltham
Glasgow Bridgeton
Glasgow Douglas
Great Barr
Hammersmith
Hemel Hempstead
High Wycombe
Hunslet
Kidbrooke
Liverpool Central
Lofthouse Gate
Manchester East
Mansfield
Northern, Birmingham
Parsons Green
Portsmouth North End
Pudsey
Rochdale
Wandsworth
Whitchurch, South Glamorgan

I was one town away from the G.fast area  :(

I hope these new pilot areas will give people who are active in the forums the ability to give us some feedback on how it performs.

How do people sign up for it? Do they contact their isp? Will it be a paid service?

Is a pilot area a commercial roll out? If not, then I guess the commercial roll out plans have been pushed back. I'm thinking maybe this will be another data experiment to get an idea of how many people will actually take up the offer.
Logged
BT Infinity 2 - HG612 & Asus RT-N66U - ECI Cab

skyeci

  • Reg Member
  • ***
  • Posts: 970
Re: Openreach Extend G.fast Pilot to 1 Million UK Premises
« Reply #2 on: August 17, 2017, 12:59:32 PM »

Some cabs in combe down, Bath already have the pods on the pcp's so just waiting to see when/what is offered. (Family members cab, not mine)
Logged
Sky Fibre Pro -  billion 8800nl v1 (bridge mode) + PFSENSE (APU2C4) 2.4.0 with ipv6 , AC-88U WAP- ECI cab, G.INP disabled as of 8th April 2016

http://www.mydslwebstats.co.uk user upload ID skyECI (using a pi3)

j0hn

  • Kitizen
  • ****
  • Posts: 1040
Re: Openreach Extend G.fast Pilot to 1 Million UK Premises
« Reply #3 on: August 17, 2017, 02:00:55 PM »

That certainly explains all the recent posts here and on TBB about pods popping up everywhere.

900m from the cab here, not gonna help me.
Logged
BT FTTC 55/10 ECI Huawei Cab - Zyxel VMG1312-B10A bridge mode + Asus RT-AC68U running Asuswrt-Merlin - minted on MDWS via DslStats

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 20142
  • Over the Rainbow
    • The ELRepo Project
Re: Openreach Extend G.fast Pilot to 1 Million UK Premises
« Reply #4 on: August 17, 2017, 04:38:35 PM »

I see that two of those listed locations are where a somewhat younger black cat lived for seven years, each.  ::)
« Last Edit: August 17, 2017, 04:55:15 PM by burakkucat »
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

KIAB

  • Reg Member
  • ***
  • Posts: 160
Re: Openreach Extend G.fast Pilot to 1 Million UK Premises
« Reply #5 on: August 17, 2017, 06:31:59 PM »

Some cabs in combe down, Bath already have the pods on the pcp's so just waiting to see when/what is offered. (Family members cab, not mine)

BNE enginer was fixing G.Fast pod to my cab at Bathampton at 6pm couple of evenings ago, but cabinet other end of village will need to be reshelled before it gets one I think.
Spotted G.Fast pods all around Bath, Upper Weston,Bathwick,etc, but they still haven't done cab 46 on Warminster Road,junction of North Road yet.

And there another cabinet on the Warminster Road, junction of Claverton Hill, going that way tomorrow, so I will see if that has a G.Fast pod on it.
« Last Edit: August 17, 2017, 06:47:31 PM by KIAB »
Logged

Chrysalis

  • Content Team
  • Kitizen
  • *
  • Posts: 4981
Re: Openreach Extend G.fast Pilot to 1 Million UK Premises
« Reply #6 on: September 27, 2017, 06:42:25 AM »

I got a theory that g.fast areas may get vectoring on vdsl2.

I have three reasons for this.

1 - in this video vdsl optimisation is mentioned https://www.youtube.com/watch?v=LLpk2dz6nBQ
2 - consider g.fast is vectoring enabled, and openreach plan to make it share vdsl2 frequencies with vdsl2, but if vdsl2 lines remain unvectored then g.fast will get crosstalk related issues on that set of frequencies.  Vectoring vdsl2 lines I assume would solve that problem.
3 - in the video its stated if an existing provider via SLU has enabled vectoring (on vdsl2) then g.fast is a no go, because cannot have 2 vectoring's running, this also suggests that vectoring will be enabled on vdsl2 frequencies.

Thoughts?

Also it looks like the horrible pppoe will be ditched, which should remove mtu issues and lower cpu utilisation as well in routers.

Also this may interest ignition as me and him have had discussions in the past related to capacity of backhaul vs burst speed of customer.
BT was asked in the above linked video is there enough capacity in the backhaul between cabinet and exchange for g.fast.
Answer was basically currently is 2.5gbit on the cabinet, in his opinion not enough (eye opener right?) which is backhaul more than 5x burst speed per customer, he then said the capability is there (not sure if he meant with existing laid fibre to aggregation point as we know BT over provisioned it for future use), for 40 x 10gbit worth of backhaul (400gbit), so seems openreach have a different idea to virgin media on what is sufficient backhaul to supply a node.  This should ease any contention concerns in my opinion, at least on the openreach side of the exchange anyway.
« Last Edit: September 27, 2017, 07:08:40 AM by Chrysalis »
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab

j0hn

  • Kitizen
  • ****
  • Posts: 1040
Re: Openreach Extend G.fast Pilot to 1 Million UK Premises
« Reply #7 on: September 27, 2017, 09:09:26 AM »

It doesn't work like that unfortunately.
The vectoring unit would need to be connected to both DSLAMs.
Vectored VDSL2 would probably cause more crosstalk for G.Fast than unvectored with the higher speeds/higher power levels that vectoring allows.

As always OpenReach will do their own thing. Any shared frequency will have psd shaping like the shared frequency between ADSL/VDSL2.
« Last Edit: September 27, 2017, 09:13:11 AM by j0hn »
Logged
BT FTTC 55/10 ECI Huawei Cab - Zyxel VMG1312-B10A bridge mode + Asus RT-AC68U running Asuswrt-Merlin - minted on MDWS via DslStats

j0hn

  • Kitizen
  • ****
  • Posts: 1040
Re: Openreach Extend G.fast Pilot to 1 Million UK Premises
« Reply #8 on: September 27, 2017, 09:45:30 AM »

I just watched that entire video. From what I just watched it sounds like it isn't possible to deploy G.Fast where VDSL2 vectoring is already in place. Note the questions from the guy from WarwickNet who have their own DSLAMs with vectoring. The speaker says it can't be rolled out to those locations. He confirms that cross vendor vectoring isn't gong to happen.

I love the question from Adrian @ AAISP asking if G.Fast will come with the ridiculous SFI visits. He was just brushed off.
Logged
BT FTTC 55/10 ECI Huawei Cab - Zyxel VMG1312-B10A bridge mode + Asus RT-AC68U running Asuswrt-Merlin - minted on MDWS via DslStats

Chrysalis

  • Content Team
  • Kitizen
  • *
  • Posts: 4981
Re: Openreach Extend G.fast Pilot to 1 Million UK Premises
« Reply #9 on: September 27, 2017, 10:23:53 AM »

yeah was funny.
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab

Chrysalis

  • Content Team
  • Kitizen
  • *
  • Posts: 4981
Re: Openreach Extend G.fast Pilot to 1 Million UK Premises
« Reply #10 on: September 27, 2017, 10:31:52 AM »

It doesn't work like that unfortunately.
The vectoring unit would need to be connected to both DSLAMs.
Vectored VDSL2 would probably cause more crosstalk for G.Fast than unvectored with the higher speeds/higher power levels that vectoring allows.

As always OpenReach will do their own thing. Any shared frequency will have psd shaping like the shared frequency between ADSL/VDSL2.

That PSD shaping shouldnt be needed because the VDSL and G.FAST signals will have comparable attenuation, in certain areas where the cabinet is very close to the exchange, they dont need to do any PSD shaping on vdsl2.

G.FAST seems will not have to navigate the troublesome tie pairs which I believe to be a significant contributor of crosstalk, on the other hand, it will have less power per tone as its power is spread across a much wider range.  Sort of like how adsl2+ has less power per tone than adsl2.

So if I understand you right, vectored vdsl2 would still conflict with vectored g.fast in those ranges because they both would see each other as 'foreign' noise.  In that case I agree, and I have misjudged the vdsl2 vectoring.  Although I am not sure why that would make vdsl2 vectoring a g.fast show stopper, it may increase crosstalk noise (if you are right), but it shouldnt completely kill a signal and would only affect the vdsl2 tones.
« Last Edit: September 27, 2017, 10:36:07 AM by Chrysalis »
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab

WWWombat

  • Kitizen
  • ****
  • Posts: 1635
Re: Openreach Extend G.fast Pilot to 1 Million UK Premises
« Reply #11 on: September 27, 2017, 12:37:54 PM »

Thoughts?

I don't think there will be any correlation between VDSL2 vectoring and G.Fast. Not at first anyway, and possibly/probably never.

1. The first reason is that G.Fast, as used by BT, will only start from around 23MHz. There is no overlap.

This also means that, for the sake of backward compatibility, G.Fast in the UK will not be as fast as it could be theoretically. See the attached graph, and the difference between the aqua and purple lines; UK's G.Fast will be either 150Mbps slower than it could be, or have about 100m less range than it could have without VDSL2.

BT are, apparently researching a way to allow for some overlap, but this hasn't happened yet. They might more easily gain by reducing the "guard band" between 17MHz and 23MHz, to allow G.Fast to start from, say, 19MHz instead.

2. The second problem is that, inherently, G.Fast is incompatible with the way that VDSL2 uses spectrum.

VDSL2 breaks the frequencies into bands for upstream and downstream, and the two bands must be used identically by everyone. If some used a frequency upstream while others used it downstream, they would encounter a different (and worse) kind of crosstalk known as near-end crosstalk. Vectoring works on the standard far-end crosstalk only. Near-end crosstalk is more fatal.

Unfortunately, G.Fast works differently. Every frequency is used for both upstream and downstream together, split by time. Say 80% of the time downstream, 20% upstream.

That means overlap with a VDSL2 band would be causing, say, far-end crosstalk 80% of the time and near-end crosstalk 20% of time (or vice-versa). That would be fatal enough.

The BT research in (1) can't fix this distinction between near-end and far-end crosstalk; the best it is likely to come up with is that overlapped segments become barred (in G.Fast) from usage in one direction.

3. Vectoring isn't a magic marker for "solved". Labelling G.Fast as "vectored" does not suddenly make it compatible with any "vectored" VDSL2.

Vectoring solves the crosstalk crisis by synchronising every transmission that is being monitored, and deliberately injecting controlled (but variable) noise onto every one of those transmissions. The controlled noise is calculated in advance to be the exact opposite of the crosstalk that will be experienced on the way to the receiver, so that it cancels out.

The "crosstalk experienced" is, of course, created by all the other transmitters under the control of the chipset. The chipset needs to know in advance everything that is going to be transmitted, in order to calculate the opposition needed.

Vectoring thus only works if the vectoring chips are in communication with, and in control of, every line transmitter.

Declaring G.Fast as vectored, and declaring VDSL2 vectored, does nothing to stop crosstalk between the two systems. There would need to be a single vectoring system that controlled both the VDSL2 transmitters and the G.Fast transmitters.

Corollary: Today's VDSL2 vectoring cannot counter crosstalk from/to the ADSL2+ spectrum either.

4. It may eventually become possible for a single vectoring chipset to control line transmitters using disparate technologies, but that isn't true today.

As an example, look within VDSL2, at profiles 17a and 30a. Profile 17a (like ADSL) transmits in tones that are 4.3125MHz apart, while profile 30a went for a different scheme, with tones that are 8.625MHz apart.

Vectoring chipsets cannot cope with these 2 profiles together; vectoring chipsets cannot figure out the cancellation necessary. That is why Alcatel invented Vplus, and Huawei came up with SuperVector; these eventually became profile 35b in the ITU-T specs, which kept a 4.3125MHz separation between tones. Vectoring is then possible in a system with lines mixed between 17a and 35b.

https://insight.nokia.com/sites/default/files/vplus-allows-mixed-vectoring-with-vdsl2-17a_figure03.jpg

If today's vectoring chips cannot cope with the difference between two VDSL2 profiles, what hope does it have in tracking both VDSL2 and G.Fast?

It might be possible eventually, but today's incumbents need a solution, like right now.

5. VDSL2 will indeed be an alien crosstalker to a G.Fast system, and vice-versa. The fact the either group is vectored internally matters not to the interference it places externally on the other group.

Yes, they could probably use PSD control to make overlapped signals of a similar strength (like VDSL2 with ADSL).

G.Fast will have their own tie pairs to traverse - but they'll only be a few feet long. They'll still have some effect though.

But the show-stopper is the issue of near-end crosstalk mentioned in (2).

6. On the video, Neil McRae doesn't really cede the cabinet on technology grounds, but on financial ones. Once a cab has been upgraded with VDSL2 SLU by Warwicknet, it becomes less viable for BT to choose to upgrade to FTTC too. Without the FTTC upgrade, there is then no power & fibre for BT's subsequent G.Fast upgrade.

That's how I read it, anyway.
Logged

WWWombat

  • Kitizen
  • ****
  • Posts: 1635
Re: Openreach Extend G.fast Pilot to 1 Million UK Premises
« Reply #12 on: September 27, 2017, 01:27:23 PM »

Also it looks like the horrible pppoe will be ditched, which should remove mtu issues and lower cpu utilisation as well in routers.

STIN 520 still seems to talk about PPPoE in the pilots. There is nothing to indicate that PPPoE is going to be phased out for the live service.

Also this may interest ignition as me and him have had discussions in the past related to capacity of backhaul vs burst speed of customer.
BT was asked in the above linked video is there enough capacity in the backhaul between cabinet and exchange for g.fast.
Answer was basically currently is 2.5gbit on the cabinet, in his opinion not enough (eye opener right?) which is backhaul more than 5x burst speed per customer, he then said the capability is there (not sure if he meant with existing laid fibre to aggregation point as we know BT over provisioned it for future use), for 40 x 10gbit worth of backhaul (400gbit), so seems openreach have a different idea to virgin media on what is sufficient backhaul to supply a node.  This should ease any contention concerns in my opinion, at least on the openreach side of the exchange anyway.

I haven't gone back and listened again, but the current FTTC cabinets have 1GBps links, using standard point-to-point bidirectional fibre optics, and the capability to use at least a second fibre. Any mention of 2.5Gbps capacity must be a reference to using GPON optics instead (2.5Gbps down, 1Gbps up), which suggest that the service could be shared amongst multiple G.Fast DPU's ... but it could just be shared by zero others.

BT also have the option of using XGPON optics instead (10Gbps down, 2.5Gbps up), or even NGPON2 optics (40Gbps down, 10Gbps up).

A mention of 40x10Gbps backhaul is almost certainly a reference to the BTW backhaul from the head-end to the metro nodes. Or even to the core.

In this other video, on the North-of-Scotland submarine build, Neil mentions how that is connected into the rest of BT's network. There he talks of 10x10Gb as being plenty:
https://youtu.be/5ZU5tvBUwZM?t=625

Using Kitz' 21CN architecture, the map behind Neil looks like they have created 30 "Tier 1 MSAN" sites (the orange "new WDM node" sites), and that this 10x10Gb connectivity runs through chains of WDM nodes back to one of the few metro nodes (red squares, 9 in Scotland). Some quite long chains too...
Logged

j0hn

  • Kitizen
  • ****
  • Posts: 1040
Re: Openreach Extend G.fast Pilot to 1 Million UK Premises
« Reply #13 on: September 27, 2017, 01:53:53 PM »

He says the backhaul to the cabinets is 2.5Gbps GPON.
They already have filters in place and can easily deploy XGPON for 40 x 10Gbps. 16:50 on the video.
Unless he's giving a different answer than to what question was asked.
Logged
BT FTTC 55/10 ECI Huawei Cab - Zyxel VMG1312-B10A bridge mode + Asus RT-AC68U running Asuswrt-Merlin - minted on MDWS via DslStats

WWWombat

  • Kitizen
  • ****
  • Posts: 1635
Re: Openreach Extend G.fast Pilot to 1 Million UK Premises
« Reply #14 on: September 27, 2017, 11:56:51 PM »

I just listened again...

Neil "only" says that running 500Mbps off a 2.5Gbps GPON is going to create challenges. He doesn't say that they are, or have been, running such a GPON to either the FTTC cabs or to the G.Fast cabs, so he does avoid answering the question.

He goes on to say "when we built it" without "it" being clear, but does indeed mention the use of filters for XGPON. Together, I take it to refer to potential upgrades to the GPON infrastructure.

Neil does indeed say "running on each PON north of 40 times 10gig", but given the context (PONs). I'm pretty sure, though, that the "40 times 10gig" really means "40gig down, 10 gig up" as that is the standard speed for NGPON2. BT have since trialled multiplexing GPON alongside both XGPON and NGPON2 on a single PON, to get 52.5Gbps, whereas I haven't heard of anyone attempting to get 400gig out of a single PON.

I'm still comfortable that the existing FTTC cabs aren't fed through a PON, so get point-to-point 1Gb service. Here's what I've posted previously:
Quote
... photos in Falmouth, of a single OLT/handover node. This happens to be an ECI node:
http://coolwebhome.co.uk/fibre-cornwall/
See picture 22, but 20 and 23 are also relevant.

In 22, it looks like
- All the GPON fibres terminate on the 6 rightmost cards, where fibres slant upwards.
- The centremost 2 cards (that have no fibres, and bulge outwards) are the switching fabric, that act as the layer 2 switch.
- Either side of these 2 cards are the 2 cards that terminate the fibres from FTTC cabs. I think these are 1000base-BX, with one fibre used to each cab, carrying both TX and RX lasers.
- The leftmost card terminates the handover cablelinks. These are more standard GbE 1000base-LX links, with a pair of fibres each - one TX, one RX.

The question for BT is how to wire up the G.Fast pod using one of the spare strands of fibre available in the FTTC cabinet, where they were originally blown as a unit of 4 strands. Because the 4-unit fibre is blown as a single unit, I think it might prove hard to put one strand through a PON splitter leaving the others intact. But otherwise, we've had little clue about how they intend to feed the pods - even knowing really whether they intend PON or pt-to-pt.
Logged
Pages: [1] 2