Test. Measure. Verify. On real devices in real markets.
Run testing, verification and network measurement through physical devices connected to live carrier networks across the markets that matter to your business.
Tell us the market, carrier, device or workflow you need. We'll show you what Unetwork can reach.
Aggregated ASN-level intelligence from the attested v3 telemetry plane. Wider Unetwork fleet: ~58K 30-day active devices · August 2026.
The same network. Pointed at your question.
Unetwork operates a composable, people-powered global edge network with vast geo-diverse coverage. Every endpoint on it is a real handset, on a live carrier network, in a real market. Carriers and enterprises use that network to test applications, verify telecom services and measure network conditions in the places they actually sell.
Real devices. Real networks. Real locations.
No emulators. No data center SIMs. No simulated routes. A task is dispatched to a physical device in the market you asked about, and the evidence comes back in a consistent, machine-readable format.
Reality is the final test.
Controlled testing gives teams repeatability, speed and known conditions. The real world adds variables that are much harder to reproduce: local carriers, physical SIMs, real signal conditions, routing, congestion, geography and the behavior of actual endpoints. That is where Unetwork adds visibility.
Controlled testing provides
- Repeatable conditions
- Known device state
- Automation
- Controlled network configuration
- Scalable software testing
The real world adds
- A physical handset in the market
- Live local network conditions
- Actual carrier routing
- Real signal and congestion
- What ultimately arrived at the endpoint
Does the application render and behave correctly on this device?
Did the OTP actually arrive on Vivo in São Paulo, and what happened at the endpoint?
Both matter. They are not the same test.
Existing tools solve important parts of the problem. Unetwork adds the real-world layer.
Why not just use someone local?
A local tester can answer a question in one place. Unetwork is designed to run repeatable tasks across multiple devices, networks and markets and return results in a consistent evidence format. The same test definition can then be repeated when you need it again.
One network. Three kinds of answer.
One physical network. Three ways to understand what is really happening. Three commercial solution paths are productized because they are what teams ask for most: Real-Device QA, Network Intelligence and Entropy Contribution. The underlying network supports additional workloads.
Real-Device QA
Test applications and end-to-end customer journeys on physical handsets operating under real market and network conditions.
Who it is for
For QA and release teams launching into new markets.
What it answers
Does the journey complete on this device, on this carrier, in this market, and how long did each step take?
From question to evidence
Define the journey
Specify the customer journey you need tested, step by step, and what a pass looks like at each step.
Target the conditions
Choose the market, carrier, device profile and operating system versions that matter for this release.
A real handset executes
Your journey runs on a physical device on a live local carrier, under whatever signal and network conditions that market actually has.
Evidence comes back
Pass or fail at every step, with screenshots, device logs, timings and the endpoint and network context for the run.
Applications
Application workflows · Device and OS compatibility · Localization · Payments · OTP and authentication · Production customer journeys
Specific network requests
That list is where most work starts, not where it stops. Name the carrier, the route, the network condition or the device population you need and we will scope it against the network. If it can be reached from a real handset, it can be asked for.
How to engage
Triggered from CI, the command line or a dashboard. No SDK goes into your build.
See what a Real-Device QA run returns
Samsung Galaxy S23 · Android 14
Hardware attested
Vivo
Brazil
Registration → OTP → Login
PASS · 4.8 sec
Evidence per run also includes screenshots, step results, timings and logs.
Network Intelligence
Measure network conditions, coverage, routing, performance and quality using distributed physical endpoints operating on live networks.
Who it is for
For network intelligence and analytics teams measuring from outside their own infrastructure.
What it answers
What do real handsets on real networks actually see, in places you do not operate and cannot instrument?
From question to evidence
Define the measurement
Start with the network question you need to answer: coverage, connection state, service quality, routing behavior or another supported network observation.
Target the population
Choose the markets, carriers, device populations and other relevant conditions. The same measurement is then distributed across qualifying endpoints rather than relying on one centralized probe.
Physical endpoints measure
Real devices make the supported observations from the networks and locations in which they are operating. This adds an outside-in view of network behavior.
Evidence comes back
Measurements return in a structured format that can be analyzed by geography, carrier, device population, time and other supported dimensions.
Examples
Coverage · Routing · Quality of service · Performance · Carrier comparison · Network anomalies
The seven continuous measurement tasks
Confirms a device is genuinely connected to a live carrier network and behaving as a real handset, not a simulated endpoint.
Checks how traffic is actually routed to the destination and whether the path matches what was contracted.
Exercises the interconnect points that carry the traffic and records how each behaves under real conditions.
Builds a picture of the operator environment in a market: who is present, what is reachable, how it performs.
Samples signal and availability from the physical locations where the devices already are.
Records latency, throughput and completion behavior as experienced by the endpoint rather than the core.
Surfaces route manipulation, number substitution and other behavior that only shows at the destination.
Customer evaluation sample - Top 25 countries in the last 30 days
Delivered as aggregated country + ASN rows - no individual user or device records.
What the sample contains
- Network identity - Country, ASN and network name.
- Coverage depth - 30-day active-device cohort size.
- Observed reach - Unique public IPs and observation volume.
- IP behavior - Average IP changes per device per day.
- Network composition - Residential / mobile vs. datacenter share.
Why a buyer should care
- Benchmark “normal” - Measure how genuine residential / mobile networks behave by ASN and market.
- Compare network dynamics - Spot large differences in IP churn and address rotation across carriers and regions.
- Add an external reference layer - Test whether real-device network signals complement fraud, identity, bot or IP-reputation models.
- Evaluate before integration - Start with a CSV against known ASNs; define recurring feed / API requirements only after the signal proves useful.
Measurement output · customer sample
Real aggregate observations from a Unetwork customer sample: where active devices sit, how many unique public IPs each network exposes, and how often those IPs change. Aggregated to country and ASN cohorts - no individual device or IP histories.
Combined fleet coverage by country (v2 + v3)
Active-device country cohorts observed in the last 30 days, combining the v2 and v3 fleets.
Source: Unetwork combined 30-day country coverage. v2 and v3 are combined by country. Country-cohort counts must not be summed to infer the unique global-device total.
Unique public IPs observed by network
Unique public IPs observed in the last 30 days, by network.
Source: Unetwork 50-network customer sample. Aggregated country + ASN cohorts; no individual device or IP histories.
IP churn varies sharply across major residential / mobile networks
Average IP changes per device per day, 15 largest active-device cohorts.
Source: Unetwork customer sample. Chart uses the 15 largest active-device cohorts in the sample, ranked by observed IP churn.
A cross-section of the networks in this sample
Six representative country + ASN cohorts, showing cohort size, address space, observation volume and IP rotation.
| Market | Network | Devices* | Unique IPs | Observations | IP changes / day |
|---|---|---|---|---|---|
| IN | Reliance Jio | 1,581 | 65,264 | 14.1M | 3.55 |
| NG | MTN Nigeria | 764 | 16,784 | 4.0M | 4.40 |
| US | T-Mobile USA | 690 | 6,437 | 11.0M | 0.62 |
| NL | KPN | 631 | 2,478 | 11.8M | 0.38 |
| PH | Globe Telecom | 537 | 4,517 | 4.8M | 0.65 |
| US | Comcast | 486 | 2,411 | 6.3M | 0.36 |
* Active-device counts are per country + ASN cohort and may overlap across cohorts.
Send us 20-100 ASNs or markets you already understand. We return an aggregated comparison dataset so your team can test whether the signal adds value before integration.
Wider Unetwork fleet: ~58K 30-day active devices. High-resolution panel figures refer to the attested v3 telemetry plane.
Entropy Contribution
Physical devices contribute hardware-sourced entropy from supported device sensors and system sources, creating geographically distributed randomness with traceable physical provenance.
Who buys it
Teams that need entropy with a physical provenance rather than a software pseudo-random source
From question to evidence
Define the requirement
Specify the entropy contribution required by the supported workload, including any relevant volume, endpoint or collection requirements.
Target the device population
Define the supported device and attestation requirements for the workload. Unetwork identifies suitable physical endpoints capable of contributing to the task.
Physical hardware contributes
Supported entropy is gathered from participating physical devices operating under real-world conditions.
Entropy and provenance come back
The contribution is returned with the supported task and endpoint metadata, including the applicable attestation state.
More from the network: Telecom Assurance and Survey Tasks
Telecom Assurance
Verify voice, CLI, SMS, OTP and connectivity at the physical destination rather than relying only on what upstream systems report.
Who it is for
For carriers, aggregators and CPaaS teams verifying what arrives at the destination.
What it answers
Did the call land with the CLI we sent, did the message arrive with the sender ID we set, and did the route behave?
From question to evidence
Define what must arrive
Specify what you expect the destination endpoint to receive: the expected CLI, an SMS Sender ID, OTP content, call behavior or connectivity outcome.
Target the destination
Choose the destination market, carrier and other supported endpoint requirements. Unetwork identifies suitable physical devices on the relevant network.
A physical endpoint receives
The call, message or supported verification task reaches a real handset on the destination network. Unetwork observes what actually arrives at that endpoint.
Evidence comes back
The result is returned with the available destination context, so the expected outcome can be compared with what was actually observed.
See what a Telecom Assurance run returns
United Kingdom
Spain
Physical handset, local SIM
Software attested
CLI route verification
+44 XXX XXX XXXX
+44 XXX XXX XXXX
VERIFIED
Core products
Caller ID Verification
A physical handset in the destination market answers the call and records what CLI actually presented, so you can compare the number you sent against the number the recipient saw.
Returns
Expected CLI, observed CLI, carrier, market, verification result
SMS Sender ID and Content Testing
Messages are received on a real SIM on the target network, and the sender ID, body content and delivery timing are captured as they arrived, not as they were submitted.
Returns
Sender ID as presented, message body as received, delivery timing, network and market
Connectivity Verification
Continuous confirmation that a route is reachable and behaving from inside the destination network, run from devices already resident in the market.
Returns
Reachability, route behavior, timing, endpoint and network context
The network can also do more.
Unetwork also supports surveys, research and other compatible real-world tasks that benefit from distributed physical participation. These are real products, kept deliberately outside the three commercial categories.
Survey Tasks
Put structured questions to participating device owners in the markets you choose, using the Unetwork network to reach respondents by supported geographic and network criteria.
Who buys it
Research and market intelligence teams needing responses from specific markets and carrier populations
From question to evidence
Define the questions
Create the structured questions you need answered and define the response format. Keep the survey focused on the decision the research needs to support.
Target the respondents
Specify the supported market, geography, carrier population or other respondent criteria relevant to the study. Unetwork identifies eligible participants matching the requirement.
Participants respond on real devices
Participating device owners receive the survey through Unetwork and submit their responses from the markets being studied. Participation is opt in.
Responses come back
Responses are returned in a structured format with the supported targeting and task context needed for analysis.
Define. Target. Execute. Get evidence back.
The shape of every engagement. Each service explains these four steps in its own terms above.
Define the question
What do you need to test, measure or verify?
Target the conditions
Choose the relevant market, carrier, device, operating system and workflow.
A real endpoint executes
Unetwork matches the task to suitable physical devices and executes the supported workload.
Evidence comes back
Depending on the workload, the result may include screenshots, logs, step results, timings, measurements and verification data.
One question. One real endpoint. Evidence back.
What a pilot looks like
You send the market, carrier, device or workflow. You choose the evidence you need back. You get a defined scope and commercial terms before anything runs.
Sample evidence report
Ungated, with no email gate at any point. The report includes a run identifier so any result can be traced back to the endpoint that produced it.
Integration
Web portal · API · Automation
Know the endpoint behind the evidence
Unetwork supports three endpoint attestation states, allowing the platform to record which attestation state applied to the participating endpoint.
No attestation
No additional software or hardware attestation result
A physical Unetwork endpoint without an additional software or hardware attestation result.
Software attested
Software verification
The endpoint has passed the supported software-based attestation process.
Hardware attested
Hardware-backed verification
The endpoint has passed the supported hardware-backed attestation process.
Attestation describes how strongly the device state has been verified, and the right level depends on the workload. These three states are presented at equal weight on purpose: there is no ranking here, and no attestation is the correct answer for a large share of real work.
Workloads can target endpoints by attestation state where that requirement is relevant to the task.
Real-world execution. The task runs under the network and market conditions required for the workload.
Evidence returned. The result is returned with the device and network context available for that task.
What we will and will not say
The platform supports three endpoint attestation states, and workloads can target endpoints by attestation state where that requirement is relevant to the task.
Real devices, controlled access.
Running a business workload on a distributed physical network should not mean uncontrolled access to the participating device.
Devices join the network deliberately and can leave it.
Customer work is isolated on the device.
Customer workloads run without access to personal data stored on the handset.
Runs are logged and retained to a defined schedule.
Questions teams bring to Unetwork.
One question in, one real endpoint, one piece of evidence out.
Does our onboarding journey work in this launch market?
- Task
- Run the defined customer journey on a suitable physical device under target market conditions.
- Evidence
- Pass or fail result, screenshots, timings, logs.
- Service
- Real-Device QA
How is our CLI presenting after this international route?
- Task
- Observe the destination behavior on a qualifying physical endpoint.
- Evidence
- Expected CLI, observed CLI, carrier, market, verification result.
- Service
- Telecom Assurance
Is our OTP reaching users on the target carrier?
- Task
- Run the authentication flow against a qualifying endpoint.
- Evidence
- Observed delivery, timing, endpoint and network context, journey result.
- Service
- Telecom Assurance
Contact us.
Tell us the market, carrier, device or workflow you need. We'll show you what Unetwork can reach.
We'll come back with what the network can reach for your exact requirement.
Frequently asked questions.
Written in the phrasing teams actually search for.
Which countries and carriers can Unetwork reach?
Unetwork has active physical presence in 185 countries. Contact us with the market, carrier, device and task you need and we'll confirm availability for your exact requirement.
How is this different from a hosted device farm?
A device farm gives you a handset on data center connectivity. Unetwork gives you a handset on a live local carrier network in the market, so carrier routing, local congestion and destination behavior are part of the result rather than absent from it.
Do I need to install an SDK in my app?
No SDK goes into your build. Runs are triggered from CI, the command line or a dashboard.
Whose phones are these, and have the owners agreed?
Participation is opt in. Devices join the network deliberately and can leave it.
Can you test OTP and SMS delivery on a specific carrier?
Yes. That is SMS & OTP verification under Telecom Assurance, running on a real SIM on the target network. Availability for a named carrier is confirmed through the coverage check.
How do you know the device is real and not an emulator?
The platform supports three endpoint attestation states, described above. Workloads can target endpoints by attestation state where that requirement is relevant to the task.
What does a pilot cost and how long does it take?
Scope and commercial terms are agreed before a pilot begins. Contact us with your requirement and we'll come back with scope, duration and pricing.
What evidence do I get back?
Depending on the workload: screenshots, logs, step results, timings, measurements and verification data, each carrying a run identifier and the endpoint and network context it came from. Examples for two of the three services are shown above.