Browse Prior Art Database

Datagram Streaming for Improved Bearer Bandwidth

IP.com Disclosure Number: IPCOM000011645D
Original Publication Date: 2003-Mar-11
Included in the Prior Art Database: 2003-Mar-11
Document File: 4 page(s) / 83K

Publishing Venue

Motorola

Related People

Anand Alen: AUTHOR [+2]

Abstract

A recommendation is made to effectively utilize the bandwidth and processing power of high-level operating systems and networks by multiplexing standard voice over IP (VoIP) packets. This solution places packets for multiple calls into a single IP datagram and uses a unique call identifier to distinguish the packets for the individual calls.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

                                        � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � Technical Developments

Datagram Streaming for Improved Bearer Bandwidth� � �

by Anand Alen and Jack Gipson

ABSTRACT

A recommendation is made to effectively utilize the bandwidth and processing power of high-level operating systems and networks by multiplexing standard voice over IP (VoIP) packets.� This solution places packets for multiple calls into a single IP datagram and uses a unique call identifier to distinguish the packets for the individual calls.

PROBLEM SUMMARY

Many VoIP solutions use the Real-Time Transport Protocol (RTP) to transport data throughout the network.� The RTP specifies a unique IP/Port pair for each call. In order to support real-time voice, vocoders send between 11 and 50 packets per second. Depending on the vocoder, the payload of a voice packet is generally 20-40 bytes.� For each packet sent over RTP there are 54 header bytes, which produces an overhead (header data vs. payload data) of as much as 70%. All of these limitations are acceptable for an individual call but as the number of calls increases it can create serious problems. A Media Gateway, for example, might be required to support thousands of simultaneous calls. In this example, the Media Gateway would be required to support thousands of IP/Port pairs and process hundreds of thousands of packets per second. Many high-level operating systems such as UNIX are incapable of processing that many IP/Port pairs or the number of packets.� In addition, both the network and Media Gateway bandwidth may have to be increase because of the extremely high overhead of using RTP for VoIP.

.

PROPOSED SOLUTION

This recommendation describes a method to be used within the core network, which reduces overhead, system resources, and the number of destinations.� Lastly the proposal does this while introducing minimal latency.� In the figure above, a standard implementation of a core network using RTP is shown. In the core network there are several elements, which might be responsible for routing RTP packets such as a Media Gateway. For this example the generic term Network Element (NE) will be used. Each NE sets up an IP/Port endpoint with the other NE destinations.� For each call a call reference identifier (CRI) is created an added to every packet. The CRI could be added as part of the RTP header extension.� The NE would keep track of which CRI needs to be mapped to each MS “channel”.� A channel could be an RF or IP channel. The sending NE combines RTP packets from multiple calls that are destined to the same NE into a single datagram. The NE “packs” the packets into one datagram up to the physical transport MTU or until some configurable time. The NE� then sends the datagram to the destination NE. The receiving NE unpacks the...