Re: [IEEE1904.1] Powersaving Ad Hoc - Sleep Protocol
Jeff,
"... However the OLT does nothing if the REPORT is not received ..." - I
disagree with that statement. The OLT behaviour in this case is not defined
and it would be the scope of the word of this ad hoc to actually put this
behaviour in place in the case of regular transmission (OLT expects a REPORT
every 50ms) and in the case of sleep cycle for the given ONU (OLT may expect
a REPORT but without any requirements in terms of regularity)
Effectively, what we need to specify is the behaviour of the MAC Control and
MAC Client ... simple task. We have done it already in C64 and C77 in 802.3
Regards
Marek
-----Original Message-----
From: Jeff Mandin [mailto:Jeff_Mandin@xxxxxxxxxxxxxx]
Sent: 26 September 2010 09:58
To: STDS-P1904-1@xxxxxxxxxxxxxxxxx
Subject: Re: [IEEE1904.1] Powersaving Ad Hoc - Sleep Protocol
Duane,
Thanks for the excerpts from 802.3 text on timers. It appears that
these timers can accommodate the powersaving scheme ... ie.
1. mpcp_timeout: it is necessary for the OLT to receive an MPCP message
from the ONU at least once per second in order to maintain registration.
So for "deep sleep" there is an issue as you say, and for the other
modes there shouldn't be any problem.
2. gate_timeout: The OLT generates a (possibly empty) GATE for a
particular ONU at least once per 50 ms. This poses no particular
problem.
3. report_timeout: The ONU is supposed to generate a REPORT at least
once per 50 ms. However the OLT does nothing if the REPORT is not
received. When the ONU is sleeping, the PHY is in a management state
that is not transmitting so the MPCP layer can be regarded as compliant.
Jeff
-----Original Message-----
From: Duane Remein [mailto:dremein@xxxxxxxxx]
Sent: Saturday, September 25, 2010 1:38 AM
To: STDS-P1904-1@xxxxxxxxxxxxxxxxx
Subject: Re: [IEEE1904.1] Powersaving Ad Hoc - Sleep Protocol
All,
I would like to suggest that we strive for as simple a sleep protocol as
possible, this strategy has always served Ethernet well in the past.
With this in mind I would like to propose that we only allow the OLT to
be the sleep cycle initiator (this is required for "synchronized" sleep
anyway). We should encourage (require?) the OLT to initiate the sleep
cycle(s) often and with liberality. By this I mean the OLT should not
presume upon the ONUs desire to stay awake, even if the OLT believes the
ONU will be receiving data in the near future. The real decision to
Sleep or not to Sleep should belong to the ONU. In essence I suggest
that the OLT send the ONU a "hall pass" to sleep and the ONU decides if
it wants to sleep or not. It would be very simple to include a field
in the sleep invite to inform the ONU of impending DS data so the ONU
could take that into account.
Making this overly complicated will do nothing to keep costs down, which
is always an issue for any access technology.
Bye the way I had an action item to investigate various timers in the
MPCP which might have relevance to sleep. I've only found four, see the
attached MS Word doc for a quick summary with xref. to 802.3. Basically
there are three 50 ms timers and one 1 sec timer. Two of these are
defined as constants but I think it would be very simple to ask 802 to
redefine them as variables with default times set to 50 ms or 1 sec as
appropriate. I don't believe this would impact any state diagrams in
the 802.3 spec.
Best Regards,
Duane