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...