iConverged

Update: I have now created a sidebar widget titled “Tech Blogs I read” instead of updating this post. Please continue sending me quality tech blogs (with more focus on concepts and less on marketing) as you come across them and refer to the sidebar for updates and not this post - thx.

Total number of ‘market reporting’ VoIP blogs = k+1

where k=number of times you can blink in a day.

However, there are very few blogs that talk about more technology & architecture details and less market details for all things VoIP, SIP, IMS, web 2.0 (with focus on telecom).

So here is a call to unite!

We need a list of what I call ‘geek-talk’ - those that provide more technical insight into how things are.

Here is my list so far. Please update me /comment here with more tech-blogs and I will update this list

Many of these blogs are a mix of techno-marketing, but are written by people who are neck-deep in actually developing/architecting many of the talked about solutions themselves, and hence offer a more detailed insight.

last updated: Apr-30-2008

1. TurnGeek - focus on P2P, SBC, etc.
2. IMS Lantern - IMS architecture related
3. Voice of VoIPSA - VoIP Security
4. IMS Quality - Testing and Monitoring with focus on IMS
5. VoIP Survivor - general voip, with significant focus on their company products
6. TelCAB - IMS B/OSS
7. iConverged - this blog

I spoke at the Internet Telephony conference in Los Angeles last week on IMS, hWiMAX, how they all work together (or not) and what it really means to applications. You can see a copy here

A colleague had emailed me this simple image a while back. They say sometimes an image can be worth a thousand words. I thought this image powerfully depicts the engineering challenges that lie behind making wireless networks ‘work well’.

(I have no idea about the original source of the image, so if someone knows, please email it and I’d be happy to post credits).

Are you surprised by the title? Well, that is really how I see things as it stands today. Based on my discussions with most OEMs and ISVs who have themselves been trialing all over the world for a few years now, we are just about at the phase when most trials are getting out into real deployment. Incidentally, incase you think that IMS all-IP ‘live’ deployments have not yet happened, think again. Remember, in 2006, there was an announcement that Wateem Telecom selected Motorola for a wimax deployment ? Well, that network does data and is ready for voice. Not sure if you knew, but that entire network is over an IMS subsystem (yes, you guessed it – WiMAX on its own is not a session specific architecture, while IMS is, so it makes sense to have IMS on WiMAX, huh ?). And yes, I mean R5+, which is all IP for both signaling and media.

Several green field operators are already deploying or have deployed IMS driven networks (we work with many of them), but very few are touting the IMS name around right now, since IMS has been a long used, much abused and somewhat delayed technology. But make no mistake, IMS powered networks are on the rise. Based on my discussions with several players, IMS deployments are on a steep rise, partly also due to ongoing WiMAX trials. It is worthy to note that most of the WiMAX trials today are to do with ‘high speed data’ and not voice. In other words, WiMAX as it stands today, and defined by WiMAX Forum is only at the IP-CAN level – all the blazing speed for an internet connection. But not voice calls, voice features or the other session level services. And please, don’t tell me “why do we need anything? P2P solves everything!”. Well it doesn’t. You need centralized services for technical and non-technical reasons. For example:

a) Technical: How on earth you do reliably implement a voice mail system and retrieve it when a person is offline ? What happens if the peer node who stored your VM is offline when you come online ?
b) Technical: How do you implement feature interaction ? (example A forwards to B to C, but by mistake C sets a forward to A) since in a P2P network no one has an idea of what service the other has provisioned
c) Technical: How do you implement dial-plans?
d) Non-Technical: What do you do if your “spectrum provider” (you know, in a wireless world, someone is paying for expensive spectrum) blocks VoIP ?

And again, this goes back to my original statement I had made in an earlier post – “IMS is the only architecture that is out there today which supports mobile, fixed and nomadic networks” from a session, policy and interworking perspective. Admittedly some of these areas are still ‘in progress’ from a standards perspective, but it’s the farthest out there in terms of maturity. It was also good to know that Verizon has decided to open up A-IMS and push it to standards bodies. A lot of vendors and operators have done good (but till date proprietary) work on enhancing IMS and filling in gaps, so it is good to see it get more public.

And finally, if you are wondering about my post because you hardly hear IMS being talked about today, this is because we are in the stage between “Hype is Over” to “Deployment is reality”. Here is how is describe it to many:

