IMS-based Middleware Solutions for Advanced Management …Bologna — 18.05.2009 8/57 Mobile multimedia services requirements – Ubiquitous service provisioning – Continuous data

IMSIMS--based Middleware Solutions for based Middleware Solutions for Advanced Management ofAdvanced Management of Mobile Multimedia ServicesMobile Multimedia Services

Luca Foschini

May 18th, DEIS, University of Bologna

DEIS, University of Bologna, [email protected]

Bologna — 18.05.2009 2/57

AgendaAgenda

Multimedia service delivery for the wireless InternetMiddleware for IMS-based mobile multimedia services– Context-aware management operations: handoff, content

adaptation, power management, …– Scalability issues: distributed Presence Service

deployments, IMS application server interposition,…Technical details and experimental evaluation (for each of above areas)

Conclusions and other ongoing research efforts

Bologna — 18.05.2009 3/57

Hotspot Wi-Fi Hotspot Wi-Fi

Internet

IMS (IP Multimedia Subsystem)

New protocols and active proxy-based infrastructures for session management

3G cellular

4G Converged 4G Converged Mobile Multimedia ScenarioMobile Multimedia Scenario

Bologna — 18.05.2009 4/57

Scenarios in the (wireless Scenarios in the (wireless ☺☺) Internet:) Internet: multimedia services handoff managementmultimedia services handoff management

WLAN

Bluetooth GPRS

Internet

IMS-based components

Bologna — 18.05.2009 5/57

UMTS


WLAN

UserA

UserB

Call to UserB

Call to UserB

Internet

Scenarios in the Scenarios in the (wireless (wireless ☺☺) Internet:) Internet: multimedia services power managementmultimedia services power management

Bologna — 18.05.2009 6/57

IMS

DOMINIO P DOMINIO W

PS

IMS

PS

WN

W2

W1P1

P2

PN

SUBSCRIBE(to P2@dominioP)

SUBSCRIBE

SUBSCRIBE

SUBSCRIBE

(to P2@dominioP)

(to P2@dominioP)

Inter-domain PS scenario

Scenarios in the Scenarios in the (wireless (wireless ☺☺) Internet:) Internet: interinter--domain presence servicedomain presence service

P: presentity PS: Presence ServerW: watcher

Bologna — 18.05.2009 7/57

IMS

DOMINIO P DOMINIO W

PS

IMS

PS

WN

W2

W1P1

P2

PN


Scenarios in the Scenarios in the (wireless (wireless ☺☺) Internet:) Internet: interinter--domain presence service scalabilitydomain presence service scalability

PUBLISH (e.g.:”I’m online”)

NOTIFYNOTIFY

NOTIFY

NOTIFY


Problem: high number of inter-domain PS messages

Bologna — 18.05.2009 8/57

Mobile multimedia services requirements– Ubiquitous service provisioning– Continuous data flow delivery service continuity

(applications must specify Service Level Agreements, SLAs)

– Adaptive service distribution (different clients, supported formats, user preferences, …)

Wireless Internet (WI) challenges– Unpredictable user mobility: location, wireless technology, and Access

Point (AP) change handoff– High variety of wireless access technologies

Bluetooth (BT), IEEE 802.11a/b/g (Wi-Fi), UMTS, …Different static and dynamic properties

– Scalability issuesContext-aware service management and personalization require to share and disseminate a huge amount of (client-side generated) informationApplication-layer solutions (IMS) are more flexible ☺, but more costly

Mobile multimedia servicesMobile multimedia services in the wireless Internetin the wireless Internet

Bologna — 18.05.2009 9/57

LowerLower--layer mobile multimedialayer mobile multimedia management approaches management approaches

Several ad hoc solutions at low OSI stack layers– Data-link layer

Protocol enhancements, e.g., to reduce energy consumptionSeveral ongoing efforts to increase bandwidth and enable mobility emerging standards: WiMax, Long Term Evolutions (LTE), …

– Network layerMobility management

– Data-link triggers/events to reduce handoff latency– Standardization efforts IEEE 802.21 Media Independent Handover –

MIHHandoff management

– (Mobile IP and its optimizations)– Buffering and multicast techniques to reduce data losses

– Transport layerContent adaptation: end-to-end bandwidth monitoring/probing to possibly adapt content delivery (but tight application-transport layer coupling)

Efficient, but not very flexible and context-aware

Bologna — 18.05.2009 10/57

ApplicationApplication--layer mobile multimedialayer mobile multimedia management approachesmanagement approaches

Few proposals at the application layer– Ad-hoc solutions (non-standard and difficult to deploy in

real environments)Buffering and multicast to reduce packet lossPower management to lower energy consumption at client devicesContent tailoring to adapt multimedia flow provisioning

