Rami Verbin, CTO of Sckipio presents the end-to-end G.fast solution to the TNO Ultrafast Broadband conference June 2015. During this discussion, he outlines all the elements of a G.fast solution.
Sckipio G.fast Presentation at TNO Ultrafast Broadband 2015
1.
2. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 20152
Connecting The Pieces
Putting the pieces together and some
insight on the evolution of G.fast
3. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 20153
Agenda
• Putting the pieces together
– DP elements
• GPON, RPF, VDSL coexistence/dual mode, management
– GW elements
• What’s next…
– Market evolution
– Next generation G.fast
– G.fast vs. VDSL 35b
4. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 20154
ME
PMAPMA
The End To End Solution
CPE (FTU-R)
EMS CPE
Netconf
G.fast
G.fast ME
PMA
Operator
Network
Copper
Network
Netconf
G.fast
Video
Head-End
OpenFlow
OpenFlow
(NFV)
OpenFlow
Backhaul
HON
DPU
PMA
aggregation
G.fast
SDK
5. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 20155
16 ports DPU
PC/Laptop
AFE
4P-DFE
AFE
Vectoring
Hybrid
Line I/F
To CPE
2.5G
SGMII
Hybrid
Line I/F
4P-DFE
4P-DFE
4P-DFE
4
4
4
4
G.999.1
G.999.1
G.999.1
Switch/NP
SFP
SFP/SFP+ Form factor
Gb-Ethernet
GPON
XPON
10G Ethernet
Etc.
DDR
Local Mng. port
2.5G
SGMII
SFP
6. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 20156
Different scenario examples
ADTRAN 500G series
G.fast Outdoor ONU
8, 16 and 24-port variants
Fully sealed enclosure for
DPU and MDU deployment flexibility
Passive cooling for completely silent
operation in residential areas
Zero construction: span or reverse- powered
GPON (via SFP ONT) and P2P fiber uplinks
Forward-compatible to
SDN-controlled architectures
7. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 20157
Indoor DPU example
ADTRAN 624G
G.fast Indoor ONU
Supports 8-16-24 MDU living units
Supports Gigabit Broadband
10Gig Ethernet Ring uplink (ERPSv2)
GPON and NG-PON2 uplink options
Forward-compatible to
SDN-controlled architectures
Hardened Outdoor version is designed
for outdoor passive (no fan) cabinet
applications
8. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 20158
Why Using GPON SFP
• Decoupling the ONT from the DPU
– Keeping the DPU simple
• Lower cost
• Opens the market to more vendor, i.e., more competition
– Easy migration to new optical technologies, NGPON?
• No lock up to a specific GPON vendor
– The history of GPON interoperability…
• Note – GPON SFP is gaining momentum also in the
GW market, volume is ramping up
9. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 20159
• 4 ports DPU with RPF was demonstrated in January 2015
• Requirements and challenges
• Power
– Run one port with <12w
– NP’s are power hungry
• Usually not scale with traffic
– Special care to avoid peaks
• Boot process
• Startup
• Noise injection from RPF
– Special care for long loops
Reverse Power Feeding (RPF)
Sckipio RPF demo
10. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 201510
Dual Mode DPU (G.fast + VDSL)
• Very few customers are looking for a dual mode DPU
– Makes no sense for CAB deployment
• Main issue is cost
– Two line interfaces
– Two AFE’s: one for VDSL and one for G.fast
– How to couple (or select) the two signals without a loss:
• Diplexer or a relay
– One DSP may be used for both but what
about the ratio between the number of ports
per mode
• If you optimize for VDSL, G.fast is going to be quite
expansive…
• And the alternative is quite simple
VDSL
DSLAM
G.fast
G.fast
Diplexer
Diplexer
VDSL
G.fast+VDSL
G.fast+VDSL
DP
CAB
11. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 201511
VDSL coexistence
• Issues in both directions
• G.fast -> VDSL
– Spectral overlapping is not allowed
– G.fast may start from 20-23MHz
• VDSL -> G.fast
– VDSL in-band NEXT into G.fast
• Some filtering may be needed
VDSL G.FAST
< 17.6MHz 20-106MHz
12. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 201512
VDSL-G.fast coexistence
• VDSL in-band signal may couple into G.fast receiver via NEXT and limit its
dynamic range (higher noise floor)
0 10 20 30 40 50 60 70 80 90 100
-140
-120
-100
-80
-60
-40
Frequency [MHz]
[dB] VDSL PSD mask
G.fast PSD mask
Background noise
G.fast dynamic range
NEXT
13. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 201513
ME
PMAPMA
Data, Management and Control Plane
CPE (FTU-R)
EMS CPE
Netconf
G.fast
G.fast ME
PMA
Operator
Network
Copper
Network
Netconf
G.fast
Video
Head-End
OpenFlow
OpenFlow
(NFV)
OpenFlow
Backhaul
HON
DPU
PMA
aggregation
G.fast
SDK
Network
Virtualization
OpenFlow v1.3.2
Agent
Netconf Server
supporting G.fast
YANG model
SDK API with
support for G.997.2
mng. objects
PMA example app
and partnering with
PMA solution
providers
14. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 201514
1P-AFE
G.fast Gateway
RPF – power injector
To DP
Line I/F RG
RGMII/
SGMII
(1G)
DDR
Flash
LAN
VoIP
WiFi
HN
G.fast Integrated Gateway (CPE)
SLIC
POTS
Coax/PLC
4
21P-DFE
15. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 201515
G.fast CPE Examples
ADTRAN 500RG series
Residential Gateway
SFP i/f for Gigabit Broadband
Rapid home installation
from eliminated home wiring
Optimized for multi-user homes
via MU-MIMO technology
ADTRAN 5660 and 6360
IP Business Gateway
Converged Gigabit Access Router
Layer 2/3 managed service delivery
Support for mobile network timing distribution
Programmed and monitored through open APIs
using NETCONF/YANG and OPENFLOW
16. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 201516
G.fast Gateway
G.fast port Hybrid
Line I/F
RG
RGMII/
SGMII
(1G)
DDR
Flash
LAN
VoIP
WiFi
HN
SFP based G.fast Gateway
SLIC
POTS
Coax/PLC
1P-
G.fast
4
21P-DFE
VDSL
G.fast SFP
VDSL port
17. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 201517
Why G.fast SFP
• Migration strategy from VDSL
to G.fast become easy
• Reuse existing VDSL
Residential and Business CPE
• Future proof
– G.fast amendment 2?
– Interop. fixes
• Multi-mode GW
– G.fast
– GPON
– 1G Eth.
• Reduce risk of interoperability
19. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 201519
G.fast is extending its scope
Distance
Port count
Short reach
100-150m
Long reach
300-350m
Low port count DPU/MDU ?
High port count Large MDU Cab deployment
20. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 201520
G.fast is evolving -
more features to be added…
Distance
Port count
Short reach
100-150m
Long reach
300-350m
Low port count DPU/MDU ?
High port count Large MDU Cab deployment
Wider BW
Advanced precoding
Power boost
Lower noise floors
Larger
vectoring
groups
Larger
constellations
Bonding
21. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 201521
0 100 200 300 400 500 600
0
100
200
300
400
500
600
700
800
900
1000
Loop length [m]
Bit-Rate[Mbps]
Downstream Rate/Reach
G.fast, 20-106
VDSL 35b
VDSL 17a
G.fast, 2-106
G.fast vs. VDSL 35b, downstream
• Huge advantage for G.fast for short lines. Similar performance if the target rate is 300Mbps. Advantage to VDSL+ if
the min rate target is 200Mbps (100m). No real advantage for VDSL+ if G.fast can start from 2MHz.
300Mbps target
200Mbps target
C
A
B
22. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 201522
V+ (35b) vs. G.fast Comparison
Parameter G.FAST VPLUS (35b)
Bandwidth 2-106MHz, 2-212MHz (future) 2-35Mhz
Max Rate Up to 1Gbps with path to even faster
future G.fast performance
Up to 400Mbps for 0m loops, no path
to higher speeds
Down/Up ratio Configurable: 90:10 to 30:70 Fixed ratio
Complexity 2K Carriers (more efficient) 8K Carriers (results in 4x more
memory required for vectoring)
Vectoring Designed to cope with the high FEXT
level in the G.fast band
Designed for the low 17MHz VDSL
frequencies. Significant performance
loss when FEXT is high.
Customer Self
Install
Likely – the huge rates leave margin
for handling tough in-home networks
Unlikely – performance may drop
under 17a rates
Openness 7 silicon vendors participate in the
G.fast interop. event (Plugfest)
Single vendor?
No BBF certification plan
* Sckipio implementation
23. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 201523
Summary
• We have all the elements in place
– Ready to start the evaluation of the complete solution
• New deployment strategies are developed for G.fast
– G.fast technology is evolving to align with the new requirements
Rami Verbin, co-founder and CTO of Sckipio Technologies presented this material and the G.fast summit on May 21, 2015.
This presentation is more about a system view, less about the G.fast technology by itself. It is more about the end-to-end solution. How we take all the different pieces to create an end-to-end service because there are many more elements than just the G.fast transceiver. It is more about our ecosystem that we are developing for our end customers to create a complete solution.
Then, on the second part of the presentation, we take a very brief look at the market evolution and the impact it has on the G.fast technology itself.
This is kind of an end-of end view of the complete solution going all the way from the EMS (the operator’s management system) to the PMA – the persistent management entity. The optical backhaul technology and then all the way to the DPU which includes the management entity and the G.fast transceiver all the way to the consumer that’s the complete solution.
As Sckipio – we are focusing our efforts on the silicon elements, but it is very important that in the end, we are part of the complete solution and not only the G.fast transceiver. So we start with the basic element, the G.fast DPU. This is the box – that we have today – demonstrating our reference design – one of the first things you should note about it is it is realy small – really compact and efficient. What we can note – before looking at the block diagram. Inside the board – these are SFP interfaces. As we now look briefly at the block diagram from left to right – if you look at the optical interface there are two SFP cages, the point is that we can use whatever optical interface technology that you’d like – You can replace this SFP with wired Ethernet interface– you can also use GPON interface for an optical interface– and number of reasons for this approach. I will touch on those later.
The next element is the network processor G.999.1 interface which connects into 4 digital engines DFEs connected to analog front ends to the phone lines and that’s the solution.
Vectoring is implemented in an integrated way, no external HW. All in the chip-set. Very efficient in cost and power.
The power consumption is low enough to support deployments in harsh conditions and I will show examples of products that are planned to allow this kind of installations. The power consumption is low enough to allow deployment in the field and to support reverse power feeding.
Multiple product variants are in development using this sealed unit.
The device is making use of an SFP optical i/f – the motivation is explained on the following slides.
Multiple product variants: 8-16-24. Four 10G Ethernet interfaces. Designed for cabinet and in-home deployment.
The next element to relate to is the GPON SFP interface. This is actually a very interesting concept promoted by number of operators. The main idea behind it is the ability to decouple between the access technology, the G.fast technology and the optical technology and this brings many benefits to the end customers – to the operators. They can have competition between GPON vendors separate from the competition between the G.fast vendors so they can have the best and lowest cost solution for the GPON SFP, the GPON interface and go maybe with a different vendors with a better solution for the G.fast technology. That’s one point.
Another point, it is quite easy to migrate. Our OEMs will be able to use exactly the same G.fast DPU and just replace over time the GPON interface, maybe to an XGPON interface. Other customers, we know that some customers would like to use the Ethernet interface and not GPON. Again this will allow our customers, the OEMs to use exactly the same G.fast CPE design and just use different pluggable interfaces or SFPs meaning that the operators, the end users will be able to benefit from higher volumes because they will use exactly the same DPU box for multiple vendors. Some with Ethernet some will like to use GPON but basically, it is going to be exactly the same DPU box which is a huge advantage.
There are other reasons behind that – the poor history of interop issues with GPON – again, the fact that the operators will have the flexibility to change GPON vendors – to use different solutions will actually force the industry also in the future with XGPON to support this interop effort because the customers, the operators, will not be lot locked to a specific solution that comes together with the DPU box.
It gives you a lot of flexibility. If it is well designed, you will be able to reuse the exact same DPU box for multiple interfaces and maybe if in the future, for next generation interfaces. Another aspect of that is we know that actually the XGPON SFP interfaces are gaining momentum hooked up to the gateway side. There are already gateways up with GPON SFP interfaces. So, in fact, we will be able to benefit from the volume, the GPON volume that is going to be used also for GPON deployments. Let me touch again the SFP concept for the CPE because we support the same concept also for the CPE.
On the next slide, we talk about reverse power feeding. I understand that some guys are very worried about the power consumption. But, we were actually the first to demonstrate a working reverse power feeding demo with Microsemi. This is a picture of this demo. The demo showed 4 ports of G.fast but surely there’s going to be, of course, a full 16 port prototype. This four port was just for demonstration. There are definitely challenges there. I agree. It’s not easy but it is good and it was proven to be working and proving to work, because you need to be able to run a single port even though you have all the lines available there, you need to be able to run a single port with a power budget which is low enough. If you want to support 250 meters, then you need to be able to keep one link alive to the DPU over that with a budget that is under 12 watts roughly. And there are some issues because network processors are usually quite power hungry. In this case, you might be surprised to find, in many cases, the network processor is not a negligible element any more. The GPON element is not at all small. So, there are many elements need to take care of in order to allow operation with reverse power feed and within the power target. But we are looking at the complete picture together with all the other elements and not only the G.fast elements.
There are some other issues that if your peak allowed power is 12watts or 15 depending on the loop length, you cannot do only average power consumption – you must make sure there will not be peaks even during boots, software boots or any other phase in the booting of this box, the power consumption cannot exceed this unit and this is something that has to be taken into account. The last, very important, last but not least, is noise injection from the reverse power feed injector into the G.fast receiver which is definitely something needed to be taken care of otherwise the performance will suffer and be hurt.
Next element, Again, I am just going element by element looking at the complete solution. So, just touching very briefly each and everyone one of them and trying to show that we have quite a wide view of the complete solution and we actually have all the elements and all the end pieces already in place.
This one is about the dual mode DPU. If fact, there are very little customers asking for that. Or, maybe I will express it differently. Everyone would like to have it if it is for free. So, give me for free and I will take it. But it is not for free. So, if fact, if it is not for free there is a very, very short list of operators, Swisscom is actually one of them and we understand why they really need it, the list is very short, yet the reason is for that is the issue is cost because, in fact it is not at all easy to support it. Especially – even if you can integrate the digital, the DSP part, still you have issues with the analog front end. It is very likely that you will need actually two independent receive and transmit paths, analog paths and then this definitely has cost implications but also for the DFE, supporting dual mode solutions has implications. It will be in the end be reflected by the number of ports for G.fast and support the ratio between VDSL port count and G.fast port count. So, in the end, whatever you need, by the way between the two, it will be all about cost and if it is not going to be for free and probably not going to need to pay for it.
The alternative is very simple because you have VDSL already in the DSLAM, either you use relay here, then its definitely doesn’t make any sense to have again VDSL supported because it is already here and you just need to select the existing VDSL and G.fast. But again, if it is for free, I suggest you buy it.
VDSL co-existence, that’s a real issue that has to be looked at and you need to look at both VDSL disturbance into G.fast and G.fast disturbance into VDSL. Both ways. And that is just one example. You need to look at different factors, different mechanisms. The lecture here won’t show all of them
I picked one here that is interesting. This is actually the VDSL PSD, downstream VDSL PSD mask. The green one is G.fast starting from 23 meg. The red line is one of the ITU noise models for the background noise and the issue is in this example is that the G.fast receive path has some [Inter] dynamic range. The minimum should be around 4-6 dB if you want to support 12 bit constellations. There may be, I am sure some vendors have much more than that, significantly much more than that, but if you think of the minimum of 4-6 dB, then, the fact that you have NEXT coming from VDSL into G.fast means that your receive signal may be higher than the dynamic range. So, if the total power, the VDSL total power into the G.fast receiver is bigger than the overall power on your line then the G.fast receiver will have to adjust power receiver gain. The outcome may be a higher noise floor. However, this can be handled by receiver filtering and that’s one reason that the diplexer – shown previously will probably need to be implemented there and this depends on the analog front end performance. It is really a specific implementation issue that can be handled – even if you are very limited receiver path.
Next is the management. This is the management concept – so just go through very briefly. Again, we have coverage for this complete end-to-end solution with multiple partners – I think one of them was just announced yesterday or the day before – iPhotonix, but there are many more. Some of our OEM customers, the bigger ones have their own solution end-to-end going from the EMS through the PMA to the management system in the DPU. What’s special about G.fast is that we have many newcomers. Many smaller OEMs that are actually trying to use the opportunity of new technology to get into this market and in order to support them, we also have partners to make the complete ecosystem available for them to take advantage of that and be able to offer a complete solution with all the elements – not only the DPU, that we are as Sckipio focusing on. The solution for which we have a complete offering including an EMS, the PMA, the OpenFlow agent. This gives the customer the network connection to the cloud. This OpenFlow we already demonstrated showing the first G.fast managed by true OpenFlow so we also have a solution for SDN.
Sckipio has also a complete GW reference design, including the GW chipset by Intel and RPF by Microsemi. Parts of it were already demonstrated like RPF.
An example of a G.fast GW product is the 500RG by Adtran for residential applications and the 5660 for buisness applications.
Both CPE programmed and monitored through open APIs using NETCONF/YANG and OPENFLOW enabling self-healing, data collection, customer self-install and auto-provisioning.
This GW supports the SFP i/f, so G.fast can be just plugged in – see next slide on why G.fast SFP is the right way forward.
A dual mode (G.fast/VDSL) reference design using Intel’s GW and VDSL chip-set and Sckipio’s solution for G.fast SFP.
GW’s are already available today supporting the SFP i/f. This makes them future proof. Can be used today for VDSL and be upgraded in the future with either GPON, G.fast or any other access technology.
The SFP approach is adopted today by many operators as the best migration strategy from VDSL to G.fast. In the near future, VDSL volume will continue to be higher than G.fast. New technology takes time to ramp up. We all know that. So you would like to have on one hand the lowest possible cost for the GW with a VDSL optimized solution. On the other hand, you would like to be able to easily upgrade the GW for G.fast customers. SFP is right for that. Over time, the optimal solution may change and an integrated G.fast/VDSL may be a better approach. But this is probably 2-3 years away.
We now move from the system level overview to the second part of this lecture. This part deals with the evolution of the G.fast technology.
Only 6 months ago the G.fast use case was very simple. Short reach, low port count. Yes, there were very few operators asking for long reach and higher port count but we considered that as special cases, to be addressed on a second phase, not as a main market application.
And then G.fast started to diversify. This is actually very common that once you have a good solution, new requirements show up. So now it is clear that G.fast is gowing to evolve in two different directions: higher port count and longer reach. For both cases, means for improving performance are now identified and to be specified in the ITU.
We have a long list of tools to improve performance for both use cases: short range and long range. Tools applicable for short range deployments have typically only small relevance for long reach applications, and visa-versa.
There is a hype now around V+, the new 35MHz VDSL variant. We do acknowledge that V+ has advantages in some cases. There is no debate about that. The question is whether the improvement justifies the investment of a new VDSL variant. The answer for most cases is probably not. V+ has an advantage if you target a ~200Mbps service. G.fast has a clear advantage if you target a service of 300Mbps and higher. Does it make sense to spend so much money (and time) on V+ upgrade where in the end you end up with a technology that can hardly fight your competition even today???
Besides, G.fast is not only about speed. There are many other advantages in G.fast over VDSL that you’ll not be able to benefit from with V+. V+ is a simple extension to VDSL. This is its advantage but also a big disadvantage.
G.fast is not only about speed and bandwidth. There are many other advantages like: flexible up/down allocation, robustness and more.
G.Fast already has all the tools needed to support vectoring in the higher frequencies. When you extend 17a VDSL to 35MHz, the FEXT level is becoming high and you start to encounter the G.fast vectoring challenges. This was already solved in G.fast, but V+ is still using the 17a VDSL assumption that the FEXT level is always quite low relative to the signal. Either V+ will adopt the G.fast tools for the high frequencies, or its performance will be lower than expected.
There is an issue also with complexity. Though G.fast uses a bandwidth which is x3 wider than V+, the amount of memory needed for vectoring V+ (linear with the number of carriers) is 4 times bigger in V+. G.fast 106a uses 2k carriers. 35MHz V+ uses 8k carriers! This is a very big gap. It will be reflected in the unit cost as the vectoring functionality is responsible for a significant part of the cost of a V+/G.fast solution.
We have all the elements in place to support the deployment of an end to end solution.
G.fast is expected to further evolve in the coming years, to cover more use cases with better performance. We have a solid foundation to support the evolution of this technology.