-
TECHNISCHES GEBIET
-
Die vorliegende Erfindung betrifft eine Multi Domain Orchestrator zur domänenübergreifenden Koordination von Service-relevanten Maßnahmen eines Systembetreibers zum Sicherstellen von Qualitätsmerkmalen von domänenübergreifenden Services insbesondere des Systembetreibers. Ferner betrifft die vorliegende Erfindung ein entsprechendes Verfahren, beispielsweise bei der Koordination von Services im Zusammenhang mit Video-on-Demand-Anwendungen. Nicht zuletzt betrifft die vorliegende Erfindung auch die Verwendung von Bewertungsschemas zum Sicherstellen von Qualitätsmerkmalen von Services in einem derartigen Kontext. Insbesondere betrifft die Erfindung eine Vorrichtung bzw. Anordnung und ein Verfahren gemäß dem Oberbegriff des jeweiligen unabhängigen Anspruchs.
-
HINTERGRUND DER ERFINDUNG
-
Technische Dienstleistungen im Zusammenhang mit domänenübergreifenden Anwendungen werden zunehmend komplexer und müssen wohl auch in Zukunft noch flexibler auf spezifische Bedingungen im Zusammenhang mit den Wünschen und Forderungen und der Art und Weise des Datenkonsums einzelner Nutzer reagieren können. Um Dienste im Zusammenhang mit Telekommunikation skalierbar und flexibel steuern zu können, besteht ein Ansatz darin, diese in Domänen zu zerlegen, welche dabei einen so genannten „Bounded Context“ darstellen, also einen in sich abgeschlossenen Bereich (Produktionsbereich), mit welchem nur mittels wohldefinierter APIs interagiert werden darf. Dies liefert auch den Vorteil, dass die einzelnen Domänen in ihrem Innern autark weiterentwickelt und betrieben werden können, solange die APIs stabil bleiben. Die einzelnen Domänen erbringen insbesondere auf der Basis der von ihnen gemanagten bzw. verwalteten Infrastruktur bestimmte Services bzw. Dienste (im Folgenden wird der Begriff „Dienste“ synonym zum Begriff „Services“ verwendet). Diese können rein intern zur Anwendung kommen (so genannte Resource Facing Services) oder auch einen nach außen gerichteten, insbesondere für Nutzer (hier: Kunde) vorgesehenen Service darstellen (so genannte Customer Facing Services). Um Skalierungsvorteile eines solchen Domänenansatzes erzielen zu können, muss mehr als nur eine einzige Domäne vorhanden sein. Ein sinnvoller und möglicher Domänenschnitt (Zergliederung) kann unter Bezugnahme auf 1 oder 2 beschrieben werden.
-
Domänen werden durch eine Management Software (SW bzw. Computerprogramm) gesteuert, welche gleichzeitig dafür zuständig ist, der Domäne das wohldefinierte API zur Verfügung zu stellen. Diese SW kann hier als Domain Orchestrator bezeichnet werden. Ein Domain Orchestrator verwaltet die Vielzahl an Ressourcen in seiner Domäne und bietet nach „oben“ (im so genannten Northbound Interface, NBI) eine Service-Abstraktion an. Die Domäne „Transport“ muss z.B. eine Vielzahl an Routern und gegebenenfalls auch OTN-Geräten und optischen Links mit allen dazu gehörenden SW-Diensten und Protokollen verwalten. In ihrem NBI, der wohldefinierten API, könnte die Domäne „Transport“ dann z.B. einen VPN-Service anbieten.
-
Ein solcher Dienst benötigt bzw. erfordert ein komplexes Zusammenspiel einer Vielzahl von Infrastrukturkomponenten und deren Konfiguration. Nach „oben“ aber kann ein solcher Dienst jedoch auf sehr einfache Weise, also mit nur sehr wenigen Attributen, beschrieben werden: ein VPN weist einen Endpunkt A (mit IP Adresse und gegebenenfalls VLAN ID), einen Endpunkt B (ebenfalls mit IP Adresse und VLAN ID) und gegebenenfalls noch Service Level Agreements auf, die eine Aussage über die maximal zulässige Latenz, die benötigte Bandbreite und dergleichen machen. Die zahlreichen Eigenheiten der zugrundeliegenden Infrastruktur mit allen Konfigurations-Artefakten sind dabei auf der Service-Ebene (also für Konsumenten eines VPN-Dienstes) überhaupt nicht mehr relevant; anders ausgedrückt: sie können also (weg-)abstrahiert werden, so dass ein Konsument (Nutzer, Kunde) sich nicht damit befassen muss.
-
Um Services bereitstellen zu können, die aus Sub-Services mehrerer Domänen bestehen, wird eine domänenübergreifende Management-SW benötigt, die hier im Folgenden als Multi-Domain Orchestrator (MDO) bezeichnet werden kann. Ein domänenübergreifender Service könnte z.B. aus einer Enterprise-CPE bestehen, die über ein nutzerspezifisches VPN an eine nutzerspezifische IMS-Instanz angebunden ist, um so ein abgeschottetes Voice- und/oder Videonetz für einen Abnehmer mit einer großen Anzahl von Nutzern zu realisieren. In diesem Beispiel würden wohl Sub-Services der vier folgenden Domänen benötigt: Customer Equipment, Access, Transport und Voice. Ein MDO würde nun die Sub-Services bei den Domänen anfordern und zu einem übergreifenden Dienst für einen Abnehmer mit einer großen Anzahl von Nutzern zusammenstellen.
-
Um eine optimale Qualität des übergeordneten Dienstes (hier im Folgenden als Multi-Domain Service MDS bezeichnet) im laufenden Betrieb sicherstellen zu können, muss der MDO diejenigen Attribute überwachen, welchem dem MDO von den Domain Orchestratoren insbesondere als Teil von deren Service-Modell zur Verfügung gestellt wurden. Wie zuvor beschrieben, besteht auf dieser (Service-)Ebene nur noch eine sehr eingeschränkte Auswahl von Attributen, da der Vorteil des Domain Orchestrators insbesondere darin besteht, die hohe Komplexität der Serviceerbringung innerhalb seiner Domäne abstrahieren zu können. Es kann/darf dabei auch nicht als Lösung erachtet werden, dass ein MDO Wissen über die Abläufe und Zusammenhänge innerhalb der einzelnen Domänen haben bzw. verstehen können soll, um seine MDS betreiben zu können. Ein solcher allwissender MDO würde wohl eine technisch nachteilige Engstelle darstellen (im Sinne eines Flaschenhalses, „bottle neck“) und würde wohl auch zu zahlreichen Skalierungs- und Konsistenzproblemen führen.
-
Dennoch muss ein MDO insbesondere in Hinblick auf ein gutes Qualitätsniveau die im jeweiligen Kontext verfügbaren Handlungsoptionen verstehen können, insbesondere dann, wenn ein MDS droht, die versprochenen SLAs zu verletzen. Die Schwierigkeit in der praktischen Umsetzung besteht nun auch darin, dass es im jeweiligen Einzelfall verschiedene Maßnahmen-Optionen geben kann: Bei einer Servicedegradation können/müssen unter Umständen mehrere Domänen zu einer Verbesserung oder Lösung der Situation beitragen. Im ungünstigen Fall reicht eine Anpassung innerhalb einer einzigen Domäne auch gar nicht aus, um ein Qualitätsproblem beheben zu können, sondern es müssen mehrere Domänen zur Adressierung eines Problems beitragen. Der MDO benötigt also eine Möglichkeit bzw. Fähigkeit, auf der generischen Service-Ebene verstehen und unterscheiden zu können, welche Domäne in welchem Kontext zu einer Qualitätsverbesserung beitragen kann, ohne dabei die Service-Abstraktion der Domain Orchestratoren zu umgehen, also ohne dass sich der MDO wieder mit Detailaspekten zur Infrastruktur beschäftigen muss.
-
Ein Beispiel soll das hier allgemein beschriebene folgende Problem verdeutlichen: Ein Video-on-Demand-Dienst soll Videos und Filme aus der Mediathek des Netzbetreibers zum Smartphone des jeweiligen Nutzers streamen. So ein Dienst würde also ein Smartphone, einen Mobile Access, möglicherweise ein Edge CDN (Content Distribution Network), einen Transport durch das Backbone und einen Videoserver im Core beinhalten. Angenommen, die Bandbreite der Verbindung wäre zu klein, sodass die Übertragung des Videos beim Nutzer gestört ist (Ruckeln, zeitliche Unterbrechungen und/oder Verzerrungen). Mögliche Handlungsoptionen wären hier:
- - der (Mobile) Access alloziert mehr Bandbreite und/oder QoS für den Nutzer;
- - das CDN beschafft den Video-Content von einem anderen Cache aus dem Netz, zu dem eine bessere Verbindung besteht;
- - der Transport wählt ein anderes Routing für die Videoübertragung;
- - der Videoserver schaltet auf einen anderen Video-Codec, der für die aktuelle Bandbreite bessere Qualität liefern kann;
-
Der MDO muss in einer derartigen Situation also in der Lage sein, intelligent aus verschiedenen Optionen auszuwählen bzw. Optionen verschiedener Domänen zu kombinieren, bis die gewünschte Service Qualität wieder sichergestellt werden kann. Demnach besteht Interesse an einem MDO, respektive einer MDO-Anordnung mittels welcher eine domänenübergreifende Koordination von Optimierungsmaßnahmen vereinfacht werden kann.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Aufgabe ist, ein MDO und ein Verfahren zur domänenübergreifenden Koordination von Service-relevanten Maßnahmen bereitzustellen, womit domänenspezifische Maßnahmen zum Sicherstellen einer guten Qualität des jeweiligen Services vorgegeben werden können. Auch ist es Aufgabe, den MDO, eine MDO-Anordnung und das Verfahren zur domänenübergreifenden Koordination derart auszugestalten bzw. auszuführen, dass domänenspezifische Maßnahmen-Optionen in Abhängigkeit von im Einzelfall involvierten Domänen identifiziert und hinsichtlich deren Relevanz klassifiziert werden können.
-
Diese Aufgabe wird durch einen Multi Domain Orchestrator gemäß Anspruch 1 sowie durch ein Verfahren gemäß dem nebengeordneten Verfahrensanspruch gelöst. Vorteilhafte Weiterbildungen der Erfindung werden in den jeweiligen Unteransprüchen erläutert. Die Merkmale der im Folgenden beschriebenen Ausführungsbeispiele sind miteinander kombinierbar, sofern dies nicht explizit verneint ist.
-
Bereitgestellt wird ein Multi Domain Orchestrator zur domänenübergreifenden Koordination von Service-relevanten Maßnahmen eines Systembetreibers zum Sicherstellen von Qualitätsmerkmalen von domänenübergreifenden Services (Diensten) insbesondere des Systembetreibers.
-
Erfindungsgemäß wird vorgeschlagen, dass der Multi Domain Orchestrator eingerichtet ist, die Koordination basierend auf jeweils mit wenigstens einem Qualitätsmerkmal wenigstens eines Services korrelierter Service Quality Indicators (SQI) vorzunehmen, wobei der jeweilige Service Quality Indicator (SQI) mit wenigstens einer Service-relevanten Maßnahme und/oder mit einer der Domänen korreliert ist, wobei der Multi Domain Orchestrator für die Service Quality Indicators (SQI) wenigstens ein Bewertungsschema vordefiniert, mittels welchem eine domänenspezifische Abstraktion vordefinierter standardisierter Service-relevanter Maßnahmen-Optionen hinsichtlich einer vorgegebenen oder domänenspezifisch vorgebaren Gruppe von Bewertungsfaktoren für die domänenspezifische Relevanz der jeweiligen Maßnahme vorgebbar ist, und basierend auf welchem jeweiligen SQI-spezifischen Bewertungsschema die zu priorisierende Service-relevante Maßnahme auswählbar und zum Sicherstellen des jeweiligen Qualitätsmerkmals durch die jeweilige Domäne vorgebbar ist. Dies liefert nicht zuletzt auch eine starke Vereinfachung bei der Koordination, Gewichtung und Auswahl von sich auf die Qualität eines Services auswirkenden Maßnahmen. Somit kann auch eine domänenübergreifende Koordination insbesondere von Service-relevanten KPIs auf sehr effiziente Weise und mit gutem qualitätssteigernden Effekt für die involvierten Instanzen bereitgestellt werden. Die Erfindung kann auch in einer entsprechend eingerichteten Multi Domain Orchestrator-Anordnung liegen.
-
Die Erfindung kann allgemein auch wie folgt beschrieben werden: Um eine gewünschte oder geforderte Servicequalität domänenübergreifend zusichern zu können, werden in einem E2E-Service-Modell hier so bezeichnete Service Quality Indicators (SQIs) eingeführt. Jedes SQI beschreibt ein Qualitätsmerkmal eines Dienstes, welches vom MDO zugesichert werden soll. Dabei enthält das E2E-Service-Modell bevorzugt auch eine Dekomposition der einzelnen SQIs in Domänen bzw. in domänenspezifische Maßnahmen. Darauf basierend kann der MDO ermitteln, welche Domäne zur Steuerung eines E2E-SQI beitragen kann. Die Dekomposition in domänenspezifische Maßnahmen kann dabei auch gewichtet sein/werden, um eine gewünschte Priorisierung der einzelnen Domänenbeiträge zu modellieren (z.B. Re-routing zunächst priorisieren, dann zweitrangig Einbeziehen des CDN, dann nachrangig Wechseln/Schalten zu einem alternativen Codec).
-
Das Service-Modell der einzelnen Domänen spezifiziert dabei für jede ihrer Maßnahmen(-Optionen) ein abstraktes Bewertungsschema:
- - erwartete Auswirkung der Maßnahmen-Option auf die Optimierung des E2E-SQI, z.B. in Form einer „Ampel“ (z.B. „Cache-Wechsel“: gelb [= mittelmäßige Verbesserung erwartet], „Re-Routing“: rot [= wenig Verbesserung erwartet], „Codec-Wechsel“: grün [= große Verbesserung erwartet]); die erwartete Auswirkung wird in der untenstehenden Struktur „Beitrag“ genannt;
- - negativer Einfluss/Impact der Maßnahmen-Option auf den Nutzer (Codec-Verschlechterung wird sich aus Sicht des Nutzers mit hoher Wahrscheinlichkeit als Verschlechterung des Dienstes wahrgenommen, Re-routing könnte zu einer Service-Interruption führen, etc.); der Impact ist definiert durch seine Dauer, durch die Häufigkeit seines Vorkommens im Rahmen einer Maßnahme, und durch die Intensität der Auswirkung auf den Nutzer; der negative Impact wird in der untenstehenden Struktur „Maßnahmen-Impact“ genannt;
- - „Kosten“ der Option für den Netz-/Systembetreiber, insbesondere in Form einer normalisierten Metrik (Allozieren von Bandbreite „Access Bandbreite“: 0.9 [= hohe Kosten], Realisieren eines alternativen Routings „Re-Routing“: 0.6 [= mittlere Kosten], „Codec-Wechsel“: 0 [= keine Kosten]); vergleiche dazu den Bewertungsfaktor „Kosten“ in der untenstehenden Struktur;
-
Da eine jeweilige Maßnahme zur Adressierung verschiedener SQIs herangezogen werden kann, und da sich die Bewertung einer Maßnahme je nach SQI ändert, ist bevorzugt ein (einziges) Bewertungsschema pro SQI vorgesehen.
-
Die obige Struktur zeigt die hier beispielhaft dargestellten Modellierungs-Artefakte skizzenhaft („Artefakte“ insbesondere im Sinne von durch Eigenschaften der Modellierung hervorgerufene Ergebnisse). Während kursiv gedruckte Werte den allgemeinen Wertebereich angeben, stellen normal gedruckte Werte konkrete Beispiele dar. Aus der gezeigten Struktur geht hervor, dass das Bewertungsschema einerseits auf E2E-Ebene implementiert ist und dort mehrere SQI und je SQI auch mehrere Domänen betreffen kann, und dass das Bewertungsschema andererseits auch auf Domänenebene implementiert ist und dort mehrere Maßnahmen und je Maßnahme auch mehrere SQI betreffen kann.
-
Die folgende Struktur zeigt beispielhaft abstrakte Modellartefakte anhand des oben beschriebenen konkreten Video-on-Demand-Dienstes.
-
Die konkreten Werte, welche die Instanzen eines Domänenmodells in ihren Bewertungsschemata bereitstellen, können je nach Erfordernis manuell von einem (Software-)Designer oder aber auch dynamisch vom Managementsystem der jeweiligen Domäne bzw. von der hier beschriebenen MDO-Anordnung ermittelt bzw. errechnet werden. Wenn eine Option einer Domäne im Zuge einer SQI-Zusicherung vom MDO getriggert wurde, wird diese Option in der Liste des Domänenmodells des Services bevorzugt adaptiert oder gekennzeichnet (z.B. Streichung, wenn kein besseres Routing oder kein besserer Cache mehr möglich ist, oder Neubewertung, solange noch weitere Codecs zur Verfügung stehen), damit gegebenenfalls weitere Maßnahmen(-Optionen) mittels des MDO treffsicher ausgewählt werden können, wenn die wenigstens eine bereits vorgenommene Maßnahme zur Behebung des SQI-Problems noch nicht ausgereicht haben sollte.
-
Mithilfe des vorgeschlagenen abstrakten/abstrahierten Service-Modells auf E2E- und auf Domänen-Ebene ist der MDO bzw. die MDO-Anordnung eingerichtet, basierend auf einem oder mehreren Algorithmen zu entscheiden, welche Maßnahmen-Optionen der einzelnen Domänen zur Optimierung der E2E-SQIs heranzuziehen sind. Beispielsweise kann der folgende vergleichsweise einfache Algorithmus für die Maßnahmen-Auswahl zugrunde gelegt werden, basierend auf welchem solange weitere Maßnahmen durchführt werden (in der Reihenfolge ihrer Priorität), bis das SQI-Problem behoben bzw. gelöst ist:
-
-
Ein etwas tiefergehender bzw. intelligenterer Algorithmus könnte auch auf die Prioritäten des E2E-Modells verzichten, indem aus den Attributen der einzelnen Domänen-Maßnahmen eine „optimale“ Priorität errechnet/bestimmt wird, z.B. auf Grundlage des folgenden Zusammenhangs:
-
Funktion ermittle _Priorität Maßnahme m, SQI q)
-
-
In diesem Beispiel wird die Priorität aus den gewichteten Einzelattributen einer jeweiligen Maßnahmen-Option gebildet (die Funktion gew(x) gibt die Gewichtung eines Attributs zurück). Höhere Beiträge einer Maßnahmen-Option führen zu einer höheren Priorität, höherer (negativer) Impact und höhere Kosten führen zu einer niedrigeren Priorität.
-
Diese hier nur grob skizzierten Algorithmen sind nur beispielhaft zu verstehen; es ist offensichtlich, dass hier im Rahmen der vorliegenden Erfindung beliebig viele Optimierungsalgorithmen implementierbar sind. Die Erfindung ist hinsichtlich der Art und/oder Anzahl der Algorithmen zur Auswahl von Maßnahmen nicht beschränkt.
-
Das hier im Rahmen der Erfindung vorgeschlagene Modell (insbesondere das abstrahierte Service-Modell auf E2E- und auf Domänen-Ebene) ist ebenfalls beispielhaft zu verstehen und kann für einen jeweiligen Anwendungsfall erweitert bzw. adaptiert werden. Beispielsweise können Einschränkungen bzw. Bedingungen dahingehend modelliert werden, dass bestimmte domänenspezifische Maßnahmen(-Optionen) nur für bestimmte Korridore von SQI-Werten vorgeschlagen bzw. angewandt werden oder dass sich die Prioritäten der einzelnen Maßnahmen-Optionen je nach SQI-Abweichung verschieben.
-
Als „Orchestrator“ ist insbesondere einen Managementsoftware (Computerprogramm) zur Koordination mehrerer Sub-Services in einem übergeordneten Kontext zu verstehen, insbesondere zum flexiblen Kombinieren mehrerer Services zu einer Komposition oder zu einem vom jeweiligen Nutzer gewünschten Dienst.
-
Personifizierte Begriffe, soweit sie nicht im Neutrum formuliert sind, können im Rahmen der vorliegenden Offenbarung alle Geschlechter betreffen.
-
Die hier verwendeten englischsprachigen Ausdrücke oder Abkürzungen sind jeweils branchenübliche Fachausdrücke und sind dem Fachmann in englischer Sprache geläufig. Dazu synonym verwendete/verwendbare deutschsprachige Begriffe werden hier der Vollständigkeit halber in (Klammern) angegeben, oder vice versa, beispielsweise bezüglich des Begriffs Domäne (Domain).
-
Gemäß einem Ausführungsbeispiel ist der Multi Domain Orchestrator oder die Multi Domain Orchestrator-Anordnung eingerichtet, die zu priorisierende Service-relevante Maßnahme zumindest basierend auf wenigstens einem der folgenden Bewertungsfaktoren auszuwählen, insbesondere basierend auf wenigstens zwei Bewertungsfaktoren oder all diesen Bewertungsfaktoren: Optimierungs-Beitrag der jeweiligen Maßnahme (erwartete Optimierungs-Auswirkung), negativer Einfluss/Impact der jeweiligen Maßnahme (negativer Maßnahmen-Impact), Kosten der jeweiligen Maßnahme insbesondere für den Systembetreiber (relative Kosten der Maßnahme im Vergleich zu weiteren möglichen Maßnahmen des Systembetreibers). Speziell diese Bewertungsfaktoren liefern eine gute Grundlage für eine Priorisierung der einzelnen Maßnahmen-Optionen.
-
Gemäß einem Ausführungsbeispiel ist je Service Quality Indicator genau ein spezifisches Bewertungsschema vordefiniert. Dies ermöglicht auch, weitere Randbedingungen bei einem jeweiligen Service oder weitere Einflüsse bei der Auswirkung einer jeweiligen qualitätssteigernden Maßnahme zu berücksichtigen. Die Art und Weise der Bewertung kann weiter individualisiert werden.
-
Gemäß einem Ausführungsbeispiel sind die einzelnen Service Quality Indicators (SQI) in Domänen oder domänenspezifische Maßnahmen zergliedert (bzw. auf die einzelnen Domänen verteilt oder dazu korreliert), insbesondere bei einer vordefinierbaren/vordefinierten Gewichtung der einzelnen domänenspezifische Maßnahmen-Optionen zur Modellierung einer/der jeweils domänenspezifisch empfehlenswerten Priorisierung. Diese Korrelation kann eine/die Auswahl und Priorisierung auf noch spezifischere Weise realisieren.
-
Gemäß einem Ausführungsbeispiel weist der Multi Domain Orchestrator oder die Multi Domain Orchestrator-Anordnung eine Recheneinheit mit einem Daten-/Programmspeicher mit darin hinterlegtem Computerprogrammcode auf, wobei der Computerprogrammcode wenigstens einen Algorithmus zur Auswahl der zu priorisierenden Service-relevanten Maßnahme umfasst, insbesondere einen zur Priorisierung der einzelnen Maßnahmen-Optionen iterativ ablaufenden Algorithmus und/oder einen eine domänenspezifische Priorität einer Maßnahmen-Option aus gewichteten Einzelattributen dieser Maßnahmen-Option ermittelnden Algorithmus. Dies kann die Anwendung der Dienstekomposition weiter vereinfachten und auch weniger aufwändig ausgestalten, insbesondere durch Verzicht auf händische/personifizierte Interaktion.
-
Gemäß einem Ausführungsbeispiel ist ein Daten-/Programmspeicher des Multi Domain Orchestrators oder der Multi Domain Orchestrator-Anordnung mit darin hinterlegtem Computerprogrammcode zum Erstellen des SQI-spezifischen Bewertungsschemas und zum Auswählen einer Maßnahme aus den Maßnahmen-Optionen basierend auf einer Modellierung einerseits auf E2E-Ebene und andererseits auf Domänenebene vorgesehen. Dies ermöglicht auch eine möglichst differenzierte Berücksichtigung von Besonderheiten sowohl auf E2E-Seite als auch auf Domänen-Seite. Auf E2E-Ebene erfolgt beispielsweise eine Gliederung nach einzelnen SQIs, wobei je SQI mehrere Domänen und auch mehrere Maßnahmen je Domäne gelistet sein können, und auf Domänen-Ebene erfolgt beispielsweise eine Gliederung nach einzelnen Maßnahmen-(Optionen), wobei je Maßnahme mehrere SQIs gelistet sein können.
-
Die zuvor genannte Aufgabe wird wie erwähnt auch gelöst durch ein Verfahren gemäß dem entsprechenden nebengeordneten Verfahrensanspruch, nämlich durch ein Verfahren zur domänenübergreifenden Koordination von Service-relevanten Maßnahmen eines Systembetreibers mittels eines Multi Domain Orchestrators, insbesondere mittels einer zuvor weiter oben beschriebenen Multi Domain Orchestrator-Anordnung, zum Sicherstellen von Qualitätsmerkmalen von domänenübergreifenden Services (Diensten) des Systembetreibers, wobei jeweils mit wenigstens einem Qualitätsmerkmal wenigstens eines Services korrelierte Service Quality Indicators (SQI) definiert werden, wobei der jeweilige Service Quality Indicator (SQI) mit wenigstens einer Service-relevanten Maßnahme und/oder mit einer der Domänen korreliert ist/wird, wobei für die Service Quality Indicators (SQI) wenigstens ein Bewertungsschema vordefiniert ist/wird, mittels welchem eine domänenspezifische Abstraktion vordefinierter standardisierter Service-relevanter Maßnahmen-Optionen hinsichtlich einer vorgegebenen oder domänenspezifisch vorgebaren Gruppe von Bewertungsfaktoren für die domänenspezifische Relevanz der jeweiligen Maßnahme erfolgt, und basierend auf welchem jeweiligen SQI-spezifischen Bewertungsschema die zu priorisierende Service-relevante Maßnahme ausgewählt und zum Sicherstellen des jeweiligen Qualitätsmerkmals durch die jeweilige Domäne vorgegeben wird. Dies liefert zuvor genannte Vorteile, insbesondere hinsichtlich einer effizienten und fehlerunanfälligen Dienstekomposition mit guter Reaktionszeit und vorteilhaftem Qualitätseffekt für den/die Nutzer.
-
Gemäß einem Ausführungsbeispiel umfasst die Gruppe von Bewertungsfaktoren für die domänenspezifische Relevanz der jeweiligen Maßnahme zumindest die folgenden Bewertungsfaktoren: Optimierungs-Beitrag der jeweiligen Maßnahme (erwartete Optimierungs-Auswirkung, hier als „Beitrag“-Bewertungsfaktor bezeichnet), negativer Einfluss/Impact der jeweiligen Maßnahme (negativer Maßnahmen-Impact, hier als „Maßnahmen-Impact“-Bewertungsfaktor bezeichnet), Kosten der jeweiligen Maßnahme insbesondere für den Systembetreiber (relative Kosten der Maßnahme im Vergleich zu weiteren möglichen Maßnahmen des Systembetreibers; hier als „Kosten“-Bewertungsfaktor bezeichnet).
-
Gemäß einem Ausführungsbeispiel umfassen die vordefinierten standardisierten Service-relevanten Maßnahmen-Optionen zumindest die folgenden Optionen: Allozieren von zusätzlicher Brandbreite und/oder höherer QoS, Einbeziehen des CDN zum Bereitstellen des angeforderten Content von einer alternativen Quelle (Cache), Realisieren eines alternativen Routings, Wechseln/Schalten zu einem alternativen Codec.
-
Gemäß einem Ausführungsbeispiel ist/wird je Service Quality Indicator genau ein spezifisches Bewertungsschema vordefiniert.
-
Gemäß einem Ausführungsbeispiel sind/werden die einzelnen Service Quality Indicators (SQI) in Domänen oder domänenspezifische Maßnahmen zergliedert, insbesondere bei einer vordefinierbaren/vordefinierten Gewichtung der einzelnen domänenspezifische Maßnahmen-Optionen zur Modellierung einer/der jeweils domänenspezifisch empfehlenswerten Priorisierung.
-
Gemäß einem Ausführungsbeispiel werden die Service Quality Indicators (SQI) auf E2E-Ebene definiert und die einzelnen Service Quality Indicators (SQI) sind/werden in Domänen oder domänenspezifische Maßnahmen zergliedert und sind/werden mit einer oder mehreren Maßnahmen-Optionen korreliert. Hierdurch lassen sich jeweils die bereits zuvor beschriebenen Vorteile erzielen.
-
Gemäß einem Ausführungsbeispiel wird wenigstens ein Algorithmus zur Auswahl der zu priorisierenden Service-relevanten Maßnahme einbezogen, insbesondere ein zur Priorisierung der einzelnen Maßnahmen-Optionen iterativ ablaufender Algorithmus.
-
Gemäß einem Ausführungsbeispiel wird zur Koordination der Service-relevanten Maßnahmen wenigstens einen Algorithmus einbezogen, welcher eine domänenspezifische Priorität einer Maßnahmen-Option aus gewichteten Einzelattributen dieser Maßnahmen-Option ermittelt.
-
Gemäß einem Ausführungsbeispiel erfolgt zum Erstellen des SQI-spezifischen Bewertungsschemas und zum Auswählen einer Maßnahme aus den Maßnahmen-Optionen eine Modellierung einerseits auf E2E-Ebene und andererseits auf Domänenebene (abstrahiertes Service-Modell auf E2E- und auf Domänen-Ebene). Hierdurch lassen sich jeweils die bereits zuvor beschriebenen Vorteile erzielen.
-
Gemäß einem Ausführungsbeispiel wird bei der Auswahl einzelner Maßnahmen eine jeweilige bereits in Betracht gezogene domänenspezifische Maßnahmen-Option adaptiert oder gekennzeichnet, insbesondere in einer Liste eines Domänenmodells des jeweiligen Services, zur weiteren Auswahl weiterer Maßnahmen aus einem adaptierten Katalog von Maßnahmen-Optionen. Dies kann auch die Auswahl und weitere Priorisierung von ebenfalls noch attraktiven oder vermutlich effektiven/effizienten Maßnahmen erleichtern.
-
Die ausgewählte und vorgegebene Service-relevante Maßnahme kann dabei auch eine Koordinations-Maßnahme sein, welche basierend auf der vorgenommenen Priorisierung aus den Maßnahmen-Optionen ausgewählt wird.
-
Die zuvor genannte Aufgabe wird wie erwähnt auch gelöst durch ein Computerprogrammprodukt umfassend Befehle, die bei Ausführung des Computerprogrammproduktes auf einem Computer diesen dazu veranlassen, ein zuvor weiter oben beschriebenes Verfahren auf dem Computer auszuführen, insbesondere Computerprogrammprodukt in Ausgestaltung als Multi Domain Orchestrator eingerichtet zur domänenübergreifenden Koordination von wenigstens zwei Service-relevanten Maßnahmen aus der folgenden Gruppe: Allozieren von zusätzlicher Brandbreite und/oder höherer QoS, Einbeziehen des CDN zum Bereitstellen des angeforderten Content von einer alternativen Quelle, Realisieren eines alternativen Routings, Wechseln/Schalten zu einem alternativen Codec; und wobei der Multi Domain Orchestrator eingerichtet ist zum Ermitteln einer domänenspezifischen Relevanz einer jeweiligen Maßnahmen-Option basierend auf wenigstens zwei Bewertungsfaktoren aus der folgenden Gruppe: Optimierungs-Beitrag, negativer Einfluss/Impact, Kosten; und wobei der Multi Domain Orchestrator eingerichtet ist zum Auswählen einer Maßnahme in Abhängigkeit von deren Relevanz. Dies erleichtert nicht zuletzt auch eine automatisierte Implementierung.
-
Die zuvor genannte Aufgabe wird demnach auch gelöst durch einen Datenträger mit einem solchen darauf hinterlegten Computerprogrammprodukt oder durch einen Computer oder ein Computersystem oder eine virtuelle Maschine oder wenigstens ein Hardwareelement mit einem solchen Computerprogrammprodukt.
-
Die zuvor genannte Aufgabe wird wie erwähnt auch gelöst durch Verwendung eines Bewertungsschemas zur domänenübergreifenden Koordination von Service-relevanten Maßnahmen eines Systembetreibers und zum Sicherstellen von Qualitätsmerkmalen von domänenübergreifenden Services des Systembetreibers, wobei wenigstens ein Service Quality Indicator (SQI) definiert wird, der mit wenigstens einem Qualitätsmerkmal wenigstens eines Services korreliert ist/wird und mit wenigstens einer Service-relevanten Maßnahme und mit einer der Domänen korreliert ist/wird, wobei das Bewertungsschema zum domänenspezifischen und SQI-spezifischen Abstrahieren und Priorisieren vordefinierter standardisierter Service-relevanter Maßnahmen-Optionen unter Bezug auf eine Gruppe von Bewertungsfaktoren für die domänenspezifische Relevanz der jeweiligen Maßnahme verwendet wird, insbesondere Verwendung eines/des SQI-spezifischen Bewertungsschemas zum Auswählen einer Maßnahme aus den Maßnahmen-Optionen basierend auf einer Modellierung der SQI-spezifischen Bewertung (beispielsweise mit einem/dem SQI für Videoqualität) einerseits auf E2E-Ebene und andererseits auf Domänenebene. Hierdurch ergeben sich zuvor genannte Vorteile.
-
Zusammenfassung: Bei der Steuerung/Regelung des Zusammenspiels von domänenübergreifenden Infrastrukturkomponenten und Services (Diensten) und deren Konfiguration ist es wünschenswert, eine im jeweiligen Einzelfall zu favorisierende Optimierungs-Maßnahme auf einfache und belastbare Weise auszuwählen und umzusetzen. Erfindungsgemäß wird eine Multi Domain Orchestrator-Anordnung zur domänenübergreifenden Koordination von Service-relevanten Maßnahmen eines Systembetreibers zum Sicherstellen von Qualitätsmerkmalen von domänenübergreifenden Services des Systembetreibers bereitgestellt, wobei die Multi Domain Orchestrator-Anordnung die Koordination basierend auf jeweils mit wenigstens einem Qualitätsmerkmal wenigstens eines Services korrelierter Service Quality Indicators (SQI) vornimmt und für die Service Quality Indicators (SQI) wenigstens ein Bewertungsschema zur domänenspezifischen Abstraktion vordefinierter standardisierter Service-relevanter Maßnahmen-Optionen hinsichtlich Bewertungsfaktoren vordefiniert, wobei die zu priorisierende Service-relevante Maßnahme basierend auf dem jeweiligen Bewertungsschema ausgewählt und vorgegeben wird. Hierdurch kann die Servicequalität auf sowohl für die Nutzer als auch für den/die Systembetreiber auf effiziente und vorteilhafte Weise optimiert werden.
-
Figurenliste
-
In den nachfolgenden Zeichnungsfiguren wird die Erfindung noch näher beschrieben, wobei für Bezugszeichen, die nicht explizit in einer jeweiligen Zeichnungsfigur beschrieben werden, auf die anderen Zeichnungsfiguren verwiesen wird. Es zeigen:
- 1 ein beispielhafter Domänenschnitt zur Realisierung von Skalierungsvorteilen;
- 2 ein weiterer beispielhafter Domänenschnitt zur Realisierung von Skalierungsvorteilen;
- 3 in schematischer Darstellung einen Aufbau einer Multi Domain Orchestrator-Anordnung gemäß einem Ausführungsbeispiel bzw. die Interaktion der in einer solchen Anordnung agierenden Komponenten, zur Realisierung des erfindungsgemäßen Verfahrens;
-
DETAILLIERTE BESCHREIBUNG DER FIGUREN
-
Die Erfindung wird zunächst unter allgemeiner Bezugnahme auf alle Bezugsziffern und Figuren erläutert. Besonderheiten bzw. Einzelaspekte der vorliegenden Erfindung werden im Zusammenhang mit der jeweiligen Figur thematisiert.
-
Bereitgestellt wird eine Multi Domain Orchestrator-Anordnung 100 zur domänenübergreifenden Koordination von Service-relevanten Maßnahmen eines Systembetreibers zum Sicherstellen von Qualitätsmerkmalen von domänenübergreifenden Services des Systembetreibers. Die Multi Domain Orchestrator-Anordnung 100 ist eingerichtet, die Koordination basierend auf jeweils mit wenigstens einem Qualitätsmerkmal wenigstens eines Services korrelierter Service Quality Indicators (SQI) vorzunehmen, wobei der jeweilige Service Quality Indicator (SQI) mit wenigstens einer Service-relevanten Maßnahme und/oder mit einer der Domänen 10, 20, 30, 40, 50, 60 korreliert ist. Die Multi Domain Orchestrator-Anordnung 100 definiert für die Service Quality Indicators (SQI) wenigstens ein Bewertungsschema, mittels welchem eine domänenspezifische Abstraktion vordefinierter standardisierter Service-relevanter Maßnahmen-Optionen hinsichtlich einer vorgegebenen oder domänenspezifisch vorgebaren Gruppe von Bewertungsfaktoren für die domänenspezifische Relevanz der jeweiligen Maßnahme vorgebbar ist, und basierend auf welchem jeweiligen SQI-spezifischen Bewertungsschema die zu priorisierende Service-relevante Maßnahme auswählbar und zum Sicherstellen des jeweiligen Qualitätsmerkmals durch die jeweilige Domäne vorgebbar ist. Beispielhaft können die folgenden Arten von Domänen und Services genannt werden: Customer Equipment-Domäne (Domain) bzw. Customer Equipment Services 10, insbesondere umfassend CPE MM Services 11 und/oder SD WAN Services 12; Access-Domäne bzw. Access Services 20, insbesondere umfassend Fixed Access Services 21 und/oder Radio Access Services 22; CDN-Domäne bzw. Edge Cloud Services 30; Transport-Domäne bzw. Transport Services 40; Streaming-Domäne 50, insbesondere umfassend eine Voice-Domäne bzw. Voice Core Services 51 und/oder eine Data-Domäne bzw. Data Core Services 52 und/oder eine Video-Domäne bzw. TV Core Services 53 und/oder weitere OTT Services 54 („Over the top“-Services über Internet-Kommunikationspfade); externe Services 60.
-
Dabei weist die Multi Domain Orchestrator-Anordnung 100 wenigstens einen Multi Domain Orchestrator 101 auf und wenigstens einen Daten-/Programmspeicher 102 zurückgreifen oder diese Komponenten umfassen, insbesondere auch zum Bereitstellen eines Computerprogrammprodukts 110, insbesondere mit Multi Domain Orchestrator-Funktion. Das Computerprogramm(-produkt) ist eingerichtet zur Interaktion mit dem jeweiligen wohldefinierten API 1 bzw. mit der jeweiligen Domäne über das jeweilige API bzw. eingerichtet zum Bereitstellen des/der jeweiligen API.
-
In der 1 ist ein beispielhafter Domänenschnitt (Zergliederung) veranschaulicht.
-
In der 2 ist ein weiterer möglicher Domänenschnitt (Zergliederung) veranschaulicht. Der Pfeil in 2 deutet eine Tendenz von Nutzer/Kunde zu Core an.
-
In der 3 sind einzelne Komponenten der hier beschriebenen Multi Domain Orchestrator-Anordnung 100 veranschaulicht. Der jeweilige SQI und die jeweilige API 1 sind/werden domänenspezifisch implementiert. Insoweit veranschaulicht 3, dass jeder SQI ein Qualitätsmerkmal eines spezifischen Dienstes bzw. einer spezifischen Domäne beschreiben kann.
-
Bezugszeichenliste
-
- 1
- (jeweiliges) wohldefiniertes API (Application Programming Interface bzw. Programmierschnittstelle)
- 10
- Customer Equipment-Domäne (Domain) bzw. Customer Equipment Services
- 11
- CPE MM Services
- 12
- SD WAN Services
- 20
- Access-Domäne bzw. Access Services
- 21
- Fixed Access Services
- 22
- Radio Access Services
- 30
- CDN-Domäne bzw. Edge Cloud Services
- 40
- Transport-Domäne bzw. Transport Services
- 50
- Streaming-Domäne
- 51
- Voice-Domäne bzw. Voice Core Services
- 52
- Data-Domäne bzw. Data Core Services
- 53
- Video-Domäne bzw. TV Core Services
- 54
- weitere OTT Services („Over the top“-Services über Internet-Kommunikationspfade)
- 60
- externe Services
- 100
- Multi Domain Orchestrator-Anordnung
- 101
- Multi Domain Orchestrator
- 102
- Daten-/Programmspeicher
- 110
- Computerprogrammprodukt, insbesondere Multi Domain Orchestrator
- SQI
- Service Quality Indicator bzw. Servicequalitätsindikator