Open Access

Pervasive multimedia guidance system for special needs passengers on public transport

  • Carmelo R García1Email author,
  • Ricardo Pérez1,
  • Alexis Quesada-Arencibia1,
  • Francisco Alayón1 and
  • Gabino Padrón1
EURASIP Journal on Wireless Communications and Networking20122012:90

DOI: 10.1186/1687-1499-2012-90

Received: 15 July 2011

Accepted: 6 March 2012

Published: 6 March 2012


This article presents a practical case of a pervasive multimedia guidance system for public transport passengers. In order to provide useful information to passengers, the system is capable of operating and adapting spontaneously to the different parts of a public transport network, using local data communication technologies. The multimedia data provided by the system are highly accessible, and adapt to the passengers' preferences, and are consequently suitable for special needs passengers. To this end, a paradigm of pervasive computing has been applied.


pervasive system intelligent transport system multimedia guidance system

1. Introduction

In the context of public transport, all the agents involved (citizens, operators and authorities) agree that it is very important to be able to access appropriate information. In the case of public transport users, appropriate information means coherent, useful information that facilitates access to the means of transport in question. These requirements become even more relevant when the transport user is a person with special needs. In this article, we describe a public transport passenger pervasive guidance system that has specifically been conceived for this type of passenger (the blind and the deaf). The system provides passengers with information that ensures that they are oriented throughout their trip, notifying them of any events occurring in the vehicle that could affect their itinerary or that may be of interest (points of specific relevance, arrival at destination, unforeseen incidents, etc.). For this reason, the system can be used to help visiting tourists. Currently, three interface types have been developed: one for the blind, one for the deaf and one for tourists. Using these interfaces, vehicle route information is provided by means of audio messages, graphic messages accompanied by terminal vibration or text messages in different languages. The architecture of the system is inspired by a pervasive computer model and its most relevant properties are thus: its distributed nature, its high level of accessibility, scalability and interoperability. Another differentiating property of the system is that it uses local communication infrastructure.

This article is laid out in seven sections. In order to contextualise the system presented, Section 2 presents a review of the literature and related studies. Section 3 describes the objectives and requirements of the system's design, underlining the need for a distributed architecture and the use of local communications. The main models and technologies used in its implementation are explained in Section 4, where we can see that a ubiquitous computing model is used, with Bluetooth communication and Java technology. Section 5 describes the distributed architecture, how its main elements work and how they are deployed in the transport network. An analysis of how the system works and of aspects regarding the system's performance appear is given in Section 6. The last section explains the main conclusions of this study.

2. Related study

Much has been written on the subject of passenger assistance information systems, given the relevance of this subject in transport systems. This literature can be classified into three groups. The first is made up of those contributions that describe the requirements demanded of information used by these types of systems, based on the different typologies of travellers. The second group includes specific cases of these types of systems. Finally, the third group comprises work describing the potential that intelligent transport systems offer for the development of systems of this kind.

In the first group, we would underline the work of Stradling [1], who analyses the effects of information on the psychology of the traveller and the consequences that arise when this information is inappropriate. These consequences can be summarised as follows: firstly, uncertainty and concern, which involve affective effort; secondly, the need to use an alternative option, which involves mental effort, and thirdly, the need to execute said alternative option, involving physical effort. For special needs passengers, these consequences and subsequent efforts required constitute an obstacle to the use of public transport. In the specific context of users of public road transport, Waara [2] analyses the information needs to the elderly when using intercity public transport, identifying the needs involved and valuing the importance of these needs for this group of travellers.

In the literature available relating to the second group, we would highlight the multi-modal transport system service for the blind proposed by Turunen et al. [3]. This system allows a blind person to plan his/her journey in real time in an intermodal transport network, using a mobile device Personal Device Assistant (PDA)and mobile telephone, which connects to an information service by means of mobile telephone operators. Sánchez and Oyarzún [4] also posit a proposal for the blind, consisting of a system that provides information from the public transport system in Santiago, Chile. This system allows a blind person to plan his/her journey and facilitates access to a public transport bus network by means of an assistant executed in a PDA, using information that has to have been downloaded beforehand from a central repository. Barbeau et al. [5] propose a system for special needs passengers that include a Global Positioning System (GPS) mobile terminal, enabling the system to provide information in real time for a journey that has been planned in advance. In these systems, the customer applications are executed in the users' mobile terminal and the information is obtained from a remote server using communications' operators' infrastructure. Finally, we also came across systems that have been developed by transport authorities or bodies in order to help plan journeys in metropolitan land-based transport networks for ordinary passengers (i.e. not contemplated for special needs passengers). These systems use a centralised architecture and information is accessed by Web or mobile telephone services. For example, the iBus project [6] developed in London by Transport for London provides information on the situation of the buses and the estimated arrival time at bus stops in real time. Helsinki's city travel planner [7] and Stockholm's planner [8] are two cases of information systems that operate in real time and by means of a Web service, generating information as to the location of buses and trains.

