SSCH maintains packets in per-neighbor FIFO queues. Using FIFO queues maintains standard higher-layer assumptions about in-order delivery. The per-neighbor FIFO queues are maintained in a priority queue ordered by perceived neighbor reachability. At the beginning of a slot, packet transmissions are attempted in a round-robin manner among all flows. If a packet transmission to a particular neighbor fails, the corresponding flow is reduced in priority until a period of time equal to one half of a slot duration has elapsed - this limits the bandwidth wasted on flows targeted at nodes that are currently on a different channel to at most two packets per slot whenever a flow to a reachable node also exists. Packets are only drawn from the flows that have not been reduced in priority unless only reduced priority flows are available.
Because nodes using SSCH will often be on different channels, broadcast packets transmitted in any one slot are likely to reach only some of the nodes within physical communication range. The SSCH layer handles this issue through repeated link-layer retransmission of broadcast packets enqueued by higher layers. Although broadcast packets sent this way may reach a different set of nodes than if all nodes had been on the same channel, we have not found this to present a difficulty to protocols employing broadcast packets -- in Section 4 we show that as few as 6 transmissions allows DSR (a protocol that relies heavily on broadcasts) to function well. This behavior is not surprising because broadcast packets are known to be less reliable the unicast packets, and so protocols employing them are already robust to their occasional loss. However, the SSCH retransmission strategy may not be compatible with all uses of broadcast, such as its use to do synchronization [15]. Also, deploying SSCH in an environment with a different number of channels might require the choice of 6 transmissions to be revisited. Finally, although retransmission increases the bandwidth consumed by broadcast packets, SSCH still delivers significant capacity improvement in the traffic scenarios we studied (Section 4).
An SSCH node with a packet to send may discover that a neighbor is not present on a given channel when no CTS is received in response to a transmitted RTS. However, the node may very well be present on another channel, in which case SSCH should still deliver the packet. To handle this, we initially retain the packet in the packet queue. Packets are dropped only when SSCH gives up on all packets to a given destination, and this dropping of an entire flow occurs only when we have failed to transmit a packet to the destination node for an entire cycle through the channel schedule. We will explain the meaning of a cycle through the channel schedule in Section 3.3, but with our chosen parameter settings the timeout is 530 ms. After a flow has been garbage collected, new packets with the same destination inserted in the queue are assigned to a new flow, and attempted in the normal manner.
This packet scheduling policy is simple to implement, and yields good performance in the common case that node schedules are known, and information about node availability is accurate. A potential drawback is that a node crash (or other failure event) can lead to a number of wasted RTSs to the failed node. When added across channels, the number may exceed the limit of 7 retransmission attempts allowed for a single channel in the IEEE 802.11 standard. In Section 4, we quantify the cost of such failures and show that it is small.