1. Introduction

The purpose of this aspect of the project was to analyze documents and other data sources that identify, describe or specify the nature of ITS messages, as well as various technical approaches, protocols and technologies that have been assessed or applied as part of any previous or currently on-going projects for ITS messages (at the logical versus physical implementation level). Additionally, consideration was given to both existing and emerging standards that might be applicable to an ITS message set template(s), as well as commercial-off-the-shelf (COTS) and emerging technical approaches and technologies. Together with the needs and requirements identified by the ITS Data Dictionary/Message Set Template Working Group, this knowledge of technical approaches, protocols and technologies for an ITS message set template can be thought of as forming a set of bounding criteria or constraints. It is within these logical boundaries that various ITS subsystems must be able to specify their message sets (i.e., message types). These boundaries provide a framework which must therefore be reflected in the standard for an ITS message set template, which is to be specified under the next task of this project.

The following terminology used within the IEEE ITS message set template project applies to this document:

Message Set Template specifies the parameters ('slots') and syntax for defining Message Sets

Messages Sets are abstract types of messages (i.e., message types)

Messages are actual instances of messages

2. Objectives of the ITS Message Set Template(s)

To understand the importance of the ITS message set template standard and the manner in which it is to be applied, one must first understand the top-level requirement for the related ITS data dictionary standard. That requirement can be stated as follows: the standard shall support the specification of data dictionaries that allow the unambiguous specification of all ITS information, including but not limited to, information to be exchanged between or among ITS subsystems (through the use of message sets). ITS message sets are therefore the logical medium by which information interchange between ITS subsystems is accomplished. The message set template standard provides the basic structure or framework for specifying message sets (i.e., types of messages). Those types, when instantiated, are the specific messages that are interchanged at the physical implementation level.

3. Requirements for and Approaches to the ITS Message Set Template

3.1 Relating the ITS Message Set Template to ITS Data Dictionaries

When specifying a message set, its contents should normally be data structures (i.e., data concepts and data elements) described in and managed by an ITS data dictionary conforming to the ITS data dictionary standard. There may be some exceptions [Note: whether some derived data elements (for example where some statistical algorithm is applied to a data element from the data dictionary) can be specified within a message set rather than in a data dictionary is an open issue]. The message sets should not specify permissible ranges of values for data elements, as this information should already be specified for the data elements as part of the meta data about them in an ITS data dictionary. Data types should also not be specified separately in a message set, as those should already be specified for the data elements as part of the meta data about them in an ITS data dictionary. For this reason, it may be useful to have the data types used in the data dictionary standard correspond to [at least a subset of] the ASN.1 data types. A subset of only the more basic ASN.1 data types may be preferable, as some of the extended ASN.1 data types cross over into limited semantics. Such semantics are best left to the data dictionary meta structures to handle. However, in a message set one should be able to specify the sequence of data elements appearing in a message, as well as allowable ranges of repeating data elements within a message (e.g., maximum four sets of Routes returned). [Note: the working group should review the ASN.1 standard to see exactly how this is specified i.e., using what syntactical construct(s) and/or extended data type(s), and determine whether ASN.1 meets the working group's requirements in this area]. Certain conditions under which data elements may appear in a message may also be specified as part of the message set specification using the message set template and ASN.1.

Another open issue remaining in this area is whether the message sets contain data elements 'flattened' to the lowest-level of data structuring, versus having the ability to re-express in ASN.1 higher-level data structures from the data dictionary and resolve them to the lowest level at runtime. This is not a logical level issue, as the specification of the message set template will be in the data dictionary and will therefore have access to the higher-level data structures. But if ASN.1 encodings are used for implementation, then the question arises as to whether these need to be flattened in advance. If they are not resolved to the lowest-level in advance, then the applications need to have access to the data structures of the data dictionary (either pre-compiled into the application - in which case update consistency becomes an issue - or at runtime).

How the actual physical messages are encoded, as well as how the actual instances are transmitted, are purely implementation issues. Implementation issues are not the subject of the ITS message set template standard, and to the degree they are addressed here at all, it is only for informational purposes. Given the variability in the nature of messages (i.e., wireline versus wireless, transactional versus dynamic, short-range, etc.), and given the need to optimize specific messaging environments to meet particular performance requirements, it is anticipated that there will be many different ways to implement ITS messages. Another way to state this is that it is the logical requirements for the message that will be specified using the message set template standard, with potentially multiple physical implementations able to meet those requirements.

Since message sets can be described and managed using data concepts and data elements just like any other ITS data, then the message sets themselves should be populated as contents in an ITS data dictionary conforming to the ITS data dictionary standard. The collection of message sets (i.e., those portions of ITS data dictionaries containing message set specifications) can be thought of as comprising a 'message catalog'. Providing a message set cataloging capability in an ITS data dictionary will require hosting the message set template as a data structure in ITS data dictionaries.

3.2 Relating the ITS Message Set Template to the ISO OSI 7-Layer Architecture

The Open System Interconnection (OSI) model developed by the International Organization for Standardization (ISO) identifies 7 layers for organizing a messaging or communications environment and managing its services. Each higher level requests a service which is provided by the next lower layer in the architecture. The 7 layers are:

Layer 7 - Application = application interface

Layer 6 - Presentation = presentation to applications

Layer 5 - Session = presentation dialog management

Layer 4 - Transport = message handling

Layer 3 - Network = routing of packets

Layer 2 - Data Link = frames from node to node with shielding

Layer 1 - Physical = bits on a wire

It should be noted that there are few if any complete, direct implementations of the 7-layer architecture. TCP/IP, for example, does not make this fine grain of distinction and does not address presentation issues to any great degree, or application (i.e., semantic) issues at all. The important distinction for purposes of the message set template is between the lower-level transport/network protocol-related aspects that are 'syntactic' (Layers 5 down to 1) and the application-related aspects (and maybe some presentation-related aspects) that are 'semantic' (Layers 7 and 6).

The message set template will provide for the specification of message types from the perspective primarily of Layer 7 - Application, but may in some cases also address at least some aspects of Layer 6 - Presentation. Layers 5-1, in particular deal heavily with implementation issues and will likely vary greatly across ITS. Implementation issues cannot be addressed directly in the message set template. However, the message set template may, for example, provide slots in its header or trailer which allow high-level specification (logically through a 'radio button' or menu-driven approach) of the particular requirements for a message set in terms of such messaging parameters as acknowledgement, authentication, security, etc. These specifications will need to be fairly-generic in order to allow various individual messaging implementation standards to be applied as appropriate. For issues such as bandwidth or quality of service, which have been raised as possible meta data issues related to ITS messages, the specific data needed to request and verify this is also at a lower level of the OSI 7 layer architecture than Layers 7 - Application or Layer 6 - Presentation. However, again, some degree of logical specification for these sorts of parameters may be provided for in the message set template, with the request to meet that requirements (i.e., provide that service) being passed down the appropriate lower level of the protocol.

3.3 Use of ASN.1 as the Expressive Formalism

After review and analysis of several alternatives (including BNF, SGML and CORBA), the IEEE ITS DD/MST Working Group decided to use Abstract Syntax Notation One (ASN.1) [ISO 8824:1994] as the expressive formalism for specifying message sets based on the message set template standard. ASN.1 is widely-used for this purpose both within the standards development community and industry. It should be noted that the decision to use ASN.1 as an expressive formalism in no way implies or requires the use of ASN.1 encodings for the actual implementation of the messages. The abstract syntax of ASN.1 is neutral with respect to implementation. Depending upon the nature (including performance requirements) of a particular messaging environment, one or more of the ASN.1 encodings may be appropriate for implementation use. One contrast to note between ASN.1 and the EDI environment is that ASN.1 encodings are binary, whereas EDI is ASCII text-based. However, any decision about the use of ASN.1 encodings for implementing messages is outside the scope of the IEEE ITS message set template standard.

ASN.1 is a primarily static-oriented specification language. It is possible to specify process or function, but languages like CORBA IDL, for example, are more explicitly oriented to behavioral specification and invocation. With ASN.1, the message is explicitly making a query or sending information; in the case of CORBA, the message is sending a process request along with the input variables and expected/desired output variables. ASN.1 does, however, provide for constraint specification. For example, SQL 92 referential and existential integrity constraints (i.e., the WHERE clause) can be expressed in ASN.1's constraint language. An ASN.1 message specification and/or its implementation would typically link to a DBMS (such as SQL) through a programming language (i.e., in the context of an application program).

ASN.1 allows fully-open specification of length, value, etc. at the abstract specification level. At the implementation level (for performance reasons) this can be limited in applications where both ends of the interchange know about the nature of the message. In other words, every message set should be specified using ASN.1, but even where ASN.1 is used for the implementation, the specification does not need to explicitly exist as part of the implementation environment. The messages can be compiled. Having a logical-level specification of the message sets, however, ensures that even compiled messages have a specification that is human-readable.

Aspects of the ASN.1 standard are also useful if there is a need to assign a unique numerical address to message sets. This appears to be the case in ISO/TC204 N224 for some transportation-related messages, and the IEEE ITS message sets may need to do this then to ensure consistency with such international standards.

4. Additional Topic Areas Identified During the Preliminary Analysis

4.1 One or More Than One Message Set Template

Given some global requirements for (broadcast) messages, does there need to be just one message set template that is applicable at this highest-level to all messages, or is there a fundamental split into DSRC versus 'other'? If there is only one message set template, are DSRC messages simply allowed to have null values in many of the header slots that do not apply to them?

4.2 Global Addressing Scheme

Regarding ISO/TC 204 N222, N223, N224: These documents appear to suggest handling the complexity of coordinating the message specifications for the many aspects of an ITS by uniquely identifying many administrative domains (via the Sector and Service ID's). These administrative domains are then assigned to working groups, each of which is then free to define the message formats required for its domain, independent of the others. Overlaps among the domains appear to be handled by liaison or coordination, but not by means of a formal, uniform interchange medium.

This approach raises some critical global issues related to port, node, network/subnetwork, group addressing. A message must somehow specify where it came from (in case there is a reply) and where it's going. A message can go to a single point (port on a node), be broadcast to a network/subnetwork, or be sent to a port on each of a pre-arranged group of nodes (i.e., multicast). ITS will probably use all of these. To handle this, the addressing scheme should be globally specified. If there are other more global messages as well (i.e., ones that cross sector, or go outside of ITS to say EPA or DoD), then there needs to be a global addressing scheme for this level of interaction. The IEEE ITS message set template should support applicable national and international standardization at this level, too. Except for dedicated messaging, how would such a global message ever have identification of where it came from or where it was going? For example, if any of the 33 basic messages in the ISO/TC204 standard cross sectors and if sectors have the right to choose their own formats, then how do messages cross boundaries and still know addresses? Only a global addressing scheme, such as used for example for Internet TCP/IP and OSI would ensure this.

4.3 Transport Services and Sessions

The question arises as to what message transport services are required for ITS messages, and if/how such services should be specified in the message set template. Some services may require the establishment of a session with the required parameters reserved across the network for all messages sent within the session. This means all elements of the network involved with retransmission of messages (i.e., routers, nodes) will understand session-related messages (e.g., establish session, end session, session status, change session). Some session-related requirements include:

Time constraints - e.g., required bandwidth, isochronous transmission, end-to-end delay limits

Integrity constraints - e.g., guaranteed error-free arrival, in-order arrival

Security constraints - e.g., encrypted channel, guaranteed identity of endpoints, encryption type

Routing and gateway requirements - e.g., address translation in mixed networks, route determination to meet other constraints (like cost)

Multicast - e.g., videoconference group.

Typically in such cases there are specific messages for setting up the sessions (i.e., these can be thought of as 'meta messages'). This means that the individual content-related messages don't have to worry then about at least some of the general session-related parameters like overall security for the session. But even in this case, individual messages could have specialized security requirements just for that message.

Since TCP/IP, as an example of a physical implementation of a messaging environment, does not have a session protocol, some might argue that it isn't relevant to specify session requirements for message sets at the logical level. It is true that TCP/IP effectively stops at the transport level and leaves sessions up to presentation and application level protocols. For some applications, like transmitting Web pages (HTTP) or netnews (NNTP), sessions may not be required. But for many more applications, like mail (SMTP, POP), terminal emulation (Telnet, rlogin), file transfer (FTP), real-time/isochronous (RSVP), file sharing (NFS), the equivalent of sessions are implemented by the individual application protocols. This has led to numerous problems: security holes, duplicated code and message content, unresolved conflicting requirements. When TCP/IP came into use, it wasn't clear what the requirements for sessions were or how they would be supported in a network. Since then, the OSI model has come out, and at the implementation level SNA and Appletalk both contain integral session protocols, due to a large number of service protocols that require security, authentication, and resource allocation. These might be looked at sources for parameters to specify for sessions, although again the message set template should abstract away from the specifics of these implementation-level protocols. Many other specific mechanisms are available to provide security, authentication and resource allocation, but most of these are too specific or too poorly packaged to be useful as sources. For example, there are a number of problems in internet protocols due to the lack of a standard session protocol, including:

FTP, Telnet, rlogin and POP all separately implement user authentication. FTP, Telnet and rlogin transmit the user's ID and password in the clear. POP does, too, but has an option for encrypted password authentication. PPP has its own optional secure authentication.

There is no standard way to encrypt messages, leading to a hodge-podge of application-level encryption schemes (like PGP mail, or applications calling DES with Kerberos-managed keys).

NFS is insecure. FTP does not encrypt transmitted content. SMTP servers typically do not do any authentication; the SMTP protocol does not provide for authentication.

RSVP is only now in the process of standardization. Reserving resources using this approach is left to the application. Previously developed code (e.g., for FTP, Telnet, socket-based applications) will have to be modified to use it in addition to the protocols already used.

This knowledge of the state-of-the-art can be applied to the question of what to specify in the message set template. When specifying a message set, it may be appropriate to specify some parameters regarding the need for and nature of user authentication (ID and password), including whether secure authentication is needed, and whether encryption of passwords is necessary. It may be also useful to specify whether a message set requires encryption of its contents, although specific encryption schemes may not be specifiable due to the wide variety of schemes and their interaction with and dependence upon specific applications or kinds of applications.

4.4 Elements Common to Many Message Domains

Based on a review of current message sets in other domains (e.g., ASC X12 EDI and U.N. Edifact), certain data elements appear to occur quite commonly in many message sets. These may be the same thing as, or at least relate to, the so-called 'basic data elements' being addressed in the IEEE ITS data dictionary standard. These should not be specified only for use in messages, but rather should be in an ITS data dictionary (directly or by reference to some other standard) and should then be applied to messages, as appropriate. If certain of them must typically be specialized when applied to messages, this information should also be represented in the data dictionary.

Example 1: Physical quantities. A common way of expressing physical quantities should be specified. A dictionary of equivalences should be available.

Physical quantities can be:

Simple units (e.g., gram, piece)

Multipliers (e.g., kilo, nano)

Combined units (e.g., kilo meter / hour)

Derived units (e.g., Newton = kilo gram * meter / (sec * sec))

Approximate common units (e.g. bargeload, container)

Standardized common units (e.g., standard container)

Gross or net (weight)

Inside or outside (dimensions)

Note: Combined units of measure and derived units of measure should also be considered. The EDI standards have addressed this area fairly extensively.

Example 2: Currencies. There should be a standard format(s) for encoding currency units in messages (e.g. DM 1,00), and for specifying the decimal point symbol. Some message set standards allow only one currency format and one decimal point symbol.

Example 3: Geographic location. There are many systems for specifying geographic location. Some subset of these should be standardized, along with a means of translating among the members of that subset. With the widespread use of GPS, Lat/Long/Elevation is finding the most use. In this case, there must be a standard reference datum.

Example 4: Country code. There should be a standard for specifying 'country' in messages. Some message set standards allow only one format.

Example 5: Telephone number. There should be a standard for specifying telephone numbers in messages. Some message set standards allow only one format.

Example 6: Date and time of day. ISO 8601 provides standards in this area. In message set standards, there is often a single standard used, with local translations. Or, if local date/time are used, there must be a standard for the locality (time zone, daylight time adjustment, calendar) and a translation to UTC.

4.5 Other Issues

The following miscellaneous issues should also be considered, and may merit parameterization as part of the message set template:

4.5.1 Acknowledgement and Synchronous/Asynchronous Transactions

Does the message require acknowledgement or not. 'Broadcast' messages inherently do not require acknowledgement.

Does the message involve synchronous or asynchronous transactions?

How does the combination of acknowledgement interplay with synchronous/ asynchronous transactions, for example in long-duration messages?

- Synchronous transactions and acknowledgement = sequential wait with locking

- Asynchronous transactions and acknowledgement = coincidence with no locking

- Synchronous/asynchronous with no acknowledgement

These criteria may change message structures, i.e., they may indicate a need for separate message set templates at a second level. However, the difference between DSRC versus transactional messages is really about temporal and spatial parameters, and may not merit separate message set templates at all.

4.5.2 Dispositions

Messages can be categorized based on their modal disposition. There are three message dispositions:

Query = Search

Command = Execute

Statement = Inform (including Broadcast).

Certain values for slots in the message set template may change depending upon which of the three dispositions is being addressed, but the overall message set template structure (i.e. the slots themselves) will not change among the three dispositions.

4.5.3 Kinds Versus Species of Message Sets

Changes in the structure of the message set template (refer to 4.5.1 above) or to values for the slots (refer to 4.5.2 above) result in different kinds of message sets. These are meta level changes, analogous to changes to the meta structures of the data dictionary. Differences in the abstract contents of message sets, for example emergency traffic information messages versus toll collection messages result in different message sets (i.e., species or types of messages) not different kinds of messages at the message set template level.

4.5.4 Compiled Versus Uncompiled Messages

All message sets should be specified using the message set template. One of the parameters when specifying message sets will likely be whether the messages are compiled or not in their implementation environment.

4.5.5 Compressed Versus Uncompressed Messages

This is different from 4.5.4 in that it is not concerned with translating a message into a form that is directly machine-interpretable for more efficient transmission and/or processing. Like compilation, this requirement is largely driven by efficiency concerns related to transmission and/or processing. However, in this case, optimization of the message involves removal of unused message parameter slots (i.e., slots with a null value) and/or reduction in size (through some compression algorithm) of the slot length allocated for some parameter based on the value of that parameter being variable in length.

4.5.6 Generalized Data Interchange

The IEEE ITS message set template is intended to support generalized data interchange. There are two basic approaches to providing this capability. Which of the two approaches is used may be useful information to specify for a message set. The two approaches are:

Direct = assumes the receiving system knows what the data being sent means, based on the data concepts and data elements of the message set all being in the overall ITS data dictionary (including the ITS data registry)

Mediated = the message itself contains references to other data dictionary structures (from functional-oriented or application-specific data dictionaries) or embeds its own specification of the data elements contained in ad hoc messages.

Details of Documents Reviewed and Associated Comments

1. ITS-Related MSTs

During the March 6-7, 1997 working group meeting the basic message was described as:

! Header ! Information/Content ! Trailer !

Header could consist of:

! Address ! Priority ! Security ! ... !

Security could be broken in to some multilevel security definition [Note: This does not need to be at the level of DoD multi-level security, although as discussed above, there may be security at at least the level of sessions and individual messages].

Trailer is undefined, but could be an error check code.

The subworking group chair performed a review of existing ITS message sets, where information was available (basically ATIS messages from a workshop in the Spring of 1994). Very little is consistent among the varied sets. They are: ADVANCE, TravTek, Mitre ATIS message Set, VICS, UTMS, SAE J1708, EURO-Scout, and the Enterprise BIF/BAP.

As to details on the message headers and trailers (and size of fields):

ADVANCE:

Header:

msgType (1 Byte)

processOptions (1 Byte)

saveBytes (2 Byte)

termAddr (4 Byte)

register (1 Byte)

format (1 Byte)

priority (1 Byte)

applHdrOffset (1 Byte)

applName (2 Byte)

MNA_Command (1 Byte)

Trailer:

None

TravTek:

Header:

Message type (1 Byte)

Version of Prog (1 Byte)

Trailer

CRC16 (2 Byte)

Mitre ATIS message Set:

Header:

Message Type (6 bits)

Trailer:

None

VICS:

No data on message structure

UTMS

! Transmission Control Section (sync 1 Byte)

! Header (8-10 Byte) header:

Automatically Generated Equipment Number (3 Byte)

Automatically generated number (3 Byte)

Vehicle type )

In-vehicle Equipment Type } - (1 Byte)

