An overview of the 802.11 project
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:
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".
- No base station or distribution system
- All machines are within range of all others
- No fragmentation or reassembly
- No power management mechanisms
- WEP will not be supported
- Calls to interface routines will not be overlapped
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):
- Bits 0-2:
- These three bits describe the frame's type, with the five frame types below currently defined:
- 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.
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:
- Callan: 101—200
- Filliater: 201—300
- Fairfield: 301—400
- Goliath: 401—500
- Lautzenheiser: 501—600
- Miller: 601—700
- Moebius: 701—800
- Niese: 801—900
- Palmer: 901—1000
- Scibetta: 1001—1100
- Vehonsky: 1101—1200
- Wyborski: 1201—1300
Data frames may carry up to 2038 bytes of data, giving a maximum frame size of 2048 (2K) bytes.
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.
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.)
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:
|Initial value if |
802_init is successful
|General error code|
|Attempt to initialize RF layer failed|
|Last transmission was acknowledged|
|Last transmission was abandoned after unsuccessful delivery attempts|
|Buffer size was negative|
|Pointer to a buffer or address was NULL|
|Illegal MAC address was specified|
|One or more arguments are invalid|
|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.
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.
- Make sure you use a
Packet class! Hide all of those bit-mangling operations so you never have to see them again.
- Use a finite-state diagram to describe the MAC behavior before you start implementing. Be sure it includes details of where and when the collision window is expanded as well as how ACKs are generated and sent.
- When desigining your implementation, think about classes first and then threads — decompose the problem into classes, and then think about which pieces of functionality within a class will need to be implemented in separate threads.
- Use the "nuke" and "jam" settings on the latest version of the monitor to help test your code: Jam can be used to keep the channel busy, and nuke can test how your code responds to collisions.