LinkedIn About USSD – Part 1
On Thursday last week I have posted the following question on LinkedIn:
What stops you from using USSD services?
I have gathered 10 answers by Monday. Of which two people (who were prompted to do so) said they are not familiar with USSD, although the question was posted in Telecommunications section of LinkedIn’s Q+A. It is 20% of answers.
By itself the fact that a fifth of professionals in Telco business are not familiar with USSD explains quite a bit. Jean Cerien, Murad Mamedov, and Menno Bot mention inadequate exposure as an important reason for the weak adoption of USSD services.
Neeraj Kumar (Technical Consultant, System Architect: 3G UMTS, WCDMA, IMS, Femto Cell) finds the following reasons:
- Yet another application with a sloppy interface. I would rather prefer a GPRS based mobile applet of my favourite internet Instant Messenger.
- cost of using is also relatively more compared to GPRS based applications.
- a killer service based on USSD is yet to be seen, or at least i’m not aware of it.
Let’s discuss these arguments. “Sloppy interface.” A USSD service (as shown in the example here) can be displayed aligned at the center (but usually it is aligned to the left) and long messages could wrap to the next line. There are no graphics, that’s true. But I would not call the interface sloppy. I would even say it is simpler and cleaner, alike Google text ads.
There are a whole bunch of problems related to user experience with GPRS. Shall I start listing them?
Here we go:
1) GPRS settings are hard to configure;
2) Switching to GPRS vs. WAP profiling (WAP gateway vs. HTTP) is not obvious but in Russia it is a matter of paying 40 times more for traffic (if using WAP gateway);
3) Does not work in all roaming situations;
4) Requires a data plan (US);
But what is more important: USSD is not a substitute to GPRS and beautiful interfaces — USSD is a complimentary technology (as it is also explained by the next post’s Figure about SMS+USSD) which can be used as a gateway to call a WAP site via GPRS.
As to advantages of USSD, it works on any GSM phone. No single adjustment is necessary.
Cost. It depends on who is paying for it. It can be set so that it costs nothing to the user, the application provider bears all the cost. This cannot be said about GPRS. A user always pays for data transmission.
“I’m not aware of killer service based on USSD”. True: there are few, depending on the network. In Russia we enjoy MTS balance inquiries (*100#), operator portals (*111#), and games (*224#).
In fact, the killer application is now being developed. If interested in beta testing, let me know. It will be a global, operator-independent initiative which uses USSD as initiating technology.
Atisha Banjare (Territory Manager – Postpaid) rightfully adds to the list of objections that USSD services unlike SMS cannot be shared — a feature which is so common with social networking. In defense of USSD, I can only add that it is easier to initiate USSD in comparison to SMS. Also USSD is usually used in conjecture with SMS, thus it is a good idea to combine USSD and SMS by simply adding a menu item “Share” or “Get an SMS link” which can be initiated from a USSD dialogue to either automatically send an SMS to the inputted mobile number, or to get an SMS onto one’s own mobile phone.
Tommy Bertling at Swisscom (Switzerland) Ltd:
“…not very user friendly and will not work properly in roaming as there is no agreement which codes must work in a network”
Tommy, along with Jean Cerien (CEO at COMM4U), Gerard Byrne (CEO, Experience IT), Menno Bot (Chief Technical Architect at Nokia Siemens Networks (Saudi-Arabia)), complains about codes which are too difficult to memorize and use.
Originally, Supplementary Services Data was designed for use where supplementary services such as call forwarding or multiparty calls were needed. For instance, a call-forwarding option for all incoming calls can be activated by: **21*«destination number»#
However, USSD commercial services are obviously not designed with such complicated combinations in mind. The 3 digits like *111# is your only passport to, say, our service which takes it from there in the form of an interactive dialogue. Seems to me like the easiest possible route to information.
Roaming and USSD. Actually, there is an agreement about USSD support in roaming:
Messages from handsets to the numbers 100-149 always route to the home network. This means that if you are roaming in another network, dialing a USSD number from 100 to 149 on your phone will always route to the application on your home network. If you are used to accessing a particular service in your home network, then you will also be able to access it from another country. USSD codes other than within 100 and 150 are routed at discretion of a guest network.
(to be continued…)
i think most challenge for USSD is less of security feature support if compare to GPRS or 3G
I could not fully agree with you.
In fact GPRS/3G by itself does not provide any security at all. The application should use some kind of encryption over TCP transport (like HTTP SSL, for example). If a service provider wants to implement authentication, he should use either an application level authentication (i.e. a wap form asking to enter username+password) or some combination with SMS (for example, eyeline’s patented call2service technology when a user dials a phone number that prompts the service to send the user a wap link with a session ID, thus providing a so called “call back authentication”), when security features of the GSM/SS7 network are used for application authentication.
Of course, SS7 transport does not allow encryption for USSD but taking into account that SS7 network is closed it becomes much more expensive to eavesdrop the traffic. Moreover all air traffic in GSM/3G networks is automatically encrypted. This means that bad guys have to have special equipment to sniff the air traffic. As for authentication, USSD behaves the same way as SMS. When an application wants to open a USSD session it goes through a regular GSM/3G signaling in order to find the HLR of the user and the VLR where he/she is currently located, then it pages the user through MSC and BSC, and opens a session on the phone in which a corresponding SIM card is installed. This authentication procedure is similar to sending an SMS to the user. And it is really very difficult and expensive to intercept USSD as well as SMS.
In fact, our 5 years of experience with commercial USSD services taught me the following advantages and disadvantages of USSD Stage 2 vs WAP:
+very fast (SS7 real-time protocol comparing to TCP over the Internet where you can wait forever)
+provides automatic authentication based on core security protocols of GSM
+works on 99% of phones
+integrates very easily with SMS and WAP (you can provide catalog navigation menu over USSD, and at the end send an SMS with a WAP link or some other info to the user)
+ease of advertising (you just can put access number into the ad)
- limited page size (160 bytes vs several Kbytes for WAP page)
- no pictures and no beauty (but some people say that this is a “+ ” rather than a “-” — users’ attention is focused on the core functionality of the application;)
- some first time users may experience difficulties to navigate the service
Our biggest client — MTS (www.mts.ru) — selected USSD as a primary access method for the customer self care service (not WAP/GPRS/3G or even voice), because it works on all phones, fast, does not scatters the attention of the user with fancy UI design elements, and is very easy to advertise and educate the users as compared to WAP or Internet apps (they just say in their printed materials something like “Please dial *111*2*3# to add MMS+ feature to your plan”).
Cannot deny that USSD is fast, compatible on most of the phone in market,however for security,some vendor could monitor the ss7 link for their own service. however because less of encryption in ussd data, information can be view by other people. especially service related to money.
I agree with you. That’s why any m-payment apps exploiting SS7 based technology (like mobile paypal for example — https://www.paypal-marketing.co.uk/mobile/MobileT2B-outside.htm) must have a specially designed architecture which ensures security. PayPal for example uses confirmation SMS sent back to the user with the WAP link where the user is requested to enter password — https://www.paypal-marketing.co.uk/mobile/MobileFAQ-outside.htm#buy3.
Killer app?
I suggest all of you turn your attention Africa and other cash based countries.
M-Pesa and Safaricom are delivering a banking solution to about 40% of the market in Kenya and it’s growing. The system uses a simple USSD menu driven system and I can probably go out on the limb and say the majority of the 40% class have never seen a school after elementary training.
After using my PDA and then using those simple Nokia phones you see everywhere in Africa, (70% market penetration); you wonder why you ever use your PDA in the first place. The phones get the job done.
There was also a deployment in Afghanastan. The USSD application used was too complicated. (We’re talking a 4th grade education). The switch to IVR started the ball rolling.
Don’t stop there. Look at most of the African countries. They’re all rolling out and most, not all; are based on USSD.
“SS7 network is closed it becomes much more expensive to eavesdrop the traffic”….Exactly!
You need to trust a handful of employees who work for the telco and have access to the internal network.