Patent Publication Number: US-7899193-B2

Title: Time aligned group audio reproduction in narrowband and broadband networks

Description:
TECHNICAL FIELD 
     The present application relates to heterogeneous networks. In particular, the application relates to simultaneous reproduction of an audio signal in heterogeneous networks. 
     BACKGROUND 
     Group-directed communications are commonplace in enterprise and public safety communication systems. With regard to voice communications, one end device directs an audio stream to a given group (i.e. a “talkgroup”) of receiving end devices. These receiving end devices reproduce the audio stream through an amplified speaker. The manner in which the receiving end devices are used usually results in the reproduced sound being audible to people other than merely the intended recipient. Typically, the receiving end devices are often located near each other, causing their associated listeners to hear the same audio stream simultaneously reproduced by multiple end devices. This is particularly true in public safety uses, in which personnel often respond to incidents in a group and this group (or a subset thereof) may be located in the same local area for an extended period of time. 
     In order to ensure the audio stream is intelligible to the intended listeners in such an environment, it is desirable for collocated devices to reproduce the audio stream in a time synchronized fashion. In other words, all amplified speakers in the collocated devices should reproduce the same audio waveform at roughly the same instant in time. In general, a temporal offset of at most 30 ms between multiple audible speakers reproducing the same waveform is virtually undetectable to most listeners. Modern wireless voice communication systems achieve synchronized presentation of group-directed audio through an over-the-air simulcast of circuit-switched audio at multiple transmitting sites. Dense populations of collocated end devices thus receive the same over-the-air signal at roughly the same instant in time. 
     Such methods of synchronized presentation work well for the specialized homogeneous narrowband circuit-switched wireless radio networks typically used in the current generation of enterprise and public safety communication systems. However, the next generation of such communication systems is likely to span multiple narrowband circuit-switched and broadband packet-switched Radio Area Network (RAN) technologies with wholly different methods of synchronization. Example circuit-switched narrowband RAN technologies include 25 kHz, 12.5 kHz, or 6.25 kHz equivalent FDMA or TDMA air interfaces (e.g. Project 25, TETRA, DMR). Example packet-switched broadband RAN technologies include LTE, UMTS, EVDO, WiMAX, and WLAN air interfaces. Without a mechanism to synchronize media reproduction in a communication system comprised of heterogeneous RAN technologies, end devices connected to the circuit-switched narrowband RAN and end devices connected to the packet-switched broadband RAN would reproduce the same audio waveform in an autonomous fashion with respect to one another. This cacophony of misaligned sound results in unintelligible audio communication where multiple narrowband and broadband end devices are collocated. 
     Additionally, half-duplex group communication systems provide a mechanism to ensure equitable speaking rights on a given shared communication resource such as a channel or “talkgroup.” To provide this, the floor (i.e. the right to broadcast) is typically granted to the first device to make an appropriate request. During a half-duplex group conversation, listeners wait for the current audio stream to finish before initiating a new floor request. If the floor is granted to the first requester, it is desirable that all listeners be given the opportunity to request the floor at the same instant. This can be achieved if the preceding audio stream ends at the same time for all listeners. 
     In addition to potential intelligibility problems, without synchronized audio reproduction, the same audio stream will terminate at different times for listeners whose end devices are connected via different RAN technologies. Since floor control is typically granted to the first requester, end devices whose reproduced audio stream is lagging are not given equal rights for floor acquisition. Thus, it is desirable to provide a mechanism to synchronize audio reproduction across end devices operating on heterogeneous RANs. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Embodiments will now be described by way of example with reference to the accompanying drawings, in which: 
         FIG. 1  illustrates one embodiment of a system. 
         FIG. 2  illustrates another embodiment of a system. 
         FIG. 3  illustrates the calculated time delays in the embodiment of  FIG. 1 . 
         FIG. 4  illustrates the calculated time delays in the embodiment of  FIG. 2 . 
     
    
    
     DETAILED DESCRIPTION 
     Coordinated media (e.g. audio) reproduction across different communication networks, such as narrowband (hereinafter referred to as NB) simulcast and broadband (hereinafter referred to as BB) networks, is presented. 
     The presentation time of media to a heterogeneous group of end devices containing, for example, NB End Devices and BB End Devices, is time aligned such that an audio signal, for example, is reproduced at roughly the same time for all of the End Devices. This synchronization provides coherent group audio reproduction, which allows multiple listeners to hear the same audio signal from heterogeneous End Devices in the same physical vicinity without the interference caused by misaligned and overlapping audio streams. In addition, the synchronization ensures fair floor access in half-duplex communication systems as each listener is given the opportunity to attempt floor acquisition at the same time. 
     One embodiment of a group communication system containing multiple heterogeneous RAN technologies is depicted in  FIG. 1 . The embodiment of  FIG. 1  includes a NB simulcast RAN (hereinafter referred to as NB RAN  102 ), which could be, for example, part of a Project 25 compliant PTT system.  FIG. 1  also includes a BB RAN  103 , which could be, for example, part of an OMA PoC (Open Mobile Alliance Push-to-talk over Cellular) compliant PTT system. Integrated together, they form a single communication System  100 . Specifically, the System  100  shown in  FIG. 1  includes a NB/BB Controller  104 , a NB Time Source  110 , a BB Time Source  111 , NB Base Stations  120 , BB Base Stations  121 , NB End Devices  130 ,  132  and BB End Devices  133 . The NB/BB Controller  104  has the ability to independently delay a group-directed audio signal to the NB RAN  102  or BB RAN  103 , thereby accommodating the NB or BB End Device  132 ,  133  which exhibits a statistically significant, e.g. worst case, delay of an audio signal measured from the NB/BB Controller  104  to its reproduction in the NB or BB End Device  132 ,  133 . In practice, the delay of an audio signal from the NB/BB Controller  104  to its reproduction in BB End Devices  133 , only one of which is shown for convenience, is typically significantly longer with respect to the same audio signal transmitted to and reproduced by NB End Devices  132 . 
     Each of the NB and BB End Devices  130 ,  132 ,  133  is a user device that has a transmitter and receiver (not shown). Although mobile NB or BB End Devices are described, at least some of the NB or BB End Devices  130 ,  132 ,  133  may be geographically fixed. The NB or BB End Devices  130 ,  132 ,  133  communicate with other NB or BB End Devices  130 ,  132 ,  133  via an associated NB Base Station  120  or BB Base Station  121 , respectively, as well as other not depicted interconnections of the System  100  and associated functions including the NB/BB Controller  104 . Note that while only one intermediary (illustrated as a Base Station) is shown between each of the NB and BB End Devices  130 ,  132 ,  133  and the NB/BB Controller  104  for convenience, one or more intermediaries of different types may be inserted depending on the specific RAN technology deployed. Although NB Base Stations  120  or BB Base Stations  121  and other intermediaries may be mobile (handsets or vehicle mounted), such elements alternatively may be geographically fixed. Each of the NB and BB End Devices  130 ,  132 ,  133  also has a speaker (not shown) through which the End Device provides acoustic reproduction of audio to the user, in addition to other circuitry and input/output mechanisms. 
     The NB End Devices  130 ,  132  communicate through the NB RAN  102 . Examples of such NB End Devices  130 ,  132  include portable and mobile NB radios or any other End Device which connects, in a wireless fashion, to the NB RAN  102 . These NB End Devices  130 ,  132  are connected to the NB/BB Controller  104  via NB Base Stations  120 . Referring to  FIG. 1 , one of the NB End Devices  130  requests and is granted the floor (i.e. the right to speak on a given communication resource) from a floor controller (not shown) of System  100 . This NB End Device  130  transmits an audio stream (hereinafter referred to as NB 
     Uplink Audio Stream  140 ) to the NB/BB Controller  104  via the NB Base Station  120 . The other NB End Devices  132  receive the repeated audio stream (hereinafter referred to as NB Downlink Audio Stream  144 ) from the NB/BB Controller  104  via one or more NB Base Stations  120 . 
     The BB End Devices  133  communicate through the BB RAN  103 . Examples of such BB End Devices  133  include cell phones, PDAs, laptop computers, or any other End Device which connects, in a wired or wireless fashion, to the BB RAN. The BB End Devices  133  are connected to the NB/BB Controller  104  through BB Base Stations  121 . Only one BB End Device  133  and one BB Base Station  121  are shown in  FIG. 1  for clarity. The BB End Devices  133  receive the audio stream (hereinafter referred to as BB Downlink Audio Packets  145 ) from the NB/BB Controller  104  via BB Base Stations  121 . Although not illustrated in  FIG. 1 , BB End Devices  133  along with other components of System  100  not shown in  FIG. 1  (e.g. a wired voice dispatch console) are equally capable of requesting the floor and transmitting an audio stream to the NB/BB Controller  104 . 
     The NB/BB Controller  104  is a combined NB simulcast and BB controller that is responsible for duplicating and routing audio streams to all NB and BB End Devices  130 ,  132 ,  133  affiliated to the same logical group. The NB and BB End Devices  130 ,  132 ,  133  join a group, for example, by turning a physical knob on the device to select a particular logical “talkgroup” or “channel.” 
     In the NB RAN  102 , the NB/BB Controller  104  synchronizes a simulcast transmission of the NB Downlink Audio Stream  144  at the appropriate NB Base Stations  120  by specifying a transmission timestamp (hereinafter referred to as NB TransmissionTimestampN ) for each audio frame (hereinafter referred to as Audio FrameN ) contained in the NB Downlink Audio Stream  144 . NB TransmissionTimestampN  is expressed in values relative to a common clock reference (hereinafter referred to as NB Time Source  110 ) known to the NB/BB Controller  104  and the NB Base Stations  120 . The NB/BB Controller  104  and the NB Base Stations  120  contain very high precision, nanosecond-accurate, internal clocks (hereinafter referred to as NB Clocks  114 ) synchronized to a common NB Time Source  110 , e.g. the Global Positioning Satellite (GPS) system 1 PPS (Pulse Per Second), via NB Clock Signal  112 . When the NB/BB Controller  104  receives the NB Uplink Audio Stream  140  from one of the NB End Devices  130  via a NB Base Station  120 , the NB/BB Controller  104  repeats the series of received Audio FrameN s, along with an associated series of NB TransmissionTimestampN s, in NB Downlink Audio Stream  144  to the appropriate NB Base Stations  120 . Upon receiving NB Downlink Audio Stream  144 , the participating NB Base Stations  120  wait until their synchronized NB Clocks  114  are exactly equal to NB TransmissionTimestampN  specified for a given Audio FrameN . At that instant in time, the participating NB Base Stations  120  simultaneously repeat Audio FrameN  to all NB End Devices  132  affiliated to the group to which the audio stream is directed. 
     However, the combined NB/BB Controller  104  does not merely repeat the same NB Downlink Audio Stream  144  provided to NB Base Stations  120  to BB End Devices  133  (by way of BB Base Stations  121 ). One reason for this is that the timing and synchronization mechanisms used in the NB RAN  102  are typically quite different from those available in the BB RAN  103 . Although it is theoretically possible to extend the same time-stamped NB Downlink Audio Stream  144  to BB End Devices  133  if a similar timing mechanism (e.g. a very high precision GPS-locked clock) were disposed in the BB End Devices  133 , providing the BB End Devices  133  with such equipment may be impracticable at least due to cost, size, and location concerns. Additionally, the values of NB TransmissionTimestampN  present in NB Downlink Audio Stream  144  specify a transmission time for Audio FrameN . This transmission time is not inclusive of the time needed to process and acoustically reproduce Audio FrameN . Since the amount of time used to perform these functions likely differs amongst NB and BB End Devices, BB End Devices  133  do not possess enough information to synchronize their audio reproduction with that of NB End Devices  132 . 
     The NB/BB Controller  104  and the BB End Devices  133  shown in  FIG. 1  contain moderate precision, millisecond-accurate, internal clocks (hereinafter referred to as BB Clocks  115 ) locked to a common BB Time Source  111 , e.g. a time-of-day clock, via BB Clock Signal  113 . Unlike simulcast transmission, which is achieved using nanosecond-accurate timing mechanisms present in participating NB Base Stations  120 , time aligned reproduction of audio can be achieved using merely the millisecond-accurate timing mechanisms present in participating BB End Devices  133 . The NB/BB Controller  104  specifies a reproduction timestamp (hereinafter referred to as BB ReproductionTimestampN ) for one or more Audio FrameN (s) contained in BB Downlink Audio Packets  145  repeated to the appropriate BB End Devices  133  (i.e., the BB End Devices  133  that have selected the channel and joined the group to which the Audio FrameN (s) are transmitted). BB Downlink Audio Packets  145  are formatted, for example, using the Real-time Transport Protocol (RTP). BB ReproductionTimestampN s embedded in BB Downlink Audio Packets  145  are relative to the common BB Time Source  111  and inform the BB End Devices  133  as to the exact time the associated Audio FrameN  is to be acoustically reproduced. Upon receiving a BB Downlink Audio Packet  145 , the participating BB End Device  133  waits until their synchronized BB Clocks  115  are exactly equal to BB ReproductionTimestampN  specified for a given Audio FrameN . At that instant in time, the participating BB End Devices  133  simultaneously reproduce Audio FrameN . 
     The theoretical delay from the time at which NB/BB Controller  104  sends an audio signal until the time at which NB End Devices  132  reproduce that audio signal is calculated by a processor (not shown) in the NB/BB Controller  104  prior to the NB/BB Controller  104  receiving a NB Uplink Audio Stream  140 . Recall that NB Base Stations  120  and the NB/BB Controller  104  contain NB Clocks  114  synchronized to the same NB Time Source  110 . To measure the signal propagation delay from the NB/BB Controller  104  to each NB Base Station  120 , the NB/BB Controller  104  samples the value of NB Clock  114 , and sends a time-stamped message containing this value (hereinafter referred to as NB Time Measurement Packets  146 ) to each NB Base Station  120 . Upon receiving NB Time Measurement Packet  146 , a NB Base Station  120  subtracts the embedded timestamp from its NB Clock  114  to derive the one-way signal propagation delay (hereinafter referred to as NB PropagationDelayBaseSiteN ) between the NB/BB Controller  104  and the NB Base Station  120 . NB PropagationDelayBaseSiteN  is then sent back to the NB/BB Controller  104  where it is recorded in a memory (not shown). All such NB PropagationDelayBaseSiteN  measurements to each NB Base Station  120  are then compared and a statistically significant (e.g. worst case, 99% worst case, 95% worst case, 90% worst case) one-way propagation delay (hereinafter referred to as NB PropagationDelay ) from the NB/BB Controller  104  to all NB Base Stations  120  is recorded in the NB/BB Controller  104 . The wireless propagation delay between the NB Base Station  120  and the NB End Devices  132  is comparatively negligible. The statistically significant delay from the time an audio frame is sent from the NB/BB Controller  104  to the time the audio signal it contains is acoustically reproduced by the speaker in a NB End Device  132  is then calculated as:
 
 NB   ReproductionDelay   =NB   PropagationDelay   +NB   DeviceProcessingDelay  
 
     where NB DeviceProcessingDelay  is the known time to process (e.g., demodulate, error-correct, and decode) the audio signal in the NB End Devices  132 . NB DeviceProcessingDelay  is measured or estimated prior to the NB End Devices  132  being shipped and device-to-device variation is comparatively negligible. NB ReproductionDelay  may be periodically recalculated by NB/BB Controller  104 , which permits modification of NB ReproductionDelay  as participating NB Base Stations  120  are added to or removed from the NB RAN  102 . 
     Similarly, the theoretical delay from the time at which NB/BB Controller  104  sends an audio signal until the time at which BB End Devices  133  reproduce that audio signal is calculated by the processor in the NB/BB Controller  104  prior to it receiving NB Uplink Audio Stream  140 . Recall that BB End Devices  133  and the NB/BB Controller  104  contain BB Clocks  115  synchronized to the same BB Time Source  111 . To measure the signal propagation delay from the NB/BB Controller  104  to each BB End Device  133 , the NB/BB Controller  104  samples the value of BB Clock  115 , and sends a time-stamped message containing this value (hereinafter referred to as BB Time Measurement Packets  147 ) to a representative set, e.g. all, of the BB End Devices  133 . Upon receiving BB Time Measurement Packet  147 , the BB End Device  133  subtracts the embedded timestamp from its BB Clock  115  to derive the one-way signal propagation delay between the NB/BB Controller  104  and the BB End Device  133  (hereinafter referred to as BB PropagationDelayDeviceN ). All such BB PropagationDelayDeviceN  measurements are then compared and the statistically significant one-way propagation delay (hereinafter referred to as BB PropagationDelay ) from the NB/BB Controller  104  to the representative set of BB End Devices  133  is recorded in the NB/BB Controller  104 . The statistically significant delay from the time an audio frame is sent from the NB/BB Controller  104  to the time the audio signal it contains is acoustically reproduced by the speaker in the BB End Device  133  is then calculated as:
 
 BB   ReproductionDelay   =BB   PropagationDelay   +BB   DeviceProcessingDelay  
 
     where BB DeviceProcessingDelay  is the known time to process (e.g., demodulate, error-correct, de-jitter, and decode) audio packets in the BB End Devices  133 . Similar to NB DeviceProcessingDelay , BB DeviceProcessingDelay  is measured or estimated prior to BB End Device  133  being shipped and device-to-device variation is again comparatively negligible. As above, BB ReproductionDelay  may be periodically recalculated by NB/BB Controller  104 , which permits modification of BB ReproductionDelay  as participating BB End Devices  133  are added to or removed from the BB RAN  103 . A diagram of the time delays described above in relation to the embodiment of  FIG. 1  is shown in  FIG. 3 . 
     As above, the NB/BB Controller  104  specifies a NB TransmissionTimestampN  to NB Base Stations  120  and a BB ReproductionTimestampN  to BB End Devices  133  for each Audio FrameN  repeated. To facilitate this, the NB/BB Controller  104  calculates the delay from a starting time 0, in units of the NB Clock  114 , at which time the first Audio Frame0  is to be simulcast by NB Base Stations  120  (hereinafter referred to as NB TransmissionTimestampDelay ) and the delay from the same starting time 0, in units of the BB Clock  115 , at which time the first Audio Frame0  is to be reproduced by BB End Devices  133  (hereinafter referred to as BB ReproductionTimestampDelay ). In an ordinary NB RAN  102 , NB TransmissionTimestampDelay  is calculated by the NB/BB Controller  104  to be equal to NB PropagationDelay . Here, however, NB TransmissionTimestampDelay  and NB PropagationDelay  are calculated via the following algorithm:
 
