Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?

Hal,

Something that's been discussed extensively by MSOs — and for which we'll have a contributions next week — is that we want the coax side of the Box to support data rates above, below, and at 1 Gbps.  We also generally discussed that the coax would run at or below the data rate of the fiber side, and that it would not exceed it.

So if the question is phrased around supporting data rates less than and greater than 1 Gbps, then that would definitely be agreed to.  If it's phrased as less than or greater than the fiber side of the box, then I don't believe they would agree: it would be just less than or equal to.  All of which makes me wonder if, particularly for the downstream direction, a 1 Gbps fiber link really makes much sense (although I suppose it's good not to preclude if if we don't have to).

Thanks.

Matt

From: Hal Roberts <Hal.Roberts@xxxxxxxxx>
Reply-To: Hal Roberts <Hal.Roberts@xxxxxxxxx>
Date: Mon, 5 Mar 2012 13:18:11 -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?

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

 

Description: cid:image001.png@01CCFB1A.59B24AC0

 

 

<="" p="">

 

<="" p="">

 

<="" p="">