When we first heard about the requirements for a project to network-enable to point-to-point broadcast radio we thought ``Kevlar, eh?'' The radio's goal (well, one of them) was to provide wireless communications in regions where traditional fiber optics were infeasible. We were surprised to hear that (particularly in countries with considerable political turbulence) fiber-optic cables were being dug up and raided for their valuable Kevlar sheathing (likely for home-brewed bullet-proof accessories). In these situations we were told wireless communications were ideal.

A typical radio installation may consist of 50-500 units arrayed in a manner to relay a digital signal across a large radio network. At each node a pair of radios provide point-to-point connectivity with the next node in the network (see Figure 1). These networks are frequently expansive, capable of spanning thousands of miles of often difficult-to-navigate terrain (one such installation is in the Amazon rain forest). Although each radio unit is preconfigured for installation, there are a number of adjustments and parameters that require routine attention. These include determining whether a radio is operating on a primary or secondary transmitter, measuring power supply voltage readings or verifying transmission frequencies.

The radio has a front panel that can be used to retrieve and adjust configuration parameters, but to do so requires an on-site operator. To ease administration and monitoring of a large network (particularly those, like the fiber-optic replacement, where it may be inconvenient or dangerous to service regularly on location), Moseley Telecommunications, our client, decided to add a suite of network accessible features. Since the existing radio was already reliable, Moseley wanted to minimize changes. They decided to add hardware to provide the additional functionality (dashed box, Figure 1).

Figure 1. Radio Diagram

The project requirements were as follows: to allow radio users the ability to use common TCP/IP protocols (SNMP and HTTP) to view and update the state of their radio, add network connectivity (routing) between units and add support for an Ethernet connection. These requirements were subjected to the following constraints: to support the existing I<+>2</+>C backplane, minimize software licensing costs and develop a working, embeddable prototype in just under two months.

Moseley was already leaning toward Linux software with a hardware choice of Bright Star Engineering's (BSE) ipEngine platform. The ipEngine board sported a Motorola MPC823 PowerPC processor (with I<+>2</+>C support), 16MB RAM, 2MB flash, 2 serial ports, 1 Ethernet port, a 16K gate FPGA (that went unused in this project) and a small footprint that would embed nicely into the existing radio case. At the time of development, the only available OSes for this system were a proprietary RTOS and a thinned version of Linux/PPC supplied by BSE. Since many of the desired features for this project were available in Linux distributions and there were no real-time constraints, we opted for the Linux OS. By choosing the BSE/Linux system we had already met our first two constraints (I<+>2</+>C support and zero-cost licensing). Next, we had to develop a working prototype in under two months.

The idea of developing a working prototype system on a Linux base under strict time constraints appeared a bit daunting at first. However, our experience with Linux software has demonstrated the power of an Open Source community with high-software availability at no cost. On the other hand, we became aware of some of the drawbacks of an Open Source community; namely, sometimes difficult to access community-based technical support, sparse documentation and the possibility of conflicts on differing platforms. These difficulties are often mediated by the responsiveness of developers in this community. However, time being precious, we did not want to get bogged down finding an ex-package maintainer or go through extensive porting of applications.

There were, fortunately, many factors in favor of Linux. Since SNMP and web support are widely available in Linux distributions, a large amount of time could be saved if clean ports could be made to our target platform. In addition, the fact that the Motorola-based target platform supported Linux/PPC allowed us to employ a standard PowerPC system running Linux/PPC 2.2.13 as a development environment and staging platform. This was a significant improvement over the Windows-based cross-compilation tools provided in the BSE package, making our full-system testing cycle as short as possible, which aided tremendously in keeping the project on schedule. Additionally, because this was a prototype system, we were able to use a rather complete target hardware system and not have to be as careful about memory restrictions as in a production environment (where purchasing large RAM and flash chips might be a bit hazardous).

