A DUAL MODE TETRA COMMUNICATION APPARATUS

The present invention is particularly, but not exclusively, concerned with two-way wireless communication effected by communications devices. TETRA (Terrestrial Trunked RAdio) is an ETSI defined standard technology, reference EN 300 392-1, for private mobile communications. The TETRA standard provides both a trunked mode (TMO) for network based connections, and a direct mode (DMO) for peer to peer connections which may be used outside the network coverage area. For instance, a terminal being used by a user in a rescue operation could be unable to establish a link with a fixed base station in TMO, but could be able to establish a peer to peer (DMO) link with another TETRA enabled device at a nearby but safer location.

TETRA supports a range of security features, including authentication to the network, Air Interface (AI) encryption and End to End (EE) encryption of user traffic, each of which may be used in direct mode and in trunked mode. The AI encryption encrypts signalling traffic and user traffic between the mobile station (MS) and the TETRA Switching and Management Infrastructure (SwMI), and protects against eavesdropping and traffic analysis. However, the AI encryption does not apply within the SwMI. Static or dynamic AI key encryption may be used. The mobile station must securely store all relevant Air Interface Encryption (AIE) keys, and the key lifetime may be managed by OTAR (Over the Air Re-keying). For increased confidentiality of user data, End to End encryption (E2EE) may be used. E2EE is decodable only by end users with the correct algorithm and traffic key. End to End keys are controlled by the end user organisation, and are fully independent of the network provider. They may be managed using OTAK (Over the Air Key management).

There is a desire to integrate such DMO networking with wider networking by TMO, to enhance wider area communication between mixed nets.

It is known how to establish a gateway function as a relay between DMO and TMO in a TETRA system, by the ETSI-defined standard Gateway, reference EN 300 396-5. However, in such Gateway implementations, special radio protocols and dedicated radio equipment is required to establish such a capability. The present inventors have devised a method of providing a TETRA DMO-TMO interface using standard TETRA over the air protocols. The Vector Secure Communication System produced by Thales is an example of a hardware platform which exemplifies a prior art TETRA system, and also provides basis for an example of implementation of the present invention.

A first aspect of the invention provides a communications apparatus and an equivalent method, the apparatus comprising a first TETRA communications device, operable to establish a first communications link in an ETSI standard TETRA direct mode or trunked mode with a respective other device or devices; a second TETRA

communications device operable to establish a second communications link in an ETSI standard TETRA direct mode or trunked mode with a respective other device or devices; a data link connecting the first and second TETRA communications devices to transport TETRA user plane message data and control information between the first and second TETRA communications devices; and control means for operating the first and second TETRA communications devices to transport said user plane message data and control information between said first and second TETRA communications devices via the data link. The first and second communications devices may be TETRA radios, and in particular, they may be individual TETRA user terminals, such as handheld TETRA radios Alternatively, either or both of them may be non-TETRA bearers of TETRA U- plane traffic.

One of the TETRA radios may be configured to operate in direct mode (DMO), and the other in trunked mode (TMO), to provide gateway services from direct mode to trunked mode. However, this is not essential, and a further embodiment of the invention comprises DMO to DMO operation i.e. configuring both radios for DMO and repeating DMO calls on one DMO net into another DMO net. In embodiments of the invention, the following modes may be supported: DMO-DMO, DMO-TMO, TMO-TMO.

Alternative embodiments of the invention could use non-TETRA bearers to transport TETRA user data for one of the communications links. The controller may comprise machine readable code installed in the first or second radio. A user control unit or remote control unit may be provided, which is removably linkable to said first or second communications device via a wired or wireless link, and is configured to send control signals to said first or second communications device.

The controller may be configured to receive control signals via the first or second communication links, and to use these control signals for controlling operation of the first and second radios. Short data service (SDS) transported control messages may be used for remote control of the configuration and mode of the first and second radios, for unattended operation.

The first and second radios may be physically separated, and the local data link may be a low delay wired or wireless link, e.g. a serial data cable, or a Bluetooth connection. A single user interface may be provided for a user to operate both of the first and second radios, and the user interface may include controls for changing the transmit and receive parameters of the first and second radios as a pair. Simultaneous traffic monitoring on both the first and second radios may be enabled and simultaneous transmission on both radios may also be enabled.

The data and control information may include voice traffic, SDS (Short Data Service) messages and/or OTAK (Over the Air Key management) messages. The data and control information may include one or more of circuit mode data and IP mode data. It may include source and/or destination addressing information. The data and control information may also include end to end encrypted information, and the apparatus may be configured to transport said end to end encrypted information transparently, and/or to use EE (End to End) keys to decrypt the encrypted information. Such decryption may allow a local user to join in with encrypted communications between parties on different DMO and/or TMO networks. A data store may be provided for storing such end to end keys. Call priority data may be transferred across the local data link, to allow a priority of data and/or control information on one of the TMO or DMO networks to be used on the other of the TMO or DMO networks. A data buffer may be provided for storing data from one of the DMO or TMO networks to prevent data loss, while the other of the DMO or TMO networks is being set up or re-configured. Pre-emption information may also be transmitted from one of the TMO or DMO networks to the other, to allow preemption for transported data on the other of the TMO or DMO networks.

The following facilities may be supported: Voice group calls optionally with AI (Air Interface) encryption and/or EE (end to end) encryption, SDS (short data service) group & individual transmissions (optionally with AI and/or EE encryption) and OTAK (Over the Air Keyfill) . The controller may use local control or over-the-air remote control. The controller may also provide local monitor and local PTT capabilities,. One or both of the communication devices may be configured as a direct mode

Repeater, ref EN 300 396-4, for extending local area direct mode coverage. Multiple sets of TETRA radio apparatus, each configured according to an embodiment of the invention, may be configured for use as a network of DMO repeaters. This network may be configured, for example, as a linear chain or a linked mesh of repeaters, to increase the direct mode area coverage.

The invention also provides a TETRA communications device, operable to establish a first communications link in an ETSI standard TETRA direct mode or trunked mode with a respective other device or devices, the TETRA communications device comprising: a data interface for transmitting and receiving TETRA user plane message data and control information to and from a second TETRA communications device via a data link; the second TETRA communications device being operable to establish a second communications link in an ETSI standard direct mode or trunked mode with a respective other device or devices; and control means for operating the first and second TETRA communications devices to transport said TETRA user plane message data and control information between said first and second TETRA communications devices via the data link. The invention also provides a control unit for a TETRA communications apparatus, said apparatus comprising first and second TETRA communications devices connected by a data link, the control unit comprising: communication means for communicating with the first and second TETRA communications devices; network setup means for sending control data to the first TETRA communications device to cause the first TETRA communications device to establish a first communications link in an ETSI standard TETRA direct mode or trunked mode with a respective other device or devices, and for sending control data to the second TETRA communications device to cause the second TETRA communications device to establish a second communications link in an ETSI standard TETRA direct mode or trunked mode with a respective other device or devices; and control means for operating the first and second TETRA communications devices to transport user plane message data and control information between said first and second TETRA communications devices via said data link.

The method also provides a method at a TETRA communications apparatus comprising a first and second TETRA communications device connected by a data link, the method comprising: using said first TETRA communications device to establish a first communications link in an ETSI standard TETRA direct mode or trunked mode with a respective other device or devices; using said second TETRA communications device to establish a second communications link in an ETSI standard TETRA direct mode or trunked mode with a respective other device or devices; operating the first and second communication devices to transport TETRA user plane message data and control information between the first and second TETRA communications devices, using the data link.

The invention also provides a method of operating a TETRA communications device, operable to establish a first communications link in an ETSI standard TETRA direct mode or trunked mode with a respective other device or devices, the method

comprising: transmitting and receiving TETRA user plane message data and control information to and from a second TETRA communications device via a data link; the second TETRA communications device being operable to establish a second communications link in an ETSI standard direct mode or trunked mode with respective other device or devices; and operating the first and second TETRA communications devices to transport said TETRA user plane message data and control information between said first and second TETRA communications devices via the data link.

The invention also provides a method of operating a control unit for a TETRA communications apparatus comprising first and second TETRA communications devices connected by a data link, the method comprising: sending control data to the first TETRA communications device to cause the first TETRA communications device to cause the first TETRA communications device to establish a first communications link in an ETSI standard TETRA direct mode or trunked mode with a respective other device or devices, and for sending control data to the second TETRA communications device to cause the second TETRA communications device to establish a second communications link in an ETSI standard TETRA direct mode or trunked mode with a respective other device or devices; and operating the first and second TETRA communications devices to transport TETRA user plane message data and control information between said first and second TETRA communications devices via said data link.

A further aspect of the invention provides an interface for connecting two TETRA radios in a TETRA gateway configuration. The interface includes means for sending signalling information to the first TETRA radio to establish a first communications link in a direct mode or trunked mode with another TETRA device or devices, and to the second TETRA radio to establish a second communications link in a direct mode or trunked mode with a further TETRA device or devices. The interface also includes control means for operating the first and second radios to transport data and control information between said first and second TETRA communications links, via the local data link.

In some embodiments of the invention, a software package for the Thales Vector radio is used to implement a Dual Tetra Station Interface. The software package may be implemented as part of the main Vector software, such that all Vector radios will be capable of DTSI operation.

A DTSI apparatus according to an embodiment of the invention provides similar facilities to a DMO Gateway, ref EN 300 396-5 , with the following main differences:

• A DTSI uses two radios, whereas a Gateway is a single radio.

• Operation on the DMO talkgroup is un-affected by the use of a DTSI. With a standard Gateway in a DMO talkgroup, DMO operation is affected as all DMO calls must connect to the Gateway and are not allowed to proceed until a TMO link has been established. This gives additional delays in both directions.

• The DMO net timing is slaved to TMO timing by the Gateway. A DTSI uses independent timing on both nets.

• A DMO station which moves out of range of the Gateway cannot communicate with local DMO radios. With a DTSI, if a TMO link cannot be established immediately, all or part of the call will be lost into the TMO network, but the DMO call can proceed.

• A Gateway guarantees connections between the DMO and TMO nets whereas a DTSI provides a best-effort service.

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 is a schematic diagram of an apparatus according to a first embodiment of the invention;

Figure 2 is a schematic diagram of two TETRA networks linked by an apparatus according to an embodiment of the invention;

Figure 3 is a schematic diagram, showing an apparatus according to an embodiment of the invention, linking a DMO network to a TMO network; Figure 4 is a block diagram showing the internal structure of an apparatus according to an embodiment of the invention;

