Improving Performance and Reliability of IMS by Co-location DHT

Yang Peng Mobile life and New media Laboratory

Beijing University of Posts and Telecommunications, Beijing China

bigbird.yp@gmail.com

Zhang Chunhong Mobile life and New media Laboratory

Beijing University of Posts and Telecommunications, Beijing China

zhangch@bupt.edu.cn

Ma Tao, Mobile life and New media Laboratory

Beijing University of Posts and Telecommunications, Beijing China

abcdmatao@gmail.com

Gou Xuerong Mobile life and New media Laboratory

Beijing University of Posts and Telecommunications, Beijing China

xrgou@126.com

Abstract—IP Multimedia Subsystem is deemed to be the core of NGN (Next Generation Network) technology. IMS is considered as the important way to solve the fixed-mobile convergence and the combination of multimedia services. P2P technology is introduced to solve the complicated structure and high OPEX of IMS, so as to promote the reliability and extensibility. However the introduction of P2P technology brings extra DHT messages and query delay that might exacerbate the performance of IMS applications. This paper proposes a new strategy called co-located DHT IMS where the IMS servers are as co-located as possible on the same DHT node host to reduce the messages necessary to exchange among IMS servers, as well as the number of physical servers involved on the process of registration and session establishment. Performance evaluation shows that the messages are reduced to and the reliability of system is improved when compared to traditional IMS. Thus the co-location DHT IMS is a feasible alternative for implementation in real system.

Keywords-component; IP Multimedia Subsystem; Peer-to-Peer; co-location; Performance; Reliability

I. INTRODUCTION The IMS [1] specified by 3rd Generation Partnership

Project (3GPP) describes architecture for providing a flexible vehicle for quickly deploying new revenue-generating applications which are allowed to delivered to fixed and mobile customers, whether the destination is in an IP or circuit-switched (CS) network. There are a variety of modes for IMS-based services including voice, text, pictures and videos, or 1any combination of these. As a result, IMS is seen as the cornerstone of carriers' fixed and mobile convergence strategies. However, there are too many different SIP proxies and functional entities used for each end-to-end SIP session. This may increase significantly the message latency and decreases reliability of IMS. It is also too complexity to operate and maintain

This work is supported by National High Technology Research and Development Program of China(863 program)(No.2007AA01Z205 and No. 2008AA01A310)

the network. The interest of IMS is being challenged as there are often cheaper alternatives to creating and deploying that particular service.

An architecture proposed by Bessi co-locates different IMS servers on the same host to improve the reliability and performance of IMS networks [2]. Because there are too much SIP proxies used for an end-to-end IMS VoIP call: originating and terminating P-CSCF and S-CSCF, terminating I-CSCF, and application servers. Co-locating different servers on the same host reduces the number of network elements need and message need for inter-server which introduces delays (end-to-end signaling delay) and impacts capacity in terms of number of call handled. When two SIP servers are on the same host, the process will skip several layers which are required without co-location mechanism. When IMS servers running on the same host and using an adequate architecture, the SIP message can be internally passed between SIP servers using a simple mechanism, there is no SIP message leaves the host. It can save the network capacity and improve its performance and reliability. Factors determining whether IMS servers can be co-located were extracted without the situation that the I-CSCF and the S-CSCF may be not co-located., sometimes S-CSCF on the I-CSCF’s host doesn’t match the capability for client to register. I-CSCF must choose another S-CSCF on different host. This impacts on the magnitude of improvement, we will analysis the influence which is brought.

Due to these constrains of IMS, [3] have evaluated the possibility of distributing the HSS across different nodes which are configured in a distributed hash table (DHT) fashion. DHT is a class of decentralized distributed systems that provide a lookup service similar to a hash table: (key, value) pairs are stored in the P2P overlay. The classic DHT algorithms include Chord [4], Pastry [5], and Tapestry [6] and so on. DHT provides the following basic features and mechanisms: improved the quality of the IT service in enterprise, but also promote the amalgamation of IT and business., self-organization, routing, resource distribution and lookup.

2010 International Conference on e-Education, e-Business, e-Management and e-Learning

978-0-7695-3948-5/10 $26.00 © 2010 IEEE

DOI 10.1109/IC4E.2010.84

102

