Prepared for use at the February, 2000

"Workshop on Position Dependent Information Services" Meeting

of the W3C Mobile Access Interest Group

David Kelley
SubCarrier Systems Corp (SCSC)
Consultant to the Society of Automotive Engineers (SAE)

For the Society of Automotive Engineers (SAE) the primary rationale for participating in these meetings is twofold:

1. To understand and learn what the preferred methodology should be in mapping its work in traveler information messages into the protocols of the WWW
2. To make others aware of the content rich message standards which it has developed for use in distributing traveler information as part of the US efforts in ITS and Telematcs.

The standards which we have developed deal primarily with message set content and not with host media issues, transaction protocols or security. By contrast, the efforts of W3 have produced a wide range of possible solutions to these issues beyond the basic tools of HTML. More recent developments, including XML and WAP present us with a number of choices in how to transmit our own standards using the web.

The positioning content of these message falls into two primary groups, client side and server side. In both cases, the value of position (both present and predicted) is used to control not only the appropriate content but also at times the appropriate server and/or client entity to connect with.

On the client equipment side, this includes not only the current position but also the predicted position (and time) so that forecasted information can be delivered in a relevant way. Client position is of course vital when responding to distress and breakdown events. Predicted position of a client is also used by some server services to initiate sending information as well (e.g. mid-route navigation instructions)

Server side position information can involve the server owner’s location (when physical access is required such as a gas station location for refueling) but more typically involves the geographic relevance of information which the server might send to the client (such as the scope of coverage for local traffic conditions). This is a vital area for advances in a uniform XML query language. Some types of filtering (either client side filtering from all of the data, or server side filtering based on expressed client preferences as well as position) almost always needs to occur. Because of the limits of bandwidth in wireless devices, a high level of efficiency is required as well.

It is desirable that the range of solutions used allows for the continued practice of "client-less" push portals as well as more active client specific server and business models. Typically today a number of public agencies use the web to disseminate traffic information by means of brute force "status board" graphic images suitable for wireline client connections. This type of portal wishes to also serve mobile device clients (and will typically use SAE standards to do so) but does not desire to interact with individual users (this is felt to be the realm of private industry by most). Hence, a desirable outcome of this workshop would be for a range of such solutions.

The SAE, in cooperation with other US standards setting organizations, and with ISO activities (TC204), has been developing a set of interrelated standards for Intelligent Transportation Systems. In the US this is a public private partnership with the Federal Highway Administration. In this context, the US work is similar to other traveler systems sponsored by the host government in the EC, Japan and other countries. The SAE role has been the establishing of message set standards for use by travelers (for both wired and wireless delivery), developing in-vehicle bus standards (the ITS Data Bus, IDB), and standards for vehicle distress systems (Mayday), as well as a number of supporting standards. The message content specifically for travelers is the area in which this forum would be most interested. This is undertaken by the Advanced Traveler Information Systems Committee (ATIS) of the SAE, chaired by Joel Markowitz.

At this time there are three US standards which are keenly relevant to those wishing to provide information message content. All involve various types of position-location information in them. All message formatting standards, rather than presentation standards.

The first, and simplest, of these is SAE J2313, a standard for exchange of vehicle position and status between a distressed vehicle and a service center (e.g. a MAYDAY or 911 call). It was developed with a simplistic protocol to be hosted on the US Analog AMPS phone system. Current trends are to make such messages more independent of the media, and in this case will likely take advantage of the cellular handset becoming aware of its own position (rather than the use of a separately integrated GPS as is done today). Issues of properly routing such calls to the responding center are of primary concerns and are being addressed in a number of other forums.

The other two bodies of work are targeted to delivering to the traveler (while mobile or pre-trip) real time information about the current and predicted roadway conditions, the weather, and other factors affecting his mobility. The message set also includes support for various eCommerce transactions such as reserving hotel or parking services.

The first of these, J2353/54 is targeted to individual traveler needs and the transactional messages needed to exchange a profile and receive back current or on-going status of relevant roadway events. The key concept is that of the individual, these messages do not in general support a one-size-fits-all broadcasting of information as the next standard does. The transactional exchanges are specified at the message level and no specific host media is defined. It is the current intention of the SAE to profile the message set so that one or more WWW methods can be used to accomplish this. Native MIME types, XML with RDF, as well as active server pages are among the expected technical solutions.

The final standard, J2369, was developed more for broadcast use, and also for use over reduced bandwidth media hosts such as are typically found when mobile. In this context, broadcast implies that the function of discarding non-relevant information (e.g. traffic events outside of the traveler’s concern) is left to the client side device. It this regard it is more of a push media application such as are found in the traditional web environment. Modest compression methods are used to reduce the information require to transmit. The format is also "packed" in that information on dozens to hundreds of nearby roadway segments are contained within one message. Typically this standard is suitable for a server side implementation which does not wish to provide filtering for each client. The transactional environment then becomes one of selecting the content and coverage areas germane to the client’s needs.

In all case the SAE standards have been developed in ASN1 specification syntax format. There is continuing wide debate over the merits of using ASN1 encoding, and a number of proponents believe that application specific encodings are superior to the options allowed by BER/PER/OER/etc. The recently authored white paper by Motorola proposing a simple TLV system for use in Telematics may have value here as the SAE and other such as GATS attempt to create a world standard in this area. Issues of formatting into XML are also clouded by various options of what granularity to use and how WAP and Binary XML might be employed.

The reader has probably experienced a server side bitmap of traffic flow information by this time. This type of web page represents to most typical deployment today and does not in general use any of the above standards in the presentation. Regrettably such a bit map is typically >50k and can take tens of minutes to download to a mobile device. Establishing methodologies for translating this type of page using the SAE standards is expected to be the earliest area of effort. This will probably be limited to recommending the use of the standards as a native MIME type and embedding the message set data using a simple OBJECT element.

Further improvement will clearly be needed if these message content standards are to enjoy wide deployment. The standards committee has in general realized that mapping into XML is a preferable solution. Specific details of this, including at what level of granularity to make such mappings, remain unclear. Further, the transactional contents of the message set appear suited to use with an XML query language, but current work in the W3 makes this a moving target at this time. We are also unclear as to what degree of active involvement in the WWW-WAP standardization effort would be suitable.

SAE seeks the assistance of W3 and any interested participants in resolving these issues. We are grateful for the opportunity to present this short summary of our own work in the area of positional aware message sets and our early effort in adding them in harmony to the WWW.

The SAE-ITS-ATIS committee is the US standards body charged with developing domestic message set standards containing a variety traveler information content. Participation of interested parties is welcome. Please contact one of the below.