 Yeah, this talk is about SMS, external SMS interface for OSMA-MSC, not used here anymore. And I'm going to talk about SMS in general. What is it? Some interesting facts about SMS. How does it work in commercial networks? Map or T-CAP-based? And how is it implemented in OSMA-CON infrastructure? So what's SMS for a regular user? It's a kind of service that enables you to exchange short text messages. And it's basically available in almost any network and supported by almost any phone. And for an OSMA-CON developer, first of all, it's a protocol stack. And it's kind of a complicated protocol stack. There is control layer, relay layer, transport layer, and only then application layer. That's exactly where you type your text. And it's a nice target for fuzzing. There is a talk, SMS of this. And they actually managed to break some phones during this fuzzing session. If you're interested, you can check it out. And some of the most important specifications, as Harald already mentioned, there are basically two kinds of SMS. One is tele-broadcast. And this is behind the scope of my talk. I'm going to talk about point-to-point SMS. Well, the first specification is mostly about the transport protocol. The second one is about the control protocol and the relay protocol. And of course, MAP describes how different parts of the core network infrastructure interact with each other. So some history. The initial idea of having short messages appeared in the early 80s. So there was a kind of cooperation between two German and French guys. I don't remember exactly. Friedelme. Anyone knows how to pronounce this correctly? And the second line, yes. Anyway, in 1984, they developed the initial concept of SMS messages. And the key idea was to use signaling channels of GSM. At that time, it was highly voice-optimized. And we see a similar problem today with LTE. It's a pure packet switch. And there is almost nothing for SMS and for UCSD and even calls. And Hilibrand actually analyzed some tele-text messages and something else. And decided that this limitation, 160, 7V characters, should be enough for everyone to express all the minds. And Twitter actually is following quite similar limitation. But actually it's 140, as far as I remember, for any kind of... Why? Well, because you can tweet using SMS. Yes, the prefix is wider. Yes, it will be something about it later. So in February 1985, the first proposal of SMS that initiated actually the development of SMS. So it was accepted, approved by JSM Group. And in JSM O2, O3, there were specified two types of SMS, SMS point-to-point and SMS tele-broadcast. And in December of 1992, the first SMS message with text Mario Christmas was sent. And it was in the UK over a water phone network. And in 2010, around 6 trillion SMS text messages were sent. And today I think they are mostly deprecated by some instant messages like telegram and so on. You just don't need to pay. But still they are actively used for like two-factor authentication or some different notifications and so on. So some interesting facts about SMS. Like SMS can not only be sent to your phone, it can be sent to your SIM card or from SIM card. And you can watch the secret life of SIM cards for more details. They can also like establish GPS channels. That's not the limit. And another interesting fact is that SMS can be basically sent over GPS. And that's more efficient, unlike SDCCH. Because packet switch demand is kind of TDMA over TDMA and multiple subscribers can share the same time slot. And I think personally that silent SMS doesn't make any sense because you can basically just establish an SDCCH channel and the result would be the same. If you have any ideas about it. You can establish a channel if you have control of the base station or the BSC. But if you are an outside operator and you have only interface to SMSP, then silent SMS makes sense because you don't control the network. So whatever the network operator is providing a service to low enforcement or whatever, their silent SMS makes sense. But I think they could provide some kind of service that would just establish an SDCCH channel. Instead of designing this behavior of mobile station just to receive and not indicate this SMS arrival. Do you have SMS going to SIM card? Other than showing to the user? Yes. But this silent SMS, I don't know, for me it's kind of useless. Just to establish a channel. Maybe there are some other use cases. I mean if you want something to establish a channel which is both authenticated and ciphered. If you want to establish a channel that is authenticated and ciphered at one time out, you actually have to start a transaction with the SMS and actually do something. Okay. Makes sense. That could be used for that. Okay. And as I already mentioned, you can tweet using SMS. And I think Twitter was inspired by this limitation. And why do we need an external interface for SMS? Well, we have kind of built in SMS center in Osmo MSC. But it's a kind of rudimentary implementation from old network in the box times. It's very limited in baggy. Like a few weeks ago, I've been writing some unit tests for it. And it's far from being perfect. And normally SMS center is a kind of separate entity of JSM network. And we need to be able to talk to some commercial implementations of SMS centers or implement our own SMS center. Or if you even have like multiple mobile switching centers, they definitely would need to connect to some single SMS entity. There is no need to maintain separate databases. And Osmo MSC also does support SMPP protocol. But the problem of this approach is that it involves some kind of transcoding between TPDU, the transport protocol and SMPP protocol. And that's maybe something that's not desired. And I will make it a bit... Yes, so this is kind of graphical representation of the SMS protocol stack. And it's a bit different on the radio access network and different on the core network. So you have your application layer. Some basically it's just text of your SMS or wherever. You optionally might have a user data header. It's used in case of multi-part SMS where you can indicate which part is it and how many of them is still pending. There is also next is the transport layer, transport protocol. This is probably the most interesting protocol. It's lots of fields. You can check the specifications. Relate protocol is basically used to acknowledge the reception and storage of SMS. It means that some entity has received this message and it was stored and there is no need to care about it. And a control protocol is used just to acknowledge reception but not storage of SMS. And when it comes to MSC, we basically replace both control and relay protocols with MAP. So we encapsulate the TPDU together with the application part into MAP forward short message. And then it travels to some SMS center or some other gateway MSC. Some messages are the most important for us. As you can see, CP protocol is quite easy. There is CP data that's commonly used to transfer some RPDU payload. CP hack, it means that okay, I received this. And CP error means that something wasn't received. RP data is used to carry TPDU. It's the transport protocol. And the SMMA is used to notify the network that some mobile station has memory available to receive at least one SMS. There is also RP hack, RP error. It's probably when there is no space left to store SMS, mobile would send RP error message with proper case. And then on the transport layer, we have like SMS submit, SMS deliver messages, deliver a report. And some SMS comments. As far as I remember, it can be used to, for example, remove already sent SMS from SMS center. There was something about this in specifications or even modify. So you can basically send some SMS and then modify it. If you are quick enough, I think. So that's how it works in commercial networks. There is SMS center. There is mobile station. So when you send some mobile originated SMS, first of all, of course, the channel establishment, authentication and cyphering optionally happening between the MSC and then mobile station. Or sometimes SGSN also can be kind of relaying entity of mobile originated or mobile terminated SMS. Mobile station basically sends CP data, like not SMS submit encapsulated into RP data and encapsulated into CP data. The network just confirms that it just received this payload and sends, now it requests some information from the VLR. And usually some commercial networks have kind of gateway MSC. So it's kind of central rotor for commercial networks. So you're serving MSC, basically initiates T-CAP transaction to the gateway mobile switching centers. And forwards the TPDU payload inside this map mobile originated forward short message. And the gateway MSC would take care about forwarding this message to the SMS center where it's going to be stored. So as soon as SMS center confirms that message was received, we actually send some acknowledged message on the map side. And then we confirm to the mobile station that your message were stored. So we say RPAC. And then mobile station confirms that it's received this RPAC and sends CPAC, just to be sure. Okay, and in case of fail delivery, the SMS center may reject these SMS. And so we say NAC and we say RP error with some cause that something went wrong. And in case of mobile terminated SMS, things get more complicated. Like first of all, the SMS center forwards mobile terminated message to the gateway MSC. Then the gateway MSC needs to know which MSC to contact, where is the subscriber for which this message is going to be forwarded. So it contacts to the HLR using maps and routing info for short message, as far as I remember. And it basically indicates the MSI is the end of subscriber. And the results, the response should contain either MC or LMSI. It's kind of team C, but on the map. And the MSC number that we need to establish tick up transaction with. So we establish transaction and forward mobile terminated short message to the serving SJSN or MSC or subscriber. Then there is a page request happening again, channel establishment. And then the serving SMS just forwards it's using the same process like RP data, CP data and so on. So RP from MS triggers, map, short word, empty, forward message. And then it's delivered. But we are not implementing tick up nor map. In Osmocome we are using gsup. And there are a few reasons. One of them is that we don't have reliable implementation of map in C yet. We need to deal with ASN1 encoding. And then we also need to deal with some lower layer protocols of map, like we wish it's being encapsulated. So we use gsup. It stands for generic subscriber update protocol. It's a simple TV base protocol that runs over TCP, IPA connection. And then we basically abuse Osmo HLR as the kind of gsup router. There is no such thing like gateway MSC, we use HLR for that. So everything goes through Osmo HLR. Over a single TCP, IPA connection, there is no such thing like multiple connections. There is no direct communication between the core network entities. Everything is done through Osmo HLR. So we have the following gsup message types. Basically, they are quite similar to map messages to be able to easily convert between gsup and map. So there is mobile-originated forward short message, like request, result, and error. That's usual variations of messages in gsup. Mobile terminated message and ready for short message. This message is used when either mobile station indicates that it has some memory available or it wasn't connected to the network. And when it does seem to attach, the MSC should notify the SMS center that the subscriber is ready now. So we have some basic information elements like destination address, originating address, the TPDU itself, and more messages to send. That's more or less generic information elements from the map specifications. Other reason, of course, also a part of this specification. But since we don't have T-CAP, we somehow need to distinguish between kind of transmissions of SMS because we're still using a single TCP connection. So we basically expose RP message reference that's used to kind of properly ask to some, like to acknowledge some RP data or indicate some error. And we also expose the cause information element because we don't implement any kind of mapping. It was generic cause and RP specific. So that's how it looks like, or probably. So the first part is the same. Mobile station establishes some SDCC channel, for example, sends RP data with SMS submit, the network forward seats directly to the HLR using mobile originated forward short message request. HLR should look for the destination address and should find the SMS center and just forward this message to the SMS center. And from the SMS center, we get either the results, which means successful delivery of this SMS. So we RP acknowledge the SMS. Either we get some error and we indicate this to the mobile station. So it's quite simple. And mobile terminated SMS delivery is a bit more complicated. I don't know, can you see it or not? On the top part, we have like SMS center basically initiates mobile terminated SMS transmission. And at that point, it doesn't know the message reference that's going to be used because it's assigned by Osma MSC. So we use any invalid value for message reference. So it's getting forwarded to Osma HLR. Osma HLR connects to Osma MSC forward this message. Then Osma MSC establishes an SDCC channel with subscriber and just forwards it. So we also get either empty forward as some result or error message. So what we basically support is mobile originated message delivery, mobile terminated message delivery and kind of alerting when mobile station has some memory to receive some SMS. We have, I think, more or less complete TTC and testing coverage. The only part that's probably missing now is proper handling of multi-part SMS. The problem is that the SMS center may indicate that there are some more messages to be sent. Like if you are running behind the limit of 160 characters. So the MSC should basically keep connection until the last part. All the parts are delivered because there is no need to terminate and establish connection again and again. It would just resource waste. The current reference counting implementation in Osma MSC doesn't allow to implement this properly. So I'm looking forward for the patch of news to be merged. So hopefully it will make everything simpler. Regarding the GPS package switch domain, I don't think it's that important for us to support this kind of delivery at the moment. Another important thing is that SMS over just up breaks SNPP support. You cannot have SNPP and SMS over just up at the same time. Because for example, if some message is getting sent over SNPP, it can be forwarded to Osma HLR because we don't tack from where does it come from. It can be solved, I think. So that's why it's disabled by default. And if you need to enable it, you just go to the VTI and just set this SMS over just up parameter. So I was going to show some message examples. The recent version of where shark was should support all just up messages we have at the moment. And curious what's happening. So this is mobile-reginated SMS transmission. So Mobile Station initiates a connection with service request with short message service. And then it just sends there, as I already said, RP data inside CP data. So the network does acknowledge reception of this. And then it basically forwards to the HLR. I will somehow make it bigger. So IMSI is mandatory part of every just up message. Then we have message reference. It was 42 in this particular example. We have destination address. It's most likely the number of SMS center. And we have originating number, originating addresses that just MSI is the end of subscriber that send this SMS. And we simply encapsulate TPDU of SMS into our just up message that's like map does. So there was no text. And then we receive acknowledgement for that message reference. It means that SMS was delivered. There is also, I think, ready for short message. Yes, it wins when the mobile station notifies that it has some memory available. So we just forward it to the HLR to the SMS center. There is mobile-mobile terminated message example. So this moment was my HLR initiates transmission towards my MSC. Then we initiate paging procedure. Then we get paging response, send this to the mobile station and so on. So as soon as mobile station acknowledge this RP data, we just send forward some result with the same message reference. That's the key point. I think that's more or less it. If you have any questions, microphone is yours. So, yeah, the question is why are you routing it through Osmo-HLR? I guess because you need some information stored there, but why it was decided to do it like that and not have some other process outside of Osmo-HLR to actually request information to Osmo-HLR when it was needed? Well, it was kind of decision to make HLR kind of central gateway like commercial networks do. But in the case of commercial networks, it's called gateway MSC, but we have kind of gateway HLR. So it's simpler and probably Harald can... But still the gateway is a separate entity, right, from the HLR or from the MSC in that case? Well, yeah, in our case it is, but not in commercial networks. Not in commercial networks, of course. HLR in general is not dealing with SMS delivery. Yeah, so I'm just wondering why not just having it in another process, you know? We would have to kind of complicate our github connections. We would have to implement direct communication between like SMS center and Osmo-MSC. In our case, Osmo-MSC is just a TCP client that connects to Osmo-HLR and that's it. So, yeah, basically you want to have a simple setup for the non-map use case and simple means you want to have as little of the complexity of setting up, you know, extra point codes and extra routes and all the kind of stuff that you would need on whatever level. You just want to have a simple single TCP connection and that's how Osmo-MSC has always handled it. And now you want to be able to swap in either to use Osmo-HLR or to swap in whatever other gateway. So, I'm not sure what advantage it would be to split that up into separate functionalities because either you want to interoperate with a map or a diameter or whatever external network and then you need that gateway and for sure you will not use Osmo-HLR or you will be using Osmo-HLR but then there's no point in having a gateway. So, I think there's a very clear distinction between those two use cases and I don't think there's a need to mix them in any way and complicate the network setup. Actually, maybe one can comment because they are the moment developing some kind of converter between just up and map. So, it works. It just works. So, they basically don't use Osmo-HLR? Yeah, so we don't use Osmo-HLR as far as that. So, it's okay. You just use all G-sub traffic on one port, so it's okay. Is this gateway open source? No. Because we use TCP and MAP and SS7 stack, it's not open source, so that's right. So, now we can pretty much split up SMSC from MSC using this protocol and move SMPP for example there in this case. Definitely. The problem gone. That's actually how commercial mobile switching centers work. There is no SMSC in them. It's usually a separate process. So, related question then, how did you test it? What you used on the other end of this connection? I usually use TTCN through test cases. Of course, you can implement something in C, but it just works with TTCN. I'm actually thinking about some little proof of concept implementation of SMSCenter that would just store something in the SQL database just to show that it works. Maybe, but I would need to do this IPOA. I don't know. Oh, okay. That would probably make sense. Any more questions? I think Holger had some questions. No. Okay. Thanks. Thank you.