Wireless LANs and mobile nodes

cnet supports mobile and wireless networking, with functions supporting mobile nodes (of node type NT_MOBILE) with wireless local area network links (of link type LT_WLAN). Only nodes of type NT_MOBILE may move during the simulation, but all types of nodes may have links of type LT_WLAN. Information described here:

• Wireless links
• The lifetime of a wireless signal
• The default characteristics of WLAN links
• Defining your own WLAN propagation model
• Node mobility

Wireless links

All node types may have one or more wireless links, and mobile nodes may only have wireless links. Links of type LT_WLAN are, by default, modelled on Orinoco PCMCIA Silver/Gold cards, but most link attributes may be set in the topology file to override the defaults.

A WLAN link may be in one of four states. In sleep state, a link cannot transmit nor receive signals, and consumes very little energy. From idle state, the link may be asked to temporarily enter transmit state to transmit a signal, and will temporarily enter receive state to receive each signal within range. Idle, transmit, and receive states all consume considerably more energy than the sleep state. The battery energy consumed by these four states depends on how long the link is in each state.

CNET_get_wlanstate determines the current state of a WLAN link, and CNET_set_wlanstate may be called to set the link into either sleep or idle state. It is not possible to set a WLAN link's state to either transmit or receive. Transitions to these states occur automatically, from the idle state, whenever a link is asked to transmit a signal, or when a signal arrives.

During simulations, nodes may examine and modify the transmission and reception characteristics of their wireless links by calling CNET_get_wlaninfo and CNET_set_wlaninfo.

All wireless power attributes are measured in decibel-milliwatts (dBm), units that are related to milliWatts by the relationship dBm = 10xlog10(Watts / 0.001).

The only wireless link attribute that cannot be modified during a simulation is the link's frequency of transmission. As an example, we can change the transmission power of a wireless link with the function:

Nodes may determine the signal strength and direction of signals arriving via their wireless links. The function CNET_wlan_arrival should be called within the event handler for EV_PHYSICALREADY, to determine the characteristics of the most recently arrived signal: The signal strength is measured in dBm, and the angle of arrival is measured in radians (0 = 3 o'clock, pi/2 = 12 o'clock).

The lifetime of a wireless signal

in cnet, to determine how it is transmitted, propagates, and is received. The following picture, reproduced with permission from Terabeam Wireless, explains the principle components in wireless transmission. Terabeam Wireless also provide a helpful signal loss calculator which may be used to support your cnet experiments.

The typical sequence of execution of cnet wireless protocols is as follows:

1. A node calls CNET_write_physical, providing a link of type LT_WLAN as the first parameter, and the bytes to be transmitted as the second.
2. The bytes are encoded by the wireless network interface card and output at the transmission power level of the card.
3. The signal first travels along a cable to the antenna, and may experience some cable signal loss in the cable. For PCMCIA cards, we assume the cable is extremely short and exhibits no loss.
4. The signal is transmitted from an antenna and, depending on the design(shape) of the antenna, may appear to be amplified (have an antenna gain) because the signal is directed and does not propagate outwards in a perfect sphere.
5. By default, cnet currently employs a simple free-space-loss (FSL) model of signal propagation, with the signal's propagation loss being related determined by the transmission frequency and the distance between nodes. The signal's strength decreases in an inverse-squared relationship, with nodes further from the source obviously receiving weaker signals.
6. The signal propagates in all directions at the speed of light, which cnet manages at 300m/usec.

   The following points now apply to all nodes that are able to "hear" the signal:

7. If a node's receiving antenna receives signals at the same frequency, the signal is gathered by the antenna, with its power level possibly increased (an antenna gain) due to the antenna's shape.
8. The signal travels from the antenna along a cable, possibly experiencing some cable signal loss, and arrives at the receiver's network interface card.
9. The signal arriving at the network interface card can be "heard" if the signal's strength exceeds the sensitivity of the interface.
10. The content of the signal (our originally transmitted bytes) may be discerned from the background noise if the signal's strength exceeds the strength of the noise by more than the card's signal to noise ratio.
11. The EV_PHYSICALREADY event is raised in the receiving node's code. An event handler calls CNET_read_physical to obtain the bytes and determine the link on which they arrived. Finally, CNET_wlan_arrival may be called to determine the strength and angle of arrival of the just arrived signal.

