Verifying carrier bands for a 4G gateway is a procurement step that most buyers skip, and it is the one that decides whether the hardware works at the destination at all. A gateway that supports the wrong bands is not a poor performer; it is a device that cannot register.
This article sets out how to build an operator-by-band matrix for the markets you intend to serve, how to read a specification for the exact model and firmware you are buying, how to verify with real SIMs rather than with promises, and what to record so the answer survives the next procurement cycle.
Why is verifying carrier bands for a 4G gateway a list rather than a claim?
Because a device supports several bands, not one standard.
Fourth-generation cellular service is delivered on multiple frequency bands, an operator uses specific bands in specific areas, and a device works only where its supported list intersects the operator’s.
The technical characteristics of terminal radio transmission and reception, including the bands and the conditions under which equipment is specified, are set out in 3GPP TS 45.005 for the GSM family, and the harmonised terminal standard for the European market is published as ETSI EN 301 511. The index of current specifications maintained by 3GPP is the place to check which document applies to a given generation.
What makes this a procurement risk rather than a technical detail is that the list is rarely uniform across a product family. Two models in the same series can differ, a firmware revision can add or remove support, and a market-specific variant can exist without the model name changing. That is why the answer belongs to a specific model and firmware revision, written down, rather than to a brand.
How do you build an operator-by-band matrix?
One row per operator, one column per band.
The matrix takes an afternoon to build and answers the question for every future deployment in those markets.
Start from the operators you will actually use, not from a regional average. Operators publish the bands they use, and in many markets several operators use different bands in the same city, so a device that works with one may not work with another a kilometre away. Note the generation as well as the band, because a device that supports a band on one generation may not support it on another.
Operator identity is carried in the network signalling, and the numbering that identifies a subscriber’s home network is described in the ITU-T E.212 recommendation, while the identifier held on the card itself is covered by ITU-T E.118. Those two references matter when you compare a device’s behaviour across operators, because the network the device selects is determined by the subscription rather than by the hardware.
Keep a column for the source of each band entry and the date it was checked. Operator networks change, and a matrix that cannot be dated is a matrix that will be reused after it has expired.
| Column | Why it exists | Where it comes from |
|---|---|---|
| Operator and market | Bands differ between operators in one country | Operator coverage documentation |
| Band list | The intersection with the device is what matters | Operator published band information |
| Generation | Support is per band per generation | Operator and device specifications |
| Device support | The claim being verified | Datasheet for the exact model and firmware |
| Verified by test | Distinguishes documentation from behaviour | Registration test with a real SIM |
Reading the datasheet for the exact model and firmware
Read the specification for the unit being shipped. A datasheet that covers a family rather than a model is a starting point, not an answer, and the model number on the quotation is the one that has to be supported. Where the vendor publishes variant differences, read them; where it does not, ask for the band list in writing against the exact model code.
Ask about firmware as well. A revision can alter which bands are enabled, either as an improvement or as a consequence of a regulatory change in one market, and a deployment that updates firmware without re-checking the band list can lose support it previously had. The practical protection is to record the band list alongside the firmware version when the equipment is accepted, so the two travel together through later changes.
Where a specification is not published for the model you are considering, treat that as a finding in itself. Capability that cannot be confirmed before purchase is capability you cannot plan around, and the answer is to require the list from the supplier rather than to infer it from a similar model.
How do you verify with a SIM from each target operator?
Register and send with a real SIM, then record it.
A test with a real SIM from each operator confirms three things at once: that the band is supported, that the subscription works in the device, and that the network accepts the equipment.
Run the test at the destination rather than at the office. Band support is a hardware property, but coverage is a local one, and a device that passes at headquarters can fail at a site where the operator uses a different band or where coverage is marginal. The registration procedure that the device completes during the test is defined in 3GPP TS 24.301, and knowing the sequence makes a failed test easier to interpret: a device that never reaches registration has not yet demonstrated anything about the band.
Test the operators you intend to use, and test more than one if the deployment relies on a backup operator. Record which band the device selected, since a device that falls back to an older generation to stay registered will pass a basic connectivity test while delivering the wrong service for the deployment.
Repeat the test on at least two units of the same model when the order is large. Radio performance varies slightly between units, and one unit that passes does not prove that a shipment will, particularly where the site sits near the edge of coverage. Where the deployment spans several sites, test at the site with the weakest coverage rather than the most convenient one, because that is the location that will produce the first complaint.
One column in the matrix is worth keeping even when it stays empty: the date of the last failed verification. An operator whose device failed to register once is an operator worth re-testing before a new deployment goes in, because the failure usually has a cause that can be checked rather than merely remembered.
Network generation as a separate check
A band is not a generation. A device can support a frequency band on one generation of technology and not on another, and operators are at different stages of refarming the same spectrum. The result is a device that reports band support correctly and still delivers the wrong performance because it is operating on an older generation than the plan assumed.
Two checks close the gap. The first is to record the generation the device actually used during the verification test, not the one the datasheet claims. The second is to note in the matrix which operators plan changes to the generation used on each band, since a refarming plan can invalidate a verification result without changing the device.
Where the deployment carries voice, the generation matters more than it does for messaging, because the voice path depends on how the network carries the call. A device that works for messages on one generation can behave differently on the voice path, and the two should be verified separately if both are in scope.
Recording the result against the deployment plan
Record the verification against the deployment it was performed for. The useful record has the market, the operators tested, the model and firmware, the bands confirmed by test, the generation observed, the date and location of the test, and the name of the person who performed it.
Keep the record where the deployment plan lives, so that an expansion into a new market starts from a list of what is already verified rather than from the beginning. The same record is the evidence a buyer needs when a later shipment behaves differently: it is the baseline that shows what the equipment did when it was accepted. Where a market is served by more than one operator, record the result per operator rather than as a single figure for the country, because the two can differ on the same model and firmware.
What do you do when a band is missing?
Change the model, change the market, or accept it.
A missing band is a design constraint, and the three responses are all legitimate depending on the commercial context.
Changing the model is the cleanest answer where the range includes a variant that covers the market. Changing the market — deploying where the equipment works rather than where the contract is — is sometimes the commercial reality, and it should be recorded as a deliberate decision rather than discovered later. Accepting the limitation is workable where the missing band affects a service the deployment does not use, and it should be written down with the consequence stated explicitly.
What should not happen is treating a band gap as a configuration problem. No setting adds radio support, and a deployment that depends on one being added later is a deployment with an unbounded dependency on a firmware release that may not exist.
Get the band list in writing against the exact model code. Send your target markets, operators and required model to service@telarvo.com, or review the published configurations on the SK-SMS Gateway range and the VoIP gateway range. Telarvo publishes the SK VOIP gateway range and the GoIP models on its product pages, and the configurations referenced above come from those listings.
FAQ
Is band support the same across a product family?
Not necessarily. Two models in one series can carry different radio modules, and a firmware revision can change which bands are enabled. Read the specification for the exact model code being shipped, and record the band list together with the firmware version so the two stay associated through later updates. Where a supplier provides a family datasheet, ask for the model-specific page.
Can we test bands without a SIM?
Not meaningfully. Some devices will report which bands they can see, but capability is only demonstrated by registering on a real network with a real subscription. A test with a SIM from each target operator confirms band support, subscription behaviour and network acceptance in a single step. Record the operator and the band actually used, not just the fact of registering.
What if the vendor does not publish a band list?
Ask for it in writing against the model you intend to buy. Where no list is available, treat the capability as unverified and plan accordingly, because a deployment that assumes support for a band cannot base a service on the assumption. The absence is procurement information rather than a negotiation tactic. It is also a signal about how the supplier treats specification requests generally.
How often should a band matrix be re-checked?
Whenever an operator changes its network, when a new market or operator is added, and at each procurement cycle. Date every entry and record its source. Networks are refarmed over time, so a matrix without dates will eventually describe a network that no longer exists. The date is what tells a later reader whether the entry is evidence or history.