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

Adjustable talk permit tone to account for links with varying latencies

IP.com Disclosure Number: IPCOM000205319D
Original Publication Date: 2011-Mar-27
Included in the Prior Art Database: 2011-Mar-27
Document File: 3 page(s) / 433K

Publishing Venue

Motorola

Related People

Zollner, Mark: INVENTOR [+3]

Abstract

In summary, the new idea is to adjust the duration of the talk permit tone so that ample time is given for the multicast tree to be set up. Since the user would start speaking after the talk permit tone has been played out the multicast tree would have been guaranteed to be set up and there would be no late join issues. To implement this idea, the call controller must maintain the link latencies to the all of the sites. As mentioned previously, this technique has been previously disclosed and is well understood. Upon receiving a call request, the call controller determines the link latency of each site that will be involved in the call. Assume there two sites in the call with latencies L1 and L2 where L1 is the sourcing site latency and L2 is the destination site latency. If L1 is much less than L2 a potential late join issue is possible. The call controller will indicate in the grant that the talk permit tone duration needs to be increased thereby preventing the user at the sourcing device from speaking too soon and truncating speech. Note that L1 has to be less than L2 by some constant. This constant includes over the air serialization, infrastructure delays, etc. This constant is easily determined via analysis from either test data or simulation. For an example of this see pg 203-214 of the Astro 7.5 system planner here: http://compass.mot.com/doc/275076764/A75_System_Planner.pdf where many of these constants have already been determined. The indication in the grant for extending the talk permit tone duration will be described separately for the console and the subscriber. Info regarding console Dispatch Consoles currently launch audio at a predetermined time that can be configured for all calls where audio is sourced from the Console. The configuration is done from the Network Management subsystem. The talk permit tone is currently not in any way derived from the audio launch time, but is a set duration. The controller can convey the desired delay and talk permit time of the Console through the PTT grant message in a Motorola system. This could either be a time in milliseconds or a small enumerated selection of a few delay constants that would point to values that have been preconfigured in the Network Management subsystem. An example of this would be Low, Medium and High delay values which have been set to equate to 150, 200, and 250 milliseconds within the configuration parameters for the Console. Optimally the Console when granted would automatically play the talk permit tone up until the launch time minus the delay of the vocoder to start generating audio. This would optimize the point where the user could begin speaking while minimizing truncation and not allowing the tone being played through the speaker to be redirected into the microphone audio. Another option would be to pre-calculate the difference between the launch time and talk permit time and start the tone and the audio launch processes independently. Info regarding radio Motorola radios when configured to make a talk permit tone always make a tone of a fixed duration. As with the Console the new idea is to tell the subscriber to make talk permit tones of different durations per call if so desired. The controller would tell the subscriber via the group or individual call grant messages via the trunking control channel. In an APCO-25 radio system, either new Motorola specific grant messages can be introduced by asserting the Motorola reserved Manufacturer ID or by using reserved values within the standard messages. One possible implementation in standard messaging is to redefine the currently unused fields: - D bit: Not used. Set to %0. - M Bit: Not used. Set to %0. within the service option field of the grant to define enumerated values. In order to be backward compatible with existing messaging, the 00 value could select the standard talk permit duration while values of 01, 10, and 11 could define alternate Low, Medium, and High delay values which could be hardcoded or pre-configured within the subscriber.

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

Adjustable talk permit tone based on varying link latencies

By Mark Zollner, Gary Hunsberger, and Rob Sharpe

Motorola Solutions Inc.

Enterprise

Mobility Business

 

ABSTRACT

This article describes a method for dealing with RF site and Dispatch Console links which have varying and unbalanced latencies. Such links usually occur in Trunking Two-Way Radio Systems which utilize Ethernet transport for remote site backhaul.

PROBLEM

Setting up calls between unbalanced links can cause audio quality problems due to late joins. Late joins occur when audio from the sourcing RF site or console reaches the RP (Rendezvous Point) router before one or more destination RF sites or Dispatch Consoles have been able to send messages to be included in router multicast trees.

Late joins manifest themselves as truncated speech and audio holes at the beginning of the call. Secure calls are especially susceptible to this type of impairment.

.

SOLUTION

In summary, the new idea is to adjust the duration of the talk permit tone played by the transmitting device as feedback for the user wishing to transmit so that ample time is given for the multicast tree to be set up. Since the user would start speaking after the talk permit tone has been played out the multicast tree would have been guaranteed to be set up and there would be no late join issues.

OPERATION

To implement this idea, the call controller must maintain the link latencies to the all of the RF sites and Dispatch Consoles. This technique has been previously disclosed and is well understood.

Upon receiving a call request, the call controller determines the link latency of each site that will be involved in the call. Assume there two sites in the call with latencies L1 and L2 where L1 is the sourcing site latency and L2 is the destination site latency. If L1 is much less than L2 a potential late join issue is possible. The call controller will indicate in the call grant that the talk permit tone duration needs to be increased thereby preventing the user at the sourcing device from speaking too soon and truncating speech. Note that L1 has to be less than L2 by some constant. This constant includes over the air serialization, infrastructure delays, etc. This constant is easily determined via analysis from either test data or simulation. Figure 1 illustrates this example.

Figure 1

Dispatch Consoles currently launch audio at a predetermined time that can be configured for all calls where audio is sourced from the Console. The configuration is done from the Network Management subsystem. The talk permit tone is currently not in any way derived from the audio launch time, but is a set duration.

The controller can convey the desired delay and talk permit time of the Console through the PTT grant message in a Motorola syst...