Set LTE Bands (Coming Soon)
Set preferred LTE bands within the range explicitly supported by the device, cellular module, and firmware to meet the needs of a specific carrier network or field communication environment.
Capability preview
This endpoint is not yet available. Changing LTE bands may temporarily take a device offline. Before use, confirm that both the target device and its current network support the selected bands.
Current Band and Preferred Bands
These concepts use different fields:
| Field | Meaning | How to Obtain It |
|---|---|---|
currentBand | LTE band on which the device is currently camped | Read it with Get LTE Network Information |
preferredBands | Set of LTE bands that the cellular module is allowed to prefer | Set by this configuration endpoint and returned after device confirmation |
The cellular module represents network preference as a set of bands instead of storing one fixed band. The planned endpoint therefore accepts an array and does not expose an ambiguous single-value band field.
Planned Request Fields
| Field | Type | Required | Description |
|---|---|---|---|
preferredBands | integer[] | Yes | Non-empty list of unique LTE band numbers; every value must be supported by the target device |
The supported bands will be defined by device type before release. The documentation will not provide one fixed list for all A76XX variants because regional variants support different bands.
Planned Success Response
This operation will use the asynchronous command model. After accepting the HTTP request, the API returns 202 Accepted and COMMAND_ACCEPTED. The fields below are inside data.command.
| Field | Type | Required | Description |
|---|---|---|---|
id | string | Yes | Command ID used to query the final result |
deviceId | string | Yes | Target device ID |
status | string | Yes | SENT, SUCCESS, FAILED, or TIMEOUT |
params.preferredBands | integer[] | Yes | Normalized band set from this request |
result.preferredBands | integer[] | No | Actual preferred band set returned after successful device confirmation |
createdAt | string | Yes | Command creation time in RFC3339 UTC |
result.preferredBands is returned only after the device confirms successful configuration. TIMEOUT means that the result was not confirmed, not that the device definitely did not apply the configuration. The caller should read the current network information or configuration result before deciding whether to retry with a new idempotency key.
Safety Boundaries
- Allow only bands explicitly declared as supported by the device. Do not substitute a frequency table from another A76XX model.
- Accept only band configuration values listed in the released documentation.
- Run only one network-configuration operation on a device at a time.
- Use idempotency to prevent duplicate configuration caused by repeated client requests.
- Do not blindly retry after a timeout. Confirm the current connection state and configuration first.
- Return asynchronous results through the standard OpenAPI command-status model.
Capability Detection
After release, callers should first use device capability information to confirm that the target device supports band configuration. Available bands may differ by device, region, carrier, cellular module, or firmware.
OpenAPI will not assume that every LTE device supports the same bands or allow callers to bypass device capability restrictions.
Field Basis
SIMCom A76XX represents LTE band preference as a combinable band set, with some higher-numbered bands represented in an extended set. OpenAPI will expose this capability as a preferredBands array and perform device-model validation and module-configuration conversion on the server. Callers do not need to process vendor bitmasks.
Rate Limits and Retries
Band changes are device-configuration operations and do not use ordinary read-query limits. The released rules will specifically control:
- Concurrent operations on the same device
- The interval between consecutive configuration operations
- Duplicate submissions while a command is running
Exact limits and retry rules will be published when the endpoint becomes available.