Patent Description:
Management of a communication network is a rather complex task. In view of this situation, it is to provide functionalities which assist operators in management of the communication network and may also allow for at least partially automating management tasks. For this reason, network automation is an important aspect of future network development, e.g., in <NUM> (<NUM>th Generation) mobile network evolution.

In network automation, management entities and/or orchestration entities may operate autonomously based on various design time data that guide the orchestration behavior and processes and/or runtime and context information. Network automation, in particular in view of orchestration, is for example addressed by standards like ETSI NFV (see, e.g., ETSI GS NFV IFA <NUM> V4. <NUM> (<NUM>-<NUM>), ETSI GS NFV-IFA <NUM> V4. <NUM> (<NUM>-<NUM>), ETSI GS NFV-IFA <NUM> V4. <NUM> (<NUM>-<NUM>), ETSI GS NFV-IFA <NUM> V4. <NUM> (<NUM>-<NUM>), and ETSI GS NFV-SOL <NUM> V4. <NUM> (<NUM>-<NUM>)), ONAP (see, e.g., ONAP Guilin Maintenance Release <NUM>. <NUM> (<NUM>-<NUM>)), or O-RAN (see, e.g., O-RAN O2 General Aspects and Principles Specification <NUM> (<NUM>-<NUM>)).

The ETSI NFV framework, in the following also shortly denoted as NFV framework, is an orchestration and management technology having widespread acceptance and support in the telecom industry and defines an architecture for orchestration and life-cycle management (LCM) of virtualized networks and virtualized network function (VNF) applications. This architecture is typically referred to as the ETSI NFV-MANO architecture (MANO: Management and Orchestration). In the ETSI NVF-MANO architecture, an entity denoted as NFV Orchestrator (NFVO) exposes a NSD (Network Service Descriptor) management interface that allows consumers, e.g., OSS /BSS (Operations Support System / Business Support System), to perform onboarding of NSDs. The NFVO also exposes a VNF package interface that allows consumers to perform onboarding of VNF Descriptors (VNFDs). An entity denoted as VNFM (VNF Manager) is responsible for LCM of VNFs and exposes a VNF LCM interface.

The NSD is a deployment template which consists of information used by the NFVO for life cycle management of an NS (Network Service). Usually, an NSD contains VNFDs as one of its constituents. Other possible constituents of a NSD are nested NSDs and PNFDs (Physical Network Function Descriptors).

Further, the NFVO exposes an NS LCM interface that allows the NS LCM operations like instantiation, updating, scaling, and/or termination of an NS. To perform such NS LCM operations, the NFVO may invoke VNF LCM operations, exposed by the VNFM in the VNF LCM interface. The NFVO may also be a consumer of an NS LCM interface exposed by another NFVO, if a nested NS is managed by a separate NFVO.

In the NFV framework, constituents of the NSD are uniquely identified by an identifier. VNFDs are uniquely identified by a VNFD identifier. Any change in the VNFD, or in another component of the VNF package, results in a different VNFD identifier. Similarly, NSDs are uniquely identified with an NSD identifier, and PNFDs are uniquely identified by an PNFD identifier.

A more recent enhancement of the NFV framework allows, upon certain conditions, to use a different version of an NSD constituent. Accordingly, if the NSD specifies a certain version of a VNFD, a certain version of a nested NSD, or a certain version of a PNFD, it may be allowed to use another version of that constituent. Such other version of the constituent then also has another identifier. The allowed different version is indicated via the NS LCM interface, e.g., by a consumer of the interface like OSS/BSS, and the allowed different version overrides the one in the NSD. Accordingly, the allowed different version may also be referred to as overriding version. A condition upon which such overriding is allowed is that the overriding version of the constituent maintains external invariance. This means that the overriding version has the same external connectivity and exposes the same attributes as the originally specified version. Such NSDs in which certain constituents are substituted by another version, may for example be used to provide different deployment flavors of the NS.

The above condition of maintaining external invariance is controlled by an Extlnvariantld attribute in the respective constituent, e.g., in a VNFD, NSD, or PNFD. The Extlnvariantld attribute can optionally be provided in addition to the unique identifier of the constituent. For example, if two VNFDs have the same Extlnvariantld, this indicates external invariance of these VNFDs and that these VNFDs are suitable for the overriding and substitution as described above. In this way, it can be avoided that an NSD needs to be updated each time when one of its constituents is modified.

In some situations, the above-way of substituting another version of an NSD constituent may still result in problems, in particular if there is a certain functional dependency among the NSD constituents. In particular, it may occur that such functional dependency exists with respect to a specific version of the constituent. Substituting this specific version with another version may then have the effect that the functional dependency is no longer satisfied. Similarly, when substituting one version of a constituent with another version, the substituted version may have different functional dependencies on one or more other constituents of the NSD, which are however not met.

<CIT> constitues a relevant piece of art.

Accordingly, there is a need for efficiently managing a network service having multiple constituents, in particular with respect to possible substitution of a constituent by another version.

According to an embodiment, a method of managing a network service corresponding to claim <NUM> is provided.

According to a further embodiment, a node for a communication network corresponding to claim <NUM> is provided.

According to a further embodiment of the invention, a computer program or computer program product corresponding to claim <NUM> is provided, e.g., in the form of a non-transitory storage medium.

In the following, concepts in accordance with exemplary embodiments of the invention will be explained in more detail and with reference to the accompanying drawings. The illustrated embodiments relate to management of a network service provided in a communication network. The communication network may for example be a mobile communication network, e.g., as specified by 3GPP. However, the concepts could also be applied in other types of communication network.

