Public Warning Systems in Mobile Networks

Introduction

Cell broadcast (CB) is a way to deliver a text message to large numbers of handsets over the cellular network. Its main use today is the delivery of Public Warning System (PWS) messages, also called CMAS, ETWS, Presidential Alerts, EU-Alerts, or other names in different parts of the world.

The Legba Lab Kit supports PWS messages through standard signaling from a core network, or through file-based configuration and command line controls (not requiring a core network). This makes the Lab Kit an easy and inexpensive way to test with PWS messages, for handset testing, for testing emergency message content and distribution systems, for education and training, or for security research.

History of Cell Broadcast

The implementation of PWS reflects its history, so it is useful to know how this technology evolved.

A Market Flop, Retooled for Public Safety

Cell broadcast was first developed as part of the GSM standard in the late 1990s, originally intended as a way to provide information services, like weather, sports scores, stock prices, and traffic reports, back before you could get the Internet on your phone. The idea was that people would pay a little extra to subscribe to these news feeds to get real-time information on their mobiles (remember again, this is pre-internet). Those services never really took off in most markets, but one of the features built into the technology was the ability to deliver emergency alert messages to the general public, like the example below, from Romania.

A Growing Service, but with Many Names

As people move away from broadcast television and radio, the cellular network is becoming more important as a means to distribution urgent warnings to the public, and so PWS-over-CB is becoming more important and getting deployed more widely around the world. This type of service is known by different names in different parts of the world (CMAS, ETWS, Presidential Alert, EU-Alert, etc.) , and depending on the nature of the alert (AMBER Alert, Presidential Alert, etc). This Wikipedia page gives a sampling of some of them. However, the underlying technology is globally standardized and works the same way everywhere, once the message gets into the cellular network.

How Cell Broadcast Works

Cell broadcast messages may look like SMS text messages to most users, and the service is sometimes called “broadcast SMS”, “SMS-CB”, or some other name involving SMS, however, CB has little to do with normal SMS text messages. Cell broadcast uses an entirely different set of procedures in the core network and and entirely different set of channels in the radio network, and it is a true broadcast service, with all handsets receiving and using the same message as it is sent out. This means that CB is delivered quickly over large areas and remains reliable even when the network is too overloaded to carry normal SMS. The broadcast protocol also requires less battery power, since is it receive-only at the handset.

Cell Broadcast in the Core Network

In the core network, CB messages originate at the Cell Broadcast Entity (CBE). The message contains the message content that the subscribers will see, along with other information about the message:

• A message type code to identify different alert types.
• A “serial number” that includes a message version number and instructions on how the message is presented to to the user. (See here for more details.)
• A repetition period and lifetime for the message.
• A geographic area where the message is to be presented.

The message is then delivered to the Cell Broadcast Center (CBC).

At the CBC, the message content is split into pages of up to 82 bytes each, or up to 93 characters using the default GSM 7-bit alphabet. A message can span up to 15 pages, giving a maximum message size of 1395 characters for most Latin/Greek alphabets, or 615 characters for other alphabets using UCS-2 encoding. This page-size requirement is a holdover from GSM, which is explained in more detail in that section.

After splitting into pages, the messages are delivered to the RAN (Radio Access Network) elements covering the geographic areas indicated by the CBE. The element types involved and the interfaces and protocols used depend on the RAN type, but every variation of the protocol supports these major operations:

• Write-Replace: Sent from the core network to the RAN. Start sending a new message or replace an existing message with a new version.
• Kill: Sent from the core network to the RAN Stop sending a message.
• Restart Indication: Sent from a RAN element to the core network. This message indicates that a RAN element has just joined or re-joined the network and needs an updated list of active messages.
• Failure Indication: Sent from a RAN element to the core network. This message indicates that a message sent by the core network could not be scheduled for transmission in the RAN.

Cell Broadcast in the GSM Radio Network

The CBC connects to the BSSs in the GSM ran over “the CBC-BSS interface”. (Unlike other interfaces in the GSM network, like “A”, “Abis”, “Um”, etc., this one does not have a proper name.) The CBC transfers messages to the BSS in 88-byte pages, each page with 82 bytes of content and 6 bytes of header information.

The BSS breaks each 88-byte page into 4 22-byte segments and delivers them to the BTS over the Abis interface, along with an extra 22-byte segment for control and scheduling information.

The CB message segments are then sent out over the Cell Broadcast Channel (CBCH), a PHY channel created by reusing one of the Standalone Dedicate Control Channels (SDCCH). The CBCH has a radio frame size of 22 bytes (surprise!) and a data rate of about 800 bits/second, requiring just under one second for each page of a CB message.

Cell Broadcast in the LTE Radio Network

In LTE, the CBC connects not directly to the RAN but to the Mobility Management Entity (MME) in the EPC, on the SBc interface. The MME then distributes the messages to the individual eNodeBs over the S1 interface, according to the geographic area specified in the message.

The message is delivered from the eNodeB to the handsets over the LTE-Uu radio interface as part of the system information. Most CB message types are carried in System Information Block 12 (SIB12), except for ETWS which is carried in SIB10 (notification information) and SIB11 (actual message content). There is a more detailed explanation of ETWS here, and keep reading for examples of SIB CB content.

Although the upper layers give a maximum message size of 15 88-byte pages, the LTE PHY limits the size of a SIB to 2216 bits (277 bytes), including all headers, which may limit the practical maximum CB message content size to 2 pages (184 characters) in some LTE networks.

Cell Broadcast with Legba Lab Kits

The Legba Lab Kit can be used to generate CB messages, including PWS, CMSA, etc., in GSM or in LTE operating modes.

GSM Example – Command Line

The YateBTS GSM CB implementation (SMS-CB) does not support the CBC-BSS interface, but you can control SMS-CB from the telnet command line interface.

First, you must enable SMS-CB in the PHY by adding this parameter to /etc/yate/sdr/bts-custom.conf:

[custom]
SMSCB=true

Then restart the BTS and access the telnet interface.

Once in the telnet interface, the following commands are available:

• control ybts cbadd – Adds a CB message to the active list in the BTS, like the Write-Replace operation. The message content is given as an encoded hex string.
• control ybts cbdel – Removes a CB message from the active list, like the Kill operation.
• mbts cblist – Lists the currently active CM message in the BTS.

For example:

yate-sdr@ybts-officess> control ybts cbadd id=4373 code=82 gs=1 dcs=2 data=C3643308A296E77410941D76D3412D5092DA0AB2CB723AA805A296E77450BB3C9F87CF65500B04CBBD60B4970C26838162395DCC066A819AF37392A8A3CD6E31D0F84D2EEB7032D079AE8B81C8E3B94E0602
Control 'ybts' OK
yate-sdr@ybts-officess> mbts cblist 
Current SMSCB queue:
1 items
id=4373 gs=1 code=82 update=0 pages=1
yate-sdr@ybts-officess> control ybts cbdel id=4373 code=82
Control 'ybts' OK
yate-sdr@ybts-officess> mbts cblist
Current SMSCB queue:
0 items

LTE Example – S1 Signaling

The Legba eNodeB supports CB-related signaling on the S1 interface. If your EPC supports some kind of CB test feature, you can use it to trigger CB from the S1 interface. In this example, we are using a YateBTS Mini-Core and controlling CB messages on the eNodeB from the telnet command line interface:

yate-ucn@core> help cbs 
 cbs send msg_id=MessageIdentifier seq=SerialNumber period=RepetitionPeriod repetitions=NumberofBroadcastRequest [param=value ...] 
 cbs stop msg_id=MessageIdentifier seq=SerialNumber [param=value...] 
 cbs params 
Control the CBS operation 

yate-ucn@core> cbs send concurrent_warning=true dcs=01 text=ThisIsAlsoTest-AndStillItGoesXX1211!! repetitions=60 period=10 seq=7008 msg_id=1112 indication_req=true warning_area.cells=00151/5ef0000,00196/2345678,00166/0000001 
Operation: WriteReplaceWarning sent 

yate-ucn@core> cbs stop seq=7008 msg_id=1112
Operation: StopWarning sent

For ETWS, the S1 message is the same, with message ID 0x1100 – 0x1107 indicating ETWS. In the ETWS case, the RAN will send SIB10 and, if message content is present, SIB11.

LTE Example – Command Line

In the Legba eNodeB, cell broadcast can also be controlled from the telnet command line using the “enb pws-test” feature. This feature pulls S1 message content from files and then injects them into higher layers of the eNodeB as if the messages had been received on S1.

To use this feature, you must have S1AP message content in XML files in /etc/yate/sdr. The Lab Kit comes with example files, but you can also provide your own if you choose:

• cmasWrite.xml – This is the message used for Write-Replace testing.
• cmasKill.xml – This is the message used for Kill testing.

Here is the sample cmasWrite.xml:

   1112
   3019
   10
   10
   01
   01537a9acda696e7f4b4fbdc68341a8d46a3d168341a8d46a3d168341a8d46a3d168341a8d46a3d168341a8d46a3d168341a8d46a3d168341a8d46a3d168341a8d46a3d168341a8d46a3d168341a8d46a3d1005

And here is the sample cmasKill.xml:

   1112
   3019

The commands are simply these:

• enb pws-test WriteReplace – Simulate receiving a WriteReplace message on S1.
• enb pws-test Kill – Simulate receiving a Kill message on S1.
• enb pws-test Restart – Send the Restart indication on S1 to every connected MME.
• enb pws-test Failure – Send the Failure indication on S1 to every connected MME.

Once the file content is in place, the use is very simple:

yate-sdr@ybts-officelk> enb pws-test WriteReplace  
yate-sdr@ybts-officelk> enb pws-test Kill  
yate-sdr@ybts-officelk> enb pws-test Restart  
yate-sdr@ybts-officelk> enb pws-test Failure

Even though the file is called “cmasWrite.xml”, this same procedure can be used to send ETWS by using a ETWS message ID (0x1100 – 0x1107).

LTE Example – Configuration Files

With the Legba Lab Kit, any SIB content can be generated directly with XML files in the /etc/yate/sdr directory, including SIBs associated with CMAS and ETWS. Any SIB XML file found in this directory will override and replace the SIB that would be normally generated by the eNodeB. (This feature has many applications beyond CB, to be covered in other posts, but here we will focus only on the use of XML files for CB.)

For example, placing this content in the file /etc/yate/sdr/enb-sib12_v920.xml will cause the eNodeB to send a CMAS message when it is restarted:

1112
3019
lastSegment
0
0154747A0E4ACF416110BD3CA783DE66D0B0199CBA4054747A0E4ACF416F373B0F0A83E8E539DD0532A6D9ECB21C34A787E5F439085D96977D2E97CBE572B95C2E97CBE572B95C2E97CBE572B95C2E97CBE50238
01

To start sending CMAS with SIB12, just place this file in /etc/yate/sdr/enb-sib12_v920.xml and restart the eNodeB.

Similarly, with this approach, you can also send ETWS with SIB10 and SIB11:

1101
4001
0180
1101
4001
lastSegment
0
0154747A0E4ACF416110BD3CA783DE6650917A9DBA4054747A0E4ACF416F373B0F0A83E8E539DD05D2A514D46A3D168341A8D46A3D168341A8D46A3D168341A8D46A3D168341A8D46A3D168341A8D46A3D16002A
01

Place these XML message in /etc/yate/sdr/enb-sib10.xml and /etc/yate/enb-sib11.xml and restart the eNodeB to start sending ETWS.

Conclusion

In this post, we have given an introduction to the technology used for emergency alert messages and described how to reproduce emergency alert signaling on the bench with Legba LabKits, through multiple interfaces.

For more information on the Legba LabKit, please see that product page, send an email to sales@leg.ba or fill out the contact form below.