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.
>
>