DE69622844T2

DE69622844T2 - Kommunikationsmanagement-vorrichtung und -verfahren und telekommunikationssystem mit einer managementvorrichtung

Info

Publication number: DE69622844T2
Application number: DE69622844T
Authority: DE
Inventors: Kjell Andersson; Per Israelsson
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1995-02-08
Filing date: 1996-02-07
Publication date: 2003-04-30
Anticipated expiration: 2016-02-08
Also published as: JPH10513327A; AU692056B2; SE9500442D0; DE69622844D1; KR100294315B1; NZ301420A; MX9705320A; FI973913A7; FI973913L; SE9500442L; FI973913A0; EP0808488A1; CN1173932A; AU4683596A; BR9607411A; WO1996024899A1; KR19980702043A; CA2209912A1; SE504072C2; EP0808488B1

Description

GEBIET DER ERFINDUNG

Die vorliegende Erfindung betrifft eine Anordnung und ein Verfahren zum Kommunikationsmanagement, wie in den Oberbegriffen der Ansprüche 1 bzw. 25 ausgesteuert.
Allgemein ist in Systemen, bei dem ein System durch ein anderes System oder Systeme gesteuert wird, im folgenden als steuerndes System bzw. gesteuertes System bezeichnet, das steuernde System mit Information über Änderungen, Zustände, etc. in dem gesteuerten System ausgestattet. Die Bereitstellung von Information umfasst eine Funktion, die oftmals als ein Senden von Benachrichtigungen bezeichnet wird. Dieses ergibt die Notwendigkeit zum Senden von Ereignisberichten zu dem steuernden System. Falls diese Funktion angewendet wird, werden bei Änderungen Benachrichtigungen erzeugt, beispielsweise in einer Ressource eines gesteuerten Systems und zu dem steuernden System weitergeleitet.
Die Erfindung betrifft auch ein Telekommunikationssystem, wie in dem Oberbegriff von Anspruch 20 ausgesteuert, das steuernde Systeme und gesteuerte Systeme umfasst, wobei Information bezüglich Änderungen, Zuständen, etc. einem steuernden System bereitgestellt werden kann, das mindestens ein gesteuertes System führt.

STAND DER TECHNIK

Die CCITT Recommendations No M.3010 beschreibt die Grundlagen für ein Telekommunikationsmanagementnetz, allgemein als TMN bezeichnet. Dieses ist ein Internationaler Standard zur Steuerung von Telekommunikationsnetzen in einheitlicher Weise mit einem Netz von Betriebssystemen. Auf der niedrigsten Ebene kann eine Telekommunikationsmanagementnetz eine Verbindung zwischen einem Betriebssystem und einem Netzelement betreffen, kann jedoch auch das gesamte Netz von Betriebssystemen betreffen, die ein großes Telekommunikationsnetz steuern. Ein Betreiberschnittstelle, mit Q3 bezeichnet, wurde für ein Telekommunikationssystem standardisiert, das die Verbindung zwischen steuernden und gesteuerten Systemen bereitstellt. In der Recommendation bezüglich dem GSM Standard (Globales System für Mobilkommunikation) ist eine Teilnehmeradministrierung in der technischen GSM Spezifikation TS 12.02 definiert. Demzufolge ist die Q3 Betreiberschnittstelle für die Bereitstellung der Teilnehmeradministrierungsfunktionalität spezifiziert. Die Q3 Schnittstelle definiert sowohl das objektorientierte Informationsmodell von sogenannten Netzelementen, als auch das Kommunikationsprotokoll zwischen den sogenannten Betriebssystemen und den Netzelementen. In der CCITT Recomendation No M.3010 ist ein Netzelementfunktionsblock als ein Funktionsblock definiert, der mit dem Telekommunikationsmanagementnetz TMN kommuniziert (zum Zwecke, überwacht zu werden und/oder gesteuert zu werden). Der Netzelementfunktionsblock liefert die Telekommunikations- und Unterstützungsfunktion, die für das gesteuerte Telekommunikationsnetz erforderlich sind. Er umfasst die Telekommunikationsfunktionen, auf die eine Steuerung (Management) anzuwenden ist. Diese Funktionen sind als solche nicht Teil des TMN, sind jedoch durch den Netzelementfunktionsblock dem TMN dargestellt. Der Teil des Netzelementfunktionsblocks, der diese Repräsentation in Unterstützung des TMN bereitstellt, ist Teil des TMN selbst, wohingegen die Telekommunikationsfunktionen außerhalb des Telekommunikationsmanagementnetzes liegen.
Darüber hinaus ist ein Betriebssystemfunktionsblock als die Information verarbeitend definiert, die das Telekommunikationsmanagement betrifft, zum Zwecke einer Überwachung/Koordination und/oder Steuerung von Telekommunikationsfunktionen einschließlich Managementfunktionen.
Es ist im "Practical Guide for OSI Management" von T. Jeffree et al., Februar 1992 beschrieben, wie von einem gesteuerten System umfasste gesteuerte Objekte Benachrichtigungen bei dem Auftreten von verschiedenen Ereignissen ausgeben. Die durch die Benachrichtigungen umfassten Parameter und die Ereignisse, die die Erzeugung bereitstellen, sind in der Definition des betreffenden gesteuerten Objekts spezifiziert. Notifikationen sind sowohl generisch definiert, in den Funktionsstandards, als auch detailliert im DMI, d. h. CCITT (nunmehr ITU-T) REC. X.721, "Definition of Managementinformation" definiert, sie können jedoch auch durch die Entwickler von gesteuerten Objekten definiert oder speziell angepasst werden. Notifikationen können beispielsweise einer Erzeugung und Löschung eines gesteuerten Objektes betreffen, eine Änderung eines Zustands, eine allgemeine Attributänderung, Alarmberichte, etc.. Das Dokument betrifft weiter den Grad einer Steuerung des Managers oder des steuernden Systems des Weiterleitungsvorgangs. Beispielsweise kann es sein, dass der Entwickler eines gesteuerten Objektes es wünscht, Notifikationen zu definieren, die unter normalen Bedingungen nicht gesendet werden sollen, die jedoch für spezielle Zwecke verfügbar sein sollten, wie beispielsweise eine Überwachung, etc.. Dieses nimmt an, dass die Übertragung von Ereignisberichten unterschiedlicher Arten an oder ausgeschaltet werden kann. Dies hängt jedoch von der Fähigkeit zu einer Unterscheidung des Zielsystems ab, die dem Entwickler des gesteuerten Objekts nicht bekannt ist, was wiederum dazu führt, dass es eventuell nicht möglich ist, die Notifikationen auf eine erwünschte Weise an- und auszuschalten, was sogar eine Steuerung ganz allgemein verhindern kann. In der Druckschrift wird erwähnt, dass es möglich wäre, zusätzliche Attribute zu definieren, die als An- Ausschalter für Modifikationen dienen würden, was jedoch als schlechte Lösung verworfen wird, da es zu einer Duplizierung der Funktion für den Diskriminator führt. Zur Erläuterung kann ein Netzelement ein Betriebssystem hinsichtlich Änderungen in einem gesteuerten Objekt informieren, indem eine Benachrichtigung zu einem Diskriminator gesendet wird, der in dem Netzelement angeordnet ist. In dem Diskriminator kann der Betreiber eine Filterung hinsichtlich der Ereignisse durchführen, die er sehen möchte. Der Diskriminator sendet ein Ereignis der (Q3 Schnittstelle) zu dem Betriebssystem, falls der Filter Notifikationen erfasst, die in die Zuordnung des Filters passen. Der Zweck des Diskriminators ist es somit, eine Einrichtung zum Steuern der Last auf der Schnittstelle (Q3) bereitzustellen.
Die oben erwähnte Druckschrift schlägt weiter vor, Notifikationen in einem separaten gesteuerten Objekt anzuordnen, das in dem ersten enthalten sein kann, es wird jedoch auch diese Lösung als nicht zufriedenstellend verworfen, da dies eine große Menge von Spezifikationen und zusätzlichen Konformitätsanforderungen benötigt, und es weiter auch scheint, dass es die Funktion des Diskriminators dupliziert, wie es in Bezug auf den ersten erwähnten Ansatz erwähnt wurde.
Ein gesteuertes Objekt (MO) ist ein Objekt, das einem Betreiber sichtbar ist, und ist in den Guidelines for the Definition of Managed Objects (GDMO), CCITT, nun ITU-T, Rec. X.722 definiert. Diese Richtlinien definieren den Objekttyp mit seinen Attributen, Aktionen und Notifikationen, unter der Verwendung von Paketen. Einige der Pakete sind optional, wohingegen andere vorgeschrieben sind. Alle Attribute sind durch eine ASN.1 Syntax definiert, und es ist durch die Q3 Schnittstelle dem Betreiber möglich, z. B. eine Instanz eines gesteuerten Objekts zu erzeugen, einen Wert in einer Instanz eines gesteuerten Objektes zu setzen, einen Wert von einer Instanz eines gesteuerten Objektes zu erhalten, eine Aktion mit einer Instanz eines gesteuerten Objekts durchzuführen, und eine Instanz eines gesteuerten Objekts zu löschen.
In Übereinstimmung mit den GSM Recommendations, Technical Specifications 12.02 sind Notifikationen optionale Pakete. Dieses bedeutet hier, dass die Option als solche lediglich auf der Entwicklungsstufe vorliegt. Falls somit die optionalen Paketnotifikationen einbezogen werden, werden die Notifikationen immer aktiv sein, d. h. falls die Funktion von Notifikationen implementiert ist, werden Notifikationen immer gesendet und der Diskriminator des Netzelements hat die Funktion eines Filters und liefert die Möglichkeit, auszuwählen, welche Notifikationen erwünscht sind, und liefert auch eine Einrichtung zum Ignorieren von Notifikationen.
Dieses ergibt jedoch eine beträchtliche Belastung des gesteuerten Systems. Falls beispielsweise eine große Anzahl von Registern und Teilnehmern in einem Heimatortsregister (HLR (Home Location Register)) vorhanden ist, wird eine sehr große Anzahl von Notifikationen gesendet werden, z. B. bezüglich Attributänderungen vom Verkehr, etc.. Dann wird die Hintergrundlast sehr hoch sein, ob nun der Manager für eingesteuerte Systeme die Information verwendet oder nicht. Die erforderliche Verarbeitungskapazität kann dann sehr hoch sein.

