 So just a quick recap, how did this start, Dieter and Harald, I'm told, started on the BS11 Avis project, or just trying to get some BS11 BTS to work for them, and it continued to BSC hack and on to openbsc.git, and that's all that basically I gathered from the preface of the OsmoCom manuals, because I wasn't there yet, I joined at this third stage, openbsc.git, was the hub of OsmoCom cellular network infrastructure, and basically it was as simple as this, you have some BTS, and the OsmoNITB program, which had a subscriber database based on SQLite, so simply enough, and just keep this image in mind for later, because it's going to change a lot. So it's obviously not that simple, there was also the packet switch site, the SGSN, and so what springs to mind already is that the SGSN had some G-sub protocol to proxy to a map, and this is of course for the subscriber database, G-sub is an OsmoCom invention, that sort of simplified map, and it started out meaning GPRS subscriber update protocol, and so it's obvious here that we have separate subscriber databases between NITB and SGSN, and that's a problem, or that's not very nice, and the SGSN also used to have accept all policies and stuff like that, but what we really want is ciphering keys, like authentication, and ciphering keys tokens managed once for both, so the obvious step, so this is not necessarily in chronological order, it's just a logical breakdown of what it ended up being, but I think this is even pretty much chronological. The HLR was the first split off from the NITB, a common subscriber database, the home location register, so the G-sub no longer means GPRS subscriber update protocol, it means generic subscriber update protocol, and so this was still an openBSC.git working on a branch, we had separate home location register and proper VLR inside the NITB, so at this stage already we have three key new features, so we have this common home location register, we have asynchronous communication with the subscriber database, before the NITB process would stop, look up subscriber data and then go on so we could technically block, and the HLR also brought the support for millenage authentication tokens, also known as aka UMTS aka. So aka, the capital ones means authentication and key exchange algorithm, what? Key agreement, that's it, and the small one means also known as. Right, so what we also wanted was 3G, and so the HMB here denotes 3G cell, actually more accurate would be the HMB gateway, the HMB GW, but so here we have the NITB, which is a BSC and an MSC together and an SMSC and whatnot, so where do you plug it to? We have this ABIS, which is sort of outside of the BSC, so that's not a nice place to add 3G support, so somewhere we need to put this IUCS, and basically then it was obvious that we need to cut the NITB in half and the parts that were BSC and MSC would have to be separate, and also obvious was that we also still had the Osmo BSC, a separate program using only the BSC part of the NITB to talk SCCP Lite to a third party MSC, so we kind of haven't BSC a separate one, but we only had the MSC and BSC, so no separate MSC, so it made sense to rearrange it a little bit to this, so this looks already quite different. We still have the HLR on the left and the BTS on the right and the BTS on the left, and now we have a separate Osmo BSC and we taught it to talk A interface to the MSC, and the Osmo MSC program still has the MSC and the VLR, like before it was actually omitted here in the NITB circle, we had the MSC, the SMSC and the VLR. The 3G HomeNote B has a proper connection point, IUCS to the MSC, and same goes for the SGSN, and now on the bottom you might have noticed what was previously the Osmo BSC talking SCCP Lite, it now became the Osmo BSC-SCCP Lite to indicate that it's the legacy Osmo BSC. This SCCP Lite one is still an open BSC.Git and the proper one that we want to be supporting and using from now on is an open-BSC.Git. Let's just add... Okay, so what we have here now is 3G support, we have a proper TrueA interface, and that means we can also interface to third-party MSCs over SCCP over M3UA, which is the proper 3GPP-specified way of doing A interface. So, just quickly, the Git repositories for later reference, I guess, so the Osmo BSC.Git, Osmo IOH.Git, well, basically it should illustrate that now it's not open BSC.Git, but it's lots of separate Git repositories and their own separate projects going on independently. And the SCCP Lite one still in the old open-BSC.Git. So, that's what it really looks like now. Quite different from the beginning. What so far I didn't mention was the media gateway, which we pair up with the MSC and also the BSC now to route RTP streams before we used to do that internally. And also I didn't mention the STP, some... Yeah, what is it? It's just quite trivial, well, not so trivial, but conceptually quite trivial, routing between SCCP point codes. So, everything subscribes with the STP and then they can talk to each other, sort of like an IP network subscribing at DHCP, something like that. Yes, so that's what we have these days when we set up an Osmo-com network. It's no longer NITB and view-done. And recently I tested some backports to the old Osmo NITB and I was pleasantly reminded of the simplicity the whole setup had back then. But of course the features we have now justify this complexity. Like, again, we have asynchronous subscriber database access, proper millenage support, we can have 3G in there into operability with third-party MSCs and we can test each part on its own. So, speaking of tests, if you don't have tests testing everything and you change everything in your code, what do you get? What's the obvious conclusion? We got it quite obviously on 34C3 last December where we set up a GSM network. So, we used the split components the first time, we added 3G to it and it was a complete disaster like the MSC crashed every 15 minutes and it was kind of working and people came in, I can't subscribe or now I can call but really it was far from stable and even going into setting up the network I thought about a few things. There was something about paging, have I fixed that? Oh no, I haven't fixed it. Better fix it before the congress and stuff got concrete and it was obviously broken and why? Because we didn't have proper testing. So, I'm not sure at which point Harald really started but I think the congress disaster really got the TTCN3 testing going that he started on. TTCN3 will have a talk on that as well and tomorrow morning I hear and that's what really need to get everything stable. So, we take complete programs input messages and get messages back and you can run it in Docker images and already we uncovered a lot of bugs and we're fixing them and when it's a lot of work also but when we are through it then we can be confident that it's reasonably stable and we've come back to OSMO NITB stability despite all the new features and having ripped out its guts and reassembled it in different ways. So, the unintended bugs aside there's also some things that obviously are different now. For example, that's still a bit unintended that I was already on the next slide here. So, the MES feed feature in NITB used to put measurement reports to a third program for analysis and while splitting the MSC from the BSC that got lost because though it belongs in the BSC the code was in LibMSC which didn't matter in the NITB because it's all one but they're not knowing really what it was I just sort of deleted it and forgot about it and then later it dawned on us wait, what, it's gone, where is it? So now it's an open task to re-add it to the OSMO BSC I started but in the daily work I haven't completed it yet. So, we need to re-add feeding measurement reports to programs currently A53 has a problem because now we do it properly we broke it so before we didn't really check whether the phone supports A53 or not we just assumed if the network configures A53 then, well, let's use it but now we actually try to check the class mark that the subscriber sent and see well, does it support A53 and if not, then don't use A53 the thing though is that this class mark that indicates A53 is not part of the standard location updating message so when the subscriber comes in it sends the class mark 2 I think which doesn't contain this indicator it only goes up to A51 and the obsolete A52 I think and so we never know whether A53 is supported from the MS or not because we don't have this class mark version present and since we don't have the information we assume that A53 is not supported and so currently we completely thwart A53 configs in the MSC obviously what we need to do is do I have it on a slide here? I don't know, I've got it later so basically the MSC needs to ask the subscriber for the proper class mark in a separate communication and then assert whether to use A53 or not it's not very difficult, someone needs to do it and I'm not sure about the state of external MNCC I just recently heard that it's not wasn't working properly but also I heard that it might be fixed maybe we can hear something on that later right, now the planned or the obvious changes since the MSC is separate from the BSC now we can't know which logical channel or which time slot on which BTS we are using for which subscriber on which call so before on the NITB we could show a summary of this phone number or this MC is using currently for this call is the BTS1 and time slot 2 and sub slot whatever 0 and this information is no longer available in one place the MC and the phone number is mostly in the MSC and the L-chance and BTS trucks are in the BSC and if we wanted to show them in one comprehensive view we would need to add or the plan is actually to add some OSMACOM specific tag level value pairs like information elements on our interface that are only sent when both sides are OSMACOM so that we can collate that information again so that's basically the same thing the BSC basically gets channel requests or assignment requests which naturally never usually never actually see what the MC is or the phone number is so though the BSC pipes all that DTAP and complete level 3 messages back and forth shouldn't really look at them but of course we can so one plan of mine is to actually also have some filter in there which helps some old feature that unpacks these messages and gets the MC and phone number well I'm not sure about the phone number anyway the MC and the TIMC so my plan is to get them, read them out of there and put them back in the state so in the logs we don't need to say well a subscriber is unknown but say this alchion is used by this MC currently so that could be quite useful yes it will sometimes be the TIMC and so yeah for example if we page for a TIMC then we will only get the TIMC from the MSC or if the subscriber comes and it has a TIMC and does location updating with the TIMC from last time we will only have the TIMC that's why I also put the TLVs in there so we might even want to tell the BSC about the actual MC or maybe even the phone number yes yes yeah so there's some it's not very complicated work but you know it needs to be put in place and sort of the same thing for the IMEI no it's not the same at all the IMEI is not known by the network normally unless it asks for it with an identity request and we have all the parts in place for it in the VLR we have the messages and everything the only thing that's missing there is the actual switching on so it's off by default and we don't have config items for it yet so all we need to do is add like three flags to the config and then we would have the IMEI back like we used to in the NITB which used to I think ask for the IMEI by default always and I wonder if it's on this slide oh yes and then the IMEI it would also make sense to pass it on to the HLR so that you can look at the data in one place and it's also some use case that Keith brought to my attention of Resomatica where in Mexico where they have someone showing up with a phone and they have no idea what their MC is but the IMEI is usually available on the phone information so if you subscribe and scan the logs for the IMEI you can easily find out the MC without taking out some cards and doing stuff like that so that would be a useful feature for open communal networks okay so so like Zainas said it's extremely useful to say what to have the IMEI and the HLR in commercial networks for statistics so I wonder if I should mention it here like the use case I mentioned now with someone showing up with a phone and subscribing and seeing an IMEI is it also contains the subscriber create on demand thing where you sort of allow anyone to show up on your network but one thing about that is that of course then you don't have aka authentication and ciphering tokens so for allowing anyone on the network you would have to not use any authentication nor encryption and thinking further into it we could possibly ask for the IMEI and then reject the subscriber because we don't have data and this use case is so sort of intricate if you want to have a secure network then you shouldn't allow it but if you want to find out the IMEI things can be done there but currently you don't have the IMEI and all that's why it's on the slide or there is the subscriber create on demand so we have issues for all of these if you open the slides it's actually a link also on the pre talks you can also click on the issues and take a look at their current state if you so desire right, plans and ideas like what should also come here besides stuff that we broke or deliberately excluded so far we had the separate OsmoBSC SCCP lite like the legacy OsmoBSC and of course we don't want to carry on back porting features to the old OsmoBSC forever so what we need is SCCP lite support in the new OsmoBSC so that you can benefit from the new features and still follow the old architecture and I'm not so sure about OsmoBSC NAT that still lives in openBSC.git and it's quite excluded or idle in the new OsmoBSC it's certainly not operational and it's also a kind of a special program. Yes so the question is the SCCP lite for third party MSCs so there are MSCs around that don't actually have a true interface so some users still require the SCCP lite so moving to the new OsmoBSC is not easily possible there oh yeah we actually have a mic for questions it's a bit more formalized with video recordings isn't it like last year we would just talk into the room transcoding in the OsmoMGW like that's been a long standing thing I noticed this when I implemented dynamic time slots where I had a network that well it's not necessary for the first time but for me for the first time I had a network that by definition had both TCHF and TCHH time slots available and then what I noticed is that it didn't work why because for some reason the first phone during the call came in on TCHF and assigning the the MT call leg always assigned TCHH so then always I had this TCHF, TCHH mismatch between the two phones and the call could never get established because we don't do transcoding and the solution well the work around there for me was to allow a configuration switch basically switch off TCHF with OsmoCom dynamic time slots so that you always use TCHH but of course we want to be flexible on that so at some point we need some sort of transcoding, yes another solution might be to use lower modes of AMR but that's also it's possible it does not require transcoding but this requires AMR support in the phones which is supposedly now supported by all modern phones yeah well it's supposedly ubiquitous but of course that's a configuration question like we still want to allow TCHF for legacy phones and TCHH basically we want to stay open to all the codecs and all the legacy stuff and the new stuff and also thinkable would be to like we do now have late assignment and choose the matching channel type but for other reasons that I'm not going to go into having transcoding in the MGW would be desirable and solve a lot of things I presume also with 3G interop and all that so far we still have a database in the Osmo MSC it used to be the subscriber database and now it's only the SMS database because SMS is still inside the MSC and we've been trying to get rid of the lib dbd dependency for a long time and it's still tagging along and keeping lib dbd in there having deprecation warnings in our builds because of that right another nice idea was the Osmo network check 2 that given the complexity it's like a completely new thought given the complexity of the network we now have some program that is able to find out which components are working and which aren't and like telling you where communication stops and if something is wrong or maybe even help you configure that so far it's still just an empty idea no concrete code yet it's just an issue number there and also recently there's been talk on simplifying the new split components for example don't have the STP in the middle but incorporate it in the MSC and operate without an MGW like in the old days like without a media gateway and stream the RTP directly so I'm pretty sure I forgot some things here so if you can think of other use cases that are important in the NITB that you may notice aren't possible or have seen aren't working anymore in the split components let's talk in the coming days about it otherwise I'm through this is my BSS map interface release request so are there any questions? you can just keep the mic is accept all mode supported in split architecture right now because remember seeing some issues in the tracker regarding it being not supported are you sure the mic is on? say again is what supported? accept all mode accept all mode accept all subscribers that's a good one it doesn't exist currently it's kind of like the subscriber create on demand I think in the SJSN you can still configure it like in the old days and bypass the HLR but the MSC needs an HLR to accept subscribers now is there any issue to recommend? is there any ideas how to get it back? well that would be a new feature to the HLR basically so the HLR gets the GSAP request for location updating and we could add a feature that creates a new database entry as soon as it receives that but so far the HLR doesn't do that I guess it's a fairly trivial thing to add if it's really needed it shouldn't be too complex actually probably you can even do without an HLR database entry you can just simply send an accept back or do an insert subscriber data with some random number or without an MSI STN depends on what the use case is but you also need to assign a phone number basically well it depends on the use case of course so then release command release complete RSLD, no RLSD ok I'm released, thank you is it? release clear? it's a pleasure