## 5 Proposed Protocol
### Security Requirements
\begin{table}
\begin{tabular}{|p{113.8 pt}|p{113.8 pt}|p{113.8 pt}|p{113.8 pt}|p{113.8 pt}|p{113.8 pt}|} \hline \multirow{2}{*}{**Message**} & \multicolumn{4}{c|}{**Security Requirements**} & \multirow{2}{*}{**Type of Message**} & \multirow{2}{*}{**Remark**} \\ \cline{2-2} \cline{4-6}  & **Data** & **Source** & **Data** & **Data** & **Data** \\  & **Integrity** & **Authentication** & **Confidentiality** & **Freshness** & **Message** \\ \hline Advertisement, **adv** & \(\boxed\) & \(\boxed\) & & \(\boxed\) & Broadcast \\ \hline Join request, **join_req** & \(\boxed\) & \(\boxed\) & & \(\boxed\) & Unicast \\ \hline The schedule, pattern seed and mapping permutation, **sched_seed_permut** & & \(\boxed\) & & & Broadcast \\ \hline Pattern code, **pattern_code** & \(\boxed\) & \(\boxed\) & & \(\boxed\) & Unicast \\ \hline Notification for the selected nodes, **selected_nodes** & \(\boxed\) & & & \(\boxed\) & Broadcast \\ \hline Sensor readings, **data** & \(\boxed\) & \(\boxed\) & & \(\boxed\) & Unicast \\ \hline Cluster key request, **CK_req** & \(\boxed\) & \(\boxed\) & & \(\boxed\) & Unicast \\ \hline Cluster key reply, **CK_rep** & \(\boxed\) & \(\boxed\) & & \(\boxed\) & Broadcast \\ \hline \end{tabular}
\end{table} 
Table 1: Security requirements of the proposed protocol. Because all members in a cluster must listen to the schedule message, no confidentiality protection is needed. Originating from the ESPDA protocol, the permutation increases the protection of the messages sent by non-CH nodes to CHs. As we know, in ESPDA, before a node sends the sensor data to its CH, it encrypts the data and then assigns the data blocks to the NOVSF time slots based on the mapping permutation. Therefore, at first any intruder needs to find out the proper order of these data blocks, rearrange them properly and then try to decrypt the data in order to recover it. Mapping permutation requires data integrity so that unwanted alterations can be detected. If the CH has a different mapping permutation than the cluster members, then the CH will not be able to reorder the data blocks in the proper way. Data confidentiality is needed so that information breaches can be prevented. If any intruder is able to learn the mapping permutation, then the use of NOVSF-BH has no effect. Source authentication is needed to prevent cluster members from getting false mapping permutations from unauthorized sources. Data freshness is also required to prevent replay attacks. The use of old mapping permutations can prevent CHs from properly reordering the data blocks. Like mapping permutation, pattern seeds are also from ESPDA. This type of message requires the same security features. Without data integrity, altered pattern seeds may yield different lookup tables that are used to generate the pattern codes within a cluster. Without source authentication, any cluster member can receive a false pattern seed from an unauthorized source that can later disrupt data aggregation. Without data confidentiality, anyone can know the content of the sensitive data. Without data freshness, replay attacks can be launched. The old pattern seeds can result in different lookup tables. As we know the cluster members generate the pattern code based on the lookup table. If different lookup tables exist, two or more of the same sensed data can be represented differently. CHs may notice these pattern codes as unique ones and ask for their corresponding actual data. This may lead to inefficient data aggregation. Moving on to another message type, the **pattern_code**, this message requires data integrity, source authentication and data freshness in order to detect unwanted alterations, unauthentic sources and replay attacks that can disrupt the proper data aggregation. In ESPDA protocol, CH requests to the nodes having unique pattern code for the actual sensor readings.