Cellbroadcast support
This MR adds initial cellbroadcast (3GPP TS 23.041) which is commonly used in many countries to alert users about threats for health and safety.
Much of this is based on logs provided by @newton688 in #253. For the
moment we support parsing the cell broadcast messages (CBMs) out of
the unsolicited event stream for AT based modems supporting GSM7 and
UCS2 (see src/tests/test-cbm-part.c
). Apart from the data coding
scheme, the actual message content and the page parameter
(indicating the current part and number of parts of the message)
the cbm consists of
- 2 Byte serial number. However this isn't a plain sequence number but contains the geographical scope, the message code (which contains two bits that indicate whether whether this is an emergency alert and if the message should be a popup) and the update number (if a CBM supersedes/updates a previous CBM).
- 2 Byte message identifier. This is what is commonly called channel (indicating the type of alert (e.g. presidential level alert, amber alert).
From the above we assemble the CBM at /org/freedesktop/ModemManager1/CBM/<mumber>
for consumers:
$ busctl --system introspect org.freedesktop.ModemManager1 /org/freedesktop/ModemManager1/CBM/0
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
…
org.freedesktop.ModemManager1.Cbm interface - - -
.Channel property u 4371 emits-change
.MessageCode property u 106 emits-change
.State property u 2 emits-change
.Text property s "NL-Alert 04-12-2023 12:00: TESTBERICHT… emits-change
.Update property u 0 emits-change
(we currently leave of the geographical scope but I intend to add this as a follow up). We expose the CBMs on a separate interface than SMS since they serve a different purpose and in the future we want to enable the Cell Broadcast interface in cases where Messaging isn't enabled (i.e. when there's no SIM).
The API for list
ing, delete
ing CBMs and the signals when CBMs get added
, deleted
looks like:
$ busctl --system introspect org.freedesktop.ModemManager1 /org/freedesktop/ModemManager1/Modem/0 org.freedesktop.ModemManager1.Modem.CellBroadcast
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
.Delete method o - -
.List method - ao -
.SetChannels method as - -
.CellBroadcasts property ao 0 emits-change
.Channels property as 0 emits-change
.Added signal o - -
.Deleted signal o - -
We also have API to set the list of channels to receive CBMs for.
The MMBroadbandModem
interface is currently very simple:
iface->check_support = modem_cell_broadcast_check_support;
iface->check_support_finish = modem_cell_broadcast_check_support_finish;
iface->setup_unsolicited_events = modem_cell_broadcast_setup_unsolicited_events;
iface->setup_unsolicited_events_finish = modem_cell_broadcast_setup_cleanup_unsolicited_events_finish;
iface->cleanup_unsolicited_events = modem_cell_broadcast_cleanup_unsolicited_events;
iface->cleanup_unsolicited_events_finish = modem_cell_broadcast_setup_cleanup_unsolicited_events_finish;
iface->set_channels = modem_cell_broadcast_set_channels;
iface->set_channels_finish = modem_cell_broadcast_set_channels_finish;
iface->create_cbm = modem_cell_broadcast_create_cbm;
as currently MM enables/disables the reception of the unsolicited CBMs
via the messaging interface's CNMI
sequence already. We might want
to disentangle that at some point but I hope that's sufficient for the
initial implementation (same seems to be true for QMI as we see the messages
in the QMI stream too already).
The MR adds support to libmm-glib
for getting, deleting CBMs, same for mmcli
. There's
a mmcbmmonitor
in tests to listen for CBMs on the command line.
I kept the MR as small as possible so we can land the initial API as soon as possible (maybe for 1.24?). This would allow us to advance the modem manager bits and other user space bits (CBM storage, display of CBMs to the user) in parallel to expanding support on the MM side (e.g. QMI). I've kept the channel setting API in a separate MR so that we could drop that in an initial version too (and basically just use th defaults the modem has set until then).
Follow ups would be:
-
QMI support (I have skeleton for this but would be nice to land the interfaces first so there' won't be any mass renames) -
Expose the GEO scope (would just expose MM_CBM_GEO_SCOPE_*
? -
Add channel
(aka message identifier) setting / getting using (a(uu)
in the DBus interface). Until then we rely on what the modem has configured by default (which usually means "empty list").
Fixes #253