|
|
Abstracting telephony: software servers for Linux mobile phones
2006-12-15 Article Rating:  / 0
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. 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:
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:
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. Related Stories:
|
news feed
