DE102021203569A1

DE102021203569A1 - Testsystem und Testverfahren zum Testen eines Breitband-Mobilfunknetzes

Info

Publication number: DE102021203569A1
Application number: DE102021203569.8A
Authority: DE
Inventors: Vlad Bratu; Goce Talaganov; Gerald Wittmann
Original assignee: Sigos GmbH
Current assignee: Sigos GmbH
Priority date: 2021-04-12
Filing date: 2021-04-12
Publication date: 2022-10-13

Abstract

Ein Testsystem (1) dient zum Testen eines Breitband-Mobilfunknetzes. Das Testsystem (1) umfasst mindestens eine Benutzerschnittstelle (2, 3) und mindestens ein zentrales Testmodul (7), das in der Lage ist, ein vorgegebenes oder benutzerdefiniertes Testverfahren durchzuführen. Ein Smartphone-Prüfsonden-Schnittstellenmodul (13) des Testsystems (1) ist mit dem zentralen Testmodul (7) verbunden. Ein solches Smartphone-Prüfsonden-Schnittstellenmodul (13) ist in der Lage, eine Daten-/Signalverbindung zwischen mindestens einer Smartphone-Prüfsonde (14) und einer Netzkomponente des Breitband-Mobilfunknetzes herzustellen. Das Testsystem (1) umfasst ferner ein Funk-Prüfsonden-Schnittstellenmodul (15) und ein Kernnetz-Prüfsonden-Schnittstellenmodul (17), welche in ähnlicher Weise eine Daten-/Signalverbindung zwischen mindestens einer Funk-/Kernnetz-Prüfsonde (16, 18) und einer jeweiligen Netzkomponente des Breitband-Mobilfunknetzes herstellen können. Während eines Testverfahrens mit einem solchen Testsystem wird eine Gruppe von Prüfsonden über die jeweiligen Schnittstellenmodule (13, 15, 17) den zu testenden Netzkomponenten des Netzes zugeordnet. Danach wird mindestens eine Testsequenz innerhalb des Netzes durchgeführt und Daten und Ergebnisse von den Prüfsonden (14, 16, 18) und den Testsequenzen werden aggregiert, um die Leistung des Netzes zu überwachen. Es entsteht ein Testsystem mit erweiterten Fähigkeiten, um das Testen des Breitband-Mobilfunknetzes zu ermöglichen.

Description

Die Erfindung betrifft ein Testsystem zum Testen eines Breitband-Mobilfunknetzes und ein Testverfahren zum Testen eines Breitband-Mobilfunknetzes unter Verwendung eines solchen Testsystems.
Testsysteme für mobile Netze sind z.B. aus US 10,791,459 B1 , aus US 10,848,562 B1 , aus US 9,768,893 B1 , aus US 10,097,981 B1 , aus US 7,831,249 B2 und aus WO 2004/049746 A1 bekannt.
Es ist die Aufgabe der Erfindung, die Fähigkeiten eines solchen Testsystems zu erweitern, um das Testen eines Breitband-Mobilfunknetzes zu ermöglichen.
Diese Aufgabe wird durch ein Testsystem mit den Merkmalen des Anspruchs 1 und durch ein Testverfahren mit den Merkmalen des Anspruchs 5 gelöst.
Ein Beispiel für ein Breitband-Mobilfunknetz, welches über das Testsystem getestet werden soll, ist ein 5G-Netz. Hinsichtlich 5G wird auf den englischen Wikipedia-Eintrag „5G“ in der Fassung vom 18. März 2021 und die dort angegebenen Referenzen verwiesen. Ein Testsystem mit Schnittstellen für Smartphone-Prüfsonden (test probes), für Funk-Prüfsonden und für Kernnetz-Prüfsonden (core network) zu haben, führt zu einem sehr flexiblen und skalierbaren Ansatz in Bezug auf das Testen von Breitband-Mobilfunknetzen. Smartphone-Prüfsonden können zum Testen von Quality-of-Experience(= Erlebnisqualitäts)-Parametern (QoE) verwendet werden, insbesondere zum Testen entsprechender Key Performance Indicators (KPI = Leistungskennzahlen). Solche KPIs sind zum Beispiel in US 10,791,459 B 1 bezeichnet. Ein Smartphone oder eine Funk-Prüfsonde kann mit dem zu testenden Mobilfunknetz über eine NR Uu-Schnittstelle interagieren. Eine Kernnetz-Prüfsonde kann mit dem zu prüfenden Mobilfunknetz über standardisierte Schnittstellen interagieren, wie beispielsweise N1/N2, N3, N4, Nausf, Nudm oder Namf-Schnittstellen. Mit dem Testsystem ist eine End-to-End-Prüfung und/oder eine Netzkomponenten-Gruppenprüfung und/oder eine Netzkomponentenprüfung möglich. Eine Netzkomponente ist ein Teil des zu testenden Breitband-Mobilfunknetzes, der über mindestens eine standardisierte Schnittstelle mit dem übrigen Netz in Signal-/Datenverbindung steht. Ein solcher Schnittstellenstandard ist in der Regel über einen Netzstandard, beispielsweise 5G, definiert. Eine solche Netzkomponente kann als Netzfunktion, beispielsweise eine 5G-Netzfunktion, implementiert sein.
Das zentrale Testmodul des Testsystems wird auch als Haupt-Testmodul bezeichnet.
Die vorgegebene Testmethode kann eine benutzerdefinierte Testmethode sein.
Ein Testsystem nach Anspruch 2, d. h. eine Cloud-basierte Lösung, ermöglicht die Nutzung verteilter Prüfsondenstandorte und kann einen Zugriff auf national, international oder global verteilte Prüfsonden ermöglichen. Das zentrale Testmodul kann alternativ oder zusätzlich als COTS (common of the shelf = handelsübliche)-Hardware umgesetzt sein, kann auf mindestens einer virtuellen Maschine umgesetzt sein oder kann in mindestens einem Container umgesetzt sein. Im Hinblick auf Virtualisierung und Container wird auf den englischen Wikipedia-Eintrag „OS Level virtualization“ in der Fassung vom 27. März 2021 und die dort angegebenen Referenzen verwiesen.
Ein Testsystem mit mindestens einer Prüfsonde nach Anspruch 3 kann jeweils national und/oder international und/oder global verteilte Prüfsonden umfassen. Insbesondere ist dann ein Roaming-Test möglich. Insbesondere können solche Roaming-Tests über eine Vielzahl von jeweils international verteilten Funk-Prüfsonden durchgeführt werden. Die Prüfsonden können proprietär sein.
Eine Anwendungs-Programmierschnittstelle nach Anspruch 4 ermöglicht eine Interaktion zwischen Anwendungen Dritter und einem Testsystem. Solche externen Komponenten, die über eine API mit dem Testsystem interagieren können, können extern programmierte Netzfunktionen, Drittsysteme oder DevOps-Tools sein. Da eine solche API eine Schnittstelle zwischen einer externen Benutzersoftware und dem Testsystem herstellen kann, ist die API ein Beispiel für die mindestens eine Benutzerschnittstelle des Testsystems. Die API kann eine RESTful-API sein. Im Hinblick auf RESTful API wird auf den englischen Wikipedia-Eintrag „representational state transfer“ in der Fassung vom 17. März 2021 und die dort angegebenen Referenzen verwiesen. Das Testsystem mit der API kann in eine CI/CD-Pipeline integriert werden. In Bezug auf CI/CD-Pipeline und DevOps wird auf den englischen Wikipedia-Eintrag „CI/CD“ in der Fassung vom 23. März 2021 und die dort angegebenen Referenzen verwiesen.
Die oben beschriebenen Vorteile gelten auch für ein Testverfahren nach Anspruch 5. Neben einer Aggregation von Daten und Ergebnissen ist auch eine Kombination solcher Daten und Ergebnisse möglich, um weitere Erkenntnisse über das zu testende Breitband-Mobilfunknetz zu gewinnen.
Die Vorteile eines Testverfahrens nach Anspruch 6 entsprechen denen des Testsystems nach Anspruch 2.
Eine End-to-End-Sequenz nach Anspruch 7 ermöglicht es, die gesamte Daten-/Signalverbindung zwischen einem Endbenutzer und einem zu testenden Netzdienst zu testen.
Das Testen einer Gruppe von Netzkomponenten nach Anspruch 8 hilft, kritische Netzkomponenten innerhalb des zu testenden Breitband-Mobilfunknetzes zu identifizieren.
Dies gilt insbesondere für ein Testverfahren nach Anspruch 9.
Eine Zuordnung von Netz-Slices nach Anspruch 10 ermöglicht das Testen von einzelnen Netz-Slices des zu testenden Netzes. Hinsichtlich des Begriffs Slice wird auf den englischen Wikipedia-Eintrag „5G network slicing“ in der Fassung vom 18. März 2021 und die dort angegebenen Referenzen verwiesen. Die zu testenden Slices können über Radio-Access-Network (Funk-Zugangsnetz = RAN)-Slicing und/oder über Core-Network (Kernnetz = CN)-Slicing realisiert werden. Dies ist insbesondere bei einem zu testenden 5G-Netz vorteilhaft.
Die mit dem Testverfahren nach Anspruch 11 getesteten Slices können über eine NSSAI-Liste (network slice selection assistance information = Informationen zur Unterstützung bei der Netzwerk-Slice-Auswahl) identifiziert werden. Über ein solches Verfahren ist eine Zuordnung von QoS-Parametern zu einem jeweiligen zu testenden Netz-Slice möglich.
Mit dem Verfahren nach Anspruch 12 wird eine Interaktion zwischen Drittanwendungen und dem Testsystem ermöglicht. Mit einer solchen Interaktion werden maßgeschneiderte automatisierte Testabläufe bereitgestellt, die zu den jeweiligen Testanforderungen passen. Die verwendete API kann eine RESTful API sein. Das Testverfahren kann in eine CI/CD-Pipeline integriert werden. Insbesondere ist eine Steuerung und Konfiguration einer Datenextraktion und von Messungen des Testsystems mit einer solchen Testmethode möglich.
Ein Verfahren nach Anspruch 13 bietet weitere Testflexibilität. Beispiele für externe Komponenten, die mit einem solchen Verfahren gesteuert und/oder konfiguriert werden können, sind Systeme von Drittanbietern, DevOps-Tools und/oder weitere hinzugefügte 5G-Netzfunktionen.
Das zu testende Netz kann ein Roaming-Netz sein. Ein solches Roaming-Netz kann über eine Roaming-Testsequenz nach Anspruch 14 getestet werden.
Beispielhafte Ausführungsformen der Erfindung werden im Folgenden unter Bezugnahme auf die beigefügten Zeichnungen beschrieben. In diesen Zeichnungen zeigen:

1 schematisch Hauptkomponenten eines Testsystems zum Testen eines Breitband-Mobilfunknetzes, wobei hinsichtlich zentraler Komponenten, welche ein zentrales Testmodul umfassen, welches in der Lage ist, ein vorbestimmtes Testverfahren auszuführen, diese mit verschiedenen Einsatzmöglichkeiten dargestellt sind;
2 einen beispielhaften Aufbau des Testsystems mit verschiedenen Prüfsonden, die an die jeweiligen Netzkomponenten des zu testenden Breitband-Mobilfunknetzes angeschlossen werden;
3 schematisch Prüfpfade eines End-to-End-Prüfverfahrens, welches mit einem Testsystem nach 1 und 2 auszuführen ist;
4 in einer zu 3 ähnlichen Darstellung Prüfpfade eines segmentierten End-to-End-Prüfverfahrens, welches mit dem Testsystem nach 1 und 2 auszuführen ist;
5 schematisch Prüfpfade eines mit dem Testsystem nach 1 und 2 auszuführenden Netzfunktions-Isolationsprüfverfahrens;
6 in einer zu 2 ähnlichen Darstellung eine Prüfsonden-Konfiguration, wobei derartige Prüfsonden verschiedenen Netz-Slices des zu testenden Netzes zugeordnet sind; und
7 in einer zu 1 ähnlichen Darstellung die Einsatzmöglichkeiten des Haupttestmoduls des Testsystems zusammen mit Netzfunktionen, Drittsystemen und Entwicklungs-/Bedienungs-Tools, die gesteuert und/oder konfiguriert werden können, um maßgeschneiderte automatisierte Testsequenzen über das Testsystem auszuführen.

