The pursuit for network programmability has a long history and great successes. It has led to Software Defined Networking (SDN) [30,50,71], revamping network design and management first for enterprise and data center networks [19,38], then to wide area networks [34,36] and radio access networks (RAN) for cellular and Wi-Fi [16,33,59,60]. These efforts have reduced network management complexity while improving reliability. Managing wireless signal propagation is the missing piece over the last hop, yet with major impacts on the end-to-end service quality and user experience.
To fill in the missing piece, the visions for programmable radio environments seek to provide signal-level programmability [17,44,58,67,69], with metasurfaces serving as generalpurpose hardware enablers. Actuated or configured by software, surfaces offer a variety of services, including connectivity enhancement, coverage extension, sensing, security protection, wireless powering and more. Compared with conventional networking infrastructure, surfaces operating at the signal level offer unique benefits of being standardagnostic [47,73], low-power or zero-power [37,48,57], lowcomplexity and low-cost [46,48]. Therefore, surfaces are being considered as 6G infrastructure. (section 2)
From a network programmability perspective, surfaces introduce novel primitives to program wireless signal propagation. However, unlike programmable switches and middleboxes that manage packet flows without changing the physical connectivity, surfaces fundamentally alter electromagnetic wave propagation in the environments, which boosts connectivity and various other wireless signal-based applications. Therefore, existing SDN management frameworks can not cover surfaces. Instead, we need a propagation environment manager to coordinate all wireless services. Existing surface prototype systems each proposes customized hardware and software control modules for specific wireless problems. Aside from redundant development efforts, this leads to several issues. First, this results in heterogeneous hardware managed by non-standard software. The inconsistent software-hardware interfaces hinder the interoperation of surface hardware and the development of a universal control plane. Second, it impedes the seamless integration of surfaceaided applications, i.e., efficiently providing multiple services (such as joint communication and sensing for 6G) without interfering with one another. Lastly, there is still a gap between enhancing signal-level metrics and improving applicationlevel performance perceived by end users. Thus, the current one-system-per-use-case approach does not scale with the diversity in surface hardware, surface-supported services, or user-level applications. (subsection 2.1)
Our Vision. This paper presents SurfOS, a metasurface operating system for programmable radio environments. We use the term "operating system" figuratively, as in NOX (network operating system) [32] for SDN and HomeOS [28] for IoT applications, instead of literally for a traditional OS like Linux.
In contrast to the one-system-per-use-case approach, we propose a general-purpose system to manage heterogeneous surface hardware within one or across multiple environments. Operating at the edge or in the cloud, SurfOS multiplexes diverse services over shared hardware for a range of applications (Figure 1). We decouple the data plane (signal alteration) from the control plane (surface control) with unified APIs, akin to SDN, allowing one universal control plane that provides high-level service abstractions. Network or building administrators ("app developers/users" of SurfOS) can develop surface applications to meet end users' demands. The nature of metasurfaces and wireless networks incurs unique challenges, originating from the shared radio environment, surfaces' signal-level functionality, and their role as last-hop infrastructure serving end user applications. (section 3) SurfOS tackles these challenges with three abstraction layers tailored to surface hardware and operations: (i) Hardware manager, drivers providing unified programming interfaces for heterogeneous surface hardware. (ii) Surface orchestrator, a universal central control plane providing high-level APIs of service abstractions. (iii) Service broker, a daemon that transparently serves existing wireless applications and coexists with new surface-native applications. The proposed abstractions also lay out clear APIs that lend to workflow automation with Large Language Models (LLMs) (subsection 3.4). We can extend recent proposals of LLMs-assisted network management [49,51,62] to wireless networks. This helps reduce manual efforts to develop applications or (new) surface hardware drivers and, thus, facilitates system adoption. Simulation results with our early-stage implementation show the feasibility and benefits of SurfOS: (1) enabling explicit and flexible system trade-offs among cost, size, re-configurability, deployment complexity; (2) supporting communication and sensing simultaneously with a single shared surface configuration (an array of phase shift values); (3) translating user demands to service API calls (section 4).
SurfOS provides OS-like functionality for both surface hardware management and application development, while facilitating workflow automation. To a minimal extent, it is a reusable control plane across surfaces for individual use cases; It should effortlessly scale to multiple services atop one or multiple nearby surfaces, or even across sites. SurfOS can be a service from ISPs (Internet service providers), a module of Cloud RAN, or a standalone system from a new service provider. These possibilities map to different business models and network architectures.
The visions of programmable radio environments [43,44,67] challenge the typical assumption that wireless channel responses are uncontrollable and fixed constraints to link-and network-level system designs. Another thread of work [17,27,58], termed reconfigurable intelligent surface (RIS), shares the idea and emphasizes using surfaces as hardware.
Substantial industry interest. Since several white papers argued for including surfaces in 6G (e.g., [5,6,65]), there has been substantial industry interest, including standardization efforts [9,10], industry testbeds for surfaces (e.g., [7,8,53]), and early commercial surface hardware [2,4]. These developments suggest that surfaces will be widely deployed in nextgeneration wireless networks. Compared with alternatives for coverage provisioning, such as more APs, repeaters, mesh routers, surfaces address the root causes of wireless problems by controlling signal propagation behavior. This offers several advantages: (1) solving common issues across standards and networks as shared infrastructure (e.g., [47,73]), (2) lowpower operations via reverse-biased diodes or zero-power via fully passive metallic patterns (e.g., [37,48,57]), (3) low system complexity and low cost (e.g., [46,48]).
Existing surface prototypes. Metasurfaces (or smart surfaces) are two-dimensional artificial material structures, often constructed as an array of sub-wavelength elements (also called meta-atoms or units). Each surface element is composed of circuit components and metallic patterns, to effectively capture and actuate passing electromagnetic waves [26,39,56]. Existing end-to-end systems have explored various signal control modalities: phase, amplitude, polarization, frequency [15,21,29,43,47], and impedance matching [46].
Freq Band Signal Control Mode Re-configurable Cost ($)
LAIA [43] 2.4 GHz Phase T ✓ / RFocus [15] 2.4 GHz Amplitude T & R ✓ / LLAMA [21] 2.4 GHz Polarization T & R ✓ 900 LAVA [73] 2.4 GHz Amplitude T ✓ / ScatterMIMO [29] 5 GHz Phase R ✓ 450 RFlens [31] 5 GHz Phase T ✓ 246 Diffract [54] 5 GHz Diffraction T ✗ 33 Scrolls [47] 0.9-6 GHz Frequency R ✓(row-wise) 156 mmWall [25] 24 GHz Phase T & R ✓(column-wise) ∼10K NR-Surface [37] 24 GHz Phase R ✓(column-wise) 600 PMSat [55] 20 & 30 GHz Phase T ✗ 30 MilliMirror [57] 60 GHz Phase R ✗ 15 AutoMS [48] 60 GHz Phase R ✗ <2
Table 1: Diverse hardware designsfoot_0 , transmissive (T) and reflective (R). Most work improves the perceived wireless channel conditions for better coverage and/or throughput [15,29,31,40,42,43,47,66,73]; Other work explores sensing applications [20,74,75,77], security protection [41,63], wireless powering/charging [14,22,64,78] and more. For higher frequencies like 60 GHz, surfaces can effectively extend the link range [23,25,37,48,57] and sensing [68] by circumventing environmental blockage. Recent investigations also cover the security threats from metasurfaces [24,61,76]. Additionally, many RIS works focus on theoretical channel modeling or small-scale, single-link experimental validation [35]. [44,45] propose a per-surface tile abstraction for network-layer modeling, but assume an oversimplified empty environment fully covered with surfaces and overlook crucial considerations for practical surfaces, such as surface control granularity and heterogeneity in the hardware designs and use cases.
For surfaces to be integrated in future wireless networks, we are missing critical system support.
Heterogeneous hardware. There have been numerous surface designs (Table 1) and they are expected to diverge further to suit diverse use cases. First, controlling each fundamental signal property, e.g., phase, amplitude, and frequency, requires different element patterns and circuitry, with specific designs incorporating one or multiple control primitives. Second, any element design can only cater to a limited wavelength range, hence covering frequencies from sub-6 GHz to the millimeter wave (mmWave) range needs multiple designs. Third, a surface can fix its configurations during fabrication (passive, one-time programmable) or support dynamic reconfiguration (programmable). On high frequencies especially, due to the hardware complexity and high components costs, programmable surfaces [23,25,37] cost over $2 per element, and often only support column-wise reconfiguration (shared element states per column) rather than element-wise (distinct element states within a column). The cost easily reaches thousands of dollars for a large array of elements. In contrast, fully passive surfaces [48,55,57] are very low-cost, e.g., $1 for 60 thousand elements in AutoMS, and need no power. Fourth, deployment constraints may call for transmissive or reflective surfaces, rigid or flexible surface substrates [46,52,72]. Fifth, we may add new surfaces with updated designs over time incrementally. To manage all these surfaces across environments, we lack unified hardware programming interfaces to enable a universal control plane.
Diverse services. We refer to low-level capabilities or features (e.g., coverage, sensing, powering) as services from surfaces. While surface systems can operate in myriad ways, existing systems only support one service each, or two services [31,77] without specifying how to handle both together.
To juxtapose multiple services, we can deploy either multiple surfaces each for one service or one surface for multiple services, both strategies problematic. First, different surfaces can interfere with each other's operations. For example, surfaces designed for 2.4 GHz may block 3 GHz cellular and 5 GHz Wi-Fi signals, causing connectivity issues for other networks. Second, without explicit consideration for coexistence, different services can fail to share the same hardware Figure 2 shows an example of a surface for mmWave coverage extension from the AP to the target room. The surface configuration to optimize for coverage can disrupt or preclude effective user localization in the same space, since the surface operations can inadvertently invalidate spatial information assumptions for the localization algorithm. To solve this, we need a central control plane to efficiently utilize hardware and coordinate diverse services for multiprogramming.
User applications. SurfOS operates at the last hop, managing the environments where end users reside. While existing systems optimize for signal-level metrics like SNR or RSSI, this does not always align with or efficiently fulfill the applicationlevel end user demands. For example, video streaming favors smooth link conditions, but the SNR enhancement from surfaces may be insufficient, unstable, or excessive. Additionally, application demands vary. VR/AR gaming needs high throughput and low latency, smart home applications need sensing capability, while sensitive data transmission necessitates added security protection. We lack system support to translate user demands and invoke suitable surface services.
SurfOS consists of three abstraction layers (Figure 3): hardware manager, surface orchestrator, and service broker. Together they aim to address three challenges: Hardware heterogeneity and interactions. There have been numerous hardware designs due to wide-ranging surface capabilities and trade-offs (Table 1). Moreover, the shared wireless propagation medium leads to inherent and implicit interactions between hardware, which can be destructive or constructive. SurfOS needs well-defined APIs to mask hardware heterogeneity while capturing their interactions.
Service scheduling and multiplexing. Efficient multi-service provisioning requires careful hardware scheduling and task multiplexing in a shared radio environment. Typical OSes manage hardware that behaves in known and controllable manners. In contrast, surfaces cannot fully control the shared medium, which is susceptible to unknown and dynamic external events such as human movement. Thus, SurfOS needs to capture the environmental conditions through wireless channel simulations or endpoint feedback to orchestrate surfaces. Application demand awareness. Given the unique role of surfaces -signal-level infrastructure serving ultimately user facing applications, SurfOS needs to ensure the signal-level objectives meet the application demands. Further, SurfOS should support both existing wireless applications and facilitate the development of new surface-native applications.
The hardware manager aims to hide hardware details from the upper layers with unified APIs. Masking heterogeneity. SurfOS leverages drivers to mask the hardware details and expose unified APIs. Despite numerous hardware design possibilities, fortunately, the distinct signal properties are limited. Therefore, we propose abstractions corresponding to the fundamental signal properties -amplitude, phase, frequency, and polarization -for signal property control, like set_amplitude(), shift_phase(), ..., analogous to the read() and write() primitives for file systems. The input to these primitives is surface configurations. One configuration is an array of signal property alteration values for each surface element, e.g., phase shift values.
OS "Kernel" Hardware Hardware Manager Surface Orchestrator Simulator Existing Surfaces (Programmable/Passive) Sensors, APs, Base stations Service Interface Connectivity Sensing Security Power … Channel Matrices User Space Service Broker App0 App1 Native App(s) Configurations Configurations Function Calls User demand translation Driver/Spec generation New Surfaces Auto-design
Figure 3: SurfOS Ecosystem Overview. We envision an OS-like "kernel" to manage surface hardware and provide programming interfaces for wireless services; These APIs lend to workflow automation using LLMs.
Programmable surfaces may accept multiple configurations to allow dynamic configuration switching. The primitives should provide the finest control granularity, e.g., element-wise surface configuration. This provides maximal flexibility for the upper layers to multiplex and compose surface control.
Decoupling surface management from dynamic adaption.
To adapt surfaces to environmental changes or endpoint mobility, the control module often needs to react in real time, sometimes requiring feedback from communication endpoints. This sets a challenging latency budget, and could limit SurfOS to a local server rather than an edge or cloud server. Accordingly, SurfOS decouples general hardware management (control plane) from real-time signal-level actuation (data plane), similar to how SDN decouples the control plane from the data plane. Surface drivers manage surfaces by updating surfaces' locally stored configurations, analogous to forwarding tables on switches or beamforming codebooks for 802.11ad APs [48]. For example, a surface may store multiple sets of phase shift values as local configurations, each for a distinct beam direction. Based on the endpoint feedback, a surface reacts locally to choose the best configuration. When the upper layer reconfigures the surfaces, the configurations can be updated asynchronously through the drivers.
Hardware specifications. The drivers also explicitly capture and expose key hardware parameters to the upper layer for efficient hardware utilization. The specifications should allow the upper layer to model hardware behaviors correctly. We list representative parameters below: (i)
Wideband frequency response, indicating reflection or transmission efficiency across the spectrum to avoid unintended blocking. (ii) Operation mode, whether this surface reflects signals or transmits the signals through, or both. (iii) Control delay, the delay for SurfOS to update configurations of a (remotely) controlled surface. For programmable surfaces, the control delay can vary from microseconds to milliseconds. Passive surfaces only have one-time configurability during fabrication, i.e., infinite control delay, similar to ROM versus other storage. Non-surface hardware. SurfOS also manages or interacts with non-surface hardware, including sensors, APs, base stations. This allows us to obtain sensing input or channel feedback from end user devices to guide the surface reconfiguration and, when available, interact with the APs and base stations for better performance. For cellular and 802.11ad networks, such feedback mechanism is already part of the MAC protocol and can interface with SurfOS. Custom external sensors can directly report measurements to SurfOS, e.g., power detectors in LAVA, Lidar in AutoMS, or cameras and mmWave radars.
Service APIs. This layer exposes service request APIs to the upper layer, e.g., enhance_link(), enable_sensing(), and init_powering() for coverage, sensing, and powering services respectively. These are environment-wide abstractions, not associated with specific hardware, to mask the details of which or how surfaces provide the requested services. Each function call specifies the service goals as input and creates a task (akin to OS processes). Then, the surface orchestrator dynamically performs service tasks by scheduling all surface hardware globally -calling hardware manager APIs and setting surface states. It includes a scheduler for task scheduling and multiplexing and an optimizer to optimize surface configurations for multiple tasks. It also uses a channel simulator to model the interactions between surfaces.
Service scheduling. The scheduler should exploit task dynamics to optimize hardware utilization, i.e., setting a task idle when not used and releasing resources. This is conceptually similar to the conventional OS process scheduler, but the challenging research problem is how to provide modern OS features, such as priority support, performance guarantee, and task isolation, in the context of wireless networks.
Modeling interactions. Although the hardware manager provides surface programming interfaces, the shared wireless medium can cause hidden correlations and break their independence. The deployment environment also impacts surface operations. To address this, we use a wireless channel simulator to model such interactions among surfaces and the environment. This modeling facilitates collaboration and avoids interference between surfaces. Given surface specifications and the 3D environment model as input, the simulator outputs the channel matrices between the surfaces and endpoints on the relevant frequency bands. The surface orchestrator uses these channel matrices to calculate service performance metrics, such as the received signal strength and estimated sensing or localization accuracy. This lays the foundation for the following task multiplexing and optimization.
Task multiplexing. Similar to handling digital signal transmission, we consider several dimensions for multiplexing: time, frequency, and space. Depending on the actuation speed, the surfaces can switch between configurations for different tasks to achieve time division multiplexing; Surfaces may operate multiple tasks on distinct frequency bands simultaneously to achieve frequency division multiplexing; A large surface or distributed surfaces can adopt space division multiplexing, i.e., spatially grouped by tasks, according to proximity to or channel response strengths at targeted devices. Thus, the minimal resource scheduling unit assigned to a task would be a slice of time, frequency, and space.
Configuration optimization. Given the scheduled tasks, we use an optimizer to achieve the desired service performance.
Based on the channel modeling by the wireless simulator, an optimizer searches the surface configurations for multiples surfaces so that surfaces can collaborate based on the unified hardware manager APIs.
Multitasking with joint optimization. We highlight a new opportunity of surface multitasking, i.e., multiple concurrent tasks or services can use the same hardware resource unit without conflicts, such as joint communication and sensing. This is a new dimension for multiplexing -surface-wide configuration multiplexing -analogous to code-division multiplexing. Intuitively, the surface can steer the main beam towards certain regions for coverage, while the side lobes can be used for sensing. SurfOS does not dictate a fixed set of codes for each task, but uses the aforementioned optimizer to search for the configurations.
By masking hardware heterogeneity and provide service abstractions, we can simplify development of applications that utilize surfaces. For existing applications not aware of surfaces, we introduce a service broker, as a base application (a daemon), that invoke services based on their demands. Instead of focusing on signal-level metrics as in prior work, the service broker should call surface services according to application-level demands of end users. It is challenging to translate user demands or application performance targets to low-level service targets for surfaces, e.g., signal-level metrics. For example, translating guaranteed VR experience to SNR improvement involves multiple non-linear mappings across network stack layers. User intent and habits come into play, affecting which service to invoke or end. Additionally, a single application may involve multiple services, hence requiring multi-objective optimization. We can potentially sense or monitor wireless traffic to understand user demands. A promising solution is to use LLMs, as discussed below.
The abstraction layers above present clear APIs that ease workflow automation by facilitating code generation and module synthesis. Taking a leaf out of recent proposals of using LLMs for network management [49,51,62], SurfOS uses LLMs as an external tool to (1) translate user intent into service function calls, and (2) generate surface hardware driver code. This reduces the manual efforts for driver and application development, which can encourage system adoption.
User demand translation. As LLMs become integral to AI assistants on personal devices [3, 11, 13], they serve as the primary user interface to invoke applications and act upon user intent. Naturally, they can also serve as assistants or administrators to manage the radio environments and surface services. By interpreting user intent described in natural languages, LLMs can invoke surface applications or directly generate new surface applications that call for services from SurfOS.
Hardware driver generation. The diversity of existing surface designs necessitates substantial effort to document their specifications and develop drivers in a unified format. LLMs can assist by parsing and summarizing long text, such as datasheets or research papers, to generate surface hardware specifications, similar to extracting protocol specifications in prior work [62]. On that basis, LLMs may further synthesize the driver code based on the specifications generated.
In this section, we highlight the feasibility and benefits of our approach with an early-stage implementation. Besides typical OS benefits, e.g., easy hardware management and reusable software modules, we explore two important functionalities of SurfOS via simulation: managing heterogeneous surfaces with unified configurations (hardware manager) and task multiplexing via joint optimization (surface orchestrator).
Implementation. We first implement a unified configuration interface of the hardware manager for phase-control metasurfaces. Specifically, a passive surface takes a single set of Joint optimization ensures high performance for both tasks with a single surface configuration.
per-element phase shift values, while each programmable surface takes multiple sets of element-wise states. The best set for a programmable surface is chosen based on endpoint feedback, following recent work [25,37]. We further implement the optimizer of the surface orchestrator, which jointly or individually optimizes for coverage and localization services with surface configurations as variables. The optimizer uses gradient descent, while other algorithms can be easily supported. Lastly, we use the open-source AutoMS channel simulator [1] to model channel conditions for SurfOS. It supports high-accuracy channel modeling, validated experimentally, of large-sized metasurfaces. To evaluate SurfOS performance, we calculate link SNR as in AutoMS [48] and estimate AoA (angle-of-arrival) according to md-Track [18,70]. The AoA between the client device and metasurface is estimated based on the channel information from the AP, then converted to localization error assuming accurate ToF (time of flight).
Heterogeneous surface management. We use two rooms of a furnished apartment as our testing scenario (Figure 4a). An AP is placed near the living room wall, and we want to extend mmWave coverage to the adjacent bedroom. We deploy two surfaces, one passive and one programmable, at suitable pre-determined deployment locations. They represent two extremes of the design spectrum: Passive surfaces incur extreme low cost, zero power, and easy setup, but need a much larger hardware area size that may not fit at many deployment enhance_link("VR_headset", snr=30.0, latency=10.0) enable_sensing("room_id", type="tracking", duration=3600) optimize_coverage("room_id", median_snr=25) enhance_link("laptop", snr=20.0, latency=50.0) init_powering("phone", duration=3600) enable_sensing("meeting_room", type="tracking", duration=3600)
User Input: I want to start VR gaming in this room.
User Input: I want to have an online meeting while charging my phone.
Context: You are a programmer who writes code to control metasurfaces to meet user demands. … You can call the following python functions: … locations; programmable surfaces impose a smaller spatial footprint via re-configurability, but are far more expensive and complex. We combine them into a hybrid solution to explore flexible trade-offs. The optimizer optimizes the configurations for both surfaces simultaneously and effortlessly, owing to the unified surface configuration interface. Figure 4 shows the cost and sizes needed to reach different median SNRs in the target room. Without surfaces, there is basically no coverage in the target room, so the median SNRs also represent the SNR gains. Compared with passive-only and programmableonly approaches, our hybrid solution only needs a fraction of the hardware cost and size for comparable performance. Intuitively, we exploit the individual advantages of the two designs simultaneously, by using the passive surface as a backhaul to relay the beam and using the programmable surface to dynamically steer the beam for coverage. Surface multitasking. To explore multitasking, we optimize for localization and coverage task performance jointly with a shared surface configuration, following the setup in Figure 2. We define the loss function of the localization task as the cross-entropy between the estimated and true AoA, and the loss function of the coverage task as the negative sum of link capacity across different locations. With the phase shift values (surface configuration) as variables, we minimize the sum of localization loss and coverage loss. We compare the performance of our multitasking configuration with singletasking configurations optimized for localization and coverage individually. Figure 5 shows CDF of performance across locations inside the target room. We note that a single surface configuration can effectively multitask with little performance loss, saving hardware resources significantly. Although we consider a passive surface here, programmable surfaces can perform similar multitasking within each time slot.
Translating user demands. We further show abbreviated input and output of GPT-4o [12] (Figure 6) to demonstrate how LLMs can help translate user demands to SurfOS function calls. The LLM is able to request services from surfaces based on the user's natural language input.
OS versus libraries or SDKs. While it may appear that libraries for surface control is an alternative to SurfOS, we argue that an OS-like runtime is necessary. Libraries or SDKs provide compile-time support, while we need run-time support to handle the dynamics of the radio environments. As surfaces can not completely control a physical environment, events such as furniture movement and people walking can require dynamic reconfiguration of surface Further, nearby wireless endpoints can request services with distinct demands. A runtime system can monitor and coordinate surface hardware to adapt to varying wireless channel changes and application demands. Native application development. With SurfOS, new surfacenative applications can be developed by directly invoking and combining surface services. Moreover, similar to how SDN paves the way for new services, such as network function virtualization (NFV) and virtualization of RAN (vRAN), the centralized control plane of SurfOS can enable new features, such as network monitoring, diagnosis, and wireless propagation environment virtualization. New hardware design and deployment. Surface systems encompass three key stages: design, deployment, and management. Our discussion so far has assumed the first two stages to be predetermined and focused on managing existing surfaces. However, in clean slate scenarios, we also need to consider the design and deployment stages. Existing systems often rely on expert knowledge to determine suitable designs (e.g., element patterns, components, substrate materials) and deployment setups (e.g., surface locations, sizes). AutoMS [48] is the first to explore workflow automation including the hardware design and placement, but specifically for mmWave coverage with passive surfaces. The abstraction layers of SurfOS make it easy to streamline and automate the entire process for generalized hardware types and use cases. This involves compiling upper-layer goals into hardware designs and deployment configurations. For design automation, based on the user input, LLMs can locate an appropriate design from a surface design database. If existing designs are inadequate, for instance, when a new operating frequency band is needed, LLMs can determine the necessary design parameter adjustments, then initiate electromagnetic simulation software to optimize and produce a new design. Deployment automation involves running the simulator to model the environment and optimize for placement as part of the surface hardware configurations.
This is not an exhaustive list; Selected examples are sorted by theoperating frequency band, re-configurability, and publishing date.