WAVE Device Management

1. WAVE Device Management John Moring June 2012

2. Agenda • IEEE P1609.6 overview • Overview of related technologies • Simple Network Management Protocol • Open Mobile Alliance – Device Management • Next steps

3. P1609.6 • Scope: This standard defines optional services, operating in the station management entities at the network layer, that support remote over-the-air management of Wireless Access in Vehicular Environments (WAVE) devices. • Purpose: The purpose of this standard is to provide optional over-the-air management and data message formats at the network layer. The related local services, that enable WAVE devices utilizing these services, will be managed over-the-air by other WAVE devices utilizing these services. This provides cryptographically secure management communications and device identification for these devices.

4. 1609.6 Intent • Over-the-air management of WAVE devices • Target is “low end” managed device, not traditional RSU/OBU • Use cases considered • Road Sensors • Traffic Cone • Pedestrian Alert • Work Crew Alert • Vehicle Marker • Cargo Seal • Message Sign

5. 1609.6 Concepts • Remote Management (WME-RM) • Remote Device (RMd) • Manager Device (RMm)

6. 1609.6 Functions • 1) A common mechanism for secure identification and addressing of Remote devices, irrespective of higher layer application function • 2) Over-the-air management of Remote devices using transmission of management commands to and reception of management responses and requests from Remote devices • Optional management functions of: • 3) the ability for a Remote device to be configured to “Quiet”, i.e. to become non responsive to over-the-air communications, and be subsequently woken either at a timed interval or by an over-the-air trigger. • definition of over-the-air triggers, i.e. identification of messages which can be used to exit “Quiet” configuration. • 4) common framework for obtaining and reporting Remote device location. • 5)Local management of device functions and WAVE Security Services attributes to support remote management services. • Other features • Manager-device association • Device synchronization via Timing Advertisement • Security of management functions • Delivery of management info over 1609 management path (VSA frame)

7. 1) Identification and Addressing • Specifies multiple WAVE Remote Management Device Identifiers (WRMDI) • WRMDI permanent identity • IEEE “Electronic” Unique Identifier (EUI) • Should be “Extended” Unique Identifier, e.g., MAC address • WRMDI session identity • At most one instance per device at any time • Supports anonymity • Assigned by Manager • WRMDI programmable identity • Multiple instances supported per device at any time • Supports group addressing • Assigned by deployer • Anonymous WRMDI • Used for certain management signaling • Used in • Management info (command/request/response) transfers and • WSMP extension (WSMI) for application data

8. WSMI (WAVE short message incorporating identities) • Only one ID included, that of the Managed device Value indicates WSMI formatted payload Data

9. 2) Command/ Response/Request • Typical management functionality • Comparable to • SNMP Get/Set/Trap • OMA Get/Replace/Alert • Some MIB-based, some not (e.g., Triggers, Quiet)

10. 3) “Quiet” and Triggers • Transmitter temporarily turned off • This seems a distinct feature from device management • Remove from this standard and standardize separately?

11. 4) Device Location • Reporting device location is covered under Command/Response • The capability for a manager to use other means to locate a device seems a distinct feature from device management • No methodology specified • Propose to remove from this standard and standardize separately, if required

12. 5) Local Management • Specifies certain management functions that can be accessed by higher layers, i.e., not over the air • Reset to default values • Invoke Quiet, set Triggers • GET and SET MIB variables • In scope of “Remote Management”?

13. 1609.6, OMA, SNMP • Are existing management protocols applicable to WAVE? • IETF - Simple Network Management Protocol (SNMP) • Open Mobile Alliance – Device Management (OMA-DM)

14. SNMP Overview • Enterprise focus • Manager and agent roles • Runs over UDP/IP • v1, 1988 • Base functionality: MIB get, set, and traps • v2c (one of several variants) • Incremental enhancements • v3 • Security

15. SNMP v1 PDUs • GetRequest • A manager-to-agent request to retrieve the value of a variable or list of variables. A Response with current values is returned. • SetRequest • A manager-to-agent request to change the value of a variable or list of variables. A Response with (current) new values for the variables is returned. • GetNextRequest • A manager-to-agent request to discover available variables and their values. Returns a Response with variable binding for the lexicographically next variable in the MIB. The entire MIB of an agent can be walked by iterative application of GetNextRequest starting at OID 0. • Response • Returns variable bindings and acknowledgement from agent to manager for GetRequest, SetRequest, GetNextRequest, GetBulkRequest and InformRequest. Error reporting is provided by error-status and error-index fields. Although it was used as a response to both gets and sets, this PDU was called GetResponse in SNMPv1. • Trap • Asynchronous notification from agent to manager. Includes current sysUpTime value. Destination addressing for traps is determined in an application-specific manner typically through trap configuration variables in the MIB. The format of the trap message was changed in SNMPv2 and the PDU was renamed SNMPv2-Trap.

16. SNMP v2 PDUs Added • GetBulkRequest • Optimized version of GetNextRequest. A manager-to-agent request for multiple iterations of GetNextRequest. Returns a Response with multiple variable bindings walked from the variable binding or bindings in the request. PDU specific non-repeaters and max-repetitions fields are used to control response behavior. • InformRequest • Acknowledged asynchronous notification manager to manager or agent to manager. Manager-to-manager notifications were already possible in SNMPv1 (using a Trap), but as SNMP commonly runs over UDP where delivery is not assured and dropped packets are not reported, delivery of a Trap was not guaranteed. InformRequest fixes this by sending back an acknowledgement on receipt. Receiver replies with Response parroting all information in the InformRequest.

17. Open Mobile Alliance • Technology-agnostic standards body with mobile (phone) focus, e.g., • Multimedia messaging service (MMS) • Location determination • Push-to-talk over cellular • Etc. • Includes a family of standards for Device Management (OMA-DM)

18. OMA Device Management • “Device management is the generic term used for technology that allows third parties to carry out the difficult procedures of configuring mobile devices on behalf of the end user (customer). Third parties would typically be wireless operators, service providers or corporate information management departments. Through device management, an external party can remotely set parameters, conduct troubleshooting servicing of terminals, install or upgrade software.”

19. Device Management defined • Management of the Device configuration and other managed objects of Devices from the point of view of the various Management Authorities. Device Management includes: • Setting initial configuration information in Devices • Subsequent updates of persistent information in Devices • Retrieval of management information from Devices • Processing events and alarms generated by Devices

20. Use cases • Provisioning • Configuration Maintenance/Management • Software management • Fault Detection, Query and Reporting • Non-application Software Download

21. OMA-DM Concepts • SyncPRO • Packages • XML • Trees

22. Messages • Manager (Server) → Device (Client) • Add • Atomic • Copy • Delete • Exec • Get • Replace • Sequence • Device (Client) → Manager (Server) • Alert • Results

23. Next Steps