## 4 SENSED-SG Design and Protocols
### Sensed-Sg Upper Layers  
In a traditional protocol stack, the transport layer is on top of the network level. The transport layer is responsible for providing end-to-end flow control or connection-oriented data streams among other features. However, since our system is intended to achieve maximum performance in very specific tasks (basically those required to furnish a control and monitoring system), most of the attributes designed for a general-purpose transport layer are not required and would introduce greater complexity to our solution; hence we discard popular solutions such as the User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) protocols. Therefore, services to be facilitated by the transport and upper layers are comprised in a single layer on top of the network level. In there, a specific mechanism is implemented to provide each particular service (which is completely in line with an _ad-hoc_ system). End-to-end retransmissions and multiplexing mechanisms that are usually found in the transport layer are implemented as follows: the former is based on ACKs and timeouts to ensure the proper dispatching of data messages. When a message is sent, a timer is set. If the ACK is not received before the timeout, a retransmission is issued. This mechanism will be validated in the next section as a good and simple solution for dealing with unstable environments with high likelihood of message loss. On the other hand, the multiplexing service of the transport level is provided by incorporating an application identifier in each message, that way there can exist multiple endpoints in a single node. Different commands or report types are identified with different application IDs. The TinyOS operating system is in charge of assigning and managing these IDs. Concerning data protection and in line with the security requirement, an encryption mechanism is implemented. The National Institute for Standards and Technology (NIST) has outlined that the preferred encryption algorithm for new deployments must be AES since other available solutions like, Triple Data Encryption Algorithm (3 DES), will become insecure by the year 2030 (note that the expected lifetime of power assets is more than 50 years). The AES implementation to be used (128 bits) is fulfilled at hardware level by the radio interface CC2420 and managed via the TinyOS operating system. Encrypting messages at hardware level brings two main advantages compared to software encryption: higher speed and lower power consumption [62]. Finally, the last set of services to be implemented in the upper layer of the network level is the following one: (i) the generation of orders for sensing physical parameters; (ii) the processing of this information and (iii) the communication management. In this regard, it is worth mentioning that WSN devices are programmed to periodically acquire physical data, process it and determine the current state of the power assets they are monitoring. If a malfunction or a non-ideal condition/trend is detected (a specific threshold is surpassed or a certain condition is met) those readings must be considered as alarms and get them delivered to the central node to register the situation and, if possible, correct the deviation/problem. Furthermore, less frequently, sensor readings are collected and all the acquired information is sent to the sink node once it has been processed (this happens regardless of the obtained values). This two-way dispatching process allows the central node to keep records of power assets' states but not at the expense of drastically increasing the power consumption of nodes--caused by frequent and non-relevant data sending. The frequency of data sensing or information reporting (sending messages to the sink node) can be adjusted at run time to allow (i) critical power assets to report data more often (increasing the frequency) and (ii) less important assets to help extend the lifespan of their WSN devices (reducing the frequency).