ZUSAMMENFASSUNG DER ERFINDUNG

Es ist eine Aufgabe der vorliegenden Erfindung, wie in den unabhängigen Ansprüchen definiert, eine Anordnung bereitzustellen, die mindestens ein gesteuertes Objekt enthält, mit dem es möglich ist, die Sendung von Notifikationen innerhalb des gesteuerten Systems zu steuern. Es ist insbesondere eine Aufgabe der vorliegenden Erfindung, die interne Hintergrundlast im gesteuerten System zu reduzieren, und nur solche Ereignisse zu übermitteln, die durch ein gesteuertes System unter den vorliegenden Umständen erwünscht sind. Ein besondere Aufgabe der vorliegenden Erfindung ist es, eine Anordnung bereitzustellen, mit der die Emission oder Erzeugung von Notifikationen gesteuert werden kann. Weiter ist es eine spezielle Aufgabe der Erfindung, eine Anordnung bereitzustellen, bei der die Erzeugung oder die Emission von Notifikationen betreibergesteuert sein kann. Eine weitere besondere Aufgabe ist es, eine Anordnung bereitzustellen, mit der das Senden von Ereignissen gesteuert werden kann, ohne irgendwelche zusätzlichen Funktionen dem Diskriminator aufzuerlegen, und wobei sowohl die Last auf der Schnittstelle zwischen einem gesteuerten und einem steuernden System als auch innerhalb eines gesteuerten Systems gesteuert werden kann.
Es ist weiter eine Aufgabe der vorliegenden Erfindung, ein Verfahren zum Versorgen eines steuernden Systems mit Information hinsichtlich eines davon gesteuerten Systems bereitzustellen, wobei die Last sowohl auf der die Systeme verbindenden Schnittstelle als auch die Last innerhalb des gesteuerten Systems auf einem niedrigen Niveau gehalten werden kann, in dem nur die benötigten oder erwünschten Notifikationen ausgesendet werden.
Die Problematik der Erzeugung einer hohen Belastung innerhalb eines gesteuerten Systems wurde in den bekannten Druckschriften nicht adressiert, sondern lediglich die Last auf der Schnittstelle zwischen dem steuernden System und dem gesteuerten System. Auch wenn es möglich ist, dem Diskriminator eine weitere Funktion aufzuerlegen, hilft dies nicht bei einer Reduzierung einer internen Last in einem gesteuerten System, was Probleme beispielsweise in Telekommunikationsanwendungen mit einem hohen Grad an Mobilität bewirkt, und auch unter anderen Umständen. Die Probleme mit einer hohen Belastung innerhalb einem gesteuerten System wurde nicht weiter berücksichtigt, da sie nicht beobachtet wurden. Es ist weiter eine Aufgabe der Erfindung, eine Anordnung bereitzustellen, mit der die interne Emission von Notifikationen vollständig ausgeschaltet werden kann oder auf einen beliebigen erwünschten Grad reduziert werden kann, oder mit der nur Notifikationen bezüglich bestimmter gegebener Ereignisse emittiert werden sollen, etc..
Es ist eine weitere Aufgabe der Erfindung, ein Telekommunikationssystem bereitzustellen, einschließlich gesteuerter Systeme, die durch steuernde Systeme gesteuert werden, wobei die interne Last aufgrund einer Ausgabe von Notifikationen innerhalb der gesteuerten Systeme extern gesteuert werden kann, und den vorliegenden Umständen angepasst werden kann, der Anzahl von Benutzern, z. B. Subskriptionen, dem Grad von Mobilität, etc..
Daher wird eine eingangs erwähnte Anordnung bereitgestellt, die eine Notifikationssteuereinrichtung zum selektiven Steuern der Erzeugung und/oder Verteilung von Notifikationen innerhalb des gesteuerten Systems umfasst. Die Notifikationssteuereinrichtung verhindert Notifikationen, die nicht zu dem steuernden System in der Form von Ereignisberichten kommuniziert werden sollen, wobei diese erzeugt und/oder imitiert werden durch das gesteuerte Objekt (MO) und/oder das Ressourcenobjekt (RO), jeweilig zu der Ereignisweiterleitungs-Diskriminatoreinrichtung (EFD/LOG).
Ein eingangs erwähntes System und Verfahren sind weiter bereitgestellt mit den kennzeichnenden Merkmalen der Ansprüche 20 bzw. 25.
Insbesondere ist es durch die Einrichtung möglich, die Emission von Notifikationen in einem beliebigen erwünschten Ausmaß zu verhindern, einschließlich vollständiger Verhinderung, oder es lediglich zu erlauben, dass gegebene Arten von Notifikationen in Abhängigkeit von einem System, Umständen, etc. emittiert werden.
Es ist ein Vorteil der Erfindung, dass die Emission von Notifikationen an- und ausgeschaltet werden kann, in Abhängigkeit von Lastbedingungen in einem gesteuerten System, dass sie jedoch immer noch angeschaltet werden können, falls der Betreiber aus einem oder anderem Grund an bestimmten Notifikationen etc. interessiert ist. Ein weiterer Vorteil der Erfindung ist es, dass die Funktion zum Aussenden von Notifikationen implementiert und auch gesteuert werden kann mit Bezug auf die Last von sowohl der Schnittstelle zwischen einem gesteuerten System und einem steuernden System, und intern in dem gesteuerten System. In einem besonderen Ausführungsbeispiel der Erfindung wird auf ein Telekommunikationsmanagementnetz bezug genommen, wobei die steuernden Systeme auch Betriebssysteme genannt werden, und die gesteuerten Systeme auch Netzelemente genannt werden, wobei eine Kommunikation zwischen den Systemen durch die Q3 Schnittstelle oder ähnliches bereitgestellt wird. Die gesteuerten Systeme oder die Netzelemente umfassen dann eine Anzahl von gesteuerten Objekten, die unterschiedliche Arten von Ressourcen repräsentieren. Dann liefert dies vorteilhafter Weise die Möglichkeit, dass Notifikationen zu einem beliebigen Zeitpunkt gesendet werden, falls ein System nur einige wenige gesteuerte Objekte handhabt, wenn sich jedoch die Anzahl von Benutzern erhöht, und sich die Systembelastung auch erhöht, und wenn die Aussendung von Notifikationen einen gegebenen Pegel erreicht, die Notifikationsfunktion entweder vollständig oder teilweise geschaltet werden kann. Die Erfindung deckt auch den Fall bezüglich untergeordneten gesteuerten Objekten ab, die durch ein übergeordnetes gesteuertes Objekt gesteuert werden, wobei in diesem Fall das übergeordnete gesteuerte Objekt die Stelle eines steuernden Systems einnimmt.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Die Erfindung wird im folgenden auf nicht beschränkende Weise unter Bezugnahme auf die begleitenden Zeichnungen weiter beschrieben.
Fig. 1 beschreibt schematisch ein Netzelement und ein Betriebssystem,
Fig. 2 veranschaulicht schematisch gesteuerte Objekte eines Netzelements, die Ressourceobjekte und/oder gesteuerte Objekte darstellen,
Fig. 3 veranschaulicht schematisch eine Notifikationsverteilung in einem gesteuerten System und eine Übertragung von Information zu einem Führungssystem,
Fig. 4 zeigt sehr schematisch ein Aussenden von Notifikationen innerhalb eines gesteuerten Systems, einschließlich einer Anzahl von MO:s und EFD:s/Log:s,
Fig. 5 zeigt sehr schematisch ein Telekommunikationssystem
Fig. 6 veranschaulicht ein Ausführungsbeispiel, bei dem alle Objekte innerhalb des gleichen Prozesses angeordnet sind,
Fig. 7 veranschaulicht ein Ausführungsbeispiel, in dem Objekte in unterschiedlichen Prozessen angeordnet sind,
Fig. 8 veranschaulicht ein Ausführungsbeispiel, in dem Objekte in unterschiedlichen Prozessen angeordnet sind, die in unterschiedlichen Prozessoren angeordnet sind,
Fig. 9 veranschaulicht ein spezielles Ausführungsbeispiel, bei dem Aktionen zur Steuerung von Notifikationen verwendet werden,
Fig. 10a veranschaulicht ein weiteres Ausführungsbeispiel unter Verwendung eines Haupt-MO zum Steuern von Notifikationen, und
Fig. 10b veranschaulicht eine weitere Alternative basierend auf der Verwendung eines Haupt-MO.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG

Fig. 1 veranschaulicht ein gesteuertes System einschließlich eines Netzelements NE, das durch ein Betriebssystem OS, ein steuerndes System darstellend, gesteuert wird. Das Netzelement NE umfasst ein gesteuertes Objekt MO. Um die Betreiberseite zu informieren, d. h. das Betriebssystem OS, hinsichtlich Änderungen in den gesteuerten Objekten MO, werden Notifikationen ausgesendet. Eine Notifikation wird durch das gesteuerte Objekt MO zu einem Diskriminator gesendet, der innerhalb des Netzelements NE angeordnet ist. In heutzutage bekannten Systemen ist es dem Betreiber ermöglicht, eine Filterung in dem Diskriminator durchzuführen, um die Ereignisse auszuwählen, die als interessant erachtet werden. Beispielsweise kann eine Notifikation zum Zwecke wie beispielsweise Attributänderungen ausgesendet werden, Zustandsänderungen, eine Erzeugung oder Löschung von Instanzen von gesteuerten Objekten etc.. Der Filter des Diskiriminators umfasst eine sogenannte Filterkarte, und falls der Filter feststellt, dass eine bestimmte Notifikation in die Filterkarte passt, sendet der Diskriminator ein Ereignis auf der Schnittstelle, in diesem speziellen Ausführungsbeispiel auf der Q3 Schnittstelle, zu dem Betriebssystem OS. Es ist somit möglich, die Last auf der Q3 Schnittstelle zu steuern, es kann jedoch die innerhalb des Netzelements NE erzeugte Last sehr hoch sein. Falls beispielsweise eine große Anzahl von Änderungen in einem gesteuerten Objekt MO vorliegt, wird jede Änderung zur Aussendung einer Notifikation führen, was nicht nur eine sehr große Anzahl von Notifikationen ergibt, die ausgesendet werden, sondern auch eine hohe Hintergrundlast ergibt, auch wenn der Betreiber den Diskriminator durch Einstellen geeigneter Filterparameter ausgeschaltet hat.
Daher wird die Emission von Notifikationen an einer früheren Stufe in Übereinstimmung mit der Erfindung gesteuert. Im folgenden (um die Wichtigkeit einer Steuerung der Emission von Notifikationen zu veranschaulichen) wird ein Beispiel eines Telekommunikationssystems dargestellt, bei dem die Anzahl von aktiven Teilnehmern 40% ist. Aktiv bedeutet in diesem Fall, dass eine Mobilstation angeschaltet ist und eine SIM (Teilnehmeridentitätsmodul)-Karte installiert ist. Es wird angenommen, dass die Ortsaktualisierung, d. h. ein neuer Ortsbereich 0,1/h pro aktivem Teilnehmer ist. Dieses würde 0,4 · 0,1 · 100.000 = 4.000 Notifikationen pro 100.000 registrierten Teilnehmern in einem Heimatortsregister pro Stunde erzeugen. Für Teilnehmerdienste ist die geschätzte Last 0,05 per No./h/Teilnehmer. Dieses bedeutet, dass 5.000 Notifikationen pro 100.000 registrierte Teilnehmer pro Heimatsortregister und Stunde ausgesendet werden. In Übereinstimmung mit dieser Schätzung werden ungefähr 9.000 Notifikationen bezüglich Attributänderungen vom Verkehr pro Stunde und 100.000 Teilnehmern von dem Netzelement erzeugt werden, was eine hohe Hintergrundlast ergibt, auch wenn die Information in dem steuernden System nicht verwendet wird. Dieses wurde jedoch lediglich als ein Beispiel bezüglich einem System gegeben, um die benötigte Verarbeitungskapazität zu veranschaulichen, wenn nur die Übertragung von Ereignisberichten gesteuert werden kann, nicht jedoch das Aussenden von Notifikationen innerhalb eines Netzelements.
Unterhalb wird die Erfindung weiter unter Bezug auf das Telekommunikationsmanagementnetz TMN beschrieben, wie in den CCITT (ITU-T) Recommendations M.3010 mit Bezug auf das GSM System definiert. Die Erfindung ist jedoch nicht auf das GSM oder TMN beschränkt, ist im Gegensatz dazu relevant bezüglich allen Systemen oder Anordnungen, in denen Notifikationen für Informationszwecke ausgesendet werden.
Bezüglich des GSM Systems ist eine Teilnehmeradministrierung in der GSM Technical Specifications TS 12.02 definiert, wobei die Q3 Betreiberschnittstelle, wie durch das TMN standardisiert, dazu vorgesehen ist, die Teilnehmeradministrierungsfunktionalität bereitzustellen.
Fig. 2 veranschaulicht ein gesteuertes System in der Form eines Netzelements NE, das durch ein steuerndes System in der Form eines Betriebssystems OS gesteuert wird. Die Kommunikation zwischen dem Betriebssystem OS und dem Netzelement NE findet über die Q3 Schnittstelle zwischen den Systemen statt, die ein Kommunikationsprotokoll enthält. Das hierin veranschaulichte Netzelement ist in eine Managementschicht und eine Ressourcenschicht aufgeteilt. Die Managementschicht umfasst eine Anzahl von gesteuerten Objekten MO, die von dem Betriebssystem OS überwacht und gesteuert werden. Die Ressourcenschicht umfasst eine Anzahl von Ressourcenobjekten RO, dargestellt durch die gesteuerten Objekte MO der Managementschicht. Die Ressourcenobjekte und die Ressourcen können funktionale Ressourcen, logische Ressourcen oder physikalische Ressourcen enthalten. Eine Ressource kann beispielsweise eine interne Ressource in einem MO sein, oder kann ein RO umfassen. Insbesondere kann eine Notifikation in einem MO erzeugt werden, kann jedoch auch in einem RO erzeugt werden.
Beispielsweise kann ein gesteuertes System Notifikationen enthalten, die intern in einem MO oder in einem RO oder in beidem erzeugt sind. Notifikationen können auch auf andere Arten erzeugt werden, z. B. in Abhängigkeit von einem System, etc. Die Erfindung ist weiterhin nicht auf objektorientierte Strukturen beschränkt. In dem gezeigten Ausführungsbeispiel ist ein MO durch ein GDMO definiert, was die Richtlinien für die Definition von gesteuerten Objekten betrifft. Die GDMO definiert den Objekttyp mit seinen Attributen, Aktionen und Notifikationen unter Verwendung von Paketen. Einige der Pakete sind optional, wohingegen andere vorgeschrieben sind. Alle Attribute werden durch eine ASN.1 Syntax definiert. Durch die Q3 Schnittstelle kann ein Betreiber beispielsweise eine MO Instanz erzeugen, einen Wert in einer MO Instanz setzen, einen Wert von einer MO Instanz erhalten, eine Aktion mit einer MO Instanz durchführen und eine MO Instanz löschen.
Die Ressourcen oder die Ressourceobjekte RO in dem Netzelement NE werden durch die Verkehrshandhabung verwendet. Beispielsweise kann eine Ressource (eine logische Ressource), die einen Stamm (trunk) darstellt, dazu verwendet werden, einen Telefonanruf in einer Richtung zu führen. Da nur die Managementschicht des NE für das OS sichtbar ist, muss ein Stamm durch ein MO repräsentiert werden, um durch das OS gesteuert werden zu können. Das MO arbeitet dann als eine Schnittstelle zum OS. Ein gesteuertes Objekt kann nicht beliebige Daten speichern, jedoch alle zu den Ressourcen gehörigen Daten. Es kann eine 1 : 1 Übereinstimmung zwischen gesteuerten Objekten und Ressourcen oder Ressourceobjekten geben, dieses ist jedoch nicht notwendigerweise der Fall. Die Pfeile a&sub1;, a&sub2; veranschaulichen unterschiedliche Managementansichten eines Ressourcenobjektes, wobei der Pfeil b1 ein MO veranschaulicht, das eine Kombination von Ressourcen darstellt. Innerhalb der gestrichpunkteten Linie in Fig. 2 ist es veranschaulicht, wie ein gesteuertes Objekt andere gesteuerte Objekte repräsentieren kann. In diesem Fall kann die Betriebsunterstützung zur Funktion in dem höchsten gesteuerten Objekt implementiert sein, anstatt in einem Betriebssystem, d. h. in diesem Fall können die höchsten gesteuerten Objekte als Betriebssysteme darstellend erachtet werden, was ebenso durch die vorliegende Erfindung abgedeckt ist. Diese Figur soll lediglich verschiedene Gesichtspunkte oder Formen von gesteuerten Systemen (insbesondere Netzelementen) veranschaulichen, auf die sich (unter anderem) die Erfindung bezieht.
Wie oben erläutert können die Daten eines MO als Attribute spezifiziert sein. Ein MO Attribut entspricht einem permanent gespeicherten Attribut einer Ressource oder einer RO. Weiter kann es in einem Algorithmus berechnet werden, der Attribute von einer Anzahl von Ressourcen oder ROs holt. Weiter können Ressourcedaten in einem Dateisystem oder in Hardwareregistern gespeichert werden.
In Fig. 3 ist das Senden von Notifikationen veranschaulicht. Um das steuernde System (beispielsweise OS) hinsichtlich Änderungen eines MO in einem gesteuerten System (z. B. NE), ein RO darstellen, zu informieren, kann eine Notifikation zu einem Diskriminator EFD (oder zu einem Agenten) gesendet werden, der dann einen Ereignisbericht zu dem Manager des OS oder der Q3 Schnittstelle sendet. Notifikationen können auch zu einem LOG (Protokoll) gesendet werden, was später weiter ausgesteuert wird. Eine Notifikation kann beispielsweise eine Alarmbedingung sein, ein Ändern von Daten und Verkehrsstatistiken. Wie oben erläutert ist, wenn eine Mobilität bereitgestellt ist, die Anzahl von Notifikationen, die ausgesendet werden kann, sehr hoch, was weiter mit Bezug auf Fig. 5 ausgeführt wird.
In Fig. 4 ist auf schematische Weise ein gesteuertes System einschließlich einer Anzahl von Ereignisweiterleitungs- Diskriminatoren EFD oder LOG:s veranschaulicht. Allgemein muss jede in einem MO erzeugte Notifikation zu jedem EFD (oder LOG) gesendet werden, was eine hohe Belastung erzeugt. Dieses veranschaulicht gut einen der Gründe warum es wünschenswert ist, in der Lage zu sein, eine Erzeugung/Sendung von Notifikationen zu steuern.
In Übereinstimmung mit GSM TS12.02 sind Notifikationen optionale Packungen, wobei in diesem Fall die Option lediglich zu einem Zeitpunkt einer Entwicklung vorliegt. Dies bedeutet, dass dann, falls optionale Packungen einbezogen werden, die Notifikationen immer aktiv sein werden. Durch die Definition eines zusätzlichen Attributs können Notifikationen pro Attribut des gesteuerten Objekts pro Attribut an- /ausgeschaltet werden. Dieses zusätzliche Attribut ist in einer GDMO Spezifikation unter der Verwendung von ASN.1 Notationen definiert. Dieses zusätzliche Attribut umfasst die Notifikationsteuereinrichtung und verhindert, dass Notifikationen gesendet werden, falls Notifikationen nicht erwünscht oder benötigt sind oder wenn sie gestoppt werden sollen.
Ressourcenotifikationen werden spontan durch die Ressourcen erzeugt, wenn bestimmte Ereignisse in dem NE auftreten. Die gesteuerten Objekte oder die Ressourcenobjekte senden dann Notifikationen zu einem Notifikationsverteiler. Allgemein gibt es einen Notifikationsverteiler in jedem Prozessor, es ist jedoch die Erfindung nicht darauf beschränkt. Falls die Notifikationen in RO:s erzeugt werden, leitet der Ressourcenotifikationsverteiler die durch ihn empfangenen Notifikationen zur Managementschicht weiter, in der sie in MO Notifikationen übersetzt werden, solange nicht verhindert wird, dass sie in dem RO erzeugt werden, oder dass sie ausgesendet werden. Wenn nicht verhindert wird, dass eine Notifikation erzeugt oder gesendet wird, als eine MO Notifikation zu dem MO Verteiler, durch das zusätzliche Attribut, wird sie zu dem OS weitergeleitet, oder zu der Einheit, die die MO Notifikation bezieht. Das Ereignisweiterleitungs-Diskriminatorobjekt EFD wird für die Beziehung von MO Notifikationen erzeugt. Das EFD als solches ist ein MO, das bestimmt, welche MO Notifikationen als Ereignisberichte zu dem Betriebssystem weiterzuleiten sind.
LOG in den Figuren betrifft eine gesteuerte Objektklasse, in der Notifikationen für einen späteren Abruf von beispielsweise der Q3 Schnittstelle gespeichert sein können. Die LOG Notifikationen sind in der Form von LOG Aufzeichnungen gespeichert, z. B. eine Alarmnotifikation wird bewirken, dass eine Alarmaufzeichnung erzeugt wird. Für jedes LOG gibt es einen Filter, der definiert, welche Notifikationen als LOG Aufzeichnungen in dieser speziellen Instanz des LOG gespeichert werden.
Somit kann eine MO Notifikation entweder zu einem EFD oder zu einem LOG gesteuert werden. Falls die Notifikation zu dem steuernden System, gebildet durch das OS, weiterzuleiten ist, wird diese als eine Ereignisnachricht durch das gesteuerte System gesendet, in diesem Fall dem NE, zu dem Manager des steuernden Systems oder in diesem Falle dem OS.
Um die interne Last in dem gesteuerten System zu reduzieren, verhindert das zusätzliche Attribut, dass Notifikationen von dem MO oder dem RO gesendet werden, abhängig davon, wo sie erzeugt werden. Dieses hängt unter anderem, wie oben erwähnt, von dem verwendeten System, Notwendigkeit etc. ab. In einem speziellen Ausführungsbeispiel können Notifikationen in einem RO erzeugt werden, es kann jedoch verhindert werden, dass sie von dem das RO repräsentierenden MO ausgesendet werden. Das zusätzliche Attribut wird nunmehr weiter erläutert unter Verwendung der Richtlinien für die Definition von gesteuerten Objekten GDMO, wobei in Übereinstimmung damit Pakete für die Definition des Objekttyps mit dessen Attributen, Aktionen und Notifikationen verwendet werden. Zu diesem Zweck wird ein Notifikationsstopp-Paket eingesteuert. Das Paket wird definiert als
NotificationsStopPackage PACKASE
ATTRIBUTES
NotificationsStop GET-REPLACE
DEFAULT VALUE < module-name> .notstopdef;
BEHAVIOUR notificationsStopPackage
BEHAVIOUR DEFINED AS (Verhalten definiert als) "Dieses Paket wird in gesteuerten Objektklassen dazu verwendet, dass Notifikationen emittiert werden. Es kann ein bedingungsabhängiges Paket eines gesteuerten Objekts sein, oder auch nicht. Die ASN.1 Syntax des Wert-Bezugs des Default-Wertes notstopdef ist ein leerer Satz, was bedeutet, dass, falls keine Information durch die Objekterzeugung bereitgestellt ist, keine Notifikation gestoppt wird. Die Registrierung ist nicht spezifiziert und hängt von der Spezifikation ab, wo das Paket definiert ist.";
REGISTERED AS (registriert als) (nichtspezifiziert)
Das Notifikationsstopp-Attribut ist definiert als notificationStop
ATTRIBUTE
WITH ATTRIBUTE SYNTAX < module-name> notstop
MATCHES FOR EQUALITY
BEHAVIOUR notification stop BEHAVIOUR DEFINED AS (Verhalten definiert als) "Dieses Attribut kann verhindern, dass eine Notifikation von einem gesteuerten Objekt intern im System emittiert wird, um die Verarbeitungsanforderungen eines Systems reduzieren. Die Verarbeitungsanforderungen werden reduziert um: 1, Benachrichtigung erfordert eine Verarbeitungskapazität, um von dem emittierenden gesteuerten Objekt in einem Teil des Systems zu den Diskriminatoren von Ereignisweiterleitungs-Diskriminatioren und Protokollen in möglicherweise anderen Teilen des Systems; 2, keine Verarbeitungskapazität wird dafür benötigt, irgendein Testen gegenüber den Definitionen von Diskriminatoren durchzuführen. Der ASN.1 Typ des Attributs ist ein Satz von OIDs (Objektidentifizierer), der Notifikationen identifiziert, die nicht ausgegeben werden sollen. Optional, falls die Notifikation ein Ergebnis einer Attributwertänderung oder einer Zustandsänderung ist, werden die Attribut IDs der Attribute, für die Notifikationen emittiert werden sollen, einbezogen. Falls keine Attribute einbezogen sind, werden alle Modifikationen gestoppt. Der Modulname hängt von der Spezifikation ab, in der die ASN.1 Syntax definiert ist. Die Registrierung ist unspezifisch und hängt von der Spezifikation ab, in der das Attribut definiert ist.";
REGISTERED AS (registriert als) (unspezifiziert)
Die ASN.1 Definition ist wie folgt:
Die Erfindung wird nun mit Bezug auf ein spezielles Ausführungsbeispiel bezüglich des GSM Systems veranschaulicht. Fig. 5 veranschaulicht sehr schematisch ein zellulares Mobilkommunikationssystem, hier das GSM System. Ein erster und zweiter Ortsbereich LAa, LAb sind veranschaulicht, jeder mit einer Anzahl von Zellen. Jede Zelle umfasst eine Basisstation BS mit einem Funktransceiversystem (hier nicht veranschaulicht), die in Kommunikation mit einem Basisstationssteuerer BSC steht, der wiederum mit einem Mobilvermittlungszentrum/Besucherortsregister MSC/VLR kommuniziert. Die zwei MSC/VLRs der Figur kommunizieren mit einem Heimatortsregister HLR, das durch ein Betriebssystem OS gesteuert ist. Wenn sich die Mobilstation MS von A nach B bewegt, wird sie einen Ortsbereich LA verändern, der in dem Heimatortsregister HLR registriert sein wird. Falls sie beispielsweise oft einen Ortsbereich LA ändert, und/oder wenn viele Mobilstationen MS einen Ortsbereich ändern, werden viele Änderungen in dem HLR registriert, und somit wird eine große Anzahl von Notifikationen erzeugt, obwohl nicht alle davon zu dem OS als Ereignisberichte übermittelt werden müssen.
Nunmehr wird die Verwendung der Erfindung in der GSM managed object class subscriber (GSM gesteuerte Objektklasse Teilnehmer) im HLR weiter erläutert. Wie oben erwähnt wird das zusätzliche Attribut hier dazu verwendet, teilnehmerinduzierte Notifikationen in dem GSM System zu verhindern, dies betrifft jedoch natürlich Mobiltelekommunikationssysteme ganz allgemein.
Die Attributwertänderungsnotifikation wird dazu verwendet, anzuzeigen, dass ein Attribut eines gesteuerten Objektes seinen Wert geändert hat. Dieses Attribut berichtet jede Änderung in einem beliebigen Attribut eines gesteuerten Objekts. Daher erzeugt dies auch eine große Verarbeitungslast, falls viele Attribute immerzu Werte ändern, z. B. von einer Aktion mit Ursprung beim Teilnehmer in einem Mobiltelefonsystem, wie oben erwähnt. Durch das Notifikationsstopp-Attribut der notificationStopPackage ist es möglich, festzulegen, für welche Attribute keine Notifikation auszusenden ist. Der im GSM spezifizierte MO Teilnehmer im HLR enthält eine Attributänderungsnotifikation und die Attribute der MSC/LVLR Nummer werden kontinuierlich geändert, als eine Folge der sich bewegenden. (roaming) Teilnehmer in dem System, wie mit Bezug auf Fig. 4 oben diskutiert.
Ein Beispiel der notificationStopPackage kann wie folgt aussehen:
SubcriberInHlr MANAGED OBJECT CLASS (gesteuerte Objektklasse)
DERIVED FROM (abgeleitet von) "CCITT X.721":top;
CHARACTERIZED BY (gekennzeichnet durch)
subscriberInHlrPackage;
CONDITIONAL PACKAGES (bedingungsabhängige Pakete) SubInHlrControlStatusPackage
PRESENT IF (vorhanden, falls) "controlStatus implementiert ist",
prevMsisdnPackage PRESENT IF (vorhanden, falls) " die Zuordnung zur vorhergehenden MSISDN implementiert ist",
subInHlrOverridePackage PRESENT IF (vorhanden, falls) "Überschreiben-Kategorie implementiert ist",
subInHlrLmsiPackage PRESENT IF (vorhanden, falls) "LMSI im HLR gespeichert ist",
subInHlrMwdPackage PRESENT IF (vorhanden, falls) "Nachrichtenwarte-Nachrichten im HLR implementiert sind",
createDeleteNotificationPackage PRESENT IF (vorhanden, falls) "Die objectCreation und objectDeletion Notifikationen (Objecterzeugungs- und Objektlöschungsnotifikationen) (wie im CCITT X.721 definiert) durch dieses gesteuerte Object unterstützt werden",
attributeValueChangeNotificationPackage PRESENT IF (vorhanden, falls) "Die attribute ValueChange (Wertänderungs-) Notifikation (wie im CCITT X.721 definiert) durch dieses gesteuerte Objekt unterstützt wird",
stateChangeNotificationPackage PRESENT IF (vorhanden, falls) "Die stateChange (Zustandsänderungs-) Notifikation (wie im CCITT X.721 definiert) durch dieses gesteuerte Objekt unterstützt wird",
NotificationStopPackage PRESENT IF (vorhanden, falls) "Das gesteuerte Objekt bedingungsabhängig daran gehindert werden soll, Notifikationen für eine weitere Verarbeitung in dem System zu emittieren.";
REGISTERED AS (registriert als) (gsm-12.02-objectclass);
In Fig. 6 wird ein spezielles Ausführungsbeispiel veranschaulicht, in dem beispielsweise ein Heimatortsregister HLR einen Prozessor umfasst. In den Fig. 6-10b veranschaulichten Ausführungsbeispielen wird angenommen, dass Notifikationen durch Ressourcenobjekte erzeugt werden. Wie im Vorhergehenden diskutiert können diese Notifikationen jedoch auch durch die gesteuerten Objekte (oder auf andere Weise) erzeugt werden, und die in Fig. 6-10b veranschaulichten Ausführungsbeispiele treffen natürlich auch darauf zu. Es muß sich natürlich nicht auf ein HLR beziehen, das Beispiel soll lediglich ein Beispiel veranschaulichen, in dem alle Objekte im gleichen Prozess (UNIX-Prozess) angeordnet sind. In diesem Fall könnte die Kommunikation zwischen Objekten effizient sein. Eine Kommunikation wird jedoch immer eine Kapazität erfordern, Nachrichten werden gesendet und empfangen. Aufgrund beispielsweise einer Änderung eines Ortsbereichs empfängt ein Ressourcenobjekt RO eines UNIX-Prozesses in dem HLR Information von einem Besucherortsregister VLR. Das RO, ausgenommen dann, wenn es durch das zusätzliche Attribut daran gehindert ist, sendet eine Kommunikation zur Datenbank DB und sendet auch eine RO Notifikation zu dem RO Notifikationsverteiler, der eine RO Notifikation zum gesteuerten Objekt MO senden kann. Dann wird eine MO Notifikation zu dem MO Notifikationsverteiler gesendet, und die MO Notifikation wird zum Agenten weiter gesendet, im Falle dass dies durch die EDF vorgesehen ist, wie oben erwähnt. Der Agent sendet dann einen Ereignisbericht zum Betriebssystem OS.
In einem anderen Ausführungsbeispiel der Erfindung, wie schematisch in Fig. 7 veranschaulicht, sind verschiedene Objekte in zwei unterschiedlichen Prozessen angeordnet. Die Anzahl zwei ist hier natürlich lediglich als Beispiel gegeben, es könnten auch mehr sein. Dann muss ein Adressiermechanismus zur Nachricht hinzugefügt werden, und die Nachricht muss eine Adressierungsinformation hinzufügen. In noch einem weiteren Ausführungsbeispiel, wie schematisch in Fig. 8 veranschaulicht, sind unterschiedliche Objekte in unterschiedlichen Prozessoren A, B angeordnet. Die Zwischenprozessorkommunikation wird durch einen Prozessorbus bereitgestellt. Eine Nachricht muss dann eine Adresse haben, die aufzeigt, wie der richtige Prozessor zu finden ist. Beispielsweise kann ein Prozessor A z. B. eines HLR Information von beispielsweise einem VLR hinsichtlich einer Änderung empfangen. Das Ressourcenobjekt RO des Prozessors A kann dann eine RO Notifikation zu einem RO Notifikationsverteiler (nicht gezeigt) des Prozessors A senden, der dann dieses zu einem gesteuerten Objekt des Prozessors B kommuniziert. Dieser gibt seinerseits eine MO Notifikation zum MO Notifikationsverteiler vom Prozessor B aus, der dann einen Ereignisbericht zu einem. Betriebssystem auf die gleiche Weise aussenden kann, wie im Vorhergehenden diskutiert. Falls eine Notifikation gestoppt wird, wird keine RO Notifikation emittiert. Die Anwendung der Erfindung auf Multi-Prozessorsysteme oder Systeme mit verteilten Prozessoren ist besonders vorteilhaft, da eine Reduktion einer Last von größter Wichtigkeit ist, da die erzeugte Last beträchtlich viel höher ist als in einem Einzelprozessorsystem.
Die mit Bezug auf Fig. 6, 7 und 8 diskutierten Ausführungsbeispiele betreffen natürlich nicht nur Prozessoren eines Heimatortsregisters, sondern auch Prozessoren in einem beliebigen gesteuerten System, und die Wertänderungen von Attributen eines gesteuerten Objektes müssen natürlich nicht Änderungen von Ortsbereichen betreffen, bereitgestellt durch VLRs etc., die Erfindung ist vielmehr auf alle Arten von Systemen anwendbar, in denen ein gesteuertes System durch ein steuerndes System gesteuert wird.
Die Erfindung betrifft auch den Fall, in dem ein untergeordnetes gesteuertes Objekt durch ein übergeordnetes Objekt gesteuert wird, das dann den Platz eines steuernden Systems oder eines Betriebssystems einnimmt.
Im folgenden werden einige weitere Ausführungsbeispiele der Erfindung kurz mit Bezug auf Fig. 9 und 10a, 10b beschrieben. Natürlich sind diese Ausführungsbeispiele unabhängig davon anwendbar, ob alle Objekte in einem Prozess enthalten sind, oder ob sie in unterschiedlichen Prozessen in einem und dem gleichen Prozessor oder auch unterschiedlichen Prozessoren angeordnet sind.
Die kurz mit Bezug auf Fig. 3 erwähnten Prinzipien sind hinsichtlich dieser Ausführungsbeispiele relevant, wie auch die im Vorhergehenden erwähnten.
Fig. 9 zeigt schematisch eine Möglichkeit, selektiv Notifikationen unter Verwendung von Aktionen anstelle von Attributen zu steuern. Eine Aktion wird dann pro MO hinzugefügt. Durch Aufrufen der Aktion wird ein Flag in dem RO an-/ausgeschaltet. Dieses Flag verhindert, dass das RO eine RO Notifikation aussendet. Durch erneutes Aufrufen dieser Aktion kann die RO Notifikation wieder angeschaltet werden.
Allgemein basiert die Verwendung einer Aktion auf den gleichen Prinzipien wie die Verwendung eines Attributs und das Ausführungsbeispiel ist natürlich auch anwendbar, wenn Notifikationen in gesteuerten Objekten erzeugt werden.
In Übereinstimmung mit einem anderen Ausführungsbeispiel der Erfindung wird ein notifikationssteuerndes gesteuertes Objekt MOcontrol eingesteuert. Ein MOcontrol umfasst ein Attribut/Aktion, die eine RO Notifikation (oder eine MO Notifikation) an-/ausschaltet. Die Menge von CMIP (Common Management Information Protocol) (Allgemeines Managementinformationsprotokoll) Operationen können dann reduziert werden. Nur eine MO Instanz muss erzeugt werden. Das/die Attribut/Aktion bestimmt, welchen MOs es erlaubt oder verboten sein soll, eine RO Notifikation auszusenden. Alternativ kann eine bestimmte MO Instanz ausgesucht werden, die RO Notifikationen an-/auszuschalten (oder eine MO Notifikation, falls Notifikationen in gesteuerten Objekten erzeugt werden).
Dieses Ausführungsbeispiel kann auf im wesentlichen zwei Arten ausgesteuert werden, von denen die erste in Fig. 10a veranschaulicht ist. Natürlich können beide Arten zum Ausführen des Ausführungsbeispiels bezüglich der Einführung eines notifikationssteuernden MO entsprechend angewendet werden, falls die Notifikationen in MO:s anstelle von RO:s erzeugt werden. MO bezieht sich in dieser Figur auf das MOcontrol, wie oben erwähnt. Wenn das notifikationssteuernde MOcontrol einen CMIP Betriebsvorgang empfängt, öffnet das MO alle RO:s, die durch den CMIP Betriebsvorgang bestimmt sind. In allen RO:s (RO A-RO D) wird die Notifikation an- /ausgeschaltet. Alternativ könnte das MOcontrol MO Instanzen berücksichtigen, anstelle von direkt dem RO. Das MOcontrol kann als permanente Daten gespeicherte Flags aufweisen, was beispielsweise dann vorteilhaft ist, wenn ein Betreiber sehen möchte, welchen Status die Flags aufweisen.
Eine zweite Möglichkeit zum Durchführen des Ausführungsbeispiels basierend auf einer Verwendung eines notifikationssteuernden gesteuerten Objekts MOcontrol ist schematisch in Fig. 10b veranschaulicht. Wenn das MOcontrol einen CMIP Betriebsvorgang empfängt, speichert das MOcontrol die CMIP Anfrage. Jedesmal, wenn eine RO Notifikation ausgesendet werden könnte, überprüft das RO, ob es dem RO (einem beliebigen der RO A-RO B) erlaubt ist, eine RO Notifikation auszusenden, oder nicht. Dieses ermöglicht einen schnellen Wechsel einer Änderung zwischen Erlaubnis/keiner Erlaubnis zum Aussenden einer Notifikation.
Falls viele Instanzen existieren wird eine ziemlich große Speichermenge benötigt, um alle Flags für alle MO Instanzen zu speichern. Diese Lösung ist vorteilhaft, falls eine Notifikation an-/ausgeschaltet werden kann pro MO Klasse.
Die Erfindung ist nicht auf die veranschaulichten Ausführungsbeispiele beschränkt, sondern kann auf eine Anzahl von Arten innerhalb des Umfangs der Ansprüche verändert werden.

Claims

1. Eine Anordnung mit mindestens einem gesteuerten System, das durch mindestens ein steuerndes System gesteuert wird, und wobei das gesteuerte System eine Anzahl von gesteuerten Objekten (MO) umfasst, die eine Anzahl von Ressourcen oder Ressourceobjekten (RO) darstellen, die durch das steuernde System (Systeme) überwacht und/oder gesteuert werden können, und wobei eine Kommunikation zwischen dem gesteuerten System und dem steuernden System (den steuernden Systemen) eine Übertragung von Ereignisberichten von einer Ereignisweiterleitungs- Diskriminatoreinrichtung (EFD/LDG) des gesteuerten Systems zu dem steuernden System (den steuernden Systemen), die sich aus Notifikationen ergeben, die innerhalb des gesteuerten Systems erzeugt und emittiert werden, wobei Notifikationen in gesteuerten Objekten (MO) und/oder in Ressourceobjekten erzeugt werden,

dadurch gekennzeichnet, dass

die Anordnung eine Notifikationssteuereinrichtung umfasst zum wahlweisen Steuern der Erzeugung und/oder Verteilung von Notifikationen intern im gesteuerten System, und dass die Notifikationssteuereinrichtung Verhindert, dass Notifikationen, die nicht in der Form von Ereignisberichten zu dem steuernden System zu kommunizieren sind, durch das gesteuerte Objekt (MO) und/oder das Ressourceobjekt (RO) erzeugt werden und/oder jeweilig zu der Ereignisweiterleitungs- Diskriminatoreinrichtung (EFD/LOG) zu emittiert werden.

2. Anordnung nach Anspruch 1, dadurch gekennzeichnet, dass die Notifikationssteuereinrichtung betreibergesteuert ist.

3. Anordnung nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Notifikationssteuereinrichtung einer Steuerung hinsichtlich einer Kategorie, etc., von Notifikationen bereitstellt, die unter gegebenen Bedingungen, etc. zu emittieren sind.

4. Anordnung nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Notifikationssteuereinrichtung ein zusätzliches Attribut umfasst, mittels dem mindestens eine Anzahl von Notifikationen bezüglich dieses Attributs gesteuert werden kann, z. B. ob sie von dem gesteuerten Objekt (MO) oder dem Ressourceobjekt (RO) zu emittieren sind oder nicht.

5. Anordnung nach Anspruch 4, dadurch gekennzeichnet, dass ein Paket das zusätzliche Attribute umfasst, z. B. ein Notifikationsstopp-Paket des gesteuerten Objekts.

6. Anordnung nach einem der Ansprüche 4 oder 5, dadurch gekennzeichnet, dass der zusätzliche Attributtyp (ASN.1) in Übereinstimmung mit den GDMO Spezifikationen definiert ist, und dass er eine Anzahl von Objektidentifizierungseinrichtungen (OID) umfasst, die Notifikationen identifizieren, die nicht zu emittieren sind.

7. Anordnung nach einem der Ansprüche 4-6, dadurch gekennzeichnet, dass das Notifikationsstopp-Paket ein bedingungsabhängiges Paket eines gesteuerten Objekts ist.

8. Anordnung nach einem der Ansprüche 4-6, dadurch gekennzeichnet, dass das Notifikationsstopp-Paket kein bedingungsabhängiges Paket eines gesteuerten Objekts ist.

9. Anordnung nach einem der Ansprüche 4-8, dadurch gekennzeichnet, dass die Attribute wertveränderte Notifikationen bezüglich eines Veränderungswertes sind.

10. Anordnung nach einem der Ansprüche 4-9, dadurch gekennzeichnet, dass Notifikationspakete bei der Entwicklung der Anordnung optional sind.

11. Anordnung nach einem der Ansprüche 4-10, dadurch gekennzeichnet, dass Attribute eines gesteuerten Objekts gespeichert und/oder berechnet werden.

12. Anordnung nach einem der Ansprüche 4-11, dadurch gekennzeichnet, dass Notifikationen pro Attribut an-/ausgeschaltet werden.

13. Anordnungen nach einem der Ansprüche 1-3, dadurch gekennzeichnet, dass die Notifikationssteuereinrichtung eine Aktion umfasst, hinzugefügt für jedes von mindestens einer Anzahl von gesteuerten Objekten.

