## 4 Discussion and Conclusions  
Troubleshooting in cellular networks is essential due to the nature of the networks' components, hardware, and software problems. Considering the competitive world among cellular network operators, the need for automatic fault detection and identification of the causes of faults, so as to restore the network to its normal mode, have become increasingly apparent. This article aimed to provide a framework for automatic fault detection and investigation of the cause of a fault to help the human resources in this field. This article was based on scientific principles and sought to solve problems in the industry, and its modeling was performed in consultation with experts in the field. Unlike other research conducted in this field, this research had different data sources, and by using the ability of the data to check the network mode from different perspectives, it identified faults with higher accuracy and exhibited greater ability to analyze the cause of fault. In addition, the proposed model had the most negligible dependence on experts in building the model and its initial assumptions. Therefore, it was immune to human faults and experts' taste. \begin{table}
\begin{tabular}{c c c c c c c c c} \hline \hline
**ID** & **C/I** & **RxLe** & **RxQual** & **TA** & **SDCong** & **SDDrop** & **SDestab** & **TCHCong** & **TCHassign** \\ \hline
1 & 11.4 & \(-91\) & 7 & 2 & 0.42 & 0.79 & 96.71 & 2.2 & 2.77 \\ \hline
2 & 17.9 & \(-79\) & 0 & 1 & 6.61 & 0.53 & 97.56 & 0 & 0.49 \\ \hline
3 & 13.2 & \(-76\) & 4 & 2 & 1.41 & 0.38 & 98.11 & 0 & 1.09 \\ \hline
4 & 8.7 & \(-79\) & 7 & 3 & 0 & 0.27 & 88.11 & 0 & 0.34 \\ \hline
5 & 11.7 & \(-77\) & 4 & 3 & 0 & 3.71 & 88.20 & 0 & 1.39 \\ \hline
6 & 12.5 & \(-82\) & 5 & 1 & 0.43 & 0.46 & 96.17 & 1.81 & 14.54 \\ \hline
7 & 13.1 & \(-83\) & 6 & 1 & 0 & 1.27 & 89.18 & 0.24 & 22.16 \\ \hline
8 & 15.4 & \(-91\) & 7 & 2 & 0 & 1.31 & 96.86 & 0 & 5.11 \\ \hline \end{tabular}
\end{table} 
Table 10: Comparison of drive test information and performance support system for blocked calls. Finally, in responding to the needs of experts, this model had a minor dependency on human resources and could continue to work without human resources' intervention. In this paper, the general framework of the activities was shown in \"Fault! Reference source not found\". The considered input sources were performance support system data, drive test data, and data related to customer complaints. Fault detection in the case of the first two categories of data, performance support system data and drive testing, was performed by methods fully explored in the second and third sections. Faults identified from the data sources were entered into the \"combining data\" section, along with potential subscriber complaints. In this part, faults were collected together with the knowledge extracted from the previous steps, and a decision was made for an area. Therefore, the input of the three parts, \"performance support system,\" \"drive test,\" and \"subscriber complaints\", was the available data from the three types of sources, and in the output port, the detected fault characteristics were entered into the information combination part. Finally, the detected fault was sent to the output and cause. The performance support system is one of the most important sources of information in identifying network problems. The data of this system were examined in detail in the second section. The CCC quality criterion was used for fault detection. The records identified as faults by this criterion were entered into the next step of the algorithm to determine the cause of the fault. These data were divided into traffic and signaling data categories, and the related problems to each section were identified separately. Since the available data were only unlabeled raw data, the clustering algorithm method was used.