LaForge: Running your own 3G/3.5G network

32C3 preroll music

Herald: For several years now, here
at the Congress and at the Camp,

we see that we have a GSM network,
that we operate our own network,

that we have some services
like recently GPRS or

roaming between the different
parts of the areas in the Camp.

All of this started around 7 years
from now, with a talk at the 25C3;

and a bunch of projects emerged
from that over the years.

But wait, there is more. Right now,
the people running these services

and running these projects are
starting to play around with 3G.

And for everybody who doesn’t know what
3G is, like I did, for like 5 minutes ago,

3G means that we will have HDSPA and
data services on our GSM networks.

And I’m very honoured to introduce
to you this evening Harald Welte,

a member of our Chaos family for
several years now, known maybe from

the Kernel development. I first read his
name while debugging a chip card driver

that stated ‘All bugs introduced
by…’ – this guy over there.

So, other people may know
him from gpl-violations.org,

where they try to enforce
the GPL. So. Please welcome

Harald Welte, and… the stage is yours!

applause

LaForge: Hi. Welcome everyone
to this talk about, well,

running your own GSM network, or
running your own 3G network, rather,

sorry for that. And in more
technical terms, the slide titles

with lots of acronyms as it is
customary in the telecom world.

So forgive me if there’s too many
acronyms, but I didn’t invent them,

I just try to use them whenever
appropriate. Okay. So, let’s start

with a little bit of a history of open
source in mobile communication protocols.

You have to remember
that we started about

16 years after the proprietary
implementations, so the GSM network

that we are running
here at the event, or that

we started to run 7 years ago, started
16 years after GSM networks were run first

in the public in Europe, so, at public
operators. So we’re really, really late,

and if you want to compare the status
of open source mobile communications

with open source operating system, then
I would say we are about where Linux was

in ’94 or ’95. So, very far from today,
for those of you who are old enough

to remember these days. So, I would
say “capable but not taken seriously”

is sort of the general status.
The developer community

working on these projects is still very
small. There’s a limited adoption

in the market and the users,
often in niche applications,

but nevertheless it is functional. So,
if we look a little bit at the timeline,

2008 we had the talk about
“Running your own GSM network”

with a huge Siemens base
station weighing I think 28 kg…

Did my microphone…? No, it works, sorry.

…weighing 28 kg and bulky old equipment

not using TCP/IP but using E1 lines etc.

Over the years we added more and more
BTS model vendors. Basically it means

we can use Ericsson and Nokia
and other equipment to actually

run these GSM networks today. People
have been working on GPRS support

in a couple of sub projects
called OsmoSGSN, OpenGGSN,

also the OsmoPCU project, so we’ve
been growing the stack downwards,

also basically implementing
the software inside such a BTS,

which we call OsmoBTS. There
are some production deployments

– all spellings my mistake,
by the way, as obviously – so,

production deployments in niche
applications such as maritime markets.

So, if today you are on a ferry or on a
cruise ship and you use GSM services, the

probability that you’re using OpenBSC and
associated projects in the background is

very strong. There are hundreds of vessels
using our software today. Now, then we…

applause

…then we moved on the telephone
side, so we thought, well, you know,

network side GSM in one thing, but let’s
do the phone as well, that was OsmocomBB,

started in 2010. We did improvements
over the years, more and more

completed the stack, but it’s really
all only old GSM/GPRS technology

until very recently.
So in 2015, 15 years again

after the first commercial deployment
of GPRS in a public network,

we start to have an open source
implementation of EDGE, and that has just

started like 2 or 3 months ago. So
again, 15..16 years late compared to

what happens in the
proprietary world. Ok. But…

this talk is not about EDGE, which
is 2.75G, if you want to speak

in generation numbers. Today
we’re talking about 3G and 3.5G.

And there’s a bit of ambivalence
with that subject because, well,

today, if you talk to people in the
industry, they will say: “Ah, who cares

about 3G, you know, it’s dead anyway!”.
We have already today at the point

where we have ‘Peak 3G’,
so in the next few years,

the number of subscribers and the
number of networks offering 3G services

is no longer growing, it’s
basically stagnating and

will turn downwards in the near
future. So LTE/4G networks

is basically what everyone is hot about.
The other reason not to look at 3G

is that it’s mind-bogglingly complex.
It’s not a single telephony system,

it’s actually a toolbox to build
arbitrary telephony systems.

And if you really wanted to start
implementing it from scratch

including all the lower layers, including
the PHY, including the Layer 2 etc.

I think it would be a waste of a lot of
time, actually. So we do what we did

with the GSM networks back then, we
used proprietary base station hardware,

and we implement the higher level
protocols, and then, if needed and

if there’s interest and contributions
etc. we drive open source further

down the stack and also
into the actual cells.

So, one term that’s going to be used here

in this context is ‘femtocells’. Quite some
number of people may have heard

about femtocells before. In technical
terms it’s a base station – which is

called NodeB in the UMTS language
world – and a radio network controller,

which is the BSC, the base station
controller – in UMTS in one box.

And using such femtocells or similar
hardware is much easier to interface

than if you would use a regular
base station. So that basically is

sort of a path that we think is doable
without spending man-years of implementing

obscure and complex transport channels
and bundles and mappings and whatnot.

There’s been a couple of talks about
doing creative stuff with femtocells.

There’ve been talks by Kevin [Redon], Nico
[Golde] and Ravishankar in 2010/2011

about security. There’s been a recent
presentation this year at Black Hat

in the United States called
‘Adventures in Femtoland’.

Those talks focus on basically, well,
the security of the femtocell itself,

breaking into such a cell, rooting it,
owning it, doing creative things

and then from there e.g.
attacking the mobile operator or

attacking the privacy of subscribers
by using such a femtocell

as a man-in-the-middle platform e.g. But
to my knowledge nobody has been talking

about free software or open source
software, to run a network with

such femtocells or similar equipment.
So, if we look at the UMTS architecture,

like you find it in a textbook or like
in this particular slide or drawing

from Kevin, you will find
several network elements

all over the network,
so lots of different elements

with lots of different acronyms.
We have a Mobile Equipment (ME)

which is the telephone. We have a radio
interface called the Uu interface.

We have actual base stations
called NodeB and we have

a base station controller that’s called
the Radio Network Controller, the RNC;

and then here we have, on this boundary
we have IuCS and IuPS interfaces

that interface the Base
Station Controllers

with the core of the network which
is the Mobile Switching Center,

the Media Gateway, the Serving GPRS
Support Node, and then other elements

here. And this is actually the interface
line which we have been implementing

in recent months at the boundary
between the Access Network,

the Radio Access Network and the Core
Network on the other side of the slide.

So, well, you could just get a NodeB
and implement the protocol Iub.

This is what we did with GSM before,
we basically started here. We only got

the actual BTS or NodeB and
we implemented that protocol.

However, well, this protocol
in UMTS is extremely complex

and fairly low down the stack.
Just to give you an idea:

every single voice codec frame
from a voice call that you receive

has 3 different classes of bits, and
each class of bits gets put into

different UDP messages, and then you
get basically 3 flows of UDP messages,

and you need to synchronize and
inter-mangle (?) and re-interleave

those bits in order to get to a speech
codec frame. So it’s… and I’m not even

talking about the signalling plane (?).
So the lower you get in UMTS the more

complex it gets, let’s try to avoid that.
And that’s the kind of complexity

that I like to avoid. This is from the
official spec about the UMTS spectrum.

It’s an extremely obvious and
self-explanatory slide, so I’ll…

laughter
I leave it at this and say, yeah,

that’s not what we want to do.
So, we… how can I say, we…

Even though we don’t like it we just use
proprietary blobs to implement that. Now,

the protocol stacking on those interfaces
that we actually want to implement

is what I’m going to look at the next
couple of slides. The Iu interface,

and by the name, Iu has no specific
meaning, it’s just the Iu interface,

you could say the A, the B, the C,
the Z interface – it’s the ‘Iu interface’.

It’s split in CS and PS, that’s circuit-
switched and packet-switched.

Circuit-switched means telephony services
and packet-switched means data services.

And we’re going to look at the
protocol stacking of those interfaces

in the next couple of slides. Originally,
remember, well, maybe a good time

to go back in history, in sort of history
of mobile communications, which

should be taught at every school, I think,
including archeology of protocols,

which… no, honestly…
laughter and applause

You need to do protocol archeology if you
want to implement certain interfaces

today. So, on my blog you can find
some posts about a couple of years ago

where I had to basically write a parser
for Microsoft Word for DOS text files

to automatically extract snippets of
ASN.1 syntax for MAP version 1

which is still used today. So, it’s… yes,
it… sometimes you really need to do

archeology. So anyway, not for this,
but any… when UMTS was specified,

this is the late 90s, this is when the
first dotcom bubble basically got big,

this is when billions and
billions of Euros or Dollars

or whatever unit of currency was
poured into the development of the

‘universal telephony mobile
system’, the… sorry, the

‘universal mobile telephony system’,
the UMTS, which should basically

be the grand unifying theory
of mobile communications.

And it was built on top of ATM, of course,
because ATM was the most shiny and

brightest technology in the late 90s that
all the universities were researching.

So, if you look at the classical protocol
stacking and you look at the individual

interfaces; the Uu is the radio interface,
Iub is between the NodeB and RNC,

but this is… the IuPS is actually what
we want to implement. So basically

the left side of this slide is
what is implemented

in the proprietary base stations
or femtocells that we are using,

and the right-hand side of that
slide is what we are implementing.

So we need to implement the protocol
stackings here. As you can see

the protocol stack is deep
and has many acronyms.

So, to make things more complicated

the femtocells that you can find
on the market are slightly different

from the real, normal 3G architecture,

so if you try to compare
this slide with that slide,

you will find some differences here.
The difference is that they introduce

a security gateway which is basically
just ITU and 3GPP language

for ‘IPsec gateway’,

and you have a HomeNodeB gateway
that doesn’t really do anything useful,

rather than putting messages from
one protocol stack on the left

to another protocol stack on the right
with the underlying protocols

doing exactly the same thing
but being differently encoded.

And this is what you can see here,
basically, the HomeNodeB gateway

which is part of the software that we
implemented. You can see basically,

well, you have RANAP,
this is the protocol

that really is sort of what
we’re interested in,

the Radio Access Network
Application Part; and RANAP,

in order to implement that, there’s
several other protocols underneath.

And on the femtocell which is called
HNodeB, the HomeNodeB, because,

well, ‘femtocells’ is a marketing term
and specs can never use marketing terms,

so they have technical
terms. So, the femtocell

basically encapsulates RANAP
into RUA, the ‘RANAP User…’,

what was it? Sorry, …Adaptation,
yes. The ‘RANAP User Adaptation’.

So the ‘Radio Access Network
Application Part User Adaptation’,

on top of the SCTP, the Streaming
Control Transfer Protocol,

which some may know is a protocol
that’s on the same layer as TCP or UDP

but has different properties. And

this RUA is implemented than (?) the
HomeNodeB Gateway where it is replaced

by M3UA and SCCP. And basically
the same RANAP message

gets passed from left to right. So
it’s really… you could think like…

think of it like an IPv6 to IPv4 proxy.

If that’s more an area that you’re
more familiar with. Okay.

So, I said there are some differences
between an actual, regular,

old-fashioned UMTS base station,
like your public operator would use it

and the HomeNodeB, or femtocell,
that we like to use in this project,

at least initially. And I said the
main difference is that the RNC,

the Radio Network Controller, is built-in,
so a lot of the lower layer protocols

are terminated, and we don’t need
to worry about that. If we look

at the protocol stacking again there
is a lot of protocol layers here,

you can see the MAC layer, the RLC layer,
the RRC layer… and all the PHYsical stuff

underneath is all basically already
implemented because it’s part of the

femtocell, in this case. So the protocol
stacking now looks a little bit like this.

We have the HomeNodeB,
and the HomeNodeB gateway,

and then our core network elements
already. So the SGSN and the GGSN,

if you’ve looked at GSM in the past, or
GPRS, even the software that exists today

and for many years in the Osmocom
project, we have implementations of those.

What we are missing is
the HomeNodeB gateway,

and is all the fancy new protocols
here. And some modifications.

So, well, what do we need to
do to actually implement?

This Iuh protocol. As I said there’s the
different protocol layers – there is RUA,

there is the RANAP protocol,
and the HNBAP protocol.

Let’s look at those protocols, what they
do, and how can we implement them.

I’m skipping a few slides in the
middle because it’s illustrative

if somebody wants to check the slides
later but it would go into too much detail

at this point. So the RANAP
User Adaptation layer

– given the spec number above there,
so if you look for that online

you can find the actual spec – is a very
simple connection-oriented layer

that provides you the
notion of a connection

over a datagram transport
layer underneath.

It has very, very few operations
and message types,

including CONNECT which – well,
surprisingly – sets up a new connection.

DIRECT TRANSFER which transfers
data inside a connection.

DISCONNECT – to terminate a connection.
And CONNECTIONLESS TRANSFER

to transfer data outside of a connection.
And, of course, an ERROR INDICATION,

in case something goes wrong. So we can
have multiple connections in parallel

over a signalling link. And they are
distinguished by a 24 bit context ID,

to differentiate those multiple
parallel connections. Think of it like

a port number. In the case of UDP,
or whatever else you might want

to compare it to. So, this… if you look
at this and you read the specs like

“Oh, pfff, you know, it’s nothing, it’s
like you implement like 5..6 message types

and that’s it”… well, there’s
a bit more details to that,

but we’ll get back later to this.
The HomeNodeB Application…

no, HomeNodeB Application
Part, the HNBAP protocol

has a couple of more transactions
which basically serve

for the registration of
the cell to the network,

the registration of user equipment,
UE, that’s your mobile phone,

and some additional messages.

So HNB is the HomeNodeB registration;
we have Registration REQUEST, ACCEPT,

REJECT, De-registration, we have
the same for mobile phones.

We have some more detailed
transactions that I’m going to skip.

But also it’s really very simple,
conceptially, it’s not very complex,

you don’t have like massive state
machines or anything like that.

Very few, very limited messages.

Then we look at RANAP. That’s the Radio
Access Network Application Part.

This is where your actual signalling
messages from the phone

are tunneled through. So if your
phone registers to the network

you may have heard the term LOCATION
UPDATE where the phone basically

registers to the network or updates
its location with the network.

That’s the first message you would
see, encapsulated inside RANAP, and

transported to the core network element.
Also things like PDP context activation,

if you activate a data connection to
a certain APN over cellular protocols,

all this is encapsulated
in the RANAP layer.

Also the number of messages that we
actually need is extremely limited.

Again, it’s a very short list, it’s
not like hundreds of messages.

But the messages themselves can be
quite complex. With nesting levels

up to 12..14 layers deep.
But we’ll see that later on.

So we have a couple of transactions.
RESET – well, I don’t need to explain –

it’s a Reset. INITIAL UE MESSAGE
means a new phone has connected,

and it has sent us the first message
that this phone has transmitted,

that’s why it’s ‘initial’ message. DIRECT
TRANSFER is all the follow-up transfer.

IU RELEASE means we’re releasing
a connection. Some commands

to configure the security, the ciphering,
the encryption. A PAGING command

by which the network can initiate
a transaction to the phone.

And RAB ASSIGNMENT. RAB
is the Radio Access Bearer

which is basically an abstract notion

of a bearer able to
transport communication.

If you come from classic
telephony the bearer was

an analog voice channel.
If you go to ISDN the bearer is

a 64kbps synchronous channel

where you have Alaw Ulaw (?)
inside, and voice data.

Or you have some HTLC (?) or X75
or whatever data inside.

In GSM the bearer is
typically voice bearers,

with different voice codecs.
The same it is in UMTS.

And basically you can configure
those bearers in UMTS because

that’s a very universal and
flexible part of the system.

Now, one of the protocols we have
seen in the stack – I’m just going back

a couple of slides to reiterate – that
is the SCCP which is introduced here.

The ‘Signalling Connection Control Part’,

if I remember correctly. It’s a protocol
that’s used a lot in core networks

of mobile operators. So if you
look at Roaming interfaces,

at classic SS7 interfaces – think of the
SS7 security talks etc. we’ve had here

at CCC events a lot of times – this is
a protocol that’s very often used

in a lot of different parts of
telecom. But the problem is –

everywhere except [at] this
particular point in UMTS and GSM

it is used only in connection-less
mode; and this is the only point

where it uses connection-oriented
SCCP. And therefor none of the existing

free software implementations is
implemented. You can look to Yate,

you can look to the libosmo-sccp,
the library that we have in

the Osmocom project. You can
look at the Mobicents Java stack

for these protocols. You can look
at the osmo_sccp Erlang code.

Basically no implementation
exists, so we also had to

implement that part,
at least to the point,

to those features that are required.
But once we have implemented

all these protocols – RUA, SCCP,

the RANAP, the HNBAP, then

we need to somehow interface
those protocols with the existing

network elements that we have for GSM. And

there are sort of several
challenges in this area,

in what people know
as the OpenBSC project.

Actually the program that most
people use is called OsmoNITB

– the network in the box – which is called
‘network in the box’ because it implements

all the network elements that you
need in one box, or in one program.

Unfortunately we need to separate
those individual pieces which are

all in one blob, in order to interface
at the point where we want to interface.

So this separation of the MSC part
and the BSC part needs to be done

inside the ‘network in the box’.
We need the UMTS authentication

and key agreement support,

and we need the different
protocols that I just mentioned

and link them in on the SGSN side.

For the data services we need
to introduce some extraction

to basically differentiate the packet data
connections coming from GPRS networks

and those coming from the new
3G networks or base stations

that we are supporting.
But that’s all manageable.

Now, the question is,

do we really want to go for the
full stack as it has been described,

or can we take some shortcuts, do we
really need to implement the full SCCP,

for example? Do we need to implement M3UA,

which is another protocol layer in there?
Can we basically simplify that?

The initial idea was
– if we go back to that slide –

to reduce the complexity, I already
mentioned this HomeNodeB gateway

which basically passes RANAP
from left to right, and just changes

the underlying encapsulation. Why don’t we
just continue using RUA up into the SGSN

and thereby avoid having
to do SCCP and M3UA,

avoid having to implement more protocols
without having any functional gain.

I mean it would just work the same way
if we take RUA and we take it all the way

into the SGSN. So there’s been
some thinking along those lines

but the idea was to…

…go sort of in a compromise so what
we’re using here is yet another protocol

called SUA, the SCCP User Adaption.

And that replaces those 2 layers
and keeps things a little bit simpler

from the implementation side. OK, now we
have all these different protocol layers,

and the integration into the core
network elements. Now the fun starts.

We have a plan, we know
what needs to be done,

we know what needs to be done,
and now we actually need to do it.

So the theory was easy – read a couple
of specs, find out 6..7 messages,

not too many transactions, no
complex state machines. Okay, now,

a lot of the more modern telecom
protocols use ASN.1 syntax.

It’s an abstract syntax notation
for defining data structures

or procedures to be communicated, and
then you can use code generation tools

to generate code in your favorite
language from this syntax

doing all the marshalling and
demarshalling of the messages.

That’s at least what’s the idea. This is
very different from what we used to do

in the GSM world because GSM
was specified in the late 1980s.

ASN.1 didn’t exist to my knowledge back
then, or at least they didn’t know about it,

and/or they thought it was not something
that you could do in a mobile phone

at that time. Think about 8 bit
microcontrollers and whatnot,

what they were using these days.
So the GSM messages,

basically you have…, you look at the spec
and you see “Oh, there’s one byte this,

then there’s a 2 byte length field, and
then there’s that”. And you need

to implement that basically in your code,
based on the textual representation.

Now, for UMTS almost all the
protocols and particularly these

that we’re looking [at] here are specified
in abstract syntax notation which, well,

on the one hand side you would say: “Oh
yes, great, now we don’t need to write

all this message encoding and decoding
code, and then we end up interpreting

the spec different[ly] and we have sort of
incompatible messages and whatnot”.

That’s true to some extent, okay. Now
what you need to know about ASN.1 is,

there are different encoding rules that
define how the abstract syntax notation

gets converted into a concrete
binary representation. There is a

Basic Encoding Rules (BER),
there is all kinds of encoding rules,

there is even JSON encoding rules these
days. There’s also XML encoding rules.

But what’s used here in these specs is
called ‘aligned Packed Encoding Rules’

(APER). This is a particular encoding rule
that was not… or is not supported

by any of the ASN.1 compilers that exist
in open source that generate C code.

So we first had to teach the ASN.1
compiler this encoding rule.

And the second big problem is the ASN.1
syntax used in those protocol specs

uses a construct called ‘Information
Object Classes’, which is sort of…

well, you know, an interesting way
how to express or how to have…

a different notation on how to construct
those messages and how to construct

operations that have like an initiating
request, a ‘successful’ response,

a ‘successful error’ outcome or something
like that. And you can express that

in a really nice way but then you need
a compiler and a code generator

that can parse that, and that’s really
difficult in the free software world

within some constraints. I’ll get into
the details. Now the next thing is

that the way how they use ASN.1
in these protocol specs

– ASN.1 being the abstract syntax
notation – is not abstract enough.

They need to have another
abstraction layer. So they use ASN.1

to describe containers, containers
for information elements,

containers for messages, containers
for lists of information elements

and containers for pairs of information
elements. It’s very important.

You cannot just have a list of 2.
No, you need to have a pair

that says, well, this is a pair of
2 information elements. Not sure why,

but somebody probably had
his reasons for doing so.

Now the point is, basically,
you use the ASN.1 syntax

and you generate some code for
encoding or decoding and then

you’re not really done at that point.
Because then you basically:

“Oh, this is a list of containers”, and
then you look into each of the containers

and then call the decoder again for each
of the elements in the list. And then

in there there might be another level
of containers and you unpack it again,

so it’s a little bit like matryoshka
or, you know, these dolls

nested in each other; or somebody
sends you a large packet etc. Well,

to illustrate that, if you’ve ever seen
ASN.1, this is a relatively simple example

describing authentication couples
or triplets or quintuplets.

Basically, the authentication data that’s
used for authenticating subscribers

in networks. This is what is used
also in GSM. It’s relatively simple,

so it basically tells you, well, there’s
an authentication set list which contains

[consists] of a choice of either a triplet
or a quintuplet list. Each of those lists

either have a length from 1..5, and then
you have basically a sequence which is

sort of struct or a record of the below
items in those lists. That is how [it] is

and should look like and how it
normally looks like. Now in RANAP

and these protocols they first – as said –
they define these containers, they say:

“We have…”. So it reminds me a bit
of some mathematicians. It’s like

“We define we have this, and then we have
that, and therefore we can construct

such a new structure” and whatnot. So
basically, they define first a container

for protocol information elements,
protocol IEs. And in the protocol IE

is the actual information element. Each
element has an ID, it has a criticality.

The criticality tells you whether,
if you do not understand

such an information element, should
you ignore it, should you reject it,

should you ignore it but report to the
sender that you did not understand it

despite proceeding with your operation,
and then the actual value.

And the value is an ANY type which
means there is another ASN.1 syntax

in that value that you then need to parse.

So you need to do these
2 steps in the code. You first

unwrap the containers and then you
decode what is inside the containers.

So working with ASN.1 really is not
as simple and as straightforward

and as automatic as it should be. And you
end up with messages looking like this

in Wireshark. So believe it or not,
the content, the useful content

of this entire message
is 4 bytes here, the c0…

laughter and applause

…is the 4 bytes starting from c0, and
those people who have seen an IP address,

an IPv4 address in a 192.168. address
range will recognize those bytes here

at the end. So the c0 is 192. etc.
And in order to communicate

this message actually, this is a message
that tells us to which IP address

something has been bound to. In this case
it’s the GTP connection for communicating

packet data. And you see all these
abstractions and encapsulations

and the nested tree, so it’s…
it starts with… well, ok,

this is an outcome. It is an outcome to
the Radio Access Bearer Assignment.

“If you do not understand
it please reject it”.

We have an Assignment Response. It
contains [consists] of a list of one item

of protocol information elements. This
one item is a SetupOrModifiedList,

which again has a criticality of ‘Ignore’.
If you don’t understand it…

oh no sorry, here it says “If you don’t
understand it just ignore it.

Don’t report an error”. It’s quite
interesting because you have a message

that only contains one element and it
says, well, you should reject the message

if you don’t understand it; but then the
information element says: “Oh, if you

don’t understand it please
ignore it”. So, okay.

Then inside the SetupOrModifiedList
we have one item

which is a protocol IE
container with one item

which has an item which is the
SetupOrModifiedItem, which is

a Radio Access Bearer Modified
Item, which contains

a Radio Access Bearer SetupOrModifiedItem
with a Radio Access Bearer ID of 1

and a transport layer address of
this. And in case you’re wondering

why the IP address has such
binary crap in front – it is

because it’s too difficult to express
in ASN.1 that this is an IP address.

You could not just define a type for an
IP address. That would be too simple.

No, you need to refer from this
specification to another specification,

another 3G specification,
which then refers to ITU-T X213

which tells you how you can encode
any possible transport layer address

in any possible network protocol on the
planet by using a hierarchical structure

like OUI IDs or something like that. And
‘35’ means it’s an IETF allocated address.

‘0001’ means it’s an IPv4 address and
then you actually have the payload.

And you can see Wireshark is too
stupid to decode such brilliance!

laughter and applause

Yeah, so. Then it’s hard to find
example traces. You want to implement

the protocol and you want to find some
example traces. This is a mail I …

actually I was looking for this this
year, in 2015. I was googling

for Iuh protocol traces. And what
did I find? My own e-mail from 2009

where I was asking for protocol traces.
But nobody ever responded.

So the situation is better today.
You can actually find, I think,

2 or 3 public pcap files containing
each maybe a handful of messages

on those interfaces. It’s really… it’s
odd, you know? These are protocols

that are specified publicly. They’re used
in production. Billions of users are using

these networks but nobody even has an
example protocol trace of those protocols.

Okay, now we have a couple of
protocol traces. We understand

the nesting level is deep. We are happy
that Wireshark decodes at least most of it,

which by the way we have to thank
one particular Ericsson employee

who is contributing those
dissectors to Wireshark.

So then we need to basically set up
a tool chain to generate code

from these ASN.1 syntaxes. So there is
an ASN.1 C compiler from Lev Walkins.

It’s good for a lot of things and I’m
very happy it exists. But it lacks many

if not most of the features that you
need in the Telecom world. That’s

sort of unfortunate. There’s no
information object classes, there is

no aligned PER support, there’s no
support for prefixing the type names.

Because we have 3 different protocols, we
want to use them from one program.

We need to prefix the type names because
of course each of those 3 protocols

has a type called ‘protocol information
element container’. But of course

it’s not the same protocol information
element container, there it said(?).

You know, each of the protocols
has its own containers.

So we had to add these pieces to the
asn1c, at least in a minimal way

in order to use it. And unfortunately
I don’t know anyone, and I’m certainly

no one who understands something
about compiler theory, so it’s

a little bit challenging. Now,
alternatives to asn1c, well,

the most complete tool kit you
can find for working with ASN.1

exists in the Erlang OTP system.
I used this in the past

for a lot of Osmocom projects,
but the fact is the C projects…

there are other developers and people
that contribute. In the Erlang projects

there is nobody that contributes except
from me. So I thought, well okay,

it’s very nice to work with ASN.1 in
Erlang, but then if nobody contributes

I’d rather go the difficult C way and then
have contributors in the project.

Also of course in the Osmocom project
we’re mostly low-level C guys;

and people are very wary of
virtual machines and the

– at least perceived – bloat they
introduce. The third alternative is

to use a proprietary ASN.1 compiler, and
in my day job I actually use such tools.

But in the first sight you think,

well, okay, so it’s a code compiler, it
compiles code, and copyright law says,

well, code that was generated by
a machine is not copyrightable because

the act of automatically compiling
code from one form into another form

does not make this… that does not
create a copyrightable work as itself.

So basically, you can take a proprietary
ASN.1 compiler, compile C code and then

use the resulting C code in an open source
project without having any problems

with the license of the ASN.1 compiler.
And that’s true, however

all those compilers I know, and I think
I know all of them, they have

a runtime library and that you only either
get as a binary library or you get it

in source code that’s not available
under a free software compatible license.

No option to do that. So we
have to stick with asn1c,

which as I said I don’t want to complain
about, it’s a great project. It just

doesn’t do all the things that we need.
But then, it was not written for us, so

of course it doesn’t do everything
we need. Luckily, a research group

at Eurecom, the European Communications
Research organization, has developed

a patch for adding aligned PER support
to asn1c. Unfortunately it was

against an old version because, well,
they probably don’t want to submit

this main line (?) and they don’t care
about porting it and rebasing (?) it.

I did that. It probably still needs some
clean-up before it can be submitted,

but my goal is to have
this included in asn1c.

And also we found quite a number
of bugs still in the code,

so it’s in the process of being improved.
Now information object classes are hard,

at least for me. Basically we skip that.

I manually edit the ASN.1 syntax for not
using information object classes anymore,

so I’m rewriting the ASN.1, that’s
supposed to be there to guarantee

that the encoding is a… so it circumvents

sort of the purpose. The idea is you take
the ASN.1 from the spec, you use it,

you don’t modify it. But I’m modifying
it because, well, the tools we have

are not good for what we want
to do. Type prefixing is done.

Now we have the information
element containers. Eurecom has

another idea about this.
They have a long Perl script.

I recommend you not to look at it, it
consists of a neverending sequence

of regular expressions, basically grep-ing
out certain parts of the ASN.1 syntax

without really formally parsing it,
or lexing it, or tokenizing it;

and then based on those regular
expressions generating C code that then

you can use with asn1c and link
against it. And surprisingly it works,

surprisingly good actually. We had to
teach it all the things that we needed

in addition to that.
But really it works surprisingly.

Now. Putting things together:
Copy and paste the ASN.1 syntax

from the 3GPP DOC files. Because 3GPP
specs are published as PDF files

and as Word documents, and you don’t
get the actual syntax as a text file.

You have to copy and paste from each page,
make sure you don’t get intermixed

like headlines or something like that.
Then you use the hacked-up, patched asn1c

to generate C code. You have to modify it
to make a shared library of the runtime

for the ASN.1 compiler because we have,
again, 3 syntaxes that we want to mix,

and that doesn’t really work with how
asn1c works. We use asn1tostruct

to remove this what I call the obfuscation
layer, these containers. We write

some code to dispatch the messages,
and then finally, we see some messages.

So we have those HNB register,
INITIAL_UE_MESSAGE and all these things.

This is what you can now get from
osmo-iuh.git, the Git repository

on the Osmocom server which
contains all this code.

It takes a long time to compile,
because asn1c generates one C file

and one header file for each type. And
they have lots of types in those specs.

So you end up with like 300..400
C files and header files compiled

into a 5 megabyte binary, and then finally
you want to get 4 bytes in a message.

So well, where do we go from here?
We have a couple of other things to do.

One interesting question is – and I’m
going to do a demo in a few minutes –

is what kind of hardware can be used?
Well, the hardware that I currently use

for this development is undisclosed
manufacturer, very expensive.

It’s not actually a femtocell, it’s a real
cell, it costs several thousand Euros,

not really suitable for hackers. However
many consumer grade femtocells

have also this Iuh protocol with the
same stacking. The problem is

they’re locked down, in a way that they
have certificates and connect over IPsec

to the operator network etc. So if
somebody can break this IPsec layer

and insert its own a certificate, or
disable the IPsec altogether then you can

talk Iuh to the osmo-iuh and then you
can use that hardware. This is something

that a couple of people have looked
at, and hopefully in the near future

we will have 1 or 2 femtocells
that people can use inexpensively

in order to use the software. At the
moment, I said, unfortunately

it’s not possible. As a summary,
before I go into the demo

of demonstrating it and you having
basically a look in the marvelous depth

of the Wireshark decodes, Iuh is
conceptually very easy to understand.

The lack of good ASN.1 tools is the
biggest problem in the free software world.

You need to overcome these containers,
and in the end you spend 90% of your time

in improving the tooling, fixing the
tooling and working around these

layers of abstraction rather than
doing the actual functionality.

We have started the work on the core
network components, the integration.

I was hoping that I could do a full demo
with a call, or a full demo with actually

having a data connection over this setup
that I have here, over the test setup.

I’m almost there. The signalling,
everything gets established,

the authentication works but then
somehow the data, the actual IP data

doesn’t want to come through. And that
is under investigation, but I’m sure

it will be available rather soon.
Now before we go for Q&A

let me just do a quick demo and let me
show you how this looks at the moment.

This is still a protocol trace

basically that was running in the past.
I’m just going to leave this here

at the left-hand side, I’m going to leave
the… on the right-hand side. So

what we can see is basically
on the left-hand side

we have the RUA encapsulated messages.
This is basically the Iuh interface

between the HomeNodeB and the
HomeNodeB gateway. Then we have

the osmo-iuh HomeNodeB gateway invisible
in between here, and that’s the program

running in the background. And then the
other side is this protocol stacking here,

where we see we have the SUA, this SCCP
User Adaption rather than the RUA

on the left-hand side. The RANAP messages
are the same on left and right, it’s

basically just converting. What I’m
going to start in the background is

basically – this is the wrong window,
I thought I had prepared everything just…

Yeah. Exactly. Good, that’s the one part,

that’s the other part…
So I’m going to start the…

I know the font is too small, you don’t
need to read that. I’m just going

to tell you the… I can make it larger,
then we won’t see really a lot.

What’s this? Why is it not…?

“Cannot listen on… socket…”.
Now that’s the demo effect!

Why on earth is it not binding?

What a pity! Okay, that’s embarrassing.

Then you get a larger font size!
And then let’s have a quick look.

I’ll try it very quickly. So I’m trying
this, it cannot bind to the sockets.

Probably my IP address has
disappeared on the laptop

while I’ve been talking here and now
it wants to bind to an address

that doesn’t exist anymore. And that
seems [to be] exactly what has happened.

Now don’t shout your SUDO! (?)
laughter

It will not like you. I can tell you.

Yeah. Now this should do the trick.

I’m starting this in Valgrind
because I’m still debugging, yeah…

Now it’s actually running, okay. Now
we do the same on the other side,

we go for a huge font size,
and I’m starting the HNB gateway.

We see a yellow line, that a connection
has been established. So now

we are waiting for the initial message
from the HomeNodeB to arrive.

We should see it here at the bottom
of this trace. We should see

a couple of Reset requests. Basically the
HomeNodeB this… the NodeB here

is trying to reconnect all the time
to its HomeNodeB gateway.

Of course there’s some backup… some
back off included and given that it was

not connected for the first 40 minutes or
so it will take some time to reconnect

to the SGSN and then I can have
the phone that I have here regist…

audio recording blanks out

one minute of audio missing

Herald: …is there somebody somewhere
at a mike? Mike 2, please!

Question: So if 3G is so annoying why
not skip it and go directly to LTE?

LaForge: Well, there’s a
couple of reasons for that.

First of all some people
really need it in terms of

there’s an actual demand
for 3G small networks

or 3G cells in applications where
it’s used. The second reason is

it’s a relatively limited incremental
step because the Layer 3 protocols

of GSM and UMTS are the same.
And that’s why basically we can use…

reuse the call control and the mobility
management, all those parts from GSM,

reuse them with 3G. I’m not saying we
shouldn’t do the same with LTE as well

but there are actually quite a number of
projects already involved in that area.

And LTE, well, to be frank, it’s so much
IP it’s not really telecom anymore.

You know I’m always interested in
the more obscure things that people

are not really looking so much at. IP,
I found IP boring when I stopped working

on Netfilter in 2004 or so. IP, well
everyone knows about IP, that’s…

you know, we need
something more interesting.

Herald: Microphone 1 please!

Question: So you say that you have
a lot of trouble parsing ASN.1.

But if it’s always the same containers
can’t you simply have a static dump

of the binary crap before and after that
stuff, and ignore the whole parsing part?

LaForge: You probably could. But then,
how can I say, my code athletics

demand better behavior from code I write
than just doing something like that. So

yes, you could, probably, but I’d rather
have a more clean way of doing that.

Herald: And continue on microphone 1!

Question: You said that UMTS
or 3G is a toolbox for creating

arbitrary telephony systems while
my knowledge tells me that GSM

is a much more rigid standard,
but, if you could please elaborate

on that concept of “arbitrary networks”!

LaForge: Well, I could illustrate that
very much with a certain protocol trace.

UMTS basically… when UMTS was specified
they didn’t know where the journey

was going to. Basically, it was not clear
that the internet would be the thing

that we know as of today. They didn’t
know that smartphones would exist.

They didn’t know that IP data services are
the type of data services that people

are interested in. Rather they were
thinking of… in generic terms.

So it could have been that
we needed all X.25 over UMTS.

It could be that, you know, people
wanted to do ATM over UMTS.

It was not clear that circuit-switched
services would basically go downhill

like they did meanwhile with
voice-over-IP telephony etc.

It was not clear that modem calls or
actual video calls that exist in UMTS

would not be the future. So it was very
unclear. And they tried to define something

that’s as flexible as possible to do
anything that you could imagine.

And if you look at the way how the layers
are structured and the fact that you have

transport channels, and transport channel
bundles, and radio access bearers etc.,

basically the structure. Even
only to transmit voice again

you have to set up with AMR for all
the codecs you need to configure

in the physical layer, I think,
for the 3 different bit classes

10 different combinations. So you end
up with something like 30 parameters

or 30 sets of parameters that you need
to communicate to the lower layers only

to configure it for establishing a voice
channel. And then the transport channels,

that where the bits are included, the
payload like how many bits fit in

into one frame doesn’t match with your
codec bitrate because they didn’t know

what codecs they would use. So it’s
really… it’s all arbitrary and with padding

and universal. So it’s not like GSM.
GSM is very simple and straightforward.

Herald: Okay, we have 5 minutes left
so we will have 2 quick questions

from the internet because
everybody on the stream:

you can actually ask questions
on the chat. Please!

Signal Angel: Okay, thanks. We have 2
questions as you said. The first one is:

if there would be interest in
implementing, you know, the whole stack

in a safe and non-VM based language
if the tooling was good enough?

LaForge breathes out heavily
laughter

LaForge: Well, I mean I’ve… It depends
on… I don’t want to find Language Wars

here. I would have been tempted to
do things in Erlang but then, I said,

the question is who else
would have been tempted?

I don’t think… I mean the point is what
we’re trying to do now is to basically

use most of what we already have
with the least additional effort

and I don’t think anyone will want
to start from scratch all over again.

But if they do so I would be happy
to see a clean implementation,

but I’m not so sure that will happen.

Signal Angel: Okay, thanks. The second
question is: why don’t we just

start over for a clean slate with hardware
and software and do a basically

100% nerd and hacker
driven mobile networks?

LaForge: Sorry, 100%…?

Signal Angel: …nerd/hacker
driven networks.

LaForge: Ah, well, I mean the point
of implementing all those specs is

you want to use the existing
devices out there. You want to use

the existing billions of mobile phones
that exist on the planet. And if you

want to talk to them then you need
to implement those protocols

and those systems that they implement.
If you want to start from something else

and do things from scratch, well, yes,
you can do that. But then keep in mind

that you will have very bulky end user
equipment with large like clusters

of FPGAs and DSPs, draining batteries,
having fans inside. Because you

will not be able to implement your system
in the same level of energy efficiency,

in the same level of, you know, ASICs
and optimized silicon processes etc.

like is the case for the
billions of existing devices.

Herald: Okay, thank you, Harald Welte!

LaForge: Yeah, thank you!
applause

postroll music

Subtitles created by c3subtitles.de
in the year 2017. Join, and help us!