– Unable to exploit potential application-level visibility: often mimic network layer approaches

– IMS-based (also SIP-based) solutions are starting to be recognized as an important evolution direction

Call and session control infrastructures for next generation 4G networksActive session control paths proxy session control entitiesSupport services IMS Presence Service (IMS PS)

BUT… IMS scalability issues not tackled yet

Bologna — 18.05.2009 11/57

IMS IMS ––

IP Multimedia SubsystemIP Multimedia Subsystem

Visited network 1

P-CSCF

Home Network 1 Home Network 2

Visited network 2

P-CSCF

AS AS

S-CSCF S-CSCF

I-CSCF I-CSCFHSS HSS

MobileNode (MN)

Corresp. Node (CN)

Proxy-based architectureworking at OSI session layer

Common set of functions to ease multimedia service deployment

in highly heterogeneous wireless computing environments

SIP

DATA FLOW

Signaling Functions

Application Servers (ASs) Signaling Functions/Entities for

IMS Signaling Extension/Integration

Authentication Functions

Bologna — 18.05.2009 12/57

PS

P1

P2

WN

SUBSCRIBE

SUBSCRIBE

W2

W1

Watchers

PN

PresenceServerPresentities

Presence service (PS) permits users and hw/sw components, called presentities (Pi ), to convey their ability and willingness to communicate with subscribed watchers (Wj ).

IMS standardizes PS as a specific AS IMS PS

NOTIFY

NOTIFY

PUBLISH IMS

IMS PS IMS PS ––

IMS IMS PresencePresence

Server Server

Bologna — 18.05.2009 13/57

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 paths– Dynamic session signaling and re-direction (for handoff

management, power management, and service optimization)

IMS-compliant solutions– Session management entities realized as a novel IMS AS– AS performs specific management operations

Application-level approach– Seamless integration

with existing services (e.g. IMS PS to deliver

context updates about mobile node)

Bologna — 18.05.2009 14/57

IHMAS handoff managementIHMAS handoff management

WLAN

Bluetooth GPRS

Internet


Bologna — 18.05.2009 15/57

Vertical handoff in Vertical handoff in wireless networkswireless networks

Handoff types– Horizontal within the same infrastructure (BT BT)– Vertical

between different infrastructures

(BT Wi-Fi)

Long and highly variable handoff latencies relevant packet lossesCollected vertical hard handoff latency (data-link layer)

Vertical Handoff: Target Card Model Handoff Latency:Mean ± St. Dev. (s)

BT Wi-Fi High Converage Low CoverageIntel Wi-Fi 0,384 ± 0,072 0,971 ± 0,163

Orinoco Wi-Fi 0,487 ± 0,064 0,584 ± 0,067Wi-Fi BT High Converage Low CoverageMopogo

BT 1,553 ± 0,250 3,633 ± 0,438Asus BT 1,765 ± 0,239 3,734 ± 0,651

Bologna — 18.05.2009 16/57

Wi-Fi conn. Loss

IMS Vertical Handoff Protocol:IMS Vertical Handoff Protocol: Open IssuesOpen Issues

MN P-CSCFMN CNS-CSCFMN

Data flow

DatalinkHandoff &DHCP req.

(1) REGISTER

(5) INVITE(6) INVITE (7) INVITE

(9) 200 OK

Data Flow Rebind and Adaptation

(10) 200 OK(11) 200 OK

Med

ia L

oss

Data flow

Registration Phase

Ren

egot

iatio

n P

hase(8)

(4) 200 OK

(2) 401 Unauth.

(3) REGISTER

Main Problems– Reactive and

sequential handoff execution approach

– Prone to long delays and media losses

May degrade any service, but especially multimedia

services (with guaranteed arrival rate requirements for the

whole session)

BT re-conn.

Bologna — 18.05.2009 17/57

Context-aware handoff management middleware– extracts

and monitors low level parameters (Received

Signal Strength Indicator, inter-arrival packet delay, …)

vertical handoff prediction– executes

application-level specific

session signaling actions multimedia flow tailoring operations

dynamic content adaptation– integrates seamlessly with existing infrastructures

full compliancy with IMS standard

IHMAS Handoff Management IHMAS Handoff Management

Bologna — 18.05.2009 18/57

Vertical Handoff Predictor – VHP (one for client): RSSI filtering and handoff predictionAS for Service Continuity – ASSC (one for IMS domain): realizes vertical handoff protocol enhancements Adaptation Media Gateway – AMG (one for access locality): content adaptation

