Mobile Server Platform - Architectures and Protocols for Future M2M Ecosystems

Public Doctoral Presentation

Architectures and Protocols for Future M2M Ecosystems

Fahad Aijaz

ComNets Research Group
RWTH Aachen University

July 12, 2011

© Fahad Aijaz, ComNets, RWTH Aachen University

Outline of Talk
• Research Area in a Nutshell
• Motivation and Research Gap
• The Mobile Server Platform
– The Mobile Web Server Layer
• Architecture, Payload and Performance Aspects
• Multimedia Extensions and Topologies
– The SLA Framework Layer
• Components and Life Cycles
• Performance Analysis
• The Software Application Layer
– MEDICARE – A Context-Aware Health Care Application
– Social Network in Pocket (SNiP)
• Conclusion and Outlook
© Fahad Aijaz, ComNets, RWTH Aachen University 2

Research Area in a Nutshell
Today‘s Internet and the WWW Internet of Things = M2M
 High-tech Web Servers. M2M Terminal M2M Terminal
 Hosts Web Service and Resources. CONSUMER + PROVIDER CONSUMER + PROVIDER
 Transparent Access to the Clients.
 Neutral towards diverse clients.
Mobile
Web Server
? Consume
Mobile
Web Server

TRANSPARENT
ACCESS
Mobile
Web Services ? Mobile
Web Services

WEB SERVICES
- Specialized functions
- Internal process Publish/Search/ Publish/Search/
- Access interface Outsource Outsource
Web Service
Broker/
Cloud
Computing
- Private Data
- Multimedia
- Websites
RESOURCES Web Server M2M Services

Motivation and Research Gap
Mobile devices are not only mobile phones!

Industrial Automation
1
interaction
2 Automotive / Telemetric

Variable Capabilities & Requirements
access interfaces
PROPERTIES
3 Smart Energy Grids service protection
 Only request-response based. Mobile
 Immediate service Web Server execution models
invocation, only. 4 Health Care Sector
 Short-lived executions. messaging protocols
 Respond on same network Mobile 5
infrastructure (blocking Web Services Home Automation
service management
call!).
 Runtime service 6 standard operations
management is not possible. Social Networking
data privacy
7
Transform into Web 2.0 Services

M2M Domain Requirements Mobile Server Platform M2M Applications

Provides a general middleware architecture and protocol stack for rapid development of M2M applications
This research gap has been confirmed through literature!

The Mobile Server Platform
(Conceptual Overview)
Health Care | Social Networks
The MSP provides a set of strategically connected architectures

The platforms architecture is categorized into logical layers Applications‘
Offers a Web Services provisioning solution for M2M apps

private data
Software Application Layer

Notification
Service Interaction Strategies

SOAP Access REST Access
Interface Interface XML/REST, JSON/REST
Solicit-Response

SLA Framework Layer WEB SERVICE AGREEMENTS
Request-Response

One-way Mobile Web Server Layer
 Server Endpoints

Observer
Instance
Factory
 Server Process Classification
 Multi-Interfaced Services
 Multimedia Delivery & Control
AGREEMENT
PROTECTED Asynchronous Server Endpoints
SERVICES

ASYNCHRONOUS SERVICE
ACCESS PROTOCOL

Multi-Interfaced Mobile Web Services
Synchronous Asynchronous
HTTP/TCP | RTP/UDP | IEEE 802.15.4
Mobile Web Services Mobile Web Services
© Fahad Aijaz


The Mobile Web Server Layer
(Classification of Server Processes)
Mandatory process to consume asynchronous Mobile Web services

Involved Server 1 2

Observer

Instance
Factory
Endpoints
Service Management Process
Service Creation Process

CreateInstance
Create with
Observer EPR
Service Factory

MOBILE WEB SERVICE
2

ASYNCHRONOUS
Request with
Observer EPR

Service Instance 3b

solicit-response / notification
1a

Response with 3a
Instance EPR
Service Observer
mutually exclusive
service invocations
starts 1b
4
Completed

Notification Service Computation Result
Listener (normal completion)


(Classification of Server Processes)
Only possible subsequent to the Service Creation Process
Service Managemenr Process

STATES OF AN
ASYNCHRONOUS MOBILE WEB SERVICE
Service Creation Process

GetProperties
Unsubscribe open.running

CONTROLLABLE
Subscribe 3
open.notrunning
SetProperties
ChangeState open.notrunning.suspended

Service Instance closed.abnormalCompleted.terminated
Request with
Observer EPR closed.abnormalCompleted

