Open source 5G core network base on 3GPP R15 | Hacker News Reader

Open source 5G core network base on 3GPP R15

github.com

164 pointsrguiscard48 comments

The original 5GC codebase hasn't seen much activity recently - there are more active forks which are moving to newer 3GPP release levels - for example, the ONF's SD-Core project: https://docs.sd-core.opennetworking.org with code here: https://github.com/omec-project

Full disclosure: I work for ONF, opinions are my own (especially on HN).

Is there a way or a good place to see an overview of the open-source projects in this area if we want to support them?

My guess is that only a small fraction of HN users are going to be able to figure out what this is for without spending a significant amount of time doing a deep dive into 5G (I don't belong to that fraction, btw).

I've been working in this space for over two years and it's still Klatchian to me, lol. Our application is built in C, I just make the configuration interface for it... using Go.

Can you write about your experiences? I'm sure plenty of people like me are interested in this space but don't know where to begin. What was your background? How did you first start? What are the problems you solve?

How is this possible? I was told that these wireless networks are all closed and proprietary. Is this done by reverse engineering the protocols?

This is "just" the core network. The 5G core is IP based, like in 4G.

From what I remember, every 4G core funcion already could run virtualized in regular server farms. So you're limited by having access to software that implement 3gpp specs.

Most ISPs run their packet cores on proprietary systems (Huawei, Ericsson, ZTE). But I believe that has more to do with their scale than with the complexity of the 3gpp specs.

I think the real trouble is running radio frequency stuff.

3G too runs on IP, for everything but voice at least. Technically you probably can run some parts on non-IP, but it makes everything vastly more expensive so I've personally not seen it.

> Most ISPs run their packet cores on proprietary systems (Huawei, Ericsson, ZTE). But I believe that has more to do with their scale than with the complexity of the 3gpp specs.

The core network often runs on bullshit "router looking" machines, where it would actually be much better if it'd just be a normal rackmounted server.

I believe the vendors just want to impress. The deliver this fancy looking blade chassi, with "packet forwarding line cards". But turns out those line cards are just Linux boxes with normal Intel CPUs.

The line cards often don't even talk across any backplane (for user data). They have their own NICs.

Or worse, their implementation is line cards to an existing Cisco or Juniper router. Ugh. I mean sure if they were fast, but they're not.

You can charge so much more if it looks like a magic box, and not just a rackmounted Linux box in disguise.

And often the implementations are completely bananas, when looking at it from a network engineer's point of view. Like "ok, you speak OSPF over the backplane between line cards. Can they forward data over those links too? No? Then that's not how OSPF works. Stop that."

The reason ISPs buy them is that they interoperate, and can be integrated into their network. That's 100% a software problem. And they need a vendor who will come and fix whatever it is that they want. And the ISP will pay through the nose for it.

I've set up OpenGGSN on a real network in an hour, and said I can replace this multi year project with it running on a couple of rack mounted Linux boxes.

Yeah, but will I support it, and guarantee that I implement a metric tonne of 3GPP specs? Will I prove why I do, when a roaming partner complains? No. Well, that's where the millions are going, isn't it?

> I think the real trouble is running radio frequency stuff.

Core network is a huge business too, though.

The 3gpp specs that define these components are freely available.

Please note even the radio protocols have to be standardized and defined for multiple hardware vendors to make the chips and antennas and […].

If you want to look at something related, you can look at srsran / open air interface which are both developing software-defined solutions for 5G (including the radio/rf parts !) :

- https://www.srslte.com/

- https://openairinterface.org/

> wireless networks are all closed and proprietary.

From a software and modern open source sense, yes. From the literal sense, No. The standard ( Core ) is open, and freely available. Their implementation are not, and subject to royalty fees.

Was curious and pulled it down.

Why does git clone on this repo produce a local copy that is lacking content in any of the subdirectories of the NFs/ directory? Looks like a symbolic link issue?

More importantly, how does one fix the issue?

Or maybe what I am seeing is references to git submodules?

Edit: got it, yes, submodules. Instead of git clone <url>, the trick is to use:

    git clone --recursive <url>

You can also do git submodule update --remote --init --recursive if you've already cloned it.

I always just download a .zip. Never understood using the whole "git clone" thing when I just want to look at the repo without participating in development.

It gives you the commit history for one thing. And if you download for archiving you get the whole thing, all the branches etc. rather than just a current snapshot of the main branch. But sure if that’s all you want, zip is fine.

This project and subthread provide one reason a clone can be necessary: submodules. The zip doesn't include any submodules, and it doesn't include the metadata necessary to go and download the submodules either. This project cannot be built from the zip; the NFs folders are all empty.

Looking at this code, and more broadly speaking the cellular telephony ecosystem as a whole, the best way to articulate what I feel is to point at GNS3, the network simulator.

GNS3 is honestly insane. It lets me run virtualized instances of the software stacks hiding inside 6..8-figure (!!) network equipment and then route packets between stuff in exactly the same way I would get if I had the physical equipment.

But I personally find absolutely no substitute (as I get started/oriented) to being able to plonk a switch on a workbench and reason about it in a tactile manner.

I think the same argument might be made about flight simulation: to a point, a flight simulator has nothing on just getting in a plane and flying around.

In both cases, a) it's entirely reasonable to do without "the real thing" and still figure things out, and b) simulation is an such an exceedingly useful drilling and training aid that the industry as a whole would be missing something measurable without it.

But it still remains that establishing a correctly calibrated fundamental sense of how everything works and how stuff gets done can be harder when using a simulator. Things might not intuitively click right away. Mental models might be a bit (or a lot) more fragmented. Complex concepts might require more juggling and mental effort to integrate and understand.

So you can kind of see my frustration: I'm extremely interested in wireless communications in general (just broadly speaking) so being able to stare at all this code is awesome... with the caveat emptor that I can't legally do anything with it in the real world. The revolution of software-defined radio might mean the physical baseband aspect of 3G/4G/5G is more accessible than ever - a couple thousand now (if that, I think) instead of 5+ figures - but the relevant spectra are still licensed and locked down tight pretty much worldwide, and that's not likely to change anytime in the long term.

Unlike the "I'll probably never see one of these in person" kit that I'm content to look at pictures of and tinker with in GNS3 :) wireless networking/communications does (at least to me) largely lend itself to being a very tactile subject that you just want to play with in the real world.

LoRaWAN is very low bitrate and (to a cursory/long distance understanding) has a bit of friction around patents/licensing (although if I can buy premade modules that Just Work™ I'm happy)

Long-range Wi-Fi is... not really an explicitly supported configuration because it gets right up at the edge of legal transmit power limits.

Wi-MAX... I honestly don't get. I can't tell where it sits on the relevance spectrum. I remember reading about it years ago but it's like it disappeared at some point.

Ham radio cannot be encrypted and thus represents a step down in terms of present status quo expectations on the public Internet.

I'm incidentally curious how DJI's drones can get 10km line of sight. I wonder what transmit power and band(s) they're using to manage that (ISM 2.4GHz/5.8GHz?). Presumably the video transmission architecture is an eye-glaze-inducing highly specialized proprietary mess that's reasonably micro-optimized to the hilt (?).

With the above in mind, is there anything up-and-coming, obscure or whatnot that I (very probably) don't know about in the space?

And flipping the entire problem domain around, how can I get interested in the open source work being done in the cellular space? What interesting things can I do without any sort of base station equipment? And to what extent can I play around with cellular-band RF if I were to go shopping?

IIRC from my drone days, the antennas were spiral (not linear) for FPOV flight on the 2.4Ghz or 5Ghz spectrum. This a) basically prevented interference from WiFi and b) gave good clean LOS signals for miles. There was still interference, but it wasn’t bad. In Afghanistan (where there were basically no competing WiFi signals) I could get consumer WiFi to go about 2km LOS on the 2.4Ghz bands.

Very interesting. IIUC, the spiral antennas were... polarizing the signal, such that the Wi-Fi antennas couldn't "see" it, I think?

I'm curious how big the antennas (and effective output power) was in Afghanistan. That's pretty cool. I can't figure out what regulatory domain they're in, I wonder if they have one lol...

In Afghanistan, I used an old fashioned DDWRT router with the transmission power turned up to 125milliwatts IIRC? No special antennas like a high gain one. The distance was a backhaul link between routers so we could have civilian internet at the office. There was no regulatory domain other than not interfering with the signals guys or messing up radar returns.

My FPOV drone was in the 5Ghz band and I could go for about 1.5 miles before a tree limb would cause significant interference.

If you're in the US you can play with professional grade wireless telecom hardware using CBRS spectrum. I have a magma core and radio on my house to play around with. Some teams are doing very interesting work in combining crypto incentives to build private and public networks which modern phones can roam onto with esims.

Huh, TIL about this. I did a bit of digging around and the 3.6GHz band appears to have been licensed in Australia in 2018 (https://www.acma.gov.au/auction-summary-36-ghz-band-2018) after some consideration of what the US was doing (https://www.acma.gov.au/sites/default/files/2020-02/3_6%20GH..., ~p40) and then apparently developing amnesia (https://docs.google.com/viewer?url=https://www.acma.gov.au/s...) (yay).

I did a bit of poking around trying to figure out what the magma radio you speak of would look like but came up completely blank. I'm very curious how this works?

I'm also interested to understand (albeit from a literal distance) more about the teams you mention, particularly how phones (you specify "modern" - does that mean 5G? 4G? 4G-with-these-specific-extras?) can roam onto CBRS-spectra networks with eSIMs - I just learned about these and wouldn't mind building a good orientational mental model about them.

*Penny drop* OH so that's why the ACMA auction mentioned the 3.6GHz spectra was relevant to 5G... you say modern phones can roam onto CBRS??? How-- oooooh, that's really interesting, I finally get what you mean about throwing crypto into the mix to incentivise (presumably the radios aren't too cheap yet).

I don't think I can play with this in Australia (but am unsure how to read the situation, for all I know I'm barking up the wrong tree with the above links) but this is very cool to know about.

Look up pollen mobile and helium 5G. both have an interesting approach to creating a totally new private wireless network, OR, creating a neutral host network for roaming agreements.

imagine getting paid to own and operate your own little cellphone tower. the day is near.

Are you working on one? I saw pollen mobile, San Francisco based at the moment and data only. Interesting stuff

I have all the associated equipment for every US-based CBRS project.

It all functions. My phone roams onto it, the eSIM / physical SIM works. The blockchain and various business agreements need to catch up for the dream to be realized.

imagine getting paid to own and operate your own small cellphone tower. the day is near.

It sounds to me like you want an inexpensive basestation and a fully-open source software stack (at all layers) to run on it. And you want to set it up to run in a open band like 3.5 GHz. I like this vision!

BTW, WiMax is obsolete :-)

I don't actually have a cohesive/concrete idea per se, but I don't find myself disagreeing with any of that description :D

TIL 3.5GHz is open. Where can I read more about it? It isn't in https://en.wikipedia.org/wiki/ISM_radio_band. Is it open worldwide? I'm in Australia (and generally interested in noodling over solutions that are region-agnostic). Edit: Ah TIL about CBRS from another comment (which I replied to, https://news.ycombinator.com/item?id=30490470).

And thanks for the headsup about WiMAX, I was wondering what happened to it. The Wikipedia article on it made relatedness noises pointing at LTE, I get the impression it kinda ended up getting used for parts. (It's curious why stuff that seems to attract reasonable investment just doesn't take off, I wouldn't mind learning more, but yeah, idle curiosity.)

Yeah, when I said 3.5 GHz, I meant CBRS [1], which is a US thing. I do think that other countries will have similarly-open bands, even if they don't match exactly. I.e. bands that you don't need to pay a license to use.

[1] https://en.wikipedia.org/wiki/Citizens_Broadband_Radio_Servi...

What about the Ubiquiti stuff that can go 100km. I love playing with the link.ui.com tool

Oooh, TIL about https://link.ui.com and https://ispdesign.ui.com!

The geographic (landmass height) processing stuff they're doing there is honestly incredible (and hilarious, it just *let* me raise antennas 3km up in the air on top of residential buildings to establish LOS hahaha). And the signal propagation spectrum stuff is cool too.

I wasn't fully aware their kit (and high-frequency digital radio in general) could go to 100km. That's awesome, and puts DJI's stuff into much better perspective too.

How does this compare to Magma?

Magma is a "throw out a large portion of how 3GPP does things" approach.

As a primer, the 3GPP (which is primarily equipment vendors and large telcos - think ITU and standards like ATM) defines a bunch of different "splits" of functionality either in code or implementation, some of which are required, some optional, as in any "made by committee" standard where everyones pet use case is in some corner of the standard. An example document about this from a vendor about splits:

https://hub.radisys.com/5g-and-iot/exploring-functional-spli...

Magma (which is Facebook and more computer networking folks) basically says "Hey, what if we don't do that, and just make our own stack that works, but ignores all the 3gpp standards". The upside is that it does exactly what Facebook wants - wireless using 3GPP technologies without all the baggage. The downside is that some of that baggage is very useful for interoperability, and the splits exist for a reason.

The majority of it is written in Go. Not a good or a bad thing per se, just some info I looked up.

Seems an add choice of language. Wouldn't GC drop calls?

Why would GC drop calls? I know a few high volume networks using .Net based platforms without any issues, Go would run circles around them performance wise.

.NET's GC is faster than Go's GC. They had a big head start.

.NET GC is pretty configurable though. I don’t know about the Go one.

Yes, both unbound heap allocation times and GC pauses could stall and cause critical timing failures. But you could theoretically use these features in a system designed for low latencies.

Go is known to be quite usable a server programming language (Caddy is a well-known HTTP server written in Go), so I think the language choice is quite fit. You wouldn't say a HTTP server drops requests because it has GC / uses Go, so why would it drop calls?

Why would it? It feels like you're making assumptions about a lot of things.

Last I remember, mobile signalling had quite strict timing requirements.

Go's GC supposedly never runs longer than 1ms, so no.

What is this for?

In a mobile network, there are a lot of parts. This is a "core" implementation handles the "control plane" - authentication of client devices, user accounting, etc.

There's also a "RAN" which manages the radio portions, and a "user plane" that manages the data flows and protocol conversion between devices and other upstream networks.

These all talk to each other and work together to make a 3GPP wireless network.

Technically the core consists of both UP (User plane) and CP (Control plane). In 4G this was MME (Mobility management entity) for CP and the S-GW and P-GW (Serving and packet gateway - which interfaces to the internet) for UP. In 5G this has been replaced with VNFs such as AMF and others for the CP and UPF (User plane function) for UP. The 5G core is truly distributed and designed from the base to have re-usable and third party VNFs with well defined (REST based) APIs so it is really a game changer.

The RAN (Radio access network) and core split is there since 2G, where the RAN in LTE is the ENB (E node B) and in 5G is the GNB (G node B).

Both core and RAN have user and control planes: the control plane is for configuration and management, and the user plane for carrying user data. This user data must go through the radio access network (RAN) and the core too.

The split between core and RAN allows a single core network to manage several different access technologies. The main RAN technologies will be the 3GPP ones (LTE, NR). But it is possible to hook WiFi networks to a cellular core (there are public 3GPP specs for this), or even fixed access. The core part provides the IP access services whatever the RAN type.

I worked for a telco advisory for 3 years. You just described in more detail than anyone of us or the telcos themselves could enunciate. Thanks! :)

Nice.

Reply on news.ycombinator.com