DE10048979A1

DE10048979A1 - Software-Entwicklungsverfahren basierend auf einem generischen Protokollstapel und standardspezifischen Modulen

Info

Publication number: DE10048979A1
Application number: DE10048979A
Authority: DE
Inventors: Bernhard Walke; Matthias Siebert
Original assignee: Individual
Current assignee: Deutsche Telekom AG
Priority date: 2000-09-27
Filing date: 2000-09-27
Publication date: 2002-04-11
Anticipated expiration: 2020-09-28
Also published as: DE10048979B4

Abstract

Die Erfindung betrifft eine Konstruktionstechnik zur Entwicklung von Software im Bereich der Telekommunikation. Durch Einsatz des zu schützenden Verfahrens ist es möglich, einen in hohem Maße wiederverwertbaren und gleichzeitig adaptiven Code zu erzeugen. Dazu werden bewährte Eigenschaften und Strukturen heutiger Kommunikationssysteme geeignet in Software formuliert, um in zukünftigen Systemen Wiederverwendung zu finden. DOLLAR A Die Grundidee besteht darin, Gemeinsamkeiten von Signalisierungs-, Datenübertragungs- und Verwaltungsprotokollen, wie ISDN BRI-, GSM-, DECT-, UMTS-, Bluetooth- und HiperLan/2-Protokolle, in Form eines generischen Protokollstapels zu formulieren, der durch Hinzuladen standardspezifischer Ergänzungen zu einem dedizierten Protokollstapel vervollständigt wird. Diese Vorgehensweise erlaubt einerseits, in einem Software Defined Radio ein multi-mode Endgerät zu realisieren und andererseits, bestehende Code für die Entwicklung von Protokollstapeln zukünftiger Standards wieder zu verwenden.

Description

Beschreibung des Stands der Technik

Um Dienste unterschiedlicher Mobilfunksysteme in Anspruch nehmen zu können, werden verschie dene Endgeräte benötigt. Schnurlose Telefonsysteme nach DECT- und zellulare Systeme nach GSM- Standard sind Beispiele, bei denen jeweils spezielle Geräte zum Einsatz kommen. Ähnliche Situatio nen treten auf, wenn das Mobilterminal im Ausland benutzt wird. Erste Lösungen dieses Problems bieten multi-band/multi-mode Geräte, welche zunächst zwei verschiedene Geräte in einem Gehäuse vereinen. Bedingt durch die mehrfache Existenz struktur- und funktionsgleicher Hard- und Protokoll software entsteht dabei unnötiger Verarbeitungs- und Speicheraufwand. Bisher ist eine Aktualisierung vorhandener Software durch Nachladen nur schwierig oder gar nicht möglich. Die Einführung neuer Dienste wie GPRS, HSCSD oder EDGE enthüllen die Grenzen der oben genannten Lösung: Obwohl sich nur Teile der funkschnittstellenbezogenen Software ändern, sind neu entwickelte Geräte nötig.

Nutzen der Erfindung

Software (Defined) Radios (SDRs) gelten als mögliche Lösung zur Verbesserung der gegenwärti gen Situation. Ein SDR basiert auf Prozessoren und Software; jegliche Funktionalität wird mittels Steuerungssoftware erreicht. Dadurch ist es möglich ein Endgerät zu entwickeln, welches mehrere Funkschnittstellen und Protokollstapel unterstützen kann.

Wie in Abb. 6.1 gezeigt, sollen SDRs verschiedenartigen Ansprüchen genügen. Die Unterstüt zung mehrerer Funkschnittstellenstandards ermöglichst den Zugang zu unterschiedlichen Netzen mit nur einem einzigen Endgerät, hier als Netzmobilität bezeichnet. Da alle Module eines SDRs von Software gesteuert werden, sind Modifikationen einfach zu realisieren. Geeignete Schnittstellen sol len erlauben, neue Dienste ohne Hardwareveränderungen zu integrieren.

