Example for SCL resource usage according to ETSI TC M2M March 2011 Josef Blanz, Qualcomm Inc.

PAGE 1 High level Architecture & Interfaces (practival view) M2M service layer on the network side Network based Application Underlying Network #1 « HLR » Device Application Comm- Module Underlying Network #2 « AAA » M2M device M2M service layer on the device side 03/21/20111 ETSI TC M2M Existing interfaces API (http/RESTful)API http/RESTful

PAGE 2 ETSI TC M2M Resource Framework The ETSI TC M2M resource framework consists of A tree-structured data model to support standardized access to information on each entity supporting the ETSI Service Capability Layer (SCL) Includes Device (DSC), Gateway (GSC) and Network (NSC) SCLs This is only a model so to be able to reference (address) information in a standardized manner and to rely on reflection of state changes in resources content Implementation may be diverging… not standardized A set of operations on the resources that each SCL exposes to its local applications (DA, GA, NA) and to other authorized SCLs Create Read Update Delete Subscribe Notify Has advantages like today in web-based applications using a REST style via http Proxying, NATing Stateless interfaces Idempotent 03/21/20112

PAGE 3 Example DANA DSCNSC write DANA DSCNSC notify DANA DSCNSC read 1. Device application writes a data value on a network data repository (e.g to indicate that a sensor value has crossed a threshold) 2. NSC notifies network application that a data value it is subscribed to has changed 3. Network application invokes a resource read operation to obtain the new value 03/21/20113

PAGE 4 1 Root of resource tree on each SCL (DSC, GSC or NSC) 1 1 applications 1 scls containers groups 1 accessRights 1 “attribute” n subscriptions 1 discovery 1 accessStatus 1 Top Level of SCL Resource Tree Collection of other SCLs that are registered with this SCL Collection of local apps that are registered with this SCL Collection of data container resources exposed by this SCL Collection of groups (allow “bulk” operations) Meta data (i.e. attributes), e.g. pointer to access right 03/21/20114 Place where access right can be created / managed Place where subscriptions can be created / managed Used as an URI through which results of discovery are delivered Reflecting access status of parent

PAGE 5 Assumptions This example section is a possible interpretation of what is specified so far Procedures and details on possible sequences of procedures not yet specified Needs to be checked against evolving state of specifications Different behavior of the Service Layer may result when specification evolve Very basic case Pre-configuration assumed whenever possible (for DSCL and DA) Based on a hypothetic metering application (e.g. smart meter) It is assumed that the considered M2M device is designed and configured for exactly one a-priori known device application (the metering application) Allows several simplifications Shows how a most simple metering device could post data to a network application Only one out of many different ways the TC M2M platform could be used for the same purpose (collection of meter reads / processing of commands to the meter). 03/21/20115

PAGE 6 M2M Device Start Assumptions 03/21/20116 NA_1 NSCL_1 Network SCL is already operational (e.g. NSCL_1) Network application (NA_1) is already operational (e.g. collecting meter reads) => certain resources related to NA_1 are already available in NSCL_1 M2M Device (e.g. smart meter) has not yet been operational, first time usage NSCL_1 applications NA_1

PAGE 7 1 st Phase: Bootstrapping 03/21/20117 Purpose: Establish ID & Root Key (K R )for communicating with a specific NSCL Allows for authentication and encryption 4 Options foreseen in specification so far Completely pre-configured The ID and K R are already stored on the device / gateway The device / gateway knows to which NSCL to talk to Bootstrapping based on access network credentials Relying on access network credentials in case that M2M service provider and access network operator are the same or trust each other Could use GBA, not yet completed Automated bootstrapping procedure based on certificates Automated bootstrapping procedure based on passwords & using IBAKE No details on bootstrapping presented here, assume it went OK. Subject for a separate discussion with security experts

PAGE 8 M2M Device Result of bootstrapping not specific to this example 03/21/20118 DSCL (DSCL_1, KR_1) DSCL has an ID (e.g. DSCL_1) that is known to the NSCL DSCL also knows a Root Key (KR_1) that allows for authentication & encryption M2M Device (i.e. DSCL_1) can now establish secure communication with network side of the M2M SL (NSCL_1) NA_1 NSCL_1 Bootstrap NSCL_1 applications NA_1

PAGE 9 Result of bootstrapping specific to this example (1) 03/21/20119 NSCL_1 knows (by pre-configuration) that DSCL_1 shall be registered by default once it bootstrapped successfully => DESCL_1 specific resources are created in NSCL_1 Also DSCL_1 assumes implicit registration with NSCL_1 and creates NSCL_1 specific resources M2M Device DSCL (DSCL_1, KR_1) NA_1 NSCL_1 DSCL_1 scls NSCL_1 applications NA_1 scls DSCL_1