IHMAS Vertical Handoff Facility: IHMAS Vertical Handoff Facility: Distributed ArchitectureDistributed Architecture

MN

IMS Client

VHP IMS-compliant

SIP Signalling

Data Tx/Rx

and Playout New

AS Node

ASSC

IMS

CN

IMS Client

IMS-compliant

SIP Signalling

Data Tx/Rx

and Playout

Media

Gateway

AMGDATA

DATAOld

SIP SIP

3.

<<controls>>

MN HomeDomain

MN Visited Wireless Access Domain

CN Domain

Proa

ctiv

eSe

ssio

nSi

gnal

ling

1. 2.

Data Tx/Rx

and Playout

Old

DATANew4.

Dat

a H

ando

off

Man

agem

ent

Bologna — 18.05.2009 19/57

Several mobility prediction solutions have been investigated (ad-hoc positioning/velocity detection, history&profile, …)

Main guideline: exploit client-side Received Signal Strength Indication (RSSI) monitoring and a simple Grey model to predict future RSSI values based on a very limited number (10) of past samples for each wireless AP more details

Specific characteristics/requirements of our mobility prediction solution:

- Wireless Internet-oriented - Coarse-grained cell precision- Non-GPS-based - Lightweight- Application-level & portable - Completely decentralized

Implementation Insights:Implementation Insights: Vertical Handoff PredictorVertical Handoff Predictor

Bologna — 18.05.2009 20/57

Implementation Insights:Implementation Insights: AS for Service ContinuityAS for Service Continuity

MN AMG CNASSC

Datalink Handoff &DHCP req.

(1) REGISTER

(8) INVITE

Handoff Prediction

OldAP NewAP

Reg

istra

tion

Phas

e

(7) 200 OK

(2) 401 Unauth.

(3) REGISTER

S-CSCFMN

ULAWULAWULAW

(4) REGISTER(5) Trying(6) 200 OK

(9) 200 OK

(10) INVITE

(11) Trying

(12) 200 OK


Ren

egot

iatio

n Ph

ase

ULAWULAW

ULAWGSMGSM

Med

ia

Loss

New Data Tx/Rx Component Creation

IHMAS original message flow extensionsIMS standard messagesData flow

1. VHP prediction proactively triggers handoff execution before IMS client detaches from old AP

2. (re-)REGISTER and (re-)INVITE signaling proceed over new AP (while data continue to flow over old wireless interface)

3. ASSC interacts with AMG to control data flow adaptation and rebind

Reduced media

losses!!

Bologna — 18.05.2009 21/57

Implementation Insights:Implementation Insights: Adaptation Media GatewayAdaptation Media Gateway

AMG implementation is based on Asterisk Asterisk can use several session control protocols (SIP, H.363, MGCP, …)

ASSC-to-AMG communicationsbased on SIP

– Widely diffusion– Ease of integration

INVITE sip:[email protected]:5070 SIP/2.0 Record-Route: <sip:[email protected]:6060;lr>, <sip:[email protected]:4060;lr> Call-ID: [email protected] From: "bob" <sip:[email protected]>;tag=7762566 To: <sip:[email protected]> … Content-Type: application/sdp CSeq: 300 INVITE Content-Length: 132 v=0 [email protected] 0 0 IN IP4 10.0.1.4 s= - c=IN IP4 10.0.1.4 t=0 0 m=audio 22224 RTP/AVP 3 b=AS:25 a=rtpmap:3 GSM/8000

[internal] exten => bob,1,Dial(SIP/bob,60) … [general] context=default … disallow=all allow=gsm allow=ulaw canreinvite=no [bob] … canreinvite=no context=internal

exte

nsio

ns.c

onf

sip.

conf

Asterisk configuration– extensions.conf: AMG serves

any new call with “bob” extension by using SIP for session control

– sip.conf: AMG allows gsm and ulaw audio encodings and canreinvite directive forces AMG to act as adaptation media gateway

re-IN

VIT

E m

essa

geA

ster

isk

conf

igur

atio

n

SDP description

Bologna — 18.05.2009 22/57

Implementation DetailsImplementation Details

IMS core components– OpenIMSCore (Fokus)– initial Filter Criteria (iFC) for IMS message re-routing

AMG– Asterisk telephony engine– High quality: ULAW/RTP audio, 50 frames/s, 64Kbps– Low quality: GSM/RTP audio, 50 frames/s, 13,2 Kbps

ASSC– Java NIST JainSIP implementation of the SIP stack– OpenIMSCore properly configured to ASSC in the signaling path

IMS client– VHP: iwconfig and hcitool (Linux), NDIS (WIN)– VHP integration with IMS Communicator

