Aayush: weblog

Test Driven Development (TDD) – A satirical discussion, with a silver lining !

Posted by Aayush Bhatnagar on January 29, 2017


TDD has been around for quite a while, and personally speaking – I have practiced it, and also heard several stories from different projects ranging from complex backend telco products, to front-end mobile applications and portals.
This post examines two divergent views on TDD.

Before reading the post further, important to keep this thought at the back of our minds –

“Thumb Rules, Textbooks and Rulebooks dont lead to mature software”

There are two sections for discussion –

A. The “TDD Devil’s Advocate”.

B. TDD – a boon for developers!

 

 

PART – A: The TDD Devil’s Advocate

 

Most bugs in complex industrial software are due to unclear or incomplete requirements. On many occasions, requirements also change rapidly with changing business needs – which demands more “agility” (pun intended !) in the way we approach our development projects.

Course correction may be required without “fragmenting” the software design and without degrading the performance of software.

Hence, when we employ TDD cycles and raise a “bug”, the fix to this bug may actually digress from the original business goal if the requirements are hazy. More often than not, bug fixes introduce unwanted functionality in addition to the patch, which may have performance or logical correctness implications.

Our destiny is always in the hands of the junior most coder of the team who is “fixing the issue”.

Therefore, there is always a need for continuous “technical housekeeping” in order to ensure that developers stay on the right path – and not go down the long road leading to oblivion , by repeating the TDD cycles of “Test-Fix-Repeat” !

This is one practical challenge in practicing TDD, especially in large multi faceted software projects involving many teams – and the egos of multiple team leads !

Most developers are averse to testing, and we need to teach our development resources to think in terms of TDD, and help them design their unit tests. This requires a lot of time, as not every developer has a mindset for writing “complete” unit tests which do not pass without proper assertions in the code.

As a result, good test cases “on paper” seldom translate into software unit tests of the same quality.

Unit test case code reviews hence become a “hidden task” which takes up a lot of time.

As requirements change (which happens often), so does the overall “test strategy” and the nature of TDD unit tests.

This needs constant change and course correction in the unit test suite, and a subset of the previous effort spent in TDD cycles is rendered redundant, as many of the bugs which were raised may no longer be valid.

Over a period of time and many TDD iterations later, projects find themselves in a situation where the amount of developer energy and effort spent in writing x-unit tests in their CI environment is more than the time spent on the actual software product. The effort needed would multiply as more features pour in – and the product evolves.

To add to this, Agile practitioners who execute TDD in an organisation may not be domain experts and may not understand the original system design requirements.

For example, if we have to build a complex telco product, the designers and developers are experts of the 3GPP standards text (requirements), related telco protocols as well as aware of how to scale the system to meet realtime latency sensitive needs demanded by carrier grade systems.

These aspects are critical to deliver a product that would be competitive. In such a scenario, TDD adds very little value, as most of the requirements are pre-known due to being part of the standards, and the nature of “bugs” and the “correct fixes” can only be understood by experts.

Another example may be of a complex IT system consisting of multiple COTS products requiring systems integration to meet our business goals. This would require COTS systems knowledge as well as business process design. TDD can add some value here in assuring the correctness of business processes to provide the intended results.

Having said that, in order to “fix the business process correctly” – the jeopardy management capabilities of the COTS systems need to be understood in depth. Otherwise a “wrong fix” may be more expensive than not fixing it at all !

Another major pitfall with TDD is the fragmentation of the software design and the mutilation of “good code”.

Many developers who work neck deep in the enthusiasm of “fixing-testing-fixing again” – may actually hurt the overall quality of the product.

Addition of “band aid” code, lots of boiler plate additions, “quick fixes here and there” as well as bad programming practices creep into the code over multiple TDD cycles.

Code reviews also become a mundane and “routine” task, as most developers adopt a mindset of “iterative development” and think that they can keep fixing bugs later once the test cycle is over.

The seriousness of “getting it right the first time” gets diluted as an outcome.

This harms the overall code quality in the long run, and may need a major “undo” effort once the software does not perform when scaled!

From a systems testing perspective, the formal boundaries between functional testing and regression testing “blur” to a large extent. Test architects need to decide the correct “release” to use for a full cycle functional test, and a regression test. As the code base keeps changing rapidly – systems testing becomes less effective and more time consuming (despite automation, as the tool automation scripts also need to evolve with rapid changes due to TDD).

Even as TDD may give a sense of security of “fixing” bugs early and delivering “code that works”, the final outcome may not be in line with the original design goals and the intricate details of software performance may get compromised – as TDD does not pay much heed to load testing and HA failover/failback testing (non functional hardening).

