 Okay, coming up we'll be talked by Niels on getting a 3G network to work. This has been what we've been working quite hard over the last, well, 1.5 years or so, mostly last year. And it introduced all kinds of new protocols and new acronyms and new standards. So, like with any new version of 3GPP technology, everything is called different. And we try to add all those new acronyms and new interfaces to our code. Okay, well, Niels? So, when I started with OsmoCom we had 2G and the next logical step is to support 3G. And it's a bit late on the market, but as 3G is phased out for productive use, it makes sense to use the devices for open communities and to be able to use the hardware that has now become cheap. And we don't support all of the hardware, but basically this type of femtosa, sorry for not disconnecting the cable, it's really hard to get it back in once I plug it out. So, that's a femtosa or a small cell and it has some advantages and I'll come back to this. So, basically, this chair is in the way. Same as with the Osmo BTS, your basic 3G network can look like this. Just your laptop, a cable and the Nano 3G. And so, that's simple enough, but of course it's harder than that. The Nano 3G exposes the IOH interface, which is handy for us. The traditional 3G, it needs an external RNC, which is sort of like the 2G BSC level, but it's a bit more complex. The H node B, well, the normal one is called the node B, the H node B or the home node B, it includes the RNC, which saves us a lot of work because we don't have to implement the RNC. So, what we get is the IOH protocol, which is basically circuit switched and packet switched IU protocols combined. And just to explain, in 2G, the phone is typically called the MS, I think the mobile station or something like that. And 3G or UMTS is usually called the UE, I think it's the user equipment. So, it's the same as the phone, right? And this is the air interface and this is my little white box with the Ethernet cable going to my laptop. And I call my laptop the core network, it's not entirely accurate. The core network is a bit less than what I have on my laptop, but basically now we're going to explore the software side of how we implement 3G. So, the IOH, I mentioned, it is circuit switched and packet switched IU combined, plus some HNBAP, some attachment protocol for the FAMTA cell to register with the network. And it all goes over SCTP, contrary to TCPIP or UDP. This is SCTP base and it's got a really complex ASN1 defined software protocol stack. But basically the core control and mobility management on top is the same that we know from 2G with some additions for UMTS, which you also can get on 2G networks. So, what we get here is IOH, all this stuff combined. IOH and B gateway, a home node B gateway, which should split this up into circuit switched and packet switch. Circuit switch just to clarify is for voice and packet switch is for data, I don't know if everyone is aware of that. So, that's why we have the Osmo HNB GW, the Osmo home node B gateway. It's a fairly simple piece of software, just receives the IOH, acknowledges the HNBAP, where the FAMTA cell registers and basically ignores that part and just forwards the circuit switch and the packet switch to whoever cares about it. And the home node B gateway is part of the, well, that's the binary and it's actually part of the Osmo IOH project. Try not to breathe into the mic ears, kind of hard. I don't have a pocket like Harold has. So, now we have IUCS, but where do we send this? Who talks IUCS? So, typically we have the Osmo NNB and this is kind of this MSC part, but it incorporates the BSC part. If you think a 2G network, there would be a BSC sitting here talking to the BTS and the NITB has them combined. So, we didn't really have a place to plug it. The code was very, well, it looked separate, but there were many threads and spaghetti reaching into the other part. One large part of the 3G work was to separate the NITB into a proper MSC. We have a separate BSC, but we never had a proper MSC. And the nice idea there would be to also have a proper A interface to also, instead of having the NITB and BSC combined, have a separate BSC and an MSC. But we didn't have an A interface so far. So, the beginning of 3G for me was to basically destroy the NITB completely. I just cut off all the paths and trying to manage to get the A interface set up. But basically, I just, you know, I just if zeroed lots of code away and started re-implementing the 3G, the IUCS part. So, that was on a branch and it still is on a branch. So, okay, so some details about configuration. Basically, on the FEMTO cell, for the case of the Nano 3G you log in with Ternet and your Nano 3G IP address and this port number. You have this on the wiki, I will also mention that later. And you just tell it where to find the HMB gateway. So that's the, it happens to be my IP address of the laptop. And then it contacts the HMB gateway. In the log you would see something like this. The SCCP gets a connection. That's then the IP address of the Nano 3G. Oh, yeah. And while you need to find out the IP address, usually from, well, sometimes I just watch with Wireshark the DHCP negotiation or look up at the router or whatever you prefer. I'm not sure if it shows up on our IP access. No, it doesn't. Anyway, and then there's the HNBAP registration and it shows some serial number that this box has internally. So then we're attached and now we need to send this stuff somewhere. So that's the Osmo MSC. That's the brand new entity we have. That's basically half the NITB and without the BSC part. And the Osmo SGSN where the MSC is for voice and signaling for voice and the SGSN is for data. And it's the same Osmo SGSN as for 2G we've had it for a long time and there we basically added the IUPS and the interface and then it starts working. And both are part of so far the OpenBSC project. So the old name and the main Git repository, sort of a kitchen sink, but we will talk about this more in other talks. Anyway, it has the Osmo MSC, the Osmo SGSN and on the master branches of course the Osmo NITB but on the VLR 3G branch it's already an Osmo MSC and there is no NITB anymore. So the HNB gateway splits up the traffic to the MSC and SGSN as I've said before. So how do I tell it where to send it? For me typically I don't even have this configuration because the HNB gateway assumes local host by default but if I wanted on another box I could just tell it to send IUCS or IUPS to remote addresses. But so writing these slides I looked into my setup and thought oh my we don't even have a configuration for the remote server but then I realized okay it's the default and just made this up for you here. So when the HNB gateway connects then both the MSC and SGSN they show this in their log that they have a link from on port so and so and that's how you know that the HNB gateway knows where to find the MSC and SGSN. And so another big change in the infrastructure is the Osmo HLR. So the NITB used to have subscriber data in it and it used to have a local SQLite database and it used to also block until the SQLite finished looking up subscribers or doing whatever. So that was one big drawback there and the other drawback there was that it doesn't support UMTS authentication it doesn't support the extended considered standard authentication way for 3G networks and so at first we thought yeah easy enough but in the end the right decision was to create the Osmo HLR as a separate entity with its own subscriber database and talking GSAP are basically a self invented protocol sort of mimicking map and great advantage here is Daniel also mentioned it we can now use the same subscriber data for SGSN and the MSC and the next great advantage as I mentioned is this doesn't block so this sends GSAP requests it has advanced state machines now to talk to the HLR the HLR can take as long as it wants and the GSAP message sent back gets handled to serve the subscriber. So the HLR was designed to support UMTS authentication right from the start and we also have this for 2G networks now and just on a separate branch. So that's a bit of future development there already and it's the reason why you need to check out GIT branches to run 3G networks. So that's basically how you tell the MSC where to find the subscriber data and again this for me I just leave this out it's default on localhost and on Osmo SGSN it's the same it has been existing for a long time already this external GSAP interface and here's a little detail as Harald mentioned we have this I don't know Harald or Daniel we have this OpenBSC config file name this is now Osmo MSC config by default so here's next bit of future the OpenBSC name which is kind of confusing with OpenBTS we are moving away from that as we continue down the road. So yeah of course you need to enter subscribers in your HLR database so it's so far it's basic SQL so here just insert an MSC and a phone number and some 3G or say UMTS aka information, KI and OPC and what have you so that's just for later reference I won't go too deep into that so let's take a look at the voice part because we don't do RTP streams in the Osmo MSC we use the well the name is for historical reasons OsmoBSC underscore MGCP because it was a tool for sending RTP through some nut and we kind of expanded or repurposed didn't really change much of it to use it for 3G so what I do is I have this MGCP gateway which is kind of a stripped-down media gateway and I just tell it where to send RTP streams and I also tell the Femtosell where to send RTP streams basically the RTP goes here and then to the remote side or even back to the same if this phone is talking to this the RTP would go here and right back there and all I do here is I notice there's a call who's calling who and I'm telling this entity where to send the RTP streams this is again part of the OpenBSC Git repository that's the config so this MGCP gateway I think so far is still the weakest or the most ad hoc part of our 3G development because I haven't really gone into depth because so far I have only been using one 3G home node B it says BTS obviously a 2G name and it has a fixed BTS IP so I don't know what I don't know yet what else we need to change I think it should be some sort of automatic discovery I haven't really discussed it yet but basically you tell the MGCP gateway what's my own address what's the Femtosell's address and where to bind and connect where to bind and accept connections on the Osmo MSC side and there's also a common number and both sides the MGCP gateway and the Osmo MSC I don't know anyway there's a base port number on which RTP streams get added so the first RTP stream would be on I think 4,000 or 4,002 and the next call would go on 4,004 and so on so there's another configuration item negotiating which ports to use for RTP streams so some detail and the MSC just needs to know where to send the instructions to direct RTP streams so there's that this is, yeah, the slide says it all and the data part again uses the Osmo SGSN that we've seen from Daniel's talk and the same Osmo GGSN and his remote access option using the external HLR and this is, the GGSN is in the open GGSN grid repository now there's one thing missing like a quiz question can anyone see what's missing in this graph for packet switched data communication so we have this very nice line here it says GTPC, that's the GTP control flow what about the user data where's the actual data communication coming so that one goes directly from the FEMTO cell to the GGSN so that's a kind of new thing so in the negotiation the SGSN tells the FEMTO cell where to send its user data and it can be kind of tricky in case of first packets and the stuff not being established yet and the same issue with dropping packets for establishing the link but that's basically how it works and the consequence is that network communication wise the open GGSN technically has to sit over here so it has to be reachable by the FEMTO cell you can't have this on a loopback interface one to seven or two or something because then your FEMTO cell won't be able to deliver the user data and again the same thing as in Daniel's talk due to the GTP specifications they share the same port number so they have to have separate IP addresses and let's see what I have on the slide so I have to add on my public interface a second IP address maybe you might remember I had 132 before and I just IP address added another IP address specifically for the GGSN and here as before the SGSN was one to seven or one and the GGSN was one to seven or two well the SGSN wouldn't have to be public but while I was at it I probably just picked a public one this is the important one is a separate IP address on the public interface could probably be a bit simpler but that's how I use my local setup currently so that's the whole picture again voice and data we have the FEMTO small cell, the HMB gateway and the MSC and the RTP control gateway sort of for voice and the SGSN and GGSN with direct GTPU connection to the FEMTO cell both using the HLR home location register for authentication data so that's just some links for a later reference I don't know what's the time do you guys have questions? maybe I can skip this and you can just read this up yourself one thing I would mention this is the future picture due to the dotty graphs stuff got swapped around now I tried to fix it up back but in the end I just left it like this this is the same picture that we saw before and the plan now is to allow 3G and 2G operation at the same time no NITB involved we have our stock OSMO BSC as we had before with a proper A interface now which is currently in development Philip is doing that the same old SGSN connection now the remote HLR and the now standard VLR HLR connection I didn't mention before the VLR is the traditional name for the part that talks to the HLR and so this is going to be OSMO COM in hopefully the pretty near future where we can operate 3G and 2G at the same time yeah so I'm through there any questions? I see one in the back hi there I see no configuration interface on the 3G so the typical TR69 type interface you've got for CPEs and 3G how are you doing the configuration of the FEMTESA? yeah it was mentioned very briefly on the summer near the start so there's much more in this DMI but this is FEMTESA specific so basically what you tell the FEMTESA is where to find the HMB Gateway plus which IMSI is to allow and the RFCN and I kept it short because there are different models of FEMTESA and this particular one uses this DMI model I guess others have web interfaces or what have you but that basically depends on your 3G cell yeah so what we're using right now the Nano 3G has this particular config interface we have some other small cell hardware that has its own MIP in a different format we don't try to implement TR69 in our code I mean there are other projects out there that do TR69 I know that some people have been working on using Huawei FEMTESA cells with some Python TR69 code to get basically the configuration done but basically we only pick it up at the point where you actually see the IUH with the RUA protocol and so on I was just wondering if anybody's got any advice of where you can actually get FEMTESA cells from I forgot to mention we recently maybe you noticed that we recently launched the Accelerate 3G5 project where we gave away a number of these Nano 3G FEMTESA cells so some of the people that received one are also here today and it's also on the links page that's where I wanted to plug it now remember so if you look at this wiki page you will see the submissions and the projects for 3G in return for receiving a free FEMTESA and I don't know if Harald wants to say some more Yeah so we have been trying for I think four years now to try to buy FEMTESA cells from FEMTESA cell manufacturers it's relatively difficult unless you want to buy 100,000 of them we even got to some point where we bought 10 samples and we filled out lengthy and lengthy excel spreadsheets with all the configuration stuff that they should be provisioned with and then they never got back so we have 10 units that are just brick which we bought because they didn't follow up with the provisioning of those devices actually so we could use them so that's been basically a pretty difficult route what we have basically is this more common is we have a certain supply of these nano 3G devices of which we, I don't know the exact figure but I think some 30 or something we basically donated to people who wanted to do something to contribute to the code and additional devices from this nano 3G stock that we have we will be offering a network in the box product basically which is a small embedded Linux system with the nano 3G like we do sysmo com with the sysmo vts net like starter kit that you can obtain so that is not ready yet because well all the software lives in branches and it's not properly packaged yet and so on but that will be released very soon now so we're in the packaging process right now and that will be available where other suppliers for Femto sells and where you can get them as I said it's difficult we are able to also sell some small hardware which is at sysmo com which is compatible with the stack but also that has been rather difficult to find companies and suppliers for that so and if you go beyond the Femto sells the pricing of course also again is rather expensive but as I said I mean this is not a sysmo com advertisement event here but yeah we have managed to obtain some stuff we are able to fulfill customer requests but where in general on the market you find Femto sells it's relatively difficult well for the nano 3g well it's clear who is the manufacturer but for the other devices I mean basically we I mean at sysmo com we subsidize our development by selling hardware so we don't really like to disclose the identity of such suppliers because that's basically what we pay developers from that knowledge yeah of course there's no problem whatsoever that's no problem okay good then I think we've run out of time thanks to Niels for his work and the presentation