Terminals based on the TC65, TC65i or EGS5 Engine from Cinterion are java enabled. This means its possible to run an Java application on these controllers. The engines offer a J2M/CLDC based runtime enviroment with an IMP-NG profile. A piece of Java software running on such an Engine is called a Midlet, thus we call our software KMMidlet. The software is based on the M2MGate framework and is called DeviceServer in some contexts.
The M2MGate DeviceServer was developed to overcome some limitations of GSM based IP services, and is the base of the KMMidlet. The main communication principle is, that the Modem has to initiate all network communication and thus acts as client, while the Server (Cascade) has to be reachable in this network (e.g. public IP address for the internet). On the other hands many of the functionalities running on the Modem are services, so we called it DeviceServer, knowing this may be misleading.
The DeviceServer opens a TCP/IP connection to a public reachable Server (Cascade). The connection may be encrypted (SSL). This connection is the communication line for all communication, and one main tasks of the DeviceServer is to maintain this open connection. The Cascade-Server offers some services for the DeviceServer and acts as Proxy for the Services of the DeviceServer. This means a Client wanting to access a Service on a Modem ha to connect to the Cascade-Server which delegates the requests to the Service instance on the DeviceServer and the answers back to the Client. The Cascade-Server hast to maintain all open connections to the connected Modems, a 'from the shelf' Linux Server can handle more than 100000 open Sockets with a Java Service.
There are some general Services available for all DeviceServer:
The Konica-Minolta MFPs are equipped with a RS-232 interface to connect a Modem. For CSRC exist communication modules (KMCore) to connect MFPs via Modem. CSD or analog modem applications dont scale very well, that and the availability of CSD were a reason to try an IP based solution. The KMMidlet runs on GPRS Modems, GPRS is a packet based IP Service on GSM. It was aimed as a drop-in for the already existing solution.
Nowaday KMCore exports its data requests as XML files to a programm called GPRSCore, which delegates this data requests via the Cascade-Server-Cluster to the correct Modems. There the KMMidlet software uses the Transfer Data Format Specification to communicate with the MFP. The whole data request is processed and sent as one block back to the Cascade-Server-Cluster and the requesting GPRSCore. The transfer in one block reduces bandwith usage a lot, because it avoids sending small packets which consists mostly of the TCP/IP Header.
The KMMidlet stores the requests and performs reguarily these requests, to cache them. If a request comes in and the MFP cant answer, the values from the cache are used.
The Version 300 of the KMMidlet is a real major release. Its a complete rebuild and many internal structures have changed dramatically. Most changes aim at an improved robustness.
Cinterion has changed the namespace of its java runtime enviroments of the different Engines (TC65, TC65i, EGS5), so a runtime executable compiled against an TC65 runtime enviroment is not able to run on an EGS5 and vice versa. The M2MGate Device Server uses an encapsulation layer to hide this namespaces from the application code, so its possible to generate a runtime, which can run on a TC65 and an EGS5.
The former software has choosen one APN depending on the issuer of the SIM card or a fixed setting in the filesystem. The Versions 300 and higher will generate an internal List depending on the issuer of the SIM card and additional individual entries in the filesystem. This List will be tested and the first successful working APN will be used. Of course there is a priority: indivial entries, private APN settings, public APN settings and last but not least some default settings.
The straight forward way to implement the Transfer data format specifications from KM is to use a state engine. Sadly many of the newer MFPs have minor bugs in that implementation. So the data requesting scheme was changed to a non-blocking synchronous request scheme. With this aproach its easy to diagnostic problems for any request token. Timeouts are deadly in the old aproach, but can be dealt easily with in the new one. This leads to a more robust data readout scheme and to more detailed informations on problems. On demand a data request is done and delivered, if its impossible to fetch data from the MFP, cached data is used if its not older than 24h. The readouts to the cache are done every 8 hours (every 3 minutes in the old version).
The usage of byte arrays instead of Strings has halfed thed memory requirements for internal cache structures. Furthermore the use of a simple Compression algorithm has eased the memory problems. The Engine has not enough resources to use a zlib aproach, but a simple Range Coding algorithm works fine (see http://winterwell.com/software/compressor.php).
Using the above mentioned compression alogrithms the length of data requests can be reduced by a factor 2 to 4 (especially for long data requests). Furthermore the keep alive mechanism for the TCP connection to the server was improved (to 2/3 at a keep alive of 25 minutes (default for most carriers)).