Click for next page ( 23


The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



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 22
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 22
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 22
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 22
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 22
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 22
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 22
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 22
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.