In reply to a post by smsm1:

I wonder if the FTTC/G.Fast lines are almost/fully used, and there's still several lines on the older ADSL or with no broadband, so needing to add some more capacity for people wanting FTTC/G.Fast.

I suppose so but having already upgraded from the original cast iron PCP to a larger steel PCP it seems odd that it should now need an extension pod.

The PCP must be upgraded to the new steel version in order for a G.fast pod to be attached. The old cast iron versions do not support any pods whatsoever, regardless of whether G.fast or copper extensions.

Apologies if you already knew that.

Edited by deleted (Sat 15-Dec-18 21:32:42)

In reply to a post by smsm1:

I wonder if the FTTC/G.Fast lines are almost/fully used, and there's still several lines on the older ADSL or with no broadband, so needing to add some more capacity for people wanting FTTC/G.Fast.

There is no differentiation of service between the premises and PCP (D-Side). All connections go down the same line regardless, but signal is injected at different points depending on the service.

If there is more FTTC capacity required, then Openreach will install a capacity upgrade to the FTTC (VDSL) DSLAM or add a twin cabinet.

If there is more G.fast capacity required, then I am not sure what happens since it's not something I have witnessed yet. Someone here might now.

If more copper pairs are required, then it is not unusual to provide an copper extension. This can be for any copper-based service.

But as Andrue implies, a reshell of a small PCP to the current type in order to provide G.Fast to the close-by properties should obviate the need for an extension pod.

In reply to a post by RobertoS:

But as Andrue implies, a reshell of a small PCP to the current type in order to provide G.Fast to the close-by properties should obviate the need for an extension pod.

For what it's worth this is the original PCP.

In reply to a post by RobertoS:

But as Andrue implies, a reshell of a small PCP to the current type in order to provide G.Fast to the close-by properties should obviate the need for an extension pod.

I would be inclined to agree. For what reason would they also need to supply a copper extension when a larger cabinet should be sufficient enough for current amount of pairs? An anticipated increase in premises connected to the cabinet, network rearrangements?

In reply to a post by Andrue:

In reply to a post by smsm1:

I wonder if the FTTC/G.Fast lines are almost/fully used, and there's still several lines on the older ADSL or with no broadband, so needing to add some more capacity for people wanting FTTC/G.Fast.

I suppose so but having already upgraded from the original cast iron PCP to a larger steel PCP it seems odd that it should now need an extension pod.

Perhaps the FTTC cabinet has also had a High Density upgrade, and so requiring additional space further?

On the larger Huawei cabinets (288 ports) the extension is the darker green section on the right of this cabinet.

https://ibb.co/gJW6khN

It's only a few inches wide and most people don't even notice it has been added. It increases capacity to 384 ports.

The smaller Huawei cabinets High Density extensions are much more obvious.

https://ibb.co/kccwH0K

Both those cabinets are local to me.
The larger Huawei in the 1st image is my serving DSLAM.

Gfast pods deploy with 48 ports, in theory can take 96 but not sure on status of vectoring engines, i.e. vectoring at G.fast speeds across 96 ports was possible in lab but they were having issues getting production chips doing it, That was a couple of years ago though.

Demand of Gfast is such that at last financials there was just 7,000 customers across UK.

I had read in quite a few places that the target was to get 96 ports in the future. But judging by uptake, 48 ports will probably suffice for the quite a while. Some people who are somewhere between midway to the edge of coverage may be put off by the potential of having a slower upstream, so it doesn't help the case.

But I am curious to know the solution if G.fast capacity becomes full at this present time because I do not see an immediate remedy.

As Vectoring is mandatory on G.Fast there are absolutely zero ways to increase capacity. They need to wait for double capacity line cards.

They can't put a 2nd G.Fast pod as they don't support node level vectoring. In other words the 2 individual G.Fast pods couldn't Vector across each other.

edit: auto correct mistakes

Edited by j0hn83 (Sun 16-Dec-18 13:58:12)