metricom_system.gif (4888 bytes)

Figure 1

 

 

 

The Ricochet System Architecture

This section presents a description of the Ricochet system architecture. This are almost the orginal excerpts from H. Balakrisnan and E. Amir CS-294-7 [1] report on the metricom system.  They  describe the components of the system, the network topology, and the routing mechanisms.

arch.gif (6182 bytes)

Figure 2

Pole Top Radio are distributed .25 - .5 mi spacing in a checkerboard fasion. Every 20 square mile area a wired access point is located. Usually a 20 square mile radius contains approximately 100 microcells [2]

 

Portable Modems (PM): These devices connect the mobile host to the Ricochet network using an RS-232 serial interface. The mobile host communicates with the PM using an extended Hayes AT command set.

Pole Top Radios (PT): These devices route packets over a wireless link towards or from the nearest wired access point after which the packet is routed through the Internet or to the mobile host . The routing is performed geographically, i.e., based on the latitude and longitude of the pole top radios with respect to the final destination. The PTs are half-duplex units, which means that they cannot send and receive packets simultaneously.

Ethernet Radios (ER): These devices bridge between the wireless and wired portion of the network. Specifically, they are multi-homed packet radio units that have one interface on the same ethernet as the Metricom Gateway (see below), and another interface on the wireless network. These radios effectively provide the gateway with the functionality of multiple wireless interfaces.

Metricom Gateway (MGW): These machines serve as gateways between the wireless network and the IP-based wired network. Their basic function is to map between IP addresses and Ricochet identifiers and appropriately encapsulate packets with Metricom-specific headers and route the packets to the correct ER en route to the destination. For packets originating from the mobile, they also decapsulate the Metricom header and forward the packets on the wired IP network to the destination. The MGW is multi-homed with one interface on the same physical subnet as the ER's it serves.

Name Server Router (NS Rtr): This host resides on the same subnet as the GW and serves as a router to the system name server. The reasons for explicitly separating this function are detailed later in this section, when we describe the initialization process.

Name Server (NS): The system name server resides in the Metricom domain. Its main functions are to validate the subscription, based on the PM identification number, and validate the service request. The registration process described below explains this in more detail.

Mobile Host(MH): Mobile Host

Fixed Host (FS): Staitionary Host

 

"Figure 2 shows an example deployment of the Ricochet architecture. In the figure, a mobile host (MH) on the Ricochet network is shown communicating with a fixed host (FH) that resides at an arbitrary location on the Internet. There are several Pole Top (PT) radios in the region that route packets to the three Ethernet Radios (ER), which bridge the wireless and wired portions of the network. We describe three basic communication scenarios: modem registration, MH to FH data transfer, and FH to MH data transfer.

Initially, when the Portable Modem (PM) is powered up, it goes through a registration process. The PM registers by sending a registration request through the pole top (PT) network. The channel acquisition and packet is ultimately received by an Ethernet Radio (ER) which forwards the registration request to the Name Server (NS) through the Name Server Router (NSR). The request contains the PM hardware identification number which is authenticated by the NS. Upon authentication, the NS replies to the PM with an authentication confirmation and notifies the MGW about this, in order to enable future packet routing through it. If either the subscriber serial number is invalid or the service being requested is not what the subscriber had purchased, the access request is denied.

After registration, the MH communicates with hosts on the Internet through the use of any of the standard serial line IP protocols (e.g., SLIP or PPP). Each IP packet generated by the MH is encapsulated by the PM in a header designating the appropriate Ethernet Radio (ER) to route to. The packet is routed geographically, i.e., through a path of approximately least physical distance between hops based on latitude and longitude, through the pole top radio network to the ER. The ER recognizes the packet as a non-registration packet and routes the packet to the MGW. The MGW then decapsulates the packet and forwards the packet to the Internet, if the header is a valid one (MGW routes packets only after a name server registration is done for the PM).

Packets destined to the MH from a FH on the Internet are received at the MGW through the standard IP routing mechanisms. The MGW then maps the IP address to the PM identifier. Based on this mapping the MGW builds a Ricochet packet header and prepends it to the IP packet. This header is typically about 80 bytes long, since it includes link-level and hop-by-hop routing information. It then forwards the packet to the appropriate ER which resides on the same physical network, and from there packets are sent to the destination through the pole top radios.

As mentioned before, packet routing through the pole top network is based on geographic coordinates. During initial channel acquisition after power-up, poletops provide their neighbors with their (geographic) WAN addresses. This enables packets to be routed progressively closer to the final destination. The Ricochet network performs alternate routing of packets if a given pole top is ``busy'' or out of operation, both of which are likely in a large-scale deployment. This implies that a series of packets belonging to the same connection can take very different routes to the final destination. As a result, significant packet reordering of packets could occur at the end point of the connection. This has adverse implications for the performance of conventional higher-level transport protocols, which assume that more than a small amount (like three) of reordering implies packet loss. " [1]

 

For more Information: