Jorge,
Makes sense to me
Thanks for the clarification
Marek
From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
Sent: 05 March 2012 20:33
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?
Right! And thanks for the clarification. I keep focusing on the 1 Gbps portion of the question.
The speed in the RF portion of the network could be less than or equal to 1 Gbps for 1 Gbps PONs, or less than, equal to, or greater than 1 Gbps for 10 Gbps PONs (although unlikely to be as high as 10 Gbps in the later). Does that make sense now?
Thanks!
Jorge
From: Hal Roberts [mailto:Hal.Roberts@xxxxxxxxx]
Sent: Monday, March 05, 2012 03:18 PM
To: Salinger, Jorge; '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?
Yes, 1 Gbps.
The reason the answer was not clear is because of the question wording which said:
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
Both Marek and I think you do not agree the greater case.
In the case of coax speeds greater than 1 Gbps you in fact would make sure the fiber speeds were greater than the coax side.
So the answer is you agree with the statement but with the word “greater” removed.
Hal
From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
Sent: Monday, March 05, 2012 2:12 PM
To: Hal Roberts; 'stds-802-3-epoc@xxxxxxxxxxxxxxxxx'
Subject: Re: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?
I assume you meant 1 Gbps, not 1 GHz, right?
If so, then yes, we could achieve speeds greater than 1 Gbps on coax (which we, in fact, intend to support), which would be backhauled by a 10 Gbps EPON PON (not multiple 1 Gbps EPON PONs).
Does that make sense?
Thanks!
Jorge
PS: its amazing how a single "yes, I agree" answer could be so incomplete :-)
From: Hal Roberts [mailto:Hal.Roberts@xxxxxxxxx]
Sent: Monday, March 05, 2012 03:05 PM
To: Salinger, Jorge; 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?
Jorge,
I want to make sure I understand you correctly.
Is it true you do see a use case where the EPoC spectrum on the coax can be greater than 1GHz and the EPON is unable to backhaul all of the spectrum?
If so the EPoC will need multiple PONs to backhaul the coax data.
Regards,
Hal
From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
Sent: Monday, March 05, 2012 1:57 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?
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="">