Browse Prior Art Database

METHODS FOR TOKEN-BASED DISTRIBUTED ARBITRATION OF PUSH-TO-TALK

IP.com Disclosure Number: IPCOM000009233D
Original Publication Date: 1999-Jun-01
Included in the Prior Art Database: 2002-Aug-13
Document File: 2 page(s) / 135K

Publishing Venue

Motorola

Related People

Gregory Cox: AUTHOR [+3]

Abstract

In extending wireless dispatch voice services to Internetworking Protocol (IP) client devices (such asPC's), a means of arbitrating push-to-talk is required to assure that only one participant in a dis- patch call can transmit at any given time. This arbi- tration should not be specific to a wireless system or systems which may or may not be present in an IP network dispatch call. IP clients should be able to conduct dispatch conversations with an arbitrary mixture of other IP clients and clients on wireless systems without requiring the presence of a specific wireless system. This calls for a distributed, peer- to-peer means of push-to-talk arbitration.

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

Page 1 of 2

MOlOROLA Technical Developments

METHODS FOR TOKEN-BASED DISTRIBUTED ARBITRATION OF PUSH-TO-TALK

by Gregory Cox, Walter L. Johnson and Senaka Baltisuriya

BACKGROUND

  In extending wireless dispatch voice services to Internetworking Protocol (IP) client devices (such asPC's), a means of arbitrating push-to-talk is required to assure that only one participant in a dis- patch call can transmit at any given time. This arbi- tration should not be specific to a wireless system or systems which may or may not be present in an IP network dispatch call. IP clients should be able to conduct dispatch conversations with an arbitrary mixture of other IP clients and clients on wireless systems without requiring the presence of a specific wireless system. This calls for a distributed, peer- to-peer means of push-to-talk arbitration.

  This article describes two potential methods for token-based arbitration of push-to-talk for voice communication among a group of peer devices such as PCS.

l DEFINITIONS

  Gateway - the interface between a wireless sys- tem and the IP network which performs all neces- sary protocol translations and manages tokens on behalf of its users

Initiator - the fmt person in a dispatch session

to Press-To-Talk

  l Multicast - application-level act of sending a message to all members of a group (may translate into IP multicast, multi-unicast or broadcast depend- ing on underlying network layers)

  Receiver - Any member of a dispatch session except the initiator

  Participant - Any member of a dispatch conversation

  Session - a dispatch; group conversation from the initiator's first Press-To-Talk to the end of the hang time after the last Press-To-Talk

INITIATOR-GOVERNED METHOD

  l Initiator determine,s that no current session exists and then creates a session and a token and ini- tiates a session with a multicast to all receivers.

  l If an initiator detects the presence of another initiator in the same group (usually caused by near- simultaneous session initiation and detected by the receipt of another initiator's control messages), then the initiator must end its session. This is a "colli- sion". If both initiators end their sessions because of a collision, each initiator must wait a pseudo-ran- dom amount of time before attempting to initiate a session in that group again to prevent perpetual col- lision.

   Initiator multicasts "token available" message when token is freed.

  l Any receiver must obtain Press-To-Talk token from initiator before talking. A wireless system gateway must obtain the token on behalf of its sub- scriber units in order for&y of its subscriber units to be allowed to talk and Imust then arbitrate among the wireless subscriber units as needed.

A receiver must return token to initiator when

finished talking.

  l A receiver must send keep alive messages to initiator while it retains the token. Keep alive inter- val is Tk seconds. The initiator will assume that the token is lost if it does not receive a keep alive mes- sage wtt...