Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [IEEE1904.1] Terminology [was Powersaving adhoc CC #2 info]



Rick hi,

 

On the first CC, there was some discussion along these lines.    For simplicity, it seems that if the powersaving sleep is going to prevent satisfaction of a service guarantee, then the ONU or OLT should ensure that powersaving sleep doesn’t happen (ie. the power is saved primarily during inactive periods, so don’t sleep during a VoIP call).

 

In the terms you use, our focus currently is “in-service sleep” – my view is that it is probably sufficient.

 

Jeff

 

From: Rick Li [mailto:Rick.Li@xxxxxxxxxxxxxxxxxxx]
Sent: Saturday, September 25, 2010 1:45 AM
To: STDS-P1904-1@xxxxxxxxxxxxxxxxx
Subject: Re: [IEEE1904.1] Terminology [was Powersaving adhoc CC #2 info]

 

Duane,

 

In addition to the length of the sleep time  - that tells the ONU ‘how sound and how deep the ONU should be sleeping’, I think it may also make sense to include the type of ‘sleep’:

-          In-service sleep: this type has the objectives of both power saving AND service quality retention

-          Out-of-service sleep: this type has the primary objective to preserve power consumption (long sleep by ignoring certain types of services)

 

If we want to further, we can include a set of services that are to be maintained and another set of services which can be subject to disruption during a particular sleep cycle.

 

This would support something that can be coined as “service aware power saving or service aware sleep cycle”.

 

Best, Rick

 

From: Duane Remein [mailto:dremein@xxxxxxxxx]
Sent: Friday, September 24, 2010 4:31 PM
To: Rick Li
Cc: STDS-P1904-1@xxxxxxxxxxxxxxxxx
Subject: Re: [IEEE1904.1] Terminology [was Powersaving adhoc CC #2 info]

 

All,
In my mind I don't see any fundamental differences between each of the 3 sleep modes (dozing, cyclical sleep and deep sleep) except the length of time the ONU is allowed or chooses to sleep.  Yes there is the potential to consider ONU's with active receivers as "dozing" as opposed to cyclical sleep but this can really be a don't care from the OLT's point of view.  We might even want to consider adopting new terms that don't carry any past biases.  Here would be my suggestions:
Tx-Sleep (transmitter sleep) describes a sleep mode where the ONU ceases to transmit for some period of time even though GATE messages are received and REPORT messages are requested by the OLT.
Xvr-Sleep (transceiver sleep) describes a sleep mode where the ONU ceases to transmit and receive for some period of time.
Best Regards,
Duane



On 9/24/2010 5:50 PM, Rick Li wrote:

Marek, Jeff,

 

I agree we should have clear definition on the terminologies.

 

Please see my comments in line.

 

Best, Rick

 

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Friday, September 24, 2010 1:03 PM
To: STDS-P1904-1@xxxxxxxxxxxxxxxxx
Subject: [IEEE1904.1] Powersaving adhoc CC #2 info

 

Hi Jeff,

 

Is the meeting at midnight sharp or 1 AM ? That 0001 GMT looks weird :P

 

Regarding the topics for discussion:

 

I think we need to define what the terms dozing, cyclic sleep and deep sleep mean for us. Do we use G.sup45 definitions or modify something in here ?

 

I would like to understand as well what the advantage of the MAC Control over OAM channel is for sleep signalling.

Given the configurability of the OAM frame rate (it is not up to the operator to decide how many frames per second are to be generated), I am not sure where the advantages of the MAC Control lie.

 

>>>Rick: my understanding is that MAC control extension may be treated with higher priority than OAM (I am not sure if standard specified the relative priority between MPCP and OAM messages). As such, critical signalling messages such as protection switch and power saving sleep message may use MAC control. However, since OAM message is already specified with high priority, this is probably a moot point.

 

I would personally prefer a single signalling mechanism for power saving signalling (and perhaps also protection switching). eOAM would be the preferred approach since it’s backward compatible with existing hardware.

 

Ideally, the equipment would be able to transport both types of messages, allowing service providers to choose.

 

Additionally, something that is a strong argument against MAC Control, it is not backward compatible with 1G-EPON hardware. Unless we expect to force silicon respin for SIEPON compatible hardware, we should use signalling solutions which are available in legacy equipment and which can be adapted to our needs through firmware upgrade. 10G-EPON is less of a problem but the solutions SIEPON WG produces MUST be by definition, applicable to both 1G-EPON and 10G-EPON. Otherwise we would be going against our own PAR.

That said, I would like to move that we use eOAM as the control channel for power saving mechanism.

I also understand you will be distributing some slides on Monday. Do they address comparison between these solutions or there are other proposals on the table that I am not yet aware of?

 

OLT-initiated versus ONU-initiated sleep:

in my opinion, the ONU in EPON has always been considered a slave device with limited processing capabilities. I would like to see it remain that way. We have an example of alternative specifications which pack many functions onto the ONU leading to both device complexity, added cost and what’s more important – device interop problems.

The fewer the functions on the ONU, the simpler it is to interoperate with the OLT. I am strongly in favour of the OLT driven approach. The ONU is told what to do and not what it feels like doing. OLT is never more than 200 us away from knowing that the ONU is running without any traffic, which should be sufficient to guarantee very reasonable efficiency of the protocol.

 

>>>Rick:

 

We agreed (I think) in the past two sessions that ONU will have a role in participating the decision making if the ONU will sleep or not after receiving the ‘sleep’ command from OLT, regardless the initiation is OLT or ONU. This is because the ONU possesses specific knowledge about its own real-time condition (such as environmental condition like local battery level, main power supply) and upstream traffic status, and IPTV subscriber membership etc.

 

The initiator (this can be OLT central controlled or ONU self-initiated) performs initial eligibility check – note this merely qualifies an ONU to be considered for a particular sleep cycle, but not final decision.

 

The OLT can naturally be the initiator for downstream eligibility checking criteria – then the ONU will perform subsequent local additional check to make final decision.

 

Similarly, the ONU can naturally be the initiator for upstream eligibility checking criteria – then the OLT will perform subsequent additional check to make final decision. One particular example where ONU may serve as the initiator is where an ONU has lost main power supply and fall back to backup battery. Under such condition, the ONU may prefer to enter as many sleep cycles as possible, except when it is handling certain emergency services such as voice. If OLT is the sole initiator, the OLT may rule that the ONU is not eligible for power saving at all since it has significant Internet traffic for example.

 

My point here is that if we want OLT to be the sole initiator for power saving (which I also support), the OLT may need to have the knowledge of additional ONU conditions of all the ONUs on that PON interface – such condition may include, for example, ONU’s upstream traffic status (not yet reported via MPCP report), environment conditions, IGMP memberships (OLT does have this though its snooping/proxy).

 

 

Hope to see some discussion on the reflector (it has been awfully quiet in here recently)

 

>>>Rick: I am contributing.

 

Regards

 

Marek Hajduczenia

 

From: Jeff Mandin [mailto:Jeff_Mandin@xxxxxxxxxxxxxx]
Sent: 24 September 2010 11:07
To: STDS-P1904-1@xxxxxxxxxxxxxxxxx
Subject: Re: [IEEE1904.1] Powersaving adhoc CC #2 info

 

The date was incorrect in the previous announcement.

 

Please see corrected announcement below:

 

 

 

Dear all,

 

The next CC of the powersaving adhoc is scheduled for Wednesday Sept 29, at 0001 GMT (that’s Tuesday Sept 28 in the US)

 

Access Numbers:

 

US/Canada: 800-747-5150

Japan:  00531001555

China: 800-8190299

Israel: 1-809-458705  

Korea:  00308140429  

Portugal: 800-780604

 

 

Meeting code: 8276114

 

Topics for discussion:

 

* Options for control protocol (I will distribute these slides by Monday)

 

* ONU-initiated wakeup (Seiji Kozaki/Ryan Hirth)

 

* Answers to outstanding questions on Deep Sleep (Duane Remein)

 

     - Deep sleep questions included:  Is it just longer sleep times or is there something else required for support?  What is the benefit over deregistering and reregistering?

 

 

 Scheduling:  0000 GMT and 0400 GMT are times which work well for the US West Coast and for Asia.  We will be alternating between these two times.

 

  

 

Thanks and Best Regards,

 

Jeff Mandin

PMC-Sierra