1 / 30

Design and Implementation of Real-Time Management Framework for Device Access

This work presents a comprehensive framework for Real-Time Management (RTM) focused on secure communication and device access management. The RTM framework allows for easy node identification through URIs, supports flexible property management, and enables secure command execution via authentication and encryption. We analyze roles in the RTM framework, such as the Initiator, doctor, and patient, and outline key functionalities like remote diagnosis and repair. The future work aims to enhance access control mechanisms and define protocols based on existing standards.

yael
Télécharger la présentation

Design and Implementation of Real-Time Management Framework for Device Access

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. RTM in SPACE4U Design and Implementation Hailiang Mei H.Mei@tue.nl

  2. Outline • Design of RTM Framework • Implementation • Conclusion and Future Work • Related Works (Possible RTM Approaches)

  3. Relation with SIM get/exec add/replace delete/exec

  4. Security setting RTM Framework inside Device

  5. Access Management for RTM • Each node (object) is identified by an URI • Each node has a set of properties • This tree can be extended by “add” message or a new installations on the device • Leaf node can be either a value or a pointer to an executable command

  6. Secure Communication • Authentication • Decryption and encryption • Maintain log file • Can keep user update with latest operations (Transparent control)

  7. ? ? RTM Initialization Sub-process (1) get/exec add/replace delete/exec

  8. RTM Initialization Sub-process (2) • Consider three roles • Initiator, doctor(TM) and patient (Terminal) • Initiator • Decide the patient and doctor • Patient • Send “help” message to doctor (if known) • Or broadcast “help” message • Doctor • Check the received “help” message • Can request RTM connection with patient

  9. Outline • Design of RTM Framework • Implementation • Conclusion and Future Work • Related Works (Possible RTM Approaches)

  10. Middleware RC 1 RC 2 . . . RC N RCDP component RTM component Robocop Run-time Environment Comply with ROBOCOP Framework OS/drivers • RCDP component is available • Scommunication can be implemented based on open-SSL and SyncML protocol stack • Access Manager is open

  11. RTM Component

  12. RTM & SIM Integration

  13. Implementation plan

  14. Conclusion • Secured RTM (RTM.01, mandatory) • Management client oriented • Healthy terminal oriented • Component downloading due to context changing (CAC.01&02) • (Legal) Component sharing (RTM.02, optional) • Service discovery (RTM.03, optional) • Non-healthy terminal oriented • Remote diagnosis (RTM.04, similar to HM.03, Mandatory ) • Remote repair (RTM.05, similar to HM.04, Mandatory ) • Management server oriented • User service data survey (RTM.06, optional) • User transparent control (RTM.07, Mandatory)

  15. Conclusion • Secured RTM (RTM.01, mandatory)  • Management client oriented • Healthy terminal oriented • Component downloading due to context changing (CAC.01&02) • (Legal) Component sharing (RTM.02, optional)  • Service discovery (RTM.03, optional)  • Non-healthy terminal oriented • Remote diagnosis (RTM.04, similar to HM.03, Mandatory)  • Remote repair (RTM.05, similar to HM.04, Mandatory )  • Management server oriented • User service data survey (RTM.06, optional) • User transparent control (RTM.07, Mandatory) 

  16. Future Work • Formulate access control mechanism • Some ideas borrowed from SNMP and SyncML • Limiting the root node access rights properties • Certain access management might be done by interacting with users • Define communication protocol and message format • Largely based on SyncML • Implementing…

  17. Questions?

  18. Outline • Design of RTM Framework • Implementation • Conclusion and Future Work • Related Works (Possible RTM Approaches)

  19. Possible RTM approaches • Telnet/SSH • Virtual Network Computing (VNC) • Web server • UPnP • SNMP • SyncML (Open Mobile Alliance)

  20. Virtual Network Computing

  21. Virtual Network Computing

  22. Web Server • The device runs a small web server application • A service runs on the device to generate run-time HTML file • The remote terminal manager access the device via the web browser and execute scripts on the device

  23. Web Server (example)

  24. UPnP Overall stack Control stack

  25. SNMP

  26. Monitoring SNMP (example)

  27. Inside client Server WAP client root client DM protocol proprietary proprietary Vendor SyncML upgrade client • Data Synch protocol • Add • Get • Replace • Exec X* … Logical tree for addressing purposes. In scope of DM standard! … … OMA DM SyncML DM (OMA) Over the air

  28. OMA DM SyncML DM (OMA) • Server <Get> <CmdID>4</CmdID> <Item> <Target> <LocURI>Vendor/Ring_signals/Default_ring</LocURI> </Target> </Item> </Get> • Client <Results> <CmdRef>4</CmdRef> <CmdID>7</CmdID> <Item> <Data>MyOwnRing</Data> </Item> </Results>

  29. OMA DM SyncML DM (OMA)

  30. Review of approaches • Virtual Network Computing (VNC, open source) (Dropped due to obvious security problems) • Web server (Dropped due to less flexibility and limited functionalities) • UPnP based (Dropped due to less competitive with SyncML DM) • SNMP based (Continuing as the complementary) • SyncML DM (Continuing as the main reference)

More Related