An IMS-based Middleware Solution for Energy-Efficient and Cost-Effective
Mobile Multimedia Services Mobile Multimedia Services
Paolo Bellavista,
A i C di L F hi i
Antonio Corradi, Luca Foschini
DEIS, University of Bologna, ITALY
{paolo.bellavista, antonio.corradi, luca.foschini}
@unibo.it
Agenda Agenda
Multimedia service delivery for the wireless Internet
Middleware for IMS-based energy-efficient mobile gy multimedia 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
–
Energy-saving evaluation
Application scenario:
Application scenario:
multimedia services in the Wireless Internet multimedia services in the Wireless Internet multimedia services in the Wireless Internet multimedia services in the Wireless Internet
UserA
Active Proxy Components
Call to UserB
Internet
Call to UserB
WLAN
UserB
UMTS
IMS
IMS – – IP Multimedia Subsystem IP Multimedia Subsystem
DATA FLOW
Application Servers (ASs)
Mobile Node (MN)
Corresp.
Node (CN)
Application Servers (ASs) Signaling Functions/Entities for IMS Signaling Extension/Integration
AS AS
Signaling Functions
Proxy-based architecture working at OSI session layer
P-CSCF P-CSCF
S-CSCF S-CSCF
working at OSI session layer
Common set of functions to ease Authentication FunctionsSIP
Visited network 1 Visited network 2
I-CSCF I-CSCF
HSS HSS
multimedia service deployment in highly heterogeneous
wireless computing environments
Home Network 1 Home Network 2
HSS HSS
IMS Presence Service IMS Presence Service
Presence Service (PS) permits users and hw/sw components, called presentities (Pi), to convey their ability and willingness to
p ( i ), y y g
communicate with subscribed watchers (Wj )
IMS standardizes PS as a specific AS
Æ IMS PS
P1 SUBSCRIBE
W1 p
NOTIFY
P2 PUBLISH IMS NOTIFYSUBSCRIBE
PS W2
PN
WN
Watchers PN
Presence
Presentities Server Watchers
Presentities
Application
Application--level middleware level middleware for multimedia services for multimedia services for multimedia services for multimedia services
Session management and continuity
Context-aware power management middleware
d t l l l t
–
updates low level parameters
(wireless communications availability, battery level, …)Æ wireless access prediction and mobile
Æ wireless access prediction and mobile node energy monitoring
–
executes application-level specific energy-saving executes application level specific energy saving decisions and session signaling actions
Æ dynamic wireless interface switch on and y automatic session re-direction/handoff
–
integrates seamlessly with existing infrastructures
Æ full compliancy with IMS standard
IHMAS active middleware IHMAS active middleware
IMS-compliant Handoff Management Application Server
Multimedia session continuity
–
Session signaling enhancements
for power managementActive session signaling and media data paths
Active session signaling and media data paths
– Dynamic session signaling and re-direction
to exploit high energy-consumption and low transmission-cost gy p wireless interfaces
IMS-compliant solution
Session management entity realized as a
novel IMS AS
– Session management entity realized as a
novel IMS AS
– AS performs management operations
Context-aware energy-saving decision making and orchestration
orchestration
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 Architecture Distributed Architecture Distributed Architecture Distributed Architecture
Low-consumption wireless interface
ng aling
MN Home Domain
ower-Savi sion Signa
2 <<publishes>>
AS Node
PS ASPM 3.
<<notifies>>
High-consumption wireless interface
CM
Data Tx/Rx
IMS IMS-compliant
SIP Signalling
Data Tx/Rx
Po Sess
1.
2. <<publishes>>
IMS-compliant SIP Signalling
5. 4.
6.
MN IMS Client Data Tx/Rx and Playout
CN IMS Client Data Tx/Rx and Playout
Data ransport
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 devices
AS for Power Management – ASPM (one for IMS domain): realizes our IMS energy-saving optimization
energy saving optimization
IMS PS – PS (one for access locality): facilitates CM-ASPM interactions
IHMAS Power Management Facility:
IHMAS Power Management Facility:
Modified Invitation Protocol Modified 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 over
t Change fication
(3) OK ( )
(4) OK
(5) PUBLISH context change (6) PUBLISH
(7) OK
y
interface on interface
CM:
context
context changes over the always-on interface 2. ASPM intercepts INVITE
Contex Notif (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 rebind
all
(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) REGISTER
itch on and ca rection (22) REGISTER
switched-on interface, and ASPM re-directs CN by using a MOVED
Dynamic swi redir
(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 MOVED 302 MOVED
(31) INVITE (32) INVITE
send MOVED
Implementation Insights:
Implementation Insights:
AS for Power Management AS for Power Management AS for Power Management AS 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 g
2. Adds in the optional field (“a:” field) the MAC of the wireless interface to switch on 3. 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:alice@open-ims.test 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 ASPM
N t li ti t
a=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 Client IMS Client IMS Client IMS Client
Based on UCT IMS Client
New-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 Details Implementation Details
IMS core components
O IMSC (F k )
– OpenIMSCore (Fokus)
– initial Filter Criteria (iFC) for IMS message re-routing
ASPM
ASPM
– Java NIST JainSIP implementation of the SIP stack
– OpenIMSCore properly configured to interpose ASPM in the
i li th
ASPM 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 environment
Deployment 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 testbed Experimental 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 WLAN
WLAN interface and re- registers
• ASPM sends to Bob a 302 Moved Temporarily to
ASPM
TE NEW_
ASPM Temp 302-M
302 Moved Temporarily to re-direct the session
toward switched-on
i t f ISTER
INVIT _INVITEMoved porarily
interface
REG
UCT IMS
IMS Core Infrastr ct re
IMS Core Infrastr ct re INVITE
302 Moved Temporarily
INVITE
UCT IMS Client (Alice)
Infrastructure Infrastructure UCT IMS
Client (Bob)
INVITE
Client (Bob)
UMTS
Experimental Results (1):
Experimental Results (1):
some elements about the testbed some 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 WiFig
T3: MOVED notification
Experimental Results (2):
Experimental Results (2):
session inititation delay session inititation delay
CN (I-)S-CSCFMN (1) INVITE
PSMN ASPM MN
CN (I-)S-CSCFMN (1) INVITE
(1) INVITE
PSMN ASPM MN
y y
s (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 0285 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
T570
um < 3s
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 2825 ms
su
(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 38 ms (19) INVITE (20) INVITE(19) INVITE (20) INVITE(20) INVITE
93
Experimental Results (3):
Experimental Results (3):
Stand
Stand--by time by time Stand
Stand by time by time
250
150
Nokia N95 200
WiFi and UMTS
t db
100 150
Hours
standby These standby
costs are
50
costs are completely eliminated by our IHMAS power
0
stand-by UMTS stand-by UMTS, IMS- based registration
stand-by WiFi, IMS- based registration
power
management technique
based registration based registration
Analytical results evaluated for N95 (also based on Arjona experience and 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 time Call time Call time Call time
300
200
In addition, 250
significant advantages
150 200
Minutes
on call time
100
M
0 50
0
UMTS 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 duration specified by Nokia for UMTS
Conclusions and Conclusions and ongoing work ongoing work ongoing work ongoing work
Conclusions
–
Feasibility of IMS-based standard approaches also for context-aware power management
Practical guide on how to exploit IMS ASs to support
–
Practical guide on how to exploit IMS ASs to support application-level management functions
– Energy-saving techniques can relevantly increase battery lifetimegy g q y y when using high-consumption and low-cost wireless interfaces
– Session invitation delays introduced by the IHMAS facility for power management are compatible even with strict VoIP reqs
p 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 client
Extensive 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 contacts and contacts and contacts and contacts
P t t d htt //li d i ib it/
Prototype code: http://lia.deis.unibo.it/
Research/IHMAS
