50120140501015 2

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING &
6367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME

TECHNOLOGY (IJCET)

ISSN 0976 – 6367(Print)
ISSN 0976 – 6375(Online)
Volume 5, Issue 1, January (2014), pp. 128-140
© IAEME: www.iaeme.com/ijcet.asp
Journal Impact Factor (2013): 6.1302 (Calculated by GISI)
www.jifactor.com

IJCET
©IAEME

AIPC : COUNTER-ACTIVE ANALYSIS OF OVERLOAD CONTROL
MECHANISM FOR SIP SERVER
Bikash Upadhyay,

Atul Mishra,

Shraddha Bikash Upadhyay

1

(Department of IT., BBDNIIT, Dr. Akhilesh Das Nagar, Lucknow, UP., India)
(Department of CSE., BBDU, Dr. Akhilesh Das Nagar, Lucknow, UP., India)
3
(Department of CSE, BBDNITM, Dr. Akhilesh Das Nagar, Lucknow, UP., India)
2

ABSTRACT
We have introduced a new mechanism similar to earlier used AIMD algorithm in which there
will be a probabilistic change in the sending rate during the overload condition. The probabilistic
change will be sender-receiver synchronized by mechanism “Additive Increase and Probabilistic
Change (AIPC)”. We show that mechanism is effective, counter-active, reliable and fair. Sender will
change its sending rate in accordance with the receiver’s capacity. Sender-receiver is synchronized
such that former reduces the sending rate and the later prevents from being overloaded. Simulation is
used to analyze the factors viz. effectiveness, efficiency, fairness and stability.
Keywords: SIP, AIPC, AIMD, VoIP, SIP Server, Probability of Rejection.
1. INTRODUCTION
SIP is the major protocol used for Multimedia communication such as VoIP. It is an
application layer protocol, independent of sub layer protocols (TCP, UDP). SIP is proposed by
Internet Engineer Task Force (IETF).
SIP works in various phases of call such as Localization of terminal, Analyzing recipient
profile and resources, negotiating the type of media & communication parameters and the availability
of the correspondent. It’s also works out during the call Set-up and Call Follow-up. SIP protocol is a
transaction based protocol designed to establish and end media sessions.

128

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976
1.1 EASE OF USE
1.1.1 SIP Overview

Figure 1
SIP is widely being adopted by the IP telephony providers [1], including Vonage and AT&T,
as the foundation of large scale deployments. Such providers typically deploy Sip Proxies which are
responsible for Call routing operations, assisting request & response, across a larger geographic area
erations,
to efficiently deal with the increasing volumes of traffic. In centralized server architecture, these
proxies also deals in authentication and signaling request.
The SIP baseline specification RFC 3261 (previously RFC 2543bis) divides SIP Server
cification
functionality into the following parts:
a. SIP Registrar Server—handles location registration messages.
handles
b. SIP Redirect Server—returns “contact this address” responses.
returns
c. SIP Proxy Server—forwards SIP requests and responses.
forwards
1.2 Causes of SIP Server Overlaod
In SIP server architecture, there are two main reasons for performance problem: Firstly, due
to the larger network latency between the Proxy & SIP Server (authentication as well) in order to
handle the query the authentication requests because the Digest authentication requires a separate
e
request for each authentication operation. Each time a proxy process authenticates a message, it has
to wait for the response to continue processing the next message. During this time, it cannot process
a new request and the requests are rejected.
This leads to lower call throughput.

Figure 2
Secondly, with the increase in notable volume of traffic leads to Overload situation. Work
done in [5] suggests that overload situations not only reduce the performance of a VoIP server but
]
can finally lead to a complete standstill of the complete VoIP service. To withstand sudden increases
129

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), © IAEME
in traffic or temporary lack of resources, SIP servers and Proxies need to implement overload control
mechanisms that aim at reducing the work load of these servers and prevent a complete depletion of
their resources.
1.3 Measured Parameters for Analysis
We used the parameters defined in IETF draft for all the measurements [6], [8]. But we use
hardware utilization parameters as well, in order to monitor the performance of memory and
resources of the proxies. The parameters are measured based on sender and receiver ends.
Call statistics and duration of calls during the message exchange is monitored at the Sender
end. Real time protocol samples are also captured as well. At receiver end, Hardware utilization
parameters are measured directly. This would include the measurement of memory and resource
utilization.
The complete list of measured parameters includes:
• CPU Utilization
• Memory Utilization
• Number of Successful calls
• Number of (Un)Successful calls
• Request delays
1.4 Categories of SIP Server Overload
There are two main categories of SIP Server overload viz. Server-to-Server overload and
Client-to-Server overload. In this paper we have adopted the former category. When server capacity
is reached and if the server continues to accept requests, application performance and stability can
exhausted.

