Sckipio G.fast Presentation at TNO Ultrafast Broadband 2015
•Als PPTX, PDF herunterladen•
1 gefällt mir•3,219 views
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.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (9)
Ähnlich wie Sckipio G.fast Presentation at TNO Ultrafast Broadband 2015
Ähnlich wie Sckipio G.fast Presentation at TNO Ultrafast Broadband 2015 (20)
Mehr von Sckipio
Mehr von Sckipio (8)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Sckipio G.fast Presentation at TNO Ultrafast Broadband 2015
- 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
- 18. 28-Aug-15Sckipio | Ultra-Fast BB seminar, June 201518 What’s next with G.fast G.fast technology going forward
- 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
- 24. Thank You
Hinweis der Redaktion
- Sckipio…
- 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.