an operators input for onem2m baseline group name: tp#2/wg1 source: dtag, vodafone group meeting...

An Operators Input for oneM2M Baseline

Group name: TP#2/WG1 Source: DTAG, Vodafone Group Meeting Date: 2012-12-10 Agenda Item: WG1 agenda item 6

Intended purpose of document:

• Decision• Discussion• Information• Other <specify>

Slide 1© 2012 oneM2M Partners

oneM2M-REQ-2012-0070r1

• 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 LayerFunctions *not* dealing with data

Data Management LayerFunctions dealing with data

Vertical Applications (services to an end customer)

App1 App2 App4App3 App5 App6 App7

Layered View & oneM2M

Other API’s (not

M2M)

oneM2M

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






Layering facilitates Business Models (I – Connectivity)

Operator

Boundary

Connectivity Layer (management)Connectivity Layer (management)

Accessing connectivity capabilities





Layering facilitates Business Models (II – Service Enablement)

Service Enablement LayerFunctions *not* dealing with data Operator

Boundary





Layering facilitates business models (III – Data Management)


Operator

Boundary



Network Layer (HPLMN)

Connectivity Layer (HPLMN)



Vertical Applications

App1 App2 App3

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


Connectivity Layer (management)





Application Server

SCS1

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.

an operators input for onem2m baseline group name: tp#2/wg1 source: dtag, vodafone group meeting...

Documents