Introduction:
3GPP IMS Release-11 has an interesting work item under study. This work item is for Unstructured Supplementary Services Data (USSD) simulation in IMS.
USSD based configuration and control of services are being used widely in GSM networks today.
However for LTE based 4G networks which will run on IMS, USSD based service configuration was missing in the standards. This has been mainly due to the presence of XCAP (XML Configuration Access Protocol) which provides user controlled service configuration.
However, there will be millions of customers who would still be using USSD for controlling their legacy services even when they move to 4G IMS. Customers might want a single mechanism to control and configure their legacy services as well as their new 4G services. Moreover, users are more accustomed to using USSD, and it will be nice to have it in 4G.
Due to these reasons, this work item is being developed and is under standardization at 3GPP.
This work item is still under study, and various options are being evaluated.
From their initial feedback, it seems that there will be no special standardization for USSD in LTE networks. It will not be reintroduced in its current form. 3GPP has noted that the current implementation of USSD in legacy networks is quite an overhead, and they will not like to re-implement it in LTE based IMS networks.
However, USSD is going to re-manifest itself in a new avtaar – USSI (USSD Simulation Service in IMS)
Yes, the new avtaar of USSD will probably be called USSI (from the work item notes). But it is still early days yet.
Implementation Options:
Several options are being evaluated which include the following:
— Re-using XCAP for USSD based control (by introducing new application usages for the XDM)
— Using SIP (new headers maybe)
— Tunneling USSD data in the SIP message body.
The whole idea behind USSI is not to re-invent the wheel by standardizing USSD from the scratch, but to only simulate it in IMS so as to provide a uniform experience to the user. Hence, it is called USSD Simulation Service (USSI).
Even though there are no concrete standards available for USSI, I would like to discuss some of the possible implementation options for it in this post:
Before we discuss the options, let is review what USSD is and how it works:
USSD services are triggered by the user, when he/she dials a special feature code appended by a “#” key. For example, in one Indian telco operator, if you dial *123#, then you get the prepaid balance on your mobile phone.
The USSD messages are routed by the MSC (Mobile Switching Centre) to the HLR which proxies it over MAP to a Service Node (called the USSD server). The USSD server responds to the request.
USSD works in two modes:
1. MMI Mode (Man Machine Interface Mode) initiatied by the UE
2. Application Mode initiated by the Network.
The MMI mode is like a “pull” mode where the user pulls data from the network using USSD
The Application mode is like a “push” mode, where the network pushes information to the registered UE using USSD.
With this basic background, let us discuss some of the possible implementation options for USSI in IMS networks:
1. Use XCAP and talk to the XDM:
This option at first seems to be the most natural fit for implementing USSI. This is so because in IMS, all service configuration for MMTEL, PoC and Presence are already standardized using XCAP. Hence, USSI can also be accommodated using this option.
However, this option has some pitfalls:
a. It completely changes the scalability requirements of the XDM server. The XCAP (Ut) interface is a peer to peer interface, and it will pose to be a problem for roaming scenarios in IMS. When the UE roams to another IMS network, there will need to be session border control on the XCAP interface similar to SIP. This would require extra standardization for this interface, and things can get a bit messy.
b. Services keep on changing: New application usages will need to be implemented for supporting USSI on XCAP. This would require standardization efforts. Moreover, it will be tricky to relate existing MMTEL application usages with USSI.
c. Using XCAP for USSI will only solve half the problem. Only MMI mode USSD can be implemented. Application mode (push mode) will still remain non-standardized.
2. The SUBCRIBE NOTIFY Option:
This according to me is the best option available. The SUBSCRIBE/NOTIFY exchange provides us with both pull mode and push mode operations. The description below is my personal suggestion and is not yet standardized in any 3GPP document.
The UE can SUBCRIBE to the “ussd” event package and receive the USSD menu in the NOTIFY message. This USSI operation can be implemented as a “poll” operation as standardized in RFC 3265.
When several USSD operations need to be performed, a dialog can be created between the UE and the USSI Application Server. For each USSI operation, a SUBSCRIBE refresh will be sent. For each successful operation a 200 OK will be sent. If the USSI server has no state to convey to the UE for a particular USSI operation, RFC 3265 provides the option for keeping the NOTIFY body empty. Otherwise, if the network needs to convey information to the UE, the NOTIFY message can contain a body.
For Application mode of operation in USSI, the USSI application server can send in-dialog NOTIFY messages to the UE.
Hence, all use cases for USSD are satisfied using this option.
Future Work:
In case there is head-way in USSI standardization, I will post updates here. For now, 3GPP is concentrating to standardize USSI for MMTEL services only and they intend to support only MMI mode. This comes to me as a surprise, as the application mode can lead to a lot of service innovations and should have been included in the work plan.
Aayush: weblog 