1 zeigt in einem Blockdiagramm ein Testsystem 1 zum Testen eines Breitband-Mobilfunknetzes. Das zu testende Breitband-Mobilfunknetz kann ein 5G-Netz sein. Das Testsystem 1 umfasst Benutzerschnittstellen 2 und 3. Die Benutzerschnittstelle 2 dient dazu, eine webbasierte Benutzerkommunikation mit einem Benutzerendgerät 4 zu ermöglichen, welches in einer Benutzerebene 5 zur Interaktion mit dem Testsystem 1 dargestellt ist. Die Benutzerschnittstelle 2 ist daher eine webbasierte Benutzerschnittstelle.
Die weitere Benutzerschnittstelle 3 ermöglicht eine Kommunikation mit einem Anwendungs-Programmiermodul 6, welches ebenfalls Teil der Benutzerebene 5 ist. Die Benutzerschnittstelle 3 ist also eine Anwendungs-Programmierschnittstelle (API). Eine solche API dient als Schnittstelle zwischen einer Benutzersoftware und dem Testsystem 1.
Die beiden Benutzerschnittstellen 2, 3 verbinden die Benutzerebene 5 mit einem zentralen Testmodul 7 des Testsystems 1. Bereitstellungsoptionen des zentralen Testmoduls 7 sind handelsübliche Hardware (COTS HW) 8 oder eine Bereitstellung als virtuelle Maschinen (VM) 9, die entsprechende virtualisierte Netzfunktionen (VNFs) aufbauen. Andere Bereitstellungsoptionen, die das zentrale Testmodul 7 einrichten können, sind Container 10 oder ein Cloud-Dienst 11. Der Cloud-Dienst 11 wird auf einem Cloud-basierten Server implementiert. Über diese Optionen 8 bis 11 kann eine Netzfunktions-Virtualisierung erfolgen, bei der entsprechende Software und Prozesse zur Durchführung vorgegebener Testmethoden ausgeführt werden.
Des Weiteren umfasst das Testsystem 1 weitere Schnittstellen, über welche das zentrale Testmodul 7 mit Prüfsonden (test probes) kommuniziert, die in 1 in einer Prüfsonden-Ebene 12 dargestellt sind. Über ein Smartphone-Prüfsonden-Schnittstellenmodul 13 ist das zentrale Testmodul 7 mit mindestens einer Smartphone-Prüfsonde 14 verbunden. Das Smartphone-Prüfsonden-Schnittstellenmodul 13 stellt somit eine Daten-/Signalverbindung zwischen dem mindestens einen Smartphone 14 und einer Netzkomponente des zu testenden Breitband-Mobilfunknetzes her. Das Betriebssystem des Smartphones, d. h. Android oder iOS, kann für Testzwecke nicht verändert werden und wird dem Tester so präsentiert, wie es einem realen Mobilfunkteilnehmer präsentiert werden würde. Alternativ kann das Smartphone 14 mit einer speziellen Test-App ausgestattet sein. Eine solche Test-App kann über das Smartphone-Prüfsonden-Schnittstellenmodul 13 bereitgestellt werden.
Weiterhin enthält das Testsystem 1 ein Funk-Prüfsonden-Schnittstellenmodul 15, das ebenfalls mit dem Haupt-Testmodul 7 verbunden ist. Das Funk-Prüfsonden-Schnittstellenmodul 15 stellt eine Daten-/Signalverbindung zwischen mindestens einer Funkprüfsonde 16 und einer Netzkomponente des zu testenden Breitband-Mobilfunknetzes her.
Weiterhin enthält das Testsystem 1 ein Kernnetz-Prüfsonden-Schnittstellenmodul 17, das ebenfalls mit dem Haupt-Testmodul 7 verbunden ist. Das Kernnetz-Prüfsonden-Schnittstellenmodul 17 stellt eine Daten-/Signalverbindung zwischen mindestens einem Kernnetz-Prüfsonde 18 und einer Netzkomponente des zu testenden Breitband-Mobilfunknetzes her.
Die Funk-Prüfsonden 16 und die Kernnetz-Prüfsonden 18 sind ebenfalls in der Prüfsonden-Ebene 12 dargestellt.
Je nach Konfiguration des Testsystems 1 können die Smartphone-Prüfsonden 14 und/oder die Funk-Prüfsonden 16 und/oder die Kernnetz-Prüfsonden 18 verwendet werden und gleichzeitig Teil des Testsystems sein oder während des jeweiligen vorgegebenen Testverfahrens hinzugefügt oder entfernt werden. Ferner können die Smartphone-Prüfsonden 14 und/oder die Funk-Prüfsonden 16 und/oder die Kernnetz-Prüfsonden 18 ein ursprünglicher Teil des Testsystems 1 sein oder zusätzliche, externe Geräte sein, die zunächst nicht Teil des Testsystems 1 sind, aber während des jeweiligen vorbestimmten Testverfahrens vom Testsystem 1 verwendet werden.
Die Prüfsonden 14, 16, 18 können als 5G-Prüfsonden ausgeführt sein.
Das Testsystem 1 konfiguriert und steuert die Prüfsonden, d.h. die Smartphone-Prüfsonden 14, die Funk-Prüfsonden 16 und die Kernnetz-Prüfsonden 18 sowie die Testverfahren. Das Testsystem 1 ist skalierbar und kann eine beliebige Anzahl von Testköpfen 14, 16, 18 in einer jeweils gewünschten Mischung und Kombination verbinden. Die Prüfsonden 14, 16, 18 werden über die Schnittstellenmodule 13, 15, 17 mit einer IP-Verbindung über feste oder mobile Transporttechnologien an das Testsystem 1 angeschlossen. Darüber hinaus sammelt und verbreitet das Testsystem 1 die Ergebnisse der Prüfsonden 14, 16, 18 und der Testverfahren und stellt eine vollständige Ansicht des zu testenden Breitband-Mobilfunknetzes zur Überwachung, Alarmierung und Fehlersuche bereit.
Das Testsystem 1 kann über die webbasierte Benutzerschnittstelle 2 oder das API-Modul 3, 6 konfiguriert und gesteuert werden. Die API kann eine programmierbare RESTful API sein. Die RESTful-API ermöglicht es Anwendungen von Drittanbietern, mit dem Testsystem 1 zu interagieren. Abhängig von der Konfiguration des Testsystems 1 gibt es möglicherweise keinen Unterschied in der Funktionalität für den Endbenutzer, wenn die webbasierte Benutzerschnittstelle 2 oder das API-Modul 3, 6 verwendet wird.
Das Testsystem 1 kann auf einem handelsüblichen (COTS) HW 8 eingesetzt werden, es kann als virtuelle Maschinen (VMs) 9 eingesetzt werden, es kann als Container 10 eingesetzt werden oder es kann als Cloud-Dienst 11 bereitgestellt werden. Unabhängig vom Bereitstellungsverfahren bietet das Testsystem dem Endbenutzer die gleiche Funktionalität.
2 zeigt eine beispielhafte Prüfsonden-Konfiguration des Testsystems 1, welches zum Testen bestimmter Netzkomponenten eines Breitband-Mobilfunknetzes 19, welches ein 5G-Netz sein kann, verwendet wird. Das Haupt-Testmodul 7 wird in diesem Fall als Cloud-Dienst 11 angeboten. In der Konfiguration aus 2 ist eine Smartphone-Prüfsonde 14 mit einer Netzkomponente 20 verbunden, die die Netzfunktion gNB ausführt. Hierzu stellt das Smartphone-Prüfsonden-Schnittstellenmodul 13 des Testsystems 1 eine Schnittstelle NR Uu zwischen der Smartphone-Prüfsonde 14 und der gNB-Netzkomponente 20 bereit.
In der Konfiguration aus 2 ist zusätzlich eine Funk-Prüfsonde 16 mit der gNB-Netzkomponente 20 verbunden. Insofern stellt das Funk-Prüfsonden-Schnittstellenmodul 15 auch eine NR Uu-Schnittstelle zur Verfügung.
Weiterhin werden in der Konfiguration aus 2 vier Kernnetz-Prüfsonden 18₁, 18₂, 18₃ und 18₄ innerhalb des Testsystems 1 verwendet.
Die Kernnetz-Prüfsonde 18₁ ist zum Testen einer Authentifizierungs-Serverfunktion AUSF vorgesehen. In dieser Hinsicht stellt das Kernnetz-Prüfsonden-Schnittstellenmodul 17 des Testsystems 1 eine Schnittstelle Nausf zwischen der Kernnetz-Prüfsonde 18₁ und einer Netzkomponente 21 bereit, die die Zugangs- und Mobilitätsmanagementfunktion AMF bereitstellt.
Die weitere Kernnetz-Prüfsonde 18₂ ist so konfiguriert, dass sie das Unified Data Management UDM des Netzes 19 testet. Dabei stellt das Kernnetz-Prüfsonden-Schnittstellenmodul 17 des Testsystems 1 eine Schnittstelle Nudm zwischen der Kernnetz-Prüfsonde 18₂ und der AMF-Netzkomponente 21 bereit.
Die weitere Kernnetz-Prüfsonde 18₃ dient zur Prüfung der gNodeB (gNB)-Funktion des Netzes 19. Dabei stellt das Kernnetz-Prüfsonden-Schnittstellenmodul 17 des Testsystems 1 eine Nl/N2-Schnittstellenverbindung der Kernnetz-Prüfsonde 18₃ mit der AMF-Netzkomponente 21 und eine N3-Schnittstellenverbindung der Kernnetz-Prüfsonde 18₃ mit einer Benutzer-Ebenen-Funktions (=user plane function, UPF)-Netzkomponente 22 des Netzes 19 bereit.
Die weitere Kernnetz-Prüfsonde 18₄ ist so konfiguriert, dass sie eine Sitzungsmanagementfunktion SMF des Netzes 19 testet. Dabei stellt das Kernnetz-Prüfsonden-Schnittstellenmodul 17 des Testsystems 1 eine Namf-Schnittstellenverbindung der Kernnetz-Prüfsonde 18₄ mit der AMF-Netzkomponente 21 und eine N4-Schnittstellenverbindung der Kernnetz-Prüfsonde 18₄ mit der UPF-Netzkomponente 22 bereit.
Das zu testende Netz 19 enthält weiterhin eine SMF-Netzkomponente 23. Die Netzkomponenten 20 und 21, 20 und 22 sowie 22 und 23 sind über Daten-/Signalnetz-Standard-Schnittstellenverbindungen 24₁, 24₂ und 24₃ miteinander verbunden. Über eine weitere standardisierte Schnittstellenverbindung 25 ist die UPF-Netzkomponente 22 des zu testenden Netzes 19 mit dem Cloud-Dienst 11, d. h. einem Datennetz und/oder einem IP-Multimedia-Subsystem (IMS), verbunden. Dieser Cloud-Dienst 11 ist Teil des Haupt-Testmoduls 7 des Testsystems 1.
Die Netzkomponenten 20 bis 23 sind jeweils Teil des zu testenden Netzes 19. Diese Netzkomponenten 20 bis 23 stehen über mindestens eine standardisierte Schnittstelle in Signal-/Datenverbindung mit dem übrigen Netz 19. Eine solche Standardisierung erfolgt nach einem jeweiligen Netzstandard, beispielsweise 5G.
Während eines vorbestimmten Durchlaufs eines Testverfahrens auf dem Testsystem 1 zum Testen des Breitband-Mobilfunknetzes 19 wird zunächst eine Gruppe von Prüfsonden, d.h. Prüfsonden 14, 16, 18₁ bis 18₄, den zu testenden Netzkomponenten 20 bis 23 des Netzes 19 über die jeweiligen Schnittstellenmodule 13, 15 und 17 des Testsystems 1 zugeordnet. Nach dieser Zuordnung wird mindestens ein Testablauf innerhalb des Netzes 19 über das Testsystem 1 durchgeführt. Die Daten und Ergebnisse der Prüfsonden 14, 16, 18 und der Testsequenzen werden dann im Testsystem 1, insbesondere im zentralen Testmodul 7, gesammelt und/oder kombiniert, um die Leistungsfähigkeit des Netzes 19 zu überwachen. Über die Benutzerschnittstellen 2, 3 können solche Daten und Ergebnisse angezeigt werden und/oder eine Interaktion zwischen Dritten/Drittanwendungen und dem Testsystem 1 wird ermöglicht.
Unter Bezugnahme auf 3 bis 5 werden spezifischere Beispiele für Testverfahren und Testabläufe beschrieben.
3 zeigt ein Beispiel für einen End-to-End (E2E) Prüfablauf, der mit einer bestimmten Prüfsonden-Konfiguration des Testsystems 1 durchgeführt werden kann. Dabei wird eine Smartphone-Prüfsonde 14 über eine Schnittstellenverbindung 27₁, welche über das Smartphone-Prüfsonden-Schnittstellenmodul 13 des Testsystems 1 hergestellt wird, mit einer bestimmten Netzkomponente 26₁ verbunden. Während des Testablaufs verbinden weitere Schnittstellenverbindungen 27₂, 27₃ diese Netzkomponente 26₁ und damit die Smartphone-Prüfsonde 14 mit weiteren Netzkomponenten 26₂ und 26₃ des zu testenden Netzes 19. Über eine weitere Schnittstellenverbindung 27₄ ist die Netzkomponente 26₃ mit einem bestimmten Netzdienst 28 verbunden, der über das zu testende Netz 19 ausgeführt werden kann.
Über die Schnittstellenverbindungen 27₁ bis 27₄ erfolgt ein End-to-End-Test des Netzdienstes 28 mit der Smartphone-Prüfsonde 14 über die Netzkomponente 26₁ bis 26₃.
Weiterhin ist in der Prüfsonden-Konfiguration nach 3 ein Funk-Prüfsonde 16 über eine weitere Schnittstellenverbindung 29₁, die wiederum vom Funk-Prüfsonden-Schnittstellenmodul 15 des Testsystems bereitgestellt wird, mit der Netzkomponente 26₁ verbunden. Weitere Schnittstellenverbindungen 29₂, 29₃ und 29₄ verbinden die Netzkomponente 26₁, 26₃ und weiterhin die Netzkomponente 26₃ mit einer weiteren Netzkomponente 26₄ des zu prüfenden Netzes 19 und stellen so eine Daten-/Signalverbindung zur Funk-Prüfsonde 16 her. Über eine weitere Schnittstellenverbindung 29₅ wird eine Daten-/Signalverbindung zwischen der Netzkomponente 26₄ und einem weiteren Netzdienst 30 des zu testenden Netzes 19 hergestellt. Über die Schnittstellenverbindungen 29₁ bis 29₅ wird somit ein End-to-End-Prüfverfahren des Netzdienstes 30 durch die Funk-Prüfsonde 16 unter Verwendung der Netzkomponente 26₁ bis 26₄ durchgeführt.
Bei diesen End-to-End-Prüfverfahren wird der gesamte Daten-/Signalweg zwischen der jeweiligen Prüfsonde 14, 16 und dem jeweiligen Netzdienst 28, 30 einschließlich aller dazwischen liegenden Netzkomponenten 26₁ bis 26₃ bzw. 26₁ bis 26₄ geprüft.
Beispielsweise kann der zu testende Netzdienst 28, 30 ein Datumsdienst, ein Sprachdienst, ein Nachrichtendienst, ein Videodienst und jeder andere Dienst der Anwendungs-Ebene sein, der über das zu testende Netz 19 angeboten wird.
Beim Testen eines 5G-Netzes 19 verwendet das E2E-Prüfverfahren die 5G-Smartphone-basierte Prüfsonde 14 und/oder die 5G-Funk-Prüfsonde 16 zur Durchführung verschiedener Arten von Tests, z. B. Daten, Sprache, Video. Das E2E-Prüfverfahren verwendet das Testsystem 1 und die Prüfsonden 14, 16, um die Serviceleistung (Quality of Service (QoS) und Quality of Experience (QoE)) zu messen, wie sie der Endbenutzer erlebt. Die Prüfsonden 14, 16 werden an der 5G NR Uu-Schnittstelle eingesetzt, der gleichen Schnittstelle, an der die Teilnehmer auf den Dienst zugreifen werden.
4 zeigt eine Konfiguration für ein segmentiertes End-to-End (E2E) Prüfverfahren. Bestandteile und Funktionen, die bereits oben unter Bezugnahme auf 1 bis 3 und insbesondere in Bezug auf 3 beschrieben wurden, weisen dieselben Bezugsziffern auf und werden nicht nochmals im Detail erläutert.
In der Konfiguration nach 4 ist eine zusätzliche Kernnetz-Prüfsonde 18 innerhalb des zu testenden Netzes 19 implementiert. Diese Kernnetz-Prüfsonde 18 steht über eine Schnittstellenverbindungssequenz 31₁, 31₂ und 31₃, die wiederum über das Kernnetz-Prüfsonden-Schnittstellenmodul 17 des Testsystems 1 hergestellt wird, in Daten-/Signalverbindung mit den Netzkomponenten 26₂, 26₃ und dem Netzdienst 28. Weiterhin steht die Kernnetz-Prüfsonde 18 der Konfiguration nach 4 über eine weitere Schnittstellenverbindungssequenz 32₁, 32₂, 32₃ und 32₄ in Daten-/Signalverbindung mit dem Netzdienst 30. Auf diese Weise ist die Kernnetz-Prüfsonde 18 in der Lage, die Netzdienste 28, 30 unter Umgehung der Netzkomponente 26₁ zu testen. Durch den Vergleich von Testergebnissen, die mit den Prüfsonden 14, 16 einerseits und mit der Kernnetz-Prüfsonde 18 andererseits erzielt wurden, ist es möglich, die Leistung der Netzkomponente 26₁ zu isolieren und zu analysieren.
Beim Testen eines 5G-Netzes 19 verwendet das E2E-Prüfverfahren die 5G-Smartphone-basierte Prüfsonde 14 und/oder die 5G-Funk-Prüfsonde 16 zur Durchführung verschiedener Arten von Tests, z. B. Daten, Sprache, Video. Das segmentierte E2E-Prüfverfahren verwendet die 5G-Smartphone-basierte Prüfsonde 14 und/oder die 5G-Funk-Prüfsonde 16 und die 5G-Kemnetz-Prüfsonden 18, um verschiedene Teile eines E2E-Netzes zu segmentieren, um Leistungs- oder Serviceprobleme zu isolieren. Die 5G-Kernnetz-Prüfsonde 18 kann so konfiguriert werden, dass sie verschiedene 5G-Netzfunktionen und ihre zugehörigen Schnittstellenprotokolle emuliert, z. B. N1/N2, N3, N4 usw. Das segmentierte E2E-Prüfverfahren gibt Einblick in die Serviceleistung für ein Segment des Netzes 19 und identifiziert das Netzsegment und/oder die Netzkomponente, in dem Leistungsabfall oder Fehler aufgetreten sind.
5 zeigt eine Konfiguration zum Testen einer isolierten Netzfunktion 26₁ über eine Vielzahl von Kernnetz-Prüfsonden 18₁, 18₂, 18₃, 18₄,18₅. Jede dieser Kernnetz-Prüfsonden 18₁ bis 18₅ steht über spezifische Schnittstellenverbindungen 33₁, 33₂, 33₃, 33₄, 33₅ in Daten-/Signalverbindung mit der zu testenden Netzkomponente 26₁. Diese Schnittstellenverbindungen 33₁ bis 33₅ werden wiederum über das Kernnetz-Prüfsonden-Schnittstellenmodul 17 des Testsystems 1 bereitgestellt.
Über die Konfiguration nach 5 kann ein Testverfahren zur Isolierung der Netzfunktion durchgeführt werden.
Beim Testen des 5G-Netzes 19 verwendet das E2E-Prüfverfahren die 5G-Smartphone-basierte Prüfsonde 14 und/oder die 5G-Funk-Prüfsonde 16 zur Durchführung verschiedener Arten von Tests, z. B. Daten, Sprache, Video. Das Netzfunktions-Isolationsverfahren verwendet die 5G-Kernnetz-Prüfsonden 18_i und optional die 5G-Funk-Prüfsonden 16 zur Isolation einer 5G-Netzkomponente 26₁, beispielsweise AMF mit allen relevanten Schnittstellen, d. h. N1/N2, N3, N4, Nausf, Nudm, Namf, zum Zweck von Funktions-, Last- und Protokolltests der zu testenden Netzkomponente 26₁. Das Verfahren setzt die Fähigkeit der 50-Kernnetz-Prüfsonden 18n wirksam ein, verschiedene 5G-Netzfunktionen und ihre zugehörigen standardisierten Protokollschnittstellen zu emulieren. Für das Netzfunktions-Isolationsprüfverfahren werden eine oder mehrere Kernnetz-Prüfsonden 18_i so konfiguriert, dass sie die Netzfunktionen und standardisierten Schnittstellenprotokolle emulieren, die direkt mit der zu testenden Netzfunktion oder Netzkomponente 26₁ verbunden sind.
Außerdem kann mit dem Testsystem 1 ein Roaming-Testverfahren bereitgestellt werden. Für den Fall, dass ein 5G-Breitband-Mobilfunknetz 19 getestet werden soll, verwendet das 5G-Roaming-Testverfahren ein globales Netz von 5G-Funk-Prüfsonden 16 und das über die Cloud 11 bereitgestellte Testsystem 1, um Tests durchzuführen, wobei insbesondere das oben beschriebene E2E-Prüfverfahren zum Testen und Messen der 5G-Leistung beim Roaming verwendet wird. Der Zugriff auf die 5G-Funk-Prüfsonden für 5G-Roaming-Tests kann über das zentrale Testmodul erfolgen.
In einem bestimmten Testverfahren können bei einer Zuordnung eines vom Testsystem 1 durchzuführenden Testverfahrens die Prüfsonden 14, 16, 18 des Testsystems 1 verschiedenen Netz-Slices 34_i des zu testenden Netzes 19 zugeordnet werden. Dies wird im Folgenden unter Bezugnahme auf 6 beschrieben.
Bestandteile und Funktionen, die bereits oben in Bezug auf die 1 bis 5 beschrieben wurden, weisen die gleichen Bezugsziffern auf und werden nicht nochmals im Detail erläutert.
5G-Netz-Slicing ist ein Verfahren, die Fähigkeiten der 5G-Netzarchitektur und -funktionalität wirksam einsetzt, um verschiedene logische Netzwerke unter Verwendung derselben zugrunde liegenden physischen Infrastruktur zu erstellen. Dies wird durch bestimmte Konfigurations- und Identifikationselemente ermöglicht, die in den 5G-Protokollnachrichten verfügbar sind, die zwischen einem Gerät (Benutzergerät = user equipment, UE) und den verschiedenen Netzelementen ausgetauscht werden. Die zu testenden Slices 34_i können über Radio Access Network RAN Slicing und/oder über Core Network CN Slicing realisiert werden.
In der Konfiguration nach 6 steht die gNB-Netzkomponente 20 über Standard-Schnittstellenverbindungen 35₁, 35₂ und 35₃ in Daten-/Signalverbindung mit den Netz-Slices 34₁, 34₂, 34₃. An die gNB-Netzkomponente 20 ist jeweils eine AMF-Netzkomponente 21₁, 21₂, 21₃ mit jeweils einem Slice angeschlossen. Der jeweilige Netz-Slice 34₁ bis 34₃ kann weiterhin eine zugeordnete Sitzungsmanagementfunktion SMF und eine zugeordnete Benutzer-Ebenen-Funktion (=user plane function) UPF enthalten.
Die gNB-Netzkomponente 20 kann als globale Netzfunktion oder als eine den jeweiligen Netz-Slices 34₁ bis 34₃ zugeordnete Slice-Funktion bereitgestellt werden.
Eine Kernnetz-Prüfsonde 18, deren prinzipielle Funktionalität derjenigen der Kernnetz-Prüfsonde 18₃ in der Konfiguration nach 2 entspricht, steht in der Konfiguration nach 6 über die jeweiligen N1/N2-Schnittstellenverbindungen, welche wiederum vom Kernnetz-Prüfsonden-Schnittstellenmodul 17 des Testsystems 1 bereitgestellt werden, in Daten-/Signalverbindung mit den AMF-Netzkomponenten 21₁ bis 21₃ der Netz-Slices 34₁ bis 34₃.
Das Testverfahren für das 5G-Netz-Slicing verwendet die 5G-Prüfsonden 14, 16, 18 und die in den vorherigen Abschnitten beschriebenen Testverfahren, um drei verschiedene Ebenen der Steuerung, Parametrierung und Informationstiefe zu erstellen, um die 5G-Netz-Slices 34₁ bis 34₃ zu testen und zu überwachen. Das Testverfahren kann sowohl RAN- als auch Kernnetz-Slicing testen und ist unabhängig davon, in welchem Modus der Netz-Slice 34₁ bis 34₃ ausgebildet und implementiert ist.
Die 5G-Smartphone-basierte Prüfsonde und das Testverfahren bieten das höchste Maß an Informationen und Kontrolle für das Testen von 5G-Netz-Slicing. Die Smartphone-Prüfsonde 14 kann so konfiguriert sein, dass sie das gleiche Verhalten reproduziert und automatisiert, welches ein Benutzer im Slice 34_i auf der Ebene der Benutzerschnittstelle eines Smartphones haben wird. Die von diesen Smartphone-Prüfsonden 14 bereitgestellten Informationen spiegeln die 5G-QoE wider, wie sie der Endbenutzer unter Berücksichtigung der spezifischen 5G-Smartphone-Prüfsonde 14 und des spezifischen 5G-Netz-Slices 34_i erlebt. Für dieses Testverfahren wird der Netz-Slice 34_i auf der Grundlage der Teilnehmerinformationen einer SIM-Karte ausgewählt, die für den Test verwendet wird.
Die 5G-Funk-Prüfsonde und das Testverfahren bieten eine Zwischenebene an Informationen und Kontrolle für das Testen von 5G-Netz-Slicing. Die von diesen Funk-Prüfsonden 16 bereitgestellten Informationen spiegeln die von dem 5G-Netz-Slice 34_i bereitgestellte QoS wider, unabhängig von einer bestimmten 5G-Smartphone-Implementierung. Darüber hinaus extrahiert das Testverfahren die NSSAI-Liste (Network Slice Selection Assistance Information) und S-NSSAI(s) (Single-Network-Slice-Selection-Assistance-Information = Informationen zur Unterstützung bei der Einzel-Netzwerk-Slice-Auswahl) aus den Traces der Radio Resource Control (Funk-Ressourcen-Steuerung)- und des Non-Access-Stratum (= Nicht-Zugriffs-Schicht) und stellt sie als KPIs (Key Performance Indicators) bereit. Eine NSSAI-Liste und/oder eine Korrelation der QoS zum jeweiligen Slice 34_i sind Beispiele für Testparameter, welche für die verschiedenen Netz-Slices 34_i während des Testverfahrens und insbesondere während der Durchführung mindestens einer Testsequenz und während der Aggregation der Daten und Ergebnisse aus den Prüfsonden und den Testsequenzen erfasst werden.
Bei dieser Testmethode wird der Netz-Slice 34_i auf der Grundlage der Teilnehmerinformationen der SIM-Karte ausgewählt, die für den Test verwendet wird.
Die 5G-Kernnetz-Sonden und das Testverfahren bieten die niedrigste Informations- und Steuerungsebene für das Testen von 5G-Netz-Slicing. Die 5G-Kernnetz-Prüfsonden 18 bieten die Möglichkeit, Parameter auf Protokollebene zu steuern, so dass das Testsystem die NSSAI-Liste und S-NSSAI(s) konfigurieren und Endbenutzer für die jeweiligen Netz-Slices 34_i emulieren kann. Abhängig von der Art der 5G-Kernnetzsonde 18, d. h. der 5G-Emulationsschnittstelle, werden die NSSAI und S-NSSAI(s) entsprechend dem jeweiligen Protokoll konfiguriert, das auf dieser Schnittstelle läuft, z. B. Layer 3 Non Access Stratum NAS, NGAP. Ein Layer 3 Trace ist ein Trace auf Protokollschicht 3, die für Radio-Resource-Control- und Non-Access-Stratum-Nachrichten zuständig ist.
Das Testsystem 1 aggregiert die Daten und Ergebnisse der oben beschriebenen 5G-Prüfsonden und Testverfahren und kann zur Überwachung der Leistung für jeden 5G-Netz-Slice 34_i auf Basis der NSSAI und S-NSSAI(s) verwendet werden. Darüber hinaus ermöglichen die Fähigkeiten des Testsystems 1 die Verarbeitung von Testdaten in Bezug auf die Netz-Slices 34_i zur:

