Meego Italian Day 2011 – Prof. Paolo Bellavista - Mobile & Context-aware Computing: Panoramica, Scenari Applicativi e Sfide Tecnologiche L’intervento cercherà di fare intuire, con esempi pratici e concreti, perchè le infrastrutture di supporto a servizi mobili e le applicazioni mobili stesse non possono più prescindere da forme avanzate di gestione del contesto a livello middleware. La gestione del contesto sta emergendo come cruciale non solo per la personalizzazione adattiva dei servizi mobili ma anche per vincere le sfide tecnologiche correlate alla necessità di scalabilità in scenari di deployment di ampie dimensioni. Saranno mostrate rapidamente esemplificazioni in ambito monitoraggio urbano tramite reti veicolari di sensori e condivisione opportunistica di risorse sotto-utilizzate. Prof. Paolo Bellavista è professore associato di sistemi distribuiti e mobili presso la Facoltà di Ingegneria dell’Università di Bologna. I suoi principali ambiti di ricerca sono il supporto middleware a sistemi e servizi mobili, i servizi context-aware, lo streaming multimediale verso smart phone su reti wired-wireless eterogenee, le reti wireless di sensori anche veicolari, l’integrazione dinamica di sistemi mobili con infrastrutture, anche cloud. E’ inoltre membro dell’Editorial Board di IEEE Communications, IEEE Transactions on Computers, IEEE Transactions on Network and Service Management., IEEE Transactions on Services Computing, Elsevier Pervasive and Mobile Computing Journal, and Springer Journal of Network and Systems Management. http://www.meegoit.com/2011

1. Mobile & Context-aware
Computing: Panoramica,
Scenari Applicativi e Sfide Tecnologiche
18 Marzo 2011 – I Facoltà di Ingegneria
Università degli Studi di Bologna
MeeGo Italian Day
Paolo Bellavista
paolo.bellavista@deis.unibo.it
http://lia.deis.unibo.it/Staff/PaoloBellavista/

2. Agenda
Definizione di mobile computing, context
awareness e middleware
Perché mobile computing non è per nulla commodity
ma grandissima opportunità aperta di ricerca
e business
Esempio di middleware per distribuzione
contesto in ambienti a larga scala
Esempio di middleware per condivisione
opportunistica di risorse
Idea provocatoria: “future pervasive systems
as social sharing spaces”?
MeeGo – Bologna - 18.03.2011 2/23

3. Mobile Computing (1)
Mobile computing richiede approccio a livelli multipli e
con competenze multiple:
Dispositivi embedded (problematiche miniaturizzazione,
consumo ridotto di energia, …)
Comunicazioni wireless (IEEE 802.11a/b/g/s, Bluetooth,
WiMAX, comunicazioni veicolari, …)
Piattaforme di supporto software (Android, iPhoneSDK,
SymbianOS, …)
Gestione energia a livello piattaforma software
Gestione interfacce wireless multiple e handover a
livello piattaforma software
Gestione contesto
…
MeeGo – Bologna - 18.03.2011 3/23

4. Mobile Computing (2)
…
Gestione cross-layer requisiti applicativi e allocazione
risorse
Supporto a servizi infrastructure-based
Supporto a servizi peer-to-peer
Supporto a servizi mobili opportunistici
Supporto a servizi mobili social-aware
E design, implementazione, deployment e
management runtime di tutte queste categorie di
servizi!
MeeGo – Bologna - 18.03.2011 4/23

5. Contesto
Gartner, November 2009, “Context-aware Computing will be
a $12 Billion Market by 2012”
Contesto (time, location,
time and personal
interessi personali, caratteristiche location interests
device/risorse/servizi, gruppi,
device
affinità sociali, storia sessioni characteristics
user context
precedenti, previsioni su
sessioni future, …) service administrative domains
Usato per personalizzare
fruizione del servizio
(adattamento) e
disciplinare accesso
a risorse/servizi
(visibilità personalizzata) network domains
personalized
service view
MeeGo – Bologna - 18.03.2011 5/23

6. NON è una COMMODITY!
Mobile computing richiede approccio a livelli multipli e
con competenze multiple:
Dispositivi embedded (problematiche miniaturizzazione,
consumo ridotto di energia, …)
Comunicazioni wireless (IEEE 802.11a/b/g/s, Bluetooth,
WiMAX, comunicazioni veicolari, …)
Piattaforme di supporto software (Android, iPhoneSDK,
SymbianOS, …)
Gestione energia a livello piattaforma software
Gestione interfacce wireless multiple e handover a
livello piattaforma software
Gestione contesto
…
MIDDLEWARE
MeeGo – Bologna - 18.03.2011 6/23

7. NON è una COMMODITY!
…
Gestione cross-layer requisiti applicativi e allocazione
risorse
Supporto a servizi infrastructure-based
Supporto a servizi peer-to-peer
Supporto a servizi mobili opportunistici
Supporto a servizi mobili social-aware
E design, implementazione, deployment e
management runtime di tutte queste categorie di
servizi!
MIDDLEWARE
+ APPS
MeeGo – Bologna - 18.03.2011 7/23

