By Olivier Terrien, Director of Strategic Marketing

We are in the age of the data tsunami. Equipped with increasingly smart devices, dongles and tablets, consumers are devouring mobile bandwidth at an unprecedented pace with no end in sight.

Unfortunately, radio access network (RAN) technologies, delivery architectures and economics haven’t kept pace with customers’ increasing appetite for mobile broadband access. Techniques used by handset manufacturers to optimize the customer experience, such as saving battery life, are severely impacting the signaling load and resources in the RAN. Mobile network congestion is increasing as more and more subscribers flock to data-intensive devices and applications. This congestion strains network resources and bandwidth, negatively impacting subscriber’s quality of experience (QoE) and creating churn because subscribers – especially smartphone users – won’t remain loyal if service quality doesn’t meet their expectations.

RAN congestion is a complex challenge, and there’s no simple solution to the problem. Each network reacts differently to bandwidth surges and rapidly changing usage patterns, depending on its capacity and network resources. Adding capacity to the network to prevent peak-usage congestion – essentially over provisioning the network – isn’t a cost-effective or practical answer since RAN bandwidth is still very expensive compared to core network bandwidth. Yet, finding a solution to RAN congestion is critical to long-term success, since RAN congestion has a direct and immediate impact on QoE and ultimately to subscriber loyalty.
Maintaining optimal QoE takes more than simply mitigating RAN congestion. It requires the ability to improve the customer experience with intelligent policy shaping that dynamically balances QoE with available network resources. That’s the idea behind Tekelec’s RAN-Aware Policy Management solution. It combines both historical and real-time data collected, parsed and analyzed from several sources including passive signaling and user data probes, RAN alarms, Location base servers with subscriber profile information to inform the policy-decision process. The solution delivers static and dynamic visibility into the RAN, which the operators need to detect what’s taking place and uses that visibility to shape policy management in real time.

As the mobile broadband market heats ups, RAN congestion management will continue to take center stage. There’s no doubt that it’s a vital component in the quest to ensure QoE. However, long-term success in this highly competitive and consumer-drive market takes more than simply delivering bandwidth. It requires end-to-end, context-aware solutions that enable operators to dynamically shape and influence policy, tune and balance network resources in real time, and measure quality of experience to continually improve service usage and customer loyalty, yielding higher revenues.

More information about how to tackle RAN congestion can be found here.

Watch this short video for a quick overview of Tekelec.

The IPv4 address shortage has officially begun.

On February 3^rd, the Internet Assigned Numbers Authority (IANA) handed out the last IPv4 address blocks to the five Regional Internet Registries (RIRs).

What does this mean?

The current version of the Internet Protocol (IPv4) has enough room for about 4.2 billion addresses. The way these have been allocated — at least, since the mid-90′s — is that IP addresses were handed out by IANA in blocks of 16.7 million at a time to the RIRs. There are five regional registries: one each for North America, Europe, Asia/Pacific, Latin America/Caribbean Islands, and Africa.

These regional registries, in turn, hand out much smaller blocks of addresses (depending on their policies) to ISPs; who then assign them (sometimes one-at-a-time and sometimes in blocks) to their customers.

So, when an ISP runs low on IP addresses, it asks its RIR for another block. When the RIR runs low on its own blocks, it asks the IANA for another chunk of 16.7 million addresses.

There are only 256 of those chunks available, and some are reserved for special purposes. Back in 2009, the RIRs and the IANA forged an agreement: once there are only 5 chunks left, they’ll be handed out to the RIRs (one for each). And that’s what happened two weeks ago.

For the first time in the Internet’s history, it is possible that an RIR could run out of addresses, and IANA would have no more to give it. And this, of course, means that an ISP could get a new customer, but not have an IP address to assign to him.

There won’t be any major changes immediately — at least, none that normal Internet users will notice. The RIRs have their own policies that kick into place when this “exhaustion phase” happens (for example, in North America, an ISP can’t request addresses more often than every 3 months), but that won’t matter to end-users.

However, sometime in the next year or so, an RIR will hand out its final address.  Projections are somewhat volatile, but most signs point to the Asia/Pacific region allocating its final address to an ISP sometime around September or October of this year. And that’s assuming the currently situation doesn’t cause a run on addresses.

What happens after that can take a couple of paths. If ISPs are allowed to allocate addresses out of pools from other regions, then the worldwide address pool will completely dry up sometime in late summer or early fall of 2012. If the RIRs stick with allocating only to their own region, then Europe runs out summer of next year; North America runs out fall of next year; and Latin America and Africa run out sometime around early 2015.

In either case, ISPs in Europe, Asia, and North America cannot request new IPv4 addresses by the end of 2012, even using conservative models.

What happens after that is a matter of much speculation.  I’ll engage in that speculation next time.

Tekelec is at Mobile World Congress this week. Stop by our booth, Hall 1 Stand 1F44/1G49, to learn about two key challenges facing mobile operators: increasing mobile data revenues and improving the customer quality of experience (QoE).

Similar to Email or web services, SIP components can use DNS and ENUM servers to find out how to route a SIP message. Using DNS has the great advantage that the operator does not need maintain local routing tables. DNS enables the operator to support load balancing and geographical redundancy, as well as change the IP addresses of some destination only by using DNS servers without the need to provision each SIP server separately with the needed routing information.

