Handling Connection Errors

This chapter discusses retries in the context of communication transaction retries, where a transaction is an individual or group of requests to one specific device. For example, a Dynamic Logic download request with several parameter write requests would in this context be considered as a transaction. The retries described here should not be confused with individual protocol or modem AT command retries (i.e. where the driver does not receive a response to a specific command within a timeout period).

From a high-level application perspective, there are three categories of error when attempting to perform communication transactions:

• Channel allocation/set-up failures - Errors occurring when attempting to allocate a channel resource or when communicating with a channel resource.

• Connection establishment failures - Errors occurring when using a channel to attempt to establish a modem connection.

• Protocol command failures - Errors occurring when sending protocol specific commands to a connected outstation.

The first category relates specifically to modem or channel errors. These cover problems where a modem cannot be allocated (e.g. all outbound modems currently in use), where a modem does not respond as expected to a specific AT command (e.g. an “ERROR” type response), where TCP problems prevent communication with a TCP port used by a particular channel, and where the modem reports specific types of error which prevent a dial from being attempted (e.g. “NO DIALTONE”, “BLACKLIST” etc). All these types of issue are handled internally by the Channel Manager and a retry performed on the next available modem. When a modem fault is detected, the Channel Manager raises a specific fault condition against the modem and increments the error count for the modem. No fault or error increment is recorded for the outstation device.

The second category of error is detected by the Channel Manager when attempting to dial a device. However, these faults are caused by a failed connection to the device and are not specific to the modem resource. These faults include timeouts whilst waiting for a solicited connection and specific connection failure responses from the modem when performing an ATD command (e.g. “NO ANSWER”, “BUSY”, “NO CARRIER”). In all cases a dial out attempt has been performed by the Channel Manager and the connection attempt has failed. For these errors the Channel Manager does NOT attempt to retry as this would contravene the systems compliance to BABT standards. Instead, the Channel Manager passes a specific error code back to the driver. The driver records the error against the device and increment the error count for the outstation. No error is recorded against the modem device used to attempt the outbound connection. The application interface to the driver has sufficient error codes to allow the application layer to determine the cause of the fault. The application layer is then responsible for scheduling of the next retry attempt after some back-off period. The application layer will make a further communications request to the driver at a future point in time ensuring that the system remains compliant to BABT rules.

The third category of error is detected by the driver after a successful connection to an outstation. These errors include protocol communication failures such as repeated command timeouts, malformed packets, non-responsive outstation devices etc. In all cases the driver must record the error against the device and not the modem used to perform the connection. Similarly, the driver does NOT automatically retry the action as the retry algorithm must conform to a recognised BABT call pattern. The application interface to the driver has sufficient error codes to allow the application layer to determine the cause of the fault. The application layer is then responsible for scheduling of the next retry attempt after some back-off period.

 (*) When the Channel Manager performs a retry request due to a channel allocation failure, then the retry is performed on the next available modem in the list of modems. For example, if there are three modems and allocation failed on modem 1, and modem 2 is available, the allocation is retried on modem 2.

(**) When the application layer requests a retry the command is tried on the next available modem.

(***) An exception to this mechanism is the command retries that are executed by the driver in case of a command timeout. In this case the retries are executed automatically.