Organizations buying two-way radio in Kenya are often surprised to learn that the equipment is the easy part. You cannot lawfully switch a professional radio system on until the Communications Authority of Kenya has licensed it, and that requirement catches out more first-time buyers than any technical issue.

This article sets out what the Authority requires, what it means for a project timeline, and where the avoidable mistakes are.

The legal position

Under section 36 of the Kenya Information and Communications Act, all radio communication equipment in Kenya must be owned and operated under a licence issued by the Communications Authority, and that licence must be kept in force at all times through regular payment of the prescribed fee.

Two things in that sentence do the work. First, it covers ownership and operation, not just transmission; possession of unlicensed equipment is not a safe position. Second, the licence is a continuing obligation, not a one-off permission. A lapsed licence is an unlicensed system.

Which category applies to you

The Authority administers radio communication licensing across several categories. The ones most organizations encounter are:

• Private Radio Networks, covering HF and VHF private networks and private paging, the category most commercial, security, conservancy and industrial users fall into
• Fixed, cellular mobile and public paging services, for operators providing services to third parties
• Aircraft station and maritime (ship) station licences, for aviation and marine operations
• Amateur radio and citizen band licences, which are not appropriate for organizational use however convenient they may look
• Wireless access systems in the shared 2.4 GHz and 5 GHz bands, which operate on a shared, non-protected basis under the Authority's guidelines

That last point is worth dwelling on. Shared non-protected means exactly what it says: you may use the band, and you have no protection from interference by others entitled to use it. It is not a substitute for assigned spectrum in an operation where communication has to work.

The mistake that costs the most

It is not choosing the wrong category. It is treating licensing as something that happens after procurement.

Frequencies are assigned by the Authority. You do not select them, and you cannot assume that the frequencies a system was configured for elsewhere will be available to you here. If equipment is bought and programmed before assignment, there is a real chance of having to reprogramme it, and a smaller but expensive chance of having bought equipment that cannot operate on what you are assigned at all.

Equipment bought abroad is the common version of this. It may be perfectly good, and it may still be unusable, either because it cannot be programmed to the assigned frequencies or because it has not been type approved for use in Kenya. The Authority operates equipment type approval, and approval is a prerequisite for putting a system into service.

What the Authority expects of an applicant

The general conditions across the Authority's licensing categories are consistent and unsurprising. An applicant is normally expected to be an entity registered in Kenya, to have a registered office and permanent premises here, and to provide evidence of tax compliance and a PIN certificate. Applications are made on the Authority's forms, in English, and addressed to the Authority.

None of that is difficult for an established organization. It is difficult for a project that assumed the supplier would handle everything and discovers in week three that the paperwork requires the customer's own corporate documents.

Ongoing obligations

A licence is not the end of it.

• Fees are payable on a recurring basis and the licence must be kept in force
• The Authority monitors and inspects spectrum use to confirm it matches the licence terms
• Frequency assignments are tied to the licensee and to the stated use; changing either is a matter for the Authority, not an internal decision
• Adding sites, raising power or extending coverage may require variation of the assignment

For a security company or conservancy running a radio fleet, the practical implication is that somebody has to own this, a named person who knows when the licence renews and what the fleet is authorised to do.

How to build it into a project properly

The sequence that works is straightforward and the one that fails is equally predictable.

Who does what

Licensing tends to stall when nobody has said out loud which side is doing which part. The division that works is roughly this.

The licence is held by the organization, not by the supplier. That matters at the end of a relationship: if you change suppliers, the assignment stays with you, provided the paperwork was done in your name from the start.

How long it takes

Timelines vary with the category and with how complete the application is when it arrives. What is predictable is the cause of delay: incomplete applications, corporate documents that have to be chased internally, and equipment ordered before the assignment is known.

Plan on the licensing running in parallel with procurement and installation rather than after them, and start it at design stage. A project that treats licensing as the final step before go-live will discover that it is not a step it controls.

What it costs

Fees vary by service type and by the spectrum involved, and the Authority publishes current schedules. We are deliberately not quoting figures here, because a fee schedule quoted in an article outlives its accuracy and a wrong number in a business case is worse than no number. Ask, and we will confirm the current position for your specific case before you commit to a system size.

A note on why this is worth doing properly

Licence cost is a genuine input into system choice. It is one of the reasons broadband push-to-talk over cellular has taken share from conventional radio in some Kenyan operations; it runs on a licensed operator's network rather than on spectrum you licence yourself, which removes both the assignment process and the recurring frequency fee. That is not automatically the better answer. But it is a real comparison, and it should be made with the licensing cost visible rather than discovered afterwards.

Discuss a Requirement

Three digital radio standards come up in almost every professional radio conversation, and they are not competitors in the way the comparison implies. They were designed for different problems by different constituencies, and most organizations have a right answer that becomes obvious once the question is framed properly.

The short version

DMR

Digital Mobile Radio is an open ETSI standard, and the practical consequence of that is a broad and competitive equipment market. It uses two time slots within a 12.5 kHz channel, which effectively doubles capacity compared with an equivalent analogue channel, a real benefit when spectrum is assigned rather than chosen.

It comes in tiers. The distinction that matters commercially is between conventional operation, where users pick a channel, and Tier III trunking, where the system assigns channels automatically. Trunking becomes worthwhile when you have enough users that channel contention is a daily irritation rather than an occasional one.

