Improving Performance of IMS Networks with Intelligent ... - ECT

Improving Performance of IMS Networks with Intelligent Message Processing Mauricio Cortes, Anwar Walid, Nachi Nithi {mcortes, anwar, karun}@alcatel-lucent.com Alcatel-Lucent, 600 Mountain Ave. Room {2D-535, 2C-324, 2C-323}, Murray Hill, NJ 07076 1. Project Goal The 3GPP IP Multimedia Subsystem (IMS) is a standard [1] for real-time multimedia commu-nications services. IMS standards define open interfaces for session management among other areas. This allows the network provider to manage IP network, with all the carriergrade attributes of switched circuit networks. The performance of IMS signaling impacts the sessioncarrying capacity of the network. In addition to the challenges posed by SIP[5] message processing, the number of the IMS elements in the signaling path and the SIP extensions add complexity and delay to establish sessions. Further, soft real-time applications such as voice calls and Push-to-talk pose stringent delay requirements to establish new sessions.. The performance of IMS signaling network will benefit from optimizations at different levels, ranging from message processing and scheduling to traffic routing and network design. In this work we focus on message processing and introduce different message prioritization polices beyond FIFO. Using simulation, we investigate different scheduling schemes at the IMS servers to support applications with varying latency requirements.

2. IMS Simulation Figure 1 shows the IMS topology that is modeled in our IMS simulation tool[4]. There are sets of callers and callees connected to their P-CSCF’s via links that may be wireless or wireline. The callers and callees use an intermediate IMS domain via an I-CSCF’s, or directly to S-CSCF’s. Some calls require service from the Application Server (AS). The simulation models one AS that is involved on 40% of the calls, introducing an additional delay following an exponential distribution with average of 1 ms. Further, some calls require that the S-CSCF initiates a DNS lookup to discover the callee’s S-CSCF. The DNS response times follow the distribution found in [5] with an median response time of about 87ms. The simulator keeps track of CPU usage on each element including all the X-CSCFs where execution time measurements were taken from Cortes[3]. Our tool simulates the message flow described in subsection 7.2.2 of the signaling flow document [2]. This flow includes as many as 120 messages, exchanged between IMS elements, to establish a session between

two end-user devices. Our tool considers message size, propagation delays depending on link type, retransmissions, and many other parameters. The reader is referred to [4] for additional details on this tool. AS DNS

I-CSCF

S-CSCF

I-CSCF

P-CSCF

P-CSCF

Callers

Callees

Fig ure 1. IMS Network Model

3. SIP Message Scheduling Policy The simplest SIP message scheduling policy to implement is FIFO (First-In-First-Out). However, FIFO scheduling may not be desirable since it does not take into account the age of a message (i.e., the sojourn time of a message in the IMS network). For example, a message that has experienced a long delay due to a DNS lookup or has visited an application server may yet experience considerable additional delay while queueing behind other messages before its service is completed. This may result in excessive ringing or call setup latency. Thus, it is of interest to investigate message scheduling policies that can prioritize messages to meet their service requirements while maximizing the call carrying capacity of the server. To this end, we have considered four other policies: 1) HOPS: uses a hop count for the entire message flow as the basis to assign message priority, 2) ASP: uses the number of times a message is processed by application servers (ASes) as the basis to assign message priority, 3) assigns dynamic priority based on earliest due date (EDD), and 4) MsgType: assigns priority to the message type based on their occurrence in the message flow. HOPS assumes that the number of hops visited by a message is kept in the message header and priority is given to those messages with the larger hop count. This policy requires a change in the standards and implementations for all IMS servers. ASP aims to give

