WO2021115587A1

WO2021115587A1 - Techniques for managing access rights to a shared network slice instance and network slice subnetwork instance

Info

Publication number: WO2021115587A1
Application number: PCT/EP2019/084659
Authority: WO
Inventors: Kostas KATSALIS; Mingui Zhang; Xueli AN
Original assignee: Huawei Technologies Duesseldorf GmbH
Current assignee: Huawei Technologies Duesseldorf GmbH
Priority date: 2019-12-11
Filing date: 2019-12-11
Publication date: 2021-06-17
Anticipated expiration: 2022-06-11

Abstract

The present disclosure relates to techniques for managing access rights to a shared network slice instance and network slice subnetwork instance. In particular, the disclosure relates to a network slice management entity (103) for managing access rights to a Network Slice Instance (104), NSI, wherein the network slice management entity (103) is configured to receive (1001) an access request for accessing the NSI (104) by a first user entity, receive (1002) information on the access rights of a plurality of user entities to the NSI (104), determine (1003), based on the information on the access rights of the plurality of user entities, whether a second user entity has an access right to the NSI and whether the NSI is shared among the plurality of user entities, and, in case the NSI is shared, deny (1004) the access request of the first user entity if the second user entity has an access right to the NSI.

Description

TECHNIQUES FOR MANAGING ACCESS RIGHTS TO A SHARED NETWORK SLICE INSTANCE AND NETWORK SLICE SUBNETWORK INSTANCE

TECHNICAL FIELD

The present disclosure relates to techniques for managing access rights to shared network slice instances and network slice subnetwork instances, particularly to a Network Slice Management Function (NSMF) entity and a Network Slice Subnet Management Function (NSSMF) entity according to 3GPP terminology. In particular, the disclosure relates to methods and devices for protection of shared network functions and resources under network slicing.

BACKGROUND

5G is expected to offer a communication ecosystem that enables a plethora of diverse services in a cost-effective manner, facilitating network connectivity for 3rd parties that do not own a network infrastructure. A means to achieve this comes through the concept of network slicing, which allows the deployment of multiple logical, self-contained networks, offering 3rd parties and vertical tenants customized services on the top of a shared infrastructure. Network slicing is applied end-to-end, combining the Radio Access Network (RAN), Transport Network (TN) and core network.

According to 3GPP‘s TR28.801, TR23.299 and TS23.501 standards, a Network Slice Instance (NSI) is a realization of a network slice, comprising a set of Network Slice Sub network Instance (NSSI)s in the RAN, Transport and core network parts. Each NSSI is a composition of Network Services (NSs). A NS is a composition of Network Functions (NFs) operated and deployed over Physical or Virtual Network Resources (NRs) arranged with specified connectivity between them or according to one or more forwarding graphs.

According to 3GPP work (like the TS23.501 standard), various sharing options exist between the NSIs, NSSIs, NS and the NF and NRs in order to provide the integrated communication services. For example, a NSSI may be shared by two or more NSIs, while a NF may be shared by two or more NSSI(s). Furthermore, a NSI may support zero or more communication services, while a communication service may be served by one or more NSIs, possibly with different characteristics. According to the 3GPP TR28.801 standard, the following orchestration and management functions are used to manage the NSIs and the corresponding NSSIs:

The Communication Service Management Function (CSMF) translates the communication service requirements to network slice related requirements. The CSMF interacts with the Network Slice Management Function (NSMF).

The Network Slice Management Function (NSMF) is responsible for management and orchestration of the entire NSI, while it is the entity that is deriving specific network slice subnet related requirements.

The Network Slice Subnet Management Function (NSSMF) is responsible for the management and orchestration of the NSSIs in a specific domain, i.e., the Radio Access Network NSSMF (RAN-NSSMF) which is responsible for the management of the RAN NSSIs, the Transport Network NSSMF (TN-NSSMF) which is responsible for the management of the TN NSSIs.

However, especially in 5G operational environments, under Network Slicing there is still a need to improve the dynamic resource operations in a mobile communication network.

SUMMARY

It is an objective of the disclosure to provide an efficient technique for solving the above described problems when applying network slicing.

In particular, it is an objective of the disclosure to provide a mechanism to support network slicing operations under different sharing scenarios.

An idea of the disclosure is to advance network slice orchestration and management systems in order to offer integrated network slice state consistency and to provide a mechanism to maintain and protect network slice instance state under different sharing conditions.

The concept described in this disclosure provides a new access permissions scheme for software and hardware entities that can be shared between different hosting entities in the context of Network slicing. Examples of sharable entities are NSIs, NSSIs, Functions, Services and Resources and can be extended to cover all software or hardware parts that constitute a network slice. In this disclosure, the identification mechanism necessary to identify sharable network slice entities is defined. Each entity is identified by a unique identifier. For each entity, sharing capabilities are defined. For each entity, the management entity defines access rights per owner/user.

In this disclosure, a novel information exchange between the different management entities (like NSFM and corresponding NSSMFs) is presented, e.g. as described in more detail in Figure 6.

In this disclosure, a real-time locking mechanism is presented to maintain and protect network slice instance state when sharable entities are constituting the slice. The locking mechanism supports the entire lifecycle operations of a network slice or subcomponents of it like different NSIs or/and NSSIs. For each entity that can be shared, the invention considers a mutex (binary semaphore) to implement a locking mechanism used to synchronize access to the entity. For more complicated scenarios the concepts described in this disclosure can be easily extended by exploiting concepts like advisory locks. The access permission scheme and the corresponding real-time locking mechanism also cover the case to protect nested sharing and sharing capabilities inherited by the hosting entity under sharing conditions.

In order to describe the invention in detail, the following terms, abbreviations and notations will be used:

NSI: Network Slice Instance

NSSI: Network Slice Subnetwork Instance

NS: Network Service

NF: Network Function

NR: Network Resource(s)

NSMF: Network Slice Management Function

NSSMF: Network Slice Subnet Management Function

CSMF: Communication Service Management Function

TN: Transport Network

MANO: Management and Orchestration

NGMN: Next Generation Mobile Networks According to this disclosure, in the event of a change/update during the lifecycle management of a Network Slice, a mechanism can be provided for NSI consistency protection under different NSI, NSSI, NF and resource sharing schemes.

Moreover, during NSI instantiation, sharing capabilities can be described between the different tenants that are sharing slice components like resources or functions or NSSIs.

In addition, NSIs operations can performed in different time scales and slice integrity mechanism need to guarantee safe operation in dynamic environments.

According to this disclosure, protocol or mechanisms can be provided to protect the various software components from concurrently manipulating the same information in the event or the attempt of a change.

In addition, the mobile network and the underlying transport network can be engaged into dynamic resource operations, in the light of different sharing options which are brought forward with the emerging concept of 5G network slicing.

According to a first aspect, the disclosure relates to a network slice management entity for managing access rights to a Network Slice Instance, NSI, wherein the network slice management entity is configured to: receive an access request for accessing the NSI by a first user entity; receive information on the access rights of a plurality of user entities to the NSI; determine, based on the information on the access rights of the plurality of user entities, whether a second user entity has an access right to the NSI and whether the NSI is shared among the plurality of user entities; and, in case the NSI is shared, deny the access request of the first user entity if the second user entity has an access right to the NSI.

Such a network slice management entity provides an efficient mechanism to support network slicing operations under different sharing scenarios. The network slice management entity hence provides a new mechanism for integrated network slice state consistency and a new mechanism for maintaining and protecting network slice instance state under different sharing conditions. The network slice management entity provides a new access permissions scheme for software and hardware entities that can be shared between different hosting entities in the context of Network slicing. Examples of sharable entities are NSIs, NSSIs, Functions, Services, and Resources and can be extended to cover all software or hardware parts that constitute a network slice. The first user entity and the second user entity are just examples. Of course, more than one first user entity may send an access request to the NSI and more than one second user entity may have access rights to the NSI.

Note that the Network slice management entity (e.g. NSMF) can manage the access rights for any type of NSIs and NSSIs while also the same holds for the locking mechanism described below.

In an exemplary implementation form of the network slice management entity, the management entity manages a NSI that comprises at least one of: a shared resource, a shared function, a shared service, and a shared Network Slice Subnetwork Instance,

NSSI.

This provides the technical advantage that not only resources can be shared but also functions, services and Network Slice Subnetwork Instances. The disclosed sharing mechanism can be extended to cover all software or hardware parts that constitute a network slice.

In an exemplary implementation form of the network slice management entity, the network slice management entity is further configured to prevent a concurrent access to the NSI by the first user entity and the second user entity that could lead to synchronization and operational state protection issues.

This provides the technical advantage that the NSI is protected against concurrent access of two or more user entities thereby enhancing security and integrity of the NSI.

In an exemplary implementation form of the network slice management entity, the network slice management entity is further configured to grant the access request of the first user entity for accessing the NSI upon determining that the second user entity has no access right to the NSI.

This provides the technical advantage that only one user entity at a time can access the NSI thereby increasing security of the NSI against non-authorized accesses.

In an exemplary implementation form of the network slice management entity, the network slice management entity is configured to grant the access request of the first user entity for accessing the NSI upon determining that: the first user entity has an access right to the NSI, an operation to be performed by the first user entity is not violating an operational rule, the operational rule indicating at least one allowable operation of the NSI, and there is no concurrent access to the NSI.

This provides the technical advantage that only eligible user entities are allowed to access and update the NSI.

An operational rule (also called a network policy or simply a policy), as described in this disclosure, is a specification of a rule comprising at least one condition, constraint or setting which define whether an operation is allowed to be performed. The specification may further include rules that define communication restrictions between different endpoints. In the case a policy is enabled, depending on whether the policy grants or denies access, an action can be performed.

An Example of an operational rule (or a policy) is given as follows:

• Assume user entity 1 has READ access for the operational state of resource X.

• Policy examples for user entity 1 :

{ allow communication with all entities in area 1, block communication with all entities in area 2, no firewall services are allowed to be deployed on X, etc.

}

Policy violation is further described in the description section with respect to Fig. 6.

In an exemplary implementation form of the network slice management entity, the network slice management entity is further configured to update the information on the access rights to the NSI upon granting the access request of the first user entity for accessing the NSI.

This provides the technical advantage that the information on the access right is always up-to-date showing the currently active access rights of the user entities.

In an exemplary implementation form of the network slice management entity, the network slice management entity is configured to determine whether the updating the information is violating an operational rule of the second user entity before updating the information on the access rights to the NSI, the operational rule indicating at least one allowable operation of the NSI.

This provides the technical advantage that a high degree of security can be guaranteed for the NSI accesses.

In an exemplary implementation form of the network slice management entity, the network slice management entity is configured to authenticate the first user entity before directing a request for information by the first user entity to a shared NSI database.

This provides the technical advantage that only authenticated user entities are allowed to access the NSI thereby avoiding malfunctions of the network slice.

In an exemplary implementation form of the network slice management entity, the access rights to the NSI comprise at least one of the following: creating access right, reading access right, updating access right, deleting access right, and releasing access right.

This provides the technical advantage that access rights include a plurality of different actions to be performed on the NSI, thereby increasing flexibility of the user access rights.

In the following, examples are given for these access rights:

- Creating access right includes creating a NSSI, creating a virtualized resource operating over physical infrastructure and/or a service or function which are all belonging to the NSI.

- Reading access right includes reading access to receive any relevant information regarding configuration, operational state or statistics of the NSI.

- Updating access right includes updating the configuration or/and an operational state of the NSI.

- Deleting access right includes access for deleting a subcomponent of the NSI.

- Release access right includes access for releasing a component of the NSI.

Reading access is not only to read the operational state of the NSI and who is using the NSI; reading access is to receive any relevant information for the resource (like CPU power, power consumption etc.).

In an exemplary implementation form of the network slice management entity, the network slice management entity is configured to: lock the NSI for a concurrent access by another user entity of the plurality of user entities before updating configuration information and/or an operational state of the NSI; and unlock the NSI for an access after updating the configuration information and/or the operational state of the NSI.

Such a locking mechanism, in particular real-time locking mechanism, implemented by the network slice management entity maintains and protects network slice instance state when sharable entities are constituting the slice. The access permission scheme and the corresponding real-time locking mechanism as implemented by the network slice management entity also cover the case to protect nested sharing and sharing capabilities inherited by the hosting entity under sharing conditions.

In the following, an example of configuration and operational data is given:

- Configuration data: “Interface-1 -I P-address= 10.0.0.1";

- Operational data examples: “router is up, Interfacel is up";

- Statistics: “200 packets were received by interface 1".

This is only an example, any other parameters may be used.

In an exemplary implementation form of the network slice management entity, the network slice management entity is configured to lock and unlock the NSI based on a binary semaphore.

This provides the technical advantage that the operational state of the NSI can be protected. For each entity that can be shared a mutex (binary semaphore) implements the locking mechanism used to synchronize access to the entity. For more complicated scenarios the concept of the locking mechanism can be easily extended by exploiting concepts like advisory locks.

In an exemplary implementation form of the network slice management entity, the operational state of the NSI comprises an identification of all user entities having access rights to the NSI.

This provides the technical advantage that the network operator is informed about all user entities having access rights to the NSI. In an exemplary implementation form of the network slice management entity, the NSI comprises at least one domain-specific Network Slice Subnetwork Instance, NSSI, from one of the following domains: Radio Access Network domain, Transport Network domain, and Core Network domain.

This provides the technical advantage that the sharing concepts can be applied throughout different domains.

In an exemplary implementation form of the network slice management entity, the network slice management entity is a Network Slice Management Function, NSMF, entity, and the at least one domain-specific NSSI is controlled by a domain controller and managed by a Network Slice Subnet Management Function, NSSMF, entity.

This provides the technical advantage that the sharing concepts described in this disclosure can be directly applied to the management entities of 5G networks.

In an exemplary implementation form of the network slice management entity, the network slice management entity is configured to: determine the NSSMF entity based on an identifier of the NSI; and exchange information on the access rights of the NSI via the NSSMF entity.

This provides the technical advantage that multiple NSSMF entities can be used in the sharing concept and information can be exchanged throughout the network since an efficient identification can be guaranteed.

In an exemplary implementation form of the network slice management entity, the network slice management entity is configured to provision a response to the access request to a Communication Service Management Function, CSMF, entity, wherein the response indicates a grant or denial for accessing the NSI by the first user entity.

This provides the technical advantage that the user entity that requires access to an NSI is immediately informed about a response to his access request.

According to a second aspect, the disclosure relates to a network slice subnetwork management entity for managing access rights to a Network Slice Subnetwork Instance, NSSI, wherein the network slice subnetwork management entity is configured to: receive an access request for accessing the NSSI by a first user entity; receive information on the access rights of a plurality of user entities to the NSSI; determine, based on the information on the access rights of the plurality of user entities, whether a second user entity has an access right to the NSSI and whether the NSSI is shared among the plurality of user entities; and in case the NSI is shared, deny the access request of the first user entity if the second user entity has an access right to the NSSI.

Such a network slice subnetwork management entity provides an efficient mechanism to support network slicing operations under different sharing scenarios. The network slice subnetwork management entity hence provides a new mechanism for integrated network slice state consistency and a new mechanism for maintaining and protecting network slice subnetwork instance state under different sharing conditions. The network slice subnetwork management entity provides a new access permissions scheme for software and hardware entities that can be shared between different hosting entities in the context of Network slicing.

In an exemplary implementation form of the network slice subnetwork management entity, the NSSI comprises at least one of: a shared resource, a shared function, and a shared service.

This provides the technical advantage that not only resources can be shared but also functions and services. The disclosed sharing mechanism can be extended to cover all software or hardware parts that constitute a network slice subnetwork.

In an exemplary implementation form of the network slice subnetwork management entity, the network slice subnetwork management entity is configured to provision a response to the access request to a network slice management entity, wherein the response indicates a grant or denial for accessing the NSSI by the first user entity.

The first user entity and the second user entity are just examples. Of course, more than one first user entity may access request to the NSSI and more than one second user entity may have access rights to the NSSI.

In an exemplary implementation form of the network slice subnetwork management entity, the NSSI is identified by a first NSSI identification for a network slice subnetwork management entity controlled by a first operator, and the NSSI is identified by a second NSSI identification for a network slice subnetwork management entity controlled by a second operator.

This provides the technical advantage that the sharing concept can be applied to NSSIs controlled by two and more operators.

According to a third aspect, the disclosure relates to a method for managing access rights to a Network Slice Instance, NSI, the method comprising: receiving an access request for accessing the NSI by a first user entity; receiving information on the access rights of a plurality of user entities to the NSI; determining, based on the information on the access rights of the plurality of user entities, whether a second user entity has an access right to the NSI and whether the NSI is shared among the plurality of user entities; and, in case the NSI is shared, denying the access request of the first user entity if the second user entity has an access right to the NSI.

Such a method provides an efficient mechanism to support network slicing operations under different sharing scenarios. The method provides a new mechanism for integrated network slice state consistency and a new mechanism for maintaining and protecting network slice instance state under different sharing conditions. The method provides a new access permissions scheme for software and hardware entities that can be shared between different hosting entities in the context of Network slicing. Examples of sharable entities are NSIs, NSSIs, Functions, Services, and Resources and can be extended to cover all software or hardware parts that constitute a network slice.

In an exemplary implementation form of the method, the method further comprises preventing a concurrent access to the NSI by the first user entity and the second user entity.

In an exemplary implementation form of the method, the method further comprises granting the access request of the first user entity for accessing the NSI upon determining that the second user entity has no access right to the NSI. This provides the technical advantage that only one user entity at a time can access the NSI thereby increasing security of the NSI against non-authorized accesses.

In an exemplary implementation form of the method, the method further comprises granting the access request of the first user entity for accessing the NSI upon determining that: the first user entity has an access right to the NSI, an operation to be performed by the first user entity is not violating an operational rule, the operational rule indicating at least one allowable operation of the NSI, and there is no concurrent access to the NSI.

This provides the technical advantage that only eligible user entities are allowed to access the NSI.

In an exemplary implementation form of the method, the method further comprises updating the information on the access rights to the NSI upon granting the access request of the first user entity for accessing the NSI.

In an exemplary implementation form of the method, the method further comprises determining whether the updating the information is violating an operational rule of the second user entity before updating the information on the access rights to the NSI, the operational rule indicating at least one allowable operation of the NSI.

In an exemplary implementation form of the method, the method further comprises authenticating the first user entity before directing a request for information by the first user entity to a shared NSI database.

In an exemplary implementation form of the method, the method further comprises: locking the NSI for a concurrent access by another user entity of the plurality of user entities before updating configuration information and/or an operational state of the NSI; and unlocking the NSI for an access after updating the configuration information and/or the operational state of the NSI.

Such a real-time locking mechanism implemented by the network slice management entity maintains and protects network slice instance state when sharable entities are constituting the slice. The locking mechanism supports the entire lifecycle operations of a network slice or subcomponents of it like different NSIs or/and NSSIs. The access permission scheme and the corresponding real-time locking mechanism as implemented by the network slice management entity also cover the case to protect nested sharing and sharing capabilities inherited by the hosting entity under sharing conditions.

BRIEF DESCRIPTION OF THE DRAWINGS

Further embodiments of the invention will be described with respect to the following figures, in which:

Fig. 1 shows a schematic diagram of a network slice management entity 103 and a network slice subnetwork management entity 112, 132, 152 according to the disclosure within a network slicing orchestration and management architecture 100 according to 3GPP;

Fig. 2 shows a schematic diagram illustrating different sharing options 200 according to the disclosure;

Fig. 3 shows a schematic diagram illustrating the concept of nested sharing objects 300 according to the disclosure;

Fig. 4 shows a schematic diagram illustrating an example of slice and sharing aware repositories 400 according to the disclosure;

Fig. 5 shows a schematic diagram illustrating an exemplary workflow 500 for policy checking and locking mechanism according to the disclosure;

Fig. 6 shows an exemplary sequence diagram 600 illustrating sharing under different stages of lifecycle management according to the disclosure; Fig. 7 shows a schematic diagram illustrating an exemplary implementation of a single operator case 700 according to a first embodiment;

Fig. 8 shows a schematic diagram illustrating an exemplary implementation of a multi operator case 800 according to a second embodiment;

Fig. 9 shows a schematic diagram illustrating an exemplary program code 900 (in json format) for a technology agnostic request for a transport NSSI according to a third embodiment; and

Fig. 10 shows a schematic diagram of a method 1000 for managing access rights to a NSI according to the disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

In the following detailed description, reference is made to the accompanying drawings, which form a part thereof, and in which is shown by way of illustration specific aspects in which the disclosure may be practiced. It is understood that other aspects may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

It is understood that comments made 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. Further, it is understood that the features of the various exemplary aspects described herein may be combined with each other, unless specifically noted otherwise.

The described devices may include integrated circuits and may be manufactured according to various technologies. For example, the circuits may be designed as logic integrated circuits, analog integrated circuits, mixed signal integrated circuits, optical circuits, memory circuits and/or integrated passives. The methods and devices described herein may also be implemented in wireless communication networks based on mobile communication standards, in particular based on 5G and beyond.

The devices, methods and systems described herein may include processors. In the following description, the term “processor” describes any device that can be utilized for processing specific tasks (or blocks or steps). A processor can be a single processor or a multi-core processor or can include a set of processors or can include means for processing. A processor can process software or firmware or applications etc.

Fig. 1 shows a schematic diagram of a network slice management entity 103 and a network slice subnetwork management entity 112, 132, 152 according to the disclosure within a network slicing orchestration and management architecture 100 according to 3GPP.

According to 3GPP TR28.801, TR23.299 and TS23.501, a Network Service (NS) is a composition of Network Functions (NF) arranged as a set of functions with unspecified connectivity between them or according to one or more forwarding graphs. Furthermore, a Network Slice Instance (NSI) and Network Slice Subnetwork Instance (NSSI) are defined as follows:

- Network Slice Instance (NSI): A Network Slice Instance (NSI) is a realization of network slice. It is defined as a set of network services and functions and the resources for these network functions, which are arranged and configured, forming a complete logical network to meet certain network characteristics required by the service instance(s).

- Network Slice Subnetwork Instance (NSSI): For the mobile network, a NSI may operate over multiple network slice subnetworks. For each sub-network, a specific set of requirements is driving the creation of one or multiple NSSIs.

- Network Service (NS): Is a composition of relevant Network Functions (NFs) that are operating on top of physical or virtual Network Resources (NRs).

A set of orchestration and management functions are used to manage the NSIs and the NSSIs (see 3GPP-TR28.801). These management entities together with their relationships are depicted in Figure 1. The Communication Service Management Function (CSMF) 102 translates the communication service requirements to network slice related requirements. The CSMF 102 interacts with the NSMF 103, also referred to as network slice management entity in this disclosure.

The Network Slice Management Function (NSMF) 103 is responsible for management and orchestration of the entire NSI 104, while it is the entity that is deriving specific network slice subnet related requirements.

The Network Slice Subnet Management Function (NSSMF) 112, 132, 152, also referred to as network slice subnetwork management entity in this disclosure, is responsible for the management and orchestration of the NSSIs 111, 131, 151 in a specific domain, e.g., the RAN-NSSMF 112 is responsible for the management of the RAN NSSIs 111 of the RAN domain 110, the TN-NSSMF 132 is responsible for the management of the TN NSSIs 131 of the TN domain 150 and the CORE-NSSMF 152 is responsible for the management of the Core-NSSIs 151 of the core domain 150. As shown in Figure 1, network functions (NFs) 105, network services (NSs) 106 and network resources (NRs) 107 are associated to each NSSI 111 , 131 , 151 and to each NSI 104.

The relevant orchestration and management actions performed by NSMF 103 (and NSSMFs 112, 132, 152) are related to NSIs 104 (and NSSIs 111, 131, 151) life-cycle management, necessary resource provisioning and instantiation-configuration actions for the associated resources and NFs, monitoring actions, fault management and automated healing over the underlying environment (software and hardware).

For each domain (i.e. , RAN domain 110, TN domain 130 and Core domain 150), its NSSIs 111, 131, 151 are managed through interaction between the NSMF 103 and the corresponding NSSMF instance 112, 132, 152. The NSSIs 111, 131, 151 are integrated in the NSMF 103 in order to provide and instantiate the end-to-end NSI 104. For each domain 110, 130, 150, a domain controller 116, 133, 156 (or multiple domain controllers) is/are used to undertake and implement the necessary control plane functionalities, empowered by the corresponding NSSMF entity 112, 132, 152. The concepts described in this disclosure can be applied even if the MANO (Management and Orchestration) design paradigm, see ETSI GS NFV-MAN 001 V1.1.1 (2014-12) is applied conformably with the 3GPP design toward the creation of an integrated orchestration and management framework. Each NSSI 111, 131, 151 may implement a MANO system (in Figure 1 as an example, MANO system is implemented in RAN-NSSI 111 and CORE-NSSI 151) including the following MANO functional blocks: VNFO (Virtual Network Function Orchestrator) 113,

153, VNFM (Virtual Network Function Manager) 114, 154, VIM (Virtualized Infrastructure Manager) 115, 155.

The VNFO 113, 153 is responsible for on-boarding of new Network Service (NS), VNF-FG and VNF Packages, NS lifecycle management (including instantiation, scale-out/in, performance measurements, event correlation, termination), global resource management, validation and authorization of NFVI resource requests and policy management for NS instances.

The VNFM 114, 154 is responsible for lifecycle management of VNF instances, overall coordination and adaptation role for configuration and event, reporting between NFVI and the E/NMS.

The VIM 115, 155 is responsible for controlling and managing the NFVI compute, storage and network resources within one operator’s infrastructure sub-domain and collection and forwarding of performance measurements and events.

In this disclosure, the same set of network slice management entities is considered as described above, where each entity may also be managed by a different vendor/operator.

Regarding domain specific control, as an example, the RAN-NSSMF entity 112 undertakes the life-cycle management of all the RAN-NSSI entities 111. If a MANO-based system is in place to control the life-cycle management of PNFs/VNFs and all the available cloud/RAN resources 117 (e.g., processing, memory, spectrum etc.), then RAN- NSSMF 112 may need to interact with the MANO VNFO entity 113. It is highlighted at this point that RAN-NSSMF 112 is slice-aware, but VNFO 113 is slice-unaware.

Note that for the Transport Network (TN) part, the integration of a MANO system is not necessary as the network functions are exposed through SDN logic. In practice the TN- NSSMF is expected to be closely coupled with the domain control entities (like SDN controllers).

In Figure 1, the entities NSMF 103 and NSSMF 112, 132, 152 are shown. In general, these entities may be implemented to provide the following functionalities: The network slice management entity 103 may be used for managing access rights to a Network Slice Instance 104. The network slice management entity 103 is configured to: receive 1001 an access request for accessing the NSI 104 by a first user entity; receive 1002 information on the access rights of a plurality of user entities to the NSI 104; determine 1003, based on the information on the access rights of the plurality of user entities, whether a second user entity has an access right to the NSI and whether the NSI is shared among the plurality of user entities; and in case the NSI is shared, deny 1004 the access request of the first user entity if the second user entity has an access right to the NSI.

The NSI 104 may comprises at least one of: a shared resource 107, a shared function 105, a shared service 106, and a shared Network Slice Subnetwork Instance 111, 131, 151.

The network slice management entity 103 may further be configured to prevent a concurrent access to the NSI 104 by the first user entity and the second user entity, e.g. as described below with respect to Fig. 5.

The network slice management entity 103 may further be configured to grant the access request of the first user entity for accessing the NSI 104 upon determining that the second user entity has no access right to the NSI 104.

The network slice management entity 103 may be configured to grant the access request of the first user entity for accessing the NSI 104 upon determining that: the first user entity has an access right to the NSI 104, an operation to be performed by the first user entity is not violating 504 an operational rule, the operational rule indicating at least one allowable operation of the NSI 104, e.g. as described below with respect to Fig. 5, and there is no concurrent access to the NSI 104.

The network slice management entity 103 may further be configured to update 507 the information on the access rights to the NSI 104 upon granting the access request of the first user entity for accessing the NSI 104, e.g. as described below with respect to Fig. 5.

The network slice management entity 103 may be configured to determine whether the updating 507 the information is violating an operational rule of the second user entity before updating 507 the information on the access rights to the NSI 104, the operational rule indicating at least one allowable operation of the NSI 104, e.g. as described below with respect to Fig. 5.

The network slice management entity 103 may be configured to authenticate the first user entity before directing a request for information by the first user entity to a shared NSI database 640, 410, e.g. as described below with respect to Figs. 4 and 6.

The access rights to the NSI 104 may comprise at least one of the following: creating access right, reading access right, updating access right, deleting access right, and releasing access right.

The network slice management entity 103 may be configured to: lock 520 the NSI 104 for a concurrent access by another user entity of the plurality of user entities before updating configuration information and/or an operational state of the NSI 104, e.g. as described below with respect to Fig. 5; and unlock the NSI 104 for an access after updating the configuration information and/or the operational state of the NSI 104, e.g. as described below with respect to Fig. 5.

The network slice management entity 103 may be configured to lock 520 and unlock the NSI 104 based on a binary semaphore.

The operational state of the NSI 104 may comprise an identification of all user entities having access rights to the NSI 104.

The NSI 104 may comprises at least one domain-specific Network Slice Subnetwork Instance 111, 131, 151 from one of the following domains: Radio Access Network domain 110, Transport Network domain 130, and Core Network domain 150.

The network slice management entity 103 may be a Network Slice Management Function entity as exemplarily shown in Fig. 1. The at least one domain-specific NSSI 111, 131,

151 may be controlled by a domain controller 116, 133, 156 and managed by a Network Slice Subnet Management Function entity 112, 132, 152 as exemplarily shown in Fig. 1.

The network slice management entity 103 may be configured to: determine the NSSMF entity 112, 132, 152 based on an identifier of the NSI 104; and exchange information on the access rights of the NSI 104 via the NSSMF entity 112, 132, 152. The network slice management entity 103 may be configured to provision a response to the access request to a Communication Service Management Function, CSMF, entity 102, wherein the response indicates a grant or denial for accessing the NSI 104 by the first user entity.

The network slice subnetwork management entities 112, 132, 152 shown in Fig. 1 may be used for managing access rights to a Network Slice Subnetwork Instance 111, 131 , 151.

The network slice subnetwork management entity may be configured to: receive an access request for accessing the NSSI by a first user entity; receive information on the access rights of a plurality of user entities to the NSSI; determine, based on the information on the access rights of the plurality of user entities, whether a second user entity has an access right to the NSSI and whether the NSSI is shared among the plurality of user entities; and in case the NSI is shared, deny the access request of the first user entity if the second user entity has an access right to the NSSI.

Thus, the network slice subnetwork management entity may have the same functionality than the network slice management entity, but applied to the Network Slice Subnetwork instances.

The NSSI 111, 131, 151 may comprise at least one of: a shared resource 107, a shared function 105, and a shared service 106.

The network slice subnetwork management entity 112, 132, 152 may be configured to provision a response to the access request to a network slice management entity 103, wherein the response indicates a grant or denial for accessing the NSSI 111, 131, 151 by the first user entity.

The NSSI may be identified by a first NSSI identification for a network slice subnetwork management entity controlled by a first operator 720, e.g. as described below with respect to Figs. 7 and 8. The NSSI may be identified by a second NSSI identification for a network slice subnetwork management entity controlled by a second operator 730, e.g. as described below with respect to Figs. 7 and 8.

Fig. 2 shows a schematic diagram illustrating different sharing options 200 according to the disclosure. In Fig. 2, interaction and dependencies between the different entities as described above with respect to Fig. 1 are illustrated, i.e. between the RAN-NSSMF 112, the TN-NSSMF 132, the Core-NSSMF 152, the NSMF 103 and Communication Services 210.

The RAN-NSSMF 112 includes in this example a first RAN-NSSI 111a with Network Services 216, Network Functions 215 and network resources 217 and a second AN-NSSI 111b with Network Services 226, Network Functions 225 and network resources 227.

The TN-NSSMF 132 includes in this example a first TN-NSSI 131a with Network Functions 235a and network resources 237a, a second TN-NSSI 131b with Network Functions 235b and network resources 237b, and a third TN-NSSI 131c with Network Services 236c, Network Functions 235c and network resources 237c.

The Core-NSSMF 152 includes in this example a first CN-NSSI 151a with Network Services 256a, Network Functions 255a and network resources 257a and a second CN- NSSI 151b with Network Services 256b, Network Functions 255b and network resources 257b.

The NSMF 103 includes in this example a first NSI 104a, a second NSI 104b and a third NSI 104c which are interacting with the services 211, 212, 213, 214 of the Communication services 210 and which are interacting with their respective NSSIs 111a, 131a, 151a.

The NSSIs may be coupled with each other as shown in Fig. 2 in order to implement the different sharing options, for example first CN-NSSI 151a can be shared with first TN- NSSI 131a and can be shared with first RAN-NSSI 111a; first CN-NSSI 151a can be shared with second TN-NSSI 131b and can be shared with second AN-NSSI 111b; and second AN-NSSI 111b can be shared with third TN-NSSI 131c and can be shared with second CN-NSSI 151b.

According to TR 28.801 and TR 23.799 various sharing options exist between the NSIs, NSSIs and the NF in order to provide the integrated communication services. In principle, a NSSI may be shared by two or more NSIs, while a NF may be shared by two or more NSSI(s). Furthermore, a NSI may support zero or more communication services, while a communication service may be served by one or more NSIs, possibly with different characteristics. In Figure 2, examples of possible sharing options are presented, where in dark shade the shared instances are depicted. For example, NSI-2 (104b) managed by the NSMF 103 may be exploited by service 2 (212) and 3 (213), NF-1 (215) in the RAN may be shared by both the NSSI-1 and NSSI-2. In the following Table 1, possible definitions related to the sharing concept according to this disclosure are presented.

Table 1: Sharing definitions per entity

In Table 1 these definitions are elaborated. For example a single shared TN-NSSI instance that is responsible for the instantiation/configuration/operation of a best-effort end-to-end path of 10Gbps on the transport domain can be exploited by all NSIs, whether these exploit shared or dedicated RAN-NSSIs or shared or dedicated Core-NSSIs. Furthermore, as network consistency is interpreted in a different way depending on the context, the following definitions are used:

Network Slice consistency: all the management functions (i.e. NSMF, NSSMF, and controllers) all have the same view on the state of every aspect of the slice (function, resource, service etc.). Network state captures various network aspects (like link state, switches’ forwarding decisions, on/off state for resources etc.).

Network Slice consistency error: A consistency error occurs when different management systems affect the operation of a resource or function without notifying the rest of the entities that are also operating on the resource or function. For example NSI-1 sees MME service in “Running”, while NSI-2 sees the same service as “stopped”.

Network Slice Isolation: multiple network management functions to operate independently without violating operations in the other slices functions in the case sharing is not enabled.

As all the communication services operate over a dynamic environment that is in a constant state of mutation, the way sharing capabilities are enabled at the orchestrator level is still blear. For each network (or subnetwork) the relevant orchestration entity (NSMF or NSSMF) will undertake the responsibility to enable sharing in a way where the following key requirements are satisfied (indicative list): o Both shared and dedicated instances, functions and resources are properly registered in the orchestration level. o For both the shared and the dedicated instances the entire life-cycle (provisioning, instantiation/operation/decommissioning) is supported o For both the shared and the dedicated instances, the data generated (regarding instance itself, OAM messaging etc.) are only distributed to the entities that are authorized. o Even when shared instances or/and NFs are exploited, different QoS guarantees per slice must be satisfied. o SFCs with both shared NFs and dedicated NFs must be supported per slice instance.

Fig. 3 shows a schematic diagram illustrating the concept of nested sharing objects 300 according to the disclosure.

A shared NF 320 can be shared 331, 311 between first NSSI 330, e.g. RAN-NSSI 111a as shown in Fig. 2, and second NSSI 310, e.g. AN-NSSI 111b as shown in Fig. 2. The shared NF 320 may include an Access and Mobility Function (AMF) with NAS signaling 321 , Handover 322, other functionalities 323 and connection management 324. Handover 322 may also be implemented as a dedicated function 332, 312 to first NSSI 330 and/or second NSSI 310. Besides a “raw” function that can be shared like Access and Mobility Management Function (AMF) an internal function may also be shared like the handover function (in the example depicted in Figure 3). Although the same software component is shared, dedicated parts can reside inside a shared function. The concept described in this disclosure considers for all cases with the proper identification mechanism enhancements.

The access permission scheme and the corresponding real-time locking mechanism (described below) also cover the case to protect service-chains under sharing conditions.

In the case of operating systems and computer programming,

(CRUD) operations are defined for persistent storage information. In addition, commands like “chmod” define access permissions for files/folders (read, write, execute), according to each owner (or co-owner) that has specific access rights. However, in the context of network slicing, no mechanism, protocol or solution exist to cover a) the ownership relationships and b) network slice consistency protection under sharing. Both are covered by the concepts described in this disclosure.

The disclosure presents an access permissions scheme for all aspects that constitute a slice like NSI, NSSIs, Network Services, Network Functions, physical and virtual Resources and can be extended to coverall software or hardware parts that constitute a network slice.

Fig. 4 shows a schematic diagram illustrating an example of slice and sharing aware repositories 400 according to the disclosure. On the left side, slice aware repositories 410 are depicted including NSIs inventory 413 connected to a NSMF 411 , e.g. the NSMF 103 as shown in Fig. 1. The slice aware repositories 410 also include RAN NSSIs inventory 414, NS inventory 415, NF inventory 416 and resource inventory 417 which are connected to the NSSMF 412, e.g. the respective NSSMF 112, 132, 152 as shown in Fig. 1.

On the right side of Fig. 4, slice unaware repositories 420 are depicted including orchestration system 421 and control system 422. Orchestration system 421 is connected to NSSMF 412.

During the planning and instantiation phase, advanced identification information can be added for each service, function, resource, NSSI or NSI regarding sharing capabilities and the way to access them. This identification information is stored to repositories that reside on the NSSMF entities 412 (regarding Resources, NFs, NSs, NSSIs information) and is exposed to NSMF 411 (hosting also the repositories/information for the end-to-end NSIs). Note that NSMF 411 and NSSMFs 412 are slice aware, while for each domain (RAN, Transport, and Core) orchestration 421 and control 422 are in principle slice unaware and optionally slice aware.

With respect to Identification, at each repository a unique identifier is used to identify the relevant entity. In the context of this disclosure UIIDs are used as unique identifiers. For example, in the NF inventory 416 a NF (like AMF) can be identified by a UIID bf67eea2- e2bf-11e9-81b4-2a2ae2dbcce4. However, other identifiers can be also used (like I P/port, endpoint URL etc.). This is implementation specific, while this allocation is made by the orchestrator during the preparation and initialization phase.

With respect to access rights, for each slice user/owner, before he is able to perform any of the following actions for shared entities, he may be authenticated/authorized by the NSMF/NSSMF systems. For each entity the invention considers a Boolean identifier to describe if the entity can be shared between multiple hosting/parent entities. If the identifier is “TRUE” then the entity is eligible to be shared by multiple entities. If it is “FALSE” it can only be exploited/manipulated by a single entity.

For each entity a list may be provided with the core access rights. This list can be easily extended to cover other needs (related for example to security). It can be easily extended to cover other relevant aspects (like, for example, exploit CRUD operations on the filesystem level, which would require exposure to the orchestrator entity).

As to resources: the following access rights for entities that are authenticated/authorized and are able to manipulate/exploit a shared physical or virtual resource may exist: o “create” access: giving right to the owner to create a virtualized resource operating over physical infrastructure. o “read" access: read the resource state and is visible to a given NSMF/NSSMF. o “update" access: the resource/function state can be updated/manipulated/ configured by a given NSMF/NSSMF (for example update the VPN MPLS label allocation). o “delete": delete the resource from the resource pool. o “release": release the resource back to the resource pool considered to be always available for every owner. As to Network Functions: the following access rights for entities that are authenticated/authorized and are able to manipulate/exploit a shared network function may exist: o “create” access: giving right to the owner to deploy a NF over virtualized or physical resource. o “read" access: read the function configuration and operational state. o “update" access: the resource/function state can be updated/manipulated/ configured by a given NSMF/NSSMF (for example update the VPN MPLS label allocation). o “delete": delete the NF from the NF inventory and update the wiring with other NFs/NSs . o “release": unregister from using the NF, but not delete. Other owners can still use the NF. o “Stop": the owner right specifies that the parent/hosting entity can stop the operation of the network function. o “start": the owner right specifies that the parent/hosting entity can start the operation of the network function on a time based or event-based manner. o “scale": the parent/hosting entity is eligible to scale the network function (for example perform load balancing). o “unscale”: the parent/hosting entity is eligible to unscale the network function (for example by reducing running instances of the NF).

Example of the NF inventory is depicted in Table 2 where the owners of two NFs are depicted. In this example, NF_1 is shared between two entities. The access rights per entity are depicted in hex format and represent a binary representation of a Boolean decision per field (for example a binary 111001001 defines “Create=TRUE”, “Read=TRUE” etc.) NF_2 is not shared, so access rights can be defined only for a single entity.

Table 2: Enhanced inventories with access rights of shareable entities

Similarly, for other shared entities (like NFs, or NSSIs) a similar access permission scheme can be enforced that can be easily extended to cover other needs.

As to network services, the disclosure presents the following access rights for entities that are authenticated/authorized and are able to manipulate/exploit a shared network service: o “create” access: giving right to the owner to deploy a NS as a composition of one or multiple NFs. Note that a NF can be a standalone software entity o “read" access: read the service configuration and operational state o “update" access: the service state can be updated/manipulated/ configured by a given NSMF/NSSMF. o “delete": delete the NS from the NS inventory and update the wiring with other NFs/NSs . o “release": unregister from using the NS, but not delete. Other owners can still use the NS. o “Stop": the owner right specifies that the parent/hosting entity can stop the operation of the network service. o “start": the owner right specifies that the parent/hosting entity can start the operation of the network service on a time based or event-based manner.

As to NSSIs, the disclosure presents the following access rights for NSIs that are authenticated/authorized and are able to manipulate/exploit a NSSI: o “ Create ” access: giving right to the owner to deploy a NSSI as a composition of one or multiple NSs, NFs and NRs. o “Read” access: read the NSSI configuration and operational state o “update” access: the NSSI state can be updated/manipulated/configured by a given NSSMF. o “delete”: delete the NSSI from the NS inventory and update the wiring with other NSSIs/NSIs. o “release”: unregister from using the NSSI, but not delete. Other NSI owners can still use the NSSI. o “Copy”: create a copy of the NSSI with the same sub entities that constitute the NSSI together with their configuration.

As to NSIs, the disclosure presents the following access rights for entities that are authenticated/authorized and are able to manipulate/exploit a NSI: o “Create" access: giving right to the owner to deploy a NSI as a composition of one or multiple NSSIs, NSs, NFs and NRs. o “read” access: read the NSI configuration and operational state. o “update” access: the NSI state can be updated/manipulated/ configured by a given NSMF. o “delete”: delete the NSI from the NSI inventory and update the wiring with other NSSIs/NSIs. o “release”: unregister from using the NSSI, but not delete. Other owners can still use the NSI. o “Copy”: create a copy of the NSI with the same sub entities that constitute the NSI together with their configuration.

For NSI and NSSIs a flagging mechanism may be implemented with “Recursive”, i.e. include objects, functions etc. in management entities lower in the hierarchy, that inherit the access rights.

Fig. 5 shows a schematic diagram illustrating an exemplary workflow 500 for policy checking and locking mechanism according to the disclosure.

During runtime, an advanced locking mechanism designed to enforce a mutual exclusion concurrency of control policies can be implemented. A synchronization mechanism can be in place for enforcing limits on access and applying state consistency protection. If one owner is trying to update the state of a resource or a service, the other users/owners are protected or not affected.

In the case two entities are eligible to update another entity, besides concurrent access violation, both need to respect the policy specified by the other entity. Policy violation checks are done by the NSSMF/NSMF entities. The workflow for the general case of an UPDATE operation is illustrated in Figure 5. If an entity is eligible to update 501 a Network Function which is shared 502 but after a policy violation check 503 it is determined that the action to be performed leads to a policy violation 504 of another owner entity, then (after checking to update reconfiguration 509) a re-configuration attempt 510 is made or a withdraw action 511 is taken. In the case that an “update” action 501 is not violating a policy 504, to prevent the case where two eligible entities are trying to concurrently “update” the entity, the concepts of advisory locks, mandatory locks and semaphores used for Thread protection are extended to also protect sharing conditions for network functions, resources, NSIs etc. In more detail, for each entity that can be shared a mutex (binary semaphore) can be introduced that implements the locking mechanism 520 used to synchronize access to the entity, e.g. as shown in the right box 520 of Fig. 5. At any given time instance, only one entity task can acquire the mutex. For shared entities where sharing conditions are inherited, a recursive mutex may also be implemented.

For example, assume two NSs, namely NSi and NS2are sharing the same NF. Assume mutex is variable “S” that initially is “S=0”. If NSi attempts a reconfiguration that is not violating the policy of NS2_,then prior to action the relevant NSSMF sets “S=1”. While “S=1”, the NF is locked and no other update operation can be performed. When operation is finished NSSMF sets again “S=0”.

Similarly, each shared entity is associated with a binary Semaphore in the NSSF/NSMF level, while for more complicated scenarios more advanced schemes can be exploited like cooperative advisory locks.

In order to enable full Network Slice lifecycle protection under sharing conditions, as an additional step, the registration of callback methods to track shared components may be implemented. After the registration step of callback methods, read-write-execute-etc. access rights of shared functions, components etc. to the different hosting entities are enabled. In the case where a Function, resource etc. is shared, then the orchestrator registers the right callback methods and subscribes to all the events. In case there is a conflict (because of a configuration required, or operational update, for example), then all the subscribers can be informed and the orchestrator can solve these conflicts. Orchestrators (NSSMF-NSMF) should maintain an optimal slice allocation during runtime through feedback and an internal control loop. As to Orchestration entities orchestration components communication-Protocol extensions, updated or new data communication models required to preserve protection may be implemented. Information needs to be preserved at any time in the relevant orchestration entity. For every file/object etc. processed a diagnostic output may be generated and may be communicated to all the hosting/parent entities.

If a function or a resource is shared, then NSSMF is the entity responsible to maintain such information.

If an entire NSSI is shared, then NSSMF needs also to pass this information to the NSMF which has the global view. This communication can be made through a message bus or following a client-server model.

In the event of a change, NSMF and NSSMF are subscribers to such events and need to update the state of the sharable entity.

NSSMF and NSMF may be implemented in order to maintain the state for each sharable entity; and solve conflicts between owners of sharable objects/functions resources etc. Sharing protection functionality can be “offloaded” to the Control plane to boost performance.

Both client-server and message bus-based communication mechanisms between the various control and orchestration components may be implemented. Depending on the access rights specific protocol operations can be used with a mapping operation. Examples are “read” maps to HTTP “GET”, “delete” maps to HTTP “DELETE” operation, or “update” is mapped to “POST” or “PUT” operation.

All the information exchange can be made between different management entities (like NSFM and corresponding NSSMFs). The information requires an extension of the existing interfaces/protocols according to the innovation points described earlier, to carry the relevant sharing information. With the approach described in this disclosure multiple network management applications are able to operate independently over the same resources/functions. This novel information exchange is described in more detail in Figure 6 below.

Fig. 6 shows an exemplary sequence diagram 600 illustrating sharing under different stages of lifecycle management according to the disclosure. Depending on the sharing scenario a different set of criteria can be used to optimize the procedures for consistency protection. In Figure 6 a sequence diagram 600 is depicted presenting key slice lifecycle operations under network slice sharing.

Messages between an Application Provider, 3^rd Party, Vertical, etc. entity 610, a 3GPP CSMF/NSMF 620, NSSMFs 630, Shared Entities state Database (Database that holds the state of all shared entities) 640, a domain controller 650 and OAM entities 660 are shown. The 3GPP CSMF/NSMF 620 may correspond to the CSMF 102 and NSMF 103 entities shown in Fig. 1. The NSSMFs 630 may correspond to the NSSMFs 112, 132, 152 entities as shown in Fig. 1. The Shared Entities state Database 640 is a database that holds the state of all shared entities.

OAM 660 may enable locking 661 (of 3GPP CSMF/NSMF 620, NSSMFs 630 and shared entities state database 640) when necessary. The sequence diagram 600 includes a preparation phase 601, an instantiate/configure/installation phase 602, a runtime 603 and a decommissioning 604.

In the preparation phase 601, Application Provider, 3^rd Party, Vertical, etc. entity 610 transmits e2e slice request message 611 to 3GPP CSMF/NSMF 620 to request for a slice. 3GPP CSMF/NSMF 620 transmits capabilities request message 621 to NSSMFs 630 to request for capabilities of the corresponding slice. NSSMFs 630 checks 631 if slice is shared and replies with capabilities response message 632 indicating capabilities of the requested slice.

Then, 3GPP CSMF/NSMF 620 transmits slice request message 622 to NSSMFs 630 to request for the respective slice. NSSMFs 630 transmit message “Check available transport slices reservations and current network slices state” 633 to shared entities state database 640 to check available transport slices reservations and current network slices state shared entities state database 640 replies with response message 641. Then, negotiation and admission control 623 is performed between 3GPP CSMF/NSMF 620 and NSSMFs 630. NSSMFs 630 transmit message “Update slice info, Provision resources” 634 to shared entities state database 640 to update slice info and provision resources. Shared entities state database 640 updates shared entities state 642 and transmits response message “Reserve resources response” 643 to NSSMFs 630 to indicate reserved resources. Response message “provisioning response” 635 is provided by NSSMFs 630 to 3GPP CSMF/NSMF 620. In the instantiate/configure/installation phase 602, NSSMFs 630 transmit “configure resources” message 643 to domain controller 650 which initiates resource configuration in shared entities state database 640. OAM 660 transmits “OAM Slice Monitoring” message 662 to domain controller 650 that responds 644 to NSSMFs 630.

During runtime 603, periodical OAM slice reporting 625 is performed including transmission of “runtime actions” message 624 by 3GPP CSMF/NSMF 620 to NSSMFs 630 and further to domain controller 650, reporting of “runtime statistics” 643 by OAM 660 to shared entities state database 640, transmitting “filtered statistics” message 645 by shared entities state database 640 to NSSMFs 630 and transmitting “filtered statistics” message 636 by NSSMFs 630 to 3GPP CSMF/NSMF 620.

During decommissioning 604, 3GPP CSMF/NSMF 620 transmits “release slice resources” message 626 to NSSMFs 630 to initiate release of slice resources, which message is forwarded to shared entities state database 640, domain controller 650 and OAM 660 and respectively acknowledged by these entities with Acknowledge message “Release slice resources Ack” 637.

Check for conflicts 646 is performed between NSSMFs 630, shared entities state database 640, domain controller 650 and OAM 660.

Fig. 7 shows a schematic diagram illustrating an exemplary implementation of a single operator case 700 according to a first embodiment.

A multi-vendor operational environment is shown, where different providers are controlling different management entities. For example, a Mobile Virtual Network Operator is controlling its NSMF, but the RAN NSMF is controlled by the physical infrastructure owner Telecom operator. In any case, the NSMF entity has a global view of the access rights.

In the scenario shown in Fig. 7, a NSMF 710 is controlled by Operator A, which also controls a first NSSMF 720a and a second NSSMF 720b. Information can be exchanged per domain. The NSMF has information, e.g. in form of a table 711 including function/resource type, resource ID, Owner 1 and Owner 2. Table 711:

Similarly, first NSSMF 720a and second NSSMF 720b have information, e.g. in form of respective tables 721, 722 including function/resource type, resource ID, Owner 1 and Owner 2.

NSMF 710 may correspond to NSMF 103 shown in Fig. 1 and NSSMFs 720a, 720b may correspond to NSSMFs 112, 132, 152 shown in Fig. 1. The tables 711, 721, 722 may also be implemented according to Table 2 described above.

Table 721:

Table 722:

Fig. 8 shows a schematic diagram illustrating an exemplary implementation of a multi operator case 800 according to a second embodiment. Resource identification information may not be common among all management entities 710, 720, 730. For example, a NSI managed by a NSMF 710 controlled by vendor A, refers to a resource using the uuid 40c0890e-6717-4377-b335-d93623013669 (see table 811), while lower in the hierarchy the NSSMF 730 controlled by operator B identifies the resource by uuid ba44fdd7-2ba7-4395-80d7-89cb4d0d7a85 (see table 822). An identification information mapping mechanism is implemented between the different management entities 730, 710 to map 823 the resource identified by operator B as uuid ba44fdd7-2ba7-4395-80d7-89cb4d0d7a85 to the resource identified by vendor A as uuid 40c0890e-6717-4377-b335-d93623013669.

Table 811:

Table 821:

Table 822:

Fig. 9 shows a schematic diagram illustrating an exemplary program code 900 (in json format) for a technology agnostic request for a transport NSSI according to a third embodiment.

In the program code 900, NSSIJD is defined, NSSI duration is defined, NSSI initial time is defined and NSSI slice policy is defined. Furthermore, NSSI sharing is defined and Owners of the NSSI are defined together with their IDs and their access rights. The access rights are known by the NSI and are set by NSMF. Furthermore, coverage type and coverage paths are defined.

This list is not exhaustive and can be extended based on e.g. Technology Independent Information Model for Network Slicing “draft-qiang-coms-netslicing-information-model-01”.

The method 1000 comprises receiving 1001 an access request for accessing the NSI by a first user entity; receiving 1002 information on the access rights of a plurality of user entities to the NSI; determining 1003, based on the information on the access rights of the plurality of user entities, whether a second user entity has an access right to the NSI and whether the NSI is shared among the plurality of user entities; and, in case the NSI is shared, denying 1004 the access request of the first user entity if the second user entity has an access right to the NSI.

The method 1000 performs the same steps as the network slice management entity described above with respect to Figures 1 to 9.

The method 1000 further comprises preventing a concurrent access to the NSI by the first user entity and the second user entity. The method 1000 further comprises granting the access request of the first user entity for accessing the NSI upon determining that the second user entity has no access right to the NSI.

The method 1000 further comprises granting the access request of the first user entity for accessing the NSI upon determining that: the first user entity has an access right to the NSI, an operation to be performed by the first user entity is not violating an operational rule, the operational rule indicating at least one allowable operation of the NSI, and there is no concurrent access to the NSI.

The method 1000 further comprises updating the information on the access rights to the NSI upon granting the access request of the first user entity for accessing the NSI.

The method 1000 further comprises determining whether the updating the information is violating an operational rule of the second user entity before updating the information on the access rights to the NSI, the operational rule indicating at least one allowable operation of the NSI.

The method 1000 further comprises authenticating the first user entity before directing a request for information by the first user entity to a shared NSI database.

