Use and Deployment of Mobile Device Technology for Real-Time Transit Information (2011)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

22 CHAPTER THREE CHARACTERISTICS OF UNDERLYING TECHNOLOGY, MOBILE TECHNOLOGY, AND MOBILE INFORMATION The synthesis survey covered several key characteristics of the underlying technologies that are required to generate the infor- mation disseminated on mobile devices, of the mobile devices and operating systems, and of the actual mobile messages. See Table 1 and Appendix C for a list of the 28 responding agencies (representing a 100% response rate). Before examining these characteristics, the overall annual ridership and modes oper- ated by each respondent were noted. Annual ridership ranged from 1 million (fixed-route bus and tourist van respondent) to 101.5 million (TriMet) to 1 billion (for an international respon- dent—National Rail in the United Kingdom). Total annual ridership for each agency and the change in ridership for each responding agency between 2005 and 2010 are shown in Appendix D, Table D1. UNDERLYING TECHNOLOGY AND REAL-TIME MOBILE MESSAGE TYPES Table 2 shows the types of underlying technology being used. The survey respondents report a wide variation in the types of real-time information and the frequency with which it is updated, as shown in Table 3. In terms of the types of real-time information, the most prevalent information that is updated on an ongoing basis is next vehicle arrival/departure prediction time, followed by information on planned detours, display/announcement of the current route and destination, identification of service disruptions, and schedule information during special events. As expected, the most prevalent infor- mation that is updated based on a specific threshold or time period is next vehicle arrival/departure prediction time. The next most prevalent information updated with this frequency is identification of service disruptions and display/announce- ment of the current route and destination. Finally, the most prevalent information updated when requested by customers (on demand) is identification of service disruptions, followed by next vehicle arrival/departure prediction time and informa- tion on planned detours. Although these results are not unex- pected, it is interesting to note that only one type of real-time information is updated when the dissemination media are not functioning (identification of service disruptions), and none of the respondents provide real-time parking information. TABLE 1 AGENCIES THAT RESPONDED TO QUESTIONNAIRE Agency Name Abbreviation City AC Transit AC Transit Oakland, CA Afifi Group Afifi Nazareth, Israel Bay Area Rapid Transit District BART Oakland, CA Carris Carris Lisbon, Portugal Central Ohio Transit Authority COTA Columbus, OH Chapel Hill Transit CHT Chapel Hill, NC CityBus CityBus Lafayette, IN Fresno Area Express FAX Fresno, CA Greater Bridgeport Transit Authority GBTA Bridgeport, CT Kansas City Area Transporta- tion Authority KCATA Kansas City, MO Metropolitan Atlanta Rapid Transit Authority MARTA Atlanta, GA METRO Transit METRO Oklahoma City, OK Metropolitan Transportation Commission MTC Oakland, CA MTA Metro–North Railroad MNCR New York, NY National Rail NRail London, UK Pace Suburban Bus PACE Arlington Heights, IL Portage Area Regional Transportation Authority PARTA Kent, OH Regional Transportation Com- mission of Washoe County RTC Reno, NV Rejseplanen A/S RA/S Valby, Denmark Société de transport de Laval STL Laval, Québec, Canada Sound Transit ST Seattle, WA Stockholm Public Transport SL Stockholm, Sweden Tampere City Public Transport TCPT Tampere, Finland TheBus—Oahu Transit Services, Inc. TheBus Honolulu, HI Trafikanten AS TAS Oslo, Norway Trafikselskabet Movia TMovia Valby, Denmark Transport for London TfL London, UK TriMet TriMet Portland, OR

23 One aspect of this synthesis was to determine the use of mobile devices as dissemination media versus other known channels. As shown in Table 4, mobile dissemination media, specifically mobile web/Internet, smartphone applications, two-way SMS, mobile tagging, and near-field communica- tion, were the most prevalent for the survey respondents. As expected, the Internet accessed by a personal computer was the next most prevalent way of disseminating real- time information, followed by DMSs and interactive voice response (IVR). These results reflect not only that this syn- thesis is focused on information provided on mobile devices, but that agencies are moving away from DMSs, which are more costly for dissemination owing to their operations (e.g., power and communication) and maintenance requirements. It is interesting to note that several agencies reported using mobile tagging technology, which is a relatively new mobile technology. The use of mobile websites by several agencies is shown in Figures 17 through 21. MOBILE TECHNOLOGY The survey covered several aspects of mobile technology, including the reasons for providing real-time information on mobile devices, the types of mobile services provided, and whether or not agencies partnered with mobile tele- phone providers to provide information. First, the survey results indicated that 17 of the 28 respondents decided to deploy real-time transit information on mobile devices to augment providing real-time information by means of TABLE 2 UNDERLYING TECHNOLOGY USED BY SURVEY RESPONDENTS Technology No. of Respondents Automatic vehicle location (AVL) 23 Alert subscription system 13 Near-field communication (NFC) capability 2 Mobile tagging software (e.g., Microsoft Tag, Semacode, 2D/3D barcodes) 3 Computer-aided dispatch (CAD) 18 Schedule adherence functionality 13 Real-time arrival prediction software 25 On-board next stop announcements (visual) 19 On-board next stop announcements (audio) 21 On-board driver voice communication system 15 On-board data communication system 11 Real-time map display at stop/station 2 Two-way messaging capability (e.g., using short message service (SMS) [text messaging] 16 Light-emitting diode (LED) 9 How many with audio capability (e.g., using a push-button or infrared device to “read” DMS display)? 1 Liquid crystal display (LCD) 3 How many with audio capability? 0 Other: Please specify. 1 How many “other” with audio capability? 0 TABLE 3 FREQUENCY OF REAL-TIME INFORMATION Type of Real-Time Information Real-Time Information Frequency Update on an ongoing basis Update when dis- semination media are not functioning Update when no information available Update per defined threshold When requested by customers (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 Marathon) 15 1 2 7 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 escalators 4 1 1 1 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

24 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/). TABLE 4 DISSEMINATION MEDIA USED TO PROVIDE REAL-TIME INFORMATION Type of Real-Time Information DMS Internet accessed by PC Mobile web/ Internet Interac- tive voice response (IVR) Smartphone applications Two-way SMS Subscrip- tion alerts Mobile tagging NFC Next vehicle arrival/departure prediction time 19 21 21 11 13 10 12 2 2 Next vehicle arrival/departure prediction distance 4 6 5 4 3 1 3 NA 1 Real-time vehicle location 2 10 7 2 6 1 2 1 2 Availability of information and dissemination media 3 6 6 3 2 2 2 NA 1 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 (e.g., Boston Marathon) 9 18 16 8 8 4 9 1 1 Emergency information (e.g., evacuation due to fire) 7 16 12 7 6 4 9 1 1 Vehicles/routes available for transfer 3 11 9 7 5 1 2 1 Display/announcement of the current route and destination 8 8 6 4 3 1 2 1 1 Display/announcement of the current route and destination 2 3 2 1 1 1 2 1 Number of cars on the next train 2 1 1 1 1 Wi-Fi access points and real-time information on availability 2 2 1 1 Real-time parking availability 1 FIGURE 18 Harvard University transit visualization (http:// harvard.transloc.com/m/).

25 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- dents indicated that they provide real-time information (and related information) to third parties for the purposes of developing mobile applications. Of these 13, 11 agen- cies require that application developers register with the agency. Of these 11, 10 require that the developers agree to specific terms of use. Of these 10, five agencies set a threshold on the use of the third-party applications so that the agency’s resources are not overwhelmed. Figure 22 depicts a typical third-party environment in which content is hosted and managed—in this case one that uses SMS as the dissemination media for information. Figures 23 through 25 show examples of real-time infor- mation provided by means of third-party mobile applications. These survey results indicate two key aspects of provid- ing information on mobile devices. First, the majority of 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 20 BART Mobile website (http://m. bart.gov/wireless/). Third, only four of the 28 respondents conducted a study to determine whether or not to deploy real-time transit infor- mation on mobile devices. This would indicate that business cases or models are not being conducted or constructed to determine whether or not to provide information on mobile devices. One of the respondents, BART, conducted customer- focused research. “Initially (1999) we focused on whether there was a market and what it wanted. Ongoing research focuses on [the] awareness of BART mobile services, plat- form use and future purchasing decisions, data type and use cases, opportunities for third-party mobile developers using BART open data, etc.” (interview with Timothy Moore, Website Manager, BART, April 6, 2010). Another respon- dent, National Rail (NRail) studied the feasibility of mobile devices, and Transport for London (TfL) conducted a busi- ness case and multiple customer surveys.

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

27 agencies are not developing applications for mobile devices in-house—they are relying either on individuals or compa- nies to produce mobile applications. Second, several of the survey respondents have embraced an “open-data” approach by which individual mobile application developers can use transit agency data to develop applications. BART and Tri- Met have adopted this approach, which has provided con- siderable savings in terms of information technology staff (who would be developing the applications) and has resulted in innovative and useful applications. Their use of the open- data approach is discussed further in chapter six. Regarding the real-time mobile services provided by the respondents, Figure 26 shows the distribution of services. Figure 27 shows the types of mobile phones on which the respondents’ mobile services operate. As expected, near-file communications (NFC) phones (which enable short-range communication between the phone handset and another electronic device) are not common and are not used to a high degree to provide real-time information. Their primary use is for mobile ticketing applications, which is not covered in this report (56, 57). FIGURE 26 Percentage of survey respondents using mobile services to provide real-time transit information. FIGURE 27 Percentage of survey respondents using mobile device types. The mobile operating systems covered by the responding agencies, listed for information purposes only and not as an endorsement of any kind, are as follows: • iPhone OS (14 respondents) • Windows Mobile (13) • Palm OS/Palm webOS (10) • Research in Motion (10) • Pocket PC (9) • Symbian OS (9) • Android (9) • Maemo (Nokia) (7) • Mobile Linux (6) • bada (Samsung) (5) • Other (4) Seven of the 28 survey respondents noted that the soft- ware they use to provide real-time information on mobile devices automatically detects the operating system of the customers’ mobile device. This feature facilitates the cus- tomers’ use of mobile websites. Only four of the 28 respondents indicated that they have partnered with mobile phone service providers. Fur- ther, only two respondents have specific contracts and/or 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 160 characters (for Latin characters) [or 70 characters for 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 28 Real-time information by means of SMS for Chicago Transit Authority—Part 1 (http://www.transitchicago. com/riding_cta/how_to_guides/bustrackertext.aspx).

28 FIGURE 29 Real-time information by means of SMS for Chicago Transit Authority—Part 2 (http://www.transitchicago. com/riding_cta/how_to_guides/bustrackertext.aspx). Some survey respondents provided their mobile website addresses, as shown in Table 5. TABLE 5 RESPONDENT MOBILE WEBSITES Agency Name Mobile Website Address AC Transit http://www.nextbus.com/wireless/miniRoute. shtml?a=actransit BART http://m.bart.gov Carris http://www.carris.pt COTA http://classic.cota.com/realtime.asp CityBus http://www.gocitybus.com/myrideweb.html MNCR http://www.mta.info MTC http://m.511.orga PACE http://www.pacebus.com RA/S http://mobil.rejseplanen.dk STL http://m.stl.laval.qc.ca SL http://mobil.sl.se TCPT http://atlas.tripplanner.fi/paras/?v=pda&lang=en TheBus http://hea.thebus.org TAS http://m.trafikanten.no TMovia http://mobil.moviatrafik.dk TfL http://www.tfl.gov.uk/tfl/livetravelnews mobileservices/ TriMet http://m.trimet.org aTo be deployed in the future. Second, the survey explored the accessibility of real-time information on mobile devices. Selected responses regard- ing accessibility are as follows: • 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. • MTA 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 mobile device platforms. One aspect of accessibility that has to be taken in account is the legibility of nontext displays, such as maps. Tradi- 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). The survey asked whether the responding agency thought that real-time information should be provided on mobile devices by means of a “pull” action (e.g., accessing a mobile website and making a selection) or a “push” action (e.g., push- ing out an SMS or e-mail with real-time information when new information is available) or both. Eight agencies stated that both should be used, seven said that only pull should be used, and one said that only push should be used. The reasons a particular approach was selected include the following: • For both push and pull: – “It is hard to consider push versus pull as a discrete decision. It is just part of the delivery mechanics in an array of mobile uses cases. It depends mostly upon the medium customers choose, where they are when they want to interact with the information (e.g., standing at the platform, in transit to a station or on the service), and ultimately what customers choose most when given the options.” – “We endeavor to provide the information in as many formats as possible, especially via technologies that are accessible on the go.” – “It depends on the actual use situation. If we are talking about commuters then a push service might be preferred, but a pull approach might be the only solution for people searching here and now.” – “In order to meet customers’ specific requirements we offered both options.”

29 – JavaScript Object Notation; and – SMS standard. Through the literature review, other mobile formatting standards related to providing real-time information on mobile devices include the following (59): • WAP, • Wireless markup language, • WAP cascading style sheet, • User agent profile, • Wireless transport layer security, and • Wireless identity module. Finally, it is critical that the real-time information pro- vided on mobile devices be reliable and accurate; therefore, one element of the survey covered these topics. The differ- ence between reliability and accuracy is that reliability is the ability of a system to perform its functions consistently and without failure, and accuracy is closeness to fact. In terms of reliability, respondents stated the following: • Monitoring is conducted at 5-min intervals; there are quarterly field verifications and log checks. Given lim- ited quality assurance/quality control resources, cus- tomer feedback is also used. • The agency relies on the real-time application service provider (ASP) to ensure reliability. • System reliability measurements are taken each month based on the availability (e.g., up-time) of the major systems. Depending on how well the system scores, contract language allows the agency to monetarily penalize the contractor to up to $10,000 per month. • In a regional context, one respondent depends on the public transit authorities that provide the real-time information. • All real-time information originates from the same source, which is monitored continuously by customer service personnel. Also, various real-time and weekly reporting tools are used to monitor the system. • Validation is conducted throughout the data collection process. • A few respondents indicated that they do not monitor system reliability. In terms of monitoring accuracy, agencies indicated the following: • IT has built logic into the application to monitor accuracy. • As of April 2010, one regional agency respondent is in the process of defining its performance monitoring procedures. The process will include comparing infor- mation received by the mobile device to ground truth of what the user is experiencing. This respondent will also work with each agency to explore its performance monitoring process. – “A pull method with specific selections is preferred for most applications. This limits the data transmis- sion to small specific request on demand. Some real time updates of vehicle positions on maps require a push to supply the data as conditions change.” • For pull: – “We believe this is what our users want.” – “On-demand provides the customer with the latest data when requested.” – “We don’t have the services yet to push information.” The respondents used a wide variety of standards, which can be separated into two categories: transit-specific data standards and mobile formatting standards. The standards are as follows: • Transit-specific data standards: – Service interface for real-time information (SIRI), which “is an [European Committee for Standardization] XML protocol to allow distributed computers to exchange real-time information about public transport services and vehicles” (http:// www.kizoom.com/standards/siri/). – Datex II, which is the “reference for all applica- tions requiring access to dynamic traffic and travel related information in Europe” (http:// www.itsradarinternational.info/News-Events / Latest-News / In it ia l-release-of-DATEX-II- Version-2_0-data-exchange-specifications;-CEN- standardisation-progressing.htm, accessed May 18, 2010). – Identification of fixed objects in public transport (IFOPT), which “defines a model and identification principles for the main fixed objects related to pub- lic access to Public Transport (e.g., stop points, stop areas, stations, connection links, entrances, etc.)” (http://www.kizoom.com/standards/ifopt/). – Transmodel, which “is a reference data model for Public Transport operations developed within sev- eral European projects” (http://www.transmodel. org/en/cadre1.html, accessed May 18, 2010). – TransXChange, which “is the UK nationwide stan- dard for exchanging bus schedules and related data” (http://www.dft.gov.uk/transxchange/, accessed May 18, 2010). • Mobile formatting standards: – XHTML Mobile Profile, which is a subset of XHTML that supports features for mobile devices; – Standard hypertext transfer protocol (http), which is a set of rules for exchanging files on the Internet; – XML, which is a flexible text format for creating electronic documents; – Representational state transfer, which is an “archi- tectural style of networked systems” (http://www. xfront.com/REST-Web-Services.html, accessed May 18, 2010);

30 • Agencies use experience data (how much time it takes for the bus to go from one stop to the next) for routes at different times during different day types. • Agencies make historical comparison of predictions with data collected through the AVL system. • Agencies rely on the real-time ASP to ensure accuracy.