Figure 5 is a timing diagram, showing the DMO call to TMO call typical timing in an embodiment of the invention;

Figure 6 is a timing diagram, showing the TMO call to DMO call typical timing in an embodiment of the invention.

Figure 1 shows a Dual TETRA Station Interface (DTSI) according to an embodiment of the invention. A dual Vector radio configuration is used to allow communication between Tetra DMO and TMO nets. The DTSI includes a first radio 100 and a second radio 200 connected together by a link cable 300. The two radios 100, 200 may have their own Individual TETRA subscriber Identity (ITSI). Each radio 100, 200 may comprise standard TETRA mobile station hardware. In this example, the first TETRA radio 100 is used for TMO communications and the second TETRA radio 200 is used for DMO communications. However, in some embodiments, each radio may be used in either TMO mode or in DMO mode.

The first radio 100 and the second radio each have an antenna 105, 205, a data interface connector 101, 201 a user control interface connector 102, 202 and a data device connector 103, 203. A DTSI link cable 300 is connected between the data interface connector 101 of the first radio and the data interface connector 201 of the second radio. This DTSI link cable is preferably a serial data link, and allows data such as voice traffic, user data, SDS (Short Data Service) messages, OTAK (Over The Air Key management) messages and control information to be transferred in either direction between the first radio 100 and the second radio 200. The Intra-DTSI serial link cable connects the RS232 data lines to allow message transfer and also will allow the radio with the user interface to turn on and off the other radio. . In alternative embodiments, instead of a link cable being provided, a data link may be established by wireless means, e.g. Bluetooth. A control unit (CLU) or remote control unit (RCU) may be connected to the first 100 or second 200 radio to allow local control and operation of the DTSI. The CLU or RCU allows the operator full speed access to the primary operational DMO net. In this embodiment, a control unit (CLU) 310 is connected via a cable 320 to the controller interface connector 202 of the DMO radio 200, which will be the master of the pair of radios. In alternative embodiments of the invention, the DTSI radio pair may be controlled via a remote control unit (RCU) e.g. a wireless controller, or remotely from a dispatcher on the TMO, e.g. using SDS messages. In another embodiment of the invention, the DTSI radio pair may be controlled by an MMI integral to one of the radios. The use of only a single user controller in this embodiment prevents control conflict and audio phasing issues. In a further embodiment, the control unit may be connected to the TMO radio 100 instead of the DMO radio 200.

In this embodiment, the DTSI radio pair 100, 200 can be controlled via the control unit 310. The control unit 310 includes a keypad 312, a display 311 and a PTT (Push To Talk) control 313. The control unit 310 may allow powering on and off the DTSI radio pair, e.g. by turning on or off both radios whenever the DMO radio 200 is turned on or off. The control unit 310 may control the operation of both the first and the second radios, by sending appropriate control signals through the link cable 300 to the first radio 100. The control unit 310 may allow the talkgroup for each radio to be changed together (keeping both radios in step). It may also allow a user to monitor both TMO network and the DMO network simultaneously, and to transmit on both the TMO network and the DMO network simultaneously. The keypad 312 allows a user to change the mode, the channel, or any other relevant parameters on both of the first 100 and second 200 radios simultaneously, or on one of these radios individually. The display 311 may be configured to display information on channel, mode, etc, other user information or control information relating to one or both of the first and second radios, or to display text or data transmissions. The PTT control 313 allows a user to transmit on both the TMO network via the first radio 100, and the DMO network via the second radio 200. Transmission may be to either network or to both networks together.

Optionally, the first or second radio may be connected via the TETRA Peripheral Equipment Interface (PEI) to a data device, e.g. via a cable or a wireless link. In this example, the second radio 200 has a cable 204 connected to its data device connector 203, to provide a PEI connection. This allows the DTSI system to be connected to a data terminal such as a computer.

The DTSI may be designed for either or both of the following two modes of operation:

(i) Unattended, typically at a fixed site. In this scenario a remote control function is used, and there is typically no local End to End (EE) key material. Preferably, the control unit would be replaced by a Remote Control unit (RCU) when the DTSI is used in this mode, to prevent unwanted audio output.

(ii) Attended, typically in a vehicle. In this case the operator will be able to participate in the DMO net. Typically, the primary radio will be fitted with a TSM (TETRA Security Module) loaded with the correct EE keys, so that all traffic on the DMO net can be monitored via the CLU audio. Typically, the secondary radio will not be loaded with EE keys. A local PTT may then be used to transmit on the DMO net, and request a TMO transmission. Any local clash between mcoming TMO traffic and a local PTT will be dealt with by the TMO protocol. If the correct EE key for decryption of a received transmission is not present, the DTSI will still transmit the call through the DTSI, but will not allow local monitoring.

In some embodiments of the invention, the DTSI allows remote control of its function, for example from a dispatcher on the TMO network. This may allow remote changing of the DTSI talkgroup pair. This control may be implemented by SDS messages, e.g. dedicated SDS user type-4 messages with a proprietary PID, individually addressed to the TMO DTSI radio. The use of type-4 messages allows the possibility of EE encryption of messages to DTSIs containing EE key material The messages may be acknowledged by the DTSI on the original channel/mode before being actioned.

Changing DTSI talkgroup pair may be controlled either from the local user control or via remote control. Optionally, there may be lockout preventing local control when controlled remotely, or vice versa, and the most recent request may be actioned. Any local changes may not be reported back to the dispatcher. In this embodiment, because the DTSI uses independent timing on the TMO and DMO nets, there is no guarantee that one radio will not be transmitting when the other is trying to receive. This gives potential co-site performance limitations. These can be mitigated by:

• Frequency separation between the DMO band and the TMO band.

• Physical separation of the two antennas.

• Additional RF filtering between the two radios.

Preferably, the system is optimised for low delay, minimum set-up time voice operation with no impact on the primary DMO net being linked into. In most cases the performance of the system is controlled by the characteristics of the DMO net which is the 'primary' net in the system.

The DTSI system may be configured to provide some or all of the following facilities and services:

• Voice group calls on the current talkgroup within the TMO net are transmitted into DMO (with the true source address transferred).

• Voice group calls on the current talkgroup within the DMO net are transmitted into TMO (but the source address may be reported as the DTSI TMO radio). Late entered DMO voice group calls may be transmitted into TMO.

• Voice individual calls from DMO to TMO.

• Call pre-emption in the DMO net may be reflected into the TMO network.

• Call priority may be transferred through the DTSI. A dispatcher can break into the DMO net, by pre-empting the call in the TMO network, which in turn causes the DTSI to pre-empt the call in the DMO net.

• Group-addressed SDS messages on TMO may be transferred into DMO (with true source address transferred)

• Group-addressed SDS messages on DMO may be transferred into TMO (but the source address may be reported as the DTSI TMO radio)

• Individually-addressed SDS messages from DMO to TMO.

• End to End OTAK (Over the Air Key management) from a Key Management Centre (KMC) on the TMO network may be used for DMO terminals. Figure 2 shows a DTSI system according to an embodiment of the invention, operating within two separate TETRA networks, e.g. a DMO net and a TMO net. As in Figure 1, a first TETRA radio 100 is connected to a second TETRA radio 200 via a data link cable 300. A user MMI (Man Machine Interface) 330, including a set of headphones and a microphone, is shown connected to the second radio 200 via a cable 331. The first radio 100 has established communication links with two other radios 11, 12 within a first TETRA network, labelled TETRA Net 1. The two other radios 11, 12 in this first TETRA network have also established a communication link between themselves. The second radio 200 has established communication links with two other radios 21, 22 within a second TETRA network 20, labelled TETRA Net 2. The two other radios 21, 22 have also established a communication link between themselves.

To correspond to the embodiment of Figure 1, the TETRA Net 1 would be a TMO network, and the TETRA Net 2 would be a DMO network. However, in alternative embodiments, each TETRA Net may be either DMO or TMO or a non-TETRA bearer of TETRA user traffic. Thus, embodiments of the invention can include a DTSI for connecting two TMO networks, two DMO networks, or a TMO network and a DMO network.

Figure 3 shows a schematic diagram of a DTSI system according to an embodiment of the invention, used to link a TMO network with a DMO network. The DTSI comprises a DMO radio, labelled "DTSI-DMO", connected via a cable to a TMO radio, labelled "DTSI-TMO". The DMO radio is configured to communicate on the DMO network, and the TMO radio is configured to communicate on the TMO network.

The DMO network includes four additional radios, labelled "DM- A", "DM-B", "DM- C" and "DM-D". Each of these radios is configured to operate in standard TETRA direct mode. The TMO network includes a dispatcher, which may be used to monitor and control TETRA terminals over the network e.g. relaying information and coordinating operations, and a KMC (Key Management Centre) for management of End- to-End Encryption keys. The Dispatcher and KMC may each be implemented using a server connected to the network. The TMO network also includes two further TETRA mobile handsets, labelled as TM-A and TM-B.

Three separate talkgroups are defined in the set-up of figure 3. The first talkgroup, TGI, spans both the TMO network and the DMO network. It includes the DTSI, and mobile units TM-A and DM-A. The second talkgroup, TG2, is limited to the DMO network. It includes the mobile units DM-A, DM-B and DM-C. The third talkgroup, TG3, is limited to the TMO network. It includes the mobile units TM-A and TM-B. The mobile unit DM-D is not included in any of these talkgroups.

Voice calls from a TETRA terminal DM-A, within the DMO network, are summarised in Table 1 below.

Call Type DMO Net Call TMO Net call

(Source->Destination) (Source->Destination)

Group (DTSI-enabled DM-A -> TG1 DTSI-T -> TG1

talkgroup)

Group (not DTSI enabled DM-A -> TG2 None

talkgroup)

Broadcast (DTSI-enabled DM-A -> Open DTSI-T -> TG1

talkgroup)

Individual (within DMO) DM-A -> DM-C None

Individual (to DTSI) DM-A -> DTSI-D None

Table 1 - DMO Voice Calls

Voice calls from a TETRA terminal TM-A, within the TMO network, are summarised in Table 2 below.

Call Type TMO Net Call DMO Net call

(Source->Destination) (Source->Destination)

Group (DTSI-enabled) TM-A -> TG1 TM-A -> TG1

Group (not DTSI enabled) TM-A -> TG3 None

Individual (within TMO) TM-A -> TM-B None

Individual (to DTSI) TM-A -> DTSI-T None

Table 2 TMO Voice Calls The DTSI supports repeating group calls within the TMO into the DMO net but may not support individual calls. When the DTSI DMO and TMO radios are on a DTSI enabled talkgroup (TGI), the TMO DTSI makes a group attachment to TGI (on talkgroup selection). When a TMO radio (TM-A) makes a group call to TGI, it is received by the TMO DTSI radio pTSI-TMO) and the DMO DTSI radio also makes a group call transmission to the TGI. The call source address is not significant within a DMO network (it does not affect Al encryption), so it can use the originating TMO radio identity (TM-A) as the call source. This means that DMO radios will correctly know the real source of the call. If another call is in progress on the DMO RF channel and the TMO call does not have higher priority, voice traffic will not be transmitted into the DMO net.

When a DMO radio (DM-A) makes a group call to TGI, it is received by the DMO DTSI radio (DTSI-DMO) and the TMO DTSI radio also makes a group call

transmission to the TGI . The call source address is significant in a TMO network as the source terminal needs to be registered on the network, so the TMO DTSI has to use its own address as the call source. This means that TMO radios will not indicate the real source of the call. If there is a delay in being granted TMO transmit permission, some of the voice traffic may be lost if the DTSI voice buffer size is exceeded. Calls to the DMO open talkgroup (broadcast calls) are also repeated across the DTSI, when on a DTSI-enabled talkgroup. As TMO does not support the open address, the DTSI-T radio transmits them on the current talkgroup.

DMO individual calls are currently not supported through the DTSI for two reasons:

• The real call source address would not be visible, as the DTSI-T needs to

transmit with its own address as the source. The receiving radio does not know the address to which to reply.

• The DTSI does not know whether the called radio is on the TMO network or within the DMO net, and hence whether to repeat the transmission. It could repeat all calls, but individual calls with presence checking would fail as the DTSI-DMO would not acknowledge the call set-up. The SwMI does not have the addresses of the DMO radios registered, and therefore does not know to transmit the call in the cell containing the DTSI-TMO.

The traffic repeated from the TMO network to the DMO net via the DTSI link is summarised in Table 3.

In further embodiments, where the SwMI supports DM Gateway registration, the DTSI- TMO may register as a DM Gateway and report the addresses of the DMO radios. Individual calls may then be supported, although presence checking may not be provided for. Individual calls to the dispatcher or KMC may be of particular interest. The DTSI would need to know all the DMO radio addresses, either by being filled, or by listening to the source addresses of DMO transmissions.

In alternative embodiments, a U-plane (User-plane) stealing technique may be used to allow source address transfer, as the U-plane data is guaranteed to get through the DTSI and SwMI to the dispatcher terminal. Alternatively, stolen EE syncs may be modified to transfer source address information. Thus, further embodiments may allow for features such as individually-addressed calls in either direction, individually-addressed SDS messages in either direction, and full duplex PSTN voice calls.

Late-entry of the DTSI radios into a DMO call is supported; however, as the DTSI TMO radio will need to initiate call set-up, extra traffic may be lost during the delay. The DMO talkgroup may use channel reservation, and this is transparent to the TMO. The DTSI TMO radio transmissions are handled in the same way whether the DMO transmission is a call set-up or changeover, and there may be no indication to DTSI TMO radio when the reservation period expires. DMO presence-checking does not affect DTSI operation, as it only applies to individual calls. If a call on a DMO talkgroup is pre-empted by another DMO radio, the TMO transmission will be restarted. The TMO transmission may still indicate the same source address, as it always uses the DTSI TMO radio's address. If multiple talkgroups are using the same DMO RF channel, only calls on the talkgroup selected by the DTSI DMO radio will be transmitted into the TMO network.

Late entry of the DTSI radios into a TMO call is supported; on group attachment the SwMI signals the call status information, allowing both call and transmission late entry. No voice traffic will be lost unless DMO call set-up takes longer than the voice buffer size; this will typically only occur if pre-emption or changeover are required and the some attempts fail.

Figure 4 shows a block diagram of two TETRA radios connected in a DTSI system. The first radio 100 is configured to operate in a TMO network, and the second radio 200 is configured to operate in a DMO network. The first radio 100 and second radio 200 each include a Control processor 110, 210, a DSP (Digital Signal Processor) 120, 220 connected to the Control processor 110, 210, a transceiver (TCVR) 106, 206 connected to the DSP 120, 220, and an antenna 105, 205 connected to the transceiver 106, 206.

The Control processor 210 of the second radio 200 is connected to a control unit (CLU) 310, 330. The control unit includes a microphone and headphones 330 component, and a Man Machine Interface (MMI) control signal component 310 for generating and receiving control signals and user data. The control signal component 310 of the control unit is connected to a MMI component 211 of the Control processor 210, to allow suitable interchange of signals between the Control processor 210 and the control unit. The microphone and headphones component 330 of the control unit is connected to a voice coder (Vocoder) 315, which is connected to a TSM (TETRA Security Module) 316, which is in turn connected via link 320 to the DSP 220 of the second radio.

The TM protocol stack comprises a User Plane (U-Plane) for speech and circuit mode data, and a Control Plane (C-Plane) for call control, short data, supplementary services, mobility management and packet data. The User Plane data is processed by a Layer 2 MAC (Media Access Control), which sits on top of the Layer 1 Physical Layer. The Control Plane data is processed by a Layer 3 Mobile/Base link entity, and a layer 2 logical link control and MAC, which sits on top of the Layer 1 Physical Layer.

