Interprocess messaging in Telecom Systems
Back to Articles
Software Telecom Research Whitepaper AMQP

Interprocess messaging in Telecom Systems

March 5, 2018 3 min
Aivis Olsteins

Aivis Olsteins

Something more technical this time.

Increasingly more and more systems while becoming more complex, are becoming multi-process, i. e. have tasks separated by type of the work to be done, or by number of workers doing same work. That is also very true in telecoms, where increase of complexity requires creation of separate dedicated units (processes, services, servers or server groups) which executes their own dedicated tasks, and increase of workload (be it CPS, MPS or whatever measure) requires increase of parallel units doing same job.

Historically, there are protocols created to do this or another specific task. Take, for example AAA (Authorization, Authentication and Accounting): there is RADIUS, DIAMETER, TACACS+ to start from. They are all great very well established and open AAA protocols, proven by decades of existence, IETF approved and each of them perhaps processed quadrillions of AAA requests in total. Their open nature make them very well suited in distributed environments, where pieces of equipment might be geographically and/or topologically distributed, and designed by different vendors.

However, outside of the described scenario, the list is probably short. Let's say besides AAA, we also want to query a NAS (Network Access Server), which by chance can be a SBC or Proxy, etc, for some specific info, like sessions status, or available resources, etc. There are few possible approaches, like: a) extending the above mentioned protocols (VSAs in case of RADIUS), or use separate protocol for monitoring, like SMPP. That becomes more complex. 

Another case is scalability: with increase of load, the systems might need to increase number of devices to handle requests - in an example with RADIUS, that would be to increase number of RADIUS servers. While that is perfectly possible in most of the implementations, the setup becomes difficult to manage if each NAS is required to add a new RADIUS server whenever laod increases.

Setting aside AAA, there are many other inter-process messages running between processes responsible for operation of telecom system. Requests from RESTful APIs, for example. They might need to pass from the API endpoints, via some kind of authentication process, and then into execution queue. Or a process requiring real time routing information. The types of requests are countless.

One of the approaches is to search for possible alternatives outside of telecom domain, within broader software development area. Several message queuing protocols are available, and AMQP or Advanced Message Queuing Protocol is one of them. It has clearly some good advantage points worth considering it as an universal tool:

a) it is transparent to the payload, i.e. you can send any type of the message, the protocol does not enforce any specific format;

b) it is not only a delivery protocol - it also queues messages which is very desirable feature in congestion-prone networks;

c) It has a concept of Message Dispatcher- a.k.a proxy, which can tell what messages from whom go to what recipient, therefore load sharing becomes more easy solvable task;

d) it has well written and maintained libraries in all important programming languages;

e) and last but not least: one of most popular opensource AMQP Message Broker implementations: RabbitMQ Server was written in Erlang, a programming language created by telecom giant Ericsson with a purpose to write highly efficient telecom related code.

More on specifics of AMQP implementation later, in another post, with some details and examples.

 

Share this article

Aivis Olsteins

Aivis Olsteins

An experienced telecommunications professional with expertise in network architecture, cloud communications, and emerging technologies. Passionate about helping businesses leverage modern telecom solutions to drive growth and innovation.

Related Articles

Case Study: Global Communications Company

Case Study: Global Communications Company

A leading communications company used our cloud Voice platform to send 30 million OTP calls per month to their customers, resulting in cost reduction and incrased conversion

Read Article
Bridging The Delay Gap in Conversational AI: The Backpressure Analogy

Bridging The Delay Gap in Conversational AI: The Backpressure Analogy

Conversational AI struggles with the time gap between text generation and speech synthesis. A “backpressure” mechanism, akin to network data flow control, could slow text generation to match speech synthesis speed, improving user interaction.

Read Article
How Voice AI Agents Can Automate Outbound Calls and Unlock New Opportunities for Businesses: A Deeper Dive

How Voice AI Agents Can Automate Outbound Calls and Unlock New Opportunities for Businesses: A Deeper Dive

AI voice agents transform healthcare scheduling by reducing costs, administrative tasks, and no-shows. They offer 24/7 service, multilingual support, proactive reminders, and valuable insights, improving efficiency and patient experiences.

Read Article
How to Fix Your Context: Mitigating and Avoiding Context Failures in LLMs

How to Fix Your Context: Mitigating and Avoiding Context Failures in LLMs

Larger context windows in LLMs cause poisoning, distraction, confusion, and clash. Effective context management (RAG, pruning, quarantine, summarization, tool loadouts, offloading) remains essential for high-quality outputs.

Read Article

SUBSCRIBE TO OUR NEWSLETTER

Stay up to date with the latest news and updates from our telecom experts