Aayush: weblog

Archive for the ‘MMTEL’ Category

Recommended Inclusions in VoLTE IR.92/94 and the IMS standards to achieve GSM-like ubiquity

Posted by Aayush Bhatnagar on December 13, 2014


The industry has seen and tracked how the VoLTE standards have been evolving over time.

GSMA IR.92 – IMS Profile for Voice and SMS, has undergone several revisions. On the same lines IR.94 has been published for video calling.

However, if we compare mobile telephony available today – with the IMS and VoLTE standards – some key gaps remain in the IR.92 guidelines, which in my opinion should be included in the GSMA standards to maintain backwards compatibility for VoLTE deployments.

All open market VoLTE device networks, and IMS vendors follow IR.92 and IR.94 as the golden standard for their implementation, and hence this alignment is important.

Some of the key features, which are “candidates” for inclusion are mentioned below. Some of these have 3GPP references, while others exist in some form or the other in exiting 2G/3G networks which are live today.

In the absence of “golden” guidelines for these issues, getting a GSM-equivalent ubiquitous and mature standards based implementation for VoLTE becomes a challenge –

1. Support for USSD over IMS should be endorsed by IR.92

The USSD standards for IMS have finally been frozen and are available in 3GPP TS 24.390 since Release-11, which happened in Q3 2012.

In some countries, USSD is a central medium to enable Value added Services – which actually contribute to whatever is left in Voice and SMS revenues for the operator.

USSD is also a good medium to integrate customer self care applications directly with back-end content based application servers – for example, we may want the customer to preview and choose a ring back tone through an android application.

On Android OS, it is trivial to dial out a USSD request from an application by using the following lines of code:

String hashString = Uri.encode(“#”);
String shortCode = “*” + hashString + “131” +hashString;
startActivityForResult(new Intent(“android.intent.action.CALL”, Uri.parse(“tel:” + ussd)), 1);

Similarly, incoming USSD responses can be intercepted easily.

However, in order to enable this functionality on a large scale on VoLTE handsets – IR.92 has to endorse the 3GPP specification and provide clear guidelines for implementation at the device side as well as at the network side.

2. Over the Air Function (OTAF) – messages tunneled via SMS and USSD.

OTAF is required for remote provisioning of SIM card information. The secure packet structure of communicating these configurations is defined by 3GPP in TS 31.115.

IR.92 should endorse this specification and include the related call flows in the VoLTE implementation guidelines specification.

The OTAF function has an important role to play in the OSS activation processes, when the customer inserts the SIM card in the handset.

Most OTAF servers connect to the IMS network (IPSMGW) as an ESME function over SMPP. Alternatively, they connect to a USSD gateway if the USSD termination option has to be exercised.

3. Complete SMS over IMS call flows (Ref: 3GPP, IR.92 and GSMA Implementation Guidelines)

The GSMA implementation guidelines as well as the 3GPP specifications do not provide end to end and complete call flows for SMS over IMS, covering all the scenarios.

Only  part call flows are explained where there is no clarity on whether the call flow is depicting IMS to IMS SMS termination or whether one of the SMS legs is from the legacy network (circuit switched).

Moreover, important call flows pertaining to international breakout of SMS messages, SMS initiation/termination when the customer is roaming in UTRAN and GERAN networks are missing.

Clarity on the interconnection of the IPSMGW with ESMEs over SMPP are not mentioned in TS 24.341, and are side-stepped in both IR.92 and the GSMA VoLTE implementation guidelines. As a result, all ESME related services which ride on SMPP are missing in the context of VoLTE.

These details should be clarified and detailed out in subsequent releases of the standards hopefully with clear call flows.

In the interim, vendors are forced to fall back to extrapolating existing 2G architectural details for SMS provided by earlier releases in 3GPP.

4. Support for STAR Code based dialing and detailed guidelines

Star code dialing has been available since GSM. Star codes can be used for activation and de-activation of supplementary services.

The MMTEL standards described in TS 24.173 and its downstream standards for IMS and VoLTE do not standardize or provide any guidelines on the usage of star codes.

This is very important from the perspective of  VoLTE devices vendors as well.

The device vendor has to decide which call flow to invoke based on the user input from the screen (whether to send an INVITE with the star code, or whether to send a standard XCAP request to an Aggregation Proxy server via HTTP)

Star code dialing can also be used for vertical services such as televoting and for other purposes.

This gap needs to be addressed in 3GPP and then ideally endorsed by IR.92. Alternatively, IR.92 can publish guidelines based on the SIP-AS models provided in TS 23.218 and allow device vendors to use star code dialing in VoLTE handsets as a configurable option controlled by OMA-DM.

5. Introducing (IN-like) and Interconnecting with (Existing IN) Toll free services for VoLTE/IMS

The 3GPP IMS architecture defines the IM-SSF (IP Multimedia Service Switching Function), as an entity which interconnects existing 2G/3G IN services with the IMS core network. TS 23.218 defines the IM-SSF formally in the standards.

Some of these services include – Televoting, 1800 toll free calling services, calling card services (for subsidized international calling for example), premium rate services (ITU-T E.155) and others.

For operators with existing 2G and 3G circuit switched core networks, it is possible to use the IM-SSF for bringing these IN services to the IMS architecture and then finally deliver them to VoLTE customers.

However, if there is a greenfield deployment of VoLTE, or a complete migration to LTE is required with no dependency on the IN platform, then this functionality of the IN architecture has to be standardized as part of IMS, and endorsed by IR.92.

3GPP may either directly standardize these applications – like they did for CRS and CAT (Customized alerting tones – also known as CRBT in India) – or 3GPP may work with OMA to define these service enablers formally and then endorse these standards.

In the absence of either of these, IR.92 can directly endorse TS 23.218 IM-SSF architecture for incumbent deployments, and the existing ITU-T recommendations for the benefit of greenfield operators, so that vendors can align to a least common denominator.

At the moment, this service agility is missing from the standards and the SIP Application server models have been defined and the rest is left to vendor innovation (please read this as vendor lock-in).

6. SMS Gateway and peering functionality (think of ESMEs)

Standards define E(SMEs) and their interconnection with SMSCs as part of the SMPP v3.4 and v5 specifications for GSM and UMTS.

However, as we move forward to IMS and VoLTE, the IPSMGW standards do not define any such entity, nor endorse the existing standards of SMPP.

Due to this gap, most of the SMS VAS services, SMS hubbing and SMS gateway services remain un-addressed. Vendors and operators have no choice but to fallback to legacy architectural choices or to support SMPP in the IPSGMW network element.

In markets such as India, SMS VAS services are a major cash cow despite OTTs, and these SMS messages are charged at a premium rate.

The SMPP interface should be included and the ESME functionality should be formally defined in TS 24.341 so that vendor implementations and VoLTE deployments are aligned.

7. Inclusion of MSRP and HTTP(S) for multimedia messaging in VoLTE IR.92/IR.94

It is a well known fact that MSRP and HTTP(S) based file transfer is addressed by GSMA in the RCSe specifications. However, it is required that these are also inlcluded in the scope of VoLTE.

Current MMS messages (even though MMS is dead), rides upon HTTP for file transfer.

With the advent of high speed LTE networks and VoLTE, HTTP and MSRP based file transfer can fuel many applications such as multimedia advertising applications, native support for multimedia messaging in VoLTE handsets (outside RCSe) – to give an integrated multimedia chat and SMS experience on a high speed data network.

Moreover, MSRP can also help in purchasing content from operator-owned content stores or streaming unicast content on-demand.

It is quite surprising that the MMS architecture has been left behind in the IMS standards and IR.92, as it can deliver a lot of value in the current context through innovative content based services.

8. Golden IMS configurations for VoLTE devices

At many occasions, there are configurations required in the VoLTE device which are in addition to the bare minimum list of parameters defined by 3GPP in the IMS Management Object specification.

Some typical examples include the following:

a. RTP keepalive timer values

b. RTCP policies

c. Impact of radio conditions on IMS registration

d. Guidelines for camping priorities between GERAN, UTRAN and E-UTRAN

e. Endorsement of SIP timers given in TS 24.229

f. UE registration re-try behavior endorsement as given in Section-5 of TS 24.229

g. UE star code dialing behavior and resolving conflict of triggering XCAP requests vis-a-vis SIP INVITE requests for dialed star codes by the user

The absence of these details cause implementation and interoperability complexities.

Hence, it is desirable if IR.92 provides an annexure detailing out UE guidelines and golden configuration options which can be followed across VoLTE UE implementations.


In conclusion, there needs to be a mechanism to include practical implementation pain-points and ensure backwards compatibility in the current IR.92 standards.

All the points listed above are widely deployed in current GERAN and UTRAN implementations with the circuit switched core network.

In the long run as more and more VoLTE devices come in the open market, and IMS deployments expand – these inclusions will help move towards attaining a GSM-like ubiquity for VoLTE.

Please feel free to add to this list or suggest more details/feedback.

Posted in 3gpp, 3GPP TS 24.229, 4G, DIAMETER, DIAMETER charging, IMS, IMS data, IMS procedures, IMS Release 11, IMS UE, ipsmgw, IR.92, IR.94, LTE, MMTEL, MSRP, network elements, RCS, supplementary services, telecom, USSD, USSI, VoLTE | Tagged: , , , , , , , , , , , , , , , , , , , , | 3 Comments »

USSD 2.0 Redux – 3GPP IMS Release-11 calls it USSI.

Posted by Aayush Bhatnagar on November 6, 2010


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.


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.

Posted in IMS, IMS Release 11, MMTEL, telecom, USSD, USSI | Tagged: , , , , , | 3 Comments »

Introduction to Terminating Identity Presentation/Restriction (TIP/TIR) Service

Posted by Aayush Bhatnagar on October 11, 2009

Similar to OIP and OIR, the TIP and TIR services also have been very common place in legacy networks.

The TIP service enables the calling party to receive the identification information of the remote party from the network. This information is provided to the originating party once the IMS communication has been accepted between the endpoints. The information is delivered regardless of the capability of the handset to process such information at the originating end.

The TIR service provides the terminating party with an option to restrict the identity to be presented to the originating party of the IMS communication.  Logically speaking, it is the reverse of what TIP is.

The TIP and TIR services need some support at the handset’s end as well to function properly. Currently the 3GPP  release is at 8.3 regarding these services.

Posted in IMS, MMTEL, supplementary services, TIP, TIR | Leave a Comment »

Introduction to Originating Identity Presentation/Restriction (OIP/OIR) service

Posted by Aayush Bhatnagar on October 11, 2009

OIP and OIR have been around for a long time in the legacy world.  So, it is no surprise that they have been standardized as part of the IMS architecture.

Even though supplementary services are call control telephony services, and should logically be the part of the CSCF, but they have been pushed to the IMS application layer in the form of a MMtel server.

The OIP service enables the called party to receive a network generated and trusted identity of the calling user on the screen of the mobile device.  The originating user may also present a custom identity to be seen at the called party. The user generated identity is usually screened by the network of the originating user.

The OIR service is invoked when the calling user does not want their identity to be shown to the called party. In such cases, the network of the originating user signals to the network of the called user, to withhold the identity of the calling user.

Both these services are pretty basic in nature, and are being used almost with every mobile phone call we make !

Posted in IMS, MMTEL, OIP, OIR, Services, supplementary services | Leave a Comment »