To remain competitive and deliver the ultra-broadband speeds subscribers demand, service providers are racing to deliver 100 Mbps services. Despite advances in VDSL2 and vectoring technology, the existing copper infrastructure within subscribers’ homes often makes this task impossible without application of G.inp. It picks up impulse noises from electrical appliances that create errors in the signal.
The G.inp standard protects transmissions from impulse noise, improving line stability while reducing latency at the same time. By combining G.inp with vectoring, service providers can currently deliver 100 Mbps reliably over a single copper pair reusing their existing copper infrastructure .
Reaching the Magic Number
100 megabits per second (100 Mbps). This is the line in the sand, the downstream speed that service providers around the world are striving to achieve so they can offer their subscribers an ultra-broadband experience.
Consumers believe this threshold speed will allow them to take full advantage of the latest applications and services that require extremely fast connections, such as access to cloud based resources, online gaming or streaming 4K TV. What’s more, they’re willing to pay more for this speed or to switch service providers to get it.
The competitive advantage of having such high-speed networks in place is so important that governments are getting involved. Europe’s Digital Agenda, for example, is pushing to have 50% or more of European households subscribe to Internet access at or above 100 Mbps by the year 2020.
While core networks might already be able to handle these speeds , the “last mile” connecting customer premises to service provider backbone networks, along with the wiring within subscribers’ homes, remains the weakest link in the ultra-broadband chain. This access infrastructure is usually twisted-pair (i.e., copper) based. Recent advances in DSL technology, however, will help to make the 100 Mbps vision a reality.
One such technology, VDSL2, is in principle capable of speeds up to 100 Mbps downstream at 500 meters. In most deployments, however, the speed is limited by noise originating from other lines in the same bundle, a phenomenon called crosstalk. To counteract the effects, a technology called vectoring is applied, which eliminates crosstalk noise.
But vectoring doesn’t counteract against other noise sources, such as impulse noise or radio noise (also called radio frequency interference, or RFI).
Any appliance with an electric motor, power switch or power adapter is capable of generating impulse noise. Telephone wiring in subscribers’ homes picks up the noise from such appliances which, in turn, impairs DSL transmission. The severity depends on how close the source of the impairment is to the telephone wiring and the quality of the wiring itself. Service providers tell us, however, that many of their subscribers’ homes have lower quality wiring, so are susceptible to impairment.
Impulse noise comes in two main flavors – intermittent and repetitive. Noise that occurs as sporadic, unpredictable events is called SHINE (single high impulse noise event). SHINE often originates from turning an appliance on or off. Impulse noise that is consistent is known as REIN (repetitive electrical impulse noise). Household dimmers and faulty power adaptors are a common source of REIN.
Resisting the Impulse
Impulse noise protection (INP) is generally comprised of techniques used by DSL transceivers to protect against the effects of impulse noise on the transmitted signal. The former best practice for handling impulse noise was to use forward error correction (FEC) based on Reed Solomon codes, together with interleaving (i.e., I-FEC) to detect and then correct errors within a block of data.
I-FEC works well with REIN, but is less efficient with SHINE, because it requires a fixed overhead of between 6% and 12% of bandwidth under normal circumstances, and up to 20% when attempting speeds of 100 Mbps. In effect, this means service providers actually need to squeeze 120 Mbps out of their VDSL2 lines to deliver 100 Mbps service to consumers due to the 20% overhead.
A solution that works REIN or SHINE
The G.inp standard (G.998.4) was approved by the International Telecommunication Union (ITU) in 2010. It is intended to provide enhanced protection against impulse noise or increase the efficiency of providing INP. The G.inp standard specifies the use of physical layer retransmission to enhance INP.
The approach is similar to the retransmission method used in TCP/IP. Instead of IP packets, however, data transfer units (DTU) are sent between transmitter and receiver. When packets get corrupted during transmission, the transmitting peer is informed and the DTU is resent.
There are several benefits to the G.inp approach. Compared to I-FEC, the method only consumes transmission capacity when retransmission is required, traditionally consuming less than 1% (more on that later). And unlike TCP/IP, all the traffic is protected, including TCP, IP, UDP, SMTP, HTTP and more.
In addition, the round-trip time -- i.e., the (minimum) time required for retransmission -- is very short in case of G.inp because the DTU error detection and retransmission occurs at the physical layer.. TCP/IP retransmission often takes up to 50 milliseconds, while G.inp only takes a couple of milliseconds (4 milliseconds is typical). The result is also that G.inp achieves enhanced INP with good efficiency at shorter delays compared to I-FEC.
Reducing latency is important even when retransmission is not required. Due to the end-to-end communication between the server and the client, having faster responses reduces the amount of time required to complete an end-user request, such as to start streaming a video or download a webpage. Beyond the speed of the connection, reduced latency improves response times and makes for a better end-user experience.
By providing extra protection and reducing latency on the weakest link – DSL – G.inp improves the entire communication chain.
The Time is Right
While the G.inp standard was released in 2010, initial adoption by the industry has been somewhat muted. This is partially because G.inp required hardware upgrades within service providers’ networks as well as within customer premises equipment.
Another factor was that when the standard was developed, it was not clear how much impulse noise generated within subscribers’ homes was intermittent (SHINE) and how much was repetitive (REIN). Depending on how much noise is actually present on the line at a given time, G.inp also requires a certain amount of overhead. If, for example, REIN was a near constant presence and 1 packet out of 10 needed to be retransmitted, then G.inp would carry a 10% overhead.
Today, however, it is much less difficult to adopt G.inp and the business case is much more apparent. Many service providers have already adopted vectoring technology within their networks. Since the G.vector (ITU-T G.993.5) standard was released after G.inp, vectoring-capable hardware typically also supports G.inp.
Reports from the Field
Alcatel-Lucent has conducted both lab trials and real-world deployments of G.inp with more than 50 operators around the world. These deployments have conclusively demonstrated that the actual number of packets that need to be retransmitted is typically less than 1%. Furthermore, adopting G.inp reduces the number of errors on the line by a factor of 10 (Figure 1). This means G.inp has much lower overhead than I-FEC, enables a higher bitrate and provides a better customer experience.
And while outside the scope of these trials, the reduced errors, improved stability and bitrate enabled by G.inp will, in turn, reduce the number of calls to service provider help desks, as well as the number of in-field interventions required. This will produce significant cost savings.
Making it Happen
Alcatel-Lucent supports G.inp on its vectoring products and on its latest generation of VDSL2 line cards. With VDSL2 vectoring, the use of G.inp is strongly recommended for achieving best bit rates and customer experience. Also, without vectoring, the use of G.inp can improve the transmission quality if supported at CPE side.
To contact the author or request additional information, please send an email to firstname.lastname@example.org.