A history of Emergency Alerts in the UK. Part 2: Trials begin & an opportunity seized.
Following on from Part 1 we’re now in late 2018 and I’ve been the Service Owner for the Environment Agency’s Flood Warning & Information Service for a couple of years. Fujitsu, the provider of the flood warning system contacted us with an invitation to visit EE’s test lab for a demonstration of Cell Broadcast (CB) on 29 January. Fujitsu’s Peter Davies and Sean Walsh through the Fujitsu-EE partnership, rented cell broadcast software which had been added to the EE test network in their lab at Borehamwood. The invitation was also extended to Nigel Brown from CCS and we were able to experience first hand the impact of receiving an Emergency Alert via CB.
Fujitsu used the development flood warning system platform and an existing flood warning area was extended to include a mobile mast within the target area and therefore enabling the warning to trigger a broadcast. Being on the test network this enabled handsets sitting in a faraday cage to receive messages whilst preventing a broadcast leaking out and alerting handsets in the local area.
The Common Alerting Protocol (CAP) was adopted as the method of exchange with a relevant translation for the Cell Broadcast Centre (CBC) software. We’d already been developing a CAP XML output from the flood warning system in order to integrate with Google Public Alerts which launched in Summer 2019.
Following this initial demonstration we formalised the next steps and extended the partnership to include The University of Hull. We planned to incrementally continue testing and learning leading to a closed trial using the test network in a location outside a lab subsequently followed by a public trial. I was interested in developing our understanding of the technology together with the user experience and needs from an alerting capability.
Whilst plans for a closed trial at the University of Hull developed, it became apparent thanks to EE’s investigations that trying to send cell broadcast messages on the test network but in a public environment would cause complications. Using supplied handsets that were listening for a particular test network may have a negative impact on public users. Specifically, there was concern that phones may latch on to this test network and as these connections were not expected, their SIMs could be refused/blocked. Clearly we couldn’t progress with this private trial as intended so we switched to running a workshop using simulated cell broadcast messages.
Dr Silvia Grant, User Research lead at DEFRA, designed and delivered the workshop and research, the latter in conjunction with Dr Kate Smith and Dr Rob Thomas from the University of Hull. The workshop comprised a technology simulation with 96 users. Immediate responses to receiving emergency alerts were captured as well as thoughts, feelings, emotions and what actions they would take. We also explored message types and tolerances of urgency, certainty and severity The results of the workshop were published.
Findings from the workshop suggested that users value combined severity and urgency over certainty, the message text should be action-focused and easy to understand in a high-stress scenario. There was solid support for an emergency alerting platform to be implemented.
In addition to the workshop we sought public opinions on emergency alerting through an online survey which attracted over 1700 responses, over three times that received by the survey supporting the Mobile Alert Trials. This survey captured some helpful insights into user behaviour and why CB would be effective. Whilst people generally sleep with phones in their room, they are unlikely to view messages until the morning.
The survey also highlighted the challenges of alert fatigue. With a whole host of notifications received daily, SMS messages have reduced in number and their value particularly when often associated with scams and unsolicited promotional material. This has impacted the influence they have to engage and initiate a response as a result of an Emergency Alert.
Political interest in emergency alerting continued through 2019, notably in May with a discussion in the House of Lords tabled by Lord Harris. Lack of progress was again highlighted although the Environment Agency Cell Broadcast trials were referenced together with acknowledgement that the technology landscape had changed since the original Mobile Alerting Trials when LBSMS was the favoured approach.
Covid-19 exposes emergency alerting need
The global Coronavirus pandemic resulted in a significant test of emergency planning and response capabilities. As the country prepared itself for a national lockdown on the 25 March 2020, with no national alerting capability in place, the UK Government turned to the mobile network operators to send out SMS messages to all their customers.
The Privacy and Electronic Communications Regulations previously updated by the Cabinet Office CCS team supported this although many in the mobile industry knew the limitations of such an approach would be a negative public response on privacy grounds and the need to batch messages to avoid network congestion.
Sending out millions of SMS messages in one hit is just not possible. Batching reduces the load on the network but the trade off is speed. It took more than 48 hours for all the SMS messages to be sent. The Cabinet Office had previously highlighted the potential for SMS based alerting systems to be compromised with delays and this was now validated.
This scenario didn’t go unnoticed by the press and industry experts. Ben Wood tweeted and was quoted in a BBC news article highlighting the delays.
Seizing the opportunity
With the UK Government now acutely aware of the limitations of SMS for such a purpose and no national emergency alerting capability in place, Dr Nigel Brown made a pitch to stakeholders involved with Covid-19 response. At this point, the UK Government was also aware of how CB technology was being used in other countries as part of their Covid-19 response, notably South Korea.
This triggered a request from the Prime Minister for a paper which was titled: Implementing a Cell Broadcast Capability UK for Mobile Phones. The paper included reference to the Environment Agency’s interest in Cell Broadcasting and a need to put in place a project team of 10–15 people to deliver the capability. Costs and timescales were estimated together with a recommendation for DCMS to take forward the implementation together with the Mobile Network Operators.
With experience of flood warning capabilities, prior involvement with the Mobile Alerting Trial and more recently the Cell Broadcast Trials, Dr Nigel Brown encouraged DCMS to engage the EA as part of the project. Many thanks to Kevin Knappett from DCMS for the invitation to join the core team and to Environment Agency for supporting that request.
The Emergency Alert Project Begins
My memories of the first few months of the national project are rather hazy. We were attempting to put a service in place within 6–12 months when most countries take several years over their implementation. The main driver was Covid-19 and as the situation started to deteriorate this put more pressure on the team to get the service in place. Broadly speaking the work split into three stages;
- Planning
- Design & build
- Testing & awareness
I’ll describe some of the key aspects of each.
Planning
A small core team formed initially, mainly comprised of DCMS, Cabinet Office (CCS), National Cyber Security Centre (NCSC) and the Environment Agency/DEFRA. The three initial goals were to complete a business case to secure HMT approval together with a costed plan, to produce an agreed set of requirements for the system and to put commercial contracts in place.
The business case produced by DCMS was comprehensive shortlisting both LBSMS and CB options but ultimately a Cell Broadcast based service was deemed the most appropriate providing substantial cost-benefit. Huge thanks go to Priya Sharma and team for their efforts producing the business case.
A set of requirements for the mobile operators took time to work through. These comprised both non-functional needs such as resolution times, capacity and availability of the service as well as the functional aspects including the format of data exchange, broadcast success rates, ability for audit, confirmation of adopted channels. The team at this point had expanded to include support from Azenby and Fujitsu who worked with the mobile network operators to agree the technical requirements.
One of the early decisions was also to confirm which networks the service would be deployed onto. 4G/5G was chosen to provide maximum reach as early as possible. This decision hasn’t entirely ruled out 2G/3G deployments in due course but some of the factors at play include:
- 3G networks are starting to get switched off. Vodafone confirmed 3G in the UK will be switched off in 2023.
- Phones that only rely on 2G are less likely to have the capability to receive emergency alerts via cell broadcasts.
- Cell Broadcasts by their nature enable those who temporarily lose 4G/5G signal to receive the messages when they return to a 4G/5G service as it isn’t a ‘one shot’.
- Understanding the reach of an operational 4G/5G service before committing to further deployments onto 2G/3G felt like a pragmatic move. Further developments can then be based on evidence rather than assumptions.
During the first 3–4 months, we had the opportunity to attend multi-agency meetings in response to Covid including Leicester which entered a full lockdown at the end of June 2020. We also engaged with Regional Directors of Public Health and emergency planners to help the team gain insights into how Covid-19 communications were being managed locally and user needs for alerting. Understanding the journey of message creation and authorisation at both a local and national level was essential.
Design & Build
One of the first key design decisions was the type of Cell Broadcast Centre (CBC) deployment. As mentioned previously, the CBC is the software that matches the location of interest to the mobile network mast infrastructure to determine which masts need to broadcast the alert, for what duration and the repetition rate. There were three options:
- Centralised CBC — quickest option, centrally controlled, requires external access to Mobile core networks (example: Romania).
- Separate CBC’s but provided by one supplier. 4 x CBCs one for each UK network, integration with the CBE (message sending engine) requires configuration but is repeatable (example: New Zealand).
- Separate & diverse CBCs (different suppliers). 4 x CBCs one for each UK network, multiple integrations with the CBE (message sending engine), less consistency, more control for the Mobile Network (example: USA)
The UK has adopted the third option which enabled HMG to put the onus on the mobile networks to assess the CBC options available in the market and to make their selection. Three of the networks chose the One2Many CBC (EE, O2 & Three UK) with Vodafone selecting Nokia.
The other key design decision was who should be responsible for the CBE, the central messaging platform. As described previously this is the system in which the authority sending the message defines the ‘what’ and the ‘where’. It was felt that the ownership and operation should lie with Government. This was supported by the Mobile Networks as they wish to be purely transporters of the message with no involvement with message creation.
A number of options were considered with regards to the CBE development covering both build/buy routes. At this point I was keen for their to be wider GDS involvement for a number of reasons; firstly with technology projects it is easy for user needs to be missed. Secondly, I thought GDS involvement would enable us to work more closely to the service standard which in turn would reinforce building a service that was user centred. Thirdly, I was keen GDS to have a hand in the development of the central messaging engine and to ensure this was sustainable, provide flexibility and at a lower cost. Finally, I hoped with greater GDS involvement we could make things open both in the adoption of open standards, which we did achieve through the adoption of the Common Alerting Protocol, but also be more transparent about the work we were delivering with the wider world.
It’s fair to say I lobbied pretty hard for GDS to be involved and huge thanks to Pete Herlihy the then Product Manager for GDS Notify for answering the call. I suspect it took a fair amount of influencing for Pete to wholesale divert from the team’s planned backlog to focus on Emergency Alerts. Pete didn’t just join alone, the team extended to include Chris Marshall (User Researcher), Chris Hill-Scott (Designer), Karl Chillmaid (Content Designer), Leo Hemsted (Developer), Pea Tyczynska (Developer), Richard Baker (Site Reliability Engineer) and Tom Byers (Frontend Developer). The Notify team quickly got to work researching, prototyping, testing and subsequently building the central messaging engine (CBE). Turns out my tweet from the Flood Digital Design Team Twitter account in March 2020 was an accurate prediction!
Two other notable pieces of work the team progressed in this period was the confirmation of the adopted channels and the creation of a National Protocol.
Selecting the Channels
I’ve written about channels previously in this blog with test channels covered in some detail so I’ll not repeat that here. Messages on test channels are not something most people will encounter as Apple do not, as a general rule, allow access to test channels and their phones account for around 50% of the market. With most other phones, users have to opt into them or access developer options to receive test alerts.
The highest level channel is 4370 which is more commonly known as the ‘Presidential Alert’ but for obvious reasons this has been renamed for the UK as Government Alert. There are however a considerable number of handsets (around 10%) which will have the default setting and will display Presidential Alerting should this channel be used.
This is the only channel which users cannot opt out of. As a result, there are no options to do so on users handsets. In this video from the 25 May 2021, I show the override in action.
4371–4372 is the range for Extreme Alerts with 4373–4378 representing the range of Severe Alerts. A video in this tweet shows an emergency alert being received on a Severe channel. Users can opt out of both Extreme and Severe. On Apple devices these are the only two options that appear, whereas on Android devices the user is generally presented with a greater number of options.
The channel number is influenced by the combination of Severity, Certainty and Urgency as defined in the Common Alerting Protocol. The following levels are excluded: Severity levels of moderate, minor or unknown, certainty of possible, unlikely and unknown and Urgencies of future, past and unknown. This is to ensure Alerts are only issued when it is appropriate to do so.
Test channels were also included in the UK spec but the following were excluded:
4392: known more commonly as Amber Alerts (America’s Missing Broadcast Emergency Response)
4396: Public Safety Alerts
4400: Channel for Device-Based Geo-Fencing (DBGF)
There was, and no doubt still is, interest from the National Crime Agency in using Amber Alerts, with the potential to extend this to include vulnerable people. However in the UK Amber Alerts has the potential to be confused with amber weather warnings and without detail on how and who would send these Alerts, the national team elected to exclude these from the initial channel specification. However, this doesn’t prevent them from being added in at a future date should there be interest in this type of messaging.
The channel for Public Safety Alerts was dropped as these have generally been used for lower-level incidents. In the USA there have examples where the frequency and type of incidents this channel has been used for have resulted in critical responses from the public.
Channels for DBGF were also not included in the first agreed specification set. You can read more on this here. In summary, this uses the phone’s positioning capability to check whether it is located within the specific targeted area. The result of this is much more accurate targeting of messages, within 0.1mile. DBGF is active in the USA but requires newer handsets. This should be a candidate for future inclusion within the UK’s channel specification.
Handset Specification Agreed
Once the channel set had been confirmed, there was a need to confirm this at the handset side. In effect so the phones are listening for the right signals. Over the air updates were required to active the UK spec, effect label changes and remove unused channels where appropriate. This work involved close cooperation between the Mobile Network Operators, DCMS and the handset manufacturers namely Apple, Samsung and Google.
The manufacturers provided their testing requirements, e.g. a particular number and types of tests needed to be completed in and out of the lab to confirm successful deployment. With Android based devices, these are all on different update cycles. The newest devices receive monthly updates, through to older devices which are on a quarterly or annual update cycle. After 6–7 years devices fall out of support and these would not be updated such as the Samsung S6.
Peter Davies from Fujitsu worked on the handset specifications and produced forecasts of the reach by handset type which were useful in gauging what levels we might expect based on the launch date of the service.
For Apple devices we needed to integrate with their iOS update cycle. Deadlines for testing were set and we raced to meet these timescales. Apple didn’t openly shared timescales for their iOS updates but we were aware this had a significant impact on the public testing and a national launch. To proceed with a national welcome message without Apple devices being enabled would have ruled out approx 50% of the population with smart phones.
The National Protocol
Any national alerting capability requires a policy defining who should use the service, how and when it should be used. Dr Nigel Brown from CCS led on this document. I know Nigel was keen to secure early agreement on the thresholds for use and to protect the service from mis-use. CCS had previously tested the threshold for using a CB capability with Cabinet Office Ministers in 2019. In Nigel’s own words…
“If we’re not careful before you know it, we’ll have warnings for dog poo on Keswick High Street”.
The National Protocol outlines the key stakeholders, the process for sending a message, incidents types considered in and out of scope, the functions and stakeholders involved in delivering, using and maintaining the capability.
Given the driver to put a service in place was Covid-19, the protocol outlined the potential initial users for COVID-19 response and the post COVID-19 response user community plus provision for extending this community beyond core Category 1 responders.
Towards the end of 2020, the draft protocol included the following post-Covid-19 users;
- Environment Agency / Scottish Environment Protection Agency / Natural Resources Wales (flood Warnings)
- Police (who take primacy in response to major incidents). Fire & Rescue service also listed as a potential candidate.
- The Department for Business, Energy and Industrial Strategy (BEIS) for Civil Nuclear incidents.
- Health & Safety Executive (HSE) & Owners and operators of COMAH sites
- Met Office — severe weather warnings
The protocol outlines what the service should not be used for e.g.
- Content of a political nature
- abusive, defamatory or fraudulent
- Unrelated to the relevant event or threat
- Could harm, or bring into disrepute, the CB capability
It also includes considerations for commissioning an Emergency Alert (starting and ending a broadcast), a checklist and draft message templates that were based on previous domestic and international research and recommendations.
“There are six key elements to a good and actionable emergency alert: Issuing authority of the warning (e.g., agency), guidance (‘what to do’) messages, the hazard, potential impacts, locations affected, the time (that the warning message was issued, as well as the expected time of impact) and where to seek further information.”
Further insights as to the importance of these elements were captured through Emergency Alerts research undertaken by GDS. In Part 3 I’ll cover the research and testing in further detail as the team makes the final push to get the service operational.