8. Middleware e
Applicazioni Mobili
Solo per citare alcuni esempi possibili:
Distribuzione di streaming multimediale
dinamicamente adattato verso terminali mobili
differenziati
Always Best Connected e Always Best Served
Sensori, smart environment e conseguente adattamento
dinamico per servizi context-aware
Monitoraggio urbano collaborativo (traffico, inquinamento,
uso di veicoli/utenti intrinsecamente mobili, …) – vedi MobEyes
Gestione sessione e continuità, anche per servizi
multimediali, in infrastrutture eterogenee integrate
conformi a IMS – vedi IHMAS
Replicazione e applicazioni delay tolerant
Resource sharing e comportamenti sociali
…
MeeGo – Bologna - 18.03.2011 8/23

9. Context-Aware Applications in
Mobile and Large-Scale Scenarios
BLUETOOTH
WLAN
GPRS
MeeGo – Bologna - 18.03.2011 9/23

10. Need for Context Data
Distribution Infrastructures (CDDI)
Context data distribution is a complex task that poses
several challenging requirements:
Heterogeneity of the computing environment: devices (smartphones,
Personal Digital Assistants, netbooks, …) and communication technologies
(WiFi, Bluetooth, cellular 3G) and types (infrastructure and ad-hoc)
Device mobility and density: ever-increasing number of mobile devices,
already producing huge amounts of context data (environmental sensing,
social computing, …)
Data delivery with guaranteed quality levels: depending on specific
service (disaster recovery and emergency scenario, entertainment, …)
We need novel Context Data Distribution Infrastructures
(CDDIs) to transparently address and take over context data
distribution aspects (integration aspects, data distribution
differentiation, scalability, …)
MeeGo – Bologna - 18.03.2011 10/23

11. CDDI for Large-Scale Mobile Networks:
SALES Design Guidelines
1. Middleware-level approach
Middleware-based approaches to hide implementation complexity
Application-level solutions to have full visibility of underlying
execution platforms and hardware resources
2. Heterogeneous wireless communications
Heterogeneous wireless standards to increase both system
coverage and total available bandwidth
3. Heterogeneous wireless modes
Wireless infrastructures to ensure context data persistency
Wireless ad-hoc communications to reduce the distribution load
MeeGo – Bologna - 18.03.2011 11/23

12. CDDI for Large-Scale Mobile Networks:
SALES Design Guidelines
4. Constrained data distribution scopes
Distribute context data only to interested nodes (logical-locality
principle)
Distribute location-dependent context data only to the devices
contained in the local physical place (physical-locality principle)
PAN data scope
LAN data scope
5. Context data distribution adaptation at run-time
CDDI has to adapt to fit available resources (minimum intrusion
principle)
Introduce differentiated quality levels to drive and constraint
possible run-time reconfigurations of the CDDI
MeeGo – Bologna - 18.03.2011 12/23

13. SALES Architecture
Legend:
CN – Central Node CUN – Coordinator User Node
CN BN – Base Node SUN – Simple User Node
BN1
BN3
BN2
CUN21
CUN11 CUN31 CUN32
SUN211
SUN311 SUN322
SUN111 SUN321
SUN112
Three-level tree-like architecture
ensures effective and integrated usage of wireless infrastructure and ad-
hoc communication modes
minimizes tree depth to reduce management overhead
Nodes at the same level form a collaborative network in which context
data are distributed in a peer-to-peer (P2P) manner
MeeGo – Bologna - 18.03.2011 13/23

14. MANET vs.
Spontaneous Networking
MANET
homogeneous wireless technology
usually targeted to a specific application with given
constrains (e.g., energy, throughput...)
many nodes with high mobility degree
Spontaneous networking
very heterogeneous node capabilities
general-purpose environment
medium node mobility
MeeGo – Bologna - 18.03.2011 14/23

15. Spontaneous Networking
Impromptu interconnection of mobile and fixed nodes
users willing to share content and resources
Maximize interconnected nodes and available services
heterogeneous wireless technologies
both infrastructure and ad-hoc connectivity
multiple connectivity opportunities
MeeGo – Bologna - 18.03.2011 15/23

16. Spontaneous Networking
Node cooperation to UMTS
Base Station
IEEE 802.11
Access Point
provide single-hop connectivity
D IEEE 802.11
manage multi-hop connectivity A IBSS
C
support peer-to-peer services Bluetooth E
Piconet
B G
F
interface providing IEEE 802.11 Bluetooth
ad hoc connectivity IBSS Piconet
Peer-to-peer File Sharing single-hop link
service advertising: NodeA provides lesson notes
service discovery: NodeF looks for nodes that share files
service invocation: NodeF browses and downloads notes stored on
NodeA
NodeA and NodeF reside in different layer-3 networks
MeeGo – Bologna - 18.03.2011 16/23

