# GNSS Spoofing Detection and Mitigation Based on Maximum Likelihood Estimation
## 4 MLE-Based GNSS Anti-Spoofing Method
### Spoofing Validation and Recovery of Navigation Solution
In Scenario 1, \(\rho_{s}\) and \(\rho_{a}\) are separate. Therefore, the number of authentic signals is more than four in \(y\), and both \(r_{1}\) and \(r_{2}\) are larger than four. Consequently, both spoofing detection and validation are successful. In Scenario 2, \(\rho_{s}\) and \(\rho_{a}\) are close. Therefore, parts of the authentic signals are eliminated in the cancellation procedure, and the residual authentic signals are fewer than four. Consequently, \(r_{2}\) is no more than four, and the spoofing validation fails. However, when the PVT bias induced by the spoofing signals becomes larger (i.e., \(\rho_{s}\) is farther from \(\rho_{a}\)), the peaks of the MLE cost function formed by the spoofing and authentic signals will separate, and this scenario will turn into Scenario 1. In Scenario 3, the number of the authentic signals is fewer than four due to the blockage in different traffic conditions. Consequently, \(r_{2}\) is no more than four, and the spoofing validation also fails. Case 2 consists of Scenarios 4, 5 and 6. In these scenarios, authentic signals are more than four, and the total power of them is higher than that of the spoofing ones. Therefore, \(\hat{\rho}_{1}\) equals \(\rho_{a}\), and only spoofing signals are reserved in \(y\). Scenarios 4, 5 and 6 are symmetric to Scenarios 1, 2 and 3, respectively. The detection and validation results are the same as those in Case 1. \begin{table}
\begin{tabular}{c c c c c c c c c c c} \hline \hline \multirow{2}{*}{**No. **} & \multirow{2}{*}{**Case**} & \multicolumn{2}{c}{\(x\)} & \multirow{2}{*}{\(\hat{\rho}_{1}\)} & \multicolumn{2}{c}{\(y\)} & \multicolumn{2}{c}{\(r\)} & \multirow{2}{*}{**Detection**} & \multirow{2}{*}{**Validation**} \\ \cline{3-3} \cline{5-10}  & & & **spf** & & & **supf** & & & \(\mathbf{r_{1}}\) & & \(\mathbf{r_{2}}\) & \\ \hline
1 & & \(>\)4 & \(>\)4 & \(=\)\(\rho_{s}\) & \(=\)0 & \(>\)4 & \(=\)\(\rho_{a}\) & \(>\)4 & \(>\)4 & \(\surd\) &  
Case 3 consists of Scenarios 7, 8 and 9. In these scenarios, the peak at \(\hat{\rho}_{1}\) is formed by parts of spoofing signals and parts of authentic ones. Since at most four authentic and spoofing signals can be superimposed in the search domain, \(r_{1}\) is no more than four, and the spoofing validation fails. Even though only Scenarios 1 and 4 can be validated successfully. The validation is very meaningful since these two scenarios include the intermediate and sophisticated spoofing attacks mentioned in [3], which are very covert since they mislead the PVT results while maintaining the tracking state of a GNSS receiver. In such spoofing attacks, the spoofer can extract the ephemeris and estimate the position and motion of a victim receiver in real time, based on which spoofing signals, which are consistent with the observed constellation, can be generated. At the initial stage of the spoofing attacks, spoofing signals try to align their code phases to those of the corresponding authentic ones; consequently, \(\mathbf{\rho}_{s}\approx\mathbf{\rho}_{a}\). Then, the spoofing signals increase their powers and take control of the delay lock loops of the victim receiver. Finally, they drag the code phases away from the true values, and \(\mathbf{\rho}_{s}\) will not be approximately equal to \(\mathbf{\rho}_{a}\) any longer. When the code phases of the spoofing and authentic signals are perfectly aligned, the proposed method cannot detect the attack. However, since the aim of a spoofing attack is to mislead the PVT results, the bias between \(\mathbf{\rho}_{s}\) and \(\mathbf{\rho}_{a}\) will not maintain as zero, and it will increase gradually. Afterwards, the spoofing attack can be detected, and the navigation solution can be recovered. The spoofing detection, validation and navigation recovery of such spoofing attacks in real tests will be provided in Section 6.