Transcript M2M middleware service - Docbox

M2M middleware service
ETSI Workshop on RFID and The Internet Of
Things, 3rd and 4th December 2007
Inge Grønbæk,
Telenor R&I
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
2
Example scenario with API
API
Legend:
Service
Platform
co
Service provider B
co
co
Business
logic
API
Service provider A
Service A
co
Business
logic
co
Service B
API
co
Device
Network
co
Service C
Telco
hub
co
co
Mobile
or
Fixed
Public
Network
Service
Platform
co
API
Telco / Newco position
Data
Repos.
RFID and The Internet Of Things, ETSI, December 2007
3
Role of API (OSA access to standard SCFs)
API
RFID and The Internet Of Things, ETSI, December 2007
4
Top level requirements
Two 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
5
Service aggregation from sub-layers
CO applications
-------------------------Layer 6+ basic applications
CO 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
6
OSA Parlay architecture
May be used
RFID and The Internet Of Things, ETSI, December 2007
7
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
8
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
9
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
10
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
11
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
12
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
13
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
14
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
15
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
16
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
17
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
18
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
19
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
20
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.
RFID and The Internet Of Things, ETSI, December 2007
21