Distribution of the network functional elements in a DHT fashion leads to increase robustness of IMS network elements. No operator's intervention is required, when a service node comes up or fails. Deploying a new service node into operation network just requires almost zero-configuration. OPEX can be saved a lot for operator. However, the self-configuration of the system comes with the cost of additional overhead which can be divided into: the load created when nodes join or leave the DHT and the load created by the self DHT maintenance. Since in many case, this will be DHT controlled by operator, the first load is negligible. The second load will create more overhead traffic which may introduce more delays than conventional IMS, especially when there are a big number of servers in one DHT and the DHT algorithm require more messages to locate a resource in an overlay.

To relieve these disadvantages, we propose co-location for DHT IMS in this paper. We design the process flow of DHT IMS and the new DHT IMS architecture in order to adapt to the situation of large-scale server farm. The notions of co-location IMS and DHT-based IMS are both not novel, Nevertheless, we explore the mechanism which make they work together can improve performance.

The rest of this paper is organized as follows: section 2 introduces the architecture of co-location DHT IMS. Section 3 takes registration and calls setup as examples, describes the implementation for co-locating servers in the DHT IMS. Section 4 simulates the message overhead and the reliability of different IMS architectures. The final conclusion and future work are presented in Section 5.

II. ARCHITECTURE OF CO-LOCATION DHT IMS

A. IMS Network Architecture This section describes the brief IMS network

equipments. • Core Network. The Call Session Control Function

(CSCF) is a central component to signaling and control within the IP Multimedia Subsystem (IMS) network. It is responsible for all signaling via SIP between the Transport Plane, Control Plane, and the Application Plane of IMS. The CSCF is subdivided into three separate parts, which each have unique functions within IMS.

• P-CSCF (Proxy-CSCF) is responsible for interfacing directly with the Transport Plane components and is a SIP proxy that is the first point of contact that the IMS domain presents to the user terminals.

• I-CSCF (Interrogating-CSCF) is the home networks first point of contact for peer IMS networks. It queries the HSS to help in finding the S-CSCF where the user is registered or selecting a new S-CSCF if the user is not registered.

• S-CSCF (Serving-CSCF) is the central node for the provision of the SIP signaling and the heart of the IMS system.

• User Database. The Home Subscriber Server (HSS) is the master database that contains subscriber information to support the network entities handling calls and sessions. It provides the following functions: identification handling, access authorization, authentication, providing information on which CSCF currently serves the user. When more than one HSS is deployed in the network, a Subscriber Location Function (SLF) is needed to locate the HSS that holds the subscription data for a given user.

In the IMS network, as specified in [7] and [8], A DNS-based mechanism for selecting the I-CSCF is used in a IMS network which is a conventional IMS or DHT IMS in [3], and the HSS query is based on the data that is got from SLF when there are more than one HSS used to contain subscriber information. As a consequence, the bigger the network grows, the more network equipments are required. The more messages are brought. There will be more potential points of failure and more message latency.

B. co-location DHT IMS s Figure1 illustrates the co-location DHT IMS network

structure, which is a hierarchical system [9].Because the whole network is divided into small overlays and nodes cache the high level node as shortcuts, the latency is less than all the nodes in different domains are in only one DHT.

Figure 1. The co-location DHT IMS framework

Each ring represents an Intra-domain which is made up of a number of server nodes which work together based on specific DHT algorithms such as Chord, Pastry. Each domain can be operated to run heterogeneous DHT algorithm by the operator. Each server node has four modules: P/I/S-CSCF and HSS. The functions of P/I/S-CSCF are similar with the entities in conventional IMS except P2P overlays replace DNS servers to be adopted as the target location mechanism for SIP. HSS is distributed and assigned to contain information based on DHT. If the source and destination server modules are on the same host, the SIP message can be internally passed using co-location mechanism.

103

The server node in a domain act as High Server Node (HSN) or Low Server Node (LSN). When there is an inter-domain SIP message, LSN will send it to HSN, HSN analysis the Request-URI of SIP message, utilizes high-level DHT to locate remote HSN in the destination and forward the sip message to its I-CSCF module. The transmission of inter-domain session is reliable and efficient.

III. USAGE PATTERN In order to co-locate servers on the same host, the DHT

IMS must be engineered and provisioned so that servers are effectively co-located.

When a consumer contract with the operator, co-location DHT IMS utilizes DHT to locate one Sever Node’s HSS according to user identifiers such as IP Multimedia Public Identity (IMPU) or the others. There are used by the hash operation to generate the keys which points one HSS which conserves the information. During registration and session process, CSCF which is on the same host with HSS will be the best candidate for the message is forwarded to, because it is selected based on the hash operation as the selection of HSS, or it will be chosen with the appropriate implementation. The performance will be improved as the CSCF and HSS are co-located on the same host.

A. Registration During the initial registration of the UE, the P-CSCF,

I-CSCF, HSS and S-CSCF modules are discovered in the co-location DHT IMS. The steps in this process are as follows:

a) P-CSCF Discovery. The P-CSCF discovery shall be performed after User Equipment(UE)get it IP address from DHCP.UE obtains the P-CSCF address from a list which is provided by DHCP,UE will request a P-CSCF until one is available. UE will send register message to the P-CSCF on one host in the geographical zone where the UE is currently located.

b) I-CSCF Discovery. I-CSCF discovery by the P-CSCF is based on DHT. When the UE is not roaming, the request URI points to the domain where the UE is currently located. The I-CSCF will be selected based on the computed hash of the user identifies. Sometimes the I-CSCF is co-located with P-CSCF, the probability of which is inversely proportional to the number of server nodes in the domain. However the other time or the UE is roaming, the P-CSCF and I-CSCF cannot be co-located.

c) HSS queried by I-CSCF. Because the I-CSCF is selected with the same manner as the selection of HSS, so the I-CSCF and HSS can always be co-located.

d) S-CSCF Selection. When it is an initial registration, the I-CSCF will select an S-CSCF “capability” from the HSS. A legal S-CSCF URI or a list of S-CSCF URIs with their capabilities is provided by for I-CSCF selecting one that matches the capability as instructed by the HSS. With the appropriate

implementation, it is easy to provide local S-CSCF on the same host with I-CSCF will be selected. Nevertheless, when the local S-CSCF doesn't match the capability, I-CSCF have to choose one on another host to register. That impacts the performance of network.

e) HSS queried by S-CSCF. When the S-CSCF and I-CSCF are co-located, it will be collocated with HSS too. This is impacted by the percentage of S-CSCF which is on the same host with I-CSCF is available for UE to register.

We can see from Figure2 that the DNS and SLF are no longer necessary even if in a large-scale network, since the discoveries between CSCF entities can completed by DHT. Because of the mathematical properties of DHT algorithms, the P-CSCF and I-CSCF will be co-located sometimes; I-CSCF and HSS always can be on the same host by reason of similar location manner they used; S-CSCF can be on the same host if it matches the capability, the influencing factor will be discussed in section C of Part IV.

Figure 2. Messages Sequence Chart for Registration

B. Call setup Once the UE is registered, the path used at registration

time will be the same path used as the call setup. The steps in call setup are as follows. a) Terminating I-CSCF discovery. Originating S-

CSCF analyses the Request URI and use DHT lookup the terminating I-CSCF. If it is in the same domain, the originating S-CSCF use the computed hash key of callee's identifies to locate the I-CSCF which is in the path which the callee used to register. However when the Terminating I-CSCF is in another domain, originating S-CSCF forward to the HSN in the domain, originating HSN will locate the remote HSN in terminating domain using the destination domain name Then using computed hash of callee HSN send the invite SIP message to the I-CSCF.

104

DM is DHT message number. I=I-CSCF, P=P-CSCF, S=S-CSCF. Hyphen between servers—Servers are remote, and no hyphen between servers—Servers can be co-located

b) HSS queried by I-CSCF: The I-CSCF and HSS are always co-located, so there is no message during the I-CSCF queries the HSS to get the terminating S-CSCF URI.

c) Terminating S-CSCF discovery. When the terminating S-CSCF is already assigned, the S-CSCF which is on the same host with I-CSCF often has been designated at the registration time. They will be co-located. It depends on the parameter c. If the terminating S-CSCF is not assigned, I-CSCF will give first priority to local S-CSCF in order for the IMS servers to be co-located.

d) Terminating P-CSCF discovery. Terminating S-CSCF has a pointer to the P-CSCF, If the callee is not roaming, and the P-CSCF is on the same host as S-CSCF during the initial registration, they will be co-located on the same host.

Figure 3. Messages Sequence Chart for Call setup

As is shown in Figure3, the originating CSCFs are assigned when the UE registered, and the terminating I-CSCF and HSS always can be on the same host，and terminating P-CSCF and S-CSCF sometimes can be on the same host.

IV. PERFORMANCE EVALUATION

A. Message overhead Let