The DM protocol stack also comprises a User Plane and a Control Plane. The User Plane data is processed by a Layer 2 Data Link Layer, which sits on top of the Layer 1 Physical Layer. The Control Plane data is processed by a Layer 3 Direct Mode Call Control, which sits on top of the Layer 2 Data Link Layer, and the Layer 1 Physical Layer.

In figure 4, the DSP is configured to process data relating to layer 1 (physical layer, 221) and layer 2 (data link layer, 222) of the DM (direct mode) protocol stack. The transceiver is connected to the layer 1 section of the DSP. The physical layer processing is then carried out, and the resulting processed data is passed to the Layer 2 data link layer. After the layer 2 processing, user data (U-Plane) including the encoded audio data from the TSM module 316 is passed to a buffer 215 in the DTSI-D unit 214 of the Control processor 210, and control data (C-Plane) is passed to the DMCC (direct mode call control) unit 213 in the Control processor 210. The control data is processed by the DMCC 213, and then passed to the DMO user application 212. The DMO user application 212 passes local control data relating to the CLU 210 to the MMI module 211, where this data is suitably processed and passed to the CLU 210. The DMO user application 212 passes other control information, such as addresses, priorities, SDS messages, etc, to the DTSI-D unit 214. The DTSI-D unit 214 is connected to a UART (universal asynchronous receiver/transmitter) serial controller 216, which controls data transfer via the serial cable 300 between the second radio 200 and the first radio 100.

The structure of the first radio 100 is similar to that of the second radio 200, except that no CLU is connected to the first radio 100. The Control processor 110 of the first radio 100 has an input connector 102 for receiving a signal from a CLU, but no CLU is connected. The DSP 120 of the first radio is configured to process data relating to layer 1 (physical layer, 121) and layer 2 (the MAC (media access control) and logical link control layer, 122) of the TM (trunked mode) protocol stack. The transceiver is connected to the layer 1 section of the DSP. The physical layer processing is then carried out, and the resulting data is passed to layer 2. After the layer 2 processing, user data (U-Plane) is passed to a buffer 115 in the DTSI-T unit 114 of the Control processor 210, and control data (C-Plane) is passed to a TMO layer 3 unit 113 in the Control processor 210. The control data is processed by the TMO layer 3 unit 113, and then passed to the TMO user application 112. The TMO user application 112 passes control information, such as addresses, priorities, SDS messages, etc, to the DTSI-T unit 114. In this case, although the Control processor 110 is provided with a MMI module 111, it is not required, since no CLU is connected to the first radio. The DTSI-T unit 114 is connected to a UART (universal asynchronous receiver/transmitter) serial controller 116, which controls data transfer via the serial cable 300 between the first radio 100 and the second radio 200.

In local PTT operation, the DMO User Application configures the DMO Upper MAC (Media Access Control) to send traffic frames to the DTSI driver as well as transmit them over the air. The traffic flows for local monitor and local PTT are summarised in the table below. In all cases the Upper MAC handles routing the traffic, following configuration by the User Application.

DTSI-D Operation Tx Traffic Source Rx Traffic Destination Normal Tx Vocoder -

DTSI without Local Monitor DTSI

(Tx)

DTSI Local Monitor (Tx) DTSI Vocoder

DTSI Local PTT Vocoder DTSI

Normal Rx - Vocoder

DTSI without Local Monitor DTSI

(Rx)

DTSI Local Monitor (Rx) - Vocoder + DTSI

The radio database in the Thales Vector Radio is provided with DTSI controls to determine whether a tenninal is a DTSI and secondly to enable operation as a DTSI on specific talkgroups. The DTSI control may have three states: DTSI Enabled (Master), DTSI Enabled (Slave) and DTSI Disabled. Master/Slave indicates which radio is the DTSI Master, responsible for establishing and maintaining the serial link to the slave radio. No other DTSI configuration and control information needs to be included within the database. The new facilities required in the Upper MAC for DTSI are:

• Allowing U-plane routing to be specified by the User Application

• Support routing of traffic to & from DTSI instead of Vocoder.

• Support routing of traffic to & from both Vocoder & DTSI at the same time, including one route in transmit whilst the other is in receive.

Pre-emption across the DTSI may be supported. A call through a DTSI may use the priority of the incoming call rather than that programmed into the radio database.

Within TMO, there are two priorities: call priority (used within call set-up) and transmit demand priority (used for individual transmissions). In most cases the TMO transmit priority can be mapped to the DMO call priority, as both have four levels: low, high, preemptive and emergency pre-emptive.

If transmissions are received simultaneously on the TMO and DMO nets, the behaviour is determined by the relative priorities. If the priorities are equal, the two calls may proceed independently with no traffic passed across the DTSI interface. If the TMO transmission has higher priority then the DMO call will be pre-empted, and the DTSI DMO radio will set up a call passing the traffic from the TMO network. The reverse applies if the DMO call is higher priority than the TMO transmission.

