Mobile Middleware Applications and Summary

Timetable

■  11.3 Introduction and assignments ■  18.3. Platforms, Middleware ■  25.3. Platforms continued. ■  1.4. Patterns and applications ■  8.4. Patterns and applications continued ■  15.4. Applications and Summary ■  Assignment reception

◆  Tuesdays 17.3-25.4 18-20 D122 Julien Mineraud ◆  Final submission in May

■  Course exam on 29.4. 16:00 in B123

Contents

■  Advanced topics ◆  Cloud and offloading ◆  Cloudlets ◆  Cellular access & SDN and cloud ◆  HIP

■  5G and Cognitive Phones ■  Summary

Environment

!"#$%&'

(#)*"+'!"#$%'#,#-%*./'

&01+%$"*./'

&1-2*./'

2+3"*0-4#.'

0-01*./'

Access network

Web services

■  The services of Cloud computing can be divided into three categories:

■  1. Software-as-a-Service (SaaS), in which a vendor supplies the hardware infrastructure, the software product and interacts with the user using a portal (software on demand, pay-as-you-go).

■  2. Platform-as-a-Service (PaaS), in which a set of software and development tools are hosted by a provider on the provider's infrastructure, for example, Google's AppEngine.

■  3. Infrastructure-as-a-Service (IaaS), which involves virtual server instances with unique IP addresses and blocks of on-demand storage, for example, Amazon's Web services infrastructure.

Cloud Computing

Cloud Computing

Browser as a Platform Datacenters and clusters

Virtualization Web Application Frameworks

Elasticity Location Independent Resource Pooling

Information demand and supply (Open APIs)

Ubiquitous Network Access

On-demand service

Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)

Private, community, public, hybrid clouds

Offloading

■  The offloading of a mobile computing task is a trade-off between the energy used for local processing and the energy required for offloading the task, uploading its data, and downloading the result, if necessary.

■  One can express the offloading energy trade-off as follows: ◆  Etrade = Elocal − Edelegate > 0, where Elocal is the

energy used for complete local execution, and Edelegate is the energy used if the task is offloaded from the perspective of the mobile device.

■  If Etrade is greater than zero, then there is an energy benefit for delegating the task to the cloud.

What can be offloaded?

■  Content processing and transformations ◆  Example: Javascript processing in OperaMini

■  Completion notification and mobile push ■  Application execution

◆  Google docs, Windows Office

■  Connection management ◆  BitTorrent! ◆  Large downloads

■  Speech recognition ◆  Siri

■  Positioning (A-GPS) ■  NVIDIA cloud enhanced 3D graphics

Example of Offloading: Indexing

■  Implemented with Dessy: mobile desktop search ■  To offload indexing

◆  Transmit entire file to the cloud service ◆  Wait for response ◆  Receive file summary

■  High energy savings can be obtained when offloading CPU-intensive tasks

■  With N900 and WLAN 700kB/s: 96.5% savings! ◆  200 000 words, 1 MB file ◆  With WLAN 100kB/s this is reduced to 83.7%

Offloading Indexing

■  Offloading to nearby nodes is preferred.

■  Offloading via fast UMTS saves 14-56% of the energy and performs the task in 21−39% of the time compared to local processing.

■  Offloading via WLAN saves 73−89% of the energy and completes the task in 7−32% of the time.

■  Using local processing compared to GPRS offloading can save 78 − 80% of the energy and complete 25−33% faster.

■  Therefore, choosing the appropriate execution method in a given situation is important.

■  We have implemented an online scheduler for this environment.

10

Dessy Offloading Mobile Search and Indexing (Lagerspetz)

Fig. 1. The offloading destinations from the point of view of the mobiledevice.

scheme. This includes offloading to the Dessy Cloud servicevia UMTS/GPRS mobile Internet or via IEE 802.11 WLAN, aswell as using Scavenger to offload computation to surrogatespresent in the WLAN. In the absence of Internet connectivityin the local WLAN, represented by a dotted line in the Figure,the local surrogates may still be used for Scavenger-basedoffloading.

In the absence of any surrogates, if the WLAN is connectedto the Internet, cloud offloading is possible. As we willsee below, the choice of the optimal offloading method andcommunication technology depends mostly on the upload rateof the N900 and the energy cost of transmitting.

From the mobile device’s perspective, offloading indexingconsists of uploading a document for indexing, waiting forthe result to become ready, and downloading the result. In theexperiments, the energy consumed by the entire transaction ismeasured.