a. Serve- to-Server Overload
It occurs when upstream server starts sending substantial amount of traffic (Engineered
Traffic E) to the main server (SIP Server, here), pushing it towards overload. We have
adopted this scenario for our research in this paper.
b. Client-to-Server Overload
It occurs when a large number of clients make a simultaneous request not handled by the next
server, thereby, putting the server into overload.
2. RELATED WORK
Aim of any Overload control mechanism is to reduce the load or burden on the SIP Server.
Overload condition is observed as condition in which certain pre-requisite threshold values are
exceeded. This leads to dropping or rejection of SIP requests.
Work done in [2] analyzes that Performance of SIP Server and VoIP calls during a DoS attack.
Quality of Calls is reduced substantially during the attack. Packet loss occurs but can be neglected. A
sudden decrease in delay increases with the increase in flooding and stress on SIP server increases. It
is also concluded in [6] variation at receiver jitter increases as load on server increases.
Detailed analysis of rate based control mechanism [7] suggests that a new class of AIMD
algorithm works well during overload condition. Additive increment is decreasing functions of the
current sending rate. The congestion control algorithm is globally asymptotically stable and will
converge to equilibrium. Mechanism uses a decreasing function of the increase factor and a constant
decrease factor. A special case of DAIMD algorithm is considered for various grid based applications.
D.Sis [3] proposed R-SOCA which aims at stabilizing the proxy behavior during the overload
condition. It prevents the server from being completely exhausted. It takes nature and cause of
130

overload together. Dropping and rejecting the incoming request are realized by sending back a 5xx
response. AIPC mechanism adopted the probabilistic factor obtained as a change factor between
sender and receiver in synchronized manner. Sender-Receiver depicts the probabilistic change during
an overload condition.
R. kusching [10] illustrates that Multiplicative decrease step of AIMD algorithm reduces the
receiving window (and the corresponding throughput) in case of the packet loss drastically, before the
Additive increase step is initiated and tries to increase the window again. This can lead to remarkable
variation of the throughput in networks with large RTTs.
3. AIPC MECHANISM
3.1 Problem Statment
The goal of any overload control scheme is to reduce the load on engaged resources. Reducing
the load has their costs in terms of CPU and Memory Utilization as well.

Figure 3
3.2 Proposed Mechanism
• The mechanism would synchronize both the sender and the receiver. Mechanism focus on both,
reducing the incoming traffic at receiver end by either dropping or rejecting the traffic, based on
a Probabilistic factor. While at the sender end, the sender would adjust its transmission
strategies in accordance with the Receivers capacity. Receiver would increase the rate of
transmission until the notice of overload occurrence and would decrease it substantially as soon
as overload is noticed. In this way, both the sender and the receiver share their status to get
synchronized and decrease the rate of rejection which will surely enhance the CPU utilization
and corresponding Proxy Throughput.
• A SIP Server is said to be overloaded if atleast one of its resources is having a value more than
a specified limit. In our mechanism, we set this limit as RLOW. It is a point beyond which a
server starts overloading to some extent. And beyond RUP (upper limit), a SIP Server is said to
be overloaded. Above RUP, the system is considered as Overloaded and it cannot handle any
more requests and it starts rejecting the entire request until the Rate of Transmission falls
between the RLOW and RUP. Reducing the load on the SIP proxy can be realized by either
dropping incoming requests or rejecting them, e.g., sending back a 5xx reply. It is suggested in
[4] that dropping incoming requests, consumes slightly less CPU at the SIP proxy than rejecting
them.
• In order to reduce the possibility of an overload situation at the receiver side, the senders of the
SIP traffic should adapt their transmission rates to the capabilities of the receivers. That is, if a
SIP proxy that is currently sending traffic to another proxy notices that the receiving proxy is
overloaded; the sending proxy should reduce its transmission rate so as to avoid overloading the
receiving one.

