E xample for SCL resource usage according to ETSI TC M2M March 2011

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

2. High level Architecture & Interfaces (practival view) Device Application Device Application Network basedApplication Device Application • M2M device API API (http/RESTful) M2M service layer on the network side ETSI TC M2M M2M service layer on the device side http/RESTful Existing interfaces UnderlyingNetwork #1 UnderlyingNetwork #2 Comm-Module Comm-Module « HLR » « AAA »

3. 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

4. DA NA write DSC NSC DA NA notify DSC NSC DA NA read DSC NSC Example 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

5. <sclBase> 1 n “attribute” 1 scls applications 1 containers 1 groups 1 accessRights 1 subscriptions 1 discovery 1 accessStatus Top Level of SCL Resource Tree Root of resource tree on each SCL (DSC, GSC or NSC) Meta data (i.e. attributes), e.g. pointer to access right Collection of other SCLs that are registered with this SCL 1 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) 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

6. 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).

7. Start Assumptions • 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 M2M Device NA_1 NSCL_1 NSCL_1 applications NA_1

8. 1st Phase: Bootstrapping • Purpose: Establish ID & Root Key (KR)for communicating with a specific NSCL • Allows for authentication and encryption • 4 Options foreseen in specification so far • Completely pre-configured • The ID and KR 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

9. Result of bootstrapping not specific to this example • 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) M2M Device NA_1 DSCL(DSCL_1, KR_1) NSCL_1 NSCL_1 Bootstrap applications NA_1

10. Result of bootstrapping specific to this example (1) • 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 NA_1 DSCL(DSCL_1, KR_1) NSCL_1 NSCL_1 DSCL_1 applications scls NA_1 scls NSCL_1 DSCL_1

11. Result of bootstrapping specific to this example (2) • 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 subscribe/notify NA_1 DSCL(DSCL_1, KR_1) NSCL_1 NSCL_1 DSCL_1 applications scls NA_1 scls NSCL_1 DSCL_1 applications DA_1 containers val cmd res

12. 2nd Phase: Device Application launches • 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 NA_1 DA_1 DSCL(DSCL_1, KR_1) NSCL_1 NSCL_1 applications DSCL_1 NA_1 scls scls DSCL_1 NSCL_1 applications DA_1 applications containers DA_1 val cmd res

13. 3rd Phase: Device Application in operation (1) • 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 URINSCL_1/scls/DSCL_1/applications/DA_1/containers/val • NA_1 gets notified and consumes new values Requestupdate NSCL_1/scls/DSCL_1/applications/DA_1/containers/val M2M Device NA_1 DA_1 Connect & forward request DSCL(DSCL_1, KR_1) NSCL_1 NSCL_1 applications DSCL_1 NA_1 scls scls DSCL_1 NSCL_1 applications DA_1 applications containers DA_1 val cmd res

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

15. 3rd Phase: Device Application in operation (3) • 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 URINSCL_1/scls/DSCL_1/applications/DA_1/containers/val • NA_1 gets notified and consumes new values Requestupdate NSCL_1/scls/DSCL_1/applications/DA_1/containers/val M2M Device NA_1 DA_1 Connect & forward request DSCL(DSCL_1, KR_1) NSCL_1 NSCL_1 applications DSCL_1 NA_1 scls scls DSCL_1 NSCL_1 applications DA_1 applications containers DA_1 val cmd res

16. 3rd Phase: Device Application in operation (4) • NA_1 wants to switch off some appliances controlled by M2M Device • NA_1 writes asynchronously a command to resource with URINSCL_1/scls/DSCL_1/applications/DA_1/containers/cmd Requestupdate NSCL_1/scls/DSCL_1/applications/DA_1/containers/cmd M2M Device NA_1 DA_1 DSCL(DSCL_1, KR_1) NSCL_1 NSCL_1 applications DSCL_1 NA_1 scls scls DSCL_1 NSCL_1 applications DA_1 applications containers DA_1 val cmd res

17. 3rd Phase: Device Application in operation (5) • DA_1 checks if there have been any commands issued by NA_1 • DA_1 requests DSCL_1 to retrieve information from resource with URINSCL_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 Requestretrieve NSCL_1/scls/DSCL_1/applications/DA_1/containers/cmd Requestupdate NSCL_1/scls/DSCL_1/applications/DA_1/containers/res M2M Device NA_1 DA_1 DSCL(DSCL_1, KR_1) NSCL_1 Forward request NSCL_1 applications DSCL_1 NA_1 scls scls DSCL_1 NSCL_1 applications DA_1 applications containers DA_1 val cmd res

18. Device Application continues to run • DA_1 writes new meter reading values periodically to the network • DA_1 checks periodically for commands, executes when needed & responds NetworkApplication continues to run • NA_1 keeps processing incoming meter readings whenever notified • NA_1 keeps sending commands to DA_1 as needed and processed responses as notified 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