INTERNAL
2
closed.completed
1
Response with closed.abnormalCompleted.aborted
mutually exclusive
Instance EPR
Service Observer service states
ASYNCHRONOUS
MOBILE WEB SERVICE
Notification
Listener GetProperties 4
StateChanged

Events and State Notifications
(solicit-response / notification)


(SOAP Access Interface Overheads)
Thick Clients Activity Oriented XML Based only! High Payload (WS-*) Processing Overhead
SOAP Access Interface

SOAP Envelope

SOAP CLIENT SOAP SERVER
<SOAP-ENV … > - Receive SOAP Envelope
- Construct Req. SOAP
<SOAP-HEADER …> >
<SOAP-HEADER … - Parse Req. SOAP
- Embed Custom XML <!–- WS-* Specifications
<!–- WS-* Specifications - Parse Embedded XML
- Conform to WS-* Custom XML … -->
Custom XML … --> - Parse WS-*
- Send SOAP Envelope </SOAP-HEADER>
</SOAP-HEADER…> - Process Request
- Receive Response
<SOAP-BODY …> >
<SOAP-BODY … - Construct Resp. SOAP
- Parse Resp. SOAP <!–- WS-* Specifications
<!–- WS-* Specifications - Embed Resp. Custom XML
- Parse Embedded XML Custom XML
Custom XML - Conform to WS-*
- Parse WS-* Complex Types … -->
Complex Types … --> - Send SOAP Envelope
-… </SOAP-BODY>
</SOAP-BODY…> -…
</SOAP-ENV>

Service as a Resource (SaaR) Performance Optimization

?
SERVER
CLIENT
- Receive HTTP Req.
- Construct Payload HTTP Request: GET, POST, PUT, DELETE - Process Request URL
- Send as HTTP Req.
- Send as HTTP Resp.
- Receive Response CUSTOMIZED-PAYLOAD -…
- Parse HTTP Resp.
-…

Think Clients Resource/Activity Oriented Format Neutral WWW-like Access Light-weight


(SaaR Design Approach)

RE S T Access
Service Provider specifies the mapping semanctics for each method

presentational tate ransfer
Static network resources Every resource Resources

Interface
Network resources
changes the client’s are transferred
Example: HTML, XML, JPG, GIF…
state using HTTP

Synchronous Access URL Service Logic
SYNCHRONOUS URL ELEMENTS

CREATE |POST
HTTP : // IP : PORT / SERVICE / METHOD
READ |GET
mandatory optional UPDATE |PUT
DELETE |DELETE
Asynchronous Access URL
ASYNCHRONOUS URL ELEMENTS

HTTP : // IP : PORT / SERVICE / METHOD / STRATEGY / ENDPOINT / OPERATION

mandatory optional mandatory


(Payload Optimization)
XML payload comparison of the operations offered by Service Factory Endpoint

SOAP Payload REST Payload

CreateInstanceRs ≈ 82 % reduction
Operations of the Service Factory endpoint

CreateInstanceRq ≈ 67 % reduction

ListInstanceRs ≈ 67 % reduction

ListInstanceRq ≈ 83 % reduction

GetPropertiesRs ≈ 67 % reduction

GetPropertiesRq ≈ 95 % reduction

0 100 200 300 400 500 600 700 800

XML payload in bytes

JSON/REST results in much optimized payload than the XML/REST

(Prototypical Performance Evaluation)
Mean Latency of the Asynchronous Server with SOAP and XML/REST Interfaces

SOAP Access Interface REST Access Interface
MEAN LATENCY AND STANDARD DEVIATION OF THE ASYNCHRONOUS SOAP SERVER MEAN LATENCY AND STANDARD DEVIATION OF THE ASYNCHRONOUS REST SERVER

Asynchronous SOAP Server Asynchronous REST Server
120 55
Mean Mean
110 Standard Deviation 50 Standard Deviation

100
Server Processing Latencies [ms]

76.62 ms

Server Processing Latencies [ms]
45
90 10.71 ms
40
80
35
70 15.8 ms
30
60 -10.71 ms
25
50 6.493 ms
40 20

30 15

20 10
-6.493 ms
10 5

5 10 15 20 25 30 35 40 45 50 5 10 15 20 25 30 35 40 45 50
No. of Requests No. of Requests

Asynchronous Server with the REST Access Interface performs ≈79% faster

(Basic Analysis of XML and JSON Payloads)

JSON elements XML elements
XML Encoding 25

