Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] EFM Requirements




'It is now clear that packet voice will be VoIP.'

Clear to whom exactly, and, more to the point, when will it happen? I
observed that the NGN flyer for the autumn conference stated something along
the lines that 80% plus of PBX systems would be replaced by VoIP this year,
dream on. There are other ways to deliver 'packet voice' that don't require
PBX systems and C5 switches to be replaced, nor the purchase of capital
intensive softswitches.

In May 2000 at NGNV John made a statement that new generation (metro / core)
equipment manufacturers would flourish on the back of well funded new
generation service providers (CLECs). In May 2001 at NGNV John was gracious
enough to eat the required portion of humble pie. Personally I don't buy
into the sentiment of the second sentence of the following quote. If people
on this exploder can support the NGN statement with hard data then I would
be happy to eat the appropriate portion of humble pie myself :-).

Bob

Quote from NGN email flyer:

Consider a few of the major changes ahead in networking.

We expect that nearly every large enterprise will soon replace
its PBX systems with IP-based products.

Today's frame relay and ATM networks, both private and
public, are reaching the end of their useful life. There will be a battle
among the various contemporary alternatives: network-based VPNs, encrypted
tunnels, and transparent Ethernet services (VLANs operating at Layer 2). As
broadband connectivity reaches millions of new businesses and residences
each year, important questions arise. A critical part of the cost
justification for broadband is the unification of voice and data services
onto a single bearer service. But are QoS technologies up to the challenge?
Are there customers who have successfully converged all their traffic onto
IP? The debate continues between building specialized overlays and
improving IP to the point that it can do "everything."

End quote

> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Sherman
> Ackley
> Sent: 16 August 2001 14:12
> To: 'Vladimir Oksman'
> Cc: 'Stds-802-3-Efm (E-mail)'
> Subject: RE: [EFM] EFM Requirements
>
>
>
> For the one application, yes.  But keep in mind that designing
> for a single
> application will force other designs, one for each application.
> That is why
> today we have ADSL, VDSL, SHDSL,HDSL, HDSL2, etc.
>
> Would it not be better to design one line card and one PHY that
> was flexible
> enough to do all of those jobs.  Today 10/100 baseT can do it for short
> distances over CAT 5 wiring.
>
> The only service that does not have to be supported is circuit switched
> voice over TDM or ATM.  It is now clear that packet voice will be VoIP.
>
> -----Original Message-----
> From: Vladimir Oksman [mailto:oksman@xxxxxxxxxxxx]
> Sent: Wednesday, August 15, 2001 6:36 PM
> To: Sherman Ackley
> Cc: 'Stds-802-3-Efm (E-mail)'
> Subject: Re: [EFM] EFM Requirements
>
>
>
> Thank you, Sherman,
>
>       so we come to 9.5Mb/s for a "regular" customer possible
> downgrades in
> the
> bit rate for out-ranging ones. However, this number you got putting two
> video
> channels which are in principal asymmetric. Here I come to a requirement:
> Downstream = 9.5 Mb/s
> Upstream      = 1.5 Mb/s + 1.5 Mb/s = 3 Mb/s (I added another 1.5 Mb/s for
> better data interactive services).
>
> Looks close to the original VDSL requirement 22/3 Mb/s!
>
> Am I interpreting you right?
>
> Vladimir.
>
>
>
> Sherman Ackley wrote:
>
> > Before you can determine a minimum bit rate, the application needs to be
> > determined.  Today, the high bit rate services are connections to web
> > hosting sites, corporate LANs and for video delivery to consumers.
> >
> > For the business customer, they only have a choice of a T1/E1
> private over
> a
> > SHDSL connection.  What would be ideal is if the bandwidth could operate
> > like an ethernet LAN in that it could go 1 Mbps outbound while going 5
> Mbps
> > inbound and the next instant go 4 Mbps outbound and 2 mbps inbound.
> >
> > For the consumer, most carriers are looking at being able to provide
> > integrated broadband services which would include VoIP,  two MPEG-2 @4
> Mbps
> > each and internet access at about 1 Mbps.  When you add 2 each
> @4 Mbps + 1
> > Mbps + 500 Kbps you get about 9.5 Mbps.  It would be nice to be
> able to do
> > this for the Copper serving area out of the CO or DLC serving
> area.  That
> is
> > about 12,000 ft.
> >
> > The system should be symmetrical in terms of the maximum bit rate.  It
> does
> > not mean that it should be two way simultaneous at the same bit
> rate.  For
> > example, a T1 provides 1.536 Mbps simultaneously in both
> directions for a
> > total 3.072 Mbps.  In the case of ethernet, the 10 Mbps can be used
> > alternatively in either direction or dynamically allocable as needed
> between
> > the two directions.  ADSL has a fixed 6:1 traffic ratio.  That
> is, if the
> > outbound is 6 Mbps, the inbound is 1 Mbps for a total of 7 Mbps.  If you
> > need 2 Mbps for inbound, you are out of luck.
> >
> > I have not personally installed an FS-VDSL service at a home so
> that I am
> > not fully aware of the complexities.
> >
> > -----Original Message-----
> > From: Vladimir Oksman [mailto:oksman@xxxxxxxxxxxx]
> > Sent: Wednesday, August 15, 2001 4:15 PM
> > To: Sherman Ackley
> > Cc: 'Stds-802-3-Efm (E-mail)'
> > Subject: Re: [EFM] EFM Requirements
> >
> > Sherman,
> >
> >      I have a sympathy to this list of 5 - seems as a strong
> step forward.
> > Some
> > small questions.
> > 1. You say: "Reach is more important that bit rate". What is the minimum
> bit
> > rate you keep in mind?
> >
> > 2. You say: "data rate needs to be dynamically allocable between
> downstream
> > and
> > upstream flows". Does it mean that system actually is not required to be
> > symmetric (or "about symmetric")?
> >
> > 3. From some discussions in FS-VDSL I got an impression that VDSL will
> > require
> > some installation at the NID (because people still don't believe that it
> > could
> > run over the home wiring) including connection to the CPE
> gateway. Does it
> > sound
> > acceptable?
> >
> > Thankfully,
> >
> > Vladimir.
> >
> > Sherman Ackley wrote:
> >
> > > It is great to get more practical field experience and information to
> help
> > > in defining the requirements for the EFM working group.
> > >
> > > Seems we are arriving at a consensus that some things that
> are important
> > > requirements.  These include:
> > > 1. Reach is mort important than raw bit rate.
> > > 2. Self install by an untrained consumer is a must.
> > > 3. The home network hides behind a gateway/firewall of some kind for
> > > security resons.
> > > 4. There are at least 5 home networking technologies.  These are
> 10-baseT
> > on
> > > new dedicated CAT5 data wiring, HomePNA on the existing phone line,
> 802.11
> > > wireless and HomePlug over the power line, and I almost forgot HomeRF
> > > (excuse me for saying it to an 802 group)
> > > 5. You cannot predict what consumers will use it for,
> therefore the data
> > > rate needs to be dynamically allocable between downstream and upstream
> > > flows.
> > >
> > > When multiple services ride over the same physical media, it is
> desireable
> > > that they not interfere with each other.
> > >
> > > One of the best frequency coordination jobs was done by the video
> > industry.
> > > It is possible to place Cable Modem, off air TV, CATV and DBS on the
> same
> > > coax without interference.  Today, the same is true with analog voice,
> > ADSL
> > > and HomePNA.  It is not true with VDSL.
> > >
> > > Since you install DOCSIS modems, did you notice that you can put the
> modem
> > > on any video outlet and it works.  You can also move it to
> another room
> > and
> > > it will work.
> > >
> > > It would be interesting to find out what percent of ADSL installations
> use
> > > splitters versus filters.  Does any one have any statistics on this?
> > >
> > > -----Original Message-----
> > > From: Fletcher E Kittredge [mailto:fkittred@xxxxxxx]
> > > Sent: Wednesday, August 15, 2001 12:23 PM
> > > To: Sherman Ackley
> > > Cc: Stds-802-3-Efm (E-mail)
> > > Subject: Re: [EFM] EFM Requirements
> > >
> > > On Mon, 13 Aug 2001 11:31:06 -0400  Sherman Ackley wrote:
> > > > 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.
> > >
> > > Sherman;
> > >
> > >         I'm in the rural Northern New England market.  We have a fair
> > > number of rural phone companies up here; they serve about 18% of the
> > > market.
> > >
> > >         I don't understand the "essential" statement above.  Does this
> > > mean that if EFM doesn't work with HomePNA, EFM is worthless or is
> > > there some other definition of "essential".  Where the 75% figure
> > > comes from?
> > >
> > >         It sounds like you have a good, detailed understanding of how
> > > the customer will use this protocol.  My experience has been that it
> > > is difficult to predict in less than the most general terms how
> > > a protocol will be used.  Two illustrations which are vivid to me are
> > > ATM, which was to replace the Internet protocols, and DSL, which was
> > > to allow video on demand over phone lines.
> > >
> > > > Finally, feedback on these ideas from other service providers and
> > vendors
> > > is
> > > > invited.
> > >
> > > I think your emphasis on the importance of reach is spot on and I
> > > could not agree more.  I think the analysis of how the service will be
> > > used should not be used to make decisions.  It is impossible to know.
> > >
> > > regards,
> > > fletcher
>