N = the number of server nodes PR = Percentage of roaming subscribers c = Average percentage of S-CSCF which is on the

same host with I-CSCF is available for UE to register

We assume that the average probability of the destination hash key is on the same host as the source is p, we can get that p=1/N, when UE is roaming, P-CSCF and I-CSCF will certainly not be on the same host, so the

probability of the P-CSCF and the I-CSCF on the same host is a1 =p*(1-PR), the probability on the different host is a2= PR+（1-p）*（1-PR）.The probability of I-CSCF and S-CSCF are co-located depends on the parameter c.

The expected message number for register NM=∑(Mi*Ri), Mi is the message number of different situation, Ri is the proportion of different situation. With the help of Talble I, we can get the NM:

NM=10-6*c+4*(1-（1-PR）/N)* DHT messages

The expected number of message for call setup is calculated as similar as above, however it is very complex to get the formula since there are 32 kinds of different situations.

TABLE I. POTENTIAL AND MESSAGE OVERHEAD FOR CO-LOCATING DHT IMS FOR REGISTRATION

PIHS P-IHS PIH-S P-IH-S Percentage a1*c a2*c a1*(1-c) a2*(1-c)

The Message number

4 4+4*DM 10 10+4* DM

Suppose that Percentage of roaming subscribers is 20%

which comes from GSM. We simulate the message number with MATLAB and the result is shown in Figure4 and Figure 5. As shown in Figure4 and Figure5, the numbers of message used in conventional IMS are fixed，respectively 20 and 42.The message number in DHT is affected by DHT algorithm since there is an overhead traffic due to DHT itself. Take Chord for example，it is able to locate a resource in an overlay with high probability using O(log n) messages. So in the figures, we can see the numbers of message for both registration and call setup are sharply increased with the increasing number of server nodes. When there are 100 server nodes, the number of message for registration is as three times as that in conventional IMS. and the number of message used per call is always as twice as that in conventional IMS. The reduction of the message number between servers in co-location DHT IMS results from the functional entities interact in the same host. Two parameters that have a significant impact on the number of message are c and N. As we can see the message number in co-location DHT IMS is similar as the conventional IMS, and is much less than that in DHT IMS when N is less than 20.As increase of N, the message number is increased, but it is still half of DHT IMS.

105

0 100 200 300 400 500 600 700 800 900 10000

10

20

30

40

50

60

70

80

90

Numer of server nodes

Num

ber

of m

essa

ges

for

regi

stra

tion

Conventional IMSDHT IMS(Chord)CD-IMS(Chord)c=0.5 CD-IMS(Chord)c=0.9CD-IMS(one hop DHT)c=0.5CD-IMS(one hop DHT)c=0.9

Figure 4. The number of message for registration in conventional IMS,

DHT IMS and Co-location DHT IMS (CD-IMS) with different parameter c.

0 100 200 300 400 500 600 700 800 900 100010

20

30

40

50

60

70

80

90

Number of server nodes

Num

ber

of m

essa

ge p

er c

all s

etup

CD-IMS(one hop DHT)c=0.5CD-IMS(one hop DHT)c=0.9CD-IMS(Chord)c=0.5CD-IMS(Chord)c=0.9conventional IMSDHT IMS(Chord)

Figure 5. The number of message for call setup in conventional IMS,

DHT IMS and Co-location DHT IMS (CD-IMS) with different parameter c.

However when the servers number is more than 20, the message used for registration is more than twice that in conventional IMS. DHT algorithm is another important factor in the impact of performance. In the figures, we have adopted one hop DHT which has better routing performance than Chord. The message number is kept on the low level. Its performance is much better than conventional IMS

When the scale of servers in a domain is small (less then 20),simple DHT algorithm such as Chord or Pastry is suggested to adopted, it will be able to achieve the same results as conventional IMS or even better. The bigger the domain network grows, the more efficient the DHT algorithm has to be used. Although it comes with the cost of additional maintain overhead, the satisfactory result will be obtained considering the number of inter-server messages is sharply reduced.

B. Reliability The reliability of the network is directly and inversely

proportional to the number of server nodes that are

involved for registration and call session setup, because each sever is a potential point of failure.

For conventional IMS architecture, a typical call setup path will include the following network equipments: DNS/ENUM, originating P-CSCF， HSS and S-CSCF, terminating I-CSCF, HSS, S-CSCF and P-CSCF, if there are many HSSs, the operator is forced to deploy SLF. While several IMS servers in co-location DHT IMS are run on the same host, the session will depend on fewer hosts and therefore will involve fewer points of failure.

