Reliability engg and system safety science direct

Software Reliability Growth Modelling Framework to Study SDN

Controllers
Adarsh Anand*
Department of Operational Research, University of Delhi, Delhi, 110007, India
aanand@or.du.ac.in

Priyanka Gupta

Department of Operational Research, University of Delhi, Delhi, 110007, India

pgupta1@or.du.ac.in

Mohamed Arezki Mellal

LMSS, Faculty of Technology, M'Hamed Bougara University, Boumerdes, 35000, Algeria

mellal.mohamed@univ-boumerdes.dz

Corresponding Author*: aanand@or.du.ac.in

Abstract: SDN, as an emerging centralized network control platform, has been studied widely by many researchers.
To make this complex and fine-grained network platform more reliable and secure, the need to understand its fault
debugging pattern was observed. The testing phase of the software has undoubtedly been considered as a crucial
phase that ensures high quality network architecture to its users. The pre-release testing activities are solely
conducted by the testers where the debugging process after its release comprises both testers and users. The study of
the joint role of testers and users has been devoid in the field of network systems. This paper methodically models
the complete testing profile (before and after release) of the SDN Controller. The two-staged modeling process is
utilized to model the detection and resolution of network faults after its release in which the joint debugging
activities of testers and users are catered with the help of Stieltjes convolution. The two-stage model addresses the
release point transition. The proposal has been validated on two real life failure data sets. The validation shows
promising results.

Keywords: Software Defined Network, Software Reliability, Software Quality, Stieltjes Convolution, Two-staged
modeling

Highlights:

-1-
1 Introduction
The dimension to study the software systems corresponding to network architecture has become a new trend. With
the increase in the virtualization of network functions, its permeable nature has gained the attention of a lot of
researchers. The main aim to use these network devices is to create a virtual pathway, via which information can be
transferred among devices by setting up a communication channel. But unfortunately, these architectural wireless
devices are bound to be surrounded by failures regarding their overall quality or because of security issues
(Rohokale et. al., 2012). Therefore, many researchers or the management have started worrying about their
productivity. But somehow, these systems are considered to be one of the “Hard To Debug” systems. Several tools
like tcpdump, ping and netflow exist in the literature which helps the management to monitor their network devices
in a synchronized manner as well as provide guidance to work on their quality aspects. These tools try to restructure
the complex and dispersed state of network devices to bring out the most reliable quotient of network architecture,
which can provide a secure network platform to rely upon (Handigol et. al., 2012). But somehow because of their
multifaceted nature and danger to the economical and financial crisis, these tools were not stated as a reliable
measure to debug network devices, which then creates an interrupted network-flow. This interruption can be
malicious from the security perspective of the software system as well. As more abstractions are launched into the
market, the need to develop such a tool or a network structure in which different measures can be easily applied to
maintain the overall stability of the system has escalated.

Software Defined Network (SDN) as architecture was observed to address these issues. It has successfully
implemented network functions as a combination of hardware and software devices which have made it quite easy
for the management to make it “Error Free”. With its centralized management of network devices, this architectural
design makes the network system more secure and allows flexible deployment of applications into the system. SDN
as a network state is supervised to handle the dynamic resource management which then escalates the network
services. This programmatically controlled network architecture is well known to provide dynamic function
provisions, which have established intelligent service orchestration in the market. Its special ability to decouple the
network architecture and applications from its hardware along with the capability to provide flexible traffic
forwarding service has unavoidably gained all the attention. Further, in conjunction with optimal utilization of
network architecture, SDN can achieve several network control and management goals. Apart from providing the
benefit of virtualized technology, SDN has established itself as a platform that simplifies network operations,
leverages standard servers, and provides better scalability, reliability, and security, which are described as some of
the important attributes of software quality (Gupta et. al., 2021). It also resembles a key technology that has
applications working on high-performance switches and servers.

Moreover, the major advantage to use SDN as network architecture lies in the fact that it disintegrates the control
plane from the data forwarding plane to bring better flexibility to the network system (Li et. al., 2015). This
architecture jointly deals with its enhanced configuration and performance by behaving like a centralized control
unit. With its intelligence, speed, the art of easy network management, and multi-tenancy, this architecture has been
widely adapted by people interested in better network services (Hu et. al., 2014). Further, the ideology to forward
the packets (data/information) in this networking environment is handled by SDN’s Controller. These devices are
responsible for selecting the server and the path connected to it, and then finally pushing the data entries along the
chosen way. Moreover, the operational behavior of these controllers is similar to that of any existing software device
which makes it easier for the management to plan and work on their quality aspects.

Since the SDN Controllers represents an Open Source Software (OSS) system, thereby they reflect upon all the
advantages that come along while using this technology. They provide unrestricted access to their source code,
flexible portability, user-friendly network system, high-reliability levels, and many more to their network users
(Singh et. al., 2021). These open systems are frequently described as an artistic way to satisfy fore-coming complex
concerns which have been effectively portrayed in the previous research (Bonaccorsi et. al., 2003). Keeping that in

-2-
mind, the OSS form of SDN Controllers is readily accepted by the market, even after facing the challenge of
spontaneous and decentralized functioning. But due to this open availability, they are often surrounded by cyber
attacks to control the network system which can be harmful for the organization as well as for its users. Thereby the
need to develop a more secure network system was identified which was well handled by the management and the
researchers. They have worked towards studying the actual pattern of occurrence of faults in the network system, if
identified, can do wonders for them.

Further, similar to the life cycle of a general OSS system, these SDN Controllers are also developed by testers and
then launched into the market where any individual can have access to their source code. The existing error-
proneness or complexity in their network structure makes it reasonable to assume that the Controller’s system will
be surrounded by errors all over its productive life cycle leading to compilation faults, logical bugs, or cyber attacks.
To make better network routing decisions, many researchers have tried to capture the debugging phenomenon of the
occurred faults. They have started developing models to predict their fault content or have even planned on their
next release policies and time to stop debugging activities. Precisely, all the domain expertise is working in this
direction to have an accurate prediction of the fault content so that they can minimize the impact of network failures
and increase the overall security of the system. Alongside them, the SDN Controller’s development team applies
their efforts to make it error-free but the presence of faults in the operational state of the system can’t be denied.
Users are encountered with errors which can lead to minor to major discomfort incorporating financial and
economic losses (Online Article, top software failures). Therefore, making it necessary for the network management
industries to build a reliable network environment and extend their support even after it has been launched in its
dynamic market.

Since the fundamental of the governance structure of SDN Controllers does not differ from that of the general
software system, both the testing team and the users willingly participate in the Controller’s debugging-related
activities. Also, the degree of involvement of motivated users in developing the prestige of the network architecture
is observed to be higher in these open operating systems. Further, to understand Controller’s debugging
phenomenon in a better way, a detailed description is provided. The whole life span of the Controller system is
broadly classified into two segments: Before its launch and After its launch. All along the first segment, testers have
their exclusive authorization. Due to this easy and broad access, they are subject to the identification and eventual
removal of the faults. Further, during the second segment i.e. after its launch, users are introduced to the system. The
debugging activities in this phase witness the mutual presence of testers and users, which have now a day’s become
a new paradigm of development of many SRGM.

Synonymous with the above-explained ideology, numerous articles are present in the literature on software
reliability which deals with the joint involvement of users and testers in making the software more reliable (Anand
et. al., 2018). The fact that operational phase of the software has been given required attention in estimating the
overall reliability of the software, is thoroughly described by (Anand et. al., 2019). Further, a lot of work has been
done to incorporate the impact of testers and users in the modeling framework whose obtained results can be directly
applied in the context of SDN Controllers as they are nothing but a kind of software programs dealing with network
issues. Moreover, it was analyzed that, the second segment of the software’s/Controller’s development cycle i.e.
Operational phase, is distinctly difficult to understand and hence requires regressive exploration strategies. Here, the
network user reports any of the faced shortcomings to the testing team who are alongside involved in a similar
process to detect any of the loopholes present in the code. After its revelation, remedial efforts are taken in the SDN
Controller to remove them. Literature is flooded with articles based on this particular concept of detection and
fixation of logical bugs.

But somehow they lag in the small detail about the debugging process. It was assumed earlier that each time a
network bug is encountered/detected, the testing team scrambles to resolve that problem. A fault is removed/fixed as
soon as it is encountered. But after a close look at the problem, it was decoded that during the Controller’s
maintenance/operational phase, the mechanism of bug removal indeed follows a two- phase pattern. In its first

-3-
phase, its acknowledgment is done either by the testers or users and in the second phase, suitable actions are taken
by the testing team to remove them. The authors have utilized the aforesaid concept in this proposal. They have
bifurcated the time line of the SDN Controller into two segments namely before release and after release. The
network faults occurring before its release are catered by a single-phase approach, whereas the after-release
phenomenon is methodically modeled by adapting a two-phased approach for the detection and removal process
being done under the conjoint supervision of testers and users.

Figure 1: Testing Profile of a SDN Controller

To have a clear understanding of the scenario, pictorial representation is presented in Figure1. Before the launch of
the Controller into its potential market, the fault eradication process is assumed to follow the one-phase model
asymptotic to that of the Goel-Okumoto model (1979). But as soon as it is launched in the market, the whole
debugging process takes the shape of a two-phased process, which works in line with one of the acclaimed models
in the literature of Software Reliability i.e. Delayed S-shaped model (Yamada et. al., 1983). The dotted portion in
the figure is used to distinguish between the detection process and the removal one. For the detection of faults,
integrated efforts of the individuals involved in the testing process of the SDN Controller and the end-users are
employed parallelly. After being notified to the testers, remedial efforts are taken to remove faults, thereby trailing a
two-phased approach.

Figure 2: Representation of a bug report

Furthermore, to provide affirmation of the aforesaid concept, authors have tried to present some validation proofs on
real-life data sets of SDN Controllers. They have selected “Open Network Operating System i.e. ONOS” which is

-4-
one of the well-known SDN Controller. Further, the Controller’s development teams utilizes “Jira Platform” to track
the product’s roadmap of its progress, error reports and their respective status, release planning and many more, with
complete visibility for its users (Online article, atlassian.com, Accessed date: 3/6/2020). It, therefore, acts as a hub
of different failure data sets. From them, authors have picked up the failure data set corresponding to one of the
releases of SDN Controller (Online article, onosproject.org, Accessed date: 3/6/2020), to showcase the validation for
utilizing a two-staged bug removal process after the release of the Controller. Figure 2 represents a vivid picture of
one of the occurred faults along with its details (Online article, jira onosproject.org, Accessed date: 2/11/2021). It
can be concluded from the figure that the date’s section is categorized into two stages namely created, and updated.
The presence of these stages has provided sufficient valedictory proof to consider the governance structure of bug-
removal phenomenon in Controller is nothing but a multi- stage process. Therefore, the authors have trailed two-
staged methodology in the presented article.

To conclude the article, the authors have presented the process of debugging faults through two of the most
important phases of the life cycle of SDN Controllers i.e. Testing phase and the Operational phase. They have
assumed that before the release of Controllers in the market, the debugging process of faults follows a single-stage
process whereas, after its release, it was converted into a two-staged modeling process taking care of the detection
and fixation of faults. Further, once released, then the involvement of both testers and network users are involved in
the study. For the said purpose, the utilization of convolution theory (Agarwal et. al., 2017) is done. The validation
of the whole study was done on two real-life failure count data sets of SDN Controllers.

The remainder of the paper is organized as follows: Section 2 presents a Literature review. Section 3 has dealt with
the utilized notations followed by mathematical modeling in Section 4. Data validation is illustrated in Section 5.
Furthermore, Results discussion is presented in Section 6. Later on, the implications for practice and conclusion are
presented in the Section 7 and 8 respectively, traced by References at the end.

2 Literature review

The importance of software’s reliability during its testing and operational profile was well discussed by Yang et. al
(2000). Kapur et.al (2007) came up with the idea of fault removal efficiency in the operational phase of project and
product type software. Researchers have also presented the mathematical framework for the existence of bugs in the
operational phase of the software (Garmabaki et. al., 2014). Apart from this, the authors in (Okamura et. al., 2015)
have brought forward the combination of distinct SRGM with regression schemes and estimated various reliability
measures in the field of OSS. Ullah et. al., (2015) has talked about the residual defects found in the software system
and have talked about their predictive algorithm in making the open source software more reliable. Researchers have
articulated the testing and operational profile of the software in the framework of multi up-grades (Anand et. al.,
2015). A mathematical model representing the removal process of faults along with vulnerabilities in which users
and testers are present, combined with their patch-related policy has been discussed by Anand et al., (2018). Further,
Das et. al., in (2020) has specifically talked about the implication of two staged modelling framework (observation
and correction) in the framework of multi release of the software system incorporating the effects of imperfect
debugging and fault generation. Apart from these articles, the faults concerning to security of the software system
have been addressed by many researchers which have contributed towards increasing software’s overall quality
(Anand et. al., 2021, I). Anand et. al. (2021, II) have showcased the influence to show the joint impact of testers and
users in making the software more reliable. Kaur et al., (2021), have claimed the usage of convolution theory to
demonstrate the presence of users and testers in the debugging process and further talked about the influence of
infected patch in the software system.

The ideology of detection and fixation of faults corresponding to SDN Controllers was thoroughly studied by
Vizarreta et al., (2017). They were the first one to deal with the process of detection and fixation of network faults
for SDN Controllers. In their study, they have deliberately shown the application of some of the well-known SRGM
in this dimension. Later on, few researchers have extended their study by discussing the optimal time to release the

-5-
SDN Controllers in the market (Vizarreta et. al., 2018). Further, the survival backup strategy with respect to
Controller platform was discussed by Alowa et al., in (2022).

3 Notations
: Software’s release time

: Faults eradicated up to time in totality

: Number of encountered faults till

