50 likes | 233 Views
SCP(11)0001 SCP Plenary #47 January 12-14, 2011. Update on TC M2M Activities. M2M Plenary #13 scheduled in Seoul was cancelled due to inter-Korean incidents and replaced by 2 days meeting in Paris Expected completion of Release 1:
E N D
SCP(11)0001 SCP Plenary #47 January 12-14, 2011
Update on TC M2M Activities M2M Plenary #13 scheduled in Seoul was cancelled due to inter-Korean incidents and replaced by 2 days meeting in Paris Expected completion of Release 1: Stage 1 (TS 102 689, Requirements) already published (CR process being put in place) Stage 2 (TS 102 690, architecture) expected completion in May 2011 Stage 3 (TS 102 921, Interfaces and Protocols) expected in September 2011 Same for TR 102 531 “Reuse of Core Network Functionality by M2M Service Capabilities” (3GPP architecture mapping) Other TRs on Use cases (other than Smart Metering: TR 102 691, published) may be Release 2 New Work Item creating TR 103 167 on Threat Analysis may impact Rel. 1 & 2 A Working Group structure is in discussion May include Security Working Group
M2M Architecture Overview (Draft TS 102 690) The specification describes horizontal Service Capabilities to be used by various M2M applications (spread between Device, Gateway and Core Network elements). They remain independent of core network technology (e.g. 3GPP, TISPAN, PLC…) An API is being defined (HTTP, REST based) for the M2M applications to use the service capabilities M2M devices connect to the core network directly or through a Gateway WAN (Wide Area Network) Core network Central Communication System PC/dedicated appliance (e.g. Smart Metering) M2M Application User interface to application e.g. Web portal mIa ETSI M2M Service Capabilities mId M2M Area Service Capabilities M2M Gateway Local M2M Network M2M Service Capabilities M2M Device Domain M2M Device M2M Device M2M Device
Relevant Architecture Details Devices connecting directly to the Core network include a Security Capability handling authentication and registration to an M2M Service Capability layer Same paradigm as e.g. IMS: Service layer security is independent of Access network security and potentially using different credentials No business relationship between M2M Service provider and Access Network Operator is assumed . Requirement that M2M Service Subscription may be changed remotely after device issuance This security capability requires a secure environment to properly handle credentials The Secure environment may be an Independent Security Element, i.e. UICC-based Bootstrapping of M2M Service layer credentials on the device may or may not be UICC based e.g. if an MNO is also M2M Service Provider or has agreement, the UICC used for network access may be shared Need for an “M2M Service Identity Module” application on UICC, next to the USIM or other NAA? Or an M2M Service Provider may choose to provide his own UICC to bootstrap his devices However, proposals are discussed to remotely bootstrap M2M Service credentials independently from access network, without UICC (PKI Certificates vs. IBAKE approach)
Update on EC M441 Smart Metering Mandate The “Technical Report on Communication” that has been produced will not be submitted to ESOs approval, because the European Commission has raised a concern that needs to be addressed: Fear that an underlying requirement promotes the smart meter as the only access point to the home network, potentially resulting in bundle offers with smart appliances. There was agreement that this is not the assumption, but the requirements need to be clarified and the document has to be revised accordingly. Further information will be provided as soon as this gets resolved. The Work Program of the involved committees (including ETSI SCP) remains a living document that can be updated as needed.