Re: [802.3_EPOC] Why multiple simultaneous MCS
Ron,
Sure, I'll indulge youŠ
Should is meant to indicate this is my opinion, not to indicate spec
language. Put another way, based on the current available information, I
believe that we should include a requirement in EPoC to support different
devices operating with different modulation and coding over the same set
of OFDM sub-carriers.
That said, until we work out the details (both of how it would work and
what the implications for EPoC would be) we cannot say for certain that
the gains outweigh the negatives, and so I am not proposing trying to push
this into the Baseline Proposal as of yet. But we should definitely
continue to look at and consider the possibility of including it, and when
a more complete proposal is available, we should carefully consider it.
Make sense?
Thanks.
Matt
On 10/9/12 11:17 PM, "Ron Wolfe" <rwolfe@xxxxxxxxxx> wrote:
>Matt,
>
>A brief clarification if you will indulge me ... When you say "an
>advanced next generation HSD system for HFC (such as EPoC) should include
>the ability to support multiple simultaneous Modulation and Coding
>Schemes (MCS)." do you use the word "should" in the context of "may,
>should, shall" as might be found in a specification, or are you implying
>that it should be a requirement? I'm not arguing for or against a
>"quarantine" mechanism here, just wanting us all to be on the same page
>as to whether it would be proposed as a "should" or a "shall.". Obviously
>if one end of the link supports a quarantine protocol and the other does
>not, even a single element, the entire mechanism could be rendered less
>effective or ineffective. In other words, this probably should be
>included or not included as a "shall support" feature??
>
>Thanks,
>Ron
>
>Ron Wolfe
>Sr. Director
>Global Product Strategy
>Aurora Networks, Inc.
>+1-650-218-0835 mobile
>+1-720-542-3704 Denver office
>RWolfe@xxxxxxxxxx<mailto:RWolfe@xxxxxxxxxx>
>
>On Oct 9, 2012, at 8:26 PM, "Matthew Schmitt"
><m.schmitt@xxxxxxxxxxxxx<mailto:m.schmitt@xxxxxxxxxxxxx>> wrote:
>
>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
>
>________________________________
________________________________________________________________________
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