Most cellular operators charge a fee per session (when a data packet it sent to the cell tower due to connection) which ranges from 10kb-200kb depending upon the operator. Its always charged once the data is activated on the device.
My application is luggage tracking, and here every 5 minutes the device will sleep and then wake up and send the GPS location to the server. The size of packet would be about 100 bytes.
My question is will I be charged any fee per connection/session or its included in the monthly charge?
So my data consumption should be:
5 minutes updates = 12 times updates in a hour.
30 Days * 24 Hours * 12 Updates per hour = 8640 updates
Size of updates = 8640 * 100 Bytes = 864000 = ~0.86 MB
Will I be charged fee based upon 0.86 MB or incur an extra surcharge per session fee?
Also can I opt for data pools instead of having a minium 1MB data on each and every SIM card?
Hi, we don’t charge any kind of fee per session but keep in mind that even if your payload is 100 bytes there’s going to be some overhead for TCP or UDP headers and that will be included in the usage charges. You can see on the dashboard exactly what the usage is.
Thanks for your prompt response!
As I’m a noobie entering this GPS tracking market, may I know how much data would TCP or UDP headers consume approximately for a 100 bytes data push?
Its hard to give you an exact figure here given that due to changes in signal strength and packet loss a device might have to send things multiple times. However I found this on stack overflow that will be a good baseline:
Size of Ethernet frame - 24 Bytes (you can ignore this)
Size of IPv4 Header (without any options) - 20 bytes
Size of TCP Header (without any options) - 20 Bytes
So total size of empty TCP datagram - 24 + 20 + 20 = 64 bytes (without the Ethernet frame its 40 bytes)
Size of UDP header - 8 bytes
So total size of empty UDP datagram - 24 + 20 + 8 = 52 bytes
My recommendation here would be to test this empirically with a device to give you a better idea of how your specific device fares.
Also, if you want to optimize for data sent you might want to consider using Hologram’s communication protocol and then routing the information from your Hologram Dashboard to your server.
Here is a blog post about the data savings by using this approach.
In my realworld experience (and hologram’s) each message sent to the hologram cloud socket uses a minimum of ~500 bytes. Check out the discussion: Data Usage and more
DNS lookup (going from url to ip address) possibly also requring a TCP connection
TCP handshake (there are multiple packets that have to go back and forth between server and client to establish a tcp connection)
TCP ACK packet (probably only one in your case as payload is so small)
Any re-transmission due to dropped packet(s)
So in reality I would expect your monthly cost to be
(500 bytes overhead + 100 bytes payload) * 8640 updates / month = ~5.2 MB
The only way to reduce this would be to:
“phone home” less often, like every 30 minutes to get closer to your initial 0.86MB estimte
use UDP to your own server and accept the reduced QOS UDP gives over TCP
use a persistent TCP connection such as MQTT. This means you only pay the 500byte pentalty once. You will have to look into a 3rd party (or your own) MQTT service as I dont think Hologram supports this at the moment.
Note once you have higher volume, look in to Hologram’s data pooling to significantly reduce the cost per MB. This is a good option if you usage is somewhat predictable. May not be for luggage tracking if its for travelers as I wont turn on my luggage tracker unless I am traveling.
EDIT: I should note @Maiky linked to the same Hologram blog that is in the other forum that has the table showing overhead. You’ll notice the Billed Byte Size is 496 bytes greater than the Payload Bytes size for the Cloud/Socket connection method (which is what you should be using).
