The BiTXml communication protocol has been designed to implement a presentation level of the (OSI-based) communication stack reference, with the main goal to standardize the way commands and control information are exchanged for the specific target of M2M communication demands (i.e. communication with generic devices with or without processing power on board - like sensors, actuators, as well as air conditioning systems, lifts, .. - or a combination of them).

The current protocol specification defines

1.      The abstraction of a BiTXml gateway

2.      The abstraction of a BiTXml controller

3.      The syntax and the semantic of a set of values used to exchange data between two communicating parties

4.      The syntax and semantic of a set of primary commands used to drive the devices connected to the BiTXml controller

The protocol syntax will be meta-coded in Xml Schema language.

The protocol semantic will be defined in natural language (no formalization will be provided).

        General description

The architectural reference model underlying the BiTXml protocol is shown in Fig. 1.

Fig. 1 - Architectural reference model

The main parts of the reference model are:

1.      BiTXml controller: any kind of software application speaking the BiTXml language, working as the master (commanding) unit for one or more gateways

2.      Network transport: any kind of network transport layer

3.      BiTXml gateway: any kind of software application, speaking the BiTXml language, working as an 'intelligent' remote execution unit

4.      I/O ports: any kind of connection port enabling the control of whatever device connected. Actually dealt connection ports range through analog and digital GPIOs and serial ports.

5.      Devices: any kind of physical device connectable to the available I/O ports.

While no detail may be given for the BiTXml controller component, being it the side where applications or middleware solutions as well may take the role of master unit, an architectural model for the gateway may be shown (see Fig. 2):

Fig. 2 - Gateway reference model

The gateway is surrounded by the network layer (right side of the drawing) and the device/ports drivers at the other side.

The gateway may be split into two main logical parts:

·         synchronous processing

·         asynchronous processing

The synchronous processing allows the basic execution of BiTXml commands, returning the replies for each executed command.

The asynchronous processing involves one or more executing unit, each one accomplishing a well-defined function within the system.

Currently defined asynchronous units are:

·         DNS: a custom protocol interpreter, described in Appendix A, specifically designed to allow the handling of gateways having their network address dynamically assigned (such as GPRS-networked devices). Master units, querying the DNS server – which would become a mandatory part of the overall master system -, can retrieve the current network address of the gateways in real time, thus allowing easier programming of controller to gateways interactions.

While the complete implementation of both the synchronous and asynchronous parts of the system exploits the whole power of the gateway architecture, an important point to be highlighted is the optionality of the whole set of asynchronous processes.