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:
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.
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:
<!-- This is an example CMAS write/replace message for PWS/CMAS testing. --> <!-- Use it with the "enb pws-test Write" command. --> <request code="WriteReplaceWarning"> <MessageIdentifier> <MessageIdentifier>1112</MessageIdentifier> </MessageIdentifier> <SerialNumber> <SerialNumber>3019</SerialNumber> </SerialNumber> <RepetitionPeriod> <RepetitionPeriod>10</RepetitionPeriod> </RepetitionPeriod> <NumberofBroadcastRequest> <NumberofBroadcastRequest>10</NumberofBroadcastRequest> </NumberofBroadcastRequest> <DataCodingScheme> <DataCodingScheme>01</DataCodingScheme> </DataCodingScheme> <WarningMessageContents> <WarningMessageContents>01537a9acda696e7f4b4fbdc68341a8d46a3d168341a8d46a3d168341a8d46a3d168341a8d46a3d168341a8d46a3d168341a8d46a3d168341a8d46a3d168341a8d46a3d168341a8d46a3d168341a8d46a3d10052</WarningMessageContents> </WarningMessageContents> </request>
And here is the sample cmasKill.xml:
<!-- This is an example CMAS kill message for PWS/CMAS testing. --> <!-- Use it with the "enb pws-test Kill" command. --> <request code="Kill"> <MessageIdentifier> <MessageIdentifier>1112</MessageIdentifier> </MessageIdentifier> <SerialNumber> <SerialNumber>3019</SerialNumber> </SerialNumber> </request>
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:
<sib12_v920> <!-- These bit strings and byte strings are all given in hexadecimal. --> <!-- See https://www.vodafone.ro/personal/magazin-online/utile/ro-alert/index.htm for info on message IDs in RO/EU --> <!-- EU-Alert: decimal 4370, hex 0x1112 (this is also "Presidential Alert" in the US) --> <messageIdentifier_r9>1112</messageIdentifier_r9> <!-- Serial Number - cell-wide scope, immediate display, with alert and pop-up --> <!-- See http://www.sharetechnote.com/html/Handbook_LTE_PWS_SerialNumber.html for information on serial number fields. --> <serialNumber_r9>3019</serialNumber_r9> <!-- This message has a single segment. --> <warningMessageSegmentType_r9>lastSegment</warningMessageSegmentType_r9> <warningMessageSegmentNumber_r9>0</warningMessageSegmentNumber_r9> <!-- This is a 64-character message "This is a test of CMAS. This is only a test. Filler starts here>" --> <!-- The fields are defined in 3GPP 23.041: 1 byte page numbering info, 82 bytes message content (padded), 1 byte message length (in bytes) --> <warningMessageSegment_r9>0154747A0E4ACF416110BD3CA783DE66D0B0199CBA4054747A0E4ACF416F373B0F0A83E8E539DD0532A6D9ECB21C34A787E5F439085D96977D2E97CBE572B95C2E97CBE572B95C2E97CBE572B95C2E97CBE50238</warningMessageSegment_r9> <!-- GSM 7-bit coding scheme, English language --> <dataCodingScheme_r9>01</dataCodingScheme_r9> </sib12_v920>
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:
<sib10> <!-- These bit strings and byte strings are all given in hexadecimal. --> <!-- earthquake and tsunami --> <messageIdentifier>1101</messageIdentifier> <serialNumber>4001</serialNumber> <!-- earthquake, alert user, pop-up window --> <warningType>0180</warningType> </sib10> <sib11> <!-- These bit strings and byte strings are all given in hexadecimal. --> <!-- earthquake and tsunami --> <messageIdentifier>1101</messageIdentifier> <serialNumber>4001</serialNumber> <warningMessageSegmentType>lastSegment</warningMessageSegmentType> <warningMessageSegmentNumber>0</warningMessageSegmentNumber> <!-- This is a 42-character message "This is a test of ETWS. This is only a test. :)" --> <!-- The fields are defined in 3GPP 23.041: 1 byte page number, 82 bytes message content (padded), 2 bytes mesage length (in bytes) --> <warningMessageSegment>0154747A0E4ACF416110BD3CA783DE6650917A9DBA4054747A0E4ACF416F373B0F0A83E8E539DD05D2A514D46A3D168341A8D46A3D168341A8D46A3D168341A8D46A3D168341A8D46A3D168341A8D46A3D16002A</warningMessageSegment> <!-- GSM 7-bit coding scheme, English language--> <dataCodingScheme>01</dataCodingScheme> </sib11>
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.
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.
- GSM 03.38, character set definitions
- GSM 03.41, defines CB in the GSM core network
- 3GPP 23.041, GSM 03.41 updated for later generations
- GSM 04.12, defines CB in the GSM RAN
- 3GPP 36.331, defines the LTE Radio Resource Control (RRC) protocol, including CB on the radio interface
- 3GPP 36.413, defines the LTE S1 interface, including CB