131


• In order to avoid the sudden changes , we should take the average of Probability of rejection
d
sh
ty
• AIPC combines linear growth of the transmission rate with the Probabilistic change during an
overload condition.
3.3 Equations
• At Receiver Side
AIPC defines two threshold points (for CPU and memory): lower (RLOW) and Upper
Threshold (RUP). AIPC work in a way that the number of rejection during the overload condition
is minimized.
Once the lower threshold is exceeded, the AIPC starts reducing the load on the SIP server by
the Probability of Rejection (PoR). This can be illustrated by rejecting the incoming requests
ity
on SIP with PoR
PoR = 0

{RTRANS < RLOW}

(1)

Αll incoming requests coming from SIP Server is rejected as the Upper Threshold value is
ll
exceeded. This threshold is set t the amount of resources required to handle the requests in
to
some worst case scenarios. Engineered traffic [4] is the amount of requests a SIP server is
expected to receive and process simultaneously under normal operational conditions i.e.
during DoS attacks or Flash crowd scenarios.
PoR = 1

{RTRANS >= RUP}

(2)

There will be a probabilistic change size of receiving window when the rate of receiving
incoming requests lies between the Upper and Lower thresholds
PoR

=

RTRANS >= RLOW}

(3)

Parameter obtained in eq. (3) is the Probability of rejection calculated at fixed time intervals
(say T) where RTRANS is the load status on SIP Server [3]. In order to avoid sudden change
.
and to obtain a smooth graph, Average of PoR is taken in eq. (3) over the time. When :
graph,
o PoRAVG≤5 system is not considered as Overload and there will be no dropping or rejection

of incoming request is initiated.
o 1 ≥ PoR ≥ 0.05, SIP Sever is considered as Overloaded. Counteractive measures are
required to Sop is from being overloaded. Hence, the incoming successful INVITE
messages are rejected with the parameter used in eq. (3).
132


o PoR = 1, SIP Server is considered as complete overloaded and no incoming request is
entertained viz. requests are rejected.
•

At Sender Side
Sender side will use same parameter used on receiver side for reducing the rate of
sending requests. AIPC enables SIP Server to estimates the overload status at its neighboring
servers and adopt the change in transmission accordingly AIPC mechanism allows a faster
reaction to a substantial overload condition and careful preventive reaction during the under load
phases.

Figure 4
I=

ୖ୲୰ୟ୬ୱିୖ୪୭୵
ୖ୳୮ିୖ୪୭୵

At starting or under normal condition, when no overload status is received and no
retransmission occurs, the sender adjusts its sending rate in an increasing manner. It follows
additive increase behavior probing to usable bandwidth until the loss occurs. AIPC increases
the sending by a fixed amount every round trip time.
RTRANS +1 = RTRANS + δ {δ = Linear increase}

(4)

Upon receiving a Overload Status (i.e. 5xx reply) AIPC uses Probabilistic parameter used in
eq. (3) for reducing the rate of transmission. It is observed that overload status is received
when the transmission rate exceeds the Lower threshold value. The sender will adjust its rate
of transmission accordingly. When :
o RTRANS ≥ RLOW , corresponding value of I lies between 0.5 to 0.9 and the rate of
transmission is illustrated as
RTRANS + 1 = RTRANS (1 – I)

(5)

The transmission rate will be adjusted in the manner of PoR at the receiver side.
o RTRANS ≥ RUP, corresponding value of I will be 1 and the receiver side is regarded as
complete or severely overloaded. The rate of transmission will be illustrated as
RTRANS + 1 = RTRANS x I

(6)

Note that the working of the equation (5) and (6) is somewhat similar. The blocking
probability is lower when the transmission rate lies between lower and upper bound while it is max
during the complete or severe overload condition.
133

