Matt,
I have no doubt the scheme you describe (adding frequency, code dimensions) is achievable (and may even be desirable) in EPoC. Indeed, that is why I suggested
it.
The question is: where do we fit it in?
Under the straightjacket of “no MPCP changes/extensions” and the BOX being a MAC relay and not a bridge, I’ll be interested to see how we accommodate these
features in 802.3.
Alex
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Tuesday, March 06, 2012 12:58 AM
To: Liu, Alex; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?
Alex,
As an FYI, we do this already in DOCSIS, starting with DOCSIS 2.0, so I don't think there'll be an issue here.
Previous to DOCSIS 2.0, DOCSIS upstream transmissions were all done using TDMA. As such, the upstream scheduling mechanism was designed to advertise upstream
transmission in units of time quanta (what we called "mini-slots"). So it was a straight one dimensional scheduling mechanism based on time.
However, in DOCSIS 2.0, we decided to add SCDMA, which has a second dimension in addition to time referred to as "codes". So transmissions need to be scheduled
not just in time, but also for particular codes which are spread across a particular unit of time (which in SCDMA is a "spreading interval"). At the same time, TDMA would still be supported as well, and we wanted to use a backward compatible scheduling mechanism.
The solution was to map our one dimensional mini-slots onto a pre-defind two-dimensinal structure, so that both the CM and the CMTS would understand that transmission
across a certain set of mini-slots actually meant transmitting across a certain set of codes and spreading intervals.
I don't see any reason why we can't do something similar here (assuming we end up selecting a multi-carrier approach). One option would be to have a pre-defined
"map" of sub-carriers and time, so that a given allocation in time quanta could be converted to one in both time and frequency. You wouldn't even need new messaging — it would just be understood by both devices based on a pre-defined set of rules. Or you
could take it a step further, and develop a new OAM or MPCP message that would advertise a mapping between the one dimensional messages and the two-dimensional transmissions.
Marek and others,
FYI, that conversation did just make me realize something else that the "OCU" or whatever we call it would need to do. Perhaps this was obvious to everyone,
but in case it isn't, it will need to read the GATE messages destined for it's CNUs. The reason is that it will — I believe — need to implement a burst receiver in the upstream, and as such it will need to know what to be prepared to receive at any given
time.
Thanks.
Matt
From:
"Liu, Alex" <alexliu@xxxxxxxxxxxxxxxx>
Reply-To: "Liu, Alex" <alexliu@xxxxxxxxxxxxxxxx>
Date: Mon, 5 Mar 2012 07:01:05 -0700
To: "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?
Marek,
Can you spell out the precise benefits of extending the MPCP domain across to coax?
Is an unified OAM domain not enough to guarantee transparent provisioning between optical and coax without the need for OLT changes?
MPCP is a one dimensional (i.e., time-based) access control scheme. Mandating it on coax will rob us of the ability to account for the frequency selectivity
of the RF medium, and the aforementioned “chunkiness” of spectrum availability.
Lastly, regarding the rate adaption and packet filtering functions that you mention the OCU potentially having to perform, how would you characterize these
changes if not MAC changes?
Alex
<="" p="">