Predictions that VoIP technology would penetrate the mass market have been around for many years. The end of the “dotcom” boom in 2000–2001, however, brought with it a slowdown in the telecommunications market in general, and the VoIP market in particular. Nowadays, we see that VoIP is finally moving from the early adopters market to the mass market. Additionally, we see that video is becoming the next “killer application,” as evidenced by its wide adoption by the 3G market. This trend brings video into the home, office, and contact centers as well. Telecommunication equipment manufacturers can achieve reduced time-to-market for Triple-Play infrastructure products by using off-the-shelf media processing tools, such as media processing DSP farm boards and DSP chips. Additionally, many factors must be taken into consideration when choosing such development tools.

VoIP Is Not Only Voice

Looking at the requirements from a customer’s perspective, simply porting the currently available PSTN services to VoIP is not justification enough for an organization to undertake the required investment in replacing their TDM systems. Users want to be able to use a single device as their mobile phone, wireless terminal in the office, and home phone. This device should provide features such as: real-time conversational voice and video, video streaming, video mail retrieval via the device or via e-mail, enhanced presence capabilities that will be integrated with location-based services, and provide information — not only about the availability of each person on the “buddy list” but also the services to which she has access — and messaging. Providing these services in a cost-effective and high-quality manner requires seamless roaming of the device between the different networks, and service availability across the networks. This dictates the following requirements:

1. Bridging between the following networks:

a. Broadband wireline IP network, mainly using SIP but also using legacy H.323 equipment.
b. Broadband wireless IP network (WiFi and WiMAX) using SIP.
c. 3G real-time conversational voice and video, currently using 3G-324M and SIP in the future.
d. Voice PSTN network.
e. Video over PSTN using H.324.

2. Connectivity between devices in these different networks: Since each network has its own characteristics, the devices support different protocols and have different media characteristics. Even when both devices support SIP there are cases where media bridging/processing is required.

Off-the-Shelf Versus In-House

As part of the design and planning of new voice and video infrastructure systems — such as gateways, conferencing bridges, media servers, and video mail servers — the manufacturer needs to decide whether to use available off-the-shelf solutions or to develop an in-house solution. Depending on the approach taken, the company will need to invest in development of different components resulting in varied time-to-market levels:

In-house only

This approach requires more than 25 R&D years to develop the following required software components:
• A complete DSP framework.
• Voice codecs, including the required voice features: echo cancellation, signal detection and generation, events detection, voice activity detection, n-way conferencing — including dominant speaker detection — and many more telecommunication features. Additionally, this type of voice implementation would require years of field-hardening prior to becoming robust and bullet-proof.
• Video codecs, including video processing features such as: frame rate change, resolution change, video conferencing algorithms, and text overlay.
• Development of other media types, such as fax and modem, if required.

In addition to the software development, an optimized DSP farm board must be developed, a task which requires additional, significant R&D resources. This board would typically be a PTMC or AMC daughter card that rides on a cPCI or ATCA motherboard. The manufacturer would need to purchase an off-the-shelf motherboard and perform the required integration work, or develop this component from scratch.

DSP software/DSP fully-loaded with software
This solution includes the DSP framework as well as the media types that run on it. Choosing this level of integration will require the manufacturer to invest significant resources in both development of the DSP farm board, and integration or development of the motherboard.

A complete off-the-shelf DSP farm solution
This solution comes pre-integrated with a motherboard and includes all the components described above. Choosing this approach will result in greatly reduced time-to-market. It will enable the manufacturer to invest all development resources to focus on and enhance its application. This approach maximizes the added value of the manufacturer’s application, providing competitive differentiation and the reason for customers to buy the end product.

Regardless of the actual development approach chosen from the four described above, the following decisions must also be made:

• Choosing the DSP farm board architecture.
• Choosing the media processing software architecture.
• Choosing the DSP.

Choosing The DSP Farm Board Architecture

