DE102021213702A1 - Verfahren und System zum Betreiben eines Netzwerks - Google Patents

Verfahren und System zum Betreiben eines Netzwerks Download PDF

Info

Publication number
DE102021213702A1
DE102021213702A1 DE102021213702.4A DE102021213702A DE102021213702A1 DE 102021213702 A1 DE102021213702 A1 DE 102021213702A1 DE 102021213702 A DE102021213702 A DE 102021213702A DE 102021213702 A1 DE102021213702 A1 DE 102021213702A1
Authority
DE
Germany
Prior art keywords
network
variable
topology
function
interface
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102021213702.4A
Other languages
English (en)
Inventor
Heidrun Grob-Lipski
Henrik Klessig
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102021213702.4A priority Critical patent/DE102021213702A1/de
Publication of DE102021213702A1 publication Critical patent/DE102021213702A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS
    • H04L41/5019Ensuring fulfilment of SLA
    • H04L41/5025Ensuring fulfilment of SLA by proactively reacting to service quality change, e.g. by reconfiguration after service quality degradation or upgrade
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0896Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H04L41/0897Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities by horizontal or vertical scaling of resources, or by migrating entities, e.g. virtual resources or entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS
    • H04L41/5009Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852Delays
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876Network utilisation, e.g. volume of load or congestion level
    • H04L43/0894Packet rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Verfahren (200), insbesondere computerimplementiertes Verfahren (200), zum Betreiben eines Netzwerks (400), umfassend die folgenden Schritte:Erfassen (210) an wenigstens einer Schnittstelle (N1, N2, N4) des Netzwerks (400) wenigstens eine die Schnittstelle (N1, N2, N4) charakterisierende erste Größe (G1), wobei die erste Größe (G1) insbesondere Latenzzeit und/oder Bandbreite umfasst;Bestimmen (220) in Abhängigkeit von der wenigstens einen ersten Größe (G1) eine zweite Größe (G2), wobei die zweite Größe (G2) wenigstens eine Topologie des Netzwerks (400) charakterisiert, und,insbesondere optional, Anpassen (230) der Topologie des Netzwerks (400) basierend auf der zweiten Größe (G2).

