Re: [802.3_EPOC] Why multiple simultaneous MCS
This is in response to an earlier part of this exchange where Eugene was
commenting on the quantified MCS example. A string of conference calls
intervened and I was delayed.....
Multicast video aside – and I think the benefit of multicast vs
(broadcast+unicast) itself is worth a closer look itself given trends
around video consumption – I concur with Eugene’s original point with
respect to the example case of 1 Gbps or 250 Mbps capable devices. There
is nothing inaccurate about the example math, and I appreciate Duane
clarifying this key asset of OFDM. But it is valid to point out that
likely comparison of MCS vs non-MCS throughputs should not be this
dramatic, and such a delta not used as a basis for MCS opinion or
decisions, at least not without more context.
One of the reasons MCS was hotly debated in DOCSIS - and I am favorable to
consideration of a small set of profiles in that environment - was
associated with relatively modest % avg capacity gains for typical SNR
distributions (its understood that "modest" is in the eye of the
beholder) Other
considerations, such as operating margin, a fall-back, opex, peak tier
implications as complementary advantages are influencing direction.
If we take the case described of 1 Gbps vs 250 Mbps, for example, using a
4096-QAM capable line (for integer math) for 1 Gbps in some spectral
allocation this would be comparing the 12 bits/symbol QAM profile to 3
bits/symbol which works out to some 27 dB SNR delta. That would just be
seriously broken. If that dynamic range is a case to cover with profiles,
that can be discussed, but I felt it was worth putting this in perspective
of Eugene’s point on the numerical example.
To emphasize another point that I think that Ed Mallete was making (and if
I put the wrong words in your mouth, Ed, please correct me), depending on
architecture, and including what may be a probable case for NA (RF overlay
over passive coax to a CNU at the point of entry), should see less
advantage of MCS than a long RF cascade. Conversely, the architecture
through amplifiers will see variation with some relationship to the cascade
depth, and see an increased benefit of MCS This latter would also not be
compatible with a TDD mode in today’s network.
The use of unqualified bandwidth above the current HFC band would
necessarily have to be over passive coax today. It thus could be TDD
eligible (not opining here on MPCP ramifications). It would be more likely
to benefit from MCS than in-band downstream, primarily if it is a case of
launching in just "excess" Tap bandwidth.
Rob H
On Thu, Oct 11, 2012 at 12:43 PM, Victor Blake
<victorblake@xxxxxxxxxxxxxxx>wrote:
> Eugene, Matt, and Marek -- There are lots of ways to do this way above
> MCS. I return again to wireless where there are mechanisms to broadcasts
> and there are common radio link control channels and then common physical
> link (ds) channels.****
>
> ** **
>
> -Victor****
>
> ** **
>
> *From:* Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
> *Sent:* Thursday, October 11, 2012 11:51 AM
> *To:* 'Victor Blake'; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
>
> *Subject:* RE: [802.3_EPOC] Why multiple simultaneous MCS****
>
> ** **
>
> Victor, ****
>
> ** **
>
> Think about how DPoE resolves multicast in phase 2. I’d think we would
> like to have similar mechanism in EPoC as well, but it relies on LLID
> transport, which implies precisely what Euguene was saying – once you start
> using MCS, you lose the benefit of broadcast delivery mode and have to
> single-cast or at most create multiple multicast groups****
>
> ** **
>
> Marek****
>
> ** **
>
> *From:* Victor Blake [mailto:victorblake@xxxxxxxxxxxxxxx<victorblake@xxxxxxxxxxxxxxx>]
>
> *Sent:* Thursday, October 11, 2012 11:26
> *To:* 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://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<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<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<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<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=""> ****
>
> ** **
> ------------------------------
>
> ** **
> ------------------------------
>
> ------------------------------
>
>
________________________________________________________________________
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