A DSP farm board needs to handle high throughput of media while simultaneously receiving controls and sending monitors. Some applications require a simultaneous interface to TDM and IP, while others require an IP interface only (i.e. Session Border Controller). Traditionally, the TDM front-end connects through an H.100 interface, and communication with the host processor is via Host Port Interface (HPI). For this architecture the host processor needs to handle both DSP traffic aggregation, providing it interface to the IP network, and the control application (that in many cases includes the signaling stacks). These two tasks are different both in nature and requirements. Since the host processor usually runs operating systems such as Windows, Linux, and Embedded Linux, it is not optimized for the aggregation task. Running these two tasks on the host processor causes media and control to compete for resources, resulting in system quality issues (since delay is increased). Additionally, the butterfly effect may occur, wherein one DSP prevents access to the bus due to implementation issues or DSP failure, in turn causing a complete board fault. In order to create a balanced DSP farm board it is necessary to separate media and control functions. This can be achieved only if the DSP has a direct interface to the IP network, which will allow media to be sent over UDP/IP using RTP. This type of architecture enables aggregation using on-board layer 2 and 4 switches (Figure 1).

Effective Usage Of DSP External Memory

Adding media types such as video and enhancing the system with new features requires external memory on the DSP. Additionally, external memory allows storage of data — such as prompts and buffering of media for streaming/recording applications — avoiding intensive host-to-DSP data transfer bottlenecks.

Having external memory in a DSP-based media processing device does not necessarily mean that it will be used in the most effective manner. In order to optimize external memory, the system architect must ensure that:

• External memory size and width comply with current application needs and leave enough room for future expansion.
• Access to external memory data is performed through a predictive caching mechanism. Accessing the external memory using a caching mechanism can reduce the memory access duration by up to five times.
• A mechanism for off-line data transfer from the host to the DSP’s external memory is established. This mechanism will simplify the host-to-DSP interface, and enable the host to view the DSP memory as an expansion to its own memory.
• Access to external memory should be mainly through DMA operations that work in the background, transferring blocks of data from external to internal memory and vice versa.

Choosing The Right Media Processing Software Architecture

Many telecommunication equipment manufacturers are taking note of their customers’ interests and making their way into the video arena by enhancing their voice solutions to support video. Most currently-available voice and video media processing solutions do not run these two media types on the same DSP. Some use different DSP types for each media and some use host processing for one of the media types. Additionally, transport protocols such as RTP for IP and H.223 for 3G-324M do not always run on the DSP. These types of solutions are usually expensive and their quality is questionable due to:

a. synchronization issues between voice, video, and the transport protocol (RTP or H.223)
b. delay issues

If a media processing development tool based on the architecture described above is chosen, there is no flexibility to add new features and media types. Consequently, these additions will require “special” (read: resource/time-consuming) work on the part of the manufacturer. Overcoming these issues requires running all media types (voice, video, and data) and the transport protocols (RTP/H.223) on the same DSP. This approach will also allow run-time flexibility for the ratio between voice and video channels running on the DSP. The DSP software should include an “Open Framework” that is actually a pseudo operating system that can handle missions such as scheduling of DSP tasks, memory access, and “sockets.” The framework should be open, with “hooks” to allow the manufacturer to plug the proprietary algorithm into the DSP, thereby enabling flexibility for addition of new features independently of the DSP software and board vendor.

Choosing The DSP

After reviewing the above architecture considerations, the requirements of the DSP can be summarized as follows:
• Provide external memory interface in order to have sufficient room to support new media processing tasks.
• Support IP interfaces directly from the DSP to enable socket-like interfaces with the network for every task.
• Possess adequate processor performance for execution of complicated tasks, such as multi-channel Video processing.
• Feature a wide range of vendors that provide software components optimized specifically for this line of DSPs.

To date, the only line of DSPs that complies with all the above criteria is the C64xx DSP generation by Texas Instruments. More specifically, TI’s C6412 DSP can support 64Mbytes of external memory, it has a fast Ethernet interface, it can perform multiple video stream compression/decompression, and it enjoys an impressive array of third-party companies that develop all kinds of new protocols/stacks. Additionally, this DSP is capable of simultaneously running all media types, such as voice and video if the right framework is used.

In conclusion, as media processing becomes more complicated and feature-rich, and since time-to-market is more crucial than ever in the current competitive market, choosing an off-the-shelf solution that takes into consideration all the requirements described in this article, and that includes a comprehensive open DSP framework that runs all media types (voice, video, and fax/modem) simultaneously, will allow telecom manufacturers to focus their resources on their added value — their application. This will result in best time-to-market and highest value to the customers. IT

Amir Zmora is vice president of marketing and product management at Surf Communications. For more information, please visit the company online at www.surf-com.com.

If you are interested in purchasing reprints of this article (in either print or HTML format), please visit Reprint Management Services online at www.reprintbuyer.com or contact a representative via e-mail at [email protected] or by phone at 800-290-5460.