: Number of resolved faults till

: Initial fault content lying in the software
: Steiljes Convolution

4 Modelling framework
In this section, the mathematical formulation of the above-explained concepts is showcased. To enhance the
readability, they have represented the mathematical equation for the fault counting process of each segment of the
SDN Controller separately. The detailed process is explained as below:

The bifurcations of the length of Controllers life cycle into its subcomponents are namely: before and after release.

4.1 Before Release

During this time period, the testing team is the sole identity that has complete hold of the Controllers. Therefore,
they are responsible for detection and then eventual removal of the encountered faults, which is assumed to be
governed by a single-phase approach as explained earlier.

To represent this scenario mathematically, the widespread usage of NHPP models and their basic assumptions have
been traced (Kapur et. al., 2011; Deepika et. al., 2017). The differential equation used to estimate the fault removed
at any particular time point from the SDN Controllers point of view can be represented as:

(1)

where represents the rate by which people involved in the testing process is removing any of the faced

shortcomings and symbolizes the hazard rate function for 1st segment. Solving the above-stated differential
equation, obtained results are represented as:

(2)

-6-
It should be noted that Equation (2) is in tune with the concept of unified approach (Anand et. al., 2020).
Furthermore, the authors have assumed that the fundamental premise of the model is based on the exponential rate

of correction of errors by the testing team i.e. follows an exponential distribution with rate .

Incorporating this, the faults removed in the concerned software upto the time of its release i.e. , is represented as:

(3)

4.2 After Release

Once the concerned software is launched in the market, the involvement of both users and testers in the debugging
of the software can be easily seen. Apart from this, the application of a two-phase methodology to understand the
detection and removal of faults has been studied in this section of the article. Therefore the mathematical equations
are developed on similar lines.

For the detection process of faults, the concept of Stieltjes Convolution theory is utilized to take care of the
integrated accountability of the end-users and the testing team. The differential equation represented in equation (1)
can be modified as:

(4)
where, and are parameters to trace the fault detection rate of testers and users during the first phase of the
2nd segment respectively, and depicts the faults which are not removed until the release of the Controllers and
can be represented as:

(5)

The above explained equation (4) can be simplified to get:

(6)

Moving on the second phase of the two-phased approach, out of the faults which were detected along with the first
phase (as obtained from equation 6) will now undergo the removal process under the supervision of the testing team.
The differential equation framed for such case is represented as:

(7)

where symbolizes the removal rate of errors followed by the testing team. To stabilize the degree of field

support, its hazard rate function is assumed to be .

-7-
Therefore, Equation (7) can be simplified to get the following equation:

(8)

To solve the above-stated differential equation, one can substitute the value of detection function i.e. and
can obtain the different forms of the fault removal function.

Furthermore, the total counts of eradicated faults all along the life cycle of the Controllers can be concluded by the
following equation:

(9)

Since the motive of the proposal is to make the readers understand the utilization of this two-stage process along
with different detection rates of the users or the testing team and its impact on the overall failure function. For the
said purpose, the authors have specifically talked about the different distribution functions which can be assumed by
both the testing team and users.

To do what is stated above, they have considered a scenario in which the management has decided that the rate of
field support activities as provided by the testers will follow an exponential distribution with parameter .Apart
from this, the involvement of users has always been an issue of concern. A mere assumption cannot be made by
their involvement process as it depends upon several other factors including various competitive or market
conditions. To rescue management from this problem, the authors have given a check that what will be the changes
in the values of remaining fault content and reliability of the Controller once the involvement of using a team is
slightly varied. Therefore, the authors have developed three cases dealing with diverse fault detection rates of the
users which are presented as follows:

Case I: Failure detection rate followed by the users is constant i.e.

Under this scenario, the failure detection rate followed by users is assumed to be constant and that of the
testing team is assumed to be following exponential distribution with parameter .
The eventual faults detected using the assumed distributions and Equation (6) can be represented as
follows:

(10)

When this obtained equation of detection rate function is substituted in Equation (8), the eventual number
of faults removed during the operational phase of the software system is obtained. The resultant equation
can be represented as

(11)

Furthermore, the total count of faults removed all along the life cycle (testing phase and operational
phase)of the concerned software can be evaluated using Equations (9) and (11), which can be expressed as

(12)

-8-
Case II: Failure detection rate followed by both users and testers is following exponential distribution with
parameter .
Once the said conditions about the behavior of testers and users are followed, the count of faults detected
and removed can be represented by the following equations respectively:

(13)

(14)

Similarly, the total counts of eradicated faults all along the life cycle of the Controllers can be concluded as
follows:

(15)

