How to communicate App with Server without internet connection?

Question

I want to know if there is any way to communicate users without internet connection to a server.

I thought it might be possible through SMS and machine-readable encoding. However this question confirms that iOS apps allows sending but not reading SMS: iphone app reading sms

I've also read a lot about using USSD but it seems that mobile opened messages aren't possible in iOS (dial USSD code from iphone programatically) and while in Android is possible to call a code programatically there is no USSD API to, nor it's possible to send USSD messages silently.

Is there any way to transfer data between my app and my server with only basic voice-sms signal?

Oxysalt

Answer 1

You are correct that SMS could be used to communicate with the server, if the server has access to a GSM modem. For large volumes of SMSes, you'd expect to have an internet connection between your server and an SMS gateway that connects directly to the messaging centre in the mobile network, instead of a modem.
This is the model of the SMS voting servers.

You can send/receive SMS as long as you have a GSM network, and you're right; no IP connection is needed. The Android platform lets you send and receive SMSes - see here.

Disadvantages are that SMS can be expensive, and has no guaranteed delivery, and no guaranteed delivery time. It's not suitable for real time communication.

USSD is another form of communication between a mobile device and the network that's built directly into the GSM network, but USSD messages are owned or licenced by the network operators, and aren't free for customers to use, as SMS is.

EDIT: USSD isn't a native protocol in CDMA, but various implementations are available from different operators. For example, here's a patent application describing an idea for one such system, which does not appear to require an IP connection. Googling "USSD CDMA" also gives various news items about commercial implementations, technical details unknown. I think you just have to find out what your target operator(s) offer.

I haven't worked directly with WAP, but a glance at the WAP Protocol Stack shows that it can indeed run over CDMA, or GSM without an IP connection. There is also a very useful Wikipedia article. My experience testing MMS is that it usually doesn't work without an IP connection, even though it is supposed to (according to that Wiki article, with WAP/SMS). So I would question how far European operators or mobile devices are supporting or testing WAP. Whether WAP is a practical choice could come down to pricing/availability at the end of the day, rather than technical issues.

Bonin

Hi, thank you for your answer. I'm really interested in USSD. For what I understand if I wanted to use it in my app I would need to make an agreement with each individual network operator, right? Which means that theoretically I would have to charge users and pay a slice to operators or they could charge them directly in their bills. I'm going to wait until tonight to award a bounty because the question is really important for me. – Oxysalt

What do you mean when you say USSD isn't free while SMS is? You mean free as in freedom right? – Oxysalt

Free in both senses. You're probably looking at something like this: tms.flashmedia.co.za/tms3-web/ussd.jsf (I don't have anything to do with this company, it's just an example, by the way). – Bonin

I've been reading a lot about USSD and it seems there is not an API for Android so you can only call a code from your App and in iOS it's not even possible to do that. Is this right? It's a pity because this seemed so promising – Oxysalt

USSD is possible over AT commands. AT commands are possible via Android, but I don't know if that fits your requirements. Search [android][at-command] on SO. – Bonin

Answer 2

Well, there are yet other options, depending on the amount of data you need to transfer back and forth to the server.

Instead of sms, for short amount of data you could try to implement an Asterisk PBX, whith your mobile calling your server and then sending other DTMF digits as your data, which would be interpreted by your Asterisk PBX (like an interactive phone audio menu from your cable company). Asterisk is GPL open-source.

Another option (an expensive one and with heavy work to do), would be to generate an audio signal encoded with your data content, and dial a phone number linked with an attached fax/modem pci board on a server, sending that audio like a call. It would'nt need to be a long call, as you could fit lots of data in a short bursts of audio stream.

Your server could check that data by acessing the content on the receiving end. Simply recording the call from the attached fax/modem pci board, or you could use an Asterisk PBX server on a local computer to save the audio file and then process by your server software.

Anyway, you would need to create a new protocol and data encoding type, like you mentioned "machine-readable encoding".

So, for the data types you could just save a lot of short audio files on your mobile and play them as your datatypes, but it would be easier to just go for the DTMF already mentioned above. Or you could encode like this: get the sound spectrum allowed to use through the voice call (Wideband/Narrowband), and divide it by the amount of single characters or chunks needed (take a look at how to encode in base64, to have some ideas). Then create a function to just encode your data as a short audio stream (read about PCM encoding and also read more about Fast Fourier transforms, if you want to complicate (but speed up) even further.

Create a simple protocol like this: first audio packet is a sequence of tones that makes a request, authenticates, and waits for acknowledgement response from the server (which could be just by not dropping the call 1 second after that). The 2nd audio packet is the size of the first frame of data, then the 3d audio packet onwards is the data itself with the size shown before. And so on. Have a look at the ftp protocol description for simplicity. Then you need to refine it so that the time of every packet above is the least possible while mantaining confiability.

For costs saving on voice calling, you could also explore phone number options, like Google Voice, Skype or any Voip service.

Bering