Re: [EFM] EFM Requirements
Frank,
I would like to remind that EFM = Ethernet in the First Mile, but not in
first 10 miles. To cover 10 miles it is probably assumed a fiber for the first
9.5 miles and some copper tail after. That's why PON is the major topic in EFM
group as well.
Vladimir.
Frank Miller wrote:
> 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.
> >
> >