Protocols key to wireless success

The wireless sector has finally ratified the air-interface specifications, such as wideband CDMA, that will make 2.5G and 3G networks a reality. But new standards are needed if we are to make the leap to an all-IP wireless approach.

According to Umesh Amin, director of the new technologies and planning team at AT&T Wireless, one of the biggest stumbling blocks to delivering voice-over-IP services over wireless links lies in the development of call control protocols. Thus far, Amin said, no call control protocol has formally been defined for 3G networks, and that has slowed the development of VoIP over wireless.

Maria Palamara, distinguished member of the technical staff within Lucent Technologies’ Mobility Solutions Group (Whippany, N.J.), also pointed to the call control protocols as a holdup to VoIP service. "Standards have not been adopted," Palamara said.

The real issue centers on defining the Session Initiation Protocol (SIP), under the Internet Engineering Task Force (IETF), for the wireless environment. SIP is designed as part of the overall IETF multimedia data and control architecture, currently incorporating such protocols as RSVP, for reserving network resources; the Real-time Transport Protocol (RTP), for transporting real-time data and providing quality of service (QoS) feedback; the Real-time Streaming Protocol (RTSP), for controlling the delivery of streaming media; the Session Announcement Protocol, for advertising multimedia sessions; and the Session Description Protocol (SDP), for describing multimedia sessions. The functionality and operation of SIP, however, are not dependent on those protocols.

"SIP brings tremendous flexibility," said Amin of AT&T Wireless. SIP allows designers to avoid being locked into one or a few coding protocols for transmitting data. On the contrary, Amin said, when data comes in, engineers can tap into SIP support for a variety of coding schemes and then choose the best one to support the chosen coding scheme for the application at hand.

According to Amin, SIP achieves that flexibility via the way it treats voice. Rather than see voice and data as separate, as some specs do, SIP views voice as another application. That lets wireless carriers and equipment manufacturers allocate coding schemes and protocols application by application, which improves network operation and efficiency.

Overhead also plays a role. According to Stephen Hayes, chairman of the 3GPP Technical Specifications Group for Core Networks (TSG-CN), 3GPP evaluated both H.323 and SIP for the call control protocol. In the end, SIP was chosen for a number of reasons. One of the biggest is that SIP appeared to be a lighter protocol that would put less strain on the wireless channels, Hayes said.

But technical considerations were not the only reasons for selecting SIP. Key business factors also came into play. The wireless industry, Hayes noted, is "trying to enter an Internet world. To do this, it’s important to work with IETF." And since IETF is defining SIP as its call control protocol, Hayes said, it made good sense to choose SIP for the upcoming 3GPP specifications.

The 3GPP2 camp expressed the same sentiment. Mark Lipford, chairman of the TSG-S All-IP Ad Hoc Group, said 3GPP2 also considered it important to align itself with IETF and to choose SIP as the call control protocol. With its colleagues at 3GPP adopting the spec, it only made sense for 3GPP2 to do the same, he said. "Everyone on the wireless side is adopting SIP. We don’t want to go in another direction," Lipford said. "There’s no advantage in having two different standards. This will better facilitate roaming and network interoperability."

Achieving interoperability will nonetheless take some work. There are still big differences in the legacy networks that will make up the heart of the 3G wireless environment. Additionally, as Hayes pointed out, the standards bodies will differ somewhat in the ways they define SIP.

Therefore, even though both bodies accept SIP, their implementations of the protocol could differ, meaning that more harmonization work will be required down the road.

While things look rosy on the SIP adoption front, the protocol poses some headaches for the wireless market. SIP was never designed for a wireless environment. Therefore, Lucent’s Palamara pointed out, the spec has some growing to do before it catches up with the circuit-switched approach used in today’s wireless networks.

One of the big problems revolves around the voice coder schemes that are supported in SIP gateways. Right now, according to Palamara, the traditional wireless voice coders, such as the adaptive multirate (AMR) vocoder, are not supported by SIP. Therefore, manufacturers need extensions that convert wireless traffic to, say, pulse-code-modulated (PCM) traffic or embed wireless coders within gateways.

Since the standards are not defined, Palamara said, many of the initial extensions or embedded coders developed will be proprietary. Those proprietary extensions hurt interoperability and hamper carriers’ ability to establish multivendor networks. Clearly, that thought doesn’t sit well with carriers.

According to both 3GPP and 3GPP2, development of the all-IP network specifications is under way. Hayes said the all-IP specifications will be included in revision 5 of the 3GPP standards work. That spec initially was slated to arrive late this year, but Hayes now thinks the release will be delayed until at least March.

3GPP2 is rolling ahead with its work on all-IP network specs. According to Lipford, the specifications will be defined under stage 2 of 3GPP2’s specification process. He could not provide a specific time frame for the release of this spec but said that work has started on stage 2. According to Steve Dennett, who chairs the 3GPP2 steering committee, the rollout of an all-IP wireless network will take at least 18 months after the completion of the specifications.

AT&T’s Amin sees rollout of an all-IP wireless network in 24 to 36 months. Thus, if the 3GPP specs don’t hit until March, services won’t roll until 2004 at the earliest. That matches up with Strauss’ assertion that "we won’t see packetized voice until at least 2004."

Amin pointed to network efficiencies as a key driver in the move toward all-IP nets. He noted that AT&T has operated two networks for a long time: CDPD for data and TDMA for voice. Going forward, that is not an efficient operating approach for AT&T. Ultimately, Amin said, the goal is to merge the networks and turn them into an all-IP structure.