 I think I'll get started. This will be quick. This is just a 15-minute time slot. It's basically the slow-associated control channel of presentations, has very low throughput and very few slides to look at. So this is also going to look a bit at the user plane evolution. So if we think of how is the user plane arranged in GSM traditionally, basically the user plane and the signaling plane are always at the same time. So you have an E1 line, and the E1 line has signaling and associated voice channels, or circuit switch data, if you wish. And the voice circuit between two phones in the same BTS would traditionally go. So you have a situation where you have two subscribers, two phones registered to the same BTS, and they call each other. And then the voice channel would go from the BTS to the BSC. Then in the BSC, you would have a transcoder and rate adaption unit, a TROW, which transcodes from the AIR interface, which would be AMR or EFR or FR or HR, transcodes that to ALaw or Ulaw, and then feeds it from the BSC to the MSC as G711 on the AIR interface. And then you go from the MSC back to the BSC and back from the BSC to the BTS. So you have really the full voice going all the way from the BTS into the core network and going back there. This is, of course, not optimal, but it works fine in low-latency, land-based, wire-TDM networks like ISDN or PSTN that was in place in the 1980s and 1990s. But it does not work well with remote sites that are connected over VSAT or other connections, such as Maritime, as well as rural BTSs. And so various vendors have implemented proprietary solutions to work with that, which conveniently create vendor lock-in, as those systems are proprietary. But basically, when IP-based BTSs came around, such as NanoBTS or later also OsmoBTS, they replicated that model. So rather than having E1, we do it over IP, but still in the absence of LCLS, which I'm talking about in a few minutes, the voice would go exactly the same way. So if you do, whether it's NITB or whether now it's with the split architecture with OsmoBSC and OsmoMSC, your voice call, if you have two subscribers in the same BTS, goes from OsmoBTS to OsmoMGW at the BSC, then from MGW to the BSC to MGW at the MSC, and it goes all the way back, which, again, is, of course, not, oops, sorry for that. I have to reduce the font size and find somehow a level that works with this. Okay, yeah. So we have 3GPP local call, local switch as a 3GPP-specified extension in later releases. I don't recall the exact release where it was introduced, where we want to change this. So the red line here in this diagram is how the signaling goes, and the blue dash line is how voice traditionally would go. You'll see here media gateways next to MSC, MSC, MSC. They don't have a media gateway, the V is here, but it doesn't matter. So the blue line dash line is how it would go, and the thick blue line here is basically the shortcut that we introduced with local call, local switch. And how do we do this? Well, basically from a signaling point of view in GSM, the OUE, that's the originating user equipment, so this is an MO call, and the bottom one is a mobile-terminated call, and those two calls are separate calls in GSM, right? There's nothing that really connects those two. It's two entirely separate calls, and the BSC has no way of knowing that basically those two calls are related because they have different, all the identities are different. They go over different SCCP connections. So basically only the MSCs here would know somehow, and particularly the IMSC in this particular case, but we can ignore the details, would know that those two calls relate to each other and in fact are connected to each other. And what happens is that basically on the A interface here between MSC and BSC, we introduce what's called a global call reference, and actually the same is also introduced here at the interfaces between those MSCs, and the global call reference then is the same for both calls. So you establish the MO call here, then the originating MSC throws some dice and decides this call will have global call ID 2435, and then this 2435 goes along with all the signaling, and when the call re-arrives here at the BSC, the BSC will say, oh, I have this call already on the other leg of the call, and now I know that this MO call and this MT call basically are connected to each other and that I could establish such a short circuit of the voice call. Now, you don't want to enable that all the time, but at least now you know that it's possible. But then what kind of problems introduces this. So if we did this automatic, if as soon as the BSC detects that this is two calls connected to each other by looking at the global call reference here and made this connection, we had problems because there's an early media alerting phase where of course you want to have an alerting tone that's generated at the core network at the MSC here on the right-hand side. Also, playback of voice announcements, something like, oh, your prepaid account has gone below limit or is about to expire or something. How do you inject this here from the core network if your voice channel is established point-to-point here on the RAN side? So this is a problem area. Then of course some people care about lawful interception for whatever reason, and then that's a problem for them if the lawful interception interfaces and everything happens at the MSC level and the call is already looped at the RAN side, at the BSC or even at the BTS side, you don't see that voice. And then also you have handover implications. Let's say you do some handovers where there's intra-BSC, inter-BSC, inter-MSC, and so on. As soon as you handover, of course, all the elements in the new chain also need to support LCLS. If they don't, you need to fall back to the old behavior and you need to discover that during all the different handover cases. So there are some problem areas that need to be resolved in local call, local switch. Now, early media basically looks like this. This is again a diagram where the green indicates the control plane that goes basically through all the MSCs. Here again we have three MSCs in the chain, the OMSC for the originating side, the TMSC for the terminating side, and the IR I think for interworking in the center. And so basically what they put in is sort of a switch here in the voice plane in the BSC or in the media gateway next to the BSC. They just say it's in the BSS, so it can be implemented wherever. And basically you can establish the signaling this way, but then there's this switch here and the early media comes from this MSC, it comes from the core network and gets injected here to the originating user equipment and it's not connected anywhere else. So originally when you start the call, you still get the media from the core network. And then later on, basically you introduce this short circuit here and there's some signaling involved in that. So basically you start in the classic way with all voice going and coming from the core network, but then there can be some signaling by the MSC which basically closes the loop here, the short circuit in the BSS and enables the local call, local switch feature. And that is done actually different. So it's not just a binary switch, but you can say, well, for each of the two directions from A to B and B to A subscriber, you can independently configure this. So you can say, well, receive audio coming local but transmit to the core network or you can even do things which they call bicasting, which basically means loop the audio local but also send a copy to the core network and you can guess what that's used for. So these are the features here and these diagrams are, as you know, I never draw diagrams. These are all taken from the three GPV specs. It's actually quite funny that in modern specs they have such colorful diagrams in the specs. This is quite far away from how the old specs look like. So this is how a tone or an announcement is being played. So again, we have here the originating MSC, the terminating MSC, the interworking MSC, we have the co-located media gateways here. Here we have the two user equipments at the bottom and the BSS, that's local call, local switch capable. So basically we have some announcement in red that's generated at the MSC here which is sent to the BSS and then the BSS here can interrupt the normal voice. Like normally the voice would come from here, go to here and go back in the local call, local switch but it can interrupt that loop temporarily and rather inject audio coming from the core network side. So in the middle of your call basically, the media gateway in the BSS can be instructed to cut the local loop and instead play an announcement that's being sent from the core network side and that could be, well, your prepaid account is about to expire kind of thing. So you basically have this switching capability here and some signaling messages that will do this. So it's, LCLS is negotiated and all calls start non-locally switched and then only over time between the MSCs can be negotiated and established. And there's LCLS negotiation requests and response and the configuration preference information element. These are new information elements that have been added to ISAP, to BIC, that's the bearer independent call control and to SIPI, which is the SIP interworking way, how modern 3GPP cornetworks use SIP rather than ISAP between them for call control. So all of these protocols have been extended by these additional information elements in the core network and the results can basically be, well, either don't do LCLS is the classic non-local case or you can say connect both ways, which in the BSS, which is called basic LCLS the complete local loop and then you can also do this by casting. So you can connect the local loop in the BSS and by cast the uplink to the cornetwork or you can say send access downlink from the cornetwork and then even you can combine or replace the local downlink data. So there's even capability so you can mix the local voice coming from the phone and the voice or the audio coming from the cornetwork so you can mix those two voice channels with each other. All kinds of combination modes in there. For the A interface, this means that we have a couple of additional information elements and messages. During call establishment, we have a new in the BSS map assignment request, we have this new global call reference field which tells us to which call this connection belongs. And then we have an LCLS config information element by which the cornetwork tells us what's the configuration, what is permitted at all in terms of local call, local switch and in the assignment complete from the BSC to the MSC, we send back a status sort of what was the result of trying to enable LCLS here. And during handover again we have in the handover complete we have this BSS status so the MSC again gets notified after a handover what's the status of local call, local switch. And then at any time there can be the MSS, the MSC can send an LCLS connection control to interrupt or reroute the audio as needed and also if the BSS changes autonomically because for example if there is a handover between two BTSs inside the BSC normally the MSC doesn't know about this but using this notification then let's say the new cell does not support LCLS but the old one did then you need to break the loop and the BSC can tell the MSC well LCLS has been broken now after handover by means of this LCLS notification. So what do we do in the Osmo.com site? We plan to support a minimal setup without this biocasting feature which is only needed for local interception anyway. So what do we need to do in Osmo BSC? We need to add support for those additional information elements, those two or three information elements and then if for example the MSC changes the LCLS configuration we will translate that into MGCP commands to change the media gateway because in the end what we need to do if the MSC tells us we'll switch from the local loop to the remote loop or back basically it's reconnecting the RTP audio and that's exactly what the media gateway does so we will basically do an MDCX Modify connection which will change the destination of the RTP stream based on LCLS. And the development we will do is test driven so we first write the tests for these new messages and information elements in TTCN and then we run that against Osmo BSC until the feature is supported. And in Osmo MSC we assume that we only have a single Osmo MSC and not a complex network with multiple MSCs where we basically will just have some VTY config to tell the MSC if LCLS should be permitted or not and then it will always try to use LCLS whenever possible on the interface side. Yeah, there is lots of spec references here if you want to read up more details. This is the report 23284 which basically is a report that 3GPP wrote before creating LCLS on how this should be done. Then we have the work items, the WI. They basically tell you all the different changes they made in the various specs in order to introduce this new feature. We have also a wiki page in the Osmo Com wiki and we have two issues to track the progress. Also again, one for the core network side, one for the radio access network side. And that's basically it in a nutshell what LCLS is and what we will do about it. Questions? Okay. No questions? Ah, there is, okay. So is in the Osmo plan are you planning to implement local call local switch on the BTS side only or only within the BSS? Well, the BTS itself doesn't really need any support for it. Let's look at this. Basically, I mean the BTS sends its audio to wherever it's instructed to on the RTP side. And we could go as far as to basically really creating this loop here between the BTSs. I think that's what your question was. My assumption was that basically we do it at the media gateway here only. So that basically the RTP would always go to the media gateway here and then from the media gateway at the BSC it goes back because the assumption is that if you have a satellite set up with Osmo Com components you have the satellite link on the A side and not on the Avis side. Avis-based satellite backhaul is stupid and is only done by legacy equipment where the BSC is an expensive piece of equipment that you cannot put at every site. But with Osmo BSC I think the cost is rather low. So you just put Osmo BSC everywhere and you have your satellite backhaul here. So there's no issue. Yeah, I kind of ask because we'd have some situations where actually the Avis link is not as nice as one might want. And so if there was two calls on the one BTS it would be nice if the RTP stream wasn't actually going anywhere at all. It's possible to do but it would require more logic in the BSC. So I mean it's easy to do as a future extension but the primary goal is to remove the backhaul from here now. Make it go through the media gateway and if you want to go further then it's, I mean the BSC knows all the, which two logical channels are involved in the call. It knows the IP addresses and port numbers associated with the two RTP sources and syncs at the BTS and it could as well basically completely delete or mute the connection on the media gateway side and then tell the BTS over RSL to connect to there and back here. With Osmo BTS at least that would work. With Nano BTS it would not because they don't like changes of the SSRC during an ongoing call. So the synchronization source of RTP must not change during a call so they would not, as far as I understand or I know, would not work but with Osmo BTS it's possible. It's just some more work in the BSC.