In the illustrated concepts, for managing a network service (NS), a descriptor of the NS is supplemented with information on version dependency between two or more of its constituents. The constituents may include one or more descriptors of network functions (NFs). Such NF may be a virtual NF (VNF) or a physical NF (PNF). Other possible constituents of the descriptor are one or more descriptors of a nested NS. The nested NS corresponds to an NS which is invoked as part of the managed NS. The nested NS may be managed by another entity. When for example considering an NS managed by the NFV framework, the NSD of the NS may include one or more VNFDs, one or more PNFDs, and/or one or more NSDs of nested NSs. For at least one of these constituents different versions may exist. In such cases, the NSD may allow that the constituent identified in the NSD is substituted by another version, e.g., by including an Extlnvariantld attribute of the respective constituent. For example, if two VNFDs in the NSD have the same Extlnvariantld, this indicates external invariance of these VNFDs and that these VNFDs are allowed to be substituted by one another. In this way, it can be avoided that the NSD needs to be updated each time when one of its constituents is modified. Here, the information on version dependency may be used as an additional criterion when deciding on whether to accept the substitution. Specifically, the constituent to be substituted may have a certain version dependency with respect to another constituent. The version dependency can involve that the version of the constituent after substitution requires the presence of a certain version of the other constituent. The information on version dependency may be used to validate in an automated manner whether this requirement is met after the substitution. In another case, the version dependency can involve that another constituent requires the presence of a certain version of the constituent to be substituted. Also here, the information on version dependency may be used to validate in an automated manner whether this requirement is met after the substitution.

<FIG> illustrates exemplary structures of the communication network, which in the illustrated example is assumed to be a wireless communication network as specified by 3GPP. In particular, <FIG> shows multiple UEs <NUM> which are served by access nodes <NUM> of the wireless communication network. Here, it is noted that each access node <NUM> may serve a number of cells within the coverage area of the wireless communication network. Depending on the supported RAT(s) each access nodes <NUM> may correspond to a gNB of the NR technology or an eNB of the LTE technology. The access nodes <NUM> may each be regarded as being part of an RAN of the wireless communication network. Further, <FIG> schematically illustrates a CN (Core Network) <NUM> of the wireless communication network. In <FIG>, the CN <NUM> is illustrated as including a GW (gateway) <NUM> and one or more control node(s) <NUM>. The GW <NUM> may be responsible for handling UP traffic of the UEs <NUM>, e.g., by forwarding user data traffic from a UE <NUM> to a network destination or by forwarding user data traffic from a network source to a UE <NUM>. Here, the network destination may correspond to another UE <NUM>, to an internal node of the wireless communication network, or to an external node which is connected to the wireless communication network. Similarly, the network source may correspond to another UE <NUM>, to an internal node of the wireless communication network, or to an external node which is connected to the wireless communication network. The control node(s) <NUM> may be used for controlling the user data traffic, e.g., by providing control data to the access node <NUM>, the GW <NUM>, and/or to the UE <NUM>.

As illustrated by double-headed arrows, the access node <NUM> may send DL transmissions to the UEs, and the UEs may send UL transmissions to the access nodes <NUM>. The DL transmissions and UL transmissions may be used to provide various kinds of services to the UEs, e.g., a voice service, a multimedia service, or a data service. Such services may be hosted in the CN <NUM>, e.g., by a corresponding network node. By way of example, <FIG> illustrates an application service platform <NUM> provided in the CN <NUM>. Further, such services may be hosted externally, e.g., by an AF (application function) connected to the CN <NUM>. By way of example, <FIG> illustrates one or more application servers <NUM> connected to the CN <NUM>. The application server(s) <NUM> could for example connect through the Internet or some other wide area communication network to the CN <NUM>. The application service platform <NUM> may be based on a server or a cloud computing system and be hosted by one or more host computers. Similarly, the application server(s) <NUM> may be based on a server or a cloud computing system and be hosted by one or more host computers. The application server(s) <NUM> may include or be associated with one or more AFs that enable interaction with the CN <NUM> to provide one or more services to the UEs <NUM>, corresponding to one or more applications. These services or applications may generate the user data traffic conveyed by the DL transmissions and/or the UL transmissions between the access node(s) <NUM> and the respective UE <NUM>. Accordingly, the application server(s) <NUM> may include or correspond to the above-mentioned network destination and/or network source for the user data traffic. In the respective UE <NUM>, such service may be based on an application (or shortly "app") which is executed on the UE <NUM>. Such application may be pre-installed or installed by the user. Such application may generate at least a part of the UP traffic between the UE <NUM> and the access node <NUM>.

In the illustrated concepts, at least some of the nodes illustrated in <FIG> may contribute to providing one or more NSs. Further, at least some of the functionalities of the illustrated nodes could be provided as an NS. For example, the CN <NUM> and/or the Application Servers <NUM> could at least in part be virtualized. Accordingly, a certain functionality of the GW <NUM>, the control node(s) <NUM>, the application service platform <NUM>, and/or the application server(s) <NUM> could be implemented as an NS, which in turn may be based on one or more VNFs, one or more PNFs, and/or one or more nested NSs. Such nested NSs may in turn itself be based on one or more VNFs, one or more PNFs, and/or one or more NSs. The illustrated concepts may be utilized for efficiently managing such NS.

In the following, the illustrated concepts will be explained in more detail, assuming that the NS is managed based on the NFV frame work, using an ETSI NFV-MANO architecture. <FIG>, illustrates an example of such architecture. In this architecture an NFVO exposes an NSD management interface that allows consumers, e.g., OSS /BSS, to perform onboarding of NSDs and other management operations of NSs. The NFVO also exposes a VNF package interface that allows the consumers to perform onboarding of VNFDs. In the architecture of <FIG>, these interfaces are implemented by the Os-Ma-nfvo reference point. A VNFM is responsible for LCM of VNFs and exposes a VNF LCM interface. In the architecture of <FIG>, this interface is implemented by the Or-Vnfm reference point. Further details concerning the architecture elements illustrated in <FIG> can be implemented as defined in the ETSI NFV specifications, in particular V4. <NUM> of ETSI GS NFV IFA <NUM>, ETSI GS NFV-IFA <NUM>, ETSI GS NFV-IFA <NUM>, ETSI GS NFV-IFA <NUM>, and ETSI GS NFV-SOL <NUM>. The illustrated concepts may in particular involve functionalities of the NFVO, interaction of the NFVO with the OSS/BSS via the Os-Ma-nfvo reference point, and interaction of the NFVO with the VNFM via the Or-Vnfm reference point.

<FIG> further illustrates the entities that may participate in management procedures according to the illustrated concepts. In particular, <FIG> illustrates an NFVO <NUM>, a VNFM <NUM>, and an OSS/BSS <NUM>. These entities may be part of an overall architecture as illustrated in <FIG>. The NFVO and the VNFM communicate via an interface <NUM>, which may correspond to the above-mentioned Or-Vnfm reference point. The NFVO and the OSS/BSS <NUM> communicate via an interface <NUM>, which may correspond to the above-mentioned Os-Ma-nfvo reference point. The interface <NUM> supports signaling for VNF LCM procedures. The interface <NUM> supports signaling for NSD management procedures, VNF package management procedures, and NS LCM procedures. Further, <FIG> also illustrates a set of exemplary types of descriptors which may be used in the illustrated concepts, namely an NSD <NUM>, a VNFD <NUM>, and a PNFD <NUM>.

In the illustrated concepts, an NSD may be supplemented with information about version dependencies between the constituents of the NSD. Further, the NS LCM interface, i.e., the interface <NUM>, may be supplemented with functionalities enabling the consumer of the interface to provide overriding version dependencies to replace the version dependencies originally indicated in the NSD. The NFVO <NUM> may be enhanced by functionalities to ensure adherence to the version dependencies during the lifecycle of an NS instance. This may be achieved by controlling NS LCM operations depending on the version dependencies: When performing an NS LCM operation, the NFVO <NUM> may verify that the current version dependencies, which are typically the last version dependencies that were provided in an NS LCM operation as overriding version dependencies or the original version dependencies indicated in the NSD if overriding version dependencies have not been provided yet, would still be satisfied after the NS LCM operation. NS LCM operations that may result in the use of an NS constituent with a different version to the one indicated in the NSD include: instantiation of the NS, and update of the NS. The update of the NS may include the following sub-cases: adding an existing VNF instance to an NS instance, instantiating a new VNF instance and adding it to the NS instance, adding an existing NS instance as nested NS to the NS instance, moving an VNF instance from one NS instance to another NS instance, adding a PNF instance to the NS instance, and/or changing the current VNF package of a VNF instance.

<FIG> illustrates an example of an NSD in accordance with the illustrated concepts. In this example, the NSD has three constituent VNFDs, identified by "aaa_2. <NUM>", "bbb_2. <NUM>", and "ccc_2. The suffix "<NUM>" may be regarded as indicating the version of the respective constituent. The NSD incorporates its constituent VNFDs by including references to these VNFDs, in terms of VNFD identifiers. It is noted that in the NFV framework the reference to a VNFD in an NSD is inherently VNFD version specific, since different VNFD versions have different VNFD identifiers. In addition, <FIG> shows a further VNFD, identified by "ccc_1. <NUM>", which is however not referenced in the NSD. This further VNFD corresponds to another version of the VNFD with identifier ccc_2. <NUM>, namely version <NUM> as compared to version <NUM> of the VNFD referenced by the NSD.

As further illustrated, the VNFDs in the example of <FIG> also each include an Extlnvariantld attribute. The VNFD with identifier aaa_2. <NUM> includes a VnfExtlnvariantld set to "aaa00". The VNFD with identifier bbb_2. <NUM> includes a VnfExtlnvariantld set to "bbb00". The VNFD with identifier ccc_2. <NUM> includes a VnfExtlnvariantld set to "ccc00", which is the same VnfExtlnvariantld as that of the VNFD with identifier ccc_1. Accordingly, from the perspective of external invariance, it would be allowed to use VNFD ccc_1. <NUM> instead of VNFD ccc_2. <NUM> in an NS instance which is based on the NSD, if such "overriding VNFD" is indicated in an NS LCM operation.

As further illustrated, the NSD in the example of <FIG> also includes an element denoted as "Dependencies". This element indicates the version dependency information of the illustrated concepts. In the illustrated example, the version dependency information indicates that the VNFD with identifier aaa_2. <NUM> depends on alternatives corresponding to the VNFDs with identifiers ccc_2. <NUM> and ccc_1. This means that VNFD with identifier aaa_2. <NUM> requires the presence of either the VNFDs with identifiers ccc_2. <NUM> or ccc_1. <NUM> in the NS instance. Further, the version dependency information indicates that the VNFD with identifier aaa_2. <NUM> depends on alternatives corresponding to the VNFDs with identifier bbb_2.

