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 |
| YAMP | 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 | The App formats the packet with the desired security mode. 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 (need to be reformatted with the security mode set from App). | Routing layer would need to format the packet when it changes communication stack (or when addr mode is changed as for scenario 1). The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. |
| Jan's | Routing layer would pass on Ieee154 security mode from App to Ieee154 layer. | Routing layer would have to retrieve all sub-layer parameters on receive and them pass them on to the right communication stack on send. The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. |
| M1 | Routing layer would adjust the Ieee154 layers addr mode which leaves everything else unchanged. | Routing layer would need to format the packet when it changes communication stack. The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. |
| M2 | Routing layer would adjust the Ieee154 layers addr mode which leaves everything else unchanged. | Routing layer would need to format the packet when it changes communication stack. The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. |
| YAMP | Routing layer would set the metadata addressing fields of the Ieee154 layer. | The App could set the Ieee154 and PropertaryPacket parameters for the packet when passed to the routing layer, but when the routing layer receives a packet from one communication stack, it would need to set the according metadata of the other communication stack. Again, The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. |
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. Especially in scenario 2 where metadata for both Ieee154 and ProprietaryPacket needs to be allocated. | No need for memmove. |
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
