RE: [EFM] EFM Requirements
Vladimir,
As a principal author of section 6.5 of T1.417, I am well of aware of the
requirements, and when I stated compliance with T1.417, I meant compliance
with all criteria, and did not feel the need to enumerate all of the
subsections (which by the way require a defined level of spectral
compatibility with ADSL, not compliance with ADSL). I would be happy to add
test cases to the extensive list submitted in March, and welcome other
copper base EFM proposals to do the same.
Patrick
-----Original Message-----
From: Vladimir Oksman [mailto:oksman@xxxxxxxxxxxx]
Sent: Tuesday, August 14, 2001 9:32 PM
To: Stanley, Patrick
Cc: 'Hugh Barrass'; Lough, Andy; Sherman Ackley; Stds-802-3-Efm (E-mail)
Subject: Re: [EFM] EFM Requirements
Patrick,
I think we need to analyze what happens when one line, for instance,
transmits medium range symmetric and other lines long range asymmetric.
Another
example, when one transmits long range symmetric and all others transmit
short
range symmetric etc. In a separated loop usually bit rate could be very
effectively exchanged for reach, but combinations in the same binder make
problems.
Regarding T1.417, as far as I understand, it states that short-term
stationary systems may be deployed, but only if they comply to the
conformance
criteria specified in section 6.5 of T1.417. I would be very interested to
see
any document which shows the compliance for high symbol rates (say, above
500
kbaud). Particularly, we need to show compliance with ADSL and plan 998.
Vladimir.
"Stanley, Patrick" wrote:
> Vladimir,
>
> My March EFM presentation contained Rate v. Reach curves under many
> scenarios, with self and mixed crosstalk, showing that capacity can be
> improved significantly vs. ADSL and VDSL. With the Spectrum Manager
> function, 100BaseCu is deployable without restriction, compliant with
T1.417
> Spectrum Management Standard, and NRICV FG3 recommendations on frequency
> usage above 1.1MHz. I added references to my July Presentation concerning
> compliance with T1.417. Private Networks are a gray area, since
demarcation
> points vary from building to building, and unless a PBX is deployed, the
> loops in the building are electrically connected to loops in the outside
> plant.
>
> Regards,
> Patrick
>
> -----Original Message-----
> From: Vladimir Oksman [mailto:oksman@xxxxxxxxxxxx]
> Sent: Tuesday, August 14, 2001 4:13 PM
> To: Stanley, Patrick
> Cc: 'Hugh Barrass'; Lough, Andy; Sherman Ackley; Stds-802-3-Efm (E-mail)
> Subject: Re: [EFM] EFM Requirements
>
> Patrick,
>
> I would say "with many limitations". And the first problem is
> spectral
> compatibility with the public network. As we face a problem of
compatibility
> between long and short loops, the compatibility between symmetric and
> asymmetric
> services plus high speed (> 5 Mb/s), it turns to be not so flexible.
> Actually, the currently operating DSL are already very close to
> the
> potential capacity. Recalling last attempts to improve ADSL, for instance,
> it
> seems to me that 5% of improvement is something I would count on.
>
> In private networks, however, the situation may be different
due
> to
> local regulations and quality requirements.
>
> Vladimir.
>
> "Stanley, Patrick" wrote:
>
> > Hugh,
> >
> > I don't think that "If you want high speed and long reach, you need more
> > pairs" is the only answer. A rate adaptive technology can offer high
> speed
> > on short loops and long reach with lower speeds.
> >
> > Regards,
> > Patrick
> >
> > -----Original Message-----
> > From: Hugh Barrass [mailto:hbarrass@xxxxxxxxx]
> > Sent: Tuesday, August 14, 2001 9: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.