Finally, in the third group, we would point to Mitchell's work [9], which describes the potential of intelligent transport systems for the improvement in the accessibility of transport means for the disabled. In this study, the main problems identified by the author are the following: not being able to identify the service required or recognise the destination stop and not knowing how much the journey costs. In order to solve or at least mitigate these problems, the author proposes the use of information and communication technology. Giannopoulos [10] analyses how the use of information and communication technology can be used to develop systems that offer passenger information adapted to the different operational areas and different typologies of passengers. The author examines the possibilities offered by the application of information and communication technology in the field of transport, identifying a number of key applications, including guidance systems.

Lastly, Jakubauskas [11] identifies the main obstacles that hinder accessibility to public transport for people with reduced mobility, describing how to overcome them using intelligent transport systems. This author concludes that, in order to travel safely, comfortably and independently, the traveller requires a set of abilities and skills in the use of public transport networks information, and this conclusion becomes even more relevant in the case of special needs passengers. He therefore proposes the use of intelligent transport systems.

3. Objectives and requirements of the system

The objective of the pervasive system developed is to provide passengers with information that enables them to access and use the public road transport system. To this end, it must be coherent, accessible and adapted to the specific needs of the different types of users. Moreover, in order to interact naturally with the passengers, the system must be able to operate autonomously and spontaneously at different points within the transport network. Based on these basic information requirements, the functionalities and properties required of the system take shape.

To ensure that the information is coherent, it must correctly represent the planned services (e.g. routes and timetables) and, moreover, be updated in order to reflect any changes (e.g. cancelled services, delays, changes in routes, etc.) that may occur in the services as a result of unforeseen incidents in the transport network (congestion, vehicle breakdowns, roadblocks, etc.). In transport, the vehicle information systems tend to be the first to have updated information representing the routes in question, and they can provide this information to the passengers' information services. Thus, the first two characteristics of the architecture emerge: it is distributed and works in real time. It is distributed, because the data are distributed in mobile repositories located in the vehicles; and works in real time, because these data represent the updated situation of the route taken by the vehicle.

In terms of the accessibility of the information, firstly, the information must be available at any point along the route taken by the passenger. The system's distributed architecture mentioned in the previous paragraph makes it easier to fulfil this accessibility requisite. Secondly, there should be no physical or technological barrier that prevents access to that information. In order to fulfil these requirements, an architecture that can operate in mobility contexts, adapt autonomously to different environments and handle the very heterogeneous variety of devices used by the passengers to access the information, is needed. Consequently, a pervasive multi-agent system architecture has been developed.

The need for a multimedia system arises from the need to adapt the communication channel to the passengers, depending on their needs. For example, blind people need sound messages; the deaf, graphic messages and vibration of the terminal and, lastly, a combination of graphic and sound messages are used for the elderly.

Finally, in order to make this service available to users (passengers and public transport operators) free of charge, local data communications technologies are used, particularly IEEE 802.15.1 (hereinafter Bluetooth) and IEEE 802.11b (hereinafter WIFI). This requirement can be dealt with thanks to the system's distributed architecture. Although this technology is well known and widely used, its use in the field of public transport information services operating in mobility contexts is new, as these types of systems in this context tend to use infrastructures belonging to mobile telephone operators. The combined intelligent use of various communication infrastructures (WIFI and Bluetooth) by the system is another of its contributions. This intelligent use consists of the fact that the system can spontaneously detect the availability of each of these infrastructures to carry out the communication and use applications transparently, as generic communication channels are used. This property of the intelligent use of different communication infrastructures, enabling spontaneity and transparency, is one of the specific objectives of ubiquitous environments as Weiser [12], the creator of the paradigm of ubiquitous computing, has indicated.

4. Technological reasoning