Deployment environment– Client: Asus laptops with IEEE 802.11b Cisco card and a Mopogo BT doungle– P-/I-/S-CSCF run on PCs: 2 CPUs 1,80GHz, 2048MB RAM, Linux Ubuntu– Wireless infrastructures:

Wi-Fi: Cisco Aironet 1100 APBT: Mopogo BT doungle, class 1, version 1.1

ASSC

Bologna — 18.05.2009 23/57

Experimental TestbedExperimental Testbed

IMS core infrastructure

IMS core infrastructure

WLAN

Bluetooth

DATAFLOWULAW

DATAFLOWULAW

DATAFLOWAMG

ASSC

REGISTER

RE-INVITE

GSM

Handoff delay: data loss period durationObjective measurements: audio waves collected at MNSubjective measurements: ITU Multiple Stimuli with Hidden Reference and Anchor (MUSHRA); different listening sessions submitted to 10 non-expert humanoperators by using the RateIt program

Bologna — 18.05.2009 24/57

Experimental Results (1)Experimental Results (1)

Wi-Fi conn. Loss

MN P-CSCFMN CNS-CSCFMN

Data flow

DatalinkHandoff &DHCP req.

(1) REGISTER

(5) INVITE(6) INVITE (7) INVITE

(9) 200 OK


(10) 200 OK(11) 200 OK

Med

ia L

oss

Data flow

Registration Phase

Ren

egot

iatio

n P

hase(8)

(4) 200 OK

(2) 401 Unauth.

(3) REGISTER

BT re-conn.

2230

ms

MN AMG CNASSC

Datalink Handoff &DHCP req.

(1) REGISTER

(8) INVITE

Handoff Prediction

OldAP NewAP

Reg

istra

tion

Phas

e

(7) 200 OK

(2) 401 Unauth.

(3) REGISTER

S-CSCFMN

ULAWULAWULAW

(4) REGISTER(5) Trying(6) 200 OK

(9) 200 OK

(10) INVITE

(11) Trying

(12) 200 OK


Ren

egot

iatio

n Ph

ase

ULAWULAW

ULAWGSMGSM

Med

ia

Loss

New Data Tx/Rx Component Creation

220

ms

Bologna — 18.05.2009 25/57

Experimental Results (2)Experimental Results (2)

Wi-Fi, ULAW: 75.3/100good

Bluetooth, ULAW, w/o background traffic: 72.3/100

good

Bluetooth, GSM, with background traffic: 64.3/100

good

Objective evaluation (received audio waves)

∞-

∞-

∞-

∞-

s0 1 2 3 4 65

(d)

- 6

- 6

- 6

- 6

- 6

- 6

- 6

- 6

(b)

(a)

(c)

dB

Bluetooth, ULAW, with background traffic: 5.4/100

bad

Subjective evaluation (Misra score [0, 100])

Bologna — 18.05.2009 26/57

Conclusions – Suitability of application-level approach to extend the

standard IMS infrastructure for session continuity– Dynamic content adaptation techniques permit to grant

high user satisfaction even in the challenging case of vertical handoff

Ongoing work– Additional objective measures of quality degradations

experienced w/out multimedia adaptation at AMG– Design and deployment of other forms of proactive

handoff management, and ASSC scalability assessment

IHMAS Handoff Management:IHMAS Handoff Management: Conclusions and ongoing workConclusions and ongoing work

Bologna — 18.05.2009 27/57

UMTS


WLAN

UserA

UserB

Call to UserB

Call to UserB

Internet

IHMAS Power ManagementIHMAS Power Management

Bologna — 18.05.2009 28/57

IHMAS Power Management IHMAS Power Management

Context-aware power management middleware– updates low level parameters (wireless communications

availability, battery level, …)

wireless access prediction and mobile node energy monitoring

– executes

application-level specific energy-saving decisions and session signaling actions

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

– integrates seamlessly with existing infrastructuresfull compliancy with IMS standard

Bologna — 18.05.2009 29/57

Context Monitor – CM (one for client): implements lightweight and completely decentralized context monitoring via local access to client wireless devicesAS for Power Management – ASPM (one for IMS domain): realizes our IMS energy-saving optimizationIMS PS – PS (one for access locality): facilitates CM-ASPM interactions

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

MNIMS Client

CM

Data Tx/Rx

and Playout

IMS

CNIMS Client

IMS-compliant

SIP Signalling

Data Tx/Rx

and Playout

Low-consumption wireless interface

MN Visited Wireless Access Domain

CN Domain

Pow

er-S

avin

g Se

ssio

n Si

gnal

ing

