## 3 IoT Attack Classification Mechanism
### Data Pre-Processing  
In this section, the purpose of data pre-processing is to convert the original data into the input format required by the model to ensure the data's consistency, availability, and applicability, thereby improving the accuracy and efficiency of the model. The data pre-processing step includes three sub-steps: data cleaning, feature selection, and data standardization. * Data cleaning: This substep will delete low-relevance feature IDs 1, 4, 6, 7, 17, and 19. For example, Feature ID 1 is the row identifier, and ID7 is the serial number of any starting value. Feature IDs 17, 18, and 19 are label fields. According to the needs of this paper, they are not used as input data. Only feature ID 18 is retained as a label field to evaluate classification performance. Feature IDs 4 and 6 are port numbers, which range from 1 to 65,535. However, attackers can set them arbitrarily without following the protocol specifications, so the relevance of this feature is low. To simplify \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**ID** & **Feature** & **Description** & **ID** & **Feature** & **Description** \\ \hline
1 & pkSeqID & Row Identifier & 11 & state\_number & Numerical representation of feature state \\
2 & Proto & \
\begin{tabular}{c} Textual representation of \\ transaction protocols present \\ in network flow \\ \end{tabular} & 12 & Mean &
\begin{tabular}{c} Average duration of \\ aggregated records \\ \end{tabular} \\
3 & Saddr & Source IP address & 13 & N\_IN\_Conn\_P\_DstIP &
\begin{tabular}{c} Number of inbound \\ connections per destination IP. \\ Destination-to-source packets \\ per second \\ \end{tabular} \\
4 & Sport & Source port number & 14 & Date &
\begin{tabular}{c} Number of inbound \\ connections-to-destination packets \\ per second \\ \end{tabular} \\
5 & Daddr & Destination IP address & 15 & \
\begin{tabular}{c} State \\ \end{tabular} &
\begin{tabular}{c} Source-to-destination packets \\ per second \\ Maximum duration of \\ aggregated records \\ \end{tabular} \\
6 & Dport & Destination port number & 16 & Max &
\begin{tabular}{c} Maximum duration of \\ aggregated records \\ \end{tabular} \\
7 & Seq & Argus sequence number & 17 & Attack &
\begin{tabular}{c} Class label: 0 for Normal \\ traffic, 1 for Attack Traffic \\ \end{tabular} \\
8 & Stddev &
\begin{tabular}{c} Standard deviation of \\ aggregated records \\ Number of inbound \\ connections per source IP \\ Minimum duration of \\ aggregated records \\ \end{tabular} & 18 & Category & Traffic category \\
9 & N\_IN\_Conn\_P\_SrcIP &
\begin{tabular}{c} Number of inbound \\ connections per source IP \\ Minimum duration of \\ aggregated records \\ \end{tabular} & 19 & Subcategory & Traffic subcategory \\
10 & Min &
\begin{tabular}{c} Minimum duration of \\ aggregated records \\ \end{tabular} & & \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Feature descriptions for the BoT-IoT dataset. the complexity, consider an environment where IPv4 is used at the network layer, and TCP or UDP is used at the transport layer. Therefore, the Address Resolution Protocol and the Internet Control Message Protocol in Feature ID 2 and IPv6 in Feature IDs 3 and 5 will not be included in the scope of this article;
* Data standardization [28; 29]: This substep is mainly to reduce the complexity of model training and accelerate the convergence speed of the model to prevent problems such as gradient explosion during model training. Feature ID 2 uses the label encoding method to set Proto's TCP and UDP to 0 and 1, respectively. Feature ID 18 also uses label encoding to set each class to a value from 1 to 5. Feature ID 18 also uses label encoding to set each class to a value from 1 to 5. After feature IDs 8 to 16 are normalized using Equation (4), their values will be in the \([0,1]\) interval.