11 Myths About Cellular Carrier Certification Requirements

We’ve seen a significant increase in the number of devices designed and manufactured for use on cellular networks. It’s only logical, though, given the demand for IoT solutions and the availability of cellular WANs across much of the nation. Carriers see the potential to connect millions and possibly even billions of IoT devices, and have created narrowband IoT channels such as CAT 1 LTE specifically for IoT and M2M communications.

Typically, product design teams focus on the functional requirements for the device, and many times create excellent products that meet internal specifications but can’t be sold commercially. In fact, a significant number of new cellular product designs fail initial carrier certification tests. Obviously, this results in rework and costly delays.

What’s needed is a more complete understanding of exact carrier requirements and an integration of those specific requirements from concept through product launch. This will help to ensure that new products have the right design to pass the required cellular compliance tests out of the gate.

Unfortunately, the details of what cellular carriers require in the design and manufacture of these products can change, and carriers insist on compliance before they allow devices on their networks. During the design phase and prior to manufacturing, OEMs, solution providers, and manufacturers themselves should not make any assumptions about what carriers may require in order to certify products for those networks. Furthermore, they should avoid some common misconceptions or myths about cellular carrier certification. 

The following are 11 common myths about cellular carrier certifications that should be avoided:

1. FCC testing is all that we need for the device.

The certification requirements for each carrier are very specific. Although they sometimes adhere to certain Federal Commuications Commission (FCC) requirements, they typically include specifications that are unique to each specific network.

2. We can worry about carrier requirements after FCC testing.

Carrier requirements don’t exist in a vacuum. They must be considered along with FCC testing requirements during the design/manufacture phase—failing to meet carrier requirements would prevent the product from being used on carrier networks. Also, if changes are made to the product after FCC testing in order to meet the carrier requirements, then some components of FCC testing may need to be repeated.

Some carriers require passing PCS Type Certification Review Board (PTCRB) testing before products can pass certification. A few PTCRB tests differ from FCC testing, including relative sensitivity intermediate channels (RSIC) and SIM card interface testing.

Carriers also have limits for over-the-air (OTA) testing that include total radiated power (TRP) and total isotropic sensitivity (TIS). These tests aren’t part of FCC testing.

3. Our device already has FCC certification, so we can add cellular capability without any issues.

FCC certification doesn’t guarantee carrier certification. Some of the things carrier certifications focus on aren’t covered by FCC certification, including RSIC and TIS levels.

4. We don’t need to go through PTCRB certification because we’re using a PTCRB-certified module.

Modules can be PTCRB-certified. When a device integrates such a module, the device will still be required to go through PTCRB testing. The process will test the interfaces that changed between the approval of the module and the device under test (DUT). These typically include the SIM card, power-supply, and antenna (OTA) interfaces. PTCRB testing for products that contain pre-certified modules includes RSIC and radiated spurious emissions (RSE).

5. If our antenna is designed well, we will not have any issues with carrier certification.

Antenna performance is only one part of the puzzle. Outside of the antenna design, the majority of certification failures are due to sensitivity issues. Noise within the product can negatively impact the sensitivity levels of the cellular module and lead to certification failures. A well-designed antenna will not solve this noise issue.

6. As long as we follow the module reference design, we will have low risk of failing certification.

Following the reference design will help with certification, but doesn’t necessarily eliminate the risk of failing certification. The surrounding circuity will affect the performance of the module. Noise from power supplies, cables, or LCD screens has been shown to produce noise in the cellular band that will impact sensitivity levels and lead to certification failures.

7. We can combine a cellular radio with a different radio without any issues.

When a design incorporates multiple radios (e.g., cellular, Wi-Fi, Bluetooth, etc.) and antennas are located within 20 cm of each other, the product is classified as having co-located radios. Once the antennas are within 20 cm of each other, this usually will violate the FCC grant of the modules. Most grants state that the module can’t be placed within 20 cm of another transmitter. Extra testing will need to be performed for this co-located product.

8. Since we used this module on another product, we don’t need to have certification testing done on our new device.

Each time a module is integrated into a product, it must go through certification testing. The level of testing will depend on whether the product is new or a variant of an existing one. A product variant could have the level of testing reduced depending on what has changed.

9. Firmware design considerations are secondary in importance.

Not true. Firmware must support certain important carrier requirements before the product can be used on those networks. Among the more important considerations is that the application/device allows test technicians to directly access the command channel for the cellular module so that they can enter test commands.

10.Data-retry requirements aren’t a high priority.

Carriers require that all data devices follow some common, standard, and logical method in their data-retry scheme under varied network conditions. The Data Retry test suite is one of the most commonly failed tests. Therefore, it’s important that this area be thoroughly tested and the correct operation be verified before submitting for certification with the carriers.

11. Our device is certified on one carrier, so we’re good to get onto any carrier network.

Each carrier is unique and will have a different set of requirements to meet before the product is allowed on their network. Some carriers care primarily about PTCRB certification and less about factors such as TIS; some require additional testing for Long Term Evolution (LTE) networks; some rely on FCC compliance for RSE testing and others don’t go that route. It’s critical that designers and engineers are aware of the most up-to-date information on each carrier’s requirements.

Conclusion

The effort to meet cellular carrier requirements is often overlooked in project plans. As a result, cellular compliance often trips up designers at the last minute, and it’s not uncommon to see a high number of first-test failures. Module, antenna selection, and EMI control are the key hardware design functions supporting compliance success for cellular-enabled M2M devices. On the firmware side, manual cellular module control for testing, firmware update support, data connection retry fallback, and over-the-air provisioning support are the critical functions supporting compliance with carrier certifications.

Few organizations are expert in managing carrier requirements for products to be used on cellular networks. Given the risks and costs of having a product fail certification, it may be prudent to work with a specialist to help ensure compliance with carrier requirements from the design phase all the way through to product launch.

Such a partner should have developed a proven methodology to ensure that a product will pass the required FCC and carrier certifications, and offer clients a state-of-the-art RF lab as well as a dedicated team of cellular engineers and a library of proven IP. An example of that kind of partner is Digi Wireless Design Services, which is involved in architecting, designing, building, and bringing IoT devices to market.