Yeah, thanks guys.
So I'm going to talk about SSRUN project, our deployable open run, open source run solution.
So it's going to be, talk about 4G and 5G, because I know that many of you still use
4G, although we usually focus these days on 5G.
I'll start with talking about our repositories and the naming, as this causes a bit of confusion.
And then I kind of split the talk, kind of 30%, 4G, and 70%, 80%, maybe 5G.
And primarily talking about our newest baby, so SSRUN project, which is an open run native
CUDU implementation written from scratch, and then obviously also demo that here.
So if you go to GitHub, SSRUN, these days you see two repositories.
One is called SSRUN 4G, and one is SSRUN project.
And I'm going to explain why we have those two projects here in a second.
But let me ask a question.
So who's interested in who's doing 4G in the audience?
You're most interested in 4G.
Great.
And who's interested in 5G?
OK, that's actually more.
Nice.
So a little bit of background in history.
So when we started with that, actually 10 years ago with libLTE, which was back then
a pure C implementation of the LTE physical layer, that obviously was all 4G.
And then the first application, the real application we had was the UE.
So a 4G UE, back then still in a separate repository that we figured out would be better
to actually join this when by 2017 we created the E-note B.
So SSRTE basically became the file layer, the UE, and the E-note B, and all in the same
repository.
And later on there was also an EPC added to that.
And then to explain a little bit that gap that we had between 2018 and 2021, so we added
a lot of new functions like carrier aggregation, ebMS, MIMO, and there's actually, Foster
talks about this and they go into detail what we did there.
But primarily what we did in this time was to harden the E-note B and the UE application
to make them deployable, to run them in real networks, and that's what we have today.
So they're deployed in the field, running in hundreds of base stations on a daily basis.
And then in 2021 we got very excited back then of course about 5G and we implemented
both for NSA and for SA based on the old, based on the existing SSRTE 4G architecture
and software architecture.
We implemented for NSA a UE and an E-note B or G-note B as well as for 5GSA.
But then, I mean that was all based on the 4G code base and we were kind of in trouble
because we still call it SSRTE.
So we kind of figured out, okay, what can we do there?
If we call it SSRTE NR, that's going to be a problem at some stage with 6G, so we figured
out okay, let's call it SSRTE RAN.
That made total sense back then, right?
So we had back then in the entire, in the same repo, we had 4G, UE, and E-note B as
well as 5GSA and 5G NSA, UE and E-note B.
But what happened then was actually ORAN came into play and everybody was getting excited
about ORAN as a buzzword.
What does it mean?
It's kind of initiation or initiative by operators to open up the interfaces between the radio
components.
And the idea here is to avoid the defector VendorLogin that we have today.
So when you build a network, you're buying all the components from a single vendor.
And the idea here is really to use off-the-shelf hardware for the CU and the DU, which is basically
your G-note B, your base station, and put Linux software on it and run it and use open interface
between those components as well as between the G-note B hardware and the radio, so the
IU side on the left side, the left-hand side.
And this is in fact something that 3GVP itself brought into the game because they are the
ones who define the CU and the DUs, but others have provided a radio interface, so a frontal
interface between the DU and the IU, which the ORAN lines took and basically defined
the open frontal interface or an open frontal interface to talk to an IU.
And that's basically what it all is.
And what we did back then was to, and having known and having implemented all of that 5G,
all those 5G applications already in the old codebase and knowing the limitations of that
codebase, we kind of set aside and said, okay, would it be cool to actually start a
scratch and get rid of all the legacy and rewrite everything?
And that's what we did.
So we sat down and rewrote everything and the Azure's Run project, so as we call it today,
is a completely new software architecture, so we had people really laying it out from
the being on with all the interfaces in there that the ORAN Alliance specifically specifies.
And with all the thinking that went into that for openness, for interoperability, for performance,
all towards really deployable open-force radio platform, RAN platform.
And that's what we did and that's what today is Azure's Run project.
And that was also back then when we figured out, okay, or realized, okay, that's now a
new project and that's now a new platform and we need to give it a proper name and distinguish
from the old codebase, which is still totally valid and totally functioning.
So we kind of renamed the old Azure's Run, which was not that old by then, only a year
or two, to become Azure's Run 4G.
And that is what it is today and that's what you find in the GitHub repository.
Still getting new releases and updates, but the new stuff is Azure's Run project.
So this new architecture, this new 5GSA codebase.
And then as we have seen, there's quite a bunch of people who are still interested in
4G that it's often a little bit misunderstood that this is kind of an old project and it's
not maintained, but that's not the case.
As I said, it's deployed and it's a maintained 4G codebase for the ENOB and the UE.
And it still contains a UE implementation like this proof of concept UE that we did back
then with limited 5G support, admittedly, with all the legacy and the limitation that
we had back then.
But it's still used by quite a few people in the research community after all and it's
good enough to attach to a GNOT B and you can work with that.
And the 5G GNOT B code that repository is not recommended to be worked on.
So for everyone who is using SA or is interested in SA, please use the new RAPO.
We're not fixing any bugs there in the old one.
And the last release was actually just the end of the year where we, because of those
users who want to use SSUE with 5GSA mode, that have been fixed for to support more bandwidths
like minor things, no real DSP changes or anything bigger, but this is something that
you can do.
And then use the UE in the old repository, so this testing UE, to connect to the GNOT
B and the new RAPO.
And it's working within the limitations perfectly fine.
And now let's come to the SSRUN project.
So this is in a nutshell the architecture and in everything we have here in green and
blue, especially within our scope.
If you're a little bit familiar with the Nome Clutcher, it's the DU and the CU.
So the CU is the control or central unit, sorry, doing most of the control and plane
stuff here in the upper left corner.
It's further split into a UP component.
And then you have the DU, which is the physical layer and layer 2.
Those two components again have a split in there.
So many splits that give you options, possibilities to cut them and implement one thing in hardware,
one thing or everything in software, however you want and whatever your application requires.
And then you have the so-called frontal interface, which you can see down there, where we support
also frontal 7.2, which is this new open frontal protocol, which you can use to talk
to commercial radio units, and also frontal split 8, which is IQ baseband, so user piece.
Like this is the default, so to speak.
And then four or five points about this.
So this is a complete solution.
So it's layer 1, layer 2, layer 3.
You get everything there.
It's not just like a subset of the RAM solution.
We don't implement anything like RIC or SMOs.
We don't implement a core.
But we are exposing all the centered interfaces so we can talk to third-party components that implement that.
It's very portable, so it's running on ARM.
It's running on x86, on Intel, and on AMD.
All performance, yeah, already coming to the third point, all performance critical things are written
in SIMD instructions for ARM, neon, and for x86, AVX2 and AVX512.
And it's also very scalable.
So you can actually run this like a full 5GSA with the physical layer on a Raspberry Pi
and attach a B200 to it and attach a phone to it and it will work.
But the same thing also runs on 128 core Ampera server or Epic server.
Obviously doing then MIMO and all the thousand whistles and higher bandwidth and throughput.
And very flexible.
As I said, every interface that you have there you can cut and then talk to a third-party component
or mix and match and maybe put some stuff on the physical layer implementation,
some running in the ARM cores and embedded system.
Everything is interoperable, so we have integrations with VATI units, with core networks, with RIX,
all the components that you need to build a full RAM, which are out of scope of us.
We do integrations and talk to others and try to work with them and it's all open.
So please feel free to look at the code and it's all very transparent,
which we believe is very important also for like TECO projects.
And I don't want to dwell too much on the mainline features here,
but I think the main takeaway is that everything is there that a normal user or operator even would actually need from that.
So all the bandwidth and all the modulation schemes and all of that.
The performance is like we are looking at carrier grade like numbers.
So many UEs, 24-7 operation, highest bandwidth.
I mean, this is what the spec defines.
So 1.5 Gb in the downlink, 200 Mb in the uplink.
This is a four-layer downlink, 100 MHz and one-layer uplink.
And it's all accelerated.
So we are not putting any, we support FAC hardware acceleration
with Intel ACC100 cards or other DbDK bound BBDF devices, but we don't need that.
So it all runs efficiently on ARM and Intel.
And then there are some features coming up in the next release.
So we're doing bi-yearly releases that's like a pattern that we have been following with like for many years already.
But we're doing constant pushes to main, but not releasing that code.
And the next one includes for instance, mobility, so between cells.
Then I know there's interest in NTN, so there will be initial support for release 17 NTN.
So to talk to geostationary satellites, multi-cell support,
and the split between the components that I showed.
It's also an important point.
And then I know that all this telco stuff is very overwhelming, especially if you start with that.
I completely understand this.
And that's something that we put a heavy emphasis on.
So to really increase the user experience and ask people to engage with us,
to simplify really the barrier and to lower the barrier, the entry barrier for telco in general,
and also ORAN, which has again its own complexities.
So we've put a lot of results in documentation.
So there's application notes, there's developer guidelines, there's code styles for contributions.
Lots of testing is going on.
That's also something.
So there's a MATLAB based repo where we do all the physical layer conformance testing against MATLAB.
Yes, you need a 5G tool for that to test.
But it's still very useful for people and for researchers who tend to have access to the university or where they work on engagement.
So everything is hosted on GitHub.
We ask you to engage here.
So discussions forum, we used to have a mailing list, but for the new repo, we're not using that anymore.
So better GitHub.
And then of course the code itself.
And then there's an overview of docs.essence-round.com.
You find everything there.
And if there's something not there, then reach out.
And it's also something we are collecting ideas to create new application notes and things like that.
And then the demo.
How am I going?
Not too bad.
So I would have loved to actually do like an ORAN demo to really show you, bring the components and everything.
Unfortunately, the reality is that it's very complex.
So you need big servers.
Usually you need extra hardware like switches.
You need timing.
Very important.
So you actually need PDP.
So precision time protocol, grandmasters, the GPS clocks, CERN.
And the IU is the one that you see there is like a big brick weighs five kilos and nothing you can just put in a trolley and bring over.
Definitely not the servers.
What we did is to kind of like, you know, miniaturize it a little bit.
But this is how small we got it.
This whole setup fits in a big suitcase like in those Peli cases.
But it's still like a desktop PC.
And this radio unit there on the left hand side, it still weighs five kilos.
Plus, you know, power supply, then the PDP grandmaster, you need GPS, which is difficult to get here.
And all of that, you know, it's still it's still complicated.
Nothing for a weekend and to put in the backpack.
But obviously we do a demo there.
And what I will show here is the exact same software.
Remember, we support both ORAN split 7.2 to talk to those guys, to those radio units, but also to a user P.
So that's why I have here my B200 mini.
And I have a Pluto running Maya.
And I have a Cots phone here.
So this is a Motorola phone.
And I'll use something that we also created to make it easier for people to get started.
So all the components that I'm showing here are running off a Docker Compost Script that it's also in the repo.
So in the Docker, you know, top level folder.
There is a Compost for the G-Node B.
That includes Open 5GS as a 5G core.
There's an Influx DB and a Krofana dashboard.
This is something we used to basically to show, visualize the performance of the radio.
And I'm trying to get us all running here.
And then let me just connect this guy here.
Yeah, one thing missing here.
So what I will run here is just a Docker Compost here.
Really in the main G-Node B or as I was running Docker folder specifying like a configuration that I just adopted here a little bit to find the frequency that's actually empty.
Because if we look at Maya here and we tune you a little bit, it was actually quite crowded here.
So all the radio folks are occupying the spectrum.
So this looks OK.
So I picked the AFKAN here that is empty.
So now it's running.
So this was just one command, just a Docker Compost up.
It's starting the core and starting the Influx, starting Krofana, starting G-Node B.
And that's running there.
So if you go back to Maya, we see the G-Node B broadcasting.
So this is the SSB and the SIB.
So all the information is broadcast by the G-Node B without a UE attached to it identify itself.
And what do you see here in the white band admission?
Those are CSIRS or reference signals for the UE to adjust it and to do tele-measurements and to report the quality back.
And what I do now is to run straight.
Do you see this?
So this is the Motorola.
I will make this a little bit smaller.
Because what we see now is, so if we, this is a Motorola phone that I have here.
So if I take this out of Airplay mode, what happens is it will scan for a cell, it will do a patch.
So send an initial signal and then all the attached procedure comes and what we, you know, what's going on there,
the communication with the cell and with the core.
And then it goes very quickly.
But that's something that we can do here.
And it's, you see there, and now it's actually attached.
So all the transition that we see here now on the outer band, this is the UE doing uplink signaling, uplink control signaling.
And now the level has adjusted a little bit.
So the dialing transmission, I guess, is the, is the blue, still like the blue level there and the higher power ones.
This is actually the UE.
And just to see that, so do you see the network name here?
That's FOSM24.
And what we can do now is to have a look at the profiler.
So that's running in the background as well.
So usually we do, it's obviously a console application.
We have console traces, but we created this nice Krofana dashboard there.
So it's all the data is pushed into influx to be, and it's just displaying the stats there.
What we can do is to, to now, yeah, use an application, signal guru.
So you can actually also look at, look at this here.
I will, because actually the Wi-Fi, the Wi-Fi is very bad here.
I would have backhauled over Wi-Fi, but it's not, it's not great.
So what I do is I just run an IPerf.
So, Mac.
So, can we still see that?
So now you see that this one user, obviously this is only a very narrow 20 mega cell CISO.
We're not, not getting 1.4 gigabit, but we get like 32 megabits here.
Maybe we can do a little bit more.
I still do that longer.
Maybe 50, I'm not sure if the channel is, is good enough to do that.
But yeah, it's going up.
And then the phone also showing that, like this is an application we use to,
to get, you know, information from the, from the baseband.
And what I do now is I disconnect that here.
I do this and maximize.
Close free mode.
So now I can actually walk around with the phone.
So it's still doing, it's still doing low.
So have a look at the, at the MCS level.
So this is very good here.
So if I walk around here, it should adopt the link and
the, the rate should kind of go down a little bit.
So the, like this dynamic MCS adaptation,
depending on the measurements that the phone does.
I mean, we can go out of the room as well.
And when I come back, like the, the MCS is, is going up again.
And doing full rate again.
And I think with that I'm.
I think we can still take a question.
Sure. Yeah. Sorry.
Yes. Yeah.
I mean, we have native support for, for UHD and in, in this
repo, but yes, you can actually use the SOPE UHD wrapper to,
to take the, the blade to run the plate over the UHD or the
UHD SOPE wrapper.
I always take, like mix it up.
But yeah, you can do that.
Also with the lime or with any other radio that supports SOPE.
Nothing, I mean, it needs to support obviously full duplex.
So it's, it's after all still like LT or NR bandwidth wise,
10 mega is enough.
But full duplex, it needs to be full duplex.
Even, I mean, TDD theory is not full duplex, but I mean,
the way we, we handle that and UHD handles, it's, it's,
it needs to be full duplex.
Yes.
But no other, other specs there.
Yeah.
Yes.
Yeah.
Yes.
And in fact, we are looking, looking at this.
So those are used here that we, that we used, that we, that I
showed here.
This one.
And so this is a, where is it now?
This is a, a so-called ORAN 7.2a IU.
So it's, it's basically doing, it's basically doing the
pre-coding in the, in the, in the, in the du.
So it's not doing the pre-coding.
So if you had a massive MIMO1, what you wanted to do is to
send all the layers to it and then compare it with the, with
the, with the pre-coding coefficients and let the IU do that.
And that's something that you can, that you can do with 7.2b.
So if you have an IU that supports that and does speak an
ORAN, ORAN open frontal, you can, you can do that.
Okay.
Thank you very much.
Thank you.