3G-324M - From Connectivity to Services

By Oren Libis

Today, 3G-324M is used for video telephony and it is deployed in Europe and Asia, and many many handsets. China is now joining the bandwagon as well, with their TD-SCDMA network.

At the IMTC, we have been covering the adoption of 3G-324M over the last several years, especially from the point of view of the handset. This includes interoperability testing between two points, each running 3G-324M. During that time, we focused on making sure that channels are opened properly, and that video codecs are negotiated reasonably. From there, we moved on to handling call setup time. Along the way, other technical issues were dealt with and solved.

Today, I feel confident that the technical issues of video calls between two handsets are solved. The level of interoperability we have achieved within our group is high. I am also quite impressed by the level of interoperability that the newest addition to the standard – H.324 Annex K (also known is MONA) enjoys. I had my doubts, but during the last SuperOp! event on April, I was able to interoperate quite well with several vendors – no small achievement for a new specification that several companies are implementing independently.

And this led me to think about what’s next in store for our Activity Group. 3G-324M is relatively limited. You can use it to open multiple multimedia channels between two points, and this is mainly used to execute video telephony calls. You can try adding text, adding more codecs or trying to increase the bandwidth, but I believe the next challenge for the 3G-324M AG will be services.

As 3G-324M is used by operators to offer interactive video services to customers, our primary concern should be making sure that 3G-324M is as flexible as possible for services. We already have basic calls up and running well. But there are other technical aspects that didn’t get as much attention as they needed. Deploying a video ring-back tone service, for example, is a technical challenge due to the way 3G-324M is defined. This is an issue that makes the deployment of such a service so expensive to operators. From my conversations with service providers, I believe that there are a lot more services that subscribers would like, but we don’t handle well enough. So we have our work cut out for us.

If you are an operator or if you are in the business of developing services for operators, I suggest you join the IMTC 3G-324M Activity Group. The time has come to make 3G-324M services a reality.

Technorati Tags: 3G-324M, ITU, MONA, Oren Libis, TD-SCDMA, WCDMA

AT&T and Video Share

By Tsahi Levent-Levi

I totally missed this one!

I’ve been to NXTcomm. I sniffed around. I searched for IMS. I came back empty handed.

But then – AT&T actually announced their Video Sharing service during the show. And on the same day I was there…

I first found out about it in MobileCrunch blog – good I’m reading others. Two days after it was posted there, my Google alerts went jiggling happily about this service. It’s so good to know that operators are going to offer Video Sharing as their first IMS service.

To those of you who don’t know what Video Sharing is and those who would like to understand what can be done with this technology, AT&T were kind enough to have some mockup demos in their site – they’re quite good.

The interesting this is that they will be doing that over their WCDMA network and not CDMA2000 EV-DO one. The reason for that is the way these two technologies differ from one another.

In WCDMA, you can utilize both the circuit switched and the packet switched networks at the same time. This means that you can do an audio call over the circuit switched connection (as it is done for every audio call today), and then you add the video over the packet switched network (the data capability of the network).

But in EV-DO, this is impossible. You either do voice calls over circuit switching or data of some kind which would be packet based. So to do Video Sharing over EV-DO would require doing the voice over IP as well – and that’s a whole different ballgame.

So Video Sharing it is.

Let’s see which operators jump on this one next.

Additional coverage - Wired News, AT&T Site

Technorati Tags: NXTcomm, Video Sharing, IMS, Tsahi Levent-Levi

NXTcomm and IMS

By Tsahi Levent-Levi

This week I had a business trip. As part of my day job, I joined a panel discussing the IPTV experience at NXTcomm. While there, I had the time to walk around the show floor and see what companies are doing.

I can definitely say that this year, the main theme of NXTcomm is IPTV.

The second coolest acronym in the show was IMS.

First question out there, is what does IPTV has to do with IMS? Probably everything and nothing at the same time… But I’ll be leaving this one to a future post sometime.

What I really want to discuss here is still IMS.

Walking the floor and talking to companies in NXTcomm means you are meeting a lot of sales people from different companies. So IMS is what I do here, and I decided to go check what these people know of the IMS offering of their companies (you know – it’s not that easy).

Here’s a short roundup of the answers I got:

• “It’s essentially SIP”
• “We’re doing SIP, connecting it with Alcatel-Lucent’s thing, and we support IMS this way”
• “We’re IMS-ready” (heard that one before)

