DE60312401T2

DE60312401T2 - Verfahren und systems zur simulation eines kommunikationsnetzwerkes, anordnung und dazugehöriges computerprogramm-produkt

Info

Publication number: DE60312401T2
Application number: DE60312401T
Authority: DE
Inventors: Andrea Telecom Ital BARBARESI; Paolo Telecom Ital GORIA; Saverio DataFox S.r. NANNICINI
Original assignee: Telecom Italia SpA
Current assignee: Telecom Italia SpA
Priority date: 2003-11-21
Filing date: 2003-11-21
Publication date: 2007-11-29
Anticipated expiration: 2023-11-22
Also published as: CA2545814C; WO2005051023A1; AU2003292534A1; EP1685732A1; US20070160181A1; CA2545814A1; ES2285199T3; US8090563B2; EP1685732B1; ATE356519T1; DE60312401D1

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft Techniken zum Simulieren von Kommunikationsnetzen wie zum Beispiel zellularen Mobilfunknetzen.
Die Simulation ist ein wesentlicher Schritt bei der Planung, Gestaltung, Realisierung und Verwaltung solcher Netze, insbesondere angesichts der Optimierung der Leistungen der Netze selbst. Genauer spielt die Simulation sowohl auf einer Überprüfungsebene zum Planen eines neuen Netzes als auch auf einer Aktualisierungs- und Optimierungsebene der Leistungen eines bereits betriebenen Netzes eine wichtige Rolle.
Die Erfindung ist unter besonderer Berücksichtigung der Techniken zur Erhebung inhärenter statistischer Daten bezüglich des Verhaltens des simulierten Netzes erdacht worden. Typische Beispiele von statistischen Daten, die in einem zellularen Mobilfunknetz-Systemsimulator gemessen werden können, sind die Netzkapazität, die durchschnittliche Verzögerung bei der Paketübertragung, der Prozentanteil blockierter Anrufe usw.
Beschreibung des Standes der Technik
Bekanntermaßen gibt es zellulare Mobilfunknetz-Systemsimulatoren, die durch eine Objektarchitektur wie derjenigen, die zum Beispiel in WO-A-02/104055 offenbart ist, gekennzeichnet sind. Gemäß dem Objektansatz ist die elementare Zerlegungseinheit nicht der Vorgang (Verfahren), sondern das Objekt, das als Modell einer realen Einheit (ein Realwelt-Objekt) zu verstehen ist.
Bekanntermaßen gibt es in solchen Simulatoren Module oder Vorrichtungen, die geeignet sind, um das Verhalten physikalischer Netzvorrichtungen zu simulieren. Jedes Modul oder jede Vorrichtung kann viele Implementierungen (gemäß den simulierten Funktionalitäten oder Technologien) aufweisen und jede dieser Implementierungen kann bei den Simulationen beliebig benutzt werden: eine unterschiedliche Betriebsweise des Moduls selbst entspricht jeder Implementierung. Es ist auch bekannt, daß die Module oder Vorrichtungen in dem Simulator untereinander Informationen austauschen, um das Verhalten von echten physikalischen Netzvorrichtungen zu simulieren; der Austausch von Informationen tritt auf zweierlei Art und Weise auf: mit „Nachrichten" und mit „Ereignissen".
Die Kommunikation mit Nachrichten ist dadurch gekennzeichnet, daß der Informationsempfang durch das Zielmodul gleichzeitig mit dem Versenden aus dem Quellenmodul stattfindet; im Gegensatz dazu ist die Kommunikation mit Ereignissen dadurch gekennzeichnet, daß der Informationsempfang aus dem Zielmodul nicht gleichzeitig mit der Übertragung aus dem Quellemodul stattfindet, sondern zu einem bestimmten nachfolgenden Zeitpunkt nach der Übertragungszeit: Die Benutzung der Ereignisse dient zur zeitlichen Abstimmung des Empfangs eines Informationsteils aus dem empfangenden Modul.
Es ist auch bekannt, daß diese Simulatoren Messungen des Verhaltens der verschiedenen simulierten Module oder Vorrichtungen ausführen können, wobei statistische Daten, die mit diesen Messungen in Beziehung stehen, als Simulationsergebnisse bereitgestellt werden.
In der in WO-A-02/104055 beschriebenen Anordnung stellt die Objektsimulatorarchitektur einen Motor bereit, in dem sich eine Einheit befindet, die als Statistikverwalter bezeichnet wird. Es ist die Aufgabe dieser Einheit, durch Abfangen von Kommunikationen zwischen Modul und Modul, die Messungen auszuführen, die mit dem Verhalten von Modulen oder Vorrichtungen selbst in Beziehung stehen, und die Statistik gemessener statistischer Daten zu verarbeiten.
Ein typisches Beispiel einer statistischen Verarbeitung ist die Berechnung durchschnittlicher Übertragungsverzögerungen eines Pakets. In diesem Fall führt die Statistikverwaltereinheit für jedes in dem simulierten System übertragene Paket eine Verzögerungsmessung aus, wobei der Mittelwert der verschiedenen gemessenen Verzögerungen unter ihnen gebildet und die durchschnittliche Verzögerung als Ergebnis erhalten wird.
Es ist bekannt, daß – mit analogen Betriebskriterien – die gesamte statistische Verarbeitung in einem Systemsimulator zum Beispiel für zellulare Mobilfunknetze realisiert werden kann.
Der Anmelder hat herausgefunden, daß in einer Situation der oben beschriebenen Art verschiedene Arten von Problemen auftreten, die mit der möglichen und häufigen Gegenwart unterschiedlicher Implementierungen der gleichen Netzfunktionalität in enger Beziehung stehen.
Erstens findet die Kommunikation zwischen zwei Modulen direkt durch die entsprechenden Implementierungen statt: bei jeder Implementierung eines gegebenen Moduls ist es folglich notwenig, zugunsten des Statistikverwalters die gesamte Information einzufügen, die Kommunikationsmodi mit allen Implementierungen der anderen Module identifiziert, mit denen das betroffene Modul kommunizieren kann.
Zweitens ändert sich der Mechanismus, mit dem der Statistikverwalter das Verhalten der Module oder Vorrichtungen mißt, je nach der Implementierung, da er sich an die bestimmte Modul-/Vorrichtungsimplementierung anpassen muß.
Dementsprechend ist es in Abhängigkeit des Standes der Technik zur Berücksichtigung der Gegenwart vieler Implementierungen der gleichen Vorrichtung oder des gleichen Moduls notwenig, in den Statistikverwalter einen spezifischen Abfang- und Meßmechanismus einzufügen, was im Hinblick auf die Zeit und Verarbeitungskomplexität sehr aufwendig sein kann.
Man wird auch zu schätzen wissen, daß dies vor allem für die Telekommunikationsnetze gilt (bei denen die gleiche Netzfunktionalität von Vorrichtungen ausgeführt wird, die von unterschiedlichen Herstellern mit unterschiedlichen Implementierungen geliefert werden) und daß unter im Wesentlichen identischen Bedingungen auch bei der Kommunikation zwischen verschiedenen Modulen oder Vorrichtungen die gleiche Art von Problemen auftritt, und zwar unabhängig von dem Eingreifen des Statistikverwalters oder einer gleichwertigen Einheit.
Aufgabe und Synthese der vorliegenden Erfindung
Es ist folglich die Aufgabe der vorliegenden Erfindung, die oben erwähnten Probleme zu lösen.
Gemäß der vorliegenden Erfindung wird diese Aufgabe dank eines Verfahrens erreicht, das die in den nachfolgenden Ansprüchen spezifisch genannten Eigenschaften aufweist. Die Erfindung betrifft auch das entsprechende System (Simulator), die darin enthaltenen Objekte sowie ein entsprechendes Computerprogrammprodukt, das in den Speicher mindestens eines elektronischen Computers geladen werden kann und Teile eines Softwarecodes umfaßt, um das Verfahren gemäß der Erfindung auszuführen, wenn das Produkt auf einem Computer ausgeführt wird: in diesem Kontext ist dieser Ausdruck in seiner Gesamtheit als gleichbedeutend mit Mitteln zu verstehen, die von einem Computer lesbar sind, der Befehle umfaßt, um ein Netz von Computern zu überprüfen, um das Verfahren gemäß der Erfindung auszuführen. Der Ausdruck „mindestens ein elektronischer Computer" soll die Möglichkeit aufzeigen, die Lösung gemäß der Erfindung in einem dezentralisierten Kontext auszuführen.
In ihrer derzeit bevorzugten Ausführungsform löst die Erfindung die oben erwähnten Probleme durch Einführen für die Module oder Vorrichtungen in dem Simulator entsprechender Kopplungsobjekte mit den anderen Modulen. Solche Kopplungsobjekte weisen bezüglich des Moduls oder der Vorrichtung eine "Außen"-Seite und eine "Innen"-Seite auf. Solch eine Außenseite weist eine von der Eigenart des Moduls oder der Vorrichtung unabhängige Eigenschaft auf und ist folglich für alle Systemmodule oder -vorrichtungen einheitlich.
Der Ausdruck „einheitlich" bezieht sich auf eine derartige Eigenschaft, daß die „Außen"-Seite der Kopplungsobjekte von dem entsprechenden Modul oder der entsprechenden Vorrichtung unabhängig ist, und kann folglich im Wesentlichen mit allen Modulen oder Vorrichtungen identisch sein.
Die oben erwähnten Probleme, die mit der möglichen Gegenwart unterschiedlicher Implementierungen der Netzfunktionalität eng verbunden sind, werden dadurch gelöst, auch was das mögliche Eingreifen des Statistikverwalters oder einer gleichwertigen Einheit angeht.
In einer besonders bevorzugten Art und Weise werden die folgenden Kopplungsobjekte eingeführt:

– Kommunikationsschnittstellen zwischen allen simulierten Modulen und/oder Vorrichtungen: Schnittstellen dieser Art verwalten die Kommunikation mit "Ereignissen" und mit "Nachrichten" und realisieren Implementierungen einzelner Module unabhängig von der Kommunikationsart, die jedes Modul mit anderen Modulen in dem Simulator ausführen kann. Insbesondere gibt es für jedes Modul / jede Vorrichtung eine einheitliche Kommunikationsschnittstelle für alle unterschiedlichen Implementierungen des berücksichtigten Moduls; jeder Kommunikationsvorgang unter Modulen und/oder Vorrichtungen findet durch die Kommunikationsschnittstellen statt;
– statistische Schnittstellen simulierter Module und/oder Vorrichtungen: Die Schnittstellen dieser Arten machen statistische Erhebungen, die von der Statistikverwaltungseinheit ausgeführt werden, unabhängig von der Implementierung simulierter Module, von denen statistische Daten erkannt werden. Insbesondere ist ein Kopplungsobjekt für jede einzelne Implementierung der fraglichen Module vorhanden; in diesem Kopplungsobjekt wird der Meßmechanismus statistischer Daten aus dem entsprechenden Modul auf einfache Art und Weise realisiert. Die Statistikverwaltungseinheit sammelt die erkannten Daten durch die einheitlich gemachte Außenseite von Kopplungsobjekten und direkter aus einzelnen Modulen.

Kurze Beschreibung der beiliegenden Zeichnungen
Die Erfindung wird nun als rein nicht einschränkendes Beispiel mit Bezug auf die beiliegenden Zeichnungen beschrieben. Es zeigen:
1 ein funktionelles Annäherungsdiagramm eines Simulators der hierin beschriebenen Art,
2 die Architektur in Beziehung stehender Kommunikationsschnittstellen,
3, 4 und 5 eine mögliche Organisation von Nachrichten und Ereignissen innerhalb eines Simulators der hierin beschriebenen Art,
6 ein funktionelles Annäherungsdiagramm eines Statistikverwaltungsmoduls in einem Simulator der hierin beschriebenen Art,
7 und 8 im Detail die Architektur der in Beziehung stehenden statistischen Schnittstellen,
9 und 10 beispielhafte Flußdiagramme der Betriebsmodi des hierin beschriebenen Simulators, und
11 in Synthese den Statistikvorgang innerhalb eines Simulators der hierin beschriebenen Art.
Ausführliche Beschreibung einer Ausführungsform der Erfindung
1 zeigt die Architektur eines Simulators 10, der einen Motor 11 umfaßt, in dem alle typischen Verwaltungsfunktionalitäten der Simulation eines Telekommunikationsnetzes wie eines Mobilfunknetzes vorhanden sind, nämlich:

– Parameterverwalter 11a
– Ereignisplaner 11b,
– Fabrikverwalter 11c und
– Statistikverwalter 11d.

Ferner ist ein Vorrichtungsgehäuse 12 vorhanden, in dem die unterschiedlichen Vorrichtungen 13 enthalten sind, die für die physikalischen Netzvorrichtungen und die Objekte stehen, die mit dem Simulationsszenario verbunden sind.
Jede Vorrichtung enthält verschiedene Module, die mit den verschiedenen Funktionalitäten verbunden sind, die von der Vorrichtung selbst verwaltet werden.
Solch ein Simulator, der im Allgemeinen unter einer Gruppe von Eingabesignalen I und einer Gruppe von Ausgabesignalen 0 arbeitet, kann zum Beispiel auf einem Computer mit Intel-Pentium-III-Prozessor und Microsoft-Windows-Betriebssystem unter Verwendung der Entwicklungsumgebung Microsoft Visual Studio 6.0 und der Programmiersprache ANSI C++ umgesetzt werden.
Wie in 2 dargestellt, kann jedes Modul 13', 13'', das in dem Vorrichtungsgehäuse 12 vorhanden ist, viele Implementierungen 13b', 13c' oder 13b'', 13c'', 13d'' aufweisen, die jeweils zum Beispiel mit einer Gruppe simulierter Funktionalitäten oder einer spezifischen Technologie in Beziehung stehen.
Die hierin beschriebene Anordnung kann für alle Implementierungen eines Moduls eine einzelne Kommunikationsschnittstelle 13a', 13a'', ... aufweisen, die bei dem Informationsaustausch mit anderen Modulen benutzt wird.
Das Konzept ist allgemein und kann auf jedes beliebige Modul oder jede beliebige Vorrichtung in einem zellularen Netzsimulator angewendet werden.
Jedes Modul hat seine eigene Kommunikationsschnittstelle: Schnittstelle 13a' für Modul 13' und Schnittstelle 13a'' für Modul 13''.
Das Modul 13' weist zwei unterschiedliche Implementierungen 13b' und 13c' auf, die beide die Schnittstelle 13a' benutzen, um mit anderen Modulen, zum Beispiel mit Modul 13'' zu kommunizieren.
Modul 13'' weist drei unterschiedliche Implementierungen 13b'', 13c'' und 13d'' auf, die alle die Schnittstelle 13a'' benutzen, um mit anderen Modulen, zum Beispiel mit Modul 13' zu kommunizieren.
Die Benutzung von Schnittstellen bei der Kommunikation unter Modulen ermöglicht eine einfachere und schnellere Einfügung neuer Implementierungen eines Moduls, ohne von Zeit zu Zeit die mit dem Informationsaustausch verbundenen Funktionalitäten zu verwalten.
Jede Kommunikationsschnittstelle (oder „Kopplungsobjekt") führt in der Tat eine „äußere" Seite A und eine „innere" Seite B bezüglich Modul oder Vorrichtung 13b', 13c' oder 13b'', 13c'' und 13d'' ein.
Die Innenseite B spiegelt die Eigenschaften (oder „Eigenarten") des spezifischen Moduls oder der spezifischen Vorrichtung und insbesondere der spezifischen, zu einer gegebenen Zeit berücksichtigen Implementierung wider
Im Gegensatz dazu ist die Außenseite A jedes Kopplungsobjekts 13a', 13a'' für alle Systemmodule oder -vorrichtungen und folglich für alle möglichen Implementierungen davon einheitlich.
Der Ausdruck „einheitlich" bezieht sich auf eine derartige Eigenschaft, daß die Außenseite A der Kopplungsobjekte von dem entsprechenden Modul oder der entsprechenden Vorrichtung unabhängig ist, und kann folglich im Wesentlichen mit allen Modulen oder Vorrichtungen identisch sein.
Insbesondere ist die Außenseite A der Kopplungsobjekte konfiguriert, um den Informationsaustausch zwischen Modulen oder Vorrichtungen mit den folgenden zwei Modi zu ermöglichen:

i) durch "Nachrichten": der Informationsaustausch findet durch die Benutzung von Objekten statt, die als „Nachrichten" bezeichnet werden.

In Abhängigkeit von der in 3 dargestellten Struktur ist jede „Nachricht" 100 durch einen Indikator des Quellen- oder Sendermoduls oder der Quellen- und Sendervorrichtung S, durch einen Indikator des Zielmoduls oder der Zielvorrichtung „Ziel" 110 und durch die Information, die unter den Modulen „Daten" 120 ausgetauscht wird, gekennzeichnet. Die Kommunikation mit Nachrichten ist dadurch gekennzeichnet, daß der Empfang von Information aus dem Zielmodul gleichzeitig mit der Übertragung aus dem Quellenmodul stattfindet.

ii) durch "Ereignisse": der Informationsaustausch findet durch die Benutzung von Objekten statt, die als „Ereignisse" bezeichnet werden. In Abhängigkeit von der in 4 dargestellten Struktur ist jedes „Ereignis" 200 durch einen Indikator des Quellen- oder Sendermoduls oder der Quellen- und Sendervorrichtung S, durch eine „Zeit" 210, durch einen Indikator des Zielmoduls oder der Zielvorrichtung „Ziel" 220 und durch die Information, die unter den Modulen „Daten" 230 ausgetauscht wird, gekennzeichnet. Die Kommunikation mit Ereignissen ist dadurch gekennzeichnet, daß der Empfang von Information aus dem Zielmodul nicht gleichzeitig mit der Übertragung aus dem Quellenmodul, sondern zu einem bestimmten Zeitpunkt nach der Übertragungszeit stattfindet.

Die Benutzung von Ereignissen dient der "Verzögerung" des Empfangs einer Information aus dem Empfangsmodul. Die Kommunikation mit Ereignissen findet durch die als Ereignisplaner bezeichnete Einheit statt, die in dem Simulatormotor zu finden ist; es ist die Funktion des Ereignisplaners, Ereignisse und eine relative Zeit in einer Warteschlange zu speichern, die als „Warteschlange von Ereignissen" bezeichnet wird, und jedes Ereignis an sein eigenes Zielmodul zu senden, wenn die Simulationszeit die Ereigniszeit selbst erreicht.
Die Implementierung jeder Kommunikationsschnittstelle stellt vier Hauptfunktionalitäten bereit, die jeweils die folgenden Bezeichnungen haben:

– NachrichtenVersender <NachrichtenTyp>: Versenden der Funktionalität von Nachrichten des Typs NachrichtenTyp, wobei NachrichtenTyp für jede beliebige Nachrichtenart steht
– EreignisVersender <EreignisTyp>: Versenden der Funktionalität von Ereignissen des Typs EreignisTyp, wobei EreignisTyp für jede beliebige Ereignisart steht;
– NachrichtenHörer <NachrichtenTyp>: Empfangen der Funktionalität von Nachrichten des Typs NachrichtenTyp, wobei NachrichtenTyp für jede beliebige Nachrichtenart steht; und
– EreignisHörer <EreignisTyp>: Empfangen der Funktionalität von Ereignissen des Typs EreignisTyp, wobei EreignisTyp für jede beliebige Ereignisart steht.

Jede Versendungs- oder Empfangsfunktionalität der Nachrichten/Ereignisse ist in den Kommunikationsschnittstellen zu finden oder nicht zu finden.
Es ist möglich, Schnittstellen mit nur einer untergeordneten Gruppe möglicher Funktionalitäten zu haben, zum Beispiel kann eine Schnittstelle nur ein NachrichtenHörer einer Nachricht sein, ohne notwendigerweise die anderen drei Funktionalitäten aufzuweisen.
Darüber hinaus kann in einer einzigen Schnittstelle die gleiche Funktionalität viele Male vorhanden sein, um verschiedene Nachrichten/Ereignisse zu verwalten. Zum Beispiel weist eine Schnittstelle, die dazu fähig sein muß, zwei Typen unterschiedlicher Ereignisse zu empfangen, zwei EreignisHörer-Funktionalitäten auf: eine für den ersten Ereignistyp und eine andere für den zweiten Ereignistyp.
Als weiteres Beispiel (das den Schutzbereich der Erfindung nicht einschränken soll) kann die Darstellung in 5 berücksichtigt werden.
Hier gibt es die Ereignistypen „Ereignis A" 1000, „Ereignis B" 1010 und „Ereignis C" 1020, die Nachrichtentypen „Nachricht 1" 2000 und „Nachricht 2" 2010 und die Schnittstelle, die mit dem Modul „Modul ABC" 3000 verbunden ist, das zu Folgendem fähig ist:

– Empfangen und Senden von Ereignissen des Typs "Ereignis A"
– Empfangen von Ereignissen des Typs "Ereignis B"
– Senden von Ereignissen des Typs "Ereignis C"
– Empfangen der Nachricht "Nachricht 1" und
– Senden der Nachricht „Nachricht 2".

Die folgenden Funktionalitäten der verbundenen Schnittstelle sind aktiv:

– EreignisHörer <Ereignis A> 3010
– EreignisVersender <Ereignis A> 3020
– EreignisHörer <Ereignis B> 3030
– EreignisVersender <Ereignis C> 3040
– NachrichtenHörer <Nachricht 1> 3050 und
– NachrichtenVersender <Nachricht 2> 3060.

