Marek,
Jeff,
I
agree we should have clear
definition on the terminologies.
Please
see my comments in line.
Best,
Rick
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.
1.
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.
2.
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.
3.
That
said, I would like to move that we use eOAM as the control
channel for power
saving mechanism.
4.
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:
1.
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.
2.
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
The
date was incorrect in the
previous announcement.
Please
see corrected
announcement below:
Dear all,
1.
The next CC of the powersaving
adhoc is scheduled for
Wednesday Sept 29,
at 0001 GMT (that’s
Tuesday Sept 28
in the US)
2.
Access Numbers:
US/Canada:
800-747-5150
Japan:
00531001555
China:
800-8190299
Israel: 1-809-458705
Korea: 00308140429
Portugal: 800-780604
Meeting
code: 8276114
3. 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?
4. 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