After having defined the context, and presented a few generalities in our first article, let's now start thinking about architecture and implementation.

We have been talking about GPRS, TCP, frames, and liveliness. If we try to represent those various aspects of our protocol in a layer diagram, as it is usually the case with protocols, we get this, for the mobile side:

Liveliness operations are handled by the link layer. More generally, this layer ensures that frames being transmitted from one machine to another one on the same network are correctly delivered. Of course, on our case, we will rely on TCP for most of the usual tasks of the link layer.

Socket layer relies on the well-known socket interface to TCP.

We can note that this diagram is not so consistent, as TCP, used in the socket layer, implements its own link layer...

For the non-mobile side, the GPRS layer disappears from the diagram! 

Let's add to this diagram the communication paths between each layer and its neighbours :

Frame layer

We'll describe those communication paths in a detailed way later on. For now, let's concentrate on the frame layer. We saw that its main task was to to provide a way to exchange delimited sets of bytes between the two sides of the communication. This layer also needs to provide a transparency mechanism. Previous article rapidly explained how to provide such a capability. As it is trivial to implement this capability on the transmitting side, we won't spend anymore time on this part. The implementation for the receiving side being a little bit more complex, we provide here the state automaton that describes it:

In our diagram, a transition is represented as an horizontal dashed line. The condition that allows transition triggering is written above this dashed line. The action(s) to be performed at transition-time is/are listed below the dashed line.

Two additional operations should be added, when implementing the above automaton, that are not mentionned in the diagram, in order to keep it readable:

• an inter-byte timeout should be used: if the period between two received bytes (for the same frame) is greater than a given value, we consider we are in trouble, and go back to WaitDLE state;
  

• if we receive more data bytes than a given value while we are in WaitEndDLE state, we stop receiving current frame, and go to the initial state.

The inter-byte timeout is a configuration parameter.

The maximum number of data bytes that can be transported in a frame is another configuration parameter. Of course, same values should be chosen, for all entities that will have to communicate together. We could think at a negociation phase, during which those configuration values (and possibly some other ones) would be exchanged, and then agreed upon by all the entities. But for now, as we want to keep things simple, nothing more will be done about that.

GPRS layer

The GPRS layer is in charge of performing what is named a context activation. Once a context is activated, the communicating device can use the mobile network it is registered on, to send and receive data. It's easy to find more information about GPRS, so we won't say more here.

The generic state automaton provided below, that describes our GPRS layer, is quite simple. But one must keep in mind that it must be adapted to the communicating platform being used. For instance, activating a GPRS context in a Sierra Wireless module using Open AT environment is totally different from activating a GPRS context on the Maemo platform, or in Mobile Devices' MCT...

To be continued...