September 1999

WIRELESS IMPLEMENTATION: Which Boards Work Best?

BY EMRE �NDER

Today's wireless networks run on proprietary hardware that is costly to maintain and difficult to upgrade. Over the years the wireless protocols have emerged as standards, although some of the older networks run proprietary protocols and place gateways to access different networks. When implementing wireless networks, it is important to note that building solutions that are both scalable and upgradeable will protect your investment of years to come. Selecting products that interoperate with each other and offer upgrade paths to newer protocols and line interfaces helps prepare the network for the third generation (called 3G) of protocols.

Consider all the types of components that are used to make up a wireless network. The BTS (Base Transceiver Station) is used to convert the RF radio signal to a digital signal. Multiple BTSs connect to BSCs (Base Station Controllers), which allow the user to travel between antennas and automatically switch between sites. Finally, you have an MSC (Mobile Switching Center) designed to connect the mobile user to the public network or switch between carriers.

CompactPCI AND WIRELESS
CompactPCI platforms raise the bar for telephony applications, offering higher density solutions for different media applications. Using DSPs as a general purpose hardware component has made applications like wireless networks, voice conferencing, and Internet fax more scalable. Now the CompactPCI platform makes this infrastructure possible in a form factor that is both affordable and flexible.

Although originally conceived for embedded computing applications, CompactPCI’s potential in wireless applications is immediately clear. It offers the advantage of a true industrial strength circuit board in a form factor that is rackable and stackable. Unlike PC cards, cPCI cards are configured in rackmount chassis and are stackable in a “real chassis” — just like real telephony modules. The cards are hot swappable. Cables can break out from either the front or the back, and the modules are easily upgraded.

Thanks to powerful DSPs and 4 or 8 T1/E1 spans on one board, you can now do it all — handle wireless connections and compress the voice calls from ADPCM to A-Law or mu-Law. Products today offer enough DSP resources from as little as 200 MIPS up to 1800 MIPS all on a single card. This can include the WAN interfaces or a separate DSP resource card. Not only can that lower the cost of raw switching by an order of magnitude — it can lower the cost of adding high-value applications to those existing switches

But such potential riches raise an important design issue: Can a plethora of new DSP-enabled functions be brought on board without adding development complexity, impeding run-time performance, and ultimately increasing costs? They can, if packaged in modules that scale as easily at the application level as they do at the board level.

SELECTING THE RIGHT BOARD
What makes this architectural challenge even more exciting is that resources are potentially as varied and complex as each individual application and network. Functions and combinations of functions are implemented as single DSP resources. Typically, these are DSP chips that apply standard algorithms for analog-to-digital, digital-to-analog, and digital-to-digital conversion, allowing wireless phone calls to switch from the standard wired phone to the wireless phones.

Over the years, these algorithms have been perfected and become more robust so that developers need to use fewer of them (or can keep going back to the same ones). While this simplifies the programming challenge, it still leaves many different functions with different real time, inter-process, and host communication requirements for the developer to meld together.

In selecting the right board for wireless DSP resource cards, the programmer must select the desired functions and the desired software architecture. This will prepare them to properly partition the application’s services they are building within and between the various telephony modules and the host CPU — and then to write the program.

In other words, for most CT applications there is usually a best way to designate DSP resources, allocate functions, and partition the system. Not only should the deployment platform be standardized before development begins, it should be application-appropriate. This eliminates the complexity of designing a DSP resource card interface and writing complex DSP algorithms.

WIRELESS NETWORK PROTOCOLS
Today the protocols that are used for compressing the voice calls — like Adaptive Differential Pulse Code Modulation (ADPCM) — must meet industry standards. To access legacy networks, the uncompressed voice calls must be converted to either A-Law or mu-Law depending on your regional/international requirements. These conversions are done using the DSPs.

On another note, the network interface to the public network is either ISDN or T1/E1 signaling. The wireless network side will run a network specific protocol like ISDN (i.e., Q931/LAPD), and in Europe and Asia the GSM protocol is used.

Look to vendors who are committed to these protocols and will work with you to add newer and higher density solutions.

Emre �nder is vice president of marketing, Brooktrout Technology, Data Technologies Division. Brooktrout Technology, a Brooktrout Company, provides enabling technologies for customers to deliver voice, fax, and data solutions for the electronic communications market. For more information, please visit their Web site at www.brooktrout.com