Software-Defined, Virtualized and Cloud-Native Wireless Networks

Introduction and Context

Wireless networks have evolved from relatively fixed infrastructures into programmable, distributed platforms that support broadband access, industrial automation, cloud applications, autonomous systems, public safety, and massive machine communication. Traditional mobile networks were built from specialized hardware appliances, vertically integrated software, and manually configured management systems. Although this architecture provided predictable performance, it was expensive to scale and difficult to adapt rapidly.

Software-defined networking (SDN), network functions virtualization (NFV), cloud-native design, network slicing, edge computing, Open Radio Access Network (Open RAN), private networks, orchestration, and application programming interfaces (APIs) represent a major transformation. Together, these technologies separate control from forwarding, replace dedicated appliances with software functions, distribute computing closer to users, and enable networks to be specified through machine-readable policies.

The transformation is not merely a change of equipment. It changes how networks are designed, operated, secured, monitored, and commercially delivered. Engineers must therefore understand both the technical architecture and its limitations, including latency, synchronization, interoperability, reliability, security, energy consumption, and operational complexity.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain the principles and architecture of SDN, NFV, and cloud-native wireless networking.
2. Distinguish virtual machines, containers, network functions, and cloud-native network functions.
3. Describe network slicing, edge computing, Open RAN, and private 5G networks.
4. Explain orchestration, intent-based management, and API-driven automation.
5. Analyze an applied wireless-network deployment and identify its benefits and risks.
6. Evaluate performance, security, governance, and operational trade-offs.

1. From Appliance-Based Networks to Programmable Infrastructure

In a traditional wireless system, functions such as mobility management, authentication, packet forwarding, radio control, firewalls, and charging are commonly implemented in purpose-built equipment. Configuration may require vendor-specific interfaces and planned maintenance windows. Scaling often means purchasing and installing additional hardware.

A software-defined and virtualized architecture aims to provide:

• Abstraction: applications and policies are separated from hardware details.
• Programmability: network behavior can be changed through software and APIs.
• Automation: provisioning, scaling, monitoring, and recovery are performed by controllers and orchestrators.
• Resource pooling: computing, storage, and networking resources are shared among functions and services.
• Disaggregation: hardware and software components may be supplied independently.

These properties support faster service creation, but they also introduce dependencies on software quality, cloud platforms, telemetry, orchestration, and multi-vendor integration.

2. Software-Defined Networking

2.1 Fundamental idea

SDN separates the control plane, which makes forwarding and policy decisions, from the data plane, which forwards packets. In a wireless network, this separation may apply to transport networks, core networks, edge platforms, and selected radio-control functions. A logically centralized controller maintains a network-wide view, although it is normally implemented as a physically distributed, redundant system.

The principal layers are:

1. Application layer: service policies, traffic engineering, security, mobility, and quality-of-service applications.
2. Control layer: controllers translate policies into device or function-specific rules.
3. Infrastructure layer: switches, routers, radio units, user-plane functions, and other forwarding resources.
4. Management and telemetry layer: inventory, configuration, alarms, metrics, logs, and events.

The controller does not necessarily carry user traffic. It programs forwarding behavior, while packets continue through the data plane. This distinction is important because excessive controller dependence can create availability and latency risks.

2.2 Southbound and northbound interfaces

A southbound interface connects a controller to network devices or functions. It may use protocols such as NETCONF, RESTCONF, gNMI, or vendor-specific mechanisms. A northbound interface exposes services and policies to applications and higher-level orchestration systems, often through RESTful APIs, gRPC, or event interfaces.

A useful design principle is that APIs should be:

• authenticated and authorized;
• versioned and documented;
• idempotent, meaning that repeating a request does not create unintended additional effects;
• observable through logs, metrics, and audit records;
• protected by rate limits and input validation.

2.3 SDN in wireless networks

SDN is particularly useful for transport and core-network functions. For example, a controller can establish a low-latency path from a factory radio access network to an edge application, reroute traffic around a failed link, or allocate bandwidth to a slice. However, radio scheduling operates on very short timescales and depends on physical-layer conditions. It is therefore not automatically appropriate to place every radio decision in a centralized controller. Control-loop placement must match the required timescale.

3. Network Functions Virtualization

3.1 Concept

NFV implements network functions as software running on general-purpose compute, storage, and networking infrastructure. Examples include virtualized packet-core functions, firewalls, load balancers, session gateways, and traffic analyzers.

A virtual network function (VNF) commonly runs in one or more virtual machines. A cloud-native network function (CNF) is designed for containers and orchestration platforms, usually following microservice principles. NFV is therefore a functional and operational concept; it is not synonymous with one particular virtualization technology.

3.2 Virtual machines and containers

A virtual machine includes a guest operating system and runs through a hypervisor. It offers strong isolation and compatibility but generally has greater startup time and resource overhead. A container shares the host operating-system kernel and usually starts faster, allowing fine-grained scaling. Containers require careful kernel, image, privilege, and namespace security.

3.3 NFV architecture

An NFV deployment normally includes:

• Virtualized infrastructure manager: controls compute, storage, and network resources.
• Virtual network functions or CNFs: provide communication services.
• NFV orchestrator: coordinates service deployment, chaining, scaling, healing, and termination.
• Catalog and descriptors: define images, resource requirements, connectivity, placement, and policies.
• Telemetry systems: provide measurements for assurance and closed-loop control.

A service chain may place a firewall, classifier, transport function, and application gateway in sequence. The chain must be engineered so that throughput, latency, state synchronization, and failure recovery remain acceptable.

3.4 Performance considerations

Virtualization introduces overhead from scheduling, memory access, I/O, packet processing, and service-to-service communication. High-performance wireless deployments may use CPU pinning, huge pages, accelerated packet processing, hardware offload, and carefully selected data paths. These optimizations can improve throughput but reduce portability and increase operational complexity.

A simple capacity relationship is:

where C_total is aggregate capacity, n is the number of active instances, and C_instance is the usable capacity of one instance. This equation assumes approximately independent instances and does not include bottlenecks such as shared links, memory bandwidth, orchestration overhead, or redundancy reservations. Actual capacity is often lower than this ideal value.

4. Cloud-Native Wireless Networking

Cloud-native design is broader than moving existing software into a cloud. A cloud-native function is typically designed for automation, elasticity, distributed execution, failure recovery, and independent service evolution. Common characteristics include:

• stateless processing where practical;
• externalized state and replicated databases;
• immutable images and declarative configuration;
• microservices with well-defined interfaces;
• automated testing and continuous delivery;
• horizontal scaling rather than dependence on a single large server;
• observability through metrics, logs, traces, and events;
• graceful degradation and self-healing.

Wireless core functions often contain state related to subscribers, sessions, security, mobility, and charging. Making such functions cloud-native is therefore challenging. State cannot simply be ignored; it must be replicated, recovered, secured, and kept consistent at acceptable latency.

A cloud-native architecture should also distinguish failure recovery from automatic scaling. Scaling adds capacity when demand rises. Recovery restores service after faults. An orchestrator may perform both, but their triggers, safety checks, and success criteria differ.

5. Network Slicing

A network slice is a logical, end-to-end network instance tailored to particular service requirements. It may include radio, transport, core, computing, security, and management resources. Slices can share physical infrastructure while maintaining policy, performance, and administrative separation.

Typical slice classes include:

• enhanced mobile broadband, emphasizing throughput;
• ultra-reliable low-latency communication, emphasizing bounded delay and availability;
• massive machine-type communication, emphasizing scale and energy efficiency.

A slice is not simply a VLAN or a separate frequency. It can include multiple technologies and domains. Isolation may be achieved through identifiers, admission control, scheduling policies, virtual networks, dedicated capacity, and security controls.

Slice performance must be specified carefully. For a traffic flow, end-to-end delay can be represented as:

Each term represents a contribution from radio access, transport, processing, queues, and the application path. The equation is a decomposition model, not a guarantee. The terms vary with traffic load, routing, retransmissions, and implementation. A low-latency slice must control the dominant terms, especially queueing and processing, rather than merely assigning a label to traffic.

A slice service-level agreement may specify throughput, latency percentile, availability, packet-loss rate, isolation, and restoration time. Percentile measures are often more informative than averages because applications can be harmed by occasional extreme delays.

6. Edge Computing and Distributed Cloud

Edge computing places processing, storage, and application services near users or devices. In wireless systems, an edge site may be located at a radio aggregation point, enterprise premises, or metropolitan facility. Its goals include reducing backhaul traffic, lowering application latency, preserving local data, and supporting operation when connectivity to a distant cloud is impaired.

Edge placement is a trade-off. More distant centralized clouds may provide greater elasticity and lower unit cost. Local edge sites may provide better latency and data locality but have limited capacity, fewer specialists, and more difficult physical security.

A practical placement decision considers:

• latency and jitter requirements;
• data sovereignty and privacy;
• application state and mobility;
• available compute, storage, and energy;
• resilience to site and backhaul failures;
• operational cost;
• protection against compromise at unattended sites.

Edge systems are especially valuable for machine vision, augmented reality, industrial control, connected vehicles, and local analytics. They must not be assumed to make every application faster: serialization, radio scheduling, congestion, and application processing can dominate total delay.

7. Open RAN

Open RAN promotes more open and interoperable interfaces among radio access network components. A commonly discussed decomposition includes the radio unit (RU), distributed unit (DU), and centralized unit (CU). The RU handles radio-frequency and lower-layer processing; the DU handles time-sensitive processing; and the CU handles higher-layer control and user-plane functions. Exact functional splits can vary.

Open interfaces can encourage multi-vendor competition and innovation. Intelligent controllers may support policy optimization and automation, including near-real-time and non-real-time control functions. However, an open interface does not automatically guarantee plug-and-play interoperability. Conformance, semantic compatibility, timing, performance, certification, and lifecycle support remain necessary.

Important engineering constraints include:

• precise timing and synchronization;
• transport capacity and bounded delay;
• hardware acceleration for demanding baseband workloads;
• radio performance and energy efficiency;
• secure software supply chains;
• interoperability testing across vendors;
• protection of controller interfaces and models.

Open RAN can reduce dependence on a single supplier, but integration responsibility may shift to the operator. Total cost must therefore include testing, optimization, support, and troubleshooting.

8. Private Wireless Networks

A private wireless network is operated for a defined organization, site, or user community. It may use licensed, shared, or locally authorized spectrum, depending on national regulation. Private networks are attractive to factories, ports, mines, universities, utilities, hospitals, and logistics centers because they can provide controlled coverage, predictable policy, device authentication, and integration with local applications.

A private network may be deployed as:

1. an on-premises standalone system;
2. a hybrid arrangement with local radio and edge functions but selected centralized services;
3. a public-network-integrated model managed with an enterprise-specific logical partition.

Design questions include spectrum rights, indoor propagation, device ecosystem, roaming, local breakout, identity management, maintenance responsibility, and emergency access. The organization must also decide whether it has the skills to operate a mobile core, radio system, security platform, and cloud infrastructure. A private network is not automatically simpler than Wi-Fi or a public cellular service.

9. Orchestration, Intent, and API-Driven Automation

Orchestration coordinates the lifecycle of multiple resources and services. It differs from simple configuration management. Configuration changes one device or function; orchestration coordinates dependencies, ordering, placement, scaling, assurance, and rollback across domains.

An intent-based system allows an operator to state a desired outcome, such as “provide secure low-latency connectivity for robotic controllers,” rather than specifying every route and parameter. The system translates intent into policies, validates feasibility, deploys resources, observes results, and adjusts operation. Intent does not remove engineering responsibility: requirements must be measurable and conflicting objectives must be resolved.

A closed-loop automation cycle can be described as:

1. Observe: collect telemetry, alarms, traces, and inventory state.
2. Analyze: detect deviations, congestion, faults, or demand changes.
3. Decide: select a policy-compliant action.
4. Act: deploy, scale, reroute, repair, or restrict a service.
5. Verify: confirm that the intended outcome was achieved.

Automation should include approval gates for high-risk changes, rollback plans, rate limits, policy validation, and separation of duties. Poorly designed automation can amplify an error across an entire network.

APIs enable integration among orchestration platforms, inventory databases, cloud systems, security tools, and business applications. Common API practices include mutual authentication, least privilege, schema validation, idempotency keys, version control, audit logging, and backward compatibility.

10. Management, Assurance, and Service-Level Engineering

A virtualized wireless network must be observable across radio, transport, compute, application, and orchestration layers. Useful telemetry includes:

• radio signal quality, resource utilization, and handover outcomes;
• packet delay, loss, jitter, and throughput;
• CPU, memory, accelerator, and storage utilization;
• service-instance health and restart rates;
• authentication failures and suspicious API activity;
• slice-level service-level indicators.

Capacity planning should include redundancy. If one instance provides usable capacity C, and r equivalent instances are reserved for redundancy or failover, the deployable capacity is not simply the total installed capacity. A basic planning expression is:

where n is the installed instance count and r is the number reserved or unavailable during a failure scenario. This simplified model assumes equal instance capacity and independent failure behavior.

Reliability may be expressed as availability:

Availability is dimensionless. If uptime and downtime are measured over the same observation period, their units cancel. High availability requires more than redundant software; it also requires resilient power, transport, synchronization, identity services, orchestration, and physical sites.

11. Security, Governance, and Regulation

The attack surface expands when network functions become software, APIs are exposed, workloads are distributed, and many suppliers participate in the platform. Major threats include compromised images, vulnerable dependencies, stolen credentials, malicious or misconfigured APIs, lateral movement between tenants, rogue radio devices, insecure orchestration, and manipulation of machine-learning models.

Best practices include:

• zero-trust access based on verified identity and context;
• hardware roots of trust and secure boot where appropriate;
• signed images, software bills of materials, and vulnerability scanning;
• network segmentation and workload isolation;
• encryption in transit and at rest;
• strong key management and credential rotation;
• independent logging and time synchronization;
• continuous vulnerability management;
• tested backup, recovery, and incident-response procedures.

Governance issues include lawful interception, emergency communications, data protection, spectrum licensing, supply-chain assurance, cross-border data movement, accessibility, and accountability for automated decisions. Network slicing also raises questions about whether isolation claims are technically and contractually enforceable. Operators should avoid presenting statistical performance targets as absolute guarantees unless the measurement method and confidence conditions are defined.

12. Artificial Intelligence in Network Operations

AI and machine learning can assist with traffic forecasting, anomaly detection, energy optimization, fault localization, radio-resource management, and predictive maintenance. A model may identify patterns in telemetry that precede congestion or equipment failure.

However, AI should be treated as a decision-support component unless its behavior has been validated for the operating context. Risks include biased training data, concept drift, adversarial inputs, opaque decisions, false alarms, and unsafe automated actions. A robust deployment needs data governance, model versioning, performance monitoring, human override, and an explicit fallback policy. AI does not replace deterministic safeguards for safety-critical or regulatory functions.

13. Illustrative Case: Private 5G Network for a Smart Factory

Background

A manufacturing plant uses automated guided vehicles, robotic arms, machine-vision cameras, and conventional enterprise applications. Wi-Fi provides general connectivity, but roaming interruptions and variable congestion affect vehicle control and video inspection.

Problem

The plant requires reliable local connectivity, bounded latency for selected control traffic, high uplink capacity for cameras, and separation between operational technology and guest devices. It also wants production data to remain on site.

Analysis

A survey identifies radio shadowing caused by machinery, peak camera demand during inspection cycles, and limited IT staff. A fully centralized public-cloud design would simplify some operations but would expose the plant to backhaul dependence and data-governance concerns. A local edge site is therefore attractive, but it needs physical protection, backup power, and remote support.

Approach and solution

The plant deploys a private cellular radio system, a local user-plane function, an edge computing cluster, and an orchestration platform. Three logical service classes are created: robotic control, machine vision, and general enterprise traffic. Admission control and traffic policies protect robotic traffic from camera bursts. Device identities are managed through a controlled enrollment process. Telemetry is collected from the radio, transport, compute, and application layers.

The robotic service is tested using delay distributions rather than only average delay. The machine-vision service is sized for peak uplink traffic, and the edge application is replicated across compute nodes. A failure test disconnects the external backhaul; local production continues, while remote management is temporarily unavailable. A second test removes one compute node and verifies that sessions recover within the defined operational target.

Outcome

The architecture improves local data handling and gives the plant policy-based separation. Nevertheless, the plant assumes additional responsibility for spectrum compliance, software updates, cyber security, radio planning, and lifecycle support. The project is successful only because technical performance and operational capability were evaluated together.

Learning points

1. Private wireless is an integrated socio-technical system, not only a radio installation.
2. Edge placement must be justified by application and resilience requirements.
3. Slices require measurable policies and assurance, not merely logical labels.
4. Failure testing is essential because normal operation does not reveal dependency risks.
5. Total cost includes skills, integration, security, and upgrades.

14. Challenges and Limitations

Despite their benefits, software-defined and cloud-native wireless systems face significant challenges:

• Latency: distributed control and service chains can add delay.
• Synchronization: radio systems require accurate frequency and time references.
• Interoperability: open interfaces may still have implementation differences.
• Operational complexity: many software components create complex dependencies.
• Energy consumption: general-purpose computing may be less efficient than specialized hardware for some workloads.
• State management: mobility, sessions, charging, and security require consistency.
• Security exposure: APIs, images, containers, and orchestration platforms enlarge the attack surface.
• Workforce requirements: operators need expertise in radio, IP networking, cloud, software delivery, and cyber security.
• Vendor accountability: disaggregated systems can make fault ownership unclear.
• Regulatory uncertainty: spectrum, privacy, automated operations, and infrastructure security rules differ across jurisdictions.

A sound design uses virtualization where flexibility and scale matter, specialized acceleration where deterministic performance and energy efficiency matter, and explicit boundaries between automated and human-controlled actions.

15. Best-Practice Design Workflow

A practical engineering workflow is:

1. Define applications, users, regulatory constraints, and measurable service requirements.
2. Map requirements to radio, transport, core, edge, and cloud resources.
3. Select functional decomposition based on latency, capacity, reliability, and lifecycle factors.
4. Define identities, trust boundaries, APIs, and security controls before deployment.
5. Establish telemetry, service-level indicators, and failure criteria.
6. Test interoperability, overload, synchronization, recovery, and security.
7. Automate repeatable lifecycle operations with validation and rollback.
8. Measure real performance and revise capacity models using production evidence.
9. Maintain software inventories, patch processes, and supplier accountability.
10. Review whether the architecture remains economical and supportable over its full lifecycle.

Contemporary Developments

Current development is moving toward multi-access edge computing, disaggregated radio platforms, programmable data planes, intent-based operations, energy-aware orchestration, digital twins, and increasingly autonomous network management. Research also explores integrated sensing and communications, non-terrestrial networks, AI-assisted radio optimization, and tighter integration between communication and industrial-control systems.

These developments should be evaluated critically. A new interface, controller, or AI model is valuable only when it improves measurable outcomes such as service reliability, deployment speed, energy efficiency, security, or cost. Architectural openness and automation are means, not ends.

Chapter Summary

Software-defined, virtualized, and cloud-native wireless networks transform telecom infrastructure from fixed, appliance-based systems into programmable and distributed platforms. SDN separates control from forwarding and enables policy-driven network programming. NFV implements network functions in software, while cloud-native functions use containers, microservices, declarative configuration, automation, and observable lifecycle management.

Network slicing creates logical end-to-end services with distinct policies and performance objectives. Edge computing places processing near users to reduce latency, backhaul dependence, and data movement. Open RAN disaggregates radio functions and promotes open interfaces, although timing, performance, testing, and integration remain demanding. Private networks provide controlled wireless connectivity for enterprises but require serious attention to spectrum, security, operations, and support.

Orchestration and APIs enable automated provisioning, scaling, assurance, and recovery. Closed-loop automation must include validation, observability, rollback, and human governance. Security, reliability, synchronization, interoperability, energy, regulation, and workforce capability are central design concerns. The most effective architecture balances flexibility with deterministic performance and operational simplicity.

Key Terms

SDN: Networking architecture that separates control functions from packet forwarding and exposes programmable interfaces.

Control plane: Network functions that make routing, policy, mobility, or forwarding decisions.

Data plane: Functions that forward or process user packets.

NFV: Implementation of network functions as software on virtualized infrastructure.

VNF: A virtual network function commonly implemented in a virtual machine.

CNF: A cloud-native network function designed for containers and cloud-oriented lifecycle management.

Orchestrator: System that coordinates deployment, scaling, healing, configuration, and termination of services.

Cloud-native: Design approach emphasizing automation, elasticity, distributed services, observability, and resilience.

Network slice: Logical end-to-end network instance tailored to a service or customer requirement.

Edge computing: Placement of computing and storage near users, devices, or access networks.

Open RAN: RAN architecture emphasizing disaggregation and open, interoperable interfaces.

Radio unit: RAN component responsible principally for radio-frequency and lower-layer processing.

Private network: Wireless network operated for a defined organization, site, or user community.

API: Programmatic interface through which software systems exchange commands or information.

Intent-based networking: Approach in which desired outcomes are translated into network policies and actions.

Telemetry: Measurements, logs, events, and traces used to observe network behavior.

Service-level indicator: Measurable quantity used to evaluate service performance.

Zero trust: Security approach that continuously verifies identity, authorization, and context rather than assuming trust based on location.

Service chain: Ordered sequence of network functions through which traffic passes.

Cloud-edge continuum: Combined resource environment extending from centralized cloud facilities to local edge sites.

Review Questions

Short Answer Questions

1. What is the difference between the control plane and the data plane in SDN?
2. Distinguish a VNF from a CNF.
3. Why is edge computing useful in industrial wireless networks?
4. What is meant by network slicing?
5. State two security practices for API-driven network automation.

Long Answer Questions

1. Explain the architecture and operational benefits of SDN in a wireless network.
2. Compare virtual machines, containers, and cloud-native network functions.
3. Discuss the benefits and limitations of Open RAN.
4. Explain how orchestration supports the lifecycle of a network slice.
5. Analyze the security and governance challenges of cloud-native telecom infrastructure.

Analytical / Application Questions

1. A factory needs low-latency robot control, high-uplink video inspection, and ordinary enterprise connectivity. Design suitable service classes, edge placement, telemetry, and failure tests.
2. An operator experiences congestion after automatically scaling a virtual packet function. Identify possible shared bottlenecks and propose a verification workflow.
3. Compare a centralized cloud deployment with a local edge deployment for a private wireless healthcare application, considering latency, privacy, resilience, cost, and operational skills.

Multiple Choice Questions with Answers

Question 1

Which statement best describes software-defined networking?

A. It permanently assigns each service to dedicated radio hardware.

B. It separates network control decisions from forwarding functions and enables programmability.

C. It replaces all wireless protocols with Ethernet.

D. It eliminates the need for network telemetry.

Correct Answer: B. It separates network control decisions from forwarding functions and enables programmability.

Question 2

A cloud-native network function is most commonly designed to run as which type of workload?

A. A containerized, service-oriented workload

B. A manually wired analog circuit

C. A fixed-frequency radio oscillator only

D. A paper-based configuration process

Correct Answer: A. A containerized, service-oriented workload

Question 3

Which component primarily coordinates deployment, scaling, healing, and termination of network services?

A. Antenna feeder

B. Packet header

C. Orchestrator

D. Subscriber device battery

Correct Answer: C. Orchestrator

Question 4

What is the principal purpose of a network slice?

A. To create a logical end-to-end network service with tailored requirements

B. To increase antenna height without changing coverage

C. To remove all isolation between customers

D. To replace spectrum regulation

Correct Answer: A. To create a logical end-to-end network service with tailored requirements

Question 5

Why is edge computing used in many industrial wireless applications?

A. It guarantees unlimited computing capacity.

B. It can reduce latency and backhaul dependence by processing data near the site.

C. It removes the need for authentication.

D. It prevents all radio interference.

Correct Answer: B. It can reduce latency and backhaul dependence by processing data near the site.

Question 6

Which is a major engineering concern in Open RAN deployments?

A. The inability to use software anywhere in the RAN

B. Timing, interoperability, transport, and integration across disaggregated components

C. The requirement that every function use identical hardware

D. The elimination of all performance testing

Correct Answer: B. Timing, interoperability, transport, and integration across disaggregated components

Question 7

In a closed-loop automation cycle, what normally follows observation?

A. Analysis of the collected information

B. Permanent deletion of telemetry

C. Removal of access control

D. Immediate uncontrolled deployment

Correct Answer: A. Analysis of the collected information

Question 8

Which practice best supports secure API-driven automation?

A. Using shared administrator passwords

B. Disabling audit logs

C. Applying authentication, authorization, validation, and version control

D. Allowing every application unrestricted access

Correct Answer: C. Applying authentication, authorization, validation, and version control

Question 9

If one virtual instance provides usable capacity C and three independent instances are active, ignoring overhead and bottlenecks, what is the ideal aggregate capacity?

A. C ÷ 3

B. 3C

C. C − 3

D. C³

Correct Answer: B. 3C

Question 10

Which statement about private wireless networks is most accurate?

A. They require no spectrum, security, or operational planning.

B. They are always cheaper and simpler than public networks.

C. They can provide controlled connectivity but require lifecycle, security, and regulatory capability.

D. They cannot use edge computing.

Correct Answer: C. They can provide controlled connectivity but require lifecycle, security, and regulatory capability.