Much has been discussed about employing TDD for performance testing, however it is easier said than done.

Performance testing of software is an art and not just “automation”.

The test strategy and design of performance tests need to be as close to the production scenarios as possible.

There is little or no value in executing performance tests on “little pieces” of functionality – as in the real world – the whole product has to function at scale together and provide 100% of the functionality.

If you happen to run into bottlenecks, it becomes almost impossible to trace back which bunch of “little changes” of the TDD process caused the degradation. Detailed profiling methods need to be employed as a result.

Almost every code optimisation and performance fix in the code also has to go through an updated execution to the TDD unit test suite to keep them “current” – which can be a lengthy process.

As a conclusion- TDD should be practiced in moderation and in the right way – just like all good things ! Some of the key aspects we should keep in mind are as follows –

a. There is no substitute to good design. No matter which agile methodology we follow, software design has to be excellent and design should be all encompassing with carefully thought out use cases. Just like we cannot build a 120 floor building without a solid foundation – no matter what construction “processes”, “architects” and raw material we use !

b. Good design “on paper” has little value if it cannot be converted into practice. Hence, the rigour of software implementation and “getting it right” should never get diluted due to “processes”, “iterative development” and “agility”.

c. Test Driven Development should be used as a means to audit and assure these objectives, and should not be confused as a “sole means” of developing products. TDD should not be allowed to compromise on performance and human discipline and it should not introduce “band aid code”.

d. It is always desirable to fix exceptions, but exceptions should not become the “rule” !

Having said that, this brings us to Part-B.

 

 

PART – B : TDD – A Boon for Developers !

 

As Donald Trump would put it – “TDD is great, its fantastic…it really is !!”.

There are projects where TDD can be valuable.

Take an example of an android and IOS application.

User interface design and user experience design is a creative process.

In many projects, software developers do not fully understand and appreciate the essence of UI/UX design objectives.

There is a constant need to “bridge the gap” between the UI/UX objectives and the outcome in the form of a mobile application.

This equally holds true for client side responsive web development using HTML5, Angular JS and other technologies.

The iterations in correcting the code to meet design objectives can be taxing for developers and UX designers alike.

This is where Test Driven Development can be a great tool.

UI/UX designers can work closely with developers and use TDD to ensure that the interaction design, navigation, wireframe layouts, animation effects and responsive design are adhered with – during the course of app development.

Changes in UI/UX can also go through TDD cycles to ensure that the creative objectives are not diluted.

TDD can play a crucial role in this respect, and I have seen many projects employ it successfully for web development and app development through “Tangible Collaboration”.

I have come to understand that using the right “processes” for the right job is such an important aspect.

We should not come under pressure to adopt “cool stuff” without fully thinking through the “context” of our projects and the skill set of the organisation.

Hope to hear rich experiences of TDD and Agile from everyone.

Posted in agile, devops, software, software design, source code, test driven development | Leave a Comment »

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.

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 »

Net Neutrality Simplified – Information super-highway analogy.

Posted by Aayush Bhatnagar on December 6, 2011


A few months back, during an informal discussion with a colleague – the concept of net neutrality came along.

During this discussion, a very interesting analogy was made with respect to the information super-highway. I am extending that analogy into a story-board, and which I feel would serve as a helpful tool to understand net neutrality.

First we will review the official FCC broadband policy statement which defines Net Neutrality, and then we will look at the analogy.

Official Regulation in the US:

According to the FCC broadband policy statement, Net Neutrality regulations are defined for both wireless and fixed broadband providers.

Wireless providers need to follow the definition below, while for fixed broadband providers some additional rules apply.

Definition of Net Neutrality (for wireless providers):

“To encourage broadband deployment and preserve and promote the open and interconnected nature of the public Internet, consumers are entitled to:”

  • access the lawful Internet content of their choice.
  • run applications and use services of their choice, subject to the needs of law enforcement.
  • connect their choice of legal devices that do not harm the network.
  • competition among network providers, application and service providers, and content providers.
Additional rules which apply for fixed broadband providers are as follows:

Transparency: Fixed and mobile broadband providers must disclose the network management practices, performance characteristics, and terms and conditions of their broadband services

No blocking: Fixed broadband providers may not block lawful content, applications, services, or non-harmful devices; mobile broadband providers may not block lawful websites, or block applications that compete with their voice or video telephony services.

No unreasonable discrimination: Fixed broadband providers may not unreasonably discriminate in transmitting lawful network traffic.

In our analogy, we will combine the definitions above.

The Information super-highway analogy:

Consider a multi-lane highway which has several toll booths installed at the very start on a toll station. Let us call this the information super highway.

