Software Communication Architecture

(1)

Institutionen för systemteknik

Department of Electrical Engineering

Examensarbete

-Waveform Distribution with MHAL

Examensarbete utfört i Kommunikationssystem vid Tekniska högskolan i Linköping

av

Jens Dackenberg

LiTH-ISY-EX--10/4363--SE Linköping 2010

Department of Electrical Engineering Linköpings tekniska högskola

Linköpings universitet Linköpings universitet

(2)

(3)

Software Communication Architecture

-Waveform Distribution with MHAL

Examensarbete utfört i Kommunikationssystem

vid Tekniska högskolan i Linköping

av

Jens Dackenberg

LiTH-ISY-EX--10/4363--SE

Handledare: Mikael Johansson

Saab Systems

Mikael Olofsson

isy, Linköpings universitet

Examinator: Mikael Olofsson

isy, Linköpings universitet

(4)

(5)

Avdelning, Institution

Division, Department

Division of Communication Systems Department of Electrical Engineering Linköpings universitet

SE-581 83 Linköping, Sweden

Datum Date 2010-08-23 Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport

URL för elektronisk version

http://www.commsys.isy.liu.se http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-58747 ISBN — ISRN LiTH-ISY-EX--10/4363--SE

Serietitel och serienummer

Title of series, numbering

ISSN

—

Titel

Title Software Communication Architecture

-Waveform Distribution with MHAL

Författare

Author

Jens Dackenberg

Sammanfattning

Abstract

For a long time radio devices have been constructed in hardware with a fixed functionality. This way of constructing radio devices is starting to change with the concept of Software Defined Radio (SDR) evolving. The SDR concept leads to more flexible and long lasting radio devices. In order to make the radio software more standardized and portable, the U.S. military has defined the Software Com-munication Architecture (SCA). Internal comCom-munication within the SCA is done by CORBA, which limit waveforms to be only distributed over CORBA-capable hardware. The U.S. military has defined the Modem Hardware Abstraction Layer (MHAL) to enable distribution over devices not supporting CORBA.

This thesis presents an implementation of MHAL and an underlying transport mechanism based on Ethernet. The implementation is done for the OSSIE pack-age. The implementation is evaluated both in terms of real-time and throughput performance. The results show that MHAL achieves good performance, in com-parison to CORBA, and can greatly be used to distribute waveforms over both CORBA and non-CORBA capable devices.

Nyckelord

(6)

(7)

Abstract

For a long time radio devices have been constructed in hardware with a fixed func-tionality. This way of constructing radio devices is starting to change with the concept of Software Defined Radio (SDR) evolving. The SDR concept leads to more flexible and long lasting radio devices. In order to make the radio software more standardized and portable, the U.S. military has defined the Software Com-munication Architecture (SCA). Internal comCom-munication within the SCA is done by CORBA, which limit waveforms to be only distributed over CORBA-capable hardware. The U.S. military has defined the Modem Hardware Abstraction Layer (MHAL) to enable distribution over devices not supporting CORBA.

This thesis presents an implementation of MHAL and an underlying transport mechanism based on Ethernet. The implementation is done for the OSSIE pack-age. The implementation is evaluated both in terms of real-time and throughput performance. The results show that MHAL achieves good performance, in com-parison to CORBA, and can greatly be used to distribute waveforms over both CORBA and non-CORBA capable devices.

(8)

(9)

Acknowledgments

First of all I would like to thank my family and friends for their support during my thesis project. Secondly, I would like to thank:

My supervisor Mikael Johansson for his help and guidance.

My examiner Mikael Olofsson for helping me in writing my thesis report and for great courses in the area of communication systems.

Last but not least, I would like to thank the staff at Saab Systems and

Com-bitech for their support.

Jens Dackenberg Linköping, 2010

(10)

(11)

Abbreviations

3G 3:rd Generation

ADC Analog-to-Digital Converter

API Application Programming Interface

CF Core Framework

CORBA Common Object Request Broker Architecture

CRC Cyclic Redundancy Check

CSMA/CD Carrier Sense Multiple Access/Collision Detection

DAC Digital-to-Analog Converter

DCD Device Configuration Descriptor

DIX Digital Equipment Corporation, Intel Corporation and Xerox

Corporation

DNS Domain Name System

DSP Digital Signal Processor

ESSOR European Secure SOftware defined Radio

FAR Fragmentation And Reassembly

FIFO First In First Out

FPGA Field-Programmable Gate Array

GIOP General Inter-ORB Protocol

GNU GNU’s Not Unix

GPP General Purpose Processor

GSM Global System for Mobile Communications

HDL Hardware Description Language

(14)

xii Contents

ICO Integrated Circuit ORB

IDL Interface Definition Language

IEEE Institute of Electrical and Electronics Engineers

IP Internet Protocol

ISO International Standards Organization

IU In-Use

JPEO Joint Program Executive Office

JTRS Joint Tactical Radio System

LD Logical Destination

MAC Medium Access Control

MHAL Modem Hardware Abstraction Layer

MIMO Multiple Input Multiple Output

MTU Maximum Transmission Unit

NAT Network Address Translation

NIC Network Interface Card

OE Operating Environment

OMG Object Management Group

ORB Object Request Broker

OSI Open System Interconnection

OSSIE Open-Source SCA Implementation - Embedded

OWD OSSIE Waveform Developer

PF PlatForm

RAM Random Access Memory

RF Radio Frequency

RTT Round Trip Time

SAD Software Assembly Descriptor

SCA Software Communication Architecture

(15)

Contents xiii

SDR Software Defined Radio

SPD Software Package Descriptor

TAP network TAP (virtual Ethernet device)

TP Twisted Pair

TUN network TUNnel (network layer device)

USRP Universal Software Radio Peripheral

VHDL Very high speed integrated circuit HDL

VITA VMEbus International Trade Association

VRL VITA Radio Link

VRT VITA Radio Transport

WF WaveForm

(16)

(17)

Chapter 1

Introduction

For a long time radio devices have been implemented in hardware with a fixed functionality. This way of constructing radio devices is starting to change with the concept of Software Defined Radio (SDR) evolving. The SDR concept pro-vides the possibility to move the radio functionality into programmable devices, such as computers, Field-Programmable Gate Arrays (FPGAs) and Digital Signal Processors (DSPs). Constructing radios in this way leads to more flexible and long lasting radio devices.

In order to make waveforms portable between radio devices, some kind of well defined and specified architecture is needed. The solution to this is to use the Software Communication Architecture (SCA). The SCA defines an underlying framework for the waveform to utilize. By building SCA-compliant radio devices the users will not only have high flexible radios, that can be used for nearly any type of waveforms, but will also save money in the long run because of the porta-bility of the waveforms.

