802.11~ Specification

An overview of the 802.11 project


Introduction:

The course project involves implementing a simplified version of the 802.11 LLC/MAC layer atop the virtual RF layer you used in the previous assignment. In other words, you will extend the broadcast-based communication facilities of the RF layer to provide access control and reliability, and offer these services to the layer above via a set of interface routines. We will make the following simplifying assumptions:
  1. No base station or distribution system
  2. All machines are within range of all others
  3. No fragmentation or reassembly
  4. No power management mechanisms
  5. WEP will not be supported
  6. Calls to interface routines will not be overlapped
Though each of you will work individually, your implementations will be expected to interoperate and share the RF layer as specified in the 802.11 specification. The interface routines you implement will also be identical, so that a common test application can be used atop any of your implementation projects. We shall call our version "802.11~", which is appropriate both because there are no more unused letters to designate 802.11 standards, and because we're "sort of 802.11".

Contents:

Frame Format

The simplifications assumed in 802.11~ allow for a much less complex frame format than that required by the full 802.11. The 802.11~ frame is shown below (in bytes), with the Control field expanded to show its contents (in bits):

Control Field

Bits 0-2:
These three bits describe the frame's type, with the five frame types below currently defined:
000	Data
001	ACK
010	Beacon
100	CTS
101	RTS
Bit 3:
This bit is set if the frame is a retransmission.

Bits 4-15:
The remaining 12 bits constitute a sequence number (a 12-bit unsigned integer) so that receiving stations can distinguish between and properly order frames. Sequence numbers always start at zero, and wrap back to zero if they reach 212-1.

Addresses

MAC addresses in 802.11~ are unsigned 16-bit integers. The address consisting of all 1's (216-1) is reserved as the broadcast address. Both the destination and source addresses are included in all frame types, for consistency, though Beacon frames use the broadcast address as their destination. The 802.11~ committee has apportioned sections of the MAC address space to the following implementors:

Data

Data frames may carry up to 2038 bytes of data, giving a maximum frame size of 2048 (2K) bytes.

CRC

All frames carry a four-byte CRC checksum, computed using the same polynomial specified in IEEE 802.11. Implementing the CRC checksum will be an extra-credit option for the 802.11~ project. Packets sent from 802.11~ implementations that do not compute valid checksums should fill the CRC field with 1s.

LLC/MAC Interface Routines

Note that these routines are member functions (methods).
init(short MACaddr, PrintWriter out);
This routine must be called before any of the other 802.11~ routines are used. The station adopts the 16-bit MAC address passed as argument. The second argument is an output stream to which diagnostic messages should be printed, unless the argument is null.

int send(short destAddr, byte[] data, int length);
This non-blocking function asks the 802.11~ layer to transmit bufSize bytes, starting at address buf, to the specified destination address. The function returns the number of bytes queued for transmission, or -1 on error, in which case an internal error code is set. Once the queued data is successfully transmitted and acknowledged, the internal status code is updated.

DataTuple recv();
This function blocks until data arrives, at which point it returns a DataTuple which holds the source and destination address along with the buffer of data. (Only data addressed to this station is returned via 802_recv, but the destination address can help a station determine whether the frame was broadcast to all stations, or addressed specifically to this station.)

int status();
This function returns a code representing the current status of the 802.11~ layer. The code reflects the most recent error, or the status of the most recent transmission or other operation. Status codes include:
1SUCCESS Initial value if 802_init is successful
2UNSPECIFIED_ERROR General error code
3RF_INIT_FAILED Attempt to initialize RF layer failed
4TX_DELIVERED Last transmission was acknowledged
5TX_FAILED Last transmission was abandoned after unsuccessful delivery attempts
6BAD_BUF_SIZE Buffer size was negative
7BAD_ADDRESS Pointer to a buffer or address was NULL
8BAD_MAC_ADDRESS Illegal MAC address was specified
9ILLEGAL_ARGUMENT One or more arguments are invalid
10INSUFFICIENT_BUFFER_SPACE Outgoing transmission rejected due to insufficient buffer space

int command(int cmd, int val);
This function provides a mechanism to pass command or configuration data to an 802.11~ layer at runtime. One could use it to enable or disable debugging output on-the-fly, change system parameters, or prompt the 802.11~ layer to summarize network activity, for example. Note: User-defined command values should be greater than 10. The 802.11~ specification committee has reserved the values 0—10 and is still debating their functionality.

Project Code:

You will use the virtual physical layer (RF) is written in Java. Your code will run on top of this interface. You will also have a GUI that will run atop your layer and allow you to test it easily (and your code will need to play nice this way).

You'll get some code goodies to get you started and to help monitor the stuff. (Again, thank you Brad Richards!)

Note: The RF layer now defines a variety of physical-layer constants that your implementation should reference. Check out the documentation.

Resources:

Tips: