Presentation is loading. Please wait.

Presentation is loading. Please wait.

M2M middleware service Inge Grønbæk, Telenor R&I ETSI Workshop on RFID and The Internet Of Things, 3rd and 4th December 2007.

Similar presentations


Presentation on theme: "M2M middleware service Inge Grønbæk, Telenor R&I ETSI Workshop on RFID and The Internet Of Things, 3rd and 4th December 2007."— 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 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

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

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

5 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.

6 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

7 RFID and The Internet Of Things, ETSI, December 2007 7 OSA Parlay architecture May be used

8 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.

9 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.

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

11 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.

12 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.

13 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.http://example.com/lightbulb/lit The http://example.com/lightbulb/lit object also responds to a GET request that returns true or false.http://example.com/lightbulb/lit 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 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.

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

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

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

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

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

20 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.

21 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.


Download ppt "M2M middleware service Inge Grønbæk, Telenor R&I ETSI Workshop on RFID and The Internet Of Things, 3rd and 4th December 2007."

Similar presentations


Ads by Google