<R>
<123> </123>
20
S XML  5  2  Broot _ name    5  2  Belement 
<123> </123> n

_ name
<123> </123> e 1

...
15
Data in Bytes

</R>

JSON Encoding 7 bytes allocated by the
10
{ XML root tag of 1 byte

 7  B 
n
"123" : null
S JSON  2  element _ name
"123" : null 5 e 1

"123" : null
2 bytes allocated by the start
... and end braces of JSON element
} 0


(Basic Analysis of XML and JSON Payloads)
Difference trend with 25 elements Difference trend with 210 elements
S XML  S JSON
0.35 11
3 bytes 10.5 3 bytes
0.325
8 bytes 10 8 bytes
0.3 13 bytes > 0.325 9.5 13 bytes ≈ 10.5
18 bytes
MB 9 18 bytes MB
0.275 23 bytes 8.5 23 bytes

0.25 8
7.5
Difference in Payload (MB)

Difference in Payload (MB)
0.225 7
6.5
0.2
6
0.175 5.5
5
0.15
4.5
0.125 4
3.5
0.1
3
2.5
0.075
< 0.025 2 ≈ 0.5
0.05 MB 1.5 MB
0.025 1
0.5
2 4 8 16 32 2 4 8 16 32 64 128 256 512 1024
No. of Elements No. of Elements

JSON results in less data transmission as number of elements increase
Lengthy element names result in much rapid increase is payload
JSON/REST for M2M terminals  Less computation requirements

(Multimedia Extensions and Topologies)
Integration of RTSP and RTP Extended RTSP States in Asynchronous Server
Offers a Web Service provisioning solution through M2M terminals

Software Application Layer

Mobile Web Server Layer

Observer
Instance
Factory

Multi-Interfaced Mobile Web Services

Delivery Resource  Asynchronous Services Control Resource  Synchronous and Asynchronous Services
Multimedia Delivery Strategy  RTP/UDP Multimedia Control Strategy  RTSP/TCP
The RTSP SETUP, PLAY, PAUSE and TEARDOWN are exposed as states of asynchronous services
The RTSP OPTIONS and DESCRIBE methods are exposed as synchronous mobile Web Services

(Multimedia Extensions and Topologies)
Relayed Delivery and Relayed Control
Multimedia Delivery Strategy  RTP/UDP
Multimedia Control Strategy  RTSP/TCP
Synchronous and Asynchronous Servers work together
Relays Control INTERMEDIATE KNOWN PUBLIC IP/PORT
Relays Multimedia ACCESS GATEWAY Server
Client
TCP TUNNEL

Server Layer
Mobile Web
Mobile Web
Server Layer

CONTROL HOLE
HOLE
CHANNEL PUNCHING
PUNCHING

RTSP/TCP RTSP/REST
TCP
TCP
RTP/UDP RTP/UDP
UDP INTERNET UDP

NAT/ DELIVERY NAT/
FIREWALL CHANNEL FIREWALL
PRIVATE IP/PORT PRIVATE IP/PORT

Works with every network where interaction are enabled!
Sequence of events during the TCP/UDP

1 Server establishes a permanent TCP tunnel with the IAG  TCP hole punching
2 The client sends RTSP SETUP to the IAG  IAG relays it to server  SCP response
3 Only client sends UDP to IAG  IAG is not introducer gateway  sends keep-alive to client
4 Client sends RTSP PLAY to IAG  IAG relays it to server  Service Management Process
5 Server indirectly delivers media over the RTP/UDP channel that is relayed by the IAG
6 Client may send RTSP PAUSE, TEARDOWN via IAG  Service Management Process

The SLA Framework Layer
Extends the Mobile Web Server Layer
 The functions of the SLA architecture are classified
into 4 distinct life cycles
Service Level Agreements Framework
 The SLA life cycles are executed based on the
incoming mobile Web Service requests
 The SLA negotiation is based on
the Web Service Agreement
4 LIFE CYCLES OF THE
standard of the Open Grid
Forum
SLA FRAMEWORK
 The standard is
optimized to define
the SLA messaging
for mobile nodes Agreement Offer Service Invocation
Agreement Agreement QoS Disposal
Life Cycle Life Cycle
 The SLA framework Creation Evaluation Monitoring Monitoring
is compatible with (AC) (AE) (QM) (DM)
the REST and SOAP
access interfaces
 Protects both, the Template Agreement
Acquisition Disposal
synchronous and Life Cycle Life Cycle
asynchronous services

The life cycles utilize the properties of the Synchronous and Asynchronous Servers

(Life Cycles)
Template Aquisition Life Cycle

1 MOBILE WEB SERVICE
CLIENTS
A) Reads and manipulates the template
MOBILE WEB SERVICE
HOST
PROTECTED
MOBILE WEB SERVICE

A) Associated agreement
B) Generates a UUID for the client
Agreement C) Saves a copy against the UUID
SLA Mobile Server template with validity
B) Must be used before expiry
Creation REST REQUEST C) Automated deletion
http://xperia.comnets.de:9090/FetchTemplate
(AC)
1 FETCH TEMPLATE AC FT

AGREEMENT TEMPLATE 2 SERVICE PROVIDER’S
Template
UUID + AGREEMENT TEMPLATE -- -- AGREEMENT TEMPLATE
Acquisition Stored in the mobile
Life Cycle ! host or the cloud
FETCH TEMPLATE
SYNCHRONOUS
MOBILE WEB SERVICE

Agreement Offer Life Cycle

CLIENTS
A) Verify the UUID of the client
B) Notify the requesting client
C) Transitions to the evaluation
MOBILE WEB SERVICE
HOST

Agreement phase (if verified)
SLA Mobile Server
Creation
(AC) A) Reads the agreement terms
B) Prepares an agreement offer
3 AGREEMENT OFFER + UUID AC
UUID
C) Sends the agreement offer as NOTIFICATION Verification
an asynchronous request
a) Agreement creation phase is completed
Agreement Offer ! b) Agreement evaluation phase is started
Life Cycle
Agreement AGREEMENT ACCEPT/REJECT 4 AE Offer
Evaluation
Evaluation A) Evaluate the agreement offer against -- --

the related template
(AE) AGREEMENT AGREEMENT
B) Accept or reject the agreement offer
TEMPLATE OFFER
NEGOTIATED C) Save a copy (if accepted) & notify PROTECTED
AGREEMENT the client MOBILE WEB SERVICE


(Life Cycles)
Template Aquisition Life Cycle

CLIENTS
A) Reads and manipulates the template
MOBILE WEB SERVICE
HOST
PROTECTED
MOBILE WEB SERVICE

A) Associated agreement
B) Generates a UUID for the client
Agreement C) Saves a copy against the UUID
SLA Mobile Server template with validity
B) Must be used before expiry
Creation REST REQUEST C) Automated deletion
http://xperia.comnets.de:9090/FetchTemplate
(AC)
1 FETCH TEMPLATE AC FT

AGREEMENT TEMPLATE 2 SERVICE PROVIDER’S
Template
UUID + AGREEMENT TEMPLATE -- -- AGREEMENT TEMPLATE
Acquisition Stored in the mobile
Life Cycle ! host or the cloud
FETCH TEMPLATE
SYNCHRONOUS
MOBILE WEB SERVICE

Agreement Offer Life Cycle

CLIENTS
A) Verify the UUID of the client
B) Notify the requesting client
C) Transitions to the evaluation
MOBILE WEB SERVICE
HOST

Agreement phase (if verified)
SLA Mobile Server
Creation
(AC) A) Reads the agreement terms
B) Prepares an agreement offer
3 AGREEMENT OFFER + UUID AC
UUID
C) Sends the agreement offer as NOTIFICATION Verification
an asynchronous request
a) Agreement creation phase is completed
Agreement Offer ! b) Agreement evaluation phase is started
Life Cycle
Agreement AGREEMENT ACCEPT/REJECT 4 AE Offer
Evaluation
Evaluation A) Evaluate the agreement offer against -- --

the related template
(AE) AGREEMENT AGREEMENT
B) Accept or reject the agreement offer
TEMPLATE OFFER
NEGOTIATED C) Save a copy (if accepted) & notify PROTECTED
AGREEMENT the client MOBILE WEB SERVICE


Service Invocation Life Cycle

3
A) Verify and evaluate request
MOBILE WEB SERVICE MOBILE WEB SERVICE
against the negotiated agreement
CLIENTS HOST
B) Verify the usage limit & the usage
interval (default)
C) Invoke or schedule the service SLA Mobile Server
D) Initiate the QoS monitoring

5 SERVICE INVOCATION + UUID AE Verification

NOTIFICATION
For asynchronous services
Service Invocation Evaluation
Agreement QoS only!
QoS VIOLATIONS
Life Cycle QM
Evaluation Monitoring QoS

(AE) (QM) SERVICE RESPONSE 6
Handlers

