Foreword: This whitepaper discusses telephony server middleware that aims to de-couple cellular modem functionality from mobile phone operating systems. It was written by Blane E. Rockafellow, who co-founded TapRoot Systems, a telephony server specialist that has partnered with Microsoft, MontaVista, Trolltech ( target=”new”>story), and Symbian.

---

Abstracting Telephony: Software Servers for Linux Mobile Phones

by Blane E. Rockafellow

The purpose of this whitepaper from TapRoot Systems, Inc. is to discuss the abstraction of modems and wireless telephony protocols from upper layer applications in Linux based mobile phones. Unlike other common mobile phone operating systems, such as Symbian OS & Windows Mobile, embedded Linux does not have an inherent abstraction layer for communications with the wireless network out of the box. This telephony abstraction layer resides on the applications processor and handles communications between the MMI framework and the actual protocols being exchanged with the modem. (See Figure 1, below.)

Providing this abstraction service allows for faster time-to-market for handset vendors, as well as an isolation of applications and MMI frameworks from the modem. As expected, this will also create independence for the modem vendors from the MMI frameworks and applications.

Linux OS based mobile phones are quickly gaining market traction. One of the key challenges that have been cited in the past has been a solid ecosystem. To address this concern, companies working with MMI frameworks are creating partnerships to address the stability of the applications ecosystem. To solidify and round out this ecosystem for mobile phones, companies like TapRoot Systems are also providing telephony servers to speed the time-to-market for Linux mobile phones.

Linux Telephony Architecture
Where does telephony software fit in the phone?
(Click to enlarge)
Licenses

When developing telephony servers for Linux mobile phone environments, it is a must to be cognizant of the GNU Public License (GPL). It is also important to understand that if the telephony server implementation is done correctly, certain portions of the implementation may not be subject to GPL. For modem vendors or application vendors who do not desire to put their interfaces into the open source community, understanding the limits of GPL and having a portion of the telephony server that is not in the open source is imperative.

Objectives of a Telephony Server

The main strategic objectives of a Linux telephony server are to allow modem vendors the freedom of not having to maintain a separate code baseline for each MMI framework or applications set, while allowing the application vendors freedom from added costs of tailoring their applications to specific modems. One should strive for the following goals within a robust telephony software server solution in order to accomplish these strategic objectives:

• Compatible with Linux distributions from multiple vendors
• Compatible with application processors from multiple vendors
• Delivered as Software Development Kit (SDK) or as a customized product
• Not dependent on additional components (e.g. TAPI, JTAPI) or patches that are not provided with the embedded Linux distribution
• Extensible interface to modems and protocol stack vendors from multiple vendors
• Provide a public telephony services interface that can be used by multiple client applications and servers
• Isolate applications from future changes to telephony hardware and components
• Provide telephony service interfaces to support GSM, GPRS, EDGE, WCDMA/UMTS, HSDPA, CDMA95, CDMA2000 1xRTT, and EVDO Rev A
• Provide a component that contains the telephony services state machines and inter-working logic
• Provide separate layer 3, layer 2 and layer 1 components for interfacing applications to the modem
• Provide re-useable layers for interfacing applications to different modems.
  Solution must be developed in a clean room environment; isolated from other embedded operating systems development efforts
• Provide an architecture that can be enhanced and extended to support other wireless technologies (e.g., Wi-Fi, WiMAX, Bluetooth and IR)
• Allows access to API's via C, C++ and Java programming languages

Components

The architecture of the telephony server for Linux mobile phones must contain components for interfacing user-level client applications to the telephony server. This interface must be provided in a manner that is flexible enough to handle different types of standardized APIs. In addition to a flexible interface to applications, the telephony server must also provide common telephony services and their associated state machines to control the functionality of the modem services and modem control. This allows the isolation of the applications from the modems as well as the wireless telephony technology. Further, with the advent of non-AT Command based modems, the user-level applications need to have isolation from the mechanism that is used to communicate with the modem.

Public Interface, Telephony API Bridge

The Telephony API Bridge component should be designed to provide an abstract Application Programming Interface (API) to client applications requiring access to a phone's underlying telephony services. By using a predefined abstract API, clients are removed from directly interfacing with the phone's telephony hardware. This separation allows the clients to be independently developed and provides a high degree of application portability across different phone platforms, which could employ a variety of telephony hardware. Additionally, the interface must allow for both synchronous and asynchronous completion of commands to support differing application requirements.

Telephony Services

The main functions of the Telephony Services is to include:

• Initializing the telephony hardware and monitoring its events
• Managing standard non-hardware telephony objects such as phones, calls, lines and connections
• Tracking the states and status of the underlying telephony device and the various telephony objects
• Tracking the status of the telephony connection and phone network
• Controlling access to the telephony hardware when requested by multiple clients
• Recover from rare errors such as the network not responding to a user action or an internal glitch

The functions provided by a well-written Telephony Services component should be capable of customization and extensibility for a given phone platform as necessary.

Modem Control

The Telephony Modem Control component should be designed to implement the specific protocols for managing the functions provided by the telephony hardware. Telephony hardware, such as modems, generally provides a layer 3 interface for external components to access their services. The interface typically includes various commands and command parameters for requesting services and their associated responses. It also usually includes a protocol for unsolicited responses as well to alert external components about telephony events such as an incoming call. The message control component must also be capable of being customized to work with the particular telephony hardware's layer 3 interface. This includes formatting the commands, parsing the responses and managing the command mode as called for by the modem's message control protocol.

Comms Device Physical Interface

The lowest architecture layer is the Comms Device Physical Interface. The implementation of this layer is also dependent on the specific telephony hardware, or communications device, included in the phone.

Typically, the communications device is contained in separate telephony hardware that's physically connected to the application processor executing the telephony server. Some type of layer 1 protocol is used to control this physical connection. This generally depends on the connection type. For example, if it's a serial interface using a UART, SPI controller or other serial connection type the Physical Interface would use the standard serial protocol to communicate over such a connection. Similarly, if shared memory is used as the physical interface, then the protocols established for accessing this memory would be implemented in this architecture layer. The design of the phone, along with the telephony hardware it includes, usually determines the physical interface and the layer 1 protocols to use.

Validation and Verification

While the design and implementation of any telephony server is crucial, it is just as important to be able to verify and validate the telephony server functionality. The framework for a test suite must be such that it can test multiple wireless networking technologies, as well as BSP issues that are critical to the functionality of the telephony product. These verification suites should be designed to provide a complete testing and validation engine for complex telephony software components. Using verification suites reduces the engineering time required for debugging the telephony software.

Conclusion

Designs and implementations of Linux mobile phone telephony server abstraction components, such as LinuxTel from TapRoot Systems, create the foundation of a mobile phone platform that can transcend different wireless telephony technologies for 2.5G to 4G networks. Regardless of the direction taken for development of telephony server software, the reality of the mobile phone world is that Linux mobile phones are no longer an oddity, but a real wave of the future.

---

About the Author — Blane E. Rockafellow is Executive VP of Business Development, Co-Founder, and a member of the Board of Directors of TapRoot Systems Inc. TapRoot Systems is headquartered in the RTP area of North Carolina and focuses on the development of connectivity software and systems integration for mobile phones. Blane has over 20 years experience as a developer in embedded software. His direct experience with mobile phone development and the ecosystems that surround mobile phones is over six years. Blane leads the company's technology strategies and business development efforts through securing strategic partnerships.

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.