This thesis project has been carried out at Saab Systems1in Linköping, Sweden, during the spring of 2010. Saab Systems has its main office in Järfälla, Sweden, and supply the market with communication and decision support systems [14]. Much of the work at Saab Systems in Linköping concerns the European Secure SOftware defined Radio (ESSOR) programme, where Sweden and other European countries develops a secure SDR architecture for future use by European forces [2]. This architecture will be based on the SCA which is developed in the United States by the Joint Program Executive Office (JPEO) for their Joint Tactical Ra-dio System (JTRS) program [9].

Parallel with the ESSOR project a couple of thesis projects have been car-ried out in the area of SDR and SCA; three in total. The first two concerned implementations based on GNU Radio [20][25], and the third was regarding wave-form development in the SCA [23]. This thesis project is the fourth, and concerns waveform distribution over different platforms when using the SCA. This chapter

1_{Is now called Business area Security and Defense Solutions}

(18)

2 Introduction

will give the reader a description of the problem, objectives and an outline of the report.

1.1 Problem Description

Distribution of waveforms in SCA-compliant radios is today done by the Common Object Request Broker Architecture (CORBA), which limits the distributed envi-ronment to CORBA capable hardware, i.e. General Purpose Processors (GPPs). The Modem Hardware Abstraction Layer (MHAL) provides functionality to in-clude non-CORBA capable hardware to the distributed environment. Non-CORBA capable hardware like DSPs and FPGAs is often much faster and more efficient than GPPs, thus more wanted in a radio system that uses the SCA. This the-sis project is about designing and implement MHAL using the Open-Source SCA Implementation - Embedded (OSSIE) in a Linux environment connected with an FPGA environment. The communication with an FPGA is to be done with Eth-ernet, without invoking the Internet Protocol (IP). Performance tests will be done to evaluate real time characteristics and throughput of MHAL. Other distribution techniques will also be considered to evaluate MHAL.

1.2 Objectives

The thesis project can be grouped into the following activities: • Studies of technologies related to SDR, SCA and MHAL

• Design and implement MHAL using OSSIE in a Linux environment con-nected with an FPGA environment

• Analysis of the transport mechanism; real time characteristics and through-put

• Investigate limitations of the implementation • Comparison with other distribution technologies

1.3 Thesis Outline

This thesis report will give the reader an introduction to SDR, SCA and MHAL. The background chapter (Ch. 2) and its subsections will give the reader basic knowledge of techniques used in this thesis project. It is necessary to understand what the Software Communication Architecture is in order to fully understand the later chapters of this report. This report is written for engineer students with knowledge of communication systems and computer networking.

The report is divided into the following chapters:

(19)

1.3 Thesis Outline 3

Chapter 2: Background information on SDR, SCA, MHAL and Ethernet Chapter 3: Problem And Solution Description

Chapter 4: Implementation Chapter 5: Evaluation

(20)

(21)

Chapter 2

Background

2.1 Software Defined Radio

For a long time the only way of implementing a waveform has been through hard-ware, until the beginning of the 1990’s when the concept of SDR were introduced in a paper by J. Mitola III [22]. By implementing a waveform in hardware, the radio device is limited to functionality that it was designed for and can not be upgraded for future waveforms. This is very much like today with a mobile phone and the next coming generations of mobile systems.

“When referring to a waveform in radio technology, one does not only mean the shape of the electromagnetic signal. A waveform can rather be seen as a signal processing application, that both describes the signals shape, conceptual design, and modulation of the signal, etc.” [20, Ch. 2]

The goal of having a waveform implemented in software is that all the signal processing, e.g. modulation and demodulation, can be done in a computer or in an embedded device, like an FPGA or a DSP. By using programmable devices separation of software and hardware can be achieved which makes its possible to swap software, but still have the same hardware. What this means in theory is that a mobile phone operating with GSM1 _{technology would be possible to} convert to operate with a 3:rd Generation (3G) mobile network, by just upgrading the software within it.

The basic idea behind an ideal SDR is that the antenna is connected to an Analog-to-Digital Converter (ADC) or a Digital-to-Analog Converter (DAC) which in turn is connected to a computer or an embedded device as seen in figure 2.1.

When radio communication is done at a high frequency which is above the operational level of standard ADCs/DACs, a Radio Frequency (RF) front end,

1_{Global System for Mobile Communications}

(22)

6 Background

ADC/DAC Software

Figure 2.1. Overview of an ideal SDR.

like in figure 2.2, is needed to do the conversion between the passband and the baseband [20, Ch. 2].

The RF front end is not the same for all frequency bands which makes an SDR not fully independent of the underlying hardware. One example of a radio hardware providing the RF front end functionality is the Universal Software Radio Peripheral (USRP) which is a simple and cheap platform for creating an SDR.

ADC/DAC Software RF front end

Figure 2.2. Overview of a practical SDR.

2.2 GNU Radio

GNU2_{Radio is a free, open-source, software development toolkit providing signal} processing blocks which allows developers to easily implement software radios us-ing the USRP and a computer with Linux installed. The toolkit contains a big collection of signal processing blocks for almost all needs within radio communi-cation, such as modulation/demodulation, error correcting codes, synchronization and much more. All the processing blocks are implemented in C++ and when creating a waveform all the developer has to do is “glue” all parts together with the high-level programming language Python. Since everything is open-source it is possible to do modifications on signal processing blocks or create new blocks with custom functionality. [4]

2.2.1 Universal Software Radio Peripheral

The Universal Software Radio Peripheral is a radio hardware developed by Ettus Research LLC for providing an RF front end to an SDR running on a computer [3]. It is a low-cost hardware device that can easily be used to setup an SDR. The USRP provides two plugin-slots for RF front end cards and it exists several such cards for different frequencies. It also supports the use of two antennas. Since it supports two antennas and can handle two cards at the same time it is possible

(23)

2.3 Software Communications Architecture 7

to setup a Multiple Input Multiple Output (MIMO) system. The interface to the USRP is either a USB 2.0 port (USRP) or a Gigabit Ethernet port (USRP2). All schematics of the hardware and drivers is freely available at the homepage of Ettus Research LLC. The GNU Radio package includes support for the USRP device.

2.3 Software Communications Architecture

2.3.1 Introduction

Since the introduction of the concept SDR, a lot has happened with the develop-ment of GPPs and other programmable devices. This has lead to possibility to do serious signal processing implementations in software. Many SDR manufacturers have developed their own solutions on the architecture and implementation, since it has not existed any standard on how to do these things. So, with these many different types of SDR radio systems problems arises like the following described in [15, Ch. 1]:

“So, when multiple radio sets from different manufacturers came to-gether in response to some coordinated exercise, military operation, or disaster, the radios did not interoperate and could not be easily reconfigured to do so.”

