| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Matt, We are in full agreement. We should write the spec assuming an CNU will be built that can sink a full 10G (assuming we can get that much onto the COAX). That The spec should allow this but not require it. 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]
Duane, I tend to agree with you to the extent that the spec probably shouldn't call out specific performance requirements for individual devices. That said, I also believe that we should ensure that
the spec does not prohibit devices from using the full capacity of the available bandwidth. In other words, we should avoid making design choices in writing the spec that would prevent a vendor from building such a device if they wanted to. Does that make sense? Thanks. Matt From: Duane Remein <Duane.Remein@xxxxxxxxxx> I think Ed has thr “rgith” ANSWER HERE. The EPON standard does not have a requirement that an ONU built to 802.3av (10G EPON) be able to deliver 10G DS, nor is a 1G-EPON ONU required to deliver 1G (in either
DS or US). The standard is written in a way that allows implementation of such devices but most of the initial ONU built only had 100M interfaces and were 100% compliant. We need to write a standard that allows a CLUT to deliver the entire DS bandwidth. That
does not preclude anyone from building CLTs that only deliver 10M and are still fully compliant (not that I would suggest this as a good idea
J ). Best Regards, Duane FutureWei Technologies Inc. Director, Access R&D 919 418 4741 Raleigh, NC From: Edwin Mallette [mailto:edwin.mallette@xxxxxxxxx]
This may indicate some significant ignorance on my part, but I was unaware that 802.3 specified performance requirements explicitly. My assumption is that, from the perspective of 802.3bn, we
focus on the standard. When it comes to product definitions and cost trade-offs within a product, we can have that discussion another day, another time, and in another forum. Ed From: Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx> Steve, Following the same approach, we will then change the way MAC works, MPCP and OAM, because they may be different in EPoC. That is all fine, but it is a different project altogether.
Marek From: Shellhammer, Steve [mailto:sshellha@xxxxxxxxxxxx]
Marek, The cost/complexity of the EPOC PHY may be very different than the EPON PHY. EPON uses BPSK, while EPOC is likely to use a multicarrier (i.e. OFDM) PHY with high order modulation (1024QAM, 4096
QAM). So you may not “buy” that argument, however, a consumer may not “buy” a high cost/complexity CNU either.
J Steve From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Steve, I do not buy that argument. 10G-EPON ONUs support full 10G if it is available. I do not see the need to subdivide the allocated spectrum into chunks which will be then assigned to individual devices. This is
not how EPON works. Marek From: Shellhammer, Steve
[mailto:sshellha@xxxxxxxxxxxx] Ed and Marek, As the channel bandwidth increases well above 120 MHz, requiring the CNU to support very large bandwidth will add to the complexity and cost of the CNU. It is not clear to me that if the channel
bandwidth is say 3x120 = 360 MHz that requiring each CNU to support the entire bandwidth is a good trade-off. I consider the CNU a consumer device and so I would expect its cost and complexity to be much less than the CLT. Is there some channel bandwidth at which we will no longer require the CNU to support the entire channel bandwidth? Steve From: Marek Hajduczenia
[mailto:marek.hajduczenia@xxxxxxxxx] Ed, That is precisely the point I was raising on the call today – EPON does not impose any limitations on bandwidth per ONU and furthermore, requires any single ONU to be able to absorb all bandwidth made available
by the OLT. The EPoC should work the same way. I think we reached a closure on the call on this point.
Marek From: Edwin Mallette
[mailto:edwin.mallette@xxxxxxxxx] Just to add on to Matt's thoughts here, our general model should be "what would EPON do?" If EPON has a specific feature or general capability (like allowing a single LLID to utilize
the entire available upstream) then EPoC should have have a similar capability. We have already scoped out some of the capabilities of 10G-EPON (10Gb/s upstream for example.) I would also agree with Matt that there would need to be some good reasons for scoping out some of the fundamental capabilities of EPON from EPoC. Regards, Ed From: Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx> With regards to the 1 Gbps item in the Objectives (being discussed below), I recently responded to a question from Bill regarding that Objective. I thought it might be worthwhile to
share the thoughts I shared with him with the rest of the group. Based on my recollection of the discussions around that objective, I should clarify that the first part of that objective — the part about 1 Gbps — is NOT so much about setting a speed
target for a device or even the system. Rather, it is in effect a back-door way of specifying a requirement for spectral efficiency (I.e., bps/Hz). So if you're looking at it as a pure speed target — that devices be able to achieve 1 Gbps — then I believe
that is not the correct way of viewing that Objective. That's not to say that devices
shouldn't be able to achieve that (given enough bandwidth). However, devices — and the system — should ideally be capable of much more. How much more we'll need to work out, but personally I think that a device that maxes out its performance at 1 Gbps
in the downstream would likely be of limited value. Regarding the question of a single CNU being able to use the entire pipe (regardless of bandwidth), I believe that we should always be designing to allow a single device to use
the entire bandwidth available for a given unit time. If it turns out that's not possible, then there really needs to be a very good reason for not designing for this, and the number should be as close to the ideal as possible. That doesn't mean you would
necessary provision a service at that data rate, or that you'd expect a device to operate at that speed continuously for a long period of time, but it should be possible for at least a short time. Technically, this second item is not addressed by any of the Objectives. We can add it if the team feels its necessary, although I consider it best practice (plus we don't yet know if
it's technically possible), so I'm inclined not to do so. Thanks. Matt From: Marek Hajduczenia <marek.hajduczenia@xxxxxx> Andrea, Please find additional feedback inline
Marek From: Garavaglia, Andrea [mailto:andreag@xxxxxxxxxxxx]
Hi Marek, Thanks a lot for your feedback – please see some answer below. Talk to you soon. Thanks, Andrea PS. Please allow me a remark so that everybody understand -> when it is stated “you” in your reply, it shall be read it as “the group” as what I am doing here is not necessarily presenting Andrea’s view, rather
what the group is converging on week by week, of course including your inputs. I hope that is clear and maybe if we all simply talk about what the slides say it is easier to understand each other – now updated with numbers even, for starters and veterans
J From: Marek Hajduczenia
[mailto:marek.hajduczenia@xxxxxx] Dear Andrea et al.,
Slide number would be welcome, for starters
J [AG] It is included – attached again, it seems Adobe did not like it
J On slide 3, I think the question “Is 1 Gb/s PAR objective to individual CNU or on coax segment?” is poorly stated.
[AG] I let Bill commenting/refining on that – please see also past e-mail from him attached. When you think of EPoC and EPoC bandwidth, it is bandwidth provided by the CLT port, and not per CNU. For example, if CLT supports the baseline conditions, it will provide 1 Gbit/s to be shared by any number
of connected CNUs. It is the same as in EPON, really, where 1G-EPON OLT provides 1 Gbit/s link to connected ONUs. If there is 1 ONU, it will get full 1 Gbit/s, if there are more ONU connected, the bandwidth is shared. So really, the bandwidth in EPoC is not
per coax segment (what is that, really?) but rather than CLT port. Then all discussions on how much bandwidth per CNU is available are moot, since it depends on distance, scheduling efficiency and number of connected CNUs. Operators have known this trade-off
for quite some time, since it is the same in DOCSIS, EPON and any other multi-access technology. So I do not understand why we are making such a fuzz about it and trying to impose a new meaning / interpretation of available bandwidth in case of EPoC.
[AG] That is understood. The question in my understanding is: is the case of one single user attached to CLT and have a sustainable 1 Gb/s a use case to consider when counting for worst case scenarios, or
not (i.e. it is a corner case)? [mh0813] I am not sure whether that is relevant. We have a nominal data rate objective and then two corner cases. These have to be supported by the equipment. Whether an operator would deploy a CTL with a single
CNU connected to it or not does not change the bandwidth requirements and objectives.
Regarding the performance model. I fear that the level of detail you try to go into in the slide deck cannot be really simulated (or even approximated reliably) using Excel model. Given the self-similar nature
of user traffic, combined with scheduling model and QoS enforcement, to reliably evaluate the system performance one would have to build at least a cure simulator tool, accounting for queuing delay, through-stack delay and scheduling delays, something that
cannot be estimated using limited tools that Excel provides. My fear is that we will spend a lot of time on this model, have discussions on something that will eventually turn out to be of very limited use to progress EPoC process forward. Yes, we can consider
line efficiency, to compare transmission efficiency with various FEC, encoding or interleaving solutions, but the effect of scheduling and queuing on overall system performance is very hard to estimate in such a simplified model. Just FYI, some more comprehensive
analysis of EPON delay were done by Glen and myself for both 1G-EPON and 10G-EPON systems, and the obtained results cannot be accounted for using simple Excel models. There are stochastic effects in play in shared media systems which you cannot really capture
in formulas. [AG] What we are trying to gain insight here is not the precise model, but the 1st approximation which can be played with in simple sheet (see formulas on page 11 – I guess those are fairly well
run on excel too). The detail modeling is not in the scope and there is no preclusion for surely companies to build a more details and sophisticated simulator and present results in case we will design performance requirements. The ambition is simply to update
the current spreadsheet with what listed as feedback in slide 3, which to me looks feasible – but I am open to further simplify it. [mh0813] I think what we will end up is not even 1st approximation, but rather approximation 0.01. When comparing analytical models for EPON performance with simulations and real-world measurements, it
is clear that models come close to observed performance only for very specific cases, while simulations come very close for all / most of the cases. I fear that we might draw incorrect conclusions based on the model that is inherently flawed
Further, on slide 5 you show various reference architectures. I would like to remind you (and others) that the scope of this project is quite strictly limited and examining OCU delay, EPON delay etc., is not
within our work scope at this time. I would certainly like to see option c) removed. If you want to model some sort of optical backhaul, remember that it can be also P2P fiber, or any other P2P technology for that matter. EPON that you show in option c) is
just one of possible options. In either case, it does not matter, since it is just a fixed delay component for EPoC, nothing more.
[AG ] The slide is just capturing the comments made offline and it is up for discussion today (that is why it is in red) – your inputs in the call are welcome. Personally, I am fine to remove case (c) and
I see your point. Slide 7 contains some interesting new terms, like E_bits and I_bits – are these intended to be defined anywhere?
[AG] Yes, will add the definition – it is just an abbreviation for information bits and encoded bits, so there is a differentiation of the encoding/decoding operations. [mh0813] I would suggest using terms from EPON, which required similar concepts. Adding new terms without any needs is never welcome.
Slide 14 – the assumptions about the scheduling model you have there allow you to simplify the model with a non-scheduled, dedicated link with 1/N capacity of overall EPoC link. The average delay will be exactly
the same. No need to account for scheduling in such a situation, unless you want to model a real scheduling model, which shares bandwidth among CNUs in a non-equal fashion, depending on report and gate mechanism. But in that case, Excel model is not sufficient
and simulations should be employed. [AG] Note that slides from 12 onwards (sorry
J) are
not up for comments yet as stated in the e-mail below, this is work in progress. They will revised/removed/modified and the presented if we still find those parts relevant on later time. [mh0813] The observation is still valid, though …
Marek From: Garavaglia, Andrea
[mailto:andreag@xxxxxxxxxxxx] Resending as PDF (size was too large). Andrea From: Garavaglia, Andrea
Hi all, Please find attached the status report slides for today’s call. I hope last week we got sorted out most questions on scope and so we can keep it shorter this week, here my proposal for discussion:
-
Briefly confirm on the scope (added a disclaimer on slide 2 and included new slide 5 – there were comments to remove the last case)
-
Slides 8-10 are new for completing FDD upstream modeling (on the same line as downstream) – can briefly touch on that if needed
-
Slide 11 includes formulas for FDD PHY and some related considerations/notes – this is the main one to review
-
The rest is ongoing work – we will not discuss it today Thanks, Andrea <="" p=""> <="" p=""> <="" p=""> <="" p=""> <="" p=""> <="" p="">
|