Description

  • Stand der Technik
  • Die Offenbarung betrifft ein Verfahren, insbesondere computerimplementiertes Verfahren, zum Betreiben eines Netzwerks.
  • Die Offenbarung betrifft ein System zum Betreiben eines Netzwerks.
  • Auf dem Gebiet des IT-Managements werden unterschiedlichste Prozesse zur Installation von Softwareanwendungen auf Rechnern und in Rechenzentren gemeinhin unter dem Begriff der Softwareverteilung (Software Deployment) zusammengefasst.
  • Aus der DE102019211908A1 ist beispielsweise eine Verfahren zum dynamischen Verteilen von Anwendungen bekannt, wobei basierend auf Laufzeitanforderungen der Anwendung durch eine Anwendungsverwaltung zugeführt eine semantische Beschreibung der Laufzeitanforderungen erzeugt wird, die Beschreibung einer Laufzeitumgebung übergeben wird und die Anwendungen gemäß der Beschreibung innerhalb der Laufzeitumgebung anhand ihrer Laufzeitanforderungen wahlweise in einer Infrastruktur auf Cloud-Computing-Plattformen, Rechenzentren, Server oder Endgeräte verteilt werden. Die Infrastruktur besteht hierbei aus einer Reihe topologisch verteilter Knoten. Diese Knoten sind mit Ressourcen wie Datenverarbeitungseinheiten, Speicher usw. verknüpft. Sie sind zudem direkt oder indirekt miteinander und direkt oder indirekt mit Endgeräten verbunden.
  • Die Herausforderungen einer dynamischen und zuverlässigen Instanziierung von Anwendungen, beispielsweise Netzwerkfunktionen, NF, in einem 5G basierten Netzwerk, an verschiedenen Standorten können unter anderem darin bestehen, dass die zugrundeliegenden Netz- und Datenverarbeitungsinfrastrukturen, auf denen ein 5G-Netzwerk potenziell verteilt betrieben werden kann, vielfältig sind und daher unterschiedliche Leistungsdynamik aufweisen können, die oft nur bis zu einem gewissen Grad vorhersehbar ist. Dies macht es schwierig, den NFs und ihren Schnittstellen die erforderlichen Ressourcen zu garantieren. Beispielsweise können die Latenzzeit und die verfügbare Bandbreite zwischen mehreren Standorten unterschiedlich sein und darüber hinaus im Laufe der Zeit erheblich schwanken. Ferner können Firewalls und andere Zugangskontrollmechanismen innerhalb und zwischen den Netzwerken an verschiedenen Standorten für zusätzliche Verzögerungen auf der Steuer- und/oder Datenebene sorgen.
  • Der Offenbarung liegt die Aufgabe zugrunde, die aus dem Stand der Technik bekannten Nachteile zu überwinden.
  • Offenbarung der Erfindung
  • Beispielhafte Ausführungsformen beziehen sich auf ein Verfahren, beispielsweise ein computerimplementiertes Verfahren, zum Betreiben eines Netzwerks, umfassend die folgenden Schritte:
    • Erfassen an wenigstens einer Schnittstelle des Netzwerks wenigstens eine die Schnittstelle charakterisierende erste Größe, wobei die erste Größe insbesondere Latenzzeit und/oder Bandbreite umfasst;
    • Bestimmen in Abhängigkeit von der wenigstens einen ersten Größe eine zweite Größe, wobei die zweite Größe wenigstens eine Topologie des Netzwerks und/oder einer Änderung der Topologie des Netzwerks charakterisiert, und, insbesondere optional, Anpassen der Topologie des Netzwerks basierend auf der zweiten Größe.
  • Bei weiteren beispielhaften Ausführungsformen kann das Netzwerk beispielsweise zumindest teilweise bzw. bereichsweise als Drahtlosnetzwerk, ausgebildet sein, beispielsweise als, z.B. zelluläres, Mobilfunknetz, beispielsweise gemäß dem 5G-Standard.
  • Bei weiteren beispielhaften Ausführungsformen kann das Netzwerk beispielsweise zumindest teilweise bzw. bereichsweise als drahtgebundenes Netzwerk ausgebildet sein.
  • Bei weiteren beispielhaften Ausführungsformen kann das Netzwerk z.B. für die Ausführung von Software Defined Networking, SDN, Verfahren, ausgebildet sein.
  • SDN basierte Verfahren bieten Mittel zur zentralen Verwaltung von Datennetzflüssen sowohl auf Steuerebene als auch auf Datenebene, insbesondere innerhalb eines lokalen oder sogar eines größeren regionalen Netzwerks.
  • Bei weiteren beispielhaften Ausführungsformen kann das Netzwerk z.B. für die Ausführung von Network Function Virtualization, NFV, Verfahren, ausgebildet sein.
  • NFV basierte Verfahren zielen auf die Virtualisierung von Netzwerkfunktionen (NFs), wie z.B. Subscriber-Management- und Policy-Control-Funktionen, ab und stellen solche NFs in Form von Software-Instanzen auf Hardware und/oder in virtualisierten Umgebungen zur Verfügung
  • Moderne Mobilfunknetze entwickeln sich auf der Basis von begleitenden Technologien, insbesondere der Network Function Virtualization (NFV) und der Software-Defined Networking (SDN). 5G basierte Netzwerke sind mit beiden Technologien sowohl im Kernnetz, 5GC, und teilweise auch im Funkzugangsnetz, RAN, konzipiert. Die Kombination von NFV und SDN für 5G führt zur 5G Service Based Architecture, SBA, die alle erforderlichen NFs miteinander verknüpft und klar definierte Schnittstellen zwischen ihnen bietet.
  • Durch das Erfassen an wenigstens einer Schnittstelle des Netzwerks wenigstens eine die Schnittstelle charakterisierende erste Größe, beispielsweise Latenzzeit und/oder Bandbreite, ist diese Größe unmittelbar zur Laufzeit bekannt.
  • Basierend auf der erfassten ersten Größe kann bestimmt werden, ob die vorhandene Topologie des Netzwerks einer jeweiligen Netzwerkfunktion und ihrer Schnittstelle die erforderlichen Ressourcen garantiert.
  • Weiter kann bestimmt werden, ob die vorhandene Topologie des Netzwerks einer jeweiligen künftigen geplanten Netzwerkfunktion und ihrer Schnittstelle die erforderlichen Ressourcen garantiert.
  • Gemäß dem Verfahren ist vorgesehen, dass in Abhängigkeit von der wenigstens einen ersten Größe eine zweite Größe bestimmt, wobei die zweite Größe wenigstens eine Topologie des Netzwerks und/oder einer Änderung der Topologie des Netzwerks charakterisiert, und, insbesondere optional, die Topologie des Netzwerks basierend auf der zweiten Größe angepasst wird, wenn dies erforderlich ist.
  • Mit dem Verfahren können insbesondere die folgenden Herausforderungen gelöst werden: a) die Infrastruktur des Netzwerks kann auf von Dritten verwalteten WAN-Verbindungen (Wide Area Network) aufbauen, deren Verwaltung und Leistung möglichweise nicht oder nur unvollständig kontrolliert werden kann; b) verfügbare Netzwerk- und Rechenressourcen eines Netzwerks können bei einem verteilten Netzwerk von Standort zu Standort variieren und/oder sich im Laufe der Zeit ändern und/oder sind nicht vollständig vorhersehbar; c) durch das Verhalten einzelner Anwendungen, insbesondere Netzwerkfunktionen, und die Kombination mehrerer Anwendungen können Schwankungen in der Auslastung von Netzwerken und Rechenressourcen hervorrufen, wobei sich Anforderungen, insbesondere an Latenzzeit und Bandbreite, bei Verhaltensänderungen einzelner Anwendung ändern können; d) durch Aktivieren und Deaktivieren von Geräten oder Anwendungen ändert sich die Menge der verfügbaren Netzwerk- und Computerressourcen auf dynamische Weise; e) durch Instanziierung und Freigabe von Netzwerkfunktions-Instanzen ändert sich die Menge der verfügbaren Netzwerk- und Computerressourcen auf dynamische Weise.
  • Die systemweite Erfassung der Größen an den Schnittstellen und die Anforderungen der aktiven Anwendungen und deren Änderungen im Laufe der Zeit bestimmen die verbleibenden verfügbaren Netzwerk- und Rechenressourcen auf dynamische Weise.
  • Bei weiteren beispielhaften Ausführungsformen ist vorgesehen, dass das Erfassen der wenigstens einen Größe das Durchführen von wenigstens einer, insbesondere periodischen, Messung, insbesondere ein wiederholtes Durchführen der Messung umfasst. Durch die periodische Messung wird die wenigstens eine erste Größe an wenigstens einer Schnittstelle periodisch erfasst und steht so zu jeder Zeit mit aktuellen Messwerten zu Verfügung. Die vorgesehenen periodischen Messungen gehen daher über ereignisbasierte Messungen heraus.
  • Gemäß dem Verfahren können basierend auf der wenigstes einen erfassten ersten Größe proaktiv Maßnahmen ergriffen werden, um einer Netzwerkfunktion und ihrer Schnittstelle die erforderlichen Ressourcen zu garantieren.
  • Bei weiteren beispielhaften Ausführungsformen ist vorgesehen, dass das Anpassen der Topologie des Netzwerks basierend auf der zweiten Größe wenigstens eines der folgenden Elemente umfasst: a) Verschieben einer Netzwerkfunktion von einem Teilnetzwerk des Netzwerks in ein weiteres Teilnetzwerk des Netzwerks; b) Instanziieren einer Netzwerkfunktion; c) Neu-Instanziieren einer Netzwerkfunktion, oder d) Entfernen einer Netzwerkfunktion.
  • Bei weiteren beispielhaften Ausführungsformen ist vorgesehen, dass das Verfahren weiter einen Schritt zum Bereitstellen von Laufzeitanforderungen umfasst und das Bestimmen der zweiten Größe ein Berücksichtigen der Laufzeitanforderungen umfasst.
  • Bei weiteren beispielhaften Ausführungsformen ist vorgesehen, dass das Verfahren weiter einen Schritt zum Bereitstellen von Kontextinformationen umfasst und das Bestimmen der zweiten Größe ein Berücksichtigen der Kontextinformationen umfasst. Bei Kontextinformationen handelt es sich um Informationen über einen Anwendungskontext einer Applikation, die über die Laufzeitanforderungen der Netzwerkfunktion hinausgehen. Unter einer Applikation ist eine konkrete Anwendung auf Nutzerebene zu verstehen. Die Interaktion einer Applikation mit dem Netzwerk kann Auswirkungen auf das Netzwerk haben, sodass das Berücksichtigen von Kontextinformationen beim Bestimmen der Topologie des Netzwerks und/oder der Änderung der Topologie des Netzwerks vorteilhaft sein kann.
  • Bei weiteren beispielhaften Ausführungsformen ist vorgesehen, dass das Bestimmen der zweiten Größe wenigstens eines der folgenden Elemente umfasst:
    1. a) ein Vorhersagen wenigstens eines Zustands wenigstens einer Schnittstelle, insbesondere einen potenziellen Kapazitäts- und/oder Latenzengpass an wenigstens einer Schnittstelle;
    2. b) Berechnen einer Wahrscheinlichkeit, insbesondere Wahrscheinlichkeitsdichtefunktionen, wenigstens einer ersten Größe, insbesondere während eines bestimmbaren Zeitintervalls;
    3. c) Bestimmen wenigstens einer Wahrscheinlichkeit, wann und/oder ob bestimmte Werte, insbesondere Latenz- und/oder Kapazitätsschwellen, überschritten werden;
    4. d) Korrelieren wenigstens eines, insbesondere vorhergesagten, Zustands wenigstens einer Schnittstelle mit Kontextinformationen;
    die Elemente a) bis d) insbesondere basierend auf der wenigstens einen ersten Größe und/oder basierend auf den Laufzeitanforderungen und/oder basierend auf den Kontextinformationen umfasst.
  • Bei weiteren beispielhaften Ausführungsformen ist vorgesehen, dass vor dem, insbesondere optionalen, Anpassen der Topologie des Netzwerks ein Schritt zum Testen einer Netzwerkfunktion in einer Testumgebung ausgeführt wird.
  • Durch Ausführen von Tests vor dem Anpassen der Topologie des Netzwerks kann verhindert werden, dass die Topologie des Netzwerks derart geändert wird, dass die erforderlichen Ressourcen nicht bereitgestellt werden können. Weiter kann verhindert werden, dass eine fehlerhafte Netzwerkfunktion in der realen Umgebung instanziiert wird.
  • Weitere Ausführungsformen betreffen ein System zum Betreiben eines Netzwerks gemäß einem Verfahren gemäß den beschriebenen Ausführungsformen. Das System ist zum Ausführen von Schritten des Verfahrens ausgebildet.
  • Bei weiteren beispielhaften Ausführungsformen ist vorgesehen, dass das System eine erste Netzwerkfunktion, nämlich Anwendungs-Kontextinformation-Funktion zum Bereitstellen von Kontextinformation bereitstellt.
  • Bei weiteren beispielhaften Ausführungsformen ist vorgesehen, dass das System eine weitere Netzwerkfunktion, nämlich Schnittstellen-Monitoring-Funktion, zum Überwachen von Schnittstellen des Netzwerks bereitstellt.
  • Schnittstellen-Monitoring-Funktion kann insbesondere die ersten Größen insbesondere zusammen mit Kontextinformationen, die von einer anderen dedizierten Netzwerkfunktion, z. B. der Anwendungs-Kontextinformation-Funktion, bereitgestellt werden, verarbeiten. Aus den Kontextinformationen können künftige Leistungsanforderungen an das gesamte Netzwerk, einschließlich von Netzwerkfunktionen und ihren Schnittstellen, abgeleitet und von der Schnittstellen-Monitoring-Funktion verwendet werden, um die Vorhersage potenzieller Kapazitäts-/Latenzengpässe an den Schnittstellen zu verbessern. Wird ein potenzieller künftiger Engpass vorhergesagt, löst die Schnittstellen-Monitoring-Funktion eine Änderung der Topologie des Netzwerks aus, beispielsweise, indem betroffene Netzwerkfunktionen verlegt oder (neu) instanziiert werden.
  • Weitere Ausführungsformen betreffen ein Netzwerk aufweisend wenigstens ein System gemäß den beschriebenen Ausführungsformen zum Ausführen eines Verfahrens gemäß den beschriebenen Ausführungsformen.
  • Weitere Ausführungsformen betreffen die Verwendung eines Verfahrens gemäß den beschriebenen Ausführungsformen und/oder eines Systems gemäß den beschriebenen Ausführungsformen und/oder eines Netzwerks gemäß den beschriebenen Ausführungsformen für wenigstens eines der folgenden Elemente:
    1. a) Vorhersage potenzieller Kapazitäts- und/oder Latenzengpässe an Schnittstellen des Netzwerks; b) Ändern einer Topologie des Netzwerks, insbesondere zur Vermeidung von Kapazitäts- und/oder Latenzengpässe an Schnittstellen.
  • Weitere Merkmale, Anwendungsmöglichkeiten und Vorteile der Erfindung ergeben sich aus der nachfolgenden Beschreibung von Ausführungsbeispielen der Erfindung, die in den Figuren der Zeichnung dargestellt sind. Dabei bilden alle beschriebenen oder dargestellten Merkmale für sich oder in beliebiger Kombination den Gegenstand der Erfindung, unabhängig von ihrer Zusammenfassung in den Ansprüchen oder deren Rückbeziehung sowie unabhängig von ihrer Formulierung bzw. Darstellung in der Beschreibung bzw. in der Zeichnung.
  • In der Zeichnung zeigt:
    • 1 eine schematische Darstellung eines 5G-Kern-Netzwerks mit einer servicebasierten Architektur (SBA);
    • 2 ein Flussdiagramm eines Verfahrens zum Betreiben eines Netzwerks, insbesondere eines Netzwerks aus 1;
    • 3 eine schematische Darstellung einer Steuerebene eines Netzwerks;
    • 4a eine schematische Darstellung eines Netzwerks mit einer ersten Topologie;
    • 4b eine schematische Darstellung eines Netzwerks mit einer weiteren Topologie;
    • 5 eine schematische Darstellung eines Netzwerks in einer Systemansicht;
    • 6 eine Detailansicht aus 5;
    • 7 eine schematische Darstellung eines Netzwerks in einer Systemansicht zum Bereitstellen eines Testverfahrens, und
    • 8 eine schematische Darstellung von Schritten eines Testverfahrens, insbesondere zum Verwenden in dem Verfahren aus 2.
  • 1 zeigt eine schematische Darstellung eines 5G-Kern-Netzwerks mit einer servicebasierten Architektur (SBA) gemäß 3GPP Standard, beispielsweise TS 23.288.
  • In 1 sind die folgenden Netzwerkfunktionen (engl. network functions, NF) dargestellt auf Steuerebene und jeweilige Schnittstellen dargestellt:
    Schnittstelle
    AUSF Authentication Server Function Nausf
    AMF Access and Mobility Function Namf
    AF Application Function Naf
    SMF Session Management Function Nsmf
    NEF Network Exposure Function Nnef
    NSSF Network Slice Selection Function Nssf
    NRF Network Repository Function Nnrf
    PCF Policy Control Function Npcf
  • Weiter sind beispielhaft dargestellt ein Endgerät, UE, ein (Radio-) Zugangsnetzwerk, (R)AN, ein Datennetzwerk, DN und Funktionen auf Nutzerebene (engl. User Plane Function, UPF) sowie die Schnittstellen N1 bis N9.
  • Kommunikation auf Datenebene ist mit einer durchgezogenen Linie und Kommunikation auf Steuerebene mit einer gestrichelten Linie dargestellt.
  • Im Folgenden wird anhand 2 und unter Bezugnahme auf die 3 bis 8 ein Verfahren zum Betreiben eines Netzwerks, welches beispielhaft in 1 dargestellt ist, beschrieben.
  • Das Verfahren 200, insbesondere ein computerimplementiertes Verfahren, zum Betreiben des Netzwerks umfasst die folgenden Schritte:
    • einen Schritt 210 zum Erfassen an wenigstens einer Schnittstelle des Netzwerks wenigstens eine die Schnittstelle charakterisierende erste Größe G1, wobei die erste Größe G1 insbesondere Latenzzeit und/oder Bandbreite umfasst;
    • einen Schritt 220 zum Bestimmen in Abhängigkeit von der wenigstens einen ersten Größe G1 eine zweite Größe G2, wobei die zweite Größe G2 wenigstens eine Topologie des Netzwerks charakterisiert, und
    • einen, insbesondere optionalen, Schritt 230 zum Anpassen der Topologie des Netzwerks basierend auf der zweiten Größe G2.
  • Gemäß einer Ausführungsform umfasst das Erfassen 210 der wenigstens einen Größe G1 das Durchführen von wenigstens einer, insbesondere periodischen, Messung, insbesondere ein wiederholtes Durchführen der Messung.
  • Das Erfassen 210 der wenigstens einen Größe G1 erfolgt beispielsweise an den N1-, N2- und N4- Schnittstellen der servicebasierten Architektur, vgl. beispielsweise 1 und 3 und damit für die NFs AMF und/oder SMF, die über diese Schnittstellen verbunden sind. Das Erfassen der wenigstens einen Größe G1 kann jedoch an weiteren Schnittstellen und damit für weitere NFs durchgeführt werden.
  • 3 zeigt die Steuerebene eines Netzwerks aus 1.
  • Gemäß 3 ist eine weitere NF NXMF, nämlich Schnittstellen-Monitoring-Funktion, vorgesehen. Die NXMF dient zum Überwachen der Schnittstellen, insbesondere der Schnittstellen N1, N2 und N4. Die NXMF fungiert beispielsweise als AF der servicebasierten Architektur.
  • SMF und/oder AMF stellen die erfassten Größen G1 beispielsweise der NXMF zur Verfügung, vgl. Schritt 240 in 2 und die Pfeile G1 in 3.
  • Das Bereitstellen der Größen G1 erfolgt beispielsweise unter Verwendung der NF NWDAF, nämlich Network Data Analytics Function.
  • Gemäß 3GPP TS 23.288 wird die Bereitstellung von NF-Leistungsmessungen unter Verwendung der NWDAF spezifiziert, die mit anderen NFs des SBA kommuniziert, NF-spezifische Informationen und Messungen abruft und diese Informationen anderen NFs, z.B. einer externen Application Function (AF), zur Verfügung stellt. Solche Messungen sind u. a. in TS 28.552 spezifiziert. Beispielhaft können in diesem Zusammenhang folgende Messgrößen genannt werden:
    • - mittlere und maximale Zeiten eines Registrierungsverfahrens (AMF) und
    • - mittlere und maximale Zeiten eines PDU-Sitzungsaufbaus (SMF).
  • Bei den angegebenen Größen handelt es sich um ereignisbasierte Messgrößen, d.h. die Messungen werden im Zusammenhang mit Registrierungsverfahren und/oder Sitzungsaufbau ausgeführt. Eine mögliche Optimierung hinsichtlich der Verteilung von Netzwerkfunktionen basierend auf diesen Messungen ist daher reaktiv.
  • Das Erfassen 210 der Größe G1 an wenigstens einer Schnittstelle des Netzwerks erfolgt durch periodische, insbesondere kontinuierliche Messung. Durch diese erweiterten, proaktiven Messungen, die nicht ereignisbasiert sind, kann gewährleistet werden, dass das Anpassen der Topologie des Netzwerks ebenfalls proaktiv erfolgt. Engpässe bei Mechanismen der Steuerungsebene, wie z. B. die Registrierung und den Aufbau von PDU-Sitzungen, können entschärft werden, bevor sie auftreten.
  • Die NF NXMF verarbeitet die Größen G1. Das Verarbeiten der Größen G1 ist beispielhaft durch den Schritt 250 in 2 dargestellt. Vorteilhafterweise ist die NXMF derart konzipiert, dass Größen G1 von derzeit aktiven NFs erfasst und/oder gespeichert werden können. Es kann auch vorteilhaft sein, wenn Größen G1 von nicht mehr aktiven NFs, beispielsweise NFs die bereits entfernt wurden, erfasst und/oder gespeichert werden können. Beispielsweise ist der NF ein Speicher zum Speichern der Größen G1 zugeordnet.
  • Das Netzwerk gemäß 1 mit einer Steuerebene gemäß 3 kann grundsätzlich an einem einzelnen Standort oder geografisch verteilt auf mehrere Standorte vorgesehen sein.
  • Die Verwendung von 5G-Netzwerken gewinnt derzeit u.a. im Produktionsbereich an Interesse, und einige der zentralen Fragen sind, wie die 5G-Netzarchitektur in ein Unternehmen und in eine IT-Umgebung in der Produktionsstätte integriert werden kann und wie sie auf eine stärker automatisierte Weise betrieben werden kann, die den manuellen Betriebsaufwand ausgleicht. Ein Aspekt dieses komplexen Problems besteht darin, eine fundierte Entscheidung über geografische und logische Standorte, an denen NFs instanziiert werden, zu treffen. Wenn Netzwerke an mehreren Standorten betrieben werden, kann von der flexiblen servicebasierten Architektur der Netzwerke profitiert werden.
  • Es ist beispielsweise möglich, dass sich ein gesamtes 5G-Netzwerk, einschließlich des RAN und aller NFs, d.h. das gesamte 5G-Kern-Netzwerk, an einem geografischen Standort befindet. Ein anderer Ansatz kann darin bestehen, einen Teil der NFs an einem zentralen Verwaltungsstandort zu verwalten und weitere NFs an einem oder mehreren von dem Verwaltungsstandort entfernten Standort zu instanziieren. Beispielsweise kann an einem jeweiligen Standort die jeweiligen NFs instanziiert werden, die an dem jeweiligen Standort benötigt werden. Dies stellt eine skalierbare und gegebenenfalls kostengünstigere Lösung dar.
  • Die Möglichkeit der zentralen Verwaltung von NFs werden beispielsweise eingeschränkt von Anforderungen einer jeweiligen NF und/oder einer Anwendung der jeweiligen NF. Beispielsweise erfordern URLLC-Anwendungen, Ultra Reliable Low Latency Communications, Anwendungen, einen lokalen Datenfluss unter Verwendung einer lokalen User-Plane-Funktion (UPF). Mit einer zentralen Verwaltung können die Latenzanforderungen der URLLC aufgrund einer möglicherweise zu großen Entfernungen zwischen dem lokalen Standort der URLLC-Anwendungen und dem zentralen Standort der zentralen Verwaltung, möglicherweise nicht erfüllt werden können.
  • Für URLLC-Anwendungen kann daher eine lokale UPF vorteilhaft sein.
  • Für Funktionen auf Steuerebene, wie beispielsweise die Zugangs- und Mobilitätsfunktion (engl. Access and Mobility Function, AMF) und die Sitzungsmanagementfunktion (engl. Session Management Function, SMF) hängt der ideale Ort zum Instanziieren dieser Funktionen von vielen Parametern und Randbedingungen ab und kann daher grundsätzlich nicht allgemein festgelegt werden.
  • Die AMF fungiert als Repräsentant des RAN gegenüber dem 5G-Kern-Netzwerk und ist unter anderem für die Registrierung und das Mobilitätsmanagement von Nutzergeräten, UE, verantwortlich ist. Die SMF ist für den Aufbau von Packet Data Unit, PDU,-Sitzungen zuständig und interagiert z.B. mit der UPF.
  • Die NFs AMF und SMF, insbesondere die Anwendungen der AMF und SMF, stellen beispielweise bestimmte Anforderungen, insbesondere Bandbreiten- und/oder Latenzanforderungen an die zugrundeliegende Netzinfrastruktur stellen. Darüber hinaus können auch funktionale Anforderungen eine Rolle spielen. So können beispielsweise sicherheitsrelevante Randbedingungen die Verteilung der NFs, die an Verschlüsselungs- und Authentifizierungsprozessen beteiligt sind, bestimmen. Wenn es beispielsweise erforderlich ist, dass kryptografische Schlüssel lokal gespeichert werden müssen, kann eine lokale Instanziierung von AMF und/oder SMF, und weiter beispielsweise einer Authentication Server Function, AUSF, und/oder des Unified Data Management (UDM) erforderlich werden.
  • 4a und 4b zeigen eine Ausführungsform bei der ein Netzwerk 400 verteilt an zwei Standorten #1 und #2 vorgesehen ist.
  • Gemäß den 4a und 4b ist an Standort #1 ist ein erstes Teilnetzwerk 400-1 und an Standort #2 ein zweites Teilnetzwerk 400-2 vorgesehen.
  • Jedes Teilnetzwerk 400-1 und 400-2 umfasst UE, RAN und UPF. Die Elemente ACIF und MES/ERP werden im Weiteren erörtert.
  • Weiter ist eine zentrale Verwaltung als drittes Teilnetzwerk 400-3 vorgesehen. Das dritte Teilnetzwerk 400-3 kann lokal an einem der Standorte #1 oder #2 oder an einem weiteren Standort vorgesehen sein.
  • Die zentrale Verwaltung umfasst NFs der Steuerebene. Gemäß der dargestellten Ausführungsform umfasst das dritte Teilnetzwerk beispielsweise NSSF, AUSF, UDM, NEF, NRF, PCF, AMF und SMF.
  • Gemäß den 4a und 4b ist weiter die NXMF der zentralen Verwaltung zugeordnet. Die NXMF ist mit weiteren Knoten der Steuerebene, insbesondere der AMF und der SMF verbunden, und kann von diesen die Größen G1 und gegebenenfalls weitere Daten erfassen.
  • Vorteilhafterweise verfügt die NXMF über ein globales Wissen über das Netzwerk, insbesondere System-, und/oder Netzwerk- und/oder Kompensationsleistung des Netzwerks.
  • Die NXMF kann auch an einem oder mehreren Standorten instanziiert werden. Die NXMF kann auch als mehrere verteilte NXMF-Instanzen, die die relevanten Informationen verteilt, beispielsweise in einer hierarchischen Weise, verarbeiten, realisiert werden.
  • Die NF NXMF verarbeitet die Größen G1, insbesondere zum Bestimmen der Größe G2. Zu diesem Zweck stellen SMF und/oder AMF die erfassten Größen G1 beispielsweise der NXMF zur Verfügung, vgl. Schritt 240 in 2 und die Pfeile G1 in 3.
  • Gemäß einer Ausführungsform ist vorgesehen, dass das Verfahren 200 das Bereitstellen 270 von Laufzeitanforderungen K1 umfasst und das Bestimmen 220 der zweiten Größe G2 ein Berücksichtigen der Laufzeitanforderungen K1 umfasst. Bei den Laufzeitanforderungen handelt es sich beispielsweise um Anforderungen einer jeweiligen NF. Die Laufzeitanforderungen der NFs umfassen beispielsweise APIs, Priorität, Latenz, Bandbreite, Rechenleistung, Ressourcenkosten usw. Die Laufzeitanforderungen der NFs werden beispielsweise semantisch beschrieben. Die Laufzeitanforderungen werden der zentralen Verwaltung, insbesondere der NF NXMF, zur Verfügung gestellt.
  • Das Verarbeiten der Größen G1 und/oder der Laufzeitanforderungen K1 ist beispielhaft durch den Schritt 250 in 2 dargestellt. Mögliche Verarbeitungsfunktionen der NXMF umfassen beispielsweise die folgenden Elemente:
    1. a) ein Vorhersagen wenigstens eines Zustands wenigstens einer Schnittstelle (N1, N2, N4), insbesondere einen potenziellen Kapazitäts- und/oder Latenzengpass an wenigstens einer Schnittstellen (N1, N2, N4), insbesondere mit Konfidenzintervallen und anderen statistischen Größen;
    2. b) Berechnen einer Wahrscheinlichkeit, insbesondere Wahrscheinlichkeitsdichtefunktionen, wenigstens einer ersten Größe (G1), insbesondere während eines bestimmbaren Zeitintervalls, insbesondere in der Vergangenheit,
    3. c) Bestimmen wenigstens einer Wahrscheinlichkeit, wann und/oder ob bestimmte Werte, insbesondere Latenz- und/oder Kapazitätsschwellen, überschritten werden.
  • Das Verfahren 200 gemäß 2 umfasst beispielsweise weiter einen Schritt 260 zum Bereitstellen von Kontextinformationen K2. Die Kontextinformationen K2 können beim Bestimmen 220 der zweiten Größe G2 berücksichtigt werden. Bei Kontextinformationen K2 handelt es sich um Informationen im Kontext mit Applikationen und dem Netzwerk 400, insbesondere mit Applikationen und einem Standort des Netzwerks 400. Am Beispiel der 4a und 4b handelt es sich beispielsweise um Informationen über Applikationen im Zusammenhang mit dem Teilnetzwerk 400-1 am Standort #1 und um Informationen über Applikationen im Zusammenhang mit dem Teilnetzwerk 400-2 am Standort #2.
  • Unter einer Applikation ist eine konkrete Anwendung auf Nutzerebene zu verstehen. Die Interaktion einer Applikation mit dem Netzwerk 400 kann Auswirkungen auf das Netzwerk haben. Das Berücksichtigen der Kontextinformationen K2 beim Bestimmen der Größe G2 erlaubt eine bessere Entscheidung über die Topologie, insbesondere die geografische Zuordnung von N Fs.
  • Gemäß den 3 ist auf Steuerebene eine weitere NF ACIF, nämlich Anwendungs-Kontextinformation-Funktion, vorgesehen. Die ACIF ist beispielsweise eine AF der servicebasierten Architektur.
  • Die ACIF kann in einem Netzwerk 400 zentral, beispielsweise in der zentralen Verwaltung, in dem Teilnetzwerk 400-3, vorgesehen werden.
  • Gemäß den 4a und 4b ist die ACIF an den Standorten #1 und #2 lokal instanziiert. In den Teilnetzwerken 400-1 und 400-2 kann die ACIF Teil eines lokalen Managements des jeweiligen Teilnetzwerks 400-1 und 400-2 sein oder mit dem lokalen Management des jeweiligen Teilnetzwerks 400-1 und 400-2 interagieren oder das lokale Management des jeweiligen Teilnetzwerks 400-1 und 400-2 bereitstellen.
  • Die ACIF kann mit einem Anwendungsmanagementsystem des jeweiligen Teilnetzwerks 400-1 und 400-2 oder einer Anwendungsdatenbank des jeweiligen Teilnetzwerks 400-1 und 400-2 verbunden sein. Ein Anwendungsmanagementsystem oder eine Anwendungsdatenbank stellt beispielsweise, insbesondere anwendungsbezogene Kontextinformationen K2 bereit.
  • In einem industriellen Kontext kann die ACIF auch direkt oder indirekt Informationen von einem Fabrikmanagementsystem, das an den Standorten #1 und #2 im Rahmen von Produktionsstätten vorgesehen sein kann, wie beispielsweise ein Manufacturing Execution System, MES, und/oder ein Enterprise Ressource Planning, ERP, erhalten.
  • Fabrikmanagementsysteme steuern und verwalten Produktionsprozesse an den Produktionsstätten und sind daher relevante Quellen für industrielle Kontextinformationen K2, wie beispielsweise Standort von Anlagen, geplante Pfade von autonomen Transportsystemen.
  • Kontextinformationen K2 können weiter beispielsweise eines oder mehrere der folgenden Elemente umfassen und/oder auf eines oder mehrere der folgenden Elemente hinweisen:
    1. a) Informationen über, insbesondere künftige, Registrierung(en), insbesondere derzeit inaktiver und/oder deregistrierter, Endgeräte, UE, und/oder, insbesondere künftige, Deregistrierung, insbesondere derzeit aktiver und/oder registrierter, Endgeräte, UEs, insbesondere mit einer Zeitangabe, wann dies geschehen wird, und/oder Anforderungen der Endgeräte, UEs, insbesondere in Bezug auf Latenz, Zuverlässigkeit, Datenrate;
    2. b) Informationen über, insbesondere künftige, Einrichtung von PDU-Sitzungen, insbesondere mit genauen Zeitangaben, wann dies geschehen wird;
    3. c) die Zeitangaben des Elements a) und/oder b) insbesondere als Vorhersage einer Wahrscheinlichkeit, insbesondere in Form einer Wahrscheinlichkeitsdichtefunktion;
    4. d) Informationen in Bezug auf Verbindungsübergaben von Endgeräten, UEs, zwischen Basisstationen (Handover), die eine Signalisierung zwischen dem Endgerät/RAN und dem AMF erfordern, und Vorhersagen darüber, insbesondere eine Häufigkeit und eine Zeitangabe, wann diese stattfinden, wobei die Informationen insbesondere auf der Grundlage von Routen mobiler Endgeräte, UE, vorhergesagt werden können, wobei die Routen beispielsweise mittels des MES und/oder ERP geplant werden;
    5. e) Routen, insbesondere geplante Routen von mobilen Endgeräten, UEs, wobei die Routen insbesondere im MES und/oder ERP gespeichert sind,
    6. f) Informationen in Bezug auf Produktionsprozesse von 5G-verbundenen Maschinen, insbesondere Art und/oder Dauer und/oder Häufigkeit und/oder Anforderungen der Produktionsprozesse.
  • Die ACIF erfasst die Kontextinformationen K2 und stellt diese gemäß dem Schritt 260 der NXMF zur Verfügung.
  • Die NXMF berücksichtigt beim Bestimmen 220 der zweiten Größe G2 Kontextinformationen K2.
  • Das Bestimmen der Größe G2 kann auf verschiedenen Algorithmen oder Algorithmusklassen basieren, beispielsweise a) heuristische Algorithmen, die insbesondere auf Schwellenwerten basieren, b) Extrapolation von G1-Vorhersagen oder c) Vorhersagealgorithmen, zum Beispiel auf der Grundlage des maschinellen Lernens.
  • Das Berücksichtigen umfasst beispielsweise das Korrelieren wenigstens eines, insbesondere vorhergesagten, Zustands wenigstens einer Schnittstelle (N1, N2, N4) mit den Kontextinformationen K2. Die Kontextinformationen K2 können beispielsweise im Zusammenhang mit Laufzeitanforderungen K1 als künftige, insbesondere vorübergehende, Anforderungen von NFs der Nutzer- und/oder Steuerebene, insbesondere Anwendungen der NFs berücksichtigt werden. Beispielsweise kann der vorhergesagte Zustand wenigstens einer Schnittstelle N1, N2, N4, insbesondere ein potenzieller Kapazitäts- und/oder Latenzengpass an wenigstens einer Schnittstelle (N1, N2, N4) mit den künftigen Anforderungen verglichen werden. Ein solcher Vergleich kann auf, insbesondere zeitvariablen, Wahrscheinlichkeiten, insbesondere Wahrscheinlichkeitsdichtefunktionen, der ersten Größen G1 und/oder der Anforderungen, basieren. Bei dem Vergleich kann insbesondere eine Wahrscheinlichkeit bestimmt werden, wann und/oder ob bestimmte Werte, insbesondere Latenz- und/oder Kapazitätsschwellen, überschritten werden.
  • Beim Bestimmen der Größe G2 werden vorteilhafterweise die Größen G1, die Laufzeitanforderungen K1 und die Kontextinformation K2 berücksichtigt.
  • Die zweite Größe G2 kann letztendlich eine Topologie des Netzwerks 400 und/oder eine Änderung der Topologie des Netzwerks 400 charakterisieren.
  • Die Größe G2 kann auch umfassen, dass, insbesondere derzeit keine Änderung der Topologie des Netzwerks 400 erforderlich ist.
  • Schließlich wird gemäß dem Schritt 230 die Topologie des Netzwerks 400 basierend auf der zweiten Größe G2 angepasst.
  • Die Größe G2 ist beispielsweise eine Konfigurationsdatei, die eine Topologie des Netzwerks 400 und/oder eine Änderung der Topologie des Netzwerks beschreibt. Die Konfigurationsdatei kann grundsätzlich mit lokalen Knoten der beteiligten Topologie geteilt werden. Weiter kann die zentrale Verwaltung basierend auf der Konfigurationsdatei die Topologie des Netzwerks 400 entsprechend anpassen. In Abhängigkeit von den Fähigkeiten der Endgeräte, UEs, kann die automatisierte dynamische Zuweisung/Neuzuweisung der NFs auch auf die Endgeräte, UE, angewendet werden.
  • Das Anpassen 230 der Topologie des Netzwerks 400 wird insbesondere durch die NXMF herbeigeführt.
  • Das Anpassen der Topologie kann grundsätzlich basierend auf verschiedenen Mechanismen erfolgen.
  • Beispielsweise kann gemäß dem 3GPP TR 28.801 Standard ein Network Slice Management vorgesehen sein, das von einer Network Slice Management Function, NSMF, durchgeführt wird. Beim Network Slicing werden virtuelle Netzwerkinstanzen, sogenannte Netzwerk Slice Instanzen. NSI, erzeugt. Jede Netzwerk Slice Instanz stellt beispielsweise eine isoliertes, End-to-End-Netzwerk bereit, das insbesondere für einen bestimmten Zweck optimiert ist. Die NSMF sieht Mechanismen vor wie beispielsweise a) Ändern der Topologie der NSI, der Kapazität der NSI, der Verbindungen der NSI und/oder b) Einrichten neuer der NSls und/oder Abschalten und/oder Entfernen überflüssiger NSIs.
  • Weitere Mechanismen, insbesondere ohne NSMF, sind beispielsweise a) Verlagern bestehender NFs von oder zu einem jeweiligen Standort; b) Wiederverwenden oder Neueinrichten dedizierter NFs, beispielsweise AMF und/oder SMF, an jeweiligen Standorten; c) Abschalten und/oder Entfernen von NFs an jeweiligen Standorten.
  • Ein Anwendungsbeispiel des Verfahrens 200 wird anhand der 4a und 4b erläutert. An einem Standort #1 und einem Standort #2 ist jeweils eine Produktionsstätte eines Unternehmens vorgesehen, wobei jede Produktionsstätte eine Teilnetzwerk 400-1 und 400-2 umfasst. Die Teilnetzwerke 400-1, 400-2 werden von einem zentralen Verwaltungsstandort aus von dem Teilnetzwerk 400-3 betrieben. Der zentrale Verwaltungsstandort ist beispielsweise ca. 100km oder mehr oder weniger als 100km von den Standorten #1 und #2 entfernt. Durch den Betrieb mittels der gemeinsamen zentralen Verwaltung können Ressourcen gespart und die Flexibilität und Skalierungseffekte der SBA genutzt werden.
  • An den Standorten #1 und #2 sind lokal das RAN und eine UPF zum Ausführen von URLLC-Anwendungen vorgesehen. Die Teilnetzwerke 400-1 und 400-2 sind über ein, insbesondere von einem Drittanbieter verwaltetes WAN, mit dem Teilnetzwerk 400-3 am zentralen Verwaltungsstandort verbunden. Das WAN kann beispielsweise Latenzschwankungen aufweisen. Solche Latenzschwankungen können einen ordnungsgemäßen Betrieb von URLLC-Anwendungen gefährden. Die Latenzanforderungen der Steuerungsebene an N1-, N2-, N4-Schnittstellen liegen beispielsweise in der Größenordnung von 10 ms.
  • Die Schwankungen der WAN-Latenzleistung werden beispielsweise anhand der NF AMF und SMF überwacht, beispielweise mittels Erfassen der Größe G1, wobei die Größe G1 beispielsweise die Latenz umfasst. Die Größen G1 werden der NF NXMF zur Verfügung gestellt. Aus den erfassten Größen G1, insbesondere den Latenzen, prognostiziert die NXMF, künftige Zustände, beispielweise umfassen die Latenzen, für einen künftigen Zeitraum, beispielsweise für die nächsten fünf Stunden, insbesondere mittels maschineller Lernverfahren.
  • An der Produktionsstätte am Standort #2 werden künftige Anwendungen geplant, die beispielsweise URLLC-Fähigkeiten erfordern. Eine künftige Anwendung ist beispielsweise die Einrichtung einer neuen Flotte von über des 5G-Netz verbundenen autonomen fahrerlosen Transportfahrzeugen (AGVs). Die Steuerungsfunktionen AGVs soll beispielsweise in eine lokale Edge-Cloud ausgelagert werden, die 5G-URLLC-Fähigkeiten erfordert. Die Routen der AGVs werden beispielsweise mithilfe des MES geplant. Das MES stellt dem ACIF beispielsweise Kontextinformationen K2 zur Verfügung. Die Kontextinformationen K2 umfassen beispielsweise Informationen über Orte und Zeitpunkte der anfänglichen Zugriffsverfahren der AGVs, Informationen über den Aufbau von PDU-Sitzungen und Informationen über Verbindungsübergaben der AGVs zwischen Basisstationen (Handover). Solche Vorgänge erfordern eine Signalisierung auf Steuerebene zwischen den AGVs, dem RAN, der AMF und der SMF über die Schnittstellen N1, N2 und N4.
  • Die ACIF stellt die Kontextinformationen K2 der NXMF zur Verfügung. Vorteilhafterweise erfolgt dies, bevor die AGVs den geplanten Betrieb aufnehmen und sich zugehöriger UEs der AGVs sich über die AMF beim 5G-System registrieren und versuchen, PDU-Verbindungen über die SMF herzustellen.
  • Die NXMF bestimmt basierend auf den Größen G1 und den Kontextinformationen K1 wenigstens eine Größe G2. Basierend auf den Kontextinformationen K1, insbesondere für davon umfasste künftige Ereignisse und Zeitpunkte und künftige Handover korreliert die NXMF die prognostizierten Zustände, beispielweise umfassend die Latenzen, der N1-, N2- und N4-Schnittstellen. Beispielsweise wird beim Korrelieren erkannt, dass für die künftigen Ereignisse die Wahrscheinlichkeiten für das Überschreiten eines Latenzwerts über einem bestimmten Schwellenwert liegen. Damit die geplanten Anwendungen störungsfrei Betrieben werden können ist daher eine Änderung der Topologie des Netzwerks 400 erforderlich.
  • In 4b ist das Netzwerk 400 mit einer neuen Topologie dargestellt. Gemäß 4b ist am Standort #2 eine lokale Instanz der AMF und der SMF vorgesehen.
  • Das Ändern der Topologie erfolgt beispielsweise unter Verwendung eines Network Slicing Mechanismus durch Aufrufen der Network Slice Management Function, NSMF. Die NXMF teilt der NSMF beispielsweise mit, dass eine lokale Instanz der SMF und der AMF an Standort #2 erforderlich ist. Beispielsweise übermittelt die NXMF die Größe G2.
  • Schließlich ändert die NSMF die entsprechenden Instanzen, in diesem Fall der NSI. Auf diese Weise können die Anforderungen der Anwendung, in diesem Fall der geplanten AGV Flotte erfüllt werden.
  • Die erfassten Größen G1 und die darauf basierenden prognostizierten Zustände der Schnittstellen, insbesondere in Bezug auf Latenz, werden berücksichtigt, bevor die entsprechenden Ereignisse, die gemäß den Kontextinformationen bereitgestellt werden, eintreten. In diesem Fall erfolgt eine proaktive Änderung der Topologie des Netzwerks 400 um künftige Anforderungen zu erfüllen.
  • 5 zeigt eine weitere Darstellung eines Netzwerks 400 als logische Netzwerktopologie mit einer Systemansicht der zentralen Verwaltung 500 sowie vier Knoten 510-1, 510-2, 510-3 und 510-4. Ein beispielhafter Knoten 510 ist weiter in 6 dargestellt. Zwischen den Knoten 510 und der zentralen Verwaltung 500 kann eine Kommunikation auf Datenebene (durchgezogene Linie) und eine Kommunikation auf Steuerebene (gestrichelten Linie) erfolgen.
  • Die zentrale Verwaltung 500 kann Messaging (M)-, Monitoring (MT)- und Logging (L)-Funktionen bereitstellen.
  • Die zentrale Verwaltung ist in der Lage, 5G (NF)-Funktionen sowie Anwendungsfunktionen, Dienste und Infrastruktur auf verschiedenen Knoten 510 der Topologie bereitzustellen und zu betreiben.
  • Die Knoten können dabei verschiedenen Sicherheitszonen, sogenannten Security Leveln, beispielsweise gemäß IEC 62443 zugeordnet sein. Beispielsweise ist der Knoten 510-4 dem Security Level 0 oder 1, SL0/SL1, der Knoten 510-1 dem Security Level 2, SL2, der Knoten 510-2 dem Security Level 3, SL3 und der Knoten 510-3 dem Security Level 4, SL4, zugeordnet. Weiter umfasst jeder Knoten eine lokale Infrastruktur 520. Der Knoten 510-4 ist beispielsweise eine Cloud, die Knoten 510-2 und 510-3 sind beispielsweise lokale Rechenzentren und der Knoten 510-4 repräsentiert beispielsweise eine Produktionsstätte.
  • In verteilten Netzwerken, mit mehreren Knoten 510, insbesondere Rechenknoten, kann es vorteilhaft sein, eines Software-Container basierte Technologie zu verwenden. Insbesondere werden die Container-basierten Programme mittels sogenannter Container-Orchestration-Techniken, beispielsweise Kubernetes (https://kubernetes.io/de/), auf die Rechenknoten verteilt, zum Ablauf gebracht und überwacht. Bei Kubernetes erfolgt dies über eine zentrale Komponente, den sogenannten Master oder Kubernetes Master, in diesem Fall die zentrale Verwaltung 500. Die zentrale Verwaltung 500 umfasst oder hat Zugriff auf Beschreibungen der Software-Komponenten, die ablaufen sollen, insbesondere Laufzeitanforderungen K1 der NF. Die zentrale Verwaltung 500 kann geeignete Knoten (Nodes) auswählen und den Container mit den Software-Komponenten dort zum Ablauf bringen, was als „Deployment“ bezeichnet wird. Ferner kann die zentrale Verwaltung 500 die Knoten überwachen, beispielsweise mittels der Monitoring-Funktion MT.
  • Gemäß der dargestellten Ausführungsform umfasst die zentrale Verwaltung einen Speicher, beispielsweise in Form eines GIT Repository, GIT. Weiter können in der zentralen Verwaltung Entwicklungsmethoden zum Entwickeln von NFs bzw. Software Container zur Anwendung kommen, die auf CI/CD, Continous Implementation und/oder Continous Delivery und/oder Continous Deployment basieren.
  • Die NXMF, vgl. 1, 3, 4a, 4b kann Teil der Monitoring-Funktion MT der zentrale Verwaltung 500 sein oder Überwachungsinformationen an Monitoring-Funktion MT der zentrale Verwaltung 500 oder an Monitoring-Funktion MT eines jeweiligen Knotens 510 bereitstellen.
  • Ein jeweiliger Knoten 510 stellt beispielsweise serviceorientierte NFs wie Messaging (M)-, Monitoring (MT)- und 5G-Funktionen, NFs; bereit. Weiter kann ein Knoten 510 anwendungsorientierte Funktionen, 530, NFs, und ein lokales Management 540 umfassen. Die NFs und das lokale Management können beispielsweise als Software Container bereitgestellt werden.
  • Gemäß einer Ausführungsform ist vorgesehen, dass das Verfahren 200 weiter einen Schritt zum Testen einer Netzwerkfunktion, NF, in einer Testumgebung umfasst.
  • Dies wird im Folgenden anhand der 7 und 8 erläutert.
  • 7 zeigt die zentrale Verwaltung 500 sowie den Knoten 510-3 und eine Testumgebung 700.
  • Beispielsweise wurde durch Ausführen von Schritten des Verfahrens, insbesondere des Schrittes 220 eine Größe G2 bestimmt. Die Größe G2 charakterisiert wenigstens eine Topologie des Netzwerks 400 und/oder einer Änderung der Topologie des Netzwerks 400. Die Änderungen der Topologie umfasst beispielsweise das Verschieben einer Netzwerkfunktion NF von einem Teilnetzwerk 400-1, 400-2, 400-3 des Netzwerks 400 in ein weiteres Teilnetzwerk 400-1, 400-2, 400-3 des Netzwerks 400, das Instanziieren einer Netzwerkfunktion NF; oder das Neu-Instanziieren einer Netzwerkfunktion NF.
  • Bevor diese Änderungen tatsächlich vorgenommen werden, kann die Netzwerkfunktion in einer Testumgebung getestet werden. Dadurch kann die Robustheit und/oder Zuverlässigkeit der Netzwerkfunktion erhöht werden.
  • Beispielsweise wird eine Netzwerkfunktion NF zunächst in der Testumgebung 700 getestet, bevor die Änderungen auf Knoten 510-3 angewendet werden.
  • 8 zeigt den Schritt 800 zum Testen einer Netzwerkfunktion, NF, in einer Testumgebung anhand eines möglichen Testablaufs.
  • In einem Schritt 810 werden die Laufzeitanforderungen K1 der NF und/oder die Kontextinformationen K2 als Input beispielsweise von der ACIF bereitgestellt. Weiter werden in dem Schritt 820 die Größen G1 beispielsweise von AMF, SMF oder NXMF als Input bereitgestellt. In einem Schritt 830 wird der Test bereitgestellt und einem Schritt 840 wird der Test ausgeführt. Beim Testen wird in der Testumgebung geprüft, ob die Anforderungen der NF erfüllt werden.
  • Wenn der Test erfolgreich ist, kann das Bereitstellen der NF und damit die Änderung der Topologie freigegeben werden, 850. Wenn der Test nicht erfolgreich ist, kann das Bereitstellen der NF und damit die Änderung der Topologie nicht freigegeben werden, 860.
  • Die Ausführungsformen in den 1 bis 8 wurden beispielhaft unter Bezugnahme auf Änderungen der Netzwerk Topologie basierend auf den NFs AMF und SMF beschrieben. Das Verfahren 200 ist jedoch nicht auf die NFs AMF und SMF beschränkt.
  • Gemäß weiterer Ausführungsformen ist vorgesehen, dass die Änderungen der Topologie auch weitere NFs betreffen können. Beispielhafte NFs sind UPF, AUSF, UDM, PCF, AF, RAN (falls virtualisiert).
  • Grundsätzlich kann die Änderung jede beliebige NF in Abhängigkeit der erfassten Größen G1, beispielsweise Latenzzeit, Bandbreite, und/oder Anforderungen der NF wie beispielsweise Nutzung der Ressourcen, Sicherheitsanforderungen der Anwendung, IT-Sicherheitsanforderungen der Anwendung oder der Anlage (z. B. Verarbeitung und Speicherung kryptographischer Schlüssel), betreffen.
  • Beim Bestimmen der Größe G2, insbesondere beim Verarbeiten von G1 und/oder K1 und/oder K2 kann die NXMF historische Kenntnisse, beispielsweise historische Kenntnisse von anderen Standorten und/oder Teil-Netzwerken berücksichtigen. Beispielsweise handelt es sich um Standorte oder TeilNetzwerke im selben Produktionskontext, wie beispielsweise gleiche oder ähnliche Produktionslinien. Dies kann hilfreich sein, wenn von einem betreffenden Standort nicht genügend Informationen verfügbar sind. In diesem Zusammenhang kann auf Techniken des Transfer-Lernens, einem speziellen Ansatz des maschinellen Lernens, zurückgegriffen werden.
  • Das vorgeschlagene Verfahren ist unabhängig von der Intensität der Umgebungsdynamik, d.h. Änderungen der Topologie können entweder sehr häufig oder sehr selten durchgeführt werden.
  • Eine sehr häufig vorgenommene Änderung der Topologie, beispielsweise auf der Grundlage einzelner Ereignisse in den Anwendungen, kann vorteilhaft sein, um einen optimalen Kompromiss zwischen Anwendungsleistung und erhöhten Skalierungseffekten durch maximale Bündelung von Ressourcen am zentralen Verwaltungsstandort zu erreichen.
  • Eine sehr seltene vorgenommene Änderung der Topologie kann vorteilhaft sein, um nahezu oder annähernd statische Topologien für bestimmte Anwendungen oder an bestimmten Standorten bereitzustellen.
  • Gemäß einer weiteren Ausführungsform kann die Instanziierung von sogenannten Dummy-Netzwerkfunktionen, Dummy-NFs vorgesehen sein. Eine Dummy-NF kann dazu verwendet werden, Größen G1, insbesondere Latenz und/oder Kapazität, an einer jeweiligen Schnittstelle zu messen. Insbesondere kann dies der einzige Zweck einer Dummy-NF sein. Die mittels der Dummy-NF erfasste Größe G1 kann wiederum die Grundlage für die Entscheidung über einen Zielstandort für neu zu lokalisierende oder neu einzurichtende NF sein.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • DE 102019211908 A1 [0004]

Claims (12)

  1. Verfahren (200), insbesondere computerimplementiertes Verfahren (200), zum Betreiben eines Netzwerks (400), umfassend die folgenden Schritte: Erfassen (210) an wenigstens einer Schnittstelle (N1, N2, N4) des Netzwerks (400) wenigstens eine die Schnittstelle (N1, N2, N4) charakterisierende erste Größe (G1), wobei die erste Größe (G1) insbesondere Latenzzeit und/oder Bandbreite umfasst; Bestimmen (220) in Abhängigkeit von der wenigstens einen ersten Größe (G1) eine zweite Größe (G2), wobei die zweite Größe (G2) wenigstens eine Topologie des Netzwerks (400) und/oder einer Änderung der Topologie des Netzwerks (400) charakterisiert, und, insbesondere optional, Anpassen (230) der Topologie des Netzwerks (400) basierend auf der zweiten Größe (G2).
  2. Verfahren (200) nach Anspruch 1, wobei das Erfassen (210) der wenigstens einen Größe (G1) das Durchführen von wenigstens einer, insbesondere periodische, Messung, insbesondere ein wiederholtes Durchführen der Messung umfasst.
  3. Verfahren (200) nach einem der Ansprüche 1 oder 2, wobei das Anpassen (230) der Topologie des Netzwerks (400) basierend auf der zweiten Größe (G2) wenigstens eines des folgenden Elemente umfasst: a) Verschieben einer Netzwerkfunktion (NF) von einem Teilnetzwerk (400-1, 400-2, 400-3) des Netzwerks (400) in ein weiteres Teilnetzwerk (400-1, 400-2, 400-3) des Netzwerks (400); b) Instanziieren einer Netzwerkfunktion (NF); c) Neu-Instanziieren einer Netzwerkfunktion (NF), oder d) Entfernen einer Netzwerkfunktion (NF).
  4. Verfahren (200) nach wenigstens einem der vorhergehenden Ansprüche, wobei das Verfahren (200) weiter einen Schritt (270) zum Bereitstellen von Laufzeitanforderungen (K1) umfasst und das Bestimmen (220) der zweiten Größe (G2) ein Berücksichtigen der Laufzeitanforderungen (K1) umfasst.
  5. Verfahren (200) nach wenigstens einem der vorhergehenden Ansprüche, wobei das Verfahren (200) weiter einen Schritt (260) zum Bereitstellen von Kontextinformationen (K2) umfasst und das Bestimmen (220) der zweiten Größe (G2) ein Berücksichtigen der Kontextinformationen (K2) umfasst.
  6. Verfahren (200) nach wenigstens einem der vorhergehenden Ansprüche, wobei das Bestimmen (220) der zweiten Größe (G2) wenigstens eines der folgenden Elemente umfasst: a) ein Vorhersagen (250) wenigstens eines Zustands wenigstens einer Schnittstelle (N1, N2, N4), insbesondere einen potenziellen Kapazitäts- und/oder Latenzengpass an wenigstens einer Schnittstellen (N1, N2, N4); b) Berechnen (250) einer Wahrscheinlichkeit, insbesondere Wahrscheinlichkeitsdichtefunktionen, wenigstens einer ersten Größe (G1), insbesondere während eines bestimmbaren Zeitintervalls; c) Bestimmen (250) wenigstens einer Wahrscheinlichkeit, wann und/oder ob bestimmte Werte, insbesondere Latenz- und/oder Kapazitätsschwellen, überschritten werden; d) Korrelieren wenigstens eines, insbesondere vorhergesagten, Zustands wenigstens einer Schnittstelle (N1, N2, N4) mit Kontextinformationen (K2); die Elemente a) bis d) insbesondere basierend auf der wenigstens einen ersten Größe (G1) und/oder basierend auf den Laufzeitanforderungen (K1) und/oder basierend auf den Kontextinformationen (K2).
  7. Verfahren (200) nach wenigstens einem der vorhergehenden Ansprüche, wobei vor dem insbesondere optionalen, Anpassen der Topologie des Netzwerks (400), einen Schritt (800), insbesondere ein Testverfahren (800) zum Testen einer Netzwerkfunktion (NF) in einer Testumgebung (700) ausgeführt wird.
  8. System (500) zum Betreiben eines Netzwerks (400) gemäß einem Verfahren (200) nach einem der Ansprüche 1 bis 7, wobei das System (500) zum Ausführen von Schritten des Verfahrens (200) ausgebildet ist.
  9. System (500) nach Anspruch 8, wobei das System (500) eine erste Netzwerkfunktion (NF), nämlich Netzwerk-Anwendungs-Kontextinformation-Funktion (ACIF) zum Bereitstellen von Kontextinformation (K2) bereitstellt.
  10. System (500) nach einem der Ansprüche 8 oder 9, wobei System (500) eine weitere Netzwerkfunktion (NF), nämlich Schnittstellen-Monitoring-Funktion (NXMF) zum Überwachen von Schnittstellen des Netzwerks (400), insbesondere der Schnittstellen (N1, N2, N4) des Netzwerks (400), bereitstellt.
  11. Netzwerk (400) aufweisend wenigstens ein System (500) nach wenigstens einem der Ansprüche 8 bis 10 zum Ausführen eines Verfahrens (200) nach einem der Ansprüche 1 bis 7.
  12. Verwendung eines Verfahrens (200) nach wenigstens einem der Ansprüche 1 bis 9 und/oder eines Systems (500) nach wenigstens einem der Ansprüche 8 bis 10 und/oder eines Netzwerks (400) nach Anspruch 11 für wenigstens eines der folgenden Elemente: a) Vorhersage potenzieller Kapazitäts- und/oder Latenzengpässe an Schnittstellen (N1, N2, N4) des Netzwerks (400); b) Ändern einer Topologie des Netzwerks (400), insbesondere zur Vermeidung von Kapazitäts- und/oder Latenzengpässe an Schnittstellen (N1, N2, N4).
