ATM comparison etc..RE: About some issues (RE: Alcatel Space interest about IP/DVB)

[<harri.hakulinen@nokia.com>]

Moro, It seems that I have already been falling behind 
      with my answers ..

> -----Original Message-----
> From: ext Kearney [mailto:clausen@cosy.sbg.ac.at]
> Sent: Thursday, April 18, 2002 3:43 AM
> >From: <harri.hakulinen@nokia.com>
> >Sent: Wednesday, April 17, 2002 3:23 AM
> 
> > Comparison to ATM
> > It is a matter of taste, if this makes any sence, but if you
> > do it, I think that it is fair to say that PID is roughly the
> > same concept as VPI(/VCI) in ATM. 
> >
> this is a point where I disagree. A  VP/VC   is basically a 
> point to point connection whereas a PID is a broadcast channel. 

Lets play that PID is analogous for point-to-multipoint VP/VC,
that is also defined in ATM. Then, what is the functional 
difference ?  

I think that "switching" or multiplexing on TS level really is
designed to work based on PID's, in the same way than it works  
on ATM based on VP/VC.

You can always do something in different way that it was designed
to work in the first place, but I am not sure if you should
(I guess that unrelated, but "a classic" example of that kind of 
 work in "IETF world" would be the consept of NAT's (Network Address
 Translators). They work, they are usefull in some cases, but overall 
 they tend to introduce lots of new/stupid problems, that were not 
 part of the original concept (end-to-end IP based routing)).

> > And, what is even more
> > interesting, mpeg section format is very close to AAL5, or
> > at least it offers the same functionality (and of course,
> > MPE builds on mpeg section format..)
>>
> AAL5 is a lot "leaner" than the Section structure which is 
> really tailored to the transmission of tables ...

I agree, that AAL5 is "leaner", but the additional fields
to section structure were added to tailor it for broadcast
kind of network..

Still I think that they have the same level of functionality.


> > Multifeed/ "satellite onboard processing" case
> >
> > If we recocnise, that PID actually forms "a connection" or "a pipe"
> > in a same sense than VPI/VCI does in ATM, it means that every
> > "feed" should use it's own PID to transmit, and every receiver
> > should receive from those PID's separately (and thus listening
> > to those feeds that it is interested in).
> >
> of course you can consider the TS packet stream conveyed by 
> one PID as a "pipe" i.e. point to point, but in general it is 
> a broadcast  channel. You can multiplex several services on one PID 
> if you introduce a discriminator ("label", "address") on the next 
> level and use this for filtering - actually both, PES and Section 
> packets have such a field called stream_id resp table_id in
> the MPEG standard.
> 

There is only one table_id (so far?) reserved for MPE. 

If you are really "multiplexing" other table_id:s to same PID,
they need to contain something else than MPE encapsulated data packets. 

You can of course introduce a swicth that is working on "MPE level" and
relies e.g. MPE MAC address on "multiplexing".

> > This also means, that "onboard swicth" in satellite systems should
> > in fact be a remux, forming an "multiprogram transport stream"
> > from incoming "singleprogram transport streams", if it is working
> > in MPEG TS level. (In other words, satellite onboard processor
> > should not be able "to mix" ts packets coming in with different
> > inputs by using the same PID.)
> >
> what is the difference between a remux and a switch ???

I quess in this context it is used to describe a device that takes
in n times "complete" Transport Streams and outputs only one. Btw,
I think that their "swithing" functionality is based on PID's..

//Harri