3.4 AIPC Constraints
• The overloaded server sends explicit congestion information to the proxy or neighboring server,
the sender side (receiving this information) needs to entirely adjust its transmission rate
accordingly. The complication lies here not in the rate adjustment but in determining the
appropriate overload information at the overloaded server. Hence, in our approach, we will
restrict the analysis to the conditions in which the overloaded servers send only implicit
congestion information, e.g., rejecting or dropping traffic. These mechanisms are already part of
the SIP specifications and do not require any additional logic at the receiving SIP proxies
server.
• We assume the overload notification purely based on closed loop feedback: Detection,
Signaling and Reaction. Detection phase will monitors the buffer utilization at Overload point
and collects data. Signaling phase will generate proper message response (5xx) and gives
feedback. The Reaction phase will refine the changes in the sending rate according to the
receiver failure message.

Figure 5
• Send routines should be non-blocking (asynchronous) whereas the receive routines can be
blocking or non-blocking.
• Actions are taken on the sending and receiving end through the message response buffer.
• The value of probabilistic factor can be negotiated between severs at service level, for adjusting
its sending rate at sender side, and for decreasing its receiver window at receiver side.
• Since data and signal take separate paths in SIP, hence, RTP stream does flow through the SIP
server and will not represent any load for it. [9]
• Do not confuse “imply” and “infer.”
3.5 AIPC Analysis Tools
For evaluation of our mechanism, we have used following tools for conducting the experiment:
1. Asterisk Server [14]: It is a complete PBX in software. Its runs on various platforms viz.
Linux, windows, MAC OS etc. It supports three way calling, caller ID services, ADS1, IAX,
SIP, H.32x, MACP and SSCP.
2. Star Trinity SIP tester [16]: It is a VoIP load testing tool which enables you to test VoIP
network, SIP Software and hardware. It can simulate thousands of incoming and outgoing SIP
calls with RTP streams. It can also analyze call and real time reports.
134

3. SIPp tool [15]: SIPp is a free Open Source test tool / traffic generator for the SIP protocol.
Features include dynamic display of statistics about running tests (call rate, round trip delay,
and message statistics) and dynamically adjustable call rates.
4. Average CPUcylce [13]: It is an open source tool used to analyze the CPU usage for specific
program and to find the total average CPU usage of a program for its entire uptime.
4. EXPERIMENTAL TEST BED
In this section, we describe our experimental setup used for the performance analysis of
AIPC mechanism under several load conditions. The test setup consists of sender and a receiver
emulated using a SIP tester. Major parts of the test setup are:
4.1 SIP Server
ASTERISK is used as a SIP server. It is an open source PBX machine in software.
4.2 Evaluation Machine
To analyze the CPU utilization, we have used AVERAGE CPUcycles on Linux console. This
is an open source tool used for measuring the CPU usage for specific program and to find the total
average CPU usage of program for its entire uptime.
4.3 Hardware configuration
The experiments are done with two systems in computer lab at BBD University, having
following configurations. The machine acting as a Server is Intel® Core 2 Duo 2.0 GHz processors
with 3GB ram and 160 GB disk drive.

Figure 6
The machine hosting UAS are Intel® Pentium®4 1.80 GHz processor with 1GB ram and 80
Gb disk drive. Both the machines run Ubuntu OS.
5. PERFORMANCE EVALUATION
For analyzing the scenario to an extent, SIP requests (INVITE) are sent to a proxy server.
Successful INVITE requests are followed by another two requests viz. ACK BYE. Rejecting
INVITE requests, thereby, will save the resources required for processing the INVITE request and
corresponding in-dialog request as well.
The goal of our experiment is to evaluate the ability of Sip Server to handle the number of
simultaneous requests during an overload condition. We evaluated the performance of AIPC during
several scenarios.
135


Sender

5.1 Assumption and Simulation
Due to the limitation of the traffic generator tool i.e. it’s simple and single threaded
architecture design, which prevents it from using the multiple cores at a time. Thus, to increase the
call capacity, it is required to run the processes of SIPp on multiple machines.
25500
25000
24500
24000
23500
23000
22500
22000
21500
21000
20500
20000
21000 21500 22000 22500 23000 23500 24000 24500 25000

Receiver

