 We get to Osmo-com and LTE, which is sort of a bit of a sad story, but So why don't we have anything LTE related at this point? Well, most of what we do in the seller network infrastructure side is done by people who get paid for what they do and That means the focus of the work is mostly determined by where customers are putting the focus and There's basically a lot of customers that still are interested in 2G related stuff and Not so many interested in LTE related topics So that's why at least that's is more calm we haven't been seeing lots of LTE requirements, so we don't have anything native related to LTE and Osmo-com We do have some LTE related bits that were introduced over time one of it is we have support for Thanks to Max. We have support for SI-2 quarter support broadcasting, which is basically the system information message in which Eutran that's evolved Universal Terrestrial radio access network So LTE basically neighbor cells over GSM The encoding is how can I say quite interesting Definitely among the most complex things you need to encode in a 2G network, I would say So That we can do and we have this SGS interface that yesterday Philip already spoke about so I won't be covering that but these are sort of the only two parts that we have So but irrespective of whether it's Osmo-com or not What do we actually have to do if we want to run a combined 2G and 4G and of course The same applies more or less to a 3G and 4G network, but 3G is not so interesting to many people. So Basically, there's three different things that we need to do if we want to run a combined 2G and 4G network and that's Basically, the first part is we need a shared subscriber database Which is well relevant for multiple topics, but the most pressing need is in order to get authentication from there We have also the advertisement of the respective neighbor cells of the opposite or the Complementary technology and we have to have a shared packet switch tunnel endpoint So that when we move from one technology to the other We can keep our PDN or PDP context and we keep our IP address and packets continue to flow So Optionally, there's some steps like the SGS interface that Philip has covered yesterday There's also optionally of course the what's called interact PS handover. So that's packet switched handover without any loss of connectivity and Also, there's something called SRVCC, which seems to be the Not a grand unified theory, but it's sort of the ultimate Stage the highest stage of consciousness or complexity for several networks if you ever looked at that that's really Mind-boggling. So the shared subscriber database Yeah, as I said, we mainly required for authentication And if we want to have a really poor man's approach Actually, it's not necessary to have a shared database because you can just put the same key information in the HSS and in the HLR Of course, the sequence numbers will not be synchronized So you will do a resync on every authentication, but the phones will still be able to attach It's of course not sufficient. So the proper solution is to have a single HLR or HSS Which both has G sub which we need for the Osmo-com 2G and 3G stack and diameter which is needed for LTE or in absence of that a diameter to G sub translator which basically would make the LTE side use Osmo-HLR or G sub to diameter translator, which would make the Osmo-com stack use an external HSS So these are the three solutions for that And I think I'll talk a bit more about what I think is realistic or what I would want to Work on there. Now, that's sort of the shared subscriber database part. The next part is the advertisement of Naver cells Where the GSM side must advertise the LTE neighbors and the LTE side must advertise the GSM neighbors So for SI 2 quarter, it's in the code for years and Osmo BTS and if you look at the Output of let's say a Thames phone, which is a phone that has a monitoring software proprietary which gives you decoded RIC and other messages. It actually looks nice But still in practice somehow it doesn't always work for everyone and We need to figure out what exactly is the problem there so we have Reports from users where they say, oh, yes, my phone shows all the LTE neighbors But somehow it never selects an LTE cell So there's still something about the cell reselection parameters or some bits somewhere that maybe Even though it sees the neighbors, it's not switching over and I don't think that is something That relates to the LTE side because right now the phone is camping on 2g and somehow it's not it's sticky And it doesn't doesn't want to move over So we need to do some more testing there on the LTE side it must advertise the GSM neighbors and that's unfortunately very vendor proprietary because there's nothing like OML for for the S1 interface so every LTE not be has some other vendor proprietary mechanism by which you can configure the contents of the system information blocks which Includes the neighbor cell broadcasts or typically have some kind of MIB Or some XML interface or what where you can insert the GSM Arfkins on which Or which the LTE cell should advertise as neighbors So both of these Generally work. So we don't really need to do much there and the third part is This shared packet switch tunnel endpoint Which basically means that you have the same APN and the same IP range in the same pool and so on whether you establish a PDP context over a GPS or whether you do a PDN context on the LTE side And the proper solution. Well, there's even two solution topics here on this slide so it's very Anyway, so We need a combined a packet gateway a P PDN GW or PGW and GGSN functionality and if you look at what's out there in terms of free software There's the ERGW the Erlang gateway, which is an Erlang implementation that actually supposedly covers both GGSN and PGW functionality Untested in a sense that not I'm sure somebody has tested it But as in we do not in Osmo-com have experience in testing that functionality And it's rather complex and for sure nothing that you would for example run on a small embedded device And Osmo GGSN on the other hand only has GGSN functionality and doesn't speak a GTP version 2c Which is the control protocol that's used in in LTE We only have GTP version 1c And next if you see is packet gateway on the other hand has only GTP version 2c support and no GTP 1c support. So it doesn't do GGSN solution. So Doesn't do GGSN functionality So we can either play with Erlang ERGW and see if we can make that work or we can For example adopt the next EPC Code generation because what they actually do in next EPC is I'll talk a bit more about this later. They generate the GTP to See encoder and decoder routines from parsing the spec even though it's not written in ASN1 and By modifying the code generator we could at least generate all the message encoding and decoding in an Osmo-com style way and use that in Osmo GGSN and Yeah, so that Might be one way to to add GTP to C to Osmo GGSN to add this functionality Well, SGS interface As we know we already implemented Mostly needs interop testing with other entities and we already found some unnamed Larger brand vendors who were unable to read the spec which very clearly states how the host names are to be encoded And they just send a string Yeah, so that does some interop testing and work around for bugs in other stacks But otherwise that's done and then the point is yeah Interrat packet switched handover and that's where it gets interesting if you remember yesterday's circuit switched Inter MSE handover presentation Packet switched is Slightly easier because you don't have to forward voice calls over SIP in parallel to other things But still it's rather convoluted and it adds lots of interfaces to the SGSN Which we don't have at this point So if you look at the diagram of a combined 2G and 4G network Then there's two additional interfaces called the S3 interface between the MME and the SGSN And an S4 interface between the SGW and the SGSN And you need those interfaces in order to do it. I don't need I don't to be honest I don't need I don't know the exact details. There is some Resources on on the network, but basically since both of these are GDPP2C based and we don't have any GDPP to V2C at all yet It's rather a long way if we want to support that I mean we don't do packet switched handover between 2G and 3G yet neither circuit switched handover But that is irrelevant in this context So I think that's quite quite a bit of a row to go there if we want to go there Because this also ties into how Cell changes are done In GPS so not sure if you to be yeah, I don't have a yeah enough time so I can talk about this The traditional way So if you start with classic circuit switch GSM the way the cell change or cell reselection works as long as you in idle mode As long as you don't have a dedicated channel the phone autonomously selects the cell and camps on it as soon as you have a dedicated channel open it's the BSC that's in control of switching cells So the phone reports all the measurements and the BSC computes what might be a good cell and then performs the handover there In GPRS the classic way. I mean you don't have a dedicated channel So you don't really have that distinction in GPRS basically the the fundamental Basic level of functionality is the the phone always chooses autonomously the new cell And even if you have TBFs active The phone will still be in charge of doing neighbor cell measurements and then switching to a new cell at its own Completely without any interaction with the network So it will basically pop up on a new cell and it will start to send LC frames And then the SGSN needs to recognize that and and move over and if there's a rooting area code change or Routing area identifier change and it has to do a rooting area update in practice That doesn't apparently doesn't perform so well if you are basically using a lot of time slots and Have a very high TBF usage because the phone then doesn't have a lot of time to do all the neighbor cell measurements and to and so on and so on and that's why apparently later in the specs they added Network assisted cell change it's called NACC and with NACC basically the PCU or let's say the network side can request the GPRS attached phone to perform measurements and to report the measurements back to the network similar to how it works on the BSC and in dedicated channel and then the network can basically either make Suggestions or actually instruct the phone to to switch to certain other channels as it roams around and We don't have any of that. So we always have only the basic functionality to make the phone autonomously change and The interact handover requires I think Or at least as far as how I understand it requires some of those bits. So that's basically Gaps in between what we have even on 2g and what's required to really do interact handover properly Yeah, so I don't think this will happen really soon unless somebody puts a lot of effort into it So the the logical steps to summarize to to improve our LTE interworking is Well the first Step how we can play with this is to have the split HLR HSS and split GGS and PGW That's actually if you put up. Let's I mean what does this mean? It means you put your osmo-com network next to let's say an SRS E-Node B plus next EPC network and you just put the Imzi's and keys in the HSS there and in the Osmo HLR on the other side and you advertise the neighbor cells And you use the same MCC MNC and that's basically the that level of integration and you can do that I played a bit with it. It's not great, but that's sort of the first step that you can do today And then the second step for me would be to have this G sub to diameter translator Preferably in the way actually a diameter to G sub translator and Then the beyond that that the share GGS and as a follow-up step. So This translator Yeah ties sort of in the next talk, I don't really like the HSF of next EPC so much So I think I would rather have a translator and that At the minimum you need exactly for the diameter messages that you need to implement So we need to implement exactly for messages that we translate to the respective counterpart on the G sub side and that's it so it's a rather simple piece of software that I hope we can hack up in a limited amount of time and Then you can basically you don't have an HSS on the on the LTE side But you just use Osmo HRR for that Yeah Okay, that brings me to the end of that talk Finishing ahead of schedule. Does anyone have questions comments feedback? Yeah So the G sub was initially born as a replacement for map because map is super complex and obnoxious Diameter seems to be much easier. So why don't we just speak diameter natively between HLA Jujusen and so on Because there are no Maintained diameter implementations outside of Erlang in free software That I'm aware of at least let's say there might be something in the Java universe. I'm not aware of but There's I'll talk about in the next presentation how next EPC does it and yeah, it's it's not so nice So actually for the for for a very initial G sub to diameter translator I mean the easiest way would be to use TTC and 3 of course That's just for lab use because we have both diameter I mean Ericsson has released the diameter code for TTC in 3 and we have G sub in there So in terms of code effort, no, I mean, I'm just saying you know for a lab But for a more realistic approach, I would actually do it in Erlang because of the the Erlang diameter stack Which is also yeah, it's not really nice to then have the dependency there But yeah, I mean just to make it work quickly one can always do something else different in the future Maybe finally we can some some day starts picking diameter. I mean the idea of marks I really like it like instead of making our own protocol. We can just use diameter in 2g to like interact with Yeah, but I mean so you have to change all the existing code for gaining exactly the functionality that we already have today I mean, oh, I pushed some button. Is it still working Kevin? Yeah, okay They were for second clicking sound while touching the mic. So anyway In I mean We are working on projects that have a scope That's incredibly large and the scope that's growing all the time with all the new developments that are happening So I think we have to be very strategic as to where we spend resources and and we're not and anything that already works sufficiently well Without any fundamental problems. I would not in you know, spend effort on it So if G sub works and it has worked between HRR, MSC, SGS and Keep it that way and then you translate if you want to interoperate with other devices now ripping it out and replacing it with diameter just because it's More elegant or whatever. Yes, it can be done, but I would rather Suggest that people spend their effort on implementing something that doesn't exist yet Rather than re-implementing something that already exists. But of course everybody can spend their time like they want I'm just saying There's so many things and I mean diameter is also not the end of the universe, right? You know in in 5g there is no diameter anymore So diameter actually has has a lower shelf life than map ever had right, so I'm not saying it's bad or anything. I'm just saying it's it's already been phased out again with the next generation of Cornetwork protocols What's in 5g? Maybe we can start with that already it's restful webs No rest restful web services specified in open API over HTTP 2.0. Yes yes And if you look at it, it's doing exactly what diameter did before which and diameter does exactly what mapped it before So there's no technical reason whatsoever other than you have to reinvent the wheel all over again and pay You know thousands of developers to do something and and you have new patterns or whatnot, but I mean there's no technical reason whatsoever Well in any case I'm just saying yeah any other questions comments So regarding this Translator translator. Do you see it's a separate application and You said that you plan to use Erlang implementation of diameter So for G sub do you plan to implement it in Erlang or yeah? Yeah, I mean it's not so much It's not so complex we have implementation of G sub in Erlang, but I will discuss maybe we can just open source this part It can be reused because yeah, that will be great. That would be great. I'll discuss with Alex. Yeah Yeah Yeah, yeah, that would be useful and definitely help that along because it's Even it's just the encoding decoding part right I mean all the logic is Can be outside, but just the encoding decoding functions Yeah More questions comments or Do we close that who who here has played with LTE in this room so far Okay, at least half or so. Okay. Yeah, should have raised my hand, but yeah Okay Yeah, then thanks and