Bisher zielen die Entwicklungen für SDRs auf die Realisierung funk- und übertragungstechnischer Funktionen. Die Erfindung betrifft eine Technik zur Konstruktion der Protokollsoftware von Tele kommunikationssystemen, welche in Standards festgelegt und üblicherweise geschichtet aufgebaut ist. Der Nutzen besteht darin, dass Protokollsoftware, die allen Standards gemeinsam ist, definiert und so realisiert wird, dass durch Zuladen standardspezifischer Komponenten so ein standardkonfor mer Protokollstapel entsteht.

Ein weiterer Nutzen der Erfindung ist Rekonfigurierbarkeit von Endgeräten. Durch Austausch der Konfigurationssoftware eines Endgerätes kann seine Verwendbarkeit für verschiedene Zugangsnet ze und seine Anpassung an verschiedene Funkschnittstellen erreicht werden. Da die Protokolle der Basisstation (BS) und der mobilen Station (MS) grundsätzlich symmetrisch sind, ist die Rekonfigu rierbarkeit auf beide Netzelemente anwendbar.

Ein weiterer Nutzen resultiert daraus, dass die Wiederverwendbarkeit von Software begünstigt wird. Neue Funkschnittstellenstandards beruhen auf wohlbekannten Protokollstapeln von Vorgängersyste men. Kostenintensive Neuentwicklung von Software kann bei Anwendung der erfindungsgemäßen Technik vermieden und Software wiederverwendet werden.

Beschreibung der Erfindung

Die Erfindung betrifft eine Konstruktionstechnik zur Entwicklung von Software im Bereich der Tele kommunikation. Durch Einsatz des neuen Verfahrens ist es möglich einen in hohem Maße wiederver wendbaren, adaptiven Code zu erzeugen. Im Einzelnen sind dabei folgende Schritte durchzuführen:

Strategie zum Aufbau eines durch Software definierten Protokollstapels

Alle Protokollspezifikationen erfolgen in einer Programmiersprache, am besten formal, z. B. in der standardisierten Spezifikationssprache SDL (Specification and Description Language). Die (formal) spezifizierte Protokollsoftware dient als Referenz für eine spätere Konformitätsprüfung der im be schriebenen Konstruktionsverfahren erzeugten laufzeiteffizienten Protokollsoftware.

Die folgende Konstruktionstechnik eines durch Software definierten Funkschnittstellen-Protokollstapels wird hier eingeführt:

Identifizierung von Gemeinsamkeiten

In einem Schritt 1 werden zwei Systeme I und II analysiert, um Gemeinsamkeiten Ihrer Protokoll stapel zu bestimmen. Die Anzahl der Systeme, die einbezogen werden können, ist nicht auf zwei begrenzt. Als Ergebnis wird eine (SDL-)Spezifikation der Schnittmenge der von beiden Systemen verwendeten Protokollstapel erstellt, siehe Abb. 6.2. Da dieser Stapel die in beiden Funkschnitt stellenstandards enthaltenen gleichartigen Funktionen in sich vereint, wird er als generischer Proto kollstapel bezeichnet.

Entwicklung standardspezifischer Module

In Schütt 2 werden die für einen gegebenen Funkschnittstellenstandard (System I oder System II) spezifischen Funktionen spezifiziert. Diese Funktionen beinhalten Eigenschaften, die den jeweiligen Standard charakterisieren und somit das individuelle Verhalten des Systems kennzeichnen. Dabei sind verschiedene Lösungsansätze möglich. Erfindungsgemäß wird eine objektorientierte (formale) Spe zifikationssprache mit Vererbung genutzt. Standardspezifische Module werden als Unterklassen von Basisklassen implementiert, die innerhalb des generischen Protokollstapels definiert werden. Dies ist von besonderem Vorteil bei der Vereinigung von mehr als zwei Systemen in ein Multistandardsystem; Prozeduren die den meisten aber nicht unbedingt allen Standards gemein sind können im generischen Stapel implementiert werden. Die standardspezifischen Module definieren die schon vorhandenen Prozeduren um und das geforderte Verhalten wird erreicht.

Möglich ist auch, die standardspezifischen Module bezüglich der Vererbungshierarchie gleichberech tigt neben dem generischen Protokollstapel zu realisieren.

Integration von generischem Protokollstapel und standardspezifischen Modulen

