Project

General

Profile

Actions

Cell Broadcast » History » Revision 22

« Previous | Revision 22/24 (diff) | Next »
laforge, 07/21/2021 06:55 AM


Cell Broadcast

Normally, all user plane data in GSM/GPRS networks are sent in point-to-point channels from the network to the user. Those are called "dedicated" radio channels whcih exist between the network and one given phone/subscriber at a time.

Cell Broadcast is an exception to that rule. It permits user data (so-called SMS-CB data) to be broadcast by the network in a way that can be received by all phones in the coverage area of the given BTS simultaneously.

More high-level information can be found at https://en.wikipedia.org/wiki/Cell_Broadcast and the related specification is found at 3GPP TS 23.041 Technical realization of Cell Broadcast Service

NOTE: In 3G/UMTS networks, Cell Broadcast is called Service_Area_Broadcast and we have a dedicated wiki page for it.

Cell Broadcast Architecture

Network Diagram

This Network diagram shows the relevant elements in the GSM network, including their interconnection.

Ladder Diagram

This ladder diagram shows the propagation / flow of messages across the Cell Broadcast enabled network.

Use Cases

Cell Broadcast was used for various different use cases primarily in the 1990ies and early 2000s, including
  • advertisement of the GPS position of the cell tower you're currently camping on
  • advertisement of the calling codes of your current "home zone", i.e. a "lower cost short distance" call zone travelling with you as you roam around.
More recently, SMS-CB is seeing some uptake by various desaster warning systems, such as
  • CMAS (Commercial Mobile Alert System), later renamed to WEA (Wireless Emergency Alerts) in the US.
  • EU-Alert in the European union
  • Messer Ishi (Rocket Alert) in Israel
  • ETWS (Earthquake and Tsunami Warning System) in Japan
  • KPAS (Korean Public Alert System)

Osmocom Cell Broadcast support

  • OsmoBTS implements
    • the CBCH channel (both BASIC and EXTENDED) in the SDCCH/4 and SDCCH/8
    • the "SMS BROADCAST COMMAND" Message in RSL according to Section 8.5.8 of 3GPP TS 08.58
    • the "CBCH LOAD INDICATION" Message in RSL, which allows the BSC to perform flow control of CBCH messages
  • OsmoNITB and OsmoBSC implement a VTY command bts <0-255> smscb-command <1-4> HEXSTRING to send a given hex-formatted cell broadcast message to a specified BTS (this is more a hack for manual testing)
    • you (obviously) first need to enable a timeslot/channel combination on the BTS that actually includes a CBCH, i.e. ccch+sdcch4+cbch or sdcch8+cbch
  • OsmoBSC implements
    • the scheduling / allocation of CBCH resources in presence of possibly many SMSCB messages, taking into account their message size, repetition period, duration
    • the CBSP protocol according to 3GPP TS 48.049 for interaction with a CBC
    • CBCH flow control based on incoming CBCH LOAD INDICATION via RSL from BTSs
    • transmission of SMSCB using SMS BROADCAST COMMAND via RSL to BTSs
  • OsmoCBC implements
  • FIXME

How to test/use it

Using recent OsmoBSC and OsmoCBC

make sure your related BTS is configured to use a channel combination with CBCH

You have the choice of adding CBCH either on a a CCCH with SDCCH/4 or on a SDCCH/8. You will loose one of the SDCCHs in terms of capacity.

Example: For using a combined CCCH with SDCCH/4 and CBCH you can use the following example snippet as part of osmo-bsc.cfg:

network
 bts 0
  trx 0
   timeslot 0
    phys_chan_config CCCH+SDCCH4+CBCH
Setting up OsmoCBC

Please see Quick_SMSCB_HOWTO and the osmo-cbc user manual for further information.

DEPRECATED: Using the "manual hack" via BSC/NITB VTY command

Before osmo-cbc was implemented, we introduced a "manual hack" that allows the user of the BSC to send relatively raw RSL commands towards a BTS.

Please don't use this method anymore, and instead use the osmo-cbc based method described above

This is sufficient for manual transmission of cell-broadcast messages in a lab environment or in small networks. The functionality has been developed and used at the 31st annual CCC congress (31C3) to deliver spoofed Presidential Level Alert messages

You need to perform two steps:

make sure your related BTS is configured to use a channel combination with CBCH

For using a combined CCCH with SDCCH/4 and CBCH you can use the following example snippet as part of osmo-bsc.cfg:

network
 bts 0
  trx 0
   timeslot 0
    phys_chan_config CCCH+SDCCH4+CBCH
telnet to osmo-bsc at port 4242, and enter something like
enable
bts 0 smscb-command 1 001000320f1141660c344dd3cba09a0c

where "1" is the number of blocks required (each 22 bytes need one block)
and the hex-dump at the end is the encoded GSM 04.12 message to be broadcast.

Message Structure

  • Message has maximum 15 pages
  • Each page is 82 bytes of data, resulting in 93 characters in GSM 7-bit default alphabet
  • Messges are broadcast on logical channels (more like an address)
  • Subscribers can activate/deactivate selective addresses

Further Reading

EU-Alert

CMAS

ETWS

Cell Broadcast in 3G/UMTS

See Service_Area_Broadcast

Cell Broadcast in 4G/LTE

4G/LTE doesn't have a general-purpose Cell Broadcast mechanism (for any kind of broadcasts) anymore. Instead, it supports only broadcasting of emergency warning messages and calls this "PWS" (Public Warning System)

On the radio interface, there is no special downlink channel to send those PWS messages. Instead, they are transmitted as SIB (System Information Block) alongside all the other SIB messages containing cell identity, etc. on the BCCH.

SBc interface between CBC and MME

The interface is based on a ASN.1 based protocol called SBc-AP which is specified in 3GPP TS 29.168

The protocol operates over SCTP. Connections are initiated by the CBC to the MME, and the MME listens for SBcAP connections on SCTP port 29168.

S1 interface between MME and eNodeB

From the MME to the eNodeB, the normal S1 interface is used to transport PWS messages. The protocol is the normal S1AP, which is used for all other signaling between MME and eNodeB, too.

The related messsages on S1 are:
  • WRITE-REPLACE-WARNING-REQUEST (to create or update a PWS message that is to be broadcast)
  • KILL-REQUEST (to stop broadcasting a PWS message)

Our sister project open5gs implements encoding those messages in src/mme/s1ap-build.c

Files (3)
presidential_alert.png View presidential_alert.png 240 KB laforge, 05/29/2017 06:12 PM
osmocom-cbs.png View osmocom-cbs.png 23.3 KB laforge, 05/29/2017 06:37 PM
osmodevcon2019-cell_broadcast__2.png View osmodevcon2019-cell_broadcast__2.png 41.1 KB laforge, 09/13/2019 08:24 PM

Updated by laforge over 2 years ago · 22 revisions

Add picture from clipboard (Maximum size: 48.8 MB)