So nobody really knows what IMS exactly is there and don’t know how to chew it. Hopefully, this will change with time… especially when they all have IMS written all over their booth…

Technorati Tags: NXTcomm, IMS, IPTV, SigComp, Tsahi Levent-Levi

Testing IMS Video Sharing in the IMTC's SuperOp!

By Kristofer Jarl

Hello friends.

I'm now facing a difficult task. I have to write enough material about our tests during SuperOp! 2007 to make this post interesting, and at the same time I have to keep the actual result and outcome secret, due to disclosure agreements. Let's see how I do.

First of all, there was no scheduled test time dedicated to CSI (or VideoShare) during SuperOp! 2007. The testing we did was outside ordinary schedule. But still, we received lots of help from the fine people arranging this event, setting up environments, provisioning SIMs and so on. Thanks to everyone who helped out.

After having tested connectivity and server environments during Thursday evening, the actual testing began early Friday morning. A few hours later, we were forced to cut off, since networks were going down and plugs were being pulled. Nevertheless, we are happy with the outcome. We have tested according to the test specification, and we have some issues that should be addressed. Video has been sent, and video has been received.

Saturday morning we had our first F2F meeting. Finally. Due to some last minute changes, only five companies were represented. But we are still satisfied, we now have momentum. Several details were discussed regarding the test document, and we started planning a new test activity sometime during August/September. This time it will be an isolated CSI test activity. We will focus solely on the services that the group is involved in. Sweden or Israel seem to be hot candidates. Hope to see you all there!

All in all, it's great to see the recognition we are gaining, after all our hard work. If we keep going like this, we are on our way to success. New companies are joining the group, and our liasons are welcomed by everyone. Hopefully, more test events will be reality soon, and we are also glancing at other features similar to CSI that we would like to bring into our group. Please join, you could be in for something good!

Take care!

Kristofer Jarl
Sony Ericsson Mobile Communication

Technorati Tags: IMS, SuperOp, Video Sharing

TD-SCDMA Video Telephony and Interoperability

By Oren Libis

In the IMTC 3G-324M Activity Group we handle interoperability for video telephony. The companies participating in this group focus on WCDMA, though other networks can be easily supported as well.

Recently, we have noticed that China is working more quickly on building its TD-SCDMA network building – most probably because of the Olympic Games planned for next year. TD-SCDMA also enables use of 3G-324M for video telephony like WCDMA – you get a 64kbps circuit switched connection in both directions of your call and you use it to transmit H.324 bit streams.

If we try to predict what’s in store for the TD-SCDMA industry, it seems like the IMTC can offer a lot to China in terms of experience with 3G-324M interoperability. We know the companies, the technology, and the facilities that test video telephony. We handled standardization when it was required and have seen more and more products conform to the 3G-324M standard and improve interoperability.

As TD-SCDMA embarks on its first steps as a live network, I am sure that vendors will face the same interoperability problems that we faced in the beginning of WCDMA. But this time, there are lessons to be learnt from our experience developing and deploying WCDMA handsets and services. My feeling is that interoperability between TD-SCDMA and WCDMA is also important.

I would like to invite all TD-SCDMA vendors out there to join us in the IMTC. Benefit from the vast experience we have accumulated and be part of our efforts to promote the use of 3G-324M in mobile handsets. There’s a lot of work to be done. We’re here to help.

Technorati Tags: 3G-324M, Oren Libis, TD-SCDMA, WCDMA

IMS and access

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,

IMTC panel at VON Europe - IMS, Enterprise Communication and Carriers

Next week, at VON Europe, I will moderate an exciting panel about the influence of IMS on the business of enterprise communication vendors. The panel will take place at the exhibition theater, 12th of June, at 1145.

The panel will cover, among other issues:

1. The evolving needs of enterprise customers

2. The way IMS opens the enterprise communication market for operators

3. Business strategies and positioning of different market players

Our panelists include:

Stefan Karapetkov, Sr. Techinal Advisor, Polycom

Edmond Osstyn, Business Development Director, IMS Applications, Alcatel-Lucent

Adi Paz, Sr. Director, Products and Marketing, Radvision


Technorati Tags: IMS, VONEUROPE07, Polycom, Alcatel-Lucent, Radvision, Kfir Pravda, Strategy, Enterprise communication, carriers, operators

Compression and IMS, Part 2: ROHC

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