Remote testing of EDACS trunking systems
Radio manufacturers have been building trunking systems for years, each system with its own unique methods and architectures. In an enhanced simulcast c onfiguration, Ericsson’s Enhanced Digital Access Communications System (EDACS) incorporates a remote-controlled, automated system capable of testing each channel in the trunking system. Channel equipment indicating a fault condition can be automatically disabled and alarm indications at a central location alert employees to technical problems.
Automated system testing The GETC (GE Trunking Card) is a unit developed by Ericsson to perform a variety of functions within a trunking environment, depending on its internal programming and strapping options. When used as a component of the automated test system, this unit can take the form of a TUAI (Test Unit Alarm Interface) GETC. The TUAI GETC, working in conjunction with a specially programmed trunked mobile radio called a test unit (TU), a separate radio dedicated to monitoring the outbound control channel data called a control channel monitor (CCM) and an alarm shelf create the subsystem that accomplishes the remote-end testing of each channel’s trunking functions at programmable intervals of one minute or longer.
Digital/analog testing When idle, the TU monitors the outbound control channel data, as any mobile unit in the system would. If, while monitoring, the TU notices problems regarding control channel sync, incorrect messaging or wrong Site ID, it will send the corresponding fault information to the TUAI GETC over a 19.2kbps serial data link.
The testing process begins when the site controller issues a special test call request on the outbound control channel.
The TU is the only radio in the system programmed to respond to a test call request. When the TU receives this request, it in turn requests a channel assignment (via an individual call). The site controller issues the channel assignment on the outbound control channel.
Once the TU receives this information, it informs the TUAI GETC (via the serial link) that the test process has begun. It lets the TUAI GETC know which channel is going to be used for the control and working channel. Equipped with this information, the TUAI GETC will be able to monitor its fault input lines from the proper radio channel.
The TU switches to the assigned working channel and listens for a high-speed (9600 baud) “dotting” signal to confirm that it landed on the proper RF channel. Once on the assigned working channel, the TU transmits a high-speed (HS) “keying” signal followed by constant low-speed (LS) data (150 baud).
The CCM also listens to the outbound control channel data. It outputs this received data onto the back-up serial link (BSL). The BSL is a 19.2kbps data buss that connects the GETCs of each RF channel together so each GETC knows what the others are doing. During a test call, the data from the CCM lets both the control and working channel GETCs involved in the test hear and respond to the test call request.
After receiving the TU’s “keying” signal and LS data, the assigned working channel under test transmits LS data followed by a high-speed “drop channel” (dotting) message.
At this point, the TU sends its test results to the TUAI GETC and reverts to the control channel to monitor for future instructions.
This process tests the TU, the working channel receiver and transmitter, and the control channel.
If the working channel under test doesn’t hear the proper HS or LS data from the TU, it sends a “fail” indication to the TUAI GETC. If the TU doesn’t see the proper HS and LS data from the working channel, it will also send a “fail” message to the TUAI GETC. In this manner, both directions are tested: TU-to-working channel and working channel-to-TU. Both the working channel and the TU send their test results to the TUAI GETC. However, they are delivered in a different manner.
The TU sends its results as an RS-232, 19.2kbps serial bit stream. The TUAI GETC decodes the data into hex bytes that not only offer “pass” or “fail” information but also details relating to what in the test failed. For example, the TU can tell the TUAI GETC whether or not it heard a channel assignment on the outbound control channel, or whether there was a HS or LS data signal transmitted from the working channel under test. The TU can also tell the TUAI GETC whether or not the working channel ended the test properly with a high-speed “drop channel” message, or whether there may be a synthesizer unlocked on the control channel or working channel.
The working channel GETC, on the other hand, merely uses a single wire car-rying either a TTL logic “high” or “low” to the TUAI GETC, offering only a “pass/fail” indication.
The CCM places the recovered outbound control channel data onto the BSL. This lets both the control channel and the working channel assigned to the test know when a test call request has been made. On receipt of this request, the normally “high” alarm line from the assigned working channel GETC goes “low.” It returns “high” in less than one second if the test passes. If the test fails, the alarm line remains “low” and a “fail” indicator light should be activated on both the assigned working channel GETC and the TUAI GETC.
If either the TU or the working channel GETC indicate a “fail” condition, the TUAI GETC sends the information along to the site alarm shelf as a “digital” alarm.
The alarm shelf’s internal 1200/2400 baud modem can relay the alarm information back to a central controlling location via master/slave polling. There, it can be viewed on an alarm PC by maintenance personnel and passed on to the site controller. The site controller can be set up to automatically remove the failed channel(s) from service.
In addition to automated testing of the trunking functions that offer “digital” alarms, each transmitter at the trunking site may be equipped with an in-line RF power sensor. This sensor produces a dc voltage proportional to the RF level coming from the transmitter’s PA. The voltage is applied to an input of an analog-to-digital converter card in the alarm shelf. These A/D cards convert the analog dc voltage to digital information that can be sent over the alarm shelf data modem back to a central location, resulting in the registration of “analog” alarms.
A detailed explanation of any EDACS configuration can quickly go beyond the scope of a magazine article. This description has been kept brief and basic but has offered an adequate glimpse into one of the features Ericsson employs within its simulcast EDACS trunking systems.