If a dispatcher needs to be able to be able to break into existing DMO calls, it should be given a higher transmit priority than the call priority within the DMO net. Break-in will require pre-emption of the transmission within the TMO network, communication across the DTSI serial link and then pre-emption on the DMO net. This will take some noticeable time (DMO pre-emption takes a minimum of 280 ms), and to the operator at the dispatcher the call will be set-up once TMO pre-emption has taken place, but not DMO pre-emption. If DMO pre-emption and call set-up takes longer than the voice buffer size, voice traffic will be lost, with the oldest voice frames being discarded. For transmission of individually-addressed SDS messages (including OTAK

commands) to DMO radios, the SwMI will not have the DMO radio (DM- A) registered, so will not know to send the SDS message to the cell containing DTSI-T. Solutions may include:

(1) Modify the KMC to transmit these messages using the OTAK group address as the SDS destination, but with the individual address within the OTAK command. The TSM would have to ignore consistency checking between the SDS message and OTAK command source addresses.

(2) Register individual addresses with SwMI (gateway/multiple group attachments). In this embodiment, the DTSI uses option (1). Option (2) is an enhancement which requires the SwMI to support registration as a DM Gateway, and which is included in further embodiments of the invention.

EE OTAK uses type-4 SDS messages as its transport mechanism, and normally needs both group addressed and individually addressed messages. Most OTAK commands from the KMC (e.g. KEY LOAD, ACTIVATE_KEY & ASSOCIATION_SET) are usually group-addressed to the OTAK group address. However, some OTAK

commands from the KMC (e.g., STU _KILL & STATUS_ENQ) have to be addressed to an individual MS. The receiving radios will respond with individually addressed ACKs or NACKs, to the KMC.

Transmissions of individually-addressed SDS messages (OTAK ACKs) to the KMC from DMO may be received by the KMC, but the SDS source address will be DTSI- TMO rather than DM-A. However, the source address (SSI) is also contained within the encrypted part of the OTAK message. If the KMC ignores the consistency checking between the SDS source address and the OTAK source address, and uses the OTAK source address, it will correctly know which radios have responded to the OTAK commands.

Preferably, emergency group voice calls or SDS messages received on either net are transferred through the DTSI with emergency priority retained. In this embodiment, the source address is reported as the DTSI-TMO radio, rather than the true source.

However, further embodiments may include support for individually addressed emergency voice calls or SDS messages, by U-plane stealing or gateway registration.

Air Interface (AT) encryption works independently on the TMO and DMO links. AI OTAR (Over The Air Re-keying) is only available within TMO so the DMO radios (including DTSI-D) will either need to be physically loaded with AI keys or register with the TMO network when within coverage. There is no AI key transfer between the DTSI radios.

EE key material may be used to locally receive or send voice at the DTSI. The encryption key is only dependent on destination address, so the source address issues do not affect EE encryption. In some embodiments, the DTSI is transparent to EE encrypted voice and SDS traffic, and traffic is not decrypted at the DTSI. DTSI operation without EE key material may be used in unattended operation. EE OTAK (Over the Air Keyfill) may work through a DTSI using SDS messages which are transferred between DMO and TMO. The OTAK system of a standard TETRA terminal may require minor modifications to the Key Management Centre (KMC) and TETRA Security Module (TSM) software for operation through a DTSI. The User-plane traffic passing across the intra-DTSI serial link may comprise circuit mode voice TETRA frames and crypto synchronisation information transported in stolen frames. These frames correspond to the TETRA TMD-SAP/DMD-SAP and are transported in the same U-plane messages as used on the Upper MAC-TSM- Vocoder interface. The rules for stealing voice frames for crypto synchronisation are the same for TMO and DMO; this includes the permitted stolen frame rates and which frames can be stolen.

The DTSI may support repeating group-addressed SDS messages within a DMO net into the TMO infrastructure but does not, in this embodiment, support individually addressed messages. The source address will be that of the DTSI-TMO, for the same reasons as voice calls. Individually addressed messages could be transmitted

successfully by the DTSI-TMO, however, as the DTSI-TMO uses its own address as the source, the real source would not be reported to the recipient. Unlike EE OTAK messages, EE encrypted SDS messages do not include the source address in the EE header.

The DTSI supports transmission of TMO group-addressed SDS messages into the DMO net but does not, in this embodiment, support TMO individually addressed messages. The DTSI-DMO radio may transmit using the original TMO address as the source so real source address will be displayed to the recipient.

The DTSI uses appropriate AI encryption on both radio links with separate keys, as defined by the TETRA standards. The traffic passed between the DTSI radios will not be AI encrypted. The TMO network encryption and authentication processes prevent the DTSI TMO terminal transmitting with any address other than its own.

When operating in DTSI mode, on each call the receiving radio's User Application indicates to the Upper MAC the traffic routing required i.e. route to the DTSI driver rather than the Vocoder. The Upper MAC pushes received traffic across the serial link to the DTSI driver in the other radio, which contains the traffic buffer. The transmitting radio's User Application indicates to its Upper MAC the source of the traffic i.e. the DTSI driver rather than the Vocoder. Once the call is set-up by the transmitting radio, its Upper MAC pulls traffic frames from the DTSI driver, which reads them from the buffer.

The traffic buffer may store received traffic frames as U-plane messages. It needs to be large enough to store the voice frames received whilst the transmitting DTSI radio is setting up the call, such that no voice traffic is lost if there is no significantly extended delay in call set-up. This means it typically needs to buffer up to 2 or 3 seconds of voice frames,.

