1 / 6

CAT over AT: status and next steps

CAT over AT: status and next steps. ST Incard ETSI SCP REQ, Sophia Antipolis, 10-12 Jan 2011 ETSI SCP, Sophia Antipolis, 12-14 Jan 2011. A brief history. CAT over AT requirements were agreed in July 2009 First technical architecture presented by Incard covering all reqs in Sept 2009

mahala
Télécharger la présentation

CAT over AT: status and next steps

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CAT over AT: status and next steps ST Incard ETSI SCP REQ, Sophia Antipolis, 10-12 Jan 2011 ETSI SCP, Sophia Antipolis, 12-14 Jan 2011

  2. A brief history • CAT over AT requirements were agreed in July 2009 • First technical architecture presented by Incard covering all reqs in Sept 2009 • Requirements improved (multiple legacy CEs and security) in Q1 2010 • Conf call in April 2010 – job split with 3GPP • CRs approved in CT1 in September 2010 Targetting Release 9 at the beginning!!!

  3. Current status • 4 Proposal are under discussions: • SCPTEC 529r1 by T-Mobile New proposal presented in SCP TEC #36 introducing encapsulation of tk commands/response. • SCPTEC 530r1 by France Telecom Based on Incard proposal from Sept 2009 with Explicit Routing TLV • SCPTEC 543 by France Telecom Based on Incard proposal from Sept 2009 but introducing Device Identity based routing • SCPTEC 413r2 by G&D No explicit routing by Toolkit application

  4. Requirement coverage • Requirements have been mainly approved in July 2009 and partially evolved in March 2010 • No CRs in Req after March 2010 • Requirements include possibility of: • Legacy / Enhanced architecture • Explicit routing for Enhanced • Default routing for Legacy • Security requirements (added in March 2010) • Solutions 1,2,3 cover the legacy / enhanced reqs • Multiple connected entities have been removed to stay aligned with CT, but mechanism to extend is provided • Solution 4 cover mainly the legacy reqs

  5. Actually two main options are avail • “Simple” solution (G&D) • Fulfills only a subset of requirements • Compatible with current CT output • Low impact on Card / modem architecture • No explicit routing – only legacy; relies on an external entity (the multiplexer) for explicit routing • “Full” solution (FT/Incard or T-Mobile) • Fulfills most of the requirements (security requirements not yet) • Compatible with current CT output, but CT docs should be extended to support multiple CEs. • Impact on Card / modem architecture • Both explicit routing and legacy are supported • Actually decision between one or the other is a decision among simplicity and flexibility

  6. The main discussion points • Allow or not for future extensions explicit routing toward multiple connected entities Required by SCP REQ but out of scope (no technical solution so far) with current CT docs • Maintain legacy architecture Required by SCP REQ but critical in terms of compatibility with already existing applications • Data format (routing TLV, encapsulation, dev. id….) For ST Incard it is the minor point – but most discussions are focused on this point

More Related