The expected message number for register NS=∑(Si*Ri), Si is the involved server number of different situation, Ri is the proportion of different situation.

100

101

102

103

99.75

99.8

99.85

99.9

99.95

100

Number of server nodes

Pro

babi

lity

of s

uces

s pe

r ca

ll (in

%)

CD-IMS c=0CD-IMS c=0.5CD-IMS c=1conventional IMS

Figure 6. Reliability of conventional IMS and Co-location DHT IMS (CD-IMS) with different parameter c.

Figure6 shows the reliabilities of conventional IMS and three co-location DHT IMS with different size of c. Then we can see that the probability of success per call in conventional IMS is 99.82%.However, DHT IMS using co-location strategy can improve the reliability to the level which is more than 99.88%.When the number of sever nodes is less than 20, the reliability is even more than 99.9%.The improvement of reliability is obvious by the reason of the number of servers participate in is reduced than that need in conventional IMS. The parameter c has significant impact on the reliability too, and it will be discussed in next section.

C. The influence of the parameter c We denote c as average percentage of S-CSCF which

is on the same host with I-CSCF is available for UE to register.

Figure4, Figure5, and Figure6 above show the size of c will affect the number of inter-server message and the number of participating servers. I-CSCF need to register S-CSCF on another host when c is so small that local S-CSCF is not available for this registration in most cases. There will be more message overhead and reduced reliability.

106

Taking into account the homogeneous functions of the server node in the distributed IMS, It is small probability that an S-CSCF cannot meet part of requirements in the registrations request from the I-CSCF on the same host. The less c illustrate smaller number of server nodes which provide the ability of certain service and the smaller number of users need for the service. Growing number of consumers contact one service, but if not increasing c, that means not to increase the number of server nodes, the capability of which meet the requirement of one service, the number of message inter-server and the number of participation servers will be increased both. This will result in reduced system performance. So with the growth of the consumers who contact one service, the number of server nodes which provided the capability for the service should be increased as the same proportion. That ensure that c will remain at a high level, and the performance of network can be satisfactory.

V. CONCLUSIONS In this paper, we propose our co-location DHT IMS

which replace the core network with self-organizing DHT overlay. The strategy detail of co-location DHT IMS has been described in this paper, and the factors which may influence the system are also discussed. The performance and reliability of system during registration and call setup are evaluated by the theoretical analysis and stimulation. There are many open problems to be addressed. The load balance of co-location DHT IMS is not considered because some servers run on the same host. These problems will be researched in our future works.

REFERENCES [1] 3rd Generation Partnership Project. IP Multimedia Subsystem

(IMS); Stage 2. http://www.3gpp.org/ftp/Specs/html-info/23228.htm

[2] Thierry Bessis. Improving Performance and Reliability of an IMS Network by Co-Locating IMS Servers. Bell Labs Technical Journal, Vol 10, No.4 Winter 2006.

[3] Marcin Matuszewski, Miguel A. Garcia-Martin. A Distributed IP Multimedia Subsystem (IMS).

[4] I. Stoica, R. Morris, D. Liben-Nowell, D.R. Karger, M.F. Kaashoek, F.Dabek, and H. Balakrishnan. Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications. IEEE/ACM Transactions on Networking, page 17,2003.

[5] A. Rowstron and P. Druschel. Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems. 2001.

[6] B.Y. Zhao, L. Huang, J. Stribling, S.C. Rhea, A.D. Joseph, and J.D.Kubiatowicz. Tapestry: a resilient global-scale overlay for service deployment. Selected Areas in Communications. IEEE Journal on, 2004.

[7] 3rd Generation Partnership Project. IP Multimedia (IM) Session Handling; IM Call Model; Stage 2. http://www.3gpp.org/ftp/Specs/html-info/23218.htm.

[8] 3rd Generation Partnership Project. Signalling Flows for the IP Multimedia Call Control Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3. http://www.3gpp.org/ftp/Specs/html-info/24228.htm.

[9] Juwei Shi, Yao Wang, Lanzhi Gu, Lichun Li, Wenjie Lin, Yinong Li,Yang Ji, Ping Zhang, A Hierarchical Peer-to-Peer SIP System

forHeterogeneous Overlays Interworking, Proc. of GLOBECOM 2007

107