[go: up one dir, main page]

WO2019029797A1 - A network management system for a multi-operator communication network - Google Patents

A network management system for a multi-operator communication network Download PDF

Info

Publication number
WO2019029797A1
WO2019029797A1 PCT/EP2017/070158 EP2017070158W WO2019029797A1 WO 2019029797 A1 WO2019029797 A1 WO 2019029797A1 EP 2017070158 W EP2017070158 W EP 2017070158W WO 2019029797 A1 WO2019029797 A1 WO 2019029797A1
Authority
WO
WIPO (PCT)
Prior art keywords
sub
network
entity
information
control entity
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.)
Ceased
Application number
PCT/EP2017/070158
Other languages
French (fr)
Inventor
Osama Abboud
Ishan Vaishnavi
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to PCT/EP2017/070158 priority Critical patent/WO2019029797A1/en
Publication of WO2019029797A1 publication Critical patent/WO2019029797A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4604LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462LAN interconnection over a bridge based backbone
    • H04L12/4625Single bridge functionality, e.g. connection of two networks over a single bridge
    • 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/02Standardisation; Integration
    • H04L41/022Multivendor or multi-standard integration
    • 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/04Network management architectures or arrangements
    • H04L41/044Network management architectures or arrangements comprising hierarchical management structures
    • 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/12Discovery or management of network topologies
    • H04L41/122Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
    • 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/085Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information

