Patent Grant
7454198
This Application is a Section 371 National Stage Application of International Application No. PCT/FR02/01024, filed Mar. 22, 2002 and published as WO 02/078375 on Oct. 3, 2002, not in English.
The domain of this invention is radiocommunication systems, and particularly but not exclusively the GSM (Global System for Mobile Communications) standard, DCS 1800 (Digital Cellular System 1800 MHz), PCS 1900 (Personal Communication system), GPRS (General Packet Radio Service) or UMTS (Universal Mobile Telecommunication System).
More precisely, the invention relates to a radiocommunication module. Remember that the radiocommunication module is an essential element of a radiotelephone. It hosts and executes a main software (commonly called “radiocommunication software” or “GSM software”) that in particular performs wireless communication functions (radiocommunication) and controls various other hardware elements (screen, keyboard, loudspeaker, etc.) of the radiotelephone.
Normally (first application), the radiocommunication module is included in a terminal (or ME for “Mobile Equipment”) that cooperates with a SIM (Subscriber Identity Module) card.
Other applications are now envisaged for the above mentioned radiocommunication module.
In particular, it has been proposed to integrate the radiocommunication module in devices other than radiocommunication terminals but that still require a wireless communication function (second application). For example, telemetry devices (for reading meters), alarm devices or bank card readers.
It has also been proposed to supply the radiocommunication module in independent form (third application); it is then qualified as a modem. This type of modem does not contain any hardware man-machine interface element (screen, keyboard, loudspeaker, etc.). It is designed to cooperate with a terminal equipment (supporting a client software), that does have hardware man-machine interface elements. In particular, but not exclusively, the terminal equipment may be a microcomputer. In general, the terminal equipment hosts and executes a client driver software that controls the radiocommunication module, using a set of driver commands in the AT format. The AT (for ATtention command) commands enable the Terminal Equipment (TE) to request the radiocommunication terminal to which it is connected to perform some predetermined actions. To achieve this, the main software (hosted on the radiocommunication module) comprises means of executing AT commands sent to it by the client driver software (hosted on the terminal equipment).
For further information about AT commands, refer firstly to the ETSI “GSM 07.05” and “GSM 07.07” standards, and secondly to the ITU-T recommendation V25ter which are inserted herein by reference.
In general, a radiocommunication module can be driven by a terminal equipment using AT commands not only within the framework of the above mentioned third application (radiocommunication module forming a modem), but also within the context of the first and second applications mentioned above (radiocommunication module included in a radiocommunication terminal or other system).
In other words, regardless of what application is envisaged, the radiocommunication module may be driven by a terminal equipment with which it cooperates (usually through a serial link). In this case, a client driver software (comprising a “client external application”), hosted and executed by the terminal equipment, sends AT commands to a main software, hosted and executed by the radiocommunication module, so that the radiocommunication module can execute them.
As shown in
Each of these steps is shown in
The existing technique for driving a radiocommunication module by terminal equipment has several disadvantages.
Firstly, it requires two sets of resources (processor and memory). The radiocommunication module comprises a processor and a memory (first set of resources) and the terminal equipment also has a processor and a memory (second set of resources). Therefore, the existing technique mentioned above is expensive in terms of equipment and energy consumption.
Another disadvantage of the above mentioned existing technique is that the radiocommunication module is entirely driven by the terminal equipment. The client driver software hosted on and executed by the terminal equipment is the “master”, while the main software hosted and executed by the radiocommunication module, is the “slave”.
The purpose of the invention is particularly to overcome these disadvantages with the state of the art.
More specifically, one purpose of this invention is to provide a technique for driving a radiocommunication type module using a client driver software, that is simple and inexpensive (in terms of hardware and energy consumption).
Another purpose of the invention is to provide such a driver technique enabling the radiocommunication module to supervise (and act upon) the driving procedure, when driving is carried out by a terminal equipment. In other words, it is desired that the radiocommunication module does not only act as a slave.
These various objectives and others which will appear later are achieved using a radiocommunication module, of the type hosting and executing a main software performing radiocommunication functions, the said main software comprising means of executing driver commands, sent to the main software by at least a client driver software, and belonging to a predetermined set of driver commands. According to the invention, the radiocommunication module also hosts and executes at least one client software, called the client embedded software. Furthermore, the client embedded software and the main software comprise means of enabling the client embedded software to perform at least one of the following two roles:
Thus, if the client embedded software acts as a client driver software, the radiocommunication module will operate independently and inexpensively. In this case, the radiocommunication module does not need to cooperate with any terminal equipment, and the main software and the client driver software use the same resources (same processor and same memory).
This invention also provides a means of not limiting the radiocommunication module to acting as a slave towards the terminal equipment that executes the client driver software, in the case in which the client embedded software acts as client supervision software. The client supervision software executed by the radiocommunication module manages driver actions requested by the client driver software executed by the terminal equipment. Note that in this case, the client embedded software is additional to the state of the art configuration mentioned above. However, this additional software is inexpensive since it uses the same resources (processor and memory) as a main software also hosted on the radiocommunication module.
Advantageously, the following features are provided to enable the client embedded software to act as client supervision software:
In this way, the client embedded software can:
Advantageously, to enable the client embedded software to act as client supervision software:
In this way, the client embedded software can:
Preferably, the said main software comprises one main application particularly based on a set of execution functions, each enabling the execution of at least one of the said driver commands. The client embedded software includes a client application, particularly based on a set of source functions, each enabling sending or receiving driver commands or responses to driver commands, to or from the main application. The main software and/or the said client embedded software comprise an application interface used to interface the said source functions with the said execution functions.
The result is to limit development costs, due to the fact that the interface application (also called the application interface library in the following) can be used with different client applications, or even with different main software, once it has been developed.
In one preferred embodiment of the invention, the said set of driver commands is a set of standard AT commands.
This enables fast development of the client embedded software, since AT commands are well known and are already used for the development of client external software (hosted on the terminal equipment). This also facilitates development of a client software strongly based on an existing client external software.
The invention also relates to a process for implementation of a client software for the control of a radio communication module, the said radiocommunication module being of the type that hosts and executes a main software particularly performing radiocommunication functions, the said main software comprising means of executing driver commands sent to the main software by the said client driver software and belonging to a predetermined set of driver commands. According to the invention, the said radiocommunication module hosts and also executes at least one client software, called the client embedded software. The client embedded software and the main software dialogue with each other such that the client embedded software performs at least one of the following two roles:
Other characteristics and advantages of the invention will become clear after reading the following description of a preferred embodiment of the invention given as a non-limitative example, and the attached drawings, in which:
Therefore, the invention relates to a radiocommunication module hosting and executing a main software and at least one client embedded software, using the same set of resources (processor and memory).
Conventionally, in particular the main software (for example a “GSM software”) performs radiocommunication functions and comprises means of executing driver commands (sent to it by a client driver software).
The client embedded software (concept specific to this invention), can act as:
In the remainder of this description, it is assumed that the driver commands are AT commands. However, it is clear that this invention is not restricted to this type of driver command.
In the particular embodiment shown in
Furthermore, the client embedded software 6 comprises:
The client embedded software 6 and the client main software 3 communicate with each other by using API layers, references 61 and 31 respectively. Note that the term API (Application Programming Interface) denotes an interface. It is a description of communication rules corresponding to a particular functional assembly.
In the client embedded software 6, the API layer (embedded) 61 comprises:
In the main application 3a in the main software 3, the API layer (exported) comprises:
The main application 3a forms the kernel of the main software 3, and the client application 6a, and the interface application 6b form the kernel 60 of the client embedded software 6.
The interface application 6b is a software entity that enables a dialogue between two independent software entities (or binary entities namely the client application 6a and the main application 3a. For example, they are in the form of a library (already compiled).
The client embedded software and the main software each use a distinct part of the same RAM. The client defines the size of the memory stack necessary for correct execution of the client embedded software. An attempt by one of the two software programs to access part of the RAM reserved for the other software will stop operation.
We will now describe a first embodiment of the invention in which the client embedded software acts as a client driver software, with reference to
Elements conventionally included in a radiocommunication module and described above with reference to
Furthermore, according to the first embodiment of the invention and as presented above with reference to
Operation of this first embodiment of the invention may be summarized as follows:
We will now present a second embodiment of the invention with relation to
In this second embodiment, the radiocommunication module is not independent (unlike in the first embodiment), but is controlled by a terminal equipment with which it cooperates. Therefore the configuration is the same as in prior art described above with relation to
According to the second embodiment of the invention, the radiocommunication module 1 also hosts and executes a client embedded software 6 acting as client supervision software and in particular comprising a client embedded application 6 and an interface application 6b. The client embedded software supervises execution (or lack of execution) of AT commands using execution means 4 included in the main software 6, transparently to the client external application 2.
The client embedded software 6 (supervision software) may decide to use the following in particular, within the radiocommunication module:
It will be noted that the first variant of each of the two mechanisms mentioned above (for AT commands and for AT responses respectively) means that the client embedded software 6 may decide to be completely passive at some times. Therefore, they correspond to conventional operation of the radiocommunication module, as described above with relation to
We will now describe the second variant of the AT command preparsing and processing mechanism, which enables the client embedded software 6 to filter AT commands originating from the client external application 2, with reference to
Operation of this second variant of the AT command preparsing and processing mechanism can be summarized in two phases done in sequence, namely:
The preliminary phase to select the second AT command preparsing policy comprises the following steps:
For simplification reasons, it is assumed in the rest of this description (and as shown in
Also for simplification reasons, it is assumed in the rest of the description (and as shown in
The AT command processing phase includes the following steps:
For example, this processing consists of resending the AT command to execution means 4 (using the mechanism corresponding to the first embodiment of the invention, described above in relation to
We will now describe the third variant of the AT command preparsing and processing mechanism that enables the client embedded software 6 to spy on AT commands from the client external application 2, in relation with
Operation of this third variant of the AT command preparsing and processing mechanism can also be summarized as two successive phases, namely:
Operation of this third variant is only very slightly different from operation of the second variant, essentially in that:
We will now describe the second variant of the AT response preparsing and processing mechanism that the client embedded software 6 uses to filter AT responses sent to the client external application 2, with reference to
Operation of this second variant of the AT response preparsing and processing mechanism can be summarized in two phases done in sequence, namely:
The preliminary phase to select the second AT response preparsing policy comprises the following steps:
For simplification reasons only, in the remainder of the description (as shown in
Also for simplification reasons only, it is assumed in the remainder of the description (and as shown in
The AT response processing phase comprises the following steps:
We will now describe the third variant of the AT response preparsing and processing mechanism that the client embedded software 6 uses to spy on AT responses sent to the client external application 2, with reference to
Operation of this third variant of the AT response preparsing and processing mechanism can also be summarized as two successive phases, namely:
The main differences between the operation of this third variant and operation of the second variant are that:
Appendix 1 contains a detailed presentation of some of the source functions on which the client embedded application is based.
For example, Appendix 2 contains an example application of an embedded application written in the C language, the objective of which is to send an ATI3 command three seconds after each initialisation and to write objects in Flash memory.
Optionally, for the purposes of this invention, it is also possible to use at least one of the following additional AT commands in addition to standard AT commands:
A1) “wm_apmAppliParser”
Function for processing a message from the main software. The message forming parameter of the processing function in particular contains an AT command or a response to an AT command.
Exact name:
The message contains a response to an AT command previously sent to the main software by the client embedded software
(see details of the “wm_osStartTimer” function for a description of “Ident”).
Returned parameters
The return parameter indicates if the message is processed (TRUE) or not (FALSE).
A2) “wm_atSendCommand”
Function for sending at least one AT command to the main software, in which one parameter indicates the destination software (namely the client embedded software and/or the client external software) of the response resulting from execution of this AT command.
Exact name:
| Number | Date | Country | Kind |
|---|---|---|---|
| 01 03909 | Mar 2001 | FR | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/FR02/01024 | 3/22/2002 | WO | 00 | 3/26/2004 |
| Publishing Document | Publishing Date | Country | Kind |
|---|---|---|---|
| WO02/078375 | 10/3/2002 | WO | A |
| Number | Name | Date | Kind |
|---|---|---|---|
| 5613123 | Tsang et al. | Mar 1997 | A |
| 5815682 | Williams et al. | Sep 1998 | A |
| 5819115 | Hoese et al. | Oct 1998 | A |
| 5951684 | Jeon | Sep 1999 | A |
| 6330586 | Yates et al. | Dec 2001 | B1 |
| 6418310 | Dent | Jul 2002 | B1 |
| 6498788 | Emilsson et al. | Dec 2002 | B1 |
| 6502124 | Shimakawa et al. | Dec 2002 | B1 |
| 6594708 | Slaughter et al. | Jul 2003 | B1 |
| 6650892 | Thiriet | Nov 2003 | B1 |
| 6658500 | Pinault | Dec 2003 | B1 |
| 6671522 | Beaudou | Dec 2003 | B1 |
| 6832373 | O'Neill | Dec 2004 | B2 |
| 7197551 | Ketola et al. | Mar 2007 | B2 |
| 7237198 | Chaney | Jun 2007 | B1 |
| 20010029178 | Criss et al. | Oct 2001 | A1 |
| 20010056502 | Hollstrom et al. | Dec 2001 | A1 |
| 20020169591 | Ryzl | Nov 2002 | A1 |
| 20030172172 | de Bonet et al. | Sep 2003 | A1 |
| 20040152456 | Montes | Aug 2004 | A1 |
| 20040162103 | Montes | Aug 2004 | A1 |
| Number | Date | Country |
|---|---|---|
| 2 775 550 | Feb 1999 | FR |
| 2 775 550 | Sep 1999 | FR |
| WO 99 63767 | Dec 1999 | WO |
| WO 9963767 | Dec 1999 | WO |
| WO 00 33538 | Jun 2000 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20040152456 A1 | Aug 2004 | US |