In the mid of the 1990’s the U.S. government addressed this problem by ini-tiating a series of programs towards creating a common software architecture for SDR radio systems. The result of this initiative was the SCA which has become the leading way of how software for SDRs is programmed. [23, Sec. 2.4]

2.3.2 What is the SCA?

The SCA is an open architecture that gives designers a set of the rules regarding interfaces and structure of the radio software. It is important to state that the SCA does not specify how things should be implemented or designed, which gives designers high flexibility but at the same time keeping things highly portable.

The main purpose of the SCA is to specify an Operating Environment (OE) where the radio software operates within (see Sec. 2.3.6). The OE consists of three parts, where the Core Framework (CF) is the key part of it. Sometimes the OE can be sloppy referred to as the CF. The following is an excerpt from the introduction of the SCA specification that described what the SCA is. [15, Ch. 1]

“The Software Communication Architecture (SCA) specification is pub-lished by the Joint Tactical Radio System (JTRS) Joint Program Ex-ecutive Office (JPEO). This program office was established to pursue the development of future communication systems, capturing the ben-efits of the technology advances of recent years, which are expected to greatly enhance interoperability of communication systems and reduce development and deployment costs. The goals set for the JTRS pro-gram are:

(24)

8 Background

• greatly increased operational flexibility and interoperability of globally deployed systems;

• reduced supportability costs;

• upgradeability in terms of easy technology insertion and capability upgrades; and

• reduced system acquisition and operation cost.

In order to achieve these goals, the SCA has been structured to • provide for portability of applications software between different

SCA implementations;

• leverage commercial standards to reduce development cost; • reduce development time of new waveforms through the ability to

reuse design modules; and

• build on evolving commercial frameworks and architectures. SCA V2.2, November 17, 2001, p. vii” The key objectives for the SCA, like stated above, are to increase many abilities and at the same time reducing costs for software defined radios.

2.3.3 CORBA

CORBA is a technology used in the SCA to connect objects together. It is de-fined as a standard by the Object Management Group (OMG) and describes the interfaces provided or used by two objects using a pseudo-code called Interface Definition Language (IDL). The IDL specifies the interface and by an IDL com-piler, source code can be generated into many programming languages. The gen-erated code can be used without the knowledge of how the involved objects are distributed, i.e. remote invocations of objects is transparent to the user. [10]

IDL

Every object in the SCA has its interface specified by one or several IDL files. The IDL files are purely declarative and contain no information about implemen-tation. The IDL compiler generate source code in the desired target programming language based on the IDL files. Since an IDL file is only declarative the generate code only provides stubs and skeletons for the interface. With the help of IDL the interface and implementation of an object can be separated from each other [10]. The client who wants to use an object uses the stub in order to invoke the imple-mentation, but the client has no idea where the true implementation of the object is located. The stub in turn is connected to what is called an Object Request Broker (ORB) which handles the transportation between processes or computers. The objects implementation uses the skeleton, which also is connected to the ORB, to make itself invokable. Every implementation that uses a skeleton to make itself invokable is called a CORBA servant. In figure 2.3 an example is depicted of a client making a request to invoke the implementation of a servant.

(25)

2.3 Software Communications Architecture 9 Client Object Implementation (servant) Stub Skeleton Request ORB

Figure 2.3. Client-servant model in CORBA using stubs and skeletons [10].

ORB

The Object Request Broker (ORB) is the object bus. It handles the requests to, and receive responses from, clients and servants located locally or on another computer. When the client and the servant are not sharing the same ORB, e.g. deployed on different computers, the General Inter-ORB Protocol (GIOP) connects the ORBs and keeps everything transparent to the client and the servant [10]. An example of GIOP is depicted in figure 2.4. The ORB itself provides a wide variety of middleware services where the most interesting part for the SCA is the Name Service. Without it, the SCA would lose some of its flexibility.

Client

Object Implementation

(servant)

Stub Skeleton

ORB GIOP Request GIOP ORB

Figure 2.4. Client-servant model in CORBA using GIOP.

Name Service

The Name Service provides a dynamic way of getting a reference to a servant from the servant’s name. Every servant registers itself with the Name Service in order to make itself invokable. When a client, like in figure 2.3, wants to request a servant, the Name Service is invoked and a reference to the servant is returned to the client [15, Sec. 3.2].

(26)

10 Background

2.3.4 Ports

Every component in the SCA that has an intention of communicating with other components need to have well defined ports. It exists two kinds of ports; the input port and the output port. In the world of SCA the input port is called “provides” port, and the output port is called “uses” port [23, Sec. 2.4.4]. These definitions will be used in rest of this report. One “uses” port needs to be of the same interface type as the “provides” port to be able to establish a connection. Every interface type is defined by an IDL file, since communication between ports is done with CORBA.

2.3.5 XML

In the SCA configurations and interconnections of components is described with eXtensible Markup Language (XML). Every waveform in the SCA is specified by a Software Assembly Descriptor (SAD) XML file. The SAD file lists the re-quired components, their configurations and how they are interconnected [15, Ch. 13]. Every component/device is described by three XML files, where the Software Component Descriptor (SCD) file is one of them describing the available ports of the component [15, Ch. 10]. Every device manager (see Sec. 2.3.7) is defined by a Device Configuration Descriptor (DCD) file, which specifies the devices that the device manager controls. More information about these XML files can be found in chapter 9 through 13 in [15].

2.3.6 The Operating Environment

The Operating Environment (OE) in the SCA consists of the Core Framework (CF), the CORBA ORB and the operating system as shown in figure 2.5. [15, Ch. 1] Waveform CORBA Operating System Hardware Core Framework Operating Environment

Figure 2.5. Overview of the Operating Environment.

The OE specifies a set of interfaces and rules that must be followed in order for radio system to be SCA-compliant. What exactly these interfaces and rules are is too comprehensive to describe in this report so it is left out, but it can be

(27)

2.3 Software Communications Architecture 11

read about in [15, Ch. 3-6]. To get a more clear picture of what the CF is, an SCA radio can be split into three segments, like in figure 2.6.

Waveform Deployment

In the Waveform Deployment segment the physical view represents the hardware of the radio system. Waveforms are defined in software which in turn are deployed on the physical hardware. The logical view has two layers. One layer where the components and services that form a waveform application reside. The second layer consists of the waveform applications where the top-level interface and control of the components are provided.

Core Framework

The CF contains software required for operating the radio system and deploying waveforms. The physical view provides high-level abstraction of the physical de-vices to enable easy management. A waveform can only see the logical view, where a set of resources and services are available.

Domain Profile

The Domain Profile consists of a set of XML files that describe configuration and properties of resources within the radio system. In the physical view there are descriptions of device managers which defines and controls a set of devices. In the logical view there are XML files describing the structure and properties of waveforms.

