Lone Worker Connectivity in 2026: Specifying the Protection Chain

Lone worker protection has matured at the device level while resting on one unspoken assumption: that the alarm path is available when the worker needs it. Three developments have broken that premise: the 2G/3G sunset, operator-core failures, and a sharper duty-of-care expectation. This paper sets out why a device that shows full signal and reports “online” can still fail to deliver an alarm, across three distinct failure modes: an operator core that fails upstream of healthy radio, a VoLTE voice path that drops even when data succeeds, and a battery or polling regime that cannot sustain the device through a worker’s shift. It proposes the Protection Chain Assurance Model as a way to specify, monitor and evidence each layer, and translates the model into a procurement checklist for higher-risk deployments.

On your monitoring platform, the device is online: signal strong, last check-in minutes ago. The worker presses the panic button. Nothing reaches the alarm receiving centre.

That is not a hypothetical. It is what happens when an operator’s core network fails while the radio coverage stays healthy. The device is attached to a mast. The mast is working. But the path from that mast to the Alarm Receiving Centre (ARC) is broken somewhere upstream, and there is no second path for the device to fall back to.

For more than a decade, lone worker protection has been getting better at almost everything except this. Devices have become rugged. App interfaces have improved. Alarm receiving centres have tightened response times. Audit logging has matured. Every one of those improvements rests on a simpler assumption: that the alarm path is available when the worker needs it. In 2026, that assumption is the weakest part of the protection chain.

The 2G and 3G sunset. The UK’s 3G networks have now effectively been retired operator by operator: Vodafone and EE completed switch-off in early 2024, Three completed in late 2025, and, as CSL’s 2G/3G switch-off tracker records, no UK 3G networks remain available in 2026 following Virgin Media O2’s final shutdowns to the end of February. All UK mobile network operators have confirmed to Ofcom that 2G will be switched off by 2033 at the latest, but several operator dates arrive earlier and apply network-wide: EE has announced that 2G switch-off will begin from May 2029, and VodafoneThree has announced that Vodafone UK 2G will be switched off during 2030. As those programmes progress, 2G can no longer be treated as a dependable bearer for lone worker estates, particularly where roaming access is part of the service design. Roaming SIM estates face an additional, earlier milestone: O2 withdrew 2G/3G inbound roaming access from 1 October 2025, narrowing roaming-SIM 2G access to EE and Vodafone. For lone worker devices on roaming SIMs, the practical 2G planning horizon is the end of this decade. The 2033 outer ceiling would only extend that for a device running a single-operator SIM, and few higher-risk lone worker services would want to surrender multi-network resilience for another year or two of a sunsetting technology. Voice paths that lone worker devices have quietly relied on for years will therefore not be there by the end of this decade.

These dates set a migration calendar, however, not an emergency: for service providers with substantial 2G estates, the practical task is a planned, risk-tiered transition aligned with device refresh cycles, starting with the highest-risk deployments and the earliest roaming-SIM milestones, and not a wholesale rebuild.

Operator-core failure. Many multi-network lone worker SIMs in deployed estates can move between operators’ radio networks, but still route service through one home or MVNO core. Operator-core incidents do occur, and when they do, radio coverage can still appear healthy on the device while the alarm path is interrupted upstream. Multi-network access is not automatically multi-core resilience. This is the lone worker instance of a point CSL has made across critical connectivity: coverage is not the same as resilience. A device can sit inside excellent coverage and still have no working path to the ARC.

Liability and evidence. HSE guidance is clear that employers must manage health and safety risks before people work alone. The Suzy Lamplugh Trust, the UK’s pioneering personal-safety authority for lone working, takes the same view of lone worker technology: devices are one part of a wider programme of policies and practice, not a substitute for it. For higher-risk lone worker deployments, that makes alarm-path availability an evidence question, not just a device-status question. After an incident, the question is no longer “did the device have signal?” It is “can the provider evidence that the alarm path remained available?” The stakes are not only legal. A serious lone worker incident is operationally disruptive: it can halt work on a site, trigger an investigation and delay a programme, with contractual and reputational consequences alongside the human ones, particularly in sectors where lone and remote working is routine, such as construction, utilities and field engineering. A failed or delayed alarm makes both the outcome and the organisation’s position worse.

The word that matters is core. Multi-network and multi-core sound alike, and procurement language often treats them as the same thing, but they answer different questions: multi-network is about which radio a device can reach, while multi-core is about how many independent operator cores its traffic can securely route through. That difference is what decides whether an alarm survives an operator-core failure.

The architectural evolution of lone worker connectivity has happened in three steps:

• Single-network uses one operator and one core path. It is exposed to coverage gaps and operator-core faults, and does not provide autonomous network or core-path recovery on its own.
• Single-core multi-network uses multiple operators’ radios but still routes through one operator’s core. It is resilient to localised radio events, but not to operator-core failures.
• Dual-core uses two independent operator cores with autonomous switching between them, managed at the SIM or the device. It recovers from both radio events and operator-core failures, with bounded, logged recovery.

The middle category, the one most procurement language describes as “multi-network”, is where many lone worker estates sit today. It looks resilient. The dashboard shows multiple operator names. But if the home operator’s core fails, the SIM has no autonomous path to a different core.

A device may be able to see a mast but still be unable to pass the alarm through the operator’s core to the ARC. That is why the architecture question matters.

Multi-network already handles most of what goes wrong day to day. If a local mast fails, or coverage degrades across an area, a device on a multi-network SIM can move to another operator’s radio, automatically where the modem is set to do so. The switch is not instant, though: moving from one operator’s radio access network to another means detecting the loss, scanning and re-attaching, so there is a gap of seconds, sometimes longer, with no service. That switching is a device behaviour, not a property of the SIM alone, and how long the gap lasts depends on the modem’s network-selection setting and how quickly it reselects, which makes it something to specify and test rather than assume. Configured well, this is genuine resilience against the most common kind of failure, and it is why multi-network is the right baseline to build on.

A core failure is a different kind of event, and it sits upstream of the radio. The device can be on a strong signal, having already moved to whichever operator has the best coverage, and still have no working path, because the single operator core it routes through is the part that has failed. Here a multi-network single-core SIM has nothing left to try: the radio is healthy, so there is nothing to switch away from, and the break is beyond the point it can reach. The estate waits for the operator to restore the core, and recovery time is whatever the operator’s recovery time turns out to be.

In a dual-core estate the SIM or device detects that the active core is no longer carrying service and switches to the second operator core without manual intervention. That switch is not instant either, but it is a bounded, designed-for delay rather than an open-ended wait on the operator’s repair. The properties that matter for a safety system are the ones the architecture is designed around: detection within a bounded window, switchover within minutes, continuous ARC visibility through the event, and a record of the switch logged as it happens that can be produced afterwards. That last point is what turns recovery from an operational nicety into evidence, which is the difference the Protection Chain Assurance Model below is built to capture.

There is a second way a multi-network device can be online and still fail the worker, and it is specific to voice. For many higher-risk lone worker services, the ARC may need a live voice path, listen-in capability or two-way audio to understand what is happening. In the 2G and 3G era, voice was circuit-switched and much more uniformly available across roaming scenarios than VoLTE is today.

On 4G, voice is normally delivered as VoLTE (Voice over LTE): an IMS (IP Multimedia Subsystem) voice service carried over LTE packet data bearers rather than over a circuit-switched voice domain. VoLTE roaming has more moving parts than data roaming: it depends on IMS support, device configuration, and interoperability between the visited and home networks. A device can roam onto a visited network, pass its location data perfectly, show green on the dashboard, and still drop the voice call to the ARC, because the required VoLTE roaming support, device profile or IMS interworking between the home and visited networks is not in place. With 3G gone and 2G thinning, the circuit-switched fallback that used to rescue those calls is no longer a reliable safety net.

Because VoLTE depends on IMS support and roaming interoperability, data-roaming success is not proof that voice will connect. A “4G multi-network SIM” does not, on its own, guarantee that a voice path to the ARC will work across every visited network. The provider has to evidence, specify and support VoLTE interoperability across the networks the device is expected to roam onto.

CSL describes resilience as something built across layers: radio access, network choice, core-network independence, backhaul diversity, device behaviour and managed visibility. The Protection Chain Assurance Model is the same layered thinking expressed as the questions a lone worker incident actually asks. Five layers, each with a question the service provider must be able to answer after an incident, and each with its own evidence requirement.

The five layers of the protection chain, therefore, require that each one be a question and an evidence requirement, not just a system component. For example:

1. Did the worker activate the device, or did the device detect a fall, no-motion, or check-in miss?
2. Could the device attach to a usable network at the moment of activation?
3. Could traffic pass through the operator core, or was the data path interrupted?
4. Did the alarm receiving centre receive the alarm and act on it within the contracted response window?
5. Was the residual risk understood, documented and accepted by the employer before the incident?

BS 8484, the British Standard for lone worker device services, sets requirements that cover provider organisation, device, ARC (which is required to comply with EN 50518), and police-response processes that an accredited service should already meet. The framework above is offered as a complement to that standard, addressing the connectivity layers it does not currently reach: radio, core and the SIM behaviour that decide whether the alarm gets to the ARC in the first place.

In a core-resilient estate, all five questions can be answered from the service-review pack. In a single-network or single-core multi-network estate, at least one layer’s evidence is missing.

Lone worker devices wake the modem on a cadence to report location, send a heartbeat, or check in with the platform. That periodic wake is one of the largest controllable draws on the battery, and how costly it is depends on the state the modem sits in between wakes.

Two things are easily conflated here. The battery question is about how often the device wakes the modem to report or check in. It is not about the continuous connectivity monitoring that dual-core resilience uses to decide when to switch operator core; that runs at the SIM, modem or connectivity-management layer and is engineered to draw very low incremental power. The cadence that drives battery is the device’s reporting cadence: more frequent wakes spend more battery, less frequent wakes preserve it. How configurable that trade-off is depends on the device.

What makes the trade-off easy to get wrong is that the same cadence costs very different amounts depending on the modem’s power-state baseline between wakes. There are three regimes worth distinguishing:

• Registered idle / RRC_IDLE with idle-mode DRX. The modem remains registered and camped on the network, and monitors paging occasions using normal idle-mode DRX. A device-originated report still establishes an RRC (Radio Resource Control) connection, or resumes one where supported, before sending uplink data, but it avoids the higher-cost boot, cell search and registration / attach cycle. This is the lowest incremental-cost case for frequent reporting.
• Power-saving sleep / PSM or eDRX. In PSM (Power Saving Mode), the device remains registered but does not monitor paging, so it is effectively unreachable for mobile-terminated traffic until it wakes. In eDRX (extended DRX), the device remains reachable only on extended paging cycles, whose length depends on RAT, device category and network timer configuration. For device-originated reports, the modem pays a wake-up plus RRC connection and signalling cost; the exact delta versus registered idle depends on module, coverage, network timers and firmware, but it can be several times higher, which is workable at longer cadences and punishing at fast ones.
• Cold start / modem off. The modem is powered down between reports and must boot, scan, synchronise, select and camp on a cell, then register or attach to the network before reporting. This is the highest-cost regime, and aggressive one-minute polling should be treated as non-viable on a small daily-recharge pendant unless validated by device testing.

A one-minute cadence is practical only when the device remains in an efficient registered-idle state between reports. Once the modem has to wake from power-saving sleep, or cold-start, for each report, that cadence becomes unaffordable on a typical pendant battery, using 850 mAh as a representative reference point, with observed pendant-class devices often sitting in the 580 to 1350 mAh range. (The figures here are illustrative. Actual figures vary by module, bearer, radio conditions, GNSS use, network-search behaviour, firmware and network timer configuration; the point is the shape of the relationship, not a single number).

Polling cadence is not a setting in isolation; it is a setting against the device’s power-state architecture. A panic-alarm lone worker pendant on a daily recharge, with the modem held in registered idle between reports, can typically absorb a one-minute cadence. An unattended long-life IoT device on a primary cell, engineered to power-saving sleep between events to hit a multi-year endurance figure, cannot absorb that cadence. Not at one minute, and possibly not at five. The procurement answer is not the same number for both, and choosing the cadence without choosing it against the power-state baseline is how estates end up with surprised battery curves twelve months in.

None of these constraints is static. Battery energy density, modem efficiency, and 3GPP power-saving features all improve with each generation. Where those gains land, though, is a product-strategy choice rather than a law. In wearable safety devices, capacity and efficiency gains have often been spent on smaller form factors, lighter weight, and added capability (bodycam sensors, richer media, on-device processing) rather than on relaxing the cadence trade-off. In long-life unattended trackers built on LTE-M or NB-IoT with PSM and eDRX, the same underlying advances have more often extended endurance directly, with multi-year battery life now standard for low-frequency reporting. The trade-off persists either way. Each new generation may improve the absolute numbers, but more frequent reporting will still cost more battery than less.

