Home Articles GPRS connectivity through dial up and Networking - Part II

Articles

[+] Articles

GPRS connectivity through dial up and Networking - Part II

by R. Vinoth

Introduction

People involved in Windows Embedded development should be aware that Windows CE provides GPRS communication through the cellcore architecture (Cellular TAPI service provider) and through the Telephony API (TAPI 2.0 Unimodem driver). Cellcore architecture is highly featured architecture and it expects the GSM modem with high capability. Unfortunately not all the modems support all the features expected by the cellcore architecture. Also highly featured modems are not preferred for some applications because of the hardware and software cost constraints. In these cases cellcore architecture is not preferred, instead applications can use Telephony API provided by Windows CE. Using TAPI is not straight forward and has limitations that need to be addressed. This article focuses on addressing these limitations.

Intended Audience

The Part 1 of the GPRS Connectivity article (Making GPRS connections in Windows CE 6.0) focused on establishing a DATA connection through GPRS using the dial-up networking.

The audience of that article raised a number of queries like

1. How to send an SMS when data connection is ON?
2. How to access the address book on the SIM or how to get the signal strength?

There is a single solution to all the above and similar questions.Being a part of Windows CE Device Driver and WinCE BSP Development team, we came up with this article that shows the solutions and implementation. This article would cater to a variety of audience including engineers, managers and wince enthusiasts who want to have parallel activities like signal strength detection, address book lookup, etc. to happen when the data connection is still ON.

Scope

The scope of this document is limited to the modems that support the CMUX protocol (part of the GSM07.10 standard).

Telephony API

Telephony API (TAPI 2.0) is developed and used to establish the data communication through the AT command based modems. Since the GSM modems are AT command based modems, TAPI is used for GPRS data communication. Using RAS APIs GPRS connection could be established.

Figure 1 - TAPI Architecture

(Click image to enlarge)

Telephony API uses the universal modem driver (TSP for AT Command modem) to establish the GPRS connection. The unimodem uses the serial port driver to access the modem.

Limitations of unimodem architecture

In general once the GPRS communication is established, the corresponding serial port becomes busy and is not accessible by the other processes and it is dedicated to the unimodem driver. This is a great barrier to access some simple features of the GSM modem like getting the signal strength, accessing the phone book etc., unless there is a dedicated port for accessing these features. Unfortunately not all modems support the dual serial port to access the GPRS and the other modem features simultaneously. Also increasing one more serial port increases the hardware overhead. The following section will explain the architecture of modern day GPRS modems and also how to use the internal multiplexer provided by the modem to resolve this limitation.

Architecture of contemporary GSM/GPRS modems

Figure 2 GSM Modem Multiplexer

Figure 2 illustrates the architecture of a GSM/GPRS modem. As shown above each GPRS/GSM modem has a internal multiplexer which takes the commands from the serial port and then internally passes on to the respective channels like circuit switched data, packet switched data, status/control, phone book access,etc. Basically, the client application communicates with the MUX (though this involves several steps as indicated below). Most of the contemporary multiplexers are designed to support CMUX protocol(part of the GSM07.10 standard) which operates between the GSM/GPRS modem and a Terminal equipment(TE ) and allows a number of simultaneous sessions(channels) over a normal serial asynchronous interface. Each session(channel) consists of a stream of bytes transferring various kinds of data like voice, fax, data, SMS, CBS, phonebook maintenance, battery status, GPRS, USSD etc. This permits SMS and CBS to be transferred to a TE when a data connection is in progress. Many other combinations are possible including digital voice. It is, for instance, possible to transfer digital voice in combination with SMS. Each channel has its own buffer management and flow control mechanism. The CMUX protocol supports up to 64 channels as illustrated above.

Windows Embedded CE 6.0 GSM 7.10 MUX driver

Windows Embedded CE 6.0 supports GSM0710 multiplexer driver as a component in the cellcore architecture and this multiplexer driver is a separable component from the cellcore architecture. Depending on the modem's capability the channels will be available to be accessed as a virtual serial port to the applications. Normally GSM modem will not be in the multiplexer mode. GSM0710 multiplexer driver will send the AT+CMUX command to enable the multiplexer mode and following that the driver will send SABM frame for requesting the channel. The first channel is the control channel and the remaining channels are the communication channels. These communication channels are exposed as virtual com ports. Figure 3 shows the interface between the multiplexer enabled GSM modem with the windows CE Device.

Figure 3 - GSM Modem interface with Windows CE multiplexer driver

Integrating the unimodem driver with MUX

An approach to perform the multiple simultaneous operations on GSM modem as described above, is would be to use the virtual serial ports exposed by the MUX driver. There are two ways to do the GPRS data communication. The first way is porting the unimodem driver to establish the GPRS data communication through virtual serial port and the other way is writing own TSPI driver that will do the same. For both the cases engineers must have a good understanding on the GSM.07.10 windows Embedded CE 6.0 driver as well as an idea of how the TSPI driver works.

Developing proprietary TSPI driver

Sample TSPI driver is provided in the "wince600/public/common /oak/ drivers /SAMPTSPI" directory. Using this driver proprietary TSPI driver can be developed. The issue is the development time and the testing time duration is high.

Porting the Unimodem driver

Figure 4 illustrates how the unimodem driver can be integrated with the MUX driver. The unimodem driver needs to be ported since the MUX driver may not be supporting some IOCTL calls the unimodem might be expecting. Porting the unimodem driver won't take time, since the driver is already developed and tested.

Expected Issues

The GSM.7.10 multiplexer driver provides the virtual serial ports. This multiplexer driver is implemented as a normal serial port driver and it has to handle lot of IOCTL calls from the unimodem driver. The unimodem would be expecting a serial driver whereas there is a multiplexer driver which is taking these calls. These IOCTLs are accessed through the standard serial port driver APIs. Unfortunately multiplexer driver doesn't support all these IOCTL calls. For example, consider the "PurgeComm()" API. This function can discard all characters from the output or input buffer of a specified communications resource. But this API's corresponding IOCTL is not implemented in the multiplexer driver. But the normal serial port driver will support this call. Hence some function call backs in unimodem driver have to be removed or some API calls have to be implemented in the multiplexer driver.

Figure 4 - TAPI on Multiplexer

Benefits

Simultaneous data connection, usage and access of other features like SMS, address book, etc.

Possible to write custom application with seamless voice and data communication.

The voice communication support on cellcore architecture is in Windows CE professional license.
Writing custom application for voice communication and using the unimodem for data communication
will be cost effective.

Conclusion

Thus a multiplexer enabled GPRS modem can be used to send both data as well as used to send SMS, access phone book, etc.