The default characteristics of WLAN links

cnet models its LT_WLAN links on Orinoco PCMCIA Silver/Gold cards, with the following characteristics:

In combination, these default characteristics permit (theoretically, perfect) transmissions to be heard (detected and decoded) up to 173 metres away, and the wireless carrier to be sensed (just detected) 1096 metres away. The functions CNET_get_wlaninfo and CNET_set_wlaninfo may be called to change all characteristics.

A transmitting node does not receive a copy of its own signal. If a new signal arrives at a node already receiving another signal, a collision results, and neither signal is fully received (and no EV_PHYSICALREADY event is raised).

Defining your own WLAN propagation model

The WLAN characteristics and the circular free-space-loss equation, described above, form cnet's default signal propagation model.

More realistic simulations may wish to employ different models that define other signal propagation equations, introduce randomness into the propagation, or account for impenetrable obstacles on the simulation map (knowledge of such obstacles could also be "shared" when managing node mobilty).

cnet's CNET_set_wlan_model function permits a simulation to register a function that determines the extent and success of wireless signal propagation. Only one such function is recorded per-simulation, and so, say, only node 0 needs to call CNET_set_wlan_model during its EV_REBOOT handler. CNET_set_wlan_model just expects a single parameter - (the address of) the new propagation model function.

Consider this simple example - within 50 metres of a transmitter its signal is perfectly detected and decoded, between 50 metres and 100 metres the signal may be decoded with a decreasing likelihood, and beyond 100 metres the signal cannot be detected at all.

Each time a wireless signal leaves its transmitting node, the propagation model function is called with a pointer to a WLANSIGNAL structure whose elements describe the transmitting (tx_) and receiving nodes (rx_) and their WLAN links.

The first 4 fields of the WLANSIGNAL structure provide the transmitter's node number, the transmitter's x and y coordinates on the simulation map, and the characteristics of the transmitter's link. The next 4 fields provide the same information about the receiving node. The final field enables the function may pass back (to cnet) the strength of the signal arriving at the receiver (in dBm).

The return type of the function is WLANRESULT. The function must return one of the values:

• WLAN_RECEIVED - the signal is detected and decodable. The receiver's EV_PHYSICALREADY event will (soon) be raised.
• WLAN_TOONOISY - the receiver cannot decode the signal from the background noise.
• WLAN_TOOWEAK - the (potential) receiver will be completely unaware of the signal.

If the result is other than WLAN_TOOWEAK, a receiver may determine the presence of signal by calling CNET_carrier_sense. If two or more signals arrive at a receiver at the same time, the receiver's EV_FRAMECOLLISION event will (soon) be raised.

The code for cnet's default (internal) function, based on the simple free-space-loss (FSL) model, appears below.

(Messy details!) Any user-defined propagation function is evaluated in the context of the transmitting node. The function needs to be very fast - it will be called millions of times in a typical simulation. The function should not modify any fields of sig->tx_info or sig->rx_info.

Node mobility

cnet simulations run on a rectangular simulation map, whose dimensions, in metres, may be specified by the global attributes of mapwidth and mapheight. Distances, in metres, are used in the default calculations of wireless signal strength and propagation delay of LT_WLAN transmissions.

Mobile nodes may determine their own position, and the dimensions of the simulation map, by calling CNET_get_position, and may then change their location on the map by calling CNET_set_position.

There is no direct support in cnet for a node to undertake steady motion, but if CNET_set_position is called from within a handler for a timer event, then we can attain the same result. For example, the following code moves a node along a diagonal path every second: