The First IMS AG Face2Face Event is Here
September 25, 2007
It’s about time this happened. We’ve been working for several months now in the IMTC IMS AG for this moment – the first face-to-face interoperability event of our group.
Why is this important?
Up until today, no real IMS testing was done for the client side in any methodical way. Sure, the IMS Forum is doing PlugFest events and the GSMA is also doing some basic interoperability testing for their specification. Nevertheless, there’s no real place where handset vendors and middleware/software providers for handsets can gather around on a regular basis and deal with interoperability. The IMS AG is just that place.
What do we focus on?
We currently deal with Video Share as an IMS service that we are testing, focusing on the client itself. Not what is required on the network side and how billing is done but rather how two mobile clients can call each other, negotiate the parameters they will use for the call and share a video session between each other. We will be moving on to additional client-side service aspects as they develop – we started with Video Share simply because it seems like one of the services of IMS that will be deployed first – I believe AT&T is the first of many operators that will focus on Video Share in the next couple of months.
What do we do?
We talk once a week or two, depending on availability. Companies in the group join a conference call to discuss matters at hand. In these calls we discuss a wide range of topics:
- Drafting out our test case document
- Establishing and discussing liaison connections with other organizations (GSMA, IMS Forum, OMTP and others)
- Scheduling interoperability events
Our goal?
To make sure that once operators decide to deploy services such as Video Share, they will be able to choose any phone vendor they want and be confident of the level of interoperability provided. This means that operators would rather take handsets from vendors who are actually test interoperability in the IMTC IMS AG.
October interoperability event
Our first event is scheduled for October 10-12 this year. RADVISION, my company, is hosting this event along with the 3G-324M AG, which will do their own interoperability testing there.
We are planning to convene after the event and publish the first official test cases document for Video Share from the IMTC. As usual, I am sure we will have some comments to the 3GPP and the GSMA that might require some clarifications or changes to the specifications – that happens when an activity group in the IMTC starts doing interoperability and places a specification under its magnifying glass…
If you do develop communication products, you must know that interoperability is important. What do you do to close this gap of interoperability in your products?
Technorati Tags: IMTC, IMS, IMS Client, Video Share, GSMA, IMS Forum, OMTP, 3GPP, Interoperability, 3G-324M, Tsahi Levent-Levi
.
IMS, 3GPP and IETF: A standardization complexity
September 3, 2007
How do we get those specifications for IMS? In a complex way.
It started off as a set if requirements for a Next Generation Network (NGN). The 3GPP wanted an all-IP network for its mobile infrastructure, calling it IMS (IP Multimedia Subsystem). As there’s no need to reinvent the wheel, the 3GPP decided to select an existing standard to do the work, and SIP was there – all young and fresh. But SIP is an RFC. It is handled and standardized by the IETF. This need not be changed.
So what does an organization like the 3GPP does at this point in time? Use the IETF as a subcontractor.
Have you ever worked with a subcontractor? I have never heard of anyone who liked the experience… you provide requirements for a rocket to space, and you get a fire cracker. You want a match, and you get a rocket instead. Time is not time, effort estimations are far from true (sounds like regular development, but it is always harder with a subcontractor).
So we have the 3GPP providing the requirements, while the development of new RFCs (=standards for IMS) done by the IETF, including modifications to RFCs when needed.
The result?
- We have a whole lot of RFCs coming from the IETF. Some colliding each other, others solving the same problems, but a bit differently.
- We have a bunch of 3GPP specifications, which point to RFCs (and a lot of drafts!) that are used by the 3GPP’s IMS network – in a way, a selection of the RFCs that are needed.
- But then, it is not always understood which features from the IETF, or the 3GPP you really need to build an application. And as usual, I haven’t covered GSMA, GCF, OMTP and other organizations.
We at the IMTC IMS AG are actually facing these issue each day. We are currently unraveling the set of specifications required for the implementation and interoperability of the Video Sharing service that is gaining momentum.
Technorati Tags: IMS, IETF, SIP, SigComp, 3GPP, Standardization, Tsahi Levent-Levi
.
IMS and access
June 11, 2007
Let’s explore the issue of access (how IMS clients register on the network and gain access to services) in the world of IMS. Today, the way this is done over UMTS is simply by using the USIM (that small card hiding behind the battery of your handset. You know; the little bugger that falls out of the phone and onto the floor sometimes).
The USIM card is what holds the information that links your identity with the mobile operator’s database. And that’s what it does on an IMS network too.
So what do we need to do? Connect a mobile handset that has a USIM to the network. The technique used is asymmetric keys, exchanged in SIP, using a procedure called AKA-MD5. And since we want the actual exchange of the information to be secure, we send everything on top of IPSec, in a mode called transport mode.
Sounds OK. But that’s the 3GPP way of doing things. IMS has been adopted by all sorts of networks, and all types of Wireless LANs (WLANs) will now used as access to IMS infrastructure.
But wait – WLAN devices don’t have USIMs. And no asymmetric keys you can use directly. And you still need authentication. Maybe the solution is to use IKE! — not AKA-MD5. And why not use IPSec – we have that already. And once we are doing that, we should use a different mode of IPSec (tunnel mode if you’re really into details).
Let’s see… can we make it even more complicated? What about all those mobile devices that have both USIM and WLANs. OK, here’s a neat solution. Let’s do IPSec twice (yes – twice!) on each and every packet we send. One will provide access to our WLAN network, and this will tunnel IPSec packets that are targeted directly at the IMS core of the mobile operator. So lo and behold, now we are going to have transport level over tunnel for IPSec!
Confused? Well, so am I.
And as if all this wasn’t enough, I haven’t even gotten into all the veritable alphabet soup of other issues like MOBIKE, EAP-AKA or EAP-SIM. Ouch!
To make a long story short, this may sound and look unwieldy. But it works.
When you are developing new products, don’t forget that gaining access to IMS can be quite a complex task. It depends on which transport you are using and what network you are trying to access. So roll up your sleeves, get out your acronym glossary and get to work!
Technorati Tags: IMS, SIP, 3GPP, IPSec, Tsahi Levent-Levi
.
Compression and IMS, Part 2: ROHC
June 1, 2007
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
.
Compression and IMS: SigComp
May 4, 2007
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.
Glossary
May 14, 2006
SIP
SIP (Session Initiation Protocol) is an IP telephony signaling protocol developed by the IETF. SIP is a text-based protocol that is suitable for integrated voice-data applications. SIP is designed for video, voice and data transmission and uses fewer resources and is considerably less complex than H.323.
VoIP
VoIP (Voice Over IP) is a set of technologies that enables voice, data and video collaboration over existing IP-based LANs, WANs, and the Internet. VoIP uses open IETF and ITU standards to move multimedia traffic over any network that uses IP.
MIPS
MIPS (Millions of Instructions Per Second) is a measurement generally used to describe the speed of computer systems, and in some cases, the speed of a given algorithm or program. As a rule of thumb, lower MIPS for an algorithm’s implementation is desirable when used in mobile handsets with limited resources and battery life considerations.
RTP
RTP (Real Time Transport Protocol) is an IP protocol that supports real-time transmission of voice and video. It is widely used For VoIP. RTP is sent over unreliable communication channels, where data may be lost, delayed or re-ordered.
H.264
Also known as MPEG-4 Part 10, or Advanced Video Coding. H.264 is a digital video codec standard which is noted for achieving very high data compression. Technically identical to the ISO/IEC MPEG-4 Part 10 standard (formally, ISO/IEC 14496-10).
CIF
CIF (Common Intermediate Format) is a standard video format used in video conferencing. CIF is defined in a resolution of 352 by 288 pixels.
3G
Third Generation Mobile System – The generic term for the next generation of mobile wireless communications networks.
PSTN
PSTN (Public Switched Telephone Network) is the worldwide voice telephone network. Once only an analog system, most telephone networks today are digital. In the US, most of the remaining analog lines are the ones from your house or office to the telephone company’s central office.
SigComp
SigComp (Signaling compression) is a specification defined in RFC 3320, which enables compressing messages generated by application protocols such a SIP.
IMS
IMS (IP Multimedia Subsystem) is a standardized Next Generation Networking (NGN) architecture for telecom operators that want to provide mobile and fixed multimedia services. It uses a VoIP implementation based on a 3GPP standardized implementation of SIP and runs over the standard Internet Protocol (IP). It supports both packet-switched and circuit-switched existing phone systems. The aim of IMS is not only to provide new services but all the services, current and future, that the Internet provides. IMS uses open standard IP protocols, defined by the IETF. IMS truly merges the Internet with the cellular world; it uses cellular technologies to provide ubiquitous access and Internet technologies to provide appealing services. Because it is access network independent, IMS enables converged fixed mobile network.
TISPAN
Telecoms & Internet Converged Services & Protocols for Advanced Networks. Formerly Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) is a standardization body of ETSI, specializing in fixed networks and Internet convergence.
3GPP
3GPP (Third Generation Partnership Project) is a body comprising several organizational partners working to produce technical specifications for a third-generation mobile system based on GSM core networks and the radio access technologies they support known as WCDMA (UMTS).
WiMAX
WiMAX (Worldwide Interoperability for Microwave Access) was defined to promote conformance and interoperability of the IEEE 802.16 standard. The Forum describes WiMAX as “a standards-based technology enabling the delivery of last mile wireless broadband access as an alternative to cable and DSL.”
XCAP
XCAP (XML Configuration Access Protocol) allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URLs, so that these components can be directly accessed by HTTP.
