Re: [8023-10GEPON] Slides for joint session with EEE
Guys,
I agree with Marek, but I wanted to chime in another direction on this subject. Maybe I am looking at this wrong-headed, but I welcome your feedback.
I agree that power savings will be useful. However, my opinion is that after considering the significant discussions that would need to take place to integrate power saving into 10G EPON, maybe we should not slow down the .3av. Would we be better moving forward with .3av and working with .3az after that?
---------------------
Also, I want to make sure that we undertake the discussions on power savings with a broader vision. It seems to me that some considerations are not being discussed.
1. ONU vs. ONT services
2. power supply efficiency
1. ONU vs. ONT Services
I know that from the IEEE perspective, we are only considering the ONU. As a system designer though, I must look beyond that. Many ONT system houses offer ONTs not just ONUs, where for this message I will distinguish ONTs as having traditional services ports like POTS and RF, as well as multiple data ports for IP video and Internet access; and, the ONU is just a single data port. As it turns out, my company sells 99% ONTs. I know that several companies will sell 99% ONUs. Your mileage may vary.
I clearly understand the power saving case for ONU, though my opinion of its significance apparently differs from the operators. I suppose saving 3 W per ONU adds up over millions of subscribers, but it seems to me that turning off a bunch of 100 W light bulbs and more efficient transportation counts for much more.
So, I want to better understand the ONT case. If we assume maximum power consumption:
ONU (1 port-Ethernet) consumes 5 W or less
ONT (triple-play) consumes 15W or less
ONT8 (8-unit MDU triple-play) consumes 40 W or less
And sales:
ONU sales < 10%
ONT sales > 80%
ONT8 sales < 10%
What then is our true power savings opportunity?
If your ONT is delivering RF services, it seems to me that the ONT does not know when Grandma is watching broadcast video. Perhaps if she has an RF settop, you'll get a channel change to process (assuming the ONT can convert the RF return to a data frame), but otherwise, I think the power-hungry RF video amplifier needs to be active at all times. Further, I am unaware of any triplexors that have a power-saving mode to delete just the RF.
If your ONT is delivering POTS services, I think that generally you've got to keep a significant portion of power-hungry circuitry running in case Grandma wants to make a call. Is anyone aware of POTS circuitry with a power saving mode?
I have similar concerns about the Ethernet switch function necessary for multiple data ports.
As for MDUs, your savings opportunity is even less. Statistically, services are probably more likely to be used across eight subscribers than one. MDUs are built on economy of scale. Typically you don't have a circuit you can turn off just for a single subscriber.
So, all in all, I am thinking that we probably cannot realistically turn off an ONT. (Perhaps we can turn off an ONU, but as written by Marek and others, there are considerations)
2. Power Supply Efficiency
I understand that many consumer grade power supplies are not particularly efficient, and the potential savings with them greatly exceeds the 3-5 W we might save on an ONU. Further, most do not have a power-saving mode input, where the ONT could induce the supply to sleep.
Best Regards,
Alan
-----Original Message-----
From: Hajduczenia, Marek (NSN - PT/Portugal - MiniMD) [mailto:marek.hajduczenia@xxxxxxx]
Sent: Tuesday, July 08, 2008 4:56 AM
To: STDS-802-3-10GEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [8023-10GEPON] Slides for joint session with EEE
Hi Jeff,
Thank You for the updated presentation. It looks much better. I saw You added also some new material.
About the issues You raise in the email, I am pretty well aware of the carrier requirements regarding power saving. The quoted material is not the first one where such requirements appear but I still have not seen any particular numbers regarding estimated savings (% of total current consumption, tons of CO2, whatever the units) if power saving mode was a reality. For now, we operate in the world of assumptions and bear with me, but not everything that works nice on paper, work as fine when implemented. I am NOT against the power saving, which I also believe is the way to go forward with access networks, but the changes need to be introduced in an organized manner, which we should take special care of.
Before jumping into adding new features to our system, we need to examine in our Task Force what the extent of the indicated problem at hand really is and what can be done to alleviate the burden to both carriers and subscribers in terms of power consumption. I guess what I would really like to understand is as follows:
- how much power does a typical ONU really consumes (I have seen figures ranging anywhere between 3 and 30 Watts, depending on the configuration and used components)
- how much power can be saved i.e. the ONU must be switched on and off periodically in the proposed solution, indicating some duty cycle. If You have an ONU with 10 W power consumption, 20% duty cycle, Your power saving is roughly 80%. The real question is what duty cycle we can achieve without causing operational problems ... This is also considered in the 802.3az proposal, where two operating modes are proposed i.e. "reduced energy" and "lowest energy". I would like us to define what would those be for our system before we enter the process of making specifications about it.
- the effect of the power down on ONU synchronization, especially at the MPCP layer, which is more critical for proper operation of the upstream channel. I would hate to see ONUs having to be reranged after each of such power down cycles. I am sure we can come up with a more solid answer to this problem than just taking it on faith that it works and no resync is needed for MPCP.
- the EEE mechanism for 10G-EPON i.e. whether it would be an extension to MPCP (any other options) and whether it is mandatory or optional. Probably a bidirectional negotiation would be needed (to make sure the OLT knows the ONU accepted the power down state), which introduces additional functionalities, state machines as well as provides some interoperability issues, which need to be discussed, before we commit to have it included in the spec
- any additional complications for the operation of the scheduling mechanism for MPCP client. Now the upstream transmission windows will not only have to scheduled in a non-overlapping manner but also observe the inactivity periods for individual subscriber stations. The process will become slightly more complicated, especially in the light of the operation of watchdog timers in the ONUs and the OLT - it just becomes more complex to run the show and make sure an ONU is not deregistered when asleep ...
- the wake-up conditions, if frames start arriving at the subscriber ports: I doubt You can wake up the system fast enough to store frames incoming on the subscriber port if the whole ONU is in the sleep mode. This means that at least part of the electronics cannot go to sleep on the subscriber side, unless the port is not connected at all or inactive. This puts some further limitations on how much power You can really save. If You have to keep the subscriber ports up and Your POTS powered, You still spend a better share of the total power consumption. Powering down central board and related electronics will shave off 10-15%. If we could switch off everything, it would be a different story but subscriber packet loss seems to be a potential threat in here ..
These are some of the issues that come to my mind off at the moment. Most likely there are some more, please feel free to jump in and let me know if I missed anything.
In summary: I understand the requirements, their aggressiveness and the drivers, but before we commit to supporting such functions, we need to understand what we are up against, whether we really save that much and what the added cost of the solution is i.e. how many % of power consumption we can save versus % of the cost increase because of additional functionalities of the system. When I see a value in favour of adding such functions, I am onboard. But I do not work on faith and belief. I want to see us discuss the topic in more detail and actually have something to build upon.
I agree with You that we need to understand this topic as soon as possible but let's hold on with producing specification until we fully understand the impact on the system operation.
That said, I will try to submit 1-3 slides with some major topics to be addressed and considered during the joint meeting with 802.3az. It should also be taken into consideration in our TF, if possible.
Regards
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: quinta-feira, 3 de Julho de 2008 13:14
To: Hajduczenia, Marek (NSN - PT/Portugal - MiniMD); STDS-802-3-10GEPON@xxxxxxxxxxxxxxxxx
Subject: 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