PAGE 10 NSCL_1 subscribe/notify NSCL_1 applications NA_1 scls DSCL_1 applications DA_1 containers val Result of bootstrapping specific to this example (2) 03/21/ NSCL_1 knows (by pre-configuration) that DSCL_1 will only run one specific application (DA_1) => registers DA_1 implicitly & creates DA_1 specific resources in NSCL_1 and gives appropriate access to DA_1 and NA_1 NSCL_1 knows (by pre-configuration) that DA_1 will communicate with NA_1 => Establishes subscriptions to resources of DA_1 to notify NA_1 on changes M2M Device DSCL (DSCL_1, KR_1) NA_1 DSCL_1 scls NSCL_1 cmd res

PAGE 11 NSCL_1 applications NA_1 scls DSCL_1 applications DA_1 containers val 2 nd Phase: Device Application launches 03/21/ DA_1 launches on M2M Device an registers with DSCL_1 =>DSCL_1 checks authentication information of DA_1 and creates DA_1 specific resources on DSCL_1 DA_1 enters regular operation, e.g. periodic pushing of meter reads, periodic polling of commands from NA_1 (next slides) M2M Device DSCL (DSCL_1, KR_1) NA_1 cmd res DA_1 DSCL_1 scls NSCL_1 applications DA_1

PAGE 12 NSCL_1 applications NA_1 scls DSCL_1 applications DA_1 containers val 3 rd Phase: Device Application in operation (1) 03/21/ A new set of values measured by the meter is ready for being pushed to NA_1 DA_1 requests DSCL_1 to write new values into resource with URI NSCL_1/scls/DSCL_1/applications/DA_1/containers/val NA_1 gets notified and consumes new values M2M Device DSCL (DSCL_1, KR_1) NA_1 cmd res DA_1 DSCL_1 scls NSCL_1 applications DA_1 Request update NSCL_1/scls/DSCL_1/applications/DA_1/containers/val Connect & forward request

PAGE 13 Request retrieve NSCL_1/scls/DSCL_1/applications/DA_1/containers/cmd NSCL_1 applications NA_1 scls DSCL_1 applications DA_1 containers val 3 rd Phase: Device Application in operation (2) 03/21/ DA_1 checks if there have been any commands issued by NA_1 DA_1 requests DSCL_1 to retrieve information from resource with URI NSCL_1/scls/DSCL_1/applications/DA_1/containers/cmd No command was issued => DA_1 waits for next cycle, DSCL_1 will disconnect M2M Device DSCL (DSCL_1, KR_1) NA_1 cmd res DA_1 DSCL_1 scls NSCL_1 applications DA_1 Forward request

PAGE 14 NSCL_1 applications NA_1 scls DSCL_1 applications DA_1 containers val 3 rd Phase: Device Application in operation (3) 03/21/ A new set of values measured by the meter is ready for being pushed to NA_1 DA_1 requests DSCL_1 to write new values into resource with URI NSCL_1/scls/DSCL_1/applications/DA_1/containers/val NA_1 gets notified and consumes new values M2M Device DSCL (DSCL_1, KR_1) NA_1 cmd res DA_1 DSCL_1 scls NSCL_1 applications DA_1 Request update NSCL_1/scls/DSCL_1/applications/DA_1/containers/val Connect & forward request

PAGE 15 NSCL_1 applications NA_1 scls DSCL_1 applications DA_1 containers val 3 rd Phase: Device Application in operation (4) 03/21/ NA_1 wants to switch off some appliances controlled by M2M Device NA_1 writes asynchronously a command to resource with URI NSCL_1/scls/DSCL_1/applications/DA_1/containers/cmd M2M Device DSCL (DSCL_1, KR_1) NA_1 cmd res DA_1 DSCL_1 scls NSCL_1 applications DA_1 Request update NSCL_1/scls/DSCL_1/applications/DA_1/containers/cmd

PAGE 16 Request retrieve NSCL_1/scls/DSCL_1/applications/DA_1/containers/cmd NSCL_1 applications NA_1 scls DSCL_1 applications DA_1 containers val 3 rd Phase: Device Application in operation (5) 03/21/ DA_1 checks if there have been any commands issued by NA_1 DA_1 requests DSCL_1 to retrieve information from resource with URI NSCL_1/scls/DSCL_1/applications/DA_1/containers/cmd Command was issued => DA_1 executes it (e.g. appliance off) and responds DA_1 waits for next cycle, DSCL_1 will disconnect M2M Device DSCL (DSCL_1, KR_1) NA_1 cmd res DA_1 DSCL_1 scls NSCL_1 applications DA_1 Forward request Request update NSCL_1/scls/DSCL_1/applications/DA_1/containers/res

PAGE 17 Device Application continues to run 03/21/ DA_1 writes new meter reading values periodically to the network DA_1 checks periodically for commands, executes when needed & responds NA_1 keeps processing incoming meter readings whenever notified NA_1 keeps sending commands to DA_1 as needed and processed responses as notified Network Application continues to run DA and NA independent Developers of NA and DA do not need to worry about setting up connections Their application logic and the transition of states inside the applications are happening asynchronous and can be executed independently (no mutual waiting or blocking I/O) SL takes care of synchronization (notifications) and buffering of data