(click here for Part I)

In a previous article, I talked about how IMS, 3G and WiMAX fit together at a conceptual level. As promised, in this article, let’s delve a bit into what it means to interwork IMS and WiMAX. I wanted to get this article out by end this year, so that we have some ‘meat’ to this thread before I forget all about this in 2007.

Note: as usual, click on images to make them larger

What needs to be interworked ?

At a macro level, we know that IMS is a session control layer, while the Wimax forum’s NWG efforts stop at IP-Connectivity. So when we think of interworking, we need to focus on

1. Policy – how will one enforce that network policies such as QoS, admission control, etc. are enforced uniformly ?
2. Security – how does one ensure that a subscriber is authenticated at the WiMAX and at the IMS layer, since they both provide different levels of services ? (for example, a UE may connect to a WiMAX network , but may not be allowed to place a call via IMS due to call barring)
3. Charging – how will one ensure that voice/video/data related access in the WiMAX network propagate to the IMS charging and policy specification
4. Session continuity – when a WiMAX UE moves between BTSs (micro-mobility) or ASNs (macro-mobility), what changes need to occur at the IMS level to ensure that an existing session is continuous ?
5. Service continuity - when a WiMAX UE side handover occurs, what effect does it have on the ‘service’ being executed -a notch up from the ‘session’ in the previous point. For example, assume that the UE is in a video conference and switches to another WiMAX ASN which has lesser bandwidth support than the previously connected ASN, which would result in loss of video and downgrade to a lower codec rate. To ensure service continuity, the centralized Application Server hosting the conference would need to be notified of this change, and this change may need to be propagated to other participants.

But what is the model of interworking ?

Before we figure out an approach, we need to answer some key questions. For example:

1. Who owns the WiMAX network and who owns the IMS network ? This is a very important question. If Sprint-Nextel went the WiMAX way and Verizon went the IMS+3G way, there are going to be business rules that govern which edge nodes of each network will get to talk to each other. Infact, ownership is one of the biggest challenges of interworking. I’ve spoken to countless enterprise companies who are considering IMS interworking, but are paranoid about exposing their corporate data to a centralized carrier’s HSS, for instance.
2. What is the relationship model ? Master-slave or Peer-Peer ? For example, we can consider a situation, where say, a Cingular own both 3G and WiMAX spectrum and deploys and end-end cross-bred solution. In this situation, since it is all owned by one operator, one could deploy a ‘Policy Control point’ (the guy who says ‘Hey buddy – reduce QoS to 128kbps’) in one and a ‘Policy Enforcement Point’ (they guy who says ‘Okey Dokey ! Let me act on that asap’) in another. Howevever, If you assume as case where two competitive operators just want to offer interworking, but not yeild control, it may be necessary to deploy both the Control and Enforcement nodes independantly in each network, and define a ‘peer’ protocol between the Policy control nodes.

A simple model

As I mentioned earlier, the business and technical permutations to this solution make it an extremely wide area. For simplicity, let us assume the following:

(Don’t ask me why I selected ‘Mo’ - I wanted to be more innovative than saying ‘X’ and this is the level of my creativity…)

1. Operator ‘Mo’ owns both 3G and WiMAX neworks
2. Operator ‘Mo’ decides to make IMS the ‘Master’ control layer and decides to deploy WiMAX as yet another access stratum, under control and direction from the IMS layer.

Understanding Policy Interworking and PCC

In previous releases of IMS, the P-CSCF and the GGSN would often play roles of the ‘Policy Definition Function’ (PDF) and the ‘Policy Enforcement Point’ (PEF), where the P-CSCF would set policy and control based on the network and user profile, while the GGSN would allow/disallow media PDP context and flows based on those instructions. The 3GPP group then felt that the Policy functions were too closely tied to the core elements and there was a need to separate the concept of ‘Policy’ away. Also, it was important to isolate charging and tie it to policy in a way that lends itself to a heterogenous network (i.e. make it IP-CAN independent). This is exactly what the SA2 group of 3GPP was tasked with, and is specified in TS 23.203 “Policy and Charging Control architecture”. This was a better evolution of the older PEF and PDF. In this new model, the following important nodes are defined:

1. PCRF (Policy and Charging Rules Function) – This is a logical node that creates ‘rules’ for setting both policy and charging. These rules could be set using a combination of parameters (example, User Joe is only allowed voice and video’ and network X can have a max bandwith of 256kbps – so when User Joe connects from network X, both attributes are combined and apply to arrive at ‘User Joe is only allowed voice and video at 256kbps while connected to X’
2. PCEF (Policy and Charging Enforcement Function) that acts on the rules from PCRF and enforces the same. The protocol between PCRF and PCEF happens to be Diameter (mapped to Gx interface)

Sidenote: I am still skeptical that in reality the PCRF and PCEF will be sold a ’separate entities’, but I do know of a few companies that have started selling independant nodes for policy. One would need to wait and see whether this becomes a scalable model for making money for them, or will most deployments simply use a policy solution from the same vendor that sold them the core IMS CSCF infrastructure.

It is not possible to define all the differences and enhancements that PCC brings over older pre-PCC releases in this blog note, but in short, it attempts to specify specific charging rules, charging models, concept of a service data flow ,more fine grained QoS control and explicit interfaces to other key nodes that participate in a service flow, like the Charging system, Application Servers, CSCFs and HSS) while ensuring that ideally the PCC should be able to be generic enough to adapt to any IP-CAN.

This is what the PCC architecture looks like (credit:taken from 3GPP TS 23.203)

Mapping to WiMAX Network Reference Model

Now that we understand how PCC works, let us take a look at the WiMAX NRM (Credit: Wimax forum Stage 2 NRM)

In short, the ASN (or Access Service Network) provides the access l
ayer connectivity and QoS to the Mobile Station (or UE). The CSN (Connectivity Service Network) provides connectivity services – usually AAA, IP Address allocation, Security (NAT/Firewalls) etc. are part of the CSN. Not shown in this diagram, is that WiMAX already specified a QoS Framework Service management and enforcement points in the ASN for access QoS and management. They are called the SFM (Service Flow Manager) and SFA (Service Flow Auth.). So it would make sense to use them as an interace with IMS’ PCC.

Remember that we assumed, for simplicity, that there is only one owner and there are no federation & sharing issues. Taking this forward then:

1. We assume that the WiMAX ‘CSN’ is replaced with ‘IMS for session control, DHCP+Home Agent for IP-CAN allocation)
2. The PCRF can then reside in the CSN of WiMAX. And since IMS is part of CSN, the PCRF can effectively talk to the HSS, CSCFs and App. Servers for interacting will all of them for service flow interactions
3. The PCEF will also be part of the CSN, and will communicate to the PCRF via Gx (Diameter)
4. The PCEF will then possibly talk to the WiMAX ASN SFA for enforcing rules in the WiMAX ASN

The last point may be confusing. Why can’t PCEF be a part of the ASN ? Well, it sure can, and like I said, there are multiple ways to slice and dice. But in this way, the PCEF can act as a ‘mediator’ between the ASN and the PCRF. The WiMAX ASN SFA does not understand how to interact with PCRFs and it uses a different mechanism for QoS enforcement. Therefore, the CSN hosted PCEF can receive requests from the PCRF, and translate to the SFA expected interface and vice versa. This also results in lesser re-engineering at the ASN. Ofcourse, that means that the interface between the PCEF and SFA is “new”. The IMS-Wimax interworking folks call this Gx’ (i.e. think of it as Gx, but modified to work in WiMAX). So the final diagram comes out to:

There goes. A simplified approach, at a 10,000 feet level. In the next few articles, I will talk about the other aspects of security interworking, session interworking, service interworking

Disclaimer: I don’t know if and when there will be a part II, but I have a lot to say in this area, and I get the feeling that a single post will not be enough. So let me at least start the article naming in the right way. As I decide to author followups, I will link each post to the other.

Updated Dec 20 2006: Link to part II

There is a lot of confusion and misunderstanding in the market today on technologies that could potentially co-exist or replace one another. This article presents my view of how IMS, 3G and WiMax fit into the larger equation. I

First, let us talk about these conceptual layers: (You would find most network architectures are based on derivations of these layered principles)

Starting from bottom up:

Access Layer: Simply put, the Access Stratum involves all the physical characteristics and the mechanisms needed to connect devices with each other. This may be WiMAX radio engineering (802.16, 802.16e etc.), WiFI engineering, UMTS RAN or other technologies. The job of the access stratum is to define and implement the required protocols to be able to physically connect multiple nodes of a network together. An analogy would be, when you connect your desktop to an ethernet cord, the ethernet related protocols (defined in IEEE 802.3 and related) are responsible to ensure that my computer is able to ‘physically reach’ my wired router sitting somewhere in the back end.

