Probability distribution for sms answer delays

Question

I'm writing an app using sms as communication. I have chosen to subscribe to an sms-gateway, which provides me with an API for doing so.

The API has functions for sending as well as pulling new messages. It does however not have any kind of push functionality.

In order to do my queries most efficient, I'm seeking data on how long time people wait before they answer a text message - as a probability function.

Extra info:

• The application is interactive (as can be), so I suppose the times will be pretty similar to real life human-human communication.
• I don't believe differences in personal style will play a big impact on the right times and frequencies to query, so average data should be fine.

Update

I'm impressed and honered by the many great answers recieved. I have concluded that my best shot will be a few adaptable heuristics, including exponential (or maybe polynomial) backoff.

All along I will be gathering statistics for later analysis. Maybe something will show up. I think I will cheat start on the algorithm for generating poll-frquenzies from a probability distribution. That'll be fun.

Thanks again many times.

Answer 1

well I would suggest finding some statistics on daily SMS/Text Messaging usage by geographical location and age groups and come up with an daily average, it wont be an exact measurement for all though.

Answer 2

Good question.

Consider that people might have multiple tasks and that answering a text message might be one of those tasks. If each of those tasks takes an amount of time that is exponentially distributed, the time to get around to answering the text message is the sum of those task completion times. The sum of n iid random variables has a Gamma distribution.

The number of tasks ahead of the text return also has a dicrete distribution - let's say it's Poisson. I don't have the time to derive the resulting distribution, but simulating it using @Risk, I get either a Weibull or Gamma distribution.

Answer 3

In the absence of any real data, the best solution may be to write the code so that the application adjusts the wait time based on current history of response times.

Basic Idea as follows:

Step 1: Set initial frequency of pulling once every x seconds.

Step 2: Pull messages at the above frequency for y duration.

Step 3: If you discover that messages are always waiting for you to pull decrease x otherwise increase x.

Several design considerations:

1. Adjust forever or stop after sometime

   You can repeat steps 2 and 3 forever in which case the application dynamically adjusts itself according to sms patterns. Alternatively, you can stop after some time to reduce application overhead.

2. Adjustment criteria: Per customer or across all customers

   You can chose to do the adjustment in step 3 on a per customer basis or across all customers.

I believe GMAIL's smtp service works along the same lines.

Answer 4

SMS is a store-and-forward messaging service, so you have to add in the delay that can be added by the various SMSCs (Short Message Service Centers) along the way. If you are connecting to one of the big aggregation houses (Sybase, TNS, mBlox etc) commercial bulk SMS providers (Clickatel, etc) then you need to allow for the message to transverse their network as well as the carriers network. If you are using a smaller shop then most likely they are using a GSM Modem (or modems) and there is a throughput limit on the message the can receive and process (as well as push out)

All that said, if you are using a direct connection or one of the big guys MO (mobile originated) messages coming to you as a CP (content provider) should take less than 5 seconds. Add to that the time it takes the Mobile Subscribers to reply.

I would say that anecdotal evidence form services I've worked on before, where the Mobile Subscriber needs to provide a simple reply it's usually within 10 seconds or not at all.

If you are polling for specific replies I would poll at 5 and 10 seconds then apply an exponential back off.

All of this is from a North American point-of-view. Europe will be fairly close, but places like Africa, Asia will be a bit slower as the networks are a bit slower. (unless you are connected directly to the operator and even then some of them are slow).