Nathan Stratton's Homepage - VoIP to AAL2 MGCP Box

VoIP to AAL2 MGCP Box

Voice over Internet Protocol (VoIP) has started to displace traditional voice traffic, but much of this has been in the core of the network. The lack of VoIP at the edge of the network is mostly due to the large overhead and Quality of Service (QoS) associated with the transport of VoIP. Today there are networks deploying Voice over ATM (VoATM) on the last mail, but this comes with the cost of deploying legacy TDM switches over newer softswitch technology. In this paper we will take a look at VoIP and VoATM technology and look at ways to combine benefits of VoIP and VoATM to build an efficient next generation voice network.

A 10 ms G.726 voice sample is 40 bytes, but requires a 20 byte IP header, 8 bytes UDP header and a 12 byte RTP header to transport on an IP network. IP is a Layer 3 protocol and requires a Layer 2 transport protocol to get the IP datagrams over a last mile access circuit such as ATM or Frame Relay. ATM provides much better CoS/QoS then Frame Relay and is normally the transport of choice.

ATM is a fix length cell layer 2 transport protocol. Each cell has a 5 byte header and a 48 byte payload. Typical IP packets are up to 1500 bytes in length, much longer then the 48 bytes available in an ATM payload. In order to transport IP over ATM one needs to be able to split an IP datagram over many ATM cells. The Segmentation and Reassembly (SAR) of IP packets into ATM is done with ATM Adoption Layer 5 (AAL5). The IP datagram is segmented into 48 byte chunks filling ATM cells payload. The last cell contains the 8 bytes AAL5 trailer. Any space between the last IP segment and the AAL5 trailer is filled with padding to maintain the cells 48 byte integrity.

In order to get the total overhead required to transport a 40 byte 10 ms G.726 voice packet you must first add 40 bytes for IP/UDP/RTP header yielding a packet size of 80 bytes. Transporting that 80 byte packet over ATM AAL5 would require two cells; the first cell would have 48 bytes of the IP datagram. The second would have 32 bytes of the IP datagram plus the 8 byte AAL5 trailer at the end of the cell. The remaining 8 bytes between the segment of the voice packet and the AAL5 trailer would be padded giving us overhead of 98.8% (53 bytes * 2 cells – 40 bytes payload / 40 bytes payload).

VoATM uses AAL2 to perform SAR function with a 3 bytes Common Part Sublayer (CPS) header and 1 bytes start field. Key fields of a CPS header include the channel identifier (CID), which uniquely identifies up to 284 individual channels inside an AAL2 cell, the length indicator (LI) identifies the length of the packet payload associated with each individual channels, the user to user indication (UUI) field responsible for linking user services or groups of services with the Service Specific Convergence Sublayer (SSCS) and the header error control (HEC) field.

Several CPS headers may be combined in one or several AAL2 PDUs allowing for multiplexing of several voice channels. An important part of AAL2 is fill delay; this allows the network operator to select size of the voice frames for each channel. If we were using G.726 with a full delay of 8 ms would yield 32 bytes. If we had 2 channels 8 ms G.726 we would requires a 1 bytes start field; the 1st channel 3 CPS header followed by the first 32 bytes of voice. Then you would add the 2nd channel CPS followed by the first 9 bytes of the 2nd voice channel filling the first cell. The 2nd cell would have a 1 byte start field and the remaining 23 bytes of voice then padding to fill the cell. If you wanted to fill a cell efficiently with only 1 channel you would use a fill delay of 11 ms with the overhead of only 20% (53 bytes cell – 44 bytes payload / 44 bytes payload).

With all the overhead associated with IP over ATM and because IP requires a Layer 2 transport protocol it begs the question “Why not just transport voice over ATM”? Several companies have built on VoATM rather then VoIP, but at large cost. All of the VoATM gateways today are unintelligent devices. They simply take a AAL2 PVC from the Integrated Access Device (IAD) and convert it to a GR303 CRV. The gateways’ front large TDM class 5 switches and the gateways act as a remote terminal with all of the intelligence residing on the class 5 switch. When the user picks up an analog phone that is connected to the IAD, the remote class 5 switch provides the dial tone and DTMF functions.

Most VoIP networks, on the other hand, have a much different overall network design. The IAD that terminates the voice and data traffic at the endpoint has some basic intelligence. When the user picks up the phone the dial tone they hear is from the IAD, not from some remote switch. When the user enters a digit string that matches the digit map in the IAD the IAD sends the string to the softswitch. The softswitch is responsible for providing the voice features and call routing. The voice traffic does not actually pass through the softswitch, rather it signals the IAD to hand the call of to another IAD or to a trunking gateway if the call is connected to the PSTN. The scope of this paper does not cover softswitch technology, but basically the softswitch approach decouples the intelligence from the switching and allows companies to put service creation into their users hand.

Currently hardware does not exist that will allow a services provider to build a efficient VoATM last mile network based on VoIP softswitch technology. In fact, such a box could easily be built that accepts AAL2 PVCs converting them to VoIP stream. Such a box would terminate AAL2 PVCs and basically act like a big MGCP IAD. Instead of analog FXS or FXO ports the box would just use AAL2 PVC from a VoATM IAD as voice path. The VoATM IAD would be responsible for encoding the raw voice channel and onto the AAL2 PVC. The box like any other MGCP IAD would need to provide dial tone, listen to DTMF digits, provide signaling to softswitch and establish VoIP RTP stream to the endpoint provided by the softswitch in the SDP message. In order listen to DTMF and maintain voice quality the box would only copy and decode incoming encoded voice stream and not actually decode and recode the voice stream before DTMF digit decode. This would allow the box to function as a pass through device from the encoded voice standpoint and simply place samples in RTP packets. This also would substantially reduce the DSP power required by such a box and may even allow DTMF and one way voice decoding to be provided by the CPU.

A VoIP to AAL2 MGCP box would allow a service provider to deploy VoIP softswitch technology and still have the benefits of VoATM at the edge of the network. Such a box would also allow service providers, who have already deployed VoATM IADs, to keep the same hardware at the customer premise, but migrate to VoIP in the core. Such a network would also be lower in cost to deploy. Instead of distributing intelligence to each IAD unintelligent VoATM IADs could be used. All the intelligence would be in the VoIP to AAL2 MGCP box and softswitch where economies of scale on processing power can be achieved.