DE102021213702.4A 2021-12-02 2021-12-02 Verfahren und System zum Betreiben eines Netzwerks Pending DE102021213702A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102021213702.4A DE102021213702A1 (de) 2021-12-02 2021-12-02 Verfahren und System zum Betreiben eines Netzwerks

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102021213702.4A DE102021213702A1 (de) 2021-12-02 2021-12-02 Verfahren und System zum Betreiben eines Netzwerks

Publications (1)

Publication Number Publication Date
DE102021213702A1 true DE102021213702A1 (de) 2023-06-07

Family

ID=86382224

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021213702.4A Pending DE102021213702A1 (de) 2021-12-02 2021-12-02 Verfahren und System zum Betreiben eines Netzwerks

Country Status (1)

Country Link
DE (1) DE102021213702A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102019211908A1 (de) 2019-08-08 2021-02-11 Robert Bosch Gmbh Verfahren und Vorrichtung zum Verteilen einer Anwendung
US20210243684A1 (en) 2018-05-03 2021-08-05 Nokia Solutions And Networks Oy Selecting and Managing Network Slices
US20210368514A1 (en) 2020-05-19 2021-11-25 T-Mobile Usa, Inc. Base station radio resource management for network slices

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210243684A1 (en) 2018-05-03 2021-08-05 Nokia Solutions And Networks Oy Selecting and Managing Network Slices
DE102019211908A1 (de) 2019-08-08 2021-02-11 Robert Bosch Gmbh Verfahren und Vorrichtung zum Verteilen einer Anwendung
US20210368514A1 (en) 2020-05-19 2021-11-25 T-Mobile Usa, Inc. Base station radio resource management for network slices

