Method and device for controlling the deployment of network functions in a communication system having a programmable metasurface

Abstract

According to one embodiment, a deployment control component of a communication system is described, comprising a metasurface management interface configured to receive information regarding the presence and capabilities of programmable metasurfaces usable by the communication system, and a controller configured to determine a deployment of network functions of the communication system in response to the received information and to control communication system resources of the communication system in accordance with the determined deployment.

Description

[Technical field]

[0001] The present disclosure relates to methods and devices for controlling the deployment of network functions of a communication system, including programmable metasurfaces, e.g., during system instantiation and during network function lifecycle management. [Background technology]

[0002] A communication system, especially a mobile communication system, typically provides coverage in a certain geographical area. To this end, communication resources (including actual network forwarding resources and data processing resources) are required to provide network functions (NFs). For example, in the case of a distributed Radio Access Network (RAN), resources are required to implement aggregation units, distribution units and radio units. Summary of the Invention

[0003] Efficient approaches to deployment regarding communication system resource usage are desirable.

[0004] According to one embodiment, a deployment control component of a communication system is provided, comprising: a metasurface management interface configured to receive information regarding the presence and capabilities of programmable metasurfaces usable by the communication system; and a controller configured to determine deployment and configuration of virtualized network functions (VNFs) and configuration of physical network functions (PNFs) of the communication system in response to the received information, and to control communication system resources of the communication system in accordance with the determined deployment.

[0005] According to a further embodiment, there is provided a method for controlling deployment of a communication system by means of the deployment control component described above. [Brief description of the drawings]

[0006] In the drawings, like reference numbers generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various aspects are described with reference to the following drawings: [Figure 1] A communications system, in this example a fifth generation (5G) communications system from, for example, the Third Generation Partnership Project (3GPP), and associated management and orchestration systems are shown. [Diagram 2] 1 illustrates a physical area (eg, a floor of a building) in which communication devices are located in three sub-area locations. [Diagram 3] 1 illustrates a deployment control configuration according to one embodiment. [Figure 4] 1 illustrates a deployment control architecture having multiple programmable metasurface (PMS) managers communicating with an orchestrator. [Diagram 5] 1 illustrates communication system components for a distributed RAN for providing network services to a mobile terminal or user equipment (UE). [Figure 6] FIG. 1 shows a flow diagram illustrating PMS-based verification according to one embodiment. [Figure 7] A flow diagram for PMS resource reservation with on-demand orchestration driven by OSS / BSS (Operation Support System / Business Support System) is shown. [Figure 8] 1 illustrates a flow diagram for PMS resource reservation through dynamic and / or automatic network-driven orchestration. [Figure 9]1 shows a flow diagram for PMS resource reservation with on-demand mounting and instantiation based on PMS Physical Network Function Descriptor (PNFD). [Figure 10] An example of modeling PMS information is shown below. [Figure 11] An example of modeling orchestrator functions and public interfaces is given. [Figure 12] The architecture shows an orchestrator 1201 communicating with a PMS manager 1202 via a smart building (or city) management system 1203. [Figure 13] This paper presents an architecture for ETSI (European Telecommunications Standards Institute) NFV-MANO (Network Functions Virtualization - Management and Orchestration)-aware orchestration, including PMS. [Figure 14] This shows an architecture for O-RAN (Open Radio Access Network)-based orchestration including PMS. [Figure 15] 1 shows an architecture for an industrial network including a PMS. [Figure 16] 1 illustrates a deployment control component of a communication system according to one embodiment. [Figure 17] 1 shows a flow diagram illustrating a method for controlling deployment of a communication system according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] The following detailed description refers to the accompanying drawings, which show, by way of example, specific details and aspects of the present disclosure in which the present invention may be practiced. Other aspects may be utilized, and structural, logical, and electrical changes may be made, without departing from the scope of the present invention. Various aspects of the present disclosure are not necessarily mutually exclusive, as some aspects of the present disclosure may be combined with one or more other aspects of the present disclosure to form new aspects.

[0008] Various examples corresponding to aspects of the present disclosure are described below.

[0009] Example 1 is a deployment control component of a communications system, including a metasurface management interface configured to receive information regarding the presence and capabilities of programmable metasurfaces usable by the communications system, and a controller configured to determine a deployment of network functions of the communications system in response to the received information and to control communications system resources of the communications system in accordance with the determined deployment.

[0010] Example 2 is the deployment control component of example 1, where the deployment of the network function takes into account placement constraints of the network function and communication system resource requirements.

[0011] Example 3 is the deployment control component of example 2, where deploying the network function includes implementing the network function by allocating at least one virtual and / or physical communication system resource at a geographic location.

[0012] Example 4 is the deployment control component of any one of examples 1-3, wherein the controller is configured to determine a deployment of the network function to conform to the deployment policy.

[0013] Example 5 is the deployment control component of example 4, including a policy decider configured to set a deployment policy in response to the received information.

[0014] Example 6 is the deployment control component of example 4, including a policy interface configured to receive a deployment policy.

[0015] Example 7 is the deployment control component of any one of Examples 1-6, including an interface configured to receive a request to provide the network service, and the controller configured to determine a deployment and control communication system resources to provide the network service according to the determined deployment.

[0016] Example 8 is the deployment control component of example 7, wherein the controller is configured to ensure that the request complies with the deployment policy, determine the deployment, and, if the request complies with the deployment policy, control the communication system resources in accordance with the determined deployment.

[0017] Example 9 is the deployment control component of example 7 or 8, wherein the controller is configured to determine whether additional network functionality is required to provide the network service, and if so, determine a deployment of the additional network functionality, and control communication system resources of the communication system to provide the additional network functionality and the determined deployment.

[0018] Example 10 is the deployment control component of example 9, wherein the controller is configured to determine, based on the received information, whether additional network functionality is required.

[0019] Example 11 is the deployment control component of example 9 or 10, wherein the controller is configured to determine a deployment of additional network functions based on the received information.

[0020] Example 12 is the deployment control component of any one of Examples 1-11, wherein the communication system is a mobile wireless communication system, and the communication system resources include at least a device for wireless communication.

[0021] Example 13 is the deployment control component of any one of Examples 1-12, wherein the communications system resources include a programmable metasurface.

[0022] Example 14 is the deployment control component of any one of Examples 1 to 13, wherein the network function is a network function for implementing a virtualized 5G core network and a virtualized 5G radio access network.

[0023] Example 15 is a method for controlling deployment of a communication system, comprising receiving information regarding the presence and capabilities of programmable metasurfaces usable by the communication system, determining a deployment of network functions of the communication system in response to the received information, and controlling communication system resources of the communication system in accordance with the determined deployment.

[0024] Communications system resources may include, for example, computing devices, network devices, storage devices, wireless transmitting devices, wireless receiving devices, and signal processing devices.

[0025] The network functions may include, for example, aggregation units, distribution units and / or radio units.

[0026] The network functions may include, for example, base station components.

[0027] It should be noted that one or more features of any of the above examples may be combined with any one of the other examples, in particular the examples described in relation to an apparatus are equally valid for the method.

[0028] According to further embodiments, there is provided a computer program and computer readable medium comprising instructions which, when executed by a computer, cause the computer to perform the method of any one of the above examples.

[0029] Various examples are described in more detail below.

[0030] FIG. 1 illustrates a communication system 100, in this example a fifth generation (5G) communication system, for example according to the Third Generation Partnership Project (3GPP).

[0031] The communication system 100 includes a 5G Core network (5GC) 101. The 5GC 101 is coupled to a radio access network (RAN) that provides radio access to mobile terminals 102. The radio access network is provided by Virtualized Network Functions (VNFs) and Physical Network Functions (PNFs), such as a Virtualized Central Unit (CU) 103 in the distributed RAN case, a Virtualized Distributed Unit (DU) 104, a (physical) Radio Unit (RU) 105, and a gNB 106 in the non-distributed case. This architecture can be applied to a 5G ng-eNB as well as to a 4G eNB connected to a 4G packet core network.

[0032] The deployment and management of Virtualized Network Functions (VNFs) and Physical Network Functions (PNFs) is controlled by an Orchestration Network Component (also called Orchestrator) 107. The Orchestrator 107 operates according to instructions and policies provided by Operation Support Systems (OSS) and Business Support Systems (BSS) 108.

[0033] According to various embodiments, the communication system 100 includes, among other things, Programmable Metasurfaces (PMS) 109. Each PMS 109 includes a PMS PNF 110 (i.e., a PMS controller function) and associated PMS resources 111 (i.e., the actual metasurfaces attached to indoor and / or outdoor walls).

[0034] Programmable metasurfaces typically include an array (e.g., a matrix) of switchable elements that provide the ability to manipulate radio signals to steer radio beams in specific directions or to absorb radio waves entirely. This allows, among other things, to mitigate undesirable path loss effects in real-world wireless communication use cases, such as those shown in FIG. 2.

[0035] FIG. 2 shows a physical area (e.g., a floor of a building) with four communication devices 201, 202. Each of the two first communication devices 201 reconstructs the properties of a 5G base station with radio capabilities hosting the necessary radio NFs, and the second communication device 202 is a UE. The left UE 202 is located in a subarea 204, and the left radio NF is also located in subarea 204. The right UE 202 is in a subarea 206, and another radio NF 201 is located in subarea 205. The subareas (e.g., rooms) are separated (fully or partially) by walls 207. The radio NFs (of the first communication devices) are connected to the rest of the RAN and core NFs (exposed as VNFs or PNFs) 208, which are deployed according to the network operator policy.

[0036] A programmable metasurface (PMS) 203 is provided on one wall within the sub-area 205.

[0037] The programmable metasurface 203 allows communication devices 201, 202 to communicate efficiently (with acceptable path loss) despite walls 207.

[0038] Thus, the need to deploy a wireless NF (base station) 201 in the left subarea 204 to cover the left UE 202 may be avoided. Besides the deployment of the wireless NF 201, the deployment of the RAN and core NF 208 can be controlled according to the presence and capabilities of the PMS 203, for example, to enable and optimize ultra-low latency services.

[0039] The programmable metasurface 203 further enables the use of tunable metasurfaces to optimize MIMO (multiple input multiple output) capacity, as well as improve wave propagation to achieve constructive superposition at user devices (mobile terminals, user equipment (UE)), optimize their power-delay profile (PDP), and avoid the adverse effects of multipath fading.

[0040] According to various embodiments, techniques are provided that enable functions in the communication system 100 (particularly in the orchestrator 107 and the OSS / BSS 108) to optimize the deployment and operation of network services (NSs) taking into account the PMS operating environment, i.e., the environment including the programmable metasurface. The techniques described below allow treating the metasurface as a programmable infrastructure resource (i.e., communication system resource) and orchestrating it jointly as part of a unified mobile network, i.e., radio access and core network. According to various embodiments, the communication system 100 includes a unified orchestration plane that enables the use of traditional (i.e., non-metasurface) network elements and metasurface deployments. In particular, interfaces are defined between the metasurface control and management elements and the mobile network orchestrator 107 and the OSS / BSS 108. From the OSS / BSS perspective, PMS vendor independent orchestration is provided by the orchestrator. The management of the programmable metasurface 109 according to various embodiments enables PMS awareness, allows PMS aware policies to be defined by the network operator, and performs PMS aware validation of network operation.

[0041] The programmable metasurface 109 is managed by a management component 112 (also referred to below as the (PMS) manager).

[0042] According to various embodiments, to enable telecommunications network deployment and operational optimization of integrated network services (NS) as a composition of virtualized network functions (VNFs) and physical network functions (PNFs) and nested network services, taking into account a PMS (managed by the telecommunications network), interfaces and functions are provided as described below with reference to FIG. 3.

[0043] FIG. 3 shows a deployment control configuration 300 including an OSS / BSS 301 (corresponding to OSS / BSS 108), an orchestrator 302 (corresponding to orchestrator 107), and a PMS manager 303 (corresponding to manager 112) that acts as a PMS manager for managing, among other things, at least one programmable metasurface PNF / VNF 304 associated with a programmable metasurface resource 305 (i.e., the actual programmable metasurface).

[0044] The OSS / BSS 301 and the orchestrator 302 are connected via one or more interfaces on the or-oss reference point. In this specification, a reference point is considered as a conceptual point at the joining of two non-overlapping functions that can be used to identify information passing between these functions. According to various embodiments, the existing or-oss reference point interface is extended to enable PMS-aware communication between the orchestrator 302 and the OSS / BSS 301 for signaling and orchestration to establish end-to-end network services, taking into account the PMS manager 303 as part of the orchestration actions (e.g., extending existing interfaces on reference points such as Os-Ma-nfvo when considering the ETSI NFV-based NFV-MANO solution). On the other hand, the (PMS) manager 303 can be technology specific, while the or-oss communication is technology agnostic. Signaling over the or-oss reference point interface is related to issues such as PMS manager / MS registration, onboarding of PMS as a resource, and PMS notification management. In one embodiment, the or-oss information exchange can be implemented as a single interface or set of interfaces that provide the intended functionality.

[0045] In OSS / BSS 301, the functionality is provided to treat the PMS as a programmable telecommunications infrastructure resource (i.e., a communication system resource), and the functionality and interactions between the OSS / BSS and the orchestrator for that purpose are provided. Furthermore, an NS definition is provided in OSS / BSS 301 that takes into account the PMS PNF as part of the NS descriptor and as an additional control variable for decision making.

[0046] The orchestrator 302 may implement an orchestration framework that supports the following extensions:

[0047] · Validation Function: Used to validate PMS aware NS descriptors and ensure their compliance against PMS policy.

[0048] Resource allocation function: resource allocation and optimization of VNF / PNF deployment based on PMS information (i.e., information about the presence and capabilities of one or more programmable metasurfaces).

[0049] The orchestration framework may be based on NFVO (Network Functions Virtualization Orchestrator), for example, when considering the NFV-MANO framework of ETSI NFV, or / and may be based on SMO (Service Management & Orchestrator), when considering the O-RAN framework.

[0050] Other functions within the orchestrator, such as validation functions and resource allocation and network deployment functions, can be extended with PMS related inputs to support decision making.

[0051] Support functions for realizing these two functions include, for example:

[0052] Further functionality to treat the PMS as a programmable infrastructure resource (i.e., a communications system resource) ○ Extended resource catalogs and mechanisms in the orchestrator 302 (e.g., updated resource catalogs, resource registration mechanisms, resource descriptors, etc.) - Hiding the complexity of the PMS manager 303 from the OSS / BSS 301 through the orchestrator 302 Orchestration procedures and interactions between the OSS / BSS 301 and the orchestrator 302 Converting NS requirements into resource reservation requests PMS resource information model and PMS PNF processing An or-pmsm (pmsm: programmable metasurface manager) reference point is established between the orchestrator 302 and the PMS manager 303 to identify communications between these two entities, which may support multi-PMS manager technology communications and signaling related to issues such as PMS capability disclosure, PMS notification, and PMS monitoring.

[0053] It should be noted that while the PMS manager 303 may expose services directly to the OSS / BSS 301, various embodiments instead provide a unified orchestration mechanism that supports end-to-end NS establishment and jointly performs resource management. Here, each metasurface is considered as a programmable infrastructure element that can be controlled and monitored as a physical network resource by the unified orchestration mechanism (i.e., by the orchestrator 302), exposing a controllable PMS PNF. This allows for optimization of end-to-end operation, rather than considering the wireless environment as an uncontrollable resource with stochastic behavior.

[0054] FIG. 4 shows a deployment control architecture with multiple PMS managers 401, 402 communicating via an or-pmsm interface with an orchestrator 405.

[0055] In this example, a multi-PMS technology environment is considered (including programmable surfaces with different PMS technologies such as nano-MIMO arrays, passive elements, programmable atoms, etc.). Each PMS manager 401, 402 is an entity responsible for managing and controlling the PMS PPF 403 and the corresponding PMS resources 404.

[0056] A single PMS manager 401, 402 can be technology specific or can handle PMS for multiple technologies. In this example, a first PMS manager 401 handles PMS for a first technology and a second PMS manager 402 handles PMS for a second technology and PMS for a third technology.

[0057] According to various embodiments, the orchestration behavior is independent of the PMS manager deployment model and PMS manager internal optimizations (it may be PMS specific). The PMS managers 401, 402 can expose metasurface control plane (CP) and management plane information northbound (i.e., to the orchestrator 405). This can be realized in the form of an Internet of Things (IoT) gateway system that realizes each PMS manager 401, 402.

[0058] Each PMS manager 401, 402 can be distributed or fully aggregated and expose its respective PMS PNF 403 to the orchestrator. The PMS manager can be physically co-located with the PMS PNFs and PMS resources, can be realized as a VNF, and can also integrate the role of an Internet of Things (IoT) gateway. The reference point or-manager enables communication between the orchestrator and the PMS managers.

[0059] It should be noted that from a management and orchestration point of view (similar to NFV-MANO (Management and Orchestration) in ETSI NFV), the actual configuration applied to the PMS PNFs may be irrelevant. For example, an application residing in either a PMS-aware OSS / BSS or an external management system may request to generate exactly matching air routes and deploy these by sending corresponding EM (Element Manager) operation commands through the PMS managers 401, 402 to the respective PMS PNFs. In this case, the orchestrator is unaware of the actual configuration applied, and does not perform any associated PMS configuration optimizations.

[0060] FIG. 5 illustrates communication system components for providing network services 500 to a mobile terminal (UE) 501 .

[0061] In a first example 510, a network service 500 is provided by a core network NS 502, an aggregation unit VNF ​​(or PNF) 503, a distribution unit VNF ​​(or PNF) 504, a radio unit PNF 505 and in particular a PMS PNF 506.

[0062] In a second implementation example 511, the CU, DU, and RU NFs can be provided by a single 5G base station (i.e., gNB or ng-eNB) 507. Similarly, in a third example 512, the NS can be configured on 4G-related NFs (e.g., eNB and SGW, PGW) 508 and 509, and further on hybrid 4G and 5G NFs.

[0063] According to various embodiments, the PMS PNF can be applied in any NS type (nested or not). The PMS manager 401, 402 handles both the PMS as a resource and the PNFs that run on top (management and control aspects).

[0064] The network service 500 is described by a network service descriptor (NSD) that contains information about the VNFD, PNFD, NestedNS, service access points, autoScalingRules, deployment flavors, forwarding graphs, virtual links (VLs), lifecycle management scripts, etc.

[0065] Below, examples of objectives from an OSS / BSS or operator perspective are given.

[0066] As a first example, assume that OSS / BSS 301 provides NSD and PMS aware policies to orchestrator 302 without providing details about the actual resource allocation. For example, OSS / BSS 303 requests "Place DU VNF on a machine with 4 vCPU and 12 GB vMem in area A that supports PMS absorption". OSS / BSS 302 does not know how absorption is actually applied and how it is actually acted upon by PMS manager 303. Orchestrator 302 is aware of the PMS specification but translates this information in an abstract way to OSS / BSS 303. It should be noted that orchestrator 302 also does not configure PMS PNFs, orchestrator 302 only requests their management (knows their capabilities, functions, their state, etc.).

[0067] As a second example, assume that the OSS / BSS 303 wants an NS to be deployed at location A where it knows that a PMS is present, and the OSS / BSS 303 wants the radio signal enhanced by the PMS functionality to cover a particular sub-area of ​​location A. This triggers the orchestrator 302 to provide actions like proper resource placement of the NFs (VNFs and PNFs) that compose the NS, optimize the associated resource allocation, and trigger the PMS manager to configure the PMS to cover the appropriate sub-area.

[0068] As a third example, assume that during the NS lifetime, the OSS / BSS 303 receives a notification from the orchestrator 302 about a change on the PMS infrastructure (e.g., that a wall has been removed or that a PMS PNF has added a new capability) and updates the associated PMS policy.

[0069] The PMS information may be part of the information considered by the orchestrator, which further includes NS information, VNF policies, constraints, deployment flavors, etc. As shown in Figure 5, the PMS PNF 506 may be part of the NS 500. Alternatively, it is not part of the on-board NSD and during runtime (after the initial NS deployment), the PMS PNF and PMS resources are processed by the orchestrator 302 and start to be used during runtime NS processing.

[0070] FIG. 6 shows a diagram 600 illustrating a PMS-based verification function according to one embodiment.

[0071] Corresponding to Fig. 3, includes OSS / BSS 601, orchestrator 602 and PMS manager 608. Besides PMS manager 608, orchestrator 602 also interacts with infrastructure manager 603, which is responsible for controlling and managing the infrastructure (e.g., compute, network and storage resources), and VNF and PNF manager 607, which is responsible for managing deployed VNFs / PNFs running on top of the virtualized or physical infrastructure, respectively. The orchestrator may, for example, instantiate (or not instantiate) network services and influence infrastructure resource allocation (e.g., which physical resources should be used to deploy a particular DU VNF, etc.).

[0072] The addition of PMS and PMS PNFs impacts the validation process for NS deployment and Life Cycle Management (LCM) operations. The presence and capabilities of a PMS can be part of NS and VNF / PNF LCM decision making, for example, when scaling out a VNF. Especially for low latency NS, the presence (or lack thereof) of a PMS can be a key factor in how the orchestrator 602 deploys the network (physical and virtual components), especially NFs (VNFs, PNFs), not only during instantiation but also during subsequent management. For example, the presence of a particular PMS capability can impact affinity and anti-affinity rules when deploying a particular VNF. The use of a PMS may be part of the deployment flavour (DF) (NS DF as well as VNF DF), for example, deciding whether to use a PMS or not can be part of NS and VNF / PNF LCM decision making.

[0073] According to various embodiments, functionality is provided within the orchestrator 602 and / or OSS / BSS 601 to support this process, particularly deployment decisions. The orchestrator 602 can manage resources (service resources and infrastructure resources) taking into account priorities based on operator policies and service level agreements (SLAs). Priorities and policies are updated to be PMS aware. Corresponding signaling may be provided between the OSS / BSS 601 and the orchestrator 602, and between the orchestrator 602 and the PMS manager 608.

[0074] According to various embodiments, the OSS / BSS 601 acts as a Policy Administration Point (PAP) that defines policies, and the orchestrator 602 implements a Policy Function (PF) 604 that evaluates policies and performs policy conformance decisions. Policies can be defined in the OSS / BSS (PAP), inside the orchestrator, etc. The Policy Function ensures conformance with PMS-aware policies (regardless of which entity defined the policy). The Infrastructure Manager 603 may also implement a PF.

[0075] Policies can be applied / activated for lifecycle management and resource orchestration. For example, the PAP (i.e., OSS / BSS 601) creates a specific PMS-aware policy (e.g., NS LCM policy, VNF LCM policy, resource management policy, or placement policy, etc.) and forwards the policy to the orchestrator. The PF 604, which resides in the orchestrator, is responsible for policy conformance. There may also be policies for VNF LCM operations.

[0076] The orchestrator 602 may perform the validation, for example, when onboarding the NS or due to an NS or VNF LCM event.

[0077] For example, instantiation of a network service may include:

[0078] 1) The Orchestrator 602 communicates with the PMS Manager 608 about the deployment, status and configuration of available PMS in the area.

[0079] 2) The orchestrator 602 receives a request to instantiate an NS (eg, using the Instantiate NS operation of a specified NS LCM interface).

[0080] 3) The orchestrator 602 performs validation 605 on the request. This includes checking both the validity of the request (e.g., that the sender is authorized) and validating the passed parameters for technical correctness such as policy conformance. For example, the orchestrator may check whether the request violates PMS-aware affinity and anti-affinity rules (if not, continue), whether the request adheres to a PMS-aware deployment flavor (DF) (e.g., NS DF or VNF DF) (if yes, continue). The inputs of 605 may be legacy inputs, PMS parameters, and PMS policies. The output of 605 is the validation result.

[0081] 4) The orchestrator 602 then performs resource allocation 606 (e.g. for scheduling in a particular area), based on the validation results of 605, legacy inputs and PMS attributes and parameters. For each VNF instance required in the NS for resource allocation, the orchestrator 602 checks if an instance matching the requirements already exists (if so, it is used as part of the NS). If a new VNF needs to be instantiated and therefore resources from the infrastructure need to be allocated, and if resource reservation is required according to the operational policy, a. The Orchestrator 602 requests the availability of required network resources and reservation of these resources from the Infrastructure Manager 603.

[0082] b. The Infrastructure Manager 603 checks the availability of the required network resources and reserves them (eg, schedules physical resources within an area).

[0083] c. The infrastructure manager 603 returns the reservation results to the orchestrator 602.

[0084] 5) The orchestrator 602 requests from the infrastructure manager 603 instantiation of the network connections required for the network service using the resource allocation or resource update operations from the virtualization resource management interface.

[0085] 6) The Infrastructure Manager 603 instantiates the connectivity networks required for the network services.

[0086] 7) Infrastructure Manager 603 acknowledges completion.

[0087] 8) Assuming the list of VNF instances to be provisioned is not empty, the orchestrator 602 requests the VNF manager to instantiate the VNF instances required by the NS and provides information about the networks connecting the VNF external interfaces.

[0088] 9) Once all VNF instances are available, for VNFs that are not yet connected, the orchestrator 602 requests the infrastructure manager 603 to connect them.

[0089] 10) Infrastructure Manager 603 connects the required network resources to the infrastructure network required by the network.

[0090] 11) Infrastructure Manager 603 acknowledges completion.

[0091] 12) If necessary, the orchestrator 602 requests the network manager to connect the VNF external interfaces to the physical network function interfaces at the application level, or provides the corresponding information about the external interfaces of the NFs involved in the NS to other management systems, so that these other management systems can perform the actual setup of the connections at the application level. The network manager can be an OSS / BSS, a Network Management System (NMS), one or more Element Managers (EMs).

[0092] 13) The orchestrator 602 acknowledges the completion of the network service instantiation.

[0093] The orchestrator 602 therefore has the following capabilities (possibly supported by corresponding signal and information models introduced for this purpose):

[0094] · Book PMS as a resource ·Perform PMS resource catalog CRUD operations (create, read, write, etc.) - Equipped with PMS related descriptors / information to interpret new PMS models Manages the PNF / VNF functions controlled by the PMS manager - Handle an extended NSD definition that also considers PMS as part of the integrated NS · Locally handles different configuration and management aspects of PMS, PMS status monitoring (handles PMS manager related OAM, alarms, etc.) Coordinates the connections between the PMS Manager and the PMS-PNF and the rest of the network · Re-expose PMS manager capabilities · Apply PMS / PMS manager security controls (e.g. authentication) Providing advanced orchestration services such as policy management for PMS-aware behavior Abstracts from OSS / BSS multi-technology PMS specifications and compatibility issues (abstracts any compatibility issues from different PMS / PMS manager technologies to OSS / BSS) Optimize network resource usage by considering PMS configuration and performance together Build a unified view of all physical network resources and PMS as a distributed set FIG. 7 shows a flow diagram 700 for PMS resource reservation with on-demand orchestration driven by OSS / BSS.

[0095] The flow takes place between OSS / BSS 701 (corresponding to OSS / BSS 301), Orchestrator 702 (corresponding to Orchestrator 302), and PMS Manager 703 (corresponding to or implemented by Manager 303). The PMS Manager can handle one or more PMS.

[0096] At 704, the third party advertises the PMS manager to the OSS / BSS (eg, by IP / port or Fully-Qualified Domain Name (FQDN)).

[0097] At 705 , the OSS / BSS 701 requests the orchestrator 702 to connect to the PMS manager 703 .

[0098] At 706, the orchestrator 702 requests a connection to the PMS manager 703 and is informed of the PMS manager capabilities.

[0099] At 707, the PMS manager 703 establishes a connection to the orchestrator 702 upon request and acknowledges at 708.

[0100] At 709, the orchestrator 702 checks with the OSS / BSS 701 for PMS manager constraints or policies. The orchestrator also acknowledges connection status and PMS manager related information to the orchestrator 701.

[0101] At 710 , the orchestrator 702 requests and receives information regarding the presence and capabilities of PMSs handled by the PMS manager 703 .

[0102] At 711, the orchestrator 702 checks for PMS constraints or policies.

[0103] At 712, the orchestrator 702 notifies the OSS / BSS 701 of the available PMS.

[0104] At 713, the OSS / BSS 701 requests reservation and registration specific PMS as a communication system resource.

[0105] At 714, the orchestrator 702 requests reservation of the PMS as an orchestrated resource from the PMS manager 703, which reserves the PMS at 715 and acknowledges at 716.

[0106] At 717, the orchestrator 702 completes the reservation and registration.

[0107] At 718, the orchestrator 702 initiates and / or updates the PMS resource catalog.

[0108] At 719, the orchestrator 702 initiates the PMS interface endpoint and the interface handler.

[0109] At 720, the orchestrator 702 notifies the OSS / BSS 701 that the registration was accepted. After this step, the registered PMS is available as a resource for network services managed by the OSS / BSS 701 and the orchestrator 702.

[0110] Different resource management models may be used for each resource type. According to one embodiment, the network operator may choose one or a combination of the following resource management models:

[0111] Model 1: The PMS manager is operated by an external entity different from the network operator's PMS manager Model 2: The network operator is also the owner of the PMS manager Model 3: The network operator interacts with the PMS manager through another management system (e.g., used to control and optimize the electricity consumption of buildings) Model 4: Network operators expose PMS-related information to third parties through APIs For Models 2 and 4, PMS resources can be committed from the network operator to a particular network operator consumer (eg, MVO) or consumer service.

[0112] FIG. 8 illustrates a flow diagram 800 for PMS resource reservation through dynamic and / or automatic network-driven orchestration.

[0113] The flow takes place between an OSS / BSS 801 (corresponding to OSS / BSS 301), an Orchestrator 802 (corresponding to Orchestrator 302), and a PMS Manager 803 (corresponding to or implemented by Manager 303). The PMS Manager can handle one or more PMSs.

[0114] The flow assumes that a connection already exists between the PMS manager 803 and the orchestrator 802.

[0115] At 804, the orchestrator 802 receives updates regarding the presence and capabilities of the PMS, which are processed by the PMS manager 803.

[0116] At 805, the orchestrator 802 checks for PMS constraints or policies.

[0117] At 806, the orchestrator 802 notifies the OSS / BSS 801 of the available PMS.

[0118] At 807, the OSS / BSS 801 reserves and registers a particular PMS from the advertised set as a communications system resource.

[0119] At 808, the orchestrator 802 requests reservation of the PMS as an orchestrated resource from the PMS manager 803, which reserves the PMS at 809 and acknowledges at 810.

[0120] At 811, the orchestrator 802 completes the reservation and registration.

[0121] At 812, the orchestrator 802 initiates and / or updates the PMS resource catalog.

[0122] At 813, the orchestrator 802 initiates the PMS interface endpoint and the interface handler.

[0123] At 814, the orchestrator 802 notifies the OSS / BSS 801 that the registration was accepted.

[0124] FIG. 9 illustrates a flow diagram 900 for PMS resource reservation with on-demand mounting and instance based on PMS PNFD (PNF Descriptor) as part of NSD by OSS / BSS.

[0125] The flow takes place between an OSS / BSS 901 (corresponding to OSS / BSS 301), an Orchestrator 902 (corresponding to Orchestrator 302), and a PMS Manager 903 (corresponding to or implemented by Manager 303). The PMS Manager can handle one or more PMSs.

[0126] At 904, the OSS / BSS 901 makes a request to the orchestrator 902 to instantiate an NS.

[0127] At 905, the orchestrator 902 decomposes the NS into VNFs, VLs (Virtual Links), PNFs, and so on.

[0128] At 906, the orchestrator 902 checks for PMS constraints or policies.

[0129] At 907, the orchestrator 902 requests reservation of the PMS as an orchestrated resource from the PMS manager 903, which reserves the PMS at 908 and acknowledges at 909.

[0130] At 910, the orchestrator 902 completes the reservation and registration.

[0131] In 911, resource reservation is completed but the PNF is not running.

[0132] At 912, the orchestrator 902 requests the PMS manager 903 to start the PNF. The PMS manager 903 activates the PMS PNF accordingly at 913 and acknowledges at 914.

[0133] At 915, the orchestrator 902 starts the interface handler.

[0134] At 916, the orchestrator completes a similar process for the remaining NFS and VNFs.

[0135] At 917, the orchestrator 902 notifies the OSS / BSS 901 that the NS instantiation is complete.

[0136] Figure 10 gives an example of modelling PMS information, in particular the information flow through the capability exposure interface on the or-manager reference point.

[0137] Communication from the Orchestrator to the PMS Manager can be realized based on a reference point (or-pmsm) that hosts one or more associated interfaces related to (non-exclusive list).

[0138] ·if_1:pms_capabilities_exposure ·if_2:pms_configuration_channel ·if_3:pms_notifications_management if_4:pms_monitoring ·….. Figure 11 gives an example of modelling the orchestrator function, in particular the information flow through the or-oss reference point.

[0139] The orchestrator for OSS / BSS communication will be updated to also take into account the configuration and management of the PMS.

[0140] Policy constraints can be provided to the orchestrator or can be set at runtime. Constraints specify the conditions for PMS manager operations and maintenance workflows that need to be executed.

[0141] The orchestrator provides an abstract NS level interface, which is the view that the operators get, ensuring that the orchestrator performs the necessary transformation functions.

[0142] If the Orchestrator can communicate with the PMS Manager indirectly through another PMS management entity, the functions and information flows in the previous section are adapted accordingly.

[0143] FIG. 12 shows an architecture in which an orchestrator 1201 communicates with a PMS manager 1202 via a smart building (or city) management system 1203.

[0144] The orchestrator 1201 is connected to an OSS / BSS 1204, a VNF / PNF manager 1205 that handles VNFs and PNFs 1206, and an infrastructure manager 1207 that handles network and cloud resources 1208. The PMS manager 1202 handles PMS resources and NFS 1209.

[0145] Figure 13 shows an architecture for NFV-MANO-aware orchestration of ETSI NFV including PMS.

[0146] The NFVO 1301 is connected to an OSS / BSS 1302 and a VNFM (VNF Manager) 1303. The VNFM 1303 is connected to a VIM (Virtual Infrastructure Manager) 1304, a NFVI (Network Functions Virtualization Infrastructure) 1305, a VNF 1306, and an EM 1307.

[0147] The NFVO 1301 is further connected to a Container Infrastructure Service Management (CISM) 1308 and a WAN Infrastructure Manager (WIM) 1309, and is connected to a PMS manager 1310 via an or-manager reference point.

[0148] The NFVO 1301 maintains the NS catalog, the VNF catalog, and handles VNF instances, NFVI resources, PMS resources, and PMS PFNs (non-exhaustive list).

[0149] The NFV architectural framework can support the integration of PMS infrastructure management deployed as part of the NFV-MANO framework or outside the NFV-MANO framework (e.g., under the control of other OSS / BSS systems).

[0150] Figure 14 shows an architecture for Open Radio Access Network (O-RAN) based orchestration including a PMS.

[0151] A Service Management and Orchestration (SMO) 1401 is connected to an OSS / BSS 1402, a RAN controller 1403, and a PMS manager 1404. The RAN controller 1403 is connected to a vDU 1406 and a vCU 1407. A vRU 1405 is connected to the vDU. The PMS manager 1404 handles the PMS, which may be an O cloud resource.

[0152] The RAN controller 1403 can also optimize the configuration of the RAN through closed-loop control through interaction with the PMS manager 1404 via the SMO. The orchestrator (SMO) is responsible for the overall optimization, management, and operation of the network.

[0153] FIG. 15 shows an architecture for an industrial network including a PMS.

[0154] The orchestrator 1501 is connected to an OSS / BSS 1502 and an industrial automation and management entity 1503 that is connected to a 5G core 1504 and a 5G RAN 1505.

[0155] The orchestrator 1501 is connected to a PMS manager 1506 which handles PMS PNFs and VNFs 1507 with associated PMS resources 1508 .

[0156] In summary, in accordance with various embodiments, a deployment control component of a communication system is provided as shown in FIG.

[0157] FIG. 16 illustrates a deployment control component 1600 of a communication system.

[0158] The deployment control component 1600 includes a metasurface management interface 1601 configured to receive information regarding the presence, status, and capabilities of programmable metasurfaces usable by the communication system.

[0159] The placement control component 1600 further includes a controller 1602 configured to determine placement of network functions of the communication system, perform resource allocation according to the received information, and control communication system resources of the communication system according to the determined placement.

[0160] In other words, according to various embodiments, a deployment control entity of a communication system takes into account the presence and capabilities of programmable metasurfaces (e.g., polarization, steering, absorption, supported frequency bands, etc.) For example, in the example of FIG. 2, the control entity may decide to deploy an NF only in the first subarea 204 to cover the entire space, for example, rather than placing multiple instances of the same NF in subareas 205 and 206.

[0161] The deployment control component is, for example, an orchestrator, but may include both orchestrator and OSS / BSS functions. Thus, the functions described above for the orchestrator and OSS / BSS, respectively, may apply to the deployment control entity. In particular, the deployment control entity may also set policies that the controller takes into account for deployment. The deployment control component is not necessarily implemented by a single device, but may be implemented by multiple devices (e.g., using one or several management functions deployed on cloud resources).

[0162] The information may come from a manager as described above, or the deployment control entity may take into account, for example, policies and requirements from the OSS / BSS (typically one or more components that issue requirements and policies).

[0163] Parts of the deployment control component (e.g., the interface and the controller) may, for example, be implemented by one or more circuits. A "circuit" may be understood as any kind of logic implementation entity, which may be a dedicated circuit or a processor executing software stored in memory, firmware, or any combination thereof. Thus, a "circuit" may be a hardwired logic circuit or a programmable processor, e.g., a programmable logic circuit such as a microprocessor. A "circuit" may also be a processor executing software, e.g., any kind of computer program. Any other kind of implementation of the respective function may also be understood as a "circuit".

[0164] The deployment control component may, for example, execute a method such as that shown in FIG.

[0165] FIG. 17 shows a flow diagram 1700 illustrating a method for controlling deployment of a communication system.

[0166] At 1701, information regarding the existence and capabilities of programmable metasurfaces available via a communication system is received.

[0167] At 1702, deployment of network capabilities and resource allocations for the communication system is determined in response to the received information.

[0168] At 1703, communication system resources of the communication system are controlled according to the determined allocation.

[0169] According to one embodiment, a communication device is provided, comprising: a receiver configured to receive PMS information related to a PMS and PMS PNF from a PMS management system, where the signaling includes PMS capability disclosure, PMS status, PMS-PNF notifications and alarms; and a controller configured to verify and optimize deployment and operation of a telecommunication network service (NS) based on the PMS / PMS-PNF information.

[0170] According to another embodiment, a method for verifying and optimizing deployment and operation of telecommunication network services (NS) is provided, the method including the steps of receiving a request to deploy or update an NS or VNF generated from an OSS / BSS or due to LCM operation, receiving (from a manager) and publishing and translating (to the OSS / BSS) information regarding programmable metasurface capabilities and programmable metasurface states, validating the received input to comply with PMS-aware policies, determining function deployment and resource allocation according to the validation results, PMS parameters and PMS-aware policies, and interacting with an infrastructure manager to allocate correct resources and perform function deployment.

[0171] According to various embodiments, a verification method for verifying NS requirements based on PMS information is provided, including:

[0172] Processing of information related to PMS Processing NSD validation rules (e.g., deployment flavors, affinity and anti-affinity rules, and NS policies) · Treatment of NSD with PMS PNF - Performing NSD verification (e.g. when installing NSD or during LCM operation) -Disclosure of verification results to OSS / BSS - Receiving NSD information from OSS / BSS taking into account PMS descriptors Further, according to various embodiments, a resource allocation method is provided for determining physical and virtual resource allocation and VNF / PNF deployment based on PMS information, the method comprising: processing information relating to the PMS; Further, according to various embodiments, a method is provided for enabling communication between an orchestrator and a PMS manager, and between the orchestrator and an OSS / BSS, to reserve / onboard a PMS within a network orchestrator and to register a management system for the PMS, the method including:

[0173] Storage and processing of information regarding PMS connection points and PMS management and control systems Exposing such information to other management systems within the Orchestrator -Incorporating PMS resources into telecom orchestration systems ·Storage and processing of information related to the PMS -PMS resource reservation / registration in network orchestration system · Enabling PMS notification management and monitoring -PMS notifications and alerts published to OSS / BSS The above method is Providing a mechanism for tailoring metasurfaces as programmable telecommunications infrastructure resources.

[0174] Providing advanced orchestration mechanisms and interactions with OSS / BSS (the entities that typically provide policies and / or requirements for network services) to jointly optimize telecommunication network operations taking into account metasurfaces.

[0175] It is not limited to one orchestration framework like ETSI NFV's NFV-MANO, but can be applied to other designs like O-RAN based solutions.

[0176] Allows flexibility as to how the use of metasurfaces can be further optimized taking into account mobile network behavior.

[0177] · Enables uniform management and orchestration of all types of programmable resources from a single logical entity.

[0178] · Applicable to multi-technology PMS environments.

[0179] Covers both indoor and outdoor PMS deployment scenarios.

[0180] The above approach therefore allows to enhance the orchestration mechanisms of network operators with methods, mechanisms and interfaces that allow to treat metasurfaces as telecommunication infrastructure resources. The walls of buildings can be used as infrastructure resources and managed uniformly by the network operator. This type of programmable infrastructure can be used to realize network services and can be part of a unified orchestration plane connected to an OSS / BSS. In particular, further network services can be designed using the PMS-PNF. The approach described above can be used in indoor and outdoor environments and can be used to implement industrial networks, mobile users, home networks, etc.

[0181] Although particular embodiments have been described, it should be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the disclosed embodiments as defined by the appended claims. The scope is therefore indicated by the appended claims, and all changes that come within the meaning and range of equivalents of the claims are therefore intended to be embraced.

Claims

1. A deployment control component of a communication system, comprising: a metasurface management interface configured to receive information regarding the presence and capabilities of programmable metasurfaces usable by the communication system; an interface configured to receive a request to provide a network service; a controller configured to ensure that the request complies with a placement policy, and if the request complies with the placement policy, to determine a placement of network functions of the communication system in response to the received information so as to comply with the placement policy, and to control communication system resources of the communication system in accordance with the determined placement for providing the network service; A deployment control component that includes

2. The deployment control component of claim 1 , wherein the deployment of the network function takes into account network function placement constraints and communication system resource requirements.

3. The deployment control component of claim 2 , wherein deploying the network function comprises implementing the network function by allocating at least one virtual and / or physical communication system resource at a geographic location.

4. The deployment control component of claim 1 , comprising a policy interface configured to receive the deployment policy.

5. 2. The deployment control component of claim 1, wherein the controller is configured to determine whether further network functionality is required to provide the network service, and if so, determine a deployment of the further network functionality, and control the communication system resources of the communication system to provide the further network functionality and the determined deployment.

6. The deployment control component of claim 5 , wherein the controller is configured to determine, based on the received information, whether the further network functionality is required.

7. The deployment control component of claim 5 , wherein the controller is configured to determine a placement of the further network function based on the received information.

8. The deployment control component of claim 6, wherein the controller is configured to determine placement of the further network function based on the received information.

9. the communication system is a mobile radio communication system and the communication system resources include at least a device for radio communication; and / or the communication system resources include the programmable metasurface; and / or The deployment control component of claim 1 , wherein the network functions are network functions for implementing a virtualized 5G core network and a virtualized 5G radio access network.

10. 1. A method for controlling deployment of a communication system, comprising: receiving information regarding the presence and capabilities of programmable metasurfaces usable by the communication system, said metasurface management interface of a deployment control component of said communication system; receiving, at an interface of the deployment control component, a request to provide a network service; a controller of the deployment control component ensuring that the request complies with a deployment policy, and if the request complies with the deployment policy, the controller determining a deployment of network functions of the communication system according to the received information so as to comply with the deployment policy; the controller controlling communication system resources of the communication system in accordance with the determined deployment to provide the network service; The method includes:

Images