[HN Gopher] Open source 5G core network base on 3GPP R15
       ___________________________________________________________________
        
       Open source 5G core network base on 3GPP R15
        
       Author : rguiscard
       Score  : 136 points
       Date   : 2022-02-26 12:39 UTC (10 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | exikyut wrote:
       | 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(tm) 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?
        
         | delabay wrote:
         | 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.
        
         | withinboredom wrote:
         | 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.
        
         | chrispeel wrote:
         | 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 :-)
        
       | The_rationalist wrote:
       | What is this for?
        
         | zdw wrote:
         | 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.
        
           | yaantc wrote:
           | 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.
        
           | unixhero wrote:
           | 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! :)
        
           | vardhanw wrote:
           | 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).
        
       | onebot wrote:
       | How does this compare to Magma?
        
         | zdw wrote:
         | 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.
        
       | makapuf wrote:
       | The majority of it is written in Go. Not a good or a bad thing
       | per se, just some info I looked up.
        
         | secondcoming wrote:
         | Seems an add choice of language. Wouldn't GC drop calls?
        
           | DaniloDias wrote:
        
           | TobTobXX wrote:
           | 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?
        
           | wyldfire wrote:
           | 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.
        
           | DarylZero wrote:
           | Go's GC supposedly never runs longer than 1ms, so no.
        
           | iSloth wrote:
           | 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.
        
             | withinboredom wrote:
             | .NET GC is pretty configurable though. I don't know about
             | the Go one.
        
           | Cthulhu_ wrote:
           | Why would it? It feels like you're making assumptions about a
           | lot of things.
        
       | natch wrote:
       | 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>
        
         | octocop wrote:
         | You can also do git submodule update --remote --init
         | --recursive if you've already cloned it.
        
           | CamperBob2 wrote:
           | 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.
        
       | zdw wrote:
       | 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).
        
         | ysnp wrote:
         | 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?
        
       | alexk307 wrote:
       | How is this possible? I was told that these wireless networks are
       | all closed and proprietary. Is this done by reverse engineering
       | the protocols?
        
         | stagger87 wrote:
         | The 3gpp specs that define these components are freely
         | available.
        
         | ksec wrote:
         | > 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.
        
         | pid-1 wrote:
         | 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.
        
           | knorker wrote:
           | 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.
        
         | Reventlov wrote:
         | 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/
        
       | tgflynn wrote:
       | 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).
        
         | Cthulhu_ wrote:
         | 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.
        
       | qualudeheart wrote:
       | Nice.
        
       ___________________________________________________________________
       (page generated 2022-02-26 23:00 UTC)