OpenD: The Technical Concept

Danny Hartnett

OpenD: The Technical Concept – article by Danny Hartnett, Business Development Director, DECT Forum

This is the second in a series of openD articles and addresses the technical concept behind openD and some of the driving elements. This was consolidated in a technical strategy workshop that took place earlier in the year. This follow-on workshop was supported by key industry players, and focused on the goal of gaining alignment on the features and proposed implementation plan for openD. The first article in the series is available here

openD: Driven by Use-Cases:

The consensus was that Use-Cases will help define the scope of openD. The first openD release will expose the DECT and ULE USPs that set our technology apart, and represent a compelling developer platform with voice and data in the same package.

The base package covers use cases such as a basic voice/VoIP connection, Internal Call, Device/Power management as well as use cases enabling ULE type sensors and actuators.   The data streaming profile in 32KBps, Intercom mode, IPV6, Range, Alarms and low latency use cases are considered for further releases.

Equally, in subsequent releases, and given the benefit of experience with the developer community, openD can start to address the specialist use-cases from healthcare – e.g. critical alarms, low speed telemetry, and low latency for industrial applications.

openD: Engaging vertical markets:

While Use-Cases are vital for defining the openD software platform, the context in which they are used is equally important. For this reason, the openD working group for requirement specification has been busy engaging other vertical industries to understand the strength of our technology in the context of the “new” vertical. The first verticals we have focused on have many requirements in addressing mission critical voice and data-only applications that dovetail with the unique feature sets of DECT & ULE.

  1. Healthcare

Stefan Brämberg (CTO Ascom) presented us some very practical input on the possible use of DECT in other healthcare applications. Here are some of the opportunities for DECT that were outlined:

  • Target DECT as the preferred voice and alarming technology
  • Position DECT as THE secure and reliable clinical device radio link
  • Currently there are many DECT wearable healthcare products like pendants that make use of voice in the application, but ULE could also play a significant role here for mission-critical data applications requiring regular real-time updates and alarm functions
  • Wi-Fi is one of the key technologies in use in hospitals because it affords a lot of flexibility.
  • The network administrators see Wi-Fi as a natural extension of their IP network.
  • Increasingly Wi-Fi is also used for mission critical data, RTLS (Real-time Location System), as well as patient video and voice services.
  • The performance, reliability and mission critical capabilities of Wi-Fi however, are often compromised by the complexity of delivering voice over Wi-Fi . In this case DECT could be regarded as a potential for Wi-Fi to offload voice. There are real opportunities here for DECT in voice, mission critical data applications and alarms.

Possible Use Cases were also pointed out for the openD perspective and included (see below graphic):

  • Critical alarms
  • Low speed telemetry for point of care applications


Key aspect for DECT: Many Industrial markets can be addressed by today’s technology although there are other strict certification requirements, and product life cycles are much longer than in consumer markets.

Requirements from the industrial vertical (as presented by guest speakers Dr. Andreas Wilzeck from Wisesense/Sennheiser and Professor Axel Sikora from Offenburg University) in our WG meetings were outlined:

  • Andreas Wilzeck underscored the idea that not only latency (<10ms), but also reliability is crucial for the industrial vertical
  • Other important attributes of DECT for industrial are licensed, royalty-free spectrum for the industrial community. This gives them planning certainty that they would not have when using licensed bands and paying royalties.
  • DECT has no LBT (listen before talk) requirements above 10mW, allowing for more flexible usage scenarios in industrial applications.
  • There are several applications in industrial automation that can be addressed with today’s DECT solutions in process automation, warehousing and monitoring. The openD Requirements Working Group (RWG) will continue to invite the experts to give their professional perspectives on target verticals, to improve the quality of openD.

openD System overview:

When looking at the diverse requirements above, we see that openD will have to be designed to focus on use cases that accommodate the targeted vertical. In time, it’s anticipated that openD will have diverse industries driving the architecture and the release plan. Follow-on releases will target different aspects of the vertical markets where DECT really can make a difference.  Let’s look at the openD system architecture the implications of those requirements.

System Overview:

  • openD is a software developer platform which runs as a ‘plug into’ – e.g. Raspberry PI on the base side or Arduino on the client side (not restricted to these platforms). It is DECT (Chip) independant
  • This SW plug-in also functions seamlessly with a so-called “DECT shield” which is a credit card sized PCB including a DECT module with stack and Radio.
  • The API (Application Programming Interface) and user layer are defined by use cases that the platform fulfills
  • openD takes advantage of the millions of Raspberry PI and Arduino users globally designing applications with wireless connectivity for the IoT and initially targets these developers.
  • OpenD enables these developers to easily access some of the most important attributes of the DECT and ULE technologies.

Implications for the system

As is evident from the above requirements, a successful openD platform will need to be flexible and modular to meet developer demands that are often dynamically changing.

API:  The API must appeal to a wide variety of programmers / makers / developers. It was agreed that an API and User Layer in “C” would be the right choice for the 3rd party developer. It would also appeal to a wide range of users across regional and application boundaries, and allow integration into a variety of applications.

The SW Architecture: The Software architecture shown below has been reviewed and agreed by our industry experts. It will provide developers a unique opportunity to design voice, audio and data (sensor) applications for hub and client.

openD software is composed of:

  • User Layer: containing sample code for each of the main use cases. This can act as an accelerator for developers building early prototypes.
  • API (Application programming Interface) in the “C” programming language. This provides maximum flexibility with the API in source code.
  • API adaption layer will ensure that all the relevant use case commands are transported to the hardware module.

Serving the needs of the openD community:

 openD is also the designated name for the community of developers that use the software kit to build applications. Within this community, openD has the chance to grow into a robust wireless interface package serving the needs of many different applications. Many of the ideas built on leading prototypes like Raspberry PI and Arduino don’t necessarily go to production in that constellation. Making that jump to a market-ready product needs a living, breathing community with access to manufacturers, integrators and channels to market. openD should help to build that bridge between ideas and bringing them to market.

Maintenance, updates and new releases:

openD will provide links to updates, bug fixes and new releases from the openD community landing page. The openD community will also find updates and new releases on Git Hub and Stack Overflow for bug fixes.


To successfully address the needs of openD and the community of developers that use it, it is critical to start with the use cases for the applications being built. This affects the architecture of the system, the sample code delivered and the API itself.

In time openD will change according to the requirements of its users and the architecture will have to be flexible enough to accommodate that. To win new market segments for the openD community, the strengths of DECT & ULE need to be teased out according to the application being designed. openD will support that process offering application relevant software, and the openD community will help bring this to market.

The openD community will be explored in more detail in the next issue of DECT Today.

Leave a Reply

Your email address will not be published. Required fields are marked *