Case III: Failure detection rate followed by users and testers are following exponential distribution with
parameter and , respectively.
Under this scenario, the eventual equation used for estimating the faults detected in the operational phase of
the concerned software can be represented as

(16)

And out of the faults detected, the equation to estimate the number of faults which will be eventually
removed can be represented as

(17)

Furthermore, the equation represented the total faults removed all along the life cycle of the software, in
this case, can be represented by:

(18)

Further, it can be concluded from the above-presented equations that even the slightest variation in the
detection pattern of faults has led to the complete change in the final expression for the latent fault removed
in the operational phase of the Controllers. The rationale behind developing such equations is to project the
comparison between these diverse detection programs.

-9-
 Moreover, to justify the validation of the above-developed mathematical formulations, authors have
presented their validation on real-life data sets. Before going into its details, brief descriptions of the data
sets are provided in the next section of the article.

5 Numerical Analysis

Data Description
To proceed with the analysis, two real-life authentic OSS data sets of SDN Controllers have been manually
extracted from an Open Source data provider (Online article, onosproject.org, Accessed date: 3/6/2020).
The two data sets comprise fault reports of the Tenth and Eleventh versions/releases of the renowned
projects namely “Kingfisher” and “Loon”, which are obtained from (Online article, jira.onosproject,
Accessed date: 26/12/2020). Further, details about the involvement of users in the operational phase and the
release cycles of both versions are explicitly mentioned in their description. The data sets are accordingly
extracted, taking care of the faults before their release and even after it. More details about the chosen data
sets are provided along with the data analysis part.

Model Validation
For the model validation, the “Non-Linear Ordinary Least Square method” along with statistical software
SAS has been employed to determine the parameter estimates. The evaluated results for both release
versions with their appropriate explanations are provided as follows.

Data Set I (Kingfisher Release)

The parameter estimates for this particular release version of SDN Controllers are presented in Table 1.
Since, the actual data set contains 517 faults occurring in the duration of 16-time units where the release
was observed to occur at the 8-time point. All the three cases were seen to slightly overestimate the
occurred faults. But the closest bit was observed to be from the first case i.e. the predicted value of network
faults deviates less from the original data set as compared to any other model. Further, it was observed that
before Controller’s release, all the three cases behave asymptotically to each other i.e. the fault removal rate
before the launch of SDN Controllers was almost equal for all the cases. Infact, after its release, the
difference between the fault detection rates can be clearly observed.

Moreover, to undergo the optimal model selection process and to determine the credibility of the findings,
the authors have selected the widely used 4 goodness of fit criteria whose values for different models are
presented in Table 2.

Table 1: Parameter estimates

Case 1 Case 2 Case 3
a 522.353 524.076 525.313
b1 0.128 0.132 0.131

b2 0.711 0.971 0.971

b3 -- -- 0.921

Table 2: Comparison Criteria

Criteria Case 1 Case 2 Case 3
SSE 11861.7 15534.1 15724.3
MSE 847.3 1109.6 1123.2
RMSE 29.107 33.31 33.513

- 10 -
 R2 0.971 0.962 0.961

It can be inferred from Table 2 that all the comparison criteria are pointing in one direction, i.e. Case 1
outperforms each one of the prescribed models/cases. This provides a clear indication that for this
particular data set, the conjoint fault detection pattern described in Case 1 has produced valuable visual
results. This observation of the simple model behaving best appears to be in line with the Principle of
Occam’s razor (Moser et. al., 2008) which states that if the simpler modeling serves the underlined
purpose, there is no need to go for complex ones.

Table 3: Phase wise representation of fault removed and detected

Case1 Case2 Case3
Phase I Removed 335.694 341.662 342.179
Phase II Detected 186.027 181.734 182.311
Removed 182.415 179.395 179.755
Left Over 4.247 3.019 3.379

Moreover, to understand the working of the models in a better way, Table 3 has been designed, which
systematically represents the numeral value of faults encountered and removed for three described cases
respectively for both the phases. While having a close look at the first scenario, a contradictory conclusion
can be made that, this particular case has the highest value of but it also attains its maximum value for
the residual fault content in the SDN Controller. Moreover, despite having less value of as compared to
case 1, the remaining scenarios have the lowest amount of left over network fault content. But since they lie
in a very close neighborhood of each other, therefore it can be interpreted that, on the behavior front there
is no major difference between the Models 2 and 3.Furthermore, a graphical representation of the predicted
vs. actual data set for the three underlined cases is presented in Figure 3.

Figure 3: Graphical representation of fault prediction for Data set I

Data set II (Loon Release):

The obtained values of the parameter and the distinct comparison criteria’s values for the “Loon” release
version of SDN Controllers are presented in Tables 4 and 5, respectively. It should be noted that the actual
data set of this release contains 485 faults occurring in the duration of 16-time units where the release was
observed to occur at the 9-time point. Interpretations analogous to the first data set can also be made from

