Embedding Linux in a Large Wireless Telecom Network

The demand for wireless phone coverage continues to increase and wireless company operators need to provide coverage along major highways, especially interstates. However, providing coverage in rural areas requires building expensive telephone infrastructure. Transcept, Inc. produces signal distribution systems for wireless communications designed to directly benefit operators of wireless networks and providers of communication bandwidth. Our TransCell 1900 TM provides a lower cost way to provide coverage along highways by forwarding the RF signals of phone calls over a microwave link to remote locations along the highway. The product digitizes the phone call at what we call a ``hub'', multiplexes multiple calls into a data stream and sends it to a ``remote'' location to connections to the antenna. The remote locations don't need a full base station or an expensive T1 line. This architecture (shown in Figure 1) typically reduces by two-thirds both the capital expenditures for base station equipment and operational costs for backhaul.

Figure 1. Transcept Build-out

Monitoring and control access to the TransCell 1900 TM System is provided both locally and remotely. Local access for monitoring and control is in the form of an Ethernet port and an RS-232 console port. Maintainers can use a laptop computer to plug in at either hub or remote locations. Transcept supplies System Element Manager (SEM) software that continuously captures alarm data from the wide area network (WAN) that connects the customer's wireless network operation center (NOC) with hundreds of hub-remote pairs (HRP). The SEM displays alarm data for review, and it is made available to the network's operation support services (OSS).

The network uses a 64Kbps circuit with the T1 interface to the hub to carry Cisco HDLC traffic between the NOC and the hubs. The hubs and remotes connect via a 64Kbps circuit over the microwave link that runs PP.

Each part of the system needs a processor and operating system to initialize the hardware, perform startup test, control and monitor the system, generate alarms on failure and communicate with the NOC. Transcept's previous products used DRDOS on the x86 family processors. This provided a simple, familiar operating system with a decent programming environment. However, DRDOS provided weak networking support. Plus, DOS clearly had reached the end of its life, with only dwindling support available. The alternative fell in two broad categories, Linux or some other real-time kernel (VxWorks, pSOS, etc.).

We chose Linux because it provided an OS with excellent networking, lots of growth potential, robustness and reliability, lots of good software and growing ``mindshare'' in the software community.

Once we chose Linux, we had to choose a processor family. We had the most experience with the x86 processors, but since we used C++ over DOS, the software team didn't have a strong preference. We needed a processor that was cheap, simple and rugged enough for outdoor use without heating or cooling. We considered x86, PowerPC and ARM. Some experience with certain x86 embedded processors (clones) indicated they failed after temperature cycles and didn't survive long in outdoor service. ARM didn't have an embedded processor board with a Linux distribution (when we looked). Past work with MPC850s (Motorola single chip PowerPCs) showed they operated over a very wide temperature range. A bit of web surfing turned up Embedded Planet (http://www.embeddedplanet.com/) and their RPX series of low cost processor boards. EP supported a Linux port and put us in contact with the guru of Linux on embedded PowerPC processors, Dan Malek. After talking to Dan, we choose the RPX boards.

When we started this project, Dan provided kernel snapshots from his personal FTP site. We definitely got in on the ground floor with this, but it worked out well in the end. MontaVista has since released Hard Hat Linux for the RPX. We regularly compare their distribution with ours and incorporate fixes relevant to our system. We also contribute our bug reports and changes back to MontaVista.

We then considered the hardware interfaces the OS must support and the difficulty in writing device drivers. Linux has a reputation for clean simple drivers, but any work in the complex UNIX environment will have some learning curve. The hardware interfaces to the processor and OS include:

We decided to use memory mapped I/O for access to the I2C ports, and hardware registers and real device drivers for the communication ports. Memory mapped I/O means we run the user-space programs with root privileges and allow them to map selected portions of the physical memory space to user space. This approach completely bypasses Linux security and memory protection features, but few embedded applications really need it. Besides, we can always go back and use a device driver to provide access to the I/O registers from non-root user processes.