An Internet-of-Things Enabled

Connected Navigation System

for Urban Bus Riders

Seminar Report
by
Gaurav Daga
2014UEC1257

Under the supervision of

Dr. Amit Mahesh Joshi

Electronics & Communication Engineering

Department
Malaviya National Institute of Technology, Jaipur
April 2017
 Contents
Page

1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

3 UBN System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.1 Public Transport Information Requirements . . . . . . . . . . . . . . . . 2
3.2 Design Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3 IoT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4 Communication with Buses . . . . . . . . . . . . . . . . . . . . . . . . . 5

5 Bus Crowd Level Estimation . . . . . . . . . . . . . . . . . . . . . . . . 6

6 Bus Crowd Information Server . . . . . . . . . . . . . . . . . . . . . . . 7

6.1 Predicting Bus Occupancy . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2 Least Crowded Route Recommendation . . . . . . . . . . . . . . . . . . . 8

7 Navigation App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1 Micro Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2 Navigation Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

8 Studying the Deployment and about the User . . . . . . . . . . . . . . 12

8.1 Technical Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2 Evaluation of User Experience . . . . . . . . . . . . . . . . . . . . . . . . 16

9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Abstract

Providing effective public bus transport services has become a key challenge for ever-
growing cities of today. The Internet of Things (IoT) has great potential to tackle
existing shortcomings of public transport systems because of its ability to embed smart
technology into real-life urban contexts. This paper applies the concept of IoT and
presents the Urban Bus Navigator (UBN), an IoT enabled navigation system for urban
bus riders. The two services provided by UBN are: 1) micro-navigation and 2) crowd-
aware route recommendation. Results from a study in Madrid, Spain, also indicates a
positive impact on how people feel about bus journeys and removed barriers for public
transport usage.

2. Introduction

Design of urban mobility infrastructures poses newer challenges due to the ever-growing
nature of cities. Although public bus transport systems have the capacity to transport a
large number of people but they do not have a good public image [2]. First, bus networks
are more often than not complex and difficult to navigate in dense urban areas. Second,
bus riders experience low level of comfort and convenience as compared to private means
of transportation. Third, personal control and ownership is lacking in bus journeys as
compared to car rides [3]. These negative perceptions can be improved with the help of
digital technologies.

Existing public transport systems can be improved by integrating smart technology

into real world transport usage contexts with the help of the Internet of Things (IoT).
A closer relationship can be developed between physical and digital travel experiences
by the use of IoT. Enhanced information availability and accessibility is a key factor
for changing the perception of people towards public transport systems [4]. Although
existing transport information systems help to plan a bus journey, still there is no di-
rect support available for the information needs that emerge during a transport journey.
Current systems fail when it comes to assisting people during their transport journeys
when complex transport decisions have to be made.

1
 The Urban Bus Navigator (UBN) is a solution presented by this paper to overcome
the problems mentioned above. It is personalized bus navigation system with the ability
to flawlessly connect bus passengers with real world public bus infrastructure. This
system utilizes a distributed IoT infrastructure. This allows the passengers’ smart-
phone devices to communicate with buses in real time and also enables the buses to
sense the presence of passengers on board. The two information services provided by
UBN are:

1) Micro-navigation refers to fine-grained contextual guidance of passengers along

a bus journey by recognizing boarded bus vehicles and tracking the passenger’s
journey progress.

2) Crowd-aware route recommendation collects and predicts crowd levels on bus

journeys to suggest better and less crowded routes to bus riders.

As can be seen, UBN has the capability to provide travelers information about the state
of transport system and also about their travel options which helps to improve the public
transport experience.

The UBN system has been launched and integrated into the municipal bus infrastruc-
ture in Madrid, Spain along with a free smart-phone app for the public. The technical
components of UBN system is discussed along with the user experiences from real world
field trials.

3. UBN System