IF BB ReproductionDelay* ≦NB ReproductionDelay  THEN:
 
 NB   TransmissionTimestampDelay   =NB   ReproductionDelay   −NB   DeviceProcessingDelay ;
 
AND
 
BB ReproductionTimestampDelay =NB ReproductionDelay* ;
 
ELSE IF BB ReproductionDelay* &gt;NB ReproductionDelay  THEN:
 
 NB   TransmissionTimestampDelay   =BB   ReproductionDelay*   −NB   DeviceProcessingDelay ;
 
AND
 
BB ReproductionTimestampDelay =BB ReproductionDelay ;
 
     where BB ReproductionDelay*  is BB ReproductionDelay  in units of NB Clock  114 , and NB ReproductionDelay*  is NB ReproductionDelay  in units of BB Clock  115 . This translation between clock units is possible, since NB/BB Controller  104  knows the respective frequencies (e.g. 1 kHz, 1 MHz, 1 GHz) and relationship (i.e. at a given instant in time, it can sample both clocks) of both NB Clock  114  and BB Clock  115 . 
     NB TransmissionTimestampDelay  and BB ReproductionTimestampDelay  may be stored on a per-group basis in a periodically-updated database in the NB/BB Controller  104 . This permits the NB/BB Controller  104  to adjust these values whenever a new NB or BB End Device  130 ,  132 ,  133  joins or leaves the group if the particular End Device statistically affects these calculated delay values in a significant way (e.g., greater than 1%, 2%, 5%, 10%, etc.). When a new End Device joins a particular group, the NB/BB Controller  104  determines its NB ReproductionDelay  or BB ReproductionDelay  and recalculates NB TransmissionTimestampDelay  or BB ReproductionTimestampDelay  if determined appropriate. Thus, although the System  100  may contain many End Devices, the NB/BB Controller  104  is able to adjust the NB TransmissionTimestampDelay  and BB ReproductionTimestampDelay  to account for only those End Devices that are to reproduce a given audio signal (e.g. that are present on the channel and joined to a particular group). In addition, if desired, the NB/BB Controller  104  can calculate and store delays on a per-End Device basis, instead of on a per-group basis. Doing so permits the NB/BB Controller  104  to, for example, reduce the delay of the audio signal to the reproducing End Devices if the transmitting End Device is also the End Device which exhibits the longest propagation delay. 
     When the first Audio Frame0  from NB Uplink Audio Stream  140  arrives at the NB/BB Controller  104 , the NB/BB Controller  104  immediately samples both the synchronized NB Clock  114  (hereinafter referred to as NB TimestampStart ) and the synchronized BB Clock  115  (hereinafter referred to as BB TimestampStart ). 
     Each Audio FrameN  in NB Downlink Audio Stream  144  contains a NB TransmissionTimestampN  which is calculated per the following algorithm:
 
 NB   TransmissionTimestampN   =NB   TimestampStart   +NB   TransmissionTimestampDelay +(Audio FrameTime   *N )
 
     where Audio FrameTime  is the duration of audio, specified in units of the NB Clock  114 , contained in each Audio FrameN  of the NB Downlink Audio Stream  144 . In the following example, each Audio FrameN  contains 180 milliseconds of audio (i.e. Audio FrameTime =180). It is understood that Audio FrameTime  could differ (e.g., 20 milliseconds, 60 milliseconds) based on the system configuration and types of RAN technologies employed. 
     For simplicity, assume that NB Clock  114  units are represented in units of milliseconds. Therefore:
 
 NB   TransmissionTimestamp0   =NB   TimestampStart   +NB   TransmissionTimestampDelay +(180*0)
 
