Mobile Server Platform - Architectures and Protocols for Future M2M Ecosystems

© Fahad Aijaz, ComNets, RWTH Aachen University

Public Doctoral Presentation

Fahad Aijaz

ComNets Research Group RWTH Aachen University

July 12, 2011

Architectures and Protocols for Future M2M Ecosystems

2 © 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


Web Server

- Specialized functions - Internal process - Access interface

RESOURCES

WEB SERVICES

- Private Data - Multimedia - Websites

TRANSPARENT ACCESS

High-tech Web Servers. Hosts Web Service and Resources. Transparent Access to the Clients. Neutral towards diverse clients.

Today‘s Internet and the WWW

Mobile

Web Server

Mobile

Web Services

M2M Services

Web Service Broker/ Cloud

Computing

Publish/Search/ Outsource

Consume

M2M Terminal CONSUMER + PROVIDER

Publish/Search/ Outsource

M2M Terminal CONSUMER + PROVIDER

Internet of Things = M2M

?

?

Mobile

Web Server

Mobile

Web Services

Research Area in a Nutshell


Mobile

Web Server

Mobile

Web Services

Motivation and Research Gap

Automotive / Telemetric

Smart Energy Grids

Health Care Sector

Web 2.0 Services

Social Networking

Home Automation

Industrial Automation

Var

iab

le C

apab

iliti

es &

Req

uir

emen

ts

1

2

3

4

5

6

7

interaction

access interfaces

execution models

service protection

messaging protocols

service management

standard operations

data privacy

PROPERTIES

Only request-response based. Immediate service invocation, only. Short-lived executions. Respond on same network infrastructure (blocking call!). Runtime service management is not possible.

Mobile devices are not only mobile phones!

M2M Applications M2M Domain Requirements Mobile Server Platform

This research gap has been confirmed through literature!

Provides a general middleware architecture and protocol stack for rapid development of M2M applications

Transform into


The Mobile Server Platform (Conceptual Overview)

The

MSP

pro

vid

es a

set

of

stra

tegi

cally

co

nn

ecte

d a

rch

itec

ture

s

Off

ers

a W

eb S

ervi

ces

pro

visi

on

ing

solu

tio

n f

or

M2

M a

pp

s

The

pla

tfo

rms

arch

itec

ture

is c

ateg

ori

zed

into

logi

cal l

ayer

s

Software Application Layer

Fact

ory

Inst

ance

Ob

serv

er

Multi-Interfaced Mobile Web Services Asynchronous Mobile Web Services

AGREEMENT PROTECTED

SERVICES

ASYNCHRONOUS SERVICE ACCESS PROTOCOL

HTTP/TCP | RTP/UDP | IEEE 802.15.4

Service Interaction Strategies

WEB SERVICE AGREEMENTS

Asynchronous Server Endpoints

REST Access Interface

SLA Framework Layer

SOAP Access Interface

Mobile Web Server Layer

Notification

Solicit-Response

Request-Response

One-way

Synchronous Mobile Web Services

Server Endpoints Server Process Classification Multi-Interfaced Services Multimedia Delivery & Control

XML/REST, JSON/REST

Health Care | Social Networks

© Fahad Aijaz

Applications‘ private data


The Mobile Web Server Layer (Classification of Server Processes)

Ob

serv

er

Serv

ice

Cre

atio

n P

roce

ss

Serv

ice

Man

age

me

nt

Pro

cess

CreateInstance

Service Observer

Service Factory

Re

qu

est

wit

h

Ob

serv

er E

PR

Create with Observer EPR

1b

3b Service Instance

ASY

NC

HR

ON

OU

S M

OB

ILE WEB

SERV

ICE

Response with Instance EPR

Notification Listener

1a

2

3a

starts

mutually exclusive service invocations

Service Computation Result (normal completion)

Completed

4

solic

it-r

esp

on

se /

no

tifi

cati

on

1

Fact

ory

Inst

ance

2

Mandatory process to consume asynchronous Mobile Web services

Involved Server Endpoints


GetProperties

GetProperties

Unsubscribe

Subscribe

SetProperties

ChangeState

Service Observer

Request with Observer EPR

CO

NTR

OLLA

BLE

Service Instance

STATES OF AN ASYNCHRONOUS MOBILE WEB SERVICE

Response with Instance EPR

Notification Listener

1

4

2

mutually exclusive service states

Events and State Notifications (solicit-response / notification)

StateChanged

3 open.running

open.notrunning

open.notrunning.suspended

closed.completed

closed.abnormalCompleted

closed.abnormalCompleted.terminated

closed.abnormalCompleted.aborted

INT

ERN

AL

ASYNCHRONOUS MOBILE WEB SERVICE

Serv

ice

Man

age

me

nr

Pro

cess

Serv

ice

Cre

atio

n P

roce

ss

The Mobile Web Server Layer (Classification of Server Processes)

Only possible subsequent to the Service Creation Process


Performance Optimization

SOAP SERVER - Receive SOAP Envelope - Parse Req. SOAP - Parse Embedded XML - Parse WS-* - Process Request - Construct Resp. SOAP - Embed Resp. Custom XML - Conform to WS-* - Send SOAP Envelope - …

SOAP CLIENT - Construct Req. SOAP - Embed Custom XML - Conform to WS-* - Send SOAP Envelope - Receive Response - Parse Resp. SOAP - Parse Embedded XML - Parse WS-* - …

<SOAP-ENV … >

<SOAP-HEADER …>

<!–- WS-* Specifications

Custom XML … -->

</SOAP-HEADER…>

<SOAP-BODY …>


Custom XML

Complex Types … -->

</SOAP-BODY…>

</SOAP-ENV>

SOAP Envelope

<SOAP-HEADER … >


Custom XML … -->

</SOAP-HEADER>

<SOAP-BODY … >


Custom XML

Complex Types … -->

</SOAP-BODY>

SOA

P A

cce

ss In

terf

ace

SERVER - Receive HTTP Req. - Process Request URL - Send as HTTP Resp. - …

CLIENT - Construct Payload - Send as HTTP Req. - Receive Response - Parse HTTP Resp. - …

CUSTOMIZED-PAYLOAD

HTTP Request: GET, POST, PUT, DELETE ?

High Payload (WS-*) Processing Overhead Activity Oriented XML Based only!

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

Thick Clients

Think Clients

Service as a Resource (SaaR)

The Mobile Web Server Layer (SOAP Access Interface Overheads)


The Mobile Web Server Layer (SaaR Design Approach)

HTTP : // : / / / / / IP PORT SERVICE METHOD

mandatory optional

ASYNCHRONOUS URL ELEMENTS

ENDPOINT STRATEGY OPERATION

mandatory

HTTP : // : / / IP PORT SERVICE METHOD

mandatory optional

SYNCHRONOUS URL ELEMENTS

|POST |GET |PUT |DELETE

CREATE

READ

UPDATE

DELETE

REpresentational State Transfer

Static network resources Example: HTML, XML, JPG, GIF…

Network resources Example: HTML, XML, JPG, GIF…

Every resource changes the client’s

state

Resources are transferred

using HTTP

Access Interface

Synchronous Access URL

Asynchronous Access URL

Service Logic

Serv

ice

Pro

vid

er s

pec

ifie

s th

e m

app

ing

sem

anct

ics

for

each

met

ho

d


0 100 200 300 400 500 600 700 800

GetPropertiesRq

GetPropertiesRs

ListInstanceRq

ListInstanceRs

CreateInstanceRq

CreateInstanceRs

XML payload in bytes

Op

era

tio

ns

of t

he

Se

rvic

e F

acto

ry e

nd

po

int

SOAP Payload REST Payload

≈ 82 % reduction

≈ 67 % reduction

≈ 67 % reduction

≈ 83 % reduction

≈ 67 % reduction

≈ 95 % reduction

The Mobile Web Server Layer (Payload Optimization)

XML payload comparison of the operations offered by Service Factory Endpoint

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


5 10 15 20 25 30 35 40 45 50

10

20

30

40

50

60

70

80

90

100

110

120

No. of Requests

Serv

er P

roce

ssin

g L

aten

cies

[m

s]

MEAN LATENCY AND STANDARD DEVIATION OF THE ASYNCHRONOUS SOAP SERVER

Asynchronous SOAP Server

Mean

Standard Deviation

76.62 ms

10.71 ms

-10.71 ms

5 10 15 20 25 30 35 40 45 50

5

10

15

20

25

30

35

40

45

50

55

No. of Requests

Serv

er P

roce

ssin

g L

aten

cies

[m

s]

MEAN LATENCY AND STANDARD DEVIATION OF THE ASYNCHRONOUS REST SERVER

Asynchronous REST Server

Mean

Standard Deviation

15.8 ms

6.493 ms

-6.493 ms

Mean Latency of the Asynchronous Server with SOAP and XML/REST Interfaces

SOAP Access Interface REST Access Interface

The Mobile Web Server Layer (Prototypical Performance Evaluation)

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


The Mobile Web Server Layer (Basic Analysis of XML and JSON Payloads)

0

5

10

15

20

25

Da

ta i

n B

yte

s

JSON elements XML elements

7 bytes allocated by the XML root tag of 1 byte

2 bytes allocated by the start and end braces of JSON element

n

e

nameelementJSON BS1

_72

n

e

nameelementnamerootXML BBS1

__ 2525

<R>

<123> </123>

<123> </123>

<123> </123>

...

</R>

{

"123" : null

"123" : null

"123" : null

...

}

JSON Encoding

XML Encoding


Difference trend with 25 elements Difference trend with 210 elements

2 4 8 16 32 64 128 256 512 1024

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

5.5

6

6.5

7

7.5

8

8.5

9

9.5

10

10.5

11

No. of Elements

Dif

fere

nce

in P

aylo

ad (

MB

)

3 bytes

8 bytes

13 bytes

18 bytes

23 bytes


JSONXML SS

2 4 8 16 32

0.025

0.05

0.075

0.1

0.125

0.15

0.175

0.2

0.225

0.25

0.275

0.3

0.325

0.35

No. of Elements

Dif

fere

nce

in P

aylo

ad (

MB

)

3 bytes

8 bytes

13 bytes

18 bytes

23 bytes

> 0.325 MB

≈ 10.5 MB

≈ 0.5 MB

< 0.025 MB

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


Fact

ory

Inst

ance

Ob

serv

er

Multi-Interfaced Mobile Web Services


Off

ers

a W

eb S

ervi

ce p

rovi

sio

nin

g so

luti

on

th

rou

gh M

2M

ter

min

als


The RTSP OPTIONS and DESCRIBE methods are exposed as synchronous mobile Web Services

The RTSP SETUP, PLAY, PAUSE and TEARDOWN are exposed as states of asynchronous services

Multimedia Delivery Strategy RTP/UDP

Integration of RTSP and RTP Extended RTSP States in Asynchronous Server

Multimedia Control Strategy RTSP/TCP

Delivery Resource Asynchronous Services Control Resource Synchronous and Asynchronous Services

The Mobile Web Server Layer (Multimedia Extensions and Topologies)


Relayed Delivery and Relayed Control

Mo

bile W

eb

Server Layer M

ob

ile W

eb

Serv

er

Laye

r

RTP/UDP

RTSP/TCP

INTERNET

CONTROL CHANNEL

NAT/ FIREWALL

HOLE PUNCHING

PRIVATE IP/PORT PRIVATE IP/PORT

NAT/ FIREWALL

HOLE PUNCHING

RTP/UDP

RTSP/REST

TCP TUNNEL

Relays Control Relays Multimedia

INTERMEDIATE ACCESS GATEWAY

KNOWN PUBLIC IP/PORT

DELIVERY CHANNEL

Sequence of events during the interaction

Client Server

Mu

ltim

edia

Del

iver

y St

rate

gy

RTP

/UD

P

Mu

ltim

edia

Co

ntr

ol S

trat

egy

RTS

P/TC

P

Syn

chro

no

us

and

Asy

nch

ron

ou

s Se

rver

s w

ork

to

geth

er

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

TCP TCP

UDP UDP

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

Works with every network where TCP/UDP are enabled!



Service Level Agreements Framework

The SLA Framework Layer (Conceptual Overview)

Agreement Creation

(AC)

Agreement Evaluation

(AE)

Agreement Offer Life Cycle

Template Acquisition Life Cycle

Service Invocation Life Cycle

QoS Monitoring

(QM)

Disposal Monitoring

(DM)

Agreement Disposal Life Cycle

The functions of the SLA architecture are classified into 4 distinct life cycles

The SLA life cycles are executed based on the incoming mobile Web Service requests

The SLA negotiation is based on the Web Service Agreement standard of the Open Grid Forum

The standard is optimized to define the SLA messaging for mobile nodes

The SLA framework is compatible with the REST and SOAP access interfaces

Protects both, the synchronous and asynchronous services

4 LIFE CYCLES OF THE SLA FRAMEWORK

Extends the Mobile Web Server Layer

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


The SLA Framework Layer (Life Cycles)

A) Reads and manipulates the templateB) Generates a UUID for the clientC) Saves a copy against the UUID

A) Associated agreement template with validity

B) Must be used before expiryC) Automated deletion

Mobile Server

--

FETCH TEMPLATESYNCHRONOUS

MOBILE WEB SERVICE

MOBILE WEB SERVICECLIENTS

FETCH TEMPLATE1

AGREEMENT TEMPLATE 2UUID + AGREEMENT TEMPLATE

REST REQUESThttp://xperia.comnets.de:9090/FetchTemplate

Stored in the mobile host or the cloud!

SLA

AC

--

MOBILE WEB SERVICEHOST

SERVICE PROVIDER’SAGREEMENT TEMPLATE

FT

PROTECTEDMOBILE WEB SERVICE

Template Aquisition Life Cycle


Agreement Creation

(AC)


(AE)


Agreement Creation

(AC)


1

2

A) Reads the agreement termsB) Prepares an agreement offerC) Sends the agreement offer as

an asynchronous request

A) Verify the UUID of the clientB) Notify the requesting clientC) Transitions to the evaluation

phase (if verified)


AGREEMENT OFFER + UUID3

AGREEMENT ACCEPT/REJECT 4A) Evaluate the agreement offer against

the related templateB) Accept or reject the agreement offerC) Save a copy (if accepted) & notify

the client

AGREEMENTOFFER

Mobile Server

--

SLA

--

OfferEvaluation

UUIDVerification

AC

AE


a) Agreement creation phase is completedb) Agreement evaluation phase is started!

AGREEMENTTEMPLATE

NOTIFICATION


NEGOTIATEDAGREEMENT


The SLA Framework Layer (Life Cycles)

A) Reads and manipulates the templateB) Generates a UUID for the clientC) Saves a copy against the UUID

A) Associated agreement template with validity

B) Must be used before expiryC) Automated deletion

Mobile Server

--

FETCH TEMPLATESYNCHRONOUS

MOBILE WEB SERVICE


FETCH TEMPLATE1

AGREEMENT TEMPLATE 2UUID + AGREEMENT TEMPLATE

REST REQUESThttp://xperia.comnets.de:9090/FetchTemplate

Stored in the mobile host or the cloud!

SLA

AC

--


SERVICE PROVIDER’SAGREEMENT TEMPLATE

FT


Template Aquisition Life Cycle


Agreement Creation

(AC)


(AE)


Agreement Creation

(AC)


1

2

A) Reads the agreement termsB) Prepares an agreement offerC) Sends the agreement offer as

an asynchronous request

A) Verify the UUID of the clientB) Notify the requesting clientC) Transitions to the evaluation

phase (if verified)


AGREEMENT OFFER + UUID3

AGREEMENT ACCEPT/REJECT 4A) Evaluate the agreement offer against

the related templateB) Accept or reject the agreement offerC) Save a copy (if accepted) & notify

the client

AGREEMENTOFFER

Mobile Server

--

SLA

--

OfferEvaluation

UUIDVerification

AC

AE


a) Agreement creation phase is completedb) Agreement evaluation phase is started!

AGREEMENTTEMPLATE

NOTIFICATION


NEGOTIATEDAGREEMENT



A) Service provider specifies the QoS handlers during deployment

B) Reads the service settingsC) Starts the associated QoS handlersD) QoS handlers monitors and reacts

upon QoS violations

SERVICE INVOCATION + UUID5

SERVICE RESPONSE 6

A) Verify and evaluate request against the negotiated agreement

B) Verify the usage limit & the usage interval (default)

C) Invoke or schedule the serviceD) Initiate the QoS monitoring

NOTIFICATIONFor asynchronous services

only!QoS VIOLATIONS


Mobile Server

--

SLA

--

Evaluation

VerificationAE


QoSHandlers

QM

Third-party QoS handlers are possible!




(AE)


QoS Monitoring

(QM)

Disposal Monitoring

(DM)


3

4

AGREEMENT DISPOSAL + UUID3

DISPOSAL RESPONSE 4A) Offers periodic cleanup cycles in automatic disposalB) Looks for the expired agreements and templatesC) Takes the agreement validity (end date) and usage limit

as the expiration criteriaD) Disposes agreements, templates and client records (e.q. UUID)E) Shared process for all agreements and templates


Mobile Server

--

SLA

--

Verification


Disposal

Explicit disposal requests are possible only from the permitted clients through the client-controlled process.!