The UBN has been developed in cooperation with EMT Madrid. EMT Madrid is the
Madrid transport organization that handles the municipal bus system. Bus infrastruc-
ture in Madrid has around 2000 vehicles that employ on more than 200 bus routes and
has more than 4600 bus stops. The modification of the Madrid public transport system
by using IoT technology is discussed in the following.

3.1 Public Transport Information Requirements

The UBN system has been developed in order to satisfy public transport information
needs. Users cannot physically control the public transport system in the same way pri-

2
vate means of transport can be controlled. So giving access to relevant transportation
information is a key factor to foster positive transport experiences.

Figure 1: Overview of the contextual information needs of bus users from start to end
of bus journeys

Fig. 1 provides an overview of the key decision points and the related information
requirements. The diagram shows a bus journey where a passenger switches buses be-
tween the journey. The rectangular boxes indicate the decision points throughout a
bus journey like boarding bus, arriving at bus stop, alighting from bus etc. The text
labels toward the right indicate passenger information requirements related to the key
decision points. The decisions made by passengers during a journey is referred to as
micro navigation decisions. These decisions are of very contextual nature. They depend
not only on time and location but also on the transport mode of traveler, the context of
current travel and the traveler’s upcoming tasks. A lot of focus and cognitive attention
is required by travelers due to the variety and complexity of information needs.

3.2 Design Rationale

Two key objectives can be formulated for UBN by taking into account the information
needs of the traveler. First, providing help regarding micro navigation decisions along
with contextual step-by-step guidance during the whole journey play an important role
in regards to shaping public transport experience. Second, estimation of crowd level for
different bus routes and recommendations of routes having least crowded can help to
uplift the perception of bus riders.

3
 These objectives are not addressed in the existing information systems. First, general
information systems concentrate on transport planning taking into account location and
time as the only contextual factors but the ever-changing information needs of micro
navigation decisions are not adequately answered. Second, even sophisticated journey
planners concentrate on optimizing travel time but the applicable contextual information
like the crowd density of bus are neglected. This affects the choices made by traveler.
The lack of inability to sense and understand the transport situation of travelers is what
can be considered as the limitation of existing transport information systems.

To overcome these issues, UBN offers the following technical modifications:

1) A distributed software and hardware system based on IoT that uses short range
WiFi communication to connect travelers’ mobile devices with the buses.

2) A micro navigation solution to provide continuous trip assistance during bus jour-
neys. This is realized by a semantic bus ride tracking scheme that detects the
bus on which the passenger is currently riding and identifies fine-grained transport
situations whenever they appear in a users’ bus journey.

3) A crowd density estimation facility to detect the number of passengers on buses.

The wireless signals of mobile phones received by buses are monitored to estimate
crowd levels and travelers are provided with enhanced bus route recommendation.

3.3 IoT Architecture

The three major components of the UBN system are:

1) Urban bus system in which buses are equipped with WiFi. Local networks are
established with the help of WiFi. This is done for keeping the mobile phone of
the passengers updated with the bus data. Moreover, bus system is also integrated
with a crowd density estimation system.

2) The UBN navigation smart-phone app for bus riders. The UBN app is able to
track a rider’s bus journey and help travelers with micro navigation decisions
by connecting to bus vehicles and extracting information about the bus and its
direction.

4
 3) The bus crowd information server to collect real time crowd density information
from each bus bus. The server encompasses an enhanced transit route planning
engine to recommend . Bus routes with lower predicted crowd are recommended
by the server which encompasses a very enhanced transit route planning engine.

Figure 2: The UBN sytem

The interconnection of each of the three components of UBN makes the system
unique. Novel interactions are facilitated by UBN (dashed lines in Fig. 2) compared to
the current communication links found in the existing bus information systems (solid
lines).

4. Communication with Buses

Each bus has an on-board computer system. This system is connected to a GPS receiver
along with a 3G network interface. Traditionally, the computer system communicates
only with the bus operator. But in case of UBN, the bus system has the capability
of communicating with users’ smart-phone. To achieve this, wireless access points are
provided inside the buses. Upon receiving a request, following information can be shared
by the system:

1) GPS Position: The current GPS position of the bus along with its id is exported
by the Web service. This information is used for visualizations and computations
that are performed by the mobile app.

5
 2) Current Route: The Web service also provides the name of current route, ve-
hicle id, direction and bus stops’ list in order to help with navigation and to give
information about the number of passengers detected on that route.

3) Next Stop: The Web service also gives information about bus id and next stop
of the bus. This information is derived from the Bus position and the state of
the doors are used to derive this information. State of doors is used in order to
compensate for inaccurate GPS positions.

5. Bus Crowd Level Estimation

Crowd density is estimated by taking advantage of the feature of WiFi-enabled devices.
They periodically send out probe requests according to IEEE802.11 protocol to detect
the nearby access points. Each bus is equipped with a WiFi access point that contin-
uously captures the probe requests transmitted by the passengers’ mobile phone. The
Media Access Control(MAC) addresses of each of the devices transmitting the probe
requests are summed which gives an estimated of the number of mobile devices in the
proximity of the bus.

This approach has a very big problem. Devices that are in the vicinity of the bus,
but not located it, also send out probe requests which are captured by the bus when it
moves through densely populated area or when it stops at a bus stop. Temporal and
spatial filter criteria is deployed so that only the passengers on-board are detected. This
is done by observing if probe requests are being received for a continuous distance which
simply means that the mobile phone is moving along with the bus. To do this, the probe
requests are associated with precise timing and position information which are obtained
from the bus system. For each of the MAC addresses m, following are tracked:

• the time tm when the last request was received

• the last position pm of the vehicle at that time

• the total distance dm for which it has been received

The total distance dm is calculated by adding the distance between last and current
position dm+1 = dm + distance(pm , pcurrent ) whenever a new request is received. Using

6
this information, number of passengers inside the bus can be estimated as the sum over
all m where dm > dthreshold and tm > tnow - tthrshold .

Previous experiments by the authors [5] have indicated that 180 s is an acceptable
value for tthreshold to detect new probe requests. To define the spatial threshold, it is seen
that the transmission range of typical WiFi hardware is not more than 100 m and thus
use 300 m as the value of dthreshold to account for the fact that a moving transport vehicle
may see a stationary device for twice the transmission range and also to account for the
errors resulting due to the incremental calculation and imprecise GPS measurements.
Employing the technique also helps to prevent people waiting at bus stop for some other
bus to be detected as bus passengers. Such devices may satisfy the temporal criteria
but they will be detected as immobile devices and thus do not satisfy the spatial criteria.

By using the unique MAC addresses, devices can be identified if they are inside the
bus or not. However, travelers’ privacy can be violated as this information can be used
to identify the trips individual riders make. To solve this issue, an approach is adopted
in which each vehicle only specifies total number of passengers for the current route and
not the individual unique identities of the smart-phone.

6. Bus Crowd Information Server

UBN system adds two components to the back-end system for making efficient and
effective use of the available bus crowd density data. These features include prediction
of bus occupancy for future rides on a particular route and how this future prediction
can be used in the route planning engine.

6.1 Predicting Bus Occupancy

With the help of the bus occupancy estimation system, streams of crowd density in-
formation can be collected and stored, from across the bus network, on a dedicated
server. Each bus occupancy report contains only the aggregated information i.e. time-
stamp, bus id, route id, and estimated number of passengers. Crowd density histories
are used as a basis for predicting the future crowd level so that the quality of contextual
information is enhanced.

7
 To make predictions on the basis of the available bus occupancy histories, a set
of temporal and structural features are defined. They capture the variations in bus
ridership with respect to time and route across the entire bus network. Thus, each
prediction is associated with a feature vector < R, Sorig , Sdest , Tday , Thour > where

• R denotes bus route

• Sorig and Sdest denotes starting and destination stop

• Thour denotes hour i.e., 0 - 23

• Tday denotes type of day i.e., 0 for Mon to Fri, 1 for Sat and 2 for Sun

For predicting the occupancy level, average number of passengers over each of the
past entries in the history for a given vector is calculated.

6.2 Least Crowded Route Recommendation

A custom transit route planning engine has been developed to recommend routes having
least occupancy to passengers. This engine relies on GTFS data to acquire details about
public transport network, OpenStreetMap information for data about street network and
the crowd density predictions to have an estimate about the occupancy of an upcoming
journey. The developed engine supports the normal constraints and queries that can
be provided in a navigation application like departure or arrival time, allowed vehicle
types, walking speed, accessibility to wheelchair etc. When integrating occupancy levels
into the route computation step, it is necessary to address the following questions have
to be addressed when it comes to deploying crowd density levels in the routing engine -

1) How should the crowd density level be aggregated for multiple segments?

2) Should the crowd density level be used to rank alternatives or to exclude routes?

As far as the first question is concerned, some or the other way is required to combine
crowd density levels which vary as bus journey progresses from origin to destination stop
on a bus route. In UBN, the crowd density levels are aggregated for the entire route
by averaging the bus occupancy levels related to all the segments traveled for the given
trip. This is done because the overall comfort experienced by a traveler is likely to be
reflected by the overall bus occupancy level. Nevertheless, the routing engine can be

8
very easily adapted to include the chances to get a seat when entering the bus.

Regarding the second question, the crowd density level was used for ranking rather
than to exclude routes. By using exclusion of routes, faster processing could be achieved
as non-fitting routes could be excluded directly when A* search was employed. But
routes with larger number of passenger was not hidden so that the choices of passengers
were not limited artificially. So ranking route alternatives is the best option when it
comes to their expected density levels. A variant of the A* algorithm [6] is used to rank
for finding the best route. We integrated the occupancy levels as an additional weight-
ing factor during the A* route computation that ensures that lower occupancy route
segments are explored preferentially given that other factors (e.g., duration, number of
transfers, etc.) are similar. To do so, constant penalty values are added for higher den-
sities to the overall weight that is used to find the order of traversal. By modifying this
value, various trade-offs can be computed between bus occupancy and classical travel
metrics like duration of trip for suggesting routes which can help to avoid traveling in
highly populated buses.

7. Navigation App

To complement the interconnected bus infrastructure, a smart-phone application has

been developed for urban bus riders. The mobile phone application is discussed in the
following.

7.1 Micro Navigation

Dedicated provision for micro navigation is supported by the mobile app. It provides
continuous guidance through each and every stage of a bus trip. Guidance is provided
before a passenger gets on bus, during the rides and when traveler alights the bus. While
traditional bus applications concentrate on route planning, micro navigation is more fine
grained and it covers a wide range of information requirements which directly appear in
the context of a bus trip such as: ”Is the bus that just pulled up at bus stop the one
that should taken?” ”Which bus am I riding on?” ”Is this the correct bus?” ”How long
before I need to alight?”

9
 To provide guidance to users when it comes to answering different contextual queries
originating at different points of a trip, it is necessary that the mobile app discovers and
connects to the physical bus infrastructure. To do so, smart-phone app runs a process
in the background that automatically attempts to establish a WiFi connection with the
buses in the vicinity of the user. Whenever a WiFi connection is established, real time
bus status data can be queried to obtain information about the route on which the bus
is operating and the next stops along the trip. The ability to connect to vehicles using
local WiFi has two important purposes:

1) Bus ride recognition: It is enabled implicitly by the connection mechanism

based on WiFi. WiFi connection requires a steady network signal having high
quality. This is available only inside or in the vicinity of buses. Thus active
connection simply means that the passenger is either on the vehicle or nearby the
vehicle. When passenger leaves the bus, the quality of network signal drops which
leads to the connection being lost. Changes in WiFi connectivity can be detected
very easily on mobile devices which can be used to interpret whether the traveler
is inside a bus or not.

