IMS-based Middleware Solutions for Advanced Management of Mobile Multimedia Services

Transcription

1 IMS-based Middleware Solutions for Advanced Management of Mobile Multimedia Services Luca Foschini DEIS, University of Bologna, ITALY May 18 th, DEIS, University of Bologna

2 Agenda Multimedia service delivery for the wireless Internet Middleware 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 /57

3 New protocols and active proxy-based infrastructures for session management 4G Converged Mobile Multimedia Scenario IMS (IP Multimedia Subsystem) Internet 3G cellular Hotspot Wi-Fi Hotspot Wi-Fi Bologna /57

4 Scenarios in the (wireless ) ) Internet: multimedia services handoff management IMS-based components Internet Bluetooth GPRS WLAN Bologna /57

5 Scenarios in the (wireless ) ) Internet: multimedia services power management UserA IMS-based components Call to UserB Internet Call to UserB WLAN UserB UMTS Bologna /57

6 Scenarios in the (wireless ) ) Internet: inter-domain presence service P: presentity PS: Presence Server W: watcher Inter-domain PS scenario P1 DOMINIO P DOMINIO W SUBSCRIBE (to P2@dominioP) SUBSCRIBE W1 P2 IMS PS IMS PS W2 SUBSCRIBE (to P2@dominioP) PN SUBSCRIBE (to P2@dominioP) WN Bologna /57

7 Scenarios in the (wireless ) ) Internet: inter-domain presence service scalability Inter-domain PS scenario IMS-based components DOMINIO P DOMINIO W P1 NOTIFY NOTIFY W1 PUBLISH (e.g.: I m online ) IMS IMS NOTIFY P2 W2 PS PS NOTIFY PN Problem: high number of inter-domain PS messages WN Bologna /57

8 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 Mobile multimedia services in the wireless Internet Unpredictable user mobility: location, wireless technology, and Access Point (AP) change handoff High variety of wireless access technologies Bluetooth (BT), IEEE a/b/g (Wi-Fi), UMTS, Different static and dynamic properties Scalability issues Context-aware service management and personalization require to share and disseminate a huge amount of (client-side generated) information Application-layer solutions (IMS) are more flexible, but more costly Bologna /57

9 Lower-layer mobile multimedia management approaches Several ad hoc solutions at low OSI stack layers Data-link layer Protocol enhancements, e.g., to reduce energy consumption Several ongoing efforts to increase bandwidth and enable mobility emerging standards: WiMax, Long Term Evolutions (LTE), Network layer Mobility management Data-link triggers/events to reduce handoff latency Standardization efforts IEEE Media Independent Handover MIH Handoff management (Mobile IP and its optimizations) Buffering and multicast techniques to reduce data losses Transport layer Content 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 /57

10 Application-layer layer mobile multimedia management 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 loss Power management to lower energy consumption at client devices Content 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 networks Active session control paths proxy session control entities Support services IMS Presence Service (IMS PS) BUT IMS scalability issues not tackled yet Bologna /57

11 IMS IP Multimedia Subsystem Mobile Node (MN) DATA FLOW Application Servers (ASs) Signaling Functions/Entities for IMS Signaling Extension/Integration Corresp. Node (CN) AS Signaling Functions AS P-CSCF Visited network 1 S-CSCF Proxy-based architecture working at OSI session layer Authentication SIP Functions S-CSCF Common set of functions to ease multimedia service deployment in highly heterogeneous P-CSCF Visited network 2 I-CSCF I-CSCF wireless computing environments HSS HSS Home Network 1 Home Network 2 Bologna /57

12 IMS PS IMS Presence Server Presence service (PS) permits users and hw/sw components, called presentities (P i ), to convey their ability and willingness to communicate with subscribed watchers (W j ). IMS standardizes PS as a specific AS IMS PS P1 SUBSCRIBE NOTIFY W1 P2 PUBLISH IMS NOTIFY SUBSCRIBE PS W2 PN Presentities Presence Server WN Watchers Bologna /57

13 IHMAS 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 /57

14 IHMAS handoff management IMS-based components Internet Bluetooth GPRS WLAN Bologna /57

15 Handoff types Vertical handoff in wireless networks Horizontal within the same infrastructure (BT BT) Vertical between different infrastructures (BT Wi-Fi) Long and highly variable handoff latencies relevant packet losses Collected vertical hard handoff latency (data-link layer) Vertical Handoff: Target Card Model Handoff Latency: Mean ± St. Dev. (s) BT Wi-Fi High Converage Low Coverage Intel Wi-Fi 0,384 ± 0,072 0,971 ± 0,163 Orinoco Wi-Fi 0,487 ± 0,064 0,584 ± 0,067 Wi-Fi BT High Converage Low Coverage Mopogo BT 1,553 ± 0,250 3,633 ± 0,438 Asus BT 1,765 ± 0,239 3,734 ± 0,651 Bologna /57

16 Wi-Fi conn. Loss Media Loss MN P-CSCF MN S-CSCF MN CN Datalink Handoff & DHCP req. Data flow (1) REGISTER (3) REGISTER (5) INVITE Data flow BT re-conn. (11) 200 OK (6) INVITE IMS Vertical Handoff Protocol: Open Issues (2) 401 Unauth. (4) 200 OK (10) 200 OK Registration Phase (7) INVITE (8) Data Flow Rebind and Adaptation (9) 200 OK Renegotiation Phase 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) Bologna /57

17 IHMAS Handoff Management 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 Bologna /57

18 IHMAS Vertical Handoff Facility: Distributed Architecture MN Visited Wireless Access Domain VHP 1. IMS-compliant 2. SIP Signalling 3. <<controls>> SIP AS Node ASSC IMS MN Home Domain SIP IMS-compliant SIP Signalling Proactive Session Signalling Data Tx/Rx and Playout New Data Tx/Rx and Playout Old IMS Client MN DATANew 4. DATAOld AMG Media Gateway DATA Data Tx/Rx and Playout IMS Client CN CN Domain Data Handooff Management Vertical Handoff Predictor VHP (one for client): RSSI filtering and handoff prediction AS for Service Continuity ASSC (one for IMS domain): realizes vertical handoff protocol enhancements Adaptation Media Gateway AMG (one for access locality): content adaptation Bologna /57

19 Implementation Insights: Vertical Handoff Predictor Several mobility prediction solutions have been investigated (ad-hoc positioning/velocity detection, history&profile, ) Specific characteristics/requirements of our mobility prediction solution: - Wireless Internet-oriented - Coarse-grained cell precision - Non-GPS-based - Lightweight - Application-level & portable - Completely decentralized 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 Bologna /57

20 Implementation Insights: AS for Service Continuity Handoff Prediction Media Loss MN OldAP NewAP AMG S-CSCF MN ASSC CN ULAW ULAW ULAW Datalink Handoff & DHCP req. (1) REGISTER (3) REGISTER (8) INVITE New Data Tx/Rx Component Creation Reduced media losses!! GSM ULAW (2) 401 Unauth. Data Flow Rebind and Adaptation GSM (4) REGISTER (5) Trying (6) 200 OK (7) 200 OK (11) Trying (12) 200 OK (9) 200 OK (10) INVITE Registration Phase Renegotiatio n Phase ULAW ULAW IHMAS original message flow extensions IMS standard messages Data 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 Bologna /57

21 re-invite message INVITE SIP/2.0 Record-Route: Call-ID: From: "bob" To: Content-Type: application/sdp CSeq: 300 INVITE Content-Length: 132 v=0 0 0 IN IP s= - c=in IP t=0 0 m=audio RTP/AVP 3 b=as:25 a=rtpmap:3 GSM/8000 SDP description Implementation Insights: Adaptation Media Gateway AMG implementation is based on Asterisk Asterisk can use several session control protocols (SIP, H.363, MGCP, ) ASSC-to-AMG communications based on SIP Widely diffusion Ease of integration Asterisk configuration [internal] exten => bob,1,dial(sip/bob,60) [general] context=default disallow=all allow=gsm allow=ulaw canreinvite=no [bob] canreinvite=no context=internal sip.conf extensions.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 Bologna /57

22 ASSC Implementation Details IMS core components OpenIMSCore (Fokus) initial Filter Criteria (ifc) for IMS message re-routing ASSC AMG Java NIST JainSIP implementation of the SIP stack OpenIMSCore properly configured to ASSC in the signaling path Asterisk telephony engine High quality: ULAW/RTP audio, 50 frames/s, 64Kbps Low quality: GSM/RTP audio, 50 frames/s, 13,2 Kbps IMS client VHP: iwconfig and hcitool (Linux), NDIS (WIN) VHP integration with IMS Communicator Deployment environment Client: Asus laptops with IEEE b 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 AP BT: Mopogo BT doungle, class 1, version 1.1 Bologna /57