This continues:
 
 NB   TransmissionTimestamp1   =NB   TimestampStart   +NB   TransmissionTimestampDelay +(180*1)
 
 NB   TransmissionTimestamp2   =NB   TimestampStart   +NB   TransmissionTimestampDelay +(180*2)
 
     The NB Base Stations  120  receiving NB Downlink Audio Stream  144  follow ordinary simulcast behavior, waiting until their NB Clocks  114  are equal to the specified NB TransmissionTimestampN  before transmitting the corresponding Audio FrameN  to NB End Devices  132 . 
     Each Audio FrameN  in BB Downlink Audio Packets  145  contains a BB ReproductionTimestampN  which is calculated per the following algorithm:
 
 BB   ReproductionTimestampN   =BB   TimestampStart   +BB   ReproductionTimestampDelay +(Audio FrameTime   *N )
 
     where Audio FrameTime  is the duration of audio, specified in units of the BB Clock  115 , contained in each Audio FrameN  of the BB Downlink Audio Packets  145 . 
     The BB End Devices  133  receiving BB Downlink Audio Packets  145  by way of BB Base Stations  121  wait until their BB Clocks  115  are equal to the BB ReproductionTimestampN  before acoustically reproducing the associated Audio FrameN . The BB End Devices  133  perform decryption and decompression to prepare the packet contents such that the audio waveform can be presented to the listener at the time indicated by BB ReproductionTimestampN . If, for whatever reason, the BB End Device  133  is late reproducing a particular Audio FrameN , it may employ techniques such as time compression to align with future BB ReproductionTimestamps  embedded in Downlink BB Audio Packets  145 . The term “late” may be set by an arbitrary threshold (hereinafter referred to as BB ReproductionThreshold ) of 180 milliseconds, for example. If BB ReproductionThreshold  is exceeded, the packet(s) may be skipped and audio reproduction may be started on time with subsequent packets. 
     Another embodiment of the heterogeneous communication system is shown in  FIG. 2 . This System  200  includes a NB Controller  204 , a BB Controller  205 , a NB Time Source  210 , a BB Time Source  211 , NB Base Stations  220 , BB Base Stations  221 , NB End Devices  230 ,  232 , and BB End Devices  233 . A common BB Time Source  211  is used to synchronize the BB Clock  215  in BB Controller  205  and BB End Device  233 . A common NB Time Source  210  is used to synchronize the NB Clock  214  in NB Controller  204 , BB Controller  205 , and NB Base Stations  220 . Although only NB End Device  230  is shown to request the floor and transmit audio, it is understood that BB End Devices  233  are equally capable of such behavior. In such cases, the audio stream from a BB End Device  233  is first forwarded to NB Controller  204  such that it may be processed in a manner similar to that of NB Uplink Audio Stream  240 . 
     In the embodiment of  FIG. 1 , a single NB/BB Controller  104  repeats NB Uplink Audio Stream  140  to both the NB and BB End Devices  132 ,  133  through NB and BB RANs  102 ,  103  respectively. In the embodiment of  FIG. 2 , however, a NB Controller  204  repeats NB Uplink Audio Stream  240  to the NB End Devices  232  through NB RAN  202  and a separate BB Controller  205  repeats NB Uplink Audio Stream  240  to the BB End Devices  233  through BB RAN  203 . In this embodiment, the NB Controller  204  treats the BB Controller  205  similar to another NB Base Station  220 . Thus, the NB Controller  204  repeats NB Uplink Audio Stream  240  as NB Downlink Audio Stream  244  to the BB Controller  205 . Doing so essentially permits an ordinary NB simulcast controller in NB RAN  202  to be used as the NB Controller  204 . The BB Controller  205 , upon receiving NB Downlink Audio Stream  244  from NB Controller  204 , reformats and repeats the audio stream as BB Downlink Audio Packets  245  to the BB End Devices  233  by way of BB Base Stations  221 . 
     Similar to the embodiment of  FIG. 1 , the BB Controller  205  periodically measures BB PropagationDelayDeviceN  from the BB Controller  205  to a representative set, e.g. all, of the BB End Devices  233  using the BB Time Measurement Packets  247 . As before, all such BB PropagationDelayDeviceN  measurements to each BB End Device  233  are then compared and a statistically significant (e.g. worst case, 99% worst case, 95% worst case, 90% worst case) one-way propagation delay from the BB Controller  205  to all BB End Devices  233  is recorded as BB PropagationDelay . The statistically significant delay from the time an audio frame is sent from the BB Controller  205  to the time the audio signal it contains is acoustically reproduced by the speaker in the BB End Device  233  is then calculated as:
 
 BB   ReproductionDelay   =BB   PropagationDelay   +BB   DeviceProcessingDelay  
 
     where BB DeviceProcessingDelay  is the known time to process (e.g., demodulate, error-correct, de-jitter, and decode) audio packets in the BB End Devices  233 . BB DeviceProcessingDelay  is measured or estimated prior to BB End Device  233  being shipped and device-to-device variation is again comparatively negligible. As in the embodiment of  FIG. 1 , BB ReproductionDelay  may be periodically recalculated by BB Controller  205 , which permits modification of BB ReproductionDelay  as participating BB End Devices  233  are added to or removed from the BB RAN  203 . 
     The NB Controller  204  periodically measures NB PropagationDelayBaseSiteN  from the NB Controller  204  to each NB Base Station  220  using the NB Time Measurement Packets  246 . In contrast to the embodiment of  FIG. 1 , however, the NB Controller  204  depicted in the embodiment of  FIG. 2  considers BB Controller  205  to be another NB Base Station  220 . As with all other NB Base Stations  220 , the NB Controller samples its NB Clock  214 , and sends a time-stamped message containing this value to BB Controller  205 . Upon receiving NB Time Measurement Packet  246 , BB Controller  205  subtracts the embedded timestamp from its NB Clock  214  to derive the one-way signal propagation delay (hereinafter referred to as NB PropagationDelayBBController ) between the NB Controller  204  and the BB Controller  205 . Unlike the operation of other NB Base Stations  220 , however, the BB Controller  205  does not merely return NB PropagationDelayBBcontroller  back to NB Controller  204 . Instead, BB Controller  205  calculates a new NB PropagationDelayBBcontroller†  per the following algorithm:
 
 NB   PropagationDelayBBController†   =NB   PropagationDelayBBcontroller   +BB   ReproductionDelay*   −NB   DeviceProcessingDelay ;
 
     where NB DeviceProcessingDelay  is the known time, in units of NB Clock  214 , to process (e.g., demodulate, error-correct, and decode) the audio signal in NB End Devices  232 . BB ReproductionDelay*  is the BB ReproductionDelay  in units of NB Clock  214 . Once NB PropagationDelayBBcontroller†  is calculated, BB Controller  205  returns this value to NB Controller  204  in a NB Time Measurement Packet  246 . 
     All NB PropagationDelayBasesiteN  measurements to each NB Base Station  220  along with NB PropagationDelayBBcontroller†  as calculated above are then compared and a statistically significant (e.g. worst case, 99% worst case, 95% worst case, 90% worst case) one-way propagation delay (hereinafter referred to as NB PropagationDelay ) from the NB Controller  204  to all NB Base Stations  220  and BB Controller  205  is recorded in the NB Controller  204 . The wireless propagation delay between the NB Base Station  220  and the NB End Devices  232  is comparatively negligible. The statistically significant delay from the time an audio frame is sent from the NB Controller  204  to the time the audio signal it contains is acoustically reproduced by the speaker in the NB End Device  232  is then calculated as:
 
 NB   ReproductionDelay   =NB   PropagationDelay   +NB   DeviceProcessingDelay  
 
     where NB DeviceProcessingDelay  is the known time to process (e.g., demodulate, error-correct, and decode) the audio signal in the NB End Devices  232 . NB DeviceProcessingDelay  is measured or estimated prior to the NB End Devices  232  being shipped and device-to-device variation is again comparatively negligible. Unlike the embodiment of  FIG. 1 , NB ReproductionDelay  is also inclusive of the NB PropagationDelayBBcontroller†  as reported by BB Controller  205  (which is itself inclusive of BB ReproductionDelay ). In this way, a NB Downlink Audio Stream  244  simulcast by NB Base Stations  220  may be delayed to ensure acoustic alignment of NB End Devices  232  to BB End Devices  233 . NB ReproductionDelay  may be periodically recalculated by NB Controller  204 , which permits modification of NB ReproductionDelay  as participating NB Base Stations  220  or BB End Devices  233  are added to or removed from the System  200 . A diagram of the time delays described above in relation to the embodiment of  FIG. 2  is shown in  FIG. 4 . 
     As in the embodiment of  FIG. 1 , the NB Controller  204  provides a NB TransmissionTimestampN  to NB Base Stations  220  for each Audio FrameN  embedded in NB Downlink Audio Stream  244 . To facilitate this, NB Controller  204  calculates NB TransmissionTimestampDelay  which represents the delay from a starting time 0, in units of the NB Clock  214 , at which the first Audio Frame0  is to be simulcast to NB Base Stations  220  and BB Controller  205 . As in an ordinary NB RAN  202 , NB Controller  204  assigns NB TransmissionTimestampDelay  as follows:
 