The paradigm of pervasive computing brings together the models of mobile, distributed and ubiquitous computing under a single umbrella. Pervasive computing is based on pervasive systems, which are mobile systems that function in a distributed fashion and which also have the capacity to integrate autonomously into environments or frameworks thanks to the use of devices that can perceive the surrounding environment. According to Saha and Ukherjee [13], the structure of a pervasive computing system is made up of pervasive devices, the pervasive networks, the pervasive middleware and applications. In the guidance system architecture, the pervasive devices are the passengers' mobile telephones and the pervasive network is provided by the transport network's communications infrastructure. More specifically, local communications technologies like Bluetooth and WIFI are used. The middleware forms part of the transport network infrastructure and thanks to this, the data needed to provide the en route information services are made available. Finally, with the guidance system, the pervasive applications are those that produce and permit access to the information services, one of its objectives being to facilitate the development of this software. These applications can be characterised basically by their capacity to integrate the physical and technological environment around them, and as a consequence of this integration, they can operate autonomously and spontaneously in different environments. To attain these functionalities, the software of the system accepts the principles that characterise pervasive system software [14]. The first of these principles is the boundary principle; this principle establishes that the distinction between environments in pervasive frameworks must be made by boundaries that mark differences in contents and these boundaries need not necessarily limit the interoperability of the systems. The second of these principles is the principle of volatility; this principle establishes that pervasive systems must accept that the number of users, devices and applications intervening in a pervasive environment is unpredictable. For this reason, a set of invariable operating prin-ciples governing the running of the system must be specified. As a consequence of these characteristics, the system architecture is deployed in two areas, the first of which is the area of infrastructure provided by the public transport system. Here, a basic set of components is run, comprising all those elements that tend to allow user applications to access transport-related information. It is in this area that the invariable operating principles are established. The second is the area of user devices, made up of the components that have the capacity to become integrated in the different environments and facilitate access to the information produced by the different system information services.

The guidance system uses Bluetooth technology for local communications with the passengers' devices, the information being exchanged between two Bluetooth units through a set of slots that form a data packet. Each device has a unique 48-bit address, based on the IEEE 802.11 standard for WLAN (Wireless Local Area Network). Two or more Bluetooth units sharing a single channel form a Bluetooth network called a piconet. Up to eight users or devices can form a piconet and up to ten piconets can co-exist in a single service area. The equipment that shares a single channel can only use part of its capacity. Although the channels have a bandwidth of 1 Mbit, the more users join the network, the more capacity is reduced, approximately 10 kbit/s. To solve this problem, a solution was adopted that gave rise to the concept of a scatternet. The units in the same service radius can potentially establish communication between one another. However, only those units that really want to share information share a single channel, thus creating a piconet. This makes it possible to create several piconets in overlapping service areas. A group of piconets is called a scatternet. In the case of connections using Bluetooth, there is a slave device that has to select the communications protocol to be used and then put itself on hold while awaiting incoming connections, which it will accept, whereby the data will be transferred. In the case of outgoing connections, the master device, which is the one that initiates the connection and whose role can be exchanged at any time, has to search for devices within range. Once a device is found, it checks to see whether the device in question offers the service needed and if it does, it selects the device and initiates the connection and the information is exchanged.

In the system, the applications that the passengers run on their mobile devices are developed in Java 2 Micro Edition (J2ME). This version of Java concentrates on applying Java technology in electronic devices with highly reduced computing and graphic capacities, such as mobile phones, PDAs or smart household appliances. There are two set-ups defined in J2ME: Connected Limited Device Configuration (CLDC) for devices with processing and memory restrictions, and Connected Device Configuration (CDC) for devices with greater resources. A given J2ME run environment is composed of the selection of a kernel-based virtual machine (KVM), a configuration and a profile. KVM is the smallest Java virtual machine developed by Sun Systems. KVM is written in C language, approximately 24,000 lines of code, and it was designed to be modular, highly portable and small, with a memory charge of between 40 and 80 kb, depending on the platforms and the compilation options. CLDC is the configuration used by the system for the passenger applications. Some examples of these devices are mobile phones, pagers, PDAs, personal organisers, etc. The devices that use CLDC, for example mobile phones and PDAs, must meet certain requisites: having between 160 and 512 kb of total memory available, a 16 or 32-bit processor with a speed of at least 25 MHz, offering low consumption and having a connection to some kind of network, normally a wireless connection. The CLDC provides the devices with the following functionalities: KVM, a sub-set of the core's Java libraries as well as the Java language and all the restrictions of its machine, support for basic input/output, access to networks and security. Finally, the Mobile Information Device Profile (MIDP) establishes the capacities of the device, and therefore specifies the APIs related to the application (MIDP application semantics and control), user interface, persistent storage, working on line and timers.

5. Description of the architecture

This section presents the main aspects of the system's architecture. It is based on multi-agent, pervasive computer paradigms in order to provide a system that can operate autonomously in conditions of mobility and in heterogeneous environments. In our context, heterogeneity means the capacity spontaneously to offer the user information services thanks to different data models, different mobile communications and a wide range of mobile user devices (mobile phones, PDAs, laptops, etc.) The main architectural entities developed are the user (passenger using the public transport network); the user terminal (any device used to access the guidance service); the vehicle (bus); the Guidance Service Customer Agent (GSCA), which is a multimedia agent executed in the user's terminal; the Guidance Service Provider Agent (GSPA), which obtains data from the vehicle's infrastructure and provides them to the customer agent and the Guidance Service Discovery Agent (GSDA), which discovers guidance services and facilitates the connection among customer agents and provider agents. Figure 1 shows a general vision of the system.
Figure 1

General vision of the system.

As we can see in Figure 1, the GSPAs are only installed in the vehicles as these agents only give information to those passengers on board. The architecture currently just contemplates one piconet in each vehicle, and consequently a GSPA installed in a vehicle could be connected to a maximum of eight GSCAs at the same time, with a reception radius of 10 m. If a larger radius were required, given vehicles that are longer than 10 m, or if more simultaneous connections were required, a scatternet would have to be installed in the vehicles. The passengers at any given stop will know which GSPAs are available; thanks to the information provided by the GSDA installed at the stop. Thanks to this information, the GSCAs located at each stop do not have to carry out time-consuming searches for the GSPAs available at each stop. With this information, the connections between the GSACs and GSPAs located at a stop take place immediately. Another type of useful information at the stops, the estimated time of arrival of the vehicles, is provided; thanks to the use of different elements: information panels, acoustic signals and audio messages. These elements are normally available at the transport network's stops and stations.

Functionally speaking, the architecture has a four-level layered structure (see Figure 2). The first level, known as the Infrastructure Level, provides the basic communication resources between the agents. These resources allow for the use of two mobile local communication technologies: WIFI and Bluetooth. Physically, this level is deployed in the elements of the transport network: vehicles, stations and stops, and at this level, it is the service discovery agents that are executed. The second level, known as the Service Layer, provides the guidance information, in this case proffered by the guidance service provision agents. These agents are executed in the computer platforms installed in the vehicles. The third level, known as the Control Layer, manages the whole data exchange between the agents executed in the different layers. Lastly, the fourth layer, known as the Customer Service Layer, provides the methods and services that facilitate data exchange between the customer agents and other agents in the system (guidance service providers and guidance service discovery agents) and the multimedia presentation of the information.
Figure 2

System architecture.

One important characteristic of efficient transport systems is the high level of interoperability of their various constituent elements. In the case of information systems, interoperability means their capacity to integrate with other systems belonging to transport companies that operate in the same transport network, and could even be based on technological products made by different manufacturers. In the case of the system presented here, the objective of interoperability is achieved by using ontology of entities based on a conceptual model of common data for the whole system. This data model is a European specification known as Transmodel [15], which establishes the different data entities to be used to develop information systems that intervene in different parts of public passenger transport activity, namely, service planning, resource availability, operations monitoring and follow-up, passenger information, data gathering and management. Our system uses passenger information specifications together with the monitoring and follow-up of operations.

Communication between the agents is carried out using the resources contributed by the system's middleware. These resources are communication channels that are independent from the communication technology used (Bluetooth or WIFI), primitives for the sending and receiving data and a representation outline of contexts based on the conceptual data model mentioned in the previous section. Using the primitives to send and receive data, a guidance service provision agent controls the execution of a customer agent of the service using a repertoire of commands. Figure 3 illustrates the main flows of data communication executed between agents, describing the communication technologies and the protocols used. Bluetooth technology with Logical Link Control and Adaptation Protocol (L2CAP) is used for data communication with the GSCA. This protocol is used for two reasons; the first is because the packets of data exchanged are small and the second is because the data communication responds to one-off events, and thus does not need to be permanently connected.
Figure 3

General communication scheme.

Communication between elements that form part of the same application, such as the threads that make up a guidance service provider agent or a customer agent of the service are carried out using the classic blackboard model consisting of a shared memory space in which the representation outline contributed by the middleware is built.

5.1. Guidance service discovery agents

