an ims-based middleware solution for energy-efficient and cost-effective mobile multimedia services

An IMS-based Middleware Solution for Energy-Efficient and Cost-Effective

Mobile Multimedia ServicesMobile Multimedia Services

Paolo Bellavista, A i C di L F hi iAntonio Corradi, Luca Foschini

DEIS, University of Bologna, ITALY{paolo.bellavista, antonio.corradi, luca.foschini}

@unibo.it

April 29th, Mobilware’09

AgendaAgenda

Multimedia service delivery for the wireless InternetMiddleware for IMS-based energy-efficient mobile gymultimedia services– The IMS-compliant Handoff Management Application p g pp

Server (IHMAS) multimedia middleware solution– Context-aware, IMS-standard-based, and dynamic

switching-on of wireless interfaces only for the duration of multimedia service sessions

Implementation insights and experimental evaluation– Switch on and session re-direction time evaluation

Mobilware’09 – Berlin, Germany - 29.04.2009 2/19

– Energy-saving evaluation

Application scenario:Application scenario:multimedia services in the Wireless Internetmultimedia services in the Wireless Internetmultimedia services in the Wireless Internetmultimedia services in the Wireless Internet

UserA

Active Proxy Components

Call to UserB

Internet

Call to UserB

WLANUserB


UMTS

IMS IMS –– IP Multimedia SubsystemIP Multimedia Subsystem

DATA FLOWApplication Servers (ASs)

MobileNode(MN)

Corresp. Node(CN)

Application Servers (ASs)Signaling Functions/Entities for

IMS Signaling Extension/Integration

AS AS

Signaling Functions

Proxy-based architectureworking at OSI session layer

P-CSCF P-CSCF

S-CSCF S-CSCFworking at OSI session layer

Common set of functions to ease

SIPAuthentication Functions

Visited network 1 Visited network 2

I-CSCF I-CSCFHSS HSS

multimedia service deployment in highly heterogeneous

wireless computing environments


Home Network 1 Home Network 2HSS HSS

IMS Presence ServiceIMS Presence ServicePresence Service (PS) permits users and hw/sw components, called presentities (Pi ), to convey their ability and willingness to p ( i ), y y gcommunicate with subscribed watchers (Wj )

IMS standardizes PS as a specific AS IMS PS

P1SUBSCRIBE

W1

p

NOTIFY

P2 SUBSCRIBENOTIFYPUBLISH IMS

PSW2

PNWN

Watchers

PN

PresencePresentities


WatchersServerPresentities

ApplicationApplication--level middlewarelevel middlewarefor multimedia servicesfor multimedia servicesfor multimedia services for multimedia services

Session management and continuity

Context-aware power management middlewared t l l l t– updates low level parameters (wireless communications

availability, battery level, …)

wireless access prediction and mobilewireless access prediction and mobile node energy monitoring

– executes application-level specific energy-savingexecutes application level specific energy saving decisions and session signaling actions

dynamic wireless interface switch on and yautomatic session re-direction/handoff

– integrates seamlessly with existing infrastructures


full compliancy with IMS standard

IHMAS active middlewareIHMAS active middleware

IMS-compliant Handoff Management Application Server

Multimedia session continuity– Session signaling enhancements for power management

Active session signaling and media data pathsActive session signaling and media data paths– Dynamic session signaling and re-direction to exploit high

energy-consumption and low transmission-cost gy pwireless interfaces

IMS-compliant solutionSession management entity realized as a novel IMS AS– Session management entity realized as a novel IMS AS

– AS performs management operationsContext-aware energy-saving decision making and orchestrationorchestration

Application-level approach– Seamless integration with existing services


IMS PS to deliver context updates about mobile node

IHMAS Power Management Facility: IHMAS Power Management Facility: Distributed ArchitectureDistributed ArchitectureDistributed ArchitectureDistributed Architecture

Low-consumption wireless interface ng

al

ing

MN Home Domain

ower

-Sav

isi

on S

igna

2 <<publishes>>

AS NodeASPMPS

3. <<notifies>>

High-consumption wireless interface

