 I'm going to introduce you to the topic of inter-MSC handover and how, I mean, the talks title said how we implemented, but basically is how I implemented it. This was the, I think, it's the biggest code bomb I ever wrote in my career. And at first, I'm going to explain what inter-MSC handover is and lead you into it. And then in the second half, I'm going to explain a little bit of what the code looks like in Osmo MSC after I was done with it, because after all, we are the developers. So and in the past, I often used the dotty diagrams with circles and arrows, but because this topic can be confusing and maybe a bit boring, I decided to use some more images that make it easier to follow what's going on. So bear with me. I'm not sure about the copyright issue. Maybe we will have to not publish this video. We will decide later, but let's see. And I managed to get exactly 42 slides. Some of the references. Yeah, no references. I've seen your addresses on the slide, so they know who to compare. Yes. So assignment is giving the subscriber a new L-shine on the BTS. Handover is from one BTS to another. Inter-BSC handover is more complex. And then inter-MSC handover is what we want to reach today. The level of expertise is quite something. So using the analogy of our son being a BSC, then the MS Voyager is like the phone that's moving from one planet to the other. And the BSC would look over it and tell the second BTS to accept Voyager passing by it and continue the call. So if the BSC is the son, then what is the MSC? It is, of course, the supermassive white milk in the center of our Milky Way. So inter-BSC handover would be Voyager moving to a different solar system in our galaxy. And now here the BSC would manage the entire handover. And this doesn't work anymore on this level. On this level, the supermassive white MSC has to be involved and tells the second BSC what to do and forwards messages back and forth. So the messages it's forwarding, these are actually BSS map messages for the 2G cases. The first BSC forwards the phones. OK, like the first BSC receives the measurement reports and sees that another cell is better and sends a handover required to the MSC. The MSC figures out what the new target BSC should be and sends a handover request to the second BSC. That says, OK, I've prepared an L-chan on this side, handover request act. And by the way, here's the RR message that you have to send to the first BSC. And then the MSC sends a handover command. And I'm cutting out all the lower level and the ABIS messages going on. But they are all happening underneath. And they are basically the same as with the standard simple handover. OK, then at some point, the phone is moved over. The new BSC says, handover detect. I've seen the phone. At this point, we switch over the voice stream. And then when handover is complete, the old connection is simply cleared. And now the subscriber is on the new BSC. And now we've covered the third from the top inter-BSC handover. And now we're moving into inter-MSC handover. Now, of course, if the MSC is the center of our galaxy in the analogy, which is the analogy is broken on so many levels. But if we follow it, of course, an inter-MSC handover would have to be intergalactic. So if you know the BC voice, this is the music video for the intergalactic planetary intergalactic intergalactic. So for some obscure reason, the MSVGIA has now ended up in another galaxy. And the way the specs describe it is that we have an E interface link, which is MAP over T-CAP, which Vadim also mentioned for SMS, and an ISAP link for the voice, which is basically another SIP call to forward the voice. Now, the first MSC is still responsible for managing the subscriber. Now remember, this is an ongoing voice call, and the phone moved. And the subscriber management remains with the first MSC. But it doesn't even have a BSC or BTS associated with it anymore. The MSCB, which is called MSCB, now has basically a BSC proxy for the first MSC. And these are the links. And as Vadim already explained, we, of course, don't use a MAP over T-CAP. We use G-SUB. And G-SUB, how do we use it? We route it via the HLR. So here we have the Osmo HLR, indicated by the smiling galaxy. And it's a G-SUB link. And we introduced new E-interface messages over G-SUB to be able to do this. And let's just take a quick look. On the top, there are the MAP messages. So there's a prepare handover procedure, which has a request and a response. And inside each of them, there's a so-called ANAPDU, which basically just say PDU. So it's like a bunch of bytes, which are actually the run messages, like the 2G, the BSSMAP messages, or the 3G, the run-up messages. And so then the third is the process access signaling. It's a very long name for a short thing. Just here have some data. Basically, it's the process access signaling. And the reverse direction would be forward access signaling. I don't know why they chose these weird names, but basically they're just sending messages. And on the bottom, you see how we modeled it in G-SUB. It's basically a couple of message types, like a prepare handover request, send end signal, whatever. And we send the MC for every message. And we have a source and destination name, which just indicates the MSC's IPA names, which they used to connect to the HLR. The handover number, it will come up later, is basically a temporary phone number that the new MSC allocates in order to forward the call. And the ANAPDU, which is basically the meat of the whole messages, which will contain the transparent BSSMAP or run-up messages. So the G-SUB is used for the e-link. And for the voice forwarding, we use just another MNCC connection to the handover number. So you have the PBX, like FreeSwitch, or Kamali, or Wich would whatever. And we just do another outgoing call to the handover number that the MSCB told us. Right, so let's just go through it step by step, yes? I'm still missing apart from the microphone. So the use case for this, can you explain a bit the use case from the MS point of view? So what's going on? Like, I'm just roaming somewhere, so I'm changing my MSC, or what's exactly? Or I'm just moving away from one zone to another, just walking? Yeah, it's actually the slides that are coming up are pretty good for this. So basically, this is like your normal phone call situation. You have the HLR and some G subconnection for the VLR subscriber authentication, and so on. And using a PBX setup, we are now having an ongoing call. So there's like the MNCC SIP call leg going all the way to the BSC and the BTS, and now the little voyager is our phone busy on a call. And now what happens is this phone is moving into another area where there is no coverage from this MSC. So basically, I guess in commercial networks, you could say, yes, it's like a handover into roaming situation. I could imagine. I don't know whether operators use more than one MSC, of course. OK, so then it's just a handover into an area where the BSC is managed by a different MSC, whether it's roaming or not. So imagine you go into the train in Berlin, and you go take the train to Leipzig or to Hamburg. For sure, in Hamburg, you will not have the same MSC as in Berlin. And somewhere along the line, you cross the boundary where the two MSCs have responsibility. Yeah, I don't really have an idea about it. Of course, yeah, yeah. Sure, that's not the point, of course. Right, so whichever it is, the phone is moving into an area where the BSC managing the cell is not managed by the same MSC. And now it sees that another cell not shown on this slide is stronger by the measurement reports and triggers a, and the BSC notices that it should do a handover. And now the BSC notices, aha, this new cell I need to handover to is not managed by me. First of all, the BG is not managed by me, and then it escalates to the MSC and sends a handover required. Now there could be the inter-BSC case where now the MSC says, aha, I know this BSC. But now we're moving into the inter-MSC case where the MSC says, this BSC is not mine, but it is listed here as belongs to that other MSC. So then it calls the other MSC and sends a handover request over there. So now the second MSC, the MSCB, sets up an L-shine on the BSC that it knows and on the cell, prepares everything and sends back a handover request act and also assigns a handover number on the MNCC SIP, on the, basically on this OSMOSIP connector link. And a complete full phone number and the PBX has to know where these numbers should be routed. It's like, basically it's like a set of I don't know how many numbers that get used for a handover and then they get unused again so they can be used again later on. So it's just very transitory. So there's a question. Is it a kind of special range of handover MSISD hands? I'm not aware of how operators do it, but in our case it will be, you know, you configure a special range for it. Okay, thank you. So it's MNCC or SIP? You can use either for this. No, it's like the, say like on the MSC we have the MNCC interface talking to OSMOSIP connector and the OSMOSIP connector is talking SIP to the PBX. It's like your normal like PBX set up with OSMOSMASC. So can we just use OSMOSIP connector or we need actual PBX for something? Well, OSMOSIP connector alone has to connect to something so you need a PBX, right? What about media interface on this picture? How should they look like? Yes, the picture would get quite crowded with the media gateways in here, sir. But basically there's a media gateway next to the BSC and a media gateway next to the MSC. And actually in my tests what the PBX did was it actually noticed that the media gateway for both MSCs are on the same server and just connected them into each other. But, you know, usually I would expect that the PBX also forwards to the other media gateway. This is the same as with your normal SIP call. It's exactly the same. So to clarify, this only works with the SIP setup, not without it? Yes, that's right. As soon as you have inter-MSC you need to have a call router behind the MSC. Because obviously for internal MNCC you only have one MSC. Of course, you could have any other external MNCC entity that translates to ISDN, to ISAP, to God knows what, to bearer independent call control as long as it speaks the MNCC protocol and it can route to the destination phone number. That's basically the point. But the only thing that we know and exists today is the Osmo SIP connector. Sure. Right, so where are we? The phone is halfway between. The new L-CHAN is prepared on the new BTS. And then the... So this is interesting because now you have the first, the original SIP call on the left, still going on and the MSCA places another call shown in orange via the PBX to the new MSC calling this temporary handover number. So basically what we have is a SIP call coming into the MSCA which is still responsible for the call and subscriber management but doesn't have a BSC or BTS or anything connected to it. All it does is forward its instructions to the new MSC which is just now a proxy to the actual BSC in use and there's a BTS behind it. So via this G-sub link, we send the DTAP messages back and forth like if there's an SMS during the call it would go via the G-sub link or the CC disconnect or the what DTMF or whatever. All this stuff would go via the G-sub link in your normal way and the MSCA manages all of that and all that the MSCB does is forward the messages and tell the BSC what it should do. And one interesting bit, question. Do we also have then LCLS, so local call local switching in the PBX because I mean in series the voice data does not have to go over the MSC MGW, right? I'm not sure maybe how I can talk about that. There is a spec that specifies how you can indicate LCLS over SIP but that we don't implement at this point. So basically the same kind of LCLS related signaling that happens on the BS SAP interface there is like with this whatever where one entity says what it can offer and the other one then chooses and so on and the global call reference and all these things they get added as additional headers in the SIP messages and then this is how it works but one would have to implement that on all the SIP related implemented elements and so on. And in fact the E interface messages also include the global call reference. I saw information elements for that in those messages it's just not implemented yet. So I guess a lot of stuff is possible but it's not there yet. Right, so the voice actually does go to the first media gateway on the MSCA and then back to the PBX and then to the MSCB. Bless you. It's fine. And actually the first MSC could at any point like what do stuff like insert some message like what you are using experimental 3G I don't know what no I'm just joking like your balance has expired you know the MSCA is still in control of everything so it could decide to play something in the voice stream and so on. So I don't know which slide is next let's see. Ah, now I'm going to go into the configuration. So just very quickly I have two MSCs with distinct point codes like so far I was always just using the default point code. So now you see on top I say point code 0231 and the bottom says 1231 so that I can connect to the same Osmo STP and route messages sensibly. And then both MSCs call connect to the same Osmo HLR and just for the sake of remaining sane I use different country codes and network codes for both they could be the same of course but just for easier logging parsing and so on I just picked like the CCC country code and network code on the top and the default CISMO COM SIM card code on the bottom. And this is also reflected in this arbitrary IPA name. So the HLR gets told an IPA name I just use the same numbers again that could also be like what Fred and whatever Fu choose any name you want. Hamburg and Berlin, yes. Hamburg and Leipzig and in the MSC section you see that both MSCs use distinct MNCC sockets so they each have an own Osmo SIP connector connecting to the same in this case Camilo on my tests, thanks to Oliver who set this up in the Osmo Dev so I could just use it out of the box without worrying or understanding anything about it which was very nice. And the neighbor config. So let's see on the bottom box, third line from the bottom you see a neighbor, A meaning A interface meaning 2G, CGI meaning so global identifier which is the MNC and what? MNCC and MNC and the LAC and the cell identifier. And like the first neighbor line is a local BSC which is indicated by the ran PC meaning ran point code. So this is a neighbor which is a locally managed BSC which would be like the normal the inter BSC handover and the second neighbor line goes to a remote MSC so there's a neighbor A interface CGI going to this other country code this other LAC and cell identifier and it says please go to this MSC IPA name which is MSC 901700. And on the bottom is basically the mirrored case and I could explain why you also have to list the local BSCs but I think that's just too much detail. Basically the BSC has to be connected but maybe it hasn't shown the cell yet and so on ask me if you want to know about it. Is it possible to define some sort of wild cards for the neighbor specification or do you have to basically have 20 CGI lines if you have an MSC with two BSCs and each have 10 BTSs? So basically what makes most sense to me is like when you handover like on the phone level you see a specific RFCN and B-SIC like you want to go to this cell so for my understanding it makes sense to just exactly pinpoint this cell so to have the complete stuff listed but you also have different cell identifier types where it says CGI here you could also say just the LAC for example or even just the cell identifier stuff like this exists so you could say hand me over to this location area code and basically the BSC could technically decide okay I'll just pick any BTS I want from this location area code but in practicality it doesn't make sense to me because if I want to hand over to this cell because the measurement report was good what would it help me to hand over to the cell on the other side of Berlin? But in this neighbor configuration you only specify which MSC handles basically the target, right? Yes, and then the MSC again the other MSC again needs to know Yeah, but the source I mean if you have a net or if you plan your network accordingly and you say all even cell IDs belong to this MSC all odd cell IDs belong to the other MSC and you could have a rule that says if the MSC is even then hand over to this MSC and that will know Yeah, yeah, yeah, of course that's right So let's say the second MSC handles all location area codes 70 then I could say Neighbor A lack 70 to the MSC IPA name whatever the other one is and it always sends this, well does it? Well then the way it should work is it should still have to send the precise target cell along with the message and then the MSC should have to decide I think now that I think of it I think it doesn't work that way because the MSC already has to decide which the target cell should be and it has to pass on this information over all the hops so that we can find the right target cell in the end I think it can pass that on sure but the rules and I think in practice you don't want these explicit lists but you always, I mean in normal networks you say well okay this BSC handles this location area or this range of location areas and this MSC handles whatever so like subnetting IP networks and I think sure you always have to pass on the complete identity but the routing rules that you specify in the config file I think they should permit some kind of subnetting and not have to specify each and every individual cell in there. Okay that's an aspect that we should probably take another look at chances are it does already work because of the magic of matching cell identifiers but to be honest I haven't considered this case yet I was too focused on rewriting all of the code Yeah you know very interesting input we will probably have this feature sooner rather than later. So that's the config on the MSC level and the BSC also needs to have prior knowledge about the target cells. Like on the top there's the normal even intra BSC handover case where you just say okay my neighbor is BTS-1 it's like within the BSC like the image with the smiling planets and the bottom one says if you see this RFCN in BSC like H70 and 1 in the measurement report it corresponds to this cell identifier which then gets sent to the MSC and then MSC can decide well is that me or is that another MSC and so on. So when you're planning your network you even have to tell each BSC what other cell identifiers it should know and precisely because the phone only tells you the RFCN and BSC and never tells you the cell identifier of the target cell so you have to have a translation there that's prior knowledge in the BSC. Right, before now we're going into the code of the OSMA MSC. Just my idea, sorry, but I just had an idea whether it makes sense to have sort of use network listen mode or to enable this list to be populated by itself because I think that is all the information you can gain from just listening to the channels, right? Well, if you are a BSC and you see RFCN and BSC you have no way of knowing what the core network thinks which cell identifier this belongs to really. I mean, if it's another BSC cell then this BSC doesn't know the other BSC cells and vice versa. I was thinking of maybe the BTS could basically detect neighbors and report that up but I guess that isn't specified in any case. Yeah, it's not specified and you still don't have the mapping and I mean you need to configure the network, right? Like what you can see there if you end up configuring more complex networks is there is a need for a central element that contains all this neighbor information and which then basically passes it to all the network elements so you don't have to configure like the inverse setting here and there and all that thing. I've actually seen such kind of automatic detection of base stations running on some RFCNs. So if you basically run your own fake BTS it will be automatically broadcasted to the neighbor cells of commercial network. Yes. But how do you figure out the complete cell identifier for the thing that you saw? I just used the random one. I think we're entering the topic of self-organizing networks which is not in the scope so let's give Nils a chance to continue. Okay, right, so now I'm going to dive into what I did to the OSMA MSC's code base and to introduce before I showed some E-interface messages which is what I removed there was these abbreviations MSCI and MSCT that you see here and there's a bit of a bit of unfortunate naming like before we had the MSCA and the MSCB which is obviously the MSC in charge and the MSC that is just the BSC proxy and then there's also roles taken by various MSCs and the first role is also called the MSCA role which could be confusing but luckily the MSCA role is always at the MSCA MSC entity so we just took the corner out of confusion and the MSCT and MSCI roles are the proxies to the BSC parts. Why is this necessary? Because obviously if you are setting up another RAN link to a different BSC there's a transitory period where you have two RAN links alongside each other so the MSCT is the transitory role and I don't have no idea what the I should mean I think it's internal or whatever maybe they just roll the dice to get another letter basically the T is while you're negotiating the handover and once the handover is complete you throw away the first MSCI and the MSCT then becomes the MSCI so I have some illustrations for this as well. Before we had this glorious GSM subscriber in the Osmo NITB it was one thing doing everything it was basically the VLR subscriber with the local database it was the RAN connection it was the mobility management it was basically even authentication everything and for a long time now already we have split off the VLR subscriber so it's not this Swiss pocket knife thing for everything so we already had two but still all the rest like the RAN connection, the mobility management and everything was still one thing so instead of this monolithic subscriber struct we now have separate roles. So basically we now have the MSCA team and the VLR subscribers on the side and this guy with the white hair is the MSCA he always remains in charge symbolized by the cigar and then normally on the left you have the MSCI which is your proxy to the BSC which has a RAN connection connected to a specific RAN peer and this RAN peer and RAN connection they are agnostic to which RAN you're using this could be a 2G or a 3G so it could be BSS map or RAN app and once it needs to actually decode messages and manage stuff it goes to the RAN Infra helicopter which knows how to decode specific RAN messages right and on the bottom right there's the M-sub, the MSC subscriber which is a very dumb container where all of them sit in and ride along and Mr. T in the middle is the transitory role that is only present during handover so this is like your normal situation you have an MSCA and an MSCI and a RAN connection to a BSC and now imagine the phone moves to a different cell and says handover required please find another BSC for me so now we are in the inter-BSC handover case no other MSC involved yet so the same MSC allocates an MSCT oh, what's that, there's a typo and it sends a handover request that sends back a handover request act and then basically the old MSC gets cleared and the new MSCT becomes the new MSCI and once it's cleared this is the new situation we have a different RAN connection to a different BSC still on the same MSC now this separation is useful to have two RAN connections at the same time but of course this second RAN connection could be in a completely different MSC that's why we have this G-sub e-link so in this case we had a local MSCI and then handover to a remote MSCB which makes it an inter-MSC handover it's the exact same messages just going over the e-interface and negotiated remotely and then when it's done we have an inter-MSC link like with the orange phone calls phone cords going to a distant Galaxy kind of image and right, so this is basically the same as this after a handover now what happens if the phone again wants to handover it says, now this other cell is even better and then of course it sends a handover required and then on the e-interface we get a prepare subsequent handover message and then the MSCA figures out where it should be and of course this could again be on a different okay subsequent message is not so interesting prepare subsequent handover let's just skip this this could even be on a different on a third MSC which would be the MSCB how do you call it? what? MSCB prime? well that would be the prime secondary whatever MSCB apostrophe would be the new MSCT so now the MSCA is all alone managing everything and there's a BSE way over here and another Galaxy way over there and so but let's just simplify say the phone just hops back to the cell that came from then the MSCT would be on the first MSCA again and once that is done we are back in the first situation only now the MSCI has a different complexion right so these are the roles that you will find in the MSC code base and basically what was the GSM subscriber or even more recently there's a bit of a misnomer a renamed to RANCon is now the MSCA that is the thing and the MSCA FSM is now basically the connection finite state machine managing all the things and you know in charge of triggering transactions and so on and the MSCI and MSCT are just bare proxies and the MSUB is not that interesting it's just a container for all of them even though it might look like that would be the proper thing managing everything it's the MSC when you're implementing new stuff most likely you are interested in the MSCA and you don't care about the others right so what else so what if this MSCT is on a remote MSC so that's an interesting problem so I have an MSCA FSM on my first MSC and I have an MSCT FSM on a different MSC so I need to somehow encode and so on so what I decided to do was on the first MSC have the same FSM definition with a different FSM implementation so the FSM implementation instead of taking action it just encapsulates into G-sub messages sends over and on the other end it's received by another de-capsulating FSM instance and then dispatches the actual event so basically the local MSC case is the same but all you do to get it remote is put into proxying FSMs in between that mimic whatever would have happened locally so what you see here is the MSCA talking to the MSCI it actually locally has an MSCI remote FSM implementation which sends over G-sub on the other end the MSCI wants to talk to the MSCA but since it's over G-sub there's a remote MSCA implementation proxying to the other side so if you see the MSCI remote and MSCA remote and MSCT remote files then you know okay this is about G-sub forwarding this is about proxying and it should be events compatible to the real implementations so just to show what the new path looks like it looks very complex but basically we on the bottom we have like a common SCCP Ryan implementation for what for both 2G and 3G and this goes up to the Ryan peer which could be a BSC or an RNC for 2G or 3G and it goes up to Ryan peer these are all the same implementations say again now G-sub is coming later so and then at this point we haven't yet even decoded anything like what the message is about in most cases like DTAP would just remain encoded get wrapped in an A and A PDU and send over G-sub or maybe this bracket doesn't exist if it's not a remote thing so here it goes over G-sub ends up at the MSCA whichever way that does it gets then the NAS the non-access stratum basically the DTAP messages and the what other like assignment command assignment complete all those kinds of messages they get decoded here in an abstract way for both run types we support so far which you see here once that's done this message gets dispatched and handled here's basically all the old code that we had with the like SMS and call and whatever handling and then when it goes back down and again goes to the the MSCA says I want to send to the I it gets encoded it possibly gets sent over the G-sub wrapped in an A and A PDU on the other end it gets decoded again like the basically the run gets taken out of the G-sub message and then sent down to the run connection and interesting new files a bit more than I bargained for in the beginning so the SCCP run is the G-sub is your SCCP interface like before we had an SCCP implementation for the BSS map and another one on the side for the IU which was also shared with the SGSN sort of made sense to me back then but now I looked at it and I saw that well like the the BSS map interface supports the reset messages and the IU one doesn't and this doesn't make sense to me and that all should just be one thing so now we have just an SCCP run which is for 3G or 2G the same thing then we have a run peer FSM which is again like a BSS or RNC is the same code for 2G or 3G it just manages like a set of cells and cell identifiers connected to a specific point code on the SCCP then the run infra is the stuff on the side where you can decode and encode messages and like the run infra lists what the coding functions are the right ones for this run and the NAS the non-access stratum is an abstraction from how runup and BSS map slightly differently encode some of the messages for example the assignment command versus the RAP assignment command request so I try to abstract the run type away completely so that basically there's the one code pass that I showed before going through the entire code so in the NAS A and NAS IU are the files implementing the individual encoding and decoding the MSC roles is basically it could be MSC A, I and T but I wanted to have an overlook of all the messages going back and forth so MSC roles defines all the FSM events for all of them then obviously MSC A, I, T and dash remote and the score remote are the actual FSM implementations the MSAP is this tank just the box they all sit in the neighbor ident is the neighbor configuration in the MSC config file MSCHO is the new FSM that handles the handover states which you also need so it creates a new MSC T and MSC T and notices when the the call forwarding is set up and then so on and so on the G sub client max is an interesting thing I added because I noticed all of the G sub messages first end up in the VLR and even if it's an SMS related or USSD related message the VLR always like first receives it and then pass it on instead I wanted to have a central hub where you receive the messages and then distribute to the individual code paths the E-link is basically your G sub E connection it's like one of the clients to the G sub client max the MNCC FSM is the MNCC connection like the orange phone cord to the PBX because our MNCC code so far is tightly glued with the GSM call control and I needed MNCC without GSM call control so I created yet another FSM it could become also the MNCC handling for this the GSM code what call control later but at the moment we have basically two separate MNCC implementations and then finally the call lag and RTP stream FSMs just for illustration in case there are questions why do you need so many FSMs because they are differently scoped like the media gateway endpoint goes on both sides and the one RTP stream is just on the run side and the other RTP stream is just on the CN side and then the call lag has to bind them all together right and now insert everything I forgot here and let's hope the crashes aren't half as dramatic as this image but I'm bracing for a fallout because the refactoring have been huge and I think a lot got improved on the on the way but obviously as always I probably broke a lot of stuff without noticing and now it's pause job to find out where I broke it you mean to report that? yes to find out yes I mean the TTCN3 tests all pass with the limitation that I had to fix a few before they started passing but I mean like they were having odd expectations or the voice call tests they accepted half a voice call and then if you do a whole one in a slightly different ordering then the whole thing falls on its face so I just had to you know fix the TTCN3 tests a bit to be more general so that's the inter-MSC handover it's still sitting on branches waiting to be merged bit by bit and review is still very welcome like the one with the wildcards for example or code design or whatever and now I'm on slide 42 if you have more questions please go ahead made? is the 42 slides made on purpose? you know I just ended up being 42 so I don't know if Holger came back and looked at the Osmo-Com Core Network code that he wrote with Harald back then he might not know what is going on anymore because almost everything has changed oh one thing I wanted to mention Vadi masked me earlier like in the current MSC master we had a reference counting which made us being able to count only one SMS transaction at a time and if another SMS or USS detrails or whatever if another one comes along our use code use count doesn't work because it can only have one transaction type at a time the new MSC can do multiple of the same kind at the same time and that's also a big improvement for the future I introduced a few bugs but I think we already found them and fixed them okay so then it looks like I'm finishing early