Browse Prior Art Database

Optimizing Dispatch (push to talk) Bearer Traffic

IP.com Disclosure Number: IPCOM000027963D
Original Publication Date: 2004-Apr-14
Included in the Prior Art Database: 2004-Apr-14
Document File: 4 page(s) / 32K

Publishing Venue

Motorola

Related People

Jeff Couts: AUTHOR [+4]

Abstract

The system architecture for providing dispatch (push to talk) services within a CDMA network includes a Dispatch Gateway which, among other things, receives bearer packets and forwards these packets to a peer Dispatch Gateway for delivery to the target Radio Access Network (RAN). This invention proposes ways to reduce network traffic and CPU processing by intelligent routing and translation of the bearer traffic

This text was extracted from a Microsoft Word document.
This is the abbreviated version, containing approximately 52% of the total text.

Title: Optimizing Dispatch (push to talk) Bearer Traffic

Authors: Jeff Couts, Herbert Calhoun, Jack Gipson, Ken Smelcer

Abstract

The system architecture for providing dispatch (push to talk) services within a CDMA network includes a Dispatch Gateway which, among other things, receives bearer packets and forwards these packets to a peer Dispatch Gateway for delivery to the target Radio Access Network (RAN). This invention proposes ways to reduce network traffic and CPU processing by intelligent routing and translation of the bearer traffic.

Introduction

When setting up a dispatch call, each call is broken into two ½ calls, the originating leg and the target leg. Each ½ call is handled independently of the other. In many cases the location of the originating MS and the target MS results in the use of the same Dispatch Gateway for both legs of the call. Ideally this would result in the ability to loop back all bearer traffic to reduce network traffic. The problem is that the Dispatch Gateway consists of many payload cards and each ½ call may be handled by any one of these payload cards. When the ½ calls are placed on different payload cards there is no way to loop back the bearer traffic which results in wasted network bandwidth.

Another problem with this scenario is the wasted processing done by the CPUs to process and translate the different protocol stacks. In a normal scenario the RAN sends the bearer packet to the Dispatch Gateway via an N8/GRE packet, this is translated into an I9/RTP/UDP packet and sent to the peer Dispatch Gateway who then translates the packet back into an N8/GRE packet for transmission to the target RAN. If both ½ calls are handled by the same payload card, this translation from GRE to UDP back to GRE is unnecessary and reduces the capacity of the Dispatch Gateway.

Summary of the Proposed Solution

The first problem to solve is how to make sure that both calls are assigned to the same payload card. This is done with the use of a binding table at each Dispatch Gateway. The binding table will contain a list of all the ½ calls currently in progress on the Dispatch Gateway along with which payload card was assigned to handle the bearer traffic for that ½ call. As SIP Invites are received by the Dispatch Gateway for the target leg, the Dispatch Gateway will first check to see if the originating leg is being handled by the same Dispatch Gateway, if this is the case the Dispatch Gateway will a...