1 / 21

M2M middleware service

M2M middleware service. Inge Grønbæk, Telenor R&I. ETSI Workshop on RFID and The Internet Of Things, 3rd and 4th December 2007. Outline. Introduction Ubiquitous topology examples Service requirements and API Role of API and example service Requirements

bramsay
Download Presentation

M2M middleware service

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. M2M middleware service Inge Grønbæk, Telenor R&I 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 RFID and The Internet Of Things, ETSI, December 2007

  3. Example scenario with API RFID and The Internet Of Things, ETSI, December 2007

  4. Role of API (OSA access to standard SCFs) API RFID and The Internet Of Things, ETSI, December 2007

  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. RFID and The Internet Of Things, ETSI, December 2007

  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 RFID and The Internet Of Things, ETSI, December 2007

  7. OSA Parlay architecture 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. RFID and The Internet Of Things, ETSI, December 2007

More Related