Device Configuration Descriptor (DCD) Core Framework

Waveform Deployment Domain Profile XML

Applications Components Radio HW A B C D

Resources Domain Manager

Domain Manager Descriptor (DMD) Log ica l P hy si ca l GPP FPGA USRP MHAL File System Device Manager File Manager Name Service DataLink1 DataLink2 Da ta Lin k A p p Fa ct o ry DataLink Waveform Software Assembly Descriptor (SAD) Components Dependencies Connections

(28)

12 Background

2.3.7 Device Manager and Devices

Before a waveform application can be deployed on a hardware set, the hardware itself must be booted and initialized. Every hardware device in the domain is ab-stracted as an SCA device. A set of devices is defined and controlled by a device manager. The device manager itself is registered with the Domain Manager which contains knowledge of all components and services available in the current domain of the radio system. The knowledge is collected in the Name Service which is depicted in figure 2.6. [15, Ch. 5]

The startup of the CF is orchestrated by a device manager that provides parts of the processing necessary to implement an SCA-compliant radio. This particular device manager is called a “boot node”. Information about the steps in the startup sequence can be read about in [15, Ch. 2].

To get a better understanding of how a waveform and the available devices in the domain interacts with each other a simple example will follow.

To implement a simple digital sound transmitter with the SCA the waveform would require three devices:

• One device that captures sound using a soundcard. • One device running the waveform components. • One device doing the transmission of radio waves.

The waveform itself takes input from the sound capture device and processes this data through three components and delivers the output to the USRP device. In figure 2.7 this simple waveform is depicted, where the dotted arrows points to which device the waveform components are deployed on.

Source Coding Channel Coding Modulator

Soundcard

Capture Device GPP Device USRP Device

Soundcard OS/Computer USRP

SCA Waveform

SCA Platform

OS/HW

(29)

2.4 MHAL 13

2.3.8 OSSIE

OSSIE is an implementation of the SCA developed by the Wireless @ Virgina Tech research group at Virginia Polytechnic Institute and State University. The goals of OSSIE is to enable research and education in the areas of SDR and wireless communications [11]. OSSIE is freely available for downloading at their home-page. It can either be downloaded and installed on Linux (Ubuntu or Fedora is recommended) or downloaded pre-installed on a virtual machine. Included in the software package is an SDR core framework based on the SCA, tools for rapid development of SDR components and waveforms applications, and an evolving library of pre-built components and waveform applications.

2.4 MHAL

Distributing a waveform can be easily done with the help of CORBA as long as the platform is a GPP. To place a part of a waveform on a programmable device, like a DSP or an FPGA, other techniques must be used since these devices do not have CORBA support and thus can not have an OE specified by the SCA. One technique that supports waveforms on DSPs and FPGAs devices is the MHAL that the JPEO JTRS has formulated [17]. The MHAL is a message-based system for communicating data to and from MHAL-capable devices. It is defined as an Application Programming Interface (API) for different programmable devices but do not cover how the underlying message transportation should be done between these devices. In figure 2.8 an overview is presented to easier understand where in a system MHAL is used.

MHAL GPP MHAL FPGA

Platform Specific Transport Platform Specific Transport

MHAL Device WF Component A WF Component B MHAL MHAL Entities WF Component A WF Component B MHAL

Figure 2.8. An overview of MHAL in a GPP and an FPGA.

2.4.1 MHAL Message

The messages that are transported by the MHAL has a structure like the one in figure 2.9.

(30)

14 Background

IU Logical Destination (15 Bits)

Length

Payload

Least Significant Bit

Most Significant Bit

Figure 2.9. Standard Message Structure for MHAL Communication [17].

The structure includes all the necessary information to deliver a payload to another data sink. The In-Use (IU) bit is used by MHAL for internal message flow control. The Logical Destination (LD) is 15 bits and tells MHAL where to send the message. The Length field describes the size of the message including the header. The total length of the header is 4 bytes. The payload may be 0 bytes to the maximum size that the MHAL allows. All communication is push-only, i.e. data can be “written” to a destination but cannot be “read” in one operation [17, Sec. A.2]. Since both the terms “message” and “packet” are interchangeably used in the API document to describe what is transported this will also be the case in this report.

IU Bit

The IU bit in the MHAL message structure is to be used for data sinks and data sources that share memory to indicate that the memory is being in-use. When the data sink and data source is on two different devices this bit is to be set to zero. [17, Sec. A.2]

Logical Destination

The Logical Destination (LD) helps MHAL to route messages to different data sinks. Every data sink has an unique LD associated with it. The LD represents an interface (group of functions), but can also represent a single function. An LD can represent a node in an FPGA. The LDs are globally defined integer constants that all devices in the system knows about. [17, Sec. A.2]

(31)

2.4 MHAL 15

Length

The maximum size of the payload is 216_{− 5 bytes, since the Length field}3 _{is 16} bits and the header size is 4 bytes. To decide the maximum allowed size several aspects has to be taken in to account such as limits of physical channel and data process performance of the devices in the domain. [17, Sec. A.2]

Byte Orientation

MHAL messages is to be encoded using the Little-Endian byte orientation. This is the same byte orientation that is used in GPPs of the x86 architecture. To decrease the data process in other devices, i.e. FPGAs and DSPs, it is recommended that these are configured to Little-Endian byte orientation. [17, Sec. A.2]

2.4.2 MHAL GPP

The GPP in MHAL is a CORBA capable processor and should be represented in the SCA as an SCA device. An SCA device that supports MHAL will from now on be called an MHAL device. This device does not only have the interfaces required by the CF to operate as a device in the SCA, but must also have “provides” and “uses” ports with the interface types specified in the API. Every “provides” port represents a CORBA servant, hence an MHAL device is a composition of objects and interfaces. [17, Sec. A.4]

Ports

The communication between the MHAL device and the waveform application is done by the MHALPacketConsumer interface. The MHAL device defines an SCA “provides” port that provides the MHALPacketConsumer interfaces to enable the waveform application to push data to it. Every waveform component with inten-tion of sending data to the MHAL device must implement a uses port of the same interface type. Every waveform component with intention of receiving data from the MHAL device must implement a “provides” port of type

MHALPacketCon-sumer. An example of this given in figure 2.10.

Services

An IDL file is provided by the API document [17, Sec. A.4] and specifies two different interface types derived from the previously mentioned

MHALPacketCon-sumer interface. The first is called PF_MHALPacketConMHALPacketCon-sumer and is used by

the radio PlatForm (PF) to interact with the MHAL device. The second is called

WF_MHALPacketConsumer and is used by the MHAL device to interact with

the WaveForm (WF). Both these two interface types extends the base interface with routing features.

