Aayush: weblog

Archive for the ‘IMS’ 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


gsma-volte

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.

Conclusion:

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.

Advertisements

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 »

IMS and LTE Policy Control for devices of different form-factors.

Posted by Aayush Bhatnagar on March 27, 2012


Background:

With the advent of LTE and IMS, Voice and Video over LTE (VoLTE) is fast becoming a reality. Customers are turning to video services rapidly and data consumption is increasing exponentially. 

Moreover, with multi-screen devices such as smart phones, tablets etc being churned out in millions – customers now own atleast 2 smart devices today. Customers also expect their applications to provide them with a uniform customer experience irrespective of the  device form factor. This holds true for all applications, and it will also be a natural expectation from IMS and VoLTE applications.

Policy Control to the Rescue:

In contrast to OTT (Over the Top) internet traffic and OTT video applications, IMS video applications have a slight edge of policy control and enforcement.

As the form factor of the device increases (from a smart phone to a tablet for example), its data consumption requirements also increase due to the bigger screen size. Moreover, if the customer chooses to play HD content, the throughput requirements would further increase accordingly.

Hence, in order to preserve the customer experience of video applications on multiple screens, it is also important that a sufficient data pipe is provided to the application in order for it to perform uniformly. In addition to the data pipe, video playback latency and jitter control also need to be controlled over the air.

This becomes increasingly important, if we wish to deliver Live TV services and VoD services over IMS.

To mitigate this situation for IMS video applications, we can effectively use the IMS and LTE policy control framework.

Solution Architecture:

The solution uses one of the most ‘ancient’ SIP headers defined by RFC 3261 in conjunction with the DIAMETER Rx interface.

The User-Agent header is defined in Section 20.41 of RFC 3261, and this header is used to provide ‘information’ on the user agent originating the SIP request. This header can be used by IMS User Equipment to provide details on the form factor of the device where the IMS client is executing. Moreover, it should also be possible to provide device pixel details (if available from the OS).

For example, on Android Operating System, the following Java code provides the screen display metrics which can be sent to the the IMS core by using the User-Agent SIP header:

DisplayMetrics dMetrics = new DisplayMetrics();
getWindowManager().getDefaultDisplay().getMetrics(dMetrics);
String str = “Display Metrics Are : ”
+ dMetrics.widthPixels
+ ” x ”
+ dMetrics.heightPixels;

System.out.println(str);

The P-CSCF in the IMS core network can extract the User-Agent header and use the device form factor details on the Rx interface. Based on the device form factor and resolution, the PCRF can enforce appropriate QCIs, UL Bandwidth and DL bandwidth for the specific device in question.

In addition, the P-CSCF also sends the codec information as received in the SDP (Session Description Protocol) to the PCRF. This information coupled with the device form factor and resolution can enable the PCRF to calculate a very accurate measure of the UL and DL bandwidth to enforce. Moreover, this information can also help the LTE network to provide bandwidth boost to premium customers or premium video content.

Discovering the Policy Enabled Architecture:

Policy control is a distinctive edge that the VoLTE architecture provides over traditional OTT video content. The ability of the LTE and the IMS network to accurately calibrate session QoS characteristics is a true differentiator as opposed to best effort video. By leveraging age old SIP headers in conjunction with the PCRF can lead to truely differentiated customer experience.

OTT video provides provide a lot of jitter control, echo cancellation and buffering techniques to enhance customer experience, especially compensating for poor RF conditions or congestion scenarios.

However, none of those techniques can match the realtime QoS enabled architecture of VoLTE, which can guarantee high throughput even in low converage areas of LTE.

This is because LTE radio coverage is not a decisive factor for calculating throughput for customers. Throughput depends on the number of empty resource blocks available in a given eNode-B cell. For a three sector LTE base station, there are 100 resource blocks per sector. This gives a total of 300 resource blocks per base station available for customers.

Throughput is a factor of the number of free resource blocks available for a given subscriber in the LTE cell at that time. Even if the coverage is poor (cell edge conditions), it is possible to provide high throughput to the customer through the policy control architecture.

Operators need to realize the power of the IMS and LTE architecture to truly exploit it and create differentiation in their services.

There are a lot of other hidden nuggets in the combined IMS and LTE network architecture, which I will leave for another discussion and for some other day. Hopefully, engineers from around the world will discover these hidden nuggets and construct innovative policy enabled services for consumers.

Posted in 4G, Carriers, data management, IMS, Java, LTE, OTT, Services | Tagged: , , , , , , | 1 Comment »

IP Multimedia Subsystem (IMS) Market Deployment Update

Posted by Aayush Bhatnagar on May 22, 2011


3GPP IMS has been buzzing in the past 18 months. I believe this is a good time to round up the IMS deployments around the world and try to summarize them in a short post.

The list below is not a complete list. Please feel free to add more names to the list by dropping a comment and I will update the post.

However, the list vindicates the fact that IMS is no longer a piped dream and has come of age. More and more carriers around the world have “silently” adopted IMS as the platform of choice for next generation communications and services.

IMS Deployments:

1. Vodafone in the Czech Republic have Ericsson’s IMS infrastructure and Atos Origin NGIN platform deployed for business customers.

2. T-Com Hungary has an IMS deployment.

3. China Mobile has deployed Huawei’s IMS infrastructure.

4. Verizon in the USA have a multi-vendor supplied IMS core.

5. AT&T had deployed IMS long back and also deployed services such as UVerse and Video Sharing.

6. Telekom Malaysia deployed Huawei’s IMS core network platform.

7. Alcatel-Lucent has deployed its end-to-end IP Multimedia Subsystem (IMS) solution with Vietnam Posts & Telecommunications Corporation Group (VNPT) and its subsidiary Vietnam Telecom National (VTN)

8. Atheeb was the first operator to start IMS network deployment and commercial operation . Ethiad Atheeb Telecom (Atheeb) is the second largest fixed-line operator in the Kingdom of Saudi Arabia. It acquired its license in 2007, and holds a 3.5GHz spectrum across 13 regional divisions within the Kingdom. Atheeb’s licence permits fixed and wireless services such as voice telephone communications, data services, internet services, and broadband internet services via WiMAX 802.16e technology. Atheeb works on ZTE IMS platform ,Motorola’s WiMAX system and WIPRO’s OSS/BSS

9. Orange Netherlands (Now France Telecom) has an IMS deployment which has matured over the years.

10.  Portugal Telecom deployed residential telephone services on IMS

11. MTN Rwanda has a MMTel solution enhanced with Presence services.

12. Optimus Portugal has their WebPhone service called TAG deployed on IMS

13.  In Brazil, Alcatel-Lucent started to deploy an IMS network at Oi (former Brasil Telecom) to replace 385 legacy switch and provide service to 500K subscribers.

14. YTL Communications (Kuala Lumpur, Malaysia) has deployed Samsung IMS on a mobile WiMAX access network.

15. Telecom Italia in Italy provides Contact Center services based on IMS infrastructure

16. Wateen Pakistan has a WiMAX access network providing voice services over an IMS core

17. Softbank Mobile Corporation in Japan has an IMS network for several years.

18. Telia Sonera has an IMS network from Nokia Siemens Networks in addition to their OneNDS product. They serve customers in six countries – Denmark, Estonia, Finland, Lithuania, Norway and Sweden.

In addition to these, US cable players have been exploring Packet Cable based access to the IMS core to provide entertainment services. Updates on them will be posted as more information emerges.

Please feel free to add more names to this list so that it can keep evolving.

Posted in IMS | 5 Comments »

Race Condition for “tel” URI Routing in IMS – Unknown numbers !

Posted by Aayush Bhatnagar on April 4, 2011


Recently, in a discussion I came across a race condition that occurs in IMS for routing tel URIs which no longer exist in the IMS domain (operator’s network).

The problem statement is as follows:


When the operator de-provisions a telephone number from the IMS core, and another IMS subscriber dials this invalid number, then the call traverses the Proxy CSCF and hits the S-CSCF. I am assuming that it is an intra IMS domain call – synonymous to a local call. Here the called party (B-party) is the invalid subscriber. The S-CSCF executes the originating iFC set for the calling party as per the standards. Then, the S-CSCF realizes that the called party address is a tel URI and an ENUM query needs to be performed. As the subscriber has been de-provisioned from the network completely, the ENUM query fails.

This triggers the S-CSCF to forward the call to BGCF believing that legacy interconnect procedures need to be performed and the called party is a legacy subscriber. The BGCF attempts breakout towards the MGCF, which converts it to an IAM and sends it to the PSTN.

The situation would become even more complex with number portability, where we can no longer filter numbers based on ranges alone at the BGCF.

The PSTN domain would send it back to the IMS core thinking that the call was destined towards IMS. As inter-working will take place again at the MGCF for the incoming call leg, this call would land as a brand new call to the I-CSCF (with a refreshed Max-Forwards header) and a new Call-id.

Now, the I-CSCF will perform the DIAMETER user location query to the HSS and this query would fail, as the tel uri never existed in the first place. Based on the procedures in TS 24.229, the I-CSCF will inspect the address (which is the tel URI) and then perform the ENUM query. This query would fail as expected and the call will be forwarded to the BGCF once more mistaking it to the legacy interconnect case.

The sequence of events above would lead to an infinite loop in the network for this call.

Solution:

The solution to this problem is to avoid the breakout to the PSTN through the BGCF in case the user has dialed an invalid number. In order for this to happen, the ENUM query must not fail. Hence, it is proposed that when the user is de-provisioned from the network, the ENUM mapping of his number is changed to a generic SIP URI such as the following –

sip:doesnotexist@domain

This will ensure that this generic SIP URI is returned when the ENUM query is fired. In this case, the S-CSCF will forward the call to the I-CSCF instead of the BGCF. The I-CSCF will then forward the call to the MRFC by executing PSI subdomain routing in the sense of TS 23.228.

This would ensure that the MRF will play an announcement that the “number does not exist”. This is what is needed in this scenario. But, even here, the I-CSCF needs to do some NETANN magic before forwarding the call to the MRF (refer here: http://tools.ietf.org/html/rfc4240). Hence, the I-CSCF implementation has to be careful to make this work well.

 

As and when I come across more race conditions in the IMS network, I will post them here (most probably with a possible solution to get around them).

 

Posted in HSS, I-CSCF, IMS, IMS data, IMS procedures, IMS Release 11 | Tagged: , , , , , , | Leave a Comment »