[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding ULE into a network already using MPE...

A few comments in-line.

Bernhard Collini-Nocker wrote:
Just came across that (again), and am adding a few thoughts on the autodetection of MPE/ULE. 

Gorry Fairhurst wrote:
There ways to do this I can think of three, and I think John you are asking 
about C?
A) You could parse the SI/PSI signalling (if any) and extract the
information from there.
B) You could configure it (out of band) or using IP
configuration/resolution, etc.
C) I once worked through an "auto-detect mode", where you knew the PID but 
didn't know the type of encapsulation.

----

The basic rule is only one type of encapsulation is allowed for a single
PID. So how can you find out which is used?

I note there is a reasonably strong CRC there in the ULE framing, and you
can easily extract framing alignment to the TS from the PUSI setting in the 
TS header:

(i) Supposing your receiver starts as unconfigured.

(ii) The receiver looks for a PUSI setting and extracts the PP value.
Before extracting PP the value of AFC field could be checked as well. If adaptation field is present, it is clearly not ULE.
True - but there was at least two people said they would have liked AFC support (although it's not in the standard for ULE), and so I'd hate to close the door on this more, so maybe I'd urge that we ignore AFC.
(iii) It then tries reassembly of the first section as a ULE packet. If it succeeds with a valid CRC-32 and Length, it is probably safe to assume this 
is ULE.
One could do probably a little better than this in looking the first byte of the Length field, which might be a valid table_id and consequently would very unlikely be part of a reasonable ULE Length. If not cheking this some many TS cells would have to be read and skipped until the potential ULE SNDU is captured and the CRC fails. 


Agreed, this could also be a good "hint".
(iv) If the CRC fails, it tries a DSM-CC section reassembly (being aware the integrity check is interpreted in more than one way in MPE). The MPE start code is also another "hint" that this may not be ULE, but this value *could* 
appear as the start of a ULE field - (Note one needs to be aware that MPE
and ATSC use different start values).

(v) You could (probably should!!!) verify the next few SNDUs to increase
your confidence, as in any alignment algorithm.  It would also be wise to
re-initialise the detection if you suffer an alignment failure. This could 
be a result of a change of mutliplexing policy.
Note: This is orthogonal to the generation of SI/PSI tables used to control the TS multiplexing layer itself. If you use a transport stream multiplexor as a part of your L2 MPEG transmission network, this may need the SI/PSI to 
allow the PID to reach the Receiver.

Thoughts?
It is a nice exercise to think about an auto-detection mode, maybe it is even worth to continue thinking about it...
Perhaps there are some useful applications of this, the one that comes to my mind is that it is a useful tool for decoding bitstreams for analysis (aka ethereal). 


Gorry



Bernhard


On 3/8/05 8:39 pm, "John Border" <border@hns.com> wrote:


   I was thinking along those lines.  The sender associates the
encapsulation method with a particular PID and "knows" (via AR) which
PID to use to send to a particular receiver.  Receivers which only
understand MPE only use MPE PIDs.  Receivers which understand ULE and
MPE determine which method is being used by which PID is being
received.  (I think the ULE capable receivers will still need to support
MPE for multicast traffic that is shared with "older" terminals.)

   I was wondering if there is a way for the receiver to look at the
header and determine if it is ULE or MPE on the fly.  I haven't taken a
close look at it yet. But, I suspect that it is not reliably possible... 

John


Marie-Jose Montpetit wrote:



I think this is one thing that could be solved by some of the
configuration work that was started where you could associate a PID to
an encapsulation. You may not want to ignore the new encapsulation.

Marie-Jose





-------- Original Message --------
Subject: RE: Adding ULE into a network already using MPE...
From: "Allison, Art" <AAllison@nab.org>
Date: Wed, August 03, 2005 2:05 pm
To: <ipdvb@erg.abdn.ac.uk>

Use of the MRD will enable a device on a MPEG-2 network that does not
understand that MRD's signaling/meaning to ignore the new encapsulation. 


Of course if the existing network just used private data with out
signaling what it was, a problem may exist.
__________________
Art Allison
Director, Advanced Engineering
NAB Science & Technology
1771 N St NW, Washington DC 20036
202 429 5418
-----Original Message-----
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]
Sent: Wednesday, August 03, 2005 11:32 AM
To: ipdvb@erg.abdn.ac.uk
Subject: Adding ULE into a network already using MPE...


  Has anyone looked at the operational problems associated with adding
ULE use to a network which has some deployed terminals which only
understand MPE?


John