23 Experimental Testbed AMG DATAFLOW GSM Bluetooth DATAFLOW ULAW ASSC DATAFLOW ULAW RE-INVITE REGISTER IMS IMS core core infrastructure WLAN Handoff delay: data loss period duration Objective measurements: audio waves collected at MN Subjective measurements: ITU Multiple Stimuli with Hidden Reference and Anchor (MUSHRA); different listening sessions submitted to 10 non-expert human operators by using the RateIt program Bologna /57

24 Experimental Results (1) 2230 ms Wi-Fi conn. Loss Media Loss MN P-CSCF MN S-CSCF MN CN MN OldAP NewAP AMG S-CSCF ASSC CN Handoff MN Prediction ULAW ULAW ULAW Datalink Handoff & DHCP req. Data flow (1) REGISTER (3) REGISTER (5) INVITE Data flow BT re-conn. (11) 200 OK 220 ms Datalink Handoff & DHCP req. (2) 401 Unauth. (1) REGISTER (3) REGISTER (4) 200 OK (8) INVITE Registration Phase (2) 401 Unauth. (6) INVITE New Data Tx/Rx (7) INVITE Component Creation ULAW (8) Data Flow Rebind and Adaptation Data Flow Rebind and Adaptation (10) 200 OK (9) 200 OK GSM GSM Media Loss (4) REGISTER (5) Trying (6) 200 OK (7) 200 OK Renegotiation Phase (11) Trying (12) 200 OK (9) 200 OK (10) INVITE Registration Phase Renegotiatio n Phase ULAW ULAW Bologna /57

25 Experimental Results (2) Objective evaluation (received audio waves) Subjective evaluation (Misra score [0, 100]) db (a) (b) (c) (d) s Wi-Fi, ULAW: 75.3/100 good Bluetooth, ULAW, w/o background traffic: 72.3/100 good Bluetooth, ULAW, with background traffic: 5.4/100 bad Bluetooth, GSM, with background traffic: 64.3/100 good Bologna /57

26 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 IHMAS Handoff Management: Conclusions and 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 Bologna /57

27 IHMAS Power Management UserA IMS-based components Call to UserB Internet Call to UserB WLAN UserB UMTS Bologna /57

28 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 infrastructures full compliancy with IMS standard Bologna /57

29 IHMAS Power Management Facility: Distributed Architecture Low-consumption wireless interface High-consumption wireless interface CM 1. IMS-compliant SIP Signalling 2. <<publishes>> 6. PS MN Home Domain AS Node 3. ASPM <<notifies>> 5. IMS 4. IMS-compliant SIP Signalling Power-Saving Session Signaling Data Tx/Rx and Playout IMS Client MN MN Visited Wireless Access Domain DATA 7. Data Tx/Rx and Playout IMS Client CN CN Domain Data Transport Context Monitor CM (one for client): implements lightweight and completely 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 IMS PS PS (one for access locality): facilitates CM-ASPM interactions Bologna /57

30 IHMAS Power Management Facility: Modified Invitation Protocol Context Change Notification Dynamic switch on and call redirection CN (I-)S-CSCF MN (2) SUBSCRIBE (4) OK PS MN ASPM MN (1) SUBSCRIBE (3) OK (6) PUBLISH (7) OK (8) OK (9) NOTIFY (10) NOTIFY context change (11) OK (12) OK (5) PUBLISH context change Always-on interface CM: context changed Switchedon interface (13) INVITE (14) INVITE (15) new-invite (16) 100 Trying wait MN Interface re-register rebind (17) (de-)register (18) 401 Unauth. (19)(de-)REGISTER (20) OK (21) REGISTER (22) REGISTER (23) 401 Unauth. (24) 401 Unauth. (25) REGISTER (26) REGISTER (30) (27) OK (28) OK 302 MOVED (29) 302 MOVED (31) INVITE (32) INVITE send MOVED IHMAS original message flow extensions IMS 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 Bologna /57

