 I'm Phillip Meyer. I'm talking today about the SGS interface in OpenMSC. Yeah, how do we go forward? Okay, yeah. Well, I will start a bit with circuit switch fallback. What's the idea is behind it and then I will talk a bit about the SGS interface and at the very end of it off the implementation details as we already have that feature in Osmo MSC, so there's an implementation. Yeah, first of all, there is no CS domain in LTE, so LTE is a pure packet switch network, so it means we have no voice, no SMS. Of course, that's not entirely true. There's a substitute for that, which is called IMS, the IP multi-media system. And we have, I mean, you'll probably know that anyway, we have these voice over IPs, these Volte, which are so sometimes written in the newspapers. And not so commonly known, we have for the SMS substitute RCS, it's the rich communication services. So basically, SMS is seen as a legacy service. Okay, but there's no reason to be upset about that LTE has no CS domain. There's the circuit switch fallback. And yeah, basically circuit switch fallback, so the IMS can be complemented with circuit switch fallback via SGS, which basically means it doesn't, it's not a replacement, you can have both. But the advantage of doing CSFPS, if you already have a 2G, 3G network available, which is the most common situation is the case, you can skip the IMS, you don't need the IMS core and all the equipment behind it. You just can reuse your existing circuit switch switching equipment. And yeah, but of course, that only works when you have the legacy networks available. And for circuit switch fallback calls, you really need 2G, 3G coverage. So there's some limitation to it. Yeah, quickly for the idea, what we want to do is we have the 2G, 3G network on the one side and we have the LTE network on the other side. And we have the UE, which is registered with the LTE and since we have, suppose we don't have no IMS core available and we want to do a 6 to 4 for SMS, it seems it's simple. We can just use our 2G, 3G switching equipment forward the SMS to LTE. That is a simplified picture, by the way. It's much more to it, but basically that's the idea. The SMS comes in into the MSC, it gets processed and just forwarded to LTE for calls. So for SMS, it's simply since the UE can be all the time registered at the LTE run, so it doesn't have to fall back in that sense. For calls, things start to be a bit more difficult. So there we don't have these forwarding capabilities. So we really have to fall back the UE to the 3G or 2G RAT, so it really has to go to another RAT and that's a bit more difficult. And the question is how do we accomplish it? The phone is basically has to be registered into network at the same time, which is not possible RAT-wise, but in SGS we would see it's almost the case. It's the UE is known by the 2G network and by the LTE network. For SMS, it's the MSC VLR forwards and for calls we do the fall back. So basically, since this is a bit of a complex task, this requires, of course, requires additional signaling. And therefore, we have to add another interface and that's the SGS interface, which brings us to the next topic. And what we see here is basically an LTE network and a 2G network. And we basically add the bridge between MME, which is the mobility management, and this is sort of an MSC and LTE. So we add a bridge between the two and the bridge is right here between MME and MSC. And yeah. So basically, there's a connection between the 2G network to the 3G network, MSC and MME, which is basically the role of the MSC and the LTE network. We don't have to, I will focus this talk more to the SGS interface and more to 2G because the LTE infrastructure here is quite complex, but we have similarities. We have an HSS HLR, the home subscriber server, that's the HLR in LTE basically, but here this is the holding the subscriber database. And that's used by the two in Osmo MSC. When Osmo MSC is interfacing with LTE networks from different vendors, we have a kind of a problem here because we have Osmo HLR. And then the other vendor has a different HLR, which the two want interface with each other, which is not a problem. So this means this can be one component, but it doesn't have to be. Yeah. So next one. So the SGS interface is specified in 3GPP, TS29, 118. And it's basically a very straightforward protocol. It's spoken over SCTP and it's consists of TLV methods. So it's really easy to implement and there's no complex parsing like ASM1 involved there. And the MSC on the 2GPP side will take the server role here. So the MME will connect the MSC. Yeah. So basically the protocol carries only signaling information. It, for the SMS in exception here. So it's usually signaling only, but SMS is also carried over SGS. That's the reason why we don't have to do a full fallback to the 3G, 2G RAT when we set an SMS that just gets forwarded through the SGS interface internally. But for voice, that's of course a different story. So that's where we really have to perform the fallback. And of course the two parties, the MME and the MSC, they have to share some subscriber state. Basically, both parties need to know that subscriber is currently available for CSFB. And that brings us to the state machine model that is specified by the SGS interface. So it basically consists of three states. Basically an SGS null state, which basically means so there's no association at all. So subscribers not available for CSFB. We have the LA present state, which basically is, this state machine also serves as a location update state machine in SGS because there is separate location update. We will come to that later. So the LA update present state basically means that the MME has initiated a location update via the SGS. So I think I have to elaborate this further. The SGS interface on the MSC side is kind of another run to the MSC, but not quite. It's different, there are sub-tile differences to it, but basically you have to imagine that it is similar to what you have on the interface location updates, service requests, stuff like that. And so it is for the SGS interface as well. So the MME will do a location update on the behalf of the subscriber that is registered with LTE on the MSC, but that's a simplified location update. It's not the complex state machine you have in 2G, 3G. So it's basically what you see here, three states. The present basically means that the location update is currently pending and SGS associated means it's done. So the subscriber is associated via the SGS interface and it's available for CSFB. So basically when you end up in the SGS associated state, it basically means the subscriber is present in the VLR of the MSC. It can, when SMS arrive at the MSC or calls, paging will occur. So it's basically a valid subscriber then, with the exception that it's not attached via 3G or 2G via an interface or something. It's attached via the SGS interface, so to say. And here's the transitions we have. It's not all transitions. So there's more to it. If you are interested, you can look it up yourself in chapter 42 from the CGPP spec. But that's it's the most important transitions here. So you can see there's the location update from the MME comes in. We end up in the present state. What happens there is the MSC will start to talk to the Osmo HLR or basically to the HLR check the subscriber valid and create it and when everything works well, the location update gets accepted. The MME of course gets informed about it and you end up in the associated state. If the MME is for some reason doing another location update, you will end up again. I'm always showing something with the mouse here which is not visible on the big screen, which is sad, but you get the point. Yeah, I always try to avoid that because if you record slides, it's better doing with the mouse. But anyway, so basically if the should see MME decide to do another location update, you will end up in the LA update present state again and basically this thing will start over. So to end up in the state null again, you either detach from the MME or you do a dual LU from 2G, 3G. So if the subscriber for some reason is registering on the normal way to the 2G network again, CSCS association also get lost of course. So basically this means if you basically the important state here is to look at is the subscriber associated or not and if it's associated, you know it's available for CSFB and you can page it. Paging happens through the SGS interface then and travels up to the LTE, to the UI via the LTE RAT run and pages subscriber basically from 2G up to the LTE. But we will see of course later in the slides as well. So there are certain situations where you are forced to SGS null state, you can either get a reset from the MME. So basically when the MME restarts or for some reason state gets lost, you can receive a reset and then you have to invalidate all the SGS associations of all subscribers associated with that MME. Of course your VLR can fail. If your HLR fails, the VLR fails as well. That's the scheme we have an Osmo MSC at the moment. So if Osmo HLR dies, we allow it to fail as well. And then of course there will be a reset in the other direction. Paging may fail or alert may fail. Alerting is not implemented at the moment in Osmo MSC. It's an optional feature basically about subscriber monitoring. And yeah basically if you look up at the specs, you will see that paging is also mentioned as a transition for the state machine. But it's not changing the state. It just keeps a set of fire omitted here. Yeah basically this SGS state machine exists similar in the MME as well. So the MME has also maintained an SGS association, of course, because it has to know as well is subscriber. Can I do CSV or not? There are different procedures defined in the SGS specification which are a bit fine grained. I've broke that down to basically five points. Basically we do locations updates. We do mobile originator and mobile terminated SMS. We do mobile terminated and in brackets MO CSFP calls. And they touch and reset. So that's basically the five major topics I've dealt in the past while implementing that for Osmo MSC. And now things get a bit more exciting. We are looking at flow charts. So this is the, this pic depicts SGS based location updates. So what we see here from the UE is on the LTE, that's still on the LTE side, the attached request. And then the attached procedure is carried out. It's a number of steps. And yeah, then we see that from the MME and LU request is sent via the SGS interface to the MSC VLR. And then we carry out the location update on the SGS interface on the MSC side. Basically creates the SGS association technically in Osmo MSC. It's a way that it's already created when a subscriber is created, but it's always created in state. It's just null of course. So basically what that means for us is we go to LA present and carry out the state transitions. And yeah, we also see the MAPGESA stuff that is when the MSC is talking to the HLR, to Osmo HLR. And if everything goes well, we get an LU accept back. So the MSC gets the LU location update accept. And then we are attached via SGS interface. And if the MSC needs some service, some SMS calls or so, it can page through the SGS interface. Then the LU gets notified. It can also look a bit further into the MESF via shark trace here create out for you. The messaging model in SGS interface is more like it's not connection oriented. So we have messages and the identification of subscriber happens through the EMZ. So almost any message except for reset I think and some basically the which are to the management of the SGS interface was almost any message subscriber related contains an IMSI. And that's how subscriber identified. There's also of course an MME name, which is a fully qualified domain name. That's what's basically what identifies the MME. So we get the location update request from the MME and the MME is identifying itself. There's also VLR names. VLRs have also names. But in that case, it doesn't have to be a fully qualified domain name, but MMEs have to. And by that, the MSC is knowing which MMEs talking to it. It's already not already carried out by SGS reset. So it recognizes the MME and can follow on with the procedure. Basically, we get the EMZ attached in there as a request. And then we accept it. So that's all. So it's not really elaborated. So that's why we also don't need a complex state machine here. So these three state machines is enough here. And then we get the TMZ reallocation complete back from the MSE. So it allocates and set from the MSE 9992. Oh, no, it's from the MME destination port. It's 29108. Yeah. So now the SDS subscribers SDS associated. So the association is present. And by the way, there's usually a periodic location update timer that doesn't exist in SDS interface. So it's, these timers temporarily disabled. So we don't have see temporary location updates there. And now we are ready for the reason why that timer isn't there is because there is a timer in the MME. So basically the periodic location update timer that normally you start in the MSE doesn't need to be started because there is a similar timer in the MME. And there's no need basically to have two timers running. And if the timer in the MME would ever expire, then it would basically send in whatever is it and MZ detach or whatever over the SDS interface. So basically we outsource the timer to the MME. I see. Thanks for clarifying that. Yeah. As I said, my focus is mostly to the MSE site. And basically I'm not so much aware what exactly happens in the MME. Okay. Yeah. Now let's look at something more difficult. So that's an mobile originated SMS via SDS. So basically what's the, what happens here is that the UE is sending an SMS via SDS interface to the MSE and the MSE is continuing on with the processing. So in SDS we have something like unit data, which basically carries the SMS messages. And it's, as far as the SDS interface is concerned, it doesn't look at the data. So when we pass the back messages back and forth inside the Osmo MSE implementation, we don't really look at it. We don't even know that it's an SMS. So we basically pull the lever set would normally be pulled on the when an SMS transmitted via the interface. So what we basically see is the UL NAS transport from the user equipment to the MME. And then it gets interesting. We see the uplink unit data and the SMS sending is basically these few messages, CP, CP data, which are not depicted here forwarded. And in the very end of it, we see an SDS API release request. That's basically when the whole process over to this basically endings the connection. It's not really a connection oriented protocol, but it has some messages say, so this is, it's now done. Yeah, things get more difficult if you have a mobile terminated SMS because then we need to page. So there we see it's a very right. We see the SMSC wants to send an SMS. And the very first thing that's happening is it's a paging. And the paging then gets propagated to the UI via the LTE network. And then the service request is carried out. The service request is not the same kind of service request we see on the normal 2G network. It's more like a paging response. It also goes in the opposite direction. Basically, by the service request, we know that the UI has responded to the paging on the LTE side. And then we carry out the SMS handshake stuff. And it's a very empty terminate with the release request. Should there be an error in any of these SGS message passing and procedures? A status message would be sent by one of the sites. And basically status is, if you see status, it means error and it clears basically everything. I only, of course, cover only the good cases because errors never happen. So now things get interesting because if the SMS sending and receiving is carried out via the SGS interface only, so that's simple. You just pass a few NAS messages back and forward without even looking at them. And basically the UI stays where it is. It stays in the LTE network. But for the mobile terminated call we see here, it has to actually change the network. So that's the real fallback. So that's the real circuit-switched fallback case. And we see this call starts via the SIP invite. And as we say, SMS, you would get a paging request which is propagated through the user equipment and basically on the LTE, you get the extended service request and stuff. And then we get a paging response from the UI to the BSS. And basically that ends up in a complete Layer 3 message. So what we see here is above these first bubbles there, we are still in the LTE network. So we get the service request from the MME. So that's via SGS interface. And we do the setup, this context setup which is done by the MME. So it's not about something we see on the SGS interface of course. Then the paging response from the UI comes in, but that paging response is already on 2G. So basically what we then see is on the interface, we see the complete Layer 3 and we do the call as we normally would do it. So actually on last slide, when SMS is being sent, let's say, there is this paging, but actually the mobile phone doesn't jump to 2G, right? No, it doesn't. So what's exactly the difference that tells the SMS to jump to 2G or just stay on 4G? Yeah, that's some magic on the T-Netbook, maybe Ken mentioned. Let's repeat the question first. So the question was in case of the paging for mobile terminated SMS in CSFB, where the phone stays on the LTE radio carrier, what's the difference to the paging that happens in the CSFB case? I think the paging itself is not different, but what happens after the paging on the RRC layer of LTE is different where then the MME either instructs the phone to do a circuit-switched fallback or where the MME basically then just stays on LTE and receives the NAS message with the SMS. So it's on the RRC layer of the LTE protocol stack. We are also looking at those that are relevant for the SGS interface here. I mean, like when you look at a normal ladder diagram in, yeah, but if you look at a normal ladder also you wouldn't put in like, oh, there was a rat request and you know, so you always reduce some, you zoom out a little bit so you don't have, you know, every LAPDM retransmission and every rat request and whatnot in there. Yeah, okay, fine. I was just thinking like, okay, yeah, I didn't saw those messages there, so I just wondering like, what was the difference, so yeah, makes sense. As far as the SGS interface is concerned in the paging request we sent there, we would say we still have some information elements that say, oh, this is the paging, we want to do SMS, so we want to do a call now, so then the MME already knows what to do. Okay, yeah, while the calls carried on the SGS association remains intact, so there wouldn't be any change to that. And there's something like, I think that's called fast fallback or something like this, so basically when the clear command is issued via the interface, there's a CSFP indication, information element is only basically one, one byte at the identifier itself, so basically if that is present, the RF generally's message would contain some flags to basically to do a cell selection after, it's a very lengthy name, after release, I don't know, so there's basically some signaling involved to throw back the UE as fast as possible, but that's a detail. So let's look at, very quick at the MO call as well, I first thought that I should exclude that, but because it's not really SGS interface related, there's a lot going on between MME and UE, but basically as far as the MSC side, the 2G side is concerned, an MO call is basically looks like a normal, looks and feels like a normal 2G call, which is also obvious because there's no paging needed for that, it's basically some kind of, the equivalent of a request on LTE and then LTE instructs a mobile phone to go to 2G and perform the call there, so there's not really anything we need to do on the MSC side basically comes for free, and then finally we also need to look at the detach, because that's a bit weird, so different detach situations and I really had some difficulty to get that right in the beginning, a detach can be also of course be implicit or explicit, implicit means the UE is detached because some time expired, basically it's gone for some reason, that doesn't make too much difference to the processing in an OSMO MSC, but there's an EPS detach, the EPS means Evolved Packet system, I don't know, that's basically LTE, so if you do an EPS detach, you basically say, oh I want to detach from LTE, but I want to live on 3G, 2G subscribers, so if we receive an EPS detach on the MSC, that basically would mean we would invalidate the SGS, its association basically go to SGS null and through it's a subscriber as it were a normal 2G subscriber, so a subscriber is not purged from the VLR, for MSC detach things are different, so that basically really means the subscriber is now detached from 2G 3G and it's gone then. Yeah, now we go through some implementation details, I already mentioned a lot of details I think, but what we have here is basically a, I call it a two territory implementation, two territories because we have MSC and VLR in one process, I don't know if there's a split plant in the near future, but it's, it could be theoretically possible, but the way it's designed in Osmo MSC is the VLR and MSC are kind of separate. The MSC side basically does all the, oops, the work in quotes, it handles the messaging, it does the pausing and does all the action work by the VLRs handling subscriber only and does controls the location update, controls the SGS association of course and basically is responsible for subscriber state ref counting and so on. So when integrating the SGS interface, I had to take care of that, I had to maintain this separation and here's what I came up with. On the very left side, we have the IP network and the connection to the EPC, basically the EPC is the Wolf packet core, I mean the MME, that's where we are connected to the SGS server C file, which is basically passing message from us back and forth between SGS ePhase C and in SGS ePhase we have the MSC, basically the action, so basically what to do, I mean if you need to page, we need to page, so this kind of stuff, initiated paging, triggering a location update, passing back and forth the NAS messages for the SMS, reacting on service request sets there and we also have this little state machine I didn't talk about yet, these null weight completers, that's for the reset, for the reset we also have a little state machine inside there which basically controls reset at the very beginning when the MMEs basically negotiate with the MSC, it has to carry out a reset procedure and that's what I mean by that. Then we have a VTY of course, which basically offers us some configuration, MME name and stuff, sorry, VLR name, yeah and then we have the boundary between the VLR and MSC side and there I basically have, I didn't reuse the location update FSM which is already present in the VLR because it's a very complex thing and since the state machine for the SGS interface is very simple compared to that I decided to basically put another state machine, it has another state machine next to it and it's also specified in that way, you know the specification, the specified state machine for a reason and it's used for location updates as well and then so basically we have these state machines and then we have a VLR, SGSC, so the VLR, SGSC is our API basically so there when we go from the MSC side and want to carry out some VLR related action we call a function in VLR, SGSC and then this function may issue a re-event to the state machine and the state machine may perform some stuff and basically the way we get back results from the state machine is a callback function so you would issue a callback function to when you call the, when you issue a call to VLR, SGSC you can issue callback functions and that are getting calls, that's by the way only necessary for location update I think because you somehow need to get notified if the location update is successful or if it failed and there are callbacks for that and these callbacks would generate the appropriate messages on the SGS interface and basically execute that. The other way would be to call functions directly from SGS, FSMC, the functions directly in SGS if AC but that would basically break the separation so I didn't want, I didn't want that so that's why I came up with this callback model there. Yeah and basically yeah that's it now, we are through now. Other questions? You mentioned that the MME got to be identified by fully qualified the name, the main name, why is that, why can't you use just IP address or how it works? It's specified that way, I don't know what's the exact reason it's behind that but it's it's in the specification you have to use a fully qualified domain name there in the form that we've seen it in the trace. So that's the way you tested it as well? Yeah that's the way we tested it, by the way testing, so when implementing this we didn't have the chance to try that out on real MME so basically all the testing and as the implementation testing is done via TTCN3 and all the tests are designed by the specifications so basically this is not very much tested on real MMEs yet there are some people out there who are currently testing it but I think there are still some some kinks in there which need to be ironed out but if you are interested in how trace would look like you can always go to our Jenkins service and look at the TTCN3 test artifacts they would get traces of it and yeah. Yeah I have one more question. I see in location update request message that we use location area in the fire. This in this fire of which location area I'm trying to understand because it's MMEs sent this message to MSC? I see I must admit that I also do not know really what to do is it other than recording it. Well I think you need to configure on the LTE side which location area overlaps the tracking area that you're currently in because in the end yeah this should so if you want to make sure that your phone can switch between do cell reselection between 2G and 4G without doing location update and EPS attached detachance on all the time you need to have overlapping tracking area and location area. It's location area of 2G network yeah? Yes so basically this means that if there is a this location area you send and this location area is recorded on the MSC side so if the phone switches to 2G and you have I think idle mode signaling reduction enabled then you don't need to do a location area update on 2G because it's already stored that it currently is in that location area. Which of these messages in which ARFCN to go? Well just about the the question was to how the phone knows to which ARFCN to go when calls happen and the more practical issue is that we are carrying some trials with 4G in Mexico and I'm doing some simple lab testing at home with some open air interface derived at the MME and HSS and also SRS, EPC I ran and they they're not be like do you know if any of them have this SG interface already in place? No unfortunately not. So no there's no open source implementation of SGS on the MME side in none of the projects and regarding the question of the ARFCN we don't know and we don't care. It's the job of the LTE E0B to advertise GSM neighbor cell information in LTE system information blocks and the phone autonomously chooses whatever ARFCN is listed within those neighbor cells with a strong signal on the right MCC MNC. Thank you. So basically you need to manually actually I have a presentation about LTE and Osmocom coming up and that will look more at this in detail. Super noob question what is SG lowercase S in the context of? Oh yeah I tried really hard to find out I think it's service gateway that's my guess You mean in SGW? The SG? The SG in SGS? No it's just it's like what's the A and A business you know? Okay that's interesting. So in LTE we had the E0B and in 5G it's called the G0B. Why is it called G0B? Somebody suggested to call it F0B but it was refused in the meeting so they went to the next letter. Okay do we have more on topic questions? No okay then I think we can thank Philip. Thanks.