DM Collaboration – OMA & BBF: Deployment Scenarios Group Name: WG5 - MAS Source: Tim Carey, ALU, Meeting Date: 2013-11-06.

Slides:



Advertisements
Similar presentations
1 Symbian Client Server Architecture. 2 Client, who (a software module) needs service from service provider (another software module) Server, who provide.
Advertisements

Geneva, Switzerland, 17 October 2011 ITU Workshop on Service Delivery Platforms (SDP) for Telecommunication Ecosystems: from todays realities to requirements.
Creating HIPAA-Compliant Medical Data Applications with Amazon Web Services Presented by, Tulika Srivastava Purdue University.
ETSI M2M / TIA architecture harmonization O. Elloumi.
28.2 Functionality Application Software Provides Applications supply the high-level services that user access, and determine how users perceive the capabilities.
Technical Architectures
Virtual Private Network
CSIT 320 (Blum)1 Client-Server Interaction Based on Appendix 1 in Computer Networks and Internets, Comer.
Microsoft ® Application Virtualization 4.6 Infrastructure Planning and Design Published: September 2008 Updated: February 2010.
Device Management using mgmtCmd resource
Device Management using mgmtCmd resource Group Name: WG2/WG5 Source: InterDigital Communications Meeting Date: Agenda Item: TBD.
Network+ Guide to Networks, Fourth Edition
Threat Management Gateway 2010 Questo sconosciuto? …ancora per poco! Manuela Polcaro Security Advisor.
RoA and SoA Integration for Message Brokers Group Name: WG2-ARC Source: ALU Meeting Date: Agenda Item:
Mechanism to support establishment of charging policies Group Name: WG2-ARC Source: InterDigital Meeting Date: TP8 Agenda Item:
Progressing the Work on the MAS TR-0006, TR-0007 Group Name: Management Abstraction and Semantics Source: Tim Carey, ALU,
An Operators Input for oneM2M Baseline  Group name: TP#2/WG1  Source: DTAG, Vodafone Group  Meeting Date:  Agenda Item: WG1 agenda item.
Computer Emergency Notification System (CENS)
Remote Access Using Citrix Presentation Server December 6, 2006 Matthew Granger IT665.
1 4/23/2007 Introduction to Grid computing Sunil Avutu Graduate Student Dept.of Computer Science.
Authorization for IoT Group Name: oneM2M SEC WG Source: Francois Ennesser, Gemalto NV Meeting Date: Agenda Item:
3GPP Rel-13 Interworking discussions
An operator’s perspective on support for different M2M deployment scenarios AT&T Group Name: TP Source: Farooq Bari, Jianrong Wang; AT&T;
Device Management A unified way of managing devices enabled by different management technologies Group Name: WG2/WG5 Source: Huawei Technologies Co., Ltd.
WG5 - MAS Progress Report at TP #9 Group Name: WG5 MAS (Management, Abstraction & Semantics) Source: Yongjing Zhang, Chair, Meeting.
Proposal for WG3 & WG5 work area split
Architectural Principles for Services Group Name: WG2- ARC Source: Tim Carey, ALU, Meeting Date: Agenda Item:
An Introduction to Networking
Step by step approach Group Name: WG2 Source: Michael hs. Yang, LG uplus, Jaeseung Song, NEC Europe, Meeting.
Status Report on Access TP8 Group Name: WG2 Decision  Meeting Date: Discussion  Source: OBERTHUR Technologies Information  Contact:
© 2013, published by Flat World Knowledge Chapter 10 Understanding Software: A Primer for Managers 10-1.
Introducing WI Proposal about Authorization Architecture and Policy Group Name: WG4 Source: Wei Zhou, Datang, Meeting Date: Agenda Item:
Distributed System Architectures Yonsei University 2 nd Semester, 2014 Woo-Cheol Kim.
Device Management using mgmtCmd resource Group Name: WG2/WG5 Source: InterDigital Communications Meeting Date: Agenda Item: TBD.
3GPP Rel-13 Interworking discussions
An Analysis of XMPP Security Team “Vision” Chris Nelson Ashwin Kulkarni Nitin Khatri Taulant Haka Yong Chen CMPE 209 Spring 2009.
Role Based Access Control In oneM2m
M2M Study Item 3GPP2 Orlett W. Pearson May | 3GPP2 M2M Study Item | May GPP2 M2M This study will include the following study targets: 
GRID ANATOMY Advanced Computing Concepts – Dr. Emmanuel Pilli.
Comments on Procedures for RBAC (doc#0056) Group Name: WG4(SEC), WG2(ARC) and WG5(MAS) Source: Suresh Nair, Alcatel-Lucent,
Realizing Ms Interface with OMA DM Group Name: MAS WG Source: Seungkyu Park, LG Meeting Date:
SE abstraction scenarios Group Name: SEC Source: Claus Dietze, Giesecke & Devrient Meeting Date: Agenda Item: WI SE abstraction.
Discussion about RESTful Admin API Group Name: SEC & ARC Source: FUJITSU Meeting Date: Agenda Item: Device Configuration.
File Transfer And Access (FTP, TFTP, NFS). Remote File Access, Transfer and Storage Networks For different goals variety of approaches to remote file.
M2M Service Layer – DM Server Security Group Name: OMA-BBF-oneM2M Adhoc Source: Timothy Carey, Meeting Date:
The overview How the open market works. Players and Bodies  The main players are –The component supplier  Document  Binary –The authorized supplier.
Device Management Deployments In oneM2m Group Name: MAS Working Group Source: Timothy Carey, Alcatel-Lucent, Meeting Date:
VPN. CONFIDENTIAL Agenda Introduction Types of VPN What are VPN Tokens Types of VPN Tokens RSA How tokens Work How does a user login to VPN using VPN.
Call for input from WGs on things to test Group Name: TST Source: Jiaxin Yin, Huawei Technologies Co., Ltd., Meeting Date:
WG5 - MAS Progress Report at TP #8 Group Name: WG5 MAS (Management, Abstraction & Semantics) Source: Yongjing Zhang, Chair, Meeting.
1 Server Business Logic & OAuth Beta Overview October 4, 2010 Alan Hantke Product Development Server Business Logic Intuit Partner Platform Diane Weiss.
Management CSF(s) Architectural choices Group Name: WG2 (ARC), WG5(MAS) Source: Catalina Mladin, InterDigital Comm., Meeting.
Specifying the Address of Management Client of Managed Entity Group Name: ARC Source: Hongbeom Ahn, SK Telecom, Meeting Date: TP#21 Agenda.
3GPP Rel-13 Interworking discussions Group Name: TP #18 Source: Rejesh Bhalla, ZTE Corporation, Meeting Date: Agenda Item:
ArcGIS for Server Security: Advanced
Unit 3 Virtualization.
Building Distributed Educational Applications using P2P
3GPP interworking in R3 Group Name: ARC
Possible options of using DDS in oneM2M
3GPP Rel-13 Interworking discussions
Considering issues regarding handling token
CSC 480 Software Engineering
Deployment Diagram.
Introduction to Cloud Computing
Chapter 3: Windows7 Part 4.
An Introduction to Software Architecture
Introduction to Computing
SMART HOME Expectation IN STANDARDS
Computer Networks Protocols
Realizing a Peer-to-Peer System using a common API
Presentation transcript:

DM Collaboration – OMA & BBF: Deployment Scenarios Group Name: WG5 - MAS Source: Tim Carey, ALU, Meeting Date: Agenda Item: MAS Adhoc

© 2013 oneM2M Partners oneM2M-MAS DM_Collaboration_OMA_BBF_Deployment_Scenarios 2 Meeting Topic for Today oneM2M Deployment Scenarios Session Management between the Service Layer and DM Servers Translation Approach Security establishment between the Service Layer and DM Servers

© 2013 oneM2M Partners oneM2M-MAS DM_Collaboration_OMA_BBF_Deployment_Scenarios 3 Introduction As oneM2M analyzed architectural approaches to device management we started with looking at deployment scenarios that exist in today’s environment and are possible in the future: – Managed Device Using Network Operator Management – Managed Device Using Service Provider Management – Shared Managed Device Using Network Operator Management – Shared Managed Device Using Service Provider Management – Shared Managed Device Using Separate Management – Federated Managed Device Using Separate Management

© 2013 oneM2M Partners oneM2M-MAS DM_Collaboration_OMA_BBF_Deployment_Scenarios 4 Managed Device Using Network Operator Management Network operator has, other than the end user, exclusive control of the resources within the device Utilize a management client in the device that connects to the Network operator’s management server Typically there is one instance of the management client within the device that connects to one management server. The management client in the device offers a proxier capabability that provides the underlying network operator with the capability to manage devices that do not have their own management client. Network operator ensures exclusive control of the resources within the device by providing device firmware and software that have been approved for use by the Network operator

© 2013 oneM2M Partners oneM2M-MAS DM_Collaboration_OMA_BBF_Deployment_Scenarios 5 Managed Device Using Service Provider Management M2M System a new stakeholder, the M2M Service Provider, also requires control of resources of the device M2M Service Provider controls all or selected resources of the device via its own management server which may be part of the M2M Service Platform Network operator ensures that the M2M Service Provider has control of underlying network operator restricted resources using an out-of-band responsibility delegation mechanism. The delegation mechanism utilized is usually a certification process by the underlying network operator of the firmware and software that is downloaded on the device by the M2M Service Provider.

© 2013 oneM2M Partners oneM2M-MAS DM_Collaboration_OMA_BBF_Deployment_Scenarios 6 Shared Managed Device Using Network Operator Management Network operator and the M2M Service Provider share control of the device by utilizing the underlying network operator’s management server Network operator restricts which resources the M2M Service Provider can control by exposing the capabilities from the management server to the M2M Service Platform Typically this is performed by providing the M2M Service Provider an account, with appropriate access control to the resources, within the underlying network operators management server

© 2013 oneM2M Partners oneM2M-MAS DM_Collaboration_OMA_BBF_Deployment_Scenarios 7 Shared Managed Device Using Service Provider Management Network operator and the M2M Service Provider share control of the device by utilizing the service provider’s management server The service provider’s management server is the primary DM server, and any requests that the Network operator wants to initiate on the M2M device using occurs over the X interface to the service provider’s Common Services Entity which in turn sends the request to the service provider’s DM server who will execute the DM operation This scenario is typically interesting when the M2M Service Provider uses different underlying networks that all require some “unified” DM access to the M2M devices

© 2013 oneM2M Partners oneM2M-MAS DM_Collaboration_OMA_BBF_Deployment_Scenarios 8 Shared Managed Device Using Separate Management Network operator and the M2M Service Provider share control of the device by utilizing separate management servers The authorization enforcement point can be implemented within the device using the delegation and access control list features of the device management technologies or in the M2M Service Platform Regardless of the enforcement point, the network operator restricts control to the network operator controlled resources by certifying the firmware and software that is placed on the device It should be noted that some technologies (e.g., TR-069) cannot implement the scenario as a management client can only connect to one management server

© 2013 oneM2M Partners oneM2M-MAS DM_Collaboration_OMA_BBF_Deployment_Scenarios 9 Federated Managed Device Using Separate Management The control of resources in a device is federated within separate operating environments of the device Typical of devices with multiple CPU complexes where one complex is dedicated to the access network termination functions (e.g., machine termination) while another CPU complex is dedicated to application functions There are multiple management clients where a management client is assigned to the M2M Service Provider’s management server and another management client is assigned to the underlying network operator’s management server

© 2013 oneM2M Partners oneM2M-MAS DM_Collaboration_OMA_BBF_Deployment_Scenarios 10 Conclusions from these Scenarios The M2M Service Provider manages resources in a device by: – Utilizing the Network Operator's management server to access resources in the device – Operating a separately owned management server that allows access to resources in the device. In this case, a separate management client might exist in the device to which the M2M Service Provider’s management server connects. Resources within a device are owned by either the Network Operator or the M2M Service Provider. Access to the resource is controlled by: – Certifying the firmware or software that is used on the device – Utilizing the access control mechanisms of the device management technologies (e.g., accounts, delegation, access control lists)