The most distinguishing feature of modern 3G mobile wireless services over the 2G and 2.5G services of the past has been the emergence of multimedia. The original Short Messaging Service (SMS) could send mere 160-byte text messages from one mobile phone to another. In 2002, however, a combination of new handset hardware and a software extension to SMS gave us the Multimedia Messaging Service (MMS), which enables the transmission by users not just of rich text (complete with selected fonts and colors), but also of images (JPEGs, GIFs, etc.), audio (MP3, MIDI) and video (MPEG) from WAP sites or cameras built into the mobile phones.

The upsurge in multimedia’s popularity and increased demand for sophisticated multimedia-based services in both the wireless and broadband wireline worlds led to the search for a common service architecture. While the 3G wireless networks were on the drawing boards, wireline carriers and equipment vendors had discovered and were beginning to adopt the Internet’s IP packets and Voice-over-IP’s SIP-based signaling and call control schemes. Therefore, it made sense that the new cellular networks could simply reuse these existing Internet Engineering Task Force (IETF) protocols, and by doing so, IP and SIP could now serve as the core of a superlative distributed common service architecture for both wireless and wireline networks, making possible quick and easy service creation, integration and usage in any and all environments (cellular, WiFi (News - Alert) , DSL, cable, etc.). This idea is currently being perfected in the form of IMS (IP Multimedia Subsystem, the first full specification of which also appeared in 2002) that will bring SIP-based multimedia communications to any IP-based wireless or wireline network, and will lead to the future, unified world of Fixed-Mobile Convergence (News - Alert) (FMC).

The upshot of all of this is that SIP becomes the standard signaling protocol/call control mechanism to support multimedia sessions in 3G and 4G networks and (presumably) beyond. Since SIP wasn’t originally designed for the stringent bandwidth restrictions of mobile networks, various developments have appeared to help facilitate the deployment of SIP in wireless environments, such as SigComp (“Signaling Compression”) which enables lossless compression and decompression of SIP messages ranging in size up to several thousand bytes.

SIP has actually been a part of some wireless networks for several years, appearing early on as the fundamental part of push-to-talk (PTT) services. In 2003, for example, Sprint (News - Alert) PCS deployed their SIP-based Sprint Readylink PTT service. Sprint was soon followed by Unefon, a Mexican carrier. However, the question now becomes: can a more sophisticated “Mobile SIP” be deployed on a large scale, allowing users to roam with their varied services to any device or environment?

SIP on the Move

Bill Lesley, Founder and CTO of Longboard (www.longboard.com), says: “I’ve been working with SIP in one form or another close to ten years now. Even in its early days it wasn’t exactly a peer-to-peer protocol; there was always envisaged a server component, but the server was originally just going to find the person in the network you were trying to contact, and then everything else at that point would pretty much revert to peer-to-peer. The view of the academic community was that everything on the Internet was going to be free and everything would center on smart endpoints. I must admit I was recently attending a meeting where I opined how complex SIP has become. Quite a few things have been bolted onto the protocol over the years, for a variety of reasons: to make it work inside of specific networks, or just to correct its initial flaws.”

“Longboard focused on building a SIP applications server,” says Lesley. “We got into that business because, when we founded the company, we were looking at softswitching technology and in talking to a variety of people they said, ‘Yes, Voice-over-IP is clearly where the industry is heading.’ Others kept asking, ‘Where are the features going to come from?’ So, we started building an applications server that would bring some of the basic, required features into the network. We looked at the different protocols available for VoIP and we selected SIP as the one we were going to work with. We got off to a reasonably good start, built a platform and made available some basic services.”

“SIP is at an interesting crossroads at the moment,” says Lesley, “because SIP has been heavily embraced by the guys in the 3GPP for building IMS. This spurred the creation of many extensions to SIP so it could be used in a mobile environment. The IMS network architecture is quite complex, and there’s still quite a few things that need to be understood in how these networks all fit together in an end-to-end perspective. It’s really difficult, as the IMS architecture has grown along with the number of its components and their functions. Fewer and fewer people in the world actually have a complete understanding of how it all actually works.”

“Even so, we should remember that there are many large networks out there that run using SIP as their basic protocol,” says Lesley. “We shouldn’t conclude that SIP itself is not mature enough to run in sizable networks. At Longboard, we’ve had considerable experience in the Japanese market, for example, where there are many large SIP networks. They use SIP not just for the interconnection of the long distance calls with media gateways linking to the backbone network, but in actually providing end user services over broadband connections. They’re quite sizable networks, and SIP has been successfully used as the base protocol inside of them. It’s worked very well in a multi-vendor environment. It’s proven itself to be a very flexible, scalable protocol. So we’ve got some sizable, established networks in place where SIP is running today.”

“I don’t think there’s anything in SIP that makes it onerous to work in the IMS environment,” says Lesley. “Our application server runs in a regular SIP network, and one of the things that we looked at over a year ago is how we could also act as an application server inside of an IMS network; that required us to be compliant with the recommendations for what’s called the ISC interface, which specifies the interface between the CSCF [Call State Control Function] and the application server in the IMS architecture. That interface is referenced as ISC, but it’s actually a very SIP-based interface. When we analyzed that interface and its requirements we were pleasantly surprised to discover that there was basically very little difference between that and what we already supported inside of our platform, just because of the maturity of SIP and how it had evolved over time. With the migration from what had occurred in the original RFC for SIP [RFC 2543] to the newer one [RFC 3261] we saw that, by taking a rigorous approach in implementation, the number of new additions necessary to support an ISC interface were relatively few and minor.”

“At the moment Longboard is focused on the Fixed-Mobile Convergence [FMC] space. We have solutions where you can take a voice call and seamlessly roam with the active call from a GSM network to a WiFi network, and vice versa. We use SIP as one of the call protocols for doing that. We’re actually seeing many other companies in this arena using SIP as the protocol of choice. That work is going through standardization as part of 3GPP for IMS. In talking with other vendors in this space, I believe that the way we all use SIP is probably not too dissimilar. So it’s reasonable to expect that with a little bit of cooperation between vendors, companies building SIP-based FMC solutions should be able to enjoy a reasonably high degree of interoperability since many of the SIP components already work today.”

“When we first got started in this industry it was always a challenge making a new SIP endpoint work with a new SIP server,” says Lesley, “but the usual case now when we receive SIP endpoint devices from a variety of vendors is that we just plug them in and they work out-of-the-box. There might be one or two minor things that need adjustment from the endpoint vendor’s perspective, but we find that there’s a much wider range of interoperability between endpoints and servers than ever before. Now we’re looking at how we can ensure that there’s a wider range of interoperability by focusing on the ways people build SIP-based solutions for FMC. It’s all about how you use the messages within SIP to form particular applications. Generally, in the past there have been sets of ‘best common practices’ wherein you define the preferred mechanism of how you use SIP to build a particular service or feature. From what I’ve seen we’ve got to put those in place regarding FMC.”

“There’s a lot of activity now in what’s being called Mobile VoIP, where you’ve got a wireless SIP client that can make calls,” says Lesley. “Now, if you take a regular wireless VoIP client, there’s no difference with a SIP server in the network, since the client can be plugged into the Ethernet socket in the wall in the way that we would make a normal call. So, there’s an opportunity for hammering out an agreement on the interoperability mechanism for clients and servers in this space, to create an environment so that so that when you start a call using, say, SIP over WiFi, as the device moves out of range of the WiFi access points, you can seamlessly reestablish that call using the GSM or CDMA network. Also, the reverse, or how you can figure out an agreement on what the messaging should look like to both the mobile network and SIP messaging in order to reestablish the call as it roams back to a WiFi environment from the mobile network.”

Lesley muses: “We’re chatting with several other companies in this space, but two years ago these conversations would never have occurred, because we all thought that we had discovered the ideal ‘secret recipe’ and we weren’t about to go around advertising to our competitors how we could make calls move from one network to another using SIP. I think we’ve all finally reached the level of maturity in the FMC industry where we realize that most of the companies that have been working in this space — especially the SIP-based space — have actually devised fairly similar solutions. So, it’s much more interesting to look at how you can grow an industry by harmonizing the way that these SIP-based solutions work so that you can have growth through interoperability amongst solutions, as opposed to having what would mistakenly be labeled ‘proprietary solutions’. I think it’s much better to harmonize the mechanisms that you use across the industry so that the players in this space can actually rely on a good degree of interoperability amongst their solutions just as you would with things such as IP phones talking to SIP servers.”

