Interoperability in the Real World

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: 3G-324M, WCDMA, Interoperability, IMTC, GCF, Oren Libis

Hosting an Interoperability Event

By Oren Libis

It is now final. My company will be hosting the next face-to-face interoperability event for the 3G-324M activity group on October 8-12, 2007. It has been a bit over a year since we hosted our last event and it seems like I am getting the hang of it.

As we are planning our next event, there is this shopping list of issues that we will be taking into consideration:

• Location
  Need to find a big enough place to accommodate the group. A table for each company, with some space between them.
• 3G coverage
  We have to make sure that there is good 3G coverage in the location of the event and that it can hold a capacity of 10 or more video calls simultaneously.
• ISDN lines
  BRI and PRI. There are those that don’t have direct access to the 3G network, or those companies that would like to test their gateways, so we need to provide ISDN access as well.
• Connectivity of 3G and ISDN
  Now that there are two separate networks (3G and ISDN), we must check that you can call from one to the other and vice versa.
• Wireless LAN
  Everyone wants to use the internet during this week. Might as well provide good access to it.
• Lunch
  The army walks on his stomach and engineers can’t think without sugar. We have to make arrangements for lunch each day – in different restaurants, with English menus.
• Social event
  We’re hosting the event, so we need to give people some good time. Last year it was Jerusalem – this time it is still open. Any suggestions?

There are additional issues such as banners for the event, visa invitations, and restaurants for the evenings...

This event is definitely going to be around MONA call setup time, H.264 video codec and AMR-WB speech codec again, but I have a pretty good feeling that these should go even better than the last time for our group. I can’t wait to meet all of the guys here in Israel!

Technorati Tags: 3G-324M, Interoperability, MONA, RADVISION, Oren Libis

IPSec - transport and tunnel modes

By Tsahi Levent-Levi

Remember my post about IMS access?

I talked about how a user is authenticated on the network using a key exchange mechanism (AKA-MD5 or IKE) and IPSec to ensure privacy.

We were left with this one nagging issue derived from the fact that IPSec is used differently with different types of access. These are:

1. Transport mode, when we use IPSec with AKA-MD5, and we have a USIM.
2. Tunnel mode, when we use IPSec with IKE, and we don’t have a USIM.
3. Transport over tunnel mode, when we use IPSec twice, since we’re outside an operator network.

Why is there a difference? Why not have IPSec in a single mode (like IP VPN) and be done with it?

Well, let’s start with tunnel mode. In tunnel mode, the data that you want to send is going to be passed “as is”, with the key exchange done using either IKE or MOBIKE. That’s not good enough for our USIM (the one that requires AKA-MD5, as it makes more sense to manage the data in front of the operator’s HSS). AKA requires exchanging keys and tweaking some internal parameters of IPSec. So we need to use a different mode for IPSec in this case. The problem is, some of the operating systems most commonly used in mobile handsets do not support this mode. So there is no real solution today for developers. Hopefully, solutions will become available soon.

Doing IPSec twice is sort of like peeling the layers of an onion. The external layer is tunnel mode, where you use IKE in front of your wireless network’s access, but then tunnel the IPSec packets generated using transport mode, which were generated with AKA-MD5 to authenticate the USIM you have with the mobile network (since you don’t have direct access to it) inside it.

So IPSec alone is also an issue.

Do you think this post was written just to make you developers despair? Nah… I know you guys. I am one of you. We developers love challenges. We thrive on them. And IMS is a doozie!

Technorati Tags: IMS, SIP, IPSec, Tsahi Levent-Levi