DM

Agreements and Agreement Templates to dispose!

Automatic disposal is a default process!

Settings


Synchronous Server Asynchronous Server

Performance Analysis (Service Creation Process)

SERVER

1

Web ServiceRequest

RESPONSE

2 3

4

56

PROCESSING READY RUNNING

ParseRequest

Create ServiceObject

Invoke ServiceMethod

Completed

DispatchResult

Terminate

SERVER

1

Web ServiceRequest

RESPONSE

2

5

67

PROCESSING READY RUNNING

ParseRequest



Completed

DispatchResult

Terminate

NOTIFY

4NotifyTerminate

WAITING


RequestTimer

SERVER

1

Web ServiceRequest

2PROCESSING READY

ParseRequest


parsed

objd

cD

sD

Until the service object is created !

Until the Service Instance endpoint is created !

Asynchronous SCP with SOAP Synchronous SCP with SOAP


<SOAP-ENV:Envelope…xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> <SOAP-ENV:Header>

<wsa:To> http://xperia.comnets.de </wsa:To><wsa:Action> soaprpc</wsa:Action><wsa:MessageId>ffb471ec-194-1cb37664-125c53c2</wsa:MessageId><wsa:ReplyTo>

<wsa:Address> http://schemas.xmlsoap.org/ws/.../role/anonymous </wsa:Address></wsa:ReplyTo><as:FactoryEPR>http://xperia.comnets.de/factory</as:FactoryEPR>

</SOAP-ENV:Header><SOAP-ENV:Body SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/>

<GPSLocation> <ServiceType>Asynchronous</ServiceType><createInstanceRq xmlns="" xsi:type=":createInstanceRq">

<StartImmediately xsi:type="xsd:boolean">true</StartImmediately><ObserverEPR xsi:type="xsd:string">

http://tattoo.comnets.de/3466b6a-0df-5fe9ad</ObserverEPR><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</Description>

<ContextData xsi:type=“xsd:ContextData"><!– user-defined input XML elements -->

</ContextData>

</createInstanceRq></GPSLocation>

</SOAP-ENV:Body></SOAP-ENV:Envelope>

ste

ine

asynke

<SOAP-ENV:Envelopexmlns:xsi=http://www.w3.org/2001/XMLSchema-instancexmlns:xsd=http://www.w3.org/2001/XMLSchemaxmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/> <SOAP-ENV:Body SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/>

<echoService xmlns="urn:Services" id="o0" SOAP-ENC:root="1"><ServiceType xmlns="" xsi:type="xsd:string">Synchronous</ServiceType>

<ContextData xmlns="" xsi:type="xsd:ContextData">

</ContextData>

</echoService>

</SOAP-ENV:Body></SOAP-ENV:Envelope>

ste

ine

synke

D

d

eeeX

syn

c

syn

parse

dDd objsynstinS

syn

soap

D

d

eeeX

asyn

c

asyn

parse

dDd objasynstinS

asyn

soap

Asynchronous SCP with XML/REST Synchronous SCP with XML/REST


<createInstanceRq xmlns="" xsi:type=":createInstanceRq"><StartImmediately xsi:type="xsd:boolean">true</StartImmediately><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</Description>

<ContextData xsi:type=“xsd:ContextData"><!– user-defined input XML elements -->

</ContextData>

</createInstanceRq>

ine

asynke

HTTP : // : / / / / / IP PORT SERVICE METHOD ENDPOINTSTRATEGY OPERATION

Factory

GPSLocation Req-Res CreateInstance

CoordinatesAsynchronousAccess URL

echoStringSynchronousAccess URL



ine

HTTP : // : / / IP PORT SERVICE METHOD

(optional)

D

X

syn

c

dDd objS

syn

rest

D

d

eeX

asyn

c

asyn

parse

dDd objasyninS

asyn

rest

XX DDsyn

soap

syn

rest XX DD

asyn

soap

asyn

rest

N

X

Xi

N

i

k

mk

m

