 So, let's start again at a little bit of a distance. Yeah, somebody wants to wake up. So, what is this talk about? It's about implementing, well implementing not in the sense of implementing software, but using software to create a system to run GSM network. GPRS will be covered in a follow-up talk by Daniel later on as free and open-source software using the Osmo-com components. Some people also call it applied protocol archaeology, which I don't mind, and we're doing all of this in Linux and user space. So, as opposed to the TCP IP stack you use on the internet, which runs inside the kernel, all the protocol stack that we are talking about today all runs in user space. There's nothing related to the operating system of the kernel. You can, of course, also run this not on Linux. I mean, you can run Osmo-com on FreeBSD or other Unix-like operating systems. Some people also have been running it on Windows. I'm not sure what's the status of that. Haven't heard about it for quite some time. Yeah, and also basically the kind of mindset or the point of view is, well, if you want to run your own private internet-style network, let's say some IP network and some people call it intranet, I'm not sure if that is still a buzzword that people recognize today. And, well, you just use some off-the-shelf hardware, an X86 PC, or whatever architecture you fancy. Ethernet cards are mostly built-in these days. You use any random Linux distribution of FreeBSD. You configure the network stack. You have all kinds of fancy features. You run your web server. You run a web browser and so on. And then you have basically your own setup with internet technologies. And that's really very easy to do. You can do whatever modifications you want. You can do whatever optimization you want. You can hack the code. You can read the code. You can do, basically, you have no restrictions. And if you wanted to do that with cellular telephony before Osmo-com, you had basically to go to one of the large equipment suppliers and spend quite some time to convince them that you are a customer that actually is eligible of buying something from them. And then you have to spend a large amount of money and you end up with lots of black boxes that you cannot really hack or understand in detail. And that's really something that I was quite surprised when I first looked into this. I grew up with free software and the internet. So I know a different world. And now the question is why didn't we have cellular free software? Despite the fact that all the specifications are public. So what many people don't know in this room, maybe they do, but a lot of people who are not familiar with it is they always think, oh, but all the specifications are closed and you can't even get the standards and so on. It's not the case. They're all public and you can all read them. Just a couple of hundred, no, a couple of thousand documents each up to a couple of hundred pages. But if you enjoy some interesting literature in the bathtub like I do, then I can very strongly recommend reading three GPP specifications. It's quite entertaining at times. Yeah, so basically why do we have this? I think the classic circuit switch telephony versus BVS community that lived on in this world. We have the BVS community that has a lot of similarity with the internet community. And we have the classic telecom community with circuit switch and all this history of ISO, OSI versus TCP IP and so on. Okay, just skipping through those slides. So basically we did some work on I already mentioned in the previous introduction. So let's look at classic GSM architecture. We have this nice drawing from Kevin in the audience that everyone uses now these days. The old one was really ugly on Wikipedia. So thanks for him. He's capable of doing nice artwork. He also did the OsmoCom logo, by the way. Yeah, so this is the classic GSM architecture as it exists. It has lots and lots and lots of elements. You have a distributed network. And what's important to understand if you have no exposure to this before is that there's not one protocol stack, but a separate protocol stack on each of the interfaces between two elements. So the protocol stack on the radio interface on UM is a completely different protocol stack. You see here on the A-vis, then you see here on the A interface, then you see on other interfaces. So it's actually every interface you start to look at. Maybe some upper layers are identical, but the lower layers are definitely each time separate and different. And there's no end-to-end connectivity. It's not like an IP network where you have relatively simple routers that pass packets from left to right. It's a really completely different architecture. The intelligence is in the network itself in all these elements and not on the edge. So what do we have? We have the mobile station MS. It's not Microsoft. We have the BTS, the base transceiver station, which consists of TRXs, transceivers, and transceivers consist of time slots, TSSs. We also have a BSC, a base station controller, and many other nice acronyms. The mobile switching center, the MSC, the HRR, the home location register, the SMSC. So these are all the key elements that we can see here. And basically when we started with OpenBSC, we had a phone, we had the base station from eBay, and basically we had to implement whatever minimum is necessary on the entire right-hand side to get this to work. We did not implement all those interfaces with all their different protocol stacks. Well, why not? Because it's a lot of work and our goal was to have something working in a feasible amount of time. And today now we are moving to introducing more and more of those interfaces. And we will talk about this in the roadmap and in the 3G talk later on. So we created basically a world that looks like this. You might have seen this in the Wiki before. It's a bit small for the audience. I'm sorry for that. We look at simplified diagrams right now. All the blue stuff is third-party proprietary things that you can integrate with the stack and all the white parts are the Osmo-com components or other open-source components such as Linux call router here in this example. So this is basically where we are today and the individual elements. So since I don't like to draw drawings, I use dotty to generate graphs. That's much quicker and much easier. That's bearable. I'm not good with slides, my apologies. So we have mobile stations that connect to BTSs. We have BTSs that connect to BSC. We have the BSC connecting to the MSC and then we have other elements later on like the home location register. That's the classic architecture. Now in Osmo-com, if you run the network in the box, we simplify this significantly. So basically, we take all those right-hand side components from the BSC and upwards and we call it the Osmo-NITB, the network in the box, which then gives us this simple diagram, the most simple one. You have one phone talking to one BTS, talking to one network in the box. And that's basically what we need to set up in order to run our own GSM network, the minimal network possible. Of course, you can have multiple BTSs and so on and scale out, but that's the most simple setup that you can imagine. So the question is, what kind of BTS do I use? Because the phone, well, most people have a phone that supports GSM. If they're not from Japan maybe, then GSM is basically still in all of the phones. So that people have. The network in the box software is open source software, but what do we do about the BTS in the middle? There's going to be a separate talk about different supported BTS hardware from the Osmo-COM point of view that Alexander and I are going to present about later on. So I'll postpone until that. You can either use a proprietary existing BTS like Ericsson or Siemens, like we did initially, or by now we also have Osmo-BTS and Osmo-TRX, so we can also run that part as open source software. But there's many different flavors and versions for the sake of simplicity and because it's the device I'm most familiar with, I use a Sysmo-BTS here, but you can do this with any other BTS as well. So now an Sysmo-BTS internally uses Osmo-BTS, which is again one of the Osmo-COM open source projects. It talks a protocol called ABIS over IP towards the network in the box and Osmo-BTS comes in different flavors for different hardware. In our case, on the Sysmo-BTS, we use the Osmo-BTS Sysmo flavor of the software. The BTS itself has normally two interfaces. It has the radio interface, the UM interface, that's your antenna interface, towards the phones, and it has the ABIS interface towards the wired backhaul. Of course, it could be wireless as well, but according to specification, it is wired and everything else you do is basically your own interpretation towards the base station controller. And now with today, I mean, in the times of actual hardware implementations of these devices, that was easy to understand, but with today's flexible and very software-defined architecture, this is of course no longer actually true, because the hardware might just be some network-connected SDR that has an Ethernet interface, so the actual device that exposes the radio interface does not have an ABIS interface, but it has an Ethernet over which samples are communicated, so it's like a radio head. Or you might have a situation where even the BTS, the BSC, or even the network in the box run on the same board, so you don't have this ABIS interface exposed, but the ABIS interface is just internally. I have a couple of diagrams to illustrate that to make it clear the square boxes are hardware, the, well, not round, but whatever bubble-shaped boxes are software components. So we have a couple of phones connected over a radio interface to a physical-layer software which communicates over certain message queues with Osmo BTS. The lower part in dashes is for GPRS. I'm not covering this in this talk, I just thought I'd put it in the slide as well. And basically you can run in the square box of the Osmo BTS, you can run the physical-layer and Osmo BTS, so you get the ABIS over IP interface here, and then you have another physical box, your Linux PC and my laptop here in this case, which runs the network in the box software. And you can also run that and then you don't have an ABIS interface if you put all of the components right, the software and run it right inside the BTS because it has a Linux operating system in there and you can just run all of the software inside. So then really your network comes down to the phones and one device and you don't have all the other interfaces exposed. Nevertheless, they exist in the software, you just speak them over the loopback interface. So why am I telling you all this? Because in such a configuration, if you want to do a protocol trace, you then for example need to do a protocol trace on the loopback device inside the BTS, which some people may find a bit, well, unobvious, let's say. So these are the configurations that you can run. What we will run now here in this talk is the upper configuration. So basically we have Osmo BTS software inside the BTS, it looks like a classic BTS, has an ABIS interface and then we run the network in the box on the laptop. If you look at this for, let's say, a USRP SDR-based system, just in comparison, if it's not a Sysmo BTS, right, then you have the mobile stations connecting over the radio interface to the USRP. In this case, it's a USB attached SDR, so you have a USB interface that goes into a Linux PC where you run the Osmo TRX software, which is the physical layer, which then connects to Osmo BTS. Here, actually over UDP, I marked it here, but not up there, sorry for that. So there's UDP packets over loopback device going into Osmo BTS, and then again you have the ABIS interface going into another PC, which runs your network in the box system, for example. Or of course also you can run all of the stuff in one device, but then you still have the USRP over USP attached to one PC, which runs all the software components inside. And again, you have those internal protocols over the loopback interface that might be interesting to look at, and also that you need to configure, because of course if all those components here talk over IP with each other, then you need to make sure that they connect to the right IP address, or that they bind to the right IP address, and so on. So that's why I illustrate this outline, basically. And on the IP layer, what we see is what's called ABIS over IP. In this example, it runs inside TCP. So you see TCP connections on part 3002 and 3003 at this point, between those two elements, in the all-in-one solution where you run everything on one device. The voice data. So in TCP, you only have the signaling traffic. The voice data is carried in RTP inside UDP. RTP is a real-time transfer protocol, which is also used in VoIP and many other applications where you transport voice streams over IP. And this is just the same on the ABIS over IP implementation that we use here. Of course, none of what I say on this slide applies if you use a classic E1-based BTS from Siemens or Ericsson or something like that. But this is the Osmo-BTS case where we have IP-based interfaces. So what do we need to configure now? Actually, to get our network. We know with the setup that we have here all we need to do is basically have this. We already have this device that runs the Osmo-BTS software. We have the NITB. So what do we need to configure to get this going? We need to make sure that the BTS somehow connects to the Linux PC, to the network in the box there, and we need to make sure that the network in the box software runs on the PC. And then after that is the case, we need to make sure that phones or SIM cards inside phones are actually authorized to join the vertical network that they can register on the network. So these are the basic steps we need to perform. And so how do we configure this software? All the native Osmo-Com software. Talk about what is native and what not, but all the software that was originally created inside this Osmo-Com cellular infrastructure universe share a common architecture that is defined by a set of libraries that we use from all the programs. And these are called Live Osmo Core, Live Osmo GSM, Live Osmo VTY, Live Osmo Avis, Live Osmo NetIF, and there's more and more of them. And part of what they provide is the configuration handling. And this is done by an interactive configuration using a command line interface similar to what people might have seen in Cisco or other routers before, where you basically are, you telnet on a console and then you have tap completion on a command line interface to enter commands, both for introspection of the state as well as for actually changing or creating configuration in there. In the end, what you enter there in the command line interface can be stored to the configuration file. So this is a bit unknown to people who have not worked with this type of interface before. Normally, or in many cases, you would expect you write a config file by hand and then you start the process and the process only reads it, but here it is bidirectional. So actually, you start the program, it reads the config file and uses the data in the config file to operate, but then you can telnet into the system at runtime and modify those parameters and then save them again back to the config file after you've done your configuration changes. You can of course also manually edit it, but that's not exactly recommended unless you know what you're doing exactly because you don't really have syntax validation at the point. If you do the editing through the telnet interface, then the system only accepts valid parsable configuration commands and if you make a mistake or a typo or something, it will immediately reject it at that point. If you just edit the config file, you will notice at the next restart it cannot be very obvious which of the 15 changes you made has now caused the syntax error at this point. So if possible, the recommended procedure is to use the manual edit, but of course let's say if you run a larger network and you have some configuration management with templates that generates those config files using text templates and some variable substitution and so on, you can do that just as well. You just have to know how exactly the syntax looks like. So this configuration format or method is used both for the Osmo BTS software and the Osmo NITB software in this case. In this case, as I said, the Osmo BTS runs in this small black box here, which is the Osmo BTS 1002. We can access that via serial line or via SSH over the Ethernet, which is the yellow cable here on the desk. And then we can edit the configuration file by hand or use the BTY as described on the next slide. And the configuration file that we need to do, the most minimal configuration file we need to put on the BTS, really looks like this. So we see this indentation here. Basically it's a hierarchical tree-like structure. You don't see it from the simple example, it goes deeper into a tree by indent levels, a little bit like Python syntax. So you have to configure the BTS zero. We start to count by zero because we are computer scientists or IT guys. So the first BTS is zero, not one. The band is DCS-1800 is just the name for the 1800 megahertz band in GSM. Why do we need to specify the band here? Isn't that obvious from the hardware and so on? Well, the creators of the ABIS protocol were not how can I say not helpful enough in this respect. And also the problem is that the channel numbers of GSM are not not unique. So if you say ARFCN 512, it has a different meaning whether you're in 850 megahertz band or 900 megahertz band. So the channel number itself is not sufficient information to say or to determine the frequency. So you can set the band here. You set the IP access unit ID just the next slide, what that is and why we need to put it there and we specify something called the OML remote IP. And that's now in this example the IP address of my laptop which will be running the NITP the network in the box software. So the BTS will then establish these TCP connections to this IP address and follow up with further configuration. That's actually the note that is slightly cut off here at the bottom of the slide. All the other configuration is as per GSM architecture is downloaded from the base station controller into the BTS. The idea is that you do not have a lot if possible actually no configuration on the BTS. The BTS are distributed over the country and all the configuration is installed only at run time when the connection between BTS and BSE is established. So you can centrally manage the configuration and don't have distributed configuration all around. Also when you swap equipment you don't really need to change more than to set these two parameters and then all the configuration again gets downloaded from the BSE into the BTS based on these addresses that are specified. So what's the unit ID? Well the unit ID first of all it consists out of three parts side number, a BTS number and a transceiver number. So in the config file why do we specify only two? Well because the transceiver number is more or less logical. If I have one transceiver the first one is TRX0. If I have two transceivers then I have TRX0 and TRX1. So I don't need to say the transceiver number I only need to say the side number which is 1801 in this case and the BTS number which is 0 in this case. I can use any arbitrary numbers there as long as I think 16 bit or something like that so arbitrary within that range it doesn't matter it's just a key by which the BSE looks up the configuration when the BTS connects. For example in this scenario three BTSs with different unit IDs they have different source IP addresses but then maybe you have network address translation in between and then you connect to the BSE. So using the source IP address to identify which BTS is connecting right now is not a good idea because it might be translated in between. So that's why there is a unit ID and that unit ID is the lookup key when the BTS is connected to the BSE or the network in the box and then a corresponding configuration section is searched using this lookup key and then this configuration is downloaded over what's called the organization and maintenance link protocol into the BTS. Okay, so just to recapitulate this is all we need to do on the BTS and then on the network in the box well we first need the software itself. It's in theory just the usual like you build any source code from free software projects that use auto tools so you check out your Git tree you do your auto reconfigure, configure, make install but then in reality there are lots of library dependencies we try to have almost no external dependencies but of course we have lots of our own libraries and most people who want to use the software they are not developers so what we have available for I think a year now are nightly packages available for Debian 8 and 2 Ubuntu flavors so if you are not a developer and you do not want to go all that deep into the like building the code yourself you can use those Debian or Ubuntu packages, install them and then basically just use the software like any other software from a package feed in terms of requirements there is not really any needs to be well for the packages it needs to be Linux otherwise you can also use if you build from source you can also do it on other operating systems and the resource requirements are extremely limited for minimal network so that's actually why we can run all of this if we want to also and this is more BTS I mean this device has a 405 megahertz ARM core with almost no cache and 128 megabytes of RAM so this is what you can run the entire system not only for GSM but also for GPR as an edge on and so the resource requirements are relatively limited I wouldn't claim that the code is written in an efficient way it's just written or the architecture is very much like what I have seen or I have been used to when I was doing this kernel work and if you do that kind of low level development the code typically ends up to be quite small and resource friendly so what do we need to configure well there's a little bit more we need to configure at the network in the box we need not only to configure the parameters of the GSM network itself but also the parameters of the BTS because they get downloaded so we start with the core network configuration we have to configure the network country code and the mobile network code well yeah this typo yeah this is why you shouldn't edit it from hand so this is not a short name but a short name of course well but then it doesn't align anymore the authentication policy the yeah sorry for that we'll just log in we'll just look at the config files together the actual ones I just want to go through the theory so the network name is a name a human readable name that gets transmitted to the phone to identify the network beware that this name is only transmitted after the phone has registered to the network so if you do a network scan you will not see a name that is sent here but you will see a name that the phone generates based on tables that are compiled into the firmware of the phone and or tables that are stored on the SIM card of the phone so the string name is only used after successful registration you have to use mobile country code network code maybe just very quickly the mobile country codes they are assigned by the ITU there is a table that tells you that 262 is Germany for example and the mobile network codes are allocated by the respective national regulatory authority one so if you had 262 is Germany and 02 inside Germany would be Vodafone so 26202 is basically the Vodafone network here in Germany as an example there's also a code for testing one and one is allocated for testing so if you run some lab type setup it's one idea to run on MCC and MNC1 there might be regulatory requirements that tell you what to use so we don't use encryption in this network so we say encryption A50 A0 means off in this case and auth policy closed means we only accept phones that are registered so basically we are using a whitelist model all phones normally cannot register to our network only those phones which we explicitly permitted in whitelist which is basically our HLR can join the network this is the only safe configuration if you don't want to interfere with other networks if there are any other networks where you are so then we need to configure parameters of the BTS BTS0 again well if we only have one BTS in this network and zero is the first one the type of the BTS which for historical reasons if you use Osmo BTS it's always sysmo BTS which is a misnomer we're cleaning this up slowly but anyway in this case it's actually correct because I use the sysmo BTS again the band in which the the BTS is to operate the maximum power permitted by phones to use in the uplink so basically this is the I'm configuring the power of the phone not of the BTS with this line and the maximum permitted power of the phone using this if you constrain this you can constrain the transmit power of the phone if you set this to lower values which might be interesting again in lab type setups where you want to limit reduce interference with other networks another interesting setting is the periodic location update a setting which basically defines how often the phones are instructed to re-register to the network 6 minute is the unit here so 6 minutes is the lowest possible interval so again if you just want to get going and want to basically well first some first testing with the network in the box this is a very interesting setting because the phones will keep registering every often so you actually see some activity because if you set this to infinite or to like I don't know how many hours maybe you don't see so much traffic on your BTS the IPX's unit ID well that's again the unit ID you see 18010 the same that we configured on the BTS side in the in this example unit ID 18010 and then you can set things like the codec support what kind of voice codecs you support in this configuration and there's many many many other commands but these are sort of the interesting ones what we need to configure also and now you see the tree structure I folded in basically the other parts here so then inside BTS we have a transceiver called TRX0 this is a single transceiver BTS so there is only TRX0 then we configure the absolute radio frequency channel number the ARFCN that's a GSM standard language for the frequency on which you transmit you don't enter frequencies but use channel numbers and then some other configuration what's important is this setting the max power red the maximum power reduction which is what many people struggle with slightly it's not something that we came up with it's part of the GSM specifications so the idea is a given hardware has something called a nominal transmit power this is the maximum output power that a given BTS supports so in this case it's an indoor sysmo BTS 1002 it has 23 dbm maximum transmit power that's the nominal transmit power and here you configure the amount of reduction from that maximum transmit power you want to have so basically if you configure 0 it will be 23 minus 0 equals 23 dbm if you configure 20 here then it will be 23 minus 20 equals 3 dbm so that's inverse basically so you don't configure how much you want to transmit but how much you want to reduce attenuate the transmission compared to the maximum capability of the device in this case it's full basically 0 means full transmit power and then GSM has time slots I didn't go into details about this but this is really fundamental GSM knowledge you have 8 time slots on every transceiver so they're from 0 to 7 I left out some in the middle and you have to configure what kind of channels you want to use on the time slots in this example the most time slot will have a combination of common control channel and slow dedicated control channels there are several different combinations that you can configure there it depends on your use case what you need and how to set them this is basically network planning part but for simple testing you can just use an example config file that we have in the examples folder in the source code of each of the osmo-com projects where you can just copy the example file and then do modifications of those things that you want to modify but the others you can just leave if you don't understand the details at that point here in this example we configure one as PDCH that is for GPRS which Daniel will cover soon so we're setting all this up and before I go on with registering a phone let's actually have a look at how this looks like in the files if I configure this here I hope the font size is large enough to be readable even in the back if I I get some nods from back there okay so what I'm going to do I'm going to SSH into the let's try it like this yeah I have a headset here but I don't like headset so much so come on actually we have some microphone stands okay so I have another shell window prepared here so I'm going to SSH to 192.168. no .100.80 which is my bts yeah I want to be root there there's no other user yes that's fine so I'm on the root shell of the bts now and sorry just have to do this yeah okay so here you see it's a small arm core whatever that's the actual device oops it's a small bts so what what we need to do is type correct and we want to look at this etc osmo com osmo bts let's open it in vi osmo bts.config file so we can already see at the beginning it says this was saved from the vty so this was stored from actually interacting with it then we have a large block that I didn't talk about in my slides about logging this is just you configured the log levels what kind of log information you want this is just some it relates to the way how we configure it and this is really the configuration you can see it's actually I'm not lying this is the end of the file at the bottom I can scroll this up for you guys but this is really ah yeah actually there is yeah well we would have found that out I thought I had fixed this this morning but okay okay so this is the basically all there is in the configuration right the band the unit id and the remote ip address so I'm deleting all the lines that I added at the bottom now so this is the config file that we have on the bts side that's really all so now I'm switching I'm switching over to the the laptop side so what I'm what I have I'm here in the inside the source code of OpenBSC but if you install the program in your system of course you don't need to do this from a specific directory and here's the OpenBSC config file the file is always called openbsc.config um whether it's the nitp or the bsc so that's a bit his for historic reasons maybe we should change that at some point um the configuration file and you can see it's actually I'm scrolling through this it's 187 lines long so it's actually quite a long file but as I said you can just use the example config and edit those bits that are important so once again we have logging configuration as you can see there's many more things that we can log which we just skip this is all just for for debugging and so on and here we get to the settings that we have seen on the on the slides the network country code for example is 901 in this case the network the the the network code is 70 we have the short name with an R um we have auth policy closed um that's also what we had on the slide we have encryption a50 so you see all those settings that we have discussed before um lots of other settings as that we just leave all the defaults what's again important is here the type sysmo bts the band in which the bts operates um the ms max power which is a bit uh theoretical um those of you yeah some people are laughing I've certainly say well the maximum permitted power is 40 dbm I don't think there's any phone on this planet that's I mean for gsm that can transmit at 40 dbm that's a lot of power yeah um but I mean this is the maximum permitted value I'm not saying the no it's just well you you may transmit up to that power um if you cannot well you just transmit at less so normal phones uh on dcs 1800 can do 30 dbm so 40 is definitely much more so basically I'm saying well do all you can um yes captain I'm doing 140 percent um okay so where were we we were at ms max power here um here is the ipx's unit id in my case it's one two three four zero not one eight oh one but it matches what we have seen on the bts side that's the important part as said you can choose any random number and then we have lots and lots and lots of other values which we ignore for now um and then we come to the transceiver here so we have the trx and the trx runs on a rfc and one with a nominal power of 23 and a maximum power reduction of 20 the line here the nominal power 23 does not do anything this is just for you if you look at the the vt-y interface to get an idea of how much you're transmitting this does not change any actual parameter in the hardware this is again I mean we just did it how it's in the spec um it's stupid but this is how it's in the in the spec for for Avis OML um we are going to improve this but this is so basically you can leave that line out or you can put any random number it only affects what you printed on the screen so basically you you check the datasheet of your bts you see oh it's 23 dbm so I put the 23 in here and the maximum power reduction of 20 means now the 23 get reduced by 20 but even if you have zero up there it will still be 23 reduced by 20 so this value doesn't matter this one matters then we have the time slot configurations where we this is a control channel and then we have full rate traffic channels for making voice calls basically in all the other time slots I think on the last one is for packet okay lots of other configuration which we'll skip for now um but basically this is the configuration and now I'm running the Osmo NITB which uses by default the config file in the local directory if you have your config file somewhere else you need to specify a command line option where your config file is so I'm starting this and it basically tells you well I'm listening to the telnet interface on Lupec IP address and port 4242 um and uh some other here the tcp ports 2002-3003 some other protocols listening at other interfaces and it's waiting for basically for a connection um surprise that this doesn't happen let me just quickly check um why there is let me open another terminal yeah the slide is the slide is different that's correct um so I'm the 239 here that's clear so let's switch to the bts again ping yeah I can ping that ip um no it it will restart itself on the bts in this case okay failure I tried this this morning after getting up or not and that's why when I fix that that let me just that's that's fine that's fine too we are a bit tolerant in what we parse so it can be with dcso without let me just see connection closed by foreign host okay ah this is probably my packet filter um yeah I think I have it on the slide uh you know make sure that you don't have a packet filter that um so and there you go uh okay this was the connection that I made the telnet connection the bad message but I think now it should oh no it actually went through it went through that's why we see it here so it was not the packet filter ah demos yeah I hate demos um let's okay ah okay yeah for some reason the bts process didn't start if I started from hand on the bts now we have the connection we get this purple line here bootstrapping rsl that basically means the bts was connected and it's bts0trx0 um and we see him again repeated the mobile country code mobile network code and we already see some location update requests from phones in here why is that because we're in a bunker and we don't have real network reception so the phones of people in this room who cannot see a real network will try to roam onto this network and we're seeing registration requests for um imsies that we don't know um so and they get rejected because we have a closed network so basically those connections get rejected if I now register with this phone I could register into the into the nit B but if you're running out of time as it is so I'm just going to back go back to the slide and basically say what the next steps are well basically the phone after it powers up it first checks the sim card if the cell is found again before it was switched off so the phone will never do a network scan if it finds the cell that was present while it was switched off so if you power off a phone in a location and you power it up again in the same location it will directly go to the cell where it was registered last it will not do a network scan doesn't matter what other networks are there so you if you want to override that you have to do a manual network scan or something like that by yourself then you see a list of the networks and then you can try to register explicitly to that network um so then it will perform what's called a location update with type in the attach which is basically the network registration um and that needs to be accepted and in order for that to be accepted um we need to set a certain flag in our subscriber database I shouldn't click on the slide this authorized flag so basically in order to make a subscriber join the network we need to authorize him so there's a command by which you can authorize the subscriber and if you show the subscriber then on the command line interface you will basically do something like this that's authorized one and then the subscriber is able to join the network and uh yeah so that's basically how far I wanted to get as I wanted to show also the registration here but as I said we are unfortunately on a very tight schedule so um we are taking the morning break now before Daniel is coming back with how to extend that configuration to GPRS okay thanks if you have questions right now to this feel free to ask I think we can do one or two questions otherwise it's the coffee break okay well then ah there is more question yeah sure sorry I give you the phone the microphone um my question it didn't used to be this way you know my question is actually about the configuration some of the features about kind of being able to save from the VTY are new to people who kind of got used to doing it the old way from like five years ago how smart is the configuration in terms of being able to tolerate or rather not tolerating correct values but to put smart things in for values that are not specified if you use old config files I'm just curious sorry yeah the microphone um the uh basically all the values that you do not specify will have default values now how sensible they are for your particular the static defaults right so basically each parameter almost all parameters have a compile in default value that's in the code so it will not try to analyze what basically your configuration is and try to make a guess that might be particularly smart for your choice but default values so let's say if you do not specify the maximum power reduction I think it will apply no reduction or if you do not specify the mobile station maximum transmit power I think it will use 33 year old I'm not sure but there's a default value it will not be a default value that will make your network completely not work right it might not be optimal but there is a default value compiled in and if there is no default value for a certain parameter then it will be able to start with a config file that does not specify that value