Framework architecture

Table of Contents

• General overview
• Primitive architecture
  • Introduction
  • Request and Confirm
  • Indication and Response
• Unified API
  • Definition
  • HAN FUN Library
  • Portable part
  • Fixed part
  • File references

General overview

This wiki page provides a description of the framework architecture. In general, the framework differentiates between two different device types - the fixed part (FP) and the portable part (PP). Furthermore, this page shows the elements of the unified API. The fixed part is a stationary device which acts as a base station in a wireless DECT network. In contrast, a portable part is a mobile device as a handheld DECT phone. The following chapters provide an introduction into the openD framework with respect to the device types. The next chapter explains the common principle for all API calls of the framework.

Primitive architecture

Introduction

The architecture of the framework follows the Request-Confirm and Indication-Response principle. In the figure below, a grey box represents the openD framework. The API to the upper layer is specified according to this principle.

Request and Confirm

The Request primitive is responsible to perform operations on the openD framework. The openD framework processes the Request and notifies the upper layer with a Confirm primitive. E.g.,a Request could be a management request to configure the openD framework into a fixed or a portable part.

The Confirm primitives contains information about the process status and in several cases, information about important parameters which are related to the operation. The openD framework calls the Confirm primitive when the Request has been processed completely.

Indication and Response

The Indication primitive is a mechanism of the openD framework to inform the upper layer of events. E.g., such an event could be the reception of a packet. The Indication primitive includes status information and may contain further information, depending on the Indication type. Further information might be applicative data or the quality of the connection.

The Response primitive is a functionality for the upper layer to "answer" to an Indication. This feature enables the upper layer to react to an Indication directly.

Unified API

Definition

The description of the unified API refers to the architectural overviews of the fixed and the portable part in the following chapters. The unified API consists of different sub APIs - the Management API (16), the Sub API (17), the Call API (18), the Audio API (19) and the HAN FUN API (20). The Sixlowpan API (21) is not available currently. Those element define the unified API of the openD framework.

Both, the fixed and the portable part utilize the same openD framework. The difference between the two implementation is an extension on the fixed part side - it contains a UDP server as an interface for the upper layers. Please refer to the different architectural overviews and the file references in the upcoming chapters.

HAN FUN Library

The framework integrates the open source HAN FUN library from the ULE Alliance. Please find the implementation on GitHub here:

HAN FUN Library

Portable part

Fixed part

File references

This chapter lists the file references for the different elements of the fixed and portable part elements of the architectures below.

No.	Description
1	Dialog stack implementation.
2	DSPG stack implementation.
3	Audio data stream.
4-9	Low level interfaces from the manufacturers stack implementation for the openD framework.
10	Interworking unit (IWU) to connect Dialog stack with the ULE Alliance 6LoWPAN control interface.
11	This wrapper adapts the Dialog stack subscription, call, audio and management control functions from element (1) to the openD framework.
12	Interworking unit (IWU) to connect Dialog stack with the ULE Alliance HAN-FUN control interface.
13	Interworking unit (IWU) to connect DSPG stack with the ULE Alliance HAN-FUN control interface.
14	This wrapper adapts the DSPG stack subscription, call, audio and management control functions from element (2) to the openD framework.
15	Interworking unit (IWU) to connect DSPG stack with the ULE Alliance 6LoWPAN control interface.
16	Open source 6LoWPAN control interface from the ULE Alliance.
17	Open source HAN-FUN control interface from the ULE Alliance.
18	Interface to provide management control functionalities that are adapted by (11) or (14).
19	Interface to provide subscription registration functionalities that are adapted by (11) or (14).
20	Interface to provide call control functionalities that are adapted by (11) or (14).
21	Interface to provide audio control functionalities that are adapted by (11) or (14).
22	Interface to provide HAN-FUN functionalities from the ULE Alliance HAN-FUN (17).
23	Interface to provide HAN-FUN functionalities from the ULE Alliance 6LoWPAN (16).
24	This represents the unified openD API.
25	Audio interface that provides the audio data. Please refer to: Audio
26	UDP server to provide the access to the unified interfaces.
27	Inter-process communication by an UDP connection.
28	UDP client to get access to the UDP server.
29	A module which abstracts the protocol over the UDP connection. This protocol must be defined. A possible format could be JSON.
30	This is a customer/community application.