- Erstellung von Gesamt-Slice-Performance-KPIs unter Verwendung einer gewichteten Aggregationsmethode für Testdaten, die von 5G-Smartphone-, Funk- und Kernnetz-Prüfsonden 14, 16, 18 abgerufen werden. Korrelation und Ableitung von Erkenntnissen aus den Pro-Slice-Testdaten der verschiedenen Sonden, beispielsweise Korrelation von Leistungseinbußen oder der Nichtverfügbarkeit von Diensten auf einem 5G-Smartphone mit KPIs, die von Kernnetz-Prüfsonden 18 abgeleitet wurden, die Tests auf denselben Slices 34_i (dieselbe S-NSSAI) durchführen.

Das Testsystem 1 und die oben erläuterten Testverfahren lassen sich in einen Continuous-Integration/Continuous-Development-Software-Engineering-Prozess integrieren, insbesondere in eine CI/CD-Pipeline. Dies wird im Folgenden auch unter Bezugnahme auf 7 beschrieben. Bestandteile und Funktionen, die bereits oben in Bezug auf die 1 bis 6 beschrieben wurden, weisen die gleichen Bezugsziffern auf und werden nicht nochmals im Detail erläutert.
Über die Benutzerschnittstelle 3 und das Anwendungsprogrammier-Schnittstellenmodul 6 steht das Haupt-Testmodul 7 in Daten-/Signalverbindung mit einer Nutzerebene 36 einschließlich spezifischer Netzkomponenten/Netzfunktionen 37, die in einem Breitband-Mobilfunknetz, insbesondere in einem 5G-Netz, zu implementieren sind, Dritt-Systemen 38 und Entwicklungs-/IT-Betriebs-(DevOps)-Tools 39. Über das Anwendungsprogrammier-Schnittstellenmodul 6 können die Testverfahren und -abläufe gesteuert und/oder konfiguriert werden, um maßgeschneiderte automatisierte Testsequenzen auszuführen. Insbesondere wird eine Interaktion zwischen Drittanwendungen in der Nutzerebene 36 und dem Testsystem 1 ermöglicht. Auch eine Steuerung und Konfiguration der Datenextraktion und Messungen des Testsystems kann ermöglicht werden. Weiterhin werden über das Anwendungs-Programmierschnittstellenmodul 6 der Komponenten außerhalb des zu testenden Netzes 19, insbesondere die Dritt-Systeme 38 in der Nutzerebene 36, gesteuert und/oder konfiguriert, um maßgeschneiderte automatisierte Testsequenzen auszuführen.
Der CI/CD-Prozess, der ursprünglich für die Softwareentwicklung und -bereitstellung geschaffen wurde, ermöglicht die automatisierte Einführung neuer Software-Veröffentlichungen in einem schnellen Tempo. CI/CD-Prozesse werden nun auf 5G angewendet und werden durch die Ausgestaltung des 5G-Netzes und seiner Funktionen ermöglicht, die die Integration von 5G-Netz- und Service-Design-, Bereitstellungs-, Start- und Betriebsprozessen in einen automatisierten CI/CD-Prozess ermöglichen.
Das in den Abschnitten beschriebene Testsystem 1 bietet Verfahren und Komponenten, mit denen das Testsystem in beliebige CI/CD-Prozess-Tools wie Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo oder Travis CI usw. integriert werden kann. Bei der Integration in solche Tools können das Testsystem 1, die Prüfsonden 14, 16, 18 und die Testverfahren für kontinuierliche Tests eingesetzt werden. Das Testsystem bietet:

- Die Anwendungs-Programmierschnittstelle (API) 6, die Systeme von Drittanbietern ermöglicht, zu denen unter anderem CI/CD-Tools, Funktionen oder Software zur Steuerung des Testsystems gehören 1 -die Fähigkeit, automatisiert zu werden
- Verfahren, die vom Testsystem 1 verwendet werden, um Drittsysteme, Funktionen oder Software zu steuern - die Fähigkeit zu automatisieren.

Das Testsystem 1 bietet die Anwendungs-Programmierschnittstelle (API) 6, die einer Industriestandardarchitektur folgen kann. Die API 6 ermöglicht Systemen von Drittanbietern, zu denen unter anderem CI/CD-Tools und Software gehören, das Testsystem 1 zu steuern und zu automatisieren. Die API 6 ermöglicht es Systemen, Tools und Software von Drittanbietern:

- Die im Testsystem verfügbaren Testverfahren 1 zu steuern und zu konfigurieren;
- Daten und Messungen aus dem Testsystem 1 zu extrahieren;
- Ereignisse zu beziehen, die vom Testsystem 1 erzeugt werden, z. B. Alarme.

Beispiele für solche Tools können Dev/Ops-Tools sein, z. B. Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo oder Travis CI, Nachrichten- und Kollaborationssysteme, z. B. Slack, und jedes andere Tool, das insbesondere mit der RESTful API des Testsystems 1 interagieren kann.
Das Testsystem 1 stellt Werkzeuge und Verfahren zur Verfügung, mit denen Dritt-Systeme 38, Funktionen oder Software automatisiert und interagiert werden können. Das Testsystem 1 bietet:

- Verfahren zur Automatisierung von Interaktionen und Steuerung mit den APIs, die von Dritt-Systemen 38, -Tools und -Software von bereitgestellt werden;
- Verfahren zur Automatisierung der Interaktion mit Befehlszeilenschnittstellen, die von Dritt-Systemen 38, -Tools und -Software von Drittanbietern bereitgestellt werden;
- Verfahren zur Automatisierung der Interaktion mit webbasierten Anwendungen, insbesondere mit der 5G-Netzfunktion 37 und den DevOps-Tools 39.

Der Zugriff auf zumindest einige der verwendeten Prüfsonden 14, 16, 18 kann über den cloudbasierten Server, d. h. über den Cloud-Dienst 11, erfolgen.
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

US 10791459 B1 [0002]
US 10848562 B1 [0002]
US 9768893 B1 [0002]
US 10097981 B1 [0002]
US 7831249 B2 [0002]
WO 2004/049746 A1 [0002]
US 10791459 [0005]

Claims

Testsystem (1) zum Testen eines Breitband-Mobilfunknetzes (19), wobei das Testsystem (1) umfasst: - mindestens eine Benutzerschnittstelle (2, 3), - mindestens ein zentrales Testmodul (7), welches in der Lage ist, ein vorgegebenes Testverfahren durchzuführen, - ein Smartphone-Prüfsonden-Schnittstellenmodul (13), welches mit dem zentralen Testmodul (7) verbunden ist, wobei das Smartphone-Prüfsonden-Schnittstellenmodul (13) in der Lage ist, eine Daten-/Signalverbindung zwischen mindestens einer Smartphone-Prüfsonde (14) und einer Netzkomponente (20; 26₁) des Breitband-Mobilfunknetzes (19) herzustellen, - ein Funk-Prüfsonden-Schnittstellenmodul (15), welches mit dem zentralen Testmodul (7) verbunden ist, wobei das Funk-Prüfsonden-Schnittstellenmodul (15) in der Lage ist, eine Daten-/Signalverbindung zwischen mindestens einer Funk-Prüfsonde (16) und einer Netzkomponente (20; 26₁) des Breitband-Mobilfunknetzes (19) herzustellen, - ein Kernnetz-Prüfsonden-Schnittstellenmodul (17), welches mit dem zentralen Testmodul (7) verbunden ist, wobei das Kernnetz-Prüfsonden-Schnittstellenmodul (17) in der Lage ist, eine Daten-/Signalverbindung zwischen mindestens einer Kernnetz-Prüfsonde (18) und einer Netzkomponente (21, 22; 26₂; 26₁; 21₁, 212, 213) des Breitband-Mobilfunknetzes (19) herzustellen.
Testsystem nach Anspruch 1, wobei das zentrale Testmodul (7) auf einem cloudbasierten Server (11) implementiert ist.
Testsystem nach Anspruch 1 oder 2, umfassend: - eine Mehrzahl von Funk-Prüfsonden (16) und/oder - eine Mehrzahl von Kernnetz-Prüfsonden (18) und/oder - eine Mehrzahl von Smartphone-Prüfsonden (14).
Testsystem nach einem der Ansprüche 1 bis 3, wobei die Benutzerschnittstelle (2, 3) eine Anwendungs-Programmierschnittstelle (API) enthält.
Testverfahren zum Testen eines Breitband-Mobilfunknetzes (19) unter Verwendung eines Testsystems (1) nach einem der Ansprüche 1 bis 4, welches die folgenden Schritte umfasst: - Zuordnen einer Gruppe von Prüfsonden (14, 16, 18₁ bis 18₄; 14, 16; 14, 16, 18; 18₁ bis 18₅) zu Netzkomponenten (20, 21, 22; 26₁; 26₁, 26₂, 26₁; 20, 21₁, 21₂, 21₃) des zu prüfenden Netzes (19) über die jeweiligen Schnittstellenmodule (13, 15, 17), - Durchführung mindestens einer Testsequenz innerhalb des Netzes (19), - die Aggregation der Daten und Ergebnisse der Prüfsonden (14, 16, 18) und der Testsequenzen zur Überwachung der Leistung des Netzes (19).
Testverfahren nach Anspruch 5, wobei der Zugriff auf mindestens einen Teil der verwendeten Prüfsonden (14, 16, 18) über den cloudbasierten Server erfolgt.
Testverfahren nach Anspruch 5 oder 6, wobei mithilfe mindestens eines Teils der Prüfsonden (14, 16) eine End-to-End-Testsequenz durchgeführt wird.
Testverfahren nach einem der Ansprüche 5 bis 7, wobei mithilfe mindestens eines Teils der Prüfsonden (14, 16, 18) eine Testsequenz zum Testen einer Gruppe von Netzkomponenten (26_i, 20, 21_i) durchgeführt wird.
Testverfahren nach einem der Ansprüche 5 bis 8, wobei mithilfe mindestens eines Teils der Prüfsonden (18_i) eine Testsequenz zum Testen einer einzelnen Netzkomponente (26₁) durchgeführt wird.
Testverfahren nach einem der Ansprüche 5 bis 9, wobei bei der Zuordnung Prüfsonden (14, 16, 18) verschiedenen Netz-Slices (34_i) des zu testenden Netzes (19) zugeordnet werden.
Testverfahren nach Anspruch 10, wobei während des Tests die Leistungs- und die Datenaggregations-Testparameter für verschiedene Netz-Slices (34_i) erfasst werden.
Testverfahren nach einem der Ansprüche 5 bis 11, wobei über die Anwendungs-Programmierschnittstelle (3) die Testabläufe gesteuert und/oder konfiguriert werden, um maßgeschneiderte automatisierte Testsequenzen auszuführen.
Testverfahren nach einem der Ansprüche 5 bis 12, wobei über die Anwendungs-Programmierschnittstelle (3) Komponenten (37, 38, 39) außerhalb des zu testenden Netzes (19) gesteuert und/oder konfiguriert werden, um maßgeschneiderte automatisierte Testsequenzen auszuführen.
Testverfahren nach einem der Ansprüche 5 bis 13, wobei mithilfe mindestens eines Teils der Prüfsonden (16) eine Testsequenz zum Testen eines Roaming-Netzes (19) durchgeführt wird.