Subject: RE: Adding ULE into a network already using MPE...

From: "Allison, Art" <[email-masked]>
Date: Wed, 3 Aug 2005 14:05:49 -0400

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: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 03, 2005 11:32 AM
To: [email-masked]
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

---

From: "Allison, Art" <[email-masked]>
Date: Wed, 3 Aug 2005 15:29:18 -0400

Fixed PID associations constrain multiplexers. I suggest you seek the
complexity impact assessment (both OTO and ongoing) from mux vendors to
have a 'fixed' or 'well known' PID. MPEG2 systems folks will tell you
this is a bad thing to do.  
__________________
Art Allison
Director, Advanced Engineering
NAB Science & Technology
1771 N St NW, Washington DC 20036
202 429 5418 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 03, 2005 2:39 PM
To: [email-masked]
Subject: Re: Adding ULE into a network already using MPE...

    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" <[email-masked]>
>>Date: Wed, August 03, 2005 2:05 pm
>>To: <[email-masked]>
>>
>>    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
>>    
>>
>
>  
>

---

From: Satyajit Roy <[email-masked]>
Date: Thu, 4 Aug 2005 12:05:05 -0400

I also support distinguishing encapsulation protocols via PMT.

Satyajit

"Goldberg, Adam" <[email-masked]>
Sent by: [email-masked]
08/04/2005 11:45 AM
Please respond to ipdvb

        To:     [email-masked]
        cc: 

Sure, you can decide to not use the mechanisms already existent in an MPEG
Transport Stream (B, C), but in doing so you merely cause redesign or
purchase of special-purpose "MPEG" processing devices.

Make it a Transport Stream.  This has very little real overhead, requiring
only a PAT and PMT.  The PMT is very lightweight but yet can easily signal
which elementary streams (er, "PIDs") are encoded with what protocols.

This has many advantages:  You don't need to reinvent anything (inband
signaling) -- merely an identifying descriptor; you don't have to require
multiplexers and other non-IETF MPEG processing devices do anything 
special
(that is to say, you don't require existing MPEG processing devices to 
also
process nonstandard IETF things); IETF streams would coexist peacefully 
with
non-IETF streams in a Transport Stream; it's very extensible to other
encapsulation formats yet-to-be-defined.

Adam Goldberg
Director, Television Standards & Policy Development
Sharp Laboratories of America
8605 Westwood Center Drive, Suite 206
Vienna, VA  22182
703-556-4406
703-556-4410 fax
571-276-0305 cell

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Gorry Fairhurst
> Sent: Thursday, August 04, 2005 3:56 AM
> To: [email-masked]
> 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.
> 
> (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.
> 
> (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?
> 
> Gorry
> 
> On 3/8/05 8:39 pm, "John Border" <[email-masked]> wrote:
> >
> > 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.)
> >
possible...
> adding

---

From: "Allison, Art" <[email-masked]>
Date: Thu, 4 Aug 2005 12:33:45 -0400

After all this is transport of ULE (which is in MPEG-2 Transport Packets)...so being MPEG-2 compliant would tend to extend the utility, and not being MPEG-2 would reduce the utility.  But whatever...

__________________
Art Allison

--Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, August 04, 2005 11:45 AM
To: [email-masked]
Subject: RE: Adding ULE into a network already using MPE...

Sure, you can decide to not use the mechanisms already existent in an MPEG Transport Stream (B, C), but in doing so you merely cause redesign or purchase of special-purpose "MPEG" processing devices.

Make it a Transport Stream.  This has very little real overhead, requiring only a PAT and PMT.  The PMT is very lightweight but yet can easily signal which elementary streams (er, "PIDs") are encoded with what protocols.

This has many advantages:  You don't need to reinvent anything (inband
signaling) -- merely an identifying descriptor; you don't have to require multiplexers and other non-IETF MPEG processing devices do anything special (that is to say, you don't require existing MPEG processing devices to also process nonstandard IETF things); IETF streams would coexist peacefully with non-IETF streams in a Transport Stream; it's very extensible to other encapsulation formats yet-to-be-defined.

Adam Goldberg
Director, Television Standards & Policy Development Sharp Laboratories of America
8605 Westwood Center Drive, Suite 206
Vienna, VA  22182
703-556-4406
703-556-4410 fax
571-276-0305 cell

> On Behalf Of Gorry Fairhurst
> asking about C?
> 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?
> 
> you can easily extract framing alignment to the TS from the PUSI 
> setting in the TS header:
> 
> (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.
> 
> (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*
> 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.
> 
> 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?
> 
> Gorry
> 
> > 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...
> >> 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
> >>
> >>
> >>
> >>> 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.
> >>>
> >>>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 4 Aug 2005 10:48:19 -0700

I agree with Gorry. I think there are many ways of looking at it and
there is a trend to design signaling mechanisms that become to certain
extent independant of the actual implementation (that can depend on for
example if you MPEG steam is DVB, DCII etc) and allow ti include other
features (such as QoS) in the auto-detection.

But then, I did write a draft on this ;-)

/mjm

> From: Gorry Fairhurst <[email-masked]>
> Date: Thu, August 04, 2005 12:55 pm
> I don't see it this way.
> On 4/8/05 5:45 pm, "Goldberg, Adam" <[email-masked]> wrote:
>
> Why do you feel auto-detection of the encapsulation ( C ) implies a redesign
> of the MPEG equipment? This is a driver issue only, and orthogonal to
> supplying SI/PSI signalling. It does not stop a stream sending signalling as
> well, or imply it. It provides a way to know that you have got the right
> encaps.
>
> > multiplexers and other non-IETF MPEG processing devices do anything special
> > (that is to say, you don't require existing MPEG processing devices to also
> > process nonstandard IETF things); IETF streams would coexist peacefully with
> I think someone should gather this thread and write one or two paragraphs to
> summarise this to include in section 4 of the address resolution document
> (draft-ietf-ipdvb-ar-00.txt), especially the implications of the PSI/SI on
> the remultiplexing environment.
>
> Gorry
>
> >
> > Adam Goldberg
> >> C) I once worked through an "auto-detect mode", where you knew the PID but
> >> I note there is a reasonably strong CRC there in the ULE framing, and you
> >> (iii) It then tries reassembly of the first section as a ULE packet. If it
> >> integrity check is interpreted in more than one way in MPE). The MPE start
> >> appear as the start of a ULE field - (Note one needs to be aware that MPE
> >> 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
> >>> received.  (I think the ULE capable receivers will still need to support