User type

Information Type (1 Byte)

Length of Valid Data (1 Byte)

Trailer:

Transmission Control Section (4 Byte CRC)

SAE J1708:

Message ids (2 Byte)

EURO-Scout:

!Poll header ! File Header !

Pool Header:

Pool Descriptor (2 Byte)

Beacon ID (15 bit)

Version (1 bit)

Number of Entries (1 Byte)

Relative Address of file _i_ (3 Byte)

File header:

Application description (2 Byte)

(class (5 bit), code (8 bit), Version (3 Bit) File length (3 Byte)

Crucial length (2 Byte)

Trailer:

CRC (2 Byte)

Enterprise BAP/BIF:

From the text, the subworking group chair determined that there are headers. Unfortunately, it was unable to be determined from the documentation exactly what the message headers are. There appear to be User messages and System Messages (the latter seem important). The header seems to include at least the following information:

System Message Types

Supplier ID

Message [Set] Type

Default Country/State Code

Location Table Code

The only consistent element in the various message headers is a "Message Type" typically of 1 Byte (refer to ADVANCE, TravTek, Mitre, UTMS, EURO-Scout and BIF/BAP).

Message Trailer, if it is used, seems to be a 2 Byte CRC.

Other Subworking Group Notes Related to the ITS Message Set Template

_Message header_

Should include a Message Type of minimum 2 Bytes (256). This would provide space to define the message by functionality and message. Potential growth to 3 Bytes is possible. Need to get a good handle as to the number of messages the various message sets may have, and how many proprietary concerns/messages are interested before nailing this one down.

Size of the message in Bytes. Here or in message body? (UTMS, EURO-Scout)

Origin information should be considered: origin identity, location, time, and date.

Prioritization should be considered.

Security could just as well be part of the message or information content. There would appear to be a limited number of messages that require security or validation - primarily the financial messages. The bulk of messages don't need the overhead.

What other elements should be included in the header?

_Message content_

[Not our concern, except perhaps for some size of message information?]

_Message trailer_

It has been proposed that the ITS Message Set Template not have a trailer. If some sort of error detection or correction scheme (CRC) is needed by the application, then the information content should include the CRC. If the transmission media needs error correction (e.g., DSRC), then the CRC is added by the lower levels of the ISO Open System Interconnection (OSI).

2. TMDD MST

Assumed basic structure (Header Fields)(Data Fields)

Header information (what header fields are mandatory in all messages?)

Message Code

Sequence Number

Time Stamp

Data Format

Security

Addressing/Origin

Priority

Message Length (Fixed/Variable)

How communication protocol-dependent is the MST?

3. NATO Industrial Advisory Group, Subgroup 52 (NIAG/SG52), Allied Naval Engineering Publication (ANEP)-51, NATO Naval Combat System Information Catalogue, Volume 0 - Introduction and Volume 4 - Message Construction Standard

At the level of Volume 0, there appears to be many similarities to the objectives and overall structuring of approaches between ANEP and the ITS data dictionary standard and guidelines and the message set template standard. For example, the notions of 'formally and unambiguously' defining data structures and data elements and the [generic] messages they get packaged into are found in both projects. ASN.1 is the expression mechanism, with MS Access serving at least as an interim analytical tool, if not a limited data dictionary or registry [Note: Vol. 0 talks about standardization of data elements and messages, particularly looking towards genericity to reduce unnecessary differences and hence reduce ambiguity]. There are also some obvious differences in terms of the breadth and general nature of the data being interchanged. This document is concerned with intra-ship communications. As such, it can ignore issues related to operation over a large area outside a tightly controlled environment, issues very much in evidence in an ITS. The general issues of message construction apply, but in an intra-ship environment, message transport is much simplified, so the protocols associated with message addressing, routing and transmission are very simple. ANEP data might well be fairly analogous to the emergency and traffic management data within the ITS, but doesn't deal with commercial/business data elements, financial data feeds, etc. that are more complex and don't map as directly to the low-level basic data types of ASN.1 (e.g., Integer, Real, String, etc.).

Based on reviewing Volume 0, the most relevant detailed document to review appeared to be Volume 4: Message Construction Standard. This was stated as providing a "formal and unambiguous syntax for the definition of messages and data structures (components of messages)". Some of the basic data elements are also stated as being 'formally defined'. However, within Volume 4 itself it makes it clear that 'formally defined' is really only 'formally syntactically defined'. The basic data types are really only the eight most primitive ASN.1 data types (i.e., for whatever reasons, they don't make use of the full set of ASN.1 basic types). Additionally, while ASN.1 may be formal and unambiguous in its syntax (since the syntax and at least aspects of the associated grammar are defined in specifications that are well-controlled standards documents), that does not in any way mean that the [semantic] definitions one specifies using ASN.1 are necessarily formal or unambiguous. That would be presuming the nature of content based on the nature of its form. "C" is a formal and unambiguously defined programming language, but that does not mean someone cannot write bad or completely nonsensical programs in it, and while they may compile and execute, they don't produce any meaningful output. Saying, for example, that Message 37, Incident, is a set with members Incident Type (VisibleString), Date (VisibleString -- YYYYMMDD), ShipNumber (Integer), NatureOfIncident (VisibleString) and Report (Sequence of Events (VisibleString)) doesn't tell a human user explicitly about what an incident is, what a ship is, what's an acceptable description of the nature of an incident, what constitutes an event versus a part of an event or a description of an event. A message of this nature can be parsed and read into a receiving application, but unless that application already 'knows' what those data elements mean and has the same expected meanings for them as the sending application, then there is no assurance of nonambiguity. Given that, appropriate questions to ask would include: do these standards at least include a set of procedures for defining data elements in a consistent manner using, for example, structured English; do they have a set of real 'building blocks." In this case, the answers seem to be 'no', and that is apparently sufficient in this case, as the messages are simple enough and the data structures and data elements are at a low enough level that a direct mapping to ASN.1 basic data types provides recipients of the message all that is necessary (in this case, syntax) to act upon the message or otherwise make use of it in the receiving application's context.

The message header - albeit very simple in this case - may be of interest in identifying potential parameters for the message set template, and should therefore be considered along with such input as the list of ITS-related message templates compiled by the message set template subworking group. The message header consists of:

Message Catalogue Number (MCN)

Message Name

Message Description

Catalogue Group

Message Source

Message Destination(s)

Message Length

- Minimum Message Length

- Typical Message Length

- Maximum Message Length

Typical Frequency

4. RFC 2076 Internet Message Headers

This memo contains a table of commonly occurring headers in headings of e-mail messages. The document compiles information from other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring headers which are not defined in RFCs are also included. For each header, the memo gives a short description and a reference to the RFC in which the header is defined.

This is deemed very useful to the message set template effort and will be used to help prepare a checklist of candidate header items.

5. EWOS Guide to Open System Specifications (GOSS) AMHI and AMH3 (EWOS) Profiles

These profiles may be good candidates for header and/or trailer slots. The following may be relevant.

AMH1

An MTA, an MS or a UA shall as the basis of the AMH11 profile support the

following Elements of Service:

* Access Management

* Content Type Indication

* Converted Indication

* Delivery Time Stamp Indication

* Message Identification

* Non-delivery Notification

* Original Encoded Information Types Indication

* Submission Time Stamp Indication

* User/UA Capabilities Registration

* Conversion Prohibition

* Delivery Notification

* Disclosure of Other Recipients

* DL Expansion Prohibited.

In addition, an MTA shall support the following Elements of Service:

* Explicit Conversion

* Grade of Delivery Selection

* Multi-destination Delivery

* Prevention of Non-delivery Notification

* Probe

* Conversion Prohibition in Case of Loss of Information

* Deferred Delivery

* Deferred Delivery Cancellation

* Redirection Disallowed by Originator.

The functional groups for AMH1 profiles are

* Conversion

* Distribution List

* Physical Delivery

* Manual Forwarding

* Redirection

* Latest Delivery

* Return of Content

* Security

* Use of Directory

* 84 Interworking.

AMH3 has EDI mappings:

An MTA, an MS or a UA shall as the basis of the AMH31 profile support the

following Elements of Service

* EDI Message Identification

* Typed Body

* Character Set

* EDI Message Type(s)

* EDI Notification Request

* EDI Standard Indication

* EDIM Responsibility Forwarding Allowed Indication

* Interchange Header

* Originator Indication

* Recipient Indication.

In addition for the EDIMG-MS and the EDIMG-UA it shall support the following

Elements of Service on reception

* Cross Reference Information

* EDIN Receiver

* Expiry Date/Time Indication

* Incomplete Copy Indication

* Multi-part Body

* Obsoleting Indication

* Related Message(s).

The functional groups for AMH3 profiles are

* Conversion

* Distribution List

* Physical Delivery

* Manual Forwarding

* Redirection

* Latest Delivery

* Security

* Use of Directory

* 84 Interworking

* Multi-part body

* X12 heading fields

* Private syntaxes

* EDIFACT heading fields.

6. MTL - A C++ Class Library for Mobile Service Protocols

This contains a recommended list of the basic ASN.1 data types to use in messages. Basically those are:

Boolean Type

Integer Type

Enumerated Type

BitString Type

OctetString Type

Null Type

CharacterString Type

[Real Type appears to be missing????]

Notes from the Discussion of ASN.1 at the March Working Group Meeting:

1. How to get from structures in the data dictionary to the message body (for specification of message sets)?

If the data dictionary and message set catalog are two separate artifacts, then would involve exporting from the data dictionary (i.e., a DBMS) to the message catalog. This would require mapping (one time) the ITS data dictionary meta structures to the message set template (and associated ASN.1 syntax).

If you have a central ITS data dictionary and/or several integrated functional-oriented data dictionaries, then more/most of the structure (i.e., intelligence) is there and doesn't have to be specified from scratch in the message sets. The message sets can be specified as a part of an ITS data dictionary. Message developers can access and utilize the data dictionaries. The applications will create the messages based on their own internal model of them, which should be consistent with that given in the message set catalog (as part of an ITS data dictionary). Message [instances] are interchanged from one local application to other local application(s). The data dictionary to ASN.1 link is for application development and maintenance, not for runtime messaging.

Other Message-Related Notes from the March Working Group Meeting

Object Class = Link

Data Element Concept = Start Node or End Node

Data Element (which is primitive and has an implementation-level data type associated with it) = Latitude and Longitude

SDO SDO

! !

11179 Data Elements (DB primitives) Message Sets in ASN.1 format

! !

Report in ASN.1 format !

! !

Combination of Message Set Header and Trailer and other message specification with the data elements from the data dictionary

Note: This only works with message sets that involve fairly simple packaging of data elements. If there is a need to embed much of the structure from the data dictionary, then there has to be a tighter coupling of the data dictionary and the message set template. In the best case, the message set should be defined in the data dictionary.

Note: The CVO/CVISN group has lots of implementations of messages in EDI and Edifact contexts. If we decide that the specification notation should be ASN.1, that doesn't preclude existing and new implementations using various messaging languages. That's an implementation issue. Also, if ASN.1 is considered for implementation purposes, it should be noted there are compilers that can take the ASN.1 expressions and translate them into various programming languages.

ITS Service Provider <-> Comms. Interface <-> 1) cellphone 2) pages 3) etc.

Message Set Template: Address; Priority; Security; Content [covered by application standards]

Security Levels would be defined elsewhere for each message set.

PDU header at Layer 7 = message set template header

What is the relationship between the header in the message set template and the protocols required for lower-layers?

The first priority should be to ensure the message set template is sufficient for center-to-center communications, but the DSRC/wireless data that goes through VASP (Value Added-Service Providers) also needs to be considered. The VASPs will filter traffic, emergency, weather, routing and other information for in-vehicle traveler systems.

IEEE/ITS Home Page Sue Vogel, Staff