Vehicle owners need to pay a certain amount as toll tax whenever they traverse the toll booth. These vehicle owners can choose which toll booth they queue up at, depending upon their previous quality of experience on that booth.

For example, a certain toll booth may process vehicles very slowly and hence provides an inferior customer experience with respect to another booth..and so on. 

Let us consider these vehicle owners as customers, and let us consider the toll booths as network service providers (carriers).

The toll station has a certain governance structure in place. Let this governance structure be the regulator.

Let the toll tax be the rating/charging plan of the carrier levied on the customer.

The story gets interesting once the customers pass the toll booth after paying their tax.

As a customer, as long as I pay my toll tax I have complete freedom to access the information present on the super-highway. On both sides of the super-highway we have huge digital “marts” – such as the facebooks of the world, and the Googles of the world. Each digital mart has its own nuances, its own services, its own pros and its own cons.

The best part is, that all products and services offered by these marts are “free” for the customers!
In order to attract customers and merchants alike, these marts offer advertising programs and provide benefit points as part of a well structured points program.

Usually, customers park their cars in one of these digital marts to enjoy their products and services freely.

This is where one of the core concepts of net neutrality resonate – that customers are free to consume lawful content of their choice.

However, service providers also have some small, less glamorous road-side marts which offer services to the same customers. Hence, the operator-controlled digital marts are in direct competition to the OTT player controlled digital marts.

Some of these OTT digital marts also provide shop-space to individual digital retail providers. Let these individuals be the “developers” who use the OTT APIs to develop their apps – that run on android, IOS, Facebook widgets etc.

All these ecosystem players are competing against one another.

At this point, another core concept of net neutrality resonates – “competition among network providers, application and service providers, and content providers.”

The problem:

As expected, the carrier controlled digital marts get fewer customers as opposed to the OTT player digital marts. The reasons are several, and we will not get into that analysis here.

As a result, the carrier controlled marts lose out on revenues made and also find it difficult to recover their CAPEX / OPEX which they had invested in building their digital marts, as well as the information super-highway itself !

Moreover, there is constant pressure of more traffic on the information super-highway, and these carriers have to periodically invest in increasing the capacity of the super-highway by adding more lanes, so that they can cater to the ever- increasing demand. This results in more CAPEX outflows by the carrier.

As soon as the new lane is added, it only adds to the woes of the carriers, as more customers throng the OTT digital marts and lead to congestion on the super-highway. A new lane is added with every technological evolution in wireless standards- from 2G, through 3G and now 4G wireless networks – thus offering customers increased bandwidth.

Some operators build cheaper by-lanes to the information super-highway to offload some traffic. These by-lanes are Wi-Fi offload by-lanes. This provides only temporary help in reducing network congestion, but the major problem still remains.

Knee-Jerk Reactions:

In order to reduce congestion, some carriers resort to bandwidth throttling – by employing speed breakers in front of OTT digital marts. This is not a fair thing to do, as service providers  may not unreasonably discriminate in transmitting lawful network traffic. (See rules above).

Some carriers resort to heavy volume based charging strategies if customers are heavy users of OTT services. All these steps are retrograde in my opinion, as you cannot charge a heavier toll tax based on which digital mart the customer intends to visit. The customer is entitled to choose and consume products and services freely on the information super highway.

Probable Solutions:

There are two solutions to this catch-22 situation:

1. Build a policy aware network.

2. Save on servers and infrastructure CAPEX by moving  to a virtualized IaaS cloud. Use these savings to build a bigger and better digital mart to challenge the OTT players.

The first option is immediately feasible with the advent of LTE networks and the Evolved Packet Core (EPC), which define nine QCI levels in the wireless standard. The PCRF node in the EPC is the nerve center for policy rules and QoS.

The second option is a bit dramatic, but can be an option. Some people would argue that the cloud business model is not proven, and that the savings on infrastructure may not be significant. I feel that rather than blindly investing heavily on infrastructure all the time, carriers can evaluate cloud based IaaS solutions and invest more on building their own digital marts to challenge the facebooks and the googles of the world.

This may sound to be an outrageous idea as of today, but you never know if a cool social network platform may click with customers and give the OTT players a run for their money. The operator holds valuable information about his customers, and this information can be used to give a more personalized customer experience in the digital mart ! Put policy, QoS and bandwidth boost in the mix, and these can act as critical differentiations. Furthermore, add reliable HD video communications capabilities to complete the customer experience.

A good customer care system coupled with a reliable policy controlled digital mart can become a competitor to OTT marts, only if the operators think in this direction and give this possibility a chance.

Food for thought ?

Posted in 4G, Apple, Carriers, Facebook, Google, LTE, OTT, policy, QoS | 2 Comments »