 Ah, okay. And now we have even more famous typos. So we have a calular infrastructure. I'm not sure if that's related to calluses, but Okay, so we have a roadmap and we have a bit of a discussion or presentation of the roadmap At this point of the day before we head into lunch. Once again, lunch is postponed by half an hour as indicated earlier so Yeah roadmap, so well actually let me increase the font size so Luckily, I don't need a mouse for that So let me basically start with a bit of a disclaimer. So, I mean this this all started with people like Dieter or Holger or Daniel or I Who who basically invested spare time and we did this because it's fun and it's still fun today. It's a lot of fun But at some point, of course, everyone needs to earn money and in the early days We had a regular day job and which was unrelated to that I did a net filter stuff or whatever or some some other work and We did Osmo come for fun And then we got first traction by luckily some operators including on waves, which we will hear later about today Very happy for their support even very early on in basically funding some of the development that we guys will be doing and Well in in this context this has continued and now we have For example sysmo com, but we also have lots of freelancers. We have other companies in in the in and around Osmo com Like fairwaves and so on and who are able to base to do development But in the end the development is that the development that we see today Is driven by well either what people are contributing patches for so no matter what kind of road map I put here on a slide who is going to do it if you know somebody somebody has to do it in the end or of course what companies or Consultants or whatever that can get contracts for so if they do a freelance work or something like that So yeah, basically unless somebody commits to putting resources in whatever form and that's not going to be much behind any kind of roadmap so But in general sort of what's more visible on the horizon Is I think the following five items So splitting up the network in the box news has already given quite some preview on that in his talk about the 3g work Where right now we basically have a need be that split in two parts and only one of the two parts still works Which is the msc part? In the context of 3g we are now Implementing the complete a interface between msc and bsc and then basically all networks will Look like that. I'll have a couple of slides about that code quality issues in general which sort of relates a bit to testing We have the integration between 2g and 3g because right now they exist in parallel universes and there's no Interrat handover or something like that and also improvement of external or addition of of external interfaces Which sort of all relates to what we've been hearing today. There's no grand You know master plan about a roadmap what we will do in two years from now because as I said It doesn't really matter what we put on here on these slides. So the network in the box Has been at the heart. It has lots of lots of issues. We already Discussed that at least if you go in a deployment beyond your desk and now Rest in peace network in the box long live Osmo msc So Osmo msc is the network in the box minus the bsc and minus the a-s-r In some okay, I stay with this slide too fast So we have this HR with the G sub interface. We will have the a over IP interface Where right now the worker or so far most of the work has been in the lower layers But we now have a brand new sccp and m3ua stack which is in live Osmo sick trend So all the lower layers underneath the the a interface protocols we Have the IUCS and IUP S interfaces in the home not be gateway, which what Niels didn't mention are in the current Code are over SU a the sccp user adaptation, which is not 3gvp compliant to have this kind of stacking So that is now also in branches not in master is Moved over to this new m3ua sccp stack And we want to basically merge all those branches and move to a single code base For 2g and 3g to have all these features integrated And this also means that the nitp is gone and for a 2g set up You will have Osmo vsc and Osmo msc and Osmo hr running So the network in the box can still be there, but the box is then let's say No pun intended a virtual box or a physical box And you still have you have multiple processes inside And now one of the challenges is How do we transition to introducing all these interfaces without making the configuration much more complicated and introduce many more ways to configure it wrong in a non-functional state and This is some of the time that I've spent on thinking about how can we be compliant with this 3gvp interfaces But at the same time sort of abuse or interpret or extend them in a way to avoid having all this configuration Inconsistency that that can and having to understand many more protocols and so on so one of the parts that We will also have in this setup and which in fact we already have but not in master is also the Osmo Com STP which then acts as a signal transfer point for all these sccp connections with m3ua It's used only with the a and iu interface at the moment So don't and I thought I had a slide about this, but okay. Sorry for that That's going to be in there and basically this is going to play a key role in assigning the addresses and and Avoiding having all kinds of configuration only on on those new interfaces another Yeah This is basically about the split the other thing that we get by Merging all this new world for which we don't have a name yet Basically is we introduced as news already said also the and Max referenced it the Osmo Com FSM Infrastructure which is a way how to how we can abstractly describe finite state machines in C So quite powerful construct to have Very good well-defined state machines with timeouts it in all places with introspection and so on and The old nitp doesn't have any of that because it's much too old for this infrastructure but the new Osmo MSc and the wheel our code in there has it and Some other parts of the code also have it so we get this the other thing where we'll see progress I think is on the Osmo Com primitives which is how we encapsulate primitives between protocol layers This has been around for quite some time. I think ever since Osmo Com BV actually but in a very How can I say minimal use and I would like to Get the Osmo Com primitives also in in a state where they can sort of self describe themselves always a general way So you could basically print primitives at any layer boundary or something like that So you can really see there is a primitive now going from left to right and this is all the parameters of the primitive without anyone having to write Code that writes print F statements or something like that because one of the advantages of Osmo FSM is also and All of the logging like which event happened which state transition has happened for which particular instance of which FSM all That is handled by the core infrastructure and you don't have to put print F So whatever our log statements into the code anymore. So we have lots of code that doesn't have any explicit Log statements anymore because all of this is handled implicitly and that's with the primitives. I also would like to see that Yeah, sorry. I had the slides. So the Osmo FSM. We have introduced in several places in the OM 2000 code for Ericsson That's the OML protocol of Ericsson connection oriented SCCP M3 UA SUA the the application server process state machines all the VR FSMs And also the AMR GTX state machines that max recently introduced in Osmo BTS use this We have some candidates that we would like to convert this is lap D lap D M code which still giving trouble even after all those years being used because of some Well, some some untested code pass or some, you know, not so explicitly coded Parts it would definitely benefit from that the ABS OML managed object Which is what is used to bring up the BTS also definitely needs some more formalization It's it's basically a big grown hack ever since the first BC 11 support Would be nice to also convert core control to Osmo FSM because then you could also have introspection about in which state The call is currently in from some external Visualization tool or whatever you might want to have And it might even be an idea to model those state machines on the camel final the camel Call state machines. I'm not sure if anyone is familiar with that But camel is the customized every coach customized applications for mobile enhanced logic Which is basically how a lot of prepaid control and so on is done in seller networks I'm not saying we want to support camel but I'm saying well if we introduce more formal state machines We could make sure that our state machines at least look like Something that could be used for camel at some point in the future Yeah, of course well, but then these kind of infrastructure internal stages I'm saying yeah Who wants to invest in that any volunteers? That's that's the big problem that you know If if there is commercial support or commercial interest, oh, I need this interface or this new driver or I need this feature But you know real Infrastructural improvements is always difficult of course Which also applies to testing. I mean the unit testing code of coverage of the code Well, it exists and we have unit tests everywhere and as Holger mentioned it is a progress, but Still the coverage I didn't measure it But just from knowing the code the coverage is not all that great So that needs more attention New code coverage is generally much more better. So code that was introduced the last two years or so has much better unit test coverage than the old code that has been around for forever and this control interface introspection into the final state machines that max mentioned can also help us to write even better testing because now you can send a message to Some implementation this message creates a state machine or transitions a state or something like that And then you can check if that state change actually has happened in the code as it was expected and on the other front like going from the unit tests To systematic and to end tests. We have something called the Osmo GSM tester Which is a Python framework for doing actual full system tests So basically you use a bank of GSM modems and you use a coaxial RF network and you use one to many BTS's and then There is lots of Python code that can basically start all the network elements execute individual test cases like like make a call from A to B Send an SMS to from A to B register unregister something like that and this basically doing a full test from a Phone basically to the core network or from a phone to a phone even in an automatic fashion and that's Has made great progress We're already doing basically a second version of the code architecture right now. It's rather finished. What Neils has been doing We also have created quite comprehensive hardware setup To enable us to do this and then we can also test across the different BTS platforms because initially it was easy We had to be a 11 and that was fine and we had to be a 11 and another BTS Okay, two BTS is to test something on you know, but then Nokia and Ericsson and Osmo BTS with You empty Erics with a usrp You have the sysmo BTS you have octazic you have you know all kinds of different Models and it explodes if even a simple call test between A to B You need to be able to systematically execute that on all the different platforms and and get proper results And that's going to be really soon now To have this system up and running we will not do this for every commit of course I mean probably takes hours, but maybe once per day have like they can take a nightly snapshot and and do the full test run for all these test cases Yeah, sorry, I always speak ahead of the slide so We were occupied by a lot of problems with the modems we initially choose we now have hardware that supports mini PCIe modems so we can basically Use any modem I can choose the modem based on how well it works not based on what is available in the market We don't have 3g support in the test cases yet. So that also needs or 3g even Starting the the Osmo msc and starting the the Hobno p-gateway and so on so that's not part of it We don't have voice testing as such and we can do Signaling testing but voice testing means you also need to look at the audio. Does the audio actually get through? and then Getting through is not sufficient because you know are there dropouts are there maybe RTP packets being dropped So this yet another domain that needs to be added to to the Osmo gsm tester at a later point to Be able to have actual tests of the voice stream because just the signaling is fine Okay, but how do you know that your RTP traffic is getting from a to b? That's a completely different question and Must be tested separately Okay external interfaces. Well, you already heard about control and vty Yes, definitely on the roadmap to put more effort into the completeness of the control interface but Really, I think the the easiest way is if people just tell us what they need in the control interface Then we can add it is typically adding Exposing something over the control interface is super easy if it's just a single variable or something like that This is really like two three lines of code literally to expose a certain setting or to make it configurable over the control interface but for us, it's really hard to predict all the different things that people might want to configure through the interface and the vty interface Get automatically added during development because well, what do you do if you write code? You want to check whether it's working and you use the the output of the vty to see what's happening as a developer But the control interface you don't automatically add yourself Because you're a human being and not a program. So as a human being you use the vty interface and so the control gets left behind Yeah, and then we have as max already said the grand unified config theory Which Yeah, I'm not very optimistic that much will happen there I mean, I definitely have lots of ideas about the architecture how something like that should look like But yeah, as I said interestingly There's nothing to be found in the free software world that does anything With the with the kind of requirements even near the requirements that we have most of the config Management libraries or whatever you can find in free software are about reading a config file when you start up And then never changing any of that and that's not what we do So we need this interactiveness. We need to be able to read write the config back from the running configuration And so on that's to any anyone who is not like in this specific world of network infrastructure. I don't think anyone has seen that And it's it's pretty alien to a lot of software out there Okay, the integration. Yeah, I said already also We need the cross advertisement of neighbor cells. There's some improvement already. So We can now advertise I think 3g and 4g neighbor cells and gsm max has been doing quite some work on that Also we can advertise the 2g neighbors from the femtocell from the 3g femtocell because that's actually a feature of the femtocell itself Not a feature of our code So those two feet things already exist to some degree But of course, there's no mobility between the two worlds and particularly no handover. That's where it gets even more interesting Or even things like which I always wanted to do combined packet switched and circuit switched attach Or SMS over packet switched services also something that I would have wanted, you know, five years ago or so, but yeah, you know There's only so much we can do In terms of operation and maintenance also We need to Improve and there has been some work already we generate more or we have the capability of generating OML alarms now in the code which we didn't have for a long time in in Osmo BTS Those alarms get reported back to the BSC and the BSC can then issue a control interface traps So basically if you have let's say a hundred BTS's all the alarms of the BTS's can get reported today already in one location rather than at 100 sites But we don't generate that many alarms yet So basically what we need to go we need to go through the code and see what kind of abnormal situation should actually raise an OML alarm And to to what kind of events are The events that we want to notice in the first place Also in terms of statistics and counters a lot of work has happened last year in Exporting all the counters and exporting more counters Particularly regarding key performance indicators On the control interface there it is useful There it is nice that any counters we add automatically get added to the control interface right because part of the infrastructure So as soon as we add a counter somewhere the counter is also accessible through the control interface Without adding a single additional line of code. So that's rather easy also to add counters But then with a lot of these key performance indicators, I mean you can read through all the the the papers and what kind of Values are defined as as key performance indicator of any part of the gsm network The detail is then always quite interesting, right? I mean do you counter traffic before or after compression is the header included or not, you know, there's all kinds of Details that are not so clear. So we have added quite a lot of counters But I don't think we have received much feedback on on how useful they are or if people are happy with them So if you are into looking at the performance of your network, definitely we would Love to hear more What we don't have at all in osmo-com is the like any kind of tool to aggregate or interpret or do analysis of that Right. So we have focused on generating data at the moment And then hope that somebody consumes them in some way either by just feeding all of that into grafana or whatever Just whatever kind of tools people want to use these days to work on such data sets But yeah, that's that's not really out of I would say it's a bit out of scope for us But it would be nice to at least have some reference implementation some some simplistic Tool for people to to look at so this is more wishlist than roadmap now The other parts are more like to some With a higher probability and and already in progress to some Definitely we want to move the smsc out of osmo-msc And thereby get rid of the last database part and the basically we want to be able to compile without any sqlite dependency How exactly it's going to be happening is open still but it's definitely something we want to do The gsub to map gateway hogar has written something in in small talk to do that But it's only for the gpr side of things so far So definitely it would be on the wishlist for me to have some way that we have gsub to map For both circuit switched and packet switched billing interfaces comes up every so often by various users, but then In most cases, they don't really know what kind of information they want And then we have this situation like, ah, we need a billing interface and we say, yeah, okay What do you want and they say about we need a billing interface? But what's your billing system? Well, we don't have a billing system, but we need a billing interface Okay, so we need to do something but apparently the typical users who requested from us are not capable of really explaining to us what exactly they need so probably we need to do something In the hope it will be useful without knowing really what users will use. So it's a bit chicken in the deck situation, I think Yeah, and then well my big wishlist item would be to also work on LTE stacks from the MME upwards I don't think there's much point in trying to go from the MME downwards to go into basically Doing an E-Node B or something like that Doing the RSC protocol and all the scheduling all the low-level stuff. I think there's unlike in in In UMTS, there is plenty of available LTE hardware out there from all kinds of vendors small and big and in all forms and shapes So I think our strength is really the the protocol parts and it would be quite interesting to do something And yes, I'm aware there is open LTE. I'm aware there is open-air interface though Open-air interface is to a large extent not open source Even though they claim it. It's not an OSI compatible license I think there is something we can do there and I would want to do something in that area But yeah, it's it's again a question of priorities and where can we from where can we cross subsidize or get project work in that area there is some some hope but I'm not Extremely heavy and the the technical issues here as well. We don't really have good asn1 tools for C In in the free and open source software world And I actually think that's the biggest issue at all in in free software telecoms That there is no good tools not only for C, but also for other languages. It's rather limited unless you go for Erlang and maybe now small talk. I'm not sure what's the state. I I cannot judge myself But I have heard good things about there, but outside It's it's really problematic if you want to go for information object classes and Unaligned packed and aligned packed encoding rules and so on So basically, which means we either have to ditch C for doing work on those protocols Or invest a lot of time in tooling And I would be very happy to even buy a developer license of a proprietary Open source Sorry a proprietary asn1 compiler, but the problem is they always come with run times that are incompatible with free software So you cannot really use them either So that's a a big problem Otherwise we could just have the compiler and basically Every time somebody does a commit on the asn1 source the server regenerates the the C source code out of it on the server and it would be fine I don't think it's a problem for open source development if that compiler would be non-free But as that the compiler needs a runtime and that runtime is incompatible and so we cannot use that so that's sort of the The stalling issue there. Okay. Once again end of file and we have five minutes for questions ahead of lunch. So questions Okay, well, I'm not sure where the second microphone went but I can just give you behind you suddenly magically a microphone appears This way. All right Just a quick question about the database getting the sql light out of Getting the smsc out of the asn1 vsc So that the only component that would be accessing the database then is the hlr And the smsc the external and the smsc. Okay, but that would be handling whatever way it's doing it So is there a plan or would it be an idea to have abstract this database layer so that it's not limited to only sql light and could be using other databases Well, if you look at the code, that's actually what we tried very early on right we use dbi which has support for different database drivers It's just that by using dbi we have basically introduced so many problems and performance penalties and bugs that never get fixed That it was not a very nice experience to say so Um, uh, and I'm not aware of any other real C language database abstraction libraries that you would want to use at that point Which would improve it and then in the end. I mean, I've done a lot of database work in in the past like long time ago And every database has different parameters anyway, and it needs to be has different data type issues and and so that's I'm not quite sure really how Useful a generic layer is um at that point or whether I mean whether it It doesn't make more sense to have like a dedicated database driver for for each particular database that you want to support in the code itself something I did in other projects, which I found more Comforting than using one of those general frameworks So for example with dbi all the binary data gets wrapped in like they they transcode from 8 bit to some whatever I say you you encode format. I mean, it's not really you encode but some base 64 or whatever And they don't use the binary native data types of the databases And so if you use an external tool then the and you read out a binary It's not really the binary, but it's some some mingle data that the dbi layer has translated and so Yeah, that's lots of issues I mean also what let me maybe say this about osmo hr Osmo hr I see more as a like it's a really minimal reference implementation of an hr So this is not what what I think you should use for a real large network This really just we implemented something the minimum necessary to talk the g sub protocol and to perform the tasks that are required so uh, I I just recently heard there is now a Python implementation of an hr. We'll hear probably a bit about that later in the In the community cellular manager talk later this evening where they have implemented the g sub protocol in python And they have a different hr in there for example, and I'm completely open to I mean Whatever people want to do there. It doesn't have to be the particular Osmo hr code that we have right now Okay Good then finally, um, we can go for lunch. Oh, sorry. There was a my apologies. Please remain seated fast in the seat pills I can I can suggest a very simple way to to solve the smsc issue you mentioned before You can use the transaction mode of smpp It's a very simple way to avoid any storing in the net maybe that's correct Yes, this we implemented the transaction mode exactly for that use case in in osmo net b that There's no storage involved, but then still it means we would have to supply a reference smsc That is external that uses this interface and actually there's some more details like how do you handle let's say The the the queuing of messages and the delivery once the subscriber comes back and Also, if you think more now with our hr and more in an s7 like world The hr needs to have something like message waiting flags and you know, so so Yes, but in general I agree that is Likely one way to do it. Maybe even the way that we will do it