14. Anordnung nach Anspruch 13, dadurch gekennzeichnet, dass dann, wenn die Aktion aufgerufen wird, ein Flag an/in einem gesteuerten Objekt (MO) oder einem Ressourceobjekt (RO) an-/ausgeschaltet wird, wobei es dem gesteuerten Objekt (MO) oder Ressourceobjekt (RO) verboten/erlaubt ist, eine Notifikation auszusenden.

15. Anordnung nach einem der Ansprüche 1-3, dadurch gekennzeichnet, dass die Notifikationssteuereinrichtung ein notifikationssteuerndes gesteuertes Objekt (MOcontrol) umfasst, mit einem/einer Attribut/Aktion zum an- /ausschalten einer Notifikation (MO; RO).

16. Anordnung nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Ressourcen oder die Ressourceobjekte (RO) physisch und/oder logisch und/oder funktional sind.

17. Anordnung nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das gesteuerte System einen Prozessor umfasst, und dass alle gesteuerten Objekte (MO) innerhalb dem einem und dem selben Prozess angeordnet sind.

18. Anordnung nach Anspruch 17, dadurch gekennzeichnet, dass die gesteuerten Objekte (MO) in unterschiedlichen Prozessen in ein und dem selben Prozessor angeordnet sind.

19. Anordnung nach einem der Ansprüche 1-16, dadurch gekennzeichnet, dass das gesteuerte System eine Verarbeitungsanordnung umfasst, mit einer Anzahl von Prozessoren, die über eine Zwischenprozessorkommunikationseinrichtung verbunden sind, und dass die gesteuerten Objekte in unterschiedlichen Prozessoren angeordnet sind.

