RE: EXT_TIME: a new HE for timing information in LCT

Hi Thorsten

Normative SCT behaviour is defined in §7.7.7 and Annex A of TS 26.346. Whereas it makes sense to make a change request (CR) to that 3GPP document, the change is a stop gap only. This HE change will also change the name of the flags in LCT so if TS 26.346 is to reference the actual standards track RFCs, it would be sufficient to remove the SCT flag and field parts from the TS.

It is essential that the CR also does this to the ERT! In fact, simple changing the document to say both SCT and ERT flags are set to zero (and leaving the reference to experimental LCT RFC) would be fine - and not even cause problems if the experimental reference doesn't get changed to standards track.

Given that the new LCT is not yet an RFC (and doesn't yet have the HE change), it's pointless to say in the 3GPP document whether this timestamp HE is mandatory, optional or excluded from the 3GPP doc. Like other header extensions not using mandatory LCT flags, it's best if the TS simply does not mention these.

Cheers, Rod.

PS The intent of making SCT mandatory in 3GPP was to keep the header as fixed as possible and so simplify implementation. (FDT expiry time synchronisation suggestions followed after). In anycase, the proposed HE change simplifies this mandatory LCT part more so it fits with the original 3GPP agreement.


>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On 
>Behalf Of ext Thorsten Lohmar (AC/EDD)
>Sent: 01 February, 2006 13:38
>To: Paila Toni (Nokia-M/Espoo); [email protected]; [email protected]
>Subject: RE: [Rmt] EXT_TIME: a new HE for timing information in LCT
>
>Hello Toni, et al.
>
>good survey. Here are some "latest news" on the use of SCT in the 3GPP
>specifications: I am currently drafting a CR to make the SCT in the TS
>26.346 optional. 
>
>The reason to use the SCT was, the mobile phones are not 
>necessarily time synchronized with the network. Therefore, we 
>needed a base to interpret the FDT expiration time. But, TS 
>26.346 includes since the last meeting a time synchronization 
>scheme. MBMS Ues are now time-synchronized with the network. 
>This makes the SCT obsolete (even increases complexity).
>
>BR,
>/Thorsten
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On 
>Behalf Of 
>> [email protected]
>> Sent: Wednesday, February 01, 2006 12:06 PM
>> To: [email protected]; [email protected]
>> Subject: RE: [Rmt] EXT_TIME: a new HE for timing information in LCT
>> 
>> Hello Vincent and the rest of RMT WG,
>> 
>> Analyzing the current 3GPP, DVB and OMA specifications making use of 
>> ALC/LCT, I found that the change you proposed does not break 
>anything.
>> That is, the following specifications do not make use of 
>either SCT or 
>> ERT.
>> 
>> DVB Document A099, "IP Datacast over DVB-H: Electronic Service Guide 
>> (ESG)"
>>  *
>> 
>http://www.dvb-h-online.org/PDF/a099.tm3348r2.cbms1199r14.IPDC_ESG.pdf
>> 
>> DVB Document A101, "IP Datacast over DVB-H: Content Delivery 
>Protocols 
>> (CDP)"
>>  *
>> http://www.dvb-h-online.org/PDF/a101.tm3350r3.cbms1167r12.IPDC
>> _Content_D
>> elivery_Protocols.pdf
>> 
>> Open Mobile Alliance, "Service Guide for Mobile Broadcast Services - 
>> Draft Version 1.0"
>>  *
>> http://member.openmobilealliance.org/ftp/public_documents/bac/
>> BCAST/Perm
>> anent_documents/OMA-TS-BCAST_Service-Guide-V1_0_0-20060106-D.zip
>> 
>> Open Mobile Alliance, "File Distribution and Stream Distribution - 
>> Draft Version 1.0"
>>  *
>> http://member.openmobilealliance.org/ftp/public_documents/bac/
>> BCAST/Perm
>> anent_documents/OMA-TS-BCAST-Distribution-V1_0_0-20060106-D.zip
>> 
>> 
>> The only specification I found using SCT and ERT is:
>> 
>> 3GPP TS 26.346 V6.3.0 (2005-12), "3rd Generation Partnership 
>Project; 
>> Technical Specification Group Services and System Aspects; 
>Multimedia 
>> Broadcast/Multicast Service (MBMS); Protocols and codecs (Release 6)"
>>  * http://www.3gpp.org/ftp/Specs/latest/Rel-6/26_series/26346-630.zip
>> 
>> In that spec:
>>  - The use of ERT is truly optional for both FLUTE client and FLUTE 
>> server.
>>  - The use of SCT is optional for FLUTE server but mandatory 
>for FLUTE 
>> client.
>> 
>> However, the proposed change (i.e. EXT_TIME) does not remove the 
>> LCT-inherent capability to signal SCT. It just does it in 
>more generic 
>> way. Therefore, I think it is just a matter of a very simple spec 
>> maintenance issue to update the 3GPP spec TS
>> 26.346 to refer to EXT_TIME carrying SCT rather than using SCT field.
>> 
>> I very much support Vincent's initiative to generalize the 
>> time-related signaling in LCT header. To me, this simplifies the 
>> design as well as makes LCT more flexible and extensible.
>> 
>> 
>> Regards,
>>  Toni
>>  
>> 
>> >-----Original Message-----
>> >From: [email protected] [mailto:[email protected]] On
>> Behalf Of
>> >ext Vincent Roca
>> >Sent: 31 January, 2006 17:18
>> >To: [email protected]
>> >Subject: [Rmt] EXT_TIME: a new HE for timing information in LCT
>> >
>> >Dear Mark et al.
>> >
>> >Here is the follow-up of a discussion we had in December on the 
>> >possibility of defining a new header extension for LCT to
>> carry several
>> >kinds of timing information.
>> >Cheers,
>> >
>> >    Vincent / Toni / Rod
>> >
>> >
>> 
>> _______________________________________________
>> Rmt mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/rmt
>> 
>
>_______________________________________________
>Rmt mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmt
>