Agents of this type are executed both in mobile platforms located in vehicles and on non-mobile platforms found in the public transport network (stations or bus stops). The mission of this type of agent is to publish the available GSPA that can be accessed by the customer agents executed in the users' devices. Whenever they discover a GSPA, they obtain the necessary parameters to connect to the service and offer them to GSCAs, which can then connect to them. Therefore, this type of agent acts as an access point between GSPA agents and GSCA. There are two reasons that justify the need for this type of agent. Firstly, it avoids the possibility of GSCAs executing a service search process, which would be slow given the limitations of the users' devices and the Bluetooth communication infrastructure. In the system, a GSCA connects directly to the GSDA, which provides the connection address of the specific service provider required and then proceeds to connect them. Secondly, each GSPA is identified by means of its connection address to the platform in which said agent is executed; this address is exclusive to each provider and is established by the platform manufacturer. Thus, it is not necessary to generate and manage new identifiers of service providers, and this makes the scalability of the system easier.

During the execution of a GSDA, two main tasks are carried out. The first consists of providing GSCAs with data that allow them to connect to a GSPA, using Bluetooth infrastructure for this purpose. The second consists of discovering the available GSPAs executed in vehicles. The GSDA is internally implemented as cooperative multi-threading applications, which allow the system to deal with concurrent requests for the services offered, thereby contributing to the overall requirement that the system be highly accessible while also offering response times in line with those expected of a real-time system. For this reason, this design philosophy is extended to all the system's modules. Each one of these tasks is executed by a thread that cooperates with the other threads making up the agent.

5.2. Guidance service provider agents

Agents of this type are executed in the computer platforms installed in vehicles. They are responsible for providing the data required by the GSCA. This data are obtained using the resources provided by the infrastructure available in the vehicle, specifically the following: data relating to the vehicle's position, the state of the vehicle (in use or out of use) and data describing the vehicle's journey (geographical coordinates of stops, names of stops, order in which the stops are passed, etc.). Figure 4 illustrates the main components of the infrastructure provided by the public transport company's buses where the system has been tested. The different components are connected to the on-board computer using a star topology, using several serial data communications interfaces, such as RS232, RS485 or CAN-bus (Controller-Area Network) to connect to the different on board devices.
Figure 4

Main functional components of the vehicle infrastructure.

All these data are obtained by WIFI communications using UDP (User Datagram Protocol) connections. This service does not require much interaction with the vehicle infrastructure; a set of commands exists that allows the vehicle infrastructure to control GSPA execution. Table 1 shows the structure of the data packet used to send these commands.
Table 1

Structure of the data packet used by the infrastructure to send commands to GSPA

Field name

Length (bytes)




Frame start: fixed value 0 × FF





0 × 01: Infrastructure out of service


0 × 02: The system tries to recover from a failed state


0 × 03: The vehicle is not in service


0 × 04: Start of a route


0 × 05: Route point description


0 × 06: The vehicle is in a bus stop


0 × 07: The vehicle is in a state of operative pause


0 × 08: Infrastructure halt



Length of the following field (DT field)



Data field whose configuration depends on the command (CM field)



Checksum value

The GSPA execution flow is presented in Figure 5. This execution consists of three stages:
Figure 5

Execution flow of a guidance service provider agent.

  1. 1.

    Data initiation. During this stage, all the variables required by the service are initialised. Values for the initialisation are either obtained from the vehicle infrastructure or are calculated when the service is initiated.

  2. 2.

    Publication of service. During this stage, the fact that the guidance service is operative and available is published. The data published consist of the Bluetooth connection address and the data describing the vehicle's journey. When the vehicle enters the area covered by the local WIFI infrastructure available in a station or at a stop, the vehicle's presence is detected by a guidance service discovery agent and the data describing the service are then sent to the agent in question.

  3. 3.

    Guidance logic. During this stage all the instructions permitting the generation of data describing the vehicle's route are executed.


This execution flow is carried out by a set of cooperative threads. One thread is responsible for obtaining the data sent to it from the vehicle infrastructure by the WIFI communication channel. Bluetooth communication with the GSCA is carried out by a set of specific threads, one for each communication established. Lastly, for each GSCA to the GSPA, there will be a thread executing the guidance logic that is adapted to the specifications and preferences of each passenger.

5.3. Guidance service customer agents

Agents of this type are mobile applications based on MIDlet specifications. A MIDlet is an application that uses the MIDP of the CLDC for the J2ME environment. The Java applications executed in the users' terminals have a cyclical execution flow that is carried out by threads executed on the second level and others that are executed on the first level (see Figure 6). The thread executed on the second level is responsible for Bluetooth communication with the GSPA. The threads executed on the first level are executed as a consequence of the relevant events produced: for example, pressing a specific terminal key, passing by a stop, arriving at the destination stop specified by the user, etc.
Figure 6

Execution flow of a guidance service customer agent.

The GSCA adapts the way the information is presented depending on the passenger's preferences. Currently, three profiles have been developed: for the blind people, for the deaf people and for the tourists. To this end, vehicle route information is provided by audio messages, graphic messages accompanied by terminal vibration or text messages in different languages. A further aspect of the client application that varies depending on passenger preferences is the amount of information provided during the trip. Specifically, there are two guidance modes: stop only mode, in which information is given only about the stops on the route, or tour mode, which gives information about all relevant points of the trip (stops, monuments, leisure centres, etc.).

All the data provided by the GSPA are received by Bluetooth communication using L2CAP connections. A Bluetooth datagram has a common structure that is shown in Table 2. In our case, the data field is used to send commands that allow the GSPA to control the execution of the GSCA. These commands are presented in Table 3.
Table 2

Bluetooth datagram structure

72 bits

54 bits

0-2745 bits

Access code generated by the master Bluetooth device

Head containing control information: control bits, address...


Table 3

Set of commands used by GSPA to control the GSCA execution




Certain information that will be shown in the client screen. The operator must type the text to send and the client identification


To reproduce in the user device the designated multimedia file. After pressing 'Enter' key, the operator must to type the name of the file


Finalise the present reproduction


Signalling to the user that the service has finalised


Signalling to the user that the service has undergone an error and will finalise


It resumes the itinerary. It must do that all the points already visited be marked as 'not reached'


To notify the end of the execution of the GSPA

6. Analysis of the working and performance of the system

This section describes the various tests carried out and an analysis of the results obtained. These tests have been carried out in order to analyse the two aspects that most affect the system's performance, i.e. the communications system provided and the reliability of the data. In the communication system study, we focussed on the Bluetooth communication and more specifically on two key aspects in the quality of the service, namely the time needed to identify and connect to a Bluetooth service, and, once the connections were established, the data transfer time. In the study of the reliability of the data provided to the passenger, we checked whether the passenger had the necessary information at the right time, for example, the alert as to the imminent arrival at a stop must take place before the stop is reached but not too far in advance, and must take place appropriately, i.e. taking into consideration the user's preferences. To this end, the system's response time was studied, understood as the time between the occurrence of a relevant event for the system, for example the imminent arrival at a stop, and the reception of the corresponding information by the traveller in his/her preferred format: vibration, bell, audio or text message.

Before describing the tests carried out and the results obtained, we will describe the environment in which the tests were carried out. We have collaborated with the Global Salcai-Utinsa S.A. public transport company, operating on the island of Gran Canaria, Canary Islands, Spain. The tests were carried out in a laboratory, and the real conditions registered in one of the transport company's vehicles were reproduced. To this end, an automatic tracking system was devised that stored all the relevant events that took place over an uninterrupted period of 4 months in three log files. Data relating to the location of the vehicle provided by its GPS system were stored in the first log file. The second log file contained all the operations carried out by the vehicle while in use (setting out, ending its route, a passenger paying by card or in cash, etc.) and the date and time of each operation. Lastly, the third file registered the technical alerts produced in the information system on board the vehicle (hardware failure, software failure, power cut, overheating, etc.) and the date and time that each alert occurred. In terms of the different operation scenarios in which performance has been studied, two were used:
  • Scenario A, relating to a vehicle in transit. In this scenario, various GSCA agents were used (up to 6) by different passengers, together with one GSPA providing the guidance services regarding the route taken by the vehicle and one GSDA.

  • Scenario B, relating to a station. In this scenario, various GSCA agents were used (up to 6) by different passengers, together with several GSPAs (up to 4) providing guidance services regarding the route taken by the vehicle in which each of them was executed and several GSDAs (up to 3) required to ensure the system had good reception throughout all the physical area of the station in question.

The mobile terminals used to execute the GSCAs were mid-to-low-range mobile telephones executing the Symbian operating system.

In the description of the communication tests, we focussed mainly on those carried out using Bluetooth, as the infrastructure used for inter-user communication and also that which gave rise to the most questions in terms of performance. Tests were carried out in order to analyse each one of the operational states or modes that Bluetooth communication goes through. At one end, we had a customer application that in our case was the GSCA application, going through the following stages:
  1. 1.

    Search for Bluetooth device, or Inquiry. In this case, this would be the device used by the GSPA application.

  2. 2.

    Search for service. In this case, this would be the service provided by the GSPA application.

  3. 3.

    Connection set-up. In this case, the connection with the GSPA application.

  4. 4.

    Communication. In this case, communication enabled data and commands to be exchanged thanks to the GSPA application.

At the other end, we had a server application, in this case, the GSPA application:
  1. 1.

    To specify the attributes of the service offered. In this case, those of the service the GSCA application searches for in the 2nd step mentioned above.

  2. 2.

    To create a server connection. In this case, this is the connection requested in step 3 executed by the above-mentioned GSCA application.

  3. 3.

    To open the customer's connections. In this case, this is the communication referred to in step 4 executed by the GSCA application.


In systems using Bluetooth communication, the stages of inquiry (searching for Bluetooth devices and available services) play a crucial role in the performance of said systems, above all in contexts where there may be a considerable number of Bluetooth devices and services available. This is so because it is an asymmetrical process that uses a special channel, which normally takes place as follows:

  • The Bluetooth device carrying out the search will be the detection device and will send search requests.

  • Any devices detected will receive the search request and respond accordingly.

As far as the way in which a service is identified is concerned, a Universally Unique Identifier (UUID), a unique integer value of 128 bits, is used, as a Bluetooth device can offer several services, each of which must have its own UUID. Only the server and the customer share the UUID, so nobody can use the service if they do not have the identifier in question.

In general, searches for Bluetooth services are carried out as follows: the identifier of the service in question is known, and inquiries are sent to the devices in the area to establish whether or not they have the service in question. In our case, this set-up implies that each GSPA must have a defined Bluetooth service that advises which guidance service (route) it provides. This model would not be viable in a context in which active GSPAs may exist, for example, in a station with numerous vehicles and consequently many active GSPAs for the following reasons:

  • Each active GSPA must have a different service identifier, otherwise the mobile would select the first service located.

  • The mobile cannot distinguish between active GSPAs until a connection is established with each of them and it receives information as to the journey in progress, unless each GSPA possesses a unique identifier, which would make the system unwieldy in terms of scalability.

  • Even if each GSPA had a unique identifier, it would have to connect to each GSPA to discover whether they are present or not, which would be very time-consuming.

In order to solve this problem, the system's architecture uses the GSDA. As we have already mentioned, this agent's mission is to advise as to the GSPAs available; throughout the whole system, this service has a common UUID. When a vehicle arrives at the station or a bus stop, the GSPA in execution detects this fact, using the vehicle location information, contacts the active GSDA at that place advising of its availability and also of its connection address. The GSDA registers the GSPA as a new service in its database. When a GSCA searches for a GSPA, it contacts a GSDA, which sends through all the data of the GSPAs represented in its database (connection address and routes taken by the vehicle in which they are executed), and finally, the GSCA selects the GSPA that is trying to connect. The tests have been carried out in both scenario A and B, as described above, and in both cases, satisfactory results were obtained. The search for devices and guidance services took between 5 and 8 s in scenario A and between 5 and 15 s in scenario B; in both cases, the differences in times registered were linked to the number of Bluetooth devices taking part in the test.

As for the tests carried out to assess the system's performance in terms of the setting up of Bluetooth connections, we should comment that the systems set up these connections immediately as, generally speaking, Bluetooth connections are established by means of an asymmetrical procedure in which one device makes the connection while the other searches for the signal; it is a directed procedure, i.e. only the Bluetooth device to which the connection is aimed will respond. The device trying to make the connection uses a special channel to receive the packets with the connection request that it then sends to the connection device. This special channel has the specific attributes of the device that is going to connect, so that only a connection device with the data of the former can establish communication using this channel.

As we mentioned at the beginning of this section, in order to assess the reliability of the data, the system's response time was analysed by carrying out tests in scenario A. In these tests, different routes were simulated by the laboratory vehicle using the log files described above, thereby ensuring that the tests carried out reproduced realistic scenarios. The system's response time was considered to be the time between the occurrence of an event to be notified, for example, the imminent arrival at a stop and the reception by the passenger via his/her GSCA of said event. During this time, once the event has happened, the system has to execute the following actions: firstly, communicate to the GSPA the fact that the event has taken place (this is done by the infrastructure layer on board using a WIFI communication channel; secondly, the GSPA has to identify the notification to the GSCAs affected, and thirdly, the GSCAs affected have to process the communication received and present it to the passenger in his/her preferred format; i.e. generate an alert in the form of vibration, bell-tone or an audio or text message. Of these three tasks, the last two take the longest and, consequently, the tests were oriented to obtaining the transmission time required to send different amounts of data from the GSPA and the time required by the GSCAs to process the data received. Moreover, the tests were carried out in an adverse scenario, in which eight GSCAs were used (the maximum number that can be connected at any one time to a piconet), and the mobile devices in which each of them were executed were low-to mid-range mobile telephones executing Symbian as the operation system. The response time taken to communicate the next stop of the route and the arrival at a given stop from the GSPA to the different GSCAs involved in the tests (up to 8) basically depended on the amount of data transferred, specifically transfers of 1 kbyte took about 2 s, 79 kbytes about 15 s and 300 kbytes around 2 min. With these results and the different lengths of time taken by the vehicle to go from one stop to the next, it was decided to limit the amount of data transmitted to communicate an event to a maximum of 1 kbyte.

7. Conclusions

In this article, we have described a guidance system for passengers using public road transport. The guidance service provided gives useful information to the passenger during his/her trip. Useful information here means coherent information that is easy to access and is given in real time. The architecture of this system is based on paradigms of multi-agent, pervasive computing. The reasons these computing models are used are because they bring to the system a set of functionalities that are suitable for the needs of different types of passengers, particularly for those with special needs. Other characteristics that differentiate it from existing systems of this kind are its distributed nature, as the data supplied to passengers is located in repositories located in the vehicles, and the use of local wireless communications (Bluetooth and WIFI) to ensure that passengers can use them for free. We emphasise that the system explained is agnostic-networked and can use wired or wireless technology. Nowadays, for local communications, it supports two commonly used wireless technologies, IEEE 802.11 and Bluetooth. As a result, the system is capable of delivering information to users with a suitable level of performance using heterogeneous mobile devices.


Authors’ Affiliations

Cybernetic Science and Technology Institute of the University of Las Palmas de Gran Canaria, Campus Universitario de Tafira


  1. Stradling SG: Moving around: the psychology of transport. Foresight Intelligent Infrastructure Project, Department of Trade and Industry. London, England 2006.Google Scholar
  2. Waara N: Older and disabled people's need and valuation of traveller information in public transport. European Transport Conference 2009, Association for European Transport and contributors, Leiden, Netherlands 2009, 1: 1-21.Google Scholar
  3. Turunen M, Hurtig T, Hakulinen J: Mobile speech-based and multimodal public transport information services. Proc 2006 Workshop on Speech in Mobile and Pervasive Environments, Espoo, Finland 2006, 1: 1-8.Google Scholar
  4. Sánchez JH, Oyarzún CA: Mobile audio assistance in bus transportation for the blind. Proc 7th International Conference Series on Disability, Virtual Reality and Associated Technologies with ArtAbilitation, Maia, Portugal 2008, 1: 279-286.Google Scholar
  5. Barbeau SJ, Winters PL, Georggi NL, Labrador MA, Perez R: The travel assistant device: utilizing GPS-enabled mobile phones to aid transit riders with special needs. Proc 15th World Congress on Intelligent Transportation Systems, New York 2008, 1: 1-12.Google Scholar
  6. Transport for London:Countdown Live Bus Arrivals. []
  7. HSL Live[]
  8. Startsida - AB Storstockholms Lokaltrafik[]
  9. Mitchell CGB: The potential of intelligent transportation systems to increase accessibility to transport for elderly and disabled people. Transportation Development Centre, Montreal, Quebec, Technical Report, TP 12926E 1997.Google Scholar
  10. Giannopoulos GA: The application of information and communication technologies in transport. Eur J Oper Res 2004, I52: 302-320.View ArticleGoogle Scholar
  11. Jakubauskas G: Improvement of urban transport accessibility for the passengers with reduced mobility by applying intelligent transport systems and services. Proc The 8th International Conference on Reliability and Statistics in Transportation and Communication 2008, Riga, Latvia 2008, 102-108.Google Scholar
  12. Weiser M: The computer for the 21st century. IEEE Pervasive Comput Mob Ubiquit Syst 2002, 1(1):18-25.Google Scholar
  13. Saha D, Ukherjee A: Pervasive computing. A paradigm for 21st century. Computer 2003, 36(3):25-31. 10.1109/MC.2003.1185214View ArticleGoogle Scholar
  14. Kindberg T, Fox A: System software for ubiquitous computing. IEEE Pervasive Comput Mob Ubiquit Syst 2002, 1(1):70-81.View ArticleGoogle Scholar
  15. European Committee Standardization, Reference data model for public transport, Technical Report CEN TC278 2005. []


© García et al; licensee Springer. 2012

This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.