By Tsahi Levent-Levi

In my last post, I discussed SigComp and how it relates to the wonderful world of IMS. SigComp though is only part of the IMS compression story. There is more. Much more.

Just in case you forgot – messages are big. We would all like to shrink them so that they use less of operators’ precious bandwidth. We tackled the big message problem by compressing the content using SigComp.

But there is one “minor” issue I left out last time – the issue of IP. IP is a nice enough protocol, and is required for IMS (you remember the IP Multimedia Subsystem…).

SIP messages are sent over TCP or UDP, which in turn are sent over IP. RTP packets (you know, that media we want to see or use) are sent over UDP, which again means it is over IP.

Last time, we dealt with the SIP message issue. But what about the IP, UDP, TCP and RTP?

All these have their own headers that add lots of overhead to the messages themselves. We’re talking about 40 bytes for an IPv4 packet sent over RTP (UDP and IP included). And if we have to send 50 of those packets every second just to keep our audio running, we have some pretty heavy packets to deal with!

The solution to this problem is ROHC (Robust Header Compression). It is defined in various RFCs, with different modes of operation. I won’t delve into the technical details, but would like to point out one very interesting thing: it’s in the operating system.

Since ROHC is used to tweak the size of IP, UDP and TCP headers and compress them to be 1 or 3 bytes, it requires support from the operating system itself. By operating system, I mean your “average” IP stack that you get for free with it.

What all this means to us, is very simple. To implement IMS – and on a client no less – requires not only application implementation but also an operating system with support for all the architecture’s special needs.

Technorati Tags: IMS, SIP, SigComp, 3GPP, Tsahi Levent-Levi, IMTC

.

By Tsahi Levent-Levi

I have been promising to touch on the different aspects of technology related to IMS, and if there is one thing I am good at – it is keeping promises! This time I will start with one of these – compression.

For all you history buffs, let me take you back in time a bit. Once upon a time, there was a great protocol named SIP. It was simple (yeah, sure!) and easy to use. It was text based (Look Mom… you can see messages!), so it was easy to implement, maintain and debug. Many people started to use it and promote it big time. And it did have some great routing and filtering criteria capabilities. So at some point, the 3GPP decided to adopt it for IMS.

So the world was a better place with a nice, simple, text-based protocol, used for signaling purposes over mobile networks. And since it’s signaling, and you don’t have a lot of information you need to convey, it should work. But as time went on, people saw that the messages and the amount of information were actually quite large. When you start adding routing information, authentication and authorization information, billing information and some more – each message becomes REALLY big.

At the end of the day, we had a text-based protocol, with large messages, running over mobile networks. Our problem: mobile networks have lower bandwidths than fixed IP networks (mostly). Also operators out there have to actually pay for the bits you use. For them, more bandwidth required per user for simple calls means less capacity in their cells… and more power consumed by the handset which means a shorter battery life. What to do?

Zip!

You take those messages; you somehow “zip” them and then send them on their way when they take up less space. Since it’s text, it zips quite well.

The secret behind this “zipping” is with a compression protocol called SigComp (RFC 3220, and more) – Signaling Compression.

Everyone agrees: SigComp is nice. It’s general purpose, and it can use different compression algorithms. You can optimize it for the exact messages and scenarios you use. But it’s complex…

By complex I mean that SigComp actually uses bytecode methodology. When you compress messages, you can send along the code that is used to uncompress the messages with the compressed data. This is done using the predefined UDVM (Universal Decompressor Virtual Machine) instructions set (hence bytecode) that outlines the different atomic operations allowed in SigComp.

The process is fairly easy. To compress, you choose an algorithm, use it for your compression, send the compressed data along with the algorithm, and the other side uses the algorithm you sent to decompress.

To make things even more interesting, there’s also a dynamic version of SigComp, which lets you update the SigComp states used in mid-session to provide optimized compression as well.

But then, what could you use as a compression algorithm? Would you go for an LZSS or a Deflate one? Would you do the dynamic optimizations with it? Do you go to patented compressions? Have you thought how much MIPS will this thing take on your mobile???

Lots of questions, huh?

So we have the IMS (3GPP that is). 3GPP means mobile networks. It also means limited bandwidth and the need to compress.

Remember though… there are other standards bodies that do not necessarily need compression, but have adopted IMS architecture. TISPAN and PacketCable, for example, are focused on the wireline and cable telephony networks. So our efforts in this area really are a wider attempt to build a single paradigm for all types of telephony and services! A virtual Utopia! Where everything looks the same.

But our friends who are adopting TISPAN and Packet Cable took a peek at our SigComp in IMS and said, “Sorry. We don’t need it.” Their networks can handle large messages, for them, adding SigComp just adds complexity and requires even more resources.

So, on top of everything else, you are faced with the million dollar compression question: Do you need SigComp or not?

Oh yeah… and what about WiMAX?

So you see, SigComp is only part of the compression story. Next time, we’ll discuss other IMS compression issues.