© 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
3 © Fahad Aijaz, ComNets, RWTH Aachen University
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
4 © Fahad Aijaz, ComNets, RWTH Aachen University
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
5 © Fahad Aijaz, ComNets, RWTH Aachen University
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
6 © Fahad Aijaz, ComNets, RWTH Aachen University
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
7 © Fahad Aijaz, ComNets, RWTH Aachen University
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
8 © Fahad Aijaz, ComNets, RWTH Aachen University
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 …>
<!–- WS-* Specifications
Custom XML
Complex Types … -->
</SOAP-BODY…>
</SOAP-ENV>
SOAP Envelope
<SOAP-HEADER … >
<!–- WS-* Specifications
Custom XML … -->
</SOAP-HEADER>
<SOAP-BODY … >
<!–- WS-* Specifications
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)
9 © Fahad Aijaz, ComNets, RWTH Aachen University
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
10 © Fahad Aijaz, ComNets, RWTH Aachen University
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
11 © Fahad Aijaz, ComNets, RWTH Aachen University
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
12 © Fahad Aijaz, ComNets, RWTH Aachen University
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
13 © Fahad Aijaz, ComNets, RWTH Aachen University
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
The Mobile Web Server Layer (Basic Analysis of XML and JSON Payloads)
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
14 © Fahad Aijaz, ComNets, RWTH Aachen University
Fact
ory
Inst
ance
Ob
serv
er
Multi-Interfaced Mobile Web Services
Mobile Web Server Layer
Off
ers
a W
eb S
ervi
ce p
rovi
sio
nin
g so
luti
on
th
rou
gh M
2M
ter
min
als
Software Application Layer
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)
15 © Fahad Aijaz, ComNets, RWTH Aachen University
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!
The Mobile Web Server Layer (Multimedia Extensions and Topologies)
16 © Fahad Aijaz, ComNets, RWTH Aachen University
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
17 © Fahad Aijaz, ComNets, RWTH Aachen University
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 Offer Life Cycle
Agreement Creation
(AC)
Agreement Evaluation
(AE)
Agreement Offer Life Cycle
Agreement Creation
(AC)
Template Acquisition Life Cycle
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)
MOBILE WEB SERVICECLIENTS
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
MOBILE WEB SERVICEHOST
a) Agreement creation phase is completedb) Agreement evaluation phase is started!
AGREEMENTTEMPLATE
NOTIFICATION
PROTECTEDMOBILE WEB SERVICE
NEGOTIATEDAGREEMENT
18 © Fahad Aijaz, ComNets, RWTH Aachen University
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 Offer Life Cycle
Agreement Creation
(AC)
Agreement Evaluation
(AE)
Agreement Offer Life Cycle
Agreement Creation
(AC)
Template Acquisition Life Cycle
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)
MOBILE WEB SERVICECLIENTS
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
MOBILE WEB SERVICEHOST
a) Agreement creation phase is completedb) Agreement evaluation phase is started!
AGREEMENTTEMPLATE
NOTIFICATION
PROTECTEDMOBILE WEB SERVICE
NEGOTIATEDAGREEMENT
19 © Fahad Aijaz, ComNets, RWTH Aachen University
The SLA Framework Layer (Conceptual Overview)
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 WEB SERVICECLIENTS
Mobile Server
--
SLA
--
Evaluation
VerificationAE
MOBILE WEB SERVICEHOST
QoSHandlers
QM
Third-party QoS handlers are possible!
Service Invocation Life Cycle
Agreement Disposal Life Cycle
Agreement Evaluation
(AE)
Service Invocation Life Cycle
QoS Monitoring
(QM)
Disposal Monitoring
(DM)
Agreement Disposal Life Cycle
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 WEB SERVICECLIENTS
Mobile Server
--
SLA
--
Verification
MOBILE WEB SERVICEHOST
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
20 © Fahad Aijaz, ComNets, RWTH Aachen University
The SLA Framework Layer (Conceptual Overview)
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 WEB SERVICECLIENTS
Mobile Server
--
SLA
--
Evaluation
VerificationAE
MOBILE WEB SERVICEHOST
QoSHandlers
QM
Third-party QoS handlers are possible!
Service Invocation Life Cycle
Agreement Disposal Life Cycle
Agreement Evaluation
(AE)
Service Invocation Life Cycle
QoS Monitoring
(QM)
Disposal Monitoring
(DM)
Agreement Disposal Life Cycle
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 WEB SERVICECLIENTS
Mobile Server
--
SLA
--
Verification
MOBILE WEB SERVICEHOST
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
21 © Fahad Aijaz, ComNets, RWTH Aachen University
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
Create ServiceObject
Invoke ServiceMethod
Completed
DispatchResult
Terminate
NOTIFY
4NotifyTerminate
WAITING
Invoke ServiceMethod
RequestTimer
SERVER
1
Web ServiceRequest
2PROCESSING READY
ParseRequest
Create ServiceObject
parsed
objd
cD
sD
Until the service object is created !
Until the Service Instance endpoint is created !
22 © Fahad Aijaz, ComNets, RWTH Aachen University
Asynchronous SCP with SOAP Synchronous SCP with SOAP
Performance Analysis (Service Creation Process)
<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"><!-- user-defined input XML elements -->
</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
23 © Fahad Aijaz, ComNets, RWTH Aachen University
Asynchronous SCP with XML/REST Synchronous SCP with XML/REST
Performance Analysis (Service Creation Process)
<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
<!-- user-defined input data -->
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
24 © Fahad Aijaz, ComNets, RWTH Aachen University
Performance Analysis (Service Creation Process)
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
25 © Fahad Aijaz, ComNets, RWTH Aachen University
Performance Analysis (Service Creation Process)
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
26 © Fahad Aijaz, ComNets, RWTH Aachen University
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
27 © Fahad Aijaz, ComNets, RWTH Aachen University
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)
28 © Fahad Aijaz, ComNets, RWTH Aachen University
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
29 © Fahad Aijaz, ComNets, RWTH Aachen University
End of Talk
Questions?
Thank you for your attention!
The Mobile Server Platform
Software Application Layer
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
Mobile Web Server Layer
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
30 © Fahad Aijaz, ComNets, RWTH Aachen University
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
31 © Fahad Aijaz, ComNets, RWTH Aachen University
less data transmission with JSON
The Mobile Web Server Layer (Basic Analysis of XML and JSON Payloads)
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
nameelementnamerootXML BBS1
__ 2525
n
e
nameelementJSON BS1
_72
≈ 0.8 MB
< 0.475 MB
> 41% less data transmission with JSON
≈7%
32 © Fahad Aijaz, ComNets, RWTH Aachen University
The Mobile Web Server Layer (Basic Analysis of XML and JSON Payloads)
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
nameelementnamerootXML BBS1
__ 2525
n
e
nameelementJSON BS1
_72
less data transmission with JSON
≈ 15 MB
> 41% less data transmission with JSON
≈9%
≈ 25.5 MB
33 © Fahad Aijaz, ComNets, RWTH Aachen University
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
Sequence of events during the interaction
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
The Mobile Web Server Layer (Multimedia Extensions and Topologies)
34 © Fahad Aijaz, ComNets, RWTH Aachen University
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
Sequence of events during the interaction
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!
The Mobile Web Server Layer (Multimedia Extensions and Topologies)
35 © Fahad Aijaz, ComNets, RWTH Aachen University
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)
36 © Fahad Aijaz, ComNets, RWTH Aachen University
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)
37 © Fahad Aijaz, ComNets, RWTH Aachen University
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)