17. RAMP Middleware
Application-layer management
layer-3 routing unsuitable for spontaneous networks
operating system independency + routing flexibility
Local management decisions
nodes have partial topology awareness
dynamic path reconfiguration
Reactive and mission-oriented approach
resource/path discovery only when required
eventually cached information invalidated very soon
Stateless communication
per-packet information delivery and path creation
Cross-layer management
applications may influence routing mechanism behavior
Management of multiple connectivity opportunities
RAMP evaluates end-to-end paths in a dynamic, context-aware, and
lightweight way
MeeGo – Bologna - 18.03.2011 17/23

18. File Sharing Application
No split: bufferSize greater than file size
transmission time increases linearly
Split: bufferSize lower than file size
transmission time greatly lowers
RAMP introduces little overhead
Best buffer size
minimum transmission time while limiting
read/write
depends on path length and packet size
sub-optimal default value: 50KB
int bestBufferSize(int
packetSize, int pathLength);
MeeGo – Bologna - 18.03.2011 18/23

19. Reliability to Path Disruptions
routing rerouting
Abrupt path disruption would interrupt
packet delivery
The intermediary node aware of path t0 A X L B
disruption looks for an alternative path,
while temporarily storing incoming
packets
t1 A X L B
Then it reroutes incoming and stored
packets and advices the multimedia
stream sender: no packet loss
Finally, the multimedia stream sender
starts exploiting the novel path
The final user only perceives a partial
quality degradation and only for a 17000
from stream start (ms)
Packet arrival time
limited time interval 16500
The overhead on the intermediary node 16000
is rather limited in terms of both 15500
additional communication and memory 15000
usage 14500
-20 -17 -14 -11 -8 -5 -2 1 4 7 10 13 16 19
Packet number (0 = last packet before path disruption)
MeeGo – Bologna - 18.03.2011 19/23

20. Reliability for
Delay Tolerant Applications
Critical message delivery in case of
(temporary) path unavailability, e.g., disaster
recovery scenario
sparse nodes in a wide geographical area
without cellular coverage routing storing
Node movements could create a path or an
intermediary node could move towards the
destination node area
t0 A X L B
Intermediary nodes cooperate temporarily
storing the message and periodically looking
for the destination N
Message discarding based on a temporal
deadline t1 A X L B
message validity gradually decreases while time
passes
Suitable in case of small-size messages, not
imposing too much overhead on intermediary
nodes
MeeGo – Bologna - 18.03.2011 20/23

21. Internet Connectivity Sharing
C
Border Nodes (BNs) provides Internet
connectivity via RAMP Internet BN1 X BN2 Internet
Node C discovers available services on 120 1
BNs and alternatively exploits them to throughput
weight 0.9
surf Google Maps (very intensive HTTP 100
0.8
interactions) via a standard Web browser
0.7
Throughput (KB/s)
80
0.6
Weight
60 0.5
0.4
Starting BN1 and BN2 bandwidth is
40
0.3
0.2
125KB/s and 25KB/s respectively (inverted 20
0.1 BN1
after 100s) 0
5 25 45 65 85 105 125 145 165 185
0
Node C notices BN1 provides a higher Time (s)
throughput and thus exploits it more
120 1
throughput
weight 0.9
frequently than BN2 100
0.8
Throughput (KB/s)
0.7
After 100s the bandwidth allocation is
80
0.6
Weight
inverted: node C notes throughput 60 0.5
0.4
modification and thus starts exploiting 40
0.3
BN2 more than BN1 20
0.2
0.1
0
5 25 45 65 85 105 125 145 165 185
0
BN2
Time (s)
MeeGo – Bologna - 18.03.2011 21/23

22. Pervasive Systems + Urban
Environments + Social Sharing
Not only urban space
pervasive personal space social space
systems go
wide-scale
(urban
environments),
but also strong
push towards
COLLABO-
RATION
Courtesy:MetroSense, A. Campbell
Social sharing of sensed information
Social sharing of available resources
MeeGo – Bologna - 18.03.2011 22/23

23. Social Applications:
a Push toward Resource Sharing?
The success of social
apps could help in
pushing users’
communities
toward better
exploitation of
available
resources (is this
“green” computing?)
via effective and
dynamic sharing
of info+services
from pervasive
systems
MeeGo – Bologna - 18.03.2011 23/24

24. Questions?
(and advertising ☺)
Grazie per l’attenzione!
E la parola adesso a relatori più specifici…
Contatti: Paolo Bellavista (paolo.bellavista@unibo.it)
Mobile Middleware Research Group
http://lia.deis.unibo.it/Staff/PaoloBellavista/
… e arrivederci all’interno del corso di
Sistemi Mobili M (prima attivazione AA 2010/2011)
MeeGo – Bologna - 18.03.2011