Um den Protokollstapel eines bestimmten Funkschnittstellenstandards zu erhalten, müssen in Schritt 3 die Module des generischen Protokollstapels mit standardspezifischen Modulen integriert werden.

Dies wird mittels Vererbung erreicht. Abb. 6.3 zeigt die Beziehungen und Abhängigkeiten der oben genannten Teilmodule in UML-Notation (Unified Modeling Language). Um zwischen spezi fischen Protokollstapeln unterscheiden zu können, die konform oder nicht konform mit dem vorge stellten Verfahren entwickelt wurden, werden in Abb. 3 die Notationen System_X (nicht konform) und System_X_spezifischer_Protokollstapel (konform) verwendet.

Falls die standardspezifischen Module in der gleichen Vererbungshierarchieebene wie der generische Protokollstapel realisiert sind, kann ein dedizierter Protokollstapel entweder durch Mehrfachverer bung oder durch das Einräumen einer Zugriffserlaubnis auf das entsprechende andere Modul realisiert werden.

Optimierung der (formalen) Spezifikation

Um nach der Integration und Übersetzung der Spezifikationen von generischen und standardspezifi schem Protokollstapel laufzeiteffizienten Code zu erhalten, werden meist in Schritt 4 Optimierungen vorgenommen. Untersuchungen haben ergeben, daß folgende Optimierungen zweckmäßig sind:

- Einführung von Zeigern anstatt von Parameterlisten
- Verringerung der Zahl der Prozesswechsel
- Reduktion der Anzahl der
- Ereignisse
- Timer-Signale
- Ersetzung von abstrakten Datentypen durch C-Code Konstrukte

Weitere Optimierung und Verifizierung

In einem letzten Schritt 5 werden diejenigen Codeabschnitte identifiziert, die zur Laufzeit dynamisch am häufigsten benutzt werden. Diese Funktionen sollten u. U. in Hardware, z. B. als FPGA realisiert werden.

Um die Konformität der optimierten Spezifikation mit der ursprünglichen Spezifikation zu gewähr leisten, sollten sie in einem Konformitätstest fehlerfrei gegeneinander ablaufen.

Wiederverwendbarkeit von Softwaremodulen

Eine bestechende Eigenschaft der oben vorgeschlagenen Entwurfstechnik ist die Wiederverwendbar keit von Softwaremodulen. Gesetzt den Fall ein existierender Funkschnittstellenstandard, z. B. System I, ist verfügbar und er wurde gemäß dem Verfahren, erläutert in dem vorherigen Unterkapitel, ent worfen (System_I ⇒ System_I_spezifischer_Protokollstapel), so sind die folgenden Schritte nötig, um den Protokollstapel eines neuen Systems, im folgenden System III genannt, zu erhalten (siehe Abb. 6.4).

Adaption des generischen Protokollstapels

Zunächst muss in Schritt A die Generizitätseigenschaft des generischen Protokollstapels des System typs I auf seine Anwendbarkeit bezüglich des zu entwickelnden Systemtyps III geprüft werden. Ist dies prinzipiell möglich, müssen in Schritt B diejenigen Teile dieses Stapels entfernt werden, welche nicht generisch bezüglich des zu entwickelnden Systemtyps III sind, so dass ein neuer generischer Protokollstapel bezüglich der Systeme I und III entsteht.

Entwurf des standardspezifischen Moduls

Um so viel Code wie möglich wiederzuverwenden wird der System I spezifische Teil als Ausgangs punkt für die Entwicklung eines Systems_III_spezifischen Moduls, vergl. Abb. 6.4 Schritt C, ge nommen. Die speziellen Anteile des Systems I, die als Blöcke mit externen Signalpfaden formuliert sind, müssen identifiziert werden. Als nächstes muss die Brauchbarkeit dieser Blöcke im Hinblick auf die Anwendbarkeit zur Abdeckung System III-spezifischer Funktionen analysiert werden. Die Imple mentierung von Modifikationen zusammen mit neuen Ergänzungen ergibt schließlich einen System III-spezifischen Block. Danach müssen neue Funktionen, die nicht in der Funkschnittstelle des Sy stems I enthalten sind identifiziert werden. Sie werden entweder existierenden Blöcken oder neu zu entwickelnden Blöcken zugewiesen.