- 11 -
this particular data set. It can be interpreted from tables that the predicted fault content was closest in case 1
as well as this case performs best on grounds of different performance criteria.

Therefore, this data set also provides the affirmation that the conjoint detection pattern in case 1 has proven
to be the best among all and have provided the best outcome.

Table 4: Parameter estimates

Case 1 Case 2 Case 3
a 501.2 503.62 506.62
b1 0.160 0.161 0.162

b2 0.461 0.677 0.62

b3 -- -- 0.462

Table 5: Comparison Criteria

Case 1 Case 2 Case 3
SSE 3377 3807.5 4266.6
MSE 241.2 272 284.4
RMSE 15.5312 16.491 16.865
R2 0.987 0.985 0.983

Asymptotic to Table 3, the faults discovered and removed in each phase are presented in Table 6.
Furthermore, a graphical representation of the predicted vs. actual data set for the three underlined cases is
presented in Figure 4.

Table 6: Phase wise representation of fault removed and detected

Case1 Case2 Case3
Phase I Removed 383.133 385.332 388.926
4
Phase II Detected 115.088 114.928 108.643
Removed 104.131 107.244 96.563
Left Over 13.936 11.046 21.131

Moreover, Figures 3 and 4 have clearly picturized a sudden deflection in the graph at the release point. This
can be attributed to the impact of including users at this point due to which a surge in the testing effort and
the number of defects found in the SDN Controller is observed. It can be concluded that generally after the
release time point, the pace of the Controller stabilizes and gets smoother.

- 12 -
 Figure 4: Graphical representation of fault prediction for Data set II

6 Results and Discussion

A direct implication of the above presented work can be easily made. For both release versions of SDN Controllers,
the residual amount of fault content was lowest in Case 2 (See Tables 3 and 6, in which the detection pattern of both
the testers and users were assumed to be following exponential distribution with the same parameter). This has
significantly proven the fact that somehow in terms of efficiency and quality aspects of the Controller system, Case
2 outperforms all the prescribed cases. But on the grounds of various Comparison Criteria (See Tables 2 and 5), the
analysis has somehow failed to follow a similar pattern. It was observed that Case 1 was the best predictor amongst
all three cases.

Therefore, it can be concluded for all these calculations that, the detection pattern described in Case 1 is being
followed by the management. But, since the lowest networking faults were achieved in Case 2, it can be said that, if
instead, they would have been tracing the detection pattern as described in this case , then it could have a been
golden opportunity for the company’s profile.

Furthermore, based on several analyses and the past behavior of the Controller, the guess estimate of faults present
in it is made at its initial stages. The management can then take the necessary steps to have control over their
detection policy. It is clear from the obtained results that if they will trace the detection pattern as described in Case
2, they will be able to deliver a more reliable and less fault prone software network environment to its users.

Moreover, the overall contribution of the presented article can be stated that this article is attempts to make the
management of SDN Controllers understand the actual pattern via which the fault debugging phenomenon is
happening in the system. The authors have worked up on improving the various aspects of the quality of the network
architecture by discussing the route traced by the occurred faults before its eventual removal from the system.

To understand the debugging phenomenon of these network devices in a better way, authors have bifurcated the
Controllers development cycle into two parts. Before the launch of SDN Controllers into the market, authors have
modeled the fault removal phenomenon with the help of a single-phase model. Whereas once being launched, they
have shifted the modeling framework to a two-staged process which particularly caters to the detection and fixation
of occurred network faults. Further, the work presented here also talks about the joint presence of users and testers
for the detection of faults, which has been catered to using the convolution process. To show the validation of the
formulated model, real-life SDN Controller failure data sets were extracted which have shown the perfect fit for the
prescribed framework.

- 13 -
7 Implications for practice

This article tries to deal with the more practical concerns of the management regarding the existing faults in the
SDN Controller. The programmers aim is to develop such a secure network controller which can perform well in its
quality aspect as well as can meet the needs of its users while working efficiently along with all its phases .Since one
cannot eradicate the probability of occurrence of network-related faults in their system therefore researchers have
worked towards developing such a model which predicts the actual fault content in the controller system. This
article is an attempt in that direction which precisely deals with the overall faults in the software, their detection,
fixation phenomenon, and the involvement of testers and users in the detection of faults in the network system.
Along with this, the presented combination of a single-staged and two- staged modeling framework to study the
actual debugging pattern in network devices before and after the release of SDN Controllers respectively seems to
be helpful for the SDN programmers to maintain the quality and reliability of the released system.