“My discussions with the vendors in this space boils down to, ‘Yes, this is something we need to do, otherwise we can put ourselves in a position as an industry in FMC by saying that the standards-based activities going on in 3GPP are really the only ‘real’ standards out there, and because those standards aren’t going to be completed until sometime in 2007, there won’t be any standardized solutions, when in fact I think we can actually take what we’ve got to date — without requiring IMS — and actually get industry agreement on a common set of practices, so that we can establish interoperability across a greater number of vendors.”

Proof of Concept

With all this talk about Mobile SIP in a wireless network, the public hasn’t actually seen some of the more interesting full-blown tests and demos until recently.

Take the demo recently presented (September 2006 at VON) by Reef Point Systems (www.reefpoint.com) makers of carrier-class Security Gateways for IMS/FMC networks (and which recently debuted their Universal Convergence Gateway (News - Alert) at ITEXPO West in San Diego), and Spirent Communications (www.spirentcom.com) a provider of integrated performance analysis and service assurance systems for next-gen networking technology.

In the demo, Reef Point’s iQ8000 and iQ4000 Security Gateways were deployed as IMS Security Gateways to provide protection for IMS voice and video calls, and were used in conjunction with Spirent’s Landslide Fixed-Mobile Convergence network tester. The security gateway features showcased in the demo included dynamic stateful-session bandwidth, SIP-aware security and encrypted tunnels for media transfer.

Scott Poretsky, Director of System Quality Assurance at Reef Point Systems, says, “We demonstrated mobile IMS scaling and performance validation using Spirent’s Landslide testing product — they had just introduced IMS testing functionality. As recently as two months ago, there was nothing on the market for actually doing IMS testing like this. Nothing could do IPsec or media, because the tests until now have been pure SIP-only. IMS takes SIP to the next level, and it has additional simulator requirements and additional protocols. So it’s not just SIP through an IPsec VPN tunnel; it also has to do with the sequencing of the SIP signal.”

“Because of the absolute absence of test tools for IMS,” says Poretsky, “we looked around and decided that Spirent, one of the leading test equipment vendors, has the best potential for doing top-notch IMS testing, extending functionality to actually test SIP in an IMS network. We worked closely with their engineering team to help them develop an IMS tester which is absolutely fabulous. It emulates all of the components of a complete IMS topology, and then you can take any networking equipment as a device-under-test and insert it into this emulated topology. The Spirent box with two interfaces will test a device-under-test and actually figure out both its conformance and performance for IMS. Sprient is clearly the leader now in IMS testing.”

“If you looked at our demo with the Reef Point security gateways in the middle, the Spirent Landslide connected to the mobile handsets on one side, and the Internet on the other,” says Poretsky. “And the whole demo simulated and provided VoIP and video security for 50,000 mobile subscriber handsets. To do this we had to set up 100,000 IPsec tunnels. In the 3GPP IMS standard you need two IPsec tunnels per handset: one tunnel is for calls originated from the mobile handset, and the other is for calls originated from the public network to the mobile handset. So, the Landslide emulated 50,000 mobile handsets. The SIP signals are encrypted through the IPsec tunnels and out our security gateway that’s also terminating the IPsec tunnels, then they’re forwarded to what would be the other, public side of the IMS network, where the traffic can get onto the service provider’s network. That’s also emulated by the Landslide test equipment.”

Poretsky beams: “We managed to prove with two boxes — the Sprient Landslide and the Reef Point Security Gateway — that the IMS concepts in the mobile 3GPP standard work.”

(Editor’s Note: For more information about this test, see the SIP Testing article elsewhere in this issue.)

Certainly the SIP that supports mobility must be a great deal more clever than its Internet-based cousin. The application layer must be prepared to suddenly encounter new networks (i.e., movement detection) and it always must maintain knowledge of the current (active) interface’s address. But tests and demos such as those by Reef Point and Spirent indicate that SIP is prepared to bring forth a new generation of exciting mobile services.

Richard Grigonis is Executive Editor of TMC’s IP Communications Group.