thinkbroadband :: Impulse noise protection rolling out on Openreach VDSL2
Based on the rumour mill of our user forums we knew that G.INP error correction was appearing shortly for Openreach FTTC services and now a few people have posted line stats showing that G.INP that helps VDSL2 to handle impulse noise better appears to be live.
We are still waiting an answer to a previous enquiry with Openreach to confirm whether this is a full national roll-out or simply an expansion of previous trials. People may recall G.INP being talked about in the same sentence as vectoring, and there is a sense that if G.INP works exactly as expected there is one less change to make when vectoring is eventually rolled out.
What does G.INP do? Basically if helps protect the data sent over the VDSL2 link from the pops and crackles that corrupt the data, a corrupt TCP/IP packet can be expensive time wise if it needs re-transmitting. Traditionally FEC interleaving was enabled on lines the DLM detected as having errors, but this would use up a higher proportion of the available bandwidth while also increasing latency in worst case scenarios. G.INP operates at a more granular level and only eats up bandwidth when small packets of data need correcting, and does so with very little impact on latency.
Will it mean your line will go faster? For those where interleaving is on, there might be some changes, but until a lot more real world examples showing whether the Openreach DLM is favouring FEC or G.INP error protection it will be difficult to say.
Where G.INP comes into its own is once you start to push 100 Mbps or more utilising vectoring and pushing the copper closer to its absolute capabilities.
Quote:
Based on the rumour mill of our user forums we knew that G.INP error correction was appearing shortly for Openreach FTTC services and now a few people have posted line stats showing that G.INP that helps VDSL2 to handle impulse noise better appears to be live.
We are still waiting an answer to a previous enquiry with Openreach to confirm whether this is a full national roll-out or simply an expansion of previous trials. People may recall G.INP being talked about in the same sentence as vectoring, and there is a sense that if G.INP works exactly as expected there is one less change to make when vectoring is eventually rolled out.
What does G.INP do? Basically if helps protect the data sent over the VDSL2 link from the pops and crackles that corrupt the data, a corrupt TCP/IP packet can be expensive time wise if it needs re-transmitting. Traditionally FEC interleaving was enabled on lines the DLM detected as having errors, but this would use up a higher proportion of the available bandwidth while also increasing latency in worst case scenarios. G.INP operates at a more granular level and only eats up bandwidth when small packets of data need correcting, and does so with very little impact on latency.
Will it mean your line will go faster? For those where interleaving is on, there might be some changes, but until a lot more real world examples showing whether the Openreach DLM is favouring FEC or G.INP error protection it will be difficult to say.
Where G.INP comes into its own is once you start to push 100 Mbps or more utilising vectoring and pushing the copper closer to its absolute capabilities.