NB TransmissionTimestampDelay =NB PropagationDelay  
 
     Similar to the embodiment of  FIG. 1 , NB End Device  230  transmits NB Uplink Audio Stream  240  to NB Controller  204  through a NB Base Station  220 . When the first Audio Frame0  from NB Uplink Audio Stream  240  arrives at the NB Controller  204 , the NB Controller  204  immediately samples the synchronized NB Clock  214  (hereinafter referred to as NB TimestampStart ). 
     Each Audio FrameN  in NB Downlink Audio Stream  244  will contain a NB TransmissionTimestampN  which is calculated per the following algorithm:
 
 NB   TransmissionTimestampN   =NB   TimestampStart   +NB   TransmissionTimestampDelay +(Audio FrameTime   *N )
 
     where Audio FrameTime  is the duration of audio, specified in units of the NB Clock  214 , contained in each Audio FrameN  of the NB Downlink Audio Stream  244 . 
     The NB Base Stations  220  receiving NB Downlink Audio Stream  244  follow ordinary simulcast behavior, waiting until their NB Clocks  214  are equal to the NB TransmissionTimestampN  before broadcasting Audio FrameN  to NB End Devices  232 . 
     The BB Controller  205  also receives NB Downlink Audio Stream  244  with embedded NB TransmissionTimestampN s for each Audio FrameN . As in the embodiment of  FIG. 1 , BB Controller  205  provides a BB ReproductionTimestampN  to BB End Devices  233  for each Audio FrameN  in BB Downlink Audio Packets  245 . The BB Controller  205  calculates BB ReproductionTimestampN  for each Audio FrameN  received in NB Downlink Audio Stream  244  as follows:
 
 BB   ReproductionTimestampN   =NB   TransmissionTimestampN   *+NB   DeviceProcessingDelay*  
 
     where NB TransmissionTimestampN*  is the received NB TransmissionTimestampN  in units of BB Clock  215 , and NB DeviceProcessingDelay*  is the NB DeviceProcessingDelay  in units of BB Clock  215 . This translation between clock units is possible, since BB Controller  205  knows the respective frequencies (e.g. 1 kHz, 1 MHz, 1 GHz) and relationship (i.e. at a given instant in time, it can sample both clocks) of both NB Clock  214  and BB Clock  215 . As in the embodiment of  FIG. 1 , NB DeviceProcessingDelay  is measured or estimated prior to the NB End Devices  232  being shipped and device-to-device variation is again comparatively negligible. 
     The BB End Devices  233  receiving BB Downlink Audio Packets  245  by way of BB Base Stations  221  wait until their BB Clocks  215  are equal to the BB ReproductionTimestampN  before acoustically reproducing Audio FrameN . The BB End Devices  233  perform decryption and decompression to prepare the packet contents such that the audio waveform can be presented to the listener at the time indicated by BB ReproductionTimestampN . 
     In the case of either of the two embodiments presented, certain rare conditions may lead to excessively long measured values of NB PropagationDelayBasesiteN  and BB PropagationDelayDeviceN . In such cases, these values are not representative of the vast majority of similarly measured delays. The NB and/or BB Controllers can take this into account by discarding those delays that are in a preset percentile of the longest delays measured (e.g. &gt;95%, &gt;98%, &gt;99%). This measurement is calculated by ordering all of the NB PropagationDelayBasesiteN  measurement values into an ordered set from minimum to maximum value. If, for example, the worst 90% NB PropagationDelayBasesiteN  measurement value is to be selected, the value in that ordered set whose index is 0.9 times the number of values in the set is chosen. If, for example, the worst 95% NB PropagationDelayBasesiteN  measurement value is to be selected, the value in that ordered set whose index is 0.95 times the number of values in the set is chosen. This same method can be applied to the measured BB PropagationDelayDeviceN  values. Note any other statistical measure (e.g. time delays greater than two or three standard deviations from the mean delay time) can alternatively be used. This measure provides a method of filtering out the extreme delay cases from greatly increasing the overall audio reproduction delay experienced by all of the End Devices affiliated to a given group at the possible understood cost of occasional overlapping audio and/or floor acquisition difficulty. 
     Although audio signals have been discussed, media signals other than solely audio signals (e.g. text, device control, video) can also be coordinated using the above technique. In addition, although only NB simulcast and BB RANs were described above, any set of heterogeneous networks which utilize similar timing mechanisms can be used. The above term “audio signal” is intended to encompass signals communicated between the various components in the network that contain audio information to reproduce the original audio signal sent from the originating End Device to the reproducing End Devices (e.g. compressed or encrypted signals that are based on, but are not exactly, the original audio signal). 
     The techniques shown in  FIGS. 1 and 2  coordinate audio or other media reproduction across heterogeneous communication systems. By synchronizing the presentation time of audio to a group, collocated end devices all present audio at roughly the same time, providing coherent reproduction of the original audio. Thus, multiple listeners hear the same audio from multiple end devices simultaneously and fair access to a given floor in half-duplex communication systems is provided as each listener is given the opportunity to attempt floor acquisition at about the same instant in time. Either embodiment contains the ability to delay audio to each RAN of the heterogeneous system independently, thereby accommodating End Devices that have significantly longer transmission-to-reproduction delays. 
     It will be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein. Relational terms such as first and second and the like may be used solely to distinguish one entity or action from another without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “a” or “an” does not, without further constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element. 
     Those skilled in the art will recognize that a wide variety of modifications, alterations, and combinations can be made with respect to the above described embodiments without departing from the spirit and scope of the invention defined by the claims, and that such modifications, alterations, and combinations are to be viewed as being within the scope of the inventive concept. Thus, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present invention. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by any claims issuing from this application and all equivalents of those issued claims. 
     The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.