-- --

A) Service provider specifies the QoS
handlers during deployment
B) Reads the service settings Third-party QoS
C) Starts the associated QoS handlers ! handlers are possible
D) QoS handlers monitors and reacts
upon QoS violations

Agreement Disposal Life Cycle

CLIENTS

Automatic disposal
MOBILE WEB SERVICE
HOST

Disposal ! is a default process
SLA Mobile Server

Monitoring
(DM) 3 AGREEMENT DISPOSAL + UUID DM Verification
Explicit disposal requests are possible only from the
! permitted clients through the client-controlled process. Settings

DISPOSAL RESPONSE 4 Disposal

Agreement A) Offers periodic cleanup cycles in automatic disposal
Disposal B) Looks for the expired agreements and templates
-- --
Life Cycle C) Takes the agreement validity (end date) and usage limit
as the expiration criteria
D) Disposes agreements, templates and client records (e.q. UUID) Agreements and Agreement
E) Shared process for all agreements and templates ! Templates to dispose


Performance Analysis
(Service Creation Process)
Synchronous Server Asynchronous Server
5
4
Completed
Completed

Create Service Invoke Service Web Service Parse Create Service Invoke Service
Web Service Parse
Request Object Method Request Request Object Method
Request SERVER RUNNING
SERVER PROCESSING READY RUNNING PROCESSING READY
1 2 3 1 2

Request
Timer
Dispatch Dispatch Invoke Service
Terminate 6 5 Terminate 7 6 Terminate Notify 4
Result Result Method

RESPONSE RESPONSE NOTIFY WAITING

Until the service Until the Service Instance
! object is created ! endpoint is created

Web Service Parse Create Service
Request Request Object
SERVER PROCESSING READY
1 2

d parse d obj

Ds Dc

Performance Analysis
(Service Creation Process)
Asynchronous SCP with SOAP Synchronous SCP with SOAP
<SOAP-ENV:Envelope <SOAP-ENV:Envelope
… xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/ xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/
<SOAP-ENV:Header>
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/>
<wsa:To> http://xperia.comnets.de </wsa:To>
<SOAP-ENV:Body SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/>
<wsa:Action> soaprpc</wsa:Action>
<wsa:MessageId>ffb471ec-194-1cb37664-125c53c2</wsa:MessageId>
<wsa:ReplyTo> <echoService xmlns="urn:Services" id="o0" SOAP-ENC:root="1">
<wsa:Address> http://schemas.xmlsoap.org/ws/.../role/anonymous </wsa:Address> <ServiceType xmlns="" xsi:type="xsd:string">Synchronous</ServiceType>
</wsa:ReplyTo>
<as:FactoryEPR>http://xperia.comnets.de/factory</as:FactoryEPR> <ContextData xmlns="" xsi:type="xsd:ContextData">
</SOAP-ENV:Header> 
<SOAP-ENV:Body SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/> </ContextData>

<GPSLocation> </echoService>
<ServiceType>Asynchronous</ServiceType>
<createInstanceRq xmlns="" xsi:type=":createInstanceRq">
</SOAP-ENV:Body>
<StartImmediately xsi:type="xsd:boolean">true</StartImmediately>
</SOAP-ENV:Envelope>
<ObserverEPR xsi:type="xsd:string">
http://tattoo.comnets.de/3466b6a-0df-5fe9ad
</ObserverEPR> ein est ek  syn
<Name xsi:type="xsd:string">GPS Location</Name>
<Subject xsi:type="xsd:string"> Create Service Instance </Subject>
<Description xsi:type="xsd:string">
Provides GPS coordinates of the host mobile
d
syn
 X   DS  ein  est  esyn   d obj
</Description> soap
 
 
syn
<ContextData xsi:type=“xsd:ContextData">  d p a rse

</ContextData>
<!– user-defined input XML elements -->    
syn
 Dc
 X   DS  ein  est  easyn   d obj
</createInstanceRq>
asyn
</GPSLocation>

</SOAP-ENV:Body>
d soap
 
 
a syn
</SOAP-ENV:Envelope>  d p a rse
   
ein est ek asyn 
a syn
Dc

Mobile Server Platform - Architectures and Protocols for Future M2M Ecosystems

Mobile Server Platform - Architectures and Protocols for Future M2M Ecosystems

Recomendados

Recomendados

Más contenido relacionado

Último

Último (20)

Destacado

Destacado (20)

Mobile Server Platform - Architectures and Protocols for Future M2M Ecosystems