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

RE: [EFM] T.V. broadcast / unicast

Sorry, I don't quite understand the cost differences between 
a) what I described, and
b) your conception of Ethernet systems. 
Let me try to be more clear as to what I am after, and please come back and tell me how my system differs from yours; again, I think this comparison could be of interest to many EFM interessees.

Bob, thanks for your referring to my previous lengthy contribution.

What I have in mind is indeed an Ethernet system, and more specifically, an 802.1D switched full duplex point-to-point Ethernet public access network, built with fiber optic links [can also use Cat5 for short length final drop].
These are something like pre-standard EFM networks that are being built today, using Enterprise-grade standard L2 Ethernet switches with optical (e.g. 1000Base-LX and 100Base-FX) interfaces. 

Several companies do this today, and the pioneers that I know of back in Europe started to build Ethernet access networks like this back in 1996-97, as limited field trials. No need to say there are operators (both new entrants and incumbents) investing in & operating these networks.
Expensive? -- Maybe, it depends on what they are compared to, and, perhaps more importantly, what are the business cases [out of scope here though].

If it is the DVB/MPEG2/IP/Ethernet content packaging you see as costly, I might agree; these Head Ends are still fairly expensive and to some extent still at a prototype stage.
If it is the IP TV CPE (Set-Top Box) that worries you, I also partly agree; these are not yet mature enough technically & have not yet reached the volumes leading to economies of scale.
However, I tend to see both of these devices as parts of a service offering, very remotely tied to subscribers' access connectivity, and I don't really think these were the components you had in mind when talking about high cost.

Just a few more words on the L3 (IP) multicast support assumed in my setup:
It is currently very common for switch makers to include a feature called 'IGMP snooping' (an L3 filtering mechanism with proprietary implementation), to realize the limited broadcast/multicast distribution mechanism desired for the IP TV application. But this is probably old news to all of you.

Finally, all, please note that what I attempted to describe above is only one of the many possible types of EFM-like Ethernet access networks; the active point-to-point topology based on new physical infrastructure.
When taking on an overall system view, capacity distribution & features usage will certainly vary between topologies, active or passive networks, etc.

Thank you,
Ingvar Froroth

> -----Original Message-----
> From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> Sent: Friday, November 23, 2001 2:40 PM
> To: bob.barrett@xxxxxxxxxxxxxxx; John Pickens;
> carlosal@xxxxxxxxxxxxxxxxxx
> Cc:;; Norman Finn
> Subject: RE: [EFM] T.V. broadcast / unicast
> Bob,
> The problem that I have with Ingvar's e-mail was that he described 
> functionality that exists on systems that cost much more than 
> Ethernet 
> systems do, starting at about 10X per megabit.  There are 
> fully loaded 
> SONET ADMS that cost less per megabit than those systems do.  
> I do not 
> believe that the EFM TF would consider that to be cost 
> effective or have 
> the "broad market potential" that is part of the 802.3 requirements.
> Thank you,
> Roy Bynum
> At 02:33 PM 11/21/2001 +0000, Bob Barrett wrote:
> >I think a lot of this depends on how the relative cost of CWDM optics
> >develops over the next two-three years. It would be far 
> simpler technically
> >to put b'cast TV (and / or user selected TV channels) on a 
> separate lambda
> >(may be not using an 802 protocol). I thought that was why 
> we are proposing
> >to leave some of the lambda bands vacant.
> >
> >I thought that the email from Ingvar was very informative.
> >
> >'Broadcasting' only the channels selected by users (probably from a
> >selection system at the POP, not at the CO) is a change of system
> >architecture from the traditional cable T.V. model. It also 
> requires powered
> >POPs. Powered POPs map well into the star / fan-out p2p 
> systems (which maps
> >into my positioning well, so I am in favour of it).
> >
> >Best regards
> >
> >Bob
> >
> >-----Original Message-----
> >From:
> >[]On Behalf Of
> >carlosal@xxxxxxxxxxxxxxxxxx
> >Sent: 20 November 2001 19:55
> >To: John Pickens
> >Cc: Norman Finn;; 
> >Subject: [EFM] Re: [EFM-P2MP] Point-to-Point plus Shared Media
> >
> >
> >
> >
> >Two comments:
> >
> >1) John Pickens said:
> >
> > > I know there is a contingent within the working group 
> that does not
> > > consider it a requirement to access the 
> single-copy-broadcast attribute
> >of
> > > the media, so probably we should poll this question at some point.
> >
> >Although I'm the first to acknowledge that my opinion is *not*
> >representative of all carriers (far from it :-), I can say that the
> >single-copy-broadcast is one of the *great* potential 
> advantages of using
> >Ethernet PON in the access network. Of course, it all 
> depends on whether
> >will we be able to provide broadcast-based services such as 
> digital video.
> >
> >I believe that many carriers will be of the same opinion.
> >
> >So my vote is already cast - single-copy-broadcasts are a 
> requirement.
> >
> >2) Norman Finn's idea is really neat from a technical *and* political
> >standpoint, as it sounds as a reasonable compromise between 
> the two fields;
> >however, I'm not sure that it's actually feasible in practice due to
> >administrative reasons, as John pointed out. It is highly 
> probable that
> >most carriers will end up using only one of the modes.
> >
> >[For instance, this already happened with DSL; almost nobody 
> uses the two
> >transmission modes of DMT modems (interleaved and fast). 
> Although it is
> >technically possible to use the two at the same time, almost 
> everybody uses
> >only the interleaved one, mainly because of the complexity, and also
> >because of potential compatibility issues]
> >
> >Anyway, just to explore the alternatives, we could deploy completely
> >separate IP networks, each over a separate MAC address (of 
> course this
> >assume that we are going to run IP over Ethernet, but who 
> bets otherwise?).
> >Each IP network could 'opt' for some particular mode of operation.
> >
> >p.s. There are also some security issues that we should 
> analyze in this
> >case; the two kinds of traffic would be received at every 
> node, and this is
> >could pose a different security problem. Not sure about it, 
> just wondering.
> >
> >
> >Carlos Ribeiro
> >CTBC Telecom