Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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
IMS-based components
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
Inter-domain PS scenario
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
IMS-based components
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
IMS-based components
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
Data Flow Rebind and Adaptation
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
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
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
Data Flow Rebind and Adaptation
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
IMS-based components
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
Implementation DetailsImplementation Details
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
Inter-domain PS scenario
PUBLISH (e.g.:”I’m online”)
NOTIFYNOTIFY
NOTIFY
NOTIFY
IMS-based components
Problem: high number of inter-domain PS messages
IHMAS PS scalability optimizationsIHMAS PS scalability optimizations
Bologna — 18.05.2009 41/57
IHMAS PS scalability optimizationsIHMAS PS scalability optimizations
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
OptimizationsOptimizations
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
OptimizationsOptimizations
towardstowards
scalabilityscalability:: batchedbatched
NOTIFYNOTIFY
“One single Watcher subscribed for multiple Presentities”
Bologna — 18.05.2009 45/57
OptimizationsOptimizations
towardstowards
scalabilityscalability:: batchedbatched
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
OptimizationsOptimizations
towardstowards
scalabilityscalability:: batchedbatched
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
Implementation DetailsImplementation Details
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
15 CPS 25 CPS 45 CPS 65 CPS 70 CPS5 CPS 90 CPS80 CPS10 CPS 20 CPS 35 CPS 55 CPS
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
15 CPS 25 CPS 45 CPS 65 CPS 70 CPS5 CPS 90 CPS80 CPS10 CPS 20 CPS 35 CPS 55 CPS
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
15 CPS 25 CPS 45 CPS 65 CPS 70 CPS5 CPS 90 CPS80 CPS10 CPS 20 CPS 35 CPS 55 CPS
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
15 CPS 25 CPS 45 CPS 65 CPS 70 CPS5 CPS 80 CPS10 CPS 20 CPS 35 CPS 55 CPS 90 CPS
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
15 CPS 25 CPS 45 CPS 65 CPS 70 CPS5 CPS 80 CPS10 CPS 20 CPS 35 CPS 55 CPS 90 CPS
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
15 CPS 25 CPS 45 CPS 65 CPS 70 CPS5 CPS 80 CPS10 CPS 20 CPS 35 CPS 55 CPS 90 CPS
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!