DMR is where most commercial operations should start, and where most of them should finish. It is not a compromise standard; it is the standard that fits the requirement.

TETRA

Terrestrial Trunked Radio is also an ETSI standard, but it was designed from the outset for public safety and large-scale trunked operation. It offers very fast call setup, robust group calling, strong encryption, direct mode operation between handsets when infrastructure is unavailable, and the kind of resilience expected where a network failure is a public safety event.

It is correspondingly more expensive: in infrastructure, in terminals and in the expertise required to operate it. TETRA makes sense when an organization is running its own network at scale and the operational consequences of failure justify the investment. It rarely makes sense for a single site or a few dozen users, whatever the feature comparison suggests.

P25

Project 25 is a TIA standard developed for public safety in North America, with interoperability between agencies as a founding objective. Where P25 is mandated, it is mandated for good reasons and the question does not arise.

Outside that context the calculus is different. The installed base and the supply chain are concentrated in North America, which has implications for equipment availability, local support and spares in East Africa. If P25 is specified for an operation here, it is worth establishing early who will maintain it in five years and where replacement terminals will come from.

The question that decides it

Not 'which standard is best' but 'what is the failure mode we are buying against'.

• If the failure mode is inefficiency (teams not coordinating well, messages missed, phones used where radio would be faster) DMR addresses it at proportionate cost
• If the failure mode is a public safety event (a network outage during an emergency, agencies unable to coordinate) the case for TETRA or P25 is real
• If the failure mode is coverage across a wide or dispersed area rather than within a site, none of the three may be the answer

When none of them is the answer

Conventional land mobile radio requires infrastructure: repeaters, antennas, sites, power, and licensed spectrum. That is proportionate for a defined area. It becomes disproportionate when an operation is spread across a city or a region, because coverage cost rises with area while the benefit does not.

Broadband push-to-talk over cellular inverts that. It uses a mobile operator's existing network, so coverage is wherever the operator reaches, and the cost is a predictable per-user subscription rather than capital expenditure on infrastructure. It also removes the frequency assignment and the recurring spectrum licence.

The trade is dependence. You are relying on a public network that you do not control and that is shared with everybody else in a congestion event. For a guarding operation across a suburb that is an acceptable trade and often the right one. For an emergency service whose whole purpose is to function when public networks do not, it is not.

Moving from analogue without stopping work

Most organizations asking this question already have analogue radio, and the practical constraint is that the operation cannot pause while a new system is installed.

DMR handles this better than the alternatives because most DMR equipment can operate in analogue mode as well as digital. That allows a phased migration: repeaters and radios are replaced progressively, with mixed-mode operation covering the transition, rather than a single cutover on a Friday night. For a security operation running continuous shifts, that is often the difference between a feasible project and an unacceptable one.

It also allows a genuine pilot. Convert one site or one shift, run it alongside the existing system, and find out what the coverage design got wrong before committing the whole fleet, which is what the Kitisuru deployment did before it was extended.

Encryption and privacy across the standards

All three standards support encryption, and all three are frequently deployed without it because somebody assumed digital meant private. It does not. Digital modulation makes casual eavesdropping harder than analogue, but a determined listener with matching equipment is a different matter.

If your traffic includes cash movements, VIP schedules, incident locations or anything a criminal would find useful, encryption should be specified explicitly and its key management understood, including what happens when a radio is lost, which is the scenario that actually occurs.

What actually determines whether the system works

A point that gets lost in standards comparisons: the standard is not usually the reason a system fails. Coverage design is.

Repeater siting, antenna selection and height, power within licensed limits, and terrain between the units determine whether a radio works when someone needs it. A well-designed DMR system will outperform a badly designed TETRA system every time, and cost a fraction as much. Any conversation that reaches a standard before it reaches a site survey has started in the wrong place.

How to run the decision

• Establish the operating area and the terrain within it, on the ground rather than on a map
• Count users and estimate call volume honestly, including peak rather than average
• Define the failure mode you are protecting against, and what it costs when it happens
• Establish what local support and spares look like for each candidate over a five to ten year life
• Include spectrum licensing cost in the comparison, because it changes the answer between conventional radio and broadband push-to-talk

Do that, and the standard usually selects itself.

Discuss a Requirement

Ask a security-conscious organization what it uses for sensitive internal communication and there is a good chance the answer is Signal. Ask who administers it and the conversation usually stops.

This is not a criticism of Signal. Signal is very good, its cryptography is well regarded, and for individual privacy it is close to the best available. The difficulty is that individual privacy and organizational governance are different problems, and a tool built superbly for one will not automatically solve the other.

What Signal is designed to do

Signal is built to give a person private communication that nobody (including Signal) can read, and to hold as little information about that person as possible. Almost every design decision follows from that goal. Messages live on the device rather than on a server. Metadata collection is minimised. Identity is verified between users themselves, through safety numbers, rather than issued and controlled by an administrator.

Those are deliberate choices and they are the right ones for the job. They also mean that certain organizational capabilities are absent by design rather than by oversight.

What an organization discovers it needs

The gap tends to appear at a specific moment: usually an audit, an incident, a departure, or a lawyer's letter. The questions that arrive at that moment are all administrative.

• Who is in this group, and who added them?
• Does the person who resigned last month still have access to anything?
• Can we produce the communications relating to this matter?
• Where is this data, physically, and under whose jurisdiction?
• Can we set retention by policy rather than hoping people delete things?
• Does this integrate with our device management, our identity provider, our monitoring?

On a consumer platform the honest answers are, in order: nobody centrally knows; probably, on their own device; not reliably; on their handset; no; and not really. Independent assessments of Signal in organizational settings consistently describe the same set of characteristics, no centrally enforced role-based access control, no native eDiscovery or legal hold workflow, no compliance logging, limited integration with device management, endpoint or monitoring systems, and no on-premises or private cloud deployment option.

The distinction that matters

It is worth being precise, because the sloppy version of this argument is both wrong and damaging.

The gap is not encryption. Signal's encryption is strong and it is not the weak point in anybody's security posture. Repeating otherwise would be inaccurate and would be quoted back at you.

The gap is governance. It is the ability to say, with evidence, who could see what, when access was removed, where the data resides and how long it is kept. That is not a cryptographic property. It is an administrative one, and a platform either has the machinery for it or it does not.

What a managed platform adds

Wire is one of a small number of platforms built for the organizational case. The relevant differences are structural rather than cosmetic.

Administration

Users, groups, devices and external participants are managed centrally. Offboarding removes access immediately and provably, which is the single most common failure in the consumer model.

Identity

Device and user verification is handled through a certificate process rather than left to participants to check manually. In practice, safety-number verification is a step most users skip.

Deployment

Public cloud, private cloud, hybrid or fully on-premises. For organizations subject to data localisation requirements or their own sovereignty policies, this is frequently the entire decision.

Integration

Single sign-on and provisioning through SAML and SCIM, so the platform inherits the identity controls the organization already operates rather than becoming a second, unmanaged directory.

Externals and guests

Contractors, counterparties and partners can be brought into specific conversations with limited rights and defined lifetimes, instead of being added to a group and forgotten.

When Signal is the right answer

Frequently. If the requirement is that a small number of individuals communicate privately, if there is no regulatory retention obligation, no audit expectation and no need to demonstrate anything to anyone afterwards, a consumer platform is proportionate and a managed one is overhead.

The threshold is worth stating plainly: you need a managed platform at the point where somebody other than the participants is accountable for the conversation. A board. A regulator. A client. A court. Until then, you probably do not.

What migration actually involves

The objection to changing platform is rarely technical. It is that people already use the current tool and will resist another one. That is a fair concern and it is worth answering honestly.

Adoption fails when the replacement is worse to use. If a platform lacks group calling, or file sharing is awkward, or the mobile client is slow, staff will keep a consumer app open alongside it and the organization ends up with two channels and control over neither. Feature parity with what people already use is not a nice-to-have; it is the precondition for the governance benefit being real rather than notional.

The migrations that work tend to share three things. They start with the groups that carry the most sensitive traffic, rather than with everybody at once. They give people a reason that makes sense to them personally (usually that a departing colleague can no longer read the group) rather than an abstract compliance argument. And they set a date after which the old channel is not used for a defined class of conversation, because voluntary migration in parallel does not converge.

What to ask in a procurement

If you are evaluating platforms, the questions that separate them are not about encryption. Every serious candidate will claim end-to-end encryption and most will be telling the truth. Ask instead:

• Can we deploy this on our own infrastructure, and what changes if we do?
• What exactly happens, and how quickly, when we deprovision a user?
• Can we set retention by policy, per group, and prove it applied?
• How do external participants join, what can they see, and when does their access end?
• Does it integrate with our identity provider and our device management, or does it become a second directory?
• If we are asked to produce communications relating to a matter, what is the process and who can perform it?

The answers will separate a consumer tool from a managed platform faster than any feature matrix.

The question to ask internally

Not 'is our messaging encrypted'. The useful question is: if we were asked tomorrow to account for a set of communications (who was in them, what was shared, when access was withdrawn) could we? If the answer depends on asking individual staff to check their phones, the tool is doing something other than what the organization needs.

Discuss a Requirement

Once an organization has decided it needs a managed secure messaging platform, the next question is where it should run. This is usually presented as a technical choice. It is not. It is a question about who you are willing to depend on, and it has a cost attached that most organizations underestimate in one direction and overestimate in the other.

The four models, plainly

Public cloud

The vendor runs the platform on shared infrastructure and you consume it as a service. You get the best availability, the fastest patching and the lowest operational burden, because the people who wrote the software are the people running it. You give up control of where the data physically sits and which legal regime reaches it.

Private cloud

A dedicated instance, in a jurisdiction you specify, run by the vendor or a hosting partner. You keep most of the operational benefit and gain control of location and tenancy. You pay more, and you are still depending on somebody else's operations team.

Hybrid

Some components in your own environment, others hosted. Usually the sensitive functions (identity, key management, message storage) are held locally while the less sensitive parts are not. It is the most flexible model and the most complex to design, and complexity is itself a security property.

On-premises

The platform runs entirely on infrastructure you own and administer, in a location you choose. Nothing leaves your control. Neither does anything get patched unless somebody on your staff does it.

What actually differs

Strip away the marketing and four things vary between the models.

The mistake that costs the most

It is choosing on-premises for the feeling of control and then not resourcing it.

An on-premises deployment is a system somebody has to run. It needs a server, redundancy, backup, monitoring, someone competent to apply updates, and a plan for what happens when that person leaves. Organizations that specify on-premises to satisfy a policy requirement, then run it on a single unmonitored machine in a comms room, have not gained security. They have moved the risk from a professionally operated data centre onto a box nobody is watching, and made it their own liability at the same time.

