Subject: RE: [Rmt] EXT_TIME: a new HE for timing information in LCT

From: "Thorsten Lohmar \(AC/EDD\)" <[email-masked]>
Date: Wed, 1 Feb 2006 12:38:18 +0100

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-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Wednesday, February 01, 2006 12:06 PM
> To: [email-masked]; [email-masked]
> 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-masked] [mailto:[email-masked]] On 
> Behalf Of 
> >ext Vincent Roca
> >Sent: 31 January, 2006 17:18
> >To: [email-masked]
> >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-masked]
> https://www1.ietf.org/mailman/listinfo/rmt
> 

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: [email-masked]
Date: Fri, 3 Feb 2006 14:50:27 +0200

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.

>Behalf Of ext Thorsten Lohmar (AC/EDD)
>Sent: 01 February, 2006 13:38
>To: Paila Toni (Nokia-M/Espoo); [email-masked]; [email-masked]
>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
>
>
>> [email-masked]
>> Analyzing the current 3GPP, DVB and OMA specifications making use of 
>> ALC/LCT, I found that the change you proposed does not break 
>anything.
>either SCT or 
>> ERT.
>> DVB Document A099, "IP Datacast over DVB-H: Electronic Service Guide 
>> (ESG)"
>>  *
>> 
>Protocols 
>> (CDP)"
>> Open Mobile Alliance, "Service Guide for Mobile Broadcast Services - 
>> Draft Version 1.0"
>>  *
>> Open Mobile Alliance, "File Distribution and Stream Distribution - 
>> Draft Version 1.0"
>>  *
>Project; 
>> Technical Specification Group Services and System Aspects; 
>Multimedia 
>> Broadcast/Multicast Service (MBMS); Protocols and codecs (Release 6)"
>>  - The use of ERT is truly optional for both FLUTE client and FLUTE 
>> server.
>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
>> time-related signaling in LCT header. To me, this simplifies the 
>> design as well as makes LCT more flexible and extensible.
>> 
>> 
>> Regards,
>>  Toni
>>  
>>