Super Technologies Library

1. If you call 1800 337 4194 and then enter any tollfree number, it will tell you which telephone company provides that number.

2. Use [http://www.telcodata.us|http://www.telcodata.us] to tell who owned the exchange originally however beyond that (to determine if the tn has been ported) requires a LERG subscription from telcordia

3. ARTICLE Integrated Voice and Data Broadband Network

By: Nathan Stratton [email protected]

INTRODUCTION

Today last-mile broadband networks are changing the world, DSL penetration in particular is offered to a majority of it’s residence in every major U.S. city . Today these networks are primarily used to transport data, if voice is needed it is provided by the public switched telephone network (PSTN). One would think that you would be able to provide voice over this broadband network and save the cost of a second overlay voice network. As we dig deeper we will find that there are some major challenges in building an integrated network.

DISCUSSION

Before we look at integrating voice and data we first need to understand what we are dealing with. Transporting voice as an analog signal is very inefficient and causes signal degradation for transmission over large distances when the signal is regenerated . If the analog voice signal is converted to a digital signal it can be regenerated without degradation.

The Nyquest theorem states that if you sample an analog signal at twice the rate of the highest frequency you can accurately reconstruct that signal. The highest voice frequency supported by the PSTN is about 4,000 Hz (400 – 3,200 for the people that want to know). If we apply the Nyquest theorem we need to sample the voice signal 8,000 times in one second. Each original analog signal sample is an 8 bit digital representation giving us a 64 kilobit per second (kbps) digital signal. The first thing we want to do with this digital voice signal is compress it. Several CODers/DECoders (CODEC) are available that can compress a voice signal to a fraction of its original size.

There are several factors that need to be looked at when choosing a CODEC. The obvious is the data rate, the lower the kbps the less bandwidth the voice signal will take on the broadband network. MIPS is the computing power required to compress the voice signal and is measured in million instructions per second. Frame size is the voice chunk the CODEC looks at and is measured in milliseconds (ms). PCM has a frame size of .125 ms or 1/8,000 of one second while G.723 has a much larger frame size of 30 ms. Mean opinion score (MOS) is a number between 1 and 5 that is giving to a voice sample. The higher the number the better the signal sounds, because it is hard to judge the quality of a sound, mean opinion scores are taken in large groups with each person judging with a number of 1 to 5. Look ahead is the amount of time in ms that the CODEC looks ahead of the current sample. This is used to see if there are any patterns in the voice signal that can be compressed into a single sample. The last is compression time; this is the amount of time the CODEC takes to compress the analog signal.

Some popular CODECs include:
CODEC kbps MIPS Frame MOS Look Compression
G.711 64 0.34 0.125 4.1 0 0.75
G.726 32 14 0.125 3.85 0 1
G.728 16 33 0.625 3.61 -2.5 3 5
G.729a 8 10.5 10 3.7 5 10
G.723.1 5.3 16 30 3.65 7.5 30

MIPS Processing power giving for Texas Instruments 54x DSP’s

Our fist choice may be to pick the lowest bit rate CODEC, after all why not use as little bandwidth as possible to transmit the voice signal? Lets start by looking at the MOS. Most people start to notice when the MOS drops below 4 and interfere with the conversation at about 3.7. If we look at G.723.1 we notice that it has a MOS of 3.9, most people would not notice this compression and it would not interfere with a normal conversation. The problem is the delay. G.723.1 has a 30 ms frame size; this is how G.723.1 is able to compress voice so much. The CODEC also has a 7.5 ms look ahead and a compression time of 30 ms giving us a 67.5 ms one way delay. If this was the only network delay source it may be acceptable, but the fact is CODEC delay is a small part of the end to end delay. A good overall CODEC is G.726; it has a good MOS, low delay and compresses the voice signal 50%.

Okay, now that we have an understanding of basic voice lets look at a basic network topology:

In this example we are using a DSL provider as the last mile broadband solution. The DSL subs are aggregated into an advanced services box that is connected to a core router and a VoIP gateway. When the user picks up the phone an IP stream is established between the IAD and the VoIP gateway using a predetermined CODEC, G.726 in this case, the call is then converted to PCM and handed off to the PSTN. Any IP packets that need to be routed over the Internet are handed off to the core router. This is all done via single PVC from the user IAD to the advanced services box. The link may add a 20 ms delay, the network 30, the CODEC around 15, bringing us way under the 150 ms one-way limit of a toll quality call.

The above may sound like a simple process, but in fact there are many things that need to be accounted for in building the above network. The biggest problem we face is the combining of voice and data traffic over single PVC. Let’s say the user is connected to the network with a 128K line and voice is provided using G.726. We learned earlier that G.726 produces a bit rate of 32 kbps and has a frame size of .125 ms. A single frame would only be 4 bytes and would give us a packet rate of 8000 packets every second, this is far too many packets to send on one IP stream so the number needs lowered without adding too much voice delay. Most G.726 implementations send a 10 ms voice packet, giving a packet size of 40 bytes.

Now take the 40-byte voice packet and add an IP header of 20 bytes, a UDP header of 8 bytes and a RTP header of 12 bytes, giving a total packet size of 80 bytes.

On 128K connections it will take 5 ms (80 bytes * 8 bits / 128,000) to transmit this packet down the link. So now there is 100 80-byte packets traveling across our link each taking up 5 ms.

If the user requests a web page while a voice call is in progress there will be a request for that data. If the user is using a standard MTU (Maximum Transmittal Unit) size of 1500 it is very possible that the network will try to send a 1500 byte packet. A 1500 byte packet will take 93.75 ms to transmit on a 128K link causing 10 of the smaller 80 byte voice packets to get jammed in the queue rather then being sent down the link. The dialed party would hear 100 ms of silence until the queued voice packets can be sent down the link.

One of the best ways to solve this problem is to setup a buffer so that there is always voice transmitted to the user, this is known as a jitter buffer.

When voice packets arrive they are sent into a buffer that can accommodate 10 packets (assuming we have setup a 100ms jitter buffer), every 10 ms a packet will move down the buffer. network congestion causes a packet to not arrive into the jitter buffer, the buffer will still be transmit the next buffered packet. This may continue until the buffer is empty. The buffer will fill up quickly after the network congestion as the queued packets are sent right after each other down the line.

A jitter buffer is a great way to deal with network delay, but it kills round trip times. The above example adds 100 ms to one-way delay leaving little for network and the CODEC overhead. To lower this number the amount of time a single packet can take on the link has to be limited. The best way to do this is to fragment large packets into many smaller chunks. We know that our voice packets take up 50% link bandwidth leaving 5 ms of bandwidth every 10 ms. The obvious solution may be to limit data packet size to something that will take only 5 ms (80 bytes) to send down the 128K link. The advanced services box would need to chop this 1500 byte packet into 25 60-byte packets (an IP header needs to be added to each fragment). One needs to be careful about fragmenting more then is required, fragmentation significantly increases the effective loss fate of network and decreases actual data throughput. If one fragment is lost the remaining fragments will still take up bandwidth and then will need to be discarded by the receiver.

Now comes the problem of queuing, even if large packets are chopped into much smaller pieces, all packet fragments will still be sent out together on a first in first out (FIFO) basis. We need to make sure that voice packets are queued with a higher priority then fragmented data packets. The priority queuing will take any queued voice packet and send it out, it will then move down the queues sending only one fragment at a time. If a new voice packet enters the queue, it would wait for only one data fragment from one of the lower queues to be sent before it will be sent. This will result in large lower priority packets being interleaved between voice packets.

Now that we have a method if sending voice and data traffic on the same link, lets look at ways to improve the process. The first thing that needs to be addressed is the overhead in sending the sampled voice, 40 bytes of headers are added to each 40-byte voice packet. In fact the overhead is much higher then 40 bytes taken by the IP, UDP and RTP headers. In the example ATM is used as the transport for DSL loops. ATM utilizes 53 byte fixed length cells, each cell has a 5-byte header and a 48-byte payload. To send IP packets over ATM a 5-byte AAL5 trailer is added to each packet. To find the overhead: take 80 bytes and put 48 bytes in the first cell leaving 32 bytes to place in the next cell, then add an 8 byte AAL5 trailer to the end of the last cell. Because ATM uses fixed length cells, the excess 8 bytes at the end is filled with padding. The new total bit rate is 53 bytes * 2 cells * 8 bits * 100 samples/s giving a total bit rate of 84.8 kbps.

The best way to lower this overhead is to find a way to compress the IP, UDP and RTP header in each voice packet. Compressed RTP or CRTP will allow the 40 byte headers to be compressed to 2 – 3 bytes. This can be accomplished because much of the header information is redundant or does not change from packet to packet. When large data packets are fragmented each fragment is required to have an IP header. Fragmenting packets to a very small size such as 40 bytes, the overhead becomes quite substantial. One way to limit that overhead is to use IP header compression on the link. This will allow the IP headers to be compressed to around 2 bytes; lowering the overhead substantially.

Using compressed RTP reduces overhead from 50% to 2.5%, the resulting packet is only 42 bytes long. If ATM is used as the underlying transport layer simply compressing the 40 bytes of IP/UDP/RTP header to 2 bytes will not help lower overhead because an 8 byte AAL5 trailer needs to be added.

The voice payload must be reduced so that it can fit in one ATM cell with the compressed RTP header and AAL5 trailer. If G.726 is used the frame size should be reduced 9.5 ms (38 bytes).

SUMMARY

In closing, it is possible to build integrated voice and data broadband networks today, but it is not as simple as placing a VoIP gateway on each end. Care must be taken to engineer the network so that other data packets sharing the link do not degrade voice quality. Vendors need to work on adding or enhancing hardware based queuing to their products and work to support protocols such as compressed RTP and IP header compression to lower the overhead required to transport voice. CODECs also need to be designed to allow variable frame sizes so they may be tuned to the underlying transport and network design.