Telemetry Design Patterns - Interoperability between device and server (SMS, GPRS etc.)

Question

I'm working now on project related to remote car management.

We have some device able to start / stop car engine, provide GPS coordinate, check door lock status and so on. This device has SIM card installed.

Second side is a server which should communicate with device and allow consumers to manage their cars via iPhones, Androids and WM7 phones.

The main question for me now is what technical requirements should be defined for communication between device and server.

Anybody knows is there any books or articles about standard design patterns for such kind of data transport?

Here below is an example of problem annoying me

We need to send some requests to device (e.g. "start the car" or "give me a mileage"). In order to provide it server should have an address where it should to send this request.

If I understand right there are following ways to do it:

• Organize VPN (expensive)
• Use SMS transport (expensive)
• Organize persistent session between device and server using TCP sockets (I have no idea whether it will work in Russian GSM network realities)

Maybe there is somebody here who has similar expertise and could give an advice where I should move?

Answer 1

Resources

• Design a service layer according to these principles

• You can keep alive your TCP connection to reduce connection costs. then the long polling cost is minimum.

• You can check ZeroMQ, it seems like an appropriate pub/sub server for your project

Costs

• a message asking for pending commands and an empty response from the server (which will be more than 99.9% of your conversations) could be reduced to a single byte per request and another per response. so making a polling every ten seconds, we have:

  (20byte TCP framing ) + 1 byte/message * ( 1 request + 1 response ) * 6messages/1min * 60min/hour * 720hour/month = 10.8Mb per month needed to use long polling

• Now, you add the cost of sending user commands from the server to the device (they are relative rare in comparison with the long polling messages):

  1 kbyte/message * ( 1 request + 1 response ) * 20messages/day * 30day/month = 1.2Mb per month needed to support user commands

• Finally, you have to decide what data you want to collect -GPS, doors sensors, etc- and how often -1min, 10min, hourly, etc- that will sum up to the long polling costs = let's say 12MB

Total costs: Around 24Mb per month