RE: 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
>