Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Duane, We meant: minimum required channel data rate = data “pipe” size = minimum aggregate data rate. We figure that operator’s know how to take “bulk” rates and provide multiple subscriber services. What we didn’t want to do was burden the SG with taking subscriber rates and back tracking to the aggregate that we care about. Mark From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx] Mark, One requirement that I don’t see in your list and think is very important is the minimum aggregate data rate (unless this is what you meant by “Minimum required channel data rate”, but I took this to mean to a subscriber. Best Regards, Duane FutureWei Technologies Inc. duane.remein@xxxxxxxxxx Director, Access R&D 919 418 4741 Raleigh, NC From: Mark Laubach [mailto:laubach@xxxxxxxxxxxx] HI All, I think Matt’s description is a good one. Howard and I didn’t have anything more specific in mind with regards to how to express sizing of cable plant relative to our SG efforts. What I (we) do know is that we need contributions on requirements as soon as possible from cable operators and there is no common format at this time. What we do know is that we’ve identified four common topologies in the CFI: 1) Passive, Node + 0; 2) Node + N (where N is 1 to ?); 3) Existing HFC; and 4) MxU. If the contributions overview requirements for speed vs “size” (maybe vs frequency) address these different common topologies and how these might change over time (as we mentioned in CFI), then we’re off to a very good start with the collection of requirements for Study Group work. Cheers, From: Hesham ElBakoury [mailto:Hesham.ElBakoury@xxxxxxxxxx] Good input Matt! Few questions/comments below. Hesham From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx] Hesham, To your question about cable plant size, it is likely most of the above, rather than any one particular metric, as several of those can impact the performance of the PHY layer (or even the MAC layer and associated sub-layers). HEB> I think MAC and upper layers are out-of-scope in EPoC based on our CFI discussions. The MAC is Ethernet MAC. There might be some new OAM messages. Do you think MPCP needs to change to support the characteristics of the HFC plants or MPCP should stay the same and DBA may need to change ? (as you know DBA is out of scope of IEEE 802.3 standards). Although Mark and Howard may have had something more specific in mind with that particular question. For example, for a given node, we'll need to define (or select) ranges or approximations for things like homes passed, length of coax segments, number of amplifiers in cascade, arrangement of amplifiers (for funneling effects), fiber lengths, number of value of taps, tap performance, etc. This will likely be critical in evaluating different proposals, and understanding how they'll work under various conditions. We'll probably also need to define service group size, and how many nodes are covered in a given service group (assuming the architecture supports multiple nodes in a service group). HEB> I would appreciate if Mark/Howard can confirm that these are the characteristics of the plant, amplifiers, taps that they are looking for or we need to take into account other characteristics such as amplifier frequency response, gain bandwidth product, distortion reduction, …. etc Note that Howard and Mark did call out a number of the things I noted above separately from "plant size" -- which is why I suspect that they may have had something more specific in mind — but IMHO it all kind of lumps together in terms of characterizing the plant conditions under which a proposal will likely need to be evaluated. Thanks. Matt From: Hesham ElBakoury <Hesham.ElBakoury@xxxxxxxxxx> Hi Howard, I have few questions regarding the Operator requirements (pertaining to physical layer): Service coexistence issues and criteria Services to be provided over EPoC HEB> Do you mean residential and business services or video, IPTV, VoIP, data services ? and how they will evolve over time Business vs residential services (will they exist on the same network?) Asymmetry vs. symmetry Existing cable plant characteristics Architectures (Node+0 "passive", Node+N [N=1-?], Complete HFC, MxU) Amplifier characteristics and considerations that will effect the PHY Cable & passives characteristics Typical size of cable plant HEB> I am not sure how you measure the size ? (number of home passed, size of coverage area, number of nodes, … etc). Subscribers passed Number and size of taps Changes to cable plant characteristics over time (e.g. passive and active element changes, any use of bypasses?) Spectral allocation and how it changes over time Which frequencies are amplified and which are passive ` What spectrum will be allocated for EPoC initially, and how will that change over time Regional differences for changes? Functional Assumptions and Impairments DOCSIS 3.0 has already characterized in CM-SP-PHYv3.0-I05-070803, Chapter 5, and in CM-SP-DRFI-I12-111117, Chapter 5, for "in amplified" regions of cable. For both "in amplified" and "passive" EPoC considerations, are there any additonal functional assumptions and impairments that need to be considered for up to 1Gbps and higher operation? How will these change over time? Are there regional differences; e.g. China, Europe? Number of subscribers per network, take rate Minimum required channel data rate Maximum desired channel data rate Thanks Hesham -----Original Message----- The first meeting of the IEEE 802.3 EPON Protocol over Coax (EPoC) PHY Study Group will be held January 24th and 25th in Newport Beach, CA, hosted by the Ethernet Alliance. Please see my previous message for links to meeting logistical details. In preparation for the meeting, Mark Laubach and I put together a list of topics that can help us prepare for a successful study group meeting, and these are listed in the attached file. The first set of topics deals with the IEEE 802 standards development process. I have all of the material I need for this section, and I am sure that I will be able to enlist the help of some of our experienced hands to deliver it. The second set of topics deals with operator requirements, and this is where I would like to make an appeal for contributions. We may not get contributions that address all of the topics listed, and there may not even be universal agreement that the topics are relevant, but I think that these are areas that must be explored in the study group if we are to do a proper job of defining the scope of a new project, and judging it against the "5 Criteria". People wishing to make a contribution to the study group should review the "Procedure for Presenters" information that can be found here: http://www.ieee802.org/3/epoc/public/presentproc.html Since this is a new email reflector, I would also like to make people aware of the IEEE 802.3 Working Group email reflector policy that can be found here: http://www.ieee802.org/3/reflector_policy.html I will welcome your comments and questions. Howard Frazier Broadcom Corporation ________________________________________________________________________ To unsubscribe from the STDS-802-3-EPOC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1 <="" p=""> <="" p=""> <="" p=""> <="" p="">
|