Patent Description:
As communications networks evolve, the number of services provided also grows. By way of example, the services provided by a communication network have evolved from a simple voice communication at the very beginning to voice and data communication, including texting, email, web browsing, video transmission and others in <NUM> (<NUM>th Generation) wireless networks. A further increase in the number of services can be expected for future <NUM> (<NUM>th Generation) wireless networks. When looking at the wide range of applications and services to be provided by a <NUM> network, it is quite obvious that these cannot effectively be addressed with a traditional approach of having a purpose-built network for each application. This would lead to high cost for networks and devices as well as inefficient use of valuable frequency resources. An operator may have one physical network infrastructure and one pool of frequency bands, which may support many separate virtualized networks, also called network slices. Each network slice may have unique characteristics for meeting the specific requirements of the use case(s) it serves. The key driver for introducing network slicing is business expansion, i.e., improving a network operator's ability to serve other industries, e.g., by offering connectivity services with different network characteristics (performance, security, robustness, and complexity). Network slicing may be applied to a <NUM> network, e.g., based on the LTE (Long Term Evolution) technology specified by 3GPP, or to a <NUM> network, e.g., based on the NR (New Radio) technology currently developed by 3GPP.

Network slicing typically involves creating logically separated partitions of the network, which may address different business purposes. These network slices are logically separated to a degree that they can be regarded and managed as networks of their own. Network slices can be associated with different slice tenants, namely entities that provide services to the end user via the network slice. Examples of slice tenants could be:.

It is also common to associate a Service Level Agreement (SLA) to each network slice. Such SLA may for example indicate the treatment to which services provided within the network slice should be subjected.

A current working assumption for network slicing is that there will be one shared Radio Access Network (RAN) infrastructure that will connect to several Core Network (CN) instances, such as Evolved Packet Core (EPC) instances (one EPC instance per network slice) or a further EPC evolution.

When using one physical RAN used for multiple network slices, two aspects should be taken into account. The first aspect is that network slicing should make it possible to support several different virtual networks on the same physical network infrastructure in order to reduce costs and energy consumption compared to deploying separate physical networks for the different use cases or business scenarios. In order to exploit this benefit fully, it is required that the slicing concept allows for efficient usage of common resources such as radio resources and infrastructure, and transport links between the slices such as fronthaul and backhaul. The second aspect is that mechanisms are required to protect common channels or resources used for UEs (user equipments) accessing the system so that congestion in one slice does not have a negative impact on another slice (often called slice isolation).

In view of slice isolation, it may be necessary to implement resource isolation in RAN, which may be achieved by resource partitioning. RAN resource partitioning may involve dividing up the full radio resource allocation into maximum of six RAN resource partitions (the number of RAN resource partitions may be extended to <NUM> in the future). The operator will be given parameters to control whether the RAN resource partition is based on Public Land Mobile Network (PLMN) or Subscriber Profile Identity (SPID), and then control how many resources each RAN resource partition shall be given. A RAN resource partition may include multiple cells and multiple access nodes, e.g., eNBs of the LTE technology or <NUM> access nodes.

Management of RAN partitions may be based on an abstract representation of the RAN, including for example coverage areas of cells or access nodes. A corresponding abstract topology representation of the RAN may be created manually and then be stored in a NMS (Network Management System) which is responsible for configuration and instantiation of the network slices.

At instantiation of a network slice, a customer may request a certain radio coverage. The NMS may determine the required radio coverage and identify which network elements (e.g., cells or access nodes) of the abstract RAN topology are needed to meet the customer's coverage requirement.

RANs are subject to periodic reconfigurations, for example to add or remove a cell or access node from the RAN. In relation to changes in radio deployment, there may be many driving factors for adding or removing a cell from the RAN although the primary reason is changing demands on the network capacity. Assuming the reason for change is capacity growth, as an existing cell experiences growth in its traffic load, its effective coverage area decreases. If additional cells are not deployed to address this increase in demand on network capacity, "white spots" in network coverage will appear. Such white spots often result in breaches of SLAs.

In an operator's process, it is usually the radio design/optimization team who will trigger a change in radio deployment though the addition or removal of a cell from the RAN, via interaction with operation supports systems for the required re-configuration of the RAN. In order to meet the evolving requirements on network management in a <NUM> context, there is now a need to be able to deploy and manage logical networks (i.e. network slices) for a particular business purpose. This deployment must be able to tolerate changes to the radio deployment throughout the complete lifecycle of a network slice, for example because of the potential impact on a network slice arising from the addition or removal of a cell from the RAN.

There is known a document related to slicing architecture for wireless communications network, namely <CIT>. However, devices and operations as in the invention now to be described are neither disclosed nor suggested in this document.

Accordingly, there is a need for techniques which allow for efficient management of network slices of the RAN with respect to configurations of RAN resource partitions of the network slices that allows for the addition and removal of cells from the RAN.

There is provided a method of managing network slices in a communications network. The method comprises a domain manager of a RAN determining a change in cell composition of the RAN, wherein the change in cell composition comprises an addition of a new cell to the RAN or a removal of a cell from the RAN. The method further comprises the domain manager determining neighbor cells within the RAN affected by the change in cell composition of the RAN. The method further comprises the domain manager determining a set of RAN resource partitions affected by the change in cell composition of the RAN. The method further comprises the domain manager adapting the configuration of RAN resource partitions of the set of RAN resource partitions by introducing changes corresponding to the change in cell composition of the RAN. The configuration of a RAN resource partition defines the network elements of the RAN that are assigned to the RAN resource partition of a network slice.

There is also provided a domain manager configured to perform any of the methods described herein including the method set out in the preceding paragraph. Hence, there is also provided a domain manager for a RAN of a communications network. The domain manager is configured to determine a change in cell composition of the RAN, wherein the change in cell composition comprises an addition of a new cell to the RAN or a removal of a cell from the RAN, and to determine neighbor cells within the RAN affected by the change in cell composition of the RAN. The domain manager is also configured to determine a set of RAN resource partitions affected by the change in cell composition of the RAN. The domain manager is also configured to adapt the configuration of RAN resource partitions of the set of RAN resource partitions by introducing changes corresponding to the change in cell composition of the RAN. A configuration of a RAN resource partition defines the network elements of the RAN that are assigned to the RAN resource partition of a network slice.

There is also provided a computer program comprising instructions which, when executed on processing circuitry, cause the processing circuitry to carry out the method described above.

In the following, concepts in accordance with exemplary embodiments will be explained in more detail and with reference to the accompanying drawings. The illustrated embodiments relate to management of network slices in a wireless communication network. Specifically, the embodiments relate to concepts for adapting and optimizing the configurations of RAN resource partitions of network slices that account for changes in cell composition of the RAN, for example the addition or removal of a cell. The wireless communication network may be, for example, based on a <NUM> technology, such as the LTE technology specified by 3GPP, or a <NUM> radio technology, e.g., the NR technology currently developed by 3GPP.

In the illustrated examples, configurations of RAN resource partitions may be automatically adapted by introducing changes corresponding to the change in cell composition of the RAN. The change in cell composition of the RAN may correspond to the addition of a new cell to the RAN or to the removal of an unwanted cell from the RAN.

A new cell may be added to the RAN because existing cells have experienced a growth in traffic load such that their effective coverage area decreases thereby risking "white spots" in network coverage appearing. Configurations of the RAN resource partitions may be automatically adapted by introducing changes corresponding to the addition of a new cell to the RAN by assigning a network element of the new cell to the configurations of RAN resource partitions to which neighbor cells are assigned.

An unwanted cell is merely a cell that is to be or has been removed from a RAN, for whatever reason. The removal of the unwanted cell may be a physical removal, or it may be just a functional removal (for example, blocking the cell from use by the RAN). For example, the unwanted cell may be removed from the RAN because there is good or adequate coverage provided by neighboring cells (i.e. the unwanted cell may still carry traffic because it is present and available for use but, by removing the unwanted cell, the traffic will be taken over by the neighboring cells). Alternatively, the unwanted cell may be removed from the RAN because it has not been carrying any traffic over a period of time or the amount of traffic carried by the unwanted cell is below certain threshold. Configurations of the RAN resource partitions may be automatically adapted by introducing changes corresponding to the removal of an unwanted cell from the RAN by assigning network elements of neighbor cells to the configuration of one or more RAN resource partitions to which an unwanted cell was previously assigned.

After adapting the configurations of the RAN resource partitions, the network slices may then be optimized on the basis of reports indicating an amount of network slice traffic handled by network elements (e.g., cells, of the RAN resource partitions used by the network slices). Cells or other network elements for which the reports indicate that there was no network slice traffic in a certain observation time window may be removed from the configuration of the RAN resource partition for that network slice. In this way, radio coverage of RAN resource partitions may be adjusted to include only those network elements which are actually required, e.g., to meet a customer request, but without seeing a breach in a SLA for that network slice. An initial oversize of the RAN resource partition upon adaptation to account for the change in cell composition in the RAN is thus not critical, which in turn facilitates initial configuration of the RAN resource partition. The subsequent optimization of the RAN network performed on the basis of the reports that indicate network traffic sees the oversized RAN resource partitions reduced in size to an optimized configuration.

<FIG> schematically illustrates network slices as used in the illustrated concepts. More specifically, <FIG> illustrates a RAN <NUM> of the wireless communication network, a first CN instance <NUM> of the wireless communication network, and a second CN instance <NUM> of the wireless communication network. As illustrated, the RAN <NUM> includes multiple network elements <NUM>, <NUM>, <NUM>. These network elements may correspond to cells and/or access nodes serving one or more cells. The first CN instance <NUM> includes CN nodes <NUM>, <NUM>, and the second CN instance <NUM> includes CN nodes <NUM>, <NUM>. The CN nodes <NUM>, <NUM>, <NUM>, <NUM> of the respective CN instance <NUM>, <NUM> may for example include one or more gateways (GWs) <NUM>, <NUM>, such as an SGW (Serving Gateway) or PGW (Packet Data Gateway) of the EPC. Further, the CN nodes <NUM>, <NUM>, <NUM>, <NUM> may include one or more mobility management nodes, such as an MME (Mobility Management Entity) of the EPC. However, it is noted that the CN instances could additionally or alternatively also include gateways or mobility management nodes of a <NUM> technology, e.g., the NR technology.

The first CN instance <NUM> is assumed to be assigned to a first network slice, referred to as "Slice <NUM>". The second CN instance <NUM> is assumed to be assigned to a second network slice, referred to as "Slice <NUM>". Further, <FIG> also illustrates an exemplary UE <NUM> receiving or sending traffic via Slice <NUM> and an exemplary UE <NUM> receiving or sending traffic via Slice <NUM>. Accordingly, the example of <FIG> assumes that there is a one to one mapping between network slice and CN instance. However, it is noted that the concepts explained herein would also be applicable to scenarios where multiple network slices are supported by the same CN instance. Further, it is noted that the different CN instances <NUM>, <NUM> do not necessarily need to be implemented by separate physical hardware elements, but could also be implemented on the basis of different virtual CN nodes implemented by the same physical hardware element. For example, a GW <NUM> of the CN instance <NUM> and a GW <NUM> of the CN instance <NUM> could be implemented as virtual nodes on the same physical hardware element. Similarly, an MME <NUM> of the CN instance <NUM> and an MME <NUM> of the CN instance <NUM> could be implemented as virtual nodes on the same physical hardware element.

In the example of <FIG>, the network slices may be used to support different services. For example, Slice <NUM> could be a Mobile Broadband slice, while Slice <NUM> could be a Machine Type Communication network slice. However, various other kinds of services could be supported as well. The network slices could also be associated with different tenants, e.g., different customers of an operator of the wireless communication network. Each of these different customers could have an individual SLA with the operator. The SLA could for example specify radio coverage offered to the customer.

As further illustrated, the RAN <NUM> of the wireless communication network is shared by both network slices. For this purpose, a corresponding RAN resource partition is configured for each of the network slices. Each of the network elements <NUM>, <NUM>, <NUM> of the RAN <NUM> may be assigned to the configuration of one of the RAN resource partitions, to the configurations of both RAN resource partitions, or to none of the RAN resource partitions.

<FIG> schematically illustrates a management architecture which may be used for implementing the illustrated concepts. As illustrated, the management architecture includes an NMS <NUM>, a Radio Domain Manager (RDM) <NUM>, and multiple RAN nodes <NUM>, <NUM>, <NUM> controlled by the RDM <NUM>. The RAN nodes <NUM>, <NUM>, <NUM> may for example include one or more access nodes which each serve one or more cells of the wireless communication network. Further, the RAN nodes <NUM>, <NUM>, <NUM> may include one or more control nodes, such as a Radio Control Function (RCF) of the NR technology. Each of the RAN nodes <NUM>, <NUM>, <NUM> may thus control one more cells of the RAN <NUM>. Each of these cells may be assigned to the configuration of a certain RAN resource partition. The RAN nodes <NUM>, <NUM>, <NUM> may thus control one or more cells, i.e., network elements of the RAN resource partition. Further, if one of the RAN nodes <NUM>, <NUM>, <NUM> controls a cell of the RAN resource partition, this RAN node <NUM>, <NUM>, <NUM> will also constitute a network element assigned to the configuration of the RAN resource partition.

For managing the network slices configured in the wireless communication network, the NMS <NUM> includes a slice manager <NUM>. The slice manager <NUM> may for example be responsible for network slice lifecycle management. In an initial phase, network slice lifecycle management may include, for example, preparation of a network slice, configuration of the network slice, instantiation of the network slice, and activation of the network slice. In a subsequent phase, network slice lifecycle management may include supervision of usage of the network slice and related reporting. This supervision and reporting may be used as a basis for reconfiguring the network slice, e.g., by scaling or upgrading. In a final phase, network slice lifecycle management may include deactivation and termination of the network slice.

For managing the RAN resource partitions, the RDM <NUM> includes a RAN partition manager <NUM>. The RAN partition manager <NUM> may be, for example, responsible for RAN resource partition lifecycle management. In an initial phase, RAN resource partition lifecycle management may include, for example, preparation of a RAN resource partition for a network slice, configuration of the RAN resource partition, instantiation of the RAN resource partition, and activation of the RAN resource partition. In a subsequent phase, RAN resource partition lifecycle management may include supervision of usage of the RAN resource partition and related reporting, e.g., to the NMS <NUM>. As further explained below, the supervision may include adapting the configurations of RAN resource partitions to account for changes in cell composition in the RAN <NUM>. The supervision may also include receiving and analyzing reports from the RAN nodes <NUM>, <NUM>, <NUM>. The reports may be used for optimization of the configurations of the RAN resource partitions. In a final phase, RAN resource partition lifecycle management may include deactivation and termination of the RAN resource partitions. In the following, an example of adapting the configurations of RAN resource partitions and optimizing the configurations of RAN resource partitions will be explained in more detail with reference to <FIG>.

The example of <FIG> involves the RDM <NUM> and the RAN nodes <NUM>, <NUM>, <NUM>. Functionalities of the RDM <NUM> as explained in connection with <FIG> may for example be implemented by the RAN partition manager <NUM>.

In an initial phase not shown in <FIG>, the RDM <NUM> creates RAN resource partitions, e.g., by determining a configuration for each RAN resource partition that defines which cells are included in each RAN resource partition. The RAN resource partitions are assigned to certain respective network slices, e.g., one to each of the above-mentioned network slices although multiple network slices may use the same RAN resource partition. Creation of the RAN resource partitions may be performed automatically, but may also involve manual input from an operator. In the example of <FIG>, it is assumed that the configurations of the RAN resource partitions include one or more cells controlled by the RAN node <NUM>, one or more cells controlled by the RAN node <NUM>, and one or more cells controlled by the RAN node <NUM>.

By sending management messages to the RAN nodes <NUM>, <NUM>, <NUM>, the RDM <NUM> instructs the RAN nodes <NUM>, <NUM>, <NUM> to associate these cells with configurations of the RAN resource partitions. The respective RAN node <NUM>, <NUM>, <NUM> may store locally that the cells indicated by the received management message are assigned to the configuration of the RAN resource partition indicated in the message and that the RAN node <NUM>, <NUM>, <NUM> itself is assigned to the configuration of the RAN resource partition. For this purpose, the RAN resource partition may be defined by a partition name and/or partition identifier. The partition identifier may be unique on the level of the respective RAN node <NUM>, <NUM>, <NUM>, while the partition name may be unique across all RAN nodes <NUM>, <NUM>, <NUM> controlled by the RDM <NUM>.

<FIG> shows the messages arising due to a change in cell composition of the RAN <NUM> that result in an adaptation of the configurations of the RAN resource partitions to account for the removal of an unwanted cell from the RAN <NUM>. The RDM <NUM> sends further management messages (labeled <NUM>, <NUM> and <NUM> in <FIG>) to the RAN nodes <NUM>, <NUM>, <NUM>, by which the RDM <NUM> instructs the RAN nodes <NUM>, <NUM>, <NUM> to associate network elements of cells with the configuration of a RAN resource partition. In this example, the resource partition is a resource partition to which the unwanted cell was assigned at the time of its removal from the RAN <NUM>.

As illustrated by blocks <NUM>, <NUM>, <NUM>, the RAN nodes <NUM>, <NUM>, <NUM> each accomplish a corresponding local association of one or more network elements (NEs) with the configuration of the RAN resource partition. The respective RAN node <NUM>, <NUM>, <NUM> may locally store that the cells indicated by the received management message are assigned to the configuration of the RAN resource partition and that the RAN node <NUM>, <NUM>, <NUM> itself is assigned to the configuration of the RAN resource partition.

Subsequently, the RAN nodes <NUM>, <NUM>, <NUM> each send one or more reports <NUM>, <NUM>, <NUM> to the RDM <NUM>. For each cell of the RAN resource partition, the reports <NUM>, <NUM>, <NUM> indicate an amount of traffic of the network slices of the RAN <NUM>. That is to say, the amount of traffic of the network slices is reported on a cell level. However, it is noted that in some scenarios it is also possible that the reporting is omitted for some of the cells. For example, for some of the cells, the configuration of a RAN resource partition could indicate that the cells should be excluded from any optimization, so that reporting is not required for these cells.

The reports may indicate the amount of traffic in terms of one or more counter values. For example, a counter indicating a number of used uplink (UL) physical resource blocks and a counter indicating a number of used downlink (DL) physical resource blocks may be used for this purpose. Accordingly, the reports <NUM>, <NUM>, <NUM> may distinguish between UL traffic and DL traffic. However, it would also be possible that the reports <NUM>, <NUM>, <NUM> indicate an overall amount of the traffic, e.g., the sum of UL traffic and DL traffic. The reports <NUM>, <NUM>, <NUM> may identify the RAN resource partition, e.g., in terms of the partition identifier and/or partition name.

On the basis of the reports, the RDM <NUM> then optimizes the configurations of the RAN resource partitions as, for example, indicated by block <NUM>. Specifically, the RDM <NUM> decides on the basis of the amount of the traffic reported for a given cell whether to remove the cell from the configuration of a RAN resource partition. If the amount of traffic in the observation time window is zero or below a threshold, it is likely that the cell is actually not required to provide the required radio coverage for a RAN resource partition, and the RDM <NUM> removes the cell from the configuration of the RAN resource partition.

In the example of <FIG>, it is assumed that the report <NUM> from the RAN node <NUM> indicated that the amount of traffic was zero for some of the cells controlled by the RAN node <NUM> for a RAN resource partition, and that the RDM <NUM> thus decided to remove these cells from the configuration of the RAN resource partition. In order to effect a corresponding adaptation of the configuration of the RAN resource partition, the RDM <NUM> sends a management message <NUM> to the RAN node <NUM> for modifying the configuration of the RAN resource partition. As indicated by block <NUM>, in response to receiving the management message <NUM>, the RAN node <NUM> locally removes the cells indicated by the management message <NUM> from the configuration of the RAN resource partition, i.e., releases the assignment of the removed cells to the configuration of the RAN resource partition.

In some scenarios, the removal of the cell(s) from the configuration of a RAN resource partition may also result in removal of all cells controlled by the RAN node <NUM> from the configuration of the RAN resource partition. That is to say, after removal of the cell(s), no cells controlled by the RAN node <NUM> remain in the configuration of the RAN resource partition. In such a situation, the RDM <NUM> may also decide to remove the RAN node <NUM> from the configuration of the RAN resource partition and indicate this decision in the management message <NUM>. Accordingly, based on the reports <NUM>, <NUM>, <NUM>, the RDM <NUM> may decide which cell(s) and/or RAN node <NUM>, <NUM>, <NUM> are to be removed from the configuration of a RAN resource partition.

<FIG> shows a flowchart for illustrating a method <NUM> of managing network slices in a communications network, for example a wireless communications network. The method <NUM> of <FIG> may be utilized for implementing the illustrated concepts in a domain manager of a RAN <NUM> of a wireless communication network, such as the above-mentioned RDM <NUM>. If a processing circuitry-based implementation of the domain manager is used, the steps of the method <NUM> may be performed and/or controlled by processing circuitry of a device implementing the domain manager. Such device may also include a memory storing program code for implementing the below described functionalities or steps of the method <NUM>. This is also true for the other methods <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> that will be described below.

At step <NUM>, the domain manager determines a change in cell composition of the RAN <NUM>. At step <NUM>, the domain manager determines neighbor cells within the RAN <NUM> affected by the change in cell composition of the RAN <NUM>. At step <NUM>, the domain manager determines a set of RAN resource partitions affected by the change in cell composition of the RAN <NUM>. At step <NUM>, the domain manager adapts the configurations of RAN resource partitions of the set of RAN resource partitions by introducing changes corresponding to the change in cell composition of the RAN <NUM>.

As described above, step <NUM> sees the domain manager determine a change in cell composition of the RAN <NUM>. As already noted, the change in cell composition may be the addition of a new cell to the RAN <NUM> or may be the removal of an unwanted cell from the RAN <NUM>. The cell composition defines the cells of the RAN <NUM>, i.e. the coverage subareas of the RAN <NUM>. The domain manager may determine a change in cell composition by receiving a trigger from a cell administration function of the domain manager. The change in cell composition of the RAN <NUM> may be planned (e.g. a change in cell composition that is being planned for instantiation and activation at a later time) or may have already been implemented (e.g. a change in cell composition that has already been instantiated or activated). That is, a notification may be issued by the cell administration function before or after a change in the cell composition of the RAN <NUM> is activated. In the following description, it is assumed that the change in cell composition of the RAN <NUM> has already been implemented, although it will be understood that the disclosure also covers embodiments where the change in cell composition of the RAN <NUM> has yet to be implemented.

As described above, step <NUM> sees the domain manager determine neighbor cells within the RAN <NUM> affected by the change in cell composition of the RAN <NUM>. This may comprise the domain manager determining a set of cells of the RAN that are neighbor cells of a new cell added to the RAN <NUM> or a set of cells of the RAN that were neighbor cells of the unwanted cell removed from the RAN <NUM>.

As described above, step <NUM> sees the domain manager determining a set of RAN resource partitions affected by the change in cell composition of the RAN <NUM>. A RAN resource partition may be affected because an unwanted cell is or was assigned to the configuration of the RAN resource partition and hence the unwanted cell will be or is lost from the configuration of that RAN resource partition. A RAN resource partition may be affected because a new cell is added to the RAN <NUM> that is then available to be assigned to the configuration of a RAN resource partition.

As described above, step <NUM> sees the domain manager adapt the configurations of RAN resource partitions of the set of RAN resource partitions by introducing changes corresponding to the change in cell composition of the RAN. A configuration of a RAN resource partition defines the network elements of the RAN <NUM> that are assigned to the RAN resource partition that is used by a network slice. The network elements assigned to the configuration of a RAN resource partition may include access nodes serving the cells, such as the above mentioned RAN nodes <NUM>, <NUM>, <NUM>. The domain manager may send one or more management messages to RAN nodes. Any such management message(s) may be used to indicate the adapted configuration of one or more RAN resource partitions to the RAN node, like explained for the management messages <NUM> of <FIG>. Adapting the configuration of RAN resource partitions by introducing changes corresponding to the change in cell composition of the RAN <NUM> may include removing an unwanted cell from the configuration of a RAN resource partition or may comprise adding a new cell to the configuration of a RAN resource partition.

Where step <NUM> sees the domain manager determine the addition of a new cell to the RAN <NUM>, step <NUM> may then see the domain manager determine a set of cells of the RAN <NUM> that are neighbor cells of the new cell. The domain manager may continue to determine the set of cells of the RAN <NUM> that are neighbor cells of the new cell until the set contains at least a minimum number of neighbor cells, for example two, three, four or more neighbor cells. Step <NUM> may then see the domain manager determining a set of RAN resource partitions affected by the change in cell composition of the RAN <NUM> because the new cell added to the RAN <NUM> that is then available to be assigned to the RAN resource partition. The domain manager may determine a set of RAN resource partitions that includes RAN resource partitions to which neighbor cells are assigned. The domain manager may continue to determine a set of RAN resource partitions until the set includes at least a minimum number of RAN resource partitions to which the neighbor cells are assigned, for example two, three, four or more. The domain manager may determine a set of RAN resource partitions that includes all the RAN resource partitions to which some of the neighbor cells of the set of neighbor cells are assigned. The domain manager may determine a set of RAN resource partitions that includes some of the RAN resource partitions to which all the neighbor cells of the set of neighbor cells are assigned. As a further alternative, the domain manager may determine a set of RAN resource partitions affected by the change in cell composition of the RAN comprises the domain manager determining a set of RAN resource partitions that includes all the RAN resource partitions to which all the neighbor cells of the set of neighbor cells are assigned.

Where step <NUM> sees the domain manager determine a change in cell composition of the RAN <NUM> corresponding to the addition of a new cell to the RAN <NUM>, step <NUM> may then comprise the domain manager adapting the configurations of RAN resource partitions by assigning a network element of the new cell to the configurations of the RAN resource partitions. Advantageously, this allows many RAN resource partitions (and hence the network slices that use these RAN resource partitions) to make use of the new cell added to the RAN <NUM>. The domain manager may adapt the configuration of each RAN resource partition of the set of RAN resource partitions by assigning a network element of the new cell to the configuration of each RAN resource partition in the set of RAN resource partitions.

Where step <NUM> sees the domain manager determine a change in cell composition of the RAN <NUM> corresponding to the removal of an unwanted cell from the RAN <NUM>, step <NUM> may then see the domain manager determine a set of cells of the RAN <NUM> that are neighbor cells of the unwanted cell. The domain manager may continue to determine the set of cells of the RAN <NUM> that are neighbor cells of the unwanted cell until the set contains at least a minimum number of neighbor cells, for example two, three, four or more neighbor cells. The domain manager may determine a set of all the cells of the RAN <NUM> that are neighbor cells of the unwanted cell.

Where step <NUM> sees the domain manager determine a change in cell composition of the RAN <NUM> corresponding to the removal of an unwanted cell from the RAN <NUM>, step <NUM> may then see the domain manager determine a set of RAN resource partitions that includes RAN resource partitions of the unwanted cell. For example, the RAN resource partitions may be RAN resource partitions to which the unwanted cell is assigned or was assigned at the time of its removal. The domain manager may continue to determine a set of RAN resource partitions until the set includes at least a minimum number of RAN resource partitions, for example two, three, four or more. The domain manager may determine a set of RAN resource partitions that includes all the RAN resource partitions of the unwanted cell.

Where step <NUM> sees the domain manager determine a change in cell composition of the RAN <NUM> corresponding to the removal of an unwanted cell from the RAN <NUM>, step <NUM> may then see the domain manager adapt the configurations of RAN resource partitions by assigning a network element of neighbor cells of the set of neighbor cells to the configurations of the RAN resource partitions. The domain manager may adapt the configurations of all the RAN resource partitions in the set of RAN resource partitions by assigning a network element of neighbor cells of the set of neighbor cells to the configurations of the RAN resource partitions. The domain manager may adapt the configurations of RAN resource partitions by assigning a network element of all the neighbor cells of the set of neighbor cells to the configurations of the RAN resource partitions. As a further alternative, the domain manager may adapt the configuration of each RAN resource partition of the set of RAN resource partitions by assigning a network element of each neighbor cell of the set of neighbor cells to the configuration of each RAN resource partition. Advantageously, this provides many new network elements to the RAN resource partition (and hence the network slice that use the RAN resource partition) to use in place of the lost network element from the unwanted cell removed from the RAN <NUM>.

<FIG> shows a flowchart for illustrating a method <NUM> of managing network slices in a communications network corresponding to that shown in <FIG>, but illustrates the differences in managing addition and removal of a cell of the RAN <NUM>. Thus, the description of <FIG> above applies to <FIG> also.

At step <NUM>, the domain manager determines a change in cell composition of the RAN <NUM>, for example by receiving a notification (e.g. trigger) from a cell administration function. At step <NUM>, the domain manager determines whether the change in cell composition of the RAN <NUM> corresponds to the addition of a new cell to the RAN <NUM> or the removal of an unwanted cell from the RAN <NUM>. This may be indicated by the notification received from the cell administration function.

If the determination at step <NUM> indicates an addition of a new cell to the RAN <NUM>, the method proceeds through steps <NUM>, <NUM>, <NUM> as will be described below. In the alternative, if the determination at step <NUM> indicates the removal of an unwanted cell from the RAN <NUM>, the method proceeds through steps <NUM>, <NUM>, <NUM> as will be described below.

When the addition of a new cell to the RAN <NUM> has been determined, the domain manager determines a set of cells of the RAN <NUM> that are neighbor cells of the new cell at step <NUM>. At step <NUM>, the domain manager determines a set of RAN resource partitions that includes RAN resource partitions to which neighbor cells of the set of neighbor cells are assigned. At step <NUM>, the domain manager adapts the configuration of RAN resource partitions by assigning a network element of the new cell to the configuration of the RAN resource partitions.

When the removal of an unwanted cell from the RAN <NUM> has been determined, the domain manager determines a set of cells of the RAN <NUM> that are neighbor cells of the unwanted cell at step <NUM>. At step <NUM>, the domain manager determines a set of RAN resource partitions that includes RAN resource partitions of the unwanted cell. For example, the resource partitions may be the RAN resource partitions to which the unwanted cell was assigned at the time of its removal from the RAN <NUM>. At step <NUM>, the domain manager adapts the configuration of RAN resource partitions by assigning a network element of the set of neighbor cells to the configuration of the RAN resource partitions.

<FIG> shows a method <NUM> of managing network slices in a communications in response to a change in cell composition of the RAN <NUM>. As will be seen from <FIG>, the method can be essentially viewed as comprising two parts.

At step <NUM>, the configurations of RAN resource partitions are adapted in response to the change in cell composition of the RAN <NUM>. Step <NUM> may, for example, comprise the method of <FIG> or <FIG>.

At step <NUM>, the configurations of RAN resource partitions are optimized (i.e. adapted) in response to reports of the amount of traffic seen by cells within the network slices of the RAN <NUM>. Step <NUM> may comprise the domain manager receiving reports indicating an amount of traffic of the network slice handled by a network element assigned to the configuration of a RAN resource partition in an observation time window. The observation time window may be configurable. Based on the reports, the domain manager may adapt the configuration of the RAN resource partition by removing the network element from the configuration of the RAN resource partition. The network element removed from the RAN resource partition may be a network element of a new cell added to the RAN <NUM>. Alternatively, the network element removed from the RAN resource partition may be a network element added to the RAN resource partition that is a network element of a neighbor cell of an unwanted cell removed from the RAN <NUM>. Also, the network element removed from the RAN resource partition may be an existing network element present in the RAN resource partition before the change in cell composition of the RAN <NUM>.

For example, by adding a network element of a new cell to the configurations of many RAN resource partitions, it may be found that some network slices make little if any use of the new cell. These network slices may see the network element removed from the configuration of the RAN resource partition the network slice uses. Alternatively, adding a network element of a new cell to the configuration of a RAN resource partition may result in a substantial reduction on the network traffic passing through an existing network element of the RAN resource partition. In this case, the existing network element may be removed from the configuration of the RAN resource partition, which may make it available to be added to the configuration of another RAN resource partition that requires an additional network element. Nonetheless, adding the new cell to the configurations of many RAN resource partitions is advantageous as it allows the domain manager to determine an optimum allocation of the new cell from the reports it receives. That is, advantageously, network slices making frequent use of the new cell may retain its network element in their configurations, while network slices making infrequent use of the new cell may drop its network element from their configurations.

As a further example, by adding the network elements of many neighbor cells to the configuration of the RAN resource partition of an unwanted cell removed from the RAN <NUM>, it may be found that the network slice makes little if any use of some of these network elements. These underused network elements may then be removed from the configuration of the RAN resource partition that the network slice uses. Providing the network slice that has lost the unwanted cell with many network elements from neighbor cells advantageously allows the domain manager to determine an optimum allocation of the network elements from the neighbor cells from the reports it receives. That is, advantageously, the neighbor cells frequently used by the network slice may be retained in the configuration of the RAN resource partition, while the neighbor cells infrequently used by the network slice may be dropped from the configuration of the RAN resource partition. In addition, adding network elements from the neighbor cells to the configuration of the RAN resource partition may result in a substantial reduction on the network traffic passing through an existing network element of the RAN resource partition. In this case, the existing network element may be removed from the configuration of the RAN resource partition, which may make it available to be added to the configuration of another RAN resource partition that requires an additional network element.

Thus, advantageously, a change in cell composition of the RAN <NUM>, either because of the addition on a new cell or the removal of an unwanted cell, results in the domain manager adapting the configurations of RAN resource partitions in a way that ensures the RAN <NUM> is configured in a flexible way. This initial adaptation in combination with the ongoing adaptation of the configuration of a RAN resource partition by removing network elements as a result of monitoring the amount of traffic handled by the network elements of the RAN is in-line with the self-learning requirements for <NUM>.

Step <NUM> may comprise the domain manager removing the network element from the configuration of the RAN resource partition when the reports indicate that the amount of traffic of the network slice handled by the network element for that RAN resource partition is below a threshold value. The threshold value may be configurable. The domain manager may remove the network element when the reports indicate that the amount of the traffic handled by the network element is zero. The reports may comprise an identifier of the RAN resource partition.

In step <NUM>, the network element removed by the domain manager may comprise a cell and an access node serving the cell. The domain manager may send a management message to the access node serving the cell, the management message causing the access node to locally release an assignment of the cell to the configuration of the RAN resource partition. Step <NUM> may comprise the domain manager removing the access node from the configuration of the RAN resource partition when removing the cell results in the access node no longer serving any cells in the RAN resource partition. In response to removing the access node from the configuration of the RAN resource partition, the domain manager may send a management message to the access node, the management message causing the access node to locally release an assignment of the access node to the configuration of the RAN resource partition.

Step <NUM> of <FIG> that comprises adapting configurations of RAN resource partitions will now be described in more detail with reference to <FIG>.

A method <NUM> of managing network slices in a communications network is shown in <FIG>. Step <NUM> comprises the method <NUM> set out in <FIG>, and so will not be described again. It will be remembered that the method <NUM> ends with the domain manager either adapting the configurations of RAN resource partitions to include a new cell added to the RAN <NUM> as shown at step <NUM> or adapting the configurations of RAN resource partitions to include neighbor cells of the unwanted cell removed from the RAN <NUM> as shown at step <NUM>.

Then, at step <NUM>, the domain manager implements the RAN <NUM> with the adapted configurations of the RAN resource partitions, i.e. the RAN <NUM> with the adapted configurations of the RAN resource partitions is instantiated and activated.

Next, at step <NUM>, the domain manager receives reports. As explained for the reports <NUM>, <NUM>, <NUM> of <FIG>, the reports may be received from one or more RAN nodes <NUM>, <NUM>, <NUM>. The reports indicate, for at least one of the network elements assigned to a RAN resource partition, an amount of traffic of the network slice handled by the network element in an observation time window. As a general rule, a longer observation time window may be selected in scenarios where the traffic of a network slice is expected to occur only sparsely, e.g., when a network slice is used to provide a service in an event location which is used on a weekly basis. A shorter observation time window may be sufficient if the traffic of a network slice is expected to occur more densely, e.g., when a network slice is used to provide a vehicle diagnostic service in an area of a heavily used road. The reports may include an identifier of the RAN resource partition, such as the above-mentioned partition name and/or partition identifier.

At step <NUM>, the domain manager adapts the configuration of a RAN resource partition by removing one or more of the network elements from the configuration of the RAN resource partition. This is accomplished based on the reports received at step <NUM>. The domain manager may remove those network elements from the configuration of the RAN resource partition for which the reports indicate that the amount of the traffic handled by the network element is below a threshold value. The threshold value may be configurable. For example, a low threshold value may be used in scenarios where the traffic of the network slice is expected to occur only sparsely. A higher threshold value may be used if the traffic of the network slice is expected to occur more densely. In some scenarios, the domain manager may remove those network elements from the configuration of the RAN resource partition for which the reports indicate that the amount of the traffic handled by the network element is zero, i.e., which handled no traffic.

<FIG> shows a flowchart for schematically illustrating a method <NUM> of managing network slices in a communications network subject to the addition of a new cell which may be used in the methods of <FIG>. The method <NUM> may correspond to step <NUM> of <FIG>.

The method <NUM> starts at step <NUM> where the domain manager determines that a new cell has been added to the RAN <NUM>. At step <NUM>, the domain manager determines all the neighbor cells, i.e. all the existing cells of the RAN <NUM> that have become neighbor cells to the new cell added to the RAN <NUM>. The domain manager also forms a set of neighbor cells at step <NUM>, with the set including all the neighbor cells determined in this way.

At step <NUM>, the domain manager takes the next neighbor cell provided in the set of neighbor cells formed in step <NUM>. When step <NUM> is first performed, the next neighbor cell will be the first neighbor cell listed in the set; when step <NUM> is performed for the second time, the next neighbor cell will be the second neighbor cell listed in the set; and so on.

At step <NUM>, the domain manager determines the RAN resource partitions to which the currently selected neighbor cell has been assigned. The neighbor cell may be assigned to any number of RAN resource partitions, for example zero, one, two, three or more.

At step <NUM>, the domain manager compares each of the RAN resource partitions determined at step <NUM> to a set of RAN resource partitions: if a RAN resource partition is not already included in the set, the domain manager adds the RAN resource partition to that set. The first time step <NUM> is performed, the set of RAN resource partitions may not yet exist, in which case the domain manager creates such a set and begins adding RAN resource partitions to the set.

At step <NUM>, the domain manager performs a check to see if further neighbor cells from the set of neighbor cells require processing. If the answer is yes, the method <NUM> loops back to step <NUM> where the next neighbor cell is selected by the domain manager. Steps <NUM> to <NUM> are then repeated by the domain manager. In this way, the domain manager will process each neighbor cell from the set of neighbor cells and will form a set of RAN resource partitions that includes all RAN resource partitions to which the neighbor cells have been assigned.

When all neighbor cells from the set of neighbor cells have been processed in steps <NUM> to <NUM>, the test applied at step <NUM> will result in a no outcome. In this case, the method <NUM> will cease to loop through steps <NUM> to <NUM> and will instead continue to step <NUM>.

At step <NUM>, the domain manager selects the next RAN resource partition from the set of RAN resource partitions formed in step <NUM>. When step <NUM> is first performed, the next RAN resource partition will be the first RAN resource partition listed in the set; when step <NUM> is performed for the second time, the next RAN resource partition will be the second RAN resource partition listed in the set; and so on.

At step <NUM>, the configuration of the currently selected RAN resource partition is adapted by adding a network element of the new cell added to the RAN <NUM>. At step <NUM>, the domain manager determines if all RAN resource partitions from the set of RAN resource partitions have been processed. If the answer is no, the method <NUM> loops back to step <NUM> where the next RAN resource partition from the set of RAN resource partitions is selected. Steps <NUM>, <NUM> and <NUM> are then repeated by the domain manager. In this way, the domain manager will process each RAN resource partition from the set of RAN resource partitions and will add the new cell to the configuration of each of the RAN resource partitions in the set of RAN resource partitions.

When all RAN resource partitions have been processed, the outcome of test <NUM> is no and the method ends at step <NUM>. When the method has ended at step <NUM>, the domain manager will have assigned the new cell to the configuration of each RAN resource partition served by at least one of the neighbor cells. The new cell is made available to the RAN resource partitions making use of the neighbor nodes, i.e. the new cell is made available to the RAN resource partitions (and hence network slices) that are most likely to make use of the new cell. This is because the new cell is most likely to have been added to the RAN due to high demand for use of the neighbor cells by the network slices they serve. If any RAN resource partition does not make use of the new cell added to the RAN <NUM>, the new cell may be removed from the configuration of that RAN resource partition during the subsequent optimization step, for example step <NUM> of <FIG>.

<FIG> shows a flowchart for schematically illustrating a method <NUM> of managing network slices in a communications network subject to the removal of an unwanted cell from the RAN <NUM> which may be used in the methods <NUM>, <NUM>, <NUM>, <NUM> of <FIG>. The method <NUM> may correspond to step <NUM> of <FIG>.

The method <NUM> starts at step <NUM> where the domain manager determines the removal of an unwanted cell from the RAN <NUM>. At step <NUM>, the domain manager determines all the neighbor cells, i.e. all the existing cells of the RAN <NUM> that were the neighbor cells of the unwanted cell removed from the RAN <NUM>. The domain manager also forms a set of neighbor cells at step <NUM>, with the set including all the neighbor cells determined in this way.

At step <NUM>, the domain manager determines the RAN resource partitions to which the unwanted cell was assigned at the time of its removal from the RAN <NUM>. The unwanted neighbor cell may have been assigned to the configurations of any number of RAN resource partitions, for example zero, one, two, three or more. At step <NUM>, the domain manager forms a set of RAN resource partitions that includes each of the RAN resource partitions determined at step <NUM>.

At step <NUM>, the configuration of the currently selected RAN resource partition is adapted by adding a network element of each neighbor cell from the list of neighbor cells formed in step <NUM>. At step <NUM>, the domain manager determines if all RAN resource partitions from the set of RAN resource partitions have been processed. If the answer is no, the method <NUM> loops back to step <NUM> where the next RAN resource partition from the set of RAN resource partitions is selected. Steps <NUM>, <NUM> and <NUM> are then repeated by the domain manager. In this way, the domain manager will process each RAN resource partition from the set of RAN resource partitions and will add the neighbor cells to the configuration of the RAN resource partitions in the set of RAN resource partitions.

When all RAN resource partitions have been processed, the outcome of test <NUM> is no and the method ends at step <NUM>. When the method has ended at step <NUM>, the domain manager will have assigned all the neighbor cells to the configuration of each RAN resource partition previously served by the unwanted cell removed from the RAN. If no action is taken, the loss of the unwanted cell from the RAN resource partition(s) to which it was assigned may result in a breach of an SLA(s) for the network slice(s). The method <NUM> ensures that the loss of the unwanted cell from the RAN resource partition(s) is adequately compensated by providing use of all the neighbor cells to the RAN resource partition(s). If the RAN resource partition(s) does not make use of one of the neighbor cells, that neighbor cell may be removed from the configuration of the RAN resource partition during the subsequent optimization step, for example step <NUM> of <FIG>.

<FIG> shows a method <NUM> which may be used to implement the further adaptation of the configuration of the RAN resource partition in step <NUM> of <FIG> and, in particular, step <NUM> of <FIG>. This method <NUM> may be performed after the methods <NUM>, <NUM> of <FIG> and <FIG>.

At step <NUM>, the domain manager may use the received reports to determine the amount of traffic for network elements (such as cells) for each of the RAN resource partitions they serve. The cells are assumed to be served by respective access nodes, e.g., the above-mentioned RAN nodes <NUM>, <NUM>, <NUM>. The cells may include cells that were newly assigned to the configuration of a RAN resource partition(s) during step <NUM> of <FIG> and/or cells that were already assigned to the configuration of a RAN resource partition(s) prior to step <NUM>.

At step <NUM>, the domain manager determines if the amount of the traffic is low for any cell for a RAN resource partition it serves, e.g., zero or below a threshold. As mentioned above, this threshold may be configurable. The cell may be a cell that was newly assigned to the configuration of the RAN resource partition during step <NUM> of <FIG>, or the cell may be a cell that was already assigned to the configuration of the RAN resource partition prior to step <NUM>. If the amount of the traffic is found to be low for a cell, the method <NUM> proceeds to step <NUM>. Otherwise, the method <NUM> proceeds to step <NUM>.

At step <NUM>, the domain manager removes the cell for which traffic is low from the configuration of the RAN resource partition for which it is seeing low traffic. In response to removing the cell from the configuration of this RAN resource partition, the domain manager may send a management message to the access node serving the cell, for example a message like the message <NUM> shown in <FIG>. The management message causes the access node locally to release an assignment of the cell to the configuration of the RAN resource partition. At step <NUM>, the domain manager keeps the cell in the configuration of the RAN resource partition.

At step <NUM>, the domain manager may check if, after removal of the cell at step <NUM>, there are any remaining cells served by the access node in the configuration of the RAN resource partition for which it is seeing low traffic, i.e., if all cells served by the access node were removed from the configuration of the RAN resource partition. If all cells are found to be removed, the method proceeds to step <NUM>. Otherwise, the method <NUM> proceeds to step <NUM>.

At step <NUM>, the domain manager removes the access node from the configuration of the RAN resource partition. Accordingly, in response to removing all of the cells served by one of the access nodes for a particular RAN partition, the domain manager may also remove this access node from the configuration of that RAN resource partition. In response to removing the access node from the configuration of the RAN resource partition, the domain manager may send a management message to the access node. An example of such management message is the above-mentioned management message <NUM> of <FIG>. The management message causes the access node locally to release an assignment of the access node to the configuration of the RAN resource partition. At step <NUM>, if there are cells served by the access node remaining in the configuration of the RAN resource partition, the domain manager keeps the access node in the configuration of the RAN resource partition.

<FIG> shows a block diagram for illustrating functionalities of a domain manager <NUM> which may perform any of the methods that are described above and that are illustrated in any of <FIG>. As illustrated, the domain manager <NUM> may be provided with a module <NUM> configured to determine a change in cell composition in the RAN <NUM>, such as explained in connection with step <NUM> of <FIG>. Further, the domain manager <NUM> may be provided with a module <NUM> configured to determine neighbor cells, such as explained in connection with step <NUM> of <FIG>. Further, the domain manager <NUM> may be provided with a module <NUM> configured to determine a set of RAN resource partitions, such as explained in connection with step <NUM> of <FIG>. Further, the domain manager <NUM> may be provided with a module <NUM> configured to adapt the configurations of RAN resource partitions, such as explained in connection with step <NUM> of <FIG>.

The domain manager <NUM> may also comprise one or more interfaces <NUM> for connecting to the network and via said network to other elements of the network. Although <FIG> illustrates one embodiment in which the components of the domain manager <NUM> are connected to a bus it would be clear for a person skilled in the art that alternative embodiments are also possible, e.g. connecting the components in series.

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

<FIG> illustrates a processing circuitry-based implementation of a domain manager <NUM> which may be used for performing any of the methods that are described above and that are illustrated in any of <FIG>. For example, the structures as illustrated in <FIG> may be used for implementing the RDM <NUM> or the domain manager <NUM>.

As illustrated, the domain manager <NUM> may include one or more interfaces <NUM> for communicating with RAN nodes or with other nodes of a wireless communication network, e.g., such as the NMS <NUM>. The interface(s) <NUM> may be used for receiving the above-mentioned reports from the RAN nodes <NUM>, <NUM>, <NUM> or for sending the above-mentioned management messages to the RAN nodes <NUM>, <NUM>, <NUM>.

Further, the domain manager <NUM> may include processing circuitry coupled to the interface(s) <NUM>. The processing circuitry may include one or more processors <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 domain manager <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>, firmware <NUM>, and/or control parameters <NUM>. The memory <NUM> may include suitably configured program code to be executed by the processing circuitry so as to implement the above-described functionalities of a domain manager, 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 domain manager <NUM> may actually include further components which, for the sake of clarity, have not been illustrated, e.g., further interfaces. The components of the domain manager <NUM> may be connected in series or to a bus, or in some other way. Also, it is to be understood that the memory <NUM> may include further program code for implementing known functionalities of a radio domain manager. According to some embodiments, also a computer program may be provided for implementing functionalities of the domain manager <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.

Claim 1:
A method of managing network slices in a communications network, the method comprising:
a domain manager of a Radio Access Network, RAN, determining (<NUM>; <NUM>, <NUM>) a change in cell composition of the RAN, wherein the change in cell composition comprises an addition of a new cell to the RAN or a removal of a cell from the RAN;
the domain manager determining (<NUM>; <NUM>, <NUM>) neighbor cells within the RAN affected by the change in cell composition of the RAN;
the domain manager determining (<NUM>; <NUM>, <NUM>) a set of RAN resource partitions affected by the change in cell composition of the RAN; and
the domain manager adapting (<NUM>; <NUM>, <NUM>) the configurations of RAN resource partitions of the set of RAN resource partitions by introducing changes corresponding to the change in cell composition of the RAN, wherein a configuration of a RAN resource partition defines the network elements of the RAN that are assigned to the RAN resource partition of a network slice.