1. Aeris
  2. Reference
  3. Device and Application Certification

 

Device and Application Operation Requirements

Avatar
Aeris Admin

All devices connecting to the Aeris network and all applications operating on those devices must comply with the following operational requirements, explained more fully below. Each Aeris customer must ensure that subsequent revisions of its devices and applications continue to comply with these requirements. This will ensure smooth device and application operations for customers in addition to avoiding device behaviours disruptive to the network.

In this article:

Randomization of Network Connection Attempt

Initial Connection Attempt

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. This helps to avoid signalling storms that can degrade network performance hence impacting services to all devices including yours. 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.

Connection Retry after Data Service Failure

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.

No Persistent Sessions without Data

Note: this requirement does not apply to LTE-M devices using PSM (Power Saving Mode). LTE-M devices using specific APNs for this purpose can remain registered while going to sleep (PSM) mode. 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 this requirement, since they occupy costly network resources, without utilizing it for transferring any data. To avoid Zero Byte Packet Sessions:

  • The device SW should only create PDP context (in GSM) or register (in LTE) when there's data to transfer, and should delete the PDP context (in GSM) or deregister (in LTE) immediately after the data transfer is done. Proper clean-up of the data session after data transfer also reduces the possibility of "hung" data session at the next data transfer. Note: in LTE, registration includes data session creation at the same time, while in GSM, they are done in 2 steps.
  • In the event that the network tears down the GSM PDP context/LTE registration, either automatically (after a max timer value has been reached) or because of a network incidence, unless the device is in the middle of passing data, the device SW should not automatically re-establish the PDP context/LTE registration and should wait till the next time it has data to transfer to do so.

Device Network Mode Setting According to Services Allowed by the Service Profile

This requirement is so that the device does not generate excessive and costly signalling traffic for a service that it will never use. It also protects the device against a total registration failure when there is network issue on the side of the network that does not concern it. The device setting allows to set a device to PS (Packet-switched), CS (Circuit-switched) or PS+CS modes.

3G/2G devices:

  • If the Service Profile allows the device to use both data and SMS/voice, the device SW should set it to PS+CS mode
  • If the Service Profile allows the device to use only data, the device SW should set it to PS-only mode.
  • If the Service Profile allows the device to use only SMS or voice, the device SW should set it to CS-only mode.

4G devices capable of 3G/2G:

  • If the Service Profile allows the device to use only data, the device SW should set it to PS-only mode.
  • If the Service Profile allows the device to use data and/or SMS/voice, the device SW should set it to PS+CS mode.

4G devices not capable of 3G/2G (e.g. LTE-M-only or NB-IoT-only devices): should be set to PS-only device mode.

Handling of Network Purge

 A device may be purged by the network if this latter does not hear from the device after a long duration. This duration varies per carrier. Some carriers use a fixed value for the purge timer (commonly 24 hours). Others purge devices (that have not been heard for a while) at a fixed time per day. The network may not hear from the device in unexpected error cases (antenna issue, coverage issue, device software bug, etc.). The network does not inform the device when the purge happens (since the network does not hear from the device, it cannot contact the device to notify of the purge). For this reason, the device software should not assume when it is ready to do data that its previous registration and/or data connectivity is always still there. The device may have been purged by the network in between the previous data session and now. Checking the registration and PDP context/PDN connectivity (e.g. via AT commands) after some time has lapsed may also give inaccurate result, since the network may have purged the device and the device does not even know about it (AT command only returns information local to the device). In order to avoid and handle network purges:

  • The device SW should always delete the PDP context (3G) / deregister (4G) after sending data and re-create the PDP context (3G) / re-register (4G) the next time it needs to send data. This way, there is no confusion as to whether a PDP context/PDN connectivity is still there or not before sending data. This is the best way to avoid getting into a purge situation.
  • If the device SW does not delete the PDP context (3G) / deregister (4G) after sending data, the next time it transfers data, it must do so and recreate PDP context (3G) / re-register (4G), before transferring data. Failure to implement such clean-up before transferring data can result in devices being stuck in a failure loop (data transfer ➜ failure ➜ retry ➜ data transfer ➜ failure ➜ retry ➜ etc.). This situation is not only an issue for the customer to achieve successful service, it also creates signalling storms to the network.

No Simultaneous Data Sessions from the Same Device to the Same Server

Applications and devices should be engineered not to exhibit spurious behaviour on the network. This will result in network issues impacting the services, and waste scarce network resources. An application should not try to establish a data session on the network after a data session is already established. This means there should not be multiple PDP contexts (in GSM) or multiple PDN connections (in LTE) for a device using the same APN. In GSM, a device should check before activating a PDP context that no PDP context already exists. In LTE, a device should not repeat PDN connectivity requests using the same APN while the previous session is still active.

Device Self-Recovery

The device must have a method of self-recovery in case of unexpected failures, such as a firmware failure or similar event that prevents the device from communicating to the customer application server after many retry attempts over an extended period. This self-recovery mechanism helps the device to get out of this failure loop, allows the customer application server to re-establish contact with the device, and also avoid excessive and costly signalling traffic spam for the network. An example of a recovery method is a watch dog timer that will reset the device when an error condition is encountered where the customer application server has lost contact with the device.

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.

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.

Have more questions? Submit a request

0 Comments

Article is closed for comments.