The method 1000 further comprises: locking the NSI for a concurrent access by another user entity of the plurality of user entities before updating configuration information and/or an operational state of the NSI; and unlocking the NSI for an access after updating the configuration information and/or the operational state of the NSI.

The NSI may be a Network Slice Subnetwork Instance.

The present disclosure also supports a computer program product including computer executable code or computer executable instructions that, when executed, causes at least one computer to execute the performing and computing steps described herein. Such a computer program product may include a readable non-transitory storage medium storing program code thereon for use by a computer. The program code may perform the processing and computing steps described herein. While a particular feature or aspect of the disclosure may have been disclosed with respect to only one of several implementations, such feature or aspect may be combined with one or more other features or aspects of the other implementations 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 labeling, 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.

The project leading to this application has received funding from the European Union’s H20205GPicture research and innovation programme under grant agreement No 762057.

Claims

CLAIMS:

1. A network slice management entity (103) for managing access rights to a Network Slice Instance (104), NSI, wherein the network slice management entity (103) is configured to:

• receive (1001) an access request for accessing the NSI (104) by a first user entity;

• receive (1002) information on the access rights of a plurality of user entities to the NSI (104);

• determine (1003), based on the information on the access rights of the plurality of user entities, whether a second user entity has an access right to the NSI and whether the NSI is shared among the plurality of user entities; and

• in case the NSI is shared, deny (1004) the access request of the first user entity if the second user entity has an access right to the NSI.

2. The network slice management entity (103) of claim 1, wherein the NSI (104) comprises at least one of: a shared resource (107), a shared function (105), a shared service (106), and a shared Network Slice Subnetwork Instance (111 , 131 , 151), NSSI.

3. The network slice management entity (103) of claim 1 or 2, further configured to prevent a concurrent access to the NSI (104) by the first user entity and the second user entity.

4. The network slice management entity (103) of one of the preceding claims, further configured to grant the access request of the first user entity for accessing the NSI (104) upon determining that the second user entity has no access right to the NSI (104).

5. The network slice management entity (103) of one of the preceding claims, configured to grant the access request of the first user entity for accessing the NSI (104) upon determining that: the first user entity has an access right to the NSI (104), an operation to be performed by the first user entity is not violating (504) an operational rule, the operational rule indicating at least one allowable operation of the NSI (104), and there is no concurrent access to the NSI (104).

6. The network slice management entity (103) of claim 4 or 5, further configured to update (507) the information on the access rights to the NSI (104) upon granting the access request of the first user entity for accessing the NSI (104).

7. The network slice management entity (103) of claim 6, configured to determine whether the updating (507) the information is violating an operational rule of the second user entity before updating (507) the information on the access rights to the NSI (104), the operational rule indicating at least one allowable operation of the NSI (104).

8. The network slice management entity (103) of claim 7, configured to authenticate the first user entity before directing a request for information by the first user entity to a shared NSI database (640, 410).

9. The network slice management entity (103) of one of the preceding claims, wherein the access rights to the NSI (104) comprise at least one of the following:

• creating access right,

• reading access right,

• updating access right,

• deleting access right, and

• releasing access right.

10. The network slice management entity (103) of one of the preceding claims, configured to:

• lock (520) the NSI (104) for a concurrent access by another user entity of the plurality of user entities before updating configuration information and/or an operational state of the NSI (104); and

• unlock the NSI (104) for an access after updating the configuration information and/or the operational state of the NSI (104).

11. The network slice management entity (103) of claim 10, configured to lock (520) and unlock the NSI (104) based on a binary semaphore.

12. The network slice management entity (103) of one of claims 10 to 11, wherein the operational state of the NSI (104) comprises an identification of all user entities having access rights to the NSI (104).

13. The network slice management entity (103) of one of the preceding claims, wherein the NSI (104) comprises at least one domain-specific Network Slice Subnetwork Instance (111, 131, 151), NSSI, from one of the following domains: Radio Access Network domain (110), Transport Network domain (130), and Core Network domain (150).

14. The network slice management entity (103) of claim 13, wherein the network slice management entity (103) is a Network Slice Management Function, NSMF, entity, and wherein the at least one domain-specific NSSI (111, 131, 151) is controlled by a domain controller (116, 133, 156) and managed by a Network Slice Subnet Management Function, NSSMF, entity (112, 132, 152).

15. The network slice management entity (103) of claim 14, configured to:

• determine the NSSMF entity (112, 132, 152) based on an identifier of the NSI (104); and

• exchange information on the access rights of the NSI (104) via the NSSMF entity (112, 132, 152).

16. The network slice management entity (103) of one of the preceding claims, configured to provision a response to the access request to a Communication Service Management Function, CSMF, entity (102), wherein the response indicates a grant or denial for accessing the NSI (104) by the first user entity.

17. A network slice subnetwork management entity (112, 132, 152) for managing access rights to a Network Slice Subnetwork Instance (111, 131, 151), NSSI, wherein the network slice subnetwork management entity is configured to:

• receive an access request for accessing the NSSI by a first user entity;

• receive information on the access rights of a plurality of user entities to the NSSI;

• determine, based on the information on the access rights of the plurality of user entities, whether a second user entity has an access right to the NSSI and whether the NSSI is shared among the plurality of user entities; and

• in case the NSI is shared, deny the access request of the first user entity if the second user entity has an access right to the NSSI.

18. The network slice subnetwork management entity (112, 132, 152) of claim 17, wherein the NSSI (111, 131, 151) comprises at least one of: a shared resource (107), a shared function (105), and a shared service (106).

19. The network slice subnetwork management entity (112, 132, 152) of claim 17 or 18, configured to provision a response to the access request to a network slice management entity (103), wherein the response indicates a grant or denial for accessing the NSSI (111, 131, 151 ) by the first user entity.

20. The network slice subnetwork management entity (112, 132, 152) of claim 19, wherein the NSSI is identified by a first NSSI identification for a network slice subnetwork management entity controlled by a first operator (720), and wherein the NSSI is identified by a second NSSI identification for a network slice subnetwork management entity controlled by a second operator (730).

21. A method (1000) for managing access rights to a Network Slice Instance, NSI, the method comprising:

• receiving (1001) an access request for accessing the NSI by a first user entity;

• receiving (1002) information on the access rights of a plurality of user entities to the NSI;

• determining (1003), based on the information on the access rights of the plurality of user entities, whether a second user entity has an access right to the NSI and whether the NSI is shared among the plurality of user entities; and

• in case the NSI is shared, denying (1004) the access request of the first user entity if the second user entity has an access right to the NSI.

22. The method (1000) of claim 21 , further comprising preventing a concurrent access to the NSI by the first user entity and the second user entity.

23. The method (1000) of claim 21 or 22, further comprising granting the access request of the first user entity for accessing the NSI upon determining that the second user entity has no access right to the NSI.

24. The method (1000) of any one of claims 21 to 23, further comprising granting the access request of the first user entity for accessing the NSI upon determining that: the first user entity has an access right to the NSI, an operation to be performed by the first user entity is not violating an operational rule, the operational rule indicating at least one allowable operation of the NSI, and there is no concurrent access to the NSI.

25. The method (1000) of claim 23 or 24, further comprising updating the information on the access rights to the NSI upon granting the access request of the first user entity for accessing the NSI.

26. The method (1000) of claim 25, further comprising determining whether the updating the information is violating an operational rule of the second user entity before updating the information on the access rights to the NSI, the operational rule indicating at least one allowable operation of the NSI.

27. The method (1000) of claim 26, further comprising authenticating the first user entity before directing a request for information by the first user entity to a shared NSI database.

28. The method (1000) of any one of claims 21 to 27, further comprising:

• locking the NSI for a concurrent access by another user entity of the plurality of user entities before updating configuration information and/or an operational state of the NSI; and

• unlocking the NSI for an access after updating the configuration information and/or the operational state of the NSI.

29. The method (1000) of any one of claims 21 to 28, wherein the NSI is a Network Slice Subnetwork Instance.