|
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. |
|
|