M2M middleware service

Inge Grønbæk,

Telenor R&IETSI Workshop on RFID and The Internet Of Things, 3rd and 4th December 2007

RFID and The Internet Of Things, ETSI, December 2007 2

Outline Introduction

Ubiquitous topology examples Service requirements and API

Role of API and example service Requirements Service aggregation and sub-layering RESTful approach to API Allocation of functionality to each layer

Architecture New network elements Allocation of functionality to network elements Protocol stacks Reference points and interfaces NGN and IMS capabilities

Implementation Alternatives for concrete API

RFID and The Internet Of Things, ETSI, December 2007 3

Example scenario with API

Service C

Service B

Service A

Business logic

Service provider B

Public Network Service

Platform

Data Repos.

co Business

logic co

Telco / Newco position

Service provider A

Device Network

Telco hub

Mobile or

Fixed

co

co

co

co

co

co co API

co Service Platform

API Legend:

API

API

RFID and The Internet Of Things, ETSI, December 2007 4

Role of API (OSA access to standard SCFs)

Network

GSM/GPRS/UMTS protocols, CAP/MAP (*)

SC 2 SC 3 SC n

Applications supporting services

Service capabilities SC 1

service capability features

Standardised OSA Application Interface

SC 4

API

RFID and The Internet Of Things, ETSI, December 2007 5

Top level requirementsTwo classes of service:

Session oriented (e.g. NGN/IMS, voice and streaming) Connectionless (e.g. Surveillance, control and telemetry)

Two categories of application Power constrained (e.g. battery powered sensors and actuators) Power abundant

Consequence Light weight implementation required for cheap low-power COs IP-based inter-domain interconnect required for ubiquitous services Session control required for streaming class of services.

RFID and The Internet Of Things, ETSI, December 2007 6

Service aggregation from sub-layers

CO applications-------------------------- Layer 6+ basic applicationsCO application components-------------------------- Layer 6 (Accessed via abstract Presentation API)Presentation-------------------------- Layer 5 (Accessed via abstract Session API)Session-------------------------- Layer 4 (Accessed via abstract Transport API)Transport-------------------------- Layer 3+ (Accessed via abstract Network API)IP bearer Multicast / Broadcast Mobility, location QoS control of IP bearer Identification / authentication, accounting and security (AAA)-------------------------- Layer 3 (Basic network service)Basic IP bearer

RFID and The Internet Of Things, ETSI, December 2007 7

OSA Parlay architecture

Parlay Gateway

Parlay X Web Services

Parlay X APIs

Parlay APIs

Parlay XApplications

ParlayApplications

Network Protocols (e.g. SIP, INAP etc)

Network Elements

Increasingabstraction

May be used

RFID and The Internet Of Things, ETSI, December 2007 8

Application component sub-layer Business opportunities:

Supply of service components as building blocks. Persistent third party storage and retrieval. Hosting of service logic. Accounting and billing. Customer Relation Management (CRM). Identity management and application based routing.

-------------------------------------------------------------- Included:

Naming and identities. Presence. Event notification.

RFID and The Internet Of Things, ETSI, December 2007 9

Naming and identities

The Internet has two important global namespaces: Internet Protocol (IP) addresses and Domain Name Service (DNS) names (i.e. URIs).

With a data-oriented application interface, the applications would revolve around the names of data and services, not the address or hostname of their location.

Host Identity Tags (HITs) from a flat namespace is therefore proposed. HIT is the hash of the public key in a public/private key pair. Will accommodate Electronic Product Codes (EPC)

However, backward compatibility demands the architecture to handle IP, MSISDN and URI based names.

RFID and The Internet Of Things, ETSI, December 2007 10

Presence and notification

Register (Registrar-CO-ID, Parameters) Event-Subscription (Target-CO-ID, Parameters) Event-Notification (Registrar-CO-ID, Target-CO-ID, Parameters) Event-Report (Registrar-CO-ID, Parameters)

RFID and The Internet Of Things, ETSI, December 2007 11

Abstract Presentation service

Vocabulary for (control of) CO service applications. I.e. The data structures and commands required for Connected Objects to function and interoperate. Many ongoing standards initiatives e.g. based on XML/WSDL.

• Canonical Situation Data Format: The Common Base Event V1.0.1

The actual monitoring or control protocol may be proprietary. The Architecture offers a container for carrying the information. The allocation of this functionality is at the discretion of the control