Similar Documents

Publication Publication Date Title
DE102022115155A1 (de) Visualisierung eines softwaredefinierten prozesssteuerungsystems für industrielle prozessanlagen
DE102021109767A1 (de) Systeme und methoden zur vorausschauenden sicherheit
DE112021003908T5 (de) Föderales maschinenlernen durch verwenden von ortsabhängigem hashing
DE102019131291A1 (de) Gleichzeitige ausführung von dienstleistungen
DE102022114391A1 (de) Suchdienst in einem softwaredefinierten Steuerungssystem
DE102022114301A1 (de) Software-definiertes prozesssteuerungssystem für industrielle prozessanlagen
DE102022114267A1 (de) Systeme und verfahren zur dynamischen aufrechterhaltung der redundanz und des lastausgleichs in softwaredefinierten steuerungssystemen für industrielle prozessanlagen
DE102022114541A1 (de) Suchdienst in einem softwaredefinierten steuerungssystem
DE102022114799A1 (de) Systeme und verfahren zur zuordnung von modulen in einem softwaredefinierten steuerungssystem für industrielle prozessanlagen
DE112017001376T5 (de) Erkennen und Vorhersagen von Engpässen in komplexen Systemen
DE102022115152A1 (de) Visualisierung eines softwaredefinierten prozesssteuerungssystems für industrielle prozessanlagen
DE102022114305A1 (de) E/a serverdienste zur auswahl und verwendung aktiver steuerungsausgänge von containerisierten steuerungsdiensten in einer prozesssteuerungsumgebung
DE102022114542A1 (de) Suchdienst in einem softwaredefinierten steuerungssystem
DE102022114306A1 (de) E/a-serverdienste, die so konfiguriert sind, dass sie die steuerung in einer prozesssteuerungsumgebung durch containerisierte steuerungsdienste erleichtern
DE102022114302A1 (de) Softwaredefiniertes prozesssteuerungssystem und verfahren für industrielle prozessanlagen
DE102022114303A1 (de) Systeme und verfahren zur dynamischen aufrechterhaltung von redundanz und lastausgleich in softwaredefinierten steuerungssystemen für industrielle prozessanlagen
DE102022114380A1 (de) Sicherheitsdienste in einem softwaredefinierten steuerungssystem
DE102022114307A1 (de) Nutzung von dienstqualitätsmetriken zur erleichterung von übergängen zwischen e/a-kanälen für e/a-serverdienste
DE102022114375A1 (de) Sicherheitsdienste in einem softwaredefiniertensteuerungssystem
DE102022114250A1 (de) Systeme und Verfahren zur hierarchischen Organisation von softwaredefinierten Prozesssteuerungssystemen für industrielle Prozessanlagen
DE102022115178A1 (de) Visualisierung eines softwaredefinierten prozesssteuerungsstems für industrielle prozessanlagen
EP1634176B1 (de) Clusteranordnung für dezentrale lastverteilung
DE102022114281A1 (de) Softwaredefiniertes steuerungssystem mit e/a-serverdiensten, die mit containerisierten diensten kommunizieren
DE102021213702A1 (de) Verfahren und System zum Betreiben eines Netzwerks
DE112016005840T9 (de) Drahtloses kommunikationsgerät, drahtloses kommunikationsverfahren und programm für drahtlose kommunikation

Legal Events

Date Code Title Description
R163 Identified publications notified