Over the past few decades, USSD technology has carved its own space in the telecom industry. It has enabled a gamut of services, such as mobile banking, customer services, etc. With higher internet speeds enabled by newer technology, such as 4G or 5G, other alternatives like application development which can work directly from smartphone to a domain on internet, are a possibility.
However, USSD service is still required in even in pure 4G and 5G networks, because:
- USSD is one of keyway to reach the subscriber
- When the subscriber’s data pack is exhausted, USSD is still required for banking , other services, etc.
In 4G and 5G networks, we don’t need a similar complex or bulkier solution for USSD. On IMS, like many other application services run, USSD can also be provided. With this approach all other underlying fundamentals of IMS can be leveraged, like using SIP as protocol for signalling, et all.
In fact, 3GPP Specs 24.390 Version 11 talks of providing USSD-like services on IMS, known as USSI (USSD Services on IMS).
Also, an upgraded version 15 of same specs highlights the same or a similar solution on 5G using IMS. Depending on network architecture, the interface geared towards HSS/UDM to fetch information shall be different on 4G and 5G networks. However, access towards UE shall remain the same.
At a very high level, this solution enables subscribers to access USSD services directly from the attached LTE/5G/IMS network and provides a similar user experience as in GSM. For the operator, it will not be a big investment, as all it needs a new application server to be added onto their network which can be either stand alone or with functionality upgraded in services that are already operational. This investment in USSD is future proof as well, as it holds true for 4G and 5G too.
As with any regular IMS flows, any request from the handset latched to 4G/5G (IMS enabled) will reach up till the S-CSCF node and S-CSCF. And, depending on registration information, shall forward the request to the application server, which is the USSI in this case. USSD can fetch the required information from HSS/UDM, using HTTP/Diameter protocols.
Typically, methods such as SIP INVITE, INFO and BYE are used to achieve this. In addition, SIP methods usually deploy Session Description Protocol (SDP) and XML content to define information pertaining to media, language, etc.
With regard to the call flow outlined above, the SIP INVITE method is used to create a USSD session. Typically, SIP INVITE messages contain SDP payload, which, in turn, usually house media information. In this case, since audio and video is not required, the port number zero will be populated. Also, the SIP message contains xml payload which actually houses a USSD string. Consider this as an example: <ussd-string>*121#</ussd-string> . Once AS understands the SIP Invite, it shall respond back with 200 OK.
Depending on the type of USSD string, if further input from the user is required, for a menu to be displayed, for example, such information will be sent as a part of the INFO message contained in the XML payload.
And, the user shall provide further input, via the SIP INFO method. Once all the required information from the user is received, a final BYE message is used to send the final USSD response.
Consider this example, <ussd-string> Dear user your credit card bill is $xyz </ussd-string>
By deploying the SIP BYE method, the USSD session is thus closed.
Based on the initial INVITE, if no more information is required from the user, INFO methods are not required and the final response can be sent as BYE.
Please note, though, the call flow described above holds good for network initiated USSD sessions as well and the SIP INVITE will be initiated by AS, instead of the handset.
