Aeris Device Approval

Certification requirements and best practices

Devices on the Aeris network, as well as the applications running on these devices, must operate in a manner consistent with the best practices outlined in this document. While a single or small number of misbehaving devices typically won’t impact other users, a large group of devices operating in a negative pattern consistently or at the same time may have a very adverse impact on network resources and therefore on other users. These best practices are put in place to ensure that devices act as “good citizens” on the Aeris network and don’t do anything which could affect the performance of the network or negatively impact other users.

1. Regulatory and legal compliance requirements

As between Aeris and its customers, it is the responsibility of the customer (or the device manufacturer) to ensure that its devices conform to regulatory requirements of the countries in which the device will spend the majority of its operational life and to acquire any necessary certifications required by the regulatory bodies in the host countries, such as EMC, radio emissions, SAR, FCC and other certifications. It is also the responsibility of the customer to ensure that its devices and applications comply with all applicable laws, including data privacy laws, advertising regulations (such as rules about cookies or “no-spam” laws), text-to-911 rules and the like.

2. Device and application operation best practices

All devices connecting to the Aeris network and all applications operating on those devices must comply with the following operational best practices. Each Aeris customer must ensure that subsequent revisions of its devices and applications continue to comply with these best practices.

Best practice 1 – Device network service connection attempt randomization.

When a device connects to the network to access a service (data, SMS, voice), the attempt timing must be randomized between devices of the same application. In other words, if there are 20,000 devices which need to call into their application server once a day, they should not do so exactly at the same time. The attempt timing should be randomized over a period which makes sense for the specific application.

Service access timing by the same application group of devices may also be randomized through implicit means. For example, if the trigger for the 20,000 devices to communicate with their application server is already random (i.e., when users start their cars), then these devices will meet this requirement. In this example, over a population of drivers, the time any specific car is started will statistically appear random, thereby meeting this requirement.

Best practice 2 – No zero byte packet sessions.

M2M applications should only establish data sessions for the purpose of sending and receiving data. An application which establishes a data session and then terminates the session without passing data (a “zero byte session”) on a regular basis is not in compliance with these best practices.

Best practice 3 – Device failed data service attempt retry mechanism randomization.

This requirement specifies how an M2M application is required to behave on the Aeris network when it cannot establish a packet data connection or fails to access its application server. Aeris does not specify a single universal data retry requirement because the data retry algorithm will depend on the specific application. For example, the appropriate data retry algorithm for devices controlling medical equipment or protecting property may be quite different from an appropriate algorithm for devices sending less critical information. However, the general principle which should be followed is that the application retry mechanism should exhibit a random back off.

If an M2M application fails to establish a packet data connection to the network or to its application server, then it must introduce a random back off timer before it attempts again. The purpose of this is to prevent a population of devices all attempting to establish a data connection at exactly the same time. The re-attempt should be randomized across the group of devices.

An example of where this can occur is if the customer’s application server fails. If multiple devices that need to communicate with that server make a repeat attempt to access data service at the same time, they may all be unsuccessful as the demand for resources may be exceeded, with the result that they then drop into a retry pattern with an effective self-created DOS. Randomizing the re-attempts across the device group can avoid this scenario and ensure an equitable availability of resources both to that customer’s devices as well as to all users of the Aeris network.

Best practice 4 – Device recovery.

The device must have a method of recovery in case of unexpected behavior, such as a firmware failure or similar event. An example of a recovery method is a watch dog timer that will reset the device when a condition is encountered where the device application no longer has control over the device.

Best practice 5 – Device support for PLMN/PRL updates.

The device must support the download of PRLs (CDMA) or PLMN lists (GSM/HSPA) and must not modify or overwrite PLMN lists or PRLs provided by Aeris.

Best practice 6 – Device graceful shutdown.

The device application firmware must adhere to the power-down procedures as specified by the radio module manufacturer. This ensures the device de-registers from the network when it powers down and clears resources.

Best Practice 7 – No spurious behavior.

Applications and devices should be engineered not to exhibit spurious behavior on the network. As an example, an application should not try to establish a data session on the network after a data session is already established.