[Automatic translation by Google]
Please provide your feedback about the website at feedback@apc.iisc.ernet.in
The Centre for Development of Telematics (C-DOT), the Indian Institute of Science (IISc), and the Foundation for Science innovation and Development (FSID) signed a tripartite agreement on 30 July 2026 for setting up a C-DOT Centre of Excellence (CoE) at IISc. Quoting from a press release by the Press Information Bureau, “The CoE will serve as a dedicated hub for high-impact R&D in advance communication technologies, fostering joint academic–industry collaboration for a self-reliant and Viksit Bharat in the telecom sector”. The IISc CoE will be the fifth CoE established by C-DOT, the other four having been set up at the Indian Institute of Technology (IIT) Hyderabad, IIT Kanpur, IIT Gandhinagar, and IIT Roorkee.
C-DoT setting up their lab in IISc prompted Anurag Kumar (INSA Distinguished Professor, Department of Electrical Communication Engineering, IISc) to communicate with Venkat Rajendran, the key person involved in the software development of the C-DoT Main Automatic Exchange (MAX) back in 1988–89. In his reminiscences below, Venkat Rajendran talks about the C-DOT team’s year-long interactions during 1988–89 with Anurag Kumar’s team — industry meeting academia to solve a national problem. He writes about the problems they faced and the solutions they implemented based on the IISc team’s work.
When Academia Met Industry: Overload Control on the C-DOT Switch
By Venkat Rajendran
The development of C-DOT’s central office switches was a major milestone in India’s technology journey and a catalyst in transforming Indian telecom. In a large exchange, call processing is the essential real-time function. But the harder engineering challenge is keeping the switch reliable: it must be available >99.999% of the time (about five minutes of downtime a year) despite hardware faults, software defects, and environmental stress, including overload. The traditional telecom benchmark for a central office switch was just two hours of downtime in forty years, roughly three minutes a year.
Overload control in a distributed processing system is a fascinating problem. Under heavy call load, both processor time and the internal message queues, which consume memory, come under severe strain.
Telephone traffic is far from uniform. It follows daily rhythms (the weekday morning peak runs from about 9:30 to 11:00 AM, with the sharpest surge near 10:30) and is also hit by seasons and sudden events. On the day Mrs Indira Gandhi was assassinated, almost everyone in Delhi tried to call someone at the same moment. The exchanges of that era were electromechanical, with a little electronics, and their overload controls were primitive or non-existent. They could not cope, and the telephone network in Delhi effectively collapsed. Failed attempts were retried, which made the overload worse. The episode showed how a single, occasional surge can bring down a switch that has no overload control. A modern switch must be designed to survive exactly that.
A switch is engineered for a customer-specified busy-hour load. Dimensioning it for the rarest, shortest peaks would make it grossly over-engineered and prohibitively expensive. The right answer is ‘graceful degradation’: when demand exceeds capacity, the switch keeps completing as many calls as it can instead of collapsing. That is the job of overload control.
C-DOT tackled this problem together with the Indian Institute of Science, notably Dr Anurag Kumar, in what was a model of academia–industry collaboration. The C-DOT switching team supplied the inputs: performance measurements taken from the switch with measurement equipment, the switch architecture, call-mix data, and the performance requirements under overload.
The C-DOT switch is a distributed system built from hundreds of microprocessors, with no single central brain. Subscriber lines terminate on the Terminal Units of the Base Modules, whose processors handle the call-processing work of setting up and clearing calls. Control messages between modules travel through message switches, and the whole system runs real-time call-handling software. Every call, therefore, draws on several resources in sequence: processor time in a Base Module, buffer memory in the queues, and capacity in the message switches. A bottleneck anywhere along that path limits the whole switch.
Dr Kumar’s team built an analytical model of this entire system. It represented each processor, queue and message path, along with the real-time software running on them. Driven by the call-mix data and measurements we supplied, the model simulated how call and message loads flowed through the switch. It showed where queues built up, which processors saturated first, and how performance degraded as the offered load rose past capacity.
Calibrated with early performance data, the model accurately predicted the switch’s total call-handling capacity. It also exposed bottlenecks that shaped our engineering:
The collaboration led to early architectural corrections and focused performance engineering in software. As a result, the switch met its call-load targets and all its call-performance parameters. I cannot overstate how important this work was in achieving the switch’s performance goals. Equally memorable was the spirit of partnership between Dr Kumars’ team at IISc and the C-DOT team.
IETE award-winning paper, an outcome of the joint work between C-DOT and IISc.