Figure 7
Fig. 7 illustrates the message transfer between sender and the receiver when there is no attack
or overload situation [2]
During the simulation, we observed that a single SIPp process on a machine can generate 250
simultaneous requests. Hence we adopted four machines to generate 1000 simultaneous requests. The
upper threshold beyond which the server gets overloaded is 1000. Ultimately the lower threshold is
assumed to be 500 simultaneous requests. Since the media stream and signaling follow separate path
in SIP, hence on the load on media stream will not affect the signaling stream.
For evaluating the blocking probability, we used the Star Trinity SIP tester. The Simulation
includes both single and load variance approach. Since AIPC aims at reducing the number of
rejections during an overload condition according to the capability of the server to handle the
simultaneous request.

Figure 8
(Source Star Trinity SIP Tester [16])
5.2 Result
For testing the performance of AIPC, the test cases are implemented on sender and receiver
separately. During no overload condition, there will no probability of rejection.
At Receiver Side
The AIPC will starts as the number of incoming request exceeds the Lower threshold. Fig. 9
and 10 illustrates the affect of Probability of rejection on number of incoming requests. There is
slight increase in the projection of rejection with the increase in the incoming request.
Fig. 11 illustrates the percentage reduction in the number of requests with the probability of
rejection with variable difference of 0.1. The slope in the figure represents the variance in the
reduction of incoming requests with the probability of rejection.
136


No. of Incoming Requests

At Sender Side
Sender side will reduce the rate of transmission or simply the number of request sent to the
simp
overloaded
1200
1000

Probabilit
y of
Rejection
Incoming
Requets

800
600
400
200

Rejected
Requests

0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Probability of Rejection

Figure 9

Rejected Requests

Incoming Requets

850

900

950

800
750
1000
855
650 700
550 600
595 720
500
375 480
195 280
120 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
55
0
0.1 0.2
0
0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Figure 10


100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%

Server
Overloaded
Rejected
Requests
Probability
of
Rejection

0 0.1
0.10.20.30.40.50.60.70.80.9 1

Figure 11
server as the Lower threshold is exceeded. The transmission rate is thus adjusted in accordance with
the table 1. No request will be entertained beyond the upper threshold. Table1 represent the effect of
probabilistic factor I on the outgoing request.
137

For smooth working of the AIPC mechanism, the triggering policies are based on the
response messages i.e. the AIPC is revoked on sender side till the overload response is received on
the sender side. It will automatically start increasing the rate of transmission linearly thereafter.
Fig. 12 illustrates the effect of AIPC mechanism on the rate of transmission at sender side. It
clear stated from the figure that the sending rate is inversely proportional to the probabilistic factor.
Only the initials requests i.e. INVITE messages are dropped by the AIPC mechanism at the sender
side. This will not only reduce the load on the overloaded server but also reduce the number of
resources required to process theses requests. It is because of the fact that a successful INVITE
message is followed by two more consecutive in-dialog messages viz. ACK and BYE.


1200
Probabilit
y of
Rejection

1000
800

Incoming
Requets

600
400

Rejected
Requests

200
0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Request
Processed


Figure 12
5.3 Tables
The table represents the effect of PoR on the outgoing request at sender side.

Prob. Of
Rejection
0

Table 1
Outgoing
Requests
500

Rejected
Requests
0

0.1

550

55

0.2

600

120

0.3

650

195

0.4

700

280

0.5

750

375

0.6

800

480

0.7

850

595

0.8

900

720

0.9

950

855

1

1000

1000

138

6. CONCLUSION
In our findings , we observed that the dropping the INVITE requests at sender side during an
overload condition , not only save the resources required to handle the requests but also reduces the
extra load on the Server as well. During an interoperability event, we measured the performance of
our server using a professional performance measurement tool and our server was able to fully
saturate the tool.
We thus, conclude that:

•
•
•

No. of requests processed

Successful INVITE requests are followed by another two requests viz. ACK BYE.
Sender drops the initial request while the receiver (Server here) reject the active sessions.
Finally, our simulation states that unresponsive active sessions can cause overload. AIPC
rejects these active sessions during overload condition.
Fig. 13 illustrates the performance comparison of AIPC mechanism with that of AIMD
mechanism. Our curve analysis shows that AIPC mechanism performs better during the overload
condition. The analysis is based on comparison between the previous and current simulation along
with the mathematical model.
2000
AIPC
Mecha
nism

1500
1000