2) Trip tracking: As the WiFi connection gives access to the information of the
boarded bus in real time, the progress of the trip of a passenger can be monitored
too. Since this connection gives the provision for polling periodically the vehicles
on which a traveler is riding for the real time status, bus trips taken by passengers
can be tracked based on the data about the current route and the next stops of
the buses. The vehicle information and the trip plan of the passenger is used to
provide micro navigation suggestions using proactive data provision that has no
need of any sort of manual intervention by the bus rider.

7.2 Navigation Interface

The mobile app provides interface to interact with the traveler and also display proactive
information during the travel. The complexity because of the distributed navigation sys-
tem is hidden from the user to offer a flawless bus experience. Initially, navigation starts
with traditional trip planning interface: the traveler can choose directions from current
location to some other location in the city of Madrid. Preferences like shortest travel
time along with routes having low predicted bus crowd density levels can be obtained.

10
The user can also inspect visually direction information which includes predicted density
levels on a map and select route for navigation.

While navigating a bus trip, special needs related to each journey activity including
walking and bus rides are supported. Information associated with navigation is displayed
on an interface that comprises of following two parts(as shown Figure 3):

• Map area

• Notification area

Figure 3: Interface of the smart-phone application

The map is used to help the user gain a geographic understanding of the trip. The
current location of user is shown and each of the travel segments involved in the trip
are represented. Micro navigation assistance is provided by textual information that is
shown in notification area below the map area. The classes of navigation information
supported are as follows:

1) Walking: If it is detected that the traveler is not on the bus, instruction related

11
 to walking are shown to direct the traveler to the next bus stop where a vehicle
needs to be entered.

2) Next Bus Departure: If a traveler walks down to a bus stop, data about the
next bus departure and the route is provided.

3) Prepare for Alighting: If the passenger is inside the bus, the number of stops
remaining before getting down is displayed. This data is updated with each and
every subsequent stop and an alert is sent before reaching the planned exit stop.

4) Missed Alighting: If a passenger is still found to be on the vehicle after he/she

should have left at the previous stop, a warning message is generated with an
option to re-plan the journey.

5) Wrong Bus Alert: If a passenger has entered a bus that is following some other
route than the planned trip, an alert is displayed and a re-planning option is also
offered.

Traveler is presented with relevant information which are selected from the above
options depending in the trip progress of the traveler. A change in vehicle status and
real world context of the user, the navigation data is re-evaluated and updated. This
enables a higher level, semantic conclusion about the transport situation of the traveler
which is much more indicative than just time and location. Apart from textual output,
the mobile application has the capability to generate spoken instructions related to
navigation with the help of a text to speech engine. Using a pair of headphones, this
allows hands free use of the micro navigation features during a bus trip.

8. Studying the Deployment and about the User

The UBN system has been integrated in Madrid’s public bus transport system since
July 2013. The mobile application is available to the public which can be downloaded
as a free Android app from Google Play. It is available at https://play.google.
com/store/apps/details?id=eu.gambas.prototype.navigator. Thousands of peo-
ple have downloaded the app since its first release. Two types of evaluations have been
conducted which are presented in the following:

1) Technical test of the effectiveness of the system

12
 2) Comprehensive user experience study in Madrid.

8.1 Technical Evaluation

It is very crucial to differentiate between passengers outside and inside the bus to assess
the effectiveness of the operation of the bus occupancy estimation system. To get in-
sights about this problem, the probe requests received in a bus operating in Madrid were
monitored during a period of 14 days. A commercial WiFi access point was installed in
that bus. OpenWRT along with libpcap and tcpdump were running on the access point
to capture continuously the probe requests on one of the channels.

Figure 4: Frequency of detected devices

The bus was operated for 224 hours out of 336 hours and during its operation, each
of the probe requests received were logged by the monitor. To avoid duplicate detection
of the same request sent out multiple times, the amount of logged probe requests were
limited to 1 request per MAC address per second. 3,84,874 probe requests were logged
from 85,212 unique MAC addresses. Figure 4 shows the frequency of the detection of
the unique MAC addresses. Among the logged addresses roughly 40,000 where only
observed once and an additional 15,000 MAC addresses were only observed twice. This
clearly demonstrates that a major fraction of devices were most probably not traveling
inside the bus. Instead, there are more chances that they were at a bus stop or in close
proximity to where the bus was driving.