31 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(); } } Implementation Insights: AS for Power Management ASPM implementation is based on JAIN SIP stack On 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 INVITE sip:alice@open-ims.test SIP/2.0 Content-Type: application/sdp Content-Length: 414 v=0 o=- 0 0 IN IP s=ims Call c=in IP t=0 0 m=audio RTP/AVP 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: 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 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 Bologna /57

32 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 */ } } Implementation Insights: IMS Client Based on UCT IMS Client New-INVITE processing Extracts from the a: field the MAC of the wireless interface to switch on Sends de-register void ims_send_re_register() { int port=5060, pid, status; pid=fork(); Re-registration 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(); } Switches on the wireless interface Sends a REGISTER over the switched-on wireless interface Bologna /57

33 Implementation Details IMS core components 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 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 b 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 Bologna /57

34 Experimental testbed Bob Alice sends switches the on the WLAN INVITE interface request and reregisters intercepted and modified ASPM sends by to Bob a 302 ASPM Moved Temporarily to re-direct the session toward switched-on interface UCT IMS Client (Bob) 302 Moved Temporarily INVITE INVITE Adds the our power saving a: field INVITE ASPM NEW_INVITE 302-Moved Temporarily IMS IMS Core Core Infrastructure REGISTER REGISTER INVITE NEW_INVITE De-REGISTER UMTS WLAN UCT IMS Client (Alice) Bologna /57

35 Experimental Results (1) CN (I-)S-CSCF MN PS MN ASPM MN 285 ms T 0 (1) INVITE (2) INVITE (4) 100 Trying (3) new-invite wait MN re-register Interface rebind sum < 3s 93 ms 825 ms 570 ms T 3 T 2 T 1 (18) 302 MOVED (19) INVITE (6) 401 Unauth. (8) OK (11) 401 Unauth. (15) OK (20) INVITE (10) REGISTER (14) REGISTER (17) 302 MOVED (5) (de-)register (7) (de-)register (9) REGISTER (12) 401 Unauth. (13) REGISTER (16) OK send MOVED Bologna /57

36 250 Experimental Results (2): Stand-by time Hours W/o power management 50 0 stand-by UMTS stand-by UMTS, IMSbased registration Analitical results evaluated for N95 Battery: 950mAH and charged at 3.7V WiFi avarage additional consumption (always-on): 0.05W stand-by WiFi, IMSbased registration Bologna /57

37 300 Experimental Results (3): Call time Minutes With power management 50 0 UMTS call time Energy-efficient WiFi call time Energy-efficient WiFi call time is longer than the talk time duration specified by Nokia for UMTS. Bologna /57

38 Conclusions IHMAS Power Management: Conclusions and ongoing work 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 /57

39 IHMAS PS scalability optimizations P: presentity PS: Presence Server W: watcher Inter-domain PS scenario P1 DOMINIO P DOMINIO W SUBSCRIBE (to P2@dominioP) SUBSCRIBE W1 P2 IMS PS IMS PS W2 SUBSCRIBE (to P2@dominioP) PN SUBSCRIBE (to P2@dominioP) WN Bologna /57

40 IHMAS PS scalability optimizations Inter-domain PS scenario IMS-based components DOMINIO P DOMINIO W P1 NOTIFY NOTIFY W1 PUBLISH (e.g.: I m online ) IMS IMS NOTIFY P2 W2 PS PS NOTIFY PN Problem: high number of inter-domain PS messages WN Bologna /57

41 IHMAS 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 infrastructures full compliancy with IMS standard Bologna /57