However, using DNS is not without costs both in terms of reliability and security. DNS servers can fail. In this case, SIP servers that contact the failed DNS server will not get a reply and will timeout. This introduces significant delays to the call establishment. In order to avoid these delays, multiple DNS servers must be used and the SIP servers should proactively monitor the status of these servers to avoid contacting a failed server. Additionally, SIP servers should implement a DNS cache so the results of DNS queries are saved locally and can be used to serve requests for destinations that were already resolved – even if no DNS server is available. This way, the cache can help keep the VoIP functioning –at least partially – even if no DNS servers are reachable.

Attacks that affect the DNS service will also have negative effects on the VoIP service as well. Here we can distinguish between two types of attacks, redirection and overloading attacks. The goal of redirection attacks is to forward SIP requests to a malicious site. This is achieved by providing a SIP server with manipulated responses for its DNS queries. Hence, a SIP server that tries to locate the IP address of the VoIP server of example.com ends up at a server belonging to the attacker. This can be achieved by intercepting the DNS queries, guessing the content of a DNS query and blindly answering it, DNS cache poisoning or hijacking a DNS server. By forwarding a SIP request to a manipulated server, the attacker can implement a man in the middle attack and either reply to the call himself –pretty bad if the call was going to the bank for example- or manipulate the SIP requests so as to reduce the security level so that the call ends up being established without any encryption allowing the attacker to eavesdrop on the communication.

Overloading attacks are based on misusing the query/response nature of DNS. When a SIP server issues a DNS query then it will block some memory and processing capacity while waiting for the response. On average it takes 1.3 DNS queries to receive an answer with the mean resolution latency less than 100 msec. The resolution latency is considerably increased in the following cases:

• Irresolvable names
• Congested networks and overloaded servers

With Overloading attacks the attacker aims at misusing and increasing the processing resources needed for resolving domain names which can lead to memory depletion or blocking of the entire server. This can be achieved by causing the SIP server to resolve domain names that are either irresolvable or are served by overloaded servers.

This kind of attacks can be mounted by sending SIP requests to the SIP server with an irresolvable domain name included in a header that used by the SIP server for routing the messages, e.g. Via or route headers or in the Request-URI. Such requests are otherwise well formatted SIP requests that comply with the SIP standard in every respect.

An attacker can ensure that a domain name is irresolvable by launching a denial of server attack on the authoritative server of this domain. Another approach is to actually register a number of domain names and set the addresses of the authoritative servers of these domains to hosts that do not reply to DNS queries or do not exist at all. For registering a domain name the attacker is supposed to provide his name, address and payment information for a domain name registration company. However, as the name and address information are usually not verified and stolen credit cards can be used for payment the attacker can falsify this information and hide his identity.

Using DNSSec (RFC2137) or secured links, e.g., TLS or IPSEC, between DNS servers and SIP servers can minimize the possibility of eavesdropping, guessing and cache poisoning and hence the chance of a redirection attack. However, using these approaches increases the complexity of using DNS, increases the processing and bandwidth needs for using the DNS server and some cooperation between the different entities marinating the different DNS servers. Also, in case an attacker manages to hijack a DNS server then at least the domains for which the hijacked servers acts as the authoritative server will still be unprotected.

The effects of overloading attacks can be reduced by implementing a DNS cache at the SIP servers. By caching not only the positive but also negative responses to a DNS query, a SIP server will not query a malicious address more than once. This will greatly reduce the number of DNS queries issued by the SIP server. Additionally SIP servers should include “receive” tags to their own Via headers. In the “receive” tag the SIP server includes the IP address from which a request was received. This way, when receiving the response, the SIP server will not have to resolve any DNS entry in the Via headers. 

Tekelec increased its global market share – as measured by enabled subscribers – for real-time connection number portabilitysolutions to 48%, up from 35% two years ago, according to research and consultancy firm Analysys Mason. The full findings are detailed in the Analysys Mason 2011 “Number Portability Research Note.”

Full release.

Tekelec has surpassed the 225 million subscriber license mark for its subscriber data management (SDM) products on the strength of three new tier-one operators in the United States, India and Brazil. Since the May 2010 acquisition of Blueslice Networks, Tekelec has also sold its SDM technology to a major Western European operator running an LTE network, a Caribbean-based multi-national operator, and two additional operators.

More information can be found here.

Tekelec will be a Mobile World Congress 2011, Hall 1 Stand 1F44/1G49. At the show, we will highlight our new RAN-aware policy management and mobile video solutions, which combine the Camiant Policy Management Product with the Performance Intelligence Center and the Subscriber Data Management solution.

Also, be sure to join CMO Susie Kim Riley at the Mobile World Congress “Network Breaking Point” panel where she will discuss ideas to address the critical issues regarding the impact of over-the-top services to the operators’ mobile broadband business case. She will be joined by: Livio Borgogno, core network director at Vodafone; Chris Neisinger, executive director, network planning at Verizon; and Michael Luna, chief technology officer of SEVEN Networks Inc. The panel is scheduled on Tuesday, February 15th from 4:15-4:45 p.m. in Hall 5, Room 6.

Here are more details:
Full show announcement
Policy Control and Mobile Video
Improving the Customer Experience with RAN-Aware Policy Management

Director of Strategic Marketing Olivier Terrien discusses RAN congestion and the benefits of Tekelec’s RAN-Aware Policy Management solution.