Marek,
There is no point in limiting the architecture to some specific technological limitation at a given time.
I expect that as EPOC will be deployed, the distance between the “box” and the CNU will become shorter and shorter. The number of CNUs serviced through one “box” will also be reduced.
As a result, 10Gbps data rates and higher are easily achievable on coax.
-Valy
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Monday, March 05, 2012 12:03 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?
Jorge,
Now you got me curious. Is it really realistic to require coax to support 10 Gbit/s when it is connected to 1G-EPON line ? What would we do with the extra data pumped through coax? Buffer it at the BOX ?
Marek
From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
Sent: 05 March 2012 19:57
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?
Steve,
Yes, that's correct.
FYI, we wanted to be clear on that, so one of our MSO presentations will cover that topic during the Hawaii meeting.
Thanks!
Jorge
From: Shellhammer, Steve [mailto:sshellha@xxxxxxxxxxxx]
Sent: Monday, March 05, 2012 02:37 PM
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?
All,
I wanted to ask the MSOs a question about data rates. Hal brought this topic up in this email thread below. By the way, I think I will use the term “Box” for the box between the fiber and the coax, since we are still discussing its functionality. And to Matt’s point I would the functionality of the Box will need to be standardized.
It would seem to me that on the fiber side of the Box it will need to support both 1 Gb/s and 10 Gb/s.
It would also seem that on the coax side of the box that the data rate could be less than 1 Gb/s and more than 1 Gb/s. I am not sure if it would ever be more than 10 Gb/s.
So it seems like the data rate on the coax side of the Box could be either less than, equal to, or greater than the data rate on the fiber side of the Box.
Question to MSOs: Is this correct?
Thanks,
Steve
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Monday, March 05, 2012 8:58 AM
To: 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="">
<="" p="">
<="" p="">