| ELJonline: Embedding Linux in a Large Wireless Telecom Network |
Jeff Millar (May, 2001)
To keep up with increasing demands for wireless phone coverage, Transcept, Inc. created a system on Linux that also helps keep the cost of coverage down.
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.
Choice of Linux
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.
Choice of Processor
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 (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.
Device Interfaces
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: - Three separate I2C buses for control of RF hardware.
- Serial synchronous port for PPP at 64Kbps over the microwave link.
- Serial synchronous port for Cisco HDLC over 64Kbps V.35 interface.
- Five serial ports (one for Console, local maintenance; one for RS-485 serial, async, multidrop to RF power amplifiers; and three for serial to other processors in the same rack).
- Ethernet for local maintenance.
- Memory mapped I/O to on-board hardware devices; digital RF signal processing ASICs; and signal routing FPGAs.
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.
Development Environment
The next step involved choosing a development environment from the two main alternatives: cross-compiling or compiling on the native platform. We elected to run LinuxPPC on two Macintosh G3s. Users of server Macs generally use VNC (www.uk.research.att.com/vnc) to access them from their Windows desktop PCs.
Naming the Processors
In a large system with many hubs and remotes, operators need a logical way to address the processors for telnet, ping and other network operations. We needed a naming convention that helped operators and technicians. Each system has hostnames for the hub and the remotes. Therefore, we developed a script to build the routing tables based on the hostnaming convention. The system router tables use hostnames to create valid routing tables throughout the TransCell 1900 TM System, as shown in the following example:
m.h.c1.node1.6cmr.id0.customer.com
This hostname contains several fields that pinpoint its corresponding processor within the 1900 TM, as shown in Table 1.
Table 1. Using Hostname Fields to Locate Corresponding Processors
Router Replacement
The 1900 TM prototypes used a commercial router (Cisco 2505) to connect from the Ethernet port on the processor to the DS0 interface. In order to use the DS0 for data traffic, a box called a CSU/DSU converts the telco DS0 format into serial synchronous bits on a V.35 interface. The production design reduces the cost of the system by implementing the V.35 interface on the processor card and using the Linux built-in TCP/IP stack for the router. Since our customers still use commercial routers at their network operation center, the V.35 interface has to remain compatible at the protocol level.
A bit of web surfing quickly led to sangoma, a maker of V.35 interface boards designed specifically to work with a variety of routers. We contacted the company and found them quite willing to sell us the design of their ISA bus S508 board. We purchased several prototypes and connected them in our test-bed configuration (see Figure 2). They worked with the Cisco routers, exchanging TCP/IP packets between a PC running DOS and a PC running Linux.
The V.35 interface connects to a DSU/CSU and then to a dedicated DS0 channel. At the other end of the link, a Cisco router will convert the TCP/IP packets on the V.35 interface to a protocol used by the host computer. The V.35 interface implements Cisco's HDLC protocol.
Figure 2. sangoma Test Setup
Testing the S508 card required downloading sangoma's WANPIPE software from their web site. The kernel parameters were modified based upon the included installation manual's instructions.
After verifying the concept, we designed the sangoma S508 chipset into our signal processing modules (SPM). The V.35 portion of the SPM hardware design was reviewed and approved by sangoma's S508 module architect.
Figure 3 shows the completed design of the sangoma 508 card on our signal processor module.
Figure 3. sangoma 508 Card on Transcept's SPM
We decided to keep the 508 card's ISA bus interface to minimize the changes to the 508 design. This required creating an ISA bus on the SPM by adding a programmable logic device to the IDE port. IDE, PCMCIA and ISA all use the same signals, heritage from the x86 processor bus. Porting the 508 design to the SPM also required modifying the sangoma WANPIPE software driver to compile and run on Linux for the Motorola MPC850 processor module. The changes mostly involved converting the driver from little-endian to the big-endian byte order used by PowerPC and adjusting for physical address differences.
Filesystem
We used BusyBox from http://busybox.lineo.com/. We stripped the filesystem to essentials but kept bash because it has a nice user interface. We elected to use libc.so.6 because it provided binary compatibility between programs developed on the Macs and the Embedded Planet board. This had the side benefit of enabling simple testing of downloaded software, compile it for the Macs and run it on the embedded system.
The total filesystem size is 9.8MB. The results from du / are shown in Listing 1.
Listing 1. Results from du /
The operational system easily fits into 16MB of RAM. The results of cat /proc/meminfo are shown in Listing 2.
Listing 2. Results of cat /proc/meminfo
Conclusion
Although Transcept primarily makes RF systems, we implemented a complex Linux system with a little help from consultants. Our software team made the transition to Linux with minimal problems, and existing C++ code ported quickly to Linux. We found that companies exist to provide support where we needed it.
 About the author: Jeff Millar is manager of advanced development at Transcept, Inc. Jeff is primarily a hardware engineer with signal processing, architecture and RF background. But, he decided to learn Linux (and UNIX) about kernel version 1.0.59. He's applied Linux to aircraft cockpit graphical displays, video processing and now embedded networking.
Copyright © 2001 Specialized Systems Consultants, Inc. All rights reserved. Embedded Linux Journal Online is a cooperative project of Embedded Linux Journal and LinuxDevices.com.
(Click here for further information)
|
|
|
FUEL Database on MontaVista Linux
Whether building a mobile handset, a car navigation system, a package tracking device, or a home entertainment console, developers need capable software systems, including an operating system, development tools, and supporting libraries, to gain maximum benefit from their hardware platform and to meet aggressive time-to-market goals.
Breaking New Ground: The Evolution of Linux Clustering
With a platform comprising a complete Linux distribution, enhanced for clustering, and tailored for HPC, Penguin Computing¿s Scyld Software provides the building blocks for organizations from enterprises to workgroups to deploy, manage, and maintain Linux clusters, regardless of their size.
Data Monitoring with NightStar LX
Unlike ordinary debuggers, NightStar LX doesn¿t leave you stranded in the dark. It¿s more than just a debugger, it¿s a whole suite of integrated diagnostic tools designed for time-critical Linux applications to reduce test time, increase productivity and lower costs. You can debug, monitor, analyze and tune with minimal intrusion, so you see real execution behavior. And that¿s positively illuminating.
Virtualizing Service Provider Networks with Vyatta
This paper highlights Vyatta's unique ability to virtualize networking functions using Vyatta's secure routing software in service provider environments.
High Availability Messaging Solution Using AXIGEN, Heartbeat and DRBD
This white paper discusses a high-availability messaging solution relying on the AXIGEN Mail Server, Heartbeat and DRBD. Solution architecture and implementation, as well as benefits of using AXIGEN for this setup are all presented in detail.
Understanding the Financial Benefits of Open Source
Will open source pay off? Open source is becoming standard within enterprises, often because of cost savings. Find out how much of a financial impact it can have on your organization. Get this methodology and calculator now, compliments of JBoss.
Embedded Hardware and OS Technology Empower PC-Based Platforms
The modern embedded computer is the jack of all trades appearing in many forms.
Data Management for Real-Time Distributed Systems
This paper provides an overview of the network-centric computing model, data distribution services, and distributed data management. It then describes how the SkyBoard integration and synchronization service, coupled with an implementation of the OMG¿s Data Distribution Service (DDS) standard, can be used to create an efficient data distribution, storage, and retrieval system.
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
|
|
|
|
|
news feed