 Okay. Hello. My name is Daniel and continuing on from Harald's talk, I'm going to talk about how to run your GPS Edge data services network with OsmoCon software. So which one of you has already run GPS data services? Okay, quite a few. So it's probably going to be boring for you as well. But yeah, I hope you'll survive. First of all, the great picture. Again, this time I'm going to concentrate on the lower part. So the packet switched network, again you have the phone which connects via UM to a BTS. BTS connects to the BSC. And then or BSC, in our case, it's the network in a box. And then you have PC usually with the BSC that connects to the SGSN via the GB interface and so on to the GGSN where authentication is done inside the packet switch network. So what we have implemented so far is a little bit simplified. Again, we have the phone obviously the Osmo BTS which basically also houses the Osmo PCU. So the PCU is the packet control unit. That's different from those of you who know classical networks where the PC usually is at the BSC level. So yes, then the Osmo PCU connects to the Osmo SGSN through the GB interface and that connects through GTP to the OpenGGSN where the connection is terminated. So the IP packets basically tunnel from the MS to the OpenGGSN and there they go into the wild. Additionally to the configuration that Harald has showcased, we also need configuration for the Osmo NITB. So as Harald mentioned, the BTS is basically configured by the BSC or in our case, the Osmo NITB. And the same is true for GPRS. So the Osmo NITB when the Osmo BTS connects to it sends also the GPRS configuration parameters to the Osmo BTS process which then talks to the Osmo PCU and so the Osmo PCU will know where to connect to. We need some configuration for the Osmo PCU and then of course for the other services Osmo SGSN and Osmo GGSN. So here it's just, I mean, we can run everything on one box. So it's also a data network in a box if you want. But for generalization sake, I've just now shown the configuration what you would do if you have everything on a different box because some larger installations you'll probably want that. So we have the Osmo NITB which has its own IP address can be run separately. You have the Osmo BTS which sits on the same device as the Osmo PCU. So they have the same IP address there. Then the Osmo SGSN has an interface facing the Osmo PCU which has an IP address and also has an interface facing the Osmo GSN with its own IP address which can be the same but doesn't have to be. And the Open GGSN can still be another box with a different IP address. So for the PCU, you generally just have the lower level configuration. So you set up which coding scheme to use. So coding scheme for GPRS is how much redundancy you want to include in your packets. If you use maximum coding scheme for GPRS, then you don't have any redundancy. So if you have any bit errors, a packet gets dropped and has to be retransmitted. While coding scheme one has lots of redundancies and you have very limited throughput. Then there are some parameters to configure the maximum coding scheme that you want to use, the thresholds of bit errors at which you want to upgrade to the next higher coding scheme or the next lower coding scheme if the error is too high. And allocation algorithm dynamic is more a historical thing. We had two different allocation algorithms back when the Osmo PCU wasn't really stable. But right now you'll want dynamic and it will know whether to allocate only one slot or multiple slots. So with GPRS, you have the time slot system and with GPRS, you can use multiple time slots together to increase your throughput rate for a subscriber. And then another interesting option for the PCU is the TBF idle time. So TBF is the temporary block flow which exists in two variants, uplink and downlink. So downlink means to the phone, uplink means from the phone to the network. And as a network, we have the choice after we have sent all data to the MS, we can still keep this temporary block flow open and wait if there might be more data. So for example, for TCP connection, the phone sends a sudden up to the network, then it has an uplink TBF obviously. At some point in time, the reply comes, Sennach. And so the Sennach generates a downlink TBF to the phone. But after this packet has been sent, then basically usually you would close the TBF again. But it doesn't make any sense because the phone wanted to talk to the network. So next thing it sends an act together with the request and it gets an answer. And then you have to go through this whole establishment procedure of creating a new DLTBF again and again potentially for many exchanges over and over again. So that really helps with the downlink throughput. Milliseconds. Okay, so as I mentioned, most of the configuration of the Osmo PCU comes from the NITB. So I've also basically the other parts that Harold has mentioned belong there as well. They're just left out for simplicity's sake. You would have GPS mode, GPS instead of GPS mode none, which is the default if you don't put anything. Then you have the routing area. It's basically similar to the location area code for classical GSM. And then the ENZINE network or the BVCI and the ENZINE, the BSS virtual connection identifier and the network service equipment or endpoint identifier. Those are basically just numbers that we choose. It has to do with the classical structure of the GSM network. This was typically run over Fremule, so you could have redundancies and use different NS connections to terminate the GB link. And yeah, well, long story short, for our purposes, you just pick a number, those two numbers identify the cell, the system, and then you can address or the SGSN can address the PCU based on that. Because as you can see below there, it uses UDP with static ports and not in place. You might not have such a good time identifying the different connections. Then for the NS virtual circuit zero, which is the only one we use, you have the local UDP port, which is the port that address packets are sent from on the PCU. And the remote UDP port is where it's sent to, obviously, and the remote IP is the IP address these packets are sent to. So why are local and remote ports not the same here? They could be if everything's on a different box, but if you run it on the same box, well, you would have the remote IP address of 127.001, and you wouldn't be able to send from the same port combination, so that's why it's different. And with this IP address AA, so this link to go to the Asma SGSN, to that interface. For the TRX, you have to, as Harald mentioned, configure the time slots. It can be a PDCH, which is a static configuration for this time slot. And probably you want to have at least one PDCH configured all the time. And quite recently, we also have dynamic time slots, which are used as PDCH if no calls are ongoing. And so TCHF and TCHH are the traffic channels for voice calls. So we have a dynamic mode of operation where you can have as many TCHs as you need for voice connections. And if you don't have a call ongoing, then this time slot can also be used as a PDCH to bundle the data and to get faster connectivity. And also the PDCHs should be used or should be in continuous order. So we always have them all bunched at the end and then run into any problems with allocating multi-slot TBF. Okay, so on to the SGSN. SGSN has two parts, the NS part in the bottom is basically its connection, its interface to the PCO. Encapsulation, UDP, local IP is AAA as seen in the network diagram. The local port is the port that we previously set the PCU to send data to or we set the configuration in the Osmo NITP, but that's what Osmo PCU then uses. Framrelay is supported, or we support Framrelay to your generic route capsulation as well, but we don't use it here. And the upper part is the SGSN node which has the connection to the GGSN as well. So for the GTP link, we set the local IP. So it binds or it can bind to a different IP there than it does for the NS link because the SGSN doesn't really need to be in the public network. So, yeah, I mean we can have different interfaces bound there. So then we configure the first and the only GGSN with the remote IP C.C.C.C. USGTP version one. And again, same as with the NITP, we have the off policy which here is set to closed. Closed means it will accept all IMZs where the first digits match the mobile country code and mobile network code name. So we don't really have, if you look at this again, the Osmo SGSN now tries to do authentication as well. But if we're operating the Osmo NITP where the VLR and the HLR is located, we can't really do that. We don't have access to the keys or to the subscriber list. So in the simple case, we have to do something or add a subscriber list in the SGSN itself. So off policy closed. There's also different other off policies. They can be accept all which just accepts everyone. Which might not be a good idea if you're broadcasting with power and on a public place. Closed accepts only the matching ones and the ones that are defined in the ACLs. ACL only, obviously only accepts the ones in the ACL and off policy remote was recently introduced with Osmo HLR, which if you're running a more complicated setup with not just Osmo NITP, you can or it can connect to the HLR and basically use the key data for real authentication, not just accepting them into the network and encryption as well. So yeah, the ACLs are just MZ ACL add and then the MZ and then that subscriber is allowed into the packet network as well. So yeah, the GGSN is quite, configuration is quite easy as well. Just specify a listen address to bind to again, then a network prefix where when you start open GGSN, it will create its own tunnel device where the IP packets of the subscribers fall out. So that's the address range that assigned the addresses to the the MS to the phones and then DNS server that will be handed along as well. Yeah, exactly. So it can easily be seen that we have VTY interfaces in the Osmo NITP, VTY in the Osmo BTS, VTY in the Osmo PC, or VTY in the Osmo SGSN, but this one is named open GGSN. So obviously there can't be a VTY interface. We or Harold, I think, resurrected the project. It was an existing project and it now has, I mean, it has Osmo lip Osmo integration now with the control interface. Yes. But I mean, it works well or well enough for us. So we didn't really need to add more to it right now. I change in the future. Okay, so some miscellaneous stuff. If you want to get it all running, you have to set up and they connect to each other. Then a couple of things you could easily forget is enable forwarding and masquerading on the box where the open GGSN is running because then the packets arrived there and the computer doesn't know what to do with it. And on phones, I mean, on Android phones, mostly the type of phone I use to test GPS. And you might have to enable data roaming, which happens if your SIM card is allowed into the network but has a different prefix than the network you're running, then it will be a roaming or the phone recognizes it as a roaming case. And because it doesn't know it's a community network where you don't pay roaming charges, usually it will just block you. I think early iPhones don't care, so they might work anyway. And the access point name must be set manually. So on Android phones, if you put in one of our SIM cards and you start it up for the first time, then it, I believe it has an internal database with the MCs and network names and then looks up which APN, so which access point name to use and the data for that. And obviously for our networks, it doesn't have that. So it just stays blank. The APN, in that configuration, we ignored completely. So you can set any name, username, no password, and it will just work. But Android phones refuse to connect via GPRS if you don't have an APN set. So, yeah. Okay. Now, the hard part. So, there I can see in the bottom. So I've logged in to OpenBSC, which is the Osmo NITP. So this is the VTY interface with logging. And let's see. What is it? There. This is the Osmo SGSN. So first, I can do is show NS. So here it will say that it has the NCI1234, NSBC1234. The remote BSS is alive and unblocked and it's coming from local host port 23001. So the PCU is talking to the Osmo SGSN. And I should also see some logging messages here. Show MM context all shows that it doesn't have any MM context or show PDP context all. So currently no phones are registered there. Then, okay, let's see. This phone out of airplane mode. Okay. So we missed the CS part, the packet switched part. There we go. You can see the logging messages. The yellow messages are basically right now the interesting ones. You have an attach request. The SGSN asks for the identity, it gets a response. Then the authorization just happens and we authorize it and we send back the GPRS attach accept and attach complete. So that's the GPRS attach attaching to the network and after that we activate the PDP context. So the phone asks for requests and activate PDP context. We found GGSN for APN TYU. So I was quite creative with creating the APN here. You can also have different GGSNs for different APNs and then have different data services according to that or terminate into an internal network or into the internet. But right now this is just the bare bones configuration. And then so this happens on the NS link. Then on GTP the SGSN asks the GGSN to create a PDP context. This comes back with a confirmation has been accepted. And yes, after that we send back and activate PDP context acknowledgement and then we have unit data here which is basically the phone trying to browse one of its Android, Google or cell servers but I don't have internet right now so that's not going to work. So yes, basically that's it. Does anyone have any questions? We have this microphone to pass around so if anyone has a question please raise your hand and I'll. Hello. Thank you. I just want to ask you the current status of the integration with the user IP, the V200. It's feasible today if we want to set up our network using GPRS to use this device from it too? I think it should be. I mean it works with Osmo TRX, Osmo BTS TRX. So what I don't know is if the physical layer is up to it to generate those messages. Because you have different coding scheme for GPRS on the physical layer but. I think there's no issue whatsoever. I'm not aware of any issue why it shouldn't work but we are not the ones who have lots of experience with the USB device but I don't think there is a problem. Yeah in fact I always had tried to get close to GPRS. Sorry. You said it worked for you? Yeah unless I'm confused. It worked for me last time I tried it. Thank you very much. Once more for the stream. So you have a question? So right now you're running all the software on the laptop right? No right now I'm running all the software on the Osmo BTS. So what did you put in as IP addresses? You had all the IP addresses on the slides? So this is the special case. Everything on one device. So I have remote IP as local host. Let's see the PCU has no IPs configured. So yeah that's one special case if you're running everything on one device. For the NS interface it's just local host port 23,000. The PCU is 23,001. And for GTP the local IP is 127,001 and it sends to 127,002 because otherwise it would receive its own GTP traffic. And then the not Osmo open GGS and configs located here just listens on 127,002 and that's all you need. And if I had a default route well it has a default route but if my laptop had internet connectivity it could serve as well. So I have a question that I think I know the answer to and then I would love to share a statement that caused me to lose many hours of my life unproductively. The question is is that all of this business with different loopback IP addresses kind of because of overlapping ports is because it's all some standard that you guys didn't pick right? Okay yeah that's what I thought. And then the comment that is incredibly obscure is that I've discovered that if you are playing with this stuff using an existing operator SIM card so that's you haven't rolled your own. You can connect to the network you know if the SIM card kind of will allow it but a lot of SIM cards have secret blacklists for which networks they are willing to pull data from. So you can have something that looks like it works completely for CS but will break for packet switch because the SIM card is prohibiting it. FOI. You're sure it's not just the APN configuration? I'm certain. Oh yeah there's something here. Well you can store on a SIM card you can store what's called a forbidden or an APN blacklist so there's a special file on the SIM card which the operator can provision which contains basically yeah a blacklist of APNs that phones are not permitted to access. I'm not sure. I think there's even wildcard possibility. I'm not quite sure about that but I'm pretty sure there is. And another fun fact are BlackBerry phones which even if you tell it to connect to an APN they will or the older ones they will always try to connect to their BlackBerry APN first and get their configuration and authorizations what are they allowed to do from there and then connect to the internet if they're indeed allowed to do that so there was some some interesting things with BlackBerry phones there as well. Okay I'll go ahead and that's I have the microphone. It's on. So just in relation to the USRP I didn't spend an awful lot of time with it but I have successfully connected phones with N210 but as I said I didn't spend an awful lot of time but in my experimentation I got everything configured correctly set up. I was able to shell into the phone and from there I could ping and I can run a CMP traceroute but I didn't successfully get actually my Jabber client to connect. I would see packets going to the internet and I would see them coming back but they weren't really making it back to the phone and it seemed that once you could ping but once you tried to do anything beyond that so something happened. I tried configuring complete PDCH channels with no voice or anything like that and I still couldn't get actual real data flow. I don't know if you have a comment on that. The issue could be our way of dealing with bursty traffic so if you only have like one packet sent and then lots of so there's no TBF established you the SGSN receives a packet or rather the PC receives the packet for the phone and then yeah we established the TBF page the phone established and the problem though is we discard the packet so we expect that it will be retransmitted as well so that can probably decrease performance. So if you've ever used a commercial TSM network a commercial GPRS network production TPRS network with any kind of like laptop or other data device you will have seen that sometimes you get ridiculed as RTT in a ping up to like 23 or 50 seconds or something absurd like that so classic production operator networks tend to buffer for hours let's say the packets whereas we do not buffer any packets so basically the packets that we receive if we cannot immediately deliver them to the mobile station we drop them right we page the phone but we drop the packet and once the phone is there we assume that TCP or whatever higher level protocol we retransmit and then deliver the packet to the receiver that's maybe what plays into the pitch anyway I'm sorry we have to really I'm one more question but we have to cut it short just to keep in the schedule so I would like just to ask you mentioned edge yes did you do any testing with edge you were able to achieve edge protocol yeah did you able to use the edge protocol with any BTS station or any modification of the RX we have edge support for the small BTS yes the caveat right now I believe is that if you switch on edge you we will not allow gps or gps only phones will not work anymore so there's basically a hard switch that you have to do so now it doesn't support voice on edge on the same TRX you mean or the the pdch is the same so it supports voice and and edge fine but it doesn't support gprs so you have old you might have old phones that don't support edge just support gprs so we have either or kind of configuration there is no dual mode because that would have involved lots more development time I mean so I'm out right now okay thank you okay yeah thanks Daniel