You are here: Home / Archives for Oren Libis

Would you like to meet F2F in the Holy land?

September 25, 2007 By Kfir Pravda 2 Comments

By Oren Libis

On October 8 -12, the company that I work in, RADVISION, is going to host the next IMTC 3G-324M AG F2F event in Tel-Aviv, Israel, and I am in charge of the organization of the event. This is not the first time RADVISION organizes such an event. The first event took place on February 2006 and yet the upcoming event is exciting just as much and even more.

I participated in many IMTC F2F events in the past 5 years and I traveled to many countries but hosting an event in your home country is completely different feeling. The fact that many people from different companies, countries and cultures get together in one place and work together is something wonderful but when it happens in your home field it is even more wonderful.

I very much enjoy hosting these people which I consider friends, telling them about my country, showing them the holy places, elaborating on the local customs and introducing them to the local food. This is amazing time and again to see their reaction to that. This makes me very proud in my country and very enthusiastic to show more and more.

In the previous event we visited in the holiest place in Israel – Jerusalem. This time we are going to visit in Caesarea. Our goal is to improve the hosting from event to event and so we have some more surprises this time that I am not going to tell otherwise I will spoil the surprise.

And yes, we are even going to work here between visits and test 3G-324M devices. But, I am sure that the special atmosphere and the activities around the event will ease the pressure of the work and make it more pleasant.

I hope that more and more people even from companies outside IMTC read this post and decide to join the event. I hope to see you F2F next month in the Holy Land…

Technorati Tags: , , , , ,

.

About the writer: Kfir Pravda
Filed Under: 3G-324M, Interoperability Tagged With: , , ,

Will 3G-324M MONA be here this Christmas?

September 9, 2007 By Kfir Pravda Leave a Comment

By Oren Libis

MONA (H.324 Annex K), the chosen call setup time reduction technique, was approved by the ITU-T and 3GPP over a year ago. How come we don’t see it in the market yet? It is mainly an issue of standardization and timing.

From past experience in 3G market, it takes about 6 – 12 months since a company has a prototype till the first model gets into the market. This happened in other standards and it has happened in 3G-324M time and again – WNSRP and channel negotiation conflicts are examples of this.

During this time many 3G-324M terminal vendors are working vigorously and intensively on their MONA implementations. Some of the implementations are more mature than others but all in all there is much more work to be done.

Implementing is not enough – you now need to test it. Most of the testing sessions are conducted in the 3G-324M Activity Group Face2Face events of IMTC. In these events many vendors perform interoperability testing against others but this is not that easy for new standards. H.324 Annex K is quite a complicated technique, which changed significantly the way 3G-324M call setup was done till now, so one can expect many interoperability clashes in the beginning of the testing – we’ve seen those in the last three events already. Obviously, the prototypes also need to maintain a very high level of interoperability with legacy terminals which makes it even harder. However, the interoperability level gets improved from event to event and the implementations mature as time passes. The upcoming Face2Face event in Tel-Aviv, Israel on October 8-12 will definitely show high level of interoperability as this is the 4th event that MONA is being tested.

Taking into account all of the above, I would expect to see MONA enabled models out in the market during the second half of 2008. Some initial models might actually hit the market prior to that, and maybe, just maybe, there will be a vendor or two that make it to Christmas this year.

Technorati Tags: , , , ,

.

About the writer: Kfir Pravda
Filed Under: 3G-324M, Interoperability Tagged With: , , ,

Beginner’s Guide to 3G-324M MONA

August 15, 2007 By Kfir Pravda 1 Comment

By Oren Libis

MONA is a call setup time reduction technique used in 3G-324M. In the past several weeks I have noticed that a lot of handset developers and operators out there – not members of the IMTC, are a bit confused at what MONA is and how it really works.

The 3G-324M Activity Group in the IMTC is working hard in the past year on MONA. We’re doing interoperability testing whenever we can and we are going to meet again during October 8-12 for a face-to-face interoperability event with MONA as one of the main items.

What is MONA?

MONA is a call setup time reduction specification for 3G-324M. It is a set of 3 different techniques: MPC, SPC and ACP. I won’t go into the technical aspects of each, but it is important to understand the following points:

  1. Each of these techniques alone can reduce call setup time to below 1 second.
  2. Each of these techniques has its advantages and disadvantages – this is why MONA specifies three different techniques and not only one.

MONA Classes

3G-324M MONA specifies in addition to these 3 techniques, 3 different classes. 3G-324M products need to support only one of these classes. Each class indicates which of the 3 techniques (MPC, SPC and ACP) need to be implemented:

  • Class 1, which requires MPC, SPC and ACP
  • Class 2, which requires MPC and ACP
  • Class 3, which requires SPC and ACP

The different MONA classes are interoperable with each other. For example, if two handsets support MONA, one supporting class 1 and the other supporting class 2, the call that will be established will either end up using MPC or ACP; if one supports class 2 and the other supports class 3, the call will simply use ACP.

What does is mean to you?

  • If you are a developer, you should choose to develop the class that makes the most sense to you in terms of resources, footprint, memory and time to market.
  • If you are a mobile operator, you should not force vendors to support a specific class – let your vendors choose their own class – in the end result, you will still get below 1 second of call setup time and you will be giving the vendors some flexibility.

Technorati Tags: , , , ,

.

About the writer: Kfir Pravda
Filed Under: 3G-324M, Interoperability, Technology insight Tagged With: , ,

Interoperability in the Real World, Part 2

August 10, 2007 By Kfir Pravda Leave a Comment

By Oren Libis

Last time, I tried to explain my view on the GCF test cases. As these are test cases that you need to pass before deploying your product (by going to GCF test labs), no matter how farfetched they are, you need to handle them. But there are another important interoperability issues that the GCF doesn’t handle. These are the real deployments out there today.

There are a large and growing number of 3G handsets out there and they are coming from several handset vendors. Each one has its own behavior and quirks. You’d be amazed how much effort it takes when you develop a 3G-324M stack to handle all of these quirks and how much you need to invest on the codec level and application level to get things done right.

Difference in behavior

This difference in behavior happens due to the complexity and richness of 3G-324M. Granted – it does only a video call, in a straightforward enough scenario, but the amount of options that this single scenario has is almost unlimited:

  • It supports multiple types of codecs each with its own set of configurable parameters
  • There are H.245 messages flowing
  • Media quality needs to be handled differently by the various media systems out there
  • Different developers have implemented 3G-324M, each one understanding the standard in his own way

Server side equipment

There are also servers on the network. These most of the time are using circuit switched networks in front of the handsets, where they are running 3G-324M, but they are also using IP based standards such as H.323 and SIP on the network side, when interacting with media servers for example. They have a different kind of behavior than handsets and they have a different decision making processes designed into them, bringing in more interoperability issues to bear.

What do you do?

The most important suggestion I can give developers of 3G-324M products is to do the GCF test cases that they must in order to get validated, but to focus and invest a lot on the handsets and servers interoperability. Try to get your hands on as much information as possible during your development regarding the differences in behavior of the handsets and servers and make sure you test against as many handsets as possible before you try to deploy your product through an operator.

Technorati Tags: , , , ,

 

.

About the writer: Kfir Pravda
Filed Under: 3G-324M, Interoperability, Technology insight Tagged With: , ,

Interoperability in the Real World

July 23, 2007 By Kfir Pravda 3 Comments

By Oren Libis

Managing interoperability for 3G-324M is not easy if you are a handset developer. There’s a lot to be done and some of it doesn’t always make sense.

What happens when a handset manufacturer finish developing and testing his 3G handset and wants to go sell it through an operator?

This seems like a straightforward enough process: you take the handset, you make sure you test it properly in your labs with a professional QA team and you’re done. That may be the case for things long supported by 3G handsets, such as audio calls over GSM or sending SMS messages, but for 3G-324M this is usually a bit more complex.

3G-324M testing has several different test phases: there are the IMTC, which does interoperability events – and publishes test cases, you have the GCF test labs, which validate handsets using a subset of the IMTC test cases, and then you have handsets and servers that are already deployed.

I have been working for a long time now with handset manufacturers and I have come to the conclusion that sometimes the focus is on the wrong kind of tests.

It might take a bit of time, so let me start by focusing on the GCF.

Take the GCF selected test cases for example. Since most of them are important when you validate your handset – they are all mandatory. But from analyzing them closely you can easily split them up into 3 distinct groups:

  1. Important test cases
  2. “Nice to have” test cases
  3. Unnecessary test cases

I’ll give an example of each. By the way, as the GCF test cases are simply references to the IMTC, you can find all of these test cases here, separated into two distinct documents: interoperability and compliance.

Important test case
An example of an important test case is test case 54. It deals with master slave conflicts – a situation that is common when you have a call between two handsets from different vendors. A few years ago, a lot of handsets on the market and those developed by IMTC companies were unable to pass this test case. As this one deals with a plausible and common scenario, it is important to test it.

“Nice to have” test case
A “Nice to have” test case is test case 47. It checks to see if a handset is capable of accepting a change in media transmission rate because the other terminal/server requested him to do so. I have never quite seen this kind of a scenario happen in real life (it might, I just never saw it). You can take my word for it that this procedure is not that necessary and effective when video is presented on a small screen like the one used in 3G handsets. So this is a “nice to have” test case in my view – it’s a good enough feature, but the problem it comes to fix is just not there most of the time.

Unnecessary test case
An unnecessary test case is test case 45 (and 45u). In this test case, you need to respond to a RequestMultiplexEntry message – either by acknowledging it and sending the entry’s information or rejecting it. If someone is sending it to you, it means that he is already in a lot of trouble, as he didn’t remember what you told him (there are only 16 entries, so this must make him a senile). Let’s assume you reject it – this makes him unable to do a thing about it but drop the call. So we have a test case where the one you are working against is faulty/senile – you choose, and you can decide you don’t support this feature, hence causing a disconnection (and you are still validated by the GCF!). I have never seen a real handset acting in this kind of a way when the terminal he was working against was doing his part of the job. This means that developers need to handle this test case (and a few others similar to it) although their handsets will never actually be in this scenario.

Distinguishing between the different test cases is not easy and requires some knowledge in 3G-324M and in what different products, both handsets and server, are doing. At the IMTC’s 3G-324M Activity Group each company gets to work against a large variety of companies and products with the actual QA and development teams of these companies. This provides important information that can assist any handset vendor to pass his interoperability tests once he gets to that point.

Technorati Tags: , , , , ,

 

.

About the writer: Kfir Pravda
Filed Under: 3G-324M, Interoperability, Technology insight Tagged With: , , ,
« Older Posts