Re: [EFM] EFM Requirements
Andy,
I understand your point. There always will be facilities which can't
be currently reached by the desired service solution. Particularly, for
5.5km you mentioned I expect the bit rate of anout 128-200 Kbit/s. That
could be done and actually is already done by RADSL, SHDSL and maybe
others. Does it solve your problem?
Vladimir.
"Lough, Andy" wrote:
> Vladimir,
>
> the majority of users live well within 10 miles of an exchange. Assuming carriers cant afford to dig up all the roads in our countries and install fibre (god help us the traffic is bad enough already), they will look to use the established physical infrastructure. This will be mixed. In city centres to MTUs and enterprise offices fibre will be the answer. In new build estates, again fibre and PON I would agree may be the answer. I do however have some concerns over it's ability to support lifeline voice for emergencies in the case of a powercut.(assuming a converged service provision of voice video data)
>
> However, the vast majority of installs for the forseeable future will come by using the existing copper fed from existing exchanges, so we need to ensure we can engineer EFM for Copper into this model. here in the UK BT are looking at RADSL because they need more reach on their services, and I've seen 5.5Km mentioned as their goal for distance from last mile solutions.
>
> R's
>
> Andy
> -----Original Message-----
> From: Vladimir Oksman [mailto:oksman@xxxxxxxxxxxx]
> Sent: Tuesday, August 14, 2001 9:00 PM
> 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.
> > >
> > >