 Okay. Then welcome to the next talk, which is about production grade cell broadcast. You will see I have removed the production grade from the slide. If you pay close attention to the schedule. So this is about cell broadcast in OsmoCom, and we quickly look at cell broadcast in general and also what this project is about and what we can expect from it. So in classic GSM, we control plus is difficult to reach. In classic GSM, most channels are point-to-point. So we have like, you know, an SDCCH, a TCH, all that stuff is point-to-point. It's between one phone and one network, and there is no point-to-multipoint communication with some very rare exceptions. Of course, there's the BCCH, but that's not really containing any user information. It's only for internal management. And we also have the VGCS and VBS. Actually, I should put all those acronyms and ask you guys what it means. So what's the MBMS, by the way? Who knows what the MBMS is? Multimedia broadcast. It's sort of a messaging system, but a multimedia broadcast for sure, yes. But I'm not sure about the second M, but yeah. Okay, yeah, so the VGCS, VBS is a voice group in broadcast calls which only exist in railway GSM but not in normal GSM networks where we actually have TCH, like a downlink TCH, that is received by multiple phones. I really love it, but it's unfortunately not supported by many phones. So it would be really nice to play with that, but it doesn't really exist outside of railway. And MBMS is multimedia. Basically, it's IP multicast for packet switched. But it was specified for 2G and 3G but never deployed there. And now I think it's sort of more on the agenda for 4G and 5G again. And actually broadcasters are looking into that as a new way of broadcasting TV over 5G. I'm not sure what kind of sense that makes, but that's not my position to comment on. So the only way to really broadcast information to many subscribers at once is the cell broadcast mechanism, which is officially called SMSCB, the short message service cell broadcast. Which means the short message service that we all mention as SMS is actually according to the spec is SMSPP, it's the SMS point to point service, which we always neglect to add. So if you talk about SMS that actually includes both the point to point and the cell broadcast service. And the main use case of this is for emergency and disaster warning. There used to be some other use cases which I think are more artificial in nature and mostly of historic interest these days. I'm not sure what like soccer results being broadcasted to people on there like Nokia or Siemens phones in the 90s. But yeah, so it's really emergency notifications. And why is that? Well, particularly if you think of regions of the planet that have earthquakes and or tsunamis resulting from earthquakes, the warning period you have is very short. So with earthquakes I think the state of science is that you're happy if you get something like four seconds of like advance notice that there will be an earthquake. Like it's in a definite prediction. And so it means you need to be really quick to get notification to as many people as possible so they can rush underneath tables and things like that. And using any kind of point to point mechanism. I mean, yeah, you can imagine how many STCCH you can establish within those four seconds and how many like point to point SMS you can deliver. It's not realistic. So the only real way is to use a broadcast mechanism. And many different countries have specified emergency related services on top. There is in Europe, there's something called EU alert, which then has national implementations like UK alert or an L alert. I guess you will know what the UK and L is about. There's no DE alert as far as I know. Because German disaster whatever authorities apparently think that they can cut one at app on Android is the way to go, which for sure will work to notify lots of people in very short time. So there is in Japan, there is the ETWS, the earthquake and tsunami warning system and there is other systems in other parts of the planet. I think there's also a Korean implementation and some American CMS, which is renamed to EWS or WAS, I forgot. So how does SMS CB look like? We have a message that consists of a maximum of 15 pages and each page has 82 bytes of payload data. So if you use the 7-bit alphabet and then you have 93 characters, if you use some other alphabets as in SMS point to point, you must have less space in there. The messages are so optimized that there's no A in the message anymore, so it's messages which are broadcast on logical channels and the logical channels are really more like an address. So you have like somewhere in the header you put 23 and then basically this message is in channel 23 and on the phone side you can then have logical filtering whether you're interested in 23 or not. This logical channel or address determines what kind of message it is and on older phones those who are old enough of you will remember that you could actually select which cell broadcast groups to subscribe or not subscribe on old phones. So you can? Yeah, okay, the comment was you could even choose the language in which you would like to subscribe. I haven't looked at that aspect yet, but yes, I know there is language indications in the SMS CB header so you can actually have the messages in multiple languages. If you want to learn more about this actual message structure there is TS03.41 or 23.041 which describes that in detail. I haven't really studied that part in that much detail yet because well, that's sort of what's in there, okay, fine, but I mean I'm more interested in the transport and the network architecture. So how does cell broadcast work as it's specified in GSM? Well, you have I say the user, in this case that's the emergency service or whoever issues such a broadcast message which is sent over a proprietary, non-specified interface to the cell broadcast center which somehow reminds you that there is like an external entity sending an SMS over proprietary interface into the SMSC. So it's really very similar to point to point but yet basically an unspecified interface. Then there is the cell broadcast center, the CBC. It's not the Canadian Broadcasting Corporation and then there's a protocol by which the CBC will forward those messages to the BSCs. You see there's no MSC in that picture so that is completely independent of the MSC. So your HLR can be down, your MSC can be down, your SGS and everything can be down as long as the BSCs are still alive and the CBC is alive you can actually push those messages just around. So the CBSP, the Cell Broadcast Service Protocol then pushes it to the BSC and the BSCs use special RSL messages to then push the messages to the BTSs which then transmit it over the so-called CBCH the Cell Broadcast Channel to the mobile station. Now if we look at this in terms of ladder diagram it looks a little bit like this. It's exactly the same just drawn as a ladder diagram. So we get some new message from the actually it's called the CBE, it's a Cell Broadcasting Entity it's a little bit like an ESME or something if you think in SMS terms which sends a new message into the CBC over this proprietary unspecified protocol and it includes information like the duration for how long time is this message valid and in which geographic area should it be broadcast. The CBC then determines which BSCs are within that geographic region and then issues so-called CBSB write-replace requests to the BSC and the BSC in turn then determines which BTSS are within that geographic region and then it also performs scheduling because if there's many different broadcast messages that you might want to send at the same time of course there's some priorities and you need to pick and choose which to send when and then it actually issues so-called RSL SMSCB commands to the BTSS and the BTSS then will actually transmit the messages over the Cell Broadcast Channel and each 80, what was it, 82-byte payload where was it, yeah, 82-byte payload which ends up in 88-byte with headers is split into four blocks of each 22 bytes and if you remember 22 just fits exactly into the 23-byte MAC block size and now you know how it's transmitted over the radio interface. So you have these four blocks in the CBCH and the BTSS itself doesn't do any retransmit unless this RSL SMSCB command said this is a default message that you should transmit whenever you don't have anything else to transmit in the CBCH and also at times the BTSS can send a CBCH load indication so that the BSC has an idea how much percent capacity of the Downlink Cell Broadcast Channel are currently utilized which can help the BSC in this task of scheduling the different CBCH messages. Yeah, so what do we have in OsmoCom today? It's rather simplistic. Daniel and I were hacking at this, I don't know how many years ago, at Congress. Sorry? Yeah, yeah, yeah. So what we have, we don't have a CBC, we don't have a CBSP, we don't have all that stuff, we just have in BSC we have a VTY command which is a proprietary interface by which we can insert a hex dump of an SMSCELL broadcast message which will then trigger a single SMSCELL broadcast command to the BTS and the BTS will then take care of this transmission and this used to work once but in absence of testing it has broken over time, I fixed some parts of it for some BTS models again and it traditionally was not implemented on OsmoBTS TRX but I added it I think at some point last year. So even that what you see there is not 100% working at this very point in time even though it was working. So how is the situation going to look like soon? Well there is a funded project now by Prototype Fund that I applied for to complete the SELL broadcast implementation in OsmoCom and that's to be completed in third quarter 2019 and it covers at least the full support for 2G and 3G and if time permits within that budget also the 4G related part will be implemented of course only up to the point where we send the respective messages to the MME and if there is no open source MME that can consume them and that's not the scope of this project. So let's look at all the different functionalities required to achieve that. So in the BTS and that as said to a large extent exists already basically what happens is that one STCCH in an STCCH4 or STCCH8 is replaced with the CVCH so in the TDMA multiplex structure and then you advertise the CVCH presence in the VCCH don't ask me which system information message it is but somewhere in there you can indicate it and then you receive these SMS broadcast commands from the BSC where you need to divide these 88 bytes into 22 byte blocks and then you transmit them in what's called a TS04.12 SMS broadcast request on the SELL broadcast channel. So the encoding and everything is exactly like an STCCH or like a PCCH or the CCCH and the difference is just that it exists in downlink only and you don't have anything in uplink during that time happening. On the BSC side so as said on the BTS side that exists at least for Osmo-BTS and it should exist also for Osmo-BTS tierics so far needs to be completed for all the other models and test it. On the BSC side what we need to implement is this SMS-CB protocol towards the CVC and then we need to distribute the respective BTSs since we don't really have a notion of geographic scope we probably just push it to all the BTSs that are currently connected we need to do some scheduling in case there's many different broadcasts but that will be rather simplistic I mean as said these days it's only emergencies really so we don't really need to worry that there's like 15 different emergencies and they need to prioritize between them at a given point in time and then we need to process a bit of flow control so we don't overflow the CVC-H and the BTS. There's also load status inquiries that the CVC can send and ask us basically what's the load on the CVC-H is their capacity for more or not. The CVC itself will be completely new Osmo-CBC program which has the following functions it receives SMS-CB from the external users which is the emergency services receive those we have to invent some protocol will be probably something rather simplistic Sorry? In the CVC I'm not sure but yeah I haven't really thought too much about it I don't want to comment on that that will be seen once it's in development we then need to distribute them for the BSCs and well have maybe some notion of geographic scope where you can see this is where the BSCs have coverage area and then also handle this exploration in terms of time so that when the time out as specified by the user has expired that we remove the messages from these BSCs so that the BSCs don't send it to the BTS anymore and the transmission stops. There was a question there on the phone, yes you have to switch, move the switch up Yes So did you think about the possibility to actually add that into MSC together with a VTY command or something? Similar to what we had in BSCs I have the feeling it's good because then you can send it to all BSCs because the MSC knows about all BSCs there so it can be sort of having an internal one like we have for SMSC I didn't really think about it of course we could I think the only real option we have is to run the entire CBC inside the MSC because of course every BSC only connects to only one well actually strictly speaking the CBC needs to know all the BSCs because the TCC connections are originating from the cell broadcast center to the BSC and not the other way around that's how it's specified at least so it could be implemented there but the point of this project is also that this can be useful even outside of OsmoCom if we implement a cell broadcast center that speaks CBSP to BSCs and has some external interface that can be used on any proprietary MSM network out there because it just uses a specified protocol so I intentionally would want to keep it separate but maybe we can have some intelligent mechanism by which over control interfaces so it can query the list of BSCs from Osmo MSC or something like that but conceptually I think makes sense I was just thinking as having also the MSC being one possible client to that interface it can also work that you can basically on the VTY issue a cell broadcast command when the MSC would send it to the CBC and the CBC would send it to the BSCs okay so well how does it look on the radio interface let's skip that the RSL broadcast command I think also we can as that it can be either default or a non-default message with 88 octets C protocol what kind of procedures do we have there it's spoken on an unnamed interface it's quite funny there is no acronym for the interface actually it's just always called the interface between the CBC and the VSC and there is no everything alright there is no formal syntax description it's a good old human readable table in some word document specification and it runs over TCP port 88049 interestingly over TCP and even on GSM it's spoken over TCP but of course then they assume in the original specs that you do that TCP IP over PPP over a serial line right because the BSC doesn't have any IP connectivity natively so that's sort of how it's a specific interest but at least they didn't use you know X25 or whatever some kind of you know frame relay or whatever and specify it over TCP there's a couple of procedures it's actually not just the key procedures it's actually all the procedures that exist there's a write-replace procedure which is basically well either you write a new message or it's like create or replace I would call it there's a kill procedure which is funnily named which is basically delete and you will see there's some interesting development there there's load status inquiry and the message status query which basically gives you information about whether or not it has been broadcast and there's an optional set DRX procedure which relates to well some optional thing we won't implement about the discontinuous discontinuous receive cycle and there's a reset procedure which like in all the interfaces if one of the two sides dies or loses state you can reset the interface state and let the other side know that it's gone now that was all 2G now in 3G of course it's a completely different thing as we know first of all it's not a cell broadcast it's a service area broadcast the SAB not to mix up with an SAP service access point so again you have this proprietary interface to a cell broadcast center which has retained its name like MSC has also retained its name but then there is a new protocol called the SABP the service area broadcast protocol which is spoken to the RNCs and the RNCs then again transmitted over IUB to the node bees which then transmitted over the broadcast message channel on the common traffic channel the CTCH to the user equipment and if you look at it it's extremely different from 2G the diagram looks exactly the same just that some acronyms are replaced okay is the equivalent in HNB for phantom cells yeah so the let's say the nano 3G for example they supposedly implement cell broadcast support we haven't tested it yet but at least the datasheet says yes we do so we should be able to actually test all of this with our 3G equipment yeah so as you see it's the same thing but with other acronyms and actually there's some slight differences there and the differences are that actually you see here there is exactly the same message between the RNC and the node bee and the node bee and the UEE this is due to the different level of functional split in 2G and 3G where the node bee really is a very dumb transceiver between a wired interface and a wireless interface it doesn't really do much intelligence itself and that's why actually the entire scheduling and whatever is done already in the RNC and this is really just relaying from a wired to a wireless interface so the node bee really doesn't have any functionality in this it's completely transparent it just passes it from left to right and that's it the RNC pretty much does what the BSC does with the additional functionality of doing the low level scheduling which the BTS is doing in 2G but now it's doing the RNC here and in the cell broadcast center well it's exactly what it needs to do in 2G but of course there's a new protocol which is doing exactly the same thing which is the SAPP protocol which is spoken on an interface that now has a name that's called the IUBC interface it's specified in AS1 as everything in that 3G had to be specified in AS1 using a basic packed encoding rules and originally it was transported over something even more obscure than IP over PPP and that is over LCAP over SAL over AL5 over ATM so that's ATM yeah later it was adapted to TCP you can find some sources on the net that some equipment vendors also implemented over UDP or over SCTP I don't know why one would want to do that but well the spec says it's TCP so we'll implement it over TCP can somebody please take care of the guy who is taking the lunch and yeah so it's typically established in the CVC to RNC direction so again this sort of opposite direction the procedures are well the same except does anyone notice what's the difference in the procedures here yeah the DRX has been removed correct max get some bonus points oh there is this one so yeah that's the the procedures that are there I'm not sure actually if it's still the kill procedure because at some point in the evolution from 2G to 40 the kill procedure was renamed in something less lethal I actually found that quite funny that in 2G you know this was specified in the so the yeah that was renamed at some point so if we look at an IUH based interface with an H&P gateway that's exactly the same situation from the CVC point of view you talk the IUBC protocol it's just that then you're not talking to an RNC on the other side but you're talking to the H&P gateway to the H&P GW which then takes care of distributing it to the individual H&P so if we look at 4G before we can finally close this session there it's rather similar again so we have some external user that over a proprietary protocol talks to the CVC and the CVC then has yet a new protocol called the SBC interface with an SBC AP protocol talking to the MNE and the MME will distribute it over S1 to the ENOTB which then transports it over something that I didn't really... it's some NAS message probably some... no it's actually in the system information blocks yes I actually so it becomes part of the system information that we're being broadcast by LTE in this case are we reusing that for 5G because it starts with G so it should be evolved right where is G? generic cell broadcast I'm saying the generic cell broadcast that we had before in LTE was replaced by something that is dedicated for emergency warnings only so basically they removed all the general purpose use cases and said this is only about emergencies it actually reflects itself in this message where it's now longer a write-replace message but it's now a write-replace warning message and to make sure and also you see on S1AP it's a write-replace warning request and an SIP warning but again the same logic the same... the same... what's your name? that's your name what's the problem with the backdoor? system information block so yeah it's exactly the same logic again so the replace procedure yeah as I said it has been renamed a bit but otherwise it's the same conceptually the functionality is also again very much same so the ENLB receives these messages and it just schedules them to transmission over system information blocks the MMC is doing very much what the BCOR and C was doing but it doesn't need to do any of the scheduling because that's inside the ENLB and it's basically just a distribution function so it receives a write-replace over SBCAP and then it retransmits that over S1AP and the CVC is basically accidentally doing the same as in 2G or 3G but has this additional protocol which again is specified in ASN1 is now operated over 4G in 429.168 and you have again a subset of the procedures so which procedure was removed this time yeah now it's the stop warning but I think actually there is something else the reset procedure has been removed interestingly for whatever reason yeah so that's basically how it works on 4G in 3G looking at Wireshark to help us with the development of that we have a detector for the TS04.12 messages we also have an SABP that's 3G a detector, we also have an SBCAP detector that's 4G but for CVSP for 2G there was none I wrote one last year but it's not really tested yet because we don't really implement those interfaces yet so hence it's not in mainline but somebody also sent me a CVSP trace from a real world network and I think apart from one or two mistakes we called it fine so yeah if you want to read specs these are the pointers and yeah as I said by later this year we should have all of this implemented and working good questions there are these geographical scopes it's not clear for me how they are translated into the set of base stations that what is for example format of this geographical scope and how BST is now which base stations to select well there is sort of I mean I don't know how it's encoded in these protocols I haven't looked at that detail yet I know that in let's say location based services and other things there's actually a way how to encode GPS positions or polygons or you know like geographical areas and there is sort of the implicit assumption even though it's not required anywhere that some entity whether it's the OMC or whatever in the network will know where exactly the location areas are and that somehow this can be translated but it's not standardized or specified anywhere so I'm just taking a look at it's pretty much stock Android phone SMS app and it seems to have two configuration sections one is entitled emergency alerts and the other is entitled SMS broadcast and within the SMS broadcast there is an add channel ID function right and the emergency alerts is just either on or off so is that emergency alerts is that relating to the 4G only stuff what's the difference between these two it's basically just one particular channel inside SMSCV where the payload format is structured and not unstructured text so there's some additional information and some additional information and a long field for signature that shall not be used so it's basically an application on top so you see like one of these channels of SMSCV has another protocol layer on top and that's these emergency systems okay just I don't know if anybody might be referencing their own phone looking at the talk stream there's also an area info channel specific ID 50 enabled or disabled function what's the functionality of that I don't know yeah exactly and from phone to phone so there's many different configuration options that some phones have and some not and in the US it's legally required that presidential level alerts may not be disabled on the phone the president must always be able to reach you should be the other way around and receive the message from the president from which yeah I think it was the current president it was recently years ago I think 02 sent the location of their base stations via cell broadcast to everyone I think there was the same mechanism right yes yeah so indeed some operator in Germany used to do that and they said some others had some services where they would broadcast the soccer results and I don't know what other use cases people came up with weather forecast I think was also at some point yeah but that's that's an emergency somehow not a natural yeah the area code was Vodafone did that for a long time to the current area code as in the landline area code of the region in which you're in because that would have a different rate it's more like a local called as opposed to a long distance called outside of that area so yeah these were the marvelous use cases yeah microphone so the connection is always from CBC towards R&C equivalent right yes so as long as we can scan short on whatever and find open ports we can just sell send some useful information to people yeah yeah okay good then we conclude that with some delay in the schedule yeah in terms of testing this now with current all this is more BTS and those more BSC that one would need to can how to say this do you have some tool to generate that or is there details on the wiki I'm not sure I think Daniel once wrote a small Python hack that generates these presidential and whatever alert messages and then it generates the hex thumb that you copy and paste into the VTY that was what we tested but it was broken for years in in Osmo BTS until it was fixed again at some point last year so depending on the software you're running it may not be working okay good then thanks