1
00:00:00,000 --> 00:00:10,270
*32C3 preroll music*

2
00:00:10,270 --> 00:00:13,269
Herald: For several years now, here
at the Congress and at the Camp,

3
00:00:13,269 --> 00:00:18,890
we see that we have a GSM network,
that we operate our own network,

4
00:00:18,890 --> 00:00:23,080
that we have some services
like recently GPRS or

5
00:00:23,080 --> 00:00:28,510
roaming between the different
parts of the areas in the Camp.

6
00:00:28,510 --> 00:00:34,490
All of this started around 7 years
from now, with a talk at the 25C3;

7
00:00:34,490 --> 00:00:39,810
and a bunch of projects emerged
from that over the years.

8
00:00:39,810 --> 00:00:45,219
But wait, there is more. Right now,
the people running these services

9
00:00:45,219 --> 00:00:50,050
and running these projects are
starting to play around with 3G.

10
00:00:50,050 --> 00:00:55,399
And for everybody who doesn’t know what
3G is, like I did, for like 5 minutes ago,

11
00:00:55,399 --> 00:01:03,740
3G means that we will have HDSPA and
data services on our GSM networks.

12
00:01:03,740 --> 00:01:08,770
And I’m very honoured to introduce
to you this evening Harald Welte,

13
00:01:08,770 --> 00:01:14,070
a member of our Chaos family for
several years now, known maybe from

14
00:01:14,070 --> 00:01:20,770
the Kernel development. I first read his
name while debugging a chip card driver

15
00:01:20,770 --> 00:01:25,270
that stated ‘All bugs introduced
by…’ – this guy over there.

16
00:01:25,270 --> 00:01:29,170
So, other people may know
him from gpl-violations.org,

17
00:01:29,170 --> 00:01:33,960
where they try to enforce
the GPL. So. Please welcome

18
00:01:33,960 --> 00:01:36,460
Harald Welte, and… the stage is yours!

19
00:01:36,460 --> 00:01:44,830
*applause*

20
00:01:44,830 --> 00:01:48,680
LaForge: Hi. Welcome everyone
to this talk about, well,

21
00:01:48,680 --> 00:01:52,410
running your own GSM network, or
running your own 3G network, rather,

22
00:01:52,410 --> 00:01:56,810
sorry for that. And in more
technical terms, the slide titles

23
00:01:56,810 --> 00:02:00,969
with lots of acronyms as it is
customary in the telecom world.

24
00:02:00,969 --> 00:02:05,640
So forgive me if there’s too many
acronyms, but I didn’t invent them,

25
00:02:05,640 --> 00:02:11,910
I just try to use them whenever
appropriate. Okay. So, let’s start

26
00:02:11,910 --> 00:02:17,720
with a little bit of a history of open
source in mobile communication protocols.

27
00:02:17,720 --> 00:02:20,290
You have to remember
that we started about

28
00:02:20,290 --> 00:02:25,470
16 years after the proprietary
implementations, so the GSM network

29
00:02:25,470 --> 00:02:29,140
that we are running
here at the event, or that

30
00:02:29,140 --> 00:02:34,610
we started to run 7 years ago, started
16 years after GSM networks were run first

31
00:02:34,610 --> 00:02:39,710
in the public in Europe, so, at public
operators. So we’re really, really late,

32
00:02:39,710 --> 00:02:44,780
and if you want to compare the status
of open source mobile communications

33
00:02:44,780 --> 00:02:49,239
with open source operating system, then
I would say we are about where Linux was

34
00:02:49,239 --> 00:02:54,069
in ’94 or ’95. So, very far from today,
for those of you who are old enough

35
00:02:54,069 --> 00:02:58,730
to remember these days. So, I would
say “capable but not taken seriously”

36
00:02:58,730 --> 00:03:02,720
is sort of the general status.
The developer community

37
00:03:02,720 --> 00:03:07,629
working on these projects is still very
small. There’s a limited adoption

38
00:03:07,629 --> 00:03:13,470
in the market and the users,
often in niche applications,

39
00:03:13,470 --> 00:03:18,450
but nevertheless it is functional. So,
if we look a little bit at the timeline,

40
00:03:18,450 --> 00:03:22,629
2008 we had the talk about
“Running your own GSM network”

41
00:03:22,629 --> 00:03:28,200
with a huge Siemens base
station weighing I think 28 kg…

42
00:03:28,200 --> 00:03:30,540
Did my microphone…? No, it works, sorry.

43
00:03:30,540 --> 00:03:35,239
…weighing 28 kg and bulky old equipment

44
00:03:35,239 --> 00:03:38,629
not using TCP/IP but using E1 lines etc.

45
00:03:38,629 --> 00:03:42,760
Over the years we added more and more
BTS model vendors. Basically it means

46
00:03:42,760 --> 00:03:46,961
we can use Ericsson and Nokia
and other equipment to actually

47
00:03:46,961 --> 00:03:52,689
run these GSM networks today. People
have been working on GPRS support

48
00:03:52,689 --> 00:03:58,260
in a couple of sub projects
called OsmoSGSN, OpenGGSN,

49
00:03:58,260 --> 00:04:03,550
also the OsmoPCU project, so we’ve
been growing the stack downwards,

50
00:04:03,550 --> 00:04:08,040
also basically implementing
the software inside such a BTS,

51
00:04:08,040 --> 00:04:12,019
which we call OsmoBTS. There
are some production deployments

52
00:04:12,019 --> 00:04:16,470
– all spellings my mistake,
by the way, as obviously – so,

53
00:04:16,470 --> 00:04:19,858
production deployments in niche
applications such as maritime markets.

54
00:04:19,858 --> 00:04:24,900
So, if today you are on a ferry or on a
cruise ship and you use GSM services, the

55
00:04:24,900 --> 00:04:30,350
probability that you’re using OpenBSC and
associated projects in the background is

56
00:04:30,350 --> 00:04:36,800
very strong. There are hundreds of vessels
using our software today. Now, then we…

57
00:04:36,800 --> 00:04:43,270
*applause*

58
00:04:43,270 --> 00:04:46,600
…then we moved on the telephone
side, so we thought, well, you know,

59
00:04:46,600 --> 00:04:50,750
network side GSM in one thing, but let’s
do the phone as well, that was OsmocomBB,

60
00:04:50,750 --> 00:04:54,740
started in 2010. We did improvements
over the years, more and more

61
00:04:54,740 --> 00:05:00,199
completed the stack, but it’s really
all only old GSM/GPRS technology

62
00:05:00,199 --> 00:05:04,669
until very recently.
So in 2015, 15 years again

63
00:05:04,669 --> 00:05:09,590
after the first commercial deployment
of GPRS in a public network,

64
00:05:09,590 --> 00:05:13,730
we start to have an open source
implementation of EDGE, and that has just

65
00:05:13,730 --> 00:05:18,310
started like 2 or 3 months ago. So
again, 15..16 years late compared to

66
00:05:18,310 --> 00:05:23,020
what happens in the
proprietary world. Ok. But…

67
00:05:23,020 --> 00:05:28,270
this talk is not about EDGE, which
is 2.75G, if you want to speak

68
00:05:28,270 --> 00:05:35,330
in generation numbers. Today
we’re talking about 3G and 3.5G.

69
00:05:35,330 --> 00:05:39,690
And there’s a bit of ambivalence
with that subject because, well,

70
00:05:39,690 --> 00:05:43,169
today, if you talk to people in the
industry, they will say: “Ah, who cares

71
00:05:43,169 --> 00:05:47,449
about 3G, you know, it’s dead anyway!”.
We have already today at the point

72
00:05:47,449 --> 00:05:51,139
where we have ‘Peak 3G’,
so in the next few years,

73
00:05:51,139 --> 00:05:54,600
the number of subscribers and the
number of networks offering 3G services

74
00:05:54,600 --> 00:05:58,770
is no longer growing, it’s
basically stagnating and

75
00:05:58,770 --> 00:06:03,160
will turn downwards in the near
future. So LTE/4G networks

76
00:06:03,160 --> 00:06:08,979
is basically what everyone is hot about.
The other reason not to look at 3G

77
00:06:08,979 --> 00:06:12,979
is that it’s mind-bogglingly complex.
It’s not a single telephony system,

78
00:06:12,979 --> 00:06:17,490
it’s actually a toolbox to build
arbitrary telephony systems.

79
00:06:17,490 --> 00:06:21,349
And if you really wanted to start
implementing it from scratch

80
00:06:21,349 --> 00:06:27,449
including all the lower layers, including
the PHY, including the Layer 2 etc.

81
00:06:27,449 --> 00:06:32,669
I think it would be a waste of a lot of
time, actually. So we do what we did

82
00:06:32,669 --> 00:06:37,319
with the GSM networks back then, we
used proprietary base station hardware,

83
00:06:37,319 --> 00:06:40,539
and we implement the higher level
protocols, and then, if needed and

84
00:06:40,539 --> 00:06:44,470
if there’s interest and contributions
etc. we drive open source further

85
00:06:44,470 --> 00:06:50,199
down the stack and also
into the actual cells.

86
00:06:50,199 --> 00:06:55,319
So, one term that’s going to be used here

87
00:06:55,319 --> 00:06:58,910
in this context is ‘femtocells’. Quite some
number of people may have heard

88
00:06:58,910 --> 00:07:02,800
about femtocells before. In technical
terms it’s a base station – which is

89
00:07:02,800 --> 00:07:08,830
called NodeB in the UMTS language
world – and a radio network controller,

90
00:07:08,830 --> 00:07:13,280
which is the BSC, the base station
controller – in UMTS in one box.

91
00:07:13,280 --> 00:07:17,840
And using such femtocells or similar
hardware is much easier to interface

92
00:07:17,840 --> 00:07:21,699
than if you would use a regular
base station. So that basically is

93
00:07:21,699 --> 00:07:26,780
sort of a path that we think is doable
without spending man-years of implementing

94
00:07:26,780 --> 00:07:32,859
obscure and complex transport channels
and bundles and mappings and whatnot.

95
00:07:32,859 --> 00:07:37,069
There’s been a couple of talks about
doing creative stuff with femtocells.

96
00:07:37,069 --> 00:07:43,890
There’ve been talks by Kevin [Redon], Nico
[Golde] and Ravishankar in 2010/2011

97
00:07:43,890 --> 00:07:49,530
about security. There’s been a recent
presentation this year at Black Hat

98
00:07:49,530 --> 00:07:53,659
in the United States called
‘Adventures in Femtoland’.

99
00:07:53,659 --> 00:07:58,810
Those talks focus on basically, well,
the security of the femtocell itself,

100
00:07:58,810 --> 00:08:03,330
breaking into such a cell, rooting it,
owning it, doing creative things

101
00:08:03,330 --> 00:08:07,389
and then from there e.g.
attacking the mobile operator or

102
00:08:07,389 --> 00:08:12,190
attacking the privacy of subscribers
by using such a femtocell

103
00:08:12,190 --> 00:08:17,180
as a man-in-the-middle platform e.g. But
to my knowledge nobody has been talking

104
00:08:17,180 --> 00:08:21,610
about free software or open source
software, to run a network with

105
00:08:21,610 --> 00:08:27,870
such femtocells or similar equipment.
So, if we look at the UMTS architecture,

106
00:08:27,870 --> 00:08:32,580
like you find it in a textbook or like
in this particular slide or drawing

107
00:08:32,580 --> 00:08:38,070
from Kevin, you will find
several network elements

108
00:08:38,070 --> 00:08:42,659
all over the network,
so lots of different elements

109
00:08:42,659 --> 00:08:48,460
with lots of different acronyms.
We have a Mobile Equipment (ME)

110
00:08:48,460 --> 00:08:52,470
which is the telephone. We have a radio
interface called the Uu interface.

111
00:08:52,470 --> 00:08:56,650
We have actual base stations
called NodeB and we have

112
00:08:56,650 --> 00:09:01,110
a base station controller that’s called
the Radio Network Controller, the RNC;

113
00:09:01,110 --> 00:09:06,690
and then here we have, on this boundary
we have IuCS and IuPS interfaces

114
00:09:06,690 --> 00:09:10,650
that interface the Base
Station Controllers

115
00:09:10,650 --> 00:09:14,470
with the core of the network which
is the Mobile Switching Center,

116
00:09:14,470 --> 00:09:18,420
the Media Gateway, the Serving GPRS
Support Node, and then other elements

117
00:09:18,420 --> 00:09:23,880
here. And this is actually the interface
line which we have been implementing

118
00:09:23,880 --> 00:09:29,360
in recent months at the boundary
between the Access Network,

119
00:09:29,360 --> 00:09:34,290
the Radio Access Network and the Core
Network on the other side of the slide.

120
00:09:34,290 --> 00:09:39,970
So, well, you could just get a NodeB
and implement the protocol Iub.

121
00:09:39,970 --> 00:09:43,790
This is what we did with GSM before,
we basically started here. We only got

122
00:09:43,790 --> 00:09:48,880
the actual BTS or NodeB and
we implemented that protocol.

123
00:09:48,880 --> 00:09:52,910
However, well, this protocol
in UMTS is extremely complex

124
00:09:52,910 --> 00:09:56,960
and fairly low down the stack.
Just to give you an idea:

125
00:09:56,960 --> 00:10:01,710
every single voice codec frame
from a voice call that you receive

126
00:10:01,710 --> 00:10:05,460
has 3 different classes of bits, and
each class of bits gets put into

127
00:10:05,460 --> 00:10:09,800
different UDP messages, and then you
get basically 3 flows of UDP messages,

128
00:10:09,800 --> 00:10:13,750
and you need to synchronize and
inter-mangle (?) and re-interleave

129
00:10:13,750 --> 00:10:18,300
those bits in order to get to a speech
codec frame. So it’s… and I’m not even

130
00:10:18,300 --> 00:10:21,170
talking about the signalling plane (?).
So the lower you get in UMTS the more

131
00:10:21,170 --> 00:10:24,740
complex it gets, let’s try to avoid that.
And that’s the kind of complexity

132
00:10:24,740 --> 00:10:30,940
that I like to avoid. This is from the
official spec about the UMTS spectrum.

133
00:10:30,940 --> 00:10:36,020
It’s an extremely obvious and
self-explanatory slide, so I’ll…

134
00:10:36,020 --> 00:10:38,590
*laughter*
I leave it at this and say, yeah,

135
00:10:38,590 --> 00:10:44,070
that’s not what we want to do.
So, we… how can I say, we…

136
00:10:44,070 --> 00:10:50,310
Even though we don’t like it we just use
proprietary blobs to implement that. Now,

137
00:10:50,310 --> 00:10:53,780
the protocol stacking on those interfaces
that we actually want to implement

138
00:10:53,780 --> 00:10:58,260
is what I’m going to look at the next
couple of slides. The Iu interface,

139
00:10:58,260 --> 00:11:01,910
and by the name, Iu has no specific
meaning, it’s just the Iu interface,

140
00:11:01,910 --> 00:11:06,180
you could say the A, the B, the C,
the Z interface – it’s the ‘Iu interface’.

141
00:11:06,180 --> 00:11:10,960
It’s split in CS and PS, that’s circuit-
switched and packet-switched.

142
00:11:10,960 --> 00:11:16,040
Circuit-switched means telephony services
and packet-switched means data services.

143
00:11:16,040 --> 00:11:20,370
And we’re going to look at the
protocol stacking of those interfaces

144
00:11:20,370 --> 00:11:25,430
in the next couple of slides. Originally,
remember, well, maybe a good time

145
00:11:25,430 --> 00:11:29,640
to go back in history, in sort of history
of mobile communications, which

146
00:11:29,640 --> 00:11:35,570
should be taught at every school, I think,
including archeology of protocols,

147
00:11:35,570 --> 00:11:41,890
which… no, honestly…
*laughter and applause*

148
00:11:41,890 --> 00:11:46,150
You need to do protocol archeology if you
want to implement certain interfaces

149
00:11:46,150 --> 00:11:50,390
today. So, on my blog you can find
some posts about a couple of years ago

150
00:11:50,390 --> 00:11:55,980
where I had to basically write a parser
for Microsoft Word for DOS text files

151
00:11:55,980 --> 00:12:00,060
to automatically extract snippets of
ASN.1 syntax for MAP version 1

152
00:12:00,060 --> 00:12:05,630
which is still used today. So, it’s… yes,
it… sometimes you really need to do

153
00:12:05,630 --> 00:12:09,790
archeology. So anyway, not for this,
but any… when UMTS was specified,

154
00:12:09,790 --> 00:12:14,560
this is the late 90s, this is when the
first dotcom bubble basically got big,

155
00:12:14,560 --> 00:12:18,710
this is when billions and
billions of Euros or Dollars

156
00:12:18,710 --> 00:12:22,040
or whatever unit of currency was
poured into the development of the

157
00:12:22,040 --> 00:12:26,490
‘universal telephony mobile
system’, the… sorry, the

158
00:12:26,490 --> 00:12:30,930
‘universal mobile telephony system’,
the UMTS, which should basically

159
00:12:30,930 --> 00:12:35,500
be the grand unifying theory
of mobile communications.

160
00:12:35,500 --> 00:12:42,260
And it was built on top of ATM, of course,
because ATM was the most shiny and

161
00:12:42,260 --> 00:12:47,080
brightest technology in the late 90s that
all the universities were researching.

162
00:12:47,080 --> 00:12:50,740
So, if you look at the classical protocol
stacking and you look at the individual

163
00:12:50,740 --> 00:12:56,740
interfaces; the Uu is the radio interface,
Iub is between the NodeB and RNC,

164
00:12:56,740 --> 00:12:59,910
but this is… the IuPS is actually what
we want to implement. So basically

165
00:12:59,910 --> 00:13:03,570
the left side of this slide is
what is implemented

166
00:13:03,570 --> 00:13:08,060
in the proprietary base stations
or femtocells that we are using,

167
00:13:08,060 --> 00:13:12,040
and the right-hand side of that
slide is what we are implementing.

168
00:13:12,040 --> 00:13:15,740
So we need to implement the protocol
stackings here. As you can see

169
00:13:15,740 --> 00:13:20,940
the protocol stack is deep
and has many acronyms.

170
00:13:20,940 --> 00:13:24,930
So, to make things more complicated

171
00:13:24,930 --> 00:13:28,450
the femtocells that you can find
on the market are slightly different

172
00:13:28,450 --> 00:13:32,580
from the real, normal 3G architecture,

173
00:13:32,580 --> 00:13:36,240
so if you try to compare
this slide with that slide,

174
00:13:36,240 --> 00:13:40,490
you will find some differences here.
The difference is that they introduce

175
00:13:40,490 --> 00:13:45,650
a security gateway which is basically
just ITU and 3GPP language

176
00:13:45,650 --> 00:13:50,190
for ‘IPsec gateway’,

177
00:13:50,190 --> 00:13:54,770
and you have a HomeNodeB gateway
that doesn’t really do anything useful,

178
00:13:54,770 --> 00:13:57,961
rather than putting messages from
one protocol stack on the left

179
00:13:57,961 --> 00:14:00,910
to another protocol stack on the right
with the underlying protocols

180
00:14:00,910 --> 00:14:05,530
doing exactly the same thing
but being differently encoded.

181
00:14:05,530 --> 00:14:09,141
And this is what you can see here,
basically, the HomeNodeB gateway

182
00:14:09,141 --> 00:14:13,300
which is part of the software that we
implemented. You can see basically,

183
00:14:13,300 --> 00:14:17,600
well, you have RANAP,
this is the protocol

184
00:14:17,600 --> 00:14:20,660
that really is sort of what
we’re interested in,

185
00:14:20,660 --> 00:14:24,920
the Radio Access Network
Application Part; and RANAP,

186
00:14:24,920 --> 00:14:29,250
in order to implement that, there’s
several other protocols underneath.

187
00:14:29,250 --> 00:14:33,440
And on the femtocell which is called
HNodeB, the HomeNodeB, because,

188
00:14:33,440 --> 00:14:37,690
well, ‘femtocells’ is a marketing term
and specs can never use marketing terms,

189
00:14:37,690 --> 00:14:42,850
so they have technical
terms. So, the femtocell

190
00:14:42,850 --> 00:14:51,270
basically encapsulates RANAP
into RUA, the ‘RANAP User…’,

191
00:14:51,270 --> 00:14:56,120
what was it? Sorry, …Adaptation,
yes. The ‘RANAP User Adaptation’.

192
00:14:56,120 --> 00:15:00,510
So the ‘Radio Access Network
Application Part User Adaptation’,

193
00:15:00,510 --> 00:15:04,630
on top of the SCTP, the Streaming
Control Transfer Protocol,

194
00:15:04,630 --> 00:15:09,180
which some may know is a protocol
that’s on the same layer as TCP or UDP

195
00:15:09,180 --> 00:15:13,110
but has different properties. And

196
00:15:13,110 --> 00:15:17,180
this RUA is implemented than (?) the
HomeNodeB Gateway where it is replaced

197
00:15:17,180 --> 00:15:21,950
by M3UA and SCCP. And basically
the same RANAP message

198
00:15:21,950 --> 00:15:26,430
gets passed from left to right. So
it’s really… you could think like…

199
00:15:26,430 --> 00:15:30,730
think of it like an IPv6 to IPv4 proxy.

200
00:15:30,730 --> 00:15:35,670
If that’s more an area that you’re
more familiar with. Okay.

201
00:15:35,670 --> 00:15:41,260
So, I said there are some differences
between an actual, regular,

202
00:15:41,260 --> 00:15:44,970
old-fashioned UMTS base station,
like your public operator would use it

203
00:15:44,970 --> 00:15:49,090
and the HomeNodeB, or femtocell,
that we like to use in this project,

204
00:15:49,090 --> 00:15:53,850
at least initially. And I said the
main difference is that the RNC,

205
00:15:53,850 --> 00:15:57,510
the Radio Network Controller, is built-in,
so a lot of the lower layer protocols

206
00:15:57,510 --> 00:16:00,290
are terminated, and we don’t need
to worry about that. If we look

207
00:16:00,290 --> 00:16:04,880
at the protocol stacking again there
is a lot of protocol layers here,

208
00:16:04,880 --> 00:16:09,910
you can see the MAC layer, the RLC layer,
the RRC layer… and all the PHYsical stuff

209
00:16:09,910 --> 00:16:14,190
underneath is all basically already
implemented because it’s part of the

210
00:16:14,190 --> 00:16:19,100
femtocell, in this case. So the protocol
stacking now looks a little bit like this.

211
00:16:19,100 --> 00:16:24,030
We have the HomeNodeB,
and the HomeNodeB gateway,

212
00:16:24,030 --> 00:16:28,000
and then our core network elements
already. So the SGSN and the GGSN,

213
00:16:28,000 --> 00:16:33,190
if you’ve looked at GSM in the past, or
GPRS, even the software that exists today

214
00:16:33,190 --> 00:16:37,910
and for many years in the Osmocom
project, we have implementations of those.

215
00:16:37,910 --> 00:16:39,950
What we are missing is
the HomeNodeB gateway,

216
00:16:39,950 --> 00:16:43,540
and is all the fancy new protocols
here. And some modifications.

217
00:16:43,540 --> 00:16:50,750
So, well, what do we need to
do to actually implement?

218
00:16:50,750 --> 00:16:54,920
This Iuh protocol. As I said there’s the
different protocol layers – there is RUA,

219
00:16:54,920 --> 00:17:00,000
there is the RANAP protocol,
and the HNBAP protocol.

220
00:17:00,000 --> 00:17:04,199
Let’s look at those protocols, what they
do, and how can we implement them.

221
00:17:04,199 --> 00:17:08,030
I’m skipping a few slides in the
middle because it’s illustrative

222
00:17:08,030 --> 00:17:11,650
if somebody wants to check the slides
later but it would go into too much detail

223
00:17:11,650 --> 00:17:17,510
at this point. So the RANAP
User Adaptation layer

224
00:17:17,510 --> 00:17:20,980
– given the spec number above there,
so if you look for that online

225
00:17:20,980 --> 00:17:25,740
you can find the actual spec – is a very
simple connection-oriented layer

226
00:17:25,740 --> 00:17:30,230
that provides you the
notion of a connection

227
00:17:30,230 --> 00:17:34,070
over a datagram transport
layer underneath.

228
00:17:34,070 --> 00:17:38,650
It has very, very few operations
and message types,

229
00:17:38,650 --> 00:17:43,710
including CONNECT which – well,
surprisingly – sets up a new connection.

230
00:17:43,710 --> 00:17:47,810
DIRECT TRANSFER which transfers
data inside a connection.

231
00:17:47,810 --> 00:17:51,140
DISCONNECT – to terminate a connection.
And CONNECTIONLESS TRANSFER

232
00:17:51,140 --> 00:17:54,860
to transfer data outside of a connection.
And, of course, an ERROR INDICATION,

233
00:17:54,860 --> 00:17:59,940
in case something goes wrong. So we can
have multiple connections in parallel

234
00:17:59,940 --> 00:18:06,310
over a signalling link. And they are
distinguished by a 24 bit context ID,

235
00:18:06,310 --> 00:18:09,990
to differentiate those multiple
parallel connections. Think of it like

236
00:18:09,990 --> 00:18:13,890
a port number. In the case of UDP,
or whatever else you might want

237
00:18:13,890 --> 00:18:18,300
to compare it to. So, this… if you look
at this and you read the specs like

238
00:18:18,300 --> 00:18:22,810
“Oh, pfff, you know, it’s nothing, it’s
like you implement like 5..6 message types

239
00:18:22,810 --> 00:18:27,010
and that’s it”… well, there’s
a bit more details to that,

240
00:18:27,010 --> 00:18:34,290
but we’ll get back later to this.
The HomeNodeB Application…

241
00:18:34,290 --> 00:18:38,920
no, HomeNodeB Application
Part, the HNBAP protocol

242
00:18:38,920 --> 00:18:42,830
has a couple of more transactions
which basically serve

243
00:18:42,830 --> 00:18:45,790
for the registration of
the cell to the network,

244
00:18:45,790 --> 00:18:50,430
the registration of user equipment,
UE, that’s your mobile phone,

245
00:18:50,430 --> 00:18:54,940
and some additional messages.

246
00:18:54,940 --> 00:18:58,860
So HNB is the HomeNodeB registration;
we have Registration REQUEST, ACCEPT,

247
00:18:58,860 --> 00:19:02,810
REJECT, De-registration, we have
the same for mobile phones.

248
00:19:02,810 --> 00:19:07,560
We have some more detailed
transactions that I’m going to skip.

249
00:19:07,560 --> 00:19:12,560
But also it’s really very simple,
conceptially, it’s not very complex,

250
00:19:12,560 --> 00:19:15,450
you don’t have like massive state
machines or anything like that.

251
00:19:15,450 --> 00:19:19,510
Very few, very limited messages.

252
00:19:19,510 --> 00:19:23,630
Then we look at RANAP. That’s the Radio
Access Network Application Part.

253
00:19:23,630 --> 00:19:26,880
This is where your actual signalling
messages from the phone

254
00:19:26,880 --> 00:19:30,750
are tunneled through. So if your
phone registers to the network

255
00:19:30,750 --> 00:19:35,050
you may have heard the term LOCATION
UPDATE where the phone basically

256
00:19:35,050 --> 00:19:38,670
registers to the network or updates
its location with the network.

257
00:19:38,670 --> 00:19:43,980
That’s the first message you would
see, encapsulated inside RANAP, and

258
00:19:43,980 --> 00:19:49,250
transported to the core network element.
Also things like PDP context activation,

259
00:19:49,250 --> 00:19:53,430
if you activate a data connection to
a certain APN over cellular protocols,

260
00:19:53,430 --> 00:19:59,850
all this is encapsulated
in the RANAP layer.

261
00:19:59,850 --> 00:20:03,760
Also the number of messages that we
actually need is extremely limited.

262
00:20:03,760 --> 00:20:08,240
Again, it’s a very short list, it’s
not like hundreds of messages.

263
00:20:08,240 --> 00:20:12,230
But the messages themselves can be
quite complex. With nesting levels

264
00:20:12,230 --> 00:20:17,410
up to 12..14 layers deep.
But we’ll see that later on.

265
00:20:17,410 --> 00:20:21,200
So we have a couple of transactions.
RESET – well, I don’t need to explain –

266
00:20:21,200 --> 00:20:26,350
it’s a Reset. INITIAL UE MESSAGE
means a new phone has connected,

267
00:20:26,350 --> 00:20:29,520
and it has sent us the first message
that this phone has transmitted,

268
00:20:29,520 --> 00:20:33,850
that’s why it’s ‘initial’ message. DIRECT
TRANSFER is all the follow-up transfer.

269
00:20:33,850 --> 00:20:38,220
IU RELEASE means we’re releasing
a connection. Some commands

270
00:20:38,220 --> 00:20:43,750
to configure the security, the ciphering,
the encryption. A PAGING command

271
00:20:43,750 --> 00:20:47,680
by which the network can initiate
a transaction to the phone.

272
00:20:47,680 --> 00:20:52,010
And RAB ASSIGNMENT. RAB
is the Radio Access Bearer

273
00:20:52,010 --> 00:20:56,640
which is basically an abstract notion

274
00:20:56,640 --> 00:21:03,310
of a bearer able to
transport communication.

275
00:21:03,310 --> 00:21:07,020
If you come from classic
telephony the bearer was

276
00:21:07,020 --> 00:21:11,030
an analog voice channel.
If you go to ISDN the bearer is

277
00:21:11,030 --> 00:21:14,930
a 64kbps synchronous channel

278
00:21:14,930 --> 00:21:19,470
where you have Alaw Ulaw (?)
inside, and voice data.

279
00:21:19,470 --> 00:21:24,790
Or you have some HTLC (?) or X75
or whatever data inside.

280
00:21:24,790 --> 00:21:29,830
In GSM the bearer is
typically voice bearers,

281
00:21:29,830 --> 00:21:36,020
with different voice codecs.
The same it is in UMTS.

282
00:21:36,020 --> 00:21:39,940
And basically you can configure
those bearers in UMTS because

283
00:21:39,940 --> 00:21:45,660
that’s a very universal and
flexible part of the system.

284
00:21:45,660 --> 00:21:48,880
Now, one of the protocols we have
seen in the stack – I’m just going back

285
00:21:48,880 --> 00:21:55,480
a couple of slides to reiterate – that
is the SCCP which is introduced here.

286
00:21:55,480 --> 00:21:58,980
The ‘Signalling Connection Control Part’,

287
00:21:58,980 --> 00:22:03,450
if I remember correctly. It’s a protocol
that’s used a lot in core networks

288
00:22:03,450 --> 00:22:09,360
of mobile operators. So if you
look at Roaming interfaces,

289
00:22:09,360 --> 00:22:14,030
at classic SS7 interfaces – think of the
SS7 security talks etc. we’ve had here

290
00:22:14,030 --> 00:22:19,120
at CCC events a lot of times – this is
a protocol that’s very often used

291
00:22:19,120 --> 00:22:24,990
in a lot of different parts of
telecom. But the problem is –

292
00:22:24,990 --> 00:22:29,820
everywhere except [at] this
particular point in UMTS and GSM

293
00:22:29,820 --> 00:22:33,580
it is used only in connection-less
mode; and this is the only point

294
00:22:33,580 --> 00:22:38,450
where it uses connection-oriented
SCCP. And therefor none of the existing

295
00:22:38,450 --> 00:22:41,660
free software implementations is
implemented. You can look to Yate,

296
00:22:41,660 --> 00:22:45,000
you can look to the libosmo-sccp,
the library that we have in

297
00:22:45,000 --> 00:22:49,980
the Osmocom project. You can
look at the Mobicents Java stack

298
00:22:49,980 --> 00:22:54,650
for these protocols. You can look
at the osmo_sccp Erlang code.

299
00:22:54,650 --> 00:22:57,810
Basically no implementation
exists, so we also had to

300
00:22:57,810 --> 00:23:03,720
implement that part,
at least to the point,

301
00:23:03,720 --> 00:23:07,440
to those features that are required.
But once we have implemented

302
00:23:07,440 --> 00:23:11,580
all these protocols – RUA, SCCP,

303
00:23:11,580 --> 00:23:15,120
the RANAP, the HNBAP, then

304
00:23:15,120 --> 00:23:20,730
we need to somehow interface
those protocols with the existing

305
00:23:20,730 --> 00:23:25,070
network elements that we have for GSM. And

306
00:23:25,070 --> 00:23:29,480
there are sort of several
challenges in this area,

307
00:23:29,480 --> 00:23:34,480
in what people know
as the OpenBSC project.

308
00:23:34,480 --> 00:23:38,019
Actually the program that most
people use is called OsmoNITB

309
00:23:38,019 --> 00:23:41,900
– the network in the box – which is called
‘network in the box’ because it implements

310
00:23:41,900 --> 00:23:47,290
all the network elements that you
need in one box, or in one program.

311
00:23:47,290 --> 00:23:50,520
Unfortunately we need to separate
those individual pieces which are

312
00:23:50,520 --> 00:23:57,190
all in one blob, in order to interface
at the point where we want to interface.

313
00:23:57,190 --> 00:24:00,780
So this separation of the MSC part
and the BSC part needs to be done

314
00:24:00,780 --> 00:24:05,220
inside the ‘network in the box’.
We need the UMTS authentication

315
00:24:05,220 --> 00:24:08,270
and key agreement support,

316
00:24:08,270 --> 00:24:13,190
and we need the different
protocols that I just mentioned

317
00:24:13,190 --> 00:24:17,830
and link them in on the SGSN side.

318
00:24:17,830 --> 00:24:22,710
For the data services we need
to introduce some extraction

319
00:24:22,710 --> 00:24:28,390
to basically differentiate the packet data
connections coming from GPRS networks

320
00:24:28,390 --> 00:24:33,200
and those coming from the new
3G networks or base stations

321
00:24:33,200 --> 00:24:37,560
that we are supporting.
But that’s all manageable.

322
00:24:37,560 --> 00:24:43,400
Now, the question is,

323
00:24:43,400 --> 00:24:47,330
do we really want to go for the
full stack as it has been described,

324
00:24:47,330 --> 00:24:53,980
or can we take some shortcuts, do we
really need to implement the full SCCP,

325
00:24:53,980 --> 00:24:58,750
for example? Do we need to implement M3UA,

326
00:24:58,750 --> 00:25:03,520
which is another protocol layer in there?
Can we basically simplify that?

327
00:25:03,520 --> 00:25:07,960
The initial idea was
– if we go back to that slide –

328
00:25:07,960 --> 00:25:11,190
to reduce the complexity, I already
mentioned this HomeNodeB gateway

329
00:25:11,190 --> 00:25:15,460
which basically passes RANAP
from left to right, and just changes

330
00:25:15,460 --> 00:25:22,460
the underlying encapsulation. Why don’t we
just continue using RUA up into the SGSN

331
00:25:22,460 --> 00:25:26,440
and thereby avoid having
to do SCCP and M3UA,

332
00:25:26,440 --> 00:25:30,220
avoid having to implement more protocols
without having any functional gain.

333
00:25:30,220 --> 00:25:33,720
I mean it would just work the same way
if we take RUA and we take it all the way

334
00:25:33,720 --> 00:25:37,640
into the SGSN. So there’s been
some thinking along those lines

335
00:25:37,640 --> 00:25:43,760
but the idea was to…

336
00:25:43,760 --> 00:25:47,880
…go sort of in a compromise so what
we’re using here is yet another protocol

337
00:25:47,880 --> 00:25:52,350
called SUA, the SCCP User Adaption.

338
00:25:52,350 --> 00:25:55,750
And that replaces those 2 layers
and keeps things a little bit simpler

339
00:25:55,750 --> 00:26:03,310
from the implementation side. OK, now we
have all these different protocol layers,

340
00:26:03,310 --> 00:26:07,510
and the integration into the core
network elements. Now the fun starts.

341
00:26:07,510 --> 00:26:11,420
We have a plan, we know
what needs to be done,

342
00:26:11,420 --> 00:26:15,090
we know what needs to be done,
and now we actually need to do it.

343
00:26:15,090 --> 00:26:20,470
So the theory was easy – read a couple
of specs, find out 6..7 messages,

344
00:26:20,470 --> 00:26:24,510
not too many transactions, no
complex state machines. Okay, now,

345
00:26:24,510 --> 00:26:27,820
a lot of the more modern telecom
protocols use ASN.1 syntax.

346
00:26:27,820 --> 00:26:34,640
It’s an abstract syntax notation
for defining data structures

347
00:26:34,640 --> 00:26:39,910
or procedures to be communicated, and
then you can use code generation tools

348
00:26:39,910 --> 00:26:44,270
to generate code in your favorite
language from this syntax

349
00:26:44,270 --> 00:26:46,809
doing all the marshalling and
demarshalling of the messages.

350
00:26:46,809 --> 00:26:51,260
That’s at least what’s the idea. This is
very different from what we used to do

351
00:26:51,260 --> 00:26:55,640
in the GSM world because GSM
was specified in the late 1980s.

352
00:26:55,640 --> 00:26:59,770
ASN.1 didn’t exist to my knowledge back
then, or at least they didn’t know about it,

353
00:26:59,770 --> 00:27:04,670
and/or they thought it was not something
that you could do in a mobile phone

354
00:27:04,670 --> 00:27:07,431
at that time. Think about 8 bit
microcontrollers and whatnot,

355
00:27:07,431 --> 00:27:12,430
what they were using these days.
So the GSM messages,

356
00:27:12,430 --> 00:27:16,000
basically you have…, you look at the spec
and you see “Oh, there’s one byte this,

357
00:27:16,000 --> 00:27:18,790
then there’s a 2 byte length field, and
then there’s that”. And you need

358
00:27:18,790 --> 00:27:24,150
to implement that basically in your code,
based on the textual representation.

359
00:27:24,150 --> 00:27:28,150
Now, for UMTS almost all the
protocols and particularly these

360
00:27:28,150 --> 00:27:33,290
that we’re looking [at] here are specified
in abstract syntax notation which, well,

361
00:27:33,290 --> 00:27:36,300
on the one hand side you would say: “Oh
yes, great, now we don’t need to write

362
00:27:36,300 --> 00:27:40,650
all this message encoding and decoding
code, and then we end up interpreting

363
00:27:40,650 --> 00:27:45,470
the spec different[ly] and we have sort of
incompatible messages and whatnot”.

364
00:27:45,470 --> 00:27:50,830
That’s true to some extent, okay. Now
what you need to know about ASN.1 is,

365
00:27:50,830 --> 00:27:55,040
there are different encoding rules that
define how the abstract syntax notation

366
00:27:55,040 --> 00:27:59,830
gets converted into a concrete
binary representation. There is a

367
00:27:59,830 --> 00:28:04,710
Basic Encoding Rules (BER),
there is all kinds of encoding rules,

368
00:28:04,710 --> 00:28:09,809
there is even JSON encoding rules these
days. There’s also XML encoding rules.

369
00:28:09,809 --> 00:28:14,470
But what’s used here in these specs is
called ‘aligned Packed Encoding Rules’

370
00:28:14,470 --> 00:28:19,740
(APER). This is a particular encoding rule
that was not… or is not supported

371
00:28:19,740 --> 00:28:26,450
by any of the ASN.1 compilers that exist
in open source that generate C code.

372
00:28:26,450 --> 00:28:30,960
So we first had to teach the ASN.1
compiler this encoding rule.

373
00:28:30,960 --> 00:28:34,720
And the second big problem is the ASN.1
syntax used in those protocol specs

374
00:28:34,720 --> 00:28:39,700
uses a construct called ‘Information
Object Classes’, which is sort of…

375
00:28:39,700 --> 00:28:48,000
well, you know, an interesting way
how to express or how to have…

376
00:28:48,000 --> 00:28:53,090
a different notation on how to construct
those messages and how to construct

377
00:28:53,090 --> 00:28:58,309
operations that have like an initiating
request, a ‘successful’ response,

378
00:28:58,309 --> 00:29:02,770
a ‘successful error’ outcome or something
like that. And you can express that

379
00:29:02,770 --> 00:29:06,020
in a really nice way but then you need
a compiler and a code generator

380
00:29:06,020 --> 00:29:12,240
that can parse that, and that’s really
difficult in the free software world

381
00:29:12,240 --> 00:29:17,470
within some constraints. I’ll get into
the details. Now the next thing is

382
00:29:17,470 --> 00:29:21,080
that the way how they use ASN.1
in these protocol specs

383
00:29:21,080 --> 00:29:24,860
– ASN.1 being the abstract syntax
notation – is not abstract enough.

384
00:29:24,860 --> 00:29:30,299
They need to have another
abstraction layer. So they use ASN.1

385
00:29:30,299 --> 00:29:34,510
to describe containers, containers
for information elements,

386
00:29:34,510 --> 00:29:38,360
containers for messages, containers
for lists of information elements

387
00:29:38,360 --> 00:29:42,190
and containers for pairs of information
elements. It’s very important.

388
00:29:42,190 --> 00:29:46,490
You cannot just have a list of 2.
No, you need to have a pair

389
00:29:46,490 --> 00:29:50,960
that says, well, this is a pair of
2 information elements. Not sure why,

390
00:29:50,960 --> 00:29:55,300
but somebody probably had
his reasons for doing so.

391
00:29:55,300 --> 00:30:00,300
Now the point is, basically,
you use the ASN.1 syntax

392
00:30:00,300 --> 00:30:03,500
and you generate some code for
encoding or decoding and then

393
00:30:03,500 --> 00:30:07,010
you’re not really done at that point.
Because then you basically:

394
00:30:07,010 --> 00:30:10,000
“Oh, this is a list of containers”, and
then you look into each of the containers

395
00:30:10,000 --> 00:30:13,750
and then call the decoder again for each
of the elements in the list. And then

396
00:30:13,750 --> 00:30:17,180
in there there might be another level
of containers and you unpack it again,

397
00:30:17,180 --> 00:30:22,280
so it’s a little bit like matryoshka
or, you know, these dolls

398
00:30:22,280 --> 00:30:27,920
nested in each other; or somebody
sends you a large packet etc. Well,

399
00:30:27,920 --> 00:30:31,720
to illustrate that, if you’ve ever seen
ASN.1, this is a relatively simple example

400
00:30:31,720 --> 00:30:37,720
describing authentication couples
or triplets or quintuplets.

401
00:30:37,720 --> 00:30:41,770
Basically, the authentication data that’s
used for authenticating subscribers

402
00:30:41,770 --> 00:30:45,909
in networks. This is what is used
also in GSM. It’s relatively simple,

403
00:30:45,909 --> 00:30:50,640
so it basically tells you, well, there’s
an authentication set list which contains

404
00:30:50,640 --> 00:30:54,740
[consists] of a choice of either a triplet
or a quintuplet list. Each of those lists

405
00:30:54,740 --> 00:30:58,640
either have a length from 1..5, and then
you have basically a sequence which is

406
00:30:58,640 --> 00:31:03,370
sort of struct or a record of the below
items in those lists. That is how [it] is

407
00:31:03,370 --> 00:31:08,600
and should look like and how it
normally looks like. Now in RANAP

408
00:31:08,600 --> 00:31:13,060
and these protocols they first – as said –
they define these containers, they say:

409
00:31:13,060 --> 00:31:17,690
“We have…”. So it reminds me a bit
of some mathematicians. It’s like

410
00:31:17,690 --> 00:31:21,260
“We define we have this, and then we have
that, and therefore we can construct

411
00:31:21,260 --> 00:31:27,140
such a new structure” and whatnot. So
basically, they define first a container

412
00:31:27,140 --> 00:31:32,170
for protocol information elements,
protocol IEs. And in the protocol IE

413
00:31:32,170 --> 00:31:36,680
is the actual information element. Each
element has an ID, it has a criticality.

414
00:31:36,680 --> 00:31:39,500
The criticality tells you whether,
if you do not understand

415
00:31:39,500 --> 00:31:44,080
such an information element, should
you ignore it, should you reject it,

416
00:31:44,080 --> 00:31:49,190
should you ignore it but report to the
sender that you did not understand it

417
00:31:49,190 --> 00:31:54,370
despite proceeding with your operation,
and then the actual value.

418
00:31:54,370 --> 00:31:58,401
And the value is an ANY type which
means there is another ASN.1 syntax

419
00:31:58,401 --> 00:32:02,450
in that value that you then need to parse.

420
00:32:02,450 --> 00:32:07,450
So you need to do these
2 steps in the code. You first

421
00:32:07,450 --> 00:32:11,570
unwrap the containers and then you
decode what is inside the containers.

422
00:32:11,570 --> 00:32:15,210
So working with ASN.1 really is not
as simple and as straightforward

423
00:32:15,210 --> 00:32:19,170
and as automatic as it should be. And you
end up with messages looking like this

424
00:32:19,170 --> 00:32:24,309
in Wireshark. So believe it or not,
the content, the useful content

425
00:32:24,309 --> 00:32:28,699
of this entire message
is 4 bytes here, the c0…

426
00:32:28,699 --> 00:32:37,670
*laughter and applause*

427
00:32:37,670 --> 00:32:42,179
…is the 4 bytes starting from c0, and
those people who have seen an IP address,

428
00:32:42,179 --> 00:32:48,170
an IPv4 address in a 192.168. address
range will recognize those bytes here

429
00:32:48,170 --> 00:32:52,429
at the end. So the c0 is 192. etc.
And in order to communicate

430
00:32:52,429 --> 00:32:56,450
this message actually, this is a message
that tells us to which IP address

431
00:32:56,450 --> 00:33:01,060
something has been bound to. In this case
it’s the GTP connection for communicating

432
00:33:01,060 --> 00:33:05,809
packet data. And you see all these
abstractions and encapsulations

433
00:33:05,809 --> 00:33:09,410
and the nested tree, so it’s…
it starts with… well, ok,

434
00:33:09,410 --> 00:33:12,880
this is an outcome. It is an outcome to
the Radio Access Bearer Assignment.

435
00:33:12,880 --> 00:33:16,860
“If you do not understand
it please reject it”.

436
00:33:16,860 --> 00:33:20,840
We have an Assignment Response. It
contains [consists] of a list of one item

437
00:33:20,840 --> 00:33:27,190
of protocol information elements. This
one item is a SetupOrModifiedList,

438
00:33:27,190 --> 00:33:30,929
which again has a criticality of ‘Ignore’.
If you don’t understand it…

439
00:33:30,929 --> 00:33:34,620
oh no sorry, here it says “If you don’t
understand it just ignore it.

440
00:33:34,620 --> 00:33:38,270
Don’t report an error”. It’s quite
interesting because you have a message

441
00:33:38,270 --> 00:33:42,110
that only contains one element and it
says, well, you should reject the message

442
00:33:42,110 --> 00:33:45,190
if you don’t understand it; but then the
information element says: “Oh, if you

443
00:33:45,190 --> 00:33:49,750
don’t understand it please
ignore it”. So, okay.

444
00:33:49,750 --> 00:33:53,590
Then inside the SetupOrModifiedList
we have one item

445
00:33:53,590 --> 00:33:57,880
which is a protocol IE
container with one item

446
00:33:57,880 --> 00:34:00,950
which has an item which is the
SetupOrModifiedItem, which is

447
00:34:00,950 --> 00:34:05,460
a Radio Access Bearer Modified
Item, which contains

448
00:34:05,460 --> 00:34:11,369
a Radio Access Bearer SetupOrModifiedItem
with a Radio Access Bearer ID of 1

449
00:34:11,369 --> 00:34:14,909
and a transport layer address of
this. And in case you’re wondering

450
00:34:14,909 --> 00:34:20,310
why the IP address has such
binary crap in front – it is

451
00:34:20,310 --> 00:34:25,510
because it’s too difficult to express
in ASN.1 that this is an IP address.

452
00:34:25,510 --> 00:34:29,020
You could not just define a type for an
IP address. That would be too simple.

453
00:34:29,020 --> 00:34:33,550
No, you need to refer from this
specification to another specification,

454
00:34:33,550 --> 00:34:40,460
another 3G specification,
which then refers to ITU-T X213

455
00:34:40,460 --> 00:34:45,719
which tells you how you can encode
any possible transport layer address

456
00:34:45,719 --> 00:34:50,570
in any possible network protocol on the
planet by using a hierarchical structure

457
00:34:50,570 --> 00:34:57,119
like OUI IDs or something like that. And
‘35’ means it’s an IETF allocated address.

458
00:34:57,119 --> 00:35:01,620
‘0001’ means it’s an IPv4 address and
then you actually have the payload.

459
00:35:01,620 --> 00:35:05,350
And you can see Wireshark is too
stupid to decode such brilliance!

460
00:35:05,350 --> 00:35:15,050
*laughter and applause*

461
00:35:15,050 --> 00:35:19,150
Yeah, so. Then it’s hard to find
example traces. You want to implement

462
00:35:19,150 --> 00:35:22,430
the protocol and you want to find some
example traces. This is a mail I …

463
00:35:22,430 --> 00:35:27,030
actually I was looking for this this
year, in 2015. I was googling

464
00:35:27,030 --> 00:35:32,450
for Iuh protocol traces. And what
did I find? My own e-mail from 2009

465
00:35:32,450 --> 00:35:37,440
where I was asking for protocol traces.
But nobody ever responded.

466
00:35:37,440 --> 00:35:40,950
So the situation is better today.
You can actually find, I think,

467
00:35:40,950 --> 00:35:46,770
2 or 3 public pcap files containing
each maybe a handful of messages

468
00:35:46,770 --> 00:35:51,270
on those interfaces. It’s really… it’s
odd, you know? These are protocols

469
00:35:51,270 --> 00:35:55,650
that are specified publicly. They’re used
in production. Billions of users are using

470
00:35:55,650 --> 00:36:01,000
these networks but nobody even has an
example protocol trace of those protocols.

471
00:36:01,000 --> 00:36:05,210
Okay, now we have a couple of
protocol traces. We understand

472
00:36:05,210 --> 00:36:09,470
the nesting level is deep. We are happy
that Wireshark decodes at least most of it,

473
00:36:09,470 --> 00:36:13,480
which by the way we have to thank
one particular Ericsson employee

474
00:36:13,480 --> 00:36:18,700
who is contributing those
dissectors to Wireshark.

475
00:36:18,700 --> 00:36:22,920
So then we need to basically set up
a tool chain to generate code

476
00:36:22,920 --> 00:36:29,030
from these ASN.1 syntaxes. So there is
an ASN.1 C compiler from Lev Walkins.

477
00:36:29,030 --> 00:36:32,930
It’s good for a lot of things and I’m
very happy it exists. But it lacks many

478
00:36:32,930 --> 00:36:36,030
if not most of the features that you
need in the Telecom world. That’s

479
00:36:36,030 --> 00:36:38,940
sort of unfortunate. There’s no
information object classes, there is

480
00:36:38,940 --> 00:36:43,500
no aligned PER support, there’s no
support for prefixing the type names.

481
00:36:43,500 --> 00:36:46,960
Because we have 3 different protocols, we
want to use them from one program.

482
00:36:46,960 --> 00:36:50,660
We need to prefix the type names because
of course each of those 3 protocols

483
00:36:50,660 --> 00:36:54,300
has a type called ‘protocol information
element container’. But of course

484
00:36:54,300 --> 00:36:57,260
it’s not the same protocol information
element container, there it said(?).

485
00:36:57,260 --> 00:37:02,150
You know, each of the protocols
has its own containers.

486
00:37:02,150 --> 00:37:07,290
So we had to add these pieces to the
asn1c, at least in a minimal way

487
00:37:07,290 --> 00:37:11,590
in order to use it. And unfortunately
I don’t know anyone, and I’m certainly

488
00:37:11,590 --> 00:37:15,189
no one who understands something
about compiler theory, so it’s

489
00:37:15,189 --> 00:37:21,100
a little bit challenging. Now,
alternatives to asn1c, well,

490
00:37:21,100 --> 00:37:25,030
the most complete tool kit you
can find for working with ASN.1

491
00:37:25,030 --> 00:37:30,310
exists in the Erlang OTP system.
I used this in the past

492
00:37:30,310 --> 00:37:36,490
for a lot of Osmocom projects,
but the fact is the C projects…

493
00:37:36,490 --> 00:37:40,050
there are other developers and people
that contribute. In the Erlang projects

494
00:37:40,050 --> 00:37:44,200
there is nobody that contributes except
from me. So I thought, well okay,

495
00:37:44,200 --> 00:37:48,450
it’s very nice to work with ASN.1 in
Erlang, but then if nobody contributes

496
00:37:48,450 --> 00:37:53,940
I’d rather go the difficult C way and then
have contributors in the project.

497
00:37:53,940 --> 00:37:58,010
Also of course in the Osmocom project
we’re mostly low-level C guys;

498
00:37:58,010 --> 00:38:04,460
and people are very wary of
virtual machines and the

499
00:38:04,460 --> 00:38:08,980
– at least perceived – bloat they
introduce. The third alternative is

500
00:38:08,980 --> 00:38:13,900
to use a proprietary ASN.1 compiler, and
in my day job I actually use such tools.

501
00:38:13,900 --> 00:38:18,230
But in the first sight you think,

502
00:38:18,230 --> 00:38:24,490
well, okay, so it’s a code compiler, it
compiles code, and copyright law says,

503
00:38:24,490 --> 00:38:28,020
well, code that was generated by
a machine is not copyrightable because

504
00:38:28,020 --> 00:38:33,260
the act of automatically compiling
code from one form into another form

505
00:38:33,260 --> 00:38:37,900
does not make this… that does not
create a copyrightable work as itself.

506
00:38:37,900 --> 00:38:42,350
So basically, you can take a proprietary
ASN.1 compiler, compile C code and then

507
00:38:42,350 --> 00:38:46,310
use the resulting C code in an open source
project without having any problems

508
00:38:46,310 --> 00:38:50,990
with the license of the ASN.1 compiler.
And that’s true, however

509
00:38:50,990 --> 00:38:54,450
all those compilers I know, and I think
I know all of them, they have

510
00:38:54,450 --> 00:38:59,991
a runtime library and that you only either
get as a binary library or you get it

511
00:38:59,991 --> 00:39:06,340
in source code that’s not available
under a free software compatible license.

512
00:39:06,340 --> 00:39:09,910
No option to do that. So we
have to stick with asn1c,

513
00:39:09,910 --> 00:39:14,470
which as I said I don’t want to complain
about, it’s a great project. It just

514
00:39:14,470 --> 00:39:17,450
doesn’t do all the things that we need.
But then, it was not written for us, so

515
00:39:17,450 --> 00:39:23,760
of course it doesn’t do everything
we need. Luckily, a research group

516
00:39:23,760 --> 00:39:29,300
at Eurecom, the European Communications
Research organization, has developed

517
00:39:29,300 --> 00:39:33,720
a patch for adding aligned PER support
to asn1c. Unfortunately it was

518
00:39:33,720 --> 00:39:37,900
against an old version because, well,
they probably don’t want to submit

519
00:39:37,900 --> 00:39:42,310
this main line (?) and they don’t care
about porting it and rebasing (?) it.

520
00:39:42,310 --> 00:39:47,290
I did that. It probably still needs some
clean-up before it can be submitted,

521
00:39:47,290 --> 00:39:52,880
but my goal is to have
this included in asn1c.

522
00:39:52,880 --> 00:39:56,960
And also we found quite a number
of bugs still in the code,

523
00:39:56,960 --> 00:40:01,460
so it’s in the process of being improved.
Now information object classes are hard,

524
00:40:01,460 --> 00:40:05,150
at least for me. Basically we skip that.

525
00:40:05,150 --> 00:40:10,570
I manually edit the ASN.1 syntax for not
using information object classes anymore,

526
00:40:10,570 --> 00:40:14,490
so I’m rewriting the ASN.1, that’s
supposed to be there to guarantee

527
00:40:14,490 --> 00:40:19,090
that the encoding is a… so it circumvents

528
00:40:19,090 --> 00:40:22,200
sort of the purpose. The idea is you take
the ASN.1 from the spec, you use it,

529
00:40:22,200 --> 00:40:26,060
you don’t modify it. But I’m modifying
it because, well, the tools we have

530
00:40:26,060 --> 00:40:30,630
are not good for what we want
to do. Type prefixing is done.

531
00:40:30,630 --> 00:40:35,190
Now we have the information
element containers. Eurecom has

532
00:40:35,190 --> 00:40:41,249
another idea about this.
They have a long Perl script.

533
00:40:41,249 --> 00:40:47,090
I recommend you not to look at it, it
consists of a neverending sequence

534
00:40:47,090 --> 00:40:53,060
of regular expressions, basically grep-ing
out certain parts of the ASN.1 syntax

535
00:40:53,060 --> 00:40:56,990
without really formally parsing it,
or lexing it, or tokenizing it;

536
00:40:56,990 --> 00:41:00,440
and then based on those regular
expressions generating C code that then

537
00:41:00,440 --> 00:41:04,940
you can use with asn1c and link
against it. And surprisingly it works,

538
00:41:04,940 --> 00:41:08,840
surprisingly good actually. We had to
teach it all the things that we needed

539
00:41:08,840 --> 00:41:13,780
in addition to that.
But really it works surprisingly.

540
00:41:13,780 --> 00:41:18,910
Now. Putting things together:
Copy and paste the ASN.1 syntax

541
00:41:18,910 --> 00:41:24,050
from the 3GPP DOC files. Because 3GPP
specs are published as PDF files

542
00:41:24,050 --> 00:41:28,130
and as Word documents, and you don’t
get the actual syntax as a text file.

543
00:41:28,130 --> 00:41:32,490
You have to copy and paste from each page,
make sure you don’t get intermixed

544
00:41:32,490 --> 00:41:37,660
like headlines or something like that.
Then you use the hacked-up, patched asn1c

545
00:41:37,660 --> 00:41:45,530
to generate C code. You have to modify it
to make a shared library of the runtime

546
00:41:45,530 --> 00:41:49,920
for the ASN.1 compiler because we have,
again, 3 syntaxes that we want to mix,

547
00:41:49,920 --> 00:41:54,349
and that doesn’t really work with how
asn1c works. We use asn1tostruct

548
00:41:54,349 --> 00:41:58,660
to remove this what I call the obfuscation
layer, these containers. We write

549
00:41:58,660 --> 00:42:03,540
some code to dispatch the messages,
and then finally, we see some messages.

550
00:42:03,540 --> 00:42:09,700
So we have those HNB register,
INITIAL_UE_MESSAGE and all these things.

551
00:42:09,700 --> 00:42:13,540
This is what you can now get from
osmo-iuh.git, the Git repository

552
00:42:13,540 --> 00:42:18,280
on the Osmocom server which
contains all this code.

553
00:42:18,280 --> 00:42:22,350
It takes a long time to compile,
because asn1c generates one C file

554
00:42:22,350 --> 00:42:26,690
and one header file for each type. And
they have lots of types in those specs.

555
00:42:26,690 --> 00:42:30,570
So you end up with like 300..400
C files and header files compiled

556
00:42:30,570 --> 00:42:38,440
into a 5 megabyte binary, and then finally
you want to get 4 bytes in a message.

557
00:42:38,440 --> 00:42:44,170
So well, where do we go from here?
We have a couple of other things to do.

558
00:42:44,170 --> 00:42:47,510
One interesting question is – and I’m
going to do a demo in a few minutes –

559
00:42:47,510 --> 00:42:51,630
is what kind of hardware can be used?
Well, the hardware that I currently use

560
00:42:51,630 --> 00:42:55,400
for this development is undisclosed
manufacturer, very expensive.

561
00:42:55,400 --> 00:43:00,990
It’s not actually a femtocell, it’s a real
cell, it costs several thousand Euros,

562
00:43:00,990 --> 00:43:05,310
not really suitable for hackers. However
many consumer grade femtocells

563
00:43:05,310 --> 00:43:09,210
have also this Iuh protocol with the
same stacking. The problem is

564
00:43:09,210 --> 00:43:15,050
they’re locked down, in a way that they
have certificates and connect over IPsec

565
00:43:15,050 --> 00:43:20,700
to the operator network etc. So if
somebody can break this IPsec layer

566
00:43:20,700 --> 00:43:24,780
and insert its own a certificate, or
disable the IPsec altogether then you can

567
00:43:24,780 --> 00:43:29,619
talk Iuh to the osmo-iuh and then you
can use that hardware. This is something

568
00:43:29,619 --> 00:43:33,030
that a couple of people have looked
at, and hopefully in the near future

569
00:43:33,030 --> 00:43:38,430
we will have 1 or 2 femtocells
that people can use inexpensively

570
00:43:38,430 --> 00:43:41,000
in order to use the software. At the
moment, I said, unfortunately

571
00:43:41,000 --> 00:43:48,010
it’s not possible. As a summary,
before I go into the demo

572
00:43:48,010 --> 00:43:53,620
of demonstrating it and you having
basically a look in the marvelous depth

573
00:43:53,620 --> 00:43:59,680
of the Wireshark decodes, Iuh is
conceptually very easy to understand.

574
00:43:59,680 --> 00:44:04,660
The lack of good ASN.1 tools is the
biggest problem in the free software world.

575
00:44:04,660 --> 00:44:09,450
You need to overcome these containers,
and in the end you spend 90% of your time

576
00:44:09,450 --> 00:44:13,380
in improving the tooling, fixing the
tooling and working around these

577
00:44:13,380 --> 00:44:18,869
layers of abstraction rather than
doing the actual functionality.

578
00:44:18,869 --> 00:44:22,960
We have started the work on the core
network components, the integration.

579
00:44:22,960 --> 00:44:27,210
I was hoping that I could do a full demo
with a call, or a full demo with actually

580
00:44:27,210 --> 00:44:32,200
having a data connection over this setup
that I have here, over the test setup.

581
00:44:32,200 --> 00:44:36,120
I’m almost there. The signalling,
everything gets established,

582
00:44:36,120 --> 00:44:39,910
the authentication works but then
somehow the data, the actual IP data

583
00:44:39,910 --> 00:44:45,250
doesn’t want to come through. And that
is under investigation, but I’m sure

584
00:44:45,250 --> 00:44:51,260
it will be available rather soon.
Now before we go for Q&A

585
00:44:51,260 --> 00:44:58,620
let me just do a quick demo and let me
show you how this looks at the moment.

586
00:44:58,620 --> 00:45:02,760
This is still a protocol trace

587
00:45:02,760 --> 00:45:07,510
basically that was running in the past.
I’m just going to leave this here

588
00:45:07,510 --> 00:45:11,240
at the left-hand side, I’m going to leave
the… on the right-hand side. So

589
00:45:11,240 --> 00:45:15,180
what we can see is basically
on the left-hand side

590
00:45:15,180 --> 00:45:19,711
we have the RUA encapsulated messages.
This is basically the Iuh interface

591
00:45:19,711 --> 00:45:23,940
between the HomeNodeB and the
HomeNodeB gateway. Then we have

592
00:45:23,940 --> 00:45:28,369
the osmo-iuh HomeNodeB gateway invisible
in between here, and that’s the program

593
00:45:28,369 --> 00:45:32,780
running in the background. And then the
other side is this protocol stacking here,

594
00:45:32,780 --> 00:45:38,680
where we see we have the SUA, this SCCP
User Adaption rather than the RUA

595
00:45:38,680 --> 00:45:42,130
on the left-hand side. The RANAP messages
are the same on left and right, it’s

596
00:45:42,130 --> 00:45:50,180
basically just converting. What I’m
going to start in the background is

597
00:45:50,180 --> 00:45:55,930
basically – this is the wrong window,
I thought I had prepared everything just…

598
00:45:55,930 --> 00:46:01,290
Yeah. Exactly. Good, that’s the one part,

599
00:46:01,290 --> 00:46:06,440
that’s the other part…
So I’m going to start the…

600
00:46:06,440 --> 00:46:08,970
I know the font is too small, you don’t
need to read that. I’m just going

601
00:46:08,970 --> 00:46:15,520
to tell you the… I can make it larger,
then we won’t see really a lot.

602
00:46:15,520 --> 00:46:24,530
What’s this? Why is it not…?

603
00:46:24,530 --> 00:46:31,110
“Cannot listen on… socket…”.
Now that’s the demo effect!

604
00:46:44,640 --> 00:46:49,970
Why on earth is it not binding?

605
00:46:49,970 --> 00:47:01,040
What a pity! Okay, that’s embarrassing.

606
00:47:01,040 --> 00:47:05,640
Then you get a larger font size!
And then let’s have a quick look.

607
00:47:05,640 --> 00:47:10,720
I’ll try it very quickly. So I’m trying
this, it cannot bind to the sockets.

608
00:47:10,720 --> 00:47:14,460
Probably my IP address has
disappeared on the laptop

609
00:47:14,460 --> 00:47:17,910
while I’ve been talking here and now
it wants to bind to an address

610
00:47:17,910 --> 00:47:28,150
that doesn’t exist anymore. And that
seems [to be] exactly what has happened.

611
00:47:28,150 --> 00:47:34,330
Now don’t shout your SUDO! (?)
*laughter*

612
00:47:34,330 --> 00:47:39,450
It will not like you. I can tell you.

613
00:47:39,450 --> 00:47:48,020
Yeah. Now this should do the trick.

614
00:47:48,020 --> 00:47:50,350
I’m starting this in Valgrind
because I’m still debugging, yeah…

615
00:47:50,350 --> 00:47:54,440
Now it’s actually running, okay. Now
we do the same on the other side,

616
00:47:54,440 --> 00:47:59,670
we go for a huge font size,
and I’m starting the HNB gateway.

617
00:47:59,670 --> 00:48:05,140
We see a yellow line, that a connection
has been established. So now

618
00:48:05,140 --> 00:48:10,960
we are waiting for the initial message
from the HomeNodeB to arrive.

619
00:48:10,960 --> 00:48:13,960
We should see it here at the bottom
of this trace. We should see

620
00:48:13,960 --> 00:48:18,900
a couple of Reset requests. Basically the
HomeNodeB this… the NodeB here

621
00:48:18,900 --> 00:48:24,670
is trying to reconnect all the time
to its HomeNodeB gateway.

622
00:48:24,670 --> 00:48:28,030
Of course there’s some backup… some
back off included and given that it was

623
00:48:28,030 --> 00:48:32,000
not connected for the first 40 minutes or
so it will take some time to reconnect

624
00:48:32,000 --> 00:48:36,060
to the SGSN and then I can have
the phone that I have here regist…

625
00:48:36,060 --> 00:48:59,210
*audio recording blanks out*

626
00:48:59,210 --> 00:49:32,190
*one minute of audio missing*

627
00:49:32,190 --> 00:49:36,450
Herald: …is there somebody somewhere
at a mike? Mike 2, please!

628
00:49:36,450 --> 00:49:42,250
Question: So if 3G is so annoying why
not skip it and go directly to LTE?

629
00:49:42,250 --> 00:49:46,930
LaForge: Well, there’s a
couple of reasons for that.

630
00:49:46,930 --> 00:49:50,550
First of all some people
really need it in terms of

631
00:49:50,550 --> 00:49:55,960
there’s an actual demand
for 3G small networks

632
00:49:55,960 --> 00:50:00,090
or 3G cells in applications where
it’s used. The second reason is

633
00:50:00,090 --> 00:50:05,660
it’s a relatively limited incremental
step because the Layer 3 protocols

634
00:50:05,660 --> 00:50:11,260
of GSM and UMTS are the same.
And that’s why basically we can use…

635
00:50:11,260 --> 00:50:15,320
reuse the call control and the mobility
management, all those parts from GSM,

636
00:50:15,320 --> 00:50:21,180
reuse them with 3G. I’m not saying we
shouldn’t do the same with LTE as well

637
00:50:21,180 --> 00:50:25,010
but there are actually quite a number of
projects already involved in that area.

638
00:50:25,010 --> 00:50:32,840
And LTE, well, to be frank, it’s so much
IP it’s not really telecom anymore.

639
00:50:32,840 --> 00:50:36,010
You know I’m always interested in
the more obscure things that people

640
00:50:36,010 --> 00:50:40,670
are not really looking so much at. IP,
I found IP boring when I stopped working

641
00:50:40,670 --> 00:50:44,030
on Netfilter in 2004 or so. IP, well
everyone knows about IP, that’s…

642
00:50:44,030 --> 00:50:47,740
you know, we need
something more interesting.

643
00:50:47,740 --> 00:50:51,890
Herald: Microphone 1 please!

644
00:50:51,890 --> 00:50:56,270
Question: So you say that you have
a lot of trouble parsing ASN.1.

645
00:50:56,270 --> 00:51:01,740
But if it’s always the same containers
can’t you simply have a static dump

646
00:51:01,740 --> 00:51:07,820
of the binary crap before and after that
stuff, and ignore the whole parsing part?

647
00:51:07,820 --> 00:51:15,180
LaForge: You probably could. But then,
how can I say, my code athletics

648
00:51:15,180 --> 00:51:21,760
demand better behavior from code I write
than just doing something like that. So

649
00:51:21,760 --> 00:51:29,420
yes, you could, probably, but I’d rather
have a more clean way of doing that.

650
00:51:29,420 --> 00:51:34,150
Herald: And continue on microphone 1!

651
00:51:34,150 --> 00:51:39,920
Question: You said that UMTS
or 3G is a toolbox for creating

652
00:51:39,920 --> 00:51:45,849
arbitrary telephony systems while
my knowledge tells me that GSM

653
00:51:45,849 --> 00:51:49,550
is a much more rigid standard,
but, if you could please elaborate

654
00:51:49,550 --> 00:51:57,560
on that concept of “arbitrary networks”!

655
00:51:57,560 --> 00:52:03,070
LaForge: Well, I could illustrate that
very much with a certain protocol trace.

656
00:52:03,070 --> 00:52:07,550
UMTS basically… when UMTS was specified
they didn’t know where the journey

657
00:52:07,550 --> 00:52:12,500
was going to. Basically, it was not clear
that the internet would be the thing

658
00:52:12,500 --> 00:52:16,340
that we know as of today. They didn’t
know that smartphones would exist.

659
00:52:16,340 --> 00:52:20,190
They didn’t know that IP data services are
the type of data services that people

660
00:52:20,190 --> 00:52:27,109
are interested in. Rather they were
thinking of… in generic terms.

661
00:52:27,109 --> 00:52:33,170
So it could have been that
we needed all X.25 over UMTS.

662
00:52:33,170 --> 00:52:38,109
It could be that, you know, people
wanted to do ATM over UMTS.

663
00:52:38,109 --> 00:52:42,060
It was not clear that circuit-switched
services would basically go downhill

664
00:52:42,060 --> 00:52:48,830
like they did meanwhile with
voice-over-IP telephony etc.

665
00:52:48,830 --> 00:52:53,670
It was not clear that modem calls or
actual video calls that exist in UMTS

666
00:52:53,670 --> 00:52:58,010
would not be the future. So it was very
unclear. And they tried to define something

667
00:52:58,010 --> 00:53:02,010
that’s as flexible as possible to do
anything that you could imagine.

668
00:53:02,010 --> 00:53:05,920
And if you look at the way how the layers
are structured and the fact that you have

669
00:53:05,920 --> 00:53:10,780
transport channels, and transport channel
bundles, and radio access bearers etc.,

670
00:53:10,780 --> 00:53:15,260
basically the structure. Even
only to transmit voice again

671
00:53:15,260 --> 00:53:21,230
you have to set up with AMR for all
the codecs you need to configure

672
00:53:21,230 --> 00:53:26,230
in the physical layer, I think,
for the 3 different bit classes

673
00:53:26,230 --> 00:53:30,910
10 different combinations. So you end
up with something like 30 parameters

674
00:53:30,910 --> 00:53:35,780
or 30 sets of parameters that you need
to communicate to the lower layers only

675
00:53:35,780 --> 00:53:40,150
to configure it for establishing a voice
channel. And then the transport channels,

676
00:53:40,150 --> 00:53:44,250
that where the bits are included, the
payload like how many bits fit in

677
00:53:44,250 --> 00:53:48,109
into one frame doesn’t match with your
codec bitrate because they didn’t know

678
00:53:48,109 --> 00:53:52,180
what codecs they would use. So it’s
really… it’s all arbitrary and with padding

679
00:53:52,180 --> 00:53:59,220
and universal. So it’s not like GSM.
GSM is very simple and straightforward.

680
00:53:59,220 --> 00:54:02,240
Herald: Okay, we have 5 minutes left
so we will have 2 quick questions

681
00:54:02,240 --> 00:54:04,510
from the internet because
everybody on the stream:

682
00:54:04,510 --> 00:54:07,820
you can actually ask questions
on the chat. Please!

683
00:54:07,820 --> 00:54:12,010
Signal Angel: Okay, thanks. We have 2
questions as you said. The first one is:

684
00:54:12,010 --> 00:54:15,480
if there would be interest in
implementing, you know, the whole stack

685
00:54:15,480 --> 00:54:21,570
in a safe and non-VM based language
if the tooling was good enough?

686
00:54:21,570 --> 00:54:25,850
*LaForge breathes out heavily*
*laughter*

687
00:54:25,850 --> 00:54:29,480
LaForge: Well, I mean I’ve… It depends
on… I don’t want to find Language Wars

688
00:54:29,480 --> 00:54:36,290
here. I would have been tempted to
do things in Erlang but then, I said,

689
00:54:36,290 --> 00:54:40,240
the question is who else
would have been tempted?

690
00:54:40,240 --> 00:54:44,140
I don’t think… I mean the point is what
we’re trying to do now is to basically

691
00:54:44,140 --> 00:54:50,680
use most of what we already have
with the least additional effort

692
00:54:50,680 --> 00:54:55,329
and I don’t think anyone will want
to start from scratch all over again.

693
00:54:55,329 --> 00:54:59,000
But if they do so I would be happy
to see a clean implementation,

694
00:54:59,000 --> 00:55:02,930
but I’m not so sure that will happen.

695
00:55:02,930 --> 00:55:06,890
Signal Angel: Okay, thanks. The second
question is: why don’t we just

696
00:55:06,890 --> 00:55:11,410
start over for a clean slate with hardware
and software and do a basically

697
00:55:11,410 --> 00:55:15,650
100% nerd and hacker
driven mobile networks?

698
00:55:15,650 --> 00:55:17,470
LaForge: Sorry, 100%…?

699
00:55:17,470 --> 00:55:21,470
Signal Angel: …nerd/hacker
driven networks.

700
00:55:21,470 --> 00:55:25,720
LaForge: Ah, well, I mean the point
of implementing all those specs is

701
00:55:25,720 --> 00:55:30,099
you want to use the existing
devices out there. You want to use

702
00:55:30,099 --> 00:55:33,500
the existing billions of mobile phones
that exist on the planet. And if you

703
00:55:33,500 --> 00:55:36,510
want to talk to them then you need
to implement those protocols

704
00:55:36,510 --> 00:55:40,610
and those systems that they implement.
If you want to start from something else

705
00:55:40,610 --> 00:55:45,480
and do things from scratch, well, yes,
you can do that. But then keep in mind

706
00:55:45,480 --> 00:55:49,520
that you will have very bulky end user
equipment with large like clusters

707
00:55:49,520 --> 00:55:54,750
of FPGAs and DSPs, draining batteries,
having fans inside. Because you

708
00:55:54,750 --> 00:55:59,099
will not be able to implement your system
in the same level of energy efficiency,

709
00:55:59,099 --> 00:56:04,900
in the same level of, you know, ASICs
and optimized silicon processes etc.

710
00:56:04,900 --> 00:56:10,660
like is the case for the
billions of existing devices.

711
00:56:10,660 --> 00:56:13,910
Herald: Okay, thank you, Harald Welte!

712
00:56:13,910 --> 00:56:17,480
LaForge: Yeah, thank you!
*applause*

713
00:56:17,480 --> 00:56:23,190
*postroll music*

714
00:56:23,190 --> 00:56:28,581
*Subtitles created by c3subtitles.de
in the year 2017. Join, and help us!*