dD

)(1

Hypothesis Mean



10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 260 270 280 290 300 310 320 330 340 350 360 370 380

0.0125

0.025

0.0375

0.05

0.0625

0.075

0.0875

0.1

0.1125

0.125

0.1375

0.15

0.1625

0.175

0.1875

0.2

0.2125

0.225

0.2375

0.25

0.2625

0.275

0.2875

0.3

0.3125

Arrival Rate ()

Mea

n W

aiti

ng

Tim

e (s

)

D rest syn (X)

D rest asyn (X)

= 50 = 205 = 380 = 35

D soap syn (X)

k = asyn

D soap asyn (X)

k = syn

M/D/1 evaluation with increasing arrival rate

≈ 7.6 times increase in serving capacity with XML/REST

Mean waiting time with XML/REST at this arrival rate is about 2% of the one with SOAP

XX DDsyn

soap

syn

rest



10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 260 270 280 290 300 310 320 330 340 350 360 370 380

0.0125

0.025

0.0375

0.05

0.0625

0.075

0.0875

0.1

0.1125

0.125

0.1375

0.15

0.1625

0.175

0.1875

0.2

0.2125

0.225

0.2375

0.25

0.2625

0.275

0.2875

0.3

0.3125

Arrival Rate ()

Mea

n W

aiti

ng

Tim

e (s

)

D rest syn (X)

D rest asyn (X)

= 50 = 205 = 380 = 35

D soap syn (X)

k = asyn

D soap asyn (X)

k = syn

M/D/1 evaluation with increasing arrival rate

Mean waiting time with XML/REST at this arrival rate is about 2% of the one with SOAP

≈ 6 times increase in servicing capacity with XML/REST

XX DDasyn

soap

asyn

rest


The Software Application Layer (MEDICARE – A Context-Aware Health Care Application)

Light

VentilatorMonitor

Diagnostic

Body TemperatureBlood Pressure

Heart Condition

Pulse SignalsMovement

.....

Equipment

Device ConfigurationMode Selection

Performance MonitorValves ConditionOxygen Monitor

.....

Environment

Light ConditionRoom TemperatureNoise Detection

PresenceDoor Status

.....

SPOT nodes with the MSP

(collector nodes)

SPOT Base Station

Doctor’sComputer

Heater

Door

Patient

Mobile Web Service Categories

Mobile Web Service Categories


The Software Application Layer (Social Network in Pocket [SNiP] – A privacy-focused social network concept)

Service Access Website SNiP-Consumers

… and more

Disallowed SNiP-Consumers

She has taken pictures, recorded videos and posted comments about many wonderful places during her Italian tours

ALICE, a SNiP user is on vacation in Italy

She has many SNiP services on her mobile phone, such as, location, gallery, chat, games, video, voice ...

To socialize and share her experience, Alice allows her selected friends from her phones address book to access her SNiP services

Her authorized friends directly access her private data stored on her phone through the Service Access website to interact and view the mobile content that Alice has provided for shared use

She feels satisfied, as SNiP allows her to share her private mobile content without posting it to any third-party server – PRIVACY!

Alice has complete control right on her phone to choose who can access her private data stored on the phone

Alice feels like her entire Social Network is in her pocket

1

2

3

4

5

6

7

8

SNiP-Provider (MSP)


Conclusion

Contributions of the Research

Introduces a novel software architecture and protocol stack, called the Mobile Server Platform

Fills the gap between M2M domain requirements and respective M2M application development

Offers multiple exceution models, protocols and strategies for terminals to address vast set of requirements

Provides a comprehensive solution for remote service creation and management on mobile terminals

Multiple access interfaces are developed and compared in terms of processing performance

JSON/REST interface is the most suitable for M2M terminals, as the payload size increases

XML/REST increases 7.6 times the serving capacity by of Synchronous Server, compared to SOAP

XML/REST increases 6 times the serving capacity of Asynchronous Server, compared to SOAP

In general, REST interface outperforms SOAP in all aspects due to reduced payload requirements

The established hypotheses are verified by M/D/1 evaluations with increasing arrival rates

Multiple execution models on Mobile Web Server layer leads to new architectural extensions

Multimedia extension on the Mobile Web Server layer with RTSP/TCP and RTP/UDP channels

Maps RTSP methods to service excecution models by extending the asynchronous service states

Uses asynchronous services as a multimedia delivery resource

Introduces three multimedia delivery and control topologies to bypass network constraints

SLA negotiation life cycles are introduced to protect services on provisioning terminals

Demonstrated suitability of the MSP for M2M terminals and consumer devices

The idea of Social Network in Pocket (SNiP) is development on a smart phone, with focus on privacy

The MEDICARE prototypes is developed on SunSPOT M2M terminals to demonstrate automation use case


End of Talk

Questions?

Thank you for your attention!

The Mobile Server Platform


Fact

ory

Inst

ance

Ob

serv

er

Multi-Interfaced Mobile Web ServicesAsynchronousMobile Web Services

AGREEMENTPROTECTED

SERVICES

ASYNCHRONOUS SERVICE ACCESS PROTOCOL

HTTP/TCP | RTP/UDP | IEEE 802.15.4

Service Interaction Strategies

WEB SERVICE AGREEMENTS

Asynchronous Server Endpoints

REST AccessInterface

SLA Framework Layer

SOAP AccessInterface


Notification

Solicit-Response

Request-Response

One-way

SynchronousMobile Web Services

Server Endpoints Server Process Classification Multi-Interfaced Services Enables Multimedia Delivery

XML/REST, JSON/REST

Health Care | Social Networks

Fahad Aijaz [email protected]

www.fahadaijaz.com


Outlook

What could be done next?

More performance optimization through other protocol encodings, for example Efficient XML Interchange

More alignment with M2M standards, for example Constrained RESTful Environments (CoRE)

Constrained Application Protocol (CoAP)

Investigation in the direction of mobile payment and charging Possibly, by involving IP Multimedia Subsystem (IMS)

Development of methods and pre-commercial demonstrators for specific use cases, for example In energy, automation and automotive sectors

Mature the privacy solution to address current ownership issues in the Web


less data transmission with JSON


2 4 8 16 32

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45

0.5

0.55

0.6

0.65

0.7

0.75

0.8

0.85

0.9

No. of XML elements

To

tal p

aylo

ad (

MB

)

23 bytes

18 bytes

13 bytes

8 bytes

3 bytes

2 4 8 16 32

0.025

0.05

0.075

0.1

0.125

0.15

0.175

0.2

0.225

0.25

0.275

0.3

0.325

0.35

0.375

0.4

0.425

0.45

0.475

0.5

No. of JSON elements

To

tal p

aylo

ad (

MB

)

3 bytes

8 bytes

13 bytes

18 bytes

23 bytes

Payload increase until 25 JSON elements Payload increase until 25 XML elements

n

e


__ 2525

n

e

nameelementJSON BS1

_72

≈ 0.8 MB

< 0.475 MB

> 41% less data transmission with JSON

≈7%



2 4 8 16 32 64 128 256 512 1024

123456789

101112131415161718192021222324252627282930

No. of XML elements

To

tal p

aylo

ad (

MB

)

3 bytes

8 bytes

13 bytes

18 bytes

23 bytes

2 4 8 16 32 64 128 256 512 1024

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

No. of JSON elements

To

tal p

aylo

ad (

MB

)

3 bytes

8 bytes

13 bytes

18 bytes

23 bytes

Payload increase until 210 JSON elements Payload increase until 210 XML elements

n

e


__ 2525

n

e

nameelementJSON BS1

_72

less data transmission with JSON

≈ 15 MB

> 41% less data transmission with JSON

≈9%

≈ 25.5 MB


ASYNCHRONOUS DELIVERY SERVICE

The mulitmedia delivery channel established!

Mo

bile W

eb

Server Layer M

ob

ile W

eb

Serv

er

Laye

r

Mu

ltim

edia

Del

iver

y St

rate

gy

RTP

/UD

P

Mu

ltim

edia

Co

ntr

ol S

trat

egy

RTS

P/TC

P

Syn

chro

no

us

and

Asy

nch

ron

ou

s Se

rver

s w

ork

to

geth

er

RTP/UDP

RTSP/TCP

INTERNET

RTP/UDP RTP/UDP

RTSP/TCP RTSP/TCP

NAT/FIREWALL

DELIVERY CHANNEL

CONTROL CHANNEL

HOLE PUNCHING KNOWN PUBLIC IP/PORT PRIVATE IP/PORT

Direct Delivery and Direct Control


Client Server

TCP

keep-alive

1 RTSP OPTION/DESCRIBE TCP hole punching Synchronous service execution

2 RTSP SETUP TCP hole punching Service Creation Process Init Ready

3 UDP Datagram UDP hole punching Delivered to sends Keep-alive

4 RTSP PLAY TCP hole punching Service Management Ready Playing

6 RTSP PAUSE TCP hole punching Service Management Playing Ready / Keep-alive

5 starts the RTP/UDP multimedia delivery Bypasses the UDP hole Received!

7 RTSP TEARDOWN TCP hole punching Service Management Playing/Ready Init

Requires a public IP for the serving terminal!

UDP



Mu

ltim

edia

Del

iver

y St

rate

gy

RTP

/UD

P

Mu

ltim

edia

Co

ntr

ol S

trat

egy

RTS

P/TC

P

Syn

chro

no

us

and

Asy

nch

ron

ou

s Se

rver

s w

ork

to

geth

er Direct Delivery and Relayed Control

Mo

bile W

eb

Server Layer M

ob

ile W

eb

Serv

er

Laye

r

RTP/UDP

RTSP/TCP

INTERNET

RTP/UDP RTP/UDP

DELIVERY CHANNEL

CONTROL CHANNEL

NAT/ FIREWALL

HOLE PUNCHING

PRIVATE IP/PORT PRIVATE IP/PORT

NAT/ FIREWALL

HOLE PUNCHING

RTP/UDP

RTSP/REST

TCP TUNNEL

Relays Control Introduces Terminals

INTERMEDIATE ACCESS GATEWAY

KNOWN PUBLIC IP/PORT

keep-alive TCP

Client Server


TCP

1 Server establishes a permanent TCP tunnel with the IAG TCP hole punching

UDP UDP

6 Client may send RTSP PAUSE, TEARDOWN via IAG Service Management Process

2 The client sends RTSP SETUP to the IAG IAG relays it to server SCP response

4 Client sends RTSP PLAY to IAG IAG relays it to server Service Management Process

3 Client/server sends UDP packets to IAG IAG introduces client/server UDP keep-alives

5 Server directly delivers media over the RTP/UDP channel through asynchronous service

Requires Full-Cone NAT at the client!



5 10 15 20 25 30 35 40 45 50

10

20

30

40

50

60

70

80

90

No. of Requests

Pro

cess

ing

Lat

ency

[m

s]

PROCESSING LATENCIES CAUSED BY THE ASYNCHRONOUS REST SERVER COMPONENTS

Asynchronous Manager (AM) [Mean = 0.44 ms]

Response Processor (ResP) [Mean = 4.34 ms]

REST Manager (RM) [Mean = 5.84 ms]

Request Processor (ReqP) [Mean = 5.9 ms]

Asynchronous REST Server [Mean = 15.8 ms]

5 10 15 20 25 30 35 40 45 50

20

40

60

80

100

120

140

160

180

200

220

240

No. of Requests

Pro

cess

ing

Lat

ency

[m

s]

PROCESSING LATENCIES CAUSED BY THE ASYNCHRONOUS SOAP SERVER COMPONENTS

Asynchronous Manager (AM) [Mean = 0.3 ms]

Request Processor (ReqP) [Mean = 21.24 ms]

Response Processor (ResP) [Mean = 51.06 ms]

Asynchornous SOAP Server [Mean = 76.62 ms]

REASON? The SOAP parsing overheads are avoided by

reducing the payload demands!

Mean Latencies of the Asynchronous Server Components with SOAP and XML/REST Interface

SOAP Access Interface REST Access Interface

INTERESTING OBSERVATION The individual server components with SOAP interface resulted in much higher mean latencies

than the overall mean latency of the asynchronous server with REST interface!

The Mobile Web Server Layer (Prototypical Performance Evaluation)


Watch the live demonstration video at: http://aims.fahadaijaz.com

4 TH Rank Worldwide

in Ericsson Application Awards 2010

Overall Impression | Sustainability | Social | Fun | Usability and Need

» The competition was opened on March 2010

» 120 teams participated from 28 countries » The short-listed projects were tested by 1000 users each

» The users were located in USA, China, UK and Australia

» The evaluations were based on the following aspects:

SNiP (alpha) secured 4th rank after the overall assessment Stood 2nd in the Best Mobile Innovation Pakistan 2010

Mobile Host Application Service Access Website

The Software Application Layer (Recognition of the SNiP concept)

http://aims.fahadaijaz.com/


CO

NTR

OL

PAN

EL

MA

NA

GEM

ENT

The Software Application Layer (MEDICARE Screen Shots)

ERICSSON PRIZE 2009!

At the annual ComNets FFV Workshop 2009

[L to R] Dr. Norbert Niebert (Ericsson Euro Labs), [L to R] Muzzamil Aziz and Fahad Aijaz (ComNets) Muzzamil Aziz and Prof. Dr. B. Walke (ComNets)

Mobile Server Platform - Architectures and Protocols for Future M2M Ecosystems

Education

Transcript of Mobile Server Platform - Architectures and Protocols for Future M2M Ecosystems