42 Optimizations towards scalability: common NOTIFY Several Watchers subscribed to one Presentity SUBSCRIBE SUBSCRIBE (to W1 IMS IMS P2 PS PS W2 SUBSCRIBE (to SUBSCRIBE (to WN Bologna /57

43 Optimizations towards scalability: common NOTIFY (2) Watchers list NOTIFY + NOTIFY W1 P2 PUBLISH IMS PS IMS PS NOTIFY W2 NOTIFY Consolidates NOTIFY messages at Presentity s domain 1 only interdomain NOTIFY message NOTIFY messages creation at Watchers s domain WN Bologna /57

44 Optimizations towards scalability: batched NOTIFY One single Watcher subscribed for multiple Presentities P1 SUBSCRIBE IMS IMS P2 PN PS PS W2 SUBSCRIBE (to Bologna /57

45 Optimizations towards scalability: batched NOTIFY (2) P1 PUBLISH P2 PUBLISH PUBLISH IMS PS NOTIFY NOTIFY NOTIFY IMS PS W2 PN Time-based (periodic) NOTIFY message batching Bologna /57

46 Optimizations towards scalability: batched NOTIFY (3) P1 PUBLISH P2 PUBLISH PUBLISH IMS PS NOTIFY NOTIFY NOTIFY NOTIFY IMS PS NOTIFY W2 PN 1 only inter-domain NOTIFY message Bologna /57

47 IHMAS PS scalability: PS protocol enhancements W A.4 W A.3 W A.1 P-/S-CSCF A IOM A + PS A I-/S-CSCF B IOM B + PS B P B.1 P B.4 P B.4 SUBSCRIBE from other watchers (1) SUBSCRIBE (2) SUBSCRIBE (3) SUBSCRIBE (4) SUBSCRIBE (8) 200 OK (5) 200 OK (7) 200 OK (6) 200 OK (9) PUBLISH (10) OK PUBLISH from other presentities Gold Clients (12) NOTIFY (13) OK (14) OK Prioritized NOTIFY schedule (11) NOTIFY Watchers Authorization and NOTIFY construction Silver Clients (14 ) NOTIFY (13 ) NOTIFY msgs (12 ) OK (11 ) Common NOTIFY (one per presentity) (15 ) OK msgs (16 ) OK Copper Clients (14 ) NOTIFY (13 ) aggregated NOTIFY (12 ) OK Watcher Authorization, NOTIFY aggregation, NOTIFY construction (11 ) Batched NOTIFY (one per watcher) (15 ) OK msgs (16 ) OK Domain A Domain B Bologna /57

48 Implementation Details IMS infrastructure Open IMS Core Presence Server OpenSER SIP traffic generation IMS Bench SIPp Bologna /57

49 Experimental testbed Linux Boxes 2CPU 1,8 GHz 2048MB di RAM IMS Bench Manager SIPp client open-ims1.test P-CSCF configuration and result gathering SIP calls SIP calls P-CSCF SIPp client open-ims2.test Presence Server (OpenSER) S-CSCF I-CSCF Presence Server Open IMS Core Open IMS Core (OpenSER) Bologna /57

50 Experimental results: w/out IHMAS optimizations 5 CPS 10 CPS 15 CPS 20 CPS 25 CPS 35 CPS 45 CPS 55 CPS 65 CPS 70 CPS 80 CPS 90 CPS sec 5 CPS 10 CPS 15 CPS 20 CPS 25 CPS 35 CPS 45 CPS 55 CPS 65 CPS 70 CPS 80 CPS 90 CPS 6.6 w/p 8.6 w/p 10.9 w/p 14.6 w/p Bologna /57 MEMORY % CPU % sec

51 Experimental results: with IHMAS common NOTIFY 5 CPS 10 CPS 15 CPS 20 CPS 25 CPS 35 CPS 45 CPS 55 CPS 65 CPS 70 CPS 80 CPS 90 CPS 5 CPS 10 CPS 15 CPS 20 CPS 25 CPS 35 CPS 45 CPS 55 CPS 65 CPS 70 CPS 80 CPS 90 CPS sec 6.6 w/p 8.6 w/p 10.9 w/p 14.6 w/p Bologna /57 MEMORY % CPU % sec

52 CPS 10 CPS 15 CPS 20 CPS 25 CPS 35 CPS 45 CPS 55 CPS 65 CPS 70 CPS 80 CPS 90 CPS Bologna / Experimental results: with IHMAS batched NOTIFY sec 5 CPS 10 CPS 15 CPS 20 CPS 25 CPS 35 CPS 45 CPS 55 CPS 65 CPS 70 CPS 80 CPS 90 CPS 6.6 w/p 8.6 w/p 10.9 w/p 14.6 w/p MEMORY % CPU % sec

53 Experimental results: number inter-domain NOTIFY transmissions # NOTIFY messages w/p w/o PS enhancements w/ Common NOTIFY w/ Batched NOTIFY Bologna /57

54 Experimental results: inter-domain NOTIFY delay ms w/p w/o service differentiation gold client silver client Bologna /57

55 Conclusions IHMAS Power Management: Conclusions and ongoing work 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 /57

56 IHMAS project web site and contacts Prototype code: Research/IHMAS Contacts: Luca Foschini Thanks for your attention! Bologna /57