New Message
TinyOS needs a new message buffer abstraction due to the need for variable headers.
Proposals
The following proposals exists.
Comparing Proposals
The following table compares the proposals based on bound on number of times a header needs to be copied, bound on the number of time data needs to be copied, memory allocated per packet, radio layer modularity, and how headers of underlying layers are accessed.
| Proposal | Bound on header copy | Bound on data copy | Memory allocated per packet | Modularity | Header access |
| KISS | O(#format) | O(#format) | MDPU + metadata | Limited. All header data is reset on format, so a layer would have to know how to restore them from the underlying layers. | Direct. |
| Jan | O(#layers) | O(1) - if a received packets new headers are unaligned with buffer | MDPU + metadata | none, vars passed from layer to layer | Through layers |
| M1 | O(#format or adjust) | O(#footers) - if footers on received packet are removed and there's not enough space for new headers | MDPU + MAX_FOOTER_LENGTH + metadata | Yes, layers can be arbitrary stacked | Direct |
| M2 | O(#format or adjust) | O(#format or adjust) - whenever a footer is added or removed | MDPU + metadata | Yes, layers can be arbitrary stacked | Direct |
| YALP | O(1) - when copied between metadata and actual header | never | MDPU + sum of all layers allocated data (max of metadata and header) | limited, total order of layers needs to be defined so metadata can be allocated accordingly | Direct |
The proposals needs to be able to handle the scenarios listed below. The following table summarizes how each proposal handle the scenarios.
| Proposal | Scenario 1 | Scenario 2 |
| KISS | Routing layer would need to format the packet when addr mode changes and hence need to know how to restore headers of all layers below. | |
| Jan's | Routing layer would pass on Ieee154 security mode from App to Ieee154 layer. | |
| M1 | Routing layer would adjust the Ieee154 layers addr mode which leaves everything else unchanged. | |
| M2 | Routing layer would adjust the Ieee154 layers addr mode which leaves everything else unchanged. | |
| YAMP | Routing layer would set the metadata addressing fields of the Ieee154 layer. |
To sum it all up, lets try and keep an overview of why/why not a proposal should be used.
| Proposal | Why should we NOT use this? | Why should we use this? |
| KISS | The data is moved every time the header length is changed. | |
| Jan's | Intermediate layers would have to pass on parameters of lower layers from upper layers. | |
| M1 | ||
| M2 | ||
| YALP | Memory overhead of Scenario 2 |
Scenarios
Scenarios that the new message abstractions should be able to handle.
Scenario 1
We have a single communication stack where the header size depends on the Ieee154 security mode and addressing length.
Layers:
App -> Route -> Ieee154 -> Radio
App internals:
Set Ieee154 security mode on packet Send to route
Route internals:
Set Ieee154 addr mode on packet Send to Ieee154
Scenario 2
We have a split communication with two different radios sending different packet formats. In this case we have to assume that the routing layer knows about its underlying layers in order to transfer a packet from Ieee154 format to the Proprietary format and vice versa. This means that the routing layer can choose one of the two underlying formats as its standard one, and expose that interface to the upper layers. Lets say it chooses Ieee154 as its standard format and for simplicity store all packets internally as Ieee154 packets (alternatively it can use a flag in the metadata to indicate the format of the packet stored).
Layers:
App -> Route -> Ieee154 -> Radio1
+----> ProprietaryPacket -> Radio2
App internals:
Set Ieee154 security mode on packet (from the App it looks like the routing layer sends Ieee154 packets). Send to route
Route internals:
if send on Ieee154
Set Ieee154 addr mode on packet
Send to Ieee154
else
Set proprietary addr mode on packet
Send to ProprietaryPacket