Integration des neuen Protokollstapels System_III_spezifischer Protokollstapel

Um den neuen System III Funkschnittstellen-Protokollstapel zu erhalten, müssen noch in Schritt D die beiden Teile, generischer Protokollstapel und System_III_spezifisches_Modul, vereint werden. Hinsichtlich der oben präsentierten Strategie, ist das weitere Vorgehen ähnlich den Schritten, die in den Unterpunkten 4.1.3 ff. beschrieben wurden.

Claims

1. Konstruktionstechnik zur Entwicklung von Software im Bereich der Telekommunikation, dadurch gekennzeichnet,
dass gleiche Strukturen und Abläufe, welche in Protokollstapeln verschiedener Kommunikati onssysteme gleichermaßen auftreten, in einem generischen Protokollstapel konzentriert werden
und dass standardspezifische Eigenschaften in getrennten Modulen implementiert werden und
dass durch Integration von generischem Protokollstapel und standardspezifischen Modulen ein dedizierter Protokollstapel gemäß einem vorbestimmten Standard realisiert wird.

2. Technik gemäß Anspruch 1 zur Entwicklung eines adaptiven Protokollstapels, dadurch gekennzeichnet, dass die standardspezifischen Software-Module als Unterklassen des generischen Protokollsta pels implementiert werden, welche auch Neu- und Umdefinition sowie Überladen von Spezifi kation des generischen Protokollstapels erlauben.

3. Technik gemäß Anspruch 1 zur Entwicklung eines adaptiven Protokollstapels, dadurch gekennzeichnet, dass die standardspezifischen Module gleichberechtigt neben Modulen des generischen Proto kollstapels implementiert werden und dass der komplette standardspezifische Protokollstapel aus Unterklassen, abgeleitet aus Basisklassen standardspezifischer und generischer Module besteht.

4. Technik gemäß Anspruch 1 zur Entwicklung eines adaptiven Protokollstapels, dadurch gekennzeichnet, dass standardspezifische Module gleichberechtigt neben Modulen des generischen Protokollsta pels implementiert werden und dass unter Aufhebung des bei objektorientierten Softwareent wicklungsverfahrens üblichen Informationsschutzes den Modulen eine wechselseitige Zugriffs erlaubnis eingeräumt wird.

5. Technik gemäß den vorangegangenen Ansprüchen zur Anpassung und Integration bestehender Protokollstapel mit einem generischen Protokollstapel, dadurch gekennzeichnet, dass ein generischer Protokollstapel für eine Systemfamilie I als Ausgangsbasis für einen neu zu entwickelnden generischen Protokollstapel einer Systemfamilie III dient, wobei nicht bezüg lich System III generische Anteile des Protokollstapels I entfernt werden und neue bezüglich Systemfamilie III systemspezifische Module durch Übernahme, Modifikation und Erweiterung von spezifischen Modulen des System I realisiert werden.

6. Technik gemäß den vorherigen Ansprüchen, zum Entwickeln von Protokollstapeln von Tele kommunikationssystemen, dadurch gekennzeichnet, dass die unter 1 bis 5 beschriebenen Techniken auf funktionale Untermengen von Protokollsta peln angewendet werden.

7. Verfahren nach den vorangegangenen Ansprüchen dadurch gekennzeichnet, dass der generische Protokollstapel und die standardspezifischen Module formal in einer automatenbasierten Sprache spezifiziert werden.

8. Verfahren nach den vorangegangenen Ansprüchen, dadurch gekennzeichnet, dass der generische Protokollstapel und die standardspezifischen Module formal in einer alge braischen Sprache spezifiziert werden.

9. Verfahren nach den Ansprüchen 1 bis 6, dadurch gekennzeichnet, dass der generische Protokollstapel und die standardspezifischen Module in einer objektorien tierten Programmiersprache spezifiziert werden.

10. Verfahren nach den Ansprüchen 1 bis 6, dadurch gekennzeichnet, dass der generische Protokollstapel und die standardspezifischen Module z. T. formal und z. T. in einer objektorientierten Programmiersprache spezifiziert werden.