Subject: RE: Adaptation field use in ULE / MPG2-TS specification

From: "William StanisLaus" <[email-masked]>
Date: Thu, 20 May 2004 12:37:35 +0530

Hi,
	Is there any decision/conclusion made by the work group on Adaption field
use in ULE by MPEG2-TS.

Best Regards,
William.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On
> Behalf Of William StanisLaus
> Sent: Friday, April 16, 2004 7:54 PM
> To: [email-masked]
> Subject: RE: Adaptation field use in ULE / MPG2-TS specification
>
>
>
>
> Let me add my understanding with MPEG2-TS decode.
>
> transport_packet(){
>         sync_byte
> 8 bslbf
>         transport_error_indicator
> 1 bslbf
>         payload_unit_start_indicator
> 1 bslbf
>         transport_priority
> 1 bslbf
>         PID
> 13 uimsbf
>         transport_scrambling_control
> 2 bslbf
>         adaptation_field_control
> 2 bslbf
>         continuity_counter
> 4 uimsbf
>         if(adaptation_field_control=='10' ||
> adaptation_field_control=='11'){
>               adaptation_field()
>         }
>         if(adaptation_field_control=='01' ||
> adaptation_field_control=='11')
> {
>              for (i=0;i<N;i++){
>                  data_byte
> 8 bslbf
>             }
>        }
> }
>
> here PUSI, says the start of new payload or continuation of
> the pervious
> payload for this MPEG packet.
> i.e. if PUSI = 0 , continuation/end of the previous payload
> and PUSI = 1
> start of new payload.
>
> NOTE the packet is identified based on the PID.
>
> Continuity counter plays a decent role, if the MPE packet
> doesn't fit in one
> MPEG header.
>
> Regarding Adaptation field, i have already explained in detail.
>
> Tor's concern (if i am not wrong) is "transport private data"
> in adaptation
> field which he wants to use to carry some private information
> within his
> network, which is purely internal and propieratory, which he
> uses for his
> network management. and also he is concerned that, his
> transport private
> data is going to be less than 50 bytes say for example and
> doesn't want to
> waste rest of the payload capacity, hence he wants to club
> with the traffic
> payload, so he updates the adaptation field control as "11".
> i.e it contains
> adaptation field as well as SNDU payload. BUT ULE draft
> doesn't support this
> AFC and discards the packet.
>
> Tor correct me if my understand is wrong.
>
> Best Regards,
> William.
>
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On
> > Behalf Of Gorry Fairhurst
> > Sent: Friday, April 16, 2004 6:43 PM
> > To: [email-masked]
> > Subject: Re: Adaptation field use in ULE / MPG2-TS specification
> >
> >
> > I'm interested in use-cases that could illustrate how the
> AF would be
> > used (if equipment supported this) with ULE TS.
> >
> > Can you give me more details of what how you see an AF
> being added by
> > some "lower layer" equipment, and how this
> > could actually be used with a stream of SNDUs using ULE?
> >
> > Tor Brekke wrote:
> >
> > >
> > > In the MPG transport stream packet definition the MPG
> > header format is
> > > defined. There is an explicit exception for the PUSI bit which the
> > > standard does not define for private data (in this context
> > I guess ULE
> > > must be considered private). All other fields are defined either
> > > independent of the payload type. I interpret this to say
> > that we are
> > > not free to redefine the use of the adaptation field for a
> > new payload
> > > type,
> >
> >  >>> The following worries/interests me, specifically
> > - does this assume the "lower layer processing" understands the
> > semantics of the PUSI?
> > Can you explain what you mean by this statement, so that we can
> > understand the full implications...
> >
> > > and that adaptation fields may be inserted at lower layers
> > (seen from
> > > the MPG layer the payload is only a stream of octets, possibly
> > > including synchronisation points as signalld by PUSI).
> > >
> > > Note again that we are not interested in enforcing the use of the
> > > adaptation field in other systems. We only want to ensure
> > that ULE can
> > > be used on systems which use the adaptation field.
> > >
> > > --Tor
> > >
> > >
> > >
> > >
> > > "HDClausen" <[email-masked]>
> > > Sent by: [email-masked]
> > >
> > > 14.04.2004 21:45
> > > Please respond to
> > > [email-masked]
> > >
> > >
> > >
> > > To
> > > 	<[email-masked]>
> > > cc
> > >
> > > Subject
> > > 	Re: Adaptation field use in ULE / MPG2-TS specification
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > Explicitly
> > > > prohibiting this in the ULE specification seems to be
> in violation
> > > > the MPG2 specification (i.e. ISO/IEC-13818-1).
> > >
> > > Could you, please, indicate where in the decument I can find this.
> > > Art Allison wrote: "Only PES or PSI structures are
> standardized for
> > > carriage
> > > by 13838-1 in
> > > MPEG-2 TS packets." If that is the case (and this is what I
> > understood
> > > from
> > > the document) than any other use is not in violation with
> > MPEG-2 but with
> > > something else i.e. the question is: is DVB-RCS imposing a
> > recommendation
> > > which is not (yet) required by MPEG-2.
> > >
> > > This does not mean we should not discuss this subject and
> > come up with a
> > > solution.
> > >
> > > --H. Clausen
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Tor Brekke" <[email-masked]>
> > > To: <[email-masked]>
> > > Cc: <[email-masked]>; <[email-masked]>
> > > Sent: Wednesday, April 14, 2004 1:01 AM
> > > Subject: Re: Adaptation field use in ULE / MPG2-TS specification
> > >
> > >
> > > > Want to fill in somewhat to William's detailed answer.
> > > >
> > > > 1)  There is a proposal in DVB-RCS to utilise the
> > adaptation field to
> > > > perform inband signalling for the DVB-RCS network. This
> > signalling
> > > has to
> > > > be independent of the higher layers, as it has to be
> > available before
> > > > these are up (same applies for Ethernet, which may of
> > course not even be
> > > > present). This was the reason for bringing this up in the first
> > > place. The
> > > > problem is more general though. The adaptation field can
> > be used by the
> > > > MPG2-TS layer (ref. William's detailed explanation). Explicitly
> > > > prohibiting this in the ULE specification seems to be in
> > violation with
> > > > the MPG2 specification (i.e. ISO/IEC-13818-1).
> > > >
> > > > 2) All receivers should as a minimum be able to rip off
> > the field. As
> > > > William S. says this is part of MPG processing and should not
> > > concern ULE
> > > > at all (unless you have a specific design in mind....).
> > In any case the
> > > > performance hit of checking one bit and throwing away some data
> > > every now
> > > > and then (most likely never in most systems) should not affect
> > > performance
> > > > much.
> > > >
> > > > --Tor Brekke
> > > >
> > > >
> > > >
> > > >
> > > > Gorry Fairhurst <[email-masked]>
> > > > Sent by: [email-masked]
> > > > 13.04.2004 17:59
> > > > Please respond to
> > > > [email-masked]
> > > >
> > > >
> > > > To
> > > > [email-masked]
> > > > cc
> > > >
> > > > Subject
> > > > Re: Adaptation field use in ULE / MPG2-TS specification
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > So... as I recall, the rationale behind the current rev. was:
> > > >
> > > > 1) There was no stated requirement for the Adaptation Field
> > > > when used with ULE, if this requirement has emerged, then
> > > > I think we need to know what function is being propossed
> > > > and why this is performed at the MPEG-2 layer, rather than
> > > > at the IP/Ethernet layers. Please send text!
> > > >
> > > > 2) There is a cost at adding Adaptation Field processing, in
> > > > that it impacts implementation/performance of the ULE receiver.
> > > > This has a performance hit, if it is mandatory to support it.
> > > > If it is optional, then there is a compatability hit.
> > > >
> > > > Thoughts?
> > > >
> > > > Gorry
> > > >
> > > > P.S. Note: ULE does *NOT* use the PES syntax for the data
> > > > sent on these streams.
> > > >
> > > > William StanisLaus wrote:
> > > >
> > > > > Here ULE is not preventing use of lower level MPEG2
> > packet header
> > > > > fields, rather we should figure out why we drop the
> > packet based on
> > > > > the adaptation field control, is there any reason
> > behind to specify in
> > > > > the draft to drop packets other than AFC is "01"
> > > > >
> > > > > In the case of adaptation field, which is coupled
> with MPEG2-TS
> > > > > header, itself will be decoded and action could have
> > taken well before
> > > > > the control reaches ULE. Hence the goal of adaptation field is
> > > > > accomplished, if it is going to be a sequential/linear
> > processing. But
> > > > > the question is, when the AFC is "11" in such case
> > MPEG2-TS payload
> > > > > contains both adaptation field private section data and
> > actual payload
> > > > > (SNDU),  SNDU payload processing will be dropped as per
> > the ULE draft.
> > > > >
> > > > > Best Regards,
> > > > > William.
> > > > >
> > > > >     -----Original Message-----
> > > > >     From: [email-masked]
> > > > >     [mailto:[email-masked]]On Behalf Of
> > Allison, Art
> > > > >     Sent: Tuesday, April 13, 2004 6:51 PM
> > > > >     To: [email-masked]'
> > > > >     Subject: RE: Adaptation field use in ULE / MPG2-TS
> > specification
> > > > >
> > > > >     I agree with Tor (and am a bit chagrined that I
> > didn't notice
> > > > >     this). The ULE draft should not prevent use of the
> > 'lower' level
> > > > >     MPEG-2 packet header fields, and that included the
> > adaptation
> > > > >     field.  A key concept ( Tor's point #2) in MPEG-2
> > systems is the
> > > > >     layering with each layer having a separable
> > function. Building
> > > > >     vertically integrated designs that constrain this
> > reduce long term
> > > > >     flexibility and can have other impacts like the one Tor
> > > identified.
> > > > >
> > > > >     However, now that I glance at the header
> > structure...to send this
> > > > >     data in TS packets, 'payload start indicator'  must
> > be set to a
> > > > >     value. It is one bit, where 0= no PES start in this
> > packet, and 1=
> > > > >     PES or PSI start in this packet. Suggest define
> > that it be set
> > > to 0.
> > > > >
> > > > >     Art
> > > > >     ::{)>
> > > > >     Art Allison
> > > > >     Director Advanced Engineering
> > > > >     NAB
> > > > >     1771 N St NW
> > > > >     Washington DC 20036
> > > > >     202 429 5418
> > > > >
> > > > >         -----Original Message-----
> > > > >         From: William StanisLaus
> [mailto:[email-masked]]
> > > > >         Sent: Tuesday, April 13, 2004 8:18 AM
> > > > >         To: [email-masked]
> > > > >         Subject: RE: Adaptation field use in ULE / MPG2-TS
> > > specification
> > > > >
> > > > >         Hi Marie-Jose,
> > > > >             I understand your point here about
> > extension headers. But
> > > > >         actually Adaptation field specified here is part of
> > > > >         MPEG2-TS header and not ULE, in that case
> even ULE is a
> > > > >         payload for MPEG2-TS. If adaption field control
> > is 10 or 11 in
> > > > >         bits, MPEG2-TS contains private adaption field,
> > and incase of
> > > > >         "10" we need not care about anything, but still
> > ULE draft says
> > > > >         anything other than " 01" in AFC, receiver
> MUST discard.
> > > > >             Thanks for your comment Tor Brekke, but i
> > wonder why we
> > > > >         have such limitation in ULE, even though we are
> > not worried in
> > > > >         ULE about the MPEG2-TS private section of
> > Adaption field, if
> > > > >         we are not going to take any action based on
> > the adaption
> > > > >         field and control field we can just ignore. I
> > see this as an
> > > > >         implementation issue and should not be limited in
> > > > >         specification/draft.
> > > > >
> > > > >         transport_packet(){
> > > > >
> > > > >         sync_byte
> > > > >         8 bslbf
> > > > >
> > > > >          transport_error_indicator
> > > > >         1 bslbf
> > > > >
> > > > >          payload_unit_start_indicator
> > > > >         1 bslbf
> > > > >
> > > > >         transport_priority
> > > > >         1 bslbf
> > > > >
> > > > >          PID
> > > > >         13 uimsbf
> > > > >
> > > > >          transport_scrambling_control
> > > > >         2 bslbf
> > > > >
> > > > >          adaptation_field_control
> > > > >         2 bslbf
> > > > >
> > > > >          continuity_counter
> > > > >         4 uimsbf
> > > > >                 if(adaptation_field_control=='10' ||
> > > > >         adaptation_field_control=='11'){
> > > > >                       adaptation_field()
> > > > >                 }
> > > > >                 if(adaptation_field_control=='01' ||
> > > > >         adaptation_field_control=='11') {
> > > > >                      for (i=0;i<N;i++){
> > > > >
> > > > >            data_byte
> > > > >                                                    8 bslbf
> > > > >                     }
> > > > >                }
> > > > >         }
> > > > >
> > > > >         here N data_byte's is SNDU as specified by ULE.
> > > > >
> > > > >         Also ULE cannot limit anything on exisiting underlying
> > > > >         protocol as such MPEG2-TS. But definitly it
> can limit or
> > > > >         provide more services to above layers.
> > > > >
> > > > >
> > > > >         Best Regards,
> > > > >         William StanisLaus
> > > > >         CalSoft, Nortel Networks Division
> > > > >
> > > > >
> > > > >             -----Original Message-----
> > > > >             From: [email-masked]
> > > > >             [mailto:[email-masked]]On Behalf Of
> > > > >             Marie-Jose Montpetit
> > > > >             Sent: Tuesday, April 13, 2004 4:00 PM
> > > > >             To: [email-masked]
> > > > >             Subject: Re: Adaptation field use in ULE / MPG2-TS
> > > > >             specification
> > > > >
> > > > >             Thanks for you input. If you follow recent
> > discussions
> > > > >             there is a proposal to use extension
> > headers in ULE to
> > > > >             support system specific signalling (and
> > other). It would
> > > > >             be interesting to know more about how you
> > process the
> > > > >             information but I think our philosophy
> > would be to use the
> > > > >             headers in the same way as you describe:
> > transparent to
> > > > >             system who do not know what to do with
> > them, processed by
> > > > >             the ones who do. This is consistent with
> > IPv6 extension
> > > > >             headers and also with other implementations
> > of extension
> > > > >             headers (cable for example).
> > > > >
> > > > >             So I do believe we could use ULE in RCS.
> > Actually in a
> > > > >             recent study sponsored by ESA we showed
> > that for traffic
> > > > >             with a lot of ACK bursts (http: for
> > example) ULE was very
> > > > >             efficient because of it's packing capability.
> > > > >
> > > > >             Again thanks for your input.
> > > > >
> > > > >             Marie-Jose
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >                 ----- Original Message -----
> > > > >                 From: Tor Brekke
> <mailto:[email-masked]>
> > > > >                 To: [email-masked]
> > > <mailto:[email-masked]>
> > > > >                 Sent: Tuesday, April 13, 2004 3:02 AM
> > > > >                 Subject: Adaptation field use in ULE / MPG2-TS
> > > > >                 specification
> > > > >
> > > > >
> > > > >                 Hello,
> > > > >
> > > > >                 I am jumping into this discussion at a
> > fairly late
> > > > >                 stage. Having just read the ULE draft I
> > have to make a
> > > > >                 comment about the use of the adaptation
> > field though.
> > > > >                 In the draft it says that "TS Packets
> from a ULE
> > > > >                 Encapsulator MUST be sent with an AFC
> > value of '01'",
> > > > >                 i.e. without adaptation field. Now the
> > adaptation
> > > > >                 field contains a private field which
> > according to the
> > > > >                 MPG2-TS specification (ISO/IEC 13818-1)
> > can be used to
> > > > >                 transmit system dependent data.
> > > > >                 Now to the question: Why is this
> > limitation imposed on
> > > > >                 ULE?
> > > > >
> > > > >                 I have two main reasons to ask this.
> > > > >                 1) Firstly there is ongoing work to use
> > the private
> > > > >                 adaptation field for network internal
> > signalling in
> > > > >                 the DVB-RCS standard. This means that
> > ULE will not
> > > > >                 work over DVB-RCS systems employing the
> > adaptation
> > > > >                 field signalling.
> > > > >                 2) As far as I have been able to
> > determine all other
> > > > >                 encapsulation forms over MPG2-TS are
> > transparent to
> > > > >                 the adaptation field, i.e. the
> > adaptation field and
> > > > >                 payload are handled independently (even
> > though there
> > > > >                 may be an implicit connection between
> > them). It seems
> > > > >                 strange to break this logicinf the
> > MPG2- TS mechanism
> > > > >                 for a new encapsulation type.
> > > > >
> > > > >                 Best Regards
> > > > >                 Tor Brekke
> > > > >                 Nera Broadband Satellite AS.
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
>