Browse Prior Art Database

SUBSCRIBER CONTROLLED CALL PRIORITY

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

Publishing Venue

Motorola

Related People

Brent Veltkamp: AUTHOR

Abstract

There are a limited number of resources (chan- nels) on a system. If all the channels are currently in use any received requests will be busied until channel resources are freed. If an emergency call is received the system needs to either busy the call or immediately preempt a current call. The problem is that the system is unaware of how important the active calls are.

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

MOTOROLA Technical Development5

SUBSCRIBER CONTROLLED CALL PRIORITY

by Brent Veltkamp

PROBLEM

  There are a limited number of resources (chan- nels) on a system. If all the channels are currently in use any received requests will be busied until channel resources are freed. If an emergency call is received the system needs to either busy the call or immediately preempt a current call. The problem is that the system is unaware of how important the active calls are.

  There is also a problem if a call is active and two (or more) subscriber units key up to transmit (assuming that different receivers are picking up the transmissions). For this condition the system needs to decide which subscriber unit's transmission will be repeated at all the sites. Currently, if subscriber unit A is transmitting and subscriber unit B needs to transmit, subscriber unit B is forced to wait for sub- scriber unit A to end its transmission.

SOLUTION

  These problems can be solved by allowing the SU to alter the priority of its request based on who the user of the SU is and what feature is currently active. Using such an approach will give the system better information about how important a request is when allocating resources.

IMPLEMENTATION

  If all the resources at a site are in use and a high priority call comes in, the system will look at the priority of the request and compare it against the

active calls on the system. If the received call is of a high priority (system definable) then the system will pre-empt the lowest priority active call. For resource allocation the priority level will be used at the FNE to queue the pending requests. Also for active calls, if two orEmore transmissions are received, the system will use the priority field to determine which transmission to repeat.

  The default priority level (RSS configurable), for each subscriber unit, will be adjusted based on the call type. Every call type will be given a priori- ty-offset to use. When the subscriber unit initiates a call, the priority it sends to the system will be (default_priority+priority_offset). This allows pref- erences to be given to dertain calls. An example would be Dynamic Regrouping, which could be set to force the transmittea priority to the highest defined priority, while Phone could be set to force the priority to the lowest available priority.

  Since the priority level is RSS configurable the default priority for supervisors can be set higher than that of normal users.~ This will allow a supervi- sor to cut of...