Die Realisierung der Simulatorschnittstellen kann vorteilhaft mit der Programmiersprache C++ ausgeführt werden.
Im Falle des oben beschriebenen Beispiels liegt der folgende Code vor:
Die Benutzung von Simulatorschnittstellen bezieht auch die Architektur ein, die mit dem Statistikverwalter verbunden ist.
In dem Simulator ist die statistische Verarbeitung die Aufgabe der Einheit Statistikverwalter 11d, die in dem Motor zu finden ist (siehe 1 und 6).
Der Statistikverwalter 11d enthält die Objekte, die die verschiedenen Statistiken speichern, genannt „Statistikrechner".
6 zeigt beispielhaft drei Einheiten SC1, SC2 und SC3, die jeweils als Statistikrechner fungieren, der mit der Verarbeitung einer bestimmten statistischen Menge verbunden ist: SC1 kann zum Beispiel mit der Systemkapazität verbunden sein, SC2 kann mit dem durchschnittlichen Übertragungsdurchsatz der Pakete verbunden sein und SC3 kann mit dem Leistungspegel verbunden sein, der bei der Übertragung von dem simulierten Mobilfunkendgerät benutzt wird.
Der Betrieb der betroffenen Computer ist unabhängig von den Implementierungen der simulierten Module und ist nur eine Funktion der zu analysierenden statistischen Probentypen.
Die hierin beschrieben Anordnung ermöglicht, daß für jede Implementierung eines Moduls eine angemessene statistische Schnittstelle realisiert wird, die als „Datensammler" bezeichnet wird, deren Ziel es ist, die gewünschten statistischen Proben aus der entsprechenden Implementierung zu sammeln und sie an die Statistikverwaltungseinheit zu senden, die dann ihre Verarbeitung vornimmt.
Als ein nicht einschränkendes Beispiel kann 7 in Betracht gezogen werden, in der eine Vorrichtung 120 dargestellt ist, die zwei Module 121 und 123 aufweist.
Das Modul 121 weist zwei unterschiedliche Implementierungen 121a und 122a auf.
Für jede Implementierung ist eine statistische Schnittstelle (Datensammler) vorhanden: Die Implementierung 121a entspricht der statistischen Schnittstelle 121b und die Implementierung 122a entspricht der statistischen Schnittstelle 122b.
Das Modul 123 weist drei unterschiedliche Implementierungen 123a, 124a und 125a auf.
Für jede Implementierung ist eine statistische Schnittstelle (Datensammler) vorhanden: die Implementierung 123a entspricht der statistischen Schnittstelle 123b, die Implementierung 124a entspricht der statistischen Schnittstelle 124b und die Implementierung 125a entspricht der statistischen Schnittstelle 125b.
Auch in diesem Fall weist jede Kommunikationsschnittstelle oder jedes Kopplungsobjekt in der Tat eine Außenseite A und eine Innenseite B mit Bezug auf das Modul oder die Vorrichtung 121a, 122a oder 123a, 124a und 125a auf.
Die Innenseite B spiegelt die Eigenschaften oder Eigenarten des spezifischen Moduls oder der spezifischen Vorrichtung und insbesondere der spezifischen, zu einer gegebenen Zeit berücksichtigen Implementierung wider.
Im Gegensatz dazu ist die Außenseite A jedes Kopplungsobjekts 121b, 122b oder 123b, 124b, 125b für alle Systemmodule oder -vorrichtungen und folglich für alle möglichen Implementierungen davon einheitlich.
Die Außenseite A der Kopplungsobjekte ist folglich von dem entsprechenden Modul oder der entsprechenden Vorrichtung unabhängig und kann dadurch im Wesentlichen für alle Module oder Vorrichtungen identisch sein.
Als eine Erläuterung und als ein Beispiel kann angenommen werden, daß das Modul 121 die Übertragung eines Paketes verwaltet; in diesem Fall ist eine statistische Probe von Interesse die Zeit, die zur Übertragung jedes einzelnen Pakets verwendet wird. Folglich muß jede statistische Schnittstelle 121b und 122b der unterschiedlichen Implementierungen von Modul 121a und 121b die Zeit, die zur Übertragung eines Paket gebraucht wird, aus der entsprechenden Implementierung des Moduls 121 identifizieren und sammeln können.
Im Allgemeinen verwalten die zwei erwähnten Implementierungen von Modul 121a und 122a die Übertragung eines Pakets auf unterschiedliche Art und Weise vollständig, weshalb die zwei entsprechenden statistischen Schnittstellen 121b und 122b die Übertragungszeit eines Paket mit einem anderen Mechanismus messen müssen.
Die Implementierung jeder statistischen Schnittstelle stellt vorzugsweise eine Funktionalität DatenVersender <DatenTyp>, nämlich eine Versendungsfunktionalität statistischer Daten des Typs DatenTyp bereit, wobei DatenTyp für jeden beliebigen statistischen Datentyp steht.
Als weiteres nicht einschränkendes Beispiel kann die Darstellung in 8 berücksichtigt werden, wobei sich auf der linken Seiten die Typen statischer Daten „Daten A" 1100, „Daten B" 1101 und „Daten C" 1102 befinden und sich auf der rechten Seite die statistischen Schnittstellen befinden, die mit dem Modul „Modul 1" 1300 und dem Modul „Modul 2" 1301 verbunden sind.
Die Schnittstelle, die mit dem Modul „Modul 1" 1300 verbunden ist, kann statistische Daten des Typs „Daten A" 1100 und des Typs „Daten C" 1102 senden.
Die Schnittstelle, die mit dem Modul „Modul 2" 1301 verbunden ist, kann statistische Daten des Typs „Daten B" 1100 und des Typs „Daten C" 1102 senden.
Dann weist die Schnittstelle, die mit dem Modul „Modul 1" 1300 verbunden ist, die folgenden aktiven Funktionalitäten auf:

– DatenVersender <Daten A> 1300a
– DatenVersender <Daten C> 1300b.

Die Schnittstelle, die mit dem Modul „Modul 2" 301 verbunden ist, weist die folgenden aktiven Funktionalitäten auf:

– DatenVersender <Daten B> 1301a
– DatenVersender <Daten C> 1301b.

Die Realisierung statistischer Schnittstellen in dem Simulator wird vorzugsweise mit der Programmiersprache C++ ausgeführt.
Im Falle des oben beschriebenen Beispiels liegt der folgende Code vor:
Der Vorgang des Versendens einer Nachricht ist in 9 dargestellt und wird wie folgt beschrieben:

– Schritt 1001: die Implementierung des Sendermoduls sendet die Nachricht an seine eigene Schnittstelle NachrichtenTyp;
– Schritt 1002: die Schnittstelle des Sendermoduls sendet die Nachricht NachrichtenTyp an die Schnittstelle des Empfangsmoduls;
– Schritt 1003: die Schnittstelle des Empfangsmoduls empfängt die Nachricht NachrichtenTyp und sendet sie an die Implementierung des Moduls.

Im Gegensatz dazu ist in 10 der Vorgang des Versendens eines Ereignisses dargestellt und wird wie folgt beschrieben:

– Schritt 2001: die Implementierung des Sendermoduls sendet das Ereignis an seine eigene Schnittstelle EreignisTyp, die die Empfangszeit t aufzeigt;
– Schritt 2002: die Schnittstelle des Sendermoduls sendet den Ereignisplaner an die Einheit, wobei das Ereignis EreignisTyp die Empfangszeit t aufzeigt;
– Schritt 2003: wenn die Simulation die Zeit t erreicht, sendet die Einheit Ereignisplaner das Ereignis EreignisTyp an die Schnittstelle des Zielmoduls;
– Schritt 2004: die Schnittstelle des Empfangsmoduls empfängt das Ereignis EreignisTyp und sendet es an die Implementierung des Moduls.

Der allgemeine Betrieb des Verfahrens zum Sammeln statistischer Proben in einem gegebenen Simulator ist in 11 dargestellt, wobei zum Beispiel der Statistikverwalter 31 drei Statistiken (Statistikrechner) 31a, 31b und 31c verwaltet. Die Statistik 31a verarbeitet Proben des Typs K, die sie aus einem ersten Modul erhält, das zwei Implementierungen 32a und 33a aufweist, die jeweils den statistischen Schnittstellen 32b und 33b entsprechen.
Die Sammlung statistischer Proben findet wie folgt statt:

– während der Simulation identifizieren die statistischen Schnittstellen 32b und 33b Proben des Typs K jeweils mit einem geeigneten Mechanismus, der die Funktionalitäten der entsprechenden Implementierungen 32a und 33a berücksichtigt.
– bei jedem Simulationsschritt fragt der Statistikverwalter die statistischen Schnittstellen ab, so daß diese die gesammelten Proben des Typs K direkt an die Statistik 31a senden; und
– mit einem geeigneten Intervall verarbeitet die Statistik 31a Proben des Typs K und sendet das Ergebnis weiter.

Die hierin beschriebene Anordnung hat im Wesentlichen zwei Hauptvorteile.
Erstens ist der Kommunikationsmodus zwischen simulierten Modulen und Vorrichtungen von den einzelnen Implementierungen von Modulen/Vorrichtungen unabhängig. Auf diese Weise werden die Informationsaustauschmodi zwischen Modulen und Vorrichtungen ein für alle Mal festgelegt und definieren die Kommunikationsschnittstellen jedes Moduls und jeder Vorrichtung. Bei jeder Einführung einer neuen Implementierung für eine Vorrichtung oder für ein Modul in den Simulator ist es nicht notwendig, sich um die Verwaltung des Informationsaustausches zu kümmern, da dieser bereits verwaltet ist.
Zweitens ist es möglich, die Planung von Statistiken, die von der Statistikverwaltungseinheit verwaltet werden, zu rationalisieren, da sie nicht davon abhängt, welche Implementierungen von Vorrichtungen oder Modulen in der Simulation benutzt werden. Folglich ist es bei jeder Einführung einer neuen Implementierung für eine Vorrichtung oder für ein Modul in den Simulator ausreichend, die entsprechende statistische Schnittstelle (Datensammler) zu realisieren, ohne den Betrieb des Statistikrechners modifizieren zu müssen.
Als Ergebnis der oben beschriebenen Situation wird eine flexible und schlanke Architektur des Simulators erhalten.
Wie schon erwähnt, kann die Implementierung des beschriebenen Simulators mit jeder beliebigen Computerart wie Intel, SUN, Apple, ... und mit jedem beliebigen Betriebssystem (Windows, Linux, Unix, MAC OS, ...) umgesetzt werden. Die Benutzung der Programmiersprache ANSI C++ ist nur eine mögliche Wahl; die Implementierung des Simulators kann in der Tat auch in anderen Programmiersprachen wie Java, Delphi, Visual Basic, ... ausgeführt werden.
Die Wahl der Sprache ANSI C++ scheint derzeit angesichts der von dieser Programmiersprache bereitgestellten guten Planungsflexibilität und des hohen Pegels erreichbarer Leistungen in dem Endprogramm im Hinblich auf die Ausführungsgeschwindigkeit bevorzugt.
Die Erfindung kann in zellularen Netzsimulatoren benutzt werden, die neben den genannten Systemen GSM, GPRS und UMTS andere Systeme simulieren. Die Erfindung kann in zellularen Netzsimulatoren benutzt werden, die die Ereignissimulationstechnik oder die Montecarlo-Simulationstechnik anwenden.
Der Fachmann wird ohne weiteres zu schätzen wissen, daß die Erfindung nicht unbedingt nur die Simulation von zellularen Mobilfunknetzen betrifft: die Erfindung kann in der Tat auch in anderen Simulatortypen benutzt werden, bei denen eine ähnliche Architektur mit Modulen und Vorrichtungen vorhanden ist, die einem echten physikalischen Gerät entsprechen, und bei denen es notwenig ist, die mit den simulierten Funktionalitäten verbundenen Parameter unter verschiedenen Modulen/Vorrichtungen mitzuteilen.
Ungeachtet des Prinzips der Erfindung ist es folglich offensichtlich, daß die Realisierungseinzelheiten und die Ausführungsformen im Hinblick auf das Beschriebene und Dargestellte grob geändert werden können, ohne den Schutzbereich der vorliegenden Erfindung, wie in den beiliegenden Ansprüchen definiert, zu verlassen.