13
 Figure 5: Probe request interval distribution

A sliding window mechanism was integrated to filter out the undesired MAC ad-
dresses. This mechanism removes the MAC addresses that are not recognized over a
longer period of time. To configure the windowing period, the logs were analyzed to
determine the rate at which probe requests would be detected from devices.

As can be seen in Figure 5, majority of requests - around 1,85,000 - are sent within
one minute. From these requests, approximately 1,29,500 are transmitted in less than
15 seconds. This means that these requests are most probably repeated requests which
were not removed by the 1 second rate limitation. However, the remaining 60,000 re-
quests are transmitted at least 15 seconds later which shows that they may be new probe
requests. Seeing the overall slope displayed by the histogram in Figure 5, it seems that
majority of consecutive requests are observed typically within 1 minute and at most
within 3 minutes.

Based on these results, the sliding window mechanism for the bus occupancy esti-
mation is configured to 3 minutes. To avoid counting the mobile devices which are not
inside the bus, devices that have not been observed for at least 1 minute are suppressed
and they are continued to be counted until their signals are no longer contained in the
window i.e., the monitor has not received a request for at least 3 minutes.

14
 Figure 6: Distribution of the spatial distances of the WiFi access points detection

For the implementation, the proposed bus occupancy estimation system relies on a
spatio-temporal classification mechanism to identify the mobile devices which are mov-
ing along with the bus. The main idea is to recognize the immobile devices which do not
follow the vehicle for a minimum amount of time and distance and hence they do not
represent actual passengers inside the bus. An evaluation scenario was constructed using
only the WiFi access points which were seen by the monitor installed in the vehicles to
demonstrate the effectiveness of this classification. The access points observed along the
vehicle routes in Madrid can be assumed to be stationary devices with a high probability.
Hence, it was tested if the approach was capable of correctly identifying them as non
bus riders on the basis of the applied filter criteria. Figure 5 plots the distribution of
the spatial distances over which the WiFi access points were observed by the vehicle. As
can be seen in the figure, roughly 30% of the WiFi access points are only observed at the
same position, 67% are observed for less than 100 m and 90% can only be observed for
300 m or less. The remaining 10% of WiFi access point sightings are forming a long tail
i.e., very low frequencies that can even reach distances in the order of kilometers. The
fact that some WiFi access points observed by the bus are not at a fixed position can
be used to explain this long tail. Instead, they are mobile and moving along with the
bus. Such examples include smart-phones with active WiFi tethering and access points
deployed in vicinity of buses that share a common route.

15
8.2 Evaluation of User Experience

The UBN system has been designed keeping in mind that it is a user centric system
which is aimed to enhance the real world experience of passengers. Thus to assess the
implications of this system, its acceptance and perception among travelers must be in-
vestigated. To do so, two user studies were conducted in Madrid.

The first study was used to gather quantitative feedback from the people who used
the UBN app. The experience sampling method (ESM) was adopted for addressing this
purpose. A short questionnaire was integrated into the mobile app to gather experience
of the travelers ”in-the-wild”. The UBN app prompted passengers to rate their experi-
ence on a Likert scale (0 to 5 stars) at important stages of their trip. The ESM approach
yielded insitu experiences from the passengers as the answers are triggered during or
shortly after the bus usage. In total 350 ESM reports were received from the passengers.

One of the questions that were answered by the passengers was whether they found
the navigation feature to be useful. 41% of the travelers gave the maximum rating of
5 stars and about 95% of the travelers rated the usefulness of the app with 3 stars or
more. This is an evidence the UBN system could provide additional value to the existing
public bus transport system. It was also asked whether the mobile app made it easier
for the users to traverse the bus network. 93% of the passengers gave a rating of 3 stars
or more. It was also asked whether the users think that the mobile app motivated them
to use public transportation more often. The responses were very positive as 36% of the
travelers completely agreed with a rating of 5 stars and further 20% rated with a 4 star.