8 Conclusions
In the field of network optimization, the idea to study SDN architecture and its Controllers system is quite
renowned. Different models and tools are developed which tries to enhance its overall quality during different
phases of its life cycle. Inline with this, both the testing team and users were seen to be jointly working on the
detection of network-related faults to make a reliable, secure, and productive network environment that can do
wonders in the networking area. This article is an attempt in this direction to study the fault debugging phenomenon
in two of the phases of its life cycle, i.e. testing and operational phase, using Single and Two-phased modeling
frameworks, respectively. The paper addressed the aspects of faults debugging in the context of detection and
removal of faults deliberately involving the impact of programmers and the network users who will be the eventual
individuals who are facing difficulties. Three special cases dealing with different conjoint detection patterns of
testers and users have been presented. The model validation has been done on two real-life data sets and their
required interpretations have been successfully made.

Declarations

The authors have no relevant financial or non-financial interests to disclose.

Acknowledgement:
Funding: This research did not receive any specific grant from funding agencies in the public, commercial, or not-
for-profit sectors.

Declaration of Competing Interest: The authors declare that they have no known competing financial interests or
personal relationships that could have appeared to influence the work reported in this paper.

References
Agarwal, M., Aggrawal, D., Anand, A., & Singh, O. (2017). Modeling multi-generation innovation adoption
based on conjoint effect of awareness process. International Journal of Mathematical, Engineering and
Management Sciences, 2(2), 74-84.
Alowa, A., Fevens, T., & Khamayseh, Y. (2022). Survival backup strategy for controller placement problem
in Software Defined Networking. Computer Communications, 185, 104-117.
Anand, A., & Ram, M. (Eds.). (2018). System Reliability Management: Solutions and Technologies. CRC
Press.

- 14 -
Anand, A., & Ram, M. (Eds.). (2019). Recent Advancements in Software Reliability Assurance. CRC Press.
Anand, A., Bhatt, N., Kaur, J., & Tamura, Y. (2021), (I). Time Lag-Based Modelling for Software
Vulnerability Exploitation Process. Journal of Cyber Security and Mobility, 663-678.
Anand, A., Das, S., Agarwal, M., & Inoue, S. (2021), (II). An optimal scheduling policy for upgraded
software with updates. International Journal of Quality & Reliability Management, 39(3).
Anand, A., Gupta, P., Klochkov, Y., & Yadavalli, V. S. S. (2018). Modeling Software Fault Removal and
Vulnerability Detection and Related Patch Release Policy. System Reliability Management: Solutions and
Technologies, 19.
Anand, A., Gupta, P., Tamura, Y., & Ram, M. (2020). Software Multi Up-Gradation Modeling Based on
Different Scenarios. In Advances in Reliability Analysis and its Applications (pp. 293-305). Springer, Cham.
Anand, A., Singh, O., & Das, S. (2015). Fault severity based multi up-gradation modeling considering testing
and operational profile. International Journal of Computer Applications, 124(4).
Bonaccorsi, A., & Rossi, C. (2003). Why open source software can succeed. Research policy, 32(7), 1243-
1258.
Das, S., Anand, A., Agarwal, M., & Ram, M. (2020). Release time problem incorporating the effect of
imperfect debugging and fault generation: an analysis for multi-upgraded software system. International
Journal of Reliability, Quality and Safety Engineering, 27(02), 2040004.
Deepika, O. S., Anand, A., & Singh, J. N. (2017). Testing domain dependent software reliability growth
models. International Journal of Mathematical, Engineering and Management Sciences, 2(3), 140-149.
Garmabaki, A. H., Kapur, P. K., Aggarwal, A. G., & Yadavali, V. S. S. (2014). The impact of bugs reported
from operational phase on successive software releases. International Journal of Productivity and Quality
Management, 14(4), 423-440.
Goel AL, Okumoto K (1979) Time dependent error detection rate model for software reliability and other
performance measures. IEEE Trans Reliab R-28(3):206–211
Gupta, P., Anand, A., & Ram, M. (2021). Reliability as Key Software Quality Metric: A Multi-Criterion
intuitionistic Fuzzy-Topsis-Based analysis. International Journal of Reliability, Quality and Safety
Engineering, 2140003.
Handigol, N., Heller, B., Jeyakumar, V., Maziéres, D., & McKeown, N. (2012, August). Where is the
debugger for my software-defined network?. In Proceedings of the first workshop on Hot topics in software
defined networks (pp. 55-60).
https://jira.onosproject.org/browse/ONOS8148?jql=project%20%3D%20ONOS%20AND%20resolution
%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC, Accessed
date 2/11/2021.
https://jira.onosproject.org/secure/ManageFilters.jspa?filterView=popular, Accessed date: 26/12/2020
https://wiki.onosproject.org/display/ONOS/ONOS, Accessed date 3/6/2020.
https://www.atlassian.com/software/jira , Accessed date 3/6/2020.

