 Yeah, 2017 retrospective, yeah, this is sort of a bit of a review, and the important points that I think to point out not so much what happened, but also what we can learn from this. So, we have a new acronym that we just introduced recently, it's CNI, is the core network infrastructure, cellular network infrastructure, sort of the problem is OsmoCom is a larger project and the GSM stuff is only part of it and we never really had a proper name for the GSM or the 2G, 3G stuff inside and CNI is sort of a new name for all the GSM slash 3G projects and to separate that group of projects from like RTL-SDR or Osmo-Tetra or Osmo-GMR or something like that. Anyway, yeah, so we had software changes, we had team or developer changes and we had also for SysmoCom some focus changes which affect the project, so on the software changes we already know, there's the Osmo-BSC migration from SCVlight to AOV IP, we had Osmo-MGW now as a new integral part, we had the NITB split, we had 3G support that went mainline, was developed in 2016 but only went to master in 2017, so lots of software changes, we also had some team, it's insignificant, yeah, but you know, there's also the TCP stack and the SCTP stack and all the kernel or the operating system that we run on, so the SCTP is something like that, it's just like infrastructure underneath that you don't really think of, it passes messages from left to right and routes them. So anyway, that's, we had some team, I mean, yes, I'm going back to 2017 but still to put things in context, so Jakob who has been doing a lot of work, particularly in Osmo-PCU had left SysmoCom at the time, so which means particularly Osmo-PCU has received a distinct lack of attention, also Jolly of course changed his focus away from the GSM projects to Osmo-Com Analog and other projects, so we have some lack of attention on the PCU, Holger has left Sysmo-Com which also not directly but indirectly over time, I think you all have witnessed the primary focus has shifted away from Osmo-Com, which is a big loss in terms of skill and capacity for sure, earlier this year Maxim left Sysmo-Com and yeah, it's again another loss of existing know-how and yeah, knowledge basically, yeah, I mean who knows, I don't want to make predictions, so yes, he may be back but we don't know now, so a lot can happen in a year, so I don't want to expect it or to take it for granted, so we'll see. Well, yeah, maybe, then we can use an Osmo-SDR based ADSB receiver to track him. Anyway, so at Sysmo-Com we traditionally, we had a lot of non-Osmo-Com projects and work that we did to cross subsidized Osmo-Com work, so since not a lot of revenue was coming from Osmo-Com related projects, we did other stuff to finance the work on Osmo-Com, which distracted resources quite a bit in 2015, that's now gone, but also used to be the case that as we did cross subsidize a lot of Osmo development by hardware sales, so if you bought some Sysmo-Com devices, then that basically paid for many days, if not weeks of development time, that's not happening as much anymore as it used to be, but on the good side, it means that at the Sysmo-Com team, we now almost work 100% on Osmo-Com projects by R&D projects, support contracts and grants, so the amount of interest in professional services, support and development projects on the Osmo-Com stack has increased to a point where we don't necessarily need to cross subsidize from such other sources, which is good and I hope that continues for the time being, so we don't have to cross subsidize. Looking at the NITP aftermath, it's the biggest architectural change since 2008, so it's really basically turned upside down many parts of the project, of course there's stuff that didn't change like the RSL code or the OML code talking to the VTS, but apart from that a lot of things have changed, there were lots of good reasons, we have all kinds of things now that we didn't have before, like proper finite state machines, with timeouts, cleanup code, integrated logging into that and so on, we have 3GPP compliant A over IP with interop testing to other implementations, we don't have the synchronous HLAR database access anymore, we have shared HLAR from MSC and SGSN, we have 2G, 3G integration and so on, so we have lots of advantages in various ways, but then of course there's also bad parts from the split NITP, we had a never ending list of breakage and that is sort of separated into two parts, one is actual regressions, so things that used to work on NITP but didn't work on the split architecture anymore unexpectedly, so not like that something was not ported or something, but real regressions, then we had also of course known omissions during restructuring, like the measurement feed sort of was, and as Nith said, he just removed it or disabled it meanwhile, he's re-enabling it now after some time in the split code and we also have some commercial users and actually I think in terms of funding rather significant commercial users that are stuck with SCCP Lite for various reasons and thus use the old, not sure why the formatting instructions show up here, the Osmo VSC SCCP Lite now, which doesn't have, has almost none of the new features and bug fixes and improvements, so they're not benefiting from this, also means there's no automatic testing, whereas we have lots of automatic testing now on the split architecture that the old one doesn't have it and we have to do some back ports which are time-consuming and distracting us from focusing on the new implementation and the reason is basically quite simple because there are some MSC vendors that simply don't implement 3GVPA over IP even in newer releases, these are mostly smaller core network vendors like Quartus for example, they don't do 3GVPA over IP but only SCCP Lite and they have apparently no roadmap to ever change that, I mean it's just what we hear indirectly from users and on the other hand the more classic larger operators that have Ericsson or Huawei or whatsoever, they only have A over IP 3GVPA compliance, so it's sort of a problem. So what did we learn? Well, the overall complexity is quite stunning now. Sorry, sorry, ah, or some coom, yeah, that's, you know, it was so, the complexity was so stunning I couldn't even write properly anymore. The absence of proper functional testing has caused lots of fallout, of course if we did have a test suit for the old stuff then we could have probably run the test suit before and after the split and we would have seen some fallout from that but actually the split architecture allows us for better testing, yeah with again typos, you can see I wrote this probably half asleep and it allows us to test smaller parts, I mean if you wanted to test only the BSC part before you just simply couldn't because there was no way to access only the B, there's only the MSC part in open BSC or an Osmonit B, so that's good and so testing has become my main focus in the last couple of months, yeah, so testing, testing and some more testing and even more testing beyond that, so what do we have in place now in terms of testing? What we always had is the unit testing in our C code which tests individual functions or APIs which is nice for like testing a message encoder or a message parser or something like that where you don't have any state or any complexity, you just have data in data out and you check whether the result is what you want, these we execute during make check, we now have the automatized functional tests in TTCN3 where we test the external visible behavior, right, the API tests, test internal API and the TTCN3 tests the externally visible behavior on all the specified interfaces, whether it's Avis, AG, SAP, GTP, MNCC, PCU interface, control interface, VTY interface, so these kind of external interfaces are tested there, we execute them right now nightly by Jenkins, we could of course do that more frequently, the tests currently take quite some time to run, most of it is test setup and tear down and not the actual test suit, so there can be quite a bit of optimization in terms of execution, it just hasn't been the focus, so the focus right now has been on test coverage and not on optimizing the execution time of the tests, but we could improve that and probably execute them more frequently, maybe up to the point of executing them as part of Garrett verification. Beyond that we have Osmo GSM tester which tests again the entire Osmo com, another way of spelling Osmo com in recent ten, so some cows involved with all the different components, it uses real BTS and MS hardware over coaxial cable and we executed, how often do we execute these days, Pao? Yeah, so basically it will execute the test suit and when it's completed and there are new commits ever since, right, it executes again, okay, so at least once per hour or more frequently if there are new commits and the hardware is not busy executing the previous test, so Pao will tell us more about what we do there tomorrow, I think, it's the time slot for this talk, that tests the overall system and not the individual components and it tests it on a very high level, so we don't look at protocol messages, but we just like basically use a modem to make a call and it's almost like user testing, but with automatic users. Then we have some interoperability testing where we do tests, one thing we have at Osmo com in the lab is what's called an ng40, that's a proprietary ran and core network simulator from ng40, I'm not sure where that percent sign is coming from, probably because percent is above the t-letter on the keyboard, and there we can test on the AGP and IU level and since it's both a ran and a core network simulator, we can either use the Osmo com ran against their core network or we can run the Osmo com core network against their ran and it can simulate millions of subscribers and hundreds of bts's and bsc's and note b's and so on and we can do that, it's not fully automatized yet, we do some basic testing that's in Jenkins, but okay so the comment was we're testing Osmo msc automatically or some, it's only very few tests, I think that yeah only location updates, so there's much to be done, much more possibilities there to be done and to automatize, but I would restrict that my mainly for interoperability since we don't want to introduce dependencies on proprietary testing tools, but it's always good to test against somebody else's implementation of course and not test Osmo com code against Osmo com code, yeah so what's the project health of the cellular network infrastructure, well we have lots of funded development, but primarily of course enterprise features that are required by professional users that actually have funds available to do funding, what I also see problematic is the dominance of sysmo com in those projects, sustainable fast projects don't have a single point of failure and that includes sysmo com as a company and I would much rather see more active participation from other entities and or individuals or research entities god knows what, but the fact I don't know what the actual statistics were I think about a year ago we did some statistics on the commits, how many of the commits were from sysmo com and from others and it was quite troubling, so we need more contributions from third parties, particularly those that benefit commercially of course because they should have some incentive, unfortunately we do have some players that do that very well, some known or some unknown, some public, some non-public, I mean you know that on waves for example is that's public fact, rock has been telling us last year about how they use osmo com in their maritime gsm network, we have others that choose to remain in the dark as to who they are, but we do have some commercial users that understand how that they need to support free software, but then we have some others where I'm more losing patience actually and I'm more likely to call them out anytime soon who basically we know are using it in commercial deployments a lot but who don't bother to send patches and or improvements and or contribute to a significant extent, yeah project health beyond other projects is quite disturbing, so osmo com data is basically dead since 2012 apart from some occasional fixes, osmo com bb has still not been forwarded to any other fight, I mean there are some attempts by one person mostly but it's very far from from getting to to completion, osmo com decks much to my dismay is completely dead, it's basically at one point it was already possible to run a deck base station completely with osmo com deck without any proprietary components so you could have a decked phone and an osmo com decked and then interface to asterisk without any proprietary base station, the allen core network projects are basically dead, I mean for sure they can be resurrected but basically there was never any contributions from anyone else with the c-projects at least we get some contributions, well which open source cellular network related erlang projects, yeah so basically you're saying there is a vans ship is working on a sick trans deck but okay that's not an osmo com project that has moved somewhere else and this is about osmo com project health, so I'm saying the osmo com erlang core network projects are dead but I'm not aware of anyone doing something with them outside of osmo com or just move them somewhere so sure other people are doing work, I mean there is mobisense that are doing core network related stuff in java, it's open source, I mean yeah yeah and but yeah I'm not talking about these projects here, simtrace is basically dead again and about to be resurrected as every year, no but now there's a lot of pressure to do so if I look at some other projects and I don't want to this is not complaining this is just I've just been just been looking at different git repositories and statistics and I see that there's very few commits in gr osmo str, I see that RTL str had no commits in three years I think it's fine I'm just stating facts this is not a judgment yeah that's fine I'm just saying you see you see you see my last point it's not that bad see next slide so we have some some activity in the osmo com bb world which I'm very happy about there is grgsm fake tier x and tier x con work by awadim we also had the word file work earlier by now this is embarrassing Sebastian yes yes yes yes my apologies yes of course we have osmo com analog which is very active but it's it's basically jolly's child I'm not sure if anyone else has contributed much I mean at least not from the classic osmo com community I'm not aware but okay you gave me more yeah it's yeah yeah it's it's silent contribution anyway but I really enjoy to see so much progress there he's implemented not only Arnett's bayonets and senets but also he's implemented amps the american analog telephony and he has also implemented the what's the the nordic one nmt yes so it's really it's really getting complete yeah all of analog yeah yeah okay yeah so the comment was the global star satellite phones the analog all once use amps too so there might be some collaboration there so now soon we will have osmo fl2k soon which is great so if we look again at the network stuff that the rand side is quite strong and complete these days sure there are always things that you can improve but the bts and bsc I think are it's also something where we focused our attention also in the terms of testing so we will see that osmo bts and osmo bsc have many more ttc and three tests compared to osmo msc or osmo hr and that's quite how can I say intentional because there are lots of users who have an interest in using the ran even with third-party mscs and so on the packet switch ran suffers from a lot of lack of attention that's osmo pcu where we don't have any automatic test suite with decent coverage at all and we still have lack of uplink multi-slot and many egbar as features so it's still quite in desperate need of attention I started to do some osmo pcu tests in ttc and three now which I'll get to probably tomorrow maybe but there's still a very humble beginning but we want to have tests that test let's I think for example now we have a test for uplink tbf establishment so you really test very low level transactions or things that happen in the physical layer and not a high-level testing from a user point of view but really individual procedures or individual events and so on and the msc and hr I think are in a healthy state now again or at all but they still lack tcap or map capabilities which makes the limits or the usability of them restricted to non-roaming networks non-roaming means I mean yes you can of course have roaming but not roaming with existing operators since there is no related interface and the packet switch core network yeah yeah the microphone is in front of you sorry yeah it's not only non-roaming but also networks which are not interconnecting with any other proper carriers because for example you can't exchange sms you know without map with any other proper carrier yeah um I'll speak about that that's that's that's correct but on the other hand I think there are probably not so many use cases where you would just want that without roaming capabilities so it's a bit um yeah so the packet switch core network I think are in good health more the ggsn even than the sgsn uh sgsn now has ipv6 support yeah even with support um and kernel gtp acceleration there seems to be some well some users say they cannot get it to work but we will investigate that very very next days there's also quite a bit of inquiries from commercial users in this area so I'm I have high confidence that we will have some working and and performing solution there we have created a test bed now but haven't run any performance tests yet at sgsn we have three machines interconnected with 100 gig ethernet cards and I want to benchmark the kernel gtp code as to what what kind of throughput we can get with the existing in kernel user plane and uh user space control plane so outlook um 2g is still in demand uh and we have lots of use cases whether it's rural network maritime networks and so on if we had teacup and map many more deployments would be possible um but then uh typically the kind of inquiries we get they never really uh want to um fund related interfaces so well I mean you get what you pay for so if you have no interest in investing in teacup or map interface well then you also don't have one and you have to go somewhere else I think that's fair um the 3g user has some users but uh I think the lack of a fos r and c limits us to femtocells and that makes it not very interesting outside of lab use um and I don't think this will change so that's also why in terms of sorry well not everywhere um and again thinking of what kind of equipment you can deploy inexpensively that gets decommissioned elsewhere um there's quite a lot of uh capacity and capability and we have at least two uh actually more than two commercial customers if we had a solution for 3g macro they would immediately deploy it but we don't have anything um so it's uh it's not such a uh a theoretic option um but yeah in absence of an r and c and I don't think anyone has an interest of doing that um there is no um and there's no soft r and c that I'm aware of that you can could license even proprietary as a as a pilot or something just nobody does that so that's not really any uh any future um and uh beyond beyond lab usage um and um that also explains why we don't have any tests yet in ttc and three for the 3g interfaces it's possible but uh I mean writing test cases uh and we do have sort of it's easy to adapt to interface the protocols we have there but writing test cases uh it's just not going to be a priority anytime soon 4g of course is deployed in parallel to 2g in many scenarios uh what I think we need to look at is 2g 4g integration that's the sgs interface that's gsub to diameter translation um and uh I think uh what we need to do is contribute to existing fast 4g projects in that area um maybe starting by those interfaces so implementing sgs on our side and also implementing it on the other side maybe and and have a good interoperability there yeah and uh what about uh uh extending hlr to support hss as well for example because that's one of the I don't think it makes sense um the osmo hr that we have today is nothing more than a simplistic reference example of how you can implement it but it's not it's never been designed as a large scale hr or something like that it's really just a small um database and I think it's rather more likely that uh we um we have a gsub to diameter translator and then have an like an external hss that uh would find attention to but we'll see um at least that's my point of view and the irony that sort of I find always uh disappointing is that it's very possible to do properly funded osmo com development um these days but we have less people involved than in the early days um that's sort of a problem sorry but it's still uh I mean I think actually in some ways it's it's more structured than before so um it's less well um I back to differ but okay um um so uh yeah but I think it's sort of it's sort of uh a pity and the other point that I don't have here on this slide is that uh also um it's we it's very easy for us to to find a project work related to 2g or even 3g but uh it's almost impossible to find some funding for open source 4g at least that's our experience not sure if somebody else has other experience but uh there's almost no interest and the inquiries that we get is extremely 2g oriented still today um um yeah so outlook uh but I think the original activity of the original developers has decreased and we need to attract more developers um and uh yeah um otherwise I don't really see much of a future and we need to um distribute the uh the involvement and have sysmo com less as a single point of failure there okay yeah so osmo com needs you uh we've lost too many friends already uh please don't leave osmo com please don't leave me otherwise I'll uh have to uh cry in my bed okay um thanks and uh I think I didn't manage to well okay yeah 10 minutes earlier so rather than taking questions now uh I think well okay one feedback from the earth okay just because we mentioned the nitby split again I wanted to mention that some I found five points that I should have included in my talk and I added it to the schedule there was just except all our l lp osmox transcoding between 2g and 3g and the e1 bts support that should have been mentioned there so might more might be added if you take a look in the schedule yeah okay these are additional topics that need to be looked into okay um yeah so uh we will wrap up here um at ccc Berlin please make sure you take all your personal belongings um and don't leave anything under the seat or above uh because tomorrow we will be at e n berlin um links is back there maybe you can just quickly identify yourself in case people are not familiar with you he will guide the group through berlin public transport to the restaurant um where we will have uh dinner soon um please try to leave as soon as possible with links is to go there I will go separately because I have to transport all the equipment and stuff with my car so I will join you there as soon as possible okay thanks