3_{There is an ambiguity about the Length field. What is described in section A.2.1.3 does not}

coincides with the examples in section A.6.1.2.2 of the MHAL API. The author has used what is described in the latter case.

(32)

16 Background Waveform Component MHAL Device MHALPacketConsumer MHALPacketConsumer Key: ”provides” port ”uses” port Interface Name

Figure 2.10. MHAL port diagram [17, Sec. A.4].

• Provide services

The MHAL provide services, which may be called by other SCA components, consists of the following interfaces and primitives depicted in figure 2.11. The interface and primitives shaded in grey are provided by the Packet API [19], which is besides the shaded primitives of less interest.

Service (Interface Provided) Primitives (Provided)

Packet:: PayloadStatus pushPacket() addTxRoute() getMaxPayloadSize() getMinPayloadSize() MHAL::PF_MHAL PacketConsumer MHAL::MHAL PacketConsumer

Figure 2.11. MHAL Device Provide Service Interface [17, Sec. A.4].

• Use services

The MHAL use services, which enables the device to act as client towards other SCA components, consists of the following interfaces and primitives depicted in figure 2.12. As mentioned before the shaded primitives comes from the Packet API [19].

(33)

2.4 MHAL 17

Service (Interface Provided) Primitives (Provided)

Packet:: PayloadStatus pushPacket() getRxRoutes() getMaxPayloadSize() getMinPayloadSize() MHAL::PF_MHAL PacketConsumer MHAL::MHAL PacketConsumer

Figure 2.12. MHAL Use Service Interface [17, Sec. A.4].

Primitives

The available primitives in the previously mentioned interfaces are quite few and thereby of interest to describe their functionality a bit more. In the following part of this section a more detailed description of each primitive is given.

pushPacket(2)

The pushPacket operation makes it possible to push data between the packet producer and the packet consumer.

Synopsis

void pushPacket (in unsigned short logicalDest, in JTRS::OctetSequence

payload);

Parameters

The logicalDest parameter specifies the destination of the packet. Since the logical destination is represented by 15 bits, see Sec. 2.4.1, it has a valid value range of 0 - 32767. The payload parameter contains the data to be sent (including the header). The JTRS::octetSequence datatype is specified in [18].

Return value

None.

getMaxPayloadSize()

The getMaxPayloadSize operation returns the maximum payload size that is allowed.

Synopsis

unsigned short getMaxPayloadSize();

Parameters

None.

Return value

(34)

18 Background

getMinPayloadSize()

The getMinPayloadSize operation returns the minimum payload size that is allowed.

Synopsis

unsigned short getMinPayloadSize();

Parameters

None.

Return value

An unsigned short containing the allowed size.

addTxRoute(2)

The addTxRoute operation adds a mapping between one logical destination and one physical destination. These mappings is used when the pushPacket operation is used in order to route the message to the right receiver. The operation makes it possible to do the mappings at run-time. The platform must call this operation for each and every logical destination that should be reachable.

Synopsis

void addTxRoute (in unsigned short logicalDest,

in MHAL::PF_MHALPacketConsumer::MHALPhysicalDestination

physicalDest);

Parameters

The logicalDest is the logical destination of a data receiver, whereas the physicalDest defines on which hardware address it can be found. This hardware address could very well be the Medium Access Control (MAC) address of a Network Interface Card (NIC). For a more detailed description see [17].

Return value

None.

getRxRoutes()

The getRxRoutes operation is called from the MHAL device to retrieve the available logical destinations within an SCA component. All the retrieved logical destinations are used to route packets within the same GPP.

Synopsis MHAL::WF_MHALPacketConsumer::RxRouteSequence getRxRoutes(); Parameters None. Return value

Returns a sequence containing each logical destination within the called component. An empty sequence, length zero, indicates that the com-ponent is not completed with its configuration of logical destinations.

(35)

2.4 MHAL 19

A sequence of length one containing the value zero indicates that the waveform components do not want to receive packets from MHAL.

2.4.3 MHAL FPGA

The MHAL FPGA is an Hardware Description Language (HDL) capable FPGA without CORBA capability [17, Sec. A.1]. It is a composition of transmit and receive nodes. Since it is more static than the MHAL GPP things like logical destination mappings must be defined before the VHDL4 _{image is loaded onto} the FPGA. Another important thing is that both the waveform components and the MHAL interface towards the underlying transport protocol must be compiled together to achieve a single loadable FPGA image. Since this report is primarily about the MHAL GPP, the part about MHAL FPGA is going to be brief.

Nodes

In the MHAL API document [17, Sec. A.6] several nodes are given as building blocks to create an MHAL capable FPGA. Each node has its inputs and outputs specified, by an entity in VHDL.

Multi-Depth Tx Node

The Multi-Depth Transmit node is a device (note: not an SCA device) con-sisting of a First In First Out (FIFO) buffer capable of queuing up multiple messages to transmit.

Multi-Depth Rx Node

The Multi-Depth Receive node is a device capable of queuing up and hold multiple message to be used by other entities.

Single-Depth Rx Node

Is the same as the previously mentioned node, but holds only a single mes-sage.

RAM Rx Node

A recieve node for data that is placed in user-defined width by user-defined length Random Access Memory (RAM). This can be useful when imple-menting an interleaver in an FPGA.

N-Word Rx Register

A recieve node for data that is placed in a user-defined width register. This can be useful for doing configuration of the FPGA during run-time.

Strobe Rx Node

A recieve node for empty messages, which can be considered as event triggers. 4_{Very high speed integrated circuit HDL}

(36)

20 Background

2.5 Ethernet

2.5.1 Introduction

The development of Ethernet started in the 1970s by Xerox Corporation as an experimental coaxial cable network operating with the data rate of 3Mbps. At beginning of the 1980s the three-company consortium, Digital Equipment Cor-poration, Intel Corporation and Xerox Corporation (DIX), developed what is to be called the version 1.0 of 10Mbps Ethernet. At the same time the Institute of Electrical and Electronics Engineers (IEEE) group began with the work of stan-dardization of Local Area Network technologies available at that time [1]. The Ethernet technology was given the name IEEE 802.3 and has evolved since the middle of the 1980s.

2.5.2 Operation Modes