system designer.

Presentation layer protocols identified: HTTP, RTP, RTCP, RTSP and codecs.

RFID and The Internet Of Things, ETSI, December 2007 12

Data-driven approach to API. Dr. R. Fielding Representational State Transfer (REST)

REST creates an environment where clients and servers that encode their information the same way work together.

The uniform interface is meant to evolve over time. That is why it is built from three different parts that serve different purposes: Identifiers for (new) objects, Methods, (Document/data) types to be exchanged.

Each part is designed to change independently of the other parts.

RFID and The Internet Of Things, ETSI, December 2007 13

REST example

Instead of a "turnOnTheLightbulb" request to a server object, we have a PUT "true" to the http://example.com/lightbulb/lit object.

The http://example.com/lightbulb/lit object also responds to a GET request that returns true or false.

In this example everything is standard. The request is understood by everyone. A plain XML data type is interpreted by the server. The CO object is defined using a standard API The only thing special is the actual selection of which object to send

the request to.

RFID and The Internet Of Things, ETSI, December 2007 14

Abstract Session service primitives

A session represent the state of active communication between connected objects. Not required to be established by e.g. the Session Initiation Protocol

(SIP).

The session layer API service primitives may be mapped on the following protocols: XML (Parlay-X style) Session Initiating Protocol (SIP) Transmission Control Protocol (TCP) A link layer protocol (e.g. HDLC)

The initial implementation may be based on XML.

RFID and The Internet Of Things, ETSI, December 2007 15

Abstract Transport service

Transport-Selection (Destination-CO-ID, Protocol, SA). The SA is used to identify the transport session and the applied

protocols. The initial protocol offerings will be UDP, TCP, MQTT(s) or NIL.

Primitives from subordinate layers will be applied e.g. for sending and receiving data. Send-SA (SA, Data)

RFID and The Internet Of Things, ETSI, December 2007 16

Abstract Network Service - data (1)

The following primitives for sending and receiving unsecured and secured data:

Send-ID (CO-ID, Data)Receive-ID (CO-ID, Data)

Send-SA (SA, Data) Receive-SA (SA, Data)

SA-Create (CO-ID, Profile, SA)SA-End (SA) % SA: Security Association----------------------------------------------------------------

Send-IP (To-IP-address, Data)Receive-IP (From-IP-address, Data)

RFID and The Internet Of Things, ETSI, December 2007 17

Multicast (2)

The Abstract API for specifying multicast to be applied for a group of Connected Objects is composed of the following primitives:

MC-Group-Open (Group-ID) MC-Group-Close (Group-ID)

Primitives used to send and receive Data: Send-ID (Group-ID, Data) Receive-ID (Group-ID, Data)

The joining and leaving of a multicast group is achieved by the following primitives:

MC-Group-Join (Group-ID) MC-Group-Leave (Group-ID)

RFID and The Internet Of Things, ETSI, December 2007 18

Mobility management (3)

The Abstract API for specifying mobility management to be applied for a CO is composed of the following primitives:

MM-Register() MM-End()

RFID and The Internet Of Things, ETSI, December 2007 19

QoS (4)

The Abstract API for specifying a default QoS to be applied is composed of the following primitives:

QoS-Set-Default (Profile) QoS-End-Default (Profile)

The Abstract API for explicit QoS control is composed of the following primitives:

QoS-Set-Path (Destination-CO-ID, Profile) QoS-End-Path (Destination-CO-ID, Profile)

RFID and The Internet Of Things, ETSI, December 2007 20

Status and location (5) Location-Request (CO-ID-Set, Scheme)

The CO-ID-Set identifies one or more COs Location-Response (RVS-CO-ID, CO-ID-Set, Scheme, Status,

Coordinate-Set)The following primitives are used to request the network to identify

objects at a specific location: ID-Location-Request (HIT-Gateway, Scheme, Coordinate-set) ID-Location-Response (HIT-Gateway, Scheme, Coordinates-set,

Status, CO-ID-Set)Reporting of end-system supplied location and status is also

defined.

RFID and The Internet Of Things, ETSI, December 2007 21

Accounting and logging (6)

The Abstract API for accounting and logging is composed of the following primitives:

Logging-Start (Profile)% Profile specifies the logging profile.

Logging-Stop (Profile)

The history may be used for many diverse purposes.