1.2. <<publishes>>

Dat

a Tr

ansp

ort

MN Home Domain

AS NodeASPMPS

IMS-compliant

SIP Signalling

3. <<notifies>>

4.5.

High-consumption wireless interface

6.

7.DATA

Bologna — 18.05.2009 30/57

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

IHMAS original message flow extensionsIMS standard messages

1. CM proactively notifies context changes over the always-on interface

2. ASPM intercepts INVITE from Correspondent Node (CN) and activates wireless interface switch-on at Mobile Node (MN)

3. MN re-REGISTERs over switched-on interface, and ASPM re-directs CN by using a MOVED message

CN (I-)S-CSCFMN

(13) INVITE

Con

text

Cha

nge

Not

ifica

tion

PSMN ASPM MN

(3) OK

(1) SUBSCRIBE(2) SUBSCRIBE

(4) OK(5) PUBLISH

context change(6) PUBLISH

(7) OK(8) OK

(9) NOTIFY(10) NOTIFY context change

(11) OK(12) OK

Always-on interface

Switched- on interface

(14) INVITE (15) new-INVITE

Interface rebind

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

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

(21) REGISTER

Dyn

amic

sw

itch

on a

nd c

all

redi

rect

ion

(16) 100 Trying wait MN re-REGISTER

(23) 401 Unauth.

(29) 302 MOVED(30)

302 MOVED(31) INVITE (32) INVITE

send MOVED

CM: context changed

(22) REGISTER(24) 401 Unauth.

(25) REGISTER

(27) OK(26) REGISTER

(28) OK

Bologna — 18.05.2009 31/57

Content-Type: application/sdp Content-Length: 414 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 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 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: AS for Power ManagementAS for Power Management

ASPM implementation is based on JAIN SIP stackOn INVITE message, ASPM:

1. Extracts Session Description Protocol (SDP) part of the message

2. Adds in the optional field (“a:” field) the MAC of the wireless interface to switch on

3. Sends it to MN

Modified INVITE message– SDP part of the INVITE message as

modified by ASPM– Note our

application

parameter

a:… field at the end of the message

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

sd=addPowerManagementAttribute(request, sd); request.removeContent(); try { request.setContent(sd, headerFactory. createContentTypeHeader("application","sdp")); } catch (ParseException e) { e.printStackTrace(); } try { sipProvider.sendRequest(request); } catch (SipException e) { e.printStackTrace(); } }

INVITE sip:[email protected] SIP/2.0 …

1.

2.

3.

Bologna — 18.05.2009 32/57

Implementation Insights:Implementation Insights: IMS Client IMS Client

Based on UCT IMS ClientNew-INVITE processing

– Extracts from the “a:…” field the MAC of the wireless interface to switch on

– Sends de-REGISTER