Examples of possible formats of indicating the version dependency information are illustrated in <FIG>. As illustrated in <FIG>, the version dependency information may be indicated by an information element of the NSD which is designated as "versionDependency". This information element includes a first attribute designated as "dependentConstituentld", which has a cardinality of <NUM> and identifies a dependent constituent in terms of its descriptor identifier. Further, the information element includes a second attribute designated as "versionDependencyStatement". <FIG> illustrates a possible format of the versionDependencyStatement information element. In this example, the versionDependencyStatement element has a cardinality corresponding to the number of other descriptors on which the dependent constituent depends, which are each identified in terms of their descriptor identifier, indicated by an attribute denoted as "descriptorld". The version dependency statement, thus identifies a VNFD, NSD or PNFD upon which the dependent constituent depends. When more than one other descriptor identifiers are present in the version dependency statement, the descriptor identifiers are regarded as corresponding to versions of the same VNF, NS or PNF and they represent alternatives, i.e., the presence of one of them fulfills the dependency. Accordingly, if multiple other descriptors are present they are to be validated in terms of a logical OR combination. If multiple versionDependencyStatement attributes are present in the versionDependency information element, these are to be validated in terms of a logical AND combination, i.e., all version dependency statements need to be fulfilled.

It is noted that in the example of <FIG>, the version dependency information can be provided for various constituent types of the NSD, e.g., VNFDs, PNFDs and/or nested NSDs. Accordingly, the version dependency information element could indicate dependency of a dependent VNFD on one or more other VNFDs, dependency of a dependent PNFD on one or more other PNFDs, or dependency of a dependent nested NS on one or more other nested NSs. Further, the version dependency information element can also indicate a dependency on another type of constituent. For example, the version dependency information element of a dependent VNFD could indicate dependency of the dependent VNFD on one or more PNFDs and/or one or more nested NSDs. Similarly, the version dependency information element of a dependent PNFD could indicate dependency of the dependent PNFD on one or more VNFDs and/or one or more nested NSDs. Further, the version dependency information element of a dependent VNFD could indicate dependency of the dependent nested NSD on one or more VNFDs and/or one or more PNFDs. Accordingly, the format of the version dependency information element may be regarded as indicating a dependent descriptor in terms of its identifier and one or more other descriptors, on which the dependent constituent depends, in terms of their respective identifiers. The dependent descriptor and the other descriptors may correspond to different constituent types, e.g., may each be a VNFD, PNFD, or nested NSD.

<FIG> shows an example of how the information on version dependency may be indicated as part of a profile of a VNF, PNF, or nested NS. In this case, an information element of the NSD which defines a VNF profile, a PNF profile, or a nested NS profile may be supplemented by a respective attribute, denoted as '"versionDependency" which indicates version dependency information for the respective VNF, PNF, or nested NS. The version dependency information may be provided in an information element as explained in connection with <FIG>. If a VNF profile references a certain VNFD, the information on version dependency indicated by the versionDependency attribute may also apply to other versions of the VNFD which have the same VndfExtlnvariantld. If a PNF profile references a certain PNFD, the information on version dependency indicated by the versionDependency attribute may also apply to other versions of the PNFD which have the same PnfdExtlnvariantld. If a nested NS profile references a certain nested NSD, the information on version dependency indicated by the versionDependency attribute may also apply to other versions of the nested NSD which have the same nsdExtlnvariantld.

<FIG> shows an example of processes in accordance with the illustrated concepts. The processes of <FIG> involve the NFVO <NUM>, the VNFM <NUM>, and the OSS/BSS <NUM>.

In the processes of <FIG>, the OSS/BSS <NUM> sends a message <NUM> for onboarding of a VNF package. The message <NUM> includes a definition of a VNF package. The VNF package includes VNFDs which are potential constituents of NSDs. For example, such VNF package could include the VNFDs illustrated in <FIG>, i.e., the VNFD identified by aaa_2. <NUM>, the VNFD identified by bbb_2. <NUM>, and the VNFD identified by ccc_2. <NUM>, but also the VNFD identified by ccc_1.

The OSS/BSS <NUM> then sends a further message <NUM> for onboarding an NSD. The message <NUM> includes a definition of a NSD, such as the NSD illustrated in <FIG>. The NSD has multiple constituents, which may be VNFDs, PNFDs, or nested NSDs. In the example of <FIG>, it is assumed that the NSD includes VNFDs defined by the VNF package onboarded by message <NUM>.

The OSS/BSS <NUM> then sends a further message <NUM> for invoking an NS LCM operation. The message <NUM> has the form of a request and is thus termed as an "NS LCM operation request", and the NFVO <NUM> is responsible on deciding whether to accept the request. The requested LCM operation can be of various types and for example include instantiation of an NS instance based on the NSD or updating of the NS. The NS LCM operation request may include an overriding descriptor identifier, e.g., an identifier of a VNFD, PNFD, or nested NSD which is intended to substitute a particular constituent of the NSD, which has the same Extlnvariantld as the descriptor identified by the overriding descriptor identifier. If the requested LCM operation corresponds to a change of the current VNF package, such overriding descriptor identifier is typically not present. However, also the request for changing the current VNF package would include at least one VNFD identifier which identifies a VNFD that is subject to the requested change.

In some case, the message <NUM> may also include information indicating overriding information on version dependencies, that shall replace at least a part of the information on version dependency included in the NSD.

As indicated by block <NUM>, the NFVO <NUM> then validates if the requested substitution of the constituent complies with the information on version dependency included in the NSD or, if applicable, with the overriding information on version dependency included in the message <NUM>. For this purpose, the NFVO <NUM> may first check compliance of the substitution with the overriding version dependencies indicated in the message <NUM>. If no overriding version dependency was indicated in the message <NUM>, the NFVO <NUM> may continue by checking if the substitution complies with earlier indicated overriding version dependencies, if no such earlier overriding version dependency is present, eventually check compliance with the version dependencies originally specified in the NSD.

In the example of <FIG>, it is assumed that the requested substitution complies with the available information on version dependency. The NFVO thus decides to accept the request of message <NUM> and proceeds by requesting a corresponding VNF LCM operation by the VNFM <NUM>, as indicated by message <NUM>. The VNF LCM operation may for example result in replacing a VNF instance with another VNF instance, with the other VNF instance corresponding to the substituted version of the VNFD.

<FIG> shows a flowchart for illustrating a procedure for validating an NS LCM operation request based on the information on version dependency. The procedure of <FIG> could for example be applied in block <NUM> of <FIG>.

At <NUM>, the NFVO <NUM> identifies the NSD constituents which have external invariance, by checking the presence of an Extlnvariantld attribute in the respective descriptors. As indicated by <NUM>, then NFVO <NUM> then continues with the following operations for each NSD constituent having external invariance: determining the version dependencies of the NSD constituent and determining the version dependencies of other NSD constituents upon this NSD constituent, as indicated by <NUM>, and checking if a dependent version of the NSD constituent is available, as indicated by <NUM>. Here, it is noted that in this check the availability of a dependent version of the NSD constituent means that there is another version of the NSD constituent available, which has the same Extlnvariantld and complies with the version dependencies of the NSD constituent as indicated by the available, overriding or original, information on version dependency. If this is not the case, the NFVO <NUM> declares the validation of version dependency as failed, as indicated by <NUM>. In response to the failed validation, the NFVO <NUM> declines the requested LCM operation, as indicated by <NUM>.

If at <NUM> a dependent version of the NSD constituent is found to be available, the NFVO <NUM> continues the validation, as indicated by <NUM>. If there are more NSD constituents having external invariance to check, as indicated by <NUM>, the NFVO <NUM> returns to <NUM> to check the dependencies of the next NSD constituent. Otherwise, if there are no more NSD constituents to check, the NFVO <NUM> proceeds by declaring the validation as successful, as indicated by <NUM>. In response to the successful validation, the NFVO <NUM> grants the requested LCM operation, as indicated by <NUM>.

Based on the above principles, and when assuming an NSD and VNFDs as illustrated in <FIG>, exemplary use cases corresponding to NS LCM operation requests schematically illustrated by <FIG>, <FIG> could be handled.

In the example of <FIG>, the requested NS LCM operation involves instantiation of the NS, with the NS LCM operation request indicating an overriding VNFD for the VNFD with identifier ccc_2. The overriding VNFD, with identifier ccc_1. <NUM>, is indicated by a parameter denoted as "overridingVnfdld", which is part of a parameter set denoted as "additionalParamForVnf". It is noted that this parameter set also includes a parameter denoted as "vnfProfileld" (not illustrated) that allows to identify the VNFD to which the overridingVnfdld parameter refers, in this case the VNFD with identifier ccc_2. If the VNFDs with identifier ccc_2. <NUM> and ccc_1. <NUM> have the same VnfdExtlnvariantld, the requested substation of VNFD ccc_2. <NUM> with VNFD ccc_1. <NUM> would be allowable from the perspective of external invariance. However, the version of VNFD ccc_1. <NUM> does not fulfill the version dependencies of aaa_2. <NUM> indicated in the NSD, because VNFD aaa_2. <NUM> depends on the presence of VNFD ccc_2. <NUM> or VNFD ccc_1. <NUM> in the NSD and this requirement is not met by VNFD ccc_1. As a result, the requested instantiation is not allowed by the NFVO <NUM>.

In the example of <FIG>, the requested NS LCM operation involves instantiation of the NS, with the NS LCM operation request indicating an overriding VNFD for the VNFD with identifier ccc_2. <NUM> and overriding version dependency information. The overriding VNFD, with identifier ccc_3. <NUM>, is indicated by a parameter denoted as "overridingVnfdld", which is part of a parameter set denoted as "additionalParamForVnf". It is noted that the parameter set additionalParamForVnf also includes a parameter denoted as "vnfProfileld" (not illustrated) that allows to identify the VNFD to which the overriding overridingVnfdld parameter refers, in this case the VNFD with identifier ccc_2.

