A few weeks ago we tried to launch a pilot for a mobile handheld solution in Turkey through Turkish carrier Turkcell and came to an halt due to unexpected results in the carrier network.
The pilot was for an international customer that has a custom built .netcf business solution, communicating with their back-end systems with SSL through GPRS/Edge/3G networks running on Motorola/Symbol rugged Windows Mobile terminals. All terminals are configured with local carrier SIM cards for Edge/GPRS/3G communication.
After successful launch in Norway, Sweden, Denmark and Germany, Turkey was next. and the whole system was configured according to deployment plans but when we started to test we could not get through to the back-end systems. All devices was online, but we didn’t get any communications with our back-end. We use a custom built communications layer supporting sync, async and push channels so we started debugging but could not figure out what was wrong until we retried using a Swedish Telia sim card in Turkey and it worked. After digging we got hold of Turcell that informed us we have to buy commercial private APN’s to get SSL for some reason. Our problem was dropped as not related to software issues, but it got us thinking about what needs to be addressed in future projects when it comes to cellular networked applications.
Communication through GPRS/Edge/3G
How it works; When you establish an network socket session through GPRS with the built in cellularmodem, your carrier assign’s you an IP. You do your request and get your response. Almost immediately the carrier disconnects your socket to free up resources but you still maintain a “cached” session leaving you with a valid IP address for your cellular modem. If you continue to stay idle the carrier network releases your IP to free up addresses in their network pool, and you are left with an invalid IP address on the device.
If your applications only use client initiated communications you only need to worry about the time period it takes to try, fail because of invalid IP, and then retry to negotiate for a new IP. If you’ve implemented server push functionality; you have a problem. The messages won’t be able to reach it’s destination since the server also has an invalid destination IP for it’s messages, and the only way around is to tell your server the client IP every now and then…. It is “every now and then” because these settings are specific to each and every carrier. Each carrier has it’s own settings for how fast you get disconnected, and how fast it releases your device IP based on their network and IP capacity.
What to do?
- Make sure your application can handle the extra time it takes to try/fail/retry.
- Remember that the idle release time for an IP in a carrier network can range from 5- 15-20 minutes, depending on how busy the network is. This is something we have experienced problems with a few times with Telia in Sweden.
- Consider that the situation wil only get worse! carriers are not spending money on building out their old GPRS networks, they’re waiting for the next 4G/5G network.
- Make sure your server knows your device address.
- Carriers are not very happy with applications that just pings for network keep-alive, but
- Do not assume that your application will work world wide because it works in your local network.
- Consider custom client/server encryption of data over open channels if you need this kind of data and/or communication security.
I’mstill working on multinational mobile device projects and are always interested in hearing about “special cases” when it comes to workarounds or solutions for local carrier (mis)configuration.
As a last note, Turkcell has been very helpful so this is not a critic against them. I’m having a workshop, hopefully in near future with network engineers at Telenor to learn more about Edge/3G and future networks and I’ll post a short overview and tutorial when done.