Re: [802.3_EPOC] Why multiple simultaneous MCS
George Hart of Rogers Communications is having trouble sending messages to the reflector (he can send but not receive — we think it's an issue with how his company email is setup), and as such asked me to forward the following on his behalf.
----------------
There was a good level of consensus achieved during the Study Group phase when Objective 4 was adopted in May. The text of that objective is reproduced here:
Provide a physical layer specification that is capable of:
– A baseline data rate of 1 Gb/s at the MAC/PLS service interface when transmitting in 120 MHz, or less, of assigned spectrum under defined baseline plant conditions;
– A data rate lower than the baseline data rate when transmitting in less than 120 MHz of assigned spectrum or under poorer than defined plant conditions;
– A data rate higher than the 1Gb/s baseline data rate and up to 10 Gb/s when transmitting in assigned spectrum and in channel conditions that permit.
So the requirement of 802.3bn to adapt to available plant conditions seems quite clear and not subject to further discussion, either now or later. The task is now to determine a means for achieving this objective while minimizing any changes to the MPCP and or OAM layers per Objective 2.
A fundamental component of the 802.3bn standard is a mechanism for mating a 10Gbps EPON MAC with a variable EPOC data rate generally less than 10Gbps as part of fulfilling Objective 4. This mechanism must accommodate changes in the EPOC data rate. The question at the core of this thread might then be stated as how quickly can this change occur? Defining a set of simultaneous MCS is one way to adapt per CNU in an efficient manner.
It seems logical that the MAC layer will need to know what data rate the EPOC PHY can support across all CNUs sharing a common port. The mechanism adopted to determine this data rate should be based on PHY layer negotiation with each CNU, based on the current channel conditions. This is critical to operating at reduced SNR margins, as Matt has explained for us. Each CNU may need to regularly report error correction rates to facilitate this negotiation. Exposing suitable parameters at the OAM layer, including support for multiple simultaneous MCS, would provide the means to support a range of adaptability to HFC plant conditions.
A relatively static configuration of a single MCS would represent one use case while frame-by-frame MCS updates, as per LTE, would represent the other extreme. In the middle of this range of options is the case where each CNU is configured separately but maintains this configuration until updated by the network operator. Defining multiple simultaneous MCS is one way to support this last use case and may help support a dynamic update per CNU by moving between the various MCS as plant conditions require. Perhaps there are other techniques which the Task Force can develop to satisfy the adaptive transmission objective instead of or in addition to multiple simultaneous MCS.
Does this make sense?
Thanks
George
From: Marek Hajduczenia <marek.hajduczenia@xxxxxx<mailto:marek.hajduczenia@xxxxxx>>
Date: Wednesday, October 10, 2012 4:23 PM
To: Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx<mailto:m.schmitt@xxxxxxxxxxxxx>>, "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>>
Subject: RE: [802.3_EPOC] Why multiple simultaneous MCS
Thank you Matt,
I would suggest that we put the whole discussion off until the link model is available and we can actually see the numbers. Until done, we can only argue based on belief and personal convictions, but not actual facts.
Regards
Marek
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Wednesday, October 10, 2012 15:58
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Why multiple simultaneous MCS
Marek,
Thanks for the additional feedback and discussion — it's good to have an open debate/discussion on these points.
As for "others"… As I thought I had made clear elsewhere (but apparently didn't), I'm referring to my members and some consensus they achieved on another technology (and more recently than Geneva). That same consensus may or may not be applicable to EPoC — as we've already discussed — but given the common environment there's a good chance it does (assuming it can be made to work — reasonably — within the EPoC framework). Beyond that I'll let them speak for themselves. But if my comments were taken to mean that it's a foregone conclusion or consensus that this feature should be included in EPoC no matter what, then I apologize for creating a misconception.
On your points below, I agree with you, to a point. The simple fact is that HFC plant exists, and it is what it is. Yes, operators could potentially further improve their plant (which is already very, very good), but at additional expense there as well. So you end up taking a hit on cost one way or the other. The question is, where do you take that hit, and which one is less of a hit?
Put another way, if you set the bar on plant requirements too high in EPoC, and the resulting up front investment to get it to work is too great, then EPoC most likely will not be successful. And I would very much like to see EPoC be successful. That's part of what leads me to the conclusion that at least some flexibility is going to be necessary.
Of course, even if you improve the plant SNR, that doesn't change the fact that operationally you still need to leave a significant amount of headroom/margin when deploying products. And that headroom can make a significant difference in the amount of capacity we're able to achieve. So no matter how much you improve the plant, you're still losing on order of 2 bits/symbol (minus any increase in overhead, of course).
Finally, we are in complete agreement that we need a more complete proposal that has undergone appropriate technical scrutiny before making any decisions; likewise, we need to make sure we don't rule this concept out prior to that same technical analysis.
Thanks. :-)
Matt
From: Marek Hajduczenia <marek.hajduczenia@xxxxxx<mailto:marek.hajduczenia@xxxxxx>>
Date: Wednesday, October 10, 2012 1:00 PM
To: Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx<mailto:m.schmitt@xxxxxxxxxxxxx>>, "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>>
Subject: RE: [802.3_EPOC] Why multiple simultaneous MCS
Matt,
It would be nice if the discussion also involved these “others” you reference. It seems that you’re building a case for pre-existing consensus on this topic, yet this is not what we observed at the last meeting in Geneva. I would encourage these “others” to voice their opinions rather than rely on the group representation.
Now, for technicalities.
Your argument on SNR headroom is valid enough for consideration. However, the way we have typically designed specs before was on putting also some requirements on the cable plant and not only on the equipment. It seems to me that you’re building the case under which the cableplant can be as bad or good as it is, while the equipment has to have all the required flexibility to adapt to any plant (physical link) that it has to operate on (and conversely, take the hit in terms of complexity and resulting cost). While it is fine if that is what the group wants, before we take the plunge into development, I think it would be worthwhile if yourself and the unnamed “others” presented a detailed analysis of the added cost, impact on latency and something more of a detailed study of how such MCS function could be implemented in EPoC without moving away from EPON-like protocol. I understand that there may be growing consensus on the side of DOCSIS 3.1 that it needs to be done, but without such a study, I personally will not be able to make an educated vote on this matter. Seeing how you propose this to be done in 802.3 architecture would make all the difference for me.
I voiced my concerns before and I hope solution exists to them in a way that makes us move forward. Appealing as the MCS might be, it needs to go through the proper technical scrutiny, involving looking at the cost / performance / latency / implementation issues. Only then I believe we can take a decision, and not before.
Regards
Marek
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]<mailto:[mailto:m.schmitt@xxxxxxxxxxxxx]>
Sent: Tuesday, October 09, 2012 23:25
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto: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
________________________________
________________________________
________________________________________________________________________
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