The overriding version dependency information is indicated by an information element of the parameter set additionalParamForVnf, which is denoted as "overridingVersionDependency". The overridingVersionDependency information element includes an information element denoted as "versionDependency" and a profileld indicating where this overridingDependency a VNF profile to which the overriding version dependency information applies, i.e., where shall replace an existing version dependency or is to be added to one or more existing version dependencies. It is noted that this profileld may be different from the vnfProfileld indicated in the additionalParamForVnf. The overriding version dependency information indicates that VNFD aaa_2. <NUM> depends on VNFD ccc_2. <NUM>, VNFD ccc_1. <NUM>, and VNFD ccc_3. <NUM>, and that VNFD aaa_2. <NUM> depends on VNFD bbb_2. Accordingly, the overriding version dependency information adds a dependency of VNFD aaa_2. <NUM> on VNFD ccc_3. <NUM> to the information on version dependency originally included in the NSD. If the VNFDs with identifier ccc_3. <NUM> and ccc_2. <NUM> have the same VnfdExtlnvariantld, the requested substation of VNFD ccc_2. <NUM> with VNFD ccc_3. <NUM> would be allowable from the perspective of external invariance. However, the version of VNFD ccc_3. <NUM> does not fulfill the version dependencies of aaa_2. <NUM> indicated in the NSD, because VNFD aaa_2. <NUM> depends on the presence of VNFD ccc_2. <NUM> or VNFD ccc_1. <NUM> in the NSD and this requirement is not met by VNFD ccc_3. On the other hand, since the overriding information on version dependency also indicates a dependency of VNDF aaa_2. <NUM> on VNDF ccc_3. <NUM> and the overriding information on version dependency is used with precedence, the requested instantiation complies with the version dependency requirements and is allowed by the NFVO <NUM>.

In the example of <FIG>, the requested LCM operation involves instantiation of the NS, with the NS LCM operation request indicating a first overriding VNFD for the VNFD with identifier ccc_2. <NUM>, a second overriding VNFD for the VNFD with identifier ccc_2. <NUM>, and overriding version dependency information. The first overriding VNFD, with identifier aaa_3. <NUM>, is indicated by a first parameter denoted as "overridingVnfdld", which is part of a first parameter set denoted as "additionalParamForVnf". It is noted that the first parameter set additionalParamForVnf also includes a parameter denoted as "vnfProfileld" (not illustrated) that allows to identify the VNFD to which the first overridingVnfdld parameter refers, in this case the VNFD with identifier aaa_2. The second overriding VNFD, with identifier ccc_3. <NUM>, is indicated by a second parameter denoted as "overridingVnfdld", which is part of a second parameter set denoted as "additionalParamForVnf". It is noted that the second parameter set additionalParamForVnf also includes a parameter denoted as "vnfProfileld" (not illustrated) that allows to identify the VNFD to which the second overridingVnfdld parameter refers, in this case the VNFD with identifier ccc_2.

The overriding version dependency information is indicated by information elements of the parameter set additionalParamForVnf, which are denoted as "overridingVersionDependency". The overridingVersionDependency information element includes an information element denoted as "versionDependency" and a profileld indicating where this overridingDependency a VNF profile to which the overriding version dependency information applies, i.e., where shall replace an existing version dependency or is to be added to one or more existing version dependencies. It is noted that this profileld may be different from the vnfProfileld indicated in the additionalParamForVnf. The overriding version dependency information indicates that VNFD aaa_3. <NUM> depends on VNFD ccc_2. <NUM>, VNFD ccc_1. <NUM>, and VNFD ccc_3. <NUM>, that VNFD aaa_3. <NUM> depends on VNFD bbb_2. <NUM>, that VNFD aaa_2. <NUM> depends on VNFD ccc_2. <NUM>, VNFD ccc_1. <NUM>, and VNFD ccc_3. <NUM>, and that VNFD aaa_2. <NUM> depends on VNFD bbb_2. Accordingly, the overriding version dependency information adds a dependency of VNFD aaa_3. <NUM> on VNFD ccc_2. <NUM>, VNFD ccc_1. <NUM>, VNFD ccc_3. <NUM>, and VNFD bbb_2. <NUM>, and a dependency of VNDF aaa_2. <NUM> on VNDF ccc_3. <NUM> to the information on version dependency originally included in the NSD. If the VNFDs with identifier aaa_3. <NUM> and aaa_2. <NUM> have the same VnfdExtlnvariantld, the requested substation of VNFD aaa_2. <NUM> with VNFD aaa_3. <NUM> would be allowable from the perspective of external invariance. Similarly, if the VNFDs with identifier ccc_3. <NUM> and ccc_2. <NUM> have the same VnfdExtlnvariantld, the requested substation of VNFD ccc_2. <NUM> with VNFD ccc_3. <NUM> would be allowable from the perspective of external invariance. Further, since the overriding information on version dependency also indicates dependency of VNDF aaa_3. <NUM> on VNDF ccc_3. <NUM> and the overriding information on version dependency is used with precedence, the requested instantiation complies with the version dependency requirements and is allowed by the NFVO <NUM>. It is noted that in the example of <FIG> the overriding information on version dependency maintains the version dependencies of VNFD aaa_2. <NUM> as originally indicated in the NSD, even though VNFD aaa_2. <NUM> is being replaced by VNFD aaa_3. <NUM>, with the addition of a further version dependency on VNDF ccc_3. Maintaining the information related to the replaced VNFD may be useful if in a future NS LCM operation VNFD aaa_3. <NUM> is for some reason re-substituted by VNFD aaa_2.

In the example of <FIG>, it assumed that the NS was already instantiated according to the original NSD, and that NS LCM operation request is directed to an update of the NS with change of the VNF package. The VNF package data to be changed is indicated by a parameter denoted as "changeVnfPackagedata", which includes an identifier of a VNF instance to which the change refers an identifier of a new VNFD to be introduced to the package, namely VNFD ccc_3. In the illustrated example, the update thus involves changing the VNFD ccc_2. <NUM> to VNFD ccc_3. Further, the LCM operation request includes overriding version dependency information.

