routing protocol

Arvind hath wroth:

Well, it's obvious you've done quite a bit of work on the problem. It's also obvious that it hasn't survived a peer review. I did a superficial read through and found a few things I didn't like:

1. The document is 11MBytes big. For 8 pages, that's a bit large. The problem seems to be that you inserted several 2MByte images of graphs at the bottom of the document, and then scaled them to size. Bad idea. I suggest you reformat the document to a smaller size.
2. There are products on the market that do roughly what you propose. Some do it with switched antennas:

or with steerable antennas as in beam forming MIMO:

or with multiple radios and antennas:

The intent is largely the same as yours. By controlling the antenna pattern, you can simultaneously improve the link performance and eliminate any interference.

1. Your paper fails to distinguish between layer 2 switching and layer 3 routing. I also cannot tell if you're modelling an 802.11 wireless network, or inventing some new protocol. I'll assume it's

802.11 which is *ALL* layer 2 switching. There's no routing anywhere in sight in 802.11. You can read through the IEEE specs and never see the word routing. Your article also makes no mention of layer 3 protocols. I suggest you do not use the term "routing" and replace it with switching where appropriate.

1. The paper describes this traffic contention metric as: "The traffic-contention metric for a path is the sum of link contention metrics for the links in the path, and the link contention metrics are determined in turn from metrics associated with the node/sector pair that forms the link.

Considerable effort is then spent detailing how this traffic contention metric is calculated. The problems are (as usual) at the boundary conditions. With no traffic, you have the optimum link quality thus giving priority to an unused path. With a link saturated with traffic, you lose managment frames, which are presumably used to communicate the link metrics to the next node, as well as data. Both extremes are an invitation to "route thrashing" where a link is subject to being periodically switched in an out as its traffic goes from zero to saturated. You mention this possibility, but I can't decode your method of preventing it.

1. You mention: "For each transmission of a network-layer data packet, a Ready-to-Send (RTS)/Clear-to-Send (CTS) packet exchange is employed on the control channel." It's "request to send" and there is no "control channel" in 802.11. You list your own paper as the only relevent reference (16).
2. For your scheme to work, link metrics would need to be communicated to each adjacent node. That works fine for a flat earth, no obstruction, ideal topology. I have some experience trying to make such geogrphic routing work with Metricom. Using link quality metrics to optimize the path was a good start, but it does nothing if you have to route around a hill or building. More simply, it doesn't turn corners very gracefully. The bulk of your paper is on how this link quality metric is calculated, but shows little as to how it's to be used in a realistic wireless network.
3. I question the (Matlab?) as the graphs apparently do not show the effects of collisions. If you employ CTS/RTS flow control to eliminate collisions (and hidden nodes), then your thruput will suffer more than your CA scheme can hope to compensate. Of course you can slow down the link switching update rate but that will make it worthless for dynamic situations such as roaming and highly reflective environments.

Enough for now.... Best of luck on getting your paper published. I also suggest you build a live model, using greatly simplified metric (i.e. signal strength or SNR only) to see how it works. I suspect you'll run into many of the problems Metricom discovered with geographic routing and why the Houston NOC was constantly tinkering with the route biases.