An Operators Input for oneM2M Baseline  Group name: TP#2/WG1  Source: DTAG, Vodafone Group  Meeting Date:  Agenda Item: WG1 agenda item 6 Intended purpose of document: Decision Discussion Information Other Slide 1© 2012 oneM2M Partners oneM2M-REQ r1

Expand range of M2M services Build on existing deployments Facilitate business models Reuse operator’s services Accelerate mass market and standard deployments Guiding Principles

M2M services range from basic device connectivity services to full data management Different business models exist today in markets, based on the different type of services offered Mobile nature of some machines demands roaming and compliance to data regulation Roaming agreements are today in place Local breakout is today decided by home operator Data from M2M Applications demands thoughtful consideration A layered model to facilitate evolution (not revolution) Rationale

Network Layer (HPLMN/VPLMN) Connectivity Layer (management) Service Enablement Layer Functions *not* dealing with data Data Management Layer Functions dealing with data Vertical Applications (services to an end customer) App1App2App4App3App5App6App7 Layered View & oneM2M Other API’s (not M2M) oneM2MoneM2M

Layers high level functions (features exposed via API’s but no need to standardize all)  Data management API’s  Reporting & Notifications  Data Store, sharing & charging  Content Management  Business rules & Policy management  AAA application control  Service Enablement API’s  (Service) Device management  Application management  (Service) Diagnostics  AAA service control  Business rules & Policy management  Network abstraction  Service level charging  Connectivity API’s?  AAA connectivity control  Registration and Roaming  Mobility, reachibility awareness  Interfacing operator’s BSS/OSS systems  Connectivity Based Charging  Network services exposure: Triggering, monitoring, small data “+” existing emergency, policy, call establishment, messaging…

Why layering?  Range of M2M services expanded  Different business models can be facilitated  Provides evolution from current market scenarios  Facilitates roaming scenarios  Roaming agreements preserved

Service Enablement Layer Functions *not* dealing with data Data Management Layer Functions dealing with data Vertical Applications (services to an end customer) App1App2App4App3App5App6App7 Network Layer (HPLMN/VPLMN) Layering facilitates Business Models (I – Connectivity) Operator Boundary Connectivity Layer (management) Accessing connectivity capabilities

Data Management Layer Functions dealing with data Vertical Applications (services to an end customer) App1App2App4App3App5App6App7 Network Layer (HPLMN/VPLMN) Layering facilitates Business Models (II – Service Enablement) Service Enablement Layer Functions *not* dealing with data Operator Boundary Connectivity Layer (management)

Vertical Applications (services to an end customer) App1App2App4App3App5App6App7 Network Layer (HPLMN/VPLMN) Layering facilitates business models (III – Data Management) Service Enablement Layer Functions *not* dealing with data Operator Boundary Data Management Layer Functions dealing with data Connectivity Layer (management)

Network Layer (HPLMN) Connectivity Layer (HPLMN) Service Enablement Layer Functions *not* dealing with data Data Management Layer Functions dealing with data Vertical Applications App1App2App3 Layering facilitates roaming and regulation Network Layer (VPLMN) Roaming Agreement M2M Application (with or w/o services level features) API’s based on business agreements HPLMN decides on local breakout or home routing Existing roaming agreements

 3GPP sees architected framework  Vertical markets see capabilities  Application developers make use of API’s  Discussions on mappings have not succeeded  Mapping combinations look multiple  SCS (Service capabilities server) not defined anywhere  AS (Application server) very much a telecom concept  Service Capabilities Layer (as per ETSI term) an over-the-top approach  Network operators, service providers and/or application providers may decide packing services based on commercial/business decisions OneM2M and 3GPP - different perspectives

Network Layer (HPLMN/VPLMN) Connectivity Layer (management) Service Enablement Layer Functions *not* dealing with data Data Management Layer Functions dealing with data Vertical Applications (services to an end customer) App1App2App4App3App5App6App7 Application Server SCS 1 One example mapping to 3GPP Hybrid Model Direct Model Seen from App perspective

Proposed Set of Requirements (I) Different business models shall be enabled where verticals shall be able to access different sets of M2M services: Connectivity management Device management Application Data management System to facilitate the use of services offered by telecom networks by means open access models (e.g. OSA, OMA, GSMA OneAPI framework), including example services like: IP Multimedia communications Messaging Location Charging and billing services Device information and profiles Configuration and management of devices (connectivity modules) Triggering, monitoring of devices … Different scenarios shall be enabled where services can be grouped or split for specific deployments.

Proposed Set of Requirements (II) (Temporary or permanent) Mobile capabilities of M2M Applications facilitated by reusing mobile telecom features (e.g. local breakout/home routing) and agreements M2M Applications data handling, management, storage and sharing to comply with relevant regulation (service) Device management to be delegated to network operator or handled independently (as applicable). Independent charging mechanisms for data management, device management or connectivity management.

Proposed Actions for OneM2M Consider a layered model to facilitate market evolution and business models. Consider telecom services (available via open interfaces) existing today, inclusive roaming. Harmonization of requirements/architectures shall consider requirements and functions to be facilitated by different layers. Discuss and agree proposed set of requirements for incorporation to normative requirements specification.