19 Sigfox Deployment
Release Plan, Site Evidence, Provisioning, Pilot Rollout, Operations Handoff, and Recheck Triggers
19.1 Start With the Story
A Sigfox deployment is proved by messages that arrive from real locations, not by a module that works on a desk. Coverage, callback delivery, payload encoding, antenna placement, and operations evidence all have to line up.
Start simple: validate one field path from device transmission to backend record before scaling the install.
Phoebe’s Why
An antenna does not create power; it redistributes a fixed amount of it in space, concentrating more into some directions by giving up others entirely. That trade is safe for a fixed device whose orientation is chosen once at install time – it is a liability for an asset tracker, which this chapter’s worked examples call out by name. A tracker tumbles in a truck bed, a shipping container, or a pallet, so its orientation relative to the nearest base station is unknown and constantly changing. Spending gain on directivity means betting that the tracker stays pointed the right way; a near-isotropic antenna gives up that peak gain but never falls into a deep pattern null either. The gain budget belongs on the network side – fixed, engineered, sectorized base-station antennas – not on a device that cannot promise which way it is facing.
The Derivation
Isotropic power density at distance \(d\):
\[S_{iso} = \frac{P_t}{4\pi d^2}\]
Gain redirects the same transmit power into a narrower solid angle \(\Omega\):
\[G = \frac{4\pi}{\Omega}, \qquad \mathrm{EIRP(dBm)} = P_t(\mathrm{dBm}) + G(\mathrm{dBi})\]
Kraus’s estimate ties gain to the two half-power beamwidths \(\theta_E, \theta_H\) in degrees:
\[G \approx \frac{41253}{\theta_E\,\theta_H}\]
Worked Numbers: The Tracker’s Gain Budget
This chapter names no specific module, so take catalog-typical Sigfox EU RC1 figures: \(P_t = 14\) dBm conducted (25 mW, a common ETSI SRD860 sub-band limit) and a near-isotropic monopole, \(G \approx 2.15\) dBi, giving \(\mathrm{EIRP} = 14+2.15 = 16.2\) dBm.
- Swap in an 8 dBi directional panel and hold that same 16.2 dBm EIRP cap: conducted power must drop to \(16.2-8 = 8.15\) dBm, a \(5.85\) dB cut, i.e. \(10^{-5.85/10} = 0.260\times\) the transmit current – to about a quarter
- Beamwidth cost from Kraus at \(G_{lin}=10^{0.8}=6.31\): \(\theta_E\theta_H \approx 41253/6.31 = 6{,}540\ \text{deg}^2\); for a symmetric lobe, \(\theta \approx \sqrt{6{,}540} = 80.9\) degrees, so the tracker must stay within about 40.4 degrees of boresight to keep any of that gain
- A tracker rotating in transit crosses 40 degrees in seconds, not hours – once outside the lobe it does not just lose the 8 dBi, real antenna patterns have nulls, so it can read weaker than the near-isotropic 2.15 dBi baseline it started with
That is the physical case for the near-isotropic default this chapter’s antenna-placement evidence field is really asking about: a moving asset cannot promise the aim a directional antenna requires, so the safer trade is to keep the device’s own gain low and let the base station’s fixed, sectorized antennas carry the range budget instead.
19.2 What This Chapter Covers
- How to convert a Sigfox-style managed-service design into deployment gates.
- How to collect site evidence that represents the actual device, enclosure, antenna, and mounting position.
- How to verify provisioning, decoding, callbacks, monitoring, and exception ownership before field scale.
- How to roll out in waves without hiding early failures in aggregate statistics.
- How to prepare operations handoff and recheck triggers for long-lived devices.
19.3 Learning Objectives
By the end of this chapter, you will be able to:
- Build a deployment release plan for a Sigfox-style managed-service project.
- Explain why service evidence must come from representative installation conditions.
- Prepare provisioning, payload decoding, callback, and monitoring checks before device rollout.
- Define rollout waves, acceptance rules, rollback actions, and exception records.
- Identify deployment assumptions that should reopen the technology decision.
19.4 Deployment Release Path
Treat deployment as a sequence of evidence gates. A project should not move forward because one gate is strong while another is missing.
Deployment release questions:
- Requirements: what telemetry, alarm, latency, downlink, and lifetime promises must the deployment support?
- Site list: which installation environments are represented, and which are still unknown?
- Payload and cadence: what does each message mean, and what happens during alarms, retries, commissioning, and maintenance?
- Service evidence: what records prove messages arrive from the intended conditions?
- Provisioning: how are device identity, activation, decoder, callback, and application ownership verified?
- Pilot rollout: what wave size, monitoring window, stop rule, and rollback action control early scale?
- Operations handoff: who owns missing messages, callback failures, device swaps, service changes, and rechecks?
19.5 Device Management And Operations
Device management starts before installation. The release packet should make identity, provisioning, decoder configuration, callback ownership, monitoring, device replacement, and retirement visible enough that operations can maintain the estate without rediscovering the pilot assumptions.
Minimum records:
- Device identifier, firmware, payload version, hardware build, antenna, enclosure, and site assignment.
- Provisioning proof for decoder, callback, application owner, and monitoring owner.
- Swap and retirement process for failed devices, moved devices, or changed customer ownership.
- Incident route for missing messages, callback failures, stale dashboards, and service changes.
19.6 Payload Cadence And Use-Case Fit
Deployment approval should prove that the payload and cadence match the use case. A compact telemetry product can fit Sigfox well; a product that needs rich transfer, frequent commands, or low-latency control should reopen the technology decision.
Use the release review to check:
- Payload versions are documented and can represent normal, alarm, commissioning, and recovery states.
- Cadence limits are written for normal operation, exceptional operation, retries, and maintenance.
- Downlink dependence is rare, non-urgent, and backed by local fallback behavior.
- Monitoring distinguishes no event, delayed event, rejected callback, and application failure.
19.7 Worked Deployment Examples
For an asset tracker, release evidence should show representative mounting positions, expected movement states, message freshness windows, and owner response when updates stop. For a meter or environmental sensor, the evidence should show payload meaning, site materials, enclosure effects, callback acceptance, and exception handling before scale.
The worked-example habit is to state the promise first, then attach proof:
- Promise: what the user believes the device is reporting.
- Evidence: which records prove device, service, backend, and application behavior.
- Limit: which sites, cadences, alarms, or downlink assumptions remain constrained.
- Owner: who acts when the evidence changes after release.
19.8 No-Hardware Lab Practice
When hardware is not available, run the deployment review as a table-top lab. Build a synthetic payload contract, site list, provisioning checklist, callback test, monitoring rule, and stop rule. The lab should not claim field readiness; it should prove that the team can ask for the right evidence before devices are installed.
Practice prompts:
- Classify a proposed payload as acceptable, version-risky, or too large for the product promise.
- Decide which site classes need representative evidence before rollout.
- Write a stop rule for a pilot wave with missing messages or callback failures.
- Identify the owner for decoder drift, service change, device swap, and stale dashboard incidents.
19.9 Site Evidence Before Scale
Deployment planning starts with a site list, but release approval depends on records from representative devices in representative conditions. The evidence should explain where the device was placed, how it was mounted, which firmware and payload were used, which backend route handled the message, and how failures were classified.
Evidence to capture:
- Site type, mounting position, enclosure, antenna, orientation, and nearby materials.
- Device firmware, payload version, retry behavior, and reporting cadence.
- Message records that include normal reports, alarms, commissioning events, and service interruptions.
- Callback results, decoder output, application acceptance, and missing-message handling.
- Exceptions and mitigations, such as relocation, antenna change, cadence change, alternative connectivity, or no release for that site class.
19.10 Provisioning and Backend Dry Run
Provisioning is not paperwork after the radio works. It is part of the deployment path. Each device must have an identity record, activation state, payload decoder, callback route, application mapping, monitoring rule, and support owner before it is installed where recovery is expensive.
Record the device
Track device identity, hardware revision, firmware version, payload version, installation site, and owner in one release record.
Prove first message
Do not ship a device until the backend can accept, decode, route, and display a known commissioning message.
Test failure modes
Verify retry, dead-letter, duplicate handling, late messages, and application outage behavior before field installation.
Assign an owner
Every missing-device alert, decoder error, callback failure, and service incident needs a named triage path.
Provisioning dry-run checks:
- A device can be identified from a message without relying on a field technician note.
- Payload decoder output matches the payload contract and application units.
- Callback delivery is observed by the application, not only by the connectivity backend.
- Duplicate, late, missing, malformed, and rejected messages have clear handling rules.
- Device replacement and site reassignment do not lose ownership or history.
19.11 Rollout Waves and Stop Rules
Deploy in waves so problems are visible while they are still cheap to fix. Each wave should have an entry rule, an observation window, a stop rule, an exception log, and a decision record.
Good rollout records answer:
- Which site classes, device builds, firmware versions, and payload versions are included in each wave?
- What observation window is long enough to include normal reports, alarms, maintenance actions, and service interruptions?
- What symptoms stop the next wave: missing reports, callback failures, device activation defects, decoder mismatch, installer errors, or customer rejection?
- What is the rollback action: hold shipment, swap antenna, change mounting, revise payload, fix callback, move site class to another technology, or withdraw release?
- Who can approve an exception, and when must the exception be reviewed again?
19.12 Operations Handoff
The deployment is not complete when the last device is installed. It is complete when operations can detect trouble, classify it, act on it, and decide when the technology fit must be reviewed again.
Operations ownership should include:
- Monitoring rules for silent devices, message bursts, decoder errors, callback failures, late data, and application rejection.
- A triage path that separates radio/service symptoms from firmware, provisioning, callback, device damage, site movement, and application defects.
- Device swap and reassignment procedures that preserve identity, site history, and payload version records.
- Service-owner change review: what changes in service terms, backend routing, support process, or regional availability reopen the deployment decision?
- A continuity plan for site classes that fail evidence requirements or become dependent on exceptions.
19.13 Deployment Anti-Patterns to Reject
Approving from a planning view
A planning view helps choose pilot locations. It does not prove the released device works inside its enclosure at the intended site.
Hiding site-class failures
A strong overall delivery summary can still hide one failing site class. Review site classes separately.
Leaving callbacks for operations
If the application cannot receive, decode, and alert on data during the dry run, the deployment is not ready.
Ignoring recheck triggers
Managed-service deployments need a written trigger for service, payload, cadence, site, ownership, or product changes.
19.14 Release Readiness Packet
A useful release packet is short enough to maintain and specific enough to audit.
Include:
- Requirements summary and rejected assumptions.
- Payload contract, decoder version, and cadence budget.
- Representative site evidence with exceptions and mitigations.
- Provisioning dry-run record and callback acceptance evidence.
- Rollout wave plan, stop rules, and rollback actions.
- Operations handoff with named owners and escalation path.
- Recheck triggers and technology-decision reopen rules.
19.15 Deployment Evidence Chain
A Sigfox-style deployment is ready to scale only when the team can prove messages arrive from representative devices, in representative places, with the final payload, cadence, provisioning path, callback route, and operations owner.
The deployment risk is not only radio coverage. It is the chain from installed antenna to managed service, payload decoder, backend callback, monitoring, incident response, device replacement, and future service changes.
Do not scale from a single successful message
One message proves a narrow path at one moment. A release record proves the deployment can survive variation, faults, operations handoff, and service changes.
The practical test is whether a reviewer can replay the decision from records rather than trust memory. If the pilot succeeds, the reviewer should see why the tested sites represent the rollout. If it fails, the reviewer should see whether the fault was radio loss, payload drift, decoder error, callback rejection, stale monitoring, or unclear ownership. That classification decides whether the next action is antenna change, payload change, backend repair, smaller rollout wave, or technology reassessment.
This evidence-first stance is especially important for managed LPWAN because the project does not directly control every network element. The team can still control what it approves: final device conditions, bounded traffic promises, callback acceptance, observability, stop rules, and recheck triggers.
19.16 Sigfox Release Record
The release record should make every deployment assumption testable. It should show which sites were represented, which devices were provisioned, which payloads were decoded, and which owner responds when a message is late or missing.
Start with the promise made to the user, then work backward. If the promise is a daily meter reading, the record needs freshness evidence and a missing-reading response. If the promise is an alarm, it needs worst-case latency, callback failure handling, and a safe local behavior while the device is silent.
Complete the dry run
Provision a pilot device, decode the payload, confirm callbacks, and prove alert visibility before the device is mounted.
Log exceptions
Record late messages, missing messages, duplicate events, decoder errors, callback failures, and device swaps as named exceptions.
Schedule rechecks
Reopen the decision when firmware, payload cadence, mounting, service region, backend endpoint, or operator conditions change.
Keep the record small enough to maintain, but strict enough to stop bad scale. A useful release record normally includes the device list, site classes, payload contract, representative message samples, decoder version, callback test result, monitoring rule, exception log, wave decision, rollback action, and recheck trigger.
Do not let averages hide deployment risk. A high delivery statistic may still fail a site class, enclosure type, backend endpoint, or alarm path that matters. Separate “what passed” from “where this evidence applies” and “what remains outside the approved boundary.”
19.17 Managed Service Ownership Review
Managed LPWAN can simplify network ownership, but it does not remove responsibility for the deployment. The project still owns device behavior, payload discipline, provisioning correctness, callback resilience, monitoring, and continuity planning.
The useful system spans several asynchronous boundaries. A device may transmit, several base stations may hear it, the managed service may deduplicate it, the cloud may create a callback, the application may accept or reject that callback, and monitoring may decide whether silence is normal or exceptional. A deployment gate must test the whole chain, not just the radio hop.
Those boundaries fail in different ways. Radio trouble looks like weak or absent reception. Payload trouble looks like fields that decode but mean the wrong thing. Callback trouble looks like rejected, duplicated, late, or unactioned records. Monitoring trouble looks like a device that goes quiet without anyone noticing. Ownership trouble looks like an alert that is visible but not assigned to someone with authority to act.
This is why a release gate should include negative tests as well as happy-path messages. Deliberately check what happens when the endpoint rejects a callback, the decoder sees an unknown payload version, the commissioning message arrives late, or the monitor sees silence after installation. The result should be a named exception and response path, not only a failed test note.
Cadence discipline
Payload size, alarm behavior, retry policy, clock drift, battery state, and commissioning traffic all affect service fit.
Callback resilience
Decoder changes, backend downtime, authentication expiry, and monitoring gaps can break the value chain even when radio messages arrive.
Exit readiness
A long-lived deployment needs a recheck and exit plan for service coverage, operator changes, device replacement, and data migration.
Downlink limits make ownership explicit. A design that depends on frequent remote commands, acknowledgements, or live correction will create operational pressure that the service was not meant to absorb. When command traffic is rare and device-initiated, the release record should still show who can request a downlink, when the device listens, what happens if the command is missed, and how the application proves the resulting state.
Provisioning changes are another hidden failure mode. A decoder update can change units, an authentication token can expire, a callback endpoint can reject a schema, or a replacement device can be installed with the wrong identity. The radio evidence may look healthy while the application record is wrong.
19.18 Summary
Sigfox deployment quality depends on evidence, ownership, and stop rules:
- Prove service from representative installation conditions, not only planning views or lab messages.
- Verify provisioning, decoding, callbacks, monitoring, and application acceptance before field installation.
- Roll out in waves with stop rules, exception logs, and rollback actions.
- Hand the deployment to operations with clear owners for alerts, incidents, device changes, and service changes.
- Record recheck triggers so long-lived devices are not locked into assumptions that no longer hold.
19.19 What’s Next
- Device Management And Operations: device identity, provisioning, monitoring, and lifecycle ownership.
- Scenario Mistakes And Assessment: evidence-first review questions for managed-service deployments.
- Payload Cadence And Use-Case Fit: payload discipline, service evidence, downlink restraint, and release readiness.
19.20 Key Takeaway
Sigfox deployment planning must check operator coverage, device certification, antenna placement, payload schedule, backend callbacks, message limits, and continuity risk.