Abstract
[Abstract] MFTP is a multicast transport protocol optimized for reliable file transfers. MFTP is rate based, which means that the transmission rate can be configured. By limiting the transmission rate one can reserve bandwidth for other protocols. MFTP uses a NACK based error correction scheme where the sender is almost constantly sending data and very seldom has to wait for acknowledgements from the receivers. This makes MFTP specially suited for transmissions over links with long delays, for example satellite links. MFTP runs over UDP and able to manage up to higher number of simultaneous receivers. MFTP consists of two protocols: MCP and MDP. MCP (Multicast Control Protocol) is used for handling the groups and MDP (Multicast Data Protocol) administrates the actual data transfer. Based on current and expected future usage potential two main applications in Inmarsat BGAN multicast were identified, namely as (a) Content distribution and (b) Net-radio type services. The main difference between these two applications is that the content distribution application will in most cases require non-real time transmission with guaranteed delivery (reliability), whereas the net-radio on the other hand requires non-guaranteed real-time transmission with very stringent requirements in terms of bandwidth and delay. This work is based on MFTP/MDP deployment on BGAN multicast Content distribution type of services. The full interaction between the MFTP server and MFTP clients deployed over the Inmarsat BGAN down link multicast delivery mechanism with BGAN uplink access mechanism is considered. There are three basic concepts within MFTP communication. They are Block, Data Transfer Unit (DTU) and Pass. Before the file is transferred it is divided into number of blocks. The block size is a configurable parameter. Each block is divided into a number of DTUs before it is sent out. The file is transferred in a sequence of passes. In the first pass the whole file is transferred to all receivers. After each block the receivers send a NACK message to the sender containing information about which DTUs in the block that were not successfully received. In the second pass the sender transfers the DTUs that were negatively acknowledged in the first pass. The DTUs that are retransmitted belongs to the same block in the second pass as they did in the first pass. In the first pass each block had a fixed length. In the subsequent passes the size of a block depends on how many DTUs in that block had to be retransmitted. The sender keeps sending the file in passes until all receivers have received an error free copy of the file. In MFTP the duration from the end of one pass to the beginning of the next pass is called the Status Retry Timer or SRT. This is an external parameter of the protocol. Once the SRT expires the MFTP server starts the next pass by transmitting the repair blocks of the received NACKs. Hence variable SRT timer results in different amounts of NACKs collected at the MFTP server. In other words longer the SRT timer larger the amount of collected NACKs and thus resulting bigger pass sizes. Also at the same time if SRT timer is unnecessary longer than the required duration to collect almost all the NACKs this will leads to longer file transfer delays. Therefore it is important to come up with the preferred values for SRT timer for efficient performance. The SRT timer variations needs to look into different multicast group sizes (number of receivers), different file sizes (ranging from Kbytes to Mbytes) and also the amount of contention slots allocated in the return link for NACK transmission. This paper analyses the performance of BGAN multicast over MFTP by looking into file transfer delay characteristics, MFTP pass size variations and NACK related statistics (successfully received NACKs, collided NACKs) for the scenarios of varying contention channel load in the return link, varying multicast group sizes, varying multicast file sizes, varying target packet error rates (PER) based on different bearer types and different slot patterns in the return link. The performance results are based on a BGAN multicast system level simulator.
Published Version
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have