Patent Description:
Modern communication systems include a high amount of communication system resources which may be used by multiple network slice instances and/or multiple management systems (e.g. of different tenants) to provide communication functions. Since provision of communication system resources requires effort and cost, communication system resources should be efficiently used. One way to allow efficient usage is sharing of communication system resources. This in particular relates to programmable metasurfaces. Accordingly, approaches which allow efficient and flexible sharing of programmable metasurfaces, e.g. between network slices or generally management systems which may be associated with different resource consumers (such as tenants), are desirable.

The publication <CIT> describes a metasurface where different functions may be assigned to different areas of the metasurface.

The publication by<NPL>, describes a wireless connectivity paradigm comprising negligible-power RISs (Reconfigurable Intelligent Surfaces) and conventional network nodes. This paradigm aims at jointly optimizing the radio wave propagation environment with an existing network infrastructure to realize highly concentrated service provisioning to intended end-users, while removing energy from regions where accidental or non-intended users are present.

The publication by <NPL> discusses network slicing on a radio access network.

The publication by <NPL> discusses use cases related to how a network function virtualization can consider new types of infrastructure resources.

According to one embodiment, a communication system is provided including a programmable metasurface configured to provide communication resources and a metasurface virtualization component configured to.

wherein the communication resources comprise time slots, frequency ranges and/or phases for communicating via the programmable metasurface and wherein the metasurface virtualization component is configured to ensure that communication functions requested to be provided by different ones of the virtual programmable metasurfaces are provided by different portions of the communication resources provided by the programmable metasurface by time multiplexing, frequency multiplexing and/or phase multiplexing, respectively.

According to a further embodiment, a method for using a programmable metasurface according to the communication system described above is provided.

The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and aspects of this disclosure in which the invention may be practiced.

According to further embodiments, a computer program and a computer readable medium including instructions, which, when executed by a computer, make the computer perform the method of any one of the above examples are provided.

In the following, various examples will be described in more detail.

<FIG> shows a mobile radio communication system <NUM>, for example configured according to <NUM> (Fifth Generation) as specified by 3GPP (Third Generation Partnership Project) in simplified form.

The mobile radio communication system <NUM> includes a mobile radio terminal device <NUM> such as a UE (user equipment), and the like. The mobile radio terminal device <NUM>, also referred to as subscriber terminal, forms the terminal side while the other components of the mobile radio communication system <NUM> described in the following are part of the mobile communication network side, i.e. part of a mobile communication network (e.g. a Public Land Mobile Network PLMN).

Furthermore, the mobile radio communication system <NUM> includes a Radio Access Network (RAN) <NUM>, which may include a plurality of radio access network nodes, i.e. base stations configured to provide radio access in accordance with a <NUM> (Fifth Generation) radio access technology (<NUM> New Radio). It should be noted that the mobile radio communication system <NUM> may also be configured in accordance with LTE (Long Term Evolution) or another mobile radio communication standard (e.g. non-3GPP accesses like WiFi) but <NUM> is herein used as an example. Each radio access network node may provide a radio communication with the mobile radio terminal device <NUM> over an air interface. It should be noted that the radio access network <NUM> may include any number of radio access network nodes.

The mobile radio communication system <NUM> further includes a core network (5GC) <NUM> including an Access and Mobility Management Function (AMF) <NUM> connected to the RAN <NUM>, a Unified Data Management (UDM) <NUM> and a Network Slice Selection Function (NSSF) <NUM>. Here and in the following examples, the UDM may further consist of the actual UE's subscription database, which is known as, for example, the UDR (Unified Data Repository). The core network <NUM> further includes an AUSF (Authentication Server Function) <NUM>, a PCF (Policy Control Function) <NUM> and an AF (application function) <NUM>.

The core network <NUM> may have multiple core network slices <NUM>, <NUM> and for each core network slice <NUM>, <NUM>, the operator (also referred to MNO for Mobile Network Operator) may create multiple core network slice instances <NUM>, <NUM>. For example, the core network <NUM> includes a first core network slice <NUM> with three core network slice instances <NUM> for providing Enhanced Mobile Broadband (eMBB) and a second core network slice <NUM> with three core network slice instances (CNIs) <NUM> for providing Vehicle-to-Everything (V2X).

Typically, when a core network slice is deployed (i.e. created), network functions (NFs) are instantiated, or (if already instantiated) referenced to form a core network slice instance and network functions that belong to a core network slice instance are configured with a core network slice instance identification.

Specifically, in the shown example, each instance <NUM> of the first core network slice <NUM> includes a first Session Management Function (SMF) <NUM> and a first User Plane Function (UPF) <NUM> and each instance <NUM> of the second core network slice <NUM> includes a second Session Management Function (SMF) <NUM> and a second User Plane Function (UPF) <NUM>. The SMFs <NUM>, <NUM> are for handling PDU (Protocol Data Unit) sessions, i.e. for creating, updating and removing PDU sessions and managing session context with the User Plane Function (UPF).

The RAN <NUM> and the core network <NUM> form the network side of the mobile radio communication system, or, in other words, form the mobile radio communication network. The mobile radio communication network and the mobile terminals accessing the mobile radio communication network form, together, the mobile radio communication system.

Like the core network <NUM>, the RAN <NUM> may also be sliced, i.e. include multiple RAN slices. A RAN slice and a core network slice <NUM>, <NUM> may be grouped to form a network slice.

In the following, "network slice" (or just "slice") generally refers to a core network slice but may also include a RAN slice or even a Transport network slice. In other words, each network slice may be made of network slice subnets like a RAN subnet, a core network subnet and a transport subnet.

An S-NSSAI (Single Network Slice Selection Assistance information) identifies a network slice and consists of:.

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

Allowed NSSAI is NSSAI provided by the serving PLMN (Public Land Mobile Network) during e.g. a registration procedure, indicating the S-NSSAI values allowed by the network for a UE in the serving PLMN for the current registration area.

Configured NSSAI is NSSAI that has been provisioned in the UE. It may be applicable to one or more PLMNs.

Requested NSSAI is NSSAI that the UE provides to the network during registration in order to establish a PDU session to the requested network slice.

The mobile radio communication system <NUM> may further include an OAM (Operation, Administration and Maintenance) function (or entity) <NUM>, e.g. implemented by one or more OAM servers which is connected to the RAN <NUM> and the core network <NUM> (connections are not shown for simplicity). The OAM <NUM> may include an MDAS (Management Data Analytics Service). The MDAS may for example provide an analytics report regarding network slice instance load. Various factors may impact the network slice instance load, e.g. number of UEs accessing the network, number of QoS flows, the resource utilizations of different NFs which are related with the network slice instance.

Further, the core network <NUM> includes an NRF (Network Repository Function).

The core network <NUM> may further include a Network Data Analytics Function (NWDAF) <NUM>. The NWDAF is responsible for providing network analytics and/or prediction information upon request from network functions.

The various network functions can be implemented on specialized hardware, i.e. on so-called ACTA (Advanced Telecommunications Computing Architecture) devices. This means that the network functions are implemented as physical network functions deployed on special hardware. In that case, software for implementing the network function is strongly coupled with the hardware.

However, it may be desirable to implement network functions also on non-specialized hardware, i.e. as software applications running on virtual machines (and/or a container) deployed over COTS (Commercial off-the-shelf) servers (i.e. on general purpose or open computing platforms, i.e. devices). This is enabled by using virtualization technology (e.g., hypervisor, operating system (OS) containers etc.), which can be used to deploy network functions (e.g., SMF, PCF etc.) as software applications running on virtual machines (VMs) and/or containers. They are then referred to as virtual network functions (VNFs).

Management and orchestration (MANO) is a key element of the ETSI (European Telecommunications Standards Institute) network functions virtualization (NFV) architecture. NFV-MANO is an architectural framework that coordinates network resources for cloud-based applications and the lifecycle management of virtual network functions (VNFs) and network services. As such, it is crucial for ensuring rapid, reliable NFV deployments at scale. NFV-MANO includes several Functional Blocks and functions like the NFV orchestrator (NFVO), the VNF manager (VNFM), the virtual infrastructure manager (VIM) and the Container Infrastructure Service Management (CISM).

<FIG> shows an architecture <NUM> including a simplified version of the Network Functions Virtualisation Management and Orchestration (NFV-MANO) Architectural Framework. It includes a collection of functional blocks and functions, data repositories used by these functional blocks, and reference points and interfaces through which these functional blocks exchange information for the purpose of managing and orchestrating NFV.

The architecture <NUM> includes an OSS/BSS (operations support system and business support system) <NUM>, and an NFV-MANO including an NFVO <NUM>, an VNFM <NUM>, a VIM <NUM>, a CISM (container Infrastructure Service Management) <NUM> and a CCM (CIS Cluster Management) <NUM>.

The NFVO <NUM> manages a network service (NS) <NUM> which, in this example, includes the following virtualized functions: an AMF <NUM>, an SMF <NUM> and a PCF <NUM> and a RAN component <NUM>. A network service (NS) is a composition of physical and virtual network function(s) and/or service(s), defined by its functional and behavioural specification.

The architecture <NUM> further includes an NFVI (Network Function Virtualization Infrastructure) <NUM> which includes hardware and software components that build up the virtualized environment in which VNFs are deployed.

In this example, the AMF <NUM>, the SMF <NUM> and the PCF <NUM> are implemented as VNFs, i.e. as NFs that can be deployed on the NFVI <NUM>. The SMF <NUM> is implemented by a container <NUM> running in a virtual machine, the PCF <NUM> on a virtual machine <NUM> and the AMF <NUM> in a container <NUM>, all running on a COTS server <NUM>. The RAN component <NUM> is, in contrast, implemented on an ATCA device <NUM>, i.e. is a physical network function.

The NFVO <NUM> manages the NS lifecycle and coordinates the overall resource usage of NS, VNF lifecycle is supported by the VNFM <NUM> and NFVI resources management supported by the VIM <NUM>, CISM <NUM> and CCM <NUM> to ensure an optimized allocation of the necessary resources and connectivity.

The VNFM <NUM> is responsible for the lifecycle management of VNFs independently on whether the VNF is deployed over VM or containers.

The VIM <NUM> is responsible for controlling and managing the NFVI compute, storage and network resources, typically within one operator's infrastructure domain. The CISM <NUM> is responsible for orchestrating and managing the container infrastructure services and the containerized workloads instantiated on them. The CCM <NUM> is responsible for the management of container clusters.

It should be noted that regarding network functionality, 3GPP is responsible for the management and configuration of the Network Functions (NFs) and interactions between NFs while it is not responsible for the management of the virtual network function aspects. In fact, the 3GPP functionality remains the same from an application perspective irrespective of whether a network function is virtualized or not. From ETSI NFV perspective, the NFV-MANO handles the orchestration and management of the both virtualized resources and the deployed VNF while remaining agnostic to the actual VNF application (e.g., if the VNF application is a virtualized PCF or a virtualized SMF).

Regarding VNF management, not only VNF instantiation but also other life cycle management (LCM) operations such as, update, scaling etc. are made by NFV-MANO (NFVO/VNFM/CISM/VIM) and the VNF configuration can be made by an element manager through interaction with the OSS.

A VNF can be part of multiple network services and a network service can be shared between multiple network slices (or network slice subnets) according to 3GPP and NFV-MANO. Further, even without considering 3GPP network slicing, multi-tenancy is possible in NFV, i.e. an NFV environment can 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 dedicated NFV-MANOs. Different sharing scenarios can be realized even without referring to the network slicing mechanism defined by 3GPP and correlation between the shared resources with specific network slice descriptors (NSDs) or identifiers (e.g., NSI-IDs).

<FIG> illustrates a sharing scenario where, in particular, a Network Service <NUM> is shared between two tenants <NUM>, <NUM>. The different VNFs which are parts of the shared Network Service are also shared between the different tenants <NUM>, <NUM>.

<FIG> illustrates a sharing scenario where two network services <NUM>, <NUM> are shared between two network slices subnet instances <NUM>, <NUM>.

Regarding the touch points between 3GPP's network slicing management model and the ETSI NFV management model one or more network slice subnet instances are mapped to one or more shared network services.

There are various options regarding the deployment of network slices using NFV Network Services (NSs):.

<FIG> illustrates network slicing in 3GPP from a management perspective.

A Communication Service Management Function (CSMF) <NUM> is responsible for translating the communication service requirements to network slice requirements.

A Slice Management Function (NSMF) <NUM> serves for the end-to-end management and orchestration of an NSI (network slice instance) <NUM>, i.e. a realization of a network slice.

Network Slice Subnet Management Functions (NSSMFs) <NUM>, <NUM>, <NUM> are responsible for the management and orchestration of the sub-network slice instance <NUM> in a specific domain, i.e. of network slice subnet-instances (NSSIs). For example, a Transport Network Slice Subnet Instance (TN-NSSI) <NUM> is a realization of the network slice on transport domain and a Core-NSSI <NUM> is realization of the network slice on the core domain. An NSI <NUM> is a composition of multiple NSSIs <NUM>, <NUM>, <NUM>.

The NSSMFs <NUM>, <NUM>, <NUM> are connected to respective domain controllers <NUM>, <NUM>, <NUM> which are responsible for the relevant control and management plane operations within the respective domain.

<FIG> illustrates slice management from a MANO perspective.

As described with reference to <FIG>, there is an NSMF <NUM> and multiple NSSMFs <NUM>. Further, as described above, there is an OSS <NUM> and an orchestration system managing VNFs and NFVI <NUM>.

In the example of <FIG>, the OSS <NUM> can configure application aspects of a shared VNF <NUM> via an element manager (EM) <NUM> following normal procedures. VNFs <NUM> belonging to a first communication network <NUM> (e.g. a first tenant) and VNFs <NUM> belonging to a second communication network <NUM> are also connected to the shared VNF <NUM>.

The orchestration system (also referred to orchestrator) <NUM> controls the deployment and management of the Virtualized Network Functions (VNF) as well as Physical Network Functions (PNF).

According to various embodiments, the communication system in particular includes Programmable Metasurfaces (PMS). The term PMS may be understood to include any kind of metasurface variations and technologies such as Smart Mirror, Spatial Microwave Modulator (SMM) Reconfigurable intelligent Surfaces (RIS) or (RSI) and Large Intelligent surface (LIS).

<FIG> shows a programmable metasurface (PMS) <NUM>.

The (PMS) <NUM> includes an arrangement (e.g. matrix) of switchable elements (denoted as "meta-atoms") <NUM> which provides the ability to manipulate radio signals like steering radio beams in a specific direction or completely absorb radio waves.

The arrangement of meta-atoms <NUM> (or "tile") forms the actual (physical) metasurface which can be mounted on an indoor and/or outdoor wall. The PMS <NUM> further includes a PMS controller function <NUM>, i.e. a controller (e.g. implementing an IoT (Internet of Things) Gateway) which implements, via connections <NUM>, the control layer of the PMS <NUM>, for example provides a tile central power supply, inter-tile communication, enables tile-to-external- world communication (in particular to a PMS manager) and optionally environmental sensing duties. The PMS controller function <NUM> is for example a dedicated programmable hardware device (e.g. arranged next to or tightly coupled with the metasurface).

A metasurface allows providing a type of communication system node leveraging smart radio surfaces with thousands of small antennas or meta material elements (i.e. the meta-atoms <NUM>) to dynamically shape and control radio signals in a goal-oriented manner. Metasurfaces may be used to optimize bandwidth usage, optimize the signal received in a receiver through exploitation of scattering and multipath phenomena by a corresponding control of the metasurface. A desired and supported electromagnetic function of the metasurface is attained by a corresponding switch state configuration setup for the meta-atoms. This gives the ability to steer beams in a specific direction or completely absorb an incoming radio signal. In particular, metasurfaces allow mitigating undesired 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 devices, optimizing their power-delay profile (PDP) and avoiding the negative effects of multi-path fading.

Like the sharing of VNFs and network services between tenants (see <FIG>) and network slices or network slice subnets (like in <FIG>) a sharing of metasurfaces between tenants or network slices or network slice subnets (which, when the subnets belong to different slices, results again in the sharing between slices) can increase the efficiency of the usage of this specific resource, i.e. the metasurface.

According to various embodiments, to allow such a sharing in an efficient manner, so-called virtual walls (i.e. metasurface abstractions) are created by a component, in the following examples denoted as PMS hypervisor (PMS-H) and an approach for managing network slice instances to operate on top of shareable programmable metasurfaces (PMS) is provided.

It should be noted that a network slice instance is a realization of network slice. For example, a generic description of a network slice can be provided (e.g. two routers operating with VLAN (virtual local area network) connectivity between them). Then a domain controller may take this description and create the right configuration for the routers, perform resource allocation etc. Then this realization of the network slice, which is called "network slice instance", can be managed. This is similar to the relation of VNF vs. VNF instance. The VNF can be seen as the abstract definition and description of what the VNF is while a VNF instance is a specific instantiation (i.e. instance) of such a type of VNF.

The PMS-H creates and manages programmable metasurface abstractions, denoted in the following examples as (programmable) virtual walls (vPMSs, i.e. virtual programmable metasurfaces, in other words virtual metasurface resource elements). The vPMS are also programmable by a management system on a per tenant or per slice basis. The PMS-H thus introduces functionality to enable multitenancy and slicing on top of physical PMSs resources, including, for example, interfaces between the PMS-H and or more network slice management systems or orchestration systems. The PMS-H is for example responsible for vPMS Lifecycle management (LCM), also handles resource and service isolation, can support additional functionality like migration of the vPMS to another PMS and can interact with one or more other PMS-Hs to support multi-technology operations (e.g., migration). Further, functionality inside a respective telecom operator slicing management system may be provided to manage and optimize the deployment and operation of network slices instances (NSs) considering a shared PMS operational environment.

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

<FIG> illustrates an architecture including a PMS-Hypervisor (PMS-H) <NUM>.

The PMS-H <NUM> is connected to a programmable metasurface <NUM> (in the "southbound" and two PMS-managers <NUM>, <NUM> (in the "northbound"). Each PMS manager <NUM>, <NUM> is in turn connected to a respective network service management or orchestration system <NUM>, <NUM> for a respective tenant or NSSMF/NSMF <NUM>, <NUM>.

The PMS-H <NUM> creates multiple virtual walls (vPMSs) <NUM> wherein each virtual wall is associated with communication resources provided by the PMS <NUM>. In this example, a first one of the virtual walls is for example associated with a first subset <NUM> of the meta-atoms of the PMS <NUM> and a second one of the virtual walls is for example associated with a second subset <NUM> of the meta-atoms. A communication function (including typically data transmission operations etc.) which is provided by a virtual wall (according to a request from a management or orchestration system <NUM>, <NUM>) is provided by the communication resources associated with the virtual wall. These can be, as illustrated in the present example, subsets of meta-atoms of the PMS <NUM> but may also be time-slots or frequency bands provided by the PMS <NUM> (i.e. multiple virtual walls may also be provided by the PMS in a time multiplexing or frequency multiplexing, phase manipulation manner).

The PMS-H <NUM> may be seen to resemble an OS hypervisor in the sense of providing a resource sharing mechanism by implementing virtual entities on top of a physical entity. Specifically, the PMS-H <NUM> creates virtual programmable walls (vPMSs) which can be assigned to a tenant or NSSIs (i.e. a resource consumer). It enables PMS resource sharing and guarantees isolation and it is responsible to guarantee isolation between different vPMS on the physical layer.

The PMS-H <NUM> can be incorporated into a PMS-Manager function or can be an independent entity exposing services to multiple managers dedicated to different tenants. It may keep the state of allocated resources per NSSI or tenant (supporting the appropriate identification mechanism). The PMS-H <NUM> manages all PMS resources and monitor PMS operations. The PMS-H approach can be applied in sharing scenarios even when considering multitenancy without necessarily 3GPP slicing.

<FIG> shows a PMS Hypervisor (PMS-H) <NUM> in more detail.

The PMS-H <NUM> includes a northbound interface <NUM> connected to control and management systems <NUM> (such as the PMS managers <NUM>, <NUM>, the orchestration and management systems <NUM>, <NUM> and the management systems of the tenants or NSSIs).

Further, the PMS-H <NUM> includes a southbound interface <NUM> connected to one or more PMSs <NUM> (possibly of different technologies), e.g. PMS <NUM>.

The (functional) core of the PMS-Hypervisor <NUM> includes.

The northbound interface <NUM> (e.g. API (Application Programming Interface) for which the PMS-H <NUM> includes a corresponding API gateway <NUM>).

Examples for information communicated via the northbound interface are.

These attributes are only examples and more extended functionalities (extensions) may be included. PMS-H also exposes similar information for the PMS (owner, resources etc.).

The southbound interface <NUM> (e.g. API).

By means of the virtual walls, a PMS <NUM> may then be shared among network services (and thus, if they belong to different tenants and/or slices, by tenants and/or slices).

<FIG> illustrates the shared use of one or more PMSs <NUM> by two network slices or tenants <NUM>, <NUM>, each providing a respective network service <NUM>, <NUM> to a respective UE <NUM>, <NUM>. Each network service <NUM>, <NUM> is managed by a respective network service orchestration and management system <NUM>, <NUM>.

Similarly to <FIG>, the first network service <NUM> and the second network service <NUM> are each provided by various respective components <NUM> including one or more distributed components and centralized components, radio units and core network components like RAN components, an AMF an SMF and a PCF which may be provided by physical and/or virtual network functions.

Further, the first network service <NUM> hosts a first vPMS-NF <NUM> operating on top of a first vPMS <NUM> created by a PMS hypervisor <NUM> from the PMS <NUM> (i.e. by allocation of communication resources of the PMS <NUM> for it) and the second network service <NUM> hosts a second vPMS-NF <NUM> operating on top of a second vPMS <NUM> created by the PMS hypervisor <NUM> from the PMS <NUM> (i.e. by allocation of communication resources of the PMS <NUM> for it).

As in <FIG>, components <NUM> to <NUM> including a vPMS <NUM> provide a network service. The vPMS <NUM> and the RU <NUM> belong to a RAN-NSSI <NUM> (i.e. RAN domain NSSI). The core network component <NUM> belongs to a CN-NSSI <NUM> (i.e. core network domain NSSI). Connections between the components <NUM> to <NUM> belong to a TN-NSSI <NUM> (i.e. transport domain NSSI). The NSSIs <NUM>, <NUM>, <NUM> are part of NSI <NUM>.

As in <FIG>, the NSI <NUM> is managed by an NSMF <NUM> and the NSSIs are managed by corresponding NSSMFs <NUM>, <NUM>, <NUM>.

The components <NUM> to <NUM> are managed by a PNF/VNF orchestration system. It is in communication with core domain controllers <NUM>, RAN domain controllers <NUM> and a PMS domain controller, e.g. a PMS manager <NUM> which, as described above, communicates with a PMS-H <NUM> creating vPMSs from one or more PMSs <NUM>. An OSS controls the PNF/VNF orchestration <NUM> and interacts with NSMF <NUM>.

From NFV-MANO point of view, there is no entity which is managing the mapping of VNF/PNFs and physical resources to NSSIs. NFV-MANO is slice unaware and only NFV Network Service aware. A PMS manager can be slice aware or slice unaware. It depends on which management level the mapping is preserved. PMS-H is slice-unaware but the vPMS can be part of one or more network services which are part of one o more NSIs. Under network slicing, an NSSI can have multiple associated vPMSs. Each vPMS may be built using a different physical layer characteristic. Sharing of vPMSs (virtual walls) is also possible between different NSSIs.

<FIG> illustrates vPMS migration operations.

In the example of <FIG>, a first PMS-H <NUM> has created a first vPMS <NUM> and a second vPMS <NUM> from a first PMS <NUM> and a second PMS-H <NUM> has created a third vPMS <NUM> from a second PMS <NUM>.

The PMS-Hs <NUM>, <NUM> may provide the functionality of vPMS migration. This means that a vPMS is moved to another PMS (operating over the same or other PMS technology) while keeping the vPMS state and functionality unaffected. In the present example, the second vPMS <NUM> is first provided by the first PMS <NUM> (i.e. by allocating communication resources provided by the first PMS <NUM> to it) and then provided by the second PMS <NUM> (i.e. by allocating communication resources provided by the second PMS <NUM> to it). The PMS-Hs <NUM>, <NUM> communicate accordingly for enabling this functionality either directly or coordinated by some other management system.

In general, the migration may mean that for a virtual programmable metasurface the amount of communication resources provided by one of the programmable metasurfaces associated with the virtual programmable metasurfaces is decreased and the amount of communication resources provided by another one of the programmable metasurfaces associated with the virtual programmable metasurfaces is increased.

Further, each PMS-H <NUM>, <NUM> may provide the functionality of vPMS resource remapping. This means that it creates (instantiates) a vPMS and maps it to one or more PMSs (i.e. allocates communication resources provided by the one or more PMSs to it) and then updates the mapping of vPMS to PMSs by remapping to one or more different PMS(s).

In the present example, the third vPMS <NUM> is initially mapped to the second PMS <NUM> and then remapped to a third PMS <NUM> by the second PMS-H <NUM>. In general, the association of communication resources with a virtual programmable metasurface is changed.

The remapping and migration operations may for example be carried out to be able to fulfil an incoming request for creation of a management system. For example, a requested virtual programmable metasurface may have requirements for which certain communication resources (e.g. supporting a certain frequency ranged) are needed which are not needed for a virtual programmable metasurface that has already been created and for which therefore a migration and/or remapping is performed to free up suitable communication resources which may then be used for the requested virtual programmable metasurface.

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

Furthermore, based on events (a call to the PMS-H northbound interface) a vPMS can be scaled out/up scaled in/down, i.e. the amount of communication resources provided by one or more PMSs which is allocated to it may be increased or reduced by the PMS-H managing it (i.e. the number of meta-atoms allocated to it may be increased or reduced). Depending on the PMS technology scaling can be realized using different means (e.g., allocate more atoms, allocate more frequencies, time etc.).

In the case of vPMS migration and/or resource remapping communication between PMS-H and the radio part of the mobile network controllers is also possible to jointly optimize the overall communication (e.g., tune dynamically beamforming parameters on the transmitting antennas of the mobile network based on the vPMS migration).

<FIG> illustrates the addition of the PMS virtualization functionality as described above by means of an additional management domain (i.e. subnet management function) in addition to RAN domain, transport domain and Core domain as described with reference to <FIG>: RAN NSSMF <NUM> is responsible for slicing management when considering RAN elements (VNFs, PNFs, Antennas, etc.). TN-NSSMF <NUM> is responsible for slicing management when considering Transport Network RAN elements. CN-NSSMF <NUM> is responsible for slicing management when considering Core Network (CN) elements (VNFS, PNFs).

The additional domain <NUM> is used to manage physical environment related NSSI instances, such as when programmable metasurfaces are part of such physical environment. Specifically, a corresponding PHY_ENV-NSSMF <NUM> is responsible to manage the LCM of the PHY_ENV NSSI related aspects. PHY_ENV-NSSMF <NUM> is able to manage subnets composed of any type of environment related resources, including programmable metasurfaces, and can be used to support a number of additional use cases (e.g., sensing). Using PHY_ENV-NSSMF different environment resources can be used to support multiple NSSIs (e.g., one NSSI is optimized for sensing, one NSSI is optimized for beamforming optimization, etc.). Non-Public networks as well as multi-technology environments (e.g. including Wi-Fi) may also be considered.

<FIG> illustrates an alternative approach where subnet management of physical environment is part of the RAN-NSSMF <NUM>. This means that the PHY-NSSMF functionality is incorporated into the RAN-NSSMF by broadening the scope of the latter (e.g., to consider PMS type of resources).

<FIG> shows a flow diagram <NUM> for creation of a vPMS for a network slice.

An upper level orchestration system <NUM> (e.g. OSS <NUM> or RAN-NSSMF <NUM> etc.), a domain management system <NUM> (e.g. corresponding to the PNF/VNF orchestration <NUM> or a PMS controller etc.), a PMS-H <NUM> (e.g. corresponding to the PMS-H <NUM>) and a PMS <NUM> (e.g. corresponding to a PMS <NUM>) are involved in the flow.

In <NUM>, the orchestration system <NUM> sends a PMS capabilities & capacity request to the domain management system <NUM> which the domain management system <NUM> forwards to the PMS-H <NUM> in <NUM>.

In <NUM>, the PMS-H <NUM> sends a corresponding reply to the domain management system <NUM> which the domain management system <NUM> forwards to the orchestration system <NUM> in <NUM>.

In <NUM>, the orchestration system <NUM> sends a request for creation of a vPMS to the domain management system <NUM>. The request may include vPMS requirements. In <NUM>, the domain management system <NUM> initiates creation of a vPMS in reaction to the request and instructs the PMS-H <NUM> accordingly.

In <NUM>, the PMS-H <NUM> parses the requirements for the vPMS. If resources are available and the request can be satisfied it creates a vPMS and associates it with an owner (e.g. the network slice in this example). Further, it reserves communication resources of the PMS <NUM> for it and initiates LCM (Lifecycle management) of the vPMS.

In <NUM>, the PMS-H <NUM> sends a reply to the creation request to the domain management system <NUM> which the domain management system <NUM> forwards to the upper level orchestration system <NUM> in <NUM>.

In <NUM>, the orchestration system <NUM> sends a vPMS configuration request to the domain management system <NUM> which the domain management system <NUM> forwards to the PMS-H <NUM> in <NUM>.

In <NUM>, the PMS-H <NUM> translates the configuration request to actual physical resource configuration instructions and performs corresponding configuration of the PMS <NUM> in <NUM>.

In <NUM>, the PMS-H <NUM> sends a reply to the configuration request to the domain management system <NUM> which the domain management system <NUM> forwards to the upper level orchestration system <NUM> in <NUM>.

<FIG> shows a flow diagram <NUM> for release of a vPMS.

As in <FIG>, an upper level orchestration system <NUM>, a domain management system <NUM>, a PMS-H <NUM> and a PMS <NUM> are involved in the flow.

In <NUM>, the upper level orchestration system <NUM> sends a request to delete a vPMS to the domain management system <NUM>. In <NUM>, the domain management system <NUM> decides whether to release the vPMS and, in this example, requests the PMS-H <NUM> to release the vPMS in <NUM>.

In <NUM>, the PMS-H <NUM>, parses the request for the vPMS-id to be released (i.e. deleted), deletes vPMS objects and updates local inventories according to the release and returns communication resources (allocated to the released vPMS) back to the available pool of communication resources so can they can be reused for (allocated to) other vPMSs.

In <NUM>, the PMS-H <NUM> performs physical resource configuration of the PMS <NUM>, e.g. deactivates meta-atoms formerly allocated and configured to the released vPMS, e.g., to save energy.

In <NUM>, the PMS-H <NUM> sends a reply to the release request to the domain management system <NUM>.

In <NUM>, the domain management system <NUM> updates inventories for one or more NSs etc. accordingly.

In <NUM>, the domain management system <NUM> forwards the reply to the upper level orchestration system <NUM>.

<FIG> shows variants <NUM> to <NUM> of an architecture including a PMS-Hypervisor.

In the first variant <NUM>, the PMS-H <NUM> communicates with the relevant 3GPP communication management systems (without MANO).

In the second variant <NUM>, a MANO <NUM> is further involved.

In the third variant <NUM>, the PMS-H <NUM> communicates with a 3GPP communication management system and, in addition an OSS <NUM> external to the 3GPP communication system.

In the fourth variant <NUM>, the PMS-H <NUM> communicates with O-RAN management systems with involvement of a MANO <NUM>.

In particular, usage of the approaches described herein are not restrictive to one orchestration framework like ETSI NFV-MANO but can be applied to other designs like in O-RAN based systems.

It should be noted that the PMS-H can be incorporated (as software) to existing PMS-managers or can be an independent entity exposing services to multiple managers.

In summary, according to various embodiments, a communication system is provided as illustrated in <FIG>.

<FIG> shows a communication system <NUM> according to an embodiment.

The communication system <NUM> includes a programmable metasurface <NUM> configured to provide communication resources and a metasurface virtualization component <NUM>.

The metasurface virtualization component <NUM> is configured to create multiple virtual programmable metasurfaces, wherein each virtual programmable metasurface is associated with a respective portion of the communication resources provided by the programmable metasurface <NUM>.

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

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

According to various embodiments, in other words, a programmable metasurface is virtualized into multiple virtual programmable metasurfaces. This allows efficient sharing of the programmable metasurface (considered as a programmable infrastructure element) among different network slices or tenants. In particular, it allows performing network slicing on top of metasurfaces when considering control and management plane from a telecom network orchestrator perspective. Functionality and interfaces may be provided to manage the lifecycle of advanced Network Services in the light of end-to-end network slicing.

The PMS virtualization (e.g. performed by a component denoted as PMS hypervisor function) may be performed in time, space (i.e. different parts of the tile, i.e. different subsets of meta-surface atoms are associated with different virtual walls), frequency (i.e. different frequency ranges are associated with different virtual walls and thus tenants/slices), phase etc. depending on the technology in effect. The PMS hypervisor (function) performs vPMS lifecycle management (i.e. creates, deletes, migrates, scales vPMSs etc). It may further support related vPMS operations (like fault and performance monitoring, security and auto-healing), PMS resource management and resource scheduling and PMS configuration and management. Further, functionality inside telecom operator network slice management systems may be provided to support life cycle management of NSSIs composed of VNF (or part of) hosted on virtual walls operating on top of shared PMSs (vPMS associate/de-associate with NSSI and network services).

The approach of <FIG> allows exposing PMS functionality as part of end-to-end telecom network service allocated to network slices.

For example, according to various embodiments, a method for optimizing deployment and operation of programmable metasurfaces is provided, including:.

The communication system <NUM> for example carries out a method as illustrated in <FIG>.

<FIG> shows a flow diagram <NUM> illustrating a method for using a programmable metasurface in a communication system.

In <NUM>, multiple virtual programmable metasurfaces are created, wherein each virtual programmable metasurface is associated with a respective portion of communication resources provided by the programmable metasurface.

In <NUM>, the virtual programmable metasurfaces are exposed to one or more managing components as resource to provide one or more communication functions.

In <NUM>, for each virtual programmable metasurface for which the one or more management components request provision of a respective communication function, the programmable metasurface is controlled to provide the requested communication function by means of the portion of the communication resources provided by the programmable metasurface associated with the virtual programmable metasurface.

Claim 1:
A communication system (<NUM>, <NUM>) comprising:
a programmable metasurface (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) configured to provide communication resources; and
a processor configured to implement a metasurface virtualization component (<NUM>) configured to
create multiple virtual programmable metasurfaces (<NUM>), wherein each virtual programmable metasurface is associated with a respective portion of the communication resources provided by the programmable metasurface (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>);
expose the virtual programmable metasurfaces (<NUM>) to one or more managing components as resource to provide one or more communication functions; and
for each virtual programmable metasurface (<NUM>) for which the one or more management components have requested provision of a respective communication function, control the programmable metasurface (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) to provide the requested communication function by means of the portion of the communication resources provided by the programmable metasurface (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) associated with the virtual programmable metasurface (<NUM>),
characterized in that
the communication resources comprise time slots, frequency ranges and/or phases for communicating via the programmable metasurface (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) and wherein the metasurface virtualization component (<NUM>) is configured to ensure that communication functions requested to be provided by different ones of the virtual programmable metasurfaces (<NUM>) are provided by different portions of the communication resources provided by the programmable metasurface (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) by time multiplexing, frequency multiplexing and/or phase multiplexing, respectively.