20. Ein Telekommunikationssystem mit einem oder mehreren Betriebssystemen (OS), die eine Anzahl von Netzelementen (NE) steuern, mit einer Anzahl von gesteuerten Objekten (MO), die eine Anzahl von Ressourcen oder Ressourceobjekten (RO) darstellen, und einer Schnittstelle (Q3) mit einem Kommunikationsprotokoll zwischen den Betriebssystemen (OS) und dem gesteuerten Objekt (den gesteuerten Objekten) (MO), wobei weiter eine Funktion implementiert ist, die ein Senden von Notifikationen umfasst, was ein Senden von Ereignisberichten von Ereignisweiterleitungs- Diskriminatoreinrichtungen (EFD; LOG) des Netzelements (der Netzelemente) (NE) zu dem Betriebssystem (OS) ergibt,

dadurch gekennzeichnet, dass

das gesteuerte System eine Notifikationssteuerungseinrichtung umfasst zum wahlweisen Steuern der Erzeugung und/oder Verteilung von Notifikationen von den gesteuerten Objekten (MO) oder den Ressourceobjekten (RO) innerhalb des Netzelements, wodurch die innerhalb des Netzelements (NE) erzeugte Last gesteuert wird, und dass die Notifikationssteuereinrichtung verhindert, dass Notifikationen, die nicht zum steuernden System in der Form von Ereignisberichten zu kommunizieren sind, erzeugt werden und/oder durch das gesteuerte Objekt (MO) und/oder das Ressourceobjekt (RO) jeweilig zu der Ereignisweiterleitungsunterscheidungseinrichtung (EFD/LOG) emittiert werden.

21. Ein System nach Anspruch 20, wobei Daten der gesteuerten Objekte (MO) als Attribute bestimmt sind, dadurch gekennzeichnet, dass die Notifikationssteuereinrichtung ein zusätzliches Attribut umfasst, und dass die Aussendung Von Notifikationen pro Attribut durch das zusätzliche Attribut gesteuert wird.

22. Ein System nach Anspruch 20, dadurch gekennzeichnet, dass die Notifikationssteuereinrichtung eine zusätzliche Aktion pro gesteuertes Objekt umfasst, und, wenn die Aktion aufgerufen wird, ein Flag in einem gesteuerten Objekt (MO) oder einem Ressourcenobjekt (RO) an- /ausgeschaltet wird, was das Aussenden einer Notifikation verhindert/erlaubt.

23. Ein System nach Anspruch 20, dadurch gekennzeichnet, dass die Notifikationssteuereinrichtung ein notifikationssteuerndes steuerndes Objekt (MOcontrol) umfasst mit einem/einer Attribut/Aktion zum An- /Ausschalten von Notifikationen.

24. Ein Telekommunikationssystem nach einem der Ansprüche 20-23, dadurch gekennzeichnet, dass das gesteuerte System (die gesteuerten Systeme) verteilte Prozessoren umfasst/umfassen.

25. Ein Verfahren zum Steuern der Verteilung von Notifikationen bezüglich Ereignissen in Ressourcen oder Ressourceobjekten, repräsentiert durch gesteuerte Objekte in einem gesteuerten System, das durch mindestens ein steuerndes System gesteuert wird, wobei eine Kommunikation zwischen dem gesteuerten System und dem steuernden System (den steuernden Systemen) eine Übertragung von einem Ereignisbericht (Ereignisberichten) von einer Ereignisweiterleitungs- Diskriminatoreinrichtung (EFD; LDG) vom gesteuerten System zum steuernden System (den steuernden Systemen) umfasst, die sich aus innerhalb des gesteuerten Systems erzeugten und emittierten Notifikationen ergibt/ergeben,

dadurch gekennzeichnet, dass es die Schritte umfasst:

- Definieren eines zusätzlichen Attributs oder Aktion pro gesteuertes Objekt, oder eines notifikationssteuernden gesteuerten Objekts, das eine Notifikationssteuereinrichtung bildet,

- selektives Steuern, über die Notifikationssteuerungseinrichtung, der Erzeugung und/oder Verteilung der Notifikationen durch gesteuerte Objekte oder Ressourceobjekte pro Attribut/Aktion oder notifikationssteuerndem gesteuerten Objekt, so dass die Erzeugung/Verteilung von Notifikationen intern in dem gesteuerten System gesteuert wird, und dass die Notifikationssteuerungseinrichtung verhindert, dass Notifikationen, die nicht zu dem steuernden System in der Form von Ereignisberichten zu kommunizieren sind, erzeugt werden und/oder durch das gesteuerte Objekt (MO) und/oder das Ressourcenobjekt (RO) jeweilig zu der Weiterleitungsunterscheidungseinrichtung (EFD/LOG) emittiert werden.