Re: [802.3_EPOC] Why multiple simultaneous MCS
Duane,
I completely agree. I'd call these operational/administrative, but the
protocol layers above the PHY do not need to know them in order for the
operator to know them. All that is required is a mechanism to collect this
information and send it north. Could be EOAM from the CLT to the OLT or IP
at the CLT, etc.
I'm not sure I follow your second paragraph about channel data rate. Let's
say there is a change (call it autonomous in the PHY) does it matter that
there is a delay ? Perhaps a better way to ask, is how real-time does the
bandwidth have to be known. I think we can agree, not as often as cellular,
but obviously far more often then just "link up". So the question is what is
the time scale of adapting to changes (a) in the phy and (b) providing that
to the scheduler. (I'm just asking, not answering.). Is that what you are
saying/asking as well ?
-Victor
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Thursday, October 11, 2012 8:45 PM
To: Victor Blake; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Cc: Duane Remein
Subject: RE: [802.3_EPOC] Why multiple simultaneous MCS
Victor,
I assume here you're talking about absolute need as in absolute need in a
real time fashion. I would expect an operator would want to have the ability
to see at which sub-channels are operating well and which are not. We will
also need to allow operators to restrict the use of some sub-channels. I
believe someone mentioned the FCC being involved in prohibiting use of
certain frequencies in this or another thread.
I agree with you that the real time information needed by the upper layers
is indeed a very limited set. But the timing of that information transfer is
crucial to proper operation. If an upper layer scheduler finds out that the
channel data rate to a given LLID increased some time ago, that is fine. If
on the other hand it finds out that an LLIDs data rate decreased 50 ms ago
that may be a very different matter. This is one of the reasons I cringe
when some says that the PHY can act autonomously in setting up the channels.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
From: Victor Blake [mailto:victorblake@xxxxxxxxxxxxxxx]
Sent: Thursday, October 11, 2012 7:41 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Why multiple simultaneous MCS
Matt,
OK, yes I guess I did mistakenly (my mistake) have that impression. So I
think one thing to reasonably ask is, for whatever happens below the MAC,
what of that information has to be elevated above the MAC, not in protocol
operations, but administratively. For example, if, after the physical layers
are "linked up" (I'd call that the physical link layer) and the MAC is
running, we have DSx/USy Mbps available, how do we convey that northbound to
be used for management/operations. Obviously the CLT can have some
mechanisms (as an IP addressable or by proxy from the OLT - I'm not sure) to
be queried for or to push that information. But the real question might be,
before forwarding begins, what does MPCP at the OLT ABSOLUSTELY NEED to know
? I understand it needs to know data rates. It isn't clear to me that it
needs to know anything else at all other than the data rates available.
Not responding to you Matt, but in the previous discussion .
On multicast, I think we can make (by decision) all of our lives easy, but
making an assumption, and sticking to it, that multicast is broadcast on the
entire EPON and passively forwarded through all CLT. I don't see how
anything that happens in terms of that phy setup would prevent that from
implicitly working. Again, if CLT is not a bridge (MAC transparent) and
certainly isn't a router or better stated - not a multicast node, then
everything broadcast on the EPON MUST be forwarded past the CLT. So I'm not
sure I following what the questions/discussion is around multicast/video
with EPoC other than, forward all broadcast/multicast as MUST.
-Victor
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Thursday, October 11, 2012 5:25 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Why multiple simultaneous MCS
Victor,
I agree that doing things above the MAC is outside the charter, so I
definitely wasn't implying that we should go that road (and I hope no one
got that impression). The MAC Control Sub-layer is definitely in scope to
modify if needed to support EPoC, although we want to minimize what we touch
there, and ideally to do so in such a way as to not break or cause problems
with EPON devices.
Thanks.
Matt
From: Victor Blake <victorblake@xxxxxxxxxxxxxxx>
Date: Thursday, October 11, 2012 1:38 PM
To: Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx>,
"STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [802.3_EPOC] Why multiple simultaneous MCS
Matt,
Can I ask, instead of pondering why we might do this or that above the EPON
MAC, why not just decide - consistent with the project charter, that we are
not going to touch (other than management) anything above the MAC and then
focus on solving the problems below the MAC ? All of these problems can in
fact be solved below the MAC. It isn't really a matter of whether it is
possible, just whether we spend time doing it or time exploring changing the
MAC which defeats the point of EPOC.
It's not that I disagree that we couldn't use higher layers to do certain
functions, it's that doing so breaks with the PAR and will lead to a dead
end without the goals being achieved.
-Victor
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Thursday, October 11, 2012 3:13 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Why multiple simultaneous MCS
Eugene,
One thing I wonder about is just how much we're going to have to modify the
EPoC system relative to EPON, regardless of this particular potential
feature. That could result in a somewhat different answer regarding how
much of a change this would take. I think the choice of how to implement it
can significant impact how much of a change as well (such as where decisions
are made in the stack). Which is why I agreed to (more or less) let go of
the argument for now, pending a more concrete proposal that can undergo more
thorough analysis. :-)
Thanks.
Matt
From: <Dai>, "Eugene (CCI-Atlanta)" <Eugene.Dai@xxxxxxx>
Date: Thursday, October 11, 2012 12:07 PM
To: Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx>,
"STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [802.3_EPOC] Why multiple simultaneous MCS
Matt: This is how D3.1 supposed to work; but not without significant change
in EPON system.
Eugene Dai PhD
Principle Transport Architect
COX Communications
Tel: 404-269-8014
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Thursday, October 11, 2012 11:55 AM
To: Dai, Eugene (CCI-Atlanta); STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Why multiple simultaneous MCS
Eugene,
Alternately, you could send the multicast (and MPCP messages) on a profile
that everyone listens to and is set to the lowest common denominator.
Thanks.
Matt
From: <Dai>, "Eugene (CCI-Atlanta)" <Eugene.Dai@xxxxxxx>
Reply-To: "Dai, Eugene (CCI-Atlanta)" <Eugene.Dai@xxxxxxx>
Date: Thursday, October 11, 2012 9:45 AM
To: "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Why multiple simultaneous MCS
Hi Victor: We haven't met, but I know your name from DPOE.
Your comments on how EPON handle multicast video are absolutely correct; but
that is also exactly the problem for multi MCS profiles for EPOC PHY. The
multiple MCS PHY profiles are essentially creating multiple small pipes
inside what you referred as "big data pipe" at PHY layer. As we know that
EPON DS is broadcast in nature, it is very efficient in handling multicast
video as you described. With this multiple PHY profiles we have duplicate
each broadcast and multicast streams to each of the small pipes, including
EPON MAC messages.
Eugene Dai PhD
Principle Transport Architect
COX Communications
Tel: 404-269-8014
From: Victor Blake [mailto:victorblake@xxxxxxxxxxxxxxx]
Sent: Thursday, October 11, 2012 11:26 AM
To: Dai, Eugene (CCI-Atlanta); STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] Why multiple simultaneous MCS
Hi Eugene,
I don't think we've met, but I've been following your comments with
interest.
I don't see the relationship to "multicast video." Unlike HFC today, the
goal is not to FDM video and data, it's one big fat data pipe which is
bandwidth managed by IP and Ethernet. Not that it's at all related to EPoC
(because I don't think it is), but one strict fix for that is simply an LLID
for video. That would all happen above the PHY without respect to other than
the obvious fact that one cannot administrative configure an LLID to support
more bandwidth than the PHY supports and that obviously one must do
calculations (either in engineering or admistratively on the box - again
without reference to the protocol) as to how to share the shared bandwidth
(aka configuration management).
Victor R. Blake
Independent Consultant
victorblake@xxxxxxxxxxxxxxx
http://www.victorblake.com <http://www.victorblake.com/>
http://twitter.com/victorblake
540-338-1076
From: Dai, Eugene (CCI-Atlanta) [mailto:Eugene.Dai@xxxxxxx]
Sent: Thursday, October 11, 2012 10:38 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Why multiple simultaneous MCS
Duane: I suggest that we consider some realistic examples, instead of this
kind of wild argument. All DOCSIS CM support 256QAM today, some may support
1024 QAM in the future. Assuming ~100MHz DS bandwidth allocation for EPOC,
with 1024 QAM we get 1 Gbps raw bandwidth, with 256 QAM the raw bandwidth
will be 800 Mbps. Where is 250Mbps in your example come from?
We can make MAC to aware PHY or more preciously PHY rate, but what price we
have to pay? The impacts are not limited at PHY layer; it will propagate to
system level, for example how to deal with multicast video? Unnecessarily
duplicate multicast video streams to different PHY profiles could consume
more bandwidth than possible gain. Backward compatibility is another
concern.
The ultimate goal is to improve outside plant condition to accommodate a
reasonably higher modulation orders.
Eugene Dai PhD
Principle Transport Architect
COX Communications
Tel: 404-269-8014
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Wednesday, October 10, 2012 9:51 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Why multiple simultaneous MCS
Marek,
A simple example.
An EPoC network with 10 CNUs, 9 can operate at 1G, 1 can only attain 250M
With 2 MCS profiles you can attain an average instantaneous network data
rate of 950 Mbps or 95 Mbps per user.
With LCD you can only attain an average instantaneous network data rate of
250 Mps or 25 Mbps per user.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Wednesday, October 10, 2012 6:20 PM
To: Duane Remein; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] Why multiple simultaneous MCS
Duane,
Could you please kindly point to me to any study which shows that
"significantly lower" bandwidth ? I failed to find any such contribution
submitted to EPoC TF / SG. Perhaps I missed something along the way.
Marek
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Wednesday, October 10, 2012 16:23
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Why multiple simultaneous MCS
Matt,
I suspect another argument for multiple profiles is that you can offer a
higher level of service. Like it or not, networks are assessed based on the
average sustained data rate that can be delivered to a customer. With a
lowest common denominator approach this would be significantly lower.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Tuesday, October 09, 2012 11:25 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: [802.3_EPOC] Why multiple simultaneous MCS
Based on some of the discussions, I think it might be worthwhile to spend a
moment going into the chain of reasoning that led myself (and others) to the
conclusion that an advanced next generation HSD system for HFC (such as
EPoC) should include the ability to support multiple simultaneous Modulation
and Coding Schemes (MCS).
If I were to sum it up in 2 words (okay, technically 4), it would be this:
SNR Headroom.
In a system that requires all end stations to operate with the same MCS (and
to receive all downstream transmissions), the great danger is that for
whatever reason the SNR to a given end station will change sufficiently that
it will drop offline. That simply cannot be allowed to happen. As a
result, operators are required to maintain a significant amount of "SNR
Headroom" when they setup and deploy an end station. Common practice is to
allow on order of 8 db of SNR headroom when deploying a modem (some a little
more, but I'm not aware of any that do less).
What this means is the following. Let's say that you needed 25 dB of SNR to
operate 1024 QAM with a 3/4 LDPC FEC code (which I believe is the case with
DVB-C2, and serves as a useful reference point here). An MSO would not
actually use that MCS unless they could get their end stations at 33 dB of
SNR (25+8) when deploying them. If they couldn't get to that level when
deploying the end station, they wouldn't be able to use that MCS.
I pulled out that particular number because, based on the SNR distributions
that were shared previously, even if you assumed you could "bring up" the
bottom 2.1% of modems, that's the best you could expect to do. And even if
you could further improve SNR, you're still always going to be operating in
effect 8 dB below what you could theoretically do. For example, just to get
to 4096 QAM with a 5/6 LDPC FEC, you'd need to get every single end station
to operate at about 40dB or higher of SNR.
Now, if you could get away from requiring that 8 dB of headroom, it would be
huge, considering that 6 dB is an order of modulation with the same FEC, an
increase of 2 bits per symbol.
One way to achieve that end is to support multiple MCSs, but only one at a
time, which is set based on the "lowest common denominator". In this
approach, if an end station were to have a sudden drop in SNR, then the
system would need to drop to a lower "lowest common denominator", until such
time as the problem could be addressed. By having that fall back, you could
in theory operate closer to the theoretical maximum and reduce the amount of
headroom required.
However, there are some issues here. First, one bad end station coming onto
the network - or a single problem in a single household - would affect the
entire network, degrading the service of every single end station. Second,
particularly in the scenario where an end station encounters a problem after
it's already online, there's no guarantee that it would even still be able
to communicate that it was having a problem and that it needed the MCS to be
changed. That risk is then going to force you to leave more headroom,
mitigating any potential gains.
The only approach that we've come up with so far that allows you to
significantly reduce that headroom and operate close to theoretical levels -
while not adversely affecting the entire system when there's a problem - is
to create a system in which a single end station is able to fall back to a
more robust MCS if it encounters a problem. In that way, only the single
device having an issue is affected, and unless the problem is truly
catastrophic you can reliably keep the mode online (meaning that you have an
opportunity to fix the problem while the customer remains online and
operational).
We could argue back and forth for quite a while about SNR spreads on the
network, how much variation there will be between end stations in a given
service group, etc. And the ability to operate each device to its maximum
potential is very appealing to be sure. But what really makes this
decision, in my opinion, is the SNR headroom issue, and in particular the
ability to significantly reduce it while actually improving robustness and
the ability to keep customers on line.
Thanks.
Matt
_____
<="" p="">
_____
<="" p="">
_____
<="" p="">
_____
_____
<="" p="">
_____
_____
_____
<="" p="">
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1