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

From: "Allison, Art" <[email-masked]>
Date: Tue, 13 Apr 2004 09:21:08 -0400

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  <mailto:[email-masked]> Brekke 
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.

---

From: "William StanisLaus" <[email-masked]>
Date: Tue, 13 Apr 2004 20:21:43 +0530

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

    -----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,

    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
                }
           }
    }

    Best Regards,
    William StanisLaus

      -----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).

      Marie-Jose

        ----- Original Message -----
        From: Tor Brekke
        To: [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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 13 Apr 2004 16:59:45 +0100

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.
>
>     [mailto:[email-masked]]On Behalf Of Allison, Art
>     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
>             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
>               
>         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
>             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
>             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.
>              
>                 From: Tor Brekke <mailto:[email-masked]>
>                 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
>                 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

---

From: "William StanisLaus" <[email-masked]>
Date: Wed, 14 Apr 2004 10:06:12 +0530

Please see the comments inlined

Best Regards,
William.

> [mailto:[email-masked]]On
> Behalf Of Gorry Fairhurst
> Sent: Tuesday, April 13, 2004 9:30 PM

William> Adaptation field is more of a private section/data which is
optional to carry some useful information for satellite network. for
example, discontinuity indicator, random access indicator...., also
"transport private data" where you can send the propieratory data within the
network.

Also adaptation field is per MPEG2-TS header and not for ULE/IP etc.
headers. Means single SNDU can be distributed across MPEG2-TS. In that case
it is NOT required all the MPEG2-TS for this particular SNDU MUST carry
adaptation field.

mm when we read more into MPEG2-TS header,
transport_scrambling_control -- This 2 bit field indicates the scrambling
mode of the Transport Stream
packet payload. The Transport Stream packet header, and the ADAPTATION FIELD
when present, SHALL NOT be
SCRAMBLED. In the case of a null packet the value of the
transport_scrambling_control field shall be set to '00'.
- which is payload scrambling we were discussing sometime before.

The format of adaptation field if present ( AFC is 10 || 11 )

adaptation_field() {
     adaptation_field_length                           8 uimsbf
     if(adaptation_field_length >0) {
        discontinuity_indicator                        1 bslbf
        random_access_indicator                        1 bslbf
        elementary_stream_priority_indicator           1 bslbf
        PCR_flag                                       1 bslbf
        OPCR_flag                                      1 bslbf
        splicing_point_flag                            1 bslbf
        transport_private_data_flag                    1 bslbf
        adaptation_field_extension_flag                1 bslbf
        if(PCR_flag == '1') {
            program_clock_reference_base               33 uimsbf
            reserved                                   6 bslbf
            program_clock_reference_extension          9 uimsbf
        }
        if(OPCR_flag == '1') {
            original_program_clock_reference_base      33 uimsbf
            reserved                                   6 bslbf
            original_program_clock_reference_extension 9 uimsbf
        }
        if (splicing_point_flag == '1') {
            splice_countdown                           8 tcimsbf
        }
        if(transport_private_data_flag == '1') {
            transport_private_data_length              8 uimsbf
            for (i=0; i<transport_private_data_length;i++){
               private_data_byte                       8 bslbf
            }
        }
        if (adaptation_field_extension_flag == '1' ) {
            adaptation_field_extension_length          8 uimsbf
            ltw_flag                                   1 bslbf
            piecewise_rate_flag                        1 bslbf
            seamless_splice_flag                       1 bslbf
            reserved                                   5 bslbf
            if (ltw_flag == '1') {
               ltw_valid_flag                          1 bslbf
               ltw_offset                              15 uimsbf
            }
            if (piecewise_rate_flag == '1') {
               reserved                                2 bslbf
               piecewise_rate                          22 uimsbf
            }
            if (seamless_splice_flag == '1'){
               splice_type                             4 bslbf
               DTS_next_AU[32..30]                     3 bslbf
               marker_bit                              1 bslbf
               DTS_next_AU[29..15]                    15 bslbf
               marker_bit                              1 bslbf
               DTS_next_AU[14..0]                     15 bslbf
               marker_bit                              1 bslbf
            }
            for ( i=0;i<N;i++) {
               reserved                                8 bslbf
            }
        }
        for (i=0;i<N;i++){
            stuffing_byte                              8 bslbf
        }
     }
}

> If it is optional, then there is a compatability hit.

William> To my knowledge the processing of Adaptation Field is part of
MPEG2-TS, and not ULE or any other MPE in that case.
Please correct me if i'm wrong.
> >                 To: [email-masked]
<mailto:[email-masked]>

---

From: Tor Brekke <[email-masked]>
Date: Wed, 14 Apr 2004 10:01:31 +0200

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

Thoughts?

Gorry

---

From: "HDClausen" <[email-masked]>
Date: Wed, 14 Apr 2004 12:45:48 -0700

> Explicitly
> prohibiting this in the ULE specification seems to be in violation

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 15 Apr 2004 15:09:28 +0100

Just taking the second point, because the first is being debated in 
another thread...

Allison, Art wrote:

<snip>

> 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

Art, is this an issue, or is the current ID clear?

Section 3 para 2 onwards of:

http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-00.txt

says:

        The ULE encapsulation is limited to TS private streams only. The
        header of each TS Packet carries a one bit Payload Unit Start
        Indicator (PUSI) field. The PUSI identifies the start of a payload
        unit (SNDU) within the MPEG-2 TS Packet payload. The semantics of
        the PUSI bit are defined differently for PES and PSI packets [ISO-
        MPEG]; for private data, its use is not defined in the MPEG-2
        Standard. In ULE, the operation follows that of PSI packets. Hence,
        the following PUSI values are defined:
        
             0: The TS Packet does NOT contain the start of a SNDU, but
             contains the continuation, or end of a SNDU;
             
             1: The TS Packet contains the start of a SNDU, and a one byte
             Payload Pointer follows the last byte of the TS Packet 
header. 
        
        If a Payload Unit (SNDU) finishes before the end of a TS Packet
        payload, but it is not convenient to start another Payload Unit, a
        stuffing procedure fills the remainder of the TS Packet payload 
with
        bytes with a value 0xFF [ISO-MPEG2], known as Padding.

---

From: Tor Brekke <[email-masked]>
Date: Fri, 16 Apr 2004 10:46:38 +0200

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, 
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

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.

--H. Clausen

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 16 Apr 2004 14:13:19 +0100

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:

> 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).  
>
> adaptation field in other systems. We only want to ensure that ULE can 
> be used on systems which use the adaptation field.
>
> --Tor
>
>
>
>

---

From: "William StanisLaus" <[email-masked]>
Date: Fri, 16 Apr 2004 19:53:41 +0530

Let me add my understanding with MPEG2-TS decode.

transport_packet(){
        sync_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.

> Sent: Friday, April 16, 2004 6:43 PM
> > > perform inband signalling for the DVB-RCS network. This
> signalling
> > has to
> > > >     PES or PSI start in this packet. Suggest define
> that it be set
> > to 0.
> > > >
> > > >     Art
> > > >     ::{)>
> > > >     Art Allison
> > > >                 Now to the question: Why is this
> limitation imposed on
> > > >                 ULE?
> > > >