We took 2nd place at the Open Gateway Hackathon run during Mobile World Congress 2026 by Talent Arena. The room was packed with strong teams and real demos—programmable networks, devices on real SIMs, and judges who knew their telco stack—so landing on the podium felt genuinely hard-earned.
This post is about the experience: why we joined, how the idea turned into a weekend build, what broke along the way, and what I’d ship next.
For architecture, code paths, and implementation detail, see the project page:
Smart Focus Streaming – technical deep-dive.
Why this hackathon
The format pushed you beyond slides: Open Gateway, Nokia Network as Code, QoD, real device identifiers, and APIs that behave like production—not toy sandboxes.
We wanted something that:
- Solves a real problem (bandwidth-heavy video).
- Uses WebRTC and network APIs in the same story.
- Has a demo you can understand in ten seconds: draw a box, watch quality follow the box, read real Mbps on the screen.
The idea: Smart Focus Streaming
Most streams spend bitrate on pixels nobody is looking at. Our pitch:
- A low-res “context” stream for the full frame.
- High resolution only in the region that matters—the user’s rectangle or ML-driven ROI.
- A web dashboard to switch modes and move that focus.
- Room to plug in Network as Code (e.g. QoD) when the link needs a bump.
From the jury’s perspective: open the grid, open a camera, flip to HYBRID, draw a rectangle, show bandwidth react. That loop carried the story.
What we shipped in a weekend
Android (Kotlin) – Camera capture, TFLite for “vision” hints, WebRTC with two inbound video tracks (context + source), a DataChannel for mode and hybrid rectangle, and HTTP signalling on :8888.
Python (FastAPI) – MongoDB for cameras, REST for focus area and mode, and an SDP proxy so the browser never hits the phone’s origin directly (CORS stays sane). We normalised legacy signalling URLs so :8080 and missing ports still landed on 8888.
React dashboard – Grid of live previews, detail view with LOW / HIGH / VISION / HYBRID, draggable focus rectangle on the video, and bandwidth from getStats() (including 0.0 Mbps when nothing is coming in—no fake wobble once we were on the real API).
End-to-end it was: device → backend → dashboard → device, with a demo that fit the hackathon brief.
What actually hurt (and how we fixed it)
1. Many WebRTC connections
Grid plus detail meant multiple peer connections per camera early on—extra load on the phone and flaky renegotiation. We stabilised always-on grid previews and a richer detail view. Next version: one shared connection per camera across the app.
2. Signalling URLs and ports
Half the team registered http://phone:8080, half :8888; the proxy would 500 and the UI looked “broken” until we normalised every URL server-side and relaxed the frontend guard to only block truly missing URLs.
3. Mock vs real bandwidth
We had mocked Mbps for UI polish. Once the stream was real, fake numbers were worse than nothing. Mock bandwidth stayed for a mock data source only; with the live API, only WebRTC stats drive the card and sparkline.
Demo day
Walkthrough:
- Grid – several cards, live preview, Mbps visible.
- Detail – HYBRID mode.
- Rectangle – user-drawn focus; high-res follows the ROI.
- Bandwidth – numbers move when you change mode or kill the stream.
Judges cared that the idea maps to surveillance / drones / field ops, that integration was end-to-end, and that the bitrate readout was real, not a prop.
After the hackathon
If I extend this beyond the PoC:
- Single WebRTC session reused between grid and detail.
- Deeper NaC: trigger QoD when the focus region is “hot” or when ICE degrades.
- Edge / encoder path to measure savings with proper ROI encoding, not just composition tricks.
- Before/after benchmarks worth publishing.
Thanks to Talent Arena, MWC, Nokia, and everyone who organised and judged. Congrats to the winners and to every team that brought a working demo to a tough room.