LTE Cat 1bis: Technology Explained and Module Selection Guide

LTE Cat 1bis modules, also known as LTE Category 1 bis, provide 4G connectivity for IoT and machine-to-machine applications. Their single cellular receive-path design can simplify RF integration while retaining Cat 1 peak data rates.

For engineers and OEMs, the value lies in matching that design to the application’s data, power, coverage and integration requirements. Smart metering, asset tracking, payments and remote monitoring each place different demands on the complete device.

This guide explains LTE Cat 1bis technology, technical features, comparisons and applicable industries. It also explores Cavli modules and the practical checks needed to move from a shortlist to a validated production design.

What is LTE Cat 1 bis?

LTE Cat 1bis is a 4G LTE device category that uses a single cellular receive path and supports peak speeds of 10 Mbps downlink and 5 Mbps uplink. It retains Cat 1 data rates while removing the second receive path used for diversity reception.

This design can help manufacturers simplify cellular RF integration and accommodate compact products. Actual performance still depends on the antenna, enclosure, signal conditions, network and application workload.

Cat 1bis is specified in 3GPP Release 13. Individual modules can implement later releases; the Cavli modules compared below specify Release 14. The category’s introduction and a module’s release specification are different facts.

Technical Features and Specifications of Cat 1 bis Technology

The antenna configuration of LTE Cat 1 bis

Conventional LTE Cat 1 supports diversity reception through two receive paths. Cat 1bis uses one, simplifying the receive-path arrangement while removing the reception benefit of a diversity antenna.

LTE Cat 1 and LTE Cat 1bis comparison

Cellular receive-path comparison: LTE Cat 1bis uses one receive path; conventional LTE Cat 1 uses two for diversity reception. GNSS antenna requirements are separate.

“Single antenna” describes the cellular design. A configuration with integrated GNSS functionality can require a separate GNSS antenna connection. Test the complete antenna arrangement in the final enclosure before selecting a module.

Data rates and application performance

Peak cellular rates are not guaranteed application throughput. Measure actual payload delivery, recurring firmware downloads and response times using the intended host interface, firmware and network. For remote control, distinguish response time while connected from response time after waking or reconnecting.

Power consumption and battery-life evaluation

A low sleep-current figure does not establish device battery life. Measure energy across connection setup, data transmission, listening, positioning and sleep under the actual workload.

Use operating-mode figures to plan the test, then measure the assembled device. Include:

• Energy from wake-up to successful payload delivery, including retries.
• Time spent in each operating state and the current in that state.
• How quickly the device must receive a server command.
• Host, sensor and GNSS activity during each reporting cycle.
• Supply behavior during transmission and reconnect attempts.
• Entry into and exit from supported power-saving modes.
• Performance under representative signal conditions.

Does LTE Cat 1bis support PSM and eDRX?

Confirm power-saving mode (PSM), extended discontinuous reception (eDRX) and other sleep-mode support for the exact module, firmware and intended network. Do not assume that every Cat 1bis configuration supports the same modes. Test server-command reachability and wake-up behavior against the application requirements.

A payload-only transmission calculation excludes registration, protocol overhead, retries and listening time. It must not be presented as the complete device ON time or proof that one technology always consumes less energy.

Use the same workload, test method and network conditions when comparing candidates. Set an acceptable daily energy budget and delivery-success target before testing. Keep module current figures separate from whole-device measurements.

When evaluating Cavli modules, use the CQ16 and C16QS specifications as inputs to your power test plan; confirm configuration-specific conditions before comparing results.

Why does a modem reset during registration or transmission?

Treat resets as a measured diagnostic problem. Capture voltage at the module supply pins alongside current and reset logs during startup, registration, transmission and wake-up. Compare the results with the selected module’s supply and transient requirements.

Check the regulator, battery condition, wiring, connectors and decoupling. Repeat the test at the intended temperature and battery operating limits. A nominal voltage reading or a working USB connection does not establish that the supply remains adequate during every operating state.

Do not apply a current-spike value from another module to your design. Obtain the documented requirements and validate them on the assembled device.

Comparison between NB-IoT, LTE-M and Cat 1 bis

Is LTE Cat 1bis better than LTE-M or NB-IoT?

There is no universal winner. Compare Cat 1bis, LTE-M and Narrowband IoT (NB-IoT) against data volume, mobility, reachability, energy use and available network service.

Cellular technology selection considerations

These are evaluation directions, not universal rankings. Confirm supported features, service availability and roaming arrangements for the selected configuration. Avoid assigning a fixed battery life, cell capacity or worldwide availability to a category.

For products moving across countries, evaluate the intended SIM or eSIM profile along representative routes. For installations inside cabinets, basements or other weak-signal locations, compare successful message delivery, retries and energy use in the final enclosure.

A migration from 2G or 3G also requires a review of host interfaces, commands, power design, antennas and service compatibility. Treat it as a complete hardware and software migration.

When should you choose Cat 4 instead?

Cat 1bis specifies peak rates of 10 Mbps downlink and 5 Mbps uplink; LTE Cat 4 offers higher peak rates of 150 Mbps downlink and 50 Mbps uplink. Consider Cat 4 when the required transfer workload cannot be met by a validated Cat 1bis design.

Monthly data volume alone is insufficient. Define the largest upload, its completion deadline, concurrent traffic and recovery after interruption. For remote control, measure command-to-response time while connected and after waking or reconnecting. Category peak rates do not establish application latency.

Applicable Industries

LTE Cat 1bis can be evaluated for automotive and logistics, agriculture, retail, smart-city infrastructure, energy and utilities, healthcare, safety and security, and industrial monitoring. Suitability depends on the specific device requirements and selected module configuration.

Start with a short requirements brief. Record the payload size, reporting interval, firmware-download requirements, server-command response time, installation conditions and expected movement of the device. Include the available power source and target deployment countries.

Application selection priorities

Application labels alone are insufficient. A mains-powered meter and an inaccessible battery-powered meter can need different acceptance tests even when they report similar data.

Cavli LTE Cat 1bis Modules: C16QS, CQ16 and P16QS

Cavli’s LTE Cat 1bis portfolio includes C16QS, CQ16 and P16QS. All three specify 3GPP Release 14, with peak rates of 10 Mbps downlink and 5 Mbps uplink. Their differences in packaging, memory, positioning and peripheral features help define the shortlist for a particular device.

C16QS: LTE connectivity with optional positioning

The Cavli C16QS is an LTE Cat 1bis IoT module with optional GNSS and eSIM. Applications include healthcare, smart cities, energy and utilities, manufacturing, safety and security, and automotive and logistics.

 Cavli C16QS LTE Cat 1bis module. GNSS and eSIM availability depend on the selected configuration.

C16QS key highlights

• LGA and mPCIe form factors: LGA measures 26.5 × 22.5 × 2.8 mm; mPCIe measures 51.0 × 30.0 × 3.5 mm.
• 1.25 MB RAM and 4 MB ROM.
• Optional independent GNSS, terrestrial positioning service and Location-as-a-Service.
• USB 2.0, Wi-Fi scanning and power-saving modes.
• Optional eSIM and Cavli Hubble support.

Positioning and integration considerations

For location-reporting designs, define the required positioning workflow before selecting the configuration. Confirm antenna requirements, supported constellations, output interfaces and operating behavior with the product team. Test position acquisition and cellular upload together in the final enclosure.

Wi-Fi scanning should not be treated as a claim of Wi-Fi data connectivity. Likewise, optional independent GNSS does not establish a particular power-control implementation. Validate those requirements for the selected configuration.

Explore GNSS integration choices when planning the positioning architecture.

Explore C16QS and evaluation options.

CQ16: Compact integration with dual SIM support

CQ16 is a compact LTE Cat 1bis module with dual SIM support, DFOTA and an LGA package measuring 17.7 × 15.8 × 2.8 mm. Its applications include healthcare, smart cities, energy and utilities, manufacturing, safety and security, and automotive and logistics.

 Cavli CQ16 LTE Cat 1bis module.

CQ16 provides 1.25 MB RAM and 4 MB NOR flash, a USB 2.0 interface, terrestrial positioning service, Wi-Fi scanning and power-saving modes. It also supports Cavli Hubble.

For a compact connected product, assess the package dimensions alongside the SIM arrangement and host integration requirements. Confirm how dual SIM operation is implemented for the intended application; do not assume simultaneous connections or automatic failover. Terrestrial positioning and Wi-Fi scanning should not be interpreted as integrated GNSS or Wi-Fi data connectivity.

P16QS: A Cat 1bis System-on-Module

P16QS is a Cat 1bis System-on-Module with a 32-bit RISC-V processor at 325 MHz, an RTOS, Wi-Fi 6, BLE 5.4, an integrated secure element and DBI Type-C display support. Its target applications include POS systems, retail and payments, and low-cost vehicle telematics. GNSS and eSIM are optional.

 Cavli P16QS LTE Cat 1bis System-on-Module. GNSS and eSIM are optional.

P16QS provides 8 MB pSRAM, 16/32 MB flash, a USB 2.0 interface and power-saving modes in a 40.0 × 30.0 × 2.7 mm LGA package. It also supports Cavli Hubble.

For payment or display-based devices, map these capabilities to the application’s processing, memory and peripheral requirements. Confirm the implementation of the secure element and display interface before committing to the architecture; the presence of a feature does not establish an application-specific integration workflow.

Compare the integration requirements

Cavli Cat 1bis module comparison

All three specify the same peak cellular rates. Compare package size, memory, interfaces and selected options against the complete device requirements. Confirm features not listed here with Cavli; omission from this table should not be interpreted as proof that a feature is unavailable.

Check these configuration details when narrowing the shortlist:

• Regional support: CQ16 lists EU, NA, IN and AN band configurations. C16QS lists WW, EAJ, NA, LA, AN, IN and EU configurations. P16QS lists an IN configuration supporting B1/B3/B5/B8/B40/B41. Match the exact band list to the intended network and destination.
• Positioning and SIM: Confirm the full part number, required positioning functions and SIM arrangement before ordering. GNSS and eSIM are optional on C16QS and P16QS. For CQ16, confirm how its dual SIM and terrestrial positioning functions meet the application requirements.
• Qualification: Obtain current certification and approval documents for the exact part number and destination market. A family-level feature list does not establish approval for every configuration.
• Power measurements: All three modules list power-saving modes. Request operating-mode current figures and test conditions, then measure the complete reporting cycle before estimating battery life.
• Remote operations: All three support Cavli Hubble. CQ16 explicitly lists DFOTA as a module feature. Confirm the module-specific update workflow, package compatibility and recovery procedure for each selected configuration; platform-level FOTA/DFOTA support does not by itself define those details.

Review detailed specifications before requesting hardware: CQ16 brochure · C16QS brochure · P16QS brochure.

Find the right Cat 1bis configuration

Share your application, deployment countries, required interfaces and GNSS/eSIM needs. Discuss your shortlist with Cavli before committing to PCB layout.

Discuss module selection →

How to Select and Validate an LTE Cat 1bis Module

Match the deployment markets and connectivity service

A regional or worldwide label is a starting point. Select a module using its documented band list, the intended connectivity service and the qualification requirements for each destination.

Build a country-and-operator requirements matrix before selecting a part number:

Deployment requirements

Band support, network access and certification are separate checks. Confirm all three for the configuration being evaluated. Request the supporting documents for the intended target markets rather than relying on a family-level feature list.

For deployments using Cavli connectivity, review network coverage alongside the selected module’s bands, SIM profile and target-market requirements.

Why can a module register but fail to send data?

Network registration does not prove that the application can reach its server. Separate SIM detection, registration, data-session activation, name resolution, transport connection and application authentication in your logs.

If one SIM works and another fails, compare the provisioned access point name (APN), credentials, address-family settings and private-network routing requirements with the connectivity provider. Reproduce the test using the intended production SIM and endpoint. Record the failure stage before changing firmware or hardware.

If SMS or voice is required, confirm support for the exact firmware, service plan and destination network. Test those functions independently of packet-data connectivity, including the intended behavior on LTE-only service.

Check hardware fit and host integration

Compare the module’s dimensions, form factor, host interfaces, antenna connections and power-supply requirements against the complete device design. The smallest module footprint is only one part of the integration decision.

Footprint and form factor

Confirm the exact package dimensions and intended carrier or PCB arrangement. An LGA module and an mPCIe configuration require their own compatibility checks. Verify the RF layout, antenna arrangement and mechanical fit in the final enclosure before freezing the design.

Host interfaces and processing

List the interfaces required by the host and peripherals, then confirm the available functions for the selected firmware and configuration. Review the hardware guide, AT command documentation and SDK scope where applicable.

Shared interface names do not establish identical commands, application compatibility or interchangeable PCB designs. Likewise, a processor specification or SDK reference does not by itself establish that a module can replace the host microcontroller.

For a System-on-Module (SoM), assess processor, memory, operating system and peripheral support against the application architecture. If the device needs display support, Wi-Fi, Bluetooth or an integrated security function, verify each requirement explicitly.

For a compact LGA layout, compare CQ16’s 17.7 × 15.8 mm footprint with your PCB constraints. For an mPCIe-based design, review the C16QS form-factor options.

UART or USB: which interface should you use?

Choose using the host’s driver support, data workload, buffering and control requirements. A faster physical interface alone does not establish lower end-to-end latency. Benchmark the complete upload and response cycle.

For UART, confirm logic levels, baud rate, flow control, startup timing and port roles. For USB, request the supported interface classes and a tested host implementation. Verify that development-board routing, onboard controllers or multiplexers do not conflict with your external host connection.

Can PPP data, AT commands and GNSS share one interface?

Plan the control and data paths before PCB layout. An active Point-to-Point Protocol (PPP) session can require a separate path for AT commands and GNSS output. Ask whether the selected firmware supports separate ports or serial multiplexing, and test concurrent operation.

Serial multiplexing is optional; confirm that both the module firmware and host implementation support the required configuration. Confirm how control access is recovered after a dropped session.

What reduces the risk of a PCB respin?

Review the reference schematic, antenna placement, ground layout, SIM connections, reset and boot signals, and unused-pin requirements against the hardware guide. Confirm antenna matching and enclosure test requirements before release. Do not copy pull-resistor values or pin assumptions from an unrelated design.

Plan positioning and SIM provisioning

GNSS: test the position-and-upload workflow

For a location-reporting product, define the required accuracy, reporting interval and installation conditions before choosing a GNSS configuration.

Evaluate time to a usable fix, location availability in the intended environment, energy per report and behavior when a fix is unavailable. Review cellular and GNSS antenna arrangements together in the final enclosure.

Confirm supported constellations and positioning power-control options for the exact module variant. If independent cellular and GNSS power control is available, validate it against the reporting schedule.

Can GNSS keep reporting while cellular data is transmitted?

Confirm simultaneous-operation support for the selected variant and firmware. Test position acquisition and reporting with cellular transmission active, then compare against GNSS-only operation under the same conditions.

Distinguish “GNSS enabled” from a valid position fix. Verify the fitted GNSS option, antenna path, output port and command set. For frequent reports, measure fix availability, data age and energy per delivered location; do not infer performance from the presence of GNSS alone.

eSIM: confirm the configuration and service

Do not assume eSIM is included in every variant. Confirm the full part number, provisioning process, connectivity service and destination markets.

Ask what is included with the evaluation configuration and what requires a separate service arrangement. For devices that cross borders, test the intended profile and contracted network access along representative routes.

Does an embedded SIM guarantee remote profile switching?

Physical SIM packaging and remote profile management are separate selection questions. An eUICC supports secure profile management, but an OEM must also confirm the provisioning architecture, connectivity service and device integration. Confirm eUICC functionality separately from whether the SIM component is removable.

Request a demonstrated profile-download and activation workflow, including recovery when the intended profile cannot connect. Optional eSIM in a product description does not establish every provisioning feature or unrestricted operator switching.

C16QS and P16QS offer optional eSIM configurations. Review Cavli’s connectivity offering and confirm the provisioning workflow for the part number being evaluated.

Review firmware, security and remote operations

Software integration should be part of the selection process before the hardware architecture is frozen. Confirm:

• Required protocol functions, connection handling and error recovery.
• The host connection and communication rate needed by the application.
• Which peripheral functions require an SDK and what that SDK supports.
• How the device enters and leaves supported low-power states.
• The firmware-update procedure and recovery after an interrupted update.
• Device onboarding, monitoring and remote-diagnostic requirements.

If remote management is part of the deployment, evaluate the module and service configuration together. Explore Cavli Hubble for connectivity and module management, and Hubble Lens for remote access and debugging. Confirm the applicable functions and service arrangement for the selected module.

Define which functions belong to the module, the host application and the cloud platform. This is especially important when the product requires host-MCU firmware updates or application-specific diagnostics.

What should you verify about MQTT and HTTPS?

Confirm whether the protocol stack runs in the modem or host, then request a working example for the exact firmware and intended server. Test the largest payload, binary data where required, reconnect behavior and repeated transfers.

For MQTT, verify the required protocol version, quality of service (QoS), retained messages, keepalive and session behavior. Evaluate these functions individually. A general “MQTT support” claim does not establish which functions a module’s command interface exposes.

Why can HTTPS or MQTT over TLS fail when basic data works?

Successful packet data does not verify Transport Layer Security (TLS). Check the supported TLS configuration, trust chain, server hostname, device time and client credentials where mutual authentication is required. Certificate validation includes checking the validity period against the current time; verify time readiness before secure connections.

Compare the evaluation board and custom PCB using the same firmware, server, credentials and SIM profile. Preserve detailed logs and isolate the failing layer. Disabling certificate verification is not an acceptable production fix.

An integrated secure element also needs an integration review: confirm how the application or TLS stack accesses credentials. Do not assume a documented security component implies a particular key-storage or authentication workflow.

What happens if a firmware update is interrupted?

Ask for the supported update paths, package compatibility rules, integrity/authenticity checks and recovery procedure. For a delta update, confirm the required starting firmware version. Establish whether rollback is supported rather than assuming it.

Test interrupted downloads, interrupted installation and restart behavior using the supplier’s procedure. Separate modem updates from host-application updates. Retain a recovery method and test a small device group before expanding deployment.

Review Cavli Hubble FOTA/DFOTA when planning remote firmware management. Confirm update compatibility and recovery behavior for your selected module and firmware.

Validate with an evaluation kit

Use an evaluation kit to test the highest-risk requirements before committing to the production layout. Begin with the intended module variant, firmware and connectivity service.

Evaluation test plan

Define pass/fail limits before testing. An EVK result provides an integration baseline; repeat critical measurements with the production power supply, antenna, enclosure and host firmware.

What should you capture when a prototype fails?

Use a reproducible test record so the hardware, firmware and connectivity teams can investigate the same event.

Prototype troubleshooting evidence

Remove credentials and private keys before sharing logs. Include firmware and board revisions so a successful EVK test can be compared with the production prototype.

Move from shortlist to evaluation

Contact Cavli to confirm sample and evaluation options for CQ16, C16QS or P16QS. Include your preferred configuration, sample quantity and evaluation timeline.

Discuss samples and evaluation →

Compare total deployment cost and supplier support

A useful module-price comparison includes the engineering and operational costs associated with each option. Request a quote for the exact configuration and expected purchase volume.

Compare module and kit costs alongside antenna components, integration effort, qualification work, connectivity services, firmware maintenance and field-service requirements.

Ask the supplier to confirm lead time, ordering quantities, production availability, change-notification arrangements and support terms. Include the full part number, destination markets, sample quantity, forecast volume and planned production date in the request.

Which documents should an OEM request before committing?

Request the hardware guide, interface and AT-command documentation, firmware release notes, tested integration examples, update/recovery instructions and configuration-specific qualification evidence. Confirm how long the selected hardware and firmware will be supported and how changes are communicated.

For deployments with special environmental or hazardous-location requirements, obtain a review of the complete product and applicable evidence from the relevant specialists. Do not infer suitability from ordinary cellular approval or another customer’s application.

Conclusion

LTE Cat 1bis combines Cat 1 peak data rates with a single cellular receive path, providing an option for connected products that need practical LTE connectivity and manageable hardware integration. Selection should account for coverage, antenna performance, power, host integration and the intended operating workflow.

Cavli’s C16QS, CQ16 and P16QS provide different integration options within this category. Use the documented specifications to shortlist a configuration, then validate it with your application before committing to production.

Share your application, deployment countries and development stage with Cavli. Include host interfaces, GNSS/eSIM needs, expected volume and target production date where available.

Build your next connected product with Cavli

Discuss module selection, integration requirements and production planning with the Cavli team. Include your expected volume and target production date to help scope the next steps.

Discuss your Cat 1bis project →