[opendtv] Re: News: TV Braces for the Apple Tablet

  • From: Kon Wilms <konfoo@xxxxxxxxx>
  • To: opendtv@xxxxxxxxxxxxx
  • Date: Mon, 1 Feb 2010 16:59:42 -0800

On Sun, Jan 31, 2010 at 2:57 PM, Manfredi, Albert E
<albert.e.manfredi@xxxxxxxxxx> wrote:
> Can you explain what "peer to peer broadcasting" means? Does it mean that the 
> cell phones create an adhoc network among themselves, each one forwarding the 
> multicast packets on to another cell phone within range that is also 
> indicating interest in joining that multicast group, without involving a cell 
> tower? (I find that hard to believe for cell phones, although MANET does try 
> to implement just such scenarios.)

Well first I have to say that none of this is automatic. It is all
configured at the application/player widget level in the code. So the
operator can turn it on (or not).

In the peer to peer broadcasting model the first 'receiver' runs,
attempts to join a multicast group, fails, tunes to the local edge
unicast stream, and starts decoding content, configuring itself to use
it's upstream (which translates also to 'local network segment')
bandwidth to feed additional peers via e.g. multicast. When 'receiver'
2 starts, it finds the local multicast broadcast from receiver 1 and
decodes the content locally.

This entire situation starts to get more interesting if you look at
the fact that the same featureset is available across platforms be
that desktop, mobile, or embedded.

So the obvious step is your tablet running a constant 3G connection
also dual homed to a local Wifi LAN pulls a stream over 3G and the
first receiver on the LAN which may be a desktop, pulls the multicast
not from the cable WAN but from the 3G device when it hits the same
website with the same video player.

This also means that Flash embedded in TV/STB systems can now do IP
multicast. Interesting possibilities.

> Yes, the ability to switch from 3G to WiFi, when WiFi is available, has been 
> around for some time. I don't see how this changes anything, though. In WiFi 
> hot spots, WiFi can offload traffic from the 3G cell. 3G picocells have 
> exactly this same effect. Used mostly for indoor coverage, the picocell also 
> offloads traffic from the outdoor macrocell. All you are pointing out here, 
> in effect, is that if the cell companies REDUCE THE SIZE of their cells, they 
> can achieve greater spectrum reuse. Of course, I agree with that.

Well my point was that the user interfaces are now abstracting the
data call types. I use the same phone dialer to dial skype as I do to
dial a regular number. The same goes for SMS and IM. I realize that
some hardware like Apple has 'an app for that'. But they will catch up
eventually.

>> You also forget about HTTP being the new delivery mechanism
>> for live broadcasts from CDNs, where any HTTP cache can cache
>> content at any edge location.
>
> Again, I don't see the relevance. The big issue here is lack of RF spectrum 
> for cellular network traffic, not so much lack of bandwidth in the backhaul 
> network. Although that too is an issue, it is not the issue the FCC has to 
> solve. If you have the TV programming stored at the edges of the backhaul 
> network, transmitting that programming to individual cell phones, over the 
> normal unicast cellular links, is what causes the RF capacity problem.

If they were smart they would look at the devices and notice that 32Gb
is the norm these days. It would not be hard to see an extension of
podcasting with minor intelligence to handle 80% of the traffic as
pre-cached content. Maybe ATT should quit their whining about how
their network can't cope with the iPhone and how Verizon is wronging
them, and sit down with Apple to push apps that take advantage of
intelligent caching when the device is in a multi-homed state. But
that would be too easy.

Cheers
Kon
 
 
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:

- Using the UNSUBSCRIBE command in your user configuration settings at 
FreeLists.org 

- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word 
unsubscribe in the subject line.

Other related posts: