Bulk data is a potentially large portion of data that should be sent to one or more nodes. Typically this can be a new firmware binary, configuration data etc. The BOTA service does not make any assumptions about what it sends. The data to send is expected to be available in some sort of Bulk memory that the BOTA can access.
Bulk memory is a memory available in the Sender where the bulk data to be sent is stored. This can be operational memory of the microcontroller, external FLASH, SD card or any type of random-access memory with linear addressing. In order to enable access to this data the user of the BOTA service is expected to provide an implementation of a read function.
Destination memory is a memory available in the Recipient where the bulk data should be stored. This can be operational memory of the microcontroller, external FLASH, SD card or any type of random-access memory with linear addressing. In order to enable access to this data the user of the BOTA service is expected to provide an implementation of a write and read function. The read function is needed for the final verification of the entire data that was received and stored.
In BOTA, a Sender is the device that has some data to send to the Recipients. Usually BOTA Sender service instance runs in the border router and BOTA Recipient service instance runs in each networked node. In BOTA the data transfer can be run from one Sender to one or more Recipients. The recipient of the transfer is defined when the transfer is started in the Sender. If the recipient is defined using a unicast IPv6 address - there will be just one recipient. If the recipient is defined using a multicast IPv6 address - there might possibly be more recipients.
In BOTA, a Transfer is a process of sending a continuous chunk of data (bulk data) from Sender to Recipients. BOTA supports multiple transfers running in parallel to different Recipients, however the maximum number of simultaneous transfers is limited (see BOTA_SENDER_MAX_TRANSFERS and BOTA_RECIPIENT_MAX_TRANSFERS definitions). Each transfer is identified by a transferId (see BotaTransferId type) that is assigned by the Sender when the transfer is started. The transfer is carried to a single node or a group of nodes. Each transfer has its recipients defined by an IPv6 address. If the recipient IPv6 address is a unicast address then there is just one recipient. If the recipient IPv6 address is a group address, then there can be multiple recipients.
When a BOTA transfer is started the first thing that happens is that the Sender sends out a transfer request message to all nodes matching the recipient IPv6 address. Each node that receives this message can accept or reject the transfer. Next the transfer is carried only to nodes that accepted it.
Each transfer can optionally carry user-defined information (up to 32 bytes) about the transfer. This information is provided to the recipients to help them not only make decision about accepting or rejecting the transfer but also to determine what to do with the transferred data once it is received.
BOTA Sender can potentially work with a large number of recipients and it needs some memory space to track this information. For this to work the user is expected to provide some memory space called Transfer Space. In order to determine how much memory space is needed the user can call BOTA_SENDER_GetRequiredTransferSpaceSize providing the expected number of recipients. In case the provided transfer space size is insufficient, some potential recipients may not be handled.