The first local networks had a topology where the Ethernet acted like a data bus. The problem with data buses is that many clients are to share the medium, e.g. a coaxial cable, but only one client can use it at the time. If two clients would send at the same time, the data would be corrupt. To solve this problem a technique called Carrier Sense Multiple Access/Collision Detection (CSMA/CD) is used. When using this technique every client has equal right to the medium and every client must before every transmission listen to (sense) the medium. If no carrier is present on the medium it is okay to transmit data. In the event of two clients sensing the medium, and find it idle, they both will start transmitting data on the medium. In this case a collision will occur. The protocol forces the clients to continue listen to the medium after the sending has begun. If a col-lision is detected both the sending clients will send out a jam signal to destroy the data on the bus, and will then wait a different random amount of time before retrying. The random wait times prevent the collision to occur again. [16, Sec. 3.1] The cable that is most often used for Ethernet today is a cable containing four twisted pairs of wiring, so called Twisted Pair (TP) cable. Nowadays the cable is not used as a bus but instead used between two Ethernet devices. The reason for the twisting of the pairs is to cancel out electromagnetic interference, e.g. external electromagnetic fields and crosstalk between neighboring pairs, which affects the signal quality. Depending on what operational mode the network interface cards are using different number of pairs are used. The first versions of Ethernet was only using one pair of wires, which lead to data communication could only be done in what is called Half-Duplex. When using more pairs of wires another mode called Full-Duplex can be used. [1]

Half Duplex

The Half-Duplex mode utilizes only one pair of wires and provides the ability to transfer data in both directions; but never at the exact same time. This how the first versions of Ethernet was used which required the CSMA/CD technique,

(37)

2.5 Ethernet 21

to control the access to the medium. Since only data can be transmitted in one direction at one instant of time, it is called Half-Duplex. [1]

Full Duplex

The Full-Duplex mode utilizes at least two pairs of wires and provides simultane-ously ability to send data in both directions. With at least one pair of wires for each direction a collision can not occur, hence no need for CSMA/CD. Transmit-ting data in this way saves a lot time since the wire is never occupied by some other client and retransmission due to collision is not needed. [1]

2.5.3 OSI Model

When talking about computer networks a thing that one always comes back to is the Open System Interconnection (OSI) model which is depicted in figure 2.13. It was formulated by the International Standards Organization (ISO) and describes the connection between systems in a layer based way. Each layer has its features and responsibility towards making data communication possible. In this thesis project the Data Link layer will be of focus since Ethernet is used as the underlying protocol for data communication. [16, Sec. 3.1]

Layer Function 7. Application 6. Presentation 5. Session 4. Transport 3. Network 2. Data Link 1. Physical Application Services (e-mail, file transfer, www) Data Representation, Encryption and Compression Dialog Control and Synchronization

End-to-End Connections and Reliability

Logical Addressing, Routing, Fragmentation and Reassembly

Logical Link Control and Media Access Control Encoding and Signaling, Data Transmission and Reception

(38)

22 Background

2.5.4 Frame Structure

The data that is transmitted via Ethernet is called frames. The first versions of IEEE 802.3 had a frame structure very much like the one in figure 2.14, with excep-tion for fifth field where length could only be specified. However before the IEEE defined the 802.3 standard the DIX group defined what is called the Ethernet v2 frame which is very similar to the later IEEE 802.3 frame. The Ethernet v2 frame uses the fifth field for specifying the the type of protocol that frame is carrying. In later version of IEEE 802.3 standard these two frame structured merged together like figure 2.14. The frame structure specified by the IEEE 802.3 standard con-tains seven fields: Preamble, Start Frame Delimiter, Destination Address, Source Address, Length/type, Data and the Cyclic Redundancy Check (CRC). [16, Sec. 3.1] Preamble Start Frame Delimiter Destination

Address Source Address Length/

type Data and Padding CRC

7 Bytes 1 Byte 6 Bytes 6 Bytes 2 Bytes 46-1500 Bytes 4 Bytes

Figure 2.14. Ethernet frame.

Preamble

The preamble contains seven bytes (56 bits) of alternating ones and zeros. It is a “heads up” for the receiving system that there is an incoming frame. It is also used to help the system with synchronization. In [16, Sec. 3.1] it states that “The preamble is actually added at the physical layer and is not (formally) part of the frame”.

Start Frame Delimiter

This field contains the value AB16 and signals the beginning of the frame. It is used for the host to do synchronization of the incoming frame.

Destination Address

This field is six bytes and contains the physical address of the destination (also known as MAC address).

Source Address

This field is six bytes and contains the physical address of the sender (also known as MAC address).

Length/type

The length/type field can either specify the length of the frame or the type of the frame. If the value is greater than 1536, this field specifies a frame type.

Data

The data field carries data encapsulated from the upper layer protocols. It has a minimum length of 46 bytes and a maximum of 1500 bytes. The upper limit is also known as the Maximum Transmission Unit (MTU).

(39)

2.5 Ethernet 23

Cyclic Redundancy Check (CRC)

The CRC field contains four bytes of error detection information. This infor-mation is calculated before sending and checked by the receiver for possible data corruption. If the data is corrupted the frame will be discarded.

(40)

(41)

Chapter 3

Problem and Solution

Description

In this chapter the problem of distributing a waveform with MHAL will be split into subproblems and discussed how they can be solved. By discussing all the subproblems in a more general way, without going into practical details regarding source code, it will be easier to understand the actual implementation in the next chapter. It is important to understand that these problems can be solved in many ways and the proposed solution in chapter 4 is only one of them. Other techniques to distribute a waveform will also be discussed in this chapter.

3.1 Integration in SCA

3.1.1 Device

Integration of MHAL GPP in an SCA based radio is to be done as an SCA device, which is specified in [17, Sec. A.4]. In order for a waveform to send message with the help of MHAL it is required to talk to an SCA device implementing the MHAL functionality; a device with this functionality must be implemented.

3.1.2 Device Manager

As mentioned in section 2.3.7 all devices must belong to a device manager in order to operate correctly in an SCA radio domain. Every device manager is specified by an XML file. One device manager needs to be specified in order to integrate an MHAL device with SCA.

3.2 Transport Mechanism

The specification given by JPEO JTRS of MHAL is an API and specifies only the interfaces between the waveform/platform and the MHAL device. How the

(42)

26 Problem and Solution Description

actual message transportation is done behind MHAL is totally up to the designer of the radio system. Due to unforeseen circumstances that were out of the author’s control there was no FPGA implementing MHAL available for the distributed en-vironment. And by that the transport mechanism between a computer and the FPGA had not been defined. What this means is that a transport mechanism needs to be designed and implemented. The mechanism needs to be lightweight but still fulfill all tasks required by MHAL. The reason for a lightweight transport mechanism requires some basic facts about FPGAs:

An FPGA is a large array of logical blocks and every logical block can imple-ment different logical operations. It only exist a limited amount of these logical blocks in an FPGA, which limits the functionality that can fit into an FPGA. For a more deeper and comprehensive description of how an FPGA works see [21, Ch. 8]. With a lightweight transport mechanism less logical blocks is needed to do the implementation, leaving more space left for waveform components to exist.

