An IMS DSL Developed at Ericsson

In this paper, we present how we created a Domain Specific Language (DSL) dedicated to IP Multimedia Subsystem (IMS) at Ericsson. First, we introduce IMS and how developers are burdened by its complexity when integrating it in their application. Then we describe the principles we followed to create our new IMS DSL from its core in the Scala language to its syntax. We then present how we integrated it in two existing projects and show how it can save time for developers and how readable the syntax of the IMS DSL is.

💡 Research Summary

The paper presents the design, implementation, and practical evaluation of a domain‑specific language (DSL) created at Ericsson to simplify development on the IP Multimedia Subsystem (IMS). IMS is a complex, standards‑driven architecture that combines many components (CSCF, HSS, PGM, MR​F, etc.) and protocols (SIP, SDP, MSRP, XCAP, H.248, …). Traditional developers must study numerous RFCs and manually invoke low‑level APIs, which leads to steep learning curves, large specialist teams, and long development cycles.

To address these challenges the authors built an IMS‑focused DSL on top of the Scala programming language. Scala was chosen because its lightweight syntax (optional dots and parentheses), support for higher‑order functions, currying, and implicit conversions enable a “natural‑language‑like” chain syntax. For example, the DSL allows userA send "Hello World" to userB instead of the more verbose Java/Scala call userA.send("Hello World").to(userB). Scala’s compilation to JVM bytecode guarantees seamless reuse of existing Java libraries, cross‑platform deployment (including Android), and interactive REPL support for rapid prototyping.

The DSL design process follows a domain‑first methodology: first enumerate IMS concepts (registration, publishing, instant messaging, media mixing, etc.), then define a minimal set of DSL tokens that map directly to those concepts, deliberately avoiding generic programming constructs such as variable declarations or control‑flow statements. The resulting syntax is concise, unambiguous, and immediately recognizable to IMS experts while still being approachable for newcomers. Scala’s traits and implicit conversions are used to modularize functionality and to keep the DSL extensible without major refactoring when new protocols or services are added.

Three prototype projects were used to evaluate the DSL.

1. Tolmie 2 – Assisted Living: The original C++ implementation (using PJSIP) required 12 man‑weeks of coding and unit testing. Re‑implementing the same functionality with the IMS DSL took 3 man‑weeks, while the DSL itself required 9 man‑weeks to build. Code‑size comparisons show dramatic reductions (e.g., SIP Register: 23 lines in C++ → 1 line in DSL; SIP Publish: 131 lines → 1 line).

2. Tolmie 3 – Automotive Telemetry: This project reused the already‑built DSL to expose a vehicle’s CAN‑bus data directly over IMS. No additional DSL work was needed; the prototype was completed in four man‑weeks, essentially the same effort as Tolmie 2 after the DSL existed, demonstrating high re‑usability.

3. Area 51 – Home Automation: A volunteer‑driven smart‑home prototype used Arduino sensors and an Odroid gateway. Even participants with limited IMS knowledge could write DSL scripts to publish sensor data and receive control commands, confirming that the DSL lowers the entry barrier for IMS‑neophytes.

Across all cases the DSL reduced development time, cut source‑code volume by an order of magnitude, and enabled rapid prototyping on heterogeneous platforms. The authors conclude that a well‑designed DSL, built on a flexible host language like Scala, can dramatically improve productivity in complex telecommunication domains, foster collaboration between domain experts and software engineers, and provide a sustainable path for extending IMS functionality in future services.