Project update 2 of 15
Cloud-based Cellular Network in a Browser with uSDR!
by Andrew Avtushenko, Sergey KostanbaevWe are thrilled to unveil a groundbreaking development that showcases the true potential of our platform: a web application that enables a fully functional 2G cellular network based on the Osmocom stack. The base station processing is done entirely in the browser, while the core network operates in the cloud. That way, you can scale up your network around the world easily while managing everything under one account.
By harnessing the capabilities of the WSDR platform, we are taking a significant step forward to make network deployment more accessible, bringing seamless coverage to everyone, anytime, anywhere. Given that 41% of the world’s population has no access to basic phone service and mobile coverage at all, we decided to start with a tool for those who want to fill that gap. Providing no hassle, one-click cellular network deployment brings us closer to the goal of providing coverage for everyone.
If you’re wondering, yes, running a network on the smartphone works too. You can keep your network with you wherever you go and re-deploy it in case of disaster recovery.
The journey of making the Osmocom stack available on the web wasn’t straightforward at all. Our optimistic estimate of two weeks became almost two months of hacking.
The full 2G stack consists of the following Osmocom programs:
| Program | Description |
|---|---|
| OsmoHLR | Home Location Register, stores subscriber IMSI, phone number, and auth tokens. |
| OsmoMSC | Mobile Switching Center, handles signalling, i.e., attach/detach of subscribers, call establishment, messaging (SMS and USSD). |
| OsmoMGW | Media Gateway, is instructed by the MSC and/or the BSC to direct RTP streams for active voice calls. |
| OsmoSTP | Signal Transfer Point, routes SCCP messages between MSC, BSC, HNBGW and for 3G also the SGSN. |
| OsmoBSC | 2G Base Station Controller, manages logical channels and other lower level aspects for one or more 2G BTS; it is technically part of the BSS and not the "core network". |
| OsmoGGSN | Gateway GPRS Support Node, "opens" GTP tunnels received from SGSNs to internet uplink. |
| OsmoSGSN | Serving GPRS Support Node, handles signalling, i.e., attach/detach of subscribers and PDP contexts. |
| OsmoBTS | for 2G networks, drives the TRX and ties to the BSC via Abis-interface. |
| OsmoTRX | SDR Burst interface for SDR based OsmoBTS |
| OsmoPCU | for 2G networks, a component closely tied to the BTS, drives the TRX for PS timeslots and ties to the SGSN via Gb-interface. |
| OsmoSIPConnector | Optional: switch OsmoMSC to external MNCC and forward Call Control and RTP to a PBX of your choice. |
How We Did It
First of all, we removed all of the components related to GPRS/EDGE, just to make things easier.
We started with a really basic approach, just putting OsmoTRX in the browser and leaving everything else in the "cloud." To simplify things further, we started with running under node.js.
The first issue we found with even running under node.js was just compiling stuff using Emscripten. Due to the number of dependency libraries, extra efforts were required to get everything included. Some libraries, notably the last version of talloc, required a special run time configuration that just doesn’t work well with Emscripten. But after some tweaks and stubs, we managed to compile libosmocore! That was a success, but it was still too early to celebrate anything.
The next step was compiling OsmoTRX. That was a huge task actually. Unlike all other Osmocom programs, OsmoTRX is multithreaded with multithreaded fifo. Emscripten supports threads with limitations, so again with a number of tweaks it’s ready. To simplify debugging, we abstracted away socket operations in OsmoTRX to API calls. So the whole OsmoTRX is a library with a Javascript interface. Then, we wrapped every UDP socket into a WebSocket connection to the backend. Running under node.js wasn’t a big problem actually. It worked almost the same way as the native application.
But when we tried to run it under a browser, the 2G network would operate for three to five seconds before shutting down with lots of errors during operation. It took us another month to understand and fix all these issues. To name just the bigger ones:
- WebWorkers scheduling in the browser was different than in node.js. OsmoTRX normally operates with 2500 samples at 1 MSps, which gives 4 ms scheduling. Browsers can't deliver that reliably.
- Async operation make scheduling even worse, yielding even more unreliable scheduling
- We had WebUSB operation in main (DOM thread), so any operation within a page (button click, scroll) would pause USB transfers. In the end we put WebUSB IO operations in a dedicated worker.
To address all these scheduling issues we almost wrote our own OsmoTRX; we removed all threads and made it single threaded with exact order of operations. This simplified OsmoTRX doesn’t support multi-BTS, but we don’t need that support in the web either. After all the redesign and tests, we were happy to integrate it with the cloud. Well, in this case the cloud was a backend process on the same host. But that didn’t work. After wiresharking and debugging we spotted the problem — it was our emulated link over UDP via WebSockets. Somehow data was getting delayed and the scheduler at OsmoBTS would go haywire.
After another week, we came to the conclusion it wasn’t a great idea to push all bursts over WebSockets. So we integrated OsmoBTS into the web. In that case, the OpenBTS scheduler didn’t get delayed and it was a first win for our browser-based network! Our phones were able to register on the network! But there was no sound, sigh.
The problem was that in order to port Osmo to Emscripten, we dropped most of SIP/RTP support but this stuff is crucial for voice communication. Hopefully Oscmocom came up with an Osmux solution for satellite link communication with distant BTS/BSCs. After hacking the Osmux interface in the stack, we were able to get a "satellite" link over WebSockets. In this case, the satellite link combines four packets before sending which is enough to make WebSockets happy.
We invite you to explore cloud-based cellular networks and build your own solutions with uSDR. Stay tuned for more updates as we continue to push the boundaries of what’s possible in the realm of wireless communication.