1.5.2 How the AL Module Works

The AL (Modem App Layer) is the access point to the Meters And More Stack, if this module is used, which is a configuration option, as seen on Configuring The Meters And More Stack.

It provides the API to an application running on top of the Meters And More Stack.

First of all, module has to be initialized at System level by calling AL_Initialize Function to get an object identifier of the AL instance. As stated, this function is called at System level, and user does not need to take care of it.

The first step a user has to take when using AL is to set the callback functions to receive events from AL module, this is done be means of AL_DataIndicationCallbackRegister Function, AL_DataConfirmCallbackRegister Function and AL_EventIndicationCallbackRegister Function, which take pointers to such callback handlers as parameter.

Before using the AL module for data exchange, user has to ensure AL is ready (i.e. has finished its initialization duties). This is done by means of AL_GetStatus Function, which returns the internal Status of AL module. When Status is equal to SYS_STATUS_READY, module is ready to be used.

Data Transmission on Meters And More Network is done by means of the AL_DataRequest Function, which expects its parameters in form of a structure defined in AL_DATA_REQUEST_PARAMS Struct.

The result of requested transmission, is provided to upper layer by invoking AL_DATA_CONFIRM_CALLBACK Typedef. Parameters include the result of transmission, and others explained on AL_DATA_CONFIRM_PARAMS Struct.

Received frames are reported to upper layer by invoking AL_DATA_IND_CALLBACK Typedef, along with reception parameters contained in AL_DATA_IND_PARAMS Struct.

In case a frame cannot be delivered to final destination, due to a problem in the repetition path, the AL_EVENT_IND_CALLBACK Typedef is invoked by the AL, indicating the Address of the repeater in which the frame was lost (a timeout expired), or indicating that the timeout expired in the Master node itself. Note this Event Indication is only generated in Master Node, Slave Nodes do not report any event when a frame is lost.

The application layer on top of AL module must set and manage these callbacks in order to receive frames and to capture the result of transmitted ones.

Parameter Information Base (IB) is a set of parameters that can be accessed for reading and/or writing. They serve mainly 2 purposes: AL layer configuration through IB writing, and information retrieval through IB reading.

The reading and writing of parameters are made by means of AL_GetRequest Function and AL_SetRequest Function primitives respectively.

These functions are synchronous, in the sense that they return the result of the Get/Set operation, and the read value (in case of Get operation) in one of the function parameters itself.

A list of available parameters and their description is provided on AL_IB_ATTRIBUTE Enum definition.

AL State Machine is called periodically by System though the AL_Tasks Function. As it is called at System level, user does not need to take care of maintaining AL State Machine.

Every AL process is done inside this state machine (except for IB access which is synchronous). Request Primitives trigger State Machine changes, and then internal processes trigger in turn the callbacks to report different events to AL user.