Definitions

  • the present invention relates to the field of communication networks and network slicing. More specifically, the present invention relates to a network management system for a multi-operator communication network, which enables the discovery of network entities managing network slices and/or resources within the multi-operator communication network.
  • an OSS is deployed to provide specific services and their visibility to third parties (in terms of networks, domains, or operators) is limited.
  • third parties in terms of networks, domains, or operators
  • a key issue will be to enable communications between different OSSs provided by different operators in the 5G network systems.
  • so far it is not possible to disclose internal services of an OSS of an operator system to other OSSs of other operators in an automated fashion.
  • Operations Support System a system used to manage the networks by network/telecom providers.
  • this includes also systems used to manage the systems within a 5G service ecosystem by network, connectivity, as well as cloud providers.
  • OSS manager an administrative entity responsible for a certain OSS and managing its registration and integration into the 5G ecosystem.
  • Discovery agent - a local agent running on an OSS in a P2P architecture that is responsible for communicating and maintaining sessions to other neighboring OSSs.
  • Operator an owner of the OSS and the respective resources (network, services, etc.)
  • OSS registrar an entity responsible for certifying OSSs taking part in the 5G Ecosystem.
  • OSS Discovery Service ODS
  • SLODS Sub Level ODS
  • Root ODS an entity responsible for acting as a top level and entry point for other SLODSs within a distributed architecture.
  • Network Slice Management Function NSMF
  • NSSMF Network Slice Subnet Management Function
  • Subnet/Infrastructure manager a local entity that manages local resources.
  • NFVO Network Function Virtualization Orchestrator.
  • VIM Virtualized Infrastructure Manager.
  • Controller a local network entity responsible for controlling local domain resources.
  • Resources actual controller resources that comprise: network connectivity, compute, and storage functions that can be chained together to form richer network services.
  • Orchestrator - a coordinator which is used to provide orchestration of computing and network resources of the infrastructure. It is used to deploy network slices upon the infrastructure according to the deployment template, and manage the lifecycle of the network slices.
  • the present invention relates to a network management system and a corresponding method for managing a multi-operator communication network. More specifically, embodiments of the present invention provide OSS management systems based on different architectures and the relevant interfaces and procedures for automatically and efficiently managing OSS registration, discovery and updates of cross- operator OSSs.
  • the network management systems according to embodiments of the present invention are based on the following different architectures: centralised, distributed, P2P and multi-layer.
  • the invention relates to a network management system for a multi-operator communication network, wherein the multi- operator communication network comprises a plurality of sub-networks operated by different network operators, each sub-network comprising a sub-network control entity configured to control one or more network slices of the respective sub-network, wherein the network management system comprises a discovery entity configured to retrieve information about the one or more network slices of each sub-network of the plurality of sub-networks and/or information about the respective sub-network control entity from the respective sub-network control entity.
  • the information about a respective sub-network control entity can include any information exposed by the respective sub-network control entity.
  • the discovery entity is associated with the sub-network control entity of one of the subnetworks of the plurality of sub-networks and configured to peer with respective further discovery entities associated with the sub-network control entities (i.e. local OSS discovery agents) of the other sub-networks of the plurality of sub-networks for retrieving information about the one or more network slices of each sub-network and/or information about the respective sub-network control entity from the respective sub-network control entity.
  • the sub-network control entities i.e. local OSS discovery agents
  • the discovery entity is a centralized network entity of the multi-operator communication network and wherein each sub-network control entity is configured to request and retrieve information about the one or more network slices of each of the other sub-networks and/or information about the respective sub-network control entity of each of the other subnetworks from the centralized discovery entity (herein also referred to as ODS entity).
  • ODS entity centralized discovery entity
  • each sub-network control entity is further configured to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity to the discovery entity (i.e. the ODS entity).
  • the system further comprises a registration unit and a plurality of sub-network administration units, wherein each sub- network administration unit is implemented in one of the plurality of sub-networks, wherein upon request of one of the plurality of sub-network administration units (i.e. local OSS managers) the registration unit is configured to check the validity of the request and, if valid, to register the corresponding sub-network control entity with the discovery entity (i.e. ODS entity) for allowing the respective sub-network control entity (i.e.
  • local OSS manager to request and retrieve information about the one or more network slices of each of the other sub-networks and/or information about the respective sub-network control entity of each of the other sub-networks from the discovery entity (i.e. ODS entity) and/or to provide updated information about the one or more network slices of the respective subnetwork and/or information about the respective sub-network control entity to the discovery entity (i.e. ODS entity).
  • the discovery entity comprises a plurality of distributed network entities of the multi-operator communication network and wherein the plurality of distributed network entities of the multi-operator communication network comprise a root discovery entity (herein also referred to as root ODS entity) and a plurality of sub-level discovery entities (herein also referred to as sub-level ODS entities), wherein the root discovery entity comprises address information for each of the plurality of sub-level discovery entities and wherein each of the plurality of sub-level discovery entities is configured to retrieve information about the one or more network slices of each sub-network and/or information about the respective sub-network control entity from t e respective sub-network control entity for a respective subset of the plurality of sub-networks.
  • root ODS entity a root discovery entity
  • sub-level ODS entities herein also referred to as sub-level ODS entities
  • each respective sub-network control entity is configured to request and retrieve information from a respective sub-level control entity about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub-networks and/or information about the respective sub-network control entity of each of the other sub-networks of the respective subset of the plurality of sub-networks.
  • each respective sub-network control entity is further configured to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity to the respective sub-level control entity of each of the other sub-networks of the respective subset of the plurality of sub-networks.
  • system further comprises a registration unit and a plurality of sub-network administration units, wherein each sub-network administration unit is implemented in one of the plurality of sub-networks, wherein each of the plurality of sub-network administration units (i.e.
  • local OSS managers has to register with the registration unit for registering the respective sub-network control entity with a respective sub-level discovery entity before being allowed to request and retrieve information from a respective sub-level control entity about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub-networks and/or information about the respective sub-network control entity of each of the other sub-networks and/or to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity to the respective sub-level discovery entity.
  • the discovery entity comprises a memory (in particular a database) configured to store the information about the one or more network slices of each sub-network of the plurality of sub-networks and/or information about the respective sub-network control entity retrieved from the respective sub-network control entity.
  • the information about the one or more network slices of each sub-network and/or information about the respective sub-network control entity retrieved from the respective sub-network control entity comprises an identifier of the operator of the respective sub-network control entity, security credentials of the respective sub-network control entity, an IP address of the respective sub-network control entity, a port number of the respective sub-network control entity, information about the version of a software running on the respective sub-network control entity, a geographical location of the respective sub-network control entity, a network tier of the operator of the respective sub-network control entity and/or service types offered by the respective sub-network control entity.
  • the sub-network control entity of each sub-network is a multi-domain orchestrator.
  • the invention relates to a method for managing a multi- operator communication network, wherein the multi-operator communication network comprises a plurality of sub-networks operated by different network operators, each subnetwork comprising a sub-network control entity configured to control one or more network slices of the sub-network, wherein the method comprises the step of retrieving by a discovery entity information about the one or more network slices of each sub-network of the plurality of sub-networks and/or information about the respective sub-network control entity from the respective sub-network control entity.
  • an improved method for managing a multi-operator communication network, which enables the discovery of network entities managing network slices and/or resources within the multi-operator communication network.
  • the discovery entity is associated with the sub-network control entity of one of the sub-networks of the plurality of sub-networks and configured to peer with respective further discovery entities associated with the subnetwork control entities of the other sub-networks of the plurality of sub-networks for retrieving information about the one or more network slices of each sub-network and/or information about the respective sub-network control entity of each of the other subnetworks from the respective sub-network control entity.
  • the method comprises the further step of providing updated information about the one or more network slices of the subnetwork of the sub-network control unit and/or information about the respective subnetwork control entity to the discovery entity.
  • the method comprises the further steps, in response to a request of a sub-network administration unit, checking the validity of the request and, if valid, registering the corresponding sub-network control entity with the discovery entity for allowing the sub-network control entity to request and retrieve information about the one or more network slices of each of the other sub-networks and/or information about the respective sub-network control entity of each of the other subnetworks from the discovery entity and/or to provide updated information about the one or more network slices of the sub-network and/or information about the respective subnetwork control entity to the discovery entity.
  • the discovery entity comprises a plurality of distributed network entities of the multi-operator communication network and wherein the plurality of distributed network entities of the multi-operator communication network comprise a root discovery entity and a plurality of sub-level discovery entities, wherein the root discovery entity comprises address information for each of the plurality of sub-level discovery entities and wherein the method comprises the further step of retrieving information about the one or more network slices of each sub-network and/or information about the respective sub-network control entity of each of the other subnetworks from the respective sub-network control entity for a respective subset of the plurality of sub-networks.
  • the method comprises the further steps of requesting and retrieving information from a respective sub-level discovery entity about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub-networks and/or information about the respective subnetwork control entity of each of the other sub-networks of the respective subset of the plurality of sub-networks by the respective sub-network control entity.
  • the method comprises the further step of providing updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity from the respective sub-network control entity to the respective sub-level discovery entity.
  • the method comprises the further step of registering a sub-network administration unit with a registration unit, for registering the respective sub-network control entity with a respective sub-level discovery entity for allowing the respective sub-network control entity to request and retrieve information from the respective sub-level discovery entity about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub-networks and/or information about the respective sub-network control entity of each of the other subnetworks and/or to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity to the respective sub-level discovery entity.
  • the invention can be implemented in hardware and/or software.
  • Fig. 1 shows a schematic diagram of a multi-operator communication network comprising a network management system according to an embodiment based on a centralized architecture
  • Fig. 2 shows a schematic diagram of a multi-operator communication network comprising a network management system according to an embodiment based on a P2P architecture
  • Fig. 3 shows a schematic diagram of a multi-operator communication network comprising a network management system according to an embodiment based on a distributed architecture
  • Fig. 4a shows a diagram illustrating a registration procedure within a network management system according to an embodiment based on a centralized architecture
  • Fig. 4b shows a diagram illustrating a discovery procedure within a network management system according to an embodiment based on a centralized architecture
  • Fig. 4c shows a diagram illustrating an update procedure within a network management system according to an embodiment based on a centralized architecture
  • Fig. 5a shows a diagram illustrating a registration procedure within a network management system according to an embodiment based on a distributed architecture
  • Fig. 5b shows a diagram illustrating a discovery procedure within a network management system according to an embodiment based on a distributed architecture
  • Fig.6a shows a diagram illustrating a discovery procedure within a network management system according to an embodiment based on a distributed architecture
  • Fig. 6b shows a diagram illustrating an update procedure within a network management system according to an embodiment based on a distributed architecture
  • Fig. 7 shows a schematic diagram of a multi-operator communication network comprising a network management system according to an embodiment based on a centralized architecture
  • Fig. 8 shows a schematic diagram of a multi-operator communication network comprising a network management system according to an embodiment based on a centralized architecture
  • Fig. 9 shows a schematic diagram illustrating a method for managing a multi-operator communication network according to an embodiment.
  • identical reference signs will be used for identical or at least functionally equivalent features.
  • a disclosure in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa.
  • a corresponding device may include a unit to perform the described method step, even if such unit is not explicitly described or illustrated in the figures.
  • embodiments of the invention relate to network management systems comprising network entities in the form of an OSS Discovery Service (ODS) entity, an OSS registrar, and an OSS manager in a 5G multi- domain reference model that depicts a possible 5G ecosystem allowing multi-operator service management.
  • ODS OSS Discovery Service
  • OSS registrar an OSS registrar
  • OSS manager in a 5G multi- domain reference model that depicts a possible 5G ecosystem allowing multi-operator service management.
  • the network management systems according to embodiments of the present invention are based on different architectures: namely centralised, distributed, P2P, and/or multi-layer.
  • a multi-operator architecture comprising an Operations Support System (OSS) and a subnet/infrastructure manager is assumed in embodiments of the invention, wherein the OSS orchestrates resources across multiple domains and the subnet/infrastructure manager manages resources in a local domain.
  • OSS Operations Support System
  • subnet/infrastructure manager manages resources in a local domain.
  • network services can be provided by multiple operators, different operators may be interested in building connections and maintaining sessions with one another.
  • a single operator can have multiple OSSs which shall communicate to offer chained services and slicing functionalities.
  • embodiments of the invention relate to a network management system for a multi-operator communication network, wherein the multi-operator communication network comprises a plurality of sub-networks operated by different network operators, each subnetwork comprising a sub-network control entity configured to control one or more network slices of the respective sub-network, wherein the network management system comprises a discovery entity configured to retrieve information about the one or more network slices of each sub-network of the plurality of sub-networks and/or information about the respective sub-network control entity from the respective sub-network control entity.
  • Figure 1 shows a schematic diagram of a multi-operator communication network 100 comprising a network management system according to an embodiment based on a centralized architecture.
  • the multi-operator communication network 100 comprises three sub-networks operated by different network operators, namely by the operators A, B and C.
  • Each sub-network comprises one or more sub-network control entities in the form of a OSS entity 1 10a-e configured to control one or more network slices and/or network resources of the respective sub-network.
  • the respective OSS entities 1 10a-e configured to control one or more network slices and/or network resources of the respective subnetwork can be one or more multi-domain orchestrators.
  • the sub-network operated by the operator A comprises the OSS entities 1 10a and 110b
  • the sub-network operated by the operator B comprises the OSS entities 1 10c and 1 10d
  • the sub-network operated by the operator C comprises the OSS entity 1 1 Oe.
  • the network management system comprises a discovery entity in the form of an ODS entity 120 configured to retrieve information about the one or more network slices of each subnetwork of the plurality of sub-networks and/or information about the respective OSS entities 1 10a-e from the respective OSS entities 1 10a-e.
  • each respective OSS entity 1 10a-e associated with a given sub-network is configured to request and retrieve information about the one or more network slices of each of the other sub-networks and/or information about the respective OSS entities 1 10a-e of the other sub-networks from the centralized discovery entity (i.e. ODS entity) 120.
  • each OSS entity 1 10a-e is further configured to provide updated information about the one or more network slices of the respective sub-network and/or information about t e respective OSS entity 1 10a-e to the centralized discovery entity (i.e. ODS entity) 120.
  • the network management system further comprises a plurality of sub- network administration units (herein also referred to as OSS managers or local managers) 130a-c.
  • each sub-network administration unit i.e. OSS manager
  • 130a-c is implemented in one of the plurality of sub-networks.
  • the network management system further comprises a registration unit in the form of a OSS registrar 140, wherein upon request of one of the plurality of subnetwork administration units (i.e. OSS managers) 130a-c the registration unit 140 is configured to check the validity of the request and, if valid, to register the corresponding sub-network control entity (i.e. OSS entity) 1 10a-e with the discovery entity (i.e. ODS entity) 120 for allowing the respective sub-network control entity (i.e. OSS entity) 131 a-e to request and retrieve information about the one or more network slices of each of the other sub-networks and/or information about the respective OSS entities 1 10a-e of the other sub-networks from the discovery entity (i.e. ODS entity) 120 and/or to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective OSS entities 1 10a-e to the discovery entity (i.e. ODS entity) 120.
  • one of the OSS managers 130a-c can be responsible for starting the registration process with the OSS registrar 140, and the OSS registrar 140 can be responsible for registering new OSSs 1 10a-c and verifying their legitimacy.
  • the OSS registrar 140 can also provide access information to register, discover, and update the OSS information, in addition to basic information handled by a Domain Name System (DNS), e.g. IP.
  • DNS Domain Name System
  • the ODS entity 120 can handle new information types such offered slice/services and geo location.
  • the ODS entity 120 itself can comprise a database for storing all information of the OSS 1 10a-e and maintain a session or/and a connection to all OSSs 1 10a-e in the system.
  • the information that the ODS 120 can maintain comprises the following: operator_name (official name of the operator); access_keys (used for registration); IP_ addresses (IPv4 or IPv6, used to connect to the OSS); port (used for the connection); oss_version (version of a software running on the OSS); geojocation (geographical location where the OSS is deployed); network_tier (a network tier of the operator indicating t e operator size); service_type (a list of offered services to be used during the OSS discovery, e.g. besteffort, Germany, loT, etc).
  • all OSSs 1 10a-e can register at the OSS registrar 140 and then open connects to the ODS entity 120. New OSSs register through the OSS registrar 140 as well.
  • the ODS entity 120 has a database that stores the registered OSSs and their information.
  • all OSSs 1 10a-e register and maintain sessions at the ODS entity 120. OSS discovery can be done using a query at the ODS entity 120.
  • FIG. 2 shows a schematic diagram of a multi-operator communication network 100 comprising a network management system according to an embodiment based on a P2P architecture.
  • the multi-operator communication network 100 comprises four sub-networks operated by different network operators, wherein each sub-network comprises a sub-network control entity in the form of an OSS entity 1 10a-d configured to control one or more network slices and/or network resources of the respective sub-network.
  • the respective OSS entity 1 10a-d is configured to control one or more network slices and/or network resources of the respective sub-network can be a multi-domain orchestrator.
  • the discovery entity that is configured to retrieve information about the one or more network slices of each sub-network of the plurality of sub-networks and/or information about the respective OSS entities 1 10a-d of the other sub-networks from the respective OSS entities 1 10a-d is provided in the form of a respective discovery agent 1 1 1 a-d.
  • a respective discovery agent for instance the discovery agent 1 1 1 a, is configured to peer with OSS discovery agents 11 1 b-d of the other sub-networks of the plurality of sub-networks for retrieving information about the one or more network slices of each sub- network and/or information about the respective OSS entities 1 10a-d of the other subnetworks.
  • the respective discovery agents 1 1 1 1 a-d are separate from the respective OSS entities 1 10a-d.
  • the respective discovery agents 1 1 1 a-d can be implemented as a part of the respective OSS entities 1 10a-d.
  • the respective discovery entity can be provided by the respective OSS entity 1 10a-d itself.
  • P2P ODS embodiments according to the invention provide an architecture in which each OSS entity 1 10a-d will peer with neighbouring agents.
  • the respective local OSS discovery agent 1 1 1 a-d is responsible for opening and managing sessions to neighbouring OSSs 1 10a-d. IPs of remote OSSs can be configured manually. Keep alive messages can be sent regularly. Service discovery can be done using a query at the peering discovery agent 1 1 1 a-d.
  • FIG. 3 shows a schematic diagram of a multi-operator communication network comprising a network management system 100 according to an embodiment based on a distributed architecture.
  • the multi-operator communication network 100 comprises three sub-networks operated by different network operators, namely by the operators A, B and C.
  • Each sub-network comprises one or more sub-network control entities in the form of an OSS entity 1 10a-e configured to control one or more network slices and/or network resources of the respective sub-network.
  • the respective OSS entities 1 10a-e configured to control one or more network slices and/or network resources of the respective subnetwork can be a multi-domain orchestrator.
  • the sub-network operated by the operator A comprises the OSS entities 1 10a and 1 10b
  • the sub-network operated by the operator B comprises the OSS entities 1 10c and 1 10d
  • the sub-network operated by the operator C comprises the OSS entity 1 10e.
  • the discovery entity comprises a root discovery entity (herein also referred to as root ODS entity) 120a and, by way of example, two sub- level discovery entities (herein also referred to as sub-level ODS entities) 120b.
  • the root ODS entity 120a comprises address information for each of the two sub-level ODS entities 120b and each of the two sub-level ODS entities 120b is configured to retrieve information about the one or more network slices of each subnetwork and/or information about the respective OSS entities 1 10a-e from the respective OSS entities 1 10a-e for a respective subset of the plurality of sub-networks.
  • a first sub-level ODS entity 120b is configured to retrieve information about the one or more network slices of the sub-network controlled by the OSS entities 1 10a, 1 10b and a second sub-level ODS entity 120b is configured to retrieve information about the one or more network slices of the respective sub-networks controlled by the OSS entities 1 10c, 1 10d and 1 10e.
  • the respective OSS entities 1 10a-e located in one of the plurality of sub-networks are configured to request and retrieve information from the respective sub-level ODS entity 120b about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub- networks and/or information about the respective OSS entities 1 10a-e of each of the other sub-networks of the respective subset of the plurality of sub-networks.
  • the OSS entities 1 10c and/or 1 10d implemented in the sub-network of the operator B can retrieve information from the sub-level ODS entity 120b about the one or more network slices of the sub-network of the operator C and/or the OSS entity 1 10e thereof.
  • each OSS entity 1 10a-e can be further configured to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective OSS entity 1 10a-e to the respective sub-level ODS entity 120b, as illustrated by the arrows in figure 3.
  • the registration unit in the form of the OSS registrar 140 is configured such that each of the plurality of local OSS managers 130a-c has to register the corresponding OSS entities 1 10a-e with the OSS registrar 140 before the corresponding OSS entities 1 10a-e are allowed to request and retrieve information from a respective sub-level ODS entity 120b about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub-networks and/or information about the respective OSS entities 1 10a-e of the other sub-networks and/or to provide updated information about the one or more network slices of the respective subnetwork and/or information about the respective OSS entities 1 10a-e to the respective sub-level ODS entity 120b.
  • Root ODS entity 120a is located at the top level and knows the entry points to all SL-ODS 120b, reachable via Any-cast.
  • a respective sub level ODS 120b can be a geo-local discovery service, aware about OSSs 1 10a-e in a certain geographical and/or administrative location. New OSSs can register through the OSS registrar 140. OSSs 1 10a-e use the root ODS 120a to get the SLODS 120b responsible for them.
  • Each SLODS 120b can have a database that stores the registered OSSs 1 10a-e and their information in their geographical and/or administrative location.
  • All OSSs 110a-e register and maintain sessions at the assigned SLODS 120b.
  • OSS discovery is done using a query at the SLODS 120b covering their geographical location. In case the SLODS 120b is asked for a service in another geographical location, it asks the SLODS 120b of other locations, as will be described in more detail further below.
  • a multi-layer ODS can be provided by expanding the layers of the ODS shown in figure 3 and adding more layers in order to allow for scaling.
  • two layers of ODSs are present between the root ODS 120a and the SL-ODS 120b. These can be expanded, for instance, to a total of 4 layers.
  • the benefit of such a design is flexibility and scalability. Flexibility is achieved via defining an adequate number of layers as required. Scalability is achieved as the load on the specific SL-ODS 120b is reduced due to distributed load balancing.
  • the multi-layer architecture is very similar to the distributed one with the exception that there can be multiple layers existing between the root ODS entity 120a and the SL-ODS 120b. Each layer can contain the so called intermediary ODSs.
  • An intermediary ODS is responsible for all ODSs in the lower layers and reports to its parent ODS just like in a tree structure. As with the distributed architecture, each SL-ODS entity can be responsible for a specific geo-location (e.g. Germany). An intermediary ODS in a specific layer is responsible to link the SL-ODS in the lower layer to the upper layers and to the SL-ODS of the neighboring geo-locations.
  • Figures 4a, 4b and 4c show respective diagrams illustrating a registration procedure, a discovery procedure and an update procedure within a network management system according to an embodiment based on a centralized architecture, such as the network management system shown in figure 1 .
  • the request procedure shown in figure 4a comprises the following main steps: the OSS manager 130a sends a request to the OSS registrar 140, which checks the validity thereof; if valid, the OSS registrar 140 provides the OSS manager 130a with access credentials, such as access keys and addresses; the OSS manager 130a provides the access credentials to the associated OSS entity 1 10a, which uses these access credentials for registering with the ODS entity 120.
  • the discovery procedure shown in figure 4b comprises the following main steps: the OSS entity 1 10a sends a request for network services to the ODS 120, including, for instance, information about the type of network services required; on the basis of this information the ODS 120 queries its database of registered OSS entities, including the OSS entity 1 10b and the OSS entity 1 10c, and returns the results to the OSS entity 1 10a; in response the OSS entity requests connection to the OSS entity 1 10b and the OSS entity 1 10c, respectively.
  • the update procedure shown in figure 4c comprises the following main steps: the OSS entity 1 10a, which is already registered, sends a change/update request to the ODS entity 120; if accepted by the ODS entity 120, the OSS entity 1 10a provides the updated information to the ODS entity 120.
  • Figures 5a and 5b show respective diagrams illustrating a registration procedure and a discovery procedure within a network management system according to an embodiment based on a distributed architecture, such as the network management system shown in figure 3.
  • the request procedure shown in figure 5a comprises the following main steps: the OSS manager 130a sends a request to the OSS registrar 140, which checks the validity thereof; if valid, the OSS registrar 140 provides the OSS manager 130a with access credentials, such as access keys and addresses; the OSS manager 130a provides the access credentials to the associated OSS entity 1 10a; the OSS entity 1 10a requests from the root ODS entity 120a the IP address of the sub-level ODS entity 120b to be assigned to the OSS entity 1 10a (for instance, based on the geographical location of the OSS entity 1 10a); the root ODS entity 120a returns the IP address of the sub-level ODS entity 120b closest to the OSS entity 1 10a; the OSS entity 1 10a uses the access credentials for registering with the sub-level ODS entity 120a, to which is has been assigned by the root ODS entity 120a.
  • the discovery procedure shown in figure 5b comprises the following main steps: the OSS entity 1 10a sends a request for network services to the sub-level ODS entity 120b the OSS entity 1 10a is assigned to, including, for instance, information about the type of network services required; on the basis of this information the sub-level ODS entity 120b queries its database of registered OSS entities, including the OSS entity 1 10b and the OSS entity 1 10c, and returns the results to the OSS entity 1 10a; in response the OSS entity requests connection to the OSS entity 1 10b and the OSS entity 1 10c, respectively.
  • Figure 6a shows a diagram illustrating the corresponding discovery procedure within a network management system according to an embodiment based on a distributed architecture, such as the network management system shown in figure 3, for a case where the requested network services cannot be provided by another OSS entity assigned to the sub-level ODS entity 120b, to which the service requesting OSS entity 1 10a is assigned to.
  • the discovery procedure shown in figure 6a comprises the following main steps: the OSS entity 1 10a sends a request for network services to a first sub-level ODS entity 120b the OSS entity 1 10a is assigned to, including, for instance, information about the type of network services required; if the requested network services cannot be provided by one of the OSS entities assigned to the first sub-level ODS entity 120b, the first sub-level ODS entity 120b will send a corresponding request to the root ODS entity 120a, which will return the IP address of a second sub-level ODS entity 120b that can provide the network services requested by the OSS entity 1 10a; in response thereto, the first sub-level ODS entity 120b forwards the original request to the second sub-level ODS entity 120b; on the basis of the information included in the request the second sub-level ODS entity 120b queries its database of registered (i.e. assigned) OSS entities, including the OSS entity 1 10b and the OSS entity 1 10c, and returns the results to the first sub-level ODS entity 120
  • Figure 6b shows a diagram illustrating an update procedure within a network management system according to an embodiment based on a distributed architecture, such as the network management system shown in figure 3.
  • the update procedure shown in figure 6b comprises the following main steps: the OSS entity 1 10a, which is already registered and assigned to the sub-level ODS entity 120b, sends a change/update request to the sub- level ODS entity 120b; if accepted by the sub-level ODS entity 120b, the OSS entity 1 10a provides the updated information to the sub-level ODS entity 120b.
  • the registration procedure in the multi-layer embodiments follows a similar procedure with the exception that the assignment of the SL ODS is done by querying the intermediary ODSs until the SL-ODS responsible for the request geo-location is reached.
  • the discovery procedure in the multi-layer embodiments follows a similar procedure with the exception that in case the SLODS cannot answer a query itself, it forwards the query one layer up to its parent, i.e. an intermediary ODS. This is done recursively until the root ODS entity is reached. At the point the responsible SLODS details are send back to the querying OSS entity.
  • the update follows the exact same procedure as for the distributed architecture.
  • Figure 7 shows a schematic diagram of the multi-operator communication network 100 comprising different embodiments of the network management system based on a centralized architecture within a 3GPP environment.
  • the NSMF Network Slice Management Function
  • the NSSMF Network Slice Subnet Management Function
  • the NSMF has the role of the OSS 1 10a and the NSSMF has the role of a Subnet/Infrastructure Manager.
  • the OSS Manager 130a will be used to trigger registration of the NSMF 1 10a at the OSS Registrar 140.
  • the NSMF 1 10a can connect to the ODS 120 to perform the discovery and update procedures described above.
  • FIG. 8 shows a schematic diagram of the multi-operator communication network 100 comprising different embodiments of the network management system based on a centralized architecture within a general Cloud/IT environment.
  • a general multi-domain orchestrator (acting as an OSS 1 10a) is provided and the subnet/infrastructure manager that manages the local resources.
  • the multi-domain orchestrator 1 10a will make use of the OSS Manager 130a, the OSS Registrar 140, and the ODS entity 120 to manage, register, discover/update in order to realize connectivity across different multi-domain orchestrators 1 10a,b.
  • Such an embodiment can be used by cloud providers, storage providers, computing providers, and SaaS and PaaS providers.
  • a further embodiment of the network management system can be based on a centralized architecture within an ETSI environment.
  • ETSI GR NFV I FA 028 VO.5.0 2017-04
  • the NFVO has the role of the OSS entity and the VIM has the role of a Subnet/Infrastructure Manager.
  • the OSS Manager will be used to trigger registration of the NFVO at the OSS Registrar.
  • the NFVO can connect to the ODS entity to perform the discovery and update procedures described above.
  • Figure 9 shows a schematic diagram illustrating a corresponding method 900 for managing the multi-operator communication network 100 described above, wherein the multi-operator communication network 100 comprises a plurality of sub-networks operated by different network operators, each sub-network comprising a sub-network control entity configured to control one or more network slices of the sub-network.
  • the method 900 comprises the step 901 of retrieving by a discovery entity information about the one or more network slices of each sub-network of the plurality of sub-networks and/or information about the respective sub-network control entity from the respective subnetwork control entity.
  • the method 900 can be performed by different embodiments of the network management system described above. Thus, further embodiments of the method 900 result directly from the functionality of the network management system described above and its different embodiments.

Landscapes

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

Abstract

The invention relates to a network management system for a multi-operator communication network (100), wherein the multi-operator communication network (100) comprises a plurality of sub-networks operated by different network operators, each sub-5 network comprising a sub-network control entity (110a-e) configured to control one or more network slices of the respective sub-network, wherein the network management system comprises a discovery entity (120) configured to retrieve information about the one or more network slices of each sub-network of the plurality of sub-networks and/or information about the respective sub-network control entity (110a-e) from the respective 10 sub-network control entity (110a-e).

Description

A NETWORK MANAGEMENT SYSTEM FOR A MULTI-OPERATOR COMMUNICATION
NETWORK
TECHNICAL FIELD
In general, the present invention relates to the field of communication networks and network slicing. More specifically, the present invention relates to a network management system for a multi-operator communication network, which enables the discovery of network entities managing network slices and/or resources within the multi-operator communication network.
BACKGROUND
In the context of the 5th Generation (5G) mobile technology, substantial efforts are being made in order to enable diverse use cases and scenarios for the next-generation communication systems, in particular applications and use cases with high bandwidth, ultra-low latency, and high reliability. To support such applications and use cases, it is essential to integrate the systems of different networks provided by the same operator as well as the systems of different networks by different operators collectively. These systems are usually managed by entities called Operations Support Systems (OSSs) or multi-domain orchestrators.
Generally, an OSS is deployed to provide specific services and their visibility to third parties (in terms of networks, domains, or operators) is limited. In order to provide supports of new use cases, cloud integration as well as cross-operator support, a key issue will be to enable communications between different OSSs provided by different operators in the 5G network systems. However, so far it is not possible to disclose internal services of an OSS of an operator system to other OSSs of other operators in an automated fashion.
In light of the above, there is a need for an improved network management system as well as a corresponding method for a multi-operator communication network with a plurality of sub-networks, which enable the discovery of network entities managing network slices and/or resources within the multi-operator communication network. SUMMARY
It is an object of the invention to provide an improved network management system and a method for a multi-operator communication network with a plurality of sub-networks, which enable the discovery of network entities managing network slices and/or resources within the multi-operator communication network.
The foregoing and other objects are achieved by the subject matter of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.
The following disclosure employs a plurality of terms which, in embodiments, have the following meaning: Operations Support System (OSS) - a system used to manage the networks by network/telecom providers. In the context of the application, this includes also systems used to manage the systems within a 5G service ecosystem by network, connectivity, as well as cloud providers. OSS manager - an administrative entity responsible for a certain OSS and managing its registration and integration into the 5G ecosystem. Discovery agent - a local agent running on an OSS in a P2P architecture that is responsible for communicating and maintaining sessions to other neighboring OSSs. Operator - an owner of the OSS and the respective resources (network, services, etc.) OSS registrar - an entity responsible for certifying OSSs taking part in the 5G Ecosystem. OSS Discovery Service (ODS) - an entity responsible for OSS management by maintaining sessions with each OSS and a local database of all registered ODSs. Sub Level ODS (SLODS) - an entity that maintains sessions and a local database of all registered ODSs within a specific geographical region. Root ODS - an entity responsible for acting as a top level and entry point for other SLODSs within a distributed architecture. Network Slice Management Function (NSMF) - function that manages a network slice in a 3GPPP system. Network Slice Subnet Management Function (NSSMF) - function that manages a network slice subnet in a 3GPPP system. Subnet/Infrastructure manager - a local entity that manages local resources. NFVO - Network Function Virtualization Orchestrator. VIM - Virtualized Infrastructure Manager. Controller - a local network entity responsible for controlling local domain resources. Resources - actual controller resources that comprise: network connectivity, compute, and storage functions that can be chained together to form richer network services. Orchestrator - a coordinator which is used to provide orchestration of computing and network resources of the infrastructure. It is used to deploy network slices upon the infrastructure according to the deployment template, and manage the lifecycle of the network slices.
Generally, the present invention relates to a network management system and a corresponding method for managing a multi-operator communication network. More specifically, embodiments of the present invention provide OSS management systems based on different architectures and the relevant interfaces and procedures for automatically and efficiently managing OSS registration, discovery and updates of cross- operator OSSs. The network management systems according to embodiments of the present invention are based on the following different architectures: centralised, distributed, P2P and multi-layer.
More specifically, according to a first aspect the invention relates to a network management system for a multi-operator communication network, wherein the multi- operator communication network comprises a plurality of sub-networks operated by different network operators, each sub-network comprising a sub-network control entity configured to control one or more network slices of the respective sub-network, wherein the network management system comprises a discovery entity configured to retrieve information about the one or more network slices of each sub-network of the plurality of sub-networks and/or information about the respective sub-network control entity from the respective sub-network control entity. In an implementation form, the information about a respective sub-network control entity can include any information exposed by the respective sub-network control entity. Thus, an improved network entity is provided for a communication network with a plurality of sub-networks, which enables the discovery of network entities managing network slices and/or resources within the multi-operator communication network.
In a further implementation form of the first aspect based on a P2P architecture, the discovery entity is associated with the sub-network control entity of one of the subnetworks of the plurality of sub-networks and configured to peer with respective further discovery entities associated with the sub-network control entities (i.e. local OSS discovery agents) of the other sub-networks of the plurality of sub-networks for retrieving information about the one or more network slices of each sub-network and/or information about the respective sub-network control entity from the respective sub-network control entity. In a further implementation form of the first aspect based on a centralized architecture, the discovery entity is a centralized network entity of the multi-operator communication network and wherein each sub-network control entity is configured to request and retrieve information about the one or more network slices of each of the other sub-networks and/or information about the respective sub-network control entity of each of the other subnetworks from the centralized discovery entity (herein also referred to as ODS entity).
In a further implementation form of the first aspect, each sub-network control entity is further configured to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity to the discovery entity (i.e. the ODS entity).
In a further implementation form of the first aspect, the system further comprises a registration unit and a plurality of sub-network administration units, wherein each sub- network administration unit is implemented in one of the plurality of sub-networks, wherein upon request of one of the plurality of sub-network administration units (i.e. local OSS managers) the registration unit is configured to check the validity of the request and, if valid, to register the corresponding sub-network control entity with the discovery entity (i.e. ODS entity) for allowing the respective sub-network control entity (i.e. local OSS manager) to request and retrieve information about the one or more network slices of each of the other sub-networks and/or information about the respective sub-network control entity of each of the other sub-networks from the discovery entity (i.e. ODS entity) and/or to provide updated information about the one or more network slices of the respective subnetwork and/or information about the respective sub-network control entity to the discovery entity (i.e. ODS entity).
In a further implementation form of the first aspect based on a distributed architecture, the discovery entity comprises a plurality of distributed network entities of the multi-operator communication network and wherein the plurality of distributed network entities of the multi-operator communication network comprise a root discovery entity (herein also referred to as root ODS entity) and a plurality of sub-level discovery entities (herein also referred to as sub-level ODS entities), wherein the root discovery entity comprises address information for each of the plurality of sub-level discovery entities and wherein each of the plurality of sub-level discovery entities is configured to retrieve information about the one or more network slices of each sub-network and/or information about the respective sub-network control entity from t e respective sub-network control entity for a respective subset of the plurality of sub-networks.
In a further implementation form of the first aspect based on a distributed architecture, each respective sub-network control entity is configured to request and retrieve information from a respective sub-level control entity about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub-networks and/or information about the respective sub-network control entity of each of the other sub-networks of the respective subset of the plurality of sub-networks.
In a further implementation form of the first aspect based on a distributed architecture, each respective sub-network control entity is further configured to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity to the respective sub-level control entity of each of the other sub-networks of the respective subset of the plurality of sub-networks.
In a further implementation form of the first aspect based on a distributed architecture, the system further comprises a registration unit and a plurality of sub-network administration units, wherein each sub-network administration unit is implemented in one of the plurality of sub-networks, wherein each of the plurality of sub-network administration units (i.e. local OSS managers) has to register with the registration unit for registering the respective sub-network control entity with a respective sub-level discovery entity before being allowed to request and retrieve information from a respective sub-level control entity about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub-networks and/or information about the respective sub-network control entity of each of the other sub-networks and/or to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity to the respective sub-level discovery entity.
In a further implementation form of the first aspect, the discovery entity comprises a memory (in particular a database) configured to store the information about the one or more network slices of each sub-network of the plurality of sub-networks and/or information about the respective sub-network control entity retrieved from the respective sub-network control entity. In a further implementation form of the first aspect, the information about the one or more network slices of each sub-network and/or information about the respective sub-network control entity retrieved from the respective sub-network control entity comprises an identifier of the operator of the respective sub-network control entity, security credentials of the respective sub-network control entity, an IP address of the respective sub-network control entity, a port number of the respective sub-network control entity, information about the version of a software running on the respective sub-network control entity, a geographical location of the respective sub-network control entity, a network tier of the operator of the respective sub-network control entity and/or service types offered by the respective sub-network control entity.
In a further implementation form of the first aspect, the sub-network control entity of each sub-network is a multi-domain orchestrator. According to a second aspect the invention relates to a method for managing a multi- operator communication network, wherein the multi-operator communication network comprises a plurality of sub-networks operated by different network operators, each subnetwork comprising a sub-network control entity configured to control one or more network slices of the sub-network, wherein the method comprises the step of retrieving by a discovery entity information about the one or more network slices of each sub-network of the plurality of sub-networks and/or information about the respective sub-network control entity from the respective sub-network control entity.
Thus, an improved method is provided for managing a multi-operator communication network, which enables the discovery of network entities managing network slices and/or resources within the multi-operator communication network.
In a further implementation form of the first aspect, the discovery entity is associated with the sub-network control entity of one of the sub-networks of the plurality of sub-networks and configured to peer with respective further discovery entities associated with the subnetwork control entities of the other sub-networks of the plurality of sub-networks for retrieving information about the one or more network slices of each sub-network and/or information about the respective sub-network control entity of each of the other subnetworks from the respective sub-network control entity. In a further implementation form of the second aspect, the method comprises the further step of providing updated information about the one or more network slices of the subnetwork of the sub-network control unit and/or information about the respective subnetwork control entity to the discovery entity.
In a further implementation form of the second aspect, the method comprises the further steps, in response to a request of a sub-network administration unit, checking the validity of the request and, if valid, registering the corresponding sub-network control entity with the discovery entity for allowing the sub-network control entity to request and retrieve information about the one or more network slices of each of the other sub-networks and/or information about the respective sub-network control entity of each of the other subnetworks from the discovery entity and/or to provide updated information about the one or more network slices of the sub-network and/or information about the respective subnetwork control entity to the discovery entity.
In a further implementation form of the second aspect, the discovery entity comprises a plurality of distributed network entities of the multi-operator communication network and wherein the plurality of distributed network entities of the multi-operator communication network comprise a root discovery entity and a plurality of sub-level discovery entities, wherein the root discovery entity comprises address information for each of the plurality of sub-level discovery entities and wherein the method comprises the further step of retrieving information about the one or more network slices of each sub-network and/or information about the respective sub-network control entity of each of the other subnetworks from the respective sub-network control entity for a respective subset of the plurality of sub-networks.
In a further implementation form of the second aspect, the method comprises the further steps of requesting and retrieving information from a respective sub-level discovery entity about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub-networks and/or information about the respective subnetwork control entity of each of the other sub-networks of the respective subset of the plurality of sub-networks by the respective sub-network control entity.
In a further implementation form of the second aspect, the method comprises the further step of providing updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity from the respective sub-network control entity to the respective sub-level discovery entity.
In a further implementation form of the second aspect, the method comprises the further step of registering a sub-network administration unit with a registration unit, for registering the respective sub-network control entity with a respective sub-level discovery entity for allowing the respective sub-network control entity to request and retrieve information from the respective sub-level discovery entity about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub-networks and/or information about the respective sub-network control entity of each of the other subnetworks and/or to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity to the respective sub-level discovery entity. The invention can be implemented in hardware and/or software.
BRIEF DESCRIPTION OF THE DRAWINGS
Further embodiments of the invention will be described with respect to the following figures, wherein:
Fig. 1 shows a schematic diagram of a multi-operator communication network comprising a network management system according to an embodiment based on a centralized architecture;
Fig. 2 shows a schematic diagram of a multi-operator communication network comprising a network management system according to an embodiment based on a P2P architecture; Fig. 3 shows a schematic diagram of a multi-operator communication network comprising a network management system according to an embodiment based on a distributed architecture;
Fig. 4a shows a diagram illustrating a registration procedure within a network management system according to an embodiment based on a centralized architecture; Fig. 4b shows a diagram illustrating a discovery procedure within a network management system according to an embodiment based on a centralized architecture;
Fig. 4c shows a diagram illustrating an update procedure within a network management system according to an embodiment based on a centralized architecture;
Fig. 5a shows a diagram illustrating a registration procedure within a network management system according to an embodiment based on a distributed architecture; Fig. 5b shows a diagram illustrating a discovery procedure within a network management system according to an embodiment based on a distributed architecture;
Fig.6a shows a diagram illustrating a discovery procedure within a network management system according to an embodiment based on a distributed architecture;
Fig. 6b shows a diagram illustrating an update procedure within a network management system according to an embodiment based on a distributed architecture;
Fig. 7 shows a schematic diagram of a multi-operator communication network comprising a network management system according to an embodiment based on a centralized architecture;
Fig. 8 shows a schematic diagram of a multi-operator communication network comprising a network management system according to an embodiment based on a centralized architecture; and
Fig. 9 shows a schematic diagram illustrating a method for managing a multi-operator communication network according to an embodiment. In the various figures, identical reference signs will be used for identical or at least functionally equivalent features.
DETAILED DESCRIPTION OF THE EMBODIMENTS
In the following description, reference is made to the accompanying drawings, which form part of the disclosure, and in which are shown, by way of illustration, specific aspects in which the present invention may be placed. It will be appreciated that other aspects may be utilized and structural or logical changes may be made without departing from the scope of the present invention. The following detailed description, therefore, is not to be taken in a limiting sense, as the scope of the present invention is defined by the appended claims.
For instance, it will be appreciated that a disclosure in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa. For example, if a specific method step is described, a corresponding device may include a unit to perform the described method step, even if such unit is not explicitly described or illustrated in the figures.
Moreover, in the following detailed description as well as in the claims embodiments with different functional blocks or processing units are described, which are connected with each other or exchange signals. It will be appreciated that the present invention covers embodiments as well, which include additional functional blocks or processing units that are arranged between the functional blocks or processing units of the embodiments described below. Finally, it is understood that the features of the various exemplary aspects described herein may be combined with each other, unless specifically noted otherwise.
As will be described in more detail in the following, embodiments of the invention relate to network management systems comprising network entities in the form of an OSS Discovery Service (ODS) entity, an OSS registrar, and an OSS manager in a 5G multi- domain reference model that depicts a possible 5G ecosystem allowing multi-operator service management. As already mentioned above, the network management systems according to embodiments of the present invention are based on different architectures: namely centralised, distributed, P2P, and/or multi-layer. A multi-operator architecture comprising an Operations Support System (OSS) and a subnet/infrastructure manager is assumed in embodiments of the invention, wherein the OSS orchestrates resources across multiple domains and the subnet/infrastructure manager manages resources in a local domain. As network services can be provided by multiple operators, different operators may be interested in building connections and maintaining sessions with one another. In addition, a single operator can have multiple OSSs which shall communicate to offer chained services and slicing functionalities. Generally, embodiments of the invention relate to a network management system for a multi-operator communication network, wherein the multi-operator communication network comprises a plurality of sub-networks operated by different network operators, each subnetwork comprising a sub-network control entity configured to control one or more network slices of the respective sub-network, wherein the network management system comprises a discovery entity configured to retrieve information about the one or more network slices of each sub-network of the plurality of sub-networks and/or information about the respective sub-network control entity from the respective sub-network control entity. Figure 1 shows a schematic diagram of a multi-operator communication network 100 comprising a network management system according to an embodiment based on a centralized architecture. In the embodiment shown in figure 1 the multi-operator communication network 100, by way of example, comprises three sub-networks operated by different network operators, namely by the operators A, B and C. Each sub-network comprises one or more sub-network control entities in the form of a OSS entity 1 10a-e configured to control one or more network slices and/or network resources of the respective sub-network. In an embodiment, the respective OSS entities 1 10a-e configured to control one or more network slices and/or network resources of the respective subnetwork can be one or more multi-domain orchestrators. By way of example, in the embodiment shown in figure 1 , the sub-network operated by the operator A comprises the OSS entities 1 10a and 110b, the sub-network operated by the operator B comprises the OSS entities 1 10c and 1 10d and the sub-network operated by the operator C comprises the OSS entity 1 1 Oe. As will be described in more detail further below, in the embodiment shown in figure 1 , the network management system comprises a discovery entity in the form of an ODS entity 120 configured to retrieve information about the one or more network slices of each subnetwork of the plurality of sub-networks and/or information about the respective OSS entities 1 10a-e from the respective OSS entities 1 10a-e. In an embodiment, each respective OSS entity 1 10a-e associated with a given sub-network is configured to request and retrieve information about the one or more network slices of each of the other sub-networks and/or information about the respective OSS entities 1 10a-e of the other sub-networks from the centralized discovery entity (i.e. ODS entity) 120. In an embodiment, each OSS entity 1 10a-e is further configured to provide updated information about the one or more network slices of the respective sub-network and/or information about t e respective OSS entity 1 10a-e to the centralized discovery entity (i.e. ODS entity) 120.
In an embodiment, the network management system further comprises a plurality of sub- network administration units (herein also referred to as OSS managers or local managers) 130a-c. In the embodiment shown in figure 1 , each sub-network administration unit (i.e. OSS manager) 130a-c is implemented in one of the plurality of sub-networks.
In an embodiment, the network management system further comprises a registration unit in the form of a OSS registrar 140, wherein upon request of one of the plurality of subnetwork administration units (i.e. OSS managers) 130a-c the registration unit 140 is configured to check the validity of the request and, if valid, to register the corresponding sub-network control entity (i.e. OSS entity) 1 10a-e with the discovery entity (i.e. ODS entity) 120 for allowing the respective sub-network control entity (i.e. OSS entity) 131 a-e to request and retrieve information about the one or more network slices of each of the other sub-networks and/or information about the respective OSS entities 1 10a-e of the other sub-networks from the discovery entity (i.e. ODS entity) 120 and/or to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective OSS entities 1 10a-e to the discovery entity (i.e. ODS entity) 120.
In an embodiment, one of the OSS managers 130a-c can be responsible for starting the registration process with the OSS registrar 140, and the OSS registrar 140 can be responsible for registering new OSSs 1 10a-c and verifying their legitimacy. The OSS registrar 140 can also provide access information to register, discover, and update the OSS information, in addition to basic information handled by a Domain Name System (DNS), e.g. IP. Furthermore, the ODS entity 120 can handle new information types such offered slice/services and geo location. In an embodiment, the ODS entity 120 itself can comprise a database for storing all information of the OSS 1 10a-e and maintain a session or/and a connection to all OSSs 1 10a-e in the system. The information that the ODS 120 can maintain comprises the following: operator_name (official name of the operator); access_keys (used for registration); IP_adresses (IPv4 or IPv6, used to connect to the OSS); port (used for the connection); oss_version (version of a software running on the OSS); geojocation (geographical location where the OSS is deployed); network_tier (a network tier of the operator indicating t e operator size); service_type (a list of offered services to be used during the OSS discovery, e.g. besteffort, Germany, loT, etc).
Thus, in the centralized ODS embodiments, all OSSs 1 10a-e can register at the OSS registrar 140 and then open connects to the ODS entity 120. New OSSs register through the OSS registrar 140 as well. In an embodiment, the ODS entity 120 has a database that stores the registered OSSs and their information. In an embodiment, all OSSs 1 10a-e register and maintain sessions at the ODS entity 120. OSS discovery can be done using a query at the ODS entity 120. Before describing the above mentioned operations and procedures, in particular registration and discovery, of the different components of the network management system in more detail, further embodiments of the network management system based on different architectures will be described.
Figure 2 shows a schematic diagram of a multi-operator communication network 100 comprising a network management system according to an embodiment based on a P2P architecture. In the P2P embodiment shown in figure 2 the multi-operator communication network 100, by way of example, comprises four sub-networks operated by different network operators, wherein each sub-network comprises a sub-network control entity in the form of an OSS entity 1 10a-d configured to control one or more network slices and/or network resources of the respective sub-network. In an embodiment, the respective OSS entity 1 10a-d is configured to control one or more network slices and/or network resources of the respective sub-network can be a multi-domain orchestrator. In the embodiment shown in figure 2, the discovery entity that is configured to retrieve information about the one or more network slices of each sub-network of the plurality of sub-networks and/or information about the respective OSS entities 1 10a-d of the other sub-networks from the respective OSS entities 1 10a-d is provided in the form of a respective discovery agent 1 1 1 a-d. A respective discovery agent, for instance the discovery agent 1 1 1 a, is configured to peer with OSS discovery agents 11 1 b-d of the other sub-networks of the plurality of sub-networks for retrieving information about the one or more network slices of each sub- network and/or information about the respective OSS entities 1 10a-d of the other subnetworks. In the embodiment shown in figure 2, the respective discovery agents 1 1 1 a-d are separate from the respective OSS entities 1 10a-d. In another embodiment, the respective discovery agents 1 1 1 a-d can be implemented as a part of the respective OSS entities 1 10a-d. In another embodiment, the respective discovery entity can be provided by the respective OSS entity 1 10a-d itself. Thus, P2P ODS embodiments according to the invention provide an architecture in which each OSS entity 1 10a-d will peer with neighbouring agents. The respective local OSS discovery agent 1 1 1 a-d is responsible for opening and managing sessions to neighbouring OSSs 1 10a-d. IPs of remote OSSs can be configured manually. Keep alive messages can be sent regularly. Service discovery can be done using a query at the peering discovery agent 1 1 1 a-d.
Figure 3 shows a schematic diagram of a multi-operator communication network comprising a network management system 100 according to an embodiment based on a distributed architecture. In the embodiment shown in figure 3 the multi-operator communication network 100, by way of example, comprises three sub-networks operated by different network operators, namely by the operators A, B and C. Each sub-network comprises one or more sub-network control entities in the form of an OSS entity 1 10a-e configured to control one or more network slices and/or network resources of the respective sub-network. In an embodiment, the respective OSS entities 1 10a-e configured to control one or more network slices and/or network resources of the respective subnetwork can be a multi-domain orchestrator. By way of example, in the embodiment shown in figure 3, the sub-network operated by the operator A comprises the OSS entities 1 10a and 1 10b, the sub-network operated by the operator B comprises the OSS entities 1 10c and 1 10d and the sub-network operated by the operator C comprises the OSS entity 1 10e.
In the embodiment shown in figure 3, the discovery entity comprises a root discovery entity (herein also referred to as root ODS entity) 120a and, by way of example, two sub- level discovery entities (herein also referred to as sub-level ODS entities) 120b. In an embodiment, the root ODS entity 120a comprises address information for each of the two sub-level ODS entities 120b and each of the two sub-level ODS entities 120b is configured to retrieve information about the one or more network slices of each subnetwork and/or information about the respective OSS entities 1 10a-e from the respective OSS entities 1 10a-e for a respective subset of the plurality of sub-networks. For instance, in the embodiment shown in figure 3, a first sub-level ODS entity 120b is configured to retrieve information about the one or more network slices of the sub-network controlled by the OSS entities 1 10a, 1 10b and a second sub-level ODS entity 120b is configured to retrieve information about the one or more network slices of the respective sub-networks controlled by the OSS entities 1 10c, 1 10d and 1 10e. In t e distributed architecture shown in figure 3, the respective OSS entities 1 10a-e located in one of the plurality of sub-networks are configured to request and retrieve information from the respective sub-level ODS entity 120b about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub- networks and/or information about the respective OSS entities 1 10a-e of each of the other sub-networks of the respective subset of the plurality of sub-networks. For instance, the OSS entities 1 10c and/or 1 10d implemented in the sub-network of the operator B can retrieve information from the sub-level ODS entity 120b about the one or more network slices of the sub-network of the operator C and/or the OSS entity 1 10e thereof. In an embodiment, each OSS entity 1 10a-e can be further configured to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective OSS entity 1 10a-e to the respective sub-level ODS entity 120b, as illustrated by the arrows in figure 3. In the embodiment shown in figure 3, the registration unit in the form of the OSS registrar 140 is configured such that each of the plurality of local OSS managers 130a-c has to register the corresponding OSS entities 1 10a-e with the OSS registrar 140 before the corresponding OSS entities 1 10a-e are allowed to request and retrieve information from a respective sub-level ODS entity 120b about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub-networks and/or information about the respective OSS entities 1 10a-e of the other sub-networks and/or to provide updated information about the one or more network slices of the respective subnetwork and/or information about the respective OSS entities 1 10a-e to the respective sub-level ODS entity 120b.
Thus, in the distributed ODS embodiments, two types of additional entities are involved, namely the Root ODS entity 120a and the plurality of sub-level ODS entities 120b. The Root ODS 120a is located at the top level and knows the entry points to all SL-ODS 120b, reachable via Any-cast. A respective sub level ODS 120b can be a geo-local discovery service, aware about OSSs 1 10a-e in a certain geographical and/or administrative location. New OSSs can register through the OSS registrar 140. OSSs 1 10a-e use the root ODS 120a to get the SLODS 120b responsible for them. Each SLODS 120b can have a database that stores the registered OSSs 1 10a-e and their information in their geographical and/or administrative location. All OSSs 110a-e register and maintain sessions at the assigned SLODS 120b. OSS discovery is done using a query at the SLODS 120b covering their geographical location. In case the SLODS 120b is asked for a service in another geographical location, it asks the SLODS 120b of other locations, as will be described in more detail further below.
A multi-layer ODS can be provided by expanding the layers of the ODS shown in figure 3 and adding more layers in order to allow for scaling. In the embodiment shown in figure 3, two layers of ODSs are present between the root ODS 120a and the SL-ODS 120b. These can be expanded, for instance, to a total of 4 layers. The benefit of such a design is flexibility and scalability. Flexibility is achieved via defining an adequate number of layers as required. Scalability is achieved as the load on the specific SL-ODS 120b is reduced due to distributed load balancing. The multi-layer architecture is very similar to the distributed one with the exception that there can be multiple layers existing between the root ODS entity 120a and the SL-ODS 120b. Each layer can contain the so called intermediary ODSs. An intermediary ODS is responsible for all ODSs in the lower layers and reports to its parent ODS just like in a tree structure. As with the distributed architecture, each SL-ODS entity can be responsible for a specific geo-location (e.g. Germany). An intermediary ODS in a specific layer is responsible to link the SL-ODS in the lower layer to the upper layers and to the SL-ODS of the neighboring geo-locations.
Figures 4a, 4b and 4c show respective diagrams illustrating a registration procedure, a discovery procedure and an update procedure within a network management system according to an embodiment based on a centralized architecture, such as the network management system shown in figure 1 .
The request procedure shown in figure 4a comprises the following main steps: the OSS manager 130a sends a request to the OSS registrar 140, which checks the validity thereof; if valid, the OSS registrar 140 provides the OSS manager 130a with access credentials, such as access keys and addresses; the OSS manager 130a provides the access credentials to the associated OSS entity 1 10a, which uses these access credentials for registering with the ODS entity 120.
The discovery procedure shown in figure 4b comprises the following main steps: the OSS entity 1 10a sends a request for network services to the ODS 120, including, for instance, information about the type of network services required; on the basis of this information the ODS 120 queries its database of registered OSS entities, including the OSS entity 1 10b and the OSS entity 1 10c, and returns the results to the OSS entity 1 10a; in response the OSS entity requests connection to the OSS entity 1 10b and the OSS entity 1 10c, respectively.
The update procedure shown in figure 4c comprises the following main steps: the OSS entity 1 10a, which is already registered, sends a change/update request to the ODS entity 120; if accepted by the ODS entity 120, the OSS entity 1 10a provides the updated information to the ODS entity 120.
Figures 5a and 5b show respective diagrams illustrating a registration procedure and a discovery procedure within a network management system according to an embodiment based on a distributed architecture, such as the network management system shown in figure 3.
The request procedure shown in figure 5a comprises the following main steps: the OSS manager 130a sends a request to the OSS registrar 140, which checks the validity thereof; if valid, the OSS registrar 140 provides the OSS manager 130a with access credentials, such as access keys and addresses; the OSS manager 130a provides the access credentials to the associated OSS entity 1 10a; the OSS entity 1 10a requests from the root ODS entity 120a the IP address of the sub-level ODS entity 120b to be assigned to the OSS entity 1 10a (for instance, based on the geographical location of the OSS entity 1 10a); the root ODS entity 120a returns the IP address of the sub-level ODS entity 120b closest to the OSS entity 1 10a; the OSS entity 1 10a uses the access credentials for registering with the sub-level ODS entity 120a, to which is has been assigned by the root ODS entity 120a.
The discovery procedure shown in figure 5b comprises the following main steps: the OSS entity 1 10a sends a request for network services to the sub-level ODS entity 120b the OSS entity 1 10a is assigned to, including, for instance, information about the type of network services required; on the basis of this information the sub-level ODS entity 120b queries its database of registered OSS entities, including the OSS entity 1 10b and the OSS entity 1 10c, and returns the results to the OSS entity 1 10a; in response the OSS entity requests connection to the OSS entity 1 10b and the OSS entity 1 10c, respectively.
Figure 6a shows a diagram illustrating the corresponding discovery procedure within a network management system according to an embodiment based on a distributed architecture, such as the network management system shown in figure 3, for a case where the requested network services cannot be provided by another OSS entity assigned to the sub-level ODS entity 120b, to which the service requesting OSS entity 1 10a is assigned to. The discovery procedure shown in figure 6a comprises the following main steps: the OSS entity 1 10a sends a request for network services to a first sub-level ODS entity 120b the OSS entity 1 10a is assigned to, including, for instance, information about the type of network services required; if the requested network services cannot be provided by one of the OSS entities assigned to the first sub-level ODS entity 120b, the first sub-level ODS entity 120b will send a corresponding request to the root ODS entity 120a, which will return the IP address of a second sub-level ODS entity 120b that can provide the network services requested by the OSS entity 1 10a; in response thereto, the first sub-level ODS entity 120b forwards the original request to the second sub-level ODS entity 120b; on the basis of the information included in the request the second sub-level ODS entity 120b queries its database of registered (i.e. assigned) OSS entities, including the OSS entity 1 10b and the OSS entity 1 10c, and returns the results to the first sub-level ODS entity 120b, which, in turn, forwards these results to the service requesting OSS entity 1 10a.
Figure 6b shows a diagram illustrating an update procedure within a network management system according to an embodiment based on a distributed architecture, such as the network management system shown in figure 3. The update procedure shown in figure 6b comprises the following main steps: the OSS entity 1 10a, which is already registered and assigned to the sub-level ODS entity 120b, sends a change/update request to the sub- level ODS entity 120b; if accepted by the sub-level ODS entity 120b, the OSS entity 1 10a provides the updated information to the sub-level ODS entity 120b.
For the multi-layer embodiments the registration, discovery and update procedures are very similar to the ones of for the distributed embodiments described above. The registration procedure in the multi-layer embodiments follows a similar procedure with the exception that the assignment of the SL ODS is done by querying the intermediary ODSs until the SL-ODS responsible for the request geo-location is reached. The discovery procedure in the multi-layer embodiments follows a similar procedure with the exception that in case the SLODS cannot answer a query itself, it forwards the query one layer up to its parent, i.e. an intermediary ODS. This is done recursively until the root ODS entity is reached. At the point the responsible SLODS details are send back to the querying OSS entity. The update follows the exact same procedure as for the distributed architecture. Figure 7 shows a schematic diagram of the multi-operator communication network 100 comprising different embodiments of the network management system based on a centralized architecture within a 3GPP environment. Based on the current 3GPPP architecture for network slice management [3GPP TR 28.801 V1 .1 .0 (2017-03)] there are two important functions, which can be incorporated into embodiments of the invention, namely the NSMF (Network Slice Management Function) and the NSSMF (Network Slice Subnet Management Function). In the embodiment shown in figure 7, the NSMF has the role of the OSS 1 10a and the NSSMF has the role of a Subnet/Infrastructure Manager. The OSS Manager 130a will be used to trigger registration of the NSMF 1 10a at the OSS Registrar 140. Thereby, the NSMF 1 10a can connect to the ODS 120 to perform the discovery and update procedures described above.
Figure 8 shows a schematic diagram of the multi-operator communication network 100 comprising different embodiments of the network management system based on a centralized architecture within a general Cloud/IT environment. In this embodiment, a general multi-domain orchestrator (acting as an OSS 1 10a) is provided and the subnet/infrastructure manager that manages the local resources. Also in this case the multi-domain orchestrator 1 10a will make use of the OSS Manager 130a, the OSS Registrar 140, and the ODS entity 120 to manage, register, discover/update in order to realize connectivity across different multi-domain orchestrators 1 10a,b. Such an embodiment can be used by cloud providers, storage providers, computing providers, and SaaS and PaaS providers.
Similar to the embodiments shown in figures 7 and 8, a further embodiment of the network management system can be based on a centralized architecture within an ETSI environment. Based on the current ETSI architecture for network slice management [ETSI GR NFV I FA 028 VO.5.0 (2017-04)] there are two important functions that can be incorporated with embodiments of the invention, namely the NFVO (Network Function Virtualization Orchestrator) and the VIM (Virtualized Infrastructure Manager). The NFVO has the role of the OSS entity and the VIM has the role of a Subnet/Infrastructure Manager. The OSS Manager will be used to trigger registration of the NFVO at the OSS Registrar. Thereby, the NFVO can connect to the ODS entity to perform the discovery and update procedures described above.
Figure 9 shows a schematic diagram illustrating a corresponding method 900 for managing the multi-operator communication network 100 described above, wherein the multi-operator communication network 100 comprises a plurality of sub-networks operated by different network operators, each sub-network comprising a sub-network control entity configured to control one or more network slices of the sub-network. The method 900 comprises the step 901 of retrieving by a discovery entity information about the one or more network slices of each sub-network of the plurality of sub-networks and/or information about the respective sub-network control entity from the respective subnetwork control entity. The method 900 can be performed by different embodiments of the network management system described above. Thus, further embodiments of the method 900 result directly from the functionality of the network management system described above and its different embodiments.
While a particular feature or aspect of the disclosure may have been disclosed with respect to only one of several implementations or embodiments, such feature or aspect may be combined with one or more other features or aspects of the other implementations or embodiments as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms "include", "have", "with", or other variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprise". Also, the terms "exemplary", "for example" and "e.g." are merely meant as an example, rather than the best or optimal. The terms "coupled" and "connected", along with derivatives may have been used. It should be understood that these terms may have been used to indicate that two elements cooperate or interact with each other regardless whether they are in direct physical or electrical contact, or they are not in direct contact with each other. Although specific aspects have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations may be substituted for the specific aspects shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the specific aspects discussed herein.
Although the elements in the following claims are recited in a particular sequence with corresponding labelling, unless the claim recitations otherwise imply a particular sequence for implementing some or all of those elements, those elements are not necessarily intended to be limited to being implemented in that particular sequence. Many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the above teachings. Of course, those skilled in the art readily recognize that there are numerous applications of the invention beyond those described herein. While the present invention has been described with reference to one or more particular embodiments, those skilled in the art recognize that many changes may be made thereto without departing from the scope of the present invention. It is therefore to be understood that within the scope of the appended claims and their equivalents, the invention may be practiced otherwise than as specifically described herein.

Claims

1 . A network management system for a multi-operator communication network (100), wherein the multi-operator communication network (100) comprises a plurality of sub- networks operated by different network operators, each sub-network comprising a subnetwork control entity (1 10a-e) configured to control one or more network slices of the respective sub-network, wherein the network management system comprises a discovery entity (120; 120a,b; 1 1 1 a-d) configured to retrieve information about the one or more network slices of each sub-network of the plurality of sub-networks from the respective sub-network control entity (1 10a-e) and/or information about the respective sub-network control entity (1 10a-e).
2. The system of claim 1 , wherein the discovery entity (1 1 1 a) is associated with the sub-network control entity (1 10a) of one of the sub-networks of the plurality of sub- networks and configured to peer with respective further discovery entities associated with the sub-network control entities (1 10b-e) of the other sub-networks of the plurality of subnetworks for retrieving information about the one or more network slices of each subnetwork and/or information about the respective sub-network control entity (1 10b-e) from the respective sub-network control entity (1 10b-e).
3. The system of claim 1 , wherein the discovery entity (120; 120a,b; 1 1 1 a-d) is a centralized network entity (120) of the multi-operator communication network (100) and wherein each sub-network control entity (1 10a-e) is configured to request and retrieve information about the one or more network slices of each of the other sub-networks and/or information about the respective sub-network control entity (1 10a-e) of each of the other sub-networks from the discovery entity (120).
4. The system of claim 3, wherein each sub-network control entity (1 10a-e) is further configured to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity (1 10a-e) to the discovery entity (120).
5. The system of claim 3 or 4, wherein the system further comprises a registration unit (140) and a plurality of sub-network administration units (130a-c), wherein each sub- network administration unit (130a-c) is implemented in one of the plurality of subnetworks, wherein upon request of one of the plurality of sub-network administration units (130a-c) t e registration unit (140) is configured to check the validity of the request and, if valid, to register the corresponding sub-network control entity (1 10a-e) with the discovery entity (120) for allowing the respective sub-network control entity (1 10a-e) to request and retrieve information about the one or more network slices of each of the other sub- networks and/or information about the respective sub-network control entity (1 10a-e) of the other sub-networks from the discovery entity (120) and/or to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity (1 10a-e) to the discovery entity (120).
6. The system of claim 1 , wherein the discovery entity (120; 120a,b; 1 1 1 a-d) comprises a plurality of distributed network entities (120a,b) of the multi-operator communication network (100) and wherein the plurality of distributed network entities (120a,b) of the multi-operator communication network (100) comprise a root discovery entity (120a) and a plurality of sub-level discovery entities (120b), wherein the root discovery entity (120a) comprises address information for each of the plurality of sub-level discovery entities (120b) and wherein each of the plurality of sub-level discovery entities (120b) is configured to retrieve information about the one or more network slices of each sub-network from the respective sub-network control entity (1 10a-e) for a respective subset of the plurality of sub-networks and/or information about the respective subnetwork control entity (1 10a-e).
7. The system of claim 6, wherein each respective sub-network control entity (1 10a- e) is configured to request and retrieve information from a respective sub-level discovery entity (120b) about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub-networks and/or information about the respective sub-network control entity (1 10a-e) of each of the other sub-networks of the respective subset of the plurality of sub-networks.
8. The system of claim 7, wherein each sub-network control entity (1 10a-e) is further configured to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity (1 10a-e) to the respective sub-level discovery entity (120b).
9. The system of claim 7 or 8, wherein the system further comprises a registration unit (140) and a plurality of sub-network administration units (130a-c), wherein each sub- network administration unit (130a-c) is implemented in one of the plurality of subnetworks, wherein each of the plurality of sub-network administration units (130a-c) has to register with the registration unit (140) for registering the respective sub-network control entity (1 10a-e) with a respective sub-level discovery entity (120b) before being allowed to request and retrieve information from a respective sub-level discovery entity (120b) about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub-networks and/or information about the respective sub-network control entity (1 10a-e) of the other sub-networks and/or to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity (1 10a-e) to the respective sub-level discovery entity (120b).
10. The system of any one of the preceding claims, wherein the discovery entity (120; 120a,b; 1 1 1 a-d) comprises a memory configured to store the information about the one or more network slices of each sub-network of the plurality of sub-networks and/or the information about the respective sub-network control entity (1 10a-e) retrieved from the respective sub-network control entity (1 10a-e).
1 1 . The system of claim 10, wherein the information about the one or more network slices of each sub-network and/or the information about the respective sub-network control entity (1 10a-e) retrieved from the respective sub-network control entity (1 10a-e) comprises an identifier of the operator of the respective sub-network control entity (1 10a- e), security credentials of the respective sub-network control entity (1 10a-e), an IP address of the respective sub-network control entity (1 1 0a-e), a port number of the respective sub-network control entity (1 10a-e), information about the version of a software running on the respective sub-network control entity (1 10a-e), a geographical location of the respective sub-network control entity (1 10a-e), a network tier of the operator of the respective sub-network control entity (1 10a-e) and/or service types offered by the respective sub-network control entity (1 10a-e).
12. The system of any one of the preceding claims, wherein the sub-network control entity (1 10a-e) of each sub-network is a multi-domain orchestrator.
13. A method (900) for managing a multi-operator communication network (100), wherein the multi-operator communication network (100) comprises a plurality of subnetworks operated by different network operators, each sub-network comprising a sub- network control entity (100a-e) configured to control one or more network slices of t e sub-network, wherein the method (900) comprises the step of retrieving (901 ) by a discovery entity (120; 120a,b; 1 1 1 a-d) information about the one or more network slices of each sub-network of the plurality of sub-networks and/or information about the respective sub-network control entity (1 10a-e) from the respective sub-network control entity (100a- e).
14. The method (900) of claim 13, wherein the discovery entity (120; 120a,b; 1 1 1 a-e) is a centralized network entity (120) of the multi-operator communication network (100) and wherein the method (900) comprises the further steps of requesting and retrieving information about the one or more network slices of each of the other sub-networks and/or information about the respective sub-network control entity (1 10a-e) of the other subnetworks from the discovery entity (120) by the respective sub-network control entity (100a-e).
15. The method (900) of claim 14, wherein the method (900) comprises the further step of providing updated information about the one or more network slices of the subnetwork of the respective sub-network control entity (1 10a-e) and/or information about the respective sub-network control entity (1 10a-e) to the discovery entity (120).
16. The method (900) of claim 14 or 15, wherein the method (900) comprises the further steps, in response to a request of a sub-network administration unit (130a-c), of checking the validity of the request and, if valid, registering the corresponding sub-network control entity (1 10a-e) with the discovery entity (120) for allowing the corresponding sub- network control entity (1 10a-e) to request and retrieve information about the one or more network slices of each of the other sub-networks and/or information about the respective sub-network control entity (1 10a-e) of each of the other sub-networks from the discovery entity (120) and/or to provide updated information about the one or more network slices of the sub-network and/or information about the respective sub-network control entity (1 10a- e) to the discovery entity (120).
17. The method (900) of claim 13, wherein the discovery entity (120; 120a,b; 1 1 1 a-d) comprises a plurality of distributed network entities (120a,b) of the multi-operator communication network (100) and wherein the plurality of distributed network entities (120a,b) of the multi-operator communication network (100) comprise a root discovery entity (120a) and a plurality of sub-level discovery entities (120b), wherein the root discovery entity (120a) comprises address information for each of the plurality of sub-level discovery entities (120b) and wherein the method (900) comprises the further step of retrieving information about the one or more network slices of each sub-network and/or information about the respective sub-network control entity (1 10a-e) of each of the other sub-networks from the respective sub-network control entity (1 10a-e) for a respective subset of the plurality of sub-networks.
18. The method (900) of claim 17, wherein the method (900) comprises the further steps of requesting and retrieving information from a respective sub-level discovery entity (120b) about the one or more network slices of each of the other sub-networks of the respective subset of the plurality of sub-networks and/or information about the respective sub-network control entity (1 10a-e) of each of the other sub-networks of the respective subset of the plurality of sub-networks by the respective sub-network control entity (100a- e).
19. The method (900) of claim 18, wherein the method (900) comprises the further step of providing updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity (1 10a-e) from the respective sub-network control entity (100a-e) to the respective sub- level discovery entity (120b).
20. The method (900) of any one of claims 13 to 19, wherein the method (900) comprises the further step of registering a sub-network administration unit (130a-c) with a registration unit (140), for registering the respective sub-network control entity (100a-e) with a respective sub-level discovery entity (120b) for allowing the respective sub-network control entity (100a-e) to request and retrieve information from the respective sub-level discovery entity (120b) about the one or more network slices of each of the other subnetworks of the respective subset of the plurality of sub-networks and/or information about the respective sub-network control entity (1 10a-e) of each of the other sub-networks of the respective subset of the plurality of sub-networks and/or to provide updated information about the one or more network slices of the respective sub-network and/or information about the respective sub-network control entity (1 10a-e) to the respective sub-level discovery entity (120b).
PCT/EP2017/070158 2017-08-09 2017-08-09 A network management system for a multi-operator communication network Ceased WO2019029797A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2017/070158 WO2019029797A1 (en) 2017-08-09 2017-08-09 A network management system for a multi-operator communication network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2017/070158 WO2019029797A1 (en) 2017-08-09 2017-08-09 A network management system for a multi-operator communication network

Publications (1)

Publication Number Publication Date
WO2019029797A1 true WO2019029797A1 (en) 2019-02-14

Family

ID=59626609

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2017/070158 Ceased WO2019029797A1 (en) 2017-08-09 2017-08-09 A network management system for a multi-operator communication network

Country Status (1)

Country Link
WO (1) WO2019029797A1 (en)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140211661A1 (en) * 2013-01-25 2014-07-31 Argela Yazilim Ve Bilisim Teknolojileri San. Ve. Tic. A.S. Automatic Discovery of Multiple Controllers in Software Defined Networks (SDNs)
WO2017119844A1 (en) * 2016-01-08 2017-07-13 Telefonaktiebolaget Lm Ericsson (Publ) Access control in a network comprising network slices

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140211661A1 (en) * 2013-01-25 2014-07-31 Argela Yazilim Ve Bilisim Teknolojileri San. Ve. Tic. A.S. Automatic Discovery of Multiple Controllers in Software Defined Networks (SDNs)
WO2017119844A1 (en) * 2016-01-08 2017-07-13 Telefonaktiebolaget Lm Ericsson (Publ) Access control in a network comprising network slices

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Study on management and orchestration of network slicing for next generation network (Release 15)", 3GPP STANDARD ; TECHNICAL REPORT ; 3GPP TR 28.801, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG5, no. V1.2.0, 14 June 2017 (2017-06-14), pages 1 - 79, XP051298434 *
DEVLIC ALISA ET AL: "NESMO: Network slicing management and orchestration framework", 2017 IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS WORKSHOPS (ICC WORKSHOPS), IEEE, 21 May 2017 (2017-05-21), pages 1202 - 1208, XP033111657, DOI: 10.1109/ICCW.2017.7962822 *

Similar Documents

Publication Publication Date Title
JP7432744B2 (en) Routing communication in telecommunications networks with multiple service communication proxies
CN111052711B (en) Method for discovering services provided by a network repository function
US20240073798A1 (en) Method and device for managing identifier of ue in edge computing service
CN110679185B (en) Network slicing service function
US11258822B2 (en) Network function service discovery method and device
EP3664370B1 (en) Network function information management method and related device
US20250193272A1 (en) Method for determining application instance, apparatus, and system
CN113132897B (en) Method, device and system for determining application instance
CN101123565B (en) P2P system and resource query method for this system
US20200162345A1 (en) Method, system and options for multi-operator service life cycle management
BR112019006086A2 (en) application friendly protocol data unit (pdu) session management systems and methods
JP2008507167A (en) System, network entity, and computer program for configuration management of dynamic host configuration protocol framework
CN112104468B (en) Management service discovery method and device
EP3000221B1 (en) Methods, systems, and computer readable media for performing enhanced service routing
CN109474936A (en) Internet of Things communication method and system applied to multiple lora gateways
US12395468B2 (en) Technique for eliminating ingress-proxy in the multi-relay approach for privacy
Levin et al. Networking architecture for seamless cloud interoperability
US10972898B2 (en) System and interface for cross administration or technology domain network functions (NFS) instantiation and configuration for roaming users
US20230299979A1 (en) Device certificate management for zero touch deployment in an enterprise network
US20040199643A1 (en) Distributed service component systems
WO2019029797A1 (en) A network management system for a multi-operator communication network
US20080117861A1 (en) Service provision and management for mobile communities
Thai et al. Towards realizing a cloud-native B5G mobile core architecture
CN115955707B (en) Device communication method, device, terminal device and storage medium
CN117956491A (en) Fronthaul control method and device

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17752100

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17752100

Country of ref document: EP

Kind code of ref document: A1