4. Results and Conclusions Figure 2 shows the average post-selection delay (PSD) as defined by ITU [6] for the five scheduling policies mentioned earlier. For each policy, we ran various call loads ranging from 150 to 190 calls per second (cps). As expected, the delays using all five policies under low load is very similar. As the load increases to 170 cps, AS policy is slightly worse than the other four policies. At full system capacity (175 cps), the average PSD is noticeable different for each scheduling policy. We do not include entries for loads 180 cps and above since system violates the upper limit of 5 seconds for the average PSD specified in the ITU recommendation for all policies. Average Post-Selection Delay 1.3

Seconds

1.2

1.1

1 150

155

160

165

170

175

Calls per Second FIFO

Hops

AS

EDD

MsgType

Figure 2. Average Post Dial Delay

It is important to point out that the number of calls that reached post-selection state is about the same in each call load for all the scheduling policies. Thus, the variation of the average PSD is due to the policy itself and not at the expense of reduced call services. Figure 3. depicts the PSD violation rate of each scheduling policy at various call rates. Similar to the average PSD, the scheduling policy does make a difference at high loads when the system is at its full capacity. Recall that the ITU recommends that only 2% of the call could have a post-selection delay of 3 seconds or worse. As shown in the figure below, Hops, EDD, and MsgType scheduling policies comply with this requirement.

Post-selection Delay Violations > 3 Seconds 3.0%

2.5% Violation Rate

priority to messages in flows that are required to visit an AS since these flows encounter additional delays. Messages can be marked by S-CSCFs and honor by all servers and end-devices. Like HOPS, it requires a change in the standards as well.. EDD gives priority to messages based on the service deadline (e.g. ringing time) they are required to meet. This policy requires keeping timing information in the message and clock synchronization on all IMS servers. Similar to HOPS and ASP, EDD will require a change in processing SIP message. MsgType policy is given to messages according to pre-determined priorities based on type. For example, ACK message has higher priority over 180Ringing messages since the former releases resources while the latter consumes additional memory This policy does not require changes to standards..

2.0%

1.5%

1.0%

0.5% 150

155

160

165

170

175

Calls per Second FIFO

Hops

AS

EDD

MsgType

Figure 3. Post-Selection Delay Violations

EDD reduces the number of PSD violations by about 20% compared to the traditional FIFO policy. Unfortunately, EDD requires modifications to the standard and its implementation is cumbersome. In contrast, MsgType reduces PSD violations by about 14% and its implementation is straightforward and no standard changes are required. MsgType policy implemented in our tool is arguably a reasonable approximation to EDD. It increases priority to messages towards the end of the call setup flow. EDD differs that early flow messages that need retransmissions will be scheduled first than later flow messages that had not suffer extra delays. HOPS is closely related to MsgType and thus its results. In contrast, ASP is outperformed by all other policies due to the low delays introduced by the single AS included in our model. Otherwise, ASP would have performed as the FIFO policy.

5. References [1] 3rd Generation Partnership Project, “IP Multimedia Call Control Protocol based on Session Initiation Protocol and Session Description Protocol (stage 3), “Rel. 6, TS 24.229, V 6.15.0, Jun. 2007. [2] 3rd Generation Partnership Project, “Signaling flows for the IP multimedia call control based on Session Initiation Protocol and Session Description Protocol (stage 3), “Rel. 5, TS 24.228, V 5.15.0, Sep. 2006. [3] Cortes, M., Ensor, J., Esteban, J., On SIP Performance, Bell Labs Technical Journal, Vol. 9, Issue 3, Pages 155–172, 2004. [4] Cortes, M., Esteban, J., Jun. H., Diabelli: An IMS Simulation Tool, Bell Labs Technical Journal, Volume 10, Issue 4 , Pages 255 – 259, 2006. [5] IETF RFC 3261, “SIP: Session Initiation Protocol”, J. Rosenberg et. al., June 2002. [6] ITU, “Network grade of service parameters and target values for circuit-switched services in the evolving isdn,” Recommendation E.721, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, May 1999. [7] Jung. J., Sit, E., Balakrishnan, H., Morris, R., DNS performance and the effectiveness of caching, Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement, San Francisco, 2001.