Stream based communication, like TCP, requires a lot of functionality since window scaling is done, every byte chunk is acknowledged and retransmission can be done. This is not considered as a lightweight transport mechanism. A simpler solution is to send the MHAL messages directly on top of Ethernet frames. This can be done since the sender and receiver is going to be connected to the same cable, or alternatively connected to the same switch. The channel in this project is a TP cable and is close to “ideal” when the cable is short and shielded. The NICs are operating at full duplex so no collisions can occur on the channel.

3.2.1 Fragmentation and Reassembly

An MHAL message can be at maximum 65 531 bytes long, which is a considerable size of a packet. It is however not likely to have such sizes of packets since it puts the involved devices to a situation where very large buffers might be needed. A more moderate size of MHAL messages would probably be around a few thousand bytes.

Ethernet uses frames that carries a payload of a maximum size of 1500 bytes, i.e. the MTU. When the MHAL message is bigger than the MTU some kind of Fragmentation And Reassembly (FAR) technique is required to transmit the message. Since this problem has already been studied and solved in the Internet Protocol [7, Ch. 3] it is a good idea to reuse parts of that method for this problem.

3.2.2 Flow Control

In TCP the flow control is done by regulating the size of the receive window and report back to the sender how much can be accepted. This can be done since TCP is stream based and not packet based. But for a more lightweight transmission mechanism which is going to be implemented in this project this can not be done. The only place where congestion or overflow can occur is at the receiver side when packets are not consumed in the same or faster pace than they arrive. Before

(43)

3.3 Protocol for Procedure Calls 27

the receive buffer is full the receiver must notify all other to halt their transmissions for some amount time or until some notification is made.

3.3 Protocol for Procedure Calls

The MHAL message itself is only a packet that is to be delivered to the target destination specified by the LD. In order to invoke some procedure on another hardware in a structured way, a protocol running on top of MHAL is required. This protocol needs to specify the target procedure, the arguments and somehow if the packet is a call, a return value or an exception. Even though there are no pro-cedures in an FPGA, it is still practical to see a set of logical blocks implementing a functionality as a kind of procedure.

3.4 Evaluation

To be able to do evaluation of the implementations without an FPGA, the MHAL device needs to be used on a computer which can be considered as non-CORBA capable device. What this means is that the MHAL device should be modular and have no or less dependencies of OSSIE and CORBA.

3.5 Other Techniques

MHAL is not the only technique that can be used to distribute a waveform over different platforms in SCA. The VITA1 _{Standards Organization has defined the} VITA Radio Transport (VRT) protocol, which is a transport protocol to provide interoperability between SDR components [24]. The VRT standard does not spec-ify anything related to a software architecture, which means it can be used on a variety of different radio systems. However, the VRT standard specifies a packet framework for transporting signal data and signal context information (settings). The packet structure for VRT, which can be seen in figure 3.1, is more sophisti-cated than the one specified in MHAL. Without going into details about each field in the structure, one can see that the structure includes high resolution timestamps and stream identifier. By having high resolution timestamps the radio system can for example perform so called time difference of arrival on signal data, which can be used to accurately locate an aircraft or other objects. With the stream iden-tifier traffic can be separated into several streams and by doing so prioritizations can be done between streams.

The more specified packet structure is more preferable for a designer of a ra-dio system, since less additional protocols needs to be created. However, MHAL includes a specification of how MHAL should be integrated into SCA, which is something that VRT does not specify. Without a specification of how the trans-port protocol is integrated into SCA, problems will arise when waveforms are ported between radio systems. One additional feature with VRT is that VMEbus

(44)

28 Problem and Solution Description Header Stream Identifier Class Identifier Integer-seconds Timestamp Fractional-seconds Timestamp Trailer Data Payload 31 0

Figure 3.1. Overview of VRT packet structure.

International Trade Association (VITA) has also specified an optional link layer protocol, VITA Radio Link (VRL), which provides framing support and error checking when no other encapsulation protocol is available. If using TCP/IP or Ethernet this is not needed. However, if using VRT packets directly on top of Ethernet and packet sizes are greater than what can be fitted in one frame there is a need of fragmentation.

Besides MHAL and VRT, there exists something called the Integrated Circuit ORB (ICO). The ICO which is an ORB implementation for an FPGA, can provide the CORBA functionality that is natively used in an SCA system. The ORB implementation is written in VHDL and includes an IDL compiler so the interface between a component and ICO can be generated [6]. In figure 3.2 the ICO can be seen in the context of communication between a GPP and an FPGA. What can also be seen in the same figure is that an underlying transport mechanism is required. If using TCP/IP one might end up using more space in an FPGA than wanted, and thereby leaving less space left for implementations of waveform components. Since the transport mechanism is pluggable, the ICO together with a more lightweight transport mechanism might be very useful for using in an SCA radio system. However, compatibility problems between ORB implementations can exist since they have been developed by different vendors and by that different interpretations of CORBA can exist. The ICO is an implementation developed by a company and using this implementation of course comes with license costs, which is something that must be taken into account when building a radio system.

(45)

3.5 Other Techniques 29 SCA Waveform Component ORB Pluggable Transport SCA Waveform Component ICO Pluggable Transport GIOP

FPGA

GPP

(46)

(47)

Chapter 4

Implementation

4.1 Introduction

In this chapter the implementation of this project will be described, without going into issues regarding the actual source code. The implementation was primarily done in C/C++ with the exception of some smaller parts in Python. Both the two programming languages are supported by OSSIE. The author chose C/C++ as the language of implementation because of higher performance. The implementation was done towards the 0.8.0 version of OSSIE, which was released in January of 2010.

Since a transport mechanism was to be implemented, a natural way of struc-turing the implementation was in a layer based way, very much like the OSI model. The advantage of doing it in this way is that layers can be changed as long as the interface is kept between them. The resulting structure of the implementation is presented in figure 4.1 and each part will be described in this chapter.

4.2 Integration in OSSIE

The implementation of the CF for this project was the software package called OSSIE. In OSSIE a plugin is available for the development environment called Eclipse. This plugin features a wizard-like environment where code skeletons for waveform components can be generated from selecting options about port inter-faces and component properties. The plugin has also a wizard where the user can quickly create waveforms by just dragging and dropping waveforms components. Then it is just a matter of connecting the components together in the preferred way to achieve an SCA waveform. What this plugin does not feature is a wizard to create SCA devices, which is the way as MHAL should be integrated in SCA. Since OSSIE is an open source project the code for other devices, that are included in the package, is available for developers. One thing that is important to notice is that there is no guide or tutorial of how to create a device in OSSIE. What this means is that the description below is something that the author has come up with

(48)

32 Implementation Routing Fragmentation and Reassembly Ethernet Handler MHAL Device Provides Uses Ethernet

Figure 4.1. Structure of the MHAL device.