AIMD
Mecha
nism

500
0
1 2 3 4 5 6 7 8 9 10 11
Time (ms)

Figure 13
FUTURE WORK
Our future can extend to analyze the working of AIPC mechanism in various types of attacks.
Also, enhancement tuning can also be performed in order to obtain customized result. This can be
done on the basis of complexity analysis.
REFERENCES
[1]

[2]
[3]

Italo Dacosta, Vijay Balasubramaniyan, IEEE, Mustaque Ahamad Patrick Traynor,
Member, IEEE “Improving Authentication Performance of Distributed SIP Proxies”,
IEEE Transactions On Parallel And Distributed Systems, Vol. 22, Issue: 11, pages: 18041812, November 2011
Bansal, A. , Kulkarni, P. ; Pais, A.R. “Effectiveness of SIP Messages on SIP Server”, 2013
IEEE Conference Information Communication Technologies (ICT), pages: 616-621.
Dorgham, John “Protecting VoIP Services against DoS using Overload Control”,
International Conference on Computer Communications and Networks , copenhegen,
october, 2008.
139

[4]

[5]

[6]
[7]
[8]

[9]
[10]

[11]

[12]

[13]
[14]
[15]
[16]
[17]

[18]

Dorgham Sisalem, John Floroiu “VoIP Overload, a Senders Burden” ,62-69 , International
Conference on Computer Communications and Networks (CCN-10), Orlando, USA, July
12-14, 2010
M. Ohta, “Simulation study of sip signaling in an overload condition.” In
Communications, Internet, and Information Technology, M. H. Hamza, Ed. IASTED/ACTA
Press, 2004, pp. 321–326
Book on “SIP Security”, Dorgham Sisalem, John Floroiu, Ulrich Abend, Henning
Schulzrinne , Wiley Publications 2009
Yunhong Gu, Xinwei Hong, and Robert L. Grossman, An Analysis of AIMD Algorithm
with Decreasing Increases, National Science Foundation
S. Poretsky , V. Gurbani, C. Davids , “ Terminology for benchmarking Session initiation
Protocol (SIP) Networking Devices”, Dorgham Sisalem, John Floroiu, Ulrich
Abend, Henning Schulzrinne , Wiley Publications 2009
Miroslav Voznak and Jan Rozhon, SIP End to End Performance Metrics, International
Journal Of Mathematics And Computers In Simulation . 2012
Robert Kuschnig, Ingo Kofler , hermann Hellwagner “Improving Internet video streaming
performance by parallel TCP-based request-response Streams “ In the proceedings of 7th
IEEE conference on Consumer Communications and Networking Conference (CCNC’10),
2010, pages:200-2004.
.R.N. Manda, R.A. Auguste “Proposed mathematical model for a SIP call”, In the
proceedings of International Conference on Multimedia Computing and Systems (ICMCS),
pages: 41-45, 10-12 May, 2012
Martin Rohricht, Roland Bless “Advanced Quality-of-Service signalling for the Session
initiation protocol (SIP)” In the Proceedings of first IEEE ICC 2012 workshop on
Telecommunications: From research to Standards, Ottawa, Canada, June 2012.
http://www.boray.se/software/averagecpu/
http://www.asteriskwin32.com/
http://sipp.sourceforge.net/
http://startrinity.com/VoIP/SipTester/SipTester.aspx
P.Vigneshwaran, Dr. R. Dhanasekaran, “A Novel Protocol to Improve TCP Performance –
Proposal”, International Journal of Computer Engineering Technology (IJCET),
Volume 3, Issue 2, 2012, pp. 12 - 18, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.
Sonia, Satinder Pal, “An Effective Approach to Contention Based Bandwidth Request
Mechanism in Wimax Networks”, International Journal of Computer Engineering
Technology (IJCET), Volume 3, Issue 2, 2012, pp. 603 - 620, ISSN Print: 0976 – 6367,
ISSN Online: 0976 – 6375.

140

50120140501015 2

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (16)

En vedette

En vedette (20)

Similaire à 50120140501015 2

Similaire à 50120140501015 2 (20)

Plus de IAEME Publication

Plus de IAEME Publication (20)

Dernier

Dernier (20)

50120140501015 2