COMMUNICATION SYSTEMS AND METHODS FOR USING PROGRAMMABLE METASURFACES - Patent application

Abstract

According to various embodiments, a communications system is described that includes a programmable metasurface configured to provide communications resources; and a metasurface virtualization component, wherein the metasurface virtualization component is configured to create a plurality of virtual programmable metasurfaces, each virtual programmable metasurface associated with a respective portion of the communications resources provided by the programmable metasurface, expose the virtual programmable metasurface to one or more management components as a resource for providing one or more communications functions, and, for each virtual programmable metasurface for which the one or more management components request the provision of a respective communications function, control the programmable metasurface to provide the requested communications function via the portion of the communications resources provided by the programmable metasurface associated with the virtual programmable metasurface.

Description

[Technical field]

[0001] The present disclosure relates to communication systems and methods for using programmable metasurfaces. [Background technology]

[0002] Modern communication systems include a large amount of communication system resources that may be used by multiple network slice instances and / or multiple management systems (e.g., multiple different tenants) to provide communication capabilities. Because the provision of communication system resources requires effort and cost, the communication system resources need to be used efficiently. One way to enable efficient use is the sharing of communication system resources. This is particularly relevant for programmable metasurfaces. Therefore, an approach that allows efficient and flexible sharing of programmable metasurfaces, for example sharing between multiple network slices or, in general, sharing between multiple management systems that may be associated with multiple different resource consumers (e.g., tenants), is desirable. Summary of the Invention

[0003] According to one embodiment, there is provided a communication system including a programmable metasurface and a metasurface virtualization component, the programmable metasurface configured to provide communication resources, the metasurface virtualization component comprising: creating a plurality of virtual programmable metasurfaces, each virtual programmable metasurface associated with a respective portion of the communications resources provided by the programmable metasurface; exposing the virtual and programmable metasurface as a (e.g., virtual) resource to one or more managing components to provide one or more communication functions; and for each virtual programmable metasurface for which one or more managing components are requesting the provision of a respective communication function, controlling the programmable metasurface to provide the requested communication function using a portion of the communication resources provided by the programmable metasurface associated with the virtual programmable metasurface; , as configured.

[0004] According to a further embodiment, there is provided a method for using a programmable metasurface in accordance with the communication system described above. [Brief description of the drawings]

[0005] In the drawings, like reference characters generally refer to the same parts consistently through different views. The drawings are not necessarily drawn to scale, and instead, emphasis is generally placed upon illustrating the principles of the invention. In the following description, various aspects are described with reference to the following drawings:

[0006] [Figure 1] 1 illustrates a mobile wireless communication system. [Diagram 2]1 illustrates an architecture that includes a Network Functions Virtualisation Management and Orchestration (NFV-MANO) architectural framework. [Diagram 3] It illustrates a VNF sharing scenario where a Network Service (NS) is shared between two different tenants. [Figure 4] It illustrates a sharing scenario in which two network services are shared between two network slices subnet instances. [Diagram 5] 1 illustrates network slicing for 3GPP from a management perspective. [Figure 6] Illustrates slice management from a MANO perspective. [Figure 7] The figure shows a programmable metasurface (PMS). [Figure 8] The architecture includes a PMS-Hypervisor (PMS-H) 801. [Figure 9] The PMS Hypervisor (PMS-H) is shown in detail. [Figure 10] 1 illustrates the shared use of one or more PMSs by two network slices or tenants. [Figure 11] 1 illustrates one example of slice management in a PMS-enabled system. [Figure 12] 1 illustrates vPMS migration operations. [Figure 13] Illustrates the addition of PMS management functionality through additional slice subnet management domains. [Figure 14] 1 illustrates an alternative approach for adding PMS virtualization functionality to a slice management system. [Figure 15] 1 shows a flow diagram of creating a vPMS for a network slice. [Figure 16] 1 shows a flow diagram for disabling vPMS. [Figure 17] It shows a variation of the architecture that includes a PMS hypervisor. [Figure 18] 1 illustrates a communication system according to one embodiment. [Figure 19] 1 shows a flowchart illustrating a method for using a programmable metasurface in a communication system. 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. The various aspects of the present disclosure are not necessarily mutually exclusive, as some of the aspects of the present disclosure may be combined with one or more other aspects of the present disclosure to form new aspects.

[0008] Below, various examples are described that correspond to several aspects of the present disclosure.

[0009] Example 1 is a communication system described below with reference to FIG.

[0010] Example 2 is the communication system of example 1, wherein the communication resources for communicating by the programmable metasurface include a subset of resources, such as frequency ranges, time slots, and / or meta-atoms of the programmable metasurface.

[0011] Example 3 is the communication system of example 1 or example 2, wherein the virtual programmable metasurface is associated with a plurality of different portions of the plurality of communication resources provided by the programmable metasurface.

[0012] Example 4 is the communication system of any one of Examples 1 to 3, wherein the plurality of communication resources includes a plurality of time slots for communicating via the programmable metasurface, and the metasurface virtualization component is configured to ensure that a plurality of communication functions required to be provided by different virtual and programmable metasurfaces of the plurality of virtual and programmable metasurfaces are provided by different portions of the plurality of communication resources provided by the programmable metasurface by time multiplexing.

[0013] Example 5 is the communication system of any one of Examples 1 to 4, wherein the plurality of communication resources includes frequency ranges, and the metasurface virtualization component is configured to ensure that communication functions required to be provided by different virtual and programmable metasurfaces of the plurality of virtual and programmable metasurfaces are provided by different portions of the plurality of communication resources that the programmable metasurfaces provide by frequency multiplexing.

[0014] Example 6 is the communication system of any one of Examples 1 to 5, wherein the metasurface virtualization component is configured to create at least one of the plurality of virtual and programmable metasurfaces based on respective requests from one or more managing components to create the plurality of virtual and programmable metasurfaces.

[0015] Example 7 is the communication system of Example 6, wherein the metasurface virtualization component is configured to associate at least one of the plurality of virtual programmable metasurfaces with communication resources provided by the programmable metasurface to meet requirements specified in the claim.

[0016] Example 8 is the communication system of any one of Examples 1 to 7, wherein the metasurface virtualization component is configured to, for at least one of the plurality of virtual and programmable metasurfaces, change an association between at least one of the virtual and programmable metasurfaces and a communication resource provided by the programmable metasurface (e.g., managed by the metasurface virtualization component).

[0017] Example 9 is the communication system of any one of Examples 1 to 8, the communication system including a plurality of programmable metasurfaces, and the metasurface virtualization component is configured to create a plurality of virtual programmable metasurfaces, whereby each virtual programmable metasurface is associated with a respective portion of the communication resources provided by the plurality of programmable metasurfaces, and at least one of the virtual programmable metasurfaces is associated with the communication resources provided by a different programmable metasurface of the plurality of programmable metasurfaces.

[0018] Example 10 is the communication system of Example 9, in which the metasurface virtualization component is configured to change, for at least one of the plurality of virtual and programmable metasurfaces, an association of the at least one of the plurality of virtual and programmable metasurfaces with the communication resources provided by the plurality of programmable metasurfaces (e.g., based on a plurality of different inputs, such as a policy, failure to meet a threshold, system load, environmental conditions, etc.), thereby increasing or decreasing an amount of communication resources provided by one of the plurality of programmable metasurfaces associated with at least one of the plurality of virtual and programmable metasurfaces. When an amount of communication resources provided by the plurality of programmable metasurfaces associated with at least one of the plurality of virtual and programmable metasurfaces decreases, an amount of communication resources provided by other of the plurality of programmable metasurfaces associated with at least one of the plurality of virtual and programmable metasurfaces may increase accordingly (i.e., to compensate for the decrease in communication resources provided by the plurality of programmable metasurfaces associated with at least one of the plurality of virtual and programmable metasurfaces).

[0019] Example 11 is the communication system of any one of Examples 1 to 10, wherein the metasurface virtualization component is configured to expose the programmable metasurface and capabilities of the virtual programmable metasurface to one or more management components.

[0020] Example 12 is the communication system of any one of Examples 1 to 11, wherein the metasurface virtualization component is configured to assign each virtual and programmable metasurface to a respective tenant managed by a respective management system of the one or more management systems.

[0021] Example 13 is the communication system of any one of Examples 1 to 12, wherein the communication system includes a plurality of network slices, and at least a portion of the one or more management systems are management systems for a plurality of different network slices.

[0022] Example 14 is the communication system of example 13, wherein the metasurface virtualization component is configured to assign a plurality of virtual and programmable metasurfaces to a plurality of different network slices.

[0023] Example 15 is a method for using a programmable metasurface in a communication system, as described below with reference to FIG.

[0024] It should be noted that one or more of the features of any of the above examples may be combined with any of the other examples. In particular, examples described in the context of a device are valid for the method as well.

[0025] According to further embodiments, a computer program and computer readable medium containing instructions, when executed by a computer, causes the computer to perform the method of any of the examples above.

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

[0027] FIG. 1 shows a mobile wireless communication system 100 configured in accordance with 5G (Fifth Generation) as defined, for example, in a simplified form by 3GPP (Third Generation Partnership Project).

[0028] The mobile radio communication system 100 includes a mobile radio terminal device 102, such as user equipment (UE), which is also called a subscriber terminal and forms the terminal side, while the other components of the mobile radio communication system 100 described below are part of the mobile communication network side, i.e. part of a mobile communication network (such as a Public Land Mobile Network (PLMN)).

[0029] Furthermore, the mobile wireless communication system 100 includes a Radio Access Network (RAN) 103, which may include a number of radio access network nodes, i.e., base stations configured to provide radio access according to 5G (Fifth Generation) radio access technology (5G New Radio). It should be noted that the mobile wireless communication system 100 may also be configured according to LTE (Long Term Evolution) or other mobile wireless communication standards (e.g., non-3GPP access such as WiFi), but 5G is used herein as an example. Each radio access network node may provide wireless communication with the mobile wireless terminal device 102 over a radio interface. It should be noted that the radio access network 103 may include any number of radio access network nodes.

[0030] The mobile radio communication system 100 further includes a Core Network (5GC) 119, which includes an Access and Mobility Management Function (AMF) 101 connected to the RAN 103, a Unified Data Management (UDM) 104, and a Network Slice Selection Function (NSSF) 105. In this specification and in the following examples, the UDM may further comprise an actual UE subscription database, known for example as a Unified Data Repository (UDR). The Core Network 119 further includes an Authentication Server Function (AUSF) 114, a Policy Control Function (PCF) 115, and an Application Function (AF) 120.

[0031] The core network 119 may have multiple core network slices 106 and 107, and for each core network slice 106 and 107, an operator (also referred to as MNO for Mobile Network Operator) may create multiple core network slice instances 108 and 109. For example, the core network 119 includes a first core network slice 106 with three core network slice instances 108 for providing Enhanced Mobile Broadband (eMBB) and a second core network slice 107 with three core network slice instances (CNI) 109 for providing Vehicle-to-Everything (V2X).

[0032] Typically, when deploying (i.e., creating) a core network slice, network functions (NFs) are instantiated or referenced (if already instantiated) to form a core network slice instance, and the network functions belonging to the core network slice instance are configured with a core network slice instance identification information.

[0033] Specifically, in the illustrated example, each instance 108 of the first core network slice 106 includes a first Session Management Function (SMF) 110 and a first User Plane Function (UPF) 111, and each instance 109 of the second core network slice 107 includes a second Session Management Function (SMF) 112 and a second User Plane Function (UPF) 113. The SMFs 110 and 112 are session management functions for processing PDU (Protocol Data Unit) sessions, i.e., creating, updating, and deleting PDU sessions, and managing session contexts using the User Plane Function (UPF).

[0034] The RAN 103 and the core network 119 form the network side of a mobile radio communication system, in other words a mobile radio communication network. The mobile radio communication network and the mobile terminals accessing the mobile radio communication network together form the mobile radio communication system.

[0035] Similar to the core network 119, the RAN 103 may also be sliced, i.e., may include multiple RAN slices. RAN slices and core network slices 106, 107 may be grouped to form network slices.

[0036] In the following, A "network slice" (or simply, "slice") generally refers to a core network slice, and may also include a RAN slice or even a transport network slice. In other words, each network slice may be composed of network slice subnets, such as a RAN subnet, a core network subnet, and a transport subnet.

[0037] S-NSSAI (Single Network Slice Selection Assistance information) identifies a network slice, and the S-NSSAI - Slice / Service type (SST), which refers to the expected network slice behavior in terms of functions and services; - Slice Differentiator (SD), which is selective information that complements the slice / service type and distinguishes between multiple network slices of the same slice / service type; It consists of:

[0038] A network slice instance (NSI) is identified by an NSI ID.

[0039] The NSSAI may include one or more S-NSSAIs.

[0040] The permitted NSSAI is, for example, an NSSAI provided by a serving PLMN (Public Land Mobile Network) during a registration procedure, and indicates the value of the S-NSSAI that the network permits for a UE in the serving PLMN for the current registration area.

[0041] A configured NSSAI is an NSSAI provisioned in the UE, which may be applicable to one or multiple PLMNs.

[0042] The requested NSSAI is the NSSAI that the UE provides to the network upon registration in order to establish a PDU session to the requested network slice.

[0043] The mobile wireless communication system 100 may further include an OAM (Operation, Administration and Maintenance) function (or entity) 116, implemented for example by one or more OAM servers connected to the RAN 103 and the core network 119 (although connections are not shown for simplicity). The OAM 116 may include a Management Data Analytics Service (MDAS). The MDAS may provide, for example, analytical reports on the load of the network slice instance. Various factors may affect the load of the network slice instance, such as, for example, the number of UEs accessing the network, the number of QoS flows, and resource utilization of different NFs associated with the network slice instance.

[0044] Additionally, the core network 118 includes a Network Repository Function (NRF).

[0045] The core network 119 may further include a Network Data Analytics Function (NWDAF) 117. The NWDAF is responsible for providing network analysis and / or predictive information upon request from the network functions.

[0046] Various network functions may be implemented in dedicated hardware, i.e. in so-called ACTA (Advanced Telecommunications Computing Architecture) devices. This implementation means that the network functions are implemented as physical network functions that are located in dedicated hardware. In that case, the software for implementing the network functions is tightly coupled to the hardware.

[0047] However, it may also be desirable to implement network functions as software applications running on virtual machines (and / or containers) deployed on non-specialized hardware, i.e., COTS (Commercial off-the-shelf) servers (i.e., general purpose or open computing platforms, i.e., general purpose or open computing devices). This implementation is made possible by using virtualization technologies (e.g., hypervisors, operating system (OS) containers, etc.), which may be used to deploy network functions (e.g., SMF, PCF, etc.) as software applications running on virtual machines (VMs) and / or containers. These network functions are referred to as Virtual Network Functions (VNFs).

[0048] Management and orchestration (MANO) is a key element of the ETSI (European Telecommunications Standards Institute) network functions virtualization (NFV) architecture. NFV-MANO is an architecture framework that orchestrates the lifecycle management of network resources and virtual network functions (VNFs) and network services for cloud-based applications. Therefore, NFV-MANO is critical to ensure large-scale, rapid, and reliable deployment of NFV. NFV-MANO includes several functional blocks, such as NFV Orchestrator (NFVO), VNF Manager (VNFM), Virtual Infrastructure Manager (VIM), and Container Infrastructure Service Management (CISM).

[0049] 2 shows an architecture 200 that includes a simplified version of the Network Functions Virtualisation Management and Orchestration (NFV-MANO) architectural framework. Architecture 200 includes a collection of functional blocks and functions, data repositories that those functional blocks use, and reference points and interfaces through which those functional blocks exchange information for the purpose of managing and orchestrating NFV.

[0050] The architecture 200 includes an OSS / BSS (operations support system and business support system) 201 and an NFV-MANO, which includes an NFVO 202, a VNFM 203, a VIM 204, a CISM (container Infrastructure Service Management) 205, and a CCM (CIS Cluster Management) 217.

[0051] The NFVO 202 manages the Network Services (NS) 206, which in this example includes virtualized functions: AMF 208, SMF 209, and PCF 210, and RAN components 207. A Network Service (NS) is a composition of physical and virtual network function(s) and / or service(s) defined by functional and behavioral specifications.

[0052] The architecture 200 further includes a Network Function Virtualization Infrastructure (NFVI) 211, which includes hardware and software components that create the virtualized environment in which the VNFs are deployed.

[0053] In this example, the AMF 208, SMF 209 and PCF 210 are implemented as VNFs, i.e. NFs that may be located in an NFVI 211. The SMF 209 is implemented by a container 212 running in a virtual machine, the PCF 210 in a virtual machine 213 and the AMF 208 in a container 214, all of which run in a COTS server 215. The RAN components 207, in contrast, are implemented in an ATCA device 216, i.e., are physical network functions.

[0054] The NFVO 202 manages the NS lifecycle and coordinates the overall resource utilization of the NS, the VNF lifecycle is supported by the VNFM 203, and the NFVI resource management is supported by the VIM 204, CISM 205, and CCM 217 to ensure optimized allocation of required resources and connectivity.

[0055] The VNFM 203 is responsible for managing the lifecycle of a VNF, regardless of whether the VNF is deployed in a VM or a container.

[0056] The VIM 204 is typically responsible for controlling and managing the compute, storage, and network resources of the NFVI within an operator's infrastructure domain. The CISM 205 is responsible for orchestrating and managing container infrastructure services and the containerized workloads instantiated by those container infrastructure services. The CCM 217 is responsible for managing container clusters.

[0057] With regard to Network Functions, it should be noted that 3GPP is responsible for managing and configuring Network Functions (NFs) and the interactions between NFs, but 3GPP is not responsible for managing the virtualized network function aspects. In fact, the 3GPP functions remain the same from an application perspective, regardless of whether a network function is virtualized or not. From an ETSI NFV perspective, NFV-MANO handles the orchestration and management of both the virtualized resources and the VNFs being deployed, remaining independent of the actual VNF application (e.g., if the VNF application is a virtualized PCF or a virtualized SMF).

[0058] With regard to VNF management, VNF instantiation as well as other life cycle management (LCM) operations such as updates, scaling, etc., are performed by the NFV-MANO (NFVO / VNFM / CISM / VIM), and VNF configuration may be performed by the element manager through interaction with the OSS.

[0059] A VNF may be part of multiple network services, which may be shared among multiple network slices (or multiple network slice subnets) according to 3GPP and NFV-MANO. Furthermore, in the case of NFV, multi-tenancy is possible without considering 3GPP network slices, i.e., one NFV environment may be shared between multiple tenants (in the sense of multi-tenancy), and a service provider can offer NFV to multiple tenants. Tenants include, but are not limited to, network slices, network services, etc. Multiple users consume services from the same NFV-MANO or from a dedicated NFV-MANO. Different sharing scenarios can be realized without referring to the network slice mechanism defined by 3GPP and the correlation between multiple shared resources with specific network slice descriptors (NSDs) or identifiers (e.g. NSI-IDs).

[0060] 3 illustrates a sharing scenario where, among other things, a network service 301 is shared between two tenants 302 and 303. Different VNFs that are parts of the shared network service are also shared between different tenants 302 and 303.

[0061] FIG. 4 illustrates a sharing scenario in which two network services 401 and 402 are shared between two network slice subnet instances 403 and 404.

[0062] With respect to the touch point between the 3GPP network slice management model and the ETSI NFV management model, one or more network slice subnet instances are mapped to one or more shared network services.

[0063] Regarding the deployment of network slices using NFV Network Services (NS), Multiple NSs as a deployment unit for one network slice instance, where NFV provides connectivity; Multiple NSs as the unit of deployment for a network slice instance, without NFV provided connectivity for inter network slice subnetworks; A single NS as the unit of deployment for a given network slice instance; Management of network slice instance transport network connections in case of multi-site connection services; There are various options such as:

[0064] Figure 5 illustrates a network slice for 3GPP from a management perspective.

[0065] The Communication Service Management Function (CSMF) 501 is responsible for translating communication service requirements into network slice requirements.

[0066] The Slice Management Function (NSMF) 502 helps in the end-to-end management and orchestration of NSIs (network slice instances) 503, i.e., realization of network slices.

[0067] Network Slice Subnet Management Functions (NSSMFs) 504, 505, and 506 are responsible for managing and orchestrating the sub-network slice instance 503, i.e., network slice subnet-instances (NSSIs), in a particular domain. For example, Transport Network Slice Subnet Instance (TN-NSSI) 507 is a realization of a network slice in the transport domain, and Core-NSSI 508 is a realization of a network slice in the core domain. NSI 503 is a composition of multiple NSSIs 507, 508, and 512.

[0068] The NSSMFs 504, 505, and 506 are connected to respective domain controllers 509, 510, and 511, which are responsible for the relevant control and management plane operations within their respective domains.

[0069] FIG. 6 illustrates slice management from the MANO perspective.

[0070] As described with reference to Figure 5, there is an NSMF 601 and multiple NSSMFs 602. Additionally, there is an orchestration system and OSS 603 that manages the VNFs and the NFVI 605, as described above.

[0071] 6, the OSS 603 may configure application aspects of a shared VNF 606 according to normal procedures via an element manager (EM) 611. A VNF 607 belonging to a first communication network 608 (e.g., of a first tenant) and a VNF 609 belonging to a second communication network 610 are also connected to the shared VNF 606.

[0072] The orchestration system 604 (also referred to as the orchestrator) controls the deployment and management of Virtualized Network Functions (VNFs) as well as Physical Network Functions (PNFs).

[0073] According to various embodiments, the communication system includes, among other things, Programmable Metasurfaces (PMS). The term PMS may be understood to include any type of metasurface variation and technology, such as Smart Mirror, Spatial Microwave Modulator (SMM), Reconfigurable intelligent Surfaces (RIS or RSI), and Large Intelligent Surface (LIS).

[0074] FIG. 7 shows a programmable metasurface (PMS) 700.

[0075] A programmable metasurface (PMS) 700 includes an arrangement (e.g., a matrix) of switchable elements 701 (denoted as "meta-atoms") that provide the ability to manipulate radio signals, such as steering radio beams in a specific direction, or to absorb radio waves entirely.

[0076] An arrangement of meta-atoms 701 (or "tiles") forms an actual (physical) metasurface, which may be attached to indoor and / or outdoor walls. The PMS 700 further includes a PMS controller function 702, i.e., a controller (e.g., implementing an IoT (Internet of Things) gateway), which implements the control layer of the PMS 700 by means of multiple connections 703, e.g., providing tile central power supply and inter-tile communication, enabling communication from tiles to the outside world (particularly to a PMS manager), and, optionally, environmental sensing duties. For example, the PMS controller function 702 is a dedicated programmable hardware device (e.g., located next to the metasurface or tightly coupled to it).

[0077] Metasurfaces make it possible to provide a type of communication system node that utilizes a smart wireless surface using thousands of small antennas or meta material elements (i.e., meta-atoms 701) that dynamically shape and control wireless signals in a goal-oriented manner. The metasurfaces may be used to optimize bandwidth utilization and optimize the signal received at the receiver by exploiting scattering and multipath phenomena through corresponding control of the metasurface. The desired and supported electromagnetic functions of the metasurface are achieved by corresponding switch state configuration settings for the meta-atoms. This provides the ability to steer a beam in a certain direction or completely absorb an incoming wireless signal. In particular, metasurfaces can mitigate undesirable path loss effects in real-world wireless communications and optimize MIMO (multiple input multiple output) capacity by grooming wave propagation to achieve constructive superposition at the user device, optimizing its power delay profile (PDP) and avoiding the adverse effects of multipath fading.

[0078] Similar to the sharing of VNFs and network services between multiple tenants (see FIG. 3) and multiple network slices or network slice subnets (as in FIG. 4), the sharing of metasurfaces between multiple tenants or multiple network slices or multiple network slice subnets (which again leads to sharing between multiple slices when the multiple subnets belong to multiple different slices) makes it possible to increase the efficiency of utilization of this particular resource, i.e., the efficiency of utilization of the metasurface.

[0079] According to various embodiments, to enable such sharing in an efficient manner, so-called virtual walls (i.e., metasurface abstractions) are created by the components, and in the following description, we provide several examples of approaches for managing network slice instances to run on top of shareable programmable metasurfaces (PMS) and a PMS hypervisor (PMS-H).

[0080] It should be noted that a network slice instance is a realization of a network slice. For example, it is possible to provide a generic description of a network slice (e.g., two routers operating with a VLAN (virtual local area network) connection between the two routers). A domain controller may then take this description and create the correct configuration for those two routers, perform resource allocation, etc., and then manage said realization of a network slice, called a "network slice instance." This is similar to the relationship between a VNF and a VNF instance. A VNF may be understood as an abstract definition and description of what the VNF is, while a VNF instance is a particular instantiation (i.e., an instance) of such a type of VNF.

[0081] The PMS-H creates and manages programmable metasurface abstractions, shown in the examples below, as (programmable) virtual walls (vPMS, i.e. virtual programmable metasurfaces, i.e. virtual metasurface resource elements). The vPMS is also programmable by the management system on a per-tenant or per-slice basis. The PMS-H thus introduces functionality that allows multitenancy and slicing on multiple physical PMS resources, including, for example, interfaces between the PMS-H and / or more network slice management systems or orchestration systems. The PMS-H may, for example, be responsible for vPMS Lifecycle management (LCM), handle resource and service separation, support additional functionality such as migration of the vPMS to other PMSs, and may interact with one or more other PMS-Hs to support multi-technology operations (e.g., migration). Additionally, it may provide functionality within the respective telecom operator slicing management system to manage and optimize the deployment and operation of multiple network slice instances (NSs) by taking into account the shared PMS operating environment.

[0082] A network function may run on top of a vPMS (and in particular configure the vPMS accordingly), i.e. may use the vPMS to perform communication functions. Such a network function is denoted as a vPMS-NF and may be a PNF or a VNF.

[0083] FIG. 8 illustrates an architecture including a PMS-Hypervisor (PMS-H) 801.

[0084] PMS-H 801 is connected to a programmable metasurface 802 (in the "southbound") and to two PMS managers (in the "northbound") 803 and 804. Each PMS manager 803 and 804 is in turn connected to a respective network service management or orchestration system 805 and 806 for a respective tenant or NSSMF / NSMF 810 and 811.

[0085] The PMS-H 801 creates a number of virtual walls (vPMS) 807, each associated with communication resources provided by the PMS 802. In this example, a first one of the virtual walls is associated with, for example, a first subset 808 of the meta-atoms of the PMS 802, and a second one of the virtual walls is associated with, for example, a second subset 809 of the meta-atoms. The communication functions provided by the virtual walls (as required by the management or orchestration systems 805 and 806) (typically including data transmission operations, etc.) are provided by the communication resources associated with the virtual walls. These may be subsets of the meta-atoms of the PMS 802, as illustrated in this example, but may also be time slots or frequency bands provided by the PMS 802 (i.e., the virtual walls may also be provided by the PMS by time or frequency multiplexing, or by phase manipulation).

[0086] The PMS-H 801 may be understood to be similar to an OS hypervisor in the sense that it provides a resource sharing mechanism by implementing virtual entities on top of physical entities. Specifically, the PMS-H 801 creates virtual programmable walls (vPMSs), which may be assigned to a tenant or NSSI (i.e., resource consumer). The PMS-H 801 enables PMS resource sharing and ensures isolation, and the PMS-H 801 is responsible for ensuring isolation between different vPMSs at the physical layer.

[0087] The PMS-H 801 may be embedded in the PMS manager functionality or may be an independent entity exposing services to multiple managers dedicated to different tenants. The PMS-H 801 may keep the state of the allocated resources per NSSI (supporting appropriate identification mechanisms) or per tenant. The PMS-H 801 manages all PMS resources and monitors PMS operations. The PMS-H approach may be applied in sharing scenarios even when considering multitenancy without necessarily using 3GPP slicing.

[0088] FIG. 9 shows the PMS Hypervisor (PMS-H) 900 in more detail.

[0089] The PMS-H 900 includes a northbound interface 901 that connects to control and management systems 913 (e.g., PMS managers 803 and 804, orchestration and management systems 805 and 806, and tenant or NSSI management systems).

[0090] Additionally, the PMS-H 900 includes a northbound interface 914 that connects to one or more PMSs 904 (possibly of multiple different technologies), such as, for example, PMS 802 .

[0091] The (functional) core of the PMS-Hypervisor 900 is A PMS Virtualization layer 916, o The PMS Virtualization Layer 916 creates and manages the vPMS, i.e., creates and manages an abstract representation of the PMS resources; o A virtual wall (vPMS) may be associated with one or more types of PMS resources (i.e. communication resources provided by one or more PMS) (e.g. separation of resources (i.e. multiplexing) may be performed in spatial and time domains, or spatial and frequency domains, etc.); A PMS virtualization layer 916; ● PMS and vPMS logger 902 for logging information; ● PMS and vPMS notifier 903 for notifications; ● A PMS and vPMS monitoring function 904 that correlates data and statistics (e.g., performance metrics, faults, etc.) received from one or more vPMS and PMS 904; A PMS and vPMS policy management function 905 that hosts policy functions used to interpret, for example, slice specific vPMS policies; ● PMS and vPMS security features 906; ● PMS power management optimization function 907 and a resource mapping function 908 for mapping resources from a PMS to a vPMS, where a vPMS may be mapped to more than one PMS (possibly of multiple different technologies); ● A resource scheduling function 909 (supporting vPMS multiplexing) that introduces a control mechanism regarding the resource sharing mechanism used (e.g. Round Robin, DRR (Deficit Round Robin), WRR (Weighted Round Robin), WFQ (Weighted Fair Queuing), static mechanisms, etc.); a vPMS isolation function 910 that preserves isolation between vPMSs in different domains while ensuring that there are no contentions due to multiplexing; ● vPMS (lifecycle) management functionality 911 (to create, delete, scale, migrate, etc. vPMS) and ● PMS configuration and management functions 912; ● Additional features such as virtual wall snapshots, high availability, and auto-repair. Includes.

[0092] A northbound interface 901 (e.g., an API (Application Programming Interface) including an API gateway 915 supported by the PMS-H 900) ● Expose functions related to vPMS management, ● Expose inventory services for northbound physical and virtual PMS resources; ● For example, it is compliant with SDK (software development kit) and REST (representational state transfer), etc. ● Handle slice service requests such as vPMS creation / deletion / migration, etc. ● Disclosure of PMS capabilities and capacity management; • Translates configuration commands received from the PMS technology-agnostic northbound interface (N-API) into the actual configuration that is applied to the PMS; • Transforming the high level requirements received by PMS N-API into actual or recommended virtual wall representations; ● N-API used by dedicated PMS management systems (e.g. acting as a domain controller for the NSSMF); Exposing performance and / or fault management data that is filtered based on virtual walls per slice.

[0093] Examples of information communicated using the northbound interface include: ■ vPMS capabilities for vPMS capacity management (similar to PMS), ■ vPMS tenant information (similar to PMS), ■ id, ■ Owner name (owner-name), ■ owner-description, ■ vPMS Tenant Policy (which applies to all of the vPMS for this tenant / slice), ■ vPMS Information [List], ■ vPMS-id, ■ vPMS location (vPMS-location), ■ vPMS policy, ■ vPMS policy id (vPMS-policy-id), ■ vPMS policy description (vPMS-policy-description), ■ vPMS monitoring information, ■ vPMS virtual wall LCM (creation, start, stop, update / scale, release, etc.) ■ vPMS requirements (used to instantiate the vPMS); ■ Technology domain, ■ realization-requirements (e.g., time-domain, space, frequency, phase, etc.); ■ reservation-duration, ■ Start of reservation, ■ Security authentication, ■ Function, It is.

[0094] These attributes are only examples and may include more extensive features (extensions). PMS-H also exposes similar information for PMS (owner, resource, etc.).

[0095] Southbound interface 902 (e.g., API) · Implement actual PMS configuration and management; Collecting and / or analysing performance and / or fault management data from one or more PMS 904; Depends on the PMS technology (e.g. in the form of drivers, etc.).

[0096] Through virtual walls, the PMS 904 may then be shared among multiple network services (and thus by multiple tenants and / or by multiple slices if the PMS 904 belongs to multiple different tenants and / or slices).

[0097] 10 illustrates the shared use of one or more PMSs 1015 by two network slices or tenants 1004 and 1005, with each PMS 1015 providing a respective network service 1001 and 1002 to a respective UE 1006 and UE 1007. Each network service 1001 and 1002 is managed by a respective network service orchestration and management system 1013 and 1014.

[0098] Similar to FIG. 2 , each of the first network service 1001 and the second network service 1002 is provided by various respective components 1003, including one or more distributed and centralized components, multiple radio units, and core network components such as RAN components, AMF, SMF, and PCF, which may provide physical and / or virtual network functions.

[0099] Furthermore, the first network service 1001 hosts a first vPMS-NF 1008 running on a first vPMS 1009 that the PMS hypervisor 1010 creates from the PMS 1015 (i.e., by allocation of communication resources of the PMS 1015 for the first network service 1001), and the second network service 1002 hosts a second vPMS-NF 1011 running on a second vPMS 1012 that the PMS hypervisor 1010 creates from the PMS 1015 (i.e., by allocation of communication resources of the PMS 1015 for the second network service 1002).

[0100] FIG. 11 illustrates the PMS slice management.

[0101] As shown in Figure 11, components 1101 to 1105 including the vPMS 1101 provide a network service. The vPMS 1101 and the RU 1102 belong to the RAN-NSSI 1106 (i.e., the RAN domain NSSI). The core network component 1105 belongs to the CN-NSSI 1108 (i.e., the core network domain NSSI). The connections between the components 1101 to 1105 belong to the TN-NSSI 1107 (i.e., the transport domain NSSI). The NSSIs 1106, 1107, and 1108 are part of the NSI 1109.

[0102] As in FIG. 5, the NSI 1109 is managed by the NSMF 1110, and the NSSIs are managed by corresponding NSSMFs 1111, 1112, and 1113.

[0103] The components 1101 to 1105 are managed by a PNF / VNF orchestration system that communicates with PMS domain controllers such as a core domain controller 1115, a RAN domain controller 1116, and a PMS manager 1117 that communicates with a PMS-H 1118 that creates a vPMS from one or more PMSs 1119, for example as described above. The OSS controls the PNF / VNF orchestration 1114 and interacts with the NSMF 1110.

[0104] From the NFV-MANO perspective, there is no entity that manages the mapping of VNFs / PNFs and physical resources to NSSIs. NFV-MANO is slice-unaware, only NFV network services. PMS managers may or may not be slice-aware.

[0105] Slice awareness or slice unawareness depends on which management level the mapping is held at. The PMS-H is slice unaware, but a vPMS may be part of one or more network services, which are part of one or more NSIs. Under a network slice, an NSSI has multiple associated vPMSs. Each vPMS may be built with different physical layer characteristics. Sharing of vPMSs (virtual walls) is also possible between different NSSIs.

[0106] FIG. 12 illustrates the vPMS migration operation.

[0107] In the example of FIG. 12, a first PMS-H 1201 creates a first vPMS 1203 and a second vPMS 1204 from a first PMS 1206, and a second PMS-H 1202 creates a third vPMS 1205 from a second PMS 1207.

[0108] PMS-H 1201 and PMS-H 1202 may provide a function of vPMS migration. This means migrating a vPMS to another PMS (operating with the same PMS technology or with another PMS technology) while leaving the state and functionality of the vPMS unaffected. In this example, the second vPMS 1204 is first provided by the first PMS 1206 (i.e., by allocating the communication resources provided by the first PMS 1206 to the second vPMS 1204) and then by the second PMS 1207 (i.e., by allocating the communication resources provided by the second PMS 1207 to the second vPMS 1204). PMS-HS 1201 and PMS-HS 1202 communicate accordingly to enable this function directly or in coordination with other management systems.

[0109] In general, transitioning means, for a virtual and programmable metasurface, decreasing the amount of communication resources provided by one of the programmable metasurfaces associated with the virtual and programmable metasurface and increasing the amount of communication resources provided by another of the programmable metasurfaces associated with the virtual and programmable metasurface.

[0110] Furthermore, each of PMS-H 1201 and PMS-H 1202 may provide a functionality of vPMS resource remapping, which means that each of PMS-H 1201 and PMS-H 1202 creates (instantiates) a vPMS, maps the created vPMS to one or more PMSs (i.e., assigns communication resources provided by one or more PMSs to the created vPMS), and then updates the mapping of vPMS to PMS by remapping to one or more different PMSs.

[0111] In this example, the third vPMS 1205 is first mapped to the second PMS 1207 and then remapped by the second PMS-H 1202 to the third PMS 1208. In general, changing the association of communication resources with virtual programmable metasurfaces.

[0112] The remapping and migration operations may be performed, for example, to enable fulfilling an incoming request for the creation of a management system. For example, a requested virtual and programmable metasurface may require certain communication resources (e.g., supporting a certain frequency range) that are not required for an already created virtual and programmable metasurface, and thus have the requirement to perform migration and / or remapping to free up appropriate communication resources that may then be used for the requested virtual and programmable metasurface.

[0113] It should be noted that a vPMS may be associated with communication resources from multiple PMSs (i.e., may be mapped to multiple PMSs by the PMS-H), i.e., a vPMS is not necessarily associated with communications from a single PMS (i.e., is mapped to a single PMS by the PMS-H).

[0114] Furthermore, based on events (such as calls to the PMS-H northbound interface), the vPMS may be scaled out / up and scaled in / down, i.e., the amount of communication resources allocated to the vPMS and provided by one or more PMSs may be increased or decreased (i.e., the number of meta-atoms allocated to the vPMS may be increased or decreased) by the PMS-H managing the vPMS. Depending on the PMS technology, scaling (e.g., allocating more atoms, allocating more frequencies, time, etc.) may be achieved using several different means.

[0115] In case of vPMS migration and / or resource re-mapping, communication between the PMS-H and the radio part of the mobile network controller also enables joint optimization of the overall communication (e.g. dynamically adjusting beamforming parameters at the mobile network's transmit antennas based on vPMS migration).

[0116] Figure 13 illustrates the addition of PMS virtualization functionality as described above with an additional management domain (i.e., subnet management function) in addition to the RAN, transport and core domains as described with reference to Figure 5, where the RAN NSSMF 1302 is responsible for slice management when considering RAN elements (VNFs, PNFs, antennas, etc.), the TN-NSSMF 1303 is responsible for slice management when considering transport network RAN ​​elements, and the CN-NSSMF 1304 is responsible for slice management when considering core network (CN) elements (VNFs, PNFs).

[0117] The additional domain 1301 is used to manage NSSI instances related to physical environments, such as when a programmable metasurface is part of such physical environment. In particular, the corresponding PHY_ENV-NSSMF 1305 is responsible for managing aspects of the LCM related to the PHY_ENV NSSI. The PHY_ENV-NSSMF 1305 can manage a subnet consisting of resources related to any type of environment, including the programmable metasurface, and may be used to support many additional use cases (e.g., sensing, etc.). Using the PHY_ENV-NSSMF, multiple different environment resources may be used to support multiple NSSIs (e.g., one NSSI optimized for sensing and one NSSI optimized for beamforming optimization). Also, multi-technology environments (e.g., including Wi-Fi) may be considered, as well as non-public networks.

[0118] Figure 14 illustrates an alternative approach where the subnet management of the physical environment is part of the RAN-NSSMF 1402. This means that the PHY-NSSMF functionality is incorporated into the RAN-NSSMF by extending the scope of the RAN-NSSMF (e.g. to take into account PMS type resources).

[0119] FIG. 15 shows a flow diagram 1500 for creating a vPMS for a network slice.

[0120] Included in the flow are an upper level orchestration system 1501 (such as OSS 1120 or RAN-NSSMF 1111), a domain management system 1502 (e.g., corresponding to PNF / VNF orchestration 1114 or PMS controller), a PMS-H 1503 (e.g., corresponding to PMS-H 1118), and a PMS 1504 (e.g., corresponding to PMS 1119).

[0121] At 1505 , the orchestration system 1501 sends a PMS capabilities & capacity request to the domain management system 1502 , which forwards the PMS capabilities & capacity request to the PMS-H 1503 at 1506 .

[0122] At 1507 , the PMS-H 1503 sends a corresponding response to the domain management system 1502 , which forwards the corresponding response to the orchestration system 1501 at 1508 .

[0123] At 1509, the orchestration system 1501 sends a request for creation of a vPMS to the domain management system 1502. The request may include vPMS requirements. At 1510, the domain management system 1502 responds to the request by initiating the creation of the vPMS and instructs the PMS-H 1503 accordingly.

[0124] At 1511, PMS-H 1503 parses the request for the vPMS. If resources are available and the request can be fulfilled, PMS-H 1503 creates the vPMS and associates it with an owner (e.g., a network slice in this example). Furthermore, PMS-H 1503 reserves communication resources of PMS 1504 for the vPMS and starts LCM (Lifecycle management) of the vPMS.

[0125] At 1512 , the PMS-H 1503 sends a response to the create request to the domain management system 1502 , which in turn forwards the response to the create request to the upper level orchestration system 1501 at 1513 .

[0126] At 1514 , the orchestration system 1501 sends a vPMS configuration request to the domain management system 1502 , which forwards the vPMS configuration request to the PMS-H 1503 at 1515 .

[0127] At 1516 , the PMS-H 1503 translates the configuration request into actual physical resource configuration commands and, at 1517 , performs the corresponding configuration of the PMS 1504 .

[0128] At 1518 , the PMS-H 1503 sends a response to the configuration request to the domain management system 1502 , which forwards the response to the configuration request to the higher level orchestration system 1501 at 1519 .

[0129] FIG. 16 shows a flow diagram 1600 for releasing a vPMS.

[0130] As in FIG. 15, an upper level orchestration system 1601, a domain management system 1602, a PMS-H 1603 and a PMS 1604 are included in the flow.

[0131] At 1605, the upper level orchestration system 1601 sends a request to delete the vPMS to the domain management system 1602. At 1606, the domain management system 1602 decides whether to release the vPMS, and in this example requests the PMS-H 1603 to release the vPMS at 1607.

[0132] At 1608, the PMS-H 1603 parses the request for the vPMS-id to be released (i.e., deleted), deletes the vPMS objects, updates local inventories accordingly, and returns the communication resources (allocated to the released vPMS) to the available pool of communication resources so that they may be reused for other vPMSs.

[0133] At 1609, the PMS-H 1609 performs physical resource configuration of the PMS 1604, for example, invalidating meta-atoms previously assigned and configured to the vPMS being released to conserve energy.

[0134] At 1610, the PMS-H 1603 sends a response to the release request to the domain management system 1602.

[0135] At 1611, the domain management system 1602 updates inventories for one or more NSs etc. according to the one or more NSs.

[0136] At 1612 , the domain management system 1602 forwards its response to the release request to the higher level orchestration system 1601 .

[0137] FIG. 17 shows several variations 1701-1704 of an architecture including a PMS-Hypervisor.

[0138] In a first variant 1701, the PMS-H 1705 communicates with an associated 3GPP Communication Management System (which does not have MANO).

[0139] In the second variation 1702, a MANO 1706 is further included.

[0140] In the third variation 1703, the PMS-H 1707 communicates with a 3GPP communication management system and also with an OSS 1708 external to the 3GPP communication system.

[0141] In a fourth variant 1704, the PMS-H 1709 communicates with an O-RAN management system involving a MANO 1710.

[0142] In particular, the use of the approaches described herein is not limited to one orchestration framework, such as ETSI NFV-MANO, but rather may be applied to other designs, such as in O-RAN based systems.

[0143] It should be noted that the PMS-H may be embedded (as software) into an existing PMS manager, or may be a separate entity that exposes services to multiple managers.

[0144] In summary, according to various embodiments, a communication system is provided as illustrated in FIG.

[0145] FIG. 18 illustrates a communication system 1800 according to one embodiment.

[0146] The communications system 1800 includes a programmable metasurface 1801 and a metasurface virtualization component 1802 configured to provide communications resources.

[0147] The metasurface virtualization component 1802 is configured to create a plurality of virtual and programmable metasurfaces, each virtual and programmable metasurface associated with a respective portion of the communication resources provided by the programmable metasurface 1801.

[0148] Further, the metasurface virtualization component 1802 is configured to expose (in other words, offers, provides, and / or makes available and / or makes accessible) the virtual and programmable metasurface to one or more management components 1803 as a resource for providing one or more communication functions, and, for each virtual and programmable metasurface for which one or more management components have requested the provision of a respective communication function, is configured to control the programmable metasurface to provide the requested communication function by the portion of the communication resources provided by the programmable metasurface associated with the virtual and programmable metasurface.

[0149] In other words, multiple virtual and programmable metasurfaces (virtual walls) are provided by a (physical and) programmable metasurface, i.e., virtualization is performed, and the communication resources provided by the programmable metasurface are distributed among the multiple virtual and programmable metasurfaces (virtual walls).

[0150] In other words, according to various embodiments, the programmable metasurface is virtualized into multiple virtual programmable metasurfaces. This allows efficient sharing of the programmable metasurface (considered to be a programmable infrastructure element) between multiple different network slices or tenants. In particular, such virtualization allows running network slices on top of the metasurface when considering the control and management plane from the perspective of a communications network orchestrator. Considering the end-to-end network slice, it may provide functions and interfaces for managing the lifecycle of advanced network services.

[0151] PMS virtualization (e.g., performed by a component denoted as a PMS hypervisor function) may be performed temporally, spatially (i.e., different portions of a tile, i.e., different subsets of metasurface atoms, are associated with different virtual walls), frequency-wise (i.e., different frequency ranges are associated with different virtual walls and therefore tenants / slices), and topologically, depending on the technology in effect. The PMS hypervisor (function) performs vPMS lifecycle management (i.e., creating, deleting, migrating, scaling vPMS, etc.). The PMS hypervisor may further support related vPMS operations (such as fault and performance monitoring, security and auto-remediation), PMS resource management and resource scheduling, and PMS configuration and management. Additionally, functionality within the carrier network slice management system may be provided to support lifecycle management of an NSSI, which is comprised of VNFs (or portions of VNFs) hosted by virtual walls running on top of a shared PMS (vPMS associates / de-associates with the NSSI and network services).

[0152] The approach of Figure 18 enables PMS capabilities to be exposed as part of an end-to-end communication network service allocated to a network slice.

[0153] For example, according to various embodiments, a method for optimizing the deployment and operation of a programmable metasurface is provided, the method comprising: ● From the management system, ○ Create virtual and programmable metasurfaces, ○ Allocate appropriate PMS resources for each virtual programmable metasurface. Mapping a virtual and programmable metasurface onto a programmable metasurface, o Verify that the received input complies with the virtual programmable metasurface and the programmable metasurface vPMS policies; ○ Construct a virtual and programmable metasurface for a physical PMS and configure the appropriate PMS resources; receiving a request for Receiving, exposing, and translating information, which is o Virtual and programmable metasurface and physical and programmable metasurface resource capabilities, ○ Virtual and programmable metasurfaces and physical and programmable metasurface states, o capacity management and resource reservation for virtual and physical programmable metasurfaces, Preserving isolation between multiple virtual and programmable metasurfaces; and Includes.

[0154] For example, the communication system 1800 may perform the method illustrated in FIG.

[0155] FIG. 19 shows a flowchart 1900 illustrating a method of using a programmable metasurface in a communication system.

[0156] At 1901, a plurality of virtual programmable metasurfaces are created, each virtual programmable metasurface associated with a respective portion of the communication resources that the programmable metasurface provides.

[0157] At 1902, the virtual and programmable metasurface is exposed to one or more management components as a resource for providing one or more communication functions.

[0158] At 1903, for each virtual programmable metasurface for which one or more managing components request that a respective communication function be provided, the programmable metasurface is controlled to provide the requested communication function with a portion of the communication resources provided by the programmable metasurface associated with the virtual programmable metasurface.

[0159] The components of the communication system 1800 (particularly the metasurface virtualization components) may be implemented, for example, by one or more circuits. A "circuit" may be understood to be any type of logic implementation entity, and a "circuit" may be a special purpose circuit or a processor that executes software stored in memory, firmware, or any combination thereof. In this manner, a "circuit" may be, for example, a programmable logic circuit, such as a programmable processor, such as a microprocessor, or a hard-wired logic circuit. A "circuit" may also be, for example, a processor that executes software, such as any type of computer program. Other types of implementations of the respective functions described above may also be understood to be "circuits".

[0160] While several particular embodiments have been described, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of those embodiments of this disclosure as defined by the appended claims, the scope of which is therefore indicated by the appended claims, and therefore all changes that come within the meaning and range of equivalency of the claims are intended to be embraced.

Claims

1. 1. A communication system comprising: a programmable metasurface configured to provide communication resources; a metasurface virtualization component, the metasurface virtualization component comprising: creating a plurality of virtual programmable metasurfaces, each virtual programmable metasurface associated with a respective portion of the communications resources provided by the programmable metasurface; exposing the virtual and programmable metasurface to one or more management components as a resource for providing one or more communication functions; for each virtual programmable metasurface for which the one or more managing components are requesting the provision of a respective communication function, controlling the programmable metasurface to provide the requested communication function by the respective portion of the communication resources provided by the programmable metasurface associated with the virtual programmable metasurface; the communication resources include at least one of time slots, frequency ranges, and phases for communicating using the programmable metasurface, and the metasurface virtualization component is configured to ensure that communication functions required to be provided by different ones of the virtual and programmable metasurfaces are provided by different portions of the communication resources provided by the programmable metasurfaces by at least one of time multiplexing, frequency multiplexing, and phase multiplexing, respectively. Communication systems.

2. 2. The communication system of claim 1, wherein the communication resources for communicating using the programmable metasurface include a subset of meta-atoms of the programmable metasurface.

3. The communication system of claim 1 , wherein the virtual programmable metasurface is associated with different portions of the communication resources that the programmable metasurface provides.

4. 2. The communication system of claim 1, wherein the metasurface virtualization component is configured to create at least one of the plurality of virtual and programmable metasurfaces based on respective requests from the one or more management components to create a plurality of virtual and programmable metasurfaces.

5. 5. The communication system of claim 4, wherein the metasurface virtualization component is configured to associate at least one of the plurality of virtual programmable metasurfaces with communication resources provided by the programmable metasurface to meet requirements specified in the request.

6. 2. The communication system of claim 1, wherein the metasurface virtualization component is configured to, for at least one of the plurality of virtual and programmable metasurfaces, change an association between the at least one of the virtual and programmable metasurfaces and a communication resource provided by the programmable metasurface.

7. 2. The communication system of claim 1, comprising a plurality of programmable metasurfaces, the metasurface virtualization component configured to create the virtual and programmable metasurfaces, whereby each virtual and programmable metasurface is associated with a respective portion of the communication resources provided by the programmable metasurface, and at least one of the virtual and programmable metasurfaces is associated with a communication resource provided by a different one of the programmable metasurfaces.

8. 8. The communication system of claim 7, wherein the metasurface virtualization component is configured to change, for at least one of the plurality of virtual and programmable metasurfaces, an association of the at least one of the virtual and programmable metasurfaces with communication resources provided by the programmable metasurface, thereby increasing or decreasing an amount of communication resources provided by the one of the programmable metasurfaces associated with the at least one of the virtual and programmable metasurfaces.

9. 2. The communication system of claim 1, wherein the metasurface virtualization component is configured to expose the programmable metasurface and capabilities of the virtual programmable metasurface to the one or more management components.

10. 2. The communication system of claim 1, wherein the metasurface virtualization component is configured to assign each virtual and programmable metasurface to a respective tenant managed by a respective one of the one or more management systems.

11. A communication system according to any one of claims 1 to 10, wherein the communication system includes a plurality of network slices, and at least some of the one or more management systems are management systems for different network slices.

12. The communication system of claim 11 , wherein the metasurface virtualization component is configured to assign the virtual and programmable metasurface to different network slices.

13. 1. A method for using a programmable metasurface in a communication system, comprising: creating a plurality of virtual and programmable metasurfaces, each virtual and programmable metasurface associated with a respective portion of the communication resources that the programmable metasurface provides; exposing the virtual and programmable metasurface to one or more management components as a resource for providing one or more communication functions; and for each virtual programmable metasurface for which the one or more managing components are requesting the provision of a respective communication function, controlling the programmable metasurface to provide the requested communication function by the respective portion of the communication resources provided by the programmable metasurface associated with the virtual programmable metasurface; the communication resources include at least one of time slots, frequency ranges, and phases for communicating using the programmable metasurface, ensuring that communication functions required to be provided by different ones of the virtual and programmable metasurfaces are provided by different portions of the communication resources provided by the programmable metasurfaces by at least one of time multiplexing, frequency multiplexing, and phase multiplexing, respectively. method.

Images