void ims_process_incoming_invite(eXosip_event *je) { … sdp_message_t * sdp_message; eXosip_lock(); sdp_message=eXosip_get_sdp_info(je->request); eXosip_unlock(); switchOnAddress=extractPowerManAttribute(sdp_message);

if(newInvite) ims_send_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 ); } else { execl("../scripts/switchOffInterface.sh", "switchOffInterface.sh", switchOnAddress, (char *)0 ); } } else { // parent wait(&status); if(!is_bye) { while( eXosip_listen_addr(IPPROTO_UDP, switchOnAddress, port, AF_INET, 0) != 0 ) port++; } else { while( eXosip_listen_addr(IPPROTO_UDP, alwaysOnAddress, port, AF_INET, 0) != 0 ) port++; } ims_send_register(); }

Re-registration– Switches on the

wireless interface– Sends a REGISTER

over the switched-on wireless interface

Bologna — 18.05.2009 33/57


IMS core components– OpenIMSCore (Fokus)– initial Filter Criteria (iFC) for IMS message re-routing

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

signaling path

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

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

ASPM

Bologna — 18.05.2009 34/57

IMS Core Infrastructure

IMS Core Infrastructure

UCT IMS Client (Bob)

ASPM

INVITE

INV

ITE

NE

W_IN

VITE

NEW_INVITE

Bob sends the INVITE request intercepted and modified by ASPM

Adds the our power saving “a:” field

De-REGISTER

UMTS

WLAN

REGISTER

302-Moved

Temporarily

302 Moved Temporarily

INVITE

INVITE

• Alice switches on the WLAN interface and re- registers• ASPM sends to Bob a 302 Moved Temporarily to re-direct the session toward switched-on interface

RE

GIS

TER

Experimental testbedExperimental testbed

UCT IMS Client (Alice)

Bologna — 18.05.2009 35/57

CN (I-)S-CSCFMN

(1) INVITE

PSMN ASPM MN

(2) INVITE (3) new-INVITE

Interface rebind

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

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

(17) 302 MOVED(18) 302 MOVED

(19) INVITE (20) INVITE

(4) 100 Tryingwait MN

re-REGISTER

(11) 401 Unauth.(10) REGISTER

(12) 401 Unauth.(13) REGISTER

(15) OK(14) REGISTER

(16) OK

(9) REGISTER

send MOVED

T 0T 1

T 2T 3

CN (I-)S-CSCFMN

(1) INVITE(1) INVITE

PSMN ASPM MN

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

Interface rebind

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

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

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

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

(4) 100 Tryingwait MN

re-REGISTER

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

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

(15) OK(15) OK(14) REGISTER(14) REGISTER

(16) OK(16) OK

(9) REGISTER(9) REGISTER

send MOVED

T 0T 1

T 2T 3

Experimental Results (1)Experimental Results (1)28

5 m

s57

0 m

s82

5 m

s93

ms

sum

< 3

s

Bologna — 18.05.2009 36/57

Experimental Results (2):Experimental Results (2): StandStand--by timeby time

0

50

100

150

200

250

stand-by UMTS stand-by UMTS, IMS-based registration

stand-by WiFi, IMS-based registration

Hou

rs

Analitical results evaluated for N95– Battery: 950mAH and charged at 3.7V– WiFi avarage additional consumption (always-on): 0.05W

W/o power

management

Bologna — 18.05.2009 37/57

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

0

50

100

150

200

250

300

UMTS call time Energy-efficient WiFi call time

Min

utes

Energy-efficient WiFi call time is longer than the talk time duration specified by Nokia for UMTS.

With power

management

Bologna — 18.05.2009 38/57

IHMAS Power Management:IHMAS Power Management: Conclusions and ongoing workConclusions and ongoing work

Conclusions – Energy-saving techniques relevantly increase battery

lifetime 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 call requirements

Ongoing work– J2ME version of CM and IMS client, tailored to any

consumer device hosting a J2ME platform– Extensive measurements of energy consumption in real

and wide-scale deployment environment

Bologna — 18.05.2009 39/57

IMS

DOMINIO P DOMINIO W

PS

IMS

PS

WN

W2

W1P1

P2

PN

SUBSCRIBE(to P2@dominioP)

SUBSCRIBE

SUBSCRIBE

SUBSCRIBE

(to P2@dominioP)

(to P2@dominioP)

Inter-domain PS scenarioP: presentity PS: Presence ServerW: watcher

IHMAS PS scalability optimizationsIHMAS PS scalability optimizations

Bologna — 18.05.2009 40/57

IMS

DOMINIO P DOMINIO W

PS

IMS

PS

WN

W2

W1P1

P2

PN


PUBLISH (e.g.:”I’m online”)

NOTIFYNOTIFY

NOTIFY

NOTIFY


Problem: high number of inter-domain PS messages


Bologna — 18.05.2009 41/57


IHMAS IMS-based PS solution– extends IMS PS to support inter-domain PS optimizations

(diminuish the number of inter-domain NOTIFY transmissions)

novel PS inter-domain optimization module for NOTIFY message parsing and inter-domain routing

– supports mobile clients and service differentiation (gold, silver, copper, …)

local PS message buffering at mobile device and differentiated service management at PS

– integrates seamlessly with existing infrastructuresfull compliancy with IMS standard

Bologna — 18.05.2009 42/57

OptimizationsOptimizations

towardstowards

scalabilityscalability:: common NOTIFYcommon NOTIFY

IMS

PS

IMS

PS

WN

SUBSCRIBE

SUBSCRIBE

SUBSCRIBE

(to P2@dominioP)

W2

W1

(to P2@dominioP)

(to P2@dominioP)SUBSCRIBE

P2

“Several Watchers subscribed to one Presentity”

Bologna — 18.05.2009 43/57

IMS

PS

IMS

PS

WN

NOTIFY

NOTIFY

NOTIFY

W2

W1

P2

PUBLISH

NOTIFY +

Consolidates NOTIFY messages

at Presentity’sdomain

1 only inter- domain NOTIFY message

NOTIFY messages creation at

Watchers’s domain

Watchers’ list


towardstowards

scalabilityscalability:: common NOTIFY (2)common NOTIFY (2)

Bologna — 18.05.2009 44/57

IMS

PS

IMS

PS SUBSCRIBE(to P1@dominioP,

P2@dominioP,PN@dominioP)

W2

SUBSCRIBE

P2

PN

P1


towardstowards

scalabilityscalability:: batchedbatched

NOTIFYNOTIFY

“One single Watcher subscribed for multiple Presentities”

Bologna — 18.05.2009 45/57


towardstowards


NOTIFY (2)NOTIFY (2)

Time-based (periodic) NOTIFY message batching

IMS

PS

IMS

PSW2

P2

PN

P1

PUBLISH

PUBLISH

PUBLISH

NOTIFYNOTIFY

NOTIFY

Bologna — 18.05.2009 46/57


towardstowards


NOTIFY (3)NOTIFY (3)

IMS

PS

IMS

PSW2

P2

PN

P1

PUBLISH

PUBLISH

PUBLISH

NOTIFY

NOTIFYNOTIFY

NOTIFY

1 only inter-domain NOTIFY message

NOTIFY

Bologna — 18.05.2009 47/57

WA.4 WA.1 P-/S-CSCFA IOMA + PSAWA.3 I-/S-CSCFB IOMB + PSB PB.1 PB.4

DomainA DomainB

(1) SUBSCRIBE (2) SUBSCRIBE (3) SUBSCRIBE (4) SUBSCRIBE

(5) 200 OK(6) 200 OK(7) 200 OK(8) 200 OK (9) PUBLISH(10) OK

SUBSCRIBEfrom other watchers

(11’) Common NOTIFY(one per presentity)

PB.4

PUBLISHfrom other presentities

(11) NOTIFYGol

dC

lient

s

(13’) NOTIFY msgs

(12) NOTIFY

(14’) NOTIFY

(13) OK (14) OK

(12’) OK

(15’) OK msgs (16’) OK

(11’’) Batched NOTIFY(one per watcher)

(13’’) aggregated NOTIFY(14’’) NOTIFY

(12’’) OK

(15’’) OK msgs (16’’) OK

Silv

erC

lient

sC

oppe

rC

lient

s

PrioritizedNOTIFY schedule

Watchers Authorization andNOTIFY construction

Watcher Authorization, NOTIFY aggregation, NOTIFY construction

WA.4WA.4 WA.1WA.1 P-/S-CSCFAP-/S-CSCFA IOMA + PSAIOMA + PSAWA.3WA.3 I-/S-CSCFBI-/S-CSCFB IOMB + PSBIOMB + PSB PB.1PB.1 PB.4PB.4

DomainA DomainB

(1) SUBSCRIBE (2) SUBSCRIBE (3) SUBSCRIBE (4) SUBSCRIBE

(5) 200 OK(5) 200 OK(6) 200 OK(6) 200 OK(7) 200 OK(7) 200 OK(8) 200 OK(8) 200 OK (9) PUBLISH(9) PUBLISH(10) OK(10) OK

SUBSCRIBEfrom other watchers

(11’) Common NOTIFY(one per presentity)

PB.4PB.4

PUBLISHfrom other presentities

(11) NOTIFYGol

dC

lient

s

(13’) NOTIFY msgs

(12) NOTIFY

(14’) NOTIFY

(13) OK(13) OK (14) OK(14) OK

(12’) OK(12’) OK

(15’) OK msgs(15’) OK msgs (16’) OK(16’) OK

(11’’) Batched NOTIFY(one per watcher)

(13’’) aggregated NOTIFY(14’’) NOTIFY

(12’’) OK(12’’) OK

(15’’) OK msgs(15’’) OK msgs (16’’) OK(16’’) OK

Silv

erC

lient

sC

oppe

rC

lient

s

PrioritizedNOTIFY schedule

Watchers Authorization andNOTIFY construction

Watcher Authorization, NOTIFY aggregation, NOTIFY construction

IHMAS PS scalability:IHMAS PS scalability: PS protocol enhancementsPS protocol enhancements

Bologna — 18.05.2009 48/57

Open IMS Core

IMS Bench SIPp

• IMS infrastructure

• Presence Server

• SIP traffic generation

OpenSER


Bologna — 18.05.2009 49/57

I-CSCF

P-CSCF

IMS BenchManager

SIPpclient

SIPcalls

configuration andresult gathering

PresenceServer

(OpenSER)

S-CSCF

SIPcalls

SIPpclient

open-ims1.test open-ims2.test

PresenceServer

(OpenSER)Open IMS Core Open IMS Core

P-CSCF

Linux Boxes2CPU 1,8 GHz2048MB di RAM

Experimental testbedExperimental testbed

Bologna — 18.05.2009 50/57

0

5

10

15

20

25

8 20 33 46 58 71 84 96

109

122

135

147

160

173

186

198

211

224

237

250

263

276

289

302

315

328

341

354

10 CPS5 CPS 15 CPS 20 CPS 25 CPS 35 CPS 45 CPS 55 CPS 65 CPS 70 CPS 80 CPS 90 CPS

0

5

10

15

20

25

8 20 33 46 58 71 84 96

109

122

135

147

160

173

186

198

211

224

237

250

263

276

289

302

315

328

341

354

10 CPS5 CPS 15 CPS 20 CPS 25 CPS 35 CPS 45 CPS 55 CPS 65 CPS 70 CPS 80 CPS 90 CPS

02550

75100125150

175200225

8 20 33 46 58 71 84 96 109

122

135

147

160

173

186

198

211

224

237

250

263

276

289

302

315

328

341

354

15 CPS 25 CPS 45 CPS 65 CPS 70 CPS5 CPS 90 CPS80 CPS10 CPS 20 CPS 35 CPS 55 CPS

6.6 w/p 8.6 w/p 10.9 w/p 14.6 w/p

sec

CPU

%M

EMO

RY

%

sec

Experimental results:Experimental results: w/out IHMAS optimizationsw/out IHMAS optimizations

Bologna — 18.05.2009 51/57

0

10

20

30

40

50

60

70

80

90

8 21 34 46 59 72 84 97 110

122

135

148

160

173

186

198

211

224

237

249

262

275

287

300

313

325

338

351


0

10

20

30

40

50

60

70

80

90

8 21 34 46 59 72 84 97 110

122

135

148

160

173

186

198

211

224

237

249

262

275

287

300

313

325

338

351


0

2

4

6

8

10

12

14

8 21 34 46 59 72 84 97 110

122

135

148

160

173

186

198

211

224

237

249

262

275

287

300

313

325

338

351


Experimental results:Experimental results: with IHMAS common NOTIFYwith IHMAS common NOTIFY

6.6 w/p 8.6 w/p 10.9 w/p 14.6 w/p

sec

CPU

%M

EMO

RY

%

sec

Bologna — 18.05.2009 52/57

0

10

20

30

40

50

60

70

6 18 31 44 56 69 82 95 107

120

133

145

158

171

183

196

209

222

234

247

260

273

285

298

311

323

336

349

15 CPS 25 CPS 45 CPS 65 CPS 70 CPS5 CPS 80 CPS10 CPS 20 CPS 35 CPS 55 CPS 90 CPS

0

10

20

30

40

50

60

70

6 18 31 44 56 69 82 95 107

120

133

145

158

171

183

196

209

222

234

247

260

273

285

298

311

323

336

349


0

1

2

3

4

5

6

7

8

6 18 31 44 56 69 82 95

107

120

133

145

158

171

183

196

209

222

234

247

260

273

285

298

311

323

336

349


0

1

2

3

4

5

6

7

8

6 18 31 44 56 69 82 95

107

120

133

145

158

171

183

196

209

222

234

247

260

273

285

298

311

323

336

349


Experimental results:Experimental results: with IHMAS batched NOTIFYwith IHMAS batched NOTIFY

6.6 w/p 8.6 w/p 10.9 w/p 14.6 w/p

sec

CPU

%M

EMO

RY

%

sec

Bologna — 18.05.2009 53/57

0

50000

100000

150000

200000

250000

6.6 8.6 10.9 14.6 w/p

# NO

TIFY

mes

sage

s

w/o PS enhancements w/ Common NOTIFY w/ Batched NOTIFY

Experimental results:Experimental results: number internumber inter--domain NOTIFY transmissionsdomain NOTIFY transmissions

Bologna — 18.05.2009 54/57

Experimental results:Experimental results: interinter--domain NOTIFY delaydomain NOTIFY delay

0

20

40

60

80

100

120

140

6.6 8.6 10.9 14.6 w/p

ms

w/o service differentiation gold client silver client

Bologna — 18.05.2009 55/57

IHMAS Power Management:IHMAS Power Management: Conclusions and ongoing workConclusions and ongoing work

Conclusions – Good scalability of the proposed

enhancements– Full standard compliancy, necessary for wide

acceptance and use

Ongoing work– Extending the support to aggregate also

SUBSCRIBE message traffic– Intra-domain PS load-balancing solutions are

under develpment

Bologna — 18.05.2009 57/57

IHMAS project web site andIHMAS project web site and contactscontacts

Prototype code: http://lia.deis.unibo.it/Research/IHMAS

Contacts: Luca Foschini ([email protected])

Thanks for your attention!

Documents

IMS-based Middleware Solutions for Advanced Management …Bologna — 18.05.2009 8/57 Mobile multimedia services requirements – Ubiquitous service provisioning – Continuous data