Radio Access Networks
Complex platform, content, and network decisions where revenue, rights, and customer experience intersect.
This interactive experience is the shipped product itself — the same application code customers run in production, mounted read-only in your browser over a real sample journey. Not a video, not a mockup: because the demo and the product are one codebase, it can never drift from the real thing.
Inside this journey
-
Pre-Sales
Qualify and diagnose before investing in a full evaluation cycle.
-
Qualification
Confirm budget range, decision process, key technical constraints, and timeline before investing in full discovery.
Qualification Questions
Trial & technical fit
- To align effort efficiently, do you expect a multi-site field trial as part of evaluation, and if so what cluster size do you anticipate?
- Which technical acceptance criteria matter most for you in a trial? (select up to three)
- If you have numeric targets or hard ceilings (for example, % energy-per-bit reduction or spectral-efficiency uplift), please share them here.
Budget
- Is there an allocated budget or expected spend range for the RAN refresh or densification program this procurement will sit in?
Decision and procurement
- Who ultimately signs contracts for RAN equipment, and which roles should we include in technical and commercial discussions?
- How long is your typical evaluation and procurement cycle from technical trial to signed agreement?
Timeline and next step
- What is the target milestone driving this evaluation (for example a coverage commitment, competitor launch, or capacity threshold)?
- So we make the best use of your time, are you ready to proceed to a full discovery meeting to align trial scope and logistics?
-
Outcome Discovery
Map current network state, capacity and energy constraints, stakeholders, and measurable acceptance criteria for vendor selection.
Discovery Questions
Quick snapshot: why you're exploring RAN change
- Tell me briefly why your team is exploring new RAN equipment right now
- When did your executive target for expanded 5G coverage or accelerated capacity first move earlier than planned
- Approximately how many active cell sites does your capital program need to address in the next 12–24 months
- Which of these outcomes is the highest-priority metric your team will use to compare vendors
- If no vendor can show measurable improvement in your top metric during a 50-site trial, would your board still approve the current program
Reality check: where the network strains first
- If your current RAN had to carry 35% more data today, which sites or clusters would you expect to fail first and why
- Walk me through the last time you hit capacity on a macro site cluster, what happened operationally and how did you mitigate traffic
- Provide the number of sites currently running at or above 80% average utilization during peak hours
- For those high-utilization sites, which hardware generations and antenna configurations are you running today
- What single site-level constraint would make your team pause further testing or field trials immediately
Where the energy bill bites and how it changes decisions
- If you could reduce average site power by 20% on urban macros, how would that change your capital or operating plans
- Estimate your current average power draw per urban macro site during peak load
- How do you currently measure energy-per-bit in live traffic, do you use automated telemetry, periodic audits, or not at all
- Which site types contribute most to your energy spend by share
- If a vendor field trial failed to show at least a 15% reduction in energy-per-bit in live conditions, would you stop the evaluation
Who moves the needle: approval, ops, and procurement
- Identify the executives and committees who must approve a multi-year RAN vendor change and the main question each stakeholder will ask
- List the functional owners on your side who must be involved in lab benchmarks and field trials
- Walk me through the last procurement that changed a primary RAN vendor, what went wrong and what worked
- Indicate the team that will own integration with your OSS and BSS, and who controls access to those APIs
- If the pilot requires a named on-site engineer from your side for five days per site, can you commit that resource within six weeks
Integration realities and the gates you might not expect
- List the primary network management and orchestration systems this RAN must integrate with, and indicate which expose APIs
- Where is your inventory and topology data stored today and how accessible would that dataset be for a trial
- Do you maintain per-site power and environmental telemetry in a central system, and if so, who is the dataset owner
- How many months of KPI and traffic trace data can you provide for proposed trial sites
- Are there regulatory approvals, landlord consents, or cross-border data rules that could delay a field trial
- Which integration dependency, if unmet, would prevent progression to a live field trial
Risks you track and the ones that surprise you
- Tell me about a vendor risk from past rollouts that still affects your operations and how it showed up
- Inside your operations teams, which issue has cost you most in truck rolls or escalations over the past 12 months
- When software releases caused regressions in the past, how long did it take on average to restore normal performance
- Has anyone on your team proposed building a custom RAN or assembling open components instead of buying a full platform
- What single contractual or technical failure would make you walk away from a trial
The competitive set: incumbents, DIY and other alternatives
- Identify the incumbent or alternative you are most inclined to stick with, and explain why that option would survive a pilot
- Select the vendors or internal approaches still under active evaluation for this program
- For your incumbent to retain this business, what performance or commercial concession would they need to make
- Is there an internal proposal to build rather than buy, and if so who would sponsor and fund that effort
- What would have to be true about your current approach for you to decide not to change vendors this year
Acceptance criteria: the numbers that unlock a deal
- If lab benchmarks and a 50-site field trial deliver the headline numbers you need, which internal approvals will clear the path to a signed multi-year agreement
- For spectral efficiency, what minimum percent improvement over your incumbent would you require in the pilot
- For energy-per-bit, what minimum percent reduction in live field conditions do you require
- Name the roles that will formally sign off on pilot acceptance at site level and at program level
- If the pilot proves all thresholds, what procurement or budget steps remain before you can place orders
- If the pilot meets your energy and throughput targets, would you be prepared to start contract negotiations within 30 days
Operational readiness: practical gates and next steps
- Identify the regulatory, landlord, or power-access barrier most likely to prevent running a contiguous 50-site field trial
- How many of your planned trial sites already have validated power, rack space, and tower mounting documented
- Specify the team that will own on-site escalation during the trial and provide their average response time for critical fixes
- Are there commercial prerequisites, such as temporary spectrum access, test SIMs, or site landlord agreements, that must be in place before traffic can be loaded
- Would you be able to provide labeled SIMs or anonymized subscriber profiles for traffic validation, or would the trial need to rely on synthetic traffic
- If we schedule lab benchmarks in four weeks, can your team commit the necessary data extracts and on-site access within that timeframe
-
-
Solution Experience
Translate the buyer's outcomes into testing scenarios, integration expectations, and operational workflows using their real network context.
Solution Experience
- Solution Experience Session
- Confirm the current state and its cost to you
- You confirm the pass/fail acceptance criteria that will be used for lab and field evaluation.
- Deliver a tailored test plan and lab benchmark scripts for the agreed acceptance criteria within 7 business days.
- You confirm the proposed test scenarios faithfully reflect your peak-hour traffic, interference profile, and site types for the trial cluster.
- Quantify what failure means for the trial
- Provide site inventory for the proposed trial cluster, including site type, hardware version, and recent peak-hour traffic profiles.
- Provide OSS/NMS integration endpoints, API specifications, and required monitoring hooks for test integration.
- You confirm the integration endpoints and operational runbook responsibilities required to run the trial and accept results.
- Agree measurable acceptance criteria
- Map test scenarios to your real network context
- You agree on the remaining evidence required to move the engagement into Lab & Field Evaluation.
- Approve the final trial scope and acceptance criteria so lab benchmarking and field scheduling can begin.
- Walk through integration and operational workflows
- Validate outcomes and get confirmation
- Solution Experience Session
- Solution Experience Deck
- Solution Experience Brief
- meeting
- slides
- document
-
Solution Scope
Define hardware and software modules, trial cluster size, responsibilities, deliverables, and measurable acceptance criteria.
Scope Configuration
- Supply and deliver base station hardware
- Install macro base station on tower sites
- Install small cell and rooftop units
- Install and calibrate massive MIMO antenna arrays
- Deploy traditional integrated RAN software stack
- Deploy Open RAN-compliant RU/DU/CU integration
- Provision backhaul links and timing synchronization
- Integrate RAN with operator OSS/NMS and APIs
- Migrate live traffic to new RAN with cutover
- Deploy power-optimized firmware and per-site energy tuning
- Provide lab RF test kit and reference test suite
- Execute 50-site field acceptance and performance validation
- Provide spares inventory and field maintenance contract
- Qualify financing and incentives for capital purchase
Scope Questions
Supply and deliver base station hardware
- How many base station units do you require for the initial trial cluster (by model or SKU)?
- Which radio bands must the supplied base station hardware support (select all that apply, reference band names used in your license)?
- What form factors are required for delivered hardware (tower cabinet, remote radio head, integrated small cell enclosure)?
- Specify any factory configuration items to pre-load on units (firmware release, power class, antenna connector type, GPS/IEEE1588 profile).
- Provide the target delivery timeframe for the first hardware shipment to the lab or field cluster.
- List any physical logistics constraints at your sites that affect delivery (crane availability, vehicle access width, rooftop load limit).
Install macro base station on tower sites
- Describe the typical tower site characteristics for installation (tower type, mounting flange pattern, cabinet footprint).
- What access windows are available for on-site installation crews (hours per day, weekdays/weekends)?
- Provide the required mechanical and electrical deliverables at each tower site (concrete pad, AC mains amperage, generator transfer switch).
- Indicate whether single-line electrical diagrams (SLD) and site structural reports are available for each tower.
- Identify any safety or permit constraints for tower work (local permitting authority, lockout/tagout (LOTO) rules).
- Who is your authorized site contact for installation sign-off and what is the preferred contact method (email, phone, OSS ticket)?
Install small cell and rooftop units
- Where will small cells be mounted (street furniture, rooftop parapet, indoor venue) and what mounting brackets are required?
- What power provisioning exists at small cell locations (PoE, dedicated AC, battery backup) and what connectors are required?
- Provide required environmental enclosure ratings for rooftop and street furniture (IP rating, tamper/anti-vandal requirements).
- Do you have right-of-way or municipal permits in place for street-level small cell installation?
- State the expected average antenna height above ground (meters) and any LOS/NLOS constraints for rooftop installs.
- List any co-location constraints or existing equipment that must be integrated or relocated at each rooftop site.
Install and calibrate massive MIMO antenna arrays
- What MIMO orders are required per site (for example 32T32R, 64T64R) for the trial cluster?
- Which antenna mechanical alignment tolerances do you require (azimuth, tilt, boresight) for OTA calibration?
- Provide the acceptable VSWR or antenna return-loss threshold for field calibration and commissioning.
- List required tests for MIMO calibration on-site (OTA beamforming verification, reciprocity checks, cross-polarization isolation).
- Identify any tower or rooftop structural engineering approvals needed before installing large antenna arrays.
- Who will own antenna pattern validation and who will provide RF sweep equipment on site (your team, third-party contractor)?
Deploy traditional integrated RAN software stack
- Which release track do you require for the RAN software stack (stable production release, maintenance release, developer/test build)?
- What integration interfaces must the stack expose for your OSS/NMS (SNMP, NETCONF/YANG, RESTful APIs)?
- Provide your required node-level feature parity list compared to incumbent (handover parameters, inter-cell interference coordination, power control).
- Describe required software lifecycle practices (security patch cadence, maintenance windows, rollback plan).
- Indicate whether you need vendor-hosted OSS elements or on-premises controllers for the trial cluster.
- Estimate expected maximum concurrent user sessions per cell for the trial to size software capacity.
Deploy Open RAN-compliant RU/DU/CU integration
- Which O-RAN interfaces must be supported in the trial (Open Fronthaul eCPRI split, A1, E2)?
- What vendor interoperability testing do you require (RIC xApp/SMO integration, RU conformance reports)?
- Provide the acceptable latency budget between RU and DU for the chosen functional split in milliseconds.
- Identify required security controls for Open RAN interfaces (TLS, mutual auth, key rotation schedule).
- State whether platform adapters or custom drivers are needed to integrate the CU with your core signaling plane.
- Who will own RIC policy testing and who will supply test xApps for the field trial?
Provision backhaul links and timing synchronization
- Which backhaul transport types are available at trial sites (fiber, microwave, leased circuit, satellite)?
- What committed information rate (CIR) or bandwidth per site do you require for the trial cluster?
- What timing reference should be used for synchronization at sites (GPS PPS, IEEE 1588v2 Precision Time Protocol (PTP), Synchronous Ethernet)?
- Provide your acceptable jitter and delay thresholds on the backhaul link for the chosen split.
- List any backhaul SFP/SFP+ module types, WAN interface cards, or QoS markings required by your transport provider.
- Identify the lead time for provisioning new circuits or for ordering additional fiber connections to trial sites.
Integrate RAN with operator OSS/NMS and APIs
- List the OSS/NMS integration endpoints and protocols you will expose for onboarding (REST endpoints, SNMP collectors, syslog destinations).
- What authentication and authorization method does your OSS/NMS accept for API calls (OAuth2, API key, client TLS certificate)?
- Provide required northbound telemetry metrics and their polling frequency (per-cell throughput, PRB utilization, energy consumption per site).
- Indicate whether your OSS requires an adapter mapping (MIB to alarm model, CMDB connector) and the preferred format.
- Identify expected SLAs for alarm propagation and ticket creation from RAN events into your NMS.
- Who are the technical contacts for API onboarding and what are their preferred testing windows?
Migrate live traffic to new RAN with cutover
- Describe the target cutover strategy for trial sites (phased per cluster, big-bang per market, per-cell rolling migration).
- Provide the traffic profile to be migrated (average downlink/uplink throughput per cell, peak users per cell) for validating capacity.
- What fallback plan do you require if cutover causes service degradation (rollback window, automated revert to incumbent node)?
- How will you verify migration completeness for cutover sign-off (acceptable call-drop rate threshold, handover success percentage, throughput baseline)?
- Who will own subscriber re-homing and SIM/IMSI mapping tasks during migration and provide authorization for final cutover?
- When do you prefer to schedule the cutover windows to minimize subscriber impact (off-peak hours, weekend nights)?
Deploy power-optimized firmware and per-site energy tuning
- Which energy-saving features do you require enabled in firmware (adaptive transmit power, sleep-mode for carriers, dynamic carrier shutdown)?
- Provide per-site constraints that affect energy tuning (available cooling capacity, battery backup runtime, ambient temperature range).
- State target energy-per-bit reduction percentage you expect to achieve in the field trial relative to incumbent hardware.
- Specify required telemetry for energy validation (per-radio power draw, traffic volumes, active PRBs) and reporting intervals.
- What rollback mechanism do you require if power-optimized firmware causes performance regressions (automatic revert, manual intervention)?
- What evidence will validate per-site energy tuning is acceptable (sampled power logs correlated to throughput, per-site energy-per-bit reports)?
-
Lab & Field Evaluation
Execute lab benchmarks and a multi-site field trial against agreed criteria to validate spectral efficiency, MIMO performance, and energy-per-bit in live conditions.
- desired_state
- current_state
- stakeholders
- gaps
- success_criteria
- decision_readiness
- desired_state
- decision_readiness
- current_state
- success_criteria
- gaps
- stakeholders
- desired_state
- success_criteria
- stakeholders
- gaps
- current_state
- decision_readiness
- decision_readiness
- decision_readiness
- decision_readiness
- decision_readiness
-
Mutual Commit
Finalize commercial framework, SLAs, integration responsibilities, and deployment milestones for the multi-year agreement.
Agreement Modules
- Purchase Agreement
- Order Confirmation
- Master Services Agreement (MSA)
- Statement of Work (SOW)
- Service Level Agreement (SLA)
- Acceptance Test Plan
- Deployment Milestone Schedule
- Integration Responsibilities Annex
- Software License and Support Agreement
- Warranty and Spare Parts Agreement
- Commercial Term Sheet and Payment Schedule
-
Deployment
Operationalize rollout with readiness checks, execution, and outcome validation.
-
Pre-Deployment Readiness
Confirm site access, power/environment constraints, integration endpoints, and named owners required for rollout.
Pre-Deployment Questions
Environment and site access
- Is there an approved site list (site IDs and addresses) for all rollout locations? (So we can produce per-site work orders and permits.)
- Earliest scheduled site access date (per site if multiple). (We need this to sequence deliveries and technician bookings.)
- Are any site-level physical or power/environment constraints applicable (power budget limits, generator-only, rooftop load limits, restricted HVAC, or access restrictions)? (List constraints per site in the next field if 'Yes'.)
Data and configuration readiness
- Has the buyer identified a single source of truth for per‑site configuration (inventory system, OSS table, or canonical spreadsheet) and named the owner? (We will pull parameters from that source during provisioning.)
- Which integration endpoints will the deployment need to connect to? Select all that apply. (This determines integration adapters and test plans.)
- Are provisioning credentials and secure API access for the selected endpoints already provisioned, or will the deployment team need to request them? (We will collect exact credentials in the Configuration Details stage.)
People and ownership
- Who is the onsite logistics/civil single point of contact and escalation owner? (Name, role, and best contact — this owner approves site access and contractor work.)
- Who is the network integration technical owner and who is the operations acceptance owner? (Provide name and role for each — these owners sign off per site.)
Timing and constraints
- Are there any blackout windows, regulatory restrictions, or maintenance freezes that would block rollout? (If yes, we will ask for affected site/date ranges in follow-up.)
- Target production cutover start date or earliest permissible month. (This date will anchor the rollout schedule and sequencing.)
-
Configuration Details
Lock exact configuration values the deployment team will use — provisioning credentials, per-site radio parameters, and monitoring hooks.
Configuration Details
Environments & Endpoints
- Primary deployment environment name — enter the exact identifier used in deployment scripts and manifests. Default: production. (Consumed by deployment orchestration)
- Deployment region (select one). Default: Global. (Used to select region-specific provisioning playbooks and sequencing)
Provisioning & Credential Handling (non-secret identifiers only)
- Provisioning account identifier (non-secret) — enter the integration user name or client ID the seller will reference in automation. Example format: deploy-integ-01. Do not paste secrets. (Consumed by provisioning module)
- Where will provisioning secrets (keys/certificates) be stored and exchanged? Select one. The secret values themselves will be exchanged over the chosen channel at kickoff — do not enter secrets here.
Per-site Radio Parameters
- Default transmit power per site (dBm) — numeric integer between 0 and 60. Default: 46. (This exact value will be written to radio config during provisioning)
- Operational frequency band for this cluster (select one). If you choose 'Other', specify the exact center frequency (MHz) in the next field. (Used by radio provisioning)
- Custom center frequency in MHz — numeric (enter only if you selected 'Other' above). Example: 3600. (Exact value applied to per-site radio profiles)
Monitoring, Telemetry & Validation Hooks
- Monitoring collector endpoint URL (format: https://collector.example.com/path). Leave blank if the seller will use seller-managed monitoring. (Consumed by monitoring integration during Go‑Live Validation and ongoing operations)
- Telemetry protocol for device metrics (select one). Default: SNMPv3 if available. (Used by the monitoring integration)
- Site-down alert threshold (minutes without heartbeat) — integer >=1. Default: 5. (This threshold configures alerting during validation and steady-state monitoring)
-
Deployment
Execute the phased rollout across trial and production clusters with clear owners, sequencing, and escalation paths.
-
Go-Live Validation
Verify per-site acceptance criteria, traffic performance baselines, and operational readiness before declaring the migration complete.
Checklist items
- Upload Lockout/Tagout (LOTO) verification record for each site
- Receive per-site acceptance sign-off from the buyer's designated approver
- Submit baseline traffic performance report for each site
- Archive energy metering and energy-per-bit measurement report
- Validate monitoring, telemetry, and alarms are reporting to the buyer NOC
- Verify integration endpoint connectivity and provisioning authentication
- Lock and archive final per-site configuration snapshot and software/firmware BOM
- Confirm operational runbooks, maintenance checklist, and escalation matrix delivered and accepted
- Validate rollback/backout procedure and checkpoint
- Close change-control release to production and record final go/no-go decision
-
-
Success
Monitor spectral efficiency and energy savings, run recurring reviews, and track issues and enhancement requests for continuous improvement.
Success Reviews
- Go-Live Health Check (weeks 1-4)
- First Measurement Review (weeks 4-10)
- Acceptance Gate — Outcome Validation and Formal Acceptance (around day 90)
- Ongoing Operational Review (monthly, then quarterly)
- Quarterly Technical Business Review (quarterly)
Issues & Enhancements
- Close resolved incidents and update the incident register with final statuses.
- Publish the acceptance decision record with pass/fail status and named signatory.
- If decommissioning, schedule the incumbent turn-down and confirm data archival completion.
- Document remediation tasks for any conditional criteria with verification test plans and dates.
- Reduce the number of critical open incidents and confirm timelines for remaining high-priority tickets.
- Prioritize top enhancement requests to be actioned in the next quarter.
- KPI trend review
- Confirm KPIs continue to meet accepted tolerances or document required corrective trajectories.
- Re-confirm acceptance criteria and owners
- Schedule the next parameter optimization window and required validation tests.
- Publish the prioritized enhancement backlog with target delivery quarters.
- Long-term KPI trends and capacity outlook
- Confirm the percentage of sites meeting spectral efficiency targets and the average energy consumption per bit, and record any sites requiring targeted remediation.
- Agree resource and readiness actions needed to sustain KPI performance next quarter.
- Finalize the prioritized operational improvement list for the next quarter.
- Produce a one-page executive metrics summary showing site-level pass rates against Solution Scope targets.
- Schedule targeted field verifications for sites below spectral efficiency targets.
- Update the enhancement roadmap with expected delivery quarters for prioritized items.
- Deployment validation report completed and distributed within 48 hours.
- All critical blockers that would prevent meaningful KPI collection identified with resolution dates.
- Monitoring and data export pipelines confirmed healthy for the upcoming measurement window.
- Publish the deployment validation report and telemetry health checklist.
- Open tracked incident records for each blocker with target resolution dates.
- Schedule the First Measurement Review once 14 days of clean telemetry are available.
- Present first-window outcome data
- Decide which corrective actions to implement before the acceptance gate and record timelines.
- Identify any data quality issues that must be closed before the acceptance gate.
- Confirm the acceptance gate date and the measurement window needed to produce a pass/fail decision.
- Run targeted root-cause analyses for sites outside expected spectral efficiency ranges.
- Apply agreed parameter tuning or software patch in a controlled subset and collect 14 days of post-change telemetry.
- Publish a pre-acceptance readiness checklist ahead of the acceptance gate meeting.
- Restate acceptance criteria and numeric targets
- Formal acceptance decision recorded with a named signatory for the enterprise engagement.
- Incumbent decommissioning decision and archival plan confirmed to prevent dual-operation and support adoption metrics.
- Remediation actions for any failed criteria documented with deadlines and verification steps.
- Deployment and migration validation
- Operational readiness and resource needs
- Incident and ticket burn-down
- Present acceptance-window outcome data
- Gap diagnosis and root-cause hypotheses
- Enhancement request backlog and prioritization
- Incident trend analysis and SLA performance
- Corrective actions and parameter tuning
- Early adoption and usage signals
- Pass/fail determination and signatory
- Confirm timeline to acceptance gate
- Operational adjustments and monitoring updates
- Incumbent decommissioning and fallback closure
- Enhancement outcomes and next-quarter priorities
- Blockers and open issues
- Immediate remediation actions
- Remediation plan for unmet criteria