 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 a recently gprs or Roaming between the different parts of the areas in the camp All of this started around seven years from now with the talk at the 25 c3 and a bunch of product projects emerge from that over the years But wait, there's more right now the 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 Five minutes ago 3g means that we will have hdspa and data services on our GSM networks And I'm very honored to introduce to you this evening Harald Welter Member of our chaos family for several years now known maybe from the kernel development I first read his name While debugging a chip car driver it that stated all bucks introduced by this guy over there So other people may know him from GP a lot relations org where they try to enforce the GPL So please welcome Harald Welter and stages yours 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 Implementation so the GSM network that we are running here at the event Or that we started to run seven years ago Started 16 years after GSM networks were run first in the public in Europe Public operators so we really really late And if you want to like to compare the status of open source mobile communications with open source operating system Then I would say you 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 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 you look a little bit at the timeline 2008 we had the talk about running your own GSM network with a huge Siemens space station weighing I think 28 kilograms Did my microphone? No, it works. Sorry weighing 28 kilograms and bulky old equipment not using TCP IP but using e1 lines and so on over the years We added more and more BTS model vendors that basically 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 Osmo sg sn open gg sn also the Osmo PCU project So we've been growing the stack downwards Also basically implementing the software inside such a BTS Which we call Osmo BTS There are some production deployments all spellings my mistake by the way as obviously so A production deployments in niche applications such as maritime markets So if today you're on a ferry or on a cruise ship and you use GSM services the probability that you're using Open BSC and associated projects in the background is a very strong. There are hundreds of vessels using our software today now then we Then we moved on the telephone side So we thought well, you know network site GSM is one thing but let's do the phone as well That was Osmo combi B 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 two or three months ago So again 15 16 years late compared to what happens in the proprietary world Okay, but this talk is not about edge which is 2.75 g 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 40 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 phi including the The layer 2 and so on. 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 use proprietary Base station hardware and we implement the higher level protocols and then if needed and if there's interest and contributions And so on 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 node B in 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. It's 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 many 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 They've been talks by Kevin Nico and Ravi Shankar in 2010 2011 about security There's been a recent presentation this year at blackhead in the United States called adventures in femto land those talks focus on basically While the security of the femtocell itself breaking into such a cell Rooting it owning it doing creative things and then from there for example attacking the mobile operator or Attacking the privacy of subscribers by using such a femtocell as a man in the middle platform for example, 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 Which is the telephone we have a radio interface called the uu interface we have actual base stations called node B 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 IUP S interfaces that interface the actual base stations with or sorry 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 or the radio access network and the core network on the other side of the slide So well, you could just get a note B and implement the protocol IUP this is what we did with GSM before we basically started here We only got the the actual BTS or node B and we implemented that protocol However, well and 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 It has three different classes of bits and each class of bits gets put into different UDP messages And then you get basically three flows of UDP messages and you need to synchronize and enter 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 signaling 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 It's an extremely obvious and self-explanatory slide, so I I leave it at this and say yeah, that's not what we want to do. So we we how can I say we Even though we don't like it We just use proprietary blocks blobs to to 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 naming 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 the circuit switched and packet switched circuit switch means telephony services and packet switch means data services and We're going to look at the the protocol stacking of those interfaces In the next couple of slides originally remember Well, basically maybe a good time to go back in history and in sort of history of mobile communications Which should be taught at every school I think including archaeology of protocols which No, honestly, honestly You need to do protocol archaeology 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 as and one syntax for map version one, which is still used today So it's yes, it sometimes you really need to do archaeology So anyway, not for this but any as a when UMTS was specified. This is the late 90s This is when the first comm 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 universal mobile telephony system the UMTS Which could be basically be the the grand unifying theory of mobile communications and It was spilled 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 classic protocol stacking and you look at the individual interfaces The uu is the radio interface iub is between the node B and the RNC But this is the IUP is 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 femto cells 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 femto cells that you can find on the market 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 3g pp language for an IP sec gateway And you have a home node be 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 home node be gateway, which is part of the software that we implemented You can see basically well You have ran up. This is the protocol that really is Sort of what we interested in the radio access network application part And ran up in order to implement that there's several other protocols underneath And on the femto cell which is called H node be the home node be because for femto cells a marketing term and Specs can never use marketing terms. So they have technical terms So the femto cell Basically encapsulates ran up into our UA the ran up a Ran up user. What was it? Sorry. I'm Adaptation. Yes, the ran up 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 protocols that's on the same layer as TCP or UDP, but has different properties and This RUA is implemented in the home node be gateway where it is replaced by M3 UA and sccp And then basically the same ran up message gets passed from left to right. So it's really You could think like a think of it like an IPv6 to IPv4 proxy If that's more an area that you're more familiar with okay, so yeah, I said there's some differences between an actual Regular old-fashioned UMTS base station like your public operator would use it and the home node be or femto cell that we like to use in this project At least initially and as that the main difference is that the RNC the radio network control 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 practical 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 femto cell in this case so the protocol stacking now looks a little bit like this we have the home node be and the The the home node be 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 osmo-com project we have implementations of those What we're missing is the home node be gateway and it's 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's RUA. There is the ran up protocol and The HNBAP protocol and 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 ran up 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 and 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 connection less 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 signaling 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 in you know If you look at this and you really expect like ops, you know, it's nothing It's like, you know you implement like five six message types and and that's it Well, there's a bit more details to that, but we'll get back later to this the home node be a Application no home node be 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 H&B is the home node be registration. We have registration request accept reject D registration. We have the same for mobile phones. We have some well more detailed transactions that I'm going to skip but also it's really very simple Conceptually, 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 ran app. That's the radio access network application part. This is where your actual Signaling 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. She would see encapsulated inside ran app And transported to the core network element also things like PDP context activation if you activate a data connection to a certain APN over a cellular protocols all this is encapsulated in The ran app layer Also the 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 I 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 while 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 rap assignment rap is the radio access bearer, which is basically a abstract notion of a Bearer able to transport communication. I mean if you come from classic telephony the bearer was well A analog voice channel if you go to ISD and the bearer is well, it's a 64 kilobit synchronous channel where you have a law U law inside and voice data or you have some HDLC or x75 or whatever Data inside in GSM. Well the bearer is typically voice Bearers with different voice codecs The same 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 signaling 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 as a seven interfaces think of the as a seven security talks And so on we've had here at CCC events a lot of the times This is a protocol that's very often used in a lot of different parts of telecom, but The problem is everywhere except 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 therefore none of the existing free software implementations implemented You can look to yate you can look to the leave Osmo sccp the library that we have in the Osmo com project You can look at the mobis sense mobis sense 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 Well once we have implemented all these protocols RUA sccp the RAN app the hnbap then we need to somehow Interface those protocols with the existing network elements that we have for GSM and They're sort of Several challenges in this area in the What people know as the open BSC project Actually the program that most people use is called Osmo and ITB 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 there's a 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 well the different protocols that I just mentioned and link them in on the SGSN side for the data services we need to Introduce some abstraction 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 that 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 M3 UA? 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 home node be gateway which basically passes ran up 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 M3 UA 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 Well go sort of in a compromise So what we're using here is yet another protocol called SUA the SCCP user adoption And that replaces those two layers and keeps things a little bit simpler from the implementation side Okay, 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 more six seven messages Not too many transactions no complex state machines Okay, now a lot of the more modern telecom protocols use ASN one 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 marshaling and demarshaling 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 one 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 Tell 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 bite this then there is a two-byte length field and then there is that and you need to implement that basically In your code based on the text trail Representation now for UMTS almost all the protocols and particularly these that we are looking 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 and we have sort of incompatible messages and whatnot That's true to some extent. Okay now What you need to know about ace and one 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 be our there is All kinds of encoding rules as even Jason encoding rules these days There's also XML encoding rules, but what's used here in these specs is called aligned packed encoding rules This is a particular encoding rule that was not is not supported by Any of the ASN one compilers that exist in open source that generates C code So we first had to teach the ASN one compiler this encoding rule And the second big problem is the ASN one syntax used in those protocol specs uses a construct called information object classes Which is sort of well, you know a an interesting way how to express or how to have yeah a different notation on how to construct those messages and how to construct operations that have like an Initiating risk quest and 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 the 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 one in these protocol specs ASN one being the abstract syntax notation is not abstract enough They need have another abstraction layer. So they use ASN one 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 two. No, you need to have a Pair that says well, this is a pair of two information elements Not sure why but somebody probably had his reasons for doing so now The point is basically you use the ASN one 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 need to 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 Matushka or you know these Dolls nested in each other or somebody sends you a large packet and so on Well, so to illustrate that if you've ever seen ASN one, this is a relatively simple example describing authentication tuples or triplets or Quinn tuples 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 is an authentication set list which contains of a choice of either a triplet or a quintuplet list Each of those lists either have a length from one to five And then you have basically a sequence which is sort of a struct or a record of the below items in those lists That is how is and it should look like and how it normally looks like now In ran up and these protocols they first as that they define these containers. They say well Oh, we have so it reminds me a bit of you know some mathematicians It's like oh well we define we have this and then we have that and therefore we can construct such a new Well structure and whatnot. So basically they define first a container for protocol information Elements protocol IE's and then 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 so and the value is an any type Which means there is another as and one syntax in that value that you then need to parse So you need to do this two steps in the code You first unwrap the containers and then you you decode what is inside the containers So working with ASN one really is not as simple and is 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 four bytes here the C0 Is The four 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 and so on 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 like starts with well, okay 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 of a list of one item of protocol information elements this one item is a setup or modified list 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 setup or modified list We have one item which is a protocol ID container IE container with one item Which has an item which is the setup of modified item, which is a radio access bearer modified item Which contains a radio access bearer set up a modified item with a radio access bearer ID of one 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 as and one 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 it ut x 213 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 ITF allocated address 001 means it's an IPv4 address and then you actually have the payload and you can see why a shark is too stupid to decode such brilliance Yeah, so Then it's hard to find example traces you want to implement the protocol and you want to find some example traces So this is a male. 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 email 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 two or three public p-cap files containing each maybe a handful of messages of those 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 wire shark decodes at least most of it Which by the way, we have to thank one particular Ericsson employee who is contributing those dissectors to wire shark and Yeah, so then we need to basically set up a toolchain to generate code for these from these as and once in Texas So there is an as and once see a compiler from Lef Vulcan It's good for a lot of things and I'm very happy it exists But it lacks money 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 PR support There's no support for prefixing the type names because we have three different protocols We want to use them from one program We need to prefix the type names because of course each of those three protocols has a type called protocol information element container But of course, it's not the same protocol information element container there is and you know each of the protocols has its own containers Yeah, so We had to add these pieces to the as and once see 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 as and one see well the the most complete toolkit you can find for working with as and one exists in the Erlang OTP system Well, I used this in the past for a lot of Osmo-com projects But well the fact is the C projects There are other developers and people that contribute and the Erlang projects. There is nobody that contributes except from me So I thought well, okay, it's very nice to work with as and one in Erlang But then if nobody contributes, I'd rather go the difficult see way and then have contributors in the project Also, of course in the Osmo-com project. We're mostly low-level C guys and people are very how can I say wary of virtual machines and and the at least perceived bloat they introduce The third alternative is to use a proprietary as and one compiler and in my day job. I actually use such tools, but Well in the first time on the first site you think well, okay, so it's a code compiler it compiles code and The 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 in as itself So basically you can take a proprietary as and one 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 as and one compiler 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 in as a binary library or You get it in source code. That's not available under a free software compatible license. So Well, no option to do that So we have to stick with as and one C Which as I said, I don't want to complain about it. It's a great project It's 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 so, okay, luckily a research group at a urecom the European Communications research Organization has developed a patch for adding a line PR support to as and one C 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 and rebasing it. I did that It probably still needs some cleanup before it can be submitted But my goal is to have this excuse me to have this included in as and one C And also we found quite a number of bucks still in the in the code So it's it's in in the process of being improved now information object classes are hard at least for me Basically, we skip that I manually added the as and one syntax for not using Information object classes anymore. So I'm rewriting the as and one that's supposed to be there to guarantee that the encoding is a Well, so circumference sort of the purpose the idea is you take the as and one from the spec 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 refixing is done now. We have the information element containers Urecom has another idea about this. They have a long Perl script. I recommend you not to look at it. It's It consists of a never-ending sequence of regular expressions Basically graphing out certain parts of the as and one 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 as and one C 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's it it works surprisingly now Putting the things together Copy and paste the as and one syntax from the 3gbp.doc files because 3gbp 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 as and one C to generate C code We you have to modify it to make a shared library of the the runtime for the as and one compiler Because we have against recent taxes that we want to mix and that doesn't really work with how as and one C works We use as and one struct 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 h&p register Initial UE message and all these things. This is what you can now get from osmo ioh.git It's a git repository on the osmo comm server which contains all this code It takes a long time to compile because as and one C 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 megabit megabyte binary and then finally you want to get four 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 we use? Well the hardware that I currently use for this development is undisclosed manufacturer very expensive It's not actually a femto cell. It's a real cell Costs several thousand euros not really suitable for hackers. However Many consumer great femto cells have also this ioh 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 and so on so if somebody can break This ipsec layer and insert his own certificate or disable the ipsec all together Then you can talk ioh to the osmo ioh 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 one or two femto cells that people can use Inexpensively in order to use the software at the moment as that unfortunately. It's not possible so well as a summary before I go into the demo of demonstrating it and you having Basically a look in in the marvelous depth of the wire shark decodes And ioh is conceptually very easy to understand the lack of good as and one tools is the biggest problem in the free software world You need to overcome these containers and in the end you spend 90% on the tire of your time in improving the tooling fixing the tooling and Working around these level layers of abstraction rather than doing the actual functionality We have started the work on the Cornetwork 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 the setup that I have here over the test setup. I'm almost there The signaling 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. Okay, so 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 Okay, this is still a protocol trace. I'm Basically that was running in the past I'm just going to leave this here on 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 I UH interface between the home node B and the home node B gateway Then we have the Osmo I UH home node B gateway invisible in between here 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 adoption rather than the RUA on the left-hand side The ran up messages are the same on left and right is basically just converting What I'm going to start in the background is Is basically This is the wrong window. I I thought I had prepared everything just yeah, exactly good. That's the one part That's the other part. Yeah, 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 The I can make it larger, but then we won't see really a lot. What's this? Why is it not? Cannot listen on So good 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 does it cannot bind to the socket. It's 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 exactly what has happened Don't shout you pseudo It will not like you. I can tell you Yeah Okay, now 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 H&B gateway. We see a yellow line that a connection has been established. So now We are waiting for the initial message from the From the home node B to arrive We should see it here at the bottom of this trace We should see a couple of reset requests basically the home not be this other the the not be here is Trying to reconnect all the time to its home not be gateway Of course, there's some backup some back off included and given that it was not connected for the fast 40 minutes or so it will take some time to reconnect to the SDSN and then I can have the phone that I have here Is there somebody somewhere at the mic mic to please So if 3g is so annoying why not skip it and go directly to LTE? well As a couple of reasons for that first of all some people really need it in terms of there's an actual demand for for 3g Small networks of 3g cells in applications where it's used the second reason is it's Relatively limited incremental step because the layer three 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 they 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 So You know, I've 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 that filter in 2004 I said IP while everyone knows about IP. That's you know, we need something more interesting Okay Microphone one, please So you say that you have a lot of trouble passing as and one 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? You probably could but then how can I say my code aesthetics? Demand How can I say demand better behavior from code? I've right then just doing something like that So yes, you could probably but I'd rather have a more clean way of doing that And continue on microphone one. You said that UNTS 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 Okay Well, I could illustrate that very much with a certain protocol trace and okay 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 20 Sorry x 25 over over a UMTS It could be that you know people wanted to do ATM over UMTS It was not clear that circuits which services would basically go downhill like they did Meanwhile with I voice over IP telephony and so on and 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 try 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 and so on basically the structure and 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 three different bit classes ten 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 into one frame doesn't match with your codec bit rate 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 It's not like GSM GSM is very simple and straightforward Okay, we have five minutes left So we will have two quick questions from the internet because everybody on the stream you can actually ask questions on the chat Please okay. Thanks. Um, we have two questions that you said the first one is if there would be interest in Implementing, you know the whole stack in a safer non-vm based language if the tooling was good enough Well, I mean I it depends on I don't want to find language wars here I would have been tempted to do things in Erlang But then as that the the question is who else would have been tempted And 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 Okay, thanks, and the second question is Why don't we just start over from a clean slate with hardware and software and do a basically a hundred percent nerd and hacker driven mobile networks Sorry 100% nerd slash hacker driven networks. 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 ESPs Draining batteries having fans inside because you will not be able to implement your system in the same level of energy efficiency and the same level of you know asics and and optimized silicon processes and so on like Is the case for the billions of existing devices? Okay, thank you. All right, Walter. Yeah, thank you