Asynchronous Data/Fax Testing
I came to Ericsson's TDMA software verification group as a contractor from Nortel where I contracted for the previous two years. My initial task within the TDMA verification group was to test the IS-130/IS-135 asynchronous Data/Fax protocol on an ANSI IS-136 TDMA handset.
The way the feature worked was that the phone was to be tethered to a PC/laptop. Dialup networking would be configured on the PC in order that terminal communication applications such as Hyperterminal, ProComm Plus and WinFax could access the computers serial port and use the cellphone as an external modem for sending and receiving asynchronous data and Group III Fax calls. So, the first thing I needed were requirements.
If you work long enough, you'll eventually find yourself on a problem project. It quickly became apparent there was no central repository for product requirements. I had to go throughout the building asking individual developers, testers and system engineers for requirements. When I did obtain copies, I never had much confidence the requirements were current. As best as I could determine, there was no single set of requirements that had been peer reviewed.
Because I was never able to determine all supported AT commands, the system engineer and I agreed that I should at minimum test those commands contained in the modem.inf file sent to Microsoft for plug-and-play certification.
A mobile switching center (MSC) in the building equipped with IS-130/135 would be used for testing. Rather than broadcasting over the air, coax fed the signals back and forth between the MSC and phone through a ceiling drop into my cube.
The cellphone's antenna was removed and an SMA antenna adapter plug was screwed in. The coax was then screwed into the antenna adapter. A tether cable connected the phone's system bus to the serial port on the computer.
I installed the modem.inf file in the PC, configured dialup networking, checked UART settings and after considerable effort managed to get the modem's attention but soon lost it. The product simply wasn't stable. Developers would say it worked fine for them and that I should try a different computer.
Eventually, I had about six different PC's, several laptops and was still unable to get anything to work reliably. diagnostic tools were poor, I had a serial port sniffer and a phone logger. Some of the phone's unreliability may have been due to the MSC but we had no way of knowing as the necessary diagnostic skills did not exist in the skeleton MSC support group.
The entire time I was testing the feature, there was no improvement in reliability and a certain attitude prevailed about the state of the feature. Considerable pressure was placed on me to "make progress" but I held my position that the product was unreliable.
Ultimately, the feature was cancelled and removed from the upcoming product release feature list. At the time, Ericsson held roughly a 25 percent market share in North America. Sales of several million of these handsets were projected in North and South America.
That the IS-130/IS-135 did not work reliably was not a great internal concern since it was widely believed none of the base stations would support it during the life of the phone. Perhaps one or two months after the decision was made to remove IS-130/IS-135 from the feature list, ATT announced accelerated deployment of IS-130/IS-135 in it's base stations. Had millions of those handsets been in the market advertised as supporting the feature, a major recall would have occured with untold consequences to the company.
