Re: [8023-10GEPON] Slides for joint session with EEE
Marek hi,
Thanks for your response. I'll be sending out a revised set of slides that includes many of your editorial suggestions and also some clarifications based on your comments.
I would like to refer to some of the major points you raise in your email...
Regarding your "need & benefit" issue ie. whether the possible powersavings in the ONU - using Low Power Idle - is significant:
Operators have been looking at the power saving for the access and their unequivocal answer is that powersaving is beneficial to them. We should be open and responsive to their needs. Even in the joint IEEE/ITU session you were quoting from, there was a strong support from the operators for powersaving. See the following presentations:
- http://www.itu.int/dms_pub/itu-t/oth/06/13/T06130000100002PDFE.pdf
- http://www.itu.int/dms_pub/itu-t/oth/06/13/T06130000100003PDFE.pdf
- http://www.itu.int/dms_pub/itu-t/oth/06/13/T06130000200001PDFE.pdf
- Note that operators specifically call out power savings during ONU idle time and "maximizing" power savings.
- Note that a major operator listed additional ONU powersaving as one of 3 top priorities for the next generation of PON access
- Consequently: for the EPON standard to pursue this direction is simply a matter of responding to the market!!
Please note that powersaving is part of a broader plan in which the operators are committed and led by governmental programs to reach aggressive targets. ITU-T SG15 has formed a group to handle it: http://www.itu.int/ITU-T/studygroups/com15/tutorials/power.html.
In addition to that, the FSAN NGOA plans include powersaving, G984.4 includes "power shedding". As well, an optional appendix for G984.3 is currently being discussed in SG15/Q2.
We can't just count on improvement in technologies because our needs and feature list also increase over time. So even if we do use the numbers you estimate, which are very aggressive for normal operation (ie. "below 2 watt" consumption) the consumption for a 10G ONU will be a lot more than 1G and new features will increase the power requirements further. Only a dedicated mode which mutes unneeded functionality can answer these specific requirements.
Requirements are aggressive. For instance, less than one watt per inactive device seems to be the target of many governments ( http://www.iea.org/textbase/papers/2005/standby_fact.pdf ).
Total household consumption is just one part of the picture: different household items are handled in different corporate sectors and different standards bodies are concerned with their improvement. I think that the appropriate way to look at ONU power is by analyzing the proportion consumed by the ONU equipment as a percent of the consumption of the access network - ie. a significant portion.
I believe our target should be to understand and respond to the power requirements of the industry. There is a technical solution we need to tailor to EPON, and I am sure that the TF can take the steps to accomplish this. I would address your technical points in that context:
1. Maintaining the clock during Tx and Rx sleep
I believe that both the Rx and Tx can go to sleep completely. When the Rx wakes up from its sleep it should fully resynchronize on the clock and on the downstream data (ie. AGC, CDR, and codeword), and on the MPCP timestamp, before resuming activity. In this way the ONU will be correctly synchronized
Please note also that the Tx of the ONU is currently not turned off completely. The laser itself as well as the other upstream components are still being powered. There is no guarantee of idle time and the ONU should be ready for transmission within 1024TQs - so an ONU could not power down those components for the brief period where no upstream traffic is guaranteed between bursts. Sleep mode enables all those components to shut off.
2. Scope/Optionality/Cost
The existence of 802.3az demonstrates that the "one problem, one solution" principle is certainly not a reason to avoid this work ... after all it's "different" power being saved (ie. active vs. idle).
Powersaving functionality must of course be optional, and there must be full interoperability between powersaving and non-powersaving devices. This will be stated explicitly in the slides.
I don't see any significant cost impact of the current concept of powersaving and it could probably become negligible in the long run with proper definition.
Once again I appreciate your comments and will distribute the revised slides soon. Additional feedback is of course appreciated.
BRs,
- Jeff Mandin
-----Original Message-----
From: Hajduczenia, Marek (NSN - PT/Portugal - MiniMD) [mailto:marek.hajduczenia@xxxxxxx]
Sent: Tuesday, July 01, 2008 11:24 AM
To: STDS-802-3-10GEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [8023-10GEPON] Slides for joint session with EEE
Importance: High
Hi Jeff,
Thank You for putting this presentation together. It is a good beginning for a longer discussion on this topic both in our TF as well as in 802.3az.
I have some generic editorial comments against the presentation. Discussion of individual points is presented a little bit further.
Here are the editorial comments:
Slide 2:
"ethernet" > "Ethernet". It is common to capitalize this word.
"MACs to be associated" > "MACs associated" - simpler, cleaner Slide 3:
"PCS based on 1000-BASEX (coding is 8b/10b)" > "PCS based on 1000BASE-X (with 8b/10b line coding)", 1000-BASEX does not exist "ONU upstream transmission operates in burst mode" > "ONUs transmit in upstream in burst mode" - cleaner "MAC control extensions for coordination of ONU's network entry and TDM" > "Extensions to MAC Control functions to manage TDMA in upstream channel and ONU network presence" (MPCP)" -> original sentence was confusing "64B/66B" > "64b/66b" - be consistent with what You use ...
Slide 4:
"when every home has one the energy requirements are enormous" > "every house is equipped with an ONU and resulting power consumption is enormous"
Slide 5:
"approach has attraction" > "is attractive"
"high level of powersavings" > "high level of power saving"
"to the multipoint topology" > "for multipoint topology"
"ONU wakes up at its appointed time" > "ONU wakes up at predefined time"
Please note that the opinions presented below are mine and mine only and they have nothing to do with my official function in this group as assistant editor. Here are some comments on the contents and issues arising from the proposal (also playing a little bit on the devil's advocate side here):
As much as I agree with the need for power saving in all aspects of our lives, I believe we are looking for savings where they are or may be minor. First of all, note that many of the ONUs were deployed not in the FTTH but rather MDU like scenarios, where a single ONU serves a number of customers, thus doing immediately away with any claims for high per subscriber power consumption. A good share of the deployed devices have power consumption below 5 W when fully loaded and below 2 W when not transmitting and only sitting idle. Multi port devices may indeed reach a few Watts more, mainly due to the larger silicon which is incorporated within for handling data streams from individual ports. That said, I do not believe that an EPON ONU has anything to power save on, let alone when compared with a DSL modem which pumps 25 W (at least mine does and has green Energy star on it ... ).
Next, in terms of technical issues ... Putting a device to sleep is a very nice concept and I agree with many of the underlying assumptions. However, the device cannot be put completely to sleep mainly because of the need to maintain the ONU clock running - otherwise an ONU leaving the sleep mode would be out of sync with the OLT and confuse the time stamps transmitted in the GATEs. If the synchronization in the downstream is necessary, You do need to keep the Rx running - ONU oscillators are not high quality enough to assure zero drift for a longer period of time. We would need to see what the quality of commonly used oscillators and how long they can be operated without sync with downstream channel recovered clock. While Rx can be put to sleep, note that the Tx does not operate continuously (burst mode after all) so it is already in the power saving mode i.e. it is switched on only when necessary. Check also http://www.itu.int/dms_pub/itu-t/oth/06/13/T06130000400001PDFE.pd!
f for some examples of how much You can really save per average household. Seems to me it is easier to simply change the light bulbs from incandescent ones to fluorescent ones to have several times higher power saving than actually putting Your ONU to sleep. Switching off a digital clock in Your bedroom when not at home saves more. Just a straightforward observation.
Next topic - availability of power savings options in other standards. I am confused. Which other PON standards have such options included ? I am not aware of any such features in G.984 series and this is probably what You refer to. 802.3ah did not have anything in the standard included. Neither did BPON and APON. So what is referred to ? If You aim at the FSAN NGOA and their plans to include power saving options, it needs to be stated clearly. Otherwise, it is just introducing generic and misleading information.
All in all, I am not sure we should paint the picture in much darker colours than it really is. More power saving can be achieved by migrating ONU silicon from discrete components to SoC than switching it off between bursts. Using lower CMOS production node also helps a lot to reduce power consumption (check out what happened in the last transmission from 65 nm to 45 nm node for PC CPUs). Finally, hibernating Your PC when not working for more than 5 minutes saves significant amount of power (a modern PC easily consumes 300 W or more, check out e.g. http://www.hothardware.com/Articles/AMD_Phenom_X4_9350e_and_9950_BE_Debut/?page=8).
In other words Jeff, a nice add-on if it comes at zero cost and can be optional. I do not see the reason why it should be part of the standard and obligate all vendors around the world to comply with this requirement. A power saving functionality is easily achievable using the existing MPCP framework with the proper DBA client programming, so proposal of a dedicated solution might be a breach in the "one problem - one solution" rule we strive to abide ...
That would be more or less all for now.
Any comments, let me know. Remember that I am playing devil's advocate here
Marek Hajduczenia (141238)
NOKIA SIEMENS Networks S.A.
System Architect - COO BBA DSLAM R&D
Rua Irmãos Siemens, 1, Ed. 1, Piso 1
Alfragide, 2720-093 Amadora, Portugal
* marek.hajduczenia@xxxxxxx
(+351.21.416.7472 4+351.21.424.2337
-----Original Message-----
From: ext Jeff Mandin [mailto:Jeff_Mandin@xxxxxxxxxxxxxx]
Sent: domingo, 29 de Junho de 2008 21:51
To: STDS-802-3-10GEPON@xxxxxxxxxxxxxxxxx
Subject: [8023-10GEPON] Slides for joint session with EEE
Hello All,
At the Thursday PM session in Munich there was discussion on planning for the 10GEPON joint session with the EEE group. At that time I was asked to prepare some slides summarizing the interest of the TF in the
EEE activity so far. A draft of these is attached and comments are
appreciated.
Thanks,
- Jeff Mandin
PMC-Sierra