Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 22
22
CHAPTER THREE
CHARACTERISTICS OF UNDERLYING TECHNOLOGY, MOBILE
TECHNOLOGY, AND MOBILE INFORMATION
The synthesis survey covered several key characteristics of the TABLE 1
underlying technologies that are required to generate the infor- AGENCIES THAT RESPONDED TO QUESTIONNAIRE
mation disseminated on mobile devices, of the mobile devices
Agency Name Abbreviation City
and operating systems, and of the actual mobile messages. See
AC Transit AC Transit Oakland, CA
Table 1 and Appendix C for a list of the 28 responding agencies
(representing a 100% response rate). Before examining these Afifi Group Afifi Nazareth, Israel
characteristics, the overall annual ridership and modes oper- Bay Area Rapid Transit BART Oakland, CA
ated by each respondent were noted. Annual ridership ranged District
from 1 million (fixed-route bus and tourist van respondent) to Carris Carris Lisbon, Portugal
101.5 million (TriMet) to 1 billion (for an international respon- Central Ohio Transit Authority COTA Columbus, OH
dent—National Rail in the United Kingdom).
Chapel Hill Transit CHT Chapel Hill, NC
CityBus CityBus Lafayette, IN
Total annual ridership for each agency and the change
in ridership for each responding agency between 2005 and Fresno Area Express FAX Fresno, CA
2010 are shown in Appendix D, Table D1. Greater Bridgeport Transit GBTA Bridgeport, CT
Authority
Kansas City Area Transporta- KCATA Kansas City, MO
tion Authority
UNDERLYING TECHNOLOGY AND REAL-TIME MOBILE
MESSAGE TYPES Metropolitan Atlanta Rapid MARTA Atlanta, GA
Transit Authority
Table 2 shows the types of underlying technology being used. METRO Transit METRO Oklahoma City, OK
Metropolitan Transportation MTC Oakland, CA
Commission
The survey respondents report a wide variation in the
types of real-time information and the frequency with which MTA Metro–North Railroad MNCR New York, NY
it is updated, as shown in Table 3. In terms of the types of National Rail NRail London, UK
real-time information, the most prevalent information that is Pace Suburban Bus PACE Arlington Heights, IL
updated on an ongoing basis is next vehicle arrival/departure
Portage Area Regional PARTA Kent, OH
prediction time, followed by information on planned detours, Transportation Authority
display/announcement of the current route and destination,
Regional Transportation Com- RTC Reno, NV
identification of service disruptions, and schedule information mission of Washoe County
during special events. As expected, the most prevalent infor-
Rejseplanen A/S RA/S Valby, Denmark
mation that is updated based on a specific threshold or time
Société de transport de Laval STL Laval, Québec,
period is next vehicle arrival/departure prediction time. The Canada
next most prevalent information updated with this frequency
Sound Transit ST Seattle, WA
is identification of service disruptions and display/announce-
Stockholm Public Transport SL Stockholm, Sweden
ment of the current route and destination. Finally, the most
prevalent information updated when requested by customers Tampere City Public Transport TCPT Tampere, Finland
(on demand) is identification of service disruptions, followed TheBus—Oahu Transit TheBus Honolulu, HI
by next vehicle arrival/departure prediction time and informa- Services, Inc.
tion on planned detours. Although these results are not unex- Trafikanten AS TAS Oslo, Norway
pected, it is interesting to note that only one type of real-time Trafikselskabet Movia TMovia Valby, Denmark
information is updated when the dissemination media are not
Transport for London TfL London, UK
functioning (identification of service disruptions), and none of
TriMet TriMet Portland, OR
the respondents provide real-time parking information.
OCR for page 23
23
One aspect of this synthesis was to determine the use of
TABLE 2
mobile devices as dissemination media versus other known
UNDERLYING TECHNOLOGY USED BY SURVEY
RESPONDENTS channels. As shown in Table 4, mobile dissemination media,
specifically mobile web/Internet, smartphone applications,
Technology No. of Respondents
two-way SMS, mobile tagging, and near-field communica-
Automatic vehicle location (AVL) 23
tion, were the most prevalent for the survey respondents.
Alert subscription system 13
As expected, the Internet accessed by a personal computer
Near-field communication (NFC) capability 2
was the next most prevalent way of disseminating real-
Mobile tagging software (e.g., Microsoft Tag, 3 time information, followed by DMSs and interactive voice
Semacode, 2D/3D barcodes)
response (IVR). These results reflect not only that this syn-
Computer-aided dispatch (CAD) 18 thesis is focused on information provided on mobile devices,
but that agencies are moving away from DMSs, which are
Schedule adherence functionality 13
more costly for dissemination owing to their operations (e.g.,
Real-time arrival prediction software 25
power and communication) and maintenance requirements.
On-board next stop announcements (visual) 19
It is interesting to note that several agencies reported using
On-board next stop announcements (audio) 21
mobile tagging technology, which is a relatively new mobile
On-board driver voice communication system 15 technology. The use of mobile websites by several agencies
is shown in Figures 17 through 21.
On-board data communication system 11
Real-time map display at stop/station 2
Two-way messaging capability (e.g., using 16
MOBILE TECHNOLOGY
short message service (SMS) [text messaging]
Light-emitting diode (LED) 9
The survey covered several aspects of mobile technology,
How many with audio capability (e.g., using a 1
i ncluding the reasons for providing real-time information
push-button or infrared device to “read” DMS
on mobile devices, the types of mobile services provided,
display)?
a nd whether or not agencies partnered with mobile tele -
Liquid crystal display (LCD) 3
phone providers to provide information. First, the survey
How many with audio capability? 0
results indicated that 17 of the 28 respondents decided to
Other: Please specify. 1
deploy real-time transit information on mobile devices
How many “other” with audio capability? 0
to augment providing real-time information by means of
TABLE 3
FREQUENCY OF REAL-TIME INFORMATION
Real-Time Information Frequency
Update on an Update when dis- Update when Update per When requested
ongoing basis semination media no information defined by customers
Type of Real-Time Information are not functioning available threshold (on-demand)
Next vehicle arrival/departure prediction time 22 3 8 8
Next vehicle arrival/departure prediction distance 6 1 2 1
Real-time vehicle location 10 4 3
Availability of information and dissemination media 8 3 2
Identification of service disruptions 15 1 2 3 9
Information on planned detours 18 1 2 8
Schedule information during special events (e.g., Boston 15 1 2 7
Marathon)
Emergency information (e.g., evacuation due to fire) 14 1 2 6
Vehicles/routes available for transfer 8 1 6
Display/announcement of the current route and escalators 17 2 5 3
Real time information on availability of elevators and 4 1 1 1
escalators
Number of cars on the next train 2 1 2
Wi-Fi access points and real-time information on availability 1
Real-time parking availability
OCR for page 24
24
TABLE 4
DISSEMINATION MEDIA USED TO PROVIDE REAL-TIME INFORMATION
Type of Real-Time Information DMS Internet Mobile Interac- Smartphone Two-way Subscrip- Mobile NFC
accessed web/ tive voice applications SMS tion alerts tagging
by PC Internet response
(IVR)
Next vehicle arrival/departure prediction time 19 21 21 11 13 10 12 2 2
Next vehicle arrival/departure prediction 4 6 5 4 3 1 3 NA 1
distance
Real-time vehicle location 2 10 7 2 6 1 2 1 2
Availability of information and dissemination 3 6 6 3 2 2 2 NA 1
media
Identification of service disruptions 10 19 17 7 9 4 10 1 1
Information on planned detours 6 19 17 4 7 4 11 1 1
Schedule information during special events 9 18 16 8 8 4 9 1 1
(e.g., Boston Marathon)
Emergency information (e.g., evacuation due to 7 16 12 7 6 4 9 1 1
fire)
Vehicles/routes available for transfer 3 11 9 7 5 1 2 1
Display/announcement of the current route and 8 8 6 4 3 1 2 1 1
destination
Display/announcement of the current route and 2 3 2 1 1 1 2 1
destination
Number of cars on the next train 2 1 1 1 1
Wi-Fi access points and real-time information 2 2 1 1
on availability
Real-time parking availability 1
other dissemination media (e.g., DMSs, Internet). Second,
11 of the 28 respondents decided to deploy real-time tran-
sit information on mobile devices as a more cost-effective
way of providing real-time information. This response was
expected because, generally, there have been discussions
in the literature and industry about using information on
mobile devices as a way to curb the costs of customer ser-
vice, such as call centers (42).
FIGURE 17 Washington Metropolitan
Area Transit Authority (WMATA) mobile
website (http://www.wmata.com/
mobile/).
FIGURE 18 Harvard University
transit visualization (http://
harvard.transloc.com/m/).
OCR for page 25
25
FIGURE 19 AC Transit Mobile Real-time Information (http://
www.nextbus.com/wireless/miniPrediction.shtml?a=actransit&
r=12&d=12_68_0&s=1002960).
FIGURE 21 Chattanooga Area Regional
Transportation Authority (CARTA) mobile real-
time information (http://bustracker.gocarta.
org/bustime/wireless/html/home.jsp).
The survey explored the use of third parties to develop
mobile applications and the guidelines governing third-
party application development. It is clear from the results
that the majority of agencies that have decided to provide
information on mobile devices are relying on either mobile
content providers or individuals to provide the information
and develop the applications. Thirteen of the 28 respon-
FIGURE 20 BART Mobile website (http://m.
dents indicated that they provide real-time information
bart.gov/wireless/).
(and related information) to third parties for the purposes
Third, only four of the 28 respondents conducted a study of developing mobile applications. Of these 13, 11 agen-
to determine whether or not to deploy real-time transit infor- cies require that application developers register with the
mation on mobile devices. This would indicate that business agency. Of these 11, 10 require that the developers agree
cases or models are not being conducted or constructed to to specific terms of use. Of these 10, five agencies set a
determine whether or not to provide information on mobile threshold on the use of the third-party applications so that
devices. One of the respondents, BART, conducted customer- the agency’s resources are not overwhelmed.
focused research. “Initially (1999) we focused on whether
there was a market and what it wanted. Ongoing research Figure 22 depicts a typical third-party environment in
focuses on [the] awareness of BART mobile services, plat- which content is hosted and managed—in this case one that
form use and future purchasing decisions, data type and use uses SMS as the dissemination media for information.
cases, opportunities for third-party mobile developers using
BART open data, etc.” (interview with Timothy Moore, Figures 23 through 25 show examples of real-time infor-
Website Manager, BART, April 6, 2010). Another respon- mation provided by means of third-party mobile applications.
dent, National Rail (NRail) studied the feasibility of mobile
devices, and Transport for London (TfL) conducted a busi- These survey results indicate two key aspects of provid-
ness case and multiple customer surveys. ing information on mobile devices. First, the majority of
OCR for page 26
26
FIGURE 22 Typical mobile environment using SMS. [Source :
(55 ).]
FIGURE 23 Transit Board™ (http://tsrf.us/cgi-bin/tboard.pl?stop=8334&stop=8383).
FIGURE 24 Third-party TriMet Tracker Application (http://trimet.onmyiphone.net/
arrivals?location_id=5373&route_number=4).
FIGURE 25 Screenshots of BART live arrivals PRO (http://itunes.apple.com/app/
bart-live-arrivals-pro/id307080410?mt=8).
OCR for page 27
27
agencies are not developing applications for mobile devices • iPhone OS (14 respondents)
in-house—they are relying either on individuals or compa- • Windows Mobile (13)
nies to produce mobile applications. Second, several of the • Palm OS/Palm webOS (10)
survey respondents have embraced an “open-data” approach • Research in Motion (10)
by which individual mobile application developers can use • Pocket PC (9)
transit agency data to develop applications. BART and Tri- • Symbian OS (9)
Met have adopted this approach, which has provided con- • A ndroid (9)
siderable savings in terms of information technology staff • Maemo (Nokia) (7)
(who would be developing the applications) and has resulted • Mobile Linux (6)
in innovative and useful applications. Their use of the open- • bada (Samsung) (5)
data approach is discussed further in chapter six. • Other (4)
Regarding the real-time mobile services provided by the Seven of the 28 survey respondents noted that the soft-
respondents, Figure 26 shows the distribution of services. ware they use to provide real-time information on mobile
Figure 27 shows the types of mobile phones on which the devices automatically detects the operating system of the
respondents’ mobile services operate. As expected, near-file customers’ mobile device. This feature facilitates the cus-
communications (NFC) phones (which enable short-range tomers’ use of mobile websites.
communication between the phone handset and another
electronic device) are not common and are not used to a high Only four of the 28 respondents indicated that they
degree to provide real-time information. Their primary use have partnered with mobile phone service providers. Fur-
is for mobile ticketing applications, which is not covered in ther, only two respondents have specific contracts and/or
this report (56, 57 ). agreements with mobile phone service providers, Internet
service providers, or information service providers. This
response was expected, given that the majority of the
respondents provide information that is independent of
mobile phone carriers.
CHARACTERISTICS OF REAL-TIME INFORMATION
PROVIDED ON MOBILE DEVICES
The survey and literature review provided extensive infor-
mation on the characteristics of the information provided on
mobile devices. First, for agencies that use SMS to provide
real-time information, the formats of those types of mes-
sages are similar, given that SMS messages are limited to
FIGURE 26 Percentage of survey respondents using mobile
160 characters (for Latin characters) [or 70 characters for
services to provide real-time transit information.
other alphabets (e.g., Chinese)]. Appendix D, Table D2,
shows examples of messages sent by customers to request
real-time information, and Appendix D, Table D3, shows
examples of the real-time information returned by means of
SMS. Figures 28 and 29 show examples of how to request
real-time information via SMS.
FIGURE 27 Percentage of survey respondents using mobile
device types.
The mobile operating systems covered by the responding FIGURE 28 Real-time information by means of SMS for
agencies, listed for information purposes only and not as an Chicago Transit Authority—Part 1 (http://www.transitchicago.
endorsement of any kind, are as follows: com/riding_cta/how_to_guides/bustrackertext.aspx).
OCR for page 28
28
• BART keeps its mobile services as “platform agnostic”
as possible. Its mobile website is as simple and func-
tional as possible and it is not optimized for one mobile
browser or another.
• CityBus stated that if mobile devices are capable of
browsing a web page, customers will be able to receive
real-time information.
• M TA Metro–North Railroad and Metropolitan
Transportation Commission (MTC) use UsableNet
to provide accessible formats for all types of mobile
devices, independent of the platforms used.
• Rejseplanen A/S uses standard WAP or XHTML web
design.
• Specific applications have been developed for the
iPhone and the BlackBerry platforms for Société de
transport de Laval (STL). The mobile website is acces-
sible to most other smartphones. The SMS service is
available to all cell phones.
• By releasing the TriMet data feed to third-party devel-
opers, applications have been developed for most
FIGURE 29 Real-time information by means of SMS for
Chicago Transit Authority—Part 2 (http://www.transitchicago. mobile device platforms.
com/riding_cta/how_to_guides/bustrackertext.aspx).
One aspect of accessibility that has to be taken in account
Some survey respondents provided their mobile website is the legibility of nontext displays, such as maps. Tradi-
addresses, as shown in Table 5. tional transit maps do not necessarily display well on mobile
devices because of the “low processing power, limited stor-
age, input capability and display area” (58).
TABLE 5
RESPONDENT MOBILE WEBSITES
The survey asked whether the responding agency thought
Agency Name Mobile Website Address
that real-time information should be provided on mobile
AC Transit http://www.nextbus.com/wireless/miniRoute. devices by means of a “pull” action (e.g., accessing a mobile
shtml?a=actransit
website and making a selection) or a “push” action (e.g., push-
BART http://m.bart.gov
ing out an SMS or e-mail with real-time information when
Carris http://www.carris.pt new information is available) or both. Eight agencies stated
that both should be used, seven said that only pull should be
COTA http://classic.cota.com/realtime.asp
used, and one said that only push should be used. The reasons
CityBus http://www.gocitybus.com/myrideweb.html
a particular approach was selected include the following:
MNCR http://www.mta.info
MTC http://m.511.orga
• For both push and pull:
PACE http://www.pacebus.com – “It is hard to consider push versus pull as a discrete
decision. It is just part of the delivery mechanics
RA/S http://mobil.rejseplanen.dk
in an array of mobile uses cases. It depends mostly
STL http://m.stl.laval.qc.ca
upon the medium customers choose, where they
SL http://mobil.sl.se
are when they want to interact with the information
TCPT http://atlas.tripplanner.fi/paras/?v=pda&lang=en
(e.g., standing at the platform, in transit to a station
TheBus http://hea.thebus.org or on the service), and ultimately what customers
choose most when given the options.”
TAS http://m.trafikanten.no
– “We endeavor to provide the information in as many
TMovia http://mobil.moviatrafik.dk
formats as possible, especially via technologies that
TfL http://www.tfl.gov.uk/tfl/livetravelnews mobileservices/
are accessible on the go.”
TriMet http://m.trimet.org
– “It depends on the actual use situation. If we are
aTo be deployed in the future.
talking about commuters then a push service might
be preferred, but a pull approach might be the only
Second, the survey explored the accessibility of real-time solution for people searching here and now.”
information on mobile devices. Selected responses regard- – “In order to meet customers’ specific requirements
ing accessibility are as follows: we offered both options.”
OCR for page 29
29
– “A pull method with specific selections is preferred – JavaScript Object Notation; and
for most applications. This limits the data transmis- – SMS standard.
sion to small specific request on demand. Some real
time updates of vehicle positions on maps require a Through the literature review, other mobile formatting
push to supply the data as conditions change.” standards related to providing real-time information on
• For pull: mobile devices include the following (59):
– “We believe this is what our users want.”
– “On-demand provides the customer with the latest • WAP,
data when requested.” • Wireless markup language,
– “We don’t have the services yet to push information.” • WAP cascading style sheet,
• User agent profile,
The respondents used a wide variety of standards, which • Wireless transport layer security, and
can be separated into two categories: transit-specific data • Wireless identity module.
standards and mobile formatting standards. The standards
are as follows: Finally, it is critical that the real-time information pro-
vided on mobile devices be reliable and accurate; therefore,
• Transit-specific data standards: one element of the survey covered these topics. The differ-
– Service interface for real-time information ence between reliability and accuracy is that reliability is the
(SIRI), which “is an [European Committee for ability of a system to perform its functions consistently and
Standardization] XML protocol to allow distributed without failure, and accuracy is closeness to fact. In terms of
computers to exchange real-time information about reliability, respondents stated the following:
public transport services and vehicles” (http://
www.kizoom.com/standards/siri/). • Monitoring is conducted at 5-min intervals; there are
– Datex II, which is the “reference for all applica- quarterly field verifications and log checks. Given lim-
tions requiring access to dynamic traffic and ited quality assurance/quality control resources, cus-
t ravel related information in Europe” (http:// tomer feedback is also used.
www.itsradarinternational.info/News-Events / • The agency relies on the real-time application service
L at est-News / I n it ia l-relea se - of-DAT EX-I I- provider (ASP) to ensure reliability.
Version-2_0-data-exchange-specifications;-CEN- • System reliability measurements are taken each month
standardisation-progressing.htm, accessed May based on the availability (e.g., up-time) of the major
18, 2010). systems. Depending on how well the system scores,
– Identification of fixed objects in public transport contract language allows the agency to monetarily
(IFOPT), which “defines a model and identification penalize the contractor to up to $10,000 per month.
principles for the main fixed objects related to pub- • In a regional context, one respondent depends on the
lic access to Public Transport (e.g., stop points, stop public transit authorities that provide the real-time
areas, stations, connection links, entrances, etc.)” information.
(http://www.kizoom.com/standards/ifopt/). • All real-time information originates from the same
– Transmodel, which “is a reference data model for source, which is monitored continuously by customer
Public Transport operations developed within sev- service personnel. Also, various real-time and weekly
eral European projects” (http://www.transmodel. reporting tools are used to monitor the system.
org/en/cadre1.html, accessed May 18, 2010). • Validation is conducted throughout the data collection
– TransXChange, which “is the UK nationwide stan- process.
dard for exchanging bus schedules and related data” • A few respondents indicated that they do not monitor
(http://www.dft.gov.uk/transxchange/, accessed May system reliability.
18, 2010).
• Mobile formatting standards: In terms of monitoring accuracy, agencies indicated the
– XHTML Mobile Profile, which is a subset of following:
XHTML that supports features for mobile devices;
– Standard hypertext transfer protocol (http), which • IT has built logic into the application to monitor accuracy.
is a set of rules for exchanging files on the Internet; • As of April 2010, one regional agency respondent is
– XML, which is a flexible text format for creating in the process of defining its performance monitoring
electronic documents; procedures. The process will include comparing infor-
– Representational state transfer, which is an “archi- mation received by the mobile device to ground truth
tectural style of networked systems” (http://www. of what the user is experiencing. This respondent will
xfront.com/REST-Web-Services.html, accessed May also work with each agency to explore its performance
18, 2010); monitoring process.
OCR for page 30
30
• Agencies use experience data (how much time it takes • Agencies make historical comparison of predictions
for the bus to go from one stop to the next) for routes at with data collected through the AVL system.
different times during different day types. • Agencies rely on the real-time ASP to ensure accuracy.
