Software Defined Acoustic Underwater Modem
Total Page：16
File Type：pdf, Size：1020Kb
Software Defined Acoustic Underwater Modem Jakob Lindgren April 13, 2011 Abstract Today many types of communication are employed on seagoing vessels, such as radio, satellite and Wi-Fi but only one type of communication is practical for submerged vessels, the acoustic underwater modem. The ”off-the-shelf” modems are sometimes difficult to update and replace, especially on a large submarine. But by separating the hardware from the signal processing and making the software modular more versatility can be achieved. The questions that this thesis are asking are: is it possible to implement the signal processing in software? How small or large should the modules be? What kind of architecture should be used? This thesis shows that it is indeed possible to implement simple algorithms that can isolate a signal and read its content regardless of the hardware configuration. Calculations show that up to 13 kbps can be reached at a range of one kilometer. It is most practical to make the entire physical layer into one module and the size of the system could drastically change the type of architecture used. 1 Preface This Master's thesis from Jakob Lindgren is the final project for receiving the Master's degree in Robotics at M¨alardalenUniversity in V¨aster˚as,Sweden. It covers the basics of digital communication in the underwater channel as well as some simple algorithms for software defined communication. The purpose of this master thesis is to investigate how a software defined acoustic underwater communication can be implemented. This work was done at Saab Underwater Systems in Motala, Sweden, during the autumn term of 2010. I hope this thesis can increase your knowledge of communications and software design and hopefully you will put this report away with more an- swers than questions. I would also like to take this opportunity to thank my thesis advisor, Ola Pettersson, for the help, questions and laughs given during this work. 2 Contents 1 Introduction 5 1.1 Background ............................ 5 1.2 Project objectives and limitations ................ 7 2 Acoustic underwater communication 8 2.1 Network protocol structure .................... 8 2.2 Acoustic underwater modem ................... 10 2.3 Software driven modem ...................... 10 2.4 Underwater channel ........................ 10 2.5 Constellation diagrams ...................... 12 2.6 Channel effects .......................... 12 2.6.1 Effect of noise ....................... 13 2.6.2 Coherent vs non-coherent . 14 2.6.3 Signal strength and Doppler effect . 15 2.6.4 Echoes ........................... 15 2.7 Modulation ............................ 17 2.7.1 Why modulate ...................... 17 2.7.2 Digital modulation .................... 17 2.7.3 Benefits and drawbacks . 22 2.8 Demodulation ........................... 23 2.9 Orthogonal frequency division multiplexing ............................ 25 2.10 Error correcting and interleaving . 27 3 Implementation 30 3.1 Physical layer structure ...................... 30 3.2 Structure of the implementation . 32 3.3 Envelope detector ......................... 33 3.4 Modulator and demodulator implementation .......................... 36 3.4.1 Processing incoming waveform . 36 3 3.4.2 Single carrier modulator and demodulator . 39 3.4.3 Generation of the constellation diagrams . 39 3.5 Simulator ............................. 41 3.6 Error correction .......................... 42 3.7 Interleaver ............................. 42 3.8 Publish and subscribe ...................... 44 4 Results and evaluation 45 4.1 Feasibility of software defined acoustic underwater modem ................... 45 4.2 Interconnection degree ...................... 45 4.3 Usage of a publish subscribe middleware . 46 4.4 Performance ............................ 47 4.4.1 Expected bit rate ..................... 47 4.5 Discussion ............................. 48 5 Conclusions and future work 51 5.1 Future work ............................ 51 A Abbreviations 52 4 Chapter 1 Introduction 1.1 Background Saab Underwater Systems (SUS) has a long history of making underwater vehicles including torpedoes, ROVs and AUVs. These ROVs and AUVs are used in sea-bottom mapping, mine detection, the offshore industry and even as a synthetic submarine target. In all these areas it is important to communicate with the ROV or AUV by sending instructions or receiving data. Therefore, many of them feature some kind of wireless communication. One vehicle can have up to four ways to communicate: Wi-Fi, radio, satellite and an acoustic link. Three of the communication links require that the vehicle has surfaced with the exception of the acoustic link. It uses sound waves to communicate and is capable to do so for several kilometers. However, the acoustic link is a very low speed communication system and often expensive and inflexible. These acoustic modems are usually bought ”off-the-shelf”, and replacing or upgrading them often implies a change of the entire unit. Many steps in the acoustic communication can be made simpler, easier to maintain and easier to change or replace. Many of these improvements could also be implemented in software. This could, in turn, result in a system consisting of software connected to a set of speakers and microphones. The software could be easily changed and able to work in different environments and regardless of the hardware attached, thus making the communication system more versatile. But some complexity is required to handle different environments which yields different problems. A shallow water environment [16, 5] may suffer heavily to echoes, which degrades the signal, and an AUV communicating with a boat can suffer severe Doppler effects. Some components of an under- 5 water communication link can be used regardless of the environment, such as compression or encryption, but some parts may not work at all. It would therefore be practical to make the software modular. This project is therefore aimed at investigating the difficulties of such a modular system. SUS have for some time used a publish and subscribe middleware [13] to aid interprocess communication. It would therefore be favorable if the underwater communication were modular and could be connected using the same middleware. The modern communication protocols are generic and very modular in their nature. TCP can for example be used regardless of the lower protocol layers and the same is true with IP. This indicates that the layers themselves should not have any problem being separate modules. But an acoustic underwater modem needs a physical layer dedicated to the underwater channel. Can this layer be modular internally? The physical layer will therefore be the focal point of the project. 6 1.2 Project objectives and limitations The interesting questions are: • Is it possible to implement a working software modem without hardware support? • Is it further possible to make the system modular? • If so, what kind of modules in the physical layer are required to make a software modem work? • What kind of modules in the physical layer are not required to make a software modem work? • How small or large should the modules be? • Is a publish Subscribe middleware a viable solution for connecting the modules? • What bit rate can be achieved with such a modem? There are several ways to answer these questions and one way is "learning by doing". This is the method that will be used and therefore a a refer- ence implementation will be constructed. This boils down to the following objectives: • Perform a literature study of existing technology. • Implement a modem. • Implement a simple channel simulator. • Draw conclusions from the reference implementation about how inter- connected the system is. • Determine if a publish subscribe middleware is suitable for the imple- mented system. There are also some topics that will not be touched. This project will not focus on the hardware development, in fact it will be hardware independent. Nor will the project address covert communication. 7 Chapter 2 Acoustic underwater communication 2.1 Network protocol structure A common protocol structure for a network stack is the OSI model [23], or Open Systems Interconnection model. This model is used as a basis for the network topology. The network is assumed to have five basic layers, as illustrated in Figure 2.1. Application layer is the top most layer. This layer is the user defined application that can send and receive data through the underwater channel. Transport layer is the interface between the application and the rest of the protocol stack. This can include flow control, resending of data and acknowledge incoming packets. Network layer is responsible for modifying the data blocks to a format that the link layer can handle. It must cut large data blocks into smaller ones and reassemble them later. It must be able to determine if an incoming packet is new or has been received before. It is also responsible for routing incoming packets. Link layer manages the transmission between the modems, determining where to send the frame in order to reach the end point. It also detects collisions and sometimes even avoids them. Physical layer is the final layer before the frame is transmitted. The frame needs to be detectable, both at the start and at the end, and data 8 Application Transport layer Transport layer Network layer Network layer Link layer Link layer Physical layer Physical layer Interface to Acoustic Underwater Modem UWM Figure 2.1: Structure of software defined acoustic underwater modem must arrive at it's destination undamaged.