Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

IMPROVED BUSY QUEUE RESOURCE ALLOCATION

IP.com Disclosure Number: IPCOM000008667D
Original Publication Date: 1998-Jun-01
Included in the Prior Art Database: 2002-Jul-02
Document File: 5 page(s) / 263K

Publishing Venue

Motorola

Related People

Patrick J. Keegan: AUTHOR [+3]

Abstract

The Access Controller Gateway (ACG) in the iDEN system contains a unique paradigm called a Busy Queue, which will be referred to from here on as "the queue" or "the busy queue".

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

Page 1 of 5

0 M

MO7OROLA Technicul Developnzents

IMPROVED BUSY QUEUE RESOURCE ALLOCATION

by Patrick J. Keegan, Matthew W. Simpson and Chris Griffin

INTRODUCTION

  The Access Controller Gateway (ACG) in the iDEN system contains a unique paradigm called a Busy Queue, which will be referred to from here on as "the queue" or "the busy queue".

  The Cell Resource Manager (CRM) task within the ACG is responsible for allocating resources in the form of logical channels when such resources are requested for the use of telephone interconnect or dispatch voice traffic.

  There are basically three types of logical channel resources that can be used for telephone or dispatch related services in the iDEN system. These Channels are referred to as interleave 3: I channels, interleave 6: I channels and interleave 12: 1 channels. These logical channel types will be further defined in succeeding sections. For now, it will suffice to say that only requests for 3: 1 or 6: I channels can be placed into the CRM's busy queue.

  If configured to do so, the CRM may place a request for a logical channel resource into the queue, a sort of holding pen for requests, if that request cannot be allocated a resource. Requests may be queued as a result of RF constraints, such as all the logical channels in a site are occupied for dispatch or telephone interconnect trafftc.

  Once a request has been queued, it will remain in the queue until resources are freed. Once resources are freed, these logical channels can be used to service resource requests that have been waiting in the queue.

  The Busy Queue is unique in that it is not a single threaded queue. Rather the CRM's Busy Queue is a priority-based, First-In, First-Out (FIFO) queue. As a result requests are stored tirst on their basis of priority. If there are multiple queued requests of the

same priority, then they are stored in FIFO order.

  When 3: I, 6: I or 12: I logical channel resources being used in the system become available (freed) as a result of call termination, the CRM attempts to service the highest priority request in the busy queue with the released resource.

  If it is not possible to use the freed resource to satisfy the highest priority queued request (e.g a 3:1 request is the highest priority, but only a 6:1 resource was freed), a different algorithm is then employed to find the highest priority request that is able to make use of the freed resource. If no request can be serviced with the freed resource, the resource is returned to the pool of available resources.

  As releasing resources is mostly a random process, it is acceptable to employ an algorithm that follows a "release-and-immediate-allocate" scheme. From the description above, we indicate that each time a resource is freed, we attempt to allocate it to a request in the queue.

  However, the question arises as to what should occur if large amounts of resources are freed at approxtmately the same time.

RELEASING MULTIPLE RESOURCES

  Currently, large amounts of resou...