 So hi again I'm going to talk about external. This is the interface. Oh, yeah. I already did and first thing I'm going to start from is introduction little introduction to supplementary services and Supplementary services is another way of communication between subscriber and network like a calls or SMS messages and And you see there are two types of supplementary services One is correlated and another is called independent and what is uses D? It's Just a type of cold independent supplementary services and it stands for unstructured supplementary services data and similar to SMS It's very similar to SMS, but a real-time communication is assumed and You cannot you cannot store Your message anywhere. You just need to forward it immediately between two sites of conversation and usually uses the request looks like this way it's at risk and some numbers between them and well-known code is used still used for years and also open BC and also MSC and And Usd payload is limited to 160 bytes So we can use any encoding you want and Possible use cases for usd is activation or deactivation of some custom probably bait network services It's probably could be used for getting some information for example account balance or so one and There is also crazy application of usd is what over is is debatting. It wasn't it is not used anywhere I think and How do we support this use of D in Osmo com? We have Libosmo core api and It was written by Holger if I remember correctly and there is some abstract representation of uses D request and Response to and it has transaction identifier invoke ID which allows to relate and the response to Corresponding request for example if a mobile station sends a request to the network and network would like to know something from subscriber It will increase the invoke ID and send another request in the response to the initial request of this subscriber and As soon as subscriber will Response to this request it will be decreased to zero back and Probably the network will return the result of this operation. Yeah, there is separation quotes because SS request could be use is D. It could be correlated or Oh, it can be use is D or something different and it can also contains usd payload and data coding scheme and It's possible to do Decoding of role layer 3 message into the structure and It's also possible to encode usd messengers into role layer 3 message and What is going what I would like to do here in the future is to improve decoding decoding of Coal related supplementary services because it's not Implemented in a good way for now and I would like to implement in coding of mobile originated Usd messengers because it could be also used in as Makon BB project and somewhere else and they also for for many years we have this common code in order to request your own number in the network and if the user of this project would like to Implement some new codes here. It has to he has to modify the source code They compile this and the if the network is already working it would have to restart the network and it's too complicated and not good way and There is a solution for that we can implement external uses the interface and We already have for you external is external interfaces for a simple It is a same pp and we have external interface for voice calls It's MNCC, but there is no external interface for usd and the good question was which protocol should we use for that and Specifications Recommend to use map for that, but there is no stable implementation in as Makon of my protocol There are some attempts, but they're not final implementation and it's a Working with my protocol is pretty complicated for Sometimes it's pretty complicated. Yeah, and the SMPP could be also used for Usd sessions, but it it's not session oriented and It's mostly used for SMS and what about just sub protocol? It stands for generic subscriber update protocol It's not standard custom protocol Which was intended in order to keep the protocol complexity out of its users And if I'm correct the current users of this protocol is our wasmo HLR msc and sgsm and This protocol the implementation of this protocol also assumes easy conversation from just up to map some day we will have to use map and Why it is good to use this Protocol because it's easy to use easy to extend it and easy to convert to map in the future But it's it is also not session Oriented but we can easily extend this and this is what I did a few weeks before and First thing we need is that the main problem of my protocol is that it's a single connection and It's impossible to perform It doesn't provide any existing methods to have sessions which is required for usd and the the solution is to emulate a tick up because the map usually comes together with tick up it is encapsulated in tick up message and I would I'm going to add to Information elements one of one is the station state for example We begin or finish station and another is a unique within uniquely identifier of station and for example if Usd gateway would like to start communication with subscriber. It has to request an unused session ID and only then it will be able to Begin session and start some usd notifications or requests and For also for session management. I'm going to introduce a new message and Three types of this message it was a request result and error And also it's required to add support for usd payload In order to be able to transfer usd payload using just a protocol just with messengers and for these There are a group of messengers usd related messengers for now Yes, and there are some information elements which is Stated by a map specification as mandatory to have in some messengers for example Usd string data coding scheme because it's the actual usd payload can can be in any language supported by JSM and this is And the representation this is the diagram of communication between subscriber and usd gateway and For example when my mobile station sends a request to the network it Comes through the base station subsystem to the msc and Msc is exactly the place where all the magic happens because we need to perform some basic transcoding between The message which we just received from Subscriber and we need to create a message which we are going to forward to usd gateway and Here is a little discussion should we perform All the operations with usd gateway through the HLR or should we also have possibility to connect to Msc directly from usd gateway But I think for now the simplest solution would be to Forward every operations through HLR It could be discussed later. I think This is how different messengers on different different stages of forwarding look like and for example in the bottom you see the message coming from a mobile station and this is what we receive at the mobile switching center and We need to perform the coding of this message according to according to the 0480 specifications and Then we can convert it to Gis up and then we can convert this up to map or wherever you want Jason or someone seep for example and There is a question why Msc should parse uses the request or assess request and First of all, we need to know what is this message Are we going to start a new session or are we going to finish session or it's just some message within session or so on and we we need to know the operation code because Supplementary services is not about usd. There is also a few types of different operation quotes and We also need to know the data coding scheme used by request from subscriber or by the response from subscriber and Finally we need to the usd payload itself Here you can see the example of Communication between a mobile station and uses the gateway. I don't put HLR here But you can imagine that it is between msc and uses the gateway and for example Yeah, mobile station first sense register type of message and The operation code is process uses the request it arrives to mobile switching center and here We need to convert it to corresponding g-sub message, which is process uses the request request subtype of this message and we using this session we begin Using this message we begin the session between Subscriber and uses the gateway then the network for example My request some additional data and it will increase the invoke ID because for example, it cannot respond to the Response immediately and it needs some additional data from subscriber for example Type one for to choose some point of menu and then subscriber response to this request and finally network my Finish or wherever network wherever mobile station may Finish the conversation in any time and here is some little example of Network originated Usd for example requests or notification First of all as I already told we need to request session ID Which is unused at the moment and as soon as we get this session ID We can begin the session and for example Request something from subscriber then on the radio access network you will see page and request Subscriber should response to this page and request and now and then she will he will get Register message with Initial request from usd gateway and then he can respond and continue this conversation until Any of both sides will decide to Finish session and What's already done here is that we managed to Correct the Libos Mocor AP implementation This is only a few points which was Implemented or corrected for example in release complete. There is optional facility message and Yeah, we also had a big problem that the AP of Libos Mocor Was always trying to decode the payload using seven default seven beat alpha beat and this is not good in case of different language used and We decided to add a new fields and the abstract representation of uses the request and What I'm currently working on these msc code in order to allow multiples transactions and Just a message coding because we we didn't have these because we only had our number only one of our number request and We can just respond and finish they can release the communication immediately and what is what I'm going to do is to implement some test cases TTC and test cases and Also, there is an idea to implement counters for uses the events for example the total number of uses the request number of active SS connections for uses the connections and a number of rejected or successful uses the connections and Yeah, thanks for your attention if you have any equations Feel free to ask me and this is some specifications you can read To get some background about this topic. That's it. No questions. Do we have questions? Yeah, Keith So I'm thinking about the the ussd gateway itself, which maybe it's not part of what you're dealing with But so if you think about the problem that you said that the average user would have to modify the ussd See source code and recompile and restart and everything. Yes This gets us to the case where now if I wanted to implement some service like pull some Information from the internet or something scrape some site and send something back How would what I then have to I mean? How are you still have any ideas on how the ussd gateway part of it will work because it needs to talk Jesus up to Yes, but the MSc, right, so we need some She's up to whatever something that's easy to program Yeah, we need some interface from Osmo HLR to I don't know it can be a map interface or it can be something different or we can implement map interface between Osmo HLR and some Converter to wherever you want and then any commercial ussd gateway allows you to create Any ussd menus and codes in some graphical interface and it should work basically the the original idea was that G super is not a difficult protocol to implement and You know there's always all Apparently, you know, obviously this is implementation in C, right? And then you could either use this C implementation to convert to into something easier to process like seep and then No, we see if you can do whatever, right? Or you can do like you know routing you can route to different application servers and then each application server would handle its specific You know its specific request and you know, whatever is whatever you want, right? It's all available tool sets in open source It's very easy or You could write the G-Soup for implementation in some scripting language Oh, yeah, so Harle says as there is already a Python implementation we have Always started an or lung implementation. I don't think it's finished but we plan to send some points finish or lung implementation and Look you can with your lung implementation. You could also use elixir, which is a friendly I'll say more user-friendly version of Erlang or more new be friendly version of Erlang So yeah, I mean there will be multiple ways to do this either converting to a protocol for which you already have tools or To write in some scripting language. That was the original idea and then after that, I mean Whatever Whatever you want Yeah, so my idea would be that in the HRR you then basically configure routes like you have your SMPP routes for SMS in in Osmo MSE or Osmo NITP that basically in Osmo HRR you can say well this particular SMPP request whatever star hash 250 hash or whatever that this gets routed to a certain external program And then this external program again can as we discussed can have can use G-Soup at least for now I mean there is no standard protocol for gprs. Sorry for for for ussd So it's I mean in the end it doesn't really matter what we choose But I think rather than inventing yet another new protocol that nobody else uses so we can just as well stick with G-Soup until somebody Works on something else, but as that with SMPP it was easy because there is a specified protocol Yes, it has all kinds of weirdness and problems itself But it is something that not only Osmo come implements, but for ussd. There really is no standard or non-standard interface protocol and the only Protocol or interface that I am aware of that exists in open source is what Mobile sense is using and I have some XML RPC API from their HLR For IMS maybe okay. Yeah Okay, sorry that we had we don't have this on the recording so there is a spec in in Apparently in IMS there is a Specification on how ussd can be passed to external applications Okay over HGP. Yeah, I Feel like an echo here, so Any other comments or feedback? Is that is that part about Which one going through the HLR is that decided now or because you know we had a feel under discussion and So what is the I mean, what's what's the benefit of is there a benefit to doing it that way? Or would it be better that if the ussd gateway in itself needed to talk to the HLR that it would do that I think than having the HLR is the principle. I think one advantage of having all requests Going through HLR is that the ussd gateway don't need to care Where particular subscriber is and connect to different different mobile switching centers It can have only a single connection with HLR and communicate with you may have multiple mobile switching centers now and They are all would be connected to HLR and that's simpler And the the other point is if you somebody wants to have a map gateway, then this is the logical Approach because in in the GSM spec, it's specified that ussd ends up at the HLR So if we have it in the same G sub connection, then basically instead of Osmo HLR you can have them the map gateway which then translates it to map and You don't have any like logic or architecture mismatch at that point. We always try to keep G sub as Convertible as possible. I mean we don't have a good converter yet I mean Holger brought a small talk a map to G sub converter for GPS some years ago, but we don't have a maintained active Universal translator yet, but I mean I think it may happen sooner or later depending on user requests But another question from my site is Should we still keep this number request feature of open BC and Osmo BTA Osmo BC? Sorry, I didn't get the question The question is should we still keep the feature of possibility to request your own number in Osmo MSC? I was no not an Osmo MSC if at all that needs to move to the HRR So I don't think the MSC should do anything with ussd It just forwards it over G sub and then any any handler including the star hash 100 handler would either have to be Inside the HRR which in this case actually makes sense because the HRR knows what that number is Or basically handled to an external application that connects to the HRR. Yeah, but There was a discussion about having a local or remote policy of ussd connections and probably this is not the only one ussd code the One would like to handle inside the HRR probably we can implement some Capability to change this code. For example, we might define some services like get your own number get your own Emsi team see for example and let the user Yeah For developers, it's perfect. Yeah Get your own. Yeah, anyway No, I think yes, you can implement all those things, but they all belong at the HRR It does know I mean the fact that we implemented this in in MSC is because we implemented in it Be because we implemented everything in it be but now I think there's no Reason why this should be handled at the MSC level and as you said you can have multiple MSC So then every MSC needs to have the same configuration with the same such services. Otherwise, it's it's going to be Complicated and the other point is if you think about roaming scenarios Even let's say only roaming within G sub between multiple networks and then also you want to have those services at the home HLR of the subscriber and not at the visited MSC of whatever network he's currently visiting So I think I don't see why the MSC would keep such functionality Yeah, I think it's important to keep us as the all uses the functions outside of MSC and HLR for one simple reason for internationalization reasons of what translation reasons, I mean we don't want to have You know all kinds of you know translations and I 18n in Osmo HLR and you know, we don't want to All this stuff in there. So it should be external just for for this simple reason Yeah, this is why we only extract the actual row uses the payload and specifies that according to human Yeah, and like the previous version of IPA We don't try to decode it using default jsm alphabet anymore We keep it for compatibility reasons, but we also have these row bytes Yeah, I mean That's that's it. So basically Osmo from my perspective Osmo HLR should be just a router of Those connections. That's it. And what do you think about a way the way how to configure this routing via VTI or some configuration files Yeah, I mean Harald probably have a better idea, but some VTI the same like we are doing for SMS or for yeah for a for a same pp I guess for like prefixes So this prefix goes to this direction this prefix go to that direction. I think there is a Or the default default route obviously and you know prefixes and then I think there is already some border plate code for this Because it's already used for The other Approach to do this would be to have the the external application register for a given USSD code so not have a Config file that way you have a table of all the USSD codes and point to certain applications But rather have a dynamic registration So you basically when when the external application connects as well. I register myself for this prefix Which is a bit like we do with point code registration and the STP It sort of requires you to have less configuration But then it makes it more difficult because you don't have a central routing table anymore And if two applications request the same code, what do you do at that point? So it becomes a bit difficult, but it has advantages and disadvantages Any other comments Thanks One more I like Just a quick follow-up on that So if you have if you do have an interface where applications or handlers can register then There are essentially two modes or like two things that can happen if two Applications want to register for the same USSD either they get they both get to do to act on this or There's a race and whoever wins Introduce some kind of priority Who made this first? one further Is it's related? I think what up this? standard call forwarding and voicemail forwarding and stuff that even some some user equipment At in see a touch time always asks the status of these things anyway Where if that were to be implemented in the HLR right so But then I guess if you are Handling calls route routing with some PBX or something you just need to we have some limitations at the moment that we only Handle uses derelicted elementary services and but and not but it could be modified But it also requires modifying of Libre smoke or IP IP which is a bit painful Yeah So what would you refer to like the call forwarding and that conditional call for one unconditional call forwarding and so on that's a supplementary a structured supplementary service, so that's just an SS not a USSD It sort of looks a little bit like similar on the radio interface, but It also like according to spec I think it also goes to the HLR and then these settings are actually stored in the HLR according to spec like what kind of forwarding or what kind of configuration you have and Then one would have to in order to integrate with PBX is basically an external PBX would have to query that Somehow in the HR. Yeah Okay, thanks Vadim. I think we can move on to the next speaker then