- 15 -
https://www.computerworld.com/article/3412197/top-software-failures-in-recent-history.html#slide1
Accessed date: 22/12/2020
Hu, F., Hao, Q., & Bao, K. (2014). A survey on software-defined network and openflow: From concept to
implementation. IEEE Communications Surveys & Tutorials, 16(4), 2181-2206.
Kapur, P. K., Gupta, A., & Jha, P. C. (2007). Reliability analysis of project and product type software in
operational phase incorporating the effect of fault removal efficiency. International Journal of Reliability,
Quality and Safety Engineering, 14(03), 219-240.
Kapur, P. K., Pham, H., Gupta, A., & Jha, P. C. (2011). Software reliability assessment with OR
applications (p. 364). London: Springer.
Kaur. J, Anand, A., Singh, O., & Kumar, V. (2021). Measuring software reliability under the influence of an
infected patch. Yugoslav Journal of Operations Research, 31(2)), 249-264.
Li, Y., & Chen, M. (2015). Software-defined network function virtualization: A survey. IEEE Access, 3,
2542-2553.
Moser, R., Pedrycz, W., & Succi, G. (2008, May). A comparative analysis of the efficiency of change metrics
and static code attributes for defect prediction. In Proceedings of the 30th international conference on
Software engineering (pp. 181-190).
Okamura, H., & Dohi, T. (2015, November). Towards comprehensive software reliability evaluation in open
source software. In 2015 IEEE 26th International Symposium on Software Reliability Engineering
(ISSRE) (pp. 121-129). IEEE.
Rohokale, V. M., Prasad, N. R., & Prasad, R. (2012). Cooperative wireless communications and physical
layer security: State-of-the-art. Journal of Cyber Security and Mobility, 226-249.
Singh, V., Bongiovanni, B., & Brandon, W. (2021). Codes of conduct in Open Source Software—for warm
and fuzzy feelings or equality in community?. Software Quality Journal, 1-40.
Ullah, N. (2015). A method for predicting open source software residual defects. Software Quality Journal,
23(1), 55-76.
Vizarreta, P., Trivedi, K., Helvik, B., Heegaard, P., Blenk, A., Kellerer, W., & Machuca, C. M. (2018).
Assessing the maturity of sdn controllers with software reliability growth models. IEEE Transactions on
Network and Service Management, 15(3), 1090-1104.
Vizarreta, P., Trivedi, K., Helvik, B., Heegaard, P., Kellerer, W., & Machuca, C. M. (2017, November). An
empirical study of software reliability in SDN controllers. In 2017 13th International Conference on Network
and Service Management (CNSM) (pp. 1-9). IEEE.
Yamada S, Ohba M, Osaki S (1983) S-shaped software reliability growth modeling for software error
detection. IEEE Trans Reliab R-32(5):475–484
Yang, B., & Xie, M. (2000). A study of operational and testing reliability in software reliability
analysis. Reliability Engineering & System Safety, 70(3), 323-329.

- 16 -
Biographies

Dr. Adarsh Anand completed his doctorate in the area of Software Reliability Assessment and Innovation
Diffusion Modeling in Marketing. Presently he is working as an Assistant Professor in the Department of
Operational Research, University of Delhi (India). In 2012, he was conferred with the Young Promising
Researcher in the field of Technology Management and Software Reliability by Society for Reliability
Engineering, Quality and Operations Management (SREQOM). He is a lifetime member of the SREQOM. He
is also on the editorial board of the International Journal of System Assurance and Engineering Management
(Springer). He has guest edited several special issues for journals of international repute. He has edited books,
System Reliability Management (Solutions and Technologies) and Recent Advancements in Software
Reliability Assurance, under the banner of Taylor and Francis (CRC Press). He has edited a book, Systems
Performance Modeling with De Gruyter and another System Assurances (Modeling and Management) with
Elsevier (Academic Press). He has also authored textbooks, Market Assessment with OR Applications and
Social Networks: Modelling and Analysiswith Taylor and Francis (CRC Press). He has publications in
journals of national and international repute. His research interests include modeling innovation adoption and
successive generations in marketing, software reliability growth modeling and social network analysis.

Priyanka Gupta is presently pursuing her PhD from University of Delhi, Delhi (India). Prior to this, she has
completed her M. Phill degree (in Software Reliability) in 2018 from University of Delhi, Delhi (India). Her
articles can be found in some of the acknowledged books and Journals of software Reliability. She has
presented her work in many national and international conferences. Her research area includes software
reliability assessment and Multi Criteria decision making.

- 17 -