The overriding version dependency information is indicated by an information element denoted as "overridingVersionDependency". The overriding version dependency information indicates that VNFD aaa_2. <NUM> depends on VNFD ccc_2. <NUM>, VNFD ccc_1. <NUM>, and VNFD ccc_3. <NUM>, and that VNFD aaa_2. <NUM> depends on VNFD bbb_2. Accordingly, the overriding version dependency information adds a dependency of VNFD aaa_2. <NUM> on VNFD ccc_3. <NUM> to the information on version dependency originally included in the NSD. If the VNFDs with identifier ccc_3. <NUM> and ccc_2. <NUM> have the same VnfdExtlnvariantld, the requested substitution of VNFD ccc_2. <NUM> with VNFD ccc_3. <NUM> would be allowable from the perspective of external invariance. However, the version of VNFD ccc_3. <NUM>, which is introduced by the requested update of the VNF package, does not fulfill the version dependencies of aaa_2. <NUM> indicated in the NSD, because VNFD aaa_2. <NUM> depends on the presence of VNFD ccc_2. <NUM> or VNFD ccc_1. <NUM> in the NSD and this requirement is not met by VNFD ccc_3. On the other hand, since the overriding information on version dependency also indicates a dependency of VNDF aaa_2. <NUM> on VNDF ccc_3. <NUM> and the overriding information on version dependency is used with precedence, the requested instantiation complies with the version dependency requirements and is allowed by the NFVO <NUM>.

In the illustrated examples, the NFVO <NUM> thus supports a capability to process information on version dependency between NSD constituents. Such information may be provided as part of an NSD defined via the interface <NUM>. Further, such information on version dependency may be provided via the interface <NUM>, together with an LCM operation request and may then have precedence over the information on version dependency included in the NSD. The NFVO may apply the information on version dependency when executing NS LCM operations that create other instances of the NSD constituents subject to the version dependency or add one or more further constituents to the NS instance, which are subject to the version dependency. As a result, it can be avoided to change the NSD itself if a different descriptor version or different version dependency information for one or more of the NSD constituents is to be used for an NS instance. The interface <NUM>, which as mentioned above may be based on the Os-Ma-nfvo reference point, may thus support providing information on version dependency between NSD constituents. This information may be used to override the version dependencies indicated in the NSD when these constituents are instantiated or added to the NS. When it affects new instances of VNFs, nested NSs or PNFs, the descriptor and version dependency referred via the interface <NUM> will be used for the instantiation. When it affects existing instances of VNFs and nested NSs to be included in the NS, these instances should comply with the descriptors and version dependencies indicated via the interface <NUM>.

It is noted that the information element for indicating the overriding version dependency information in the above examples may itself be provided as part of different types of other information element, depending on the considered NSD constituent and depending on the type of NS LCM operation being requested. For example, the overridingVersionDependency information element could be part of an information element denoted as "VnflnstanceData", which specifies existing VNF instances to be used in an NS instance, part of an information element denoted as "ParamsForVnf", which specifies additional parameters for an NS instance on a per VNF basis, part of an information element denoted as "InstantiateVnfData", which specifies parameters that are needed for VNF instantiation when the OSS/BSS explicitly requests VNF instantiation for a given NS, part of an information element denoted as "NestedNslnstanceData" which specifies an existing nested NS instance to be used in the NS instance, additional parameters on a per nested NS instance basis "ParamsForNestedNs", which specifies additional parameters on a per nested NS instance basis, part of an information element denoted as "AddPnfData", which provides input information about PNF which needs to be added into an NS instance, or part of an information element denoted as "ChangeVnfPkgData", which specifies changes of VNF package data, like in the example of <FIG>. The overridingVersionDependency information element may refer to a profile of a VNF, PNF, or NS, in which the indicated version dependency shall overrides an existing version dependency or is to be added to the existing version dependencies. If the referenced profile contains a versionDependency information element with a dependentConstituent equal to the one indicated in the versionDependency attribute of the overridingVersionDependency information element, the versionDependency of the overridingVersionDependency information element overrides the one in the profile, otherwise it is added to the version dependencies in the profile. The overridingVersionDependency information element may indicate the overriding version dependency information by including a versionDependency information element having a structure as explained in connection with <FIG>.

<FIG> shows a flowchart for illustrating a method, which may be utilized for implementing the illustrated concepts. The method of <FIG> may be used for implementing the illustrated concepts in a node of a communication network, e.g., corresponding to the above-mentioned NFVO <NUM>.

If a processor-based implementation of the node is used, at least some of the steps of the method of <FIG> may be performed and/or controlled by one or more processors of the node. Such node may also include a memory storing program code for implementing at least some of the below described functionalities or steps of the method of <FIG>.

At step <NUM>, a descriptor of a network service is determined. The descriptor includes multiple constituents. The constituents of the descriptor may include at least one descriptor of a virtual network function for implementing the network service, such as the above-mentioned VNFDs. Alternatively or in addition, the constituents of the descriptor may include at least one descriptor of a physical network function for implementing the network service, such as the above-mentioned PNFDs. Alternatively or in addition, the constituents of the descriptor may include at least one descriptor of a nested network service for implementing the network service, such as the above-mentioned nested NSDs. In some scenarios, the descriptor of the network service further includes information identifying one or more of the constituents which are allowed to be replaced with another version of the same constituent. The above-mentioned Extlnvariantld attributes are examples of such information.

At step <NUM>, the descriptor is provided with information on version dependency between at least two of the multiple constituents. The information on version dependency identifies one or more of the constituents of the descriptor, respectively for each of the identified constituents, indicate one or more versions of at least one other of the constituents on which the identified constituent depends. Example formats of indicating such information on version dependency are illustrated in <FIG>. In some scenarios, at least a part of the information on the version dependency may be received via a network service management interface, such as the above-mentioned interface <NUM>.

At step <NUM>, management of the network service may be controlled depending on the information on the version dependency. The management controlled at step <NUM> may include receiving a request for management of the network service and, depending on the information on version dependency, deciding whether to accept the request. Examples of such requests are the above-mentioned NS LCM requests. The management of the network service may include instantiating the network service. Further, the management of the network service may include updating the network service. Such updating of the network service may involve replacing one of the constituents of the descriptor of the network service with another version of the same constituent. Further, such updating of the network service comprises removing one of the constituents from the descriptor of the network service. Further, such updating of the network service may include adding a new constituent to the descriptor of the network service. In some scenarios, the management of the network service may include modifying the information on version dependency, such as explained above for the overriding information on version dependency.

<FIG> shows a block diagram for illustrating functionalities of a node <NUM> for a communication network which operates according to the method of <FIG>. The node <NUM> may for example correspond to or implement the above-mentioned NFVO <NUM>. As illustrated, the node <NUM> may be provided with a module <NUM> configured to determine a descriptor of a network service, such as explained in connection with step <NUM>. Further, the node <NUM> may be provided with a module <NUM> configured to provide the descriptor with information on version dependency of constituents, such as explained in connection with step <NUM>. Further, the node <NUM> may be provided with a module <NUM> configured to control management of the network service, such as explained in connection with step <NUM>.

It is noted that the node <NUM> may include further modules for implementing other functionalities, such as known functionalities of an NFVO of the ETSI NFV framework or management node. Further, it is noted that the modules of the node <NUM> do not necessarily represent a hardware structure of the node <NUM>, but may also correspond to functional elements, e.g., implemented by hardware, software, or a combination thereof.

<FIG> schematically illustrates a processor-based implementation of a node <NUM> for a communication network, which may be used for implementing the above-described concepts. For example, the structures as illustrated in <FIG> may be used for implementing the concepts in the above-mentioned NFVO <NUM> or similar management node.

As illustrated, the node <NUM> may include one or more interfaces <NUM>. The interface(s) <NUM> may be used for communication with one or more other nodes of the communication network, such as the above-mentioned VNFM <NUM> or OSS/BSS <NUM>.

Further, the node <NUM> may include one or more processors <NUM> coupled to the interface(s) <NUM> and a memory <NUM> coupled to the processor(s) <NUM>. By way of example, the interface(s) <NUM>, the processor(s) <NUM>, and the memory <NUM> could be coupled by one or more internal bus systems of the node <NUM>. The memory <NUM> may include a read-only memory (ROM), e.g., a flash ROM, a random-access memory (RAM), e.g., a dynamic RAM (DRAM) or static RAM (SRAM), a mass storage, e.g., a hard disk or solid state disk, or the like. As illustrated, the memory <NUM> may include software <NUM> and/or firmware <NUM>. The memory <NUM> may include suitably configured program code to be executed by the processor(s) <NUM> so as to implement the above-described functionalities for managing a network service, such as explained in connection with <FIG>.

It is to be understood that the structures as illustrated in <FIG> are merely schematic and that the node <NUM> may actually include further components which, for the sake of clarity, have not been illustrated, e.g., further interfaces or further processors. Also, it is to be understood that the memory <NUM> may include further program code for implementing known functionalities of a NFVO or similar management node. According to some embodiments, also a computer program may be provided for implementing functionalities of the node <NUM>, e.g., in the form of a physical medium storing the program code and/or other data to be stored in the memory <NUM> or by making the program code available for download or by streaming.

As can be seen, the concepts as described above may be used for efficiently managing a network service which is provided by cooperation of multiple network functions, such as VNFs or PNFs. In particular, a NSD of the network service may be supplemented with information on version dependency among constituents of the NSD. In this way, substitution of a constituent with another version may be enabled while at the same time avoiding a risk of no longer matching version dependencies. Risks of version incompatibilities that may arise during the life cycle of an NS instance if different versions of some constituent descriptors are used instead of the ones indicated in the NSD may thus be eliminated or at least significantly reduced. Further, functionalities allowing substitution of NSD constituents like provided by the Extlnvariantld attribute may be exploited in an efficient and safe manner. This may also help to support Continuous Integration (CI) and Continuous Delivery or Deployment (CD). The illustrated concepts may help to supports automation of software upgrade and/or update processes, by enabling the management and orchestration system to detect any version incompatibilities during a software upgrade or update. In the case of an error during the upgrade or update process, the claimed solution may also help to determine compatible versions that can be used in a rollback.

Claim 1:
A method of managing a network service in a communication network based on a Network Functions Virtualisation, NFV, framework, the method comprising:
determining a descriptor (<NUM>) of a network service, the descriptor (<NUM>) comprising multiple constituents (<NUM>, <NUM>, <NUM>);
wherein the descriptor (<NUM>) is provided with information on version dependency between at least two of the multiple constituents (<NUM>, <NUM>, <NUM>) and the information on version dependency identifies one or more of the constituents (<NUM>, <NUM>, <NUM>) and, respectively for each of the identified constituents (<NUM>, <NUM>, <NUM>), indicates one or more versions of at least one other of the constituents on which the identified constituent depends.