4.3 Protocollo per la propagazione dell’aggiornamento
4.3.1 Protocollo FOTA per il livello 1
Descriviamo ora nel dettaglio il protocollo implementato per la trasmissione del firmware da parte del border ai propri vicini. La struttura generale di un singolo pacchetto di trasmissione è la seguente (Fig. 4.10):
Elenco dei possibili header da border a nodo: • richiesta aggiornamento intero firmware
#define MWN_MESSAGE_UPDATE_REQUEST WUr; • richiesta aggiornamento app
#define MWN_MESSAGE_UPDATE_NPCK_APP WUu ; • singolo pacchetto app
#define MWN_MESSAGE_UPDATE_REQUEST_APP WUb ; • singolo pacchetto firmware
4.3 Protocollo per la propagazione dell’aggiornamento
Figura 4.9: Suddivisione a livelli della rete
Figura 4.10: Struttura del pacchetto FOTA
• invio dell’update completato da parte del master
#define MWN_MESSAGE_UPDATE_SEND_COMPLETE WUd; • comando per ordinare la ritrasmissione del firmware
#define MWN_MESSAGE_UPDATE_REAPETER_CMD WUe ; • comando per effettuare la scansione dei vicini
#define MWN_MESSAGE_WHO_NEIGHBORS WUf ; • comando per far partire la procedura di aggiornamento
#define MWN_MESSAGE_UPDATE_START WUs ;
• comando per verificare la versione di aggiornamento a disposizione #define MWN_MESSAGE_UPDATE_VERIFY WUv ;
• comando per scrivere la versione del firmware all’indirizzo MEMORI_ADDRESS_VER #define MWN_MESSAGE_WRITE_VER_FR WUy .
Figura 4.11: Struttura del pacchetto WUr
Elenco possibili header da nodo a border:
• messaggio dei pacchetti mancanti dopo la ricezione del MWN_MESSAGE_UPDATE_SEND_COMPLETE #define MWN_MESSAGE_NEEDED_PCK WUp ;
• messaggio per informare che tutti i pacchetti sono stati ricevuti dopo il MWN_MESSAGE_UPDATE_SEND_COMPLETE
#define MWN_MESSAGE_IHAVEALL_PCK WUh ;
• messaggio che informa di non avere un aggiornamento disponibile, segue dal messaggio MWN_MESSAGE_UPDATE_START
#define MWN_MESSAGE_NOREADY_FIR WUz ;
• messaggio contiene versione del firmware installato e in memoria #define MWN_MESSAGE_SEND_VER_FIR WUg .
Elenco degli identificatori di campo: • campo dati raw
#define DATA_TYPE_RAW_DATA r: ; • campo dati contenente indirizzo ip
#define DATA_TYPE_ADDRESS i: ;
• campo dati contenente il numero del pacchetto mancante #define DATA_TIPE_NEED_PCK n: ;
• campo dati per ritrasmissione ack
#define DATA_TYPE_ENABLE_ACK a: .
Vediamo come avviene la trasmissione del firmware da parte del border. Per inizializzare la ricezione del file binario dell’aggiornamento, il border invia il comando WUr con all’interno l’informazione della versione del firmware che si sta per inviare e il numero totale dei pacchetti che si invieranno (Fig. 4.11).
I nodi che ricevono tale comando verificano se la versione che sta per essere trasmessa è diversa da quella attualmente installata e se hanno disponibile e valida la stessa versione all’interno della EEPROM esterna. Se il nodo non
4.3 Protocollo per la propagazione dell’aggiornamento
Figura 4.12: Struttura del pacchetto WUg
Figura 4.13: Struttura del pacchetto WUc
ha la stessa versione firmware provvederà a cancellare la EEPROM esterna per poter scrivere il file binario dell’aggiornamento. Questo verrà fatto anche se la versione firmware coincide con quella attualmente in uso ma il firmware non è disponibile nella memoria esterna. Se invece coincide in tutte e due le memorie non viene fatto nulla. Il salvataggio nella memoria esterna del firmware, in ogni caso diverso da quello che non sia lo stesso sulla memoria esterna, è dovuto al fatto che quel nodo poi potrebbe essere selezionato per ritrasmettere il firmware, quindi lo deve avere disponibile. Per essere certi dell’avvenuta ricezione da parte di tutti i nodi vicini, il border invia più volte il primo comando. Naturalmente il nodo terrà conto solo del primo utile non ripetendo la formattazione della EEPROM tutte le volte. Terminata l’eventuale formattazione della EEPROM esterna il nodo risponde, sempre in multicast con il comando WUg (Fig. 4.12) con all’interno un campo con la sua versione firmware attualmente in uso ed un campo con il suo indirizzo ip, in modo che il border possa iniziare a costruirsi una mappa della struttura della rete con le varie versioni installate in ciascun nodo.
Dopo un determinato numero di invii del primo comando, il border inizia l’invio di tutti i pacchetti che compongono l’aggiornamento. L’intestazione di ogni pacchetto e WUc (Fig. 4.13) con all’interno un campo di dati raw da 64 byte più 4 byte di checksum a 32 bit e 4 byte di indice del pacchetto. Grazie alla size fissa del pacchetto e al suo indice non è necessario che tutti i pacchetti vengano ricevuti in ordine dai nodi, ma questi possono essere ricevuti in ordine sparso. Il nodo terrà traccia dei pacchetti arrivati.
Una volta terminato l’invio di tutti i pacchetti che compongono l’aggiorna- mento il border invia un pacchetto, con header WUd (Fig. 4.14), per notificare a tutti i nodi vicini che l’aggiornamento è stato trasmesso tutto.
Alla ricezione di tale comando i nodi verificano di aver ricevuto tutti i pac- chetti. Se ne dovesse mancare qualcuno chiederanno, tramite un pacchetto con header WUp (Fig. 4.15), la ritrasmissione dei pacchetti mancanti.
Figura 4.14: Struttura del pacchetto WUd
Figura 4.15: Struttura del pacchetto WUp
Figura 4.16: Struttura del pacchetto WUh
e, terminata la ritrasmissione, invia nuovamente il comando WUd con cui i nodi ripetono la procedura di verifica di eventuali pacchetti mancanti. Se tutti i pacchetti risultano pervenuti il nodo invia un messaggio con header WUh (Fig. 4.16) ad indicare la corretta ricezione dell’aggiornamento.
Nello schema in Fig. 4.17 è mostrato il diagrammi a stati per la trasmissione del nuovo firmware da parte de border.