Claims

Verfahren zum Simulieren eines Kommunikationsnetzes durch Objekte (13), die eine entsprechende Gruppe von Netzmodulen oder -vorrichtungen modellieren, dadurch gekennzeichnet, daß es den Schritt eines Einfügens zumindest eines entsprechenden Kopplungsobjektes (13a', 13a''; 121b, 122b, 123b, 124b, 125b) mit anderen Modulen oder Vorrichtungen der Gruppe für jedes Modul oder jede Vorrichtung der Gruppe umfaßt, wobei das entsprechende Kopplungsobjekt (13a', 13a''; 121b, 122b, 123b, 124b, 125b) eine Außenseite (A) und eine Innenseite (B) bezüglich des Moduls oder der Vorrichtung aufweist, wobei die Außenseite (A) des entsprechenden Kopplungsobjekts (13a', 13a''; 121b, 122b, 123b, 124b, 125b) für alle Module oder Vorrichtungen der Gruppe einheitlich ist.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß es die Schritte umfaßt: – Realisieren einer Mehrzahl verschiedener Implementierungen (13b'; 13c'; 13b'', 13c'', 13d'') für ein Modul oder eine Vorrichtung der Gruppe und – Bereitstellen eines einheitlichen Kopplungsobjekts (13a'; 13a'') für alle verschiedenen Implementierungen der Mehrzahl.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß es die Schritte umfaßt: – Realisieren einer Mehrzahl von verschiedenen Implementierungen (121a, 122a; 123a, 124a, 125a) für ein Modul oder eine Vorrichtung der Gruppe und – Bereitstellen eines entsprechenden Kopplungsobjekts (121b, 122b; 123b, 124b, 125b) für jede verschiedene Implementierung der Mehrzahl verschiedener Implementierungen.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß es den Schritt eines Konfigurierens der Außenseite (A) der Kopplungsobjekte umfaßt, um die Kommunikation unter Modulen oder Vorrichtungen der Gruppe als Ereignisse (200; 1000, 1010, 1020) zu ermöglichen.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß es den Schritt eines Konfigurierens der Außenseite (A) der Kopplungsobjekte umfaßt, um die Kommunikation unter Modulen oder Vorrichtungen der Gruppe als Nachrichten (110, 120; 2000, 2010) zu ermöglichen.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß es die Schritte umfaßt: – Bereitstellen eines Statistikverwaltungsmoduls (11d) zur Sammlung von statistischen Daten, die den Betrieb des simulierten Netzes betreffen, und – Messen der statistischen Daten durch das Statistikverwaltungsmodul (11d) durch die Außenseite (A) der Kopplungsobjekte (121b, 122b; 123b, 124b, 125b), die den Modulen oder Vorrichtungen (121, 123) der Gruppe zugeordnet sind.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Außenseiten (A) der Kopplungsobjekte Informationen mit homologen Objekten, die Modulen oder Vorrichtungen der Gruppe zugeordnet sind, durch Strukturen austauschen, die umfassen: – einen Indikator des Quellenmoduls oder der Quellenvorrichtung (S), – einen Indikator (110) des Zielmoduls oder der Zielvorrichtung und – die ausgetauschte Information (120).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Kopplungsobjekte Informationen mit homologen Objekten, die den Modulen oder Vorrichtungen der Gruppe zugeordnet sind, durch Strukturen austauschen, die umfassen: – einen Indikator des Quellenmoduls oder der Quellenvorrichtung (S), – einen Zeitindikator (210), – einen Indikator des Zielmoduls oder der Zielvorrichtung (220) und – die ausgetauschte Information (230).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Kopplungsobjekte Funktionalitäten umfassen, die aus der Gruppe gewählt sind, umfassend: – eine Nachrichten versendende Funktionalität (3060), – eine Ereignisse versendende Funktionalität (3020, 3040); – eine Nachrichten empfangende Funktionalität (3050) und – eine Ereignisse empfangende Funktionalität (3010, 3030).
Verfahren zum Simulieren eines Kommunikationsnetzes durch Objekte (13), die eine entsprechende Gruppe von Netzmodulen oder -vorrichtungen modellieren, dadurch gekennzeichnet, daß das System für jedes Modul oder für jede Vorrichtung der Gruppe zumindest ein entsprechendes Kopplungsobjekt (13a', 13a''; 121b, 122b, 123b, 124b, 125b) mit anderen Modulen oder Vorrichtungen der Gruppe umfaßt, wobei das entsprechende Kopplungsobjekt (13a', 13a''; 121b, 122b, 123b, 124b, 125b) eine Außenseite (A) und eine Innenseite (B) bezüglich des Moduls oder der Vorrichtung aufweist, wobei die Außenseite (A) des entsprechenden Kopplungsobjekts (13a', 13a''; 121b, 122b, 123b, 124b, 125b) für alle Module oder Vorrichtungen der Gruppe einheitlich ist.
System nach Anspruch 10, dadurch gekennzeichnet, daß es umfaßt: – für zumindest ein Modul oder eine Vorrichtung der Gruppe eine Mehrzahl verschiedener Implementierungen (13b'; 13c', 13b'', 13c'', 13d'') und – ein einheitliches Kopplungsobjekt (13a'; 13a'') für alle verschiedenen Implementierungen der Mehrzahl verschiedener Implementierungen.
System nach Anspruch 10, dadurch gekennzeichnet, daß es umfaßt: – für zumindest ein Modul oder eine Vorrichtung der Gruppe eine Mehrzahl verschiedener Implementierungen (121a, 122a, 123a, 124a, 125a) und – ein entsprechendes Kopplungsobjekt (121b, 122b; 123b, 124b, 125b) für jede unterschiedliche Implementierung der Mehrzahl verschiedener Implementierungen.
System nach Anspruch 10, dadurch gekennzeichnet, daß die Außenseite (A) der Kopplungsobjekte dafür konfiguriert ist, die Kommunikation zwischen Modulen oder Vorrichtungen der Gruppe als Ereignisse (200; 1000, 1010, 1020) zu ermöglichen.
System nach Anspruch 10, dadurch gekennzeichnet, daß die Außenseite (A) der Kopplungsobjekte dafür konfiguriert ist, die Kommunikation zwischen Modulen oder Vorrichtungen der Gruppe als Nachrichten (110, 120; 2000, 2010) zu ermöglichen.
System nach Anspruch 10, dadurch gekennzeichnet, daß es ein Statistikverwaltungsmodul (11d) zur Sammlung von statistischen Daten bezüglich des Betriebs des simulierten Netzes umfaßt und dadurch, daß das Statistikverwaltungsmodul (11d) dafür konfiguriert ist, die statistischen Daten durch die Außenseite (A) der Kopplungsobjekte (121b, 122b; 123b, 124b, 125b) zu messen, die den Modulen oder Vorrichtungen (121, 123) der Gruppe zugeordnet sind.
System nach Anspruch 10, dadurch gekennzeichnet, daß die Außenseite (A) der Kopplungsobjekte dafür konfiguriert ist, Informationen mit homologen Objekten, die den Modulen oder Vorrichtungen der Gruppe zugeordnet sind, durch Strukturen auszutauschen, die umfassen: – einen Indikator des Quellenmoduls oder der Quellenvorrichtung (S), – einen Indikator (110) des Zielmoduls oder der Zielvorrichtung und – die ausgetauschte Information (120).
System nach Anspruch 10, dadurch gekennzeichnet, daß die Außenseite (A) der Kopplungsobjekte dafür konfiguriert ist, Informationen mit homologen Objekten, die den Modulen oder Vorrichtungen der Gruppe zugeordnet sind, durch Strukturen auszutauschen, die umfassen: – einen Indikator des Quellenmoduls oder der Quellenvorrichtung (S), – einen Zeitindikator (210), – einen Indikator des Zielmoduls oder der Zielvorrichtung (220) und – die ausgetauschte Information (230).
System nach Anspruch 10, dadurch gekennzeichnet, daß die Kopplungsobjekte Funktionalitäten aufweisen, die aus der Gruppe gewählt sind, welche umfaßt: – ein Nachrichten versendende Funktionalität (3060), – eine Ereignisse versendende Funktionalität (3020, 3040), – eine Nachrichten empfangende Funktionalität (3050) und – eine Ereignisse empfangede Funktionalität (3010, 3030).
Objekt (13) eines Systems zum Simulieren von Telekommunikationsnetzen gemäß einem der Ansprüche 10 bis 18, dadurch gekennzeichnet, daß es zumindest ein entsprechendes Kopplungsobjekt (13a', 13a''; 121b, 122b, 123b, 124b, 125b) mit einer Außenseite (A) und einer Innenseite (B) bezüglich des modulierten Moduls oder der modulierten Vorrichtung umfaßt, wobei die Außenseite (A) des entsprechenden Kopplungsobjekts (13a', 13a''; 121b, 122b, 123b, 124b, 125b) eine Eigenschaft aufweist, die unabhängig von der Eigenart des Moduls oder der Vorrichtung ist.
Computerprogrammprodukt, das dazu eingerichtet ist, in den Speicher zumindest eines Computers geladen zu werden, und das Teile eines Softwarecodes umfaßt, um die Verfahrensschritte gemäß einem der Ansprüche 1 bis 9 auszuführen.