This is also where the choice of bearer shows up, because cadence and bearer are really one decision. LTE-M earns much of its standby advantage through lower-power radio design and 3GPP power-saving features such as PSM and eDRX; the more often the application wakes the modem and transmits, the more of that advantage it spends. Many conventional 4G pendant designs can start from a worse idle-power baseline than LTE-M designs, which is why older 4G pendants often struggle past a day or two. 5G RedCap brings a reduced-capability NR option for devices that need more throughput than LTE-M, with 3GPP work in Release 17 (RedCap) and Release 18 (eRedCap) covering reduced UE complexity and extended-DRX enhancements. For a small pendant it should be chosen only where the extra capability, such as richer media or higher uplink throughput, is actually required. CSL has written separately on where 5G RedCap fits.

Availability and multi-network reach are not the same as capability, and for a safety device that gap matters. LTE-M coverage and cross-operator roaming support vary by operator and deployment, so a device chosen for LTE-M power efficiency may reach a narrower set of networks than a standard multi-network LTE SIM. 5G RedCap is still an emerging option for critical IoT, with real service depending on operator RedCap enablement, 5G core readiness, certified modules and a roaming model that is still maturing. A bearer chosen on power or capability alone can quietly give back the multi-network resilience this paper argues for, so the choice belongs against real availability and roaming maturity in the operators and territories where the estate operates, not against power and feature claims alone.

There is also a drain that has nothing to do with deliberate polling: network hunting. A device repeatedly searching across bands in poor coverage, or hunting for the 2G and 3G networks now being switched off, burns power continuously. It is one of the less obvious ways the sunset shows up in the field, a legacy or single-network device spending battery looking for networks that are no longer there. A well-configured multi-network roaming SIM can reduce much of that hunting cost by allowing the device to camp on a usable available network rather than repeatedly failing on a single preferred network. Here, unusually, resilience and battery life pull in the same direction.

Signal bars are not the only dashboard number that can look reassuring while masking the operational reality. Battery health is the other. A bodycam reporting a high state-of-health can still be unable to deliver its required ten-hour shift. Runtime reserve at the end of a real shift, after cycle aging, cold weather, livestream load, and polling overhead, is the operational test, not state-of-health percent. Both metrics, signal-bar status and battery health, are headline numbers that procurement has historically trusted as proxies for safety. Neither is.

The procurement questions follow from the model. Some are connectivity questions, some are power questions, and some are evidence questions. All of them sit at one of the five layers.

• What core architecture does the device use, single operator core or two independent cores, and how does that match the risk this deployment carries?
• What is the maximum detection latency for an operator-core failure on this service, and how is it bounded?
• Is failover autonomous at the SIM or device, or does it depend on a platform first noticing the failure?
• What polling cadence does the service run, and what is its per-event cost given the modem’s power-state baseline on this device: registered idle, power-saving sleep (PSM or eDRX), or cold start between reports?
• What is the runtime reserve at end-of-shift after twenty-four months of expected duty cycle, in the conditions of actual deployment?
• Are switching events logged at the time they happen, and can the provider produce the log on request?
• Can the provider distinguish radio failure from core-path failure in incident reporting?
• Can the provider evidence and support VoLTE voice interoperability across every network the SIM will roam onto, so the call to the ARC connects even when the device is on a visited network?
• Is the lone worker service accredited to BS 8484, including ARC compliance with EN 50518 and a documented police-response process?

These are not architecture-of-the-day questions. They are the new baseline for higher-risk lone worker deployments: security, healthcare community visits, utilities field engineering, isolated working, and violence-risk roles. These are settings where alarm delivery delay has material consequences.

A growing number of lone worker devices are now marketed on satellite coverage, and the timing is real: direct-to-device satellite has moved from trial toward early commercial service in the UK and US over the last year. CSL covers that shift in detail in Satellite is moving into the cellular roadmap. For lone worker protection, satellite is becoming a genuine resilience layer, but it is a layer to add to a resilient cellular baseline, not a wider-coverage replacement for one.

The claim usually made is wider coverage than cellular, and for a genuinely remote, open-sky worker that can be true. But coverage breadth is not the safety question, and three limits matter. Today’s device-level satellite services depend on a clear view of the sky and are limited indoors, which is where a great many lone workers actually are: basements, stairwells, vehicles, care homes and urban areas, the places multi-network cellular still reaches. Most satellite paths today carry messages and data rather than the two-way voice an alarm receiving centre needs, which is the separate failure mode described earlier. And a device routed through a single satellite operator, or a single operator core, is still single-path at the layer that matters: wider reach is not the same as continuity, in the same way that multi-network is not multi-core.

The word satellite also blurs two different things. Satellite positioning, GPS or more correctly GNSS, is receive-only: it tells a device where it is but carries nothing back. Satellite or cellular communication is the bearer that actually delivers the alarm. A device described as having “satellite GPS” may have no satellite communication path at all, which means it can know precisely where an incident is and still have no way to report it. Both matter for a safety case, but they are not interchangeable: position tells the response where to go, and the bearer is what carries the alarm to the people who can respond.

None of this argues against satellite. It argues for treating it the way the protection chain treats every layer: as something to specify and evidence, not assume. For the right estate, an open-sky remote workforce, satellite earns its place as an added path on top of multi-network or dual-core cellular, and it is best designed in at that level rather than bolted on as a substitute. For most lone worker estates it is a planning conversation worth having early, not a procurement decision worth rushing.

Many lone worker service providers reading this already operate multi-network SIMs, many at scale. That is a sound and deliberate position, not a stopgap: a multi-network SIM is not locked to one operator’s radio footprint, so as coverage improves the service environment improves with it, without device-side change. The radio layer of the protection chain is largely handled, and for a great many devices multi-network remains exactly the right answer.

The gaps sit above the radio layer, and they matter most at the higher-risk end of an estate. A multi-network single-core SIM still routes through one operator core, so an operator-core failure interrupts the alarm path until the operator restores service. VoLTE interoperability across the networks the SIM roams onto is not guaranteed by multi-network access alone. And each device’s reporting cadence and bearer have to be matched to its battery and power-state baseline. None of these require an emergency rebuild, and none of them mean re-platforming an estate that is working. They are questions to weigh device by device, by risk tier, at the next device or contract refresh, alongside the 2G/3G sunset dates that already sit on your migration calendar. For bodycams and other high-load devices, the battery is its own question. A high state-of-health reading does not guarantee that the device will last a full shift under real load and it is therefore important to consider and specify against the runtime likely to be remaining at end of shift instead.

The right answer is rarely a single product. It depends on device class and risk level. A multi-network IoT SIM is the right fit for many monitoring roles, while higher-criticality voice and alarm devices justify dual-core resilience, such as CSL’s rSIM®, with two independent operator cores and autonomous switching at the SIM. The cadence and bearer are then matched to the device’s battery. In practice many mature estates run multi-network broadly and introduce dual-core where a core failure would carry the most serious consequences, often piloting it on that tier first to build the evidence before any wider decision.

For service providers still running legacy 2G or single-network estates, the same conversation includes managing the transition itself: which devices and sites move first, what device refresh cycles allow, and how to phase the change against the operator milestones above without disrupting what is working. Defining that mix is a design exercise, and the trade-offs in this paper, the core, the voice path and the battery, are exactly the ones a connectivity partner should help resolve rather than leave to the buyer.

Above the SIM sits the layer that lone worker service providers actually rely on: the managed service. Continuous network monitoring, the switching logic itself, switch logging and evidence, ARC integration, and reporting against the protection chain are what turn a resilient architecture into a service that can be specified, monitored, recovered and evidenced. This is where CSL positions itself: supplying the SIMs, from multi-network IoT SIMs through to rSIM dual-core, helping define the right solution for each device class, and running the managed service layer above it.

Lone worker protection is moving from device assurance to protection-chain assurance.

The device side has matured. The next phase is for the connectivity and power layers to catch up: to be specified, monitored, recovered and evidenced like any other safety control. That is what the procurement conversation needs to be about in 2026-2030, and it is a conversation a connectivity partner should be leading with you.

• What Ofcom’s Spring 2026 Connected Nations Update Means for Critical Connectivity. Where coverage stands, and why coverage alone is not resilience.
• Satellite is moving into the cellular roadmap: an emerging layer for critical IoT. Where satellite and Direct-to-Device fit in a layered resilience architecture.
• Five Trends Shaping Critical IoT Connectivity in 2026. Legacy network sunsets, multi-network resilience, eSIM and 5G evolution.
• IoT SIM Cards. Multi-network roaming SIMs for monitoring and tracking lone worker devices.
• rSIM®. Dual-core resilient SIM with two independent operator cores and autonomous switching, for higher-criticality voice and alarm devices.

Terms used throughout this paper, grouped by topic.

Standards and bodies

• 3GPP Third Generation Partnership Project, the standards body that publishes the specifications for cellular technologies including LTE and 5G.
• ARC (Alarm Receiving Centre). The monitoring centre that receives alarms from lone worker devices and decides on response, including, where authorised, requesting police action via a URN.
• BS 8484. British Standard for lone worker device services. Sets requirements covering provider, device, ARC and police-response processes. References EN 50518 as the ARC standard.
• EN 50518. European Standard for monitoring and alarm receiving centres.
• GSMA IR.92. GSMA profile specifying how networks and devices should implement VoLTE interoperably.
• URN (Unique Reference Number). Code issued to BS 8484-accredited lone worker services that allows the ARC to request police response directly.

Cellular bearers and services

• IMS (IP Multimedia Subsystem). The operator network elements that carry voice and multimedia over packet bearers; what handles a VoLTE call.
• LTE-M (LTE Cat-M1). A 3GPP LTE variant designed for low-power IoT devices, with native support for 3GPP power-saving features.
• Operator core. The signalling, data and voice network elements that sit upstream of the radio access network.
• RAN (Radio Access Network). The radio side of an operator’s network (cell sites and antennas) through which a device reaches the operator core.
• RAT (Radio Access Technology). A specific cellular technology family, such as GSM, UMTS, LTE, LTE-M, NB-IoT, or 5G NR. A device’s supported RAT’s determines which network types it can attach to.
• RedCap / eRedCap. Reduced Capability NR (3GPP Release 17) and Enhanced RedCap (Release 18). A 5G option for IoT devices that need more capability than LTE-M but less than full 5G NR.
• VoLTE (Voice over LTE). Voice carried as IMS over LTE packet data bearers, rather than over a circuit-switched voice domain.

SIM architectures

• Multi-network SIM. A SIM that can attach to more than one operator’s radio access network. A single-core multi-network SIM reaches multiple RANs but routes through one operator core. A dual-core SIM routes through two independent operator cores.
• Native UK SIM (single-operator SIM). A SIM whose home network is a UK operator.
• Roaming SIM. A SIM whose home network is different from the network it is attaching to; in the UK lone worker context, typically a SIM whose home network is outside the UK, attaching to UK operators via roaming agreements.

Modem power states

• Cold start. The modem booting from off, including cell search, synchronisation, cell selection, camping and registration or attach to the network.
• DRX (Discontinuous Reception). A power-saving mechanism that has the modem monitor the network only at scheduled intervals.
• eDRX (extended DRX). 3GPP Release 13 feature that lengthens the paging interval. Reduces power consumption at the cost of reachability latency for mobile-terminated traffic.
• PSM (Power Saving Mode). 3GPP Release 12 feature in which the modem remains registered but stops monitoring paging until a configured timer expires or the device triggers an event.
• RRC The Radio Resource Control idle state. The modem is registered, camped on a cell, and monitors paging using idle-mode DRX. The typical baseline between device-originated reports for an efficiently configured pendant.

Device and battery

• GNSS (Global Navigation Satellite System). The family of satellite positioning systems, including GPS, Galileo, GLONASS and BeiDou.
• State of health (SoH). The proportion of a battery’s original capacity that remains. A common battery-aging metric, though not on its own sufficient to predict whether a device can deliver a full shift.

Whether you run multi-network SIMs today or are planning your next device generation, CSL can help define the right connectivity across the protection chain, from multi-network IoT SIMs through to rSIM dual-core, and run the managed service layer above it: monitoring, switching, evidence and reporting.

Contact CSL: https://www.csl-group.com/contact-us/

Lone Worker Connectivity in 2026: Specifying the Protection Chain. CSL Group white paper, May 2026.

About CSL: The leading connectivity provider for critical alarm and safety applications, including life-critical connectivity, alarm signalling, lone worker, fire, security, and assisted living.

• Ofcom, 3G and 2G switch-off: our expectations of mobile providers.
• HSE, Lone working: protecting those working alone.
• Suzy Lamplugh Trust, Personal safety at work.
• CSL, 2G / 3G Switch-Off.

• 3GPP, Release 12 (PSM, Power Saving Mode).
• 3GPP, Release 13 (eDRX, extended Discontinuous Reception, for LTE-M and NB-IoT).
• 3GPP, Release 17 (5G NR Reduced Capability, RedCap), and Release 18 (eRedCap).
• GSMA, 92 IMS Profile for Voice and SMS (VoLTE).