Browse Prior Art Database

PACKET DATA HALF-DUPLEX COLLISION AVOIDANCE

IP.com Disclosure Number: IPCOM000009308D
Original Publication Date: 1999-Jun-01
Included in the Prior Art Database: 2002-Aug-15
Document File: 3 page(s) / 125K

Publishing Venue

Motorola

Related People

Steven Charnota: AUTHOR [+3]

Abstract

The impact of a half-duplex subscriber unit on a distributed store-and-forward system architecture may go beyond those components that directly sup- port the RF interface. The failure of impacted FNE components to address the (perhaps indirect) effects of half-duplex collisions on the RF interface can adversely impact the system @NE) throughput.

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 50% of the total text.

Page 1 of 3

Developments Technical 0 M MOTOROLA

PACKET DATA HALF-DUPLEX ~

COLLISION AVOIDANCE

by Steven Charnota, David Hensley and Yan Zhang

BACKGROUND

  The impact of a half-duplex subscriber unit on a distributed store-and-forward system architecture may go beyond those components that directly sup- port the RF interface. The failure of impacted FNE components to address the (perhaps indirect) effects of half-duplex collisions on the RF interface can adversely impact the system @NE) throughput.

PROBLEM

  The FNE commits to sending outbound packet data to a half-duplex SU without information about whether that SU in currently transmitting inbound packet data. This half-duplex collision occurs within the FNE due to a distributed processing hardware architecture. In this architecture one device (e.g. an iDEN base radio) controls the RF interface and has queued requests from multiple SUs for inbound packet data transmission. Another device (e.g. the iDEN ACG) has queued requests from multiple store and forward devices (e.g. the iDEN MDG) for outbound packet data transmission. The SU stores inbound packet data waiting for transmission and the MDG stores outbound packet data waiting for transmission.

SOLUTION

  Each device that queues requests for access to the RF packet data channel (i.e. the ACG and BR) also stores the identifier of the SU associated with the channel request. In the iDEN system, the MDG would send the SU identifier (i.e. the TEI) in the SRP Channel Request message. When data transfer is in progress, the devices that queue channel requests (i.e. the ACG and BR) will indicate to each other the SU involved in the current data transfer and the SU (if known) that will be involved in the next data transfer. In the widen system, this would require adding TEIs to the Packet Outbound Data Request and to the Packet Inbound Data Indication messages on the ACG-BR interface. The "next SU" is identified only after its selection can not be revoked. In the iDEN system this occurs when the ACG sends an SRP channel grant to the MDG and when the BR starts sending a reservation response
(i.e. slot descriptor block type = $B) to the SU. The ACG will avoid granting the outbound channel, if possible, to an SU that is currently transmitting or that will be the next SU'to transmit. Likewise the BR will avoiding granting the inbound channel, if possible, to an SU that wi,ll be the next SU to which the outbound channel will be granted. Both the ACG and...