RE: [EFM] EFM Requirements
<last 400 meters in Europe?>
Are you referring to to PON implementations?
MY experience from discussions with a number of ILECS and CLECS on the unbundling situation in the EU is their view is that distance is a limiting factor for VDSL, it just wont go far enough and is a real headache to implement spectrally. They are expending huge amounts of time and effort to implement DSL services and hence deployment is always later/slower than anticipated, and therefore hugely more costly.
If we can resolve all these issues with EFM then I'm confident Copper EFM will have a huge adoption curve.
They definitely want distance, and that's here in the UK where we have a reasonably small area to cover and lots of high density areas.
R's
Andy
-----Original Message-----
From: Bob Barrett [mailto:bob.barrett@xxxxxxxxxxxxxxx]
Sent: Thursday, August 16, 2001 3:19 PM
To: Stds-802-3-Efm (E-mail)
Subject: RE: [EFM] EFM Requirements
If it is just the last / first mile, or more likely last 400 metres in
Europe, then the business case for p2p fiber makes a lot of sense. Once
there is a wayleave, probably a trunk and a draw-string, the incemental cost
of fiber becomes less onerous. And if you are pulling fiber may as well make
it multi-strand. That makes the PON business case look a bit sick. Probably
a different story in the US where the distances are longer, simply because
buildings are bigger and further apart.
It's a bit like E1 with CCS is better (in terms of channels) than the
earlier T1 with CAS, and GSM is better than the earlier PCS ;-). It's not
always good to be first, because the second player learns from the
experiences of the first market roll-out.
Bob Barrett
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Vladimir
> Oksman
> Sent: 14 August 2001 21:00
> To: Frank Miller
> Cc: 'Hugh Barrass'; Lough, Andy; Sherman Ackley; Stds-802-3-Efm (E-mail)
> Subject: 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.
> > >
> > >
>
>