IP Connectivity Layer: Most next generation network architectures have chosen to us IP as their connectivity layer. In other words, designers would like abstract the upper layers from the Access Stratum such that when people build applications on top, they see IP packets, IP addressess and the IP based mechanisms that have become the de-facto standard of the Internet. Of course, what that means is someone needs to figure out how to run IP over the Access Stratum – and there are a lot of ‘convergence subsystems’ that define elaborate technologies to achieve just this. This layer should be able to create an “IP pipe” over the “physical pipe” such that layers on top can use IP addressing to communicate without worrying about the intricacies of how the communication is really happening.

Session Management Layer: Now that we have an end-end IP pipe, where I can reach elements using IP addressing, how does one communicate with them ? How do I discover another user ? How do I request a phone call ? Or a Video call ? How do I, as a network provider set policies (example, Bob is barred from calling), charge (example, $10 flat rate for push-to-talk calls, $17 flat rate for 2 way audio) and provision the network ? This is what the Session Management Layer defines.

Mapping 3G, WiMAX and IMS to these layers:

3G is the full set of layers – it defined protocols from the Access Stratum through the Session Layer. Specifically, in the Access Stratum, it defined UMTS and W-CDMA as popular cellular technologies. As time passed, they realized that other disruptive technologies such as Metro-Wifi and WiMax could be alternate access technologies and that it is potential in the future, as these alternate access stratums get laid out, there may be large subscriber base that do not need cellular protocols but only use WiMAX, for example.

WiMax as it stands today, specifies the protocols for the Access Stratum (IEEE 802.16, 802.16e and related families). To add to this, the WiMax Forum defined a WiMAX based Network Reference Model which uses the ‘Access Stratum’ of the 802.16x specifications and specifies mechanisms of how to run IP over it. In addition, it also specifies the convergence subsystem in great depth, that is required to run a WiMAX based system and end up with an end-end IP pipe with good stuff like Mobility Management, QoS management, Resource Management and the rest, at the IP layer.

IMS is the ‘top most’ stack of 3G protocols. It uses SIP as a preferred choice for session management and specifies Policy, Charging, Location, Routing, Services and Session management so that devices connected to the network via an IP pipe can ‘do things’ like place calls, send IMS and Networks can figure out how to charge, bill, provision and manage.

So when people say ‘IMS is dead, long live WiMAX’ or the other way around, they are probably mixing things.

As an example, WiMAX forum has for long considered to adopt the work done by 3GPP/IMS to see how IMS as a session management layer could fit on top of the WiMAX NRM. WiMAX needs some session management layer, correct ? Now one could create proprietary session management layers on top which are not standardized (many of the current wimax trials use their own walled in session management layers) but there are a few problems with this:

A network architecture takes years to ‘thaw out’. Any network architecture that accounts for session management (so please don’t sight IP and HTTP, please), subscriber management, and heterogenous network interworking issues (example wimax caller calling a PSTN user, or wimax-gprs etc.) requires a lot of thought and design. Are you sure that if you start on your own path, four years down the line you will not re-invent the same thing that IMS already is ?
The motivation for an open standards network is just that – something that is validated and vetted by multiple organizations so that both the users and networks could benefit from muti-vendor interoperability.

On the other side, it is true that the IMS layer carrier within it a lot of ‘baggage’ that may or may not apply to a pure WiMAX network (call continuty anchoring at the IMS level is one example).

The key therefore, is to select a relevant subset of the IMS that is useful for WiMAX as perceived today, and then continue to build on top as the network evolves.

In short, while I think it is reasonable to say ‘long live WiMAX, UMTS is dead’ or ‘long live UMTS, WiMAX is dead’, it is incorrect to say that for IMS vs. WIMAX. They don’t play in the same layer !!

Specifically:

Right, I do have a lot to say. And I think I should end this article here. In subsequent parts, I would like to talk about how WiMAX and IMS coexist and the interworking mechanisms, including ‘Why you may eventually re-invent a lot of IMS even if you think you don’t need it’.

So there you have it, a promise for Part II and Part II at least…

Updated Dec 20 2006: Link to part II