If you are going to hold it yourself, hold it properly. If you cannot resource that, private cloud in the right jurisdiction is the honest answer and it is a good one.

What sovereignty actually costs

Organizations budget the licence and forget the rest, so it is worth being explicit. An on-premises deployment carries server hardware or virtual infrastructure, redundancy if availability matters, backup and tested restore, monitoring, a patching routine, and staff time to run all of it. Private cloud removes the hardware and most of the operations but adds a hosting cost and a dependency on the hosting provider's jurisdiction and practices.

The useful comparison is not licence against licence. It is total cost over the life of the deployment, including the staff time nobody puts in the business case. When that is done honestly, private cloud in a specified jurisdiction wins for most organizations that thought they wanted on-premises, and the ones for whom it does not win have a reason they can articulate.

Moving between models later

This is worth asking about before you commit, because the answer varies sharply between platforms.

Some are architected so that the same software runs in all four models and moving is a migration exercise. Others are cloud services with an on-premises variant that behaves differently, and moving means rebuilding. If there is any prospect that your requirement will harden (a new funder condition, a new jurisdiction, a change in the sensitivity of what you hold) establish at selection whether the platform can follow you.

Ask directly: if we start in your cloud and need to move on-premises in two years, what exactly happens to our data, our groups and our history? A clear answer is a good sign in itself.

Federation, which is usually overlooked

There is a fifth option that suits multi-organization work particularly well. Federation lets separate deployments interconnect, so several organizations can communicate as though they were on one system while each retains its own. Nobody becomes the custodian of everybody else's data.

For humanitarian coordination, joint operations, or a lead agency working with implementing partners, that maps onto the actual governance far better than one organization hosting a platform for everybody and quietly acquiring visibility of all of it.

How to choose

Three questions settle most cases.

• Are you subject to a data localisation requirement, or an internal policy that behaves like one? If yes, public cloud is out and the question is private cloud or on-premises.
• Could the data you hold be used to harm the people it describes? If yes, the cost of sovereignty is part of the cost of the programme rather than an optional extra.
• Do you have, and will you keep, the people to operate infrastructure? If not, choose the model that does not require them.

Most organizations that work through those honestly land on private cloud in a specified jurisdiction. A minority genuinely need on-premises, and they usually know why before they ask.

Discuss a Requirement

Somebody in your organization has been asked to confirm that internal communications are secure. They are looking at a WhatsApp group with forty people in it, some of whom left the organization, and they are trying to work out what to write.

This article is for them.

What a security review is actually asking

Reviews vary, but the questions underneath them are consistent, and none of them is about encryption strength.

• Who has access to this system, and how do we know?
• How is access granted, and how is it removed?
• Where is the data, and under whose jurisdiction?
• How long is it kept, and who decided that?
• Can we produce records if we are required to?
• Who administers it, and who watches the administrators?
• How does it integrate with our identity and device management?

A consumer messaging app answers none of these, because it was not built to. That is not a defect in the app. It is a mismatch between the tool and the question.

Where the failures actually happen

Offboarding

The single most common finding. Someone leaves, their organizational accounts are disabled the same day, and they remain in six operational groups on a personal phone that nobody controls. There is no administrative action available that removes them, because there is no administrator.

Group membership

Nobody can produce a list of who is in which group, or who added them, or when. In a review that is not a minor gap. It means the organization cannot state who has seen its sensitive information.

Retention

Messages persist on individual devices according to individual habits. Some staff keep everything for years, others clear weekly. Neither is policy, and both are the organization's exposure.

Records and legal hold

If the organization is asked to preserve or produce communications relating to a matter, the honest answer is that it would have to ask individuals to search their own phones and trust the result.

Data location

Rarely knowable, frequently outside the jurisdiction the organization is answerable to, and not selectable.

Why banning it does not work

The standard response to these findings is a policy prohibiting consumer messaging for work. It fails, and it fails predictably.

Staff use consumer apps because they are fast, everybody already has them and they work on a poor connection. If the sanctioned alternative is slower or clumsier, people will use both, and the organization ends up with the same exposure plus a policy it is visibly not enforcing, which is worse in a review than having no policy at all.

The replacement has to be at least as good to use. That is not a soft requirement; it is the condition on which everything else depends.

What to do about the groups that already exist

Remediation is where these reviews usually stall, because the honest position is uncomfortable: the organization has years of operational conversation sitting on personal devices it does not control, and no way to retrieve or delete it.

You cannot fix the past. What you can do is stop it accumulating, and there is a sequence that works.

• Identify the groups that carry genuinely sensitive traffic. It is usually far fewer than people assume, operations, security, leadership, and anything touching beneficiaries or personnel
• Move those first, with a date after which the old group is not used for that class of conversation
• Leave the social and low-sensitivity groups alone. Fighting them costs goodwill and buys nothing
• Ask departing staff to leave work groups as part of the exit checklist. It is imperfect and it is better than nothing, and it costs a line in a form

An organization that has done those four things has a defensible answer, which is the realistic goal. A perfect answer is not available.

What a useful finding looks like

Reviews fail to change anything when findings are written abstractly. Compare two versions of the same finding.

Weak: 'Use of unmanaged messaging applications presents a data governance risk.' Nobody disagrees, nobody acts.

Strong: 'Three former staff members remain in the operations coordination group. The organization cannot remove them, cannot establish what they have seen since leaving, and cannot produce a record of the group's membership at any past date.'