Our project specs required several technologies to be integrated into our Linux system. We started the process by implementing the routines that would connect to the radio in order to set and return parameters. The project originally entailed using a platform that could support I<+>2</+>C calls on the radio's back-plane in the future. However, there was already an existing serial port interface to read the radio's settings in bulk and to set operating parameters. We decided to use this existing system in the prototype while minimizing the difficulty in switching over to the I<+>2</+>C bus in the future. The only drawback was that the serial port ran at 9600Bps with a one- to two-second total requirement for a full system state reading. This delay made it impractical to initiate a read whenever a request for data came to the system, and instead the radio was polled every three to five seconds with the current state kept in a shared memory location. Once reading data was handled, we created a small library that updates modified settings on the radio unit. We decided to let this library access the serial port directly, even with a known delay of several seconds, as writes occur much less frequently than reads and a user would usually be interested in whether the setting was accepted by the radio (indicated by the write attempt's return code). With the ability to read settings from, and write settings to the host radio, we were ready to approach the development of SNMP, web and network services.

The Linux Open Source community provided resources that could be adapted to our implementation. We decided on using UCD-SNMP as our SNMP agent, Apache as our web server and PPPD for our extended network support. Why the need for extended network support? Although the BSE hardware is equipped with an Ethernet connection (for local network connectivity), the radio units are often placed in remote locations where a direct network connection is inconvenient. To overcome this limitation, we took advantage of an auxiliary communications channel on the broadcast radio unit. The auxiliary channel was a small portion of the radio's bandwidth dedicated to direct communication between two paired units. In this case, the channel appeared to us as a 9600Bps serial port directly connected to an adjacent unit. Over this channel we would need to route TCP/IP packets from any machine in a radio network to a machine connected to a monitoring station (or larger network).

We decided to use this side-band channel to create a PPP connection between a pair of machines (Figure 1 reflects configuration environment). Our system differed from a standard dial-up usage of PPPD, where one processor runs the dæmon as server while another acts as a client by initiating a connection. In our application, the radios had to self-configure as much as possible, making a client/server toggle on the box a nuisance. To resolve this issue, we looked into other modes of running the standard PPPD and came up with a peer-to-peer operating mode. In this mode, PPPD waits on a specified port until it sees a connection (in this case by another machine running PPPD in the identical manner) and then attempts to establish a direct connection. Since a locked radio connection is necessary to establish this connection, we were able to disable the login-password authentication process. This is the exact functionality we desired, and it became the basis for a network that supported the complete TCP/IP functionality.

With the existence of a standard network (albeit slightly slower than what we were used to working with), we started work on the web server that would present the radio's state information and allow for modifications to the system's settings. Apache was already available for the Linux/PPC platform and built with no major issues. We thinned out the install and readied paths to a set of C CGI programs that would generate pages and handle requests to change the radio parameters. These C programs accessed the shared memory filled with the radio's current state and linked to the serial port library that provided parameter updates.

Our last major requirement, the ability to serve SNMP requests, was the longest aspect of the project design. This length was due to the fact that the general implementation of an SNMP agent is much more complicated than serving the same information on a set of web pages. One important reason for this is that SNMP transmits semantic information (not unlike XML) along with each requested datum and, therefore, requires a much more complex design specification and implementation. This design specification is referred to as a MIB (Management Information Base), and its main use is to inform an SNMP browser how to retrieve and interpret the data returned by an SNMP agent. The SNMP agent in this case was UCD-SNMP and required modifications to the agent itself in order to serve the MIB for our project. We extended the UCD-SNMP code in the same manner as the C CGI programs for the web server--accessing shared memory for reading parameters and linking our serial library for updates. The UCD-SNMP dæmon was already ported to the Linux/PPC platform. With two minor bug fixes to the dæmon (and exhaustive fixes to our own modifications), we were ready to serve our own MIB.

Knowing that in some installations an intranet or Internet connection may be made to a radio, security was an issue in accessing or setting any information from or to the unit. Since Linux is a very security-conscious environment, we were able to establish security restrictions easily. The two forms of accessing the machine are HTTP and SNMP. Since Apache has a very well-supported authentication scheme, we mapped user security requests into .htaccess and .htpass files located in our CGI directory. Apache was told to look at these files to filter incoming IP addresses and to request authentication (user and password) to access the CGI scripts. The same security information was adapted to the UCD-SNMP configuration file format and, with a HUP of the dæmon, readily updated based on user preferences (settable through CGI or SNMP calls).

Once we finished testing the prototype on our PowerPC system, we used the ipLinux flash tools to upload our 1.8MB compressed memory image (using tftp over the board's Ethernet) to the target platform. We spent some time debugging this initial port, which mainly consisted of diagnosing a miscompiled library that was not built to take into account that the MC823 has no floating-point unit. With the ipLinux board installed into Moseley's radio system, we achieved the main functional goals of the project prototype, i.e., supporting interunit network connectivity, serving web-based content and providing SNMP support. There were a few remaining issues, such as keeping the system state when power is toggled, as well as some optimization concerns. The system state was handled by tarring up a set of data files that represented runtime change (such as security settings) and storing the tar file (capped at just under 50K) in the remaining 200K of Flash memory. Although the optimizations had to be handled by traditional techniques, having a Linux environment on our target board made it easy for us to test our progress. For example, instead of forking a process to poll radio parameters from the serial port into shared memory, we let the shell handle this chore for us with a simple script (see Listing 1) and background command:

./run &

Listing 1. Updating Shared Memory

It was then trivial to separate the testing of the port accessing routines from the rest of the system during testing and to vary the radio polling rates during optimization.

Let's take a look now and see what gains we made (and risks we took) using embedded Linux for this prototype.

Being able to use the familiar and standardized GNU-based tools and development environment allowed us to concentrate our time on building project code with very little time spent on proprietary code. Programming in the standard UNIX C-based environment utilized our existing knowledge and eliminated the need to learn the proprietary APIs of a non-UNIX-based embedded system. We also did not have to reinvent software since we were able to integrate high-quality, freely available software packages. This allowed us to spend more time adding features and debugging rather than rewriting software that had already existed in other forms.

Although there was some initial doubt about the avenues for support of the open-source software integrated into our project, we were pleasantly surprised to receive great responsiveness for the issues that did come up, specifically with UCD-SNMP. This could have been due to our usage of popular Linux packages, and we may have found ourselves in a different situation if we needed something more obscure. However, with the tremendous amount of interest currently brewing over the use of Linux in nearly every type of application, we will probably see more organized support channels appearing for lesser known open-source packages in the near future.

There was also another, less obvious, risk of being limited in the amount of optimization that we could achieve using the high-level of functionality provided to us by the Linux OS. In a non-Linux-based approach, we could have built a much tighter integration to our hardware configuration. This is definitely a trade-off in using the Linux system, although if we were interested in making specific enhancements to our hardware, we could always rewrite parts of the Linux OS (since it too is open source).

Finally, we were able to build a timely product that was free from royalties and software costs. Under our conditions, Linux ended up being an ideal choice for an OS and saved us a large amount of application development time. While Linux can be ``rough around the edges'', Linux and its supporting community proved to be a mature and competent solution to this project's development choices.

RESOURCES