M2M middleware service

1
M2M middleware service
Inge Grønbæk, Telenor RI
ETSI Workshop on RFID and The Internet Of Things,
3rd and 4th 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

3
Example scenario with API
4
Role of API (OSA access to standard SCFs)
API
5
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.

6
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

7
OSA Parlay architecture
May be used
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.

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.

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)

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.

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.

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.

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.

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)

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)

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)

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()

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)

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.

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.