The second is the same risk, stated so that it cannot be filed. It also points at the remedy without arguing for a particular product, which is the right way round.

Taking it to a board

Boards do not act on control gaps described in control language. They act on consequences they can picture.

Three framings tend to work. What we would say to a regulator or a major client who asked how we protect their information. What happens if a departing employee takes a group's contents to a competitor or a journalist. And what we would be able to produce if a matter went to dispute and we were asked for the communications.

None of those requires the board to understand encryption, and all of them are true.

If you are the person running the review

Three things make the exercise useful rather than performative.

• Write down what is actually used, not what policy says. The gap between those two is the finding.
• Test offboarding specifically. Pick someone who left three months ago and establish what they can still see. It is the fastest way to make an abstract risk concrete for a board.
• Frame the recommendation around control rather than encryption, because encryption is where the conversation goes to die. Everyone agrees encryption is good and nothing changes.

The outcome worth aiming for is not a more secure app. It is an organization that can state, with evidence, who could see what and when their access ended.

Discuss a Requirement

It is the question every radio project starts with and the one that cannot be answered on the phone. The reason is simple: repeater count is determined by what is between your radios, not by how many of them you have.

The misconception worth clearing first

More users do not require more repeaters. More users require more channels, which is a different problem with a different solution. A single repeater can serve a large fleet if the coverage works and the traffic fits; forty radios in one warehouse may need none at all, because they can talk directly to each other.

What requires a repeater is distance and obstruction. Two radios that cannot hear each other need something in between that can hear both.

What actually drives the count

Coverage area and shape

A compact site is easier than a long thin one of the same area. A corridor, a pipeline, a road or a perimeter fence needs coverage along its length, and length is what costs repeaters.

Terrain

Hills, escarpments and valley floors block signal. In much of Kenya this is the dominant factor, and it is why coverage that works on a map fails on the ground. A single well-sited repeater on high ground can replace three badly sited ones.

Vegetation

Dense tree cover attenuates signal significantly, and seasonally. A system commissioned in the dry season can degrade noticeably once the canopy fills in, which is a genuine and frequently missed cause of complaints months after handover.

Building structure

Reinforced concrete, metal cladding, lift shafts, basements and multi-storey layouts all attenuate. Indoor coverage in a large building can need in-building infrastructure regardless of what the site coverage looks like outside.

Antenna height and siting

Frequently more consequential than the repeater itself. Raising an antenna is often the cheapest coverage improvement available, and it is regularly overlooked in favour of adding equipment.

What it costs to get wrong, in both directions

Under-building leaves black spots. The system appears to work during commissioning, because commissioning happens in the accessible parts of the site, and fails in the places nobody walks, which are the places where somebody alone needs to call for help.

Over-building costs money three times: capital on equipment, installation on sites and masts, and recurring licence fees on frequencies you did not need. In Kenya each repeater generally means a frequency pair licensed from the Communications Authority, so redundant repeaters carry a recurring cost, not just a one-off one.

How it is actually established

By survey. Somebody walks or drives the site with test equipment, transmits from candidate locations and measures what is receivable where. Predictive modelling is useful for narrowing candidates, but terrain data does not capture a metal-clad warehouse or a stand of trees, and those are usually what decides it.

The survey also answers questions that determine cost more than repeater count does: whether existing masts can be used, whether power and backhaul exist at candidate sites, and whether site access is practical for maintenance.

What a survey report should give you

If you commission a survey, these are the things that make it worth what you paid.

• Coverage maps showing measured signal, not only predicted, with the measurement points marked
• Named candidate sites with the reasoning for and against each, including the rejected ones
• Antenna heights and types assumed, because changing those changes everything downstream
• Identified black spots and what it would cost to cover them, so you can decide whether to
• Power, backhaul and access notes for each site, which frequently decide feasibility
• The frequency requirement, so licensing can start rather than waiting for delivery

A survey that produces only a repeater count and a price has not told you anything you can check.

Designing for the site you will have

Sites grow. A compound adds a wing, a conservancy extends a patrol sector, a plant adds a yard. Repeater siting that was optimal for the original footprint is frequently poor for the extended one, and the cost of moving infrastructure exceeds the cost of having sited it with room to grow.

Ask the survey to consider the expansion you already know about. It rarely changes the recommendation, and when it does, it changes it cheaply.

When the answer is none

Small compact sites with clear line of sight frequently need no repeater at all. Radios operating direct (simplex) are cheaper, simpler and have no infrastructure to fail. Any supplier who proposes a repeater without establishing whether simplex would work is selling equipment rather than solving a problem.

Questions to ask anyone proposing a count

If a supplier gives you a repeater number, these four questions establish whether it is engineering or a guess.

• What is that based on: a measured survey, a predictive model, or experience of similar sites?
• Which parts of the site does this design not cover, and what would covering them cost?
• What antenna height does the design assume, and what happens to coverage if we cannot achieve it?
• How many frequency pairs does this require, and what is the recurring licence cost?

The last one catches most inflated proposals, because it converts an extra repeater from a one-off line item into a recurring cost the customer will see every year.

When the answer is not a repeater at all

If the operation is spread across a city or region rather than concentrated on a site, repeater coverage becomes disproportionate; cost rises with area while benefit does not. Broadband push-to-talk over a mobile network is usually better economics at that point, and it removes both the infrastructure and the recurring spectrum licence.

The right question is never 'how many repeaters'. It is 'what does coverage have to achieve, and what is the cheapest way to achieve it'.

Discuss a Requirement

Television in a hotel, lodge, compound or staff accommodation looks like a small decision until the first invoice, the first outage or the first letter about licensing. It is worth getting right at the start, and the decisions are fewer than they appear.

First, the question everybody gets wrong

A residential television subscription does not license commercial or public viewing. Using a home subscription in guest rooms, a bar, a reception area or staff accommodation is a breach of the subscription terms and of the content licensing behind them.

The exposure sits with the business, not with whoever installed it. This is the single most common finding when we survey an existing installation, and it is almost never deliberate; somebody set up what they had, the property grew, and nobody revisited it.

A commercial subscription licenses the viewing your premises actually does. It also comes with a commercial support relationship, which matters when a system serving sixty rooms fails on a Friday night.

And the one people get wrong second

Pirate services and cloned decoders are cheap and openly available in some markets. They are a poor trade for a business, and not principally for ethical reasons.

• Modified decoder software and streaming applications of unknown origin are a documented malware route, and you are installing them on equipment inside the network your guests use
• There is no support line, no service level and no engineer when the stream drops during a match
• The supplier is unlicensed, which means it is accountable to no regulator and to you least of all

A guest whose room television fails complains to you. That is the whole argument.

Which package suits which premises

Commercial packages are structured around what the premises is, not around budget. Getting this right is most of the decision.

Sites with more than one character need more than one package. A compound with staff accommodation, a canteen and an office is genuinely three environments, and pretending otherwise produces either overspend or complaints.

The part that costs more than the subscription

Distribution. One signal has to reach many rooms, and how that is done determines both the installed cost and how much trouble the system gives you afterwards.

A master antenna television system takes a central source and distributes it through a single cabled network to every outlet. One headend, one dish array, one set of amplifiers. The alternative (a decoder and a dish per room) is cheaper for four rooms and absurd for forty, and it puts equipment in guest rooms where guests will reconfigure it.

Two practical points. Existing cabling can frequently be reused, and cabling is usually the expensive part, so a survey before quotation genuinely saves money. And distribution design is where in-room quality problems come from: signal level, splitter losses and amplification determine whether room 412 at the end of the run looks like room 101.

Channel counts, and why they move

Package comparisons usually come down to channel counts, and they are the least reliable basis for a decision.

Counts are approximate and they change: broadcasters add and remove channels, rights move between platforms, and the operator reserves the right to adjust the line-up. A package that had a particular sports channel last season may not this season, and that is normal rather than a failure.

What matters for a hospitality or compound buyer is not the total but whether the specific things your audience actually watches are in the package, usually a handful of sports, news and general entertainment channels, plus language coverage appropriate to your guests or staff. Ask for the current channel list for the specific package and check it against that shortlist. It takes ten minutes and it is the only comparison that predicts satisfaction.

Add-ons, and the one worth understanding

Packages can be extended. News, language and regional add-ons are inexpensive and are the usual way to tailor a system to a particular staff or guest population.

The one worth understanding properly is ExtraView, which allows a second viewing point on the same subscription rather than requiring a second subscription. For a compound with a communal area as well as accommodation, or a property with a public bar and guest rooms, it frequently changes the arithmetic. Ask about it specifically, because it is rarely volunteered.

Working out what it should cost

The number that matters is cost per room per month, and it has three components: the subscription, the amortised installation, and the support arrangement. A cheap subscription attached to a badly designed distribution system is not cheap; it is a maintenance liability with a low headline rate.

Ask any supplier for all three. A quotation that gives you only the subscription is not a quotation.

A short checklist before you buy

• How many rooms or viewing points, now and after the next expansion?
• What is the premises actually for: sleeping, drinking, working, living?
• Is there existing cabling, and has anyone surveyed it?
• Who supports it, from where, and how quickly?
• Is the subscription commercial, and is that in writing?

Five questions. Most bad television installations fail at least three of them, and they fail them before anything is switched on.

Discuss a Requirement

Systems integration is one of those terms that appears in every supplier's description of itself and means something different in each. It is worth defining precisely, because the difference between an integrator and a reseller is the difference between buying a system and buying a pile of equipment that ought to work together.

The definition, without the jargon

Integration is making separate technologies operate as one system, designed around an operational objective rather than around a product catalogue.

The word doing the work is 'designed'. Anyone can supply a camera, a radio and an access control reader. Integration is establishing what has to happen when the reader is forced at two in the morning (which camera records, who is told, over what channel, and what the record looks like afterwards), and then building the thing that does it.

What it looks like when it is absent

You can recognise an unintegrated installation without opening a cabinet.

• Systems that were bought together but do not talk to each other
• Three separate interfaces an operator has to watch simultaneously, so in practice they watch one
• An incident that is visible on one system and invisible on the others
• No single record of what happened, only fragments in three places with unsynchronised clocks
• Each vendor confident the fault is somebody else's

That last point is the practical reason organizations pay for integration. Not elegance, accountability.

When you genuinely need an integrator

• When more than one technology has to work together to achieve the objective
• When the operational requirement is specific enough that off-the-shelf configuration will not meet it
• When you are extending or connecting systems you already own, which is harder than building new
• When the consequence of the system failing is operational rather than merely inconvenient
• When you do not have the in-house capacity to own the design yourself

When you do not

Plenty of requirements are procurement, not integration, and treating them as integration wastes money.

If you need twenty radios on an existing system, that is supply. If you need cameras added to a working platform with capacity, that is installation. A supplier who turns either of those into an integration project is inflating the work, and you are entitled to say so.

Integrating what you already own

Most integration work in practice is not building from nothing. It is connecting systems bought at different times, from different suppliers, by different people, none of whom expected them to be joined.

That is harder than new-build and it is where experience shows. The constraints are real: equipment that has reached end of support, proprietary interfaces that were never meant to be opened, cabling installed for a different purpose, and documentation that does not match what is actually there.

The honest sequence is to survey what exists before designing anything, and to expect the survey to contradict the drawings. Any proposal to integrate existing systems that was written without someone looking at them is a guess with a price attached.

What an integration project actually looks like

For anyone who has not run one, the shape is worth knowing, because it tells you where to apply attention.

• Requirements and survey, where the operational objective is established and the site is examined
• Design, where the technologies and the interfaces between them are specified, and which is signed off
• Procurement, where lead times and licensing usually determine the programme rather than price
• Installation and configuration, which is the visible part and rarely the risky one
• Integration and testing, where the joins are proved and where problems surface
• Training and handover, including documentation, credentials and the maintenance arrangement

The two stages that decide whether a project succeeds are the first and the fifth. The middle is logistics. If a supplier's programme compresses survey and testing to make a date, that is where the failure will come from.

How to tell an integrator from a reseller

Four questions, and the answers are revealing.

A reseller answers the first question with a product, avoids the second, treats the third as a warranty question and does not understand the fourth.

The documentation test

The most reliable indicator is what you receive at handover. An integrated system comes with as-built drawings, configuration records, an equipment schedule, credentials handed over properly and a maintenance schedule. A pile of equipment comes with manuals.

The reason this matters is not tidiness. It is that the next engineer to touch the system (who may not be from the same company) can only work on what is documented. Undocumented systems become unmaintainable at exactly the moment the person who built them moves on.

The honest version of the single-supplier argument

Integrators argue that one accountable supplier is better than several. That is true, and it is worth being clear about why, because the reason usually given is not the real one.

The real benefit is not convenience. It is that when several suppliers each own a part, the gaps between the parts are owned by nobody, and the gaps are where systems fail. A single accountable design means somebody is responsible for the joins.

The corresponding risk is concentration: one supplier failing you across everything. Mitigate it by owning your documentation and insisting on standards-based equipment rather than proprietary lock-in. A good integrator will agree with that, because it is a description of good practice rather than a threat.

Discuss a Requirement

Most access control at critical sites was designed to answer one question: is this person allowed in? That is the easy question, and answering it well does not make a site secure.

The harder questions arrive afterwards. Who was on site when the pump failed. Which contractor had access to the switch room in the fortnight before the outage. Whether the person who left through the north gate at 02:00 is the same person who entered through the main gate at 18:00. A system that cannot answer those has controlled entry without producing security.

What critical infrastructure actually changes

The phrase gets used loosely, so it is worth being specific about what makes a site different. Three things.

The consequence of failure extends past the operator. A breach at an office costs the business. A breach at a water treatment works, a substation or a fuel depot reaches people who never chose to take the risk, which is why these sites attract regulatory attention that ordinary commercial premises do not.

The threat is patient. Opportunistic theft is a nuisance. The serious risk at infrastructure sites is someone who is prepared to spend weeks understanding shift patterns, contractor rotations and which gate is unmanned at handover. Controls that defeat an opportunist barely inconvenience that person.

And the site is rarely one place. A generating station is a compound with an administrative block, a control room, a switchyard, a fuel store and a perimeter, and the population allowed into each differs. Treating it as a single access boundary (in or out) is the most common design failure and the hardest to retrofit.

Zones, not doors

The useful mental model is concentric. Public approach, controlled perimeter, operational area, critical area. Each boundary has its own population and its own evidence requirement.

Most sites implement the perimeter and stop. The gap between perimeter and critical is where incidents actually happen, because it is where contractors, deliveries and maintenance crews operate, the population with legitimate access and the least oversight.

Contractors, which is where the exposure actually sits

The population with legitimate access and the least oversight is contractors, and at an infrastructure site it is usually the largest population on any given day. Maintenance crews, specialist engineers, cleaners, caterers, delivery drivers and the subcontractors they bring without telling anyone.

Three controls do most of the work here, and none of them is expensive.

• Access tied to a work order with a start and an end, so authorisation expires by default rather than by somebody remembering to revoke it
• A record of who a contractor actually is, held by the site rather than by the contracting company. Sites that cannot name the people who were on them are relying on a supplier's list they have never seen
• Exit recorded as strictly as entry. A site that knows who came in but not who left cannot answer the question that matters during an evacuation, and cannot detect the person who never went home

Retrofitting these is unglamorous work with a poor demo and a very good return. It is also the part most likely to be descoped when a project runs long, which is worth knowing before the project runs long.

Where surveillance is misunderstood

Cameras are usually bought for deterrence and justified for evidence, and they frequently deliver neither, for reasons that are known in advance and ignored anyway.

• Coverage is specified by camera count rather than by what has to be identifiable. A camera that proves someone was present is a different specification from one that proves who
• Retention is set by disk size rather than by how long an incident takes to surface. Infrastructure incidents are frequently discovered weeks later, by which time the footage has rolled
• Nobody is watching, and nobody was ever going to. Live monitoring is a staffing commitment, and a system sold on live monitoring but resourced for review is a review system with an expensive interface
• Lighting was never considered. A camera that produces unusable footage at night is unusable during the hours that matter

The honest position is that most surveillance at these sites is forensic rather than preventive. That is fine (forensic value is real value), but it should be designed for on purpose. Designing for prevention and delivering forensics is how organizations end up with footage nobody can use.

The integration that makes the difference

Access control and surveillance are usually procured separately, installed separately and operated separately, and the value sits in joining them.

A badge event with no corresponding camera event is worth investigating. So is a camera event with no badge. So is a badge used at a gate two minutes after the same badge was used at a gate fifteen minutes' walk away. None of those is detectable if the two systems keep separate records that a person has to reconcile by hand after something has already gone wrong.

The same applies to radio. Site security teams communicate over two-way radio, and the value of tying a radio call, a badge event and a camera view to the same timestamp is that an incident can be reconstructed rather than reconstructed from memory.

What to ask before you buy anything

• What question do we need this system to answer after an incident, and can it?
• Which population is actually the risk: outsiders, or authorised people doing unauthorised things?
• How long does it take us to notice something, and does our retention cover that period?
• Who reviews the records when nothing has happened? A system only checked after an incident is a system nobody knows is broken
• What happens when the power fails, and what happens when the network fails? These are the conditions during which sites are most vulnerable and most systems are least available

The last one is worth pressing on. Access control that fails open leaves the site unprotected; access control that fails closed can trap people inside a hazardous area. There is a right answer per door and it is a safety decision as much as a security one.

Doing it in stages

Nobody rebuilds a site's security in one project. The sequence that works is: fix the zone model on paper first, because it costs nothing and it determines everything after it; then bring identity and time attribution to the boundaries that matter most; then extend surveillance to those same boundaries at a specification that produces usable evidence; then integrate.

Doing it in the other order (cameras first, zones never) is how sites end up with sixty cameras, one gate and no idea who was in the switch room.

Discuss a Requirement

Satellite gets specified for one of two reasons. Either there is genuinely no terrestrial option, or there is one and it cannot be relied on. Those are different problems and they lead to different designs, so the first useful step is deciding which you have.

The three situations

No coverage at all. A camp, a conservancy, an exploration site or a construction project outside any cellular footprint. Satellite is the primary link and everything depends on it, so availability matters more than speed.

Coverage that exists but fails. A site with cellular or fibre that drops during rain, at peak, or whenever a backhoe finds the duct. Satellite is a backup, and the design question is how quickly and how automatically it takes over.

Coverage that cannot be trusted for other reasons. Operations where the terrestrial network may be congested, monitored or deliberately interrupted during exactly the period the link is needed. This is the case least often stated in a requirement and the one that most changes the answer.

What actually varies between options

The market is usually presented as a choice of orbit. Orbit matters, but it is not what a buyer feels.

Latency and contention are the two that determine whether users are satisfied. A link that tests well on installation day and is unusable at 09:00 on a Monday is a contention problem, and no amount of retesting the hardware will find it.

The mistake that costs the most

It is sizing the link for the application and forgetting everything else the site will do with it.

A remote camp specifies satellite for operational reporting, sizes it accordingly, and then discovers that thirty people with phones have found the Wi-Fi. The operational traffic (the reason the link exists) is now competing with video streaming, and it loses.

The fix is not a bigger link. It is deciding, before installation, what the link is for and enforcing that in configuration: operational traffic prioritised, staff welfare access permitted within a ceiling, and both monitored. Welfare access matters at remote sites and removing it entirely is neither kind nor sustainable. But it has to be bounded, and the boundary has to be technical rather than a notice on a wall.

The cost shape, which is where budgets fail

Satellite hardware is a one-off number that appears in a capital budget and gets approved. Airtime is a monthly number that lands in an operating budget for as long as the site exists, and it is the one that decides whether the link survives its second year.

Two things distort the comparison at purchase. Promotional airtime pricing that steps up after an introductory period, and allowances that look generous until the site's actual usage is measured rather than estimated. A requirement written as an average monthly figure will be wrong, because remote sites are not average; usage spikes during the incidents and mobilisations that are precisely when the link matters.

Budget for twelve months at the plan you will actually be on, with headroom for the months that are not typical. Then ask what happens if the site is still there in three years, because remote sites usually are.

The first thirty days

Most satellite links that disappoint were commissioned badly rather than specified badly.

Three things are worth insisting on at handover. A baseline performance measurement taken at a busy hour rather than at installation, so there is something to compare against when users say it has got worse. A written record of the terminal's position and alignment, so it can be restored by someone who was not there. And a named person on site who has been shown what to check, in what order, before escalating.

That last one converts a multi-day outage into a twenty-minute one more often than any hardware decision made during procurement.

Satellite and radio are not competitors

At most remote sites both belong, because they solve different problems.

Two-way radio handles communication between people on the site, immediate, group-wide, no dependency on anything beyond the local infrastructure, and it keeps working when the satellite link is down. Satellite handles communication between the site and everywhere else.

The sites that run well treat them as one system rather than two purchases. The radio network works locally, the satellite link carries the site's traffic outward, and where it matters the two are bridged so a person on a radio can reach someone who is not on site at all.

Discuss a Requirement