In the experimental setup, we used the Nokia N900 mobiledevice, with Bluetooth and FM radio disabled. The energy usewas measured using a Monsoon Power Monitor device2. ThePower Monitor allows recording of (time, current, voltage)-tuples at a sample rate of 5 kHz. Internally, the device is ableto measure at 50 kHz, and the recorded samples are averagesof 10 measurements each.

The N900 device was powered through the Power Mon-itor using a fake battery. No USB cable was connected tothe N900 during the experiments. Figure 2 shows the MonsoonPower Monitor and the N900 along with the fake battery. Theinput voltage was set to 4 V. The formula to obtain mWhvalues from the current, voltage and time tuples is

E = I ⇥ U ⇥ t/3600, (1)

where E is the energy in mWh, I is the current in mA, Uis the voltage in V , and t is the time in seconds. The PowerMonitor gave a steady voltage of 4V in all of the experiments.We will therefore use mAh values in the rest of this paper,

2http://msoon.com/LabEquipment/PowerMonitor/

Fig. 2. The Power Monitor, powering the N900 through a fake battery.

omitting U from the formula above. To obtain mWh values,one can just multiply the mAh value by 4. Note that the PowerMonitor records current in mA.

Every experiment run proceeded in the following manner:

1) The experiment script was started and the N900 screenis turned off

2) Measurement was started in Monsoon PowerTool3) Several seconds of idle time elapsed4) The N900 started an upload of the chosen file to the

target server using the chosen communication method5) The N900 finished the upload and started waiting for

the result to be ready6) The N900 downloaded the result7) The experiment script finished8) Several seconds of idle time elapsed9) Measurement was stopped in Monsoon PowerTool

The idle time was used to find the beginning and endof the active experiment time in the measured data. When

11

Cloudlets on a network

Constructed from clip art from pixabay.com

Cloudlets

12

Cloudlet architecture from CMU consists of customized ephemeral virtual machines with soft state, and a platform for running them Deploy applications near the users to avoid latency and bandwidth problems Facilitates elastic and mobile execution of network components in base stations Network support for computation offloading?

Virtualization

■  Virtualization system is a framework that combines or divides computing resources to present a transparent view of one or more environments ◆  Hardware/software partitioning (or

aggregation) ◆  Partial or complete machine simulation ◆  Emulation (can be partial or complete) ◆  Time-sharing

Mobile virtualization

■  Server Based Virtualization of Desktop Infrastructure

■  Moving the desktop to a virtualized image in the data center allows the complex components to be protected and componentized ◆  Workload isolation and migration ◆  Application virtualization

■  Virtualization is a possible solution to the fragmentation problem

■  Virtualization for offloading

◆  Running applications in a base station, nearby server, in the cloud

◆  Research proposals

LTE Evolved Packet Core (EPC)

15

SGW PGW

PCRF MME

HSS

eNodeB UE

UE

UE

Internet GTP

GTP: GPRS Tunneling Protocol for IP-over-UDP control and data MME: Mobile Management Entity SGW: Serving Gateway: forwards user traffic and mobility anchor PGW: Packet Data Network Gateway: external networks and billing HSS: Home Subscriber Service PCRF: Policy Charging and Rules Function

LTE RAN and EPC with SDN and Cloud

16

SGW PGW

PCRF MME

HSS

eNodeB UE

UE

UE

Internet

Controller

Switch Switch

Virt.

Virt. Virt.

Virt.

Virt.

Virt.

5G elements as services/applications running in virtualized environment

Virt.

Local and centralized coordination of radio resources

VMs

Virtualization aims for elasticity and runtime configuration support

17

OpenFlow Wireless SoftRAN SoftCell

Structure Centralized controller Local agents and centralized controller

Local agents and centralized controller

Environment Cellular and WiFi networks

Cellular network, centralized software-defined radio

Cellular network

Aim Resource virtualization with policy support

Separation of local and core functionalities of the radio access and consistent centralized control (spectrum, handovers, power values)

Separation of local and core functionalities and rule aggregation for small switch tables

Resource virtualization FlowVisor for slicing the network

No virtualization mechanism. Radio resources are managed by the controller with a 3D resource grid.

Not specified

Scalability Centralized controller makes all the decisions

Local agents make simple decisions to reduce the workload of the centralized controller

Similar to SoftRAN

Evaluation Real implementation and network experiments

Small-scale prototyping Prototyping with Floodlight controller and trace-driven simulation