The aim of the next study was to get a more deep understanding of the specific feel-
ings that the users developed during the use of the mobile app. Thus ten participants,
three females and seven males, with an age range from 23 to 46 (Mean = 38, SD = 9.3)
were recruited and semi-structured interviews were conducted after they had used the
mobile applicationfor roughly one week. First, the interview began with general ques-
tions about the users’ transport habits like how often they conducted bus rides and for
what purposes. Then, more specific questions related to users’ individual experiences
were asked: How did you perceive the navigation support? Did the application change

16
the way of how you feel about bus usage? Did the application make any difference to you?

Several participants expressed positively about their experiences in regards to im-

proved information accessibility. Many participants were satisfied with the variety of
contextual situations the UBN system could handle during their trips and that at occa-
sions the system revealed key facts that the participants had overlooked. The fact that
the UBN app is alive throughout the bus trip increased the trust of the users in the
navigation support. This further raised their confidence in using the public bus system.

9. Conclusion

The base paper presented the Urban Bus Navigator System which is a navigation system
for public bus riders that has the capability to seamlessly interconnect bus riders with
the real world bus infrastructure. The UBN system utilizes a distributed IoT system.
This system comprises of an embedded bus computing system, back-end computing in-
frastructure and mobile smart-phone application to detect the presence of passengers on
buses and provide continuous real time navigation during the entire bus trip. A several
month long study in the city of Madrid indicated that the UBN system indeed is experi-
enced by travelers as a true navigation system and perceived differently from the current
mobile transport applications. Lots of positive experiences were noted: more relaxed
traveling, reduced uncertainties, better accessibility and visibility of travel information
and effective support for cognitive tasks needed for bus trips. The generic design of
makes it possible to adapt the system in any city which has a digital urban transport
infrastructure like that of Madrid. All in all, UBN demonstrates the potential of the
IoT for delivering innovative urban transport experiences.

The future scope of this system is immense. Overall UBN is a very novel and inno-
vative idea. But there are aspects where some improvements can be done. UBN system
heavily relies on the fact that a user always has the WiFi of his/her mobile device
switched on. But this may not be the case always which leads to inaccurate calculation
on crowd density levels. To overcome this drawback, roles played by WiFi in the UBN
system can be substituted by RFID technology.

17
References

[1] Base Paper: M. Handte, S. Foell, S. Wagner, G. Kortuem, and P. Jos Marrn, ”An
Internet-of-Things Enabled Connected Navigation System for Urban Bus Riders”,
IEEE Internet of Things Journal, vol. 3, no. 5, pp. 735-744, Apr. 2016.

[2] S. Stradling, M. Carreno, T. Rye, and A. Noble, ”Passenger perceptions and the
ideal urban bus journey experience,” Transp. Pol., vol. 14, no. 4, pp. 283-292,
2007.

[3] B. Gardner and C. Abraham, ”What drives car use? A grounded theory analysis
of commuters’ reasons for driving,” Transp. Res. F, Traffic Psychol. Behav., vol.
10, no. 3, pp. 187-200, 2007.

[4] B. Ferris, K. Watkins, and A. Borning, ”OneBusAway: A transit traveler infor-

mation system,” in Mobile Computing, Applications, and Services. Heidelberg,
Germany: Springer, 2010, pp. 92-106.

[5] M. Handte et al., ”Crowd density estimation for public transport vehicles,” in
Proc. Workshop Min. Urban Data (MUD) Joint Conf. EDBT/ICDT, Athens,
Greece, Mar. 2014, pp. 315-322.

[6] P. E. Hart, N. J. Nilsson, and B. Raphael, ”A formal basis for the heuristic deter-
mination of minimum cost paths,” IEEE Trans. Syst. Sci. Cybern., vol. 4, no. 2,
pp. 100-107, Jul. 1968.

18