The Ricochet network uses a fascinating geographic routing protocol. Each poletop is programmed with its latitude and longitude when it's installed. Packets are addressed to locations, and the poletops figure out the most direct route to get them there.

The network is explained in some detail in and which was presented at the InterOp /Networlf conference in May 2001. The capacity of the network is calculcated in detail in and . An example of a network diagram for Silicon Valley and San Francisco or San Diego from 2001 shows connectivity between poletops and Wired Access Points (WAPs) in some detail.

The rest of this page is intended as a brief primer, after which the pdfs and ppts will make more sense.

Portable modems do not know their lat/long, but they know what network radios (e-radios and poletops) they can hear. Each portable maintains a node table, sorted roughly by signal strength and ping time. The poletop at the top of the table is known as the "best node", and the portable adopts the location of the poletop for purposes of addressing data. (Node acquisition and performance when mobile, among other things, are discussed in detail in .)

Establishing a connection depends on knowing the address of the remote end. If you dial by serial number, and the other modem is in range (is in your node table because it's directly reachable) then this works fine. But if it's not in range, the serial number is a useless piece of information by itself. Packets more than one hop away are routed by WAN address, which is a packed lat/long format.

Resolving serial numbers to WAN addresses is what the nameserver does. When you attempt to dial anything that's not in the local node table, your modem sends a lookup to the nameserver and waits for a response. Currently, the nameserver is down and this response never arrives. If it did, your modem would use the response to add the destination modem to its node table. Having the WAN address of the other modem would enable your modem to address packets to it, and thus open a connection.

What we know about nameserver packets has been gleaned from watching live packets on a dead network, we have requests but no responses. The protocol is also documented in this patent .

Headers use a format called TLV, which is Type, Length, Value. The high nybble of the first byte specifies "type", which can be an IP address, a WAN address (packed lat/long format), or a serial number. The low nybble specifies "length" in bytes, and the next so-many bytes are the actual address. After that another TL byte, and more V, another TL byte, more V bytes, until the string is done.

Using TLVs enables routes to contain multiple address types. A packet sent to the nameserver from a portable might contain that modem's serial number, then the WAN address of the best node, then the WAN address of the e-radio at the WAP site, then the IP address of the nameserver. Each node figures out whether it can directly reach the destination address, and if not, uses its routing table to get the packet to the next hop in the header. (Redundant routes tend to optimize themselves, since the next hop will be zero-cost. Someone explain that better?)

In software, the ethernet interface, the 900MHz radio board, and the 2.4GHz radio board are all just "interfaces" where packets can be tossed. The radios behave like real "routers", deciding on a per-packet basis which interface is most appropriate for which packet. Congestion and signal quality are taken into account, as well as the actual distance that a given hop would accomplish. It's anybody's guess how a given packet will make its way to its destination, but it's very nearly optimal. (Except in the case of cul-de-sac routes, which require special handling for geographic situations that break a flat mesh.)

One of the key advantages that the metricom system had was that it was tuned to transmit Internet protocols efficiently, particularly TCP. Other wireless systems at the time were still extremely inefficient at doing this. This paper explains some of the steps that were taken to improve the TCP performance.

Difficulties with long strings of poletops. The system wasn't well suited to providing connectivity "along an isolated stretch of highway" or similar situations, emphasizing that most customers should be within 2 or 3 hops of a WAP. The key reason for this was latency. The TCP performance deteriorated dramatically as the latency increased.

Media Access Control (MAC) Protocol

The Ricochet system used frequency hopping in its MAC protocol. This protocol allowed neighboring radios to talk to each other (no routing involved.) Each radio in the network hopped 25 to 40 times a second to a different frequency. If a modem wanted to talk to a poletop, for instance. It would calcualte what frequency the poletop would be on at the time it wanted to send the packet. Then it would tune its transmitter to that frequency and begin transmitting. If the packet was successfully received by the poletop it would send an acknowledgement to the modem. If the modem did not receive the acknowledgement it would retry the packet, typically on a different frequency, until the packet was successfully sent. This made the system very robust in the presence of interference.

Some patents describing these protocols.

1. Routing: , , ,

2. Media Access Protocol: , , ,