Recent Proposals

Host Identity Protocol

What is HIP?

■  HIP = Host Identity Protocol ■  A proposal to separate identifier from locator at the

network layer of the TCP/IP stack ◆  A new name space of public keys ◆  A protocol for discovering and authenticating bindings

between public keys and IP addresses

■  Secured using signatures and keyed hashes (hash in combination with a secret key)

■  HIP slides originally by Dr. Pekka Nikander

Motivation

■  Not to standardise a solution to a problem ◆  No explicit problem statement

■  Exploring the consequences of the id / loc split ◆  Try it out in real life, in the live Internet

■  A different look at many problems ◆  Mobility, multi-homing, end-to-end security, signalling, control/

data plane separation, rendezvous, NAT traversal, firewall security, ...

HIP in a Nutshell

■  Architectural change to TCP/IP structure

■  Integrates security, mobility, and multi-homing ◆  Opportunistic host-to-host IPsec ESP ◆  End-host mobility, across IPv4 and IPv6 ◆  End-host multi-address multi-homing, IPv4/v6 ◆  IPv4 / v6 interoperability for apps

■  A layer between IP and transport ◆  Introduces cryptographic Host Identifiers

IP addr

A new Name Space of Host Identifiers (HI)

Public crypto keys! Presented as 128-bit long hash values, Host ID Tags (HIT)

Sockets bound to HIs, not to IP addresses HIs translated to IP addresses in the kernel

The Idea

Process

Transport

IP layer

Link layer

IP address

< , port>

Host Identity Host ID

Host ID

Protocol overview Initiator Responder

I1: HITI, HIT

R or NULL

R1: HITI, [HIT

R, puzzle, DH

R, HI

R]

sig

I2: [HITI, HIT

R, solution, DH

I, {HI

I}]

sig

R2: [HITI, HIT

R, authenticator]

sig

User data messages

Control!

Data!

Base exchange

Initiator Responder

I1 HITI, HIT

R or NULL

R1 HITI, [HIT

R, puzzle, DH

R, HI

R]

sig

I2 [HITI, HIT

R, solution, DH

I,{HI

I}]

sig

R2 [HITI, HIT

R, authenticator]

sig

ESP protected TCP/UDP, no explicit HIP header

User data messages

solve puzzle

verify, authenticate, replay protection

• Based on SIGMA family of key exchange protocols

standard authenticated Diffie-Hellman key

exchange for session key generation

Select precomputed R1. Prevent DoS. Minimal

state kept at responder! Does not protect from

replay attacks.

Other Core Components

■  Per-packet identity context ◆  Indirectly, through SPI if ESP is used ◆  Directly, e.g., through an explicit shim header

■  A mechanism for resolving identities to addresses ◆  DNS-based, if FQDNs used by applications ◆  Or distributed hash tables (DHTs) based

Many Faces

■  Different IKE for simplified end-to-end ESP ■  Super Mobile IP with v4/v6 interoperability and

dynamic home agents ■  A host multi-homing solution

■  New waist of IP stack; universal connectivity ■  Secure carrier for signalling protocols

Rendezvous

■  Initial rendezvous ◆  How to find a moving end-point? ◆  Can be based on directories ◆  Requires fast directory updates

✦  Bad match for DNS

■  Tackling double-jump ◆  What if both hosts move at same time? ◆  Requires rendezvous point

Depends on application For multi-addressing, self-generated keys Usually keys in the DNS Can use PKI if needed Opportunistic mode supported

SSH-like leap-of-faith Accept a new key if it matches a fingerprint

Key distribution for HIP

DNS server

Client app

DNS query: A, AAAA, KEY

DNS reply: A, AAAA, KEY

Basic HIP rendezvous

Rendezvous server

Server

Client

Rendezvous registration

I1!

R1!I2!R2!

HIs originally planned to be stored in the DNS Retrieved simultaneously with IP addresses Does not work if you have only a HIT

Question: How to get data based on HIT only? HITs look like 128-bit random numbers

Possible answer: DHT based overlay like i3

The infrastructure question

Distributed Hash Tables

Distributed directory for flat data Several different ways to implement Each server maintains a partial map Overlay addresses to direct to the right server Resilience through parallel, unrelated mappings Used to create overlay networks

HIP Applications

■  Data center and cloud networking

■  Secure signalling between VMs

■  Secure mobile access

■  Control protocol for devices

Examples

Email

■  Simple Mail Transfer Protocol (SMTP) protocol for sending messages

■  The Internet Message Access Protocol (IMAP) supports polling and notifications

■  The server sends a notification to a client to inform that there is data available

■  This allows flexible retrieval of messages and gives the client the control of whether or not to download new message data.

Mobile Push Email

■  BlackBerry ■  Microsoft DirectPush ■  Apple iPhone OS 3.0

■  Implementation ◆  Custom server in access network ◆  IMAP IDLE ◆  Long-lived client-initiated connection ◆  SIP (in the future?)

BlackBerry

■  Blackberry devices have become popular among business users in part because they support desktop style email usage experience with almost instant delivery of messages

■  Blackberry devices utilize a custom enterprise server that is connected to the traditional e-mail system

■  The enterprise server monitors the e-mail server and then can pull new messages and send them to the Blackberry device using push over the wireless network

DirectPush

■  Microsoft introduced the DirectPush Technology with Windows Mobile 6

■  Mobile devices that support DirectPush utilize a long-lived HTTPS request to the Exchange server

■  The Exchange server monitors activity on the users mailbox

■  Details ◆  http://technet.microsoft.com/en-us/library/

cc182260.aspx

Source: http://technet.microsoft.com/en-us/library/cc182270.aspx

Can now increase interval, one previous RTT with the same value

Hearbeat settings

■  The heartbeat starts at the default rate. ■  The direct push algorithm on the device then

dynamically adjusts the heartbeat interval to maintain the maximum time between heartbeats without exceeding the time-out value.

■  The rate adjustment is based on the following configuration parameter settings (increments are maximum, can be smaller set by tuning component). ◆  HeartbeatDefault (480s=8min) ◆  HeartbeatIncrement (300s=5min) ◆  HeartbeatMin (480s=8min) ◆  HeartbeatMax (1680s=28min)

Why adaptive?

■  Two different things: ◆  Network timeout ◆  Server data available rate

■  Too large value à network timeout breaks connection (should be below network timeout)

■  Too small value à too many polling operations

■  Polling operations delay data retrieval ■  Thus dynamic setting of the polling

taking the network/server into account

IMAP IDLE

■  This solution relies on the existing IDLE (RFC 2177) command to provide instant e-mail notification on the client device

■  The IDLE command is often used to signal the ability of a client to process notifications sent outside of a running command

■  This can be used to provide a similar user experience to push

Mobile Advertisement Example ■  The central entities are the end user, the trusted

party, the operator, and the provider ■  The trusted party manages end user profiles and

anonymizes user profiles and other data so that other parties cannot determine user preferences

■  The operator is responsible for running the core system that stores orders

■  When an order and offer match, a notification is generated towards the end user

■  The provider is the advertiser and responsible for the offers and providing advertisement information that can be then delivered to end users.

Anonymizer

Resolver

Trusted party

Private and Public context

End user

Publishing and rendering

Provide adv. Offers

Provider

Notifications

Orders

Core System Notification

profiles

Orders Offers

Administration

Statistics

Operator

Matches

Public context (weather, time, …)

Offers

Statistics

Adv. Data

Adv. information

Resolver requests notifications

Revisiting Patterns 1/4

■  Widgets ◆  Widgets can employ a number of

patterns, typically Remote Proxy and Broker are pertinent. Observer for updates.

■  Location Awareness. ◆  Rendezvous and Synchronization are

crucial. This can be achieved using a Remote Proxy pattern and the Connection patterns. The Remote Facade pattern is often applied to minimize the number of remote calls needed. Eager Acquisition can be used to anticipate future information needs.

Revisiting Patterns 2/4

■  Generic Mobile push. This application case is similar to Mobile Server, Location Awareness, Mobile Advertisement, and Mobile Video.

■  Mobile Push Email. Reachability is vital also in this application scenario. This is achieved using the Client-initiated Connection, Remote Proxy, and Rendezvous patterns.

■  Facebook Chat. Multi-tier, client-initiated connection, Lazy synchronization (contacts), Rendezvous, and Remote Proxy.

Revisiting Patterns 3/4

■  Mobile Advertisement. ◆  This application requires a combination of

patterns, namely Client-initiated connections, Rendezvous, Synchronization, Caching, Remote Proxy, and Broker.

◆  The connections ensure reachability of the mobile terminals and allow to the advertisement system to synchronize advertisements and impressions with the mobile device (if they are stored on board).

◆  Rendezvous is needed to keep track of the current location of the device.

◆  Remote proxy is needed to handle the connections.

◆  The Broker is used to provide indirection (and privacy) between different components in the system.

Revisiting Patterns 4/4

■  Mobile Video. This application can utilize the Client-initiated Connection and Multiplexed Connection for enabling continuous media delivery to the client. ◆  Video-on-demand can be Cached, and

video stream buffering can be seen a variant of the Eager Acquisition pattern.

■  Mobile Server. ◆  Reachability is vital in this application and

it is achieved using the Client-initiated Connection, Remote Proxy, and Rendezvous patterns. Caching can be used at the Remote Proxy to improve performance.

Recent Trends

49

Gartner Hype Curve 2013

Topics ■  App stores

◆  Searching, purchasing, advertising, … ◆  How to do software updates ◆  How to support community buildup

■  Distributed control plane for applications ■  Inter-app communication is still in early phases ■  Difficult to build on local communication context

(some games do this today)

Sensors

■  The number of sensors will increase dramatically

■  Innovative new applications ◆  Pulse monitor, augmented reality, …

■  Plug-in sensors and devices

■  Crowdsourcing sensor data and processing?

■  Can we use basestations? ■  Decentralized processing?

■  Smartphones have become hubs for applications and connecting with the Internet

■  Cloud has emerged as a backend for mobile applications ■  Mobile data and WiFi are the dominant protocols for

connecting with Internet resources ■  The next generation solutions are addressing limitations of

the current smartphones ◆  Coordination of resource usage ◆  Offloading in its many forms ◆  Heterogeneous environment and the emergence of IoT / M2M /

wearables

Smartphones

Observations

■  Smartphone and mobile device hardware and software evolve rapidly

■  Multiple wireless protocols ■  Heterogeneous computing over multiple cores

◆  Dedicated subsystems (sensor hubs) ◆  Increasing number of sensing subsystems ◆  Always-on sensing

■  Battery technology has not kept pace with the development ■  Software is not, in many cases, optimized ■  Difficult to balance between local versus distributed processing ■  Difficult to control traffic across interfaces

Challenges

■  Cloud integration ■  Event-based program flow ■  Content storage, search, and sync ■  APIs and interoperability

◆  Mitigating fragmentation

■  Energy efficiency

■  Beyond 4G for early 2020s ■  Significant improvements in wireless

communication ◆  Smart radios and spectrum sharing ◆  1000 times higher spectral efficiency ◆  Cooperative relays and femtocells

■  Device-to-Device communication ■  Support for Internet of Things and Machine-to-

Machine ■  World Wide Wireless Web ■  SDN and cloud for the core network

Discussion on 5th Generation Mobile Networks (5G)

■  Distributed sensing and data gathering across mobile devices and network elements

■  Modeling and predicting the operating environment ◆  User, device, device neighborhood, network

■  Offline and online optimization based on the models ◆  Taking into account the feedback effect

■  Optimization of user experience, energy consumption, traffic patterns, wireless usage, …

Vision of a cognitive phone and network

Conclusions

■  Mobile software is mainstream ◆  Appstores ◆  Better tools and development environments ◆  Integration with Web resources ◆  Integration with other apps ◆  Integration with sensors!

■  Challenges include ◆  Fragmentation in its many forms

✦  Devices, standards, implementations ◆  Access to mobile APIs ◆  Practical ubicomp deployment ◆  Adaptation

Outlook

Mobile OS and Platform

Future phone SoC

Applications

Heterogeneous multiprocessing, always-on sensing, virtualization, traffic and computation offloading, IoT

5G, BT LE, new IEEE protocols Wireless connectivity

More cores, GPUs, hardware co-processors, hubs

Context-awareness Augmented reality Wearable computing Health and medical Games

Battery Larger batteries, wireless charging Long term: new materials

Exam

■  Course exam on 29.4. 16:00 in B123

Included chapters

■  Chapter 1: Introduction ■  Chapter 2: Architectures (note 2.6 describes old

systems) ■  Chapter 3: Support Technologies. 3.1, 3.6, 3.7 ■  Chapter 4: Principles and Patterns ■  Chapter 10: Application and Service Case Studies

Additional reading

■  Carat: Collaborative Energy Diagnosis for Mobile Devices. ACM Sensys 2013.

■  Analyzing Inter-Application Communication in Android. Mobisys 2011.

■  K. Kumar and Y-H. Lu. Cloud computing for Mobile Users: Can Offloading Computation Save Energy? IEEE Computer, 2011.