during the project and might not be, by some people, the “proper” way of doing it.

4.2.1 Creating an MHAL Device

The creation of the MHAL device was based on the C++ source code of the USRP device which can be found in <Path to OSSIE source>/platform/USRP/. The USRP device has a similar operation mode as the MHAL device must have, i.e. passing data from an upper layer to a lower layer and vice versa. Modifications that were needed are the following:

• Removing the existing ports of the device

• Adding ports of specified type by the MHAL API

• Replacing all filenames containing “USRP” with “MHAL” • Changes in the belonging XML files

• Changes in the make script

The removal of the existing ports is purely done by editing the source code and is too detailed to describe here. Adding of the new MHAL ports is done both by editing the source code but also through compiling and installing IDL files speci-fied in the MHAL API. The procedure of compiling and installing an IDL file is described in a good way in the master’s thesis report of E. Paone [23, Sec. 3.7.2]. By doing so the OE will be able to recognize the port type and communication between such ports will be possible. The MHAL device is fitted with one “uses”

(49)

4.2 Integration in OSSIE 33

port and one “provides” port to be able to pass data to a waveform component in both directions.

The XML files that belong to the device are the SCD file and the Software Package Descriptor (SPD) file. In the latter of these two the only changes required was just replacement of the word “USRP” with “MHAL”. However, in the SCD file the part describing the ports of the component was changed to what is stated in listing 4.1. The providesname and usesname is what the ports will be identified with when connections are specified by the waveform. The port interface that was used for this implementation was the MHALPacketConsumer. The reason for this was that primary goal of the implementation was to get the data communication working.

Listing 4.1. Port specifications in the SCD file.

The last step to get everything compiled and linked required some editing in the

Makefile.in file. Since the contents of these kind of files are very comprehensive,

the changes required will be described very briefly.

The first step was to rename files so it matched with the names of the source code files. The second step was to add additional files required to the list of source code files. The Last step was to change name of the linked output executable. By executing the ./configure command a new make script is generated. Installation into OSSIE is done by invoking: make && make install.

4.2.2 Creating a Device Manager

In the SCA every device is required to be part of a device manager. As previously mentioned in Sec. 2.3.7, a device manager can also be called a node, which will from now on be used interchangeably. The device manager is specified by several XML files like all other components in the SCA. Fortunately, a device manager can be created by an application and thereby requires no manual editing in any files. The application for creating a device manager is called OSSIE Waveform

Developer and can be executed by the command OWD in a terminal.

(50)

34 Implementation

are listed and also predefined device managers. However, since the MHAL device is a foreign device for the OE, a new device manager must be specified. To be enabled to perform tests on the implemented solution which is going to involve waveform components, a device manager containing both the MHAL device and the GPP was created by doing the following steps.

1. Execute the command OWD in a terminal

2. In the marked white box, depicted in fig. 4.2, right click and select Add node 3. When the node appears in the box, the GPP device can be added by right clicking on the GPP device and selecting Add to node. The same procedure goes for the MHAL device.

4. The device manager can now be generated by right clicking on the node and selecting Generate. It is a wise idea to choose the save location to be: <Path to OSSIE source>/platform/nodes/.

5. Once generated, use a terminal and change directory to the location where the device manager is saved1_{. Finally, run: ./reconf && ./configure &&} make && make install

Figure 4.2. Overview of OWD.

(51)

4.3 Routing 35

4.3 Routing

The routing layer needed to do two types of routing; one which involves physical addresses and one that involves the connected ports of the device. The messages coming from a waveform component above was routed by using a mapping of the LD to a physical destination, in this case a MAC address. The second type of routing that was needed to be done used a mapping between the LD of a message, coming from a another MHAL programmable device, to a port.

The interfaces PF_MHALPacketConsumer and WF_MHALPacketConsumer mentioned in Sec. 2.4.2 supports a dynamic way of controlling the routing that occur in the MHAL device. The author however, settled for a more static way of controlling the routing, by allowing the user to define the mapping between LDs and MAC addresses in an XML file before starting the waveform. The actual routing was solved by a so called dictionary where the LD is the keyword. An example of this presented in table 4.1.

LD MAC

0 00:0C:29:61:A4:A1

1 00:0C:29:F5:36:00

2 00:0C:29:61:A4:A1

3 00:0C:29:F5:36:00

Table 4.1. An example of a routing table.

The mapping between an LD and a port, was implemented in a similar way with the only difference that the dictionary contained references to ports instead of MAC addresses. This was however hardcoded in the source code, due to complexity of making it user defined in an XML file.

4.4 Fragmentation and Reassembly

The messages that are transported via MHAL can be of different sizes depending on the functionality of the waveform, i.e. voice communication would require longer messages than simple text communication. When the messages are bigger than the MTU, which is the maximum size of the payload in Ethernet frames, some kind of fragmentation must occur. How the fragmentation is done must be specified by a protocol in order to make it possible for the receiver to reassemble messages in a structured way.

In this project the protocol which specifies the FAR was chosen as a subset of the IP and was going to ride directly on top of the Ethernet frames. The IP has already solved the problem of FAR, but includes many other things that is considered as overhead for this implementation, e.g. IP numbers.

(52)

36 Implementation

4.4.1 Packet Structure

The protocol for FAR handling was specified to have a header like in figure 4.3 and uses only 6 bytes compared to the 20 bytes that is minimum in IP. However, IP includes many other features that are of less interest for this implementation, and are therefore stripped away.

Length Identification _FragmentsFlag and Payload

2 Bytes 2 Bytes 2 Bytes 52-1494 Bytes

MF Fragment Offset 1 Bit 15 Bits

Figure 4.3. Packet structure of FAR.

Length

The length field specifies the size in bytes of the fragment including the header.

Identification

The identification field specifies the id number of the MHAL message which the fragment is part of.

Flag and Fragments This field is divided into two parts; the flag part and the

offset part. The flag part is one 1 bit and is set if more fragments follow. The second part contains a byte offset which describes the position of the fragment within the full MHAL message.

4.4.2 Fragmentation Algorithm

The fragmentation algorithm that was used in this project was very similar like the one presented in [7, Sec. 3.2]. It starts off with an MHAL message and splits it into fragments which are less or equal to the MTU. The algorithm used for this is presented in pseudo code in algorithm 1. The input for the algorithm is an MHAL message.

4.4.3 Reassembly Algorithm

To reassemble an MHAL message out of fragments at the receiver side an algorithm doing the inverse of the fragmentation algorithm is needed. It is presented in pseudo code in algorithm 2. Every fragment is processed by the algorithm in order to reassemble the MHAL message it is part of. The reason for having the fragment offset property in the implementation is that it is a way of checking that all fragments of an MHAL message are received.