SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : LAST MILE TECHNOLOGIES - Let's Discuss Them Here -- Ignore unavailable to you. Want to Upgrade?


To: lml who wrote (7514)7/7/2000 6:53:58 PM
From: Frank A. Coluccio  Read Replies (2) | Respond to of 12823
 
lml, Mike, I'd like to address some of the architectural issues surrounding VDSL, in comparison to the other modes of delivery, and hopefully clear up some matters here.

[late edit: excuse the use of "Mb/s" and "Meg," below, which I use interchangeably to mean the same thing: Million Bits per Second.]

First, VDSL does not support broadcast mode. Over the air, HFC, and most Satellite TV systems support broadcast and select forms of delivery, where the channel selection is most often performed locally, in the Set-top Box. VDSL, on the other hand, supports at most three (3) program grade "sessions" simultaneously. Ordinarily, however, VDSL could be expected to support only one or two, depending on viewing habits within a home.

We've been over this before, but maybe it's not a bad idea to review it again. Head shots only require 1.5 Mb/s (although 3 Mb/s would be preferable. Movies which have been predigitized may require up to 3 Meg, but then again 6 is better.

Sporting events (especially horse racing and field sports), particularly those which are aired live, require a minimum of 6 Meg.

Full blown HDTV, according to those who propose to send it over VDSL, if and when it ever materializes, will require a minimum of 38 Meg.

HDTV's sibling in waiting, ATV (a watered down version of HDTV), might require only one-quarter of the HDTV requirement. (I could be wrong on this last bit rate, but I believe I'm in the right ball park).

And Internet access may require from 1 to 4 Meg, or more, depending on grade of service selected.

Once we know all of these requirements, we can begin to piece different scenarios together, say, where maybe..

- two NTSC sessions might be required (3.0 Meg for Casablanca and 6 Meg for the Super Bowl), in addition to...

- a watered down version of HDTV (18 Meg for The Perfect Storm), and...

- one telecommuter working at the same time requiring 4 Meg.

These services combined put us just under the bogie for the half rate (26 Mb/s) VDSL offering. As you can deduce on your own, a full HDTV requirement could not co-exist on this platform. For this we might need to move up to the next gradation of VDSL which operates at 52 Mb/s. While close to actuals, some of these figures are arbitrary, and I'm using them for illustrative purposes, since each proprietary vendor architecture may choose to treat them differently in the last mile.

Getting back to channel selection, if the channel selection is not performed locally in the VDSL model, then where is it performed?

Somewhere upstream, and it could be in different places, depending on which architecture is used. In some, it could be done all the way back at the host digital terminal location (head end, or central office). In others, it could be done somewhere between the residence and the host site, say, in a controlled environmental vault (CEV), or at the field node itself which may be a pedestal or a field cabinet where aggregate payloads are delivered in bulk over fiber and bled out to individual homes, piecemeal, via VDSL.

The implication of this should become apparent in light of some of the assumptions I've read upstream. And the most poignant one is this: VDSL does not in and of itself support 50, or 200 or 11 channels. It only supports from one to three at any one time.

Having said that, there are some other constraints in delivering video over vdsl that are of no concern to HFC systems or analog over the air systems. Namely, content must be digitized first, before it can be sent.

Real time digitization of analog feeds which have been scheduled on a program basis is not such a burden here, since techniques exist to handle this, already, most notably MPEG encoding of content streams. The real issue becomes manifest when we begin to discuss video on demand (VoD) via (or other programming which is delivered exclusively via) switched digital video (SDV) techniques, and, in particular, those which are unscheduled and not pre-recorded (live sporting events, for example).

You may not have realized it when you were writing about this, but this is exactly what you were implying would take place when a customer could choose their own 50 out of 200 channels in a laser-focused- like delivery scheme. How does the discrimination take place if not through sdv?

And a problem with sdv/vod is that most titles have not been digitized and stored on servers yet, and that leads me to the next factor, one being that of servers. Video servers are still expensive to purchase and operate, making the proliferation of vod, and some stored selections using servers impractical, still. These factors combined, one could conclude, might also lead to a fewer number of overall channels being offered by startups who support video over VDSL.

FAC