Showing posts with label Diameter. Show all posts
Showing posts with label Diameter. Show all posts

Nov 6, 2011

The Brain Surgeons of Diameter

I’ve been hearing something from the field that doesn’t quite sit right. I’ve been hearing that developers of 3G voice protocol SS7 can easily segue into developing good solutions using 4G Diameter protocol such as real-time intelligent routers and reliable load balancing solutions.

Diameter was selected by the industry standards bodies such as 3GPP to be the one protocol that replaces all legacy protocols (MAP, LDAP, Radius, and others) because of its extreme flexibility to support data, services, and applications.
On the flip side, that side flexibility does cause management difficulties. Software engineers who work with Diameter find that after years of intense programming, they can succeed in creating cutting-edge solutions. They understand why Diameter is the chosen protocol to support all the data dominated services and applications of 4G. They know how to configure the code to ensure a 4G network’s reliability to send the right message to the right location 100% of the time. They can design intelligent routing and load balancing solutions to give the network unlimited scalability and 100% reliability.

However, this expertise took some years to perfect and a dedicated team focusing solely on the Diameter protocol and here’s the secret. It took the experience of deploying the Diameter protocol stack in operators around the world to learn the deep secrets and tricks of the trade of working with Diameter. And that is why today, Traffix is the only company that can call themselves true experts in the field of Diameter. That is why there is still is no other vendor offering a full Diameter solution of routing, load balancing and gateway solutions with the added value that Traffix Service Delivery Controller (SDC) offers.

I would say that for others to claim, “we know signaling” based on past experience with SS7 or other legacy protocol is equivalent to a heart surgeon leading a team to operate on a brain without the back up of a brain surgeon.

My son wants to have laser eye surgery to correct his myopia. Am I going to look for a doctor who recently went to a short course to perform the operation, or am going to ask everyone I know for their references, and then select the surgeon who has been doing this operation for years with the highest rate of success? I think the answer is obvious.
Susan Becker

Jun 18, 2010

Improving Diameter protocol

This time I want to discuss one of the problems we see with Diameter and introduce a work being done to overcome this problem.
Capabilities exchange is one of the fundamental and most important mechanisms in Diameter, it is taking place in the beginning of each session, and allows peers to define the basic parameters/capabilities for the session (version number, supported Diameter apps, security mechanisms, etc…)
But what if the capabilities on one of the sides change during the session ? what if the sessions are being kept open for long time and in this time an upgrade or configuration change in one of the clients/servers involved takes place ?

The way Capabilities exchange is defined in RFC 3588 is that it can take place only in the inception of a session, so if there is a change during the session it means we need to tear down all the existing sessions involved and restarted in order for the updated capabilities to be taken into account – not very efficient you’ll agree.

But worry no more, the cure is on the way, a new IETF Diameter draft is here to help - The Diameter Capabilities Update Application.
A work led by Glen Zorn, whom is one of the driving forces behind Diameter since his Cisco days.

This work defines a new Diameter application intended to allow the dynamic update of a subset of Diameter peer capabilities over an existing connection.
Because the new proposed Capabilities Update application operates over an existing transport connection, modifications of certain capabilities is prohibited.
There are a lot of heated discussions going on in the Diameter swamp around this new work – some security issues have being raised, but I think those will be handled also.
This is a blessed and important work (I can see all of you with Gx interface related work scars nodding your heads) and let’s hope we will have this draft approved soon.

I personally believe with service providers complaining on the amount of signaling in Diameter and the delays involved in some of sessions set up times – this new work is very important and sheds bright healthy light into one of the dark corners of the Diameter 3588 RFC.

Oct 6, 2009

Next Generation Networks Control Plane Challenges

The Challenge
The introduction of NGN elements into the telecom network present opportunities to utilize technological advancements to reliably and cost effectively provide a broad array of all IP based services (mobile data, streaming video, advertisements, stock-market quotes,…) to an ever-expanding customer-base, in real time. Yes, we all know NGN is not happening overnight, nor is it happening all over the network at one time. But it is clear to the telecom observer that certain NGN elements are making their appearance in the telecom network, at times as a new Diameter-based OCS node and at other times as a newly introduced NGN element such as a PCRF.

But to make this efficient, manageable and cost effective, the telco must adopt an overall NGN strategy. This NGN strategy needs to take into account both the opportunities that NGN presents to them as well as deal with the challenges presented by the new architecture. An NGN strategic view is especially important because an NGN network doesn't happen overnight. The last thing a telecom operator would like is to have an evolving NGN introduction without a real vision of the final goal. Were NGN an easy short term effort, the coherent implementation would be a simple part of the NGN project implementation; but NGN introduction is slow, at times very local to a specific area within the network (such as the interface between the GGSN and the OCS). Especially under these conditions the challenge of having an overall NGN strategy is crucial to the telecom operator.

Of the many opportunities and challenges that NGN strategy presents to the telco, I would like to focus on those related to the NGN Control Plane. Unlike legacy networks, in which the control plane was primarily the proprietary domain of the Network Equipment Provider, the new NGN control plane is more open and standard. It benefits from well defined interfaces and functionalities and a new broad and flexible enhanced AAA signaling protocol –Diameter - which replaces the existing variety of legacy signaling protocols.

Information that in the past was very difficult to retrieve from the network is now easily obtained. Interfaces requiring long and cumbersome integration are now replaced by standardized connectivity. NGN signaling enables new, fast, easy and cost effective service launches, translating into more services to the customer.

However, this new NGN architecture faces some critical challenges (especially since more and more services will be, over time, launched based on this architecture):
· How to roll out and activate new real time services.
· How to handle the rapidly increasing signaling volume from the new services (which are typically more signaling-intensive than common in the past. Most legacy protocols that are UDP based, Diameter is TCP-based, with an ACK for each transaction – this alone doubles the amount of signaling),
· How to deal with the unavoidably greater fragmentation and amount of network components needed for real time and new multimedia services introduced by NGN.
Thus, load balancing (LB) becomes a key issue, - specifically the control plane load balancing.

This is the challenge of the Control Plane – ensuring that the network is able to optimize the signaling load according to individual telco-defined network, subscriber needs and business operations parameters.

May 2, 2009

Diameter implementations – not for the faint of heart

I want to share with you a few horror stories about some of the Diameter implementations we see out there.
We recently came across an implementation by one of the main network vendors where Diameter server is sending Diameter client messages – of course that the clients in the other end could not respond and some of them where getting quite mixed up with the unexpected message.
This is really the tip of the iceberg, Diameter is very flexible and in NGN the applications are still very young – a destructive combination it seems, so the way the standards are translated and implemented varies across different vendors.
It’s not only the network equipment providers, some of the operators have also joined the party, with in-house Diameter standards and requirements that have already gained quite a “notorious reputation” in where they taken the standards and their non conformance, I don’t want to name and shame anyone, but I’m sure some of you are nodding their heads with called sweat.

Is it becoming better ? well not really, LTE/SAE is being developed today, new cable standards, new ETSI TISPAN equipment, and there things aren’t better, development is starting before the interfaces are finalized, so sorry no good end to this post, I believe the interoperability issues will keep accompany us in the recent future and will affect the dream of open plug & play no silo networks.

Feb 21, 2009

Barcelona – thoughts in Layer 5


This week I been in the Mobile World Congress in Barcelona.
A lot of words were written about the show, by people with much more knowledge and better writing skills.
I will try to give another view of the show – not from the shiny handsets point of view, but from the Diameter view of things.
I think that from the network side there are three main trends/activities that are happening and have close symbiotic relationship with Diameter
The first one is Convergence, I know it’s been around since the millennium, but it’s really happening, maybe not because of the service transparency and new services, as much as the fact that it can save OPEX and CAPEX and create new revenues by opening new markets. Convergence requires a lot of Diameter, but also presents a huge challenge in the Diameter level – how to connect wireline and mobile infrastructure that use different Diameter standards, or how to connect mobile Diameter based equipment to ISP equipment that is still using RADIUS.

The second trend is LTE, it’s enough to see some of the press releases from Verizon, Ericsson and Alcatel-Lucent to understand that the industry is aligning behind the technology, and in 2010 we are expected to see the first roll outs.
LTE represent a all new set of Diameter interfaces, with brand new networks that are using (by the standard) more than 45 Diameter interfaces, Diameter is everywhere and actually not limited to the core anymore, it is moving out to the edges, up to the last mile – those Diameter interfaces are not out there yet – so what will NEP’s do – I guess as always – build their own semi standard interfaces – and will continue to sweat on interoperability and lock the operators

The last trend is the Cloud – some heavyweights such as IBM, are pushing it, and they see it taking over the telecom world.
Financially it makes sense, mainly with MVNO’s and small operators but also with the Tier-1’s that don’t want to spend billions on OPEX and CAPEX.
I think one of the main issues that I can see from that level is that there are going to be huge interoperability issues, and the datacenters will need to have Diameter Gateways in the entrance to the cloud to make sure the information can be spread inside the cloud with no vendor and standard lock-in.

There are a few more things that changed this year, such as UMA – one of the big trends of the last few years almost disappeared, and it seems that Mobile WiMax might be going in the same route, unless something drastic will change, most of the people I met weren’t’ optimistic on its future.

That it, next time I will try to dig in Diameter and LTE, what is new, and some of the challenges.