[SensorNetArch] Re: Fragmentation & Reassembly

[Cheng Tien Ee]

I agree that using OSI for sensor networks is not entirely suitable. 
Perhaps what we can do is to identify the important functionalities 
provided by OSI to help guide what we should have in the sensornet 
architecture. Again I think that letting SP have payload sizes being the 
same as that of the MAC layer is good. However, if an SP packet travels 
across a network with different MAC layers having different packet 
lengths then we have to decide which of the lengths it should be. 
Suppose we start with the larger one, then we would definitely need to 
fragment the packet when it subsequently travels to the part of the 
network that have MACs using smaller packets. The MAC layer can either 
fragment, then force the forwarding of each fragment to the same next 
hop and reassemble, or forward to different next hops depending on the 
current link status. Since it is possible that the latter happen, then 
the only chance of reassembling would be at the destination mote. Thus 
the frag+reassembly problem.

> I think it's unlikely that transparent fragmentation/defragmentation 
> (strict layering) will be an effective mechanism. I also think we need 
> to be careful to not conflate the idea of an architecture with that of 
> a uniform API; I would assume that SP provides datagrams of a size 
> corresponding to the underlying layer 2, as opposed to an a single 
> (and inherently inefficient) constant size.
>
Hmm, I think ChannelMonM is below Encoding (perhaps I'm wrong). Anyway, 
refering to the diagram on pg 6 of the proposal, I think 1 and 3 
corresponds to the "Physical architecture", 2, 4 and 5 to "data-link", 
and 6 to "SP" (duh).

> I suspect that discussing network protocols is going to start to 
> become difficult if we constrain ourselves to the OSI model. We need 
> to effectively distinguish the lowest level datagram format from media 
> sensing from communication scheduling from SP. A strawman:
>
> 6: SP (e.g., AM, dispatch)
> 5: Scheduling Layer (e.g., S-MAC)
> 4: Datagram Layer (e.g, 802.15.4 format)
> 3: Carrier Layer (e.g. ChannelMonM, some of CC1000RadioIntM)
> 2: Encoding Layer (e.g., SecDed)
> 1: Physical Layer

Since SP (is supposed to) corresponds to IP in the Internet, I would 
think routing (between networks of different tech) takes place there. 
And even though in the Internet congestion control is at the transport 
layer, I believe that in sensor networks that functionality should 
co-exist with SP. The reason is that congestion control in the Internet 
being at transport layer makes sense because TCP manages each end hosts' 
traffic injection into the network, whereas in sensor networks both 
route-through and self-generated traffic have to be managed locally (and 
downstream, as opposed to end-to-end), and since routing takes place at 
SP I would put CC there as well. Okay so this assumes that nobody is 
going to write TCP for sensor networks (I believe I once saw someone in 
TinyOS-help talking about doing that).

I've also been wondering if the different types of traffic in a sensor 
network requires the network to provide various types of services. For 
instance, are there applications that absolutely require end-to-end 
reliability (though I don't see any at this time)? Or traffic that can 
be delayed to allow others of a time-critical nature to be sent first? I 
think it would be good to identify all the possible services an 
application can possibly (and reasonably) require from the network (like 
finding which mote in the network has a particular piece of 
information), and break them down into components each providing 
dedicated functionalities, combinations of which provide the required 
services, much like what has happened in the layers below SP.


Ee