create new tag
, view all tags

Reliable File Transfer over Wireless Links


In this project you will gain insight into the challenges of reliable data communications over an unreliable, shared wireless link.


FileSendReceive modules

You will need to create the modules FileSend, FileReceive, and MAC to write an OMNeT++ program that performs a reliable peer-to-peer file transfer by modifying and extending the functionality of the peer-to-peer chat assignment. You will need to use the SmartPacketRadio module as well. An overview of the system is shown in the figure above.

Your program needs to complete a file transfer operation in a reasonable time, with a transfer speed of no slower than 2 Kbytes/sec.


When you start your OMNeT++ program, the FileSend module should ask for a file name with the following command:

   Enter the recipient's address and name of the file to be sent:

If the user presses the Enter key without typing a file name, the program should enter into "file receive" mode passively and start waiting for a sender to start sending a file. Otherwise if the user enters an address and a file name (which should exist in the current directory that your program started from) in this form


where XXX is the address of the recipient and YYY is the name of the file to be sent, it should start sending the file. When the file sending operation is complete, it should terminate with the following message:

   File YYY has been sent successfully (recipient: XXX, total bytes: ZZZ)

where ZZZ is the number of bytes sent.


Whenever the FileReceive module starts receiving a file, it should display a message in this format:

   Receiving a file from XXX, saving with name XXX.dat

where XXX is the file sender's address, the received file may or may not have the same name with the original. Then it should save the contents of the received messages in a file (in the current directory) with the name XXX.dat. After file reception is complete, it should display the message

   File reception is complete, N bytes saved. 

where N is the number of bytes saved into the file XXX.dat.

Media Access Control (MAC)

MAC module is more complex than the simple MAC module used in the peer-to-peer chat assignment. For example, this assignment will require use of the Sequence Number bits (in the Control field byte) to cope with the duplicate frame transmission problem that will inevitably be encountered. In addition, lost or damaged frames will need to be detected in order to transfer a file error-free.


The MAC protocol to be used is very similar to "pure" ALOHA - a very simple multiple access scheme involving two steps:

  1. Send data when it is ready (that is, when a message is received from the FileSend module).
  2. Wait for an ACK. If the receiver does not "ACK" the packet within a fixed time period, assume collision/frame damage, wait for a random time period and resend. If after X repeats the frame still cannot be sent, abort the file transfer (you will decide about the optimum value of X).
The frame format is the same as the one we use in the peer-to-peer chat assignment, but makes use of almost all the existing fields. An ACK frame will not have any payload, and the ACK bit in the Control byte will be set.

You will need to calculate the CRC checksums, otherwise detecting transmission errors will not be possible. Please use the CRC16 implementation example provided in this Philips data sheet (with C source code, see Section 10)


When a frame is received, the MAC sublayer should

  1. check that no frame damage occurred during transmission, and destination address matches to your radio, if yes
  2. deliver the message contents to FileReceive, and send an ACK back to the sender.

Notification of the End-of-File Condition

Sender needs to tell to the receiver when all the bytes of a file are sent. Otherwise the receiver will keep waiting for more bytes which will never arrive! Normally, in layered protocol suites such as TCP/IP this is the responsibility of the application layer protocol (FTP for example). But, in our assignment we don't want to overly complicate the work. Here is our solution: FileSend reads blocks of bytes from the file to be transferred, and sends to the MAC layer. When it reads the last block of bytes (end-of-file condition), it sends the last block and also tells the MAC layer that there are no more bytes coming. Then, the sender's MAC module prepares the frame containing the last block of bytes, sets the ACK bit on (so, the ACK bit has an additional meaning now: in a frame carrying data, it signals the last frame of a file), and transmits the frame. Receiver's MAC module monitors the ACK bits of the data frames, and when detects an ACK bit on, it now knows that no more frames will arrive. Based on this, it notifies the FileReceive module.


As in your Peer to Peer Chat assignment, you can work on your assignments and debug the code on your own time without accessing to a Monash packet radio board.

An additional important component of this assignment is the detection of transmission errors with CRC fields and recovery. If you insert the following "packet corruptor" module along the message path between the MAC and SmartPacketRadio modules, you can easily check the operation of your error detection and recovery methods and debug your code:

There is a reference implementation that you can use to test your file transfer code against. You can test your program against the reference in two ways:

  • without radios by using the library libFileTransferRef.a, makefrag and the NED files, and
  • with radios by using the executable FileTransferRef and the NED files.
Here are the files:
  • Common files used in both options:
    • omnetpp.ini
    • FileSendRef.ned
      • There is a parameter for FileSendRef called commandToSend. If this is non-empty, FileSend will try to execute (in 10 seconds) that line as if someone had typed it in.
      • The module FileSendRef also has a parameter called initialStateIsReceive. If this is set to true, then the FileSendRef module and the MACRef module will immediately go into receive mode at the start of the simulation. Additionally, FileSendRef will not listen to input on the keyboard. This might be useful for testing purposes.
    • FileReceiveRef.ned
    • FileTransferRef.ned
    • MACRef.ned
      • The MACRef module has an added parameter useRadioAddress. If this is set to a non-zero value, then the MAC module will use that as an address, and not try to lookup the radio module.
    • SmartPacketRadio.ned
    • package.ned
  • Without radio:
    • libFileTransferRef.a library
      • The library contains the object files FileReceiveRef.o, FileSendRef.o and MACRef.o, built on the lab computers in release mode. makefrag contains a line that will make the linker link in with the library for creating your executable, and when you build your project with makefrag present, it will be automatically included in your Makefile. Have a look in omnetpp.ini to see how these two options can be differently configured.
    • makefrag
  • With radio:
Topic revision: r14 - 2013-10-16 - AhmetSekercioglu
This site is powered by the TWiki collaboration platformCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback