Your mobile application uses cloud servers, but the latency between device and cloud is 50–150 ms. For AR, IoT, or gaming, this is critical. Edge Computing based on 5G MEC reduces RTT to 1–10 ms by moving computation to edge nodes. We have implemented such solutions for logistics, retail, and industry, and we know where edge is truly needed and where it is unnecessary complexity.
Consider a typical scenario: you are developing an AR navigation app. Video frames are sent to the cloud, the algorithm recognizes objects, and returns annotations. With cloud architecture, latency of 180–200 ms makes AR unnatural. With edge, latency drops to 45–60 ms — quite acceptable for a smooth experience. On one project for a logistics operator, we cut cloud data transfer costs by 40% due to local processing on MEC. Which architecture suits your project? Contact us — we'll conduct an audit.
Suitable and Unsuitable Scenarios for Edge Computing
Edge Computing is justified when latency is critical (< 20 ms) or raw data volume is too large to transmit to the cloud.
Suitable tasks:
- Real-time video stream processing (AR annotations, object detection without sending video to cloud)
- IoT device control with response requirement < 10 ms (industrial automation, medical devices)
- Multiplayer gaming with regional matchmaking
- Local aggregation of telemetry before batch sending to cloud
Tasks where edge is not needed:
- Ordinary REST API requests where 100 ms is indistinguishable from 50 ms for the user
- ML inference of models > 500 MB (cheaper to keep in cloud)
- Any task without strict latency requirements
How to Implement Service Discovery?
On the mobile app side, edge computing requires several architectural changes. The first is discovering the nearest edge node. When connecting to a 5G network, the app requests the Edge Discovery Service (standardized in ETSI MEC 011) and receives the endpoint of the nearest MEC server:
// iOS let discoveryClient = MECDiscoveryClient(appId: "com.myapp.edge") let edgeEndpoint = try await discoveryClient.resolveNearestEdge( location: locationManager.location, serviceType: .videoProcessing ) For platforms without ETSI MEC API (most commercial clouds — AWS Wavelength, Azure Edge Zones, Google Distributed Cloud Edge) — proprietary SDKs: AWSWavelengthClient, Azure SDK for Edge Zones.
Fallback to cloud. Edge nodes are less reliable than cloud regions. The code must handle edge unavailability: on timeout > 50 ms or HTTP 503 from edge — automatic retry to cloud endpoint. The switch must be transparent to UX. We implement this via Circuit Breaker pattern with half-open state: after 3 consecutive errors — circuit open, all requests go to cloud, after 30 seconds — half-open (probe request to edge), if successful — close circuit.
Data partitioning. Not all data goes through edge. Two-tier architecture:
| Data Type | Route | Reason |
|---|---|---|
| Video frames for processing | Edge | No need to send to cloud, processing locally |
| Detection results | Cloud | Small volume, needs persistence |
| User settings | Cloud | Accessibility from any device |
| IoT control commands | Edge | < 10 ms requirement |
| Command history | Cloud | Audit, analytics |
Latency comparison:
| Scenario | Edge (ms) | Cloud (ms) | Improvement |
|---|---|---|---|
| AR annotation | 45–60 | 180–200 | up to 70% |
| IoT command | < 10 | 60–80 | > 85% |
| Video analytics (1 frame) | 100–150 | 300–400 | up to 60% |
Implementation: AR with Edge Inference
Practical example: AR app for warehouse logistics. Camera scans barcodes on boxes, edge server on MEC recognizes and returns product data, app overlays AR annotation.
Full pipeline:
- Camera → frame buffering → JPEG compression (720p, quality 60)
- HTTP/2 POST to edge endpoint (keep-alive, single connection)
- YOLOv8 inference on GPU edge server (15–30 ms)
- JSON with bounding boxes → AR overlay via ARKit / ARCore
Latency target: frame → annotation < 80 ms. With edge (20 ms to MEC) + inference (15–30 ms on GPU) + network overhead (10 ms) = 45–60 ms. Realistically achievable. Through ordinary cloud (150 ms RTT) + inference = 180–200 ms. AR at such latency looks unnatural.
On iOS side, we use AVCaptureSession with AVCaptureVideoDataOutput, downscale via vImageScale_ARGB8888 before sending. URLSession with HTTP/2 and keep-alive connection — do not create a new connection per frame, that adds +30–50 ms handshake latency.
On Android — CameraX with ImageAnalysis.Analyzer, JPEG compression via YuvToRgbConverter → Bitmap → compress(JPEG, 60), OkHttp with HTTP/2 and connection pooling.
Request frequency: not every frame, only when camera movement > threshold or every 100 ms via timer. Video 30 fps = 30 requests per second = unacceptable. 10 requests per second with client-side overlay interpolation is a working compromise.
What to Do When 5G Connection Is Lost?
5G is not everywhere, even if the app is positioned as a "5G app." On 4G, edge latency loses its meaning (RTT to MEC can be 80–120 ms). On 3G/WiFi — we work in cloud-only or offline-first mode.
Network condition detection: NWPathMonitor (iOS) / ConnectivityManager.NetworkCallback (Android). When switching to 4G — automatically switch to cloud endpoint. When network is lost — local ML inference via CoreML / TensorFlow Lite with a model bundled in the app (a smaller and less accurate version of the edge model).
What's Included in the Work
- Designing edge interaction architecture (discovery, fallback, data routing)
- Integration of SDKs for MEC (ETSI or cloud providers)
- Implementing Circuit Breaker and offline logic
- Testing on real 5G networks and emulators
- Documentation for operating edge modules
- Post-launch support (2 months)
Our experience: years of practice in mobile development, 50+ completed projects with edge and 5G, certified engineers (Apple Certified iOS, Google Associate Android). Get a consultation for your project — we'll assess the feasibility of edge and propose an optimal architecture. Contact us to get started.