There is a minimum number of traffic frames required in the buffer at the start of a transmission, to allow for the difference between the rate at which voice frames are received and the rate they are requested by the Upper MAC. They are received at a constant rate (every 30 ms), but while the average pull rate is the same, it is not constant as the Upper MAC transmits 17 traffic slots, followed by a signalling slot. The minimum number of frames in the buffer at call start is 2 to 3, depending on the timing within the multiframe. If there are insufficient frames at call start-up, frames marked as bad (corrupted) are transmitted instead. The traffic buffer also needs to preserve half- slot position, as different stealing rules apply to each half-slot.

In local monitor operation audio is output on the DTSI-DMO radio, via the CLU. The DTSI-TMO radio is unaffected by local monitor operation. The DTSI-DMO radio operation depends on whether it is the DTSI-DMO or DTSI-TMO radio that is receiving. For DMO Radio Receive, the DMO User Application configures the DMO Upper MAC to send U-plane traffic frames to both the Vocoder (via the TSM) and the DTSI driver. The Upper MAC sends identical frames to each destination. For TMO Radio Receive, the DMO User Application configures the DMO Upper MAC to pull U- plane frames from the DTSI driver, as per a normal DTSI call. It also configures the DMO Upper MAC to send U-plane frames to the Vocoder. As the Upper MAC therefore controls the flow of frames to the Vocoder, the audio reflects the call on the DMO net rather than the TMO network. This means if the DMO call is delayed or aborted, the local audio is also delayed or aborted. There are two key timing parameters of interest for DTSI operation:

1. The delay from call set-up in one network to call set-up in the other network.

2. The delay between voice traffic received in the first network to the voice traffic being received in the second network.

Both these delays are made up of several components, including the time to transmit protocol syncs, the protocol processing delays and DTSI processing delays. Timing diagrams for typical call set-up cases for both DMO to TMO and TMO to DMO calls are shown in Figure 5 and Figure 6.

Figure 5 relates to a call received in DMO and repeated into TMO. The delay between call set-up transmissions in the two nets ("DTSI delay") is in the order of 150 ms in this embodiment, and is comprised of:

• DMO sync transmission delay: 1 time slot.

• Black DSP DMO processing (physical & MAC layers).

• Controller DMO processing (DMCC).

• Controller DTSI-D and DTSI-T processing, plus message transfer across the serial link.

• Controller TMO processing (network layer).

• Black DSP TMO processing (physical & MAC layers, including any random access delay)

The DTSI-dependent delay (DTSI-D and DTSI-T processing and message transfer) is typically 20 to 30 ms. The other delays are estimated to be about 9 slots (i.e. 125 ms), giving a total DTSI delay of about 150 ms. The additional DTSI voice delay is approximately 250 ms. This is comprised of the call set delay, plus the extra duration of TMO call set-up relative to DMO call set-up (about 6 slots) and the delay whilst the basestation retransmits the traffic (2 slots). Figure 6 relates to a call received in TMO and repeated into DMO. The delay between call set-up transmissions in the two nets ("DTSI delay") is also in the order of 150 ms in this embodiment. In the same way as for DMO to TMO calls, it is comprised of:

• TMO sync transmission delay: 1 time slot.

• Black DSP TMO processing (physical & MAC layers).

• Controller TMO processing (DMCC).

• Controller DTSI-D and DTSI-T processing, plus message transfer across the serial link.

• Controller DMO processing (network layer)

• . Black DSP DMO processing (physical & MAC layers, including any random access delay)

As with DMO to TMO calls, the DTSI-dependent delay (DTSI-D and DTSI-T processing and message transfer) is typically 20 to 30 ms. The other delays are estimated to be about 9 slots (i.e. 125 ms), giving a total DTSI delay of about 150 ms. The additional DTSI voice delay is approximately 210 ms. This is comprised of the call set delay, plus the extra duration of DMO call set-up relative to TMO call set-up (about 4 slots).

The present invention can be implemented in dedicated hardware, using a

programmable digital controller suitably programmed, or using a combination of hardware and software. The hardware may comprise personal radios, vehicle radios, or some other type of radio apparatus.

Alternatively, the present invention can be implemented by software or programmable computing apparatus. This includes any computer, including PDAs (personal digital assistants), mobile phones, etc. The code for each process in the methods according to the invention may be modular, or may be arranged in an alternative way to perform the same function. The methods and apparatus according to the invention are applicable to any computer with a network connection. Thus the present invention encompasses a carrier medium carrying machine readable instructions or computer code for controlling a programmable controller, computer or number of computers as the apparatus of the invention. The carrier medium can comprise any storage medium such as a floppy disk, CD ROM, DVD ROM, hard disk, magnetic tape, or programmable memory device, or a transient medium such as an electrical, optical, microwave, RF, electromagnetic, magnetic or acoustical signal. An example of such a signal is an encoded signal carrying a computer code over a communications network, e.g. a TCP/IP signal carrying computer code over an IP network such as the Internet, an intranet, or a local area network.

Although the above described embodiments relate to the Thales Vector Secure

Communication System, it is equally possible to implement the present invention using alternative hardware, in order to allow two TETRA radios or TETRA u-plane bearers to operate together as a TETRA gateway or repeater for unmodified standard TETRA- compliant terminals.

While the invention has been described in terms of what are at present its preferred embodiments, it will be apparent to those skilled in the art that various changes can be made to the preferred embodiments without departing from the scope of the invention, which is defined by the claims.