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

RE: [EFM] EFM Requirements




Hugh,

From an initial requirements baseline, why not start with requirements
that provide for a less capital intensive deployment ... more distance and
more reach.
A design that starts with a capital intensive deployment in a capital-poor
telcommunications market
definitely puts a smile on my budget.

I cannot build a business model in my markets in rural Oregon, Washington
and Idaho with
the proposed solution for 802.3 EFM.  My average loop distance, and a first
glance, is probably
between 14 and 16 Kft in the rural market. 

Frank 

> -----Original Message-----
> From: Hugh Barrass [mailto:hbarrass@xxxxxxxxx]
> Sent: Tuesday, August 14, 2001 6:52 AM
> To: Lough, Andy
> Cc: Vladimir Oksman; Sherman Ackley; Stds-802-3-Efm (E-mail)
> Subject: Re: [EFM] EFM Requirements
> 
> 
> 
> Andy,
> 
> Thanks for your input. I agree with *almost* all of it:
> 
> First - although reach and bandwidth are political issues 
> there is a hard limit governed by the Shannon capacity of the 
> cable. If you want it to go further, it will be slower; If 
> you want higher speed, it won't go as far; If you want high 
> speed and long reach, you need more pairs. There is no free lunch.
> 
> I think it is vital that 802.3ah focus on all three media 
> types (copper, p-p fiber, p-mp fiber) as there are clearly 
> applications that will not fit the same solution as one 
> another. It's no use inventing a hammer and simply describing 
> the whole world as a nail...
> 
> Secondly, with respect to compatibility and unbundling - the 
> two issues are closely related. However, I do not think we 
> can get our requirements by looking at any and every 
> (non-standard) service that is out there and trying to fit in 
> around them. I suggest the starting point should be 
> standards-based compatibility. FSAN has defined spectral 
> standards, these have been adopted by NRIC-5 (committee of 
> the FCC). It seems likely that spectral compatibility on a 
> cable will soon be regulated as closely as it is in the 
> airwaves. This makes sense as a cable binder behaves like a 
> shared medium at higher frequencies.
> 
> I think that the main difference in our viewpoints is the 
> angle we are looking from. I see the rate/reach as a 
> technical problem (i.e. what's possible) and try to meet the 
> requirements from there. I see the compatibility as a 
> regulatory issue and expect that if we comply then others should.
> 
> This is a very healthy discussion for the group - it is very 
> important that we can align the expectations of the majority 
> in order to make progress on developing the standard.
> 
> Hugh.
> 
> "Lough, Andy" wrote:
> 
> > I see the key issues as being broken down into 3 simple 
> areas (my frame of reference is the EU market only)
> >
> > reach
> > bandwidth
> > compatibility
> >
> >  we need to consider the needs of all operators 
> (telcos,ISPs, etc.). Rapid deployment of Ethernet broadband 
> services will only practically be achieved over copper in the 
> short to medium term. put simply it will be  impractical for 
> carriers to install fibre everywhere due to deployment costs. 
> Carriers on the whole do not have the finances or ability to 
> raise finances to cover extensive fibre deployments (to every 
> building currently copper connected). This leaves the 
> existing Copper as the main practicable medium for deployment 
> as an existing asset(excluding wireless which is outside the 
> scope of this forum).
> >
> > reach - reach is a practical issue. If we are to support 
> all service providers in a given market we need to be able to 
> support longer distances to ensure the maximum possible 
> coverage from a given area, hence a maximum potential 
> subscriber area and thus the maximum possible revenues for 
> that carrier to sustain its business. This applies in all 
> areas, rural definitely, but also in city centres, where COLO 
> opportunities are congested, the need to span multiple areas 
> via copper can clearly be justified. For specific numbers 
> that's down to opinion, 12Km is a hell of a long way, I 
> believe 6,000ft @30-40Mb+ and 12,000ft@15-20Mb+ would be 
> ideal. thus enabling both city centre and business focused 
> services to be covered(shorter loops high bandwidth) and more 
> distant/home applications to be served (at longer distances, 
> longer loops lower bandwidth).
> >
> > bandwidth - Bandwidth needs to be focused on the 
> applications, I believe most thoughts are in the 20Mbps range 
> (for home), however the key issue is that it needs to be 
> flexible such that a deployment of a technology doesn't 
> restrict the ability to service customer needs based on a 
> technology symmetry limitation (indeed inline with the basic 
> principles set by the original Ethernet standard).The SME 
> market is one area I believe will demand distance and BW 
> above 6000ft@30Mb, for ASP type services, with fibre install 
> being negated by a suitable copper deployment. Allowing a 
> service provider to be ultimately flexible and using a single 
> technology for deployment will be a key advantage over 
> current technologies - hence encouraging adoption of Ethernet 
> first mile propositions. We also need to consider that 
> application bandwidth requirements will only increase going 
> forward as adoption increases and service providers generate 
> content based businesses, so we should design in some s!
> pa!
> > re capacity upsides if at all possible to ensure longevity 
> of the standard.
> >
> > compatibility - For me this is THE most important issue. We 
> have to keep in mind the EU directive on unbundling the 
> copper loops. This means any particular service provider may 
> have an SLA and contract with a customer delivering copper 
> based service over Ethernet - if another service provider 
> installs a service the next day in the loop that 
> interferes/is interfered with   by EFM then it will become 
> impossible for the local loop unbundling to work, this will 
> cause the whole broadband over copper deployment to fail as 
> those tasked with managing the local loop look to restrict 
> access to both service providers and technologies. As we are 
> here to set a successful technology standard to encourage the 
> deployment of Ethernet in the First mile, then compatibility 
> in local loops must be allowed for.
> >
> > compatibility, if built in as an intrinsic part of the 
> technology, should also be considered when looking at the 
> home end, where technology advances and implementations both 
> current and future are likely to evolve. We will likely see a 
> combination of current and new wireless , plus wired (copper 
> e.g. HPNA) and more likely power line technologies deployed 
> at ever increasing rates to meet the consumer needs. (power 
> line has my personal vote @ 15Mb-40Mb over the next 3 years). 
> We cannot assume spectral containment of these signals. using 
> powerline for example it is impractical to filter a power 
> cct, and the signal leakage from the cables themselves likely 
> running in parallel to the copper telco cables will introduce 
> crosstalk that needs to be planned for.
> >
> > As engineers we like to see things in black and white, but 
> the truth is the world is grey. a perfect pair of copper 
> doesn't exist, no one single example customer requirement can 
> represent the complete overall requirements.
> >
> > The key to our success is a standard that will do the most 
> for the most number of customers in the simplest way without 
> imposed restriction. (pretty much in line with the 
> achievements of the original Ethernet standards)
> >
> > Regards
> >
> > Andrew Lough, Mitel Networks
> >
> > -----Original Message-----
> > From: Vladimir Oksman [mailto:oksman@xxxxxxxxxxxx]
> > Sent: Monday, August 13, 2001 9:19 PM
> > To: Sherman Ackley
> > Cc: Stds-802-3-Efm (E-mail)
> > Subject: Re: [EFM] EFM Requirements
> >
> > Dear Sherman,
> >
> >      thank you very much for this significant and really 
> helpful input. A couple
> > of questions for clarification anyway.
> >
> > 1. By your experience only two MPEG-2 channels are 
> required. Why, however, US
> > telcos were pushing so strong for 22Mb/s downstream for 
> VDSL motivating that by
> > a need in 3 video channels. Is there some specifics in 
> video service over
> > Ethernet you keep in mind?
> >
> > 2. You mentioned loop length of 10-12 km. It seems to me 
> that the technology
> > will allow 1-1.5 km. Does it still make sense to work on EFM?
> >
> > 3. You mentioned compatibility with HPNA. Here several 
> questions come to the
> > mind.
> >     A. Is it right that you assume EFM running over the home wiring?
> >     B. If yes, do you mean HPNA running over the same wire 
> with EFM or over
> > different wires?
> >     C. What kind of HPNA do you keep in mind (there is no 
> standard on HPNA)?
> >
> > Thankfully,
> >
> > Vladimir Oksman, Broadcom Corporation.
> >
> > Sherman Ackley wrote:
> >
> > > Service Provider Requirements for Ethernet in the First 
> (two) Mile(s):
> > > Sherman L. Ackley, CTO
> > >
> > > The National Rural Telecommunications Cooperative 
> provides services to over
> > > 350 member independent telephone companies who serve over 
> 6 million access
> > > lines.  Ethernet in the first mile is the most promising 
> technology for the
> > > delivery of integrated voice, video and data services in 
> the suburban and
> > > rural areas served by our Members.  As the Chief 
> Technology Officer for
> > > NRTC, I would like to submit some practical requirements 
> as seen by the
> > > service providers most likely to implement this 
> technology in the USA.  The
> > > intent of this contribution is to help the study group prepare the
> > > requirements document based on actual needs.
> > >
> > > The user locations will be 90 percent residential and 10 
> percent business.
> > > Of those businesses, 90 percent will have 10 or fewer PCs.
> > >
> > > The system must work over standard high capacitance 
> telephone outside plant
> > > cable.  Binder group integrity is not assured.  The 
> technology should not
> > > force removal of bridge taps and end sections.  It needs 
> to operate without
> > > degradation at binder group fills over 70%.
> > >
> > > System reach is the most important aspect of the design.  
> Ethernet in the
> > > first mile must operate over the longest reach possible.  
> The number of
> > > households and small businesses served by a node is 
> proportional to the
> > > square of the reach.  For example, a reach of 3 km can 
> serve about 100
> > > single-family homes per node. Doubling the reach to 6 km 
> increases the homes
> > > served per node to 400.  And with a 12 km reach, 1600 
> homes per node can be
> > > served.  This assumes 100 percent subscribe.  At 25 
> percent subscription,
> > > short reach technology gets down to some dismal financial 
> outlooks in terms
> > > of cost per revenue producing subscriber as well forcing 
> the construction of
> > > too many street corner server nodes.
> > >
> > > Coexistence with HomePNA on the same cable pair is 
> essential.  This feature
> > > will be necessary in over 75% of households served with 
> Integrated Broadband
> > > services.  For example, a data stream of 10 Mbps will 
> support two MPEG-2
> > > high-resolution standard TV signals.  The DSL will carry 
> this to the primary
> > > service set-top box/home gateway that can be located 
> anywhere in the house.
> > > The Gateway device will terminate the video and data for 
> use at the primary
> > > TV, it will then forward the second video and data over 
> the same cable pair
> > > to other set-top boxes and PCs within the house using HomePNA.
> > >
> > > Peer-to Peer (or server to server) communications 
> requires that the service
> > > be adaptable so that full rate is available upstream or 
> downstream as
> > > required by the user generated traffic.  For example, it 
> is now possible to
> > > record MPEG-1 video on a camcorder and e-mail it over the 
> Internet.
> > > Unfortunately, sending the e-mail over a conventional 
> fixed data rate
> > > ADSL/VDSL system takes forever for the 20 Mbps file.
> > >
> > > There is little demand for sending three simultaneous 
> MPEG-2 video streams
> > > to the home.  This is based on the analysis of over 20 
> million DBS and
> > > digital cable subscribers.  In fact, two streams are 
> required in only 30
> > > percent of households.  It is far more economical to 
> install a second
> > > Ethernet Subscriber Loop (ESL) for the one in 100 who 
> want three HDTV videos
> > > than to burden all with the high costs required to 
> support a higher bit rate
> > > short reach technology such as VDSL.
> > >
> > > In conclusion, long reach is of paramount importance.  
> For delivery of two
> > > Standard TV signals, 10 Mbps at 12 km is required.  For 
> one HDTV plus one
> > > Standard TV, 20 Mbps at 12 km is desired.  Also, the 
> selected technology
> > > should allow data to flow in either direction at the full 
> data rate.
> > > Finally, the technology should be spectrally compatible 
> with HomePNA without
> > > requiring the use of a splitter at the residence.
> > >
> > > Finally, feedback on these ideas from other service 
> providers and vendors is
> > > invited.
> 
>