 |
 |
 |
 |
This document also available for downloading as a
Microsoft® Word file (2.02 Mbytes)
or an Adobe
Acrobat PDF file (187 Kbytes).
 |
 |
 |
 |
What is 511?
On March 8, 1999, the U.S. Department of Transportation (USDOT) petitioned the Federal Communications Commission (FCC) to designate a nationwide three-digit telephone number for traveler information. On July 21, 2000, the FCC designated 511 as the United States' national travel information telephone number. The FCC ruling leaves nearly all implementation issues and schedules to state and local agencies and telecommunications carriers. In 2005, the FCC will review our progress in implementing 511.
What is the 511 Deployment Coalition?
In early 2001, mindful of both the opportunity and challenge that 511 presents, the American Association of State Highway and Transportation Officials (AASHTO), in conjunction with many other organizations including the American Public Transportation Association (APTA) and the Intelligent Transportation Society of America (ITS America), with the support of the USDOT, established the 511 Deployment Coalition (Coalition). An executive-level Policy Committee and a supporting Working Group were established to conduct the work of the Coalition. Membership of the Coalition draws from all levels and types of government agencies, various segments of the telecommunications industry and the fields of consulting, system integration and information service provision.
The Coalition has made its goal "the timely establishment of a national 511 traveler information service that is sustainable and provides value to users available to a majority of Americans by 2005." The Coalition recognizes that 511 services will be developed in a bottom-up fashion with state and local transportation agencies establishing services in areas and timeframes determined by them.
As of March 31, 2003, 511 was available statewide in nine states - Arizona, Kentucky, Iowa, Minnesota, Montana, Nebraska, North Dakota, South Dakota, Utah and on a limited basis in the State of Washington - and in the Greater Cincinnati / Northern Kentucky Area; the I-81 Corridor in Virginia; Orlando, Miami and Dade, Broward and Palm Beach Counties in Florida; and San Francisco. With these deployments, 511 serves ten of the top 60 metropolitan markets in the United States.
511 services are also expected to launch in 2003 in Alaska, Boston, Kansas, Maine, Missouri, Nevada, New Hampshire, New Mexico, North Carolina, Oregon and Vermont. In total, thirty-nine states and the District of Columbia have received federal grants to begin planning their 511 deployments.
The Coalition has developed the "Implementation Guidelines for Launching 511 Services" to assist implementers in their efforts to develop quality systems and to lay the foundation for ultimately establishing a consistent nationwide 511 service. The Implementation Guidelines are comprised of both Content and Consistency Guidelines. 511 deployers' use of these Guidelines will lead to a certain degree of expectation where users will understand the level of highway information, public transportation information and weather information that they will receive. The Guidelines are available at http://www.its.dot.gov/511/511ver11.htm.
What is a Deployment Assistance Report?
The Guidelines cover both content and consistency for 511 systems and this Deployment Assistance Report (DAR) is an outgrowth of the System Considerations section of the Consistency Guidelines. Inter-regional interoperability was raised in item 2.10 of the System Considerations section, where the issue of how 511 services interconnect was flagged as a future issue to be dealt with because a Guideline could not be established at that time. This issue is addressed in this DAR as deployers have accumulated the necessary body of knowledge and experience on the topic contained herein since publishing the Guidelines.
This DAR is the fourth in a series published by the Coalition:
DARs result from the focused efforts of Coalition volunteers. While in each prior case, these efforts originated to support development of the Guidelines; the Coalition members determined that much was learned in exploring each area that should be shared with the broader deployment community. Thus, each volunteer effort has concluded its activity by electronically publishing an information report.
Purpose of this Deployment Assistance Report
The 511 Deployment Coalition recognizes that 511 services will be developed in a bottom-up fashion by state and local transportation agencies – with the close collaboration of the private sector – establishing services in areas and timeframes determined by them.
The purpose of this DAR is to offer 511 implementers technical advice on how to deal with callers who logically want information on transportation facilities and services outside of the area served by your 511 system. Callers to 511 may not know which jurisdiction they are in nor where the boundary for the next jurisdiction is – they just want information about the travel conditions ahead of them. This is an issue of interoperability between state borders and within states where there may be a metropolitan 511 system(s) and a statewide system as well. In this DAR, the terms sharing and transferring are used interchangeably.
A real world example: since December 2002, the metropolitan Cincinnati system (ARTIMIS) has been successfully passing Kentucky suburban incident information into the Kentucky statewide Condition Acquisition Reporting System (CARS-511) using Traffic Management Data Dictionary (TMDD) ITS standards, implemented in Traveler Information Markup Language (TIML) / eXtensible Markup Language (XML). Kentucky traffic events reported in ARTIMIS are imported to the CARS-511 system for fully automated reporting without any manual data re-entry. Although the two 511 systems were developed at different times and independently, the standards are allowing seamless data exchange as no call transfers or manual processing are necessary. This DAR will provide information on how you may also achieve this kind of interoperability.
511 implementers need to consider local, regional and corridor travel that require information presentation on their 511 system.
This DAR is intended for the planners and implementers of 511 systems.
Where to Find More Information on 511?
Information on the 511 Deployment Coalition, including DARs, educational materials, a marketing toolkit, supporting resource materials and additional useful references for 511 implementers may be found at the following websites:
Acknowledgements
The 511 Deployment Coalition Working Group established a task force with the purpose of developing this DAR to examine regional interoperability by the transferring of calls and data amongst 511 services. All members of the task force contributed technical information, cost data and editorial assistance to enable the assembling of this report:
The 511 service will be available in many areas of the country and it is believed that users will have an expectation that information relating to areas outside of their region will be available in a single call. In years past, calling Directory Assistance (411) allowed telephone users to access only local directory information. As the Information Age has matured, users dialing 411 are now able to request information for any city and state in the country. It is believed that this type of expectation will pervade into 511 services as well.
An increasing number of 511 systems share boundaries and / or have significant travel in between them. This is also true along major travel corridors throughout the country. Callers in one metropolitan area may wish to dial 511 to find information not just for their local travels, but for their entire trip, which might include traveling through other metropolitan areas or regions and crossing state borders.
As a starting point, consider the following examples:
Based on the above examples, it is assumed that callers to one 511 system are likely to welcome the opportunity to access information from another 511 system. Regional interoperability is both an interstate and intrastate issue, especially with many states considering both metropolitan and statewide 511 systems. Today, 511 systems in Utah and Arizona are exploring how to share information, Virginia and North Carolina are examining 511 call transfer between toll-free numbers in their states and Kentucky has both a statewide system and one operating in its Cincinnati suburbs.
Kentucky has a statewide system and a regional system serving the Greater Cincinnati / Northern Kentucky Area. The regional system has a menu item for the statewide system. While there is not direct access from the statewide system to the regional system, an interface has been developed that automatically updates the statewide system with traffic data from the regional system.
The 511 Deployment Coalition will continue to monitor these and other data and call transfer situations and look at the benefits, challenges and opportunities of both options.
Depending on how 511 is marketed, and most deployers today use the same 511 logo, consumers may have the expectation of receiving inter-regional information. 511 implementers need to take a local, regional and corridor travel focus and deal with regional interoperability as the customer does not know, or care, about boundaries and political jurisdictions.
The 511 Deployment Coalition released its vision for a mature national 511 service in its 511 National Progress Report (available at: http://www.its.dot.gov/511/511.htm, which notes 511 deployment progress to date. Relevant to regional interoperability in the vision is that 511 will be established "through locally deployed interoperable systems." Clearly, this means that callers to one locally deployed system should be able to get information about areas outside that system for the vision to become reality. Later this year, for example, New Hampshire, Vermont and Maine will share all their travel reports automatically. Maine will also import reports from the National Park Service travel information system deployed in Acadia National Park, so that park information is available via data transfer throughout the three states.
The Coalition recognizes that national interoperability of local implementations requires that complex issues be identified and resolved and the Coalition is examining these issues.
N11 systems, by design, are not national in scope. Only 411 gives the appearance of being national in scope and that is accomplished with an integrated database behind the systems which its business model supports. With the overlap and varied boundaries of agencies, regions, travel patterns and the unknowns of cellular routing, 511 deployers need to look beyond their borders to make 511 a success with the traveling public. If 511 developers, deployers and operators accomplish regional interoperability through data sharing, then we may achieve national interoperability ultimately as well. This national interoperability may ultimately yield a 511 system where the caller may be asked, "City and state, please."
Whether considering a call transfer or a data transfer option, the current expectation is not for full national availability of information via a local 511 service, rather for full information availability within a region plus relevant travel corridors to and from the region.
For those implementing systems, this DAR is intended to provide you with the best information available on options for call transfers and data sharing. These are the primary means available today to provide information from outside your region to callers.
Data transfer / sharing issues concern how data from other 511 systems might be accessed by a local 511 service as an alternative to transferring calls between services. Within this topic, we will investigate the concept of incorporating information regarding key travel corridors beyond the borders of a 511 service's coverage area.
Questions and Issues Regarding Data Transferability are:
Members of the task force agreed that agencies receiving information from other 511 implementers should have the final decision as to what information is made available to their users. As such, implementing agencies should make all, or as much as possible, of their data and information available in electronic form to other agencies for inclusion in the receiving agency's 511 system, although the final decision on what data to provide resides with the implementing agency.
This available data may take many forms. For example, the I-95 Corridor Coalition uses a system called the Information Exchange Network (IEN) that directly links numerous public agencies, or their representatives, through a private network of computers and common databases. This system requires each participating agency to enter information into a stand-alone database when an incident or event occurs that seems, in the judgment of the entering agency, to be of high enough importance to be shared with other agencies along the corridor. Examples of such incidents are: Interstate highway closures due to accidents or other significant events; severe weather conditions limiting roadway speeds; etc. The system does not list every available roadway in its database, but system users are able to include information on roadways other than those listed in available data entry space. Incidents are quantified regarding impact and inclusion in the system's database by the entering agency, however the decision on use and / or inclusion in a local agency's Advanced Traveler Information System (ATIS) falls to the receiving agency. Though the database is available to a receiving agency directly, currently there are no automated links between the IEN and any agency's ATIS system.
There is a concern that some agencies will be asked to "drink from a fire hose" with more information than they are able to process being delivered to them on a regular basis. Cross border exchanges can and should include as much detail as in-state exchanges if possible. There are at least two other models available: information transfer sent only on request and specific request / reply pairs for specific information. For example, it could be that agencies outside of an immediate region or corridor may only be interested in information on airports or major access points.
Implementing agencies should provide their data sets in the SAE ATIS (J2354) message sets, available at: http://www.sae.org/servlets/productDetail?PROD_TYP=STD&PROD_CD=J2354_199911. To obtain the latest draft version of the standard from the SAE ATIS committee contact Joel Markowitz (JMarkowitz@mtc.ca.gov) or David Kelley (davidkelley@ITSware.Net).
The SAE ATIS (J2354) standard has many important components for 511 systems, including transit information and vehicle routing.
Current 511 systems receive data from traffic management centers (TMCs) in standard format developed by AASHTO / Institute of Transportation Engineers (ITE) TMDD Committee. "Message Sets for External Traffic Management Center Communications" (MS/ETMCC) is the exact name of the approved Abstract Syntax Notation number One (ASN.1) message sets which are currently being updated in an "Expedited" standards process. The TMDD Committee has agreed to publish XML versions of its messages alongside ASN.1 in future releases. Currently the committee-approved standard for traffic event exchanges is the Event Report Message (ERM) of MS/ETMCC, as approved by the TMDD Committee.
From this data output, receiving agencies can either map data directly into their own systems or translate the data into a format that may be input to their systems.
The task force had considerable discussion over how wide a geographic area should shared system information be provided. Some members of the task force believe that any system should have the opportunity to provide information on areas covered by any other system nationwide. However, the reality of providing this type of interface is technically daunting, especially when keeping in mind the goal of providing basic information on another region. Implementing a solution that allows updated information from all 511 systems to be received at and be available within a local 511 system requires a much larger database, a data interface and a substantial menu structure from which a user might select their information. Instead of storing all the information locally, an alternative is to make a real-time request / reply transaction to the appropriate 511 system to get the requested data. This process could take several seconds though, making each call longer and increasing delay in response times.
This is especially true with regard to the nature of many of the incidents reported on ATIS systems available today. The time required to clear traffic accidents and their resulting delays are difficult to determine at best. The posting of an incident that requires a road closure can have an "estimated" time for clearing, but many factors can contribute to this estimate being off by minutes, hours or, in some cases, days. For this reason, agencies receiving data from other systems must use editorial judgment on whether the inclusion of certain information has real value to their users. Similarly, agencies providing information on a local level may wish to carefully format the information being provided to agencies outside of the local area.
Consider a road closure due to an overturned truck on an Interstate highway. The closure may involve a clean up that will take 2-3 hours and the local agency may provide this information to its local users as well as agencies outside of the local area. Most likely, any agency within a 3-hour drive of the area would find the information valuable to its users. However is this information as valuable to a user connecting from an area 800 miles away? There may be a time zone change and even with air travel to the new destination, any information garnered prior to the start of the trip will likely have changed, and the time of day – rush hour, overnight or midday – will affect any residual tie-up in the area.
The inclusion of this information on a system outside of the local area is one that the receiving agency will have to weigh on its own. Even in select regions or corridors, where vast amounts of data are available to known and subscribing agencies, there does not appear to be a universal answer to the issue of sharing data and information.
In the greater Cincinnati / Northern Kentucky area, the ARTIMIS system has a menu selection that will transfer calls directly to the Kentucky Statewide system. During January of 2003, only a few hundred calls were transferred. Data from the ARTIMIS system is transferred to the statewide system via a recently developed interface. As an example of the types of information agencies might share, the Kentucky statewide system is a CARS-511 implementation and provides information on the National Highway System (NHS) roadways. The ARTIMIS system focuses on the Greater Cincinnati area and offers a much more detailed view of regional freeway traffic conditions as well as transit, ridesharing, construction, special events and airport limo service.
In Virginia, the Virginia Operational Information System (VOIS) shares maintenance-related activities that impact traffic flow, as well as other items. The system, which at one time required dedicated workstations, now allows access through a password-protected Internet connection. This allows for a higher level of input even from agency representatives outside of VDOT.
In California, Caltrans would like to make every region's information available to every other region in the state and beyond. Given California's large size and separated urban areas, the regions can almost be thought of as separate states. Rather than attempt to reach a consensus as to what information should or can be shared, the model calls for each participating agency to post their output on an "extranet" file transfer protocol (FTP) site. It would then be up to 511 implementers wishing to use information from other systems to sign up with the originating agency for access to the FTP site so as to be able to download / parse the messages for inclusion into their system. For example, if TravInfo® wants Caltrans information on road closures / snow chain requirements / incidents on I-80 east of the San Francisco Bay Area and into the Sierra Nevadas, they would only have to select the I-80 messages out of the Sacramento Council of Governments' Central California and the Lake Tahoe / Sierra Nevada 511 systems.
Writing the ATIS / 511 format to the Internet using the SAE ATIS (J2354) standard is a simple automated output report. Posting on a secure Internet server in FTP standards may have an associated cost, which should be minimal. Besides a simple Internet post (retrieved without password) and FTP with a password, one can utilize: Internet post accessible only with password; anonymous FTP; and / or web service transaction based (probably using Simple Object Access Protocol [SOAP] and Web Services Description Language [WSDL]). The web service transaction based method may be of more interest in the future as ATIS services move beyond simple Internet post and FTP. FTP is best suited for access to large amounts of data, not for requesting specific pieces of information.
An additional benefit to the California architecture is that commercial traffic reporting companies could also access the same FTP files for their traveler information systems / services. This would give all information service providers (ISPs) the same baseline of data, to which the private sector would then be able to add value by offering personalized service, enhanced delivery and packaging to satisfy their customers.
In the context of a "regular user" of a 511 system, data from an outside agency might not receive as much attention as information on the local agency's highways or secondary roadways. However, offering outside agency data is expected especially with adjoining states or along travel corridors.
The incorporation and presentation of this information within the menu structure of the 511 system falls to the local agency, though there is an opportunity to present this option as a standard selection in the 511 main menu – similar to selecting traffic or public transportation. There is an impact on the vocabulary (number of possible correct words), accents and grammars that the system must recognize in the voice dialogs if the menu of options includes other regions, roads and types of information.
Current thinking amongst the task force is that creating a high-level menu selection for "out of region" or "corridor" roadways would be the best presentation level. This would allow users to select information outside of their local region after checking local travel. This separation might allow them the understanding that information outside their local area may not be as granular as local information. This menu issue will be addressed further in the next revision of the Guidelines.
Call transfer issues concern the technical and financial challenges involved when a call made to one 511 system is transferred to a 511 system in another region or state, i.e., outside the coverage area offered by the local 511 service.
If an agency offers call-transfer, or a direct connection, to another agency or 511 system, the caller should be informed that they are leaving their 511 service and outside information is provided by another agency.
Questions and Issues Regarding Call Transferability include:
The task force decided that limiting the number of systems available for transfer might defeat the purpose of the transfer itself. Members of the task force agreed that if a user were able to transfer from one system to another, then limiting them to systems within their state or adjoining states would only serve to confuse them.
Call transfer menus are complex and costly and to have many of them implies great menu complexity and high operating cost as every menu choice has per call costs and almost every call transfer incurs costs for both systems.
The technical aspects of call transfer are essentially the same regardless of call origination or type of telephone system. There are two basic approaches to call-transfer:
Call Transfer Disconnect – This feature allows a Centrex[1] user to transfer a call to another telephone number either within or outside the Centrex system and hang up, leaving the two remaining parties connected. The Centrex user is then free to accept another call and the transferred call continues on its own just as if it was placed directly to the "transferred to" number. However, when transferring a call to the Long Distance Telecommunications Network, the Centrex customer is responsible for the payment of charges between the Centrex location and the telephone to which the call is being transferred[2].
Direct Call Transfer – Many PBX[3] systems offer a Call Transfer option. However, this option requires that the implementer's PBX / IVR[4] system have this capability – which may add additional cost to the system. This type of call transfer requires that the system take another phone line or PBX trunk and then out-pulse or signal the digits to the new system. It does not take advantage of the Centrex feature that allows the call-receiving party to drop out of the call and it requires the original call receiver to use two lines or trunks for every call transferred. The system originating the call must stay on-line during the transferred call in order to complete the circuit.
As with all N11 codes, the 511 dialing code is not Area Code specific. In other words, one cannot dial 1-NPA[5]-511 and have a call terminate in another area code. When dialing an area code, current telecommunications systems understand that there will be seven digits following the three-digit area code. Thus, a call to a 511 system in another region or state would have to be sent to a "back-door" number, presumably the 10-digit number to which the 511 code is translated in that area.
In order to accomplish a Call Transfer Disconnect, the implementer is required to have Centrex or similar service on each of the system's incoming telephone lines. Different telecommunications providers break out or bundle services that allow for call transfers, often using other names for these services (SBC, for example, calls their Centrex service "Plexar-I"). The financial impact of this requirement is one that needs to be measured on a case-by-case basis.
Systems that are designed to use simple POTS[6] line hunt groups will require a number[7] of extra lines to facilitate a Direct Call Transfer. If, by chance, every caller into a 100-line system chooses at the same moment to be transferred to another system, then another 100 lines would be required to facilitate the transfer. The number of lines required will vary and the actual number will depend upon the number of calls that the implementer expects to transfer to other systems.
In order to accomplish a call transfer, regardless of the line characteristics involved, long distance service is required on each telephone line in the system. This additional feature is added directly to the lines through a PIC[8] code – choosing a long distance carrier for the lines. Without a long distance carrier, call transfers are limited to local or toll-free lines only.
A call transfer from one 511 system to another would allocate charges to the implementer or ISP originating the call, whichever is responsible for the charges for the incoming and outgoing phone lines for the 511 system. The exception to this rule would be a call transfer to a toll-free number, in which case the receiving system (and its implementer or ISP) would be assessed the cost of the call.
There was discussion within the task force concerning the use of the Calling Party Number (CPN) for billing purposes and informing callers that they would be assessed the cost of the call transfer and any long distance charges for the call. However, the CPN is not always present when a call is terminated and some users might intentionally block their call information (Caller-ID) and some PBX systems do not transmit the CPN by design.
Though Automatic Number Identification (ANI) is present for 911 emergency purposes and cannot be turned off, requiring implementers to provide equipment capable of retrieving this data for billing purposes poses financial challenges and raises privacy issues that an implementer might not be willing to assume. This is thoroughly discussed in DAR #2: Transfer of 511 Calls to 911.
Wireless calls may carry Caller-ID information, however it is difficult to gauge whether each and every wireless carrier[9] nationwide would be willing to assess these calling charges to their users.
Consideration must be given for misplaced calls to a 511 system either between 511 service areas or areas where 511 is only available on one side of a "border."
In the event that two adjacent states or regions offer 511 services, there is the possibility that a call placed from a wireless phone near the border of the two systems may be erroneously delivered to the wrong system.
Along borders where one agency provides 511 and another does not, the 511 call may be misrouted because the cell tower or a mobile switching center (MSC) receiving the call is in an area where there is no 511 service – see Figure 1.
Figure 1 – Mobile Switching Center Call Routing
For example, an Indiana wireless user traveling near the Kentucky border dials 511 and is erroneously connected to the Kentucky 511 system. Through an agreement between the two implementing agencies, the caller is connected to the Kentucky 511 system. The Kentucky Transportation Cabinet and the Indiana Department of Transportation have exchanged correspondence whereby they agree to work out how such calls will be handled and who will bear the cost. The details will be a part of Indiana's planning for 511 implementation.
It should be noted that this issue is not exclusively for regions that "touch." A wireless caller along the Connecticut shoreline may sometimes find a wireless call routed through a cellular tower in New York, as the best signal is over the waters of the Long Island Sound rather than through the trees and residential areas on the Connecticut shore.
Additionally, proximity to a cellular tower is not the only issue with call routing. Cell towers have limited capacity and though they are sized for optimal capacity (i.e., the number of concurrent users on a single reception site), it is not unheard of for a tower's capacity to become "full." The configuration of wireless tower routing may also vary from day to day as well. Callers dialing their wireless phones may have their calls picked up by the "next nearest" tower site, regardless of the number dialed, be it 511 or a regular phone number. These calls may be received on a tower that is outside of the coverage area of the 511 system that the caller is trying to reach, and may therefore be translated to another region or state's 511 system instead of the intended system – see Figure 2.
Figure 2 – Wireless "Nearest Tower" Call Routing
In many 511 systems across the nation, there are transit and other transportation agencies that allow calls to be directly transferred to their existing telephone systems for additional information, e.g., transit schedule and route information, airport parking information, etc. Most of these systems fall into two categories:
Either scenario would cause problems if a caller wishes to transfer to another system after they have retrieved information from their local system. In order for a caller to transfer to another region's system after cross-connecting[10] to an outside local agency, the caller would need to transfer back into the local 511 system or hang up and dial back into the local 511 system a second time.
From a programming standpoint, each time a new agency launches a 511 service, every agency that participates in allowing transfers between the 511 systems would be required to, within a reasonable amount of time, reprogram their system to enable the new transfer. This would involve both updating the menu system to announce the availability of a new system and programming the system's software to perform the call transfer.
Since some regions will implement toll-free backbone numbers and others will not, it is difficult, if not impossible, to determine the cost of call transfers to the local implementer or the "other" implementer. A system programmed to transfer a call to a toll-free number assesses the charges to the receiving party. A region such as the San Francisco Bay Area might see an increase in costs from users transferring into their system from other areas within California, as well as from outside of the state. A region such as Cincinnati, whose 511 system is switched as a local call and does not use a toll-free backbone, will see no increase in cost, but the implementers transferring calls to Cincinnati will bear the long distance cost of the calls.
Finally, some agencies that will use a toll-free backbone may do so only for non-local, in-state or in-region callers. For example, New Jersey Transit's toll-free information number is restricted to New Jersey callers only and callers from outside of New Jersey are blocked from connecting to the system. In a 511 implementation, an ATIS provider might choose to implement a toll-free backbone to facilitate cost-free calling for the users. In order for other 511 services nationwide to be able to send / transfer calls to this service, the implementer would need to use a national toll-free service number[11]. This would invite more calls from outside the region and drive up the cost of providing the toll-free system.
There are a number of technical and financial issues to be considered by a 511 implementing agency. These issues are linked to the complexity of a technical solution that may lead to additional financial outlay on the part of both the sender and the recipient. Of the utmost importance to an agency that is receiving information is the ability to store and fuse this information into its own system.
Message storage requires a standard database format with standard "slots" or repositories for information that always contain the same type of information. In most cases, the implementer of an ATIS service creates these standard "slots" for their systems in order to not replicate messages and standard content over and over.
The issue becomes more technically complex when the receiving agency is asked to receive information in the form of another agency's "slots" which might not precisely line up with their own. Though translation tables can be written, each agency must understand and communicate their own standard categories and content beforehand in order to assure that all of the data is received and presented in the proper form. Additionally, any changes to its databases may require a re-write of some portions of the translation tables. This assumes that the agencies are not using the same standard database and that an update would not affect both of them at the same time. The writing and re-writing of translation tables and databases can become costly and open communication is essential between any agencies wishing to share each other's data feeds.
On the side of the sending agency, an existing database system used to create content for an ATIS system may contain more information than another agency requires. Local agencies may customize their own database content, even though they might use a standard format database.
The national ITS standards effort has developed standard data elements and standard messages. Data exchange software pulls information out of one system's "slots" and drops them into the equivalent data element slots in the second system.
In all cases, the goal of a delivering or receiving agency should be to allow the information to be presented in both their and other regions without requiring numerous additional, and often manual, steps to create a separate data stream to or from another agency. The SAE ATIS (J2354) standard has been specifically developed to eliminate these problems. Regardless of the internal computer programs an ATIS may use, writing the output in a SAE ATIS (J2354) standard database feed will allow traffic reporters, broadcasters and other ATIS / 511 systems to receive and parse the messages for further distribution through their systems.
The following factors relating to call transfers and data sharing need to be considered:
If an implementer determines data sharing is preferred, then the following items need to be considered:
If an implementer determines that call transfers are preferred, then the following items need to be considered:
The 511 Deployment Coalition will continue to monitor the issue of regional interoperability and developments in regions where solutions are implemented. If implementers have suggestions for improvements, please provide this information electronically to 511feedback@aashto.org.
[1] Centrex is a central office based communications system for business. Every phone at a customer's location has its own dedicated connection to switching equipment at the central office. Everyone at a customer's business gets the convenience of a separate line. (Definition from SBC Communications).
[2] Basic definition from SBC Communications.
[3] Private Business Exchange: A subscriber-owned telecommunications exchange that usually includes access to the public switched network.
[4] Interactive Voice Response: A system that responds to a user's input (through either touch-tone interactions or voice recognition).
[5] NPA is the telecommunications industry abbreviation for Area Code.
[6] POTS – Plain Old Telephone Service – Another name for PSTN, or Public Switched Telephone Network. PSTN refers to the global network of interconnected telephone companies. While PSTN started out as an operator-operated "Hello Central" system it has evolved into an extensive digital network except for the "last mile" (the connection to each subscriber). In other words, POTS / PSTN is similar to the connection you have in your home, without all the enhanced capabilities one might find in a multi-line office environment.
[7] The number of lines required is dependent on the number of calls envisioned as being transferred to another service. The number should be calculated based on an understanding of the geographic location of the 511 system transferring the calls and its users' average travel habits.
[8] A PIC code is an acronym for Primary Intra-LATA Carrier (PIC) Code. This is the code used to identify the long distance carrier selected for the phone line in question (e.g., MCI, AT&T, Sprint, etc.).
[9] Since wireless callers travel, a caller may be using a 511 system in an area they are visiting, even though there is no 511 service available in their local/subscribed area.
[10] The term cross-connect is used to describe the transfer of a call from one system to another.
[11] Toll-free numbers may be implemented in a number of configurations. The most common commercial application is a National toll-free number, which allows callers from anywhere in the country to complete a call. However regional and statewide programming is also available, and in some applications, the number may even be programmed to accept calls from even more specific delineations.