CM

Data Tx/Rx

IMS IMS-compliantSIP Signalling

Data Tx/Rx

PoSe

ss1.2. <<publishes>>

IMS-compliantSIP Signalling

4.5.

6.

MNIMS Client

Data Tx/Rxand Playout

CNIMS Client

Data Tx/Rxand Playout

Dat

a ra

nspo

rt

7.DATA

Context Monitor – CM (one for client): implements lightweight and completely

MN Visited Wireless Access Domain CN Domain Tr

decentralized context monitoring via local access to client wireless devicesAS for Power Management – ASPM (one for IMS domain): realizes our IMS energy-saving optimization


energy saving optimizationIMS PS – PS (one for access locality): facilitates CM-ASPM interactions

IHMAS Power Management Facility: IHMAS Power Management Facility: Modified Invitation ProtocolModified Invitation Protocol

IHMAS original message flow extensions

CN (I-)S-CSCFMN PSMN ASPM MN

(1) SUBSCRIBE(2) SUBSCRIBE Always-on Switched-

IMS standard messages

1. CM proactively notifies context changes overt C

hang

e fic

atio

n

(3) OK( )

(4) OK(5) PUBLISH

context change(6) PUBLISH

(7) OK

yinterface on interface

CM:context context changes over

the always-on interface2. ASPM intercepts INVITE

Con

tex

Not

if (7) OK(8) OK

(9) NOTIFY(10) NOTIFY context change

(11) OK(12) OK

changed

from Correspondent Node (CN) and activates wireless i t f it h t

(13) INVITE

(12) OK

(14) INVITE (15) new-INVITE

Interface rebindal

l

(16) 100 Trying wait MN re-REGISTER

interface switch-on at Mobile Node (MN)

3. MN re-REGISTERs over

(17) (de-)REGISTER(18) 401 Unauth.

(19)(de-)REGISTER(20) OK

(21) REGISTERitch

on a

nd c

are

ctio

n

(22) REGISTER switched-on interface, and ASPM re-directs CN by using a MOVED D

ynam

ic s

wi

redi

r

(23) 401 Unauth.

(29) 302 MOVED(30)

302 MOVED

(22) REGISTER(24) 401 Unauth.

(25) REGISTER

(27) OK(26) REGISTER

(28) OK


message(29) 302 MOVED302 MOVED(31) INVITE (32) INVITE

send MOVED

Implementation Insights:Implementation Insights:AS for Power ManagementAS for Power ManagementAS for Power ManagementAS for Power Management

ASPM implementation is based on JAIN SIP stack

private void processInvite(Request request) { SessionDescription sdp = sipUtils.getSessionDescription(request);

i

1.

On INVITE message, ASPM:1. Extracts Session Description Protocol

(SDP) part of the message

sd=addPowerManagementAttribute(request, sd); request.removeContent(); try { request.setContent(sd, headerFactory.

createContentTypeHeader("application","sdp"));

2.

( ) p g2. Adds in the optional field (“a:” field) the

MAC of the wireless interface to switch on3. Sends it to MN

createContentTypeHeader( application , sdp )); } catch (ParseException e) { e.printStackTrace(); } try { sipProvider.sendRequest(request); } catch (SipException e) { e.printStackTrace(); } }

3.

Content-Type: application/sdp Content-Length: 414

0 Modified INVITE message

INVITE sip:[email protected] SIP/2.0 …

v=0 o=- 0 0 IN IP4 192.168.3.11 s=IMS Call c=IN IP4 192.168.3.11 t=0 0 m=audio 10281 RTP/AVP 3 0 14 101 b=AS:64

Modified INVITE message– SDP part of the INVITE message as

modified by ASPMN t li ti ta=rtpmap:3 GSM/8000

a=rtpmap:0 PCMU/8000 a=rtpmap:14 MPA/90000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 a=curr:qos local none a curr:qos remote none

– Note our application parameter a:… field at the end of the message


a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=switchoninterface:00:04:23:5E:48:DE 192.168.125.2

Implementation Insights:Implementation Insights:IMS ClientIMS ClientIMS Client IMS Client

Based on UCT IMS ClientNew-INVITE processing

void ims_process_incoming_invite(eXosip_event *je) { … sdp_message_t * sdp_message;

X i l k() New-INVITE processing– Extracts from the “a:…”

field the MAC of the wireless interface to

eXosip_lock(); sdp_message=eXosip_get_sdp_info(je->request); eXosip_unlock(); switchOnAddress=extractPowerManAttribute(sdp_message);

if(newInvite) ims_send_de_register(); / i i i / wireless interface to

switch on– Sends de-REGISTER

else { … /* standard session invite management */ }} void ims_send_re_register() { int port=5060, pid, status;pid=fork(); if(pid==0) { // child if(!is_bye) { execl("../scripts/switchOnInterface.sh", "switchOnInterface.sh", switchOnAddress, (char *)0 ); }

Re-registration– Switches on the

wireless interface else { execl("../scripts/switchOffInterface.sh", "switchOffInterface.sh", switchOnAddress, (char *)0 ); } } else { // parent wait(&status); if(!is_bye) { while( eXosip_listen_addr(IPPROTO_UDP, switchOnAddress,

wireless interface– Sends a REGISTER

over the switched-on wireless interface_ _ _ _

port, AF_INET, 0) != 0 ) port++; } else { while( eXosip_listen_addr(IPPROTO_UDP, alwaysOnAddress, port, AF_INET, 0) != 0 ) port++; } ims_send_register(); }

wireless interface


}

Implementation DetailsImplementation Details

IMS core componentsO IMSC (F k )– OpenIMSCore (Fokus)

– initial Filter Criteria (iFC) for IMS message re-routing

ASPMASPM– Java NIST JainSIP implementation of the SIP stack– OpenIMSCore properly configured to interpose ASPM in the

i li thASPM signaling path

University of Cape Town (UCT) IMS Client – CM: iwconfig and hcitool (Linux), NDIS (WIN)

ASPM

g ( ) ( )– CM integration with UCT IMS Client

Deployment environmentDeployment environment– Client: Linux laptops with 3G UMTS adaptor and IEEE 802.11b Cisco card– P-/I-/S-CSCF run on PCs: 2 CPUs 1,80GHz, 2048MB RAM, Linux Ubuntu– Wireless infrastructures:


Wi-Fi: Cisco Aironet 1100 AP

Experimental testbedExperimental testbed

Bob sends the INVITE t

Adds our power saving “a:” field WLAN

• Alice switches on the WLAN interface and re-INVITE request

intercepted and modified by

g WLANWLAN interface and re-registers• ASPM sends to Bob a 302 Moved Temporarily to

ASPM

TEN

EW

_

ASPM

302-MTem

p

302 Moved Temporarily to re-direct the session toward switched-on i t f IS

TER

INV

IT_IN

VITE

Moved

porarily

interface

RE

G

UCT IMS

IMS Core Infrastr ct re

IMS Core Infrastr ct re

INVITE

302 Moved Temporarily

INVITE

UCT IMS Client (Alice)

InfrastructureInfrastructure

UCT IMS Client (Bob)

INVITE


Client (Bob)UMTS

Experimental Results (1):Experimental Results (1):some elements about the testbedsome elements about the testbed

Experimental testbed:

Linux boxes for the IMS infrastructure (1.8GHz CPU and 2GB RAM)

Nokia N95 as reference client device (one of the first smart phones with WiFi)

VoIP service with GSM-encoded audio, frame rate = 50 frames/s

Reported results are averaged over 1000 session initiation cases

Session Initiation Delay Analysis:

T0: initiation phase

T1: mobile node de-registration

T2: mobile node registration for WiFi


g

T3: MOVED notification

Experimental Results (2):Experimental Results (2):session inititation delaysession inititation delay

CN (I-)S-CSCFMN

(1) INVITE

PSMN ASPM MNCN (I-)S-CSCFMN

(1) INVITE(1) INVITE

PSMN ASPM MN

yys (1) INVITE

(2) INVITE (3) new-INVITE

Interface rebind(4) 100 Trying

wait MN re-REGISTER

T 0

(1) INVITE(1) INVITE(2) INVITE(2) INVITE (3) new-INVITE(3) new-INVITE

Interface rebind(4) 100 Trying

wait MN re-REGISTER

T 0

285

ms

(5) (de-)REGISTER(6) 401 Unauth.

(7) (d )REGISTER

re REGISTER

1

(5) (de-)REGISTER(5) (de-)REGISTER(6) 401 Unauth.(6) 401 Unauth.

(7) (d )REGISTER(7) (d )REGISTER

re REGISTER

1 ms

largel lo er than 3s indicated b(7) (de-)REGISTER(8) OK

(10) REGISTER(9) REGISTER

T (7) (de-)REGISTER(7) (de-)REGISTER(8) OK(8) OK

(10) REGISTER(10) REGISTER(9) REGISTER(9) REGISTER

T57

0um

< 3

s largely lower than 3s, indicated by E.721 as the recommended call setup

delay for local calls(11) 401 Unauth.

(10) REGISTER

(12) 401 Unauth.(13) REGISTER

(14) REGISTER

T 2

(11) 401 Unauth.(11) 401 Unauth.(10) REGISTER(10) REGISTER

(12) 401 Unauth.(12) 401 Unauth.(13) REGISTER(13) REGISTER

(14) REGISTER(14) REGISTER

T 2

825

mssu

(17) 302 MOVED(18) 302 MOVED

(19) INVITE (20) INVITE

(15) OK (16) OK

send MOVED

T 3

(17) 302 MOVED(17) 302 MOVED(18) 302 MOVED(18) 302 MOVED

(19) INVITE (20) INVITE(20) INVITE

(15) OK(15) OK (16) OK(16) OK

send MOVED

T 3

8 m

s


(19) INVITE (20) INVITE(19) INVITE (20) INVITE(20) INVITE93

Experimental Results (3):Experimental Results (3):StandStand--by timeby timeStandStand by timeby time

250

150

200Nokia N95WiFi and UMTS t db

100

150H

oursstandby

These standby costs are

50

costs are completely eliminated by our IHMAS power

0stand-by UMTS stand-by UMTS, IMS-

based registrationstand-by WiFi, IMS-based registration

power management technique

based registration based registration

Analytical results evaluated for N95 (also based on Arjona experienceand measurements)

B tt 950 AH d h d t 3 7V


– Battery: 950mAH and charged at 3.7V– WiFi average additional consumption (always-on): 0.05W

Experimental Results (4):Experimental Results (4):Call timeCall timeCall timeCall time

300

200

250In addition, significant advantages

150

200M

inut

es

on call time

100

M

0

50

0UMTS call time Energy-efficient WiFi call time

Energy-efficient WiFi call time is longer than the talk time duration


Energy-efficient WiFi call time is longer than the talk time durationspecified by Nokia for UMTS

Conclusions andConclusions andongoing workongoing workongoing workongoing work

Conclusions– Feasibility of IMS-based standard approaches also for

context-aware power managementPractical guide on how to exploit IMS ASs to support– Practical guide on how to exploit IMS ASs to supportapplication-level management functions

– Energy-saving techniques can relevantly increase battery lifetimegy g q y ywhen using high-consumption and low-cost wireless interfaces

– Session invitation delays introduced by the IHMAS facility forpower management are compatible even with strict VoIP reqsp g p q

Ongoing work– Scalability issues of IMS PS (see our article on IEEE Wireless Comm in June)

– J2ME version of CM and IMS clientExtensive measurements of energy consumption in wide-scale


– Extensive measurements of energy consumption in wide-scale deployment environments

IHMAS project Web site IHMAS project Web site and contactsand contactsand contacts and contacts

P t t d htt //li d i ib it/Prototype code: http://lia.deis.unibo.it/Research/IHMAS

Contacts: Luca Foschini ([email protected])

A ti ?Any questions?

Thanks for your attention!


y

an ims-based middleware solution for energy-efficient and cost-effective mobile multimedia services

Documents