| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Rick, The only problem with keeping
the Rx path on is that this the ONU element that consumes most power,
especially when using APD receivers. I think what Duane proposed was
reasonable. We support both Tx only and TRx sleep modes and it is up to the ONU
to figure out which one it can use. Marek From:
Rick Li [mailto:Rick.Li@xxxxxxxxxxxxxxxxxxx] Duane, For the OLT buffering
requirement, I assume it is needed regardless it’s service aware or
service-unaware. The question is what types of buffering is needed: For synchronized or coordinated sleep where all sleeping
ONUs will enter the same cycle (perhaps at a slight different times) and exit
at the same time (after optics power-on time adjustment), per ONU buffering is
needed as well as broadcast traffic buffering (unless we replicate the
broadcast packets onto unicast LLIDs). For uncoordinated sleep or ONU initiated sleep (I am not
suggesting that this should will be included), I would think per ONU buffering
is also a must while broadcast traffic buffering is not possible –
because it will need to be buffered all the time (for example, the ONUs enter
sleep in staggered fashion) or broadcast traffic is simply discarded (if we can
accept this). Keeping ONU Rx always on would definitely help
‘service aware sleep’. My proposal on ‘service aware’ is to include,
in the sleep OAM, a bitmapped byte to indicate what types of service traffics
are being buffered at OLT in downstream or at ONU in upstream. Such information
can then be taken into the decision making process – though the decision
algorithm is totally out of scope. Best, Rick From:
Duane Remein [mailto:dremein@xxxxxxxxx] Rick, 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] All, 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]
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]
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 |