WO1999022353A1

WO1999022353A1 - Dedicated short range communication system and network architecture for intelligent transportation systems

Info

Publication number: WO1999022353A1
Application number: PCT/CA1998/001009
Authority: WO
Inventors: Peter R. H. Mcconnell; Robert A. Scragg
Original assignee: Sonic Systems
Priority date: 1997-10-29
Filing date: 1998-10-29
Publication date: 1999-05-06
Also published as: AU9731798A

Abstract

Recent advances in the area of Digital Signal Processing chips, signal processing algorithms, and network architectures have allowed the introduction of new methods for implementing components of the Intelligent Transportation System (ITS). In terms of the network architecture, the mobility management function is an important consideration in the network design and operation. A Dedicated Short Range Communications (DSRC) link, together with some of the design aspects of the network architecture and communication interfaces, effectively meet the requirements of the ITS architecture. The DSRC link is an effective one-way and two-way communications link between the vehicle and the roadside.

Description

DEDICATED SHORT RANGE COMMUNICATION SYSTEM

AND NETWORK ARCHITECTURE FOR

INTELLIGENT TRANSPORTATION SYSTEMS

BACKGROUND OF THE INVENTION

The present invention relates to vehicular communications. The Intelligent Transportation Systems (ITS) Architecture has been described in many forms by many authors, but is generally considered as consisting of four subsystems. These are: 1) Center Subsystem - an ensemble of management functions, such as those for traffic management, transit management, emergency management, toll administration, incident management, etc.

2) Roadside Subsystem - a means for sending and receiving information via a wireless means to and from a vehicle. It is generally located at e side of the road. 3) Vehicle Subsystem - the various Vehicles which are being managed by one or more of the management systems at the Center Subsystem. These could consist of personal, transit, commercial, emergency vehicles, etc.

4) Remote Access - these could consist of free or value added services which would be accessed by the Vehicles, or possibly the Roadside and Center Subsystems. Examples of such services are travel advisories, route assistance, weather broadcasts, news, etc.

These subsystems are connected by various communications links. Between the

Roadside and Vehicle Subsystems is a short range wireless communications link, known as the Dedicated Short Range Communication link or DSRC. This link was referred to in the past as Vehicle to Roadside communications link. It is required to provide communications over a short range when the vehicle is in the immediate vicinity one of the Roadside Subsystems. Having a large number of Roadside units over a large geographic area ensures that the required communications capacity or bandwidth is provided. Between the Center and the Roadside Subsystems is a Wide Area Communications Link which is typically a landline interface. This provides the high bandwidth needed by the Center Subsystem management functions, as well as reasonable security and low latency. In some cases where a landline link is not possible, a wireless radio frequency (RF) link can be provided.

Despite the promise of ITS, this promise has to date remained largely unfulfilled due to technical, regulatory and financial obstacles.

SUMMARY OF THE INVENTION The present invention, generally speaking, provides an ITS architecture that uses widely-available, inexpensive technology and that overcomes regulatory hurdles. The use of existing open standards and architectures for the ITS infrastructure provides the required functionality for the ITS network. Advantages gained from such an architecture are the use of existing, off the shelf equipment for most of the network elements such as routers and frame relay elements. The ability to purchase existing equipment from multiple vendors ensures competitive pricing for the network infrastructure as well as rapid deployment of the network. By limiting the services in the ITS network to the Network layer and below, other networks and network application services can be provided external to the ITS network. It is also possible for the ITS network to maintain its own application services within the network. In this way, the same network architecture can be used to support a vast array of applications. With the proliferation of software and protocol stacks supporting TCP/IP, the use of this protocol within the network architecture is a reasonable one. As long as communications links in the network, such as DSRC or wide area wireless links, are required to access the network with an IP protocol, many different communications needs can be easily supported to meet the wide range of requirements in the ITS network. Acoustic communications links for the DSRC link can provide the required functionality for that portion of the network. In addition, an acoustic communications link has the advantages of: license free operation, non-jurisdictional operation and low cost implementation.

The application of advanced error correction and detection mechanisms ensure robust performance in a noisy urban environment. BRIEF DESCRIPTION OF THE DRAWING Figure 1 is a block diagram of an ITS network realized as a collection of service providers;

Figure 2 is a block diagram of a Network Layer Reference Model of the ITS network of Figure 1 ;

Figure 3 is a block diagram of an ITS architecture using a Frame Relay backbone;

Figure 4 is a diagram of a Data Link Layer Packet between the M-ES and RS of Figure 3; Figure 5 is a block diagram of a multi-application vehicle system using a DSRC link; and

Figure 6 is a block diagram of a multi-function application using the DSRC link.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An ITS system generally consists of four subsystems as previously described, a

Center Subsystem, a Roadside Subsystem, a Vehicle Subsystem and a Remote Access Subsystem. Between the Remote Access Subsystem and the Center Subsystem, a landline link provides high bandwidth and low latency access to the various services used by the management functions or for distribution to vehicles within the ITS network. It is also possible for vehicles to subscribe to these services outside of the ITS architecture using wireless packet switched data services from network operators. Such services are provided by various cellular radio operators using Cellular Digital Packet Data (CDPD), and by private operators such as RAM Mobile Data and ARDIS using their Mobitex and RDLAP technologies respectively. A wide range of services can be made available through the ITS network to subscribers within the network. These can consist of standard services available through the network, but also additional services provided by application service providers external to the ITS network. The services provided within the ITS architecture can even be considered as being provided by different service providers within the network, such as emergency management, electronic toll collection, transit management, etc. Services external to the network could be provided by technologies different than those used in the DSRC system described herein, such as wide area wireless network systems. This collection of service provider networks is depicted in Figure 1. Within the context of the Network Architecture, the ITS Service Providers would provide those services associated with the Center Subsystem. For example, one Service Provider network would support the Freight and Fleet Management application, another would provide the Toll Administration application, another would provide emergency management, and so on. These services could be provided on a federal, state, or municipal level, all with the framework of the ITS Network. The external network services would be provided by private or commercial systems offering a service which would be of benefit to the users. An example of this external service would be using a wireless technology such as CDPD to perform remote monitoring or diagnosis of commercial freight vehicles en-route.

The entire ITS Network, as well as the Service Provider Networks, are built up from various functional elements. It represents a true internetwork. The ITS

Architecture and the elements which constitute it can be described with a Network Layer Reference model, such as the Open Systems Interconnect (OSI) model. This model identifies the abstract functional elements in the network and the communications required between each functional element in the network. This is shown in Figure 2, which identifies the interfaces between the various elements of the network.

Some of the concepts used herein follow those used in a wide area wireless network, specifically the Cellular Digital Packet Data (CDPD) network. Although this system is intended for RF communications in the cellular radio band, many of the objectives and concepts pertinent to that system are also pertinent to ITS. Some of the design objectives of the CDPD system were:

1) compatibility with existing data networks, technology, and applications;

2) support for a wide range of present and future data network services and facilities;

3) provide maximal use of existing data network technologies; 4) allow a phased deployment strategy; 5) support multiple network data protocols;

6) minimize impact on End Systems;

7) provide certain services and facilities that are exclusive to mobile and portable situations; 8) support multiple equipment vendors;

9) provide seamless service during subscriber roaming between all networked systems;

10) protect the identity and data of users; and

11) ensure portability of applications The CDPD internal network architecture follows the Open System Interconnect

(OSI) layered protocol defined by the International Standards Organization (ISO). In the following sections, a network architecture is described which is similar to the CDPD network architecture. This architecture has been focused on supporting a Dedicated Short Range Communication (DSRC) system between a vehicle and the roadside, however the architecture can also support other communications means.

Network Interfaces

The ITS network can be thought of as being a collection of networked systems connected to each other by specific interfaces. There are three basic interfaces between the elements of the network, these being:

1) The Airlink Interface (A) - it is the network interface for providing services between the Roadside Subsystem (RS) and the Vehicles (ESs). This is provided using a short range DSRC link. The system described herein uses an acoustic DSRC link. 2) The External Interface (E) - it is the network interface to external networks, where external application service providers communicate with subscribers on the network. This is generally provided by a wireline interface using various network backbones, such as Frame Relay or X.25, to link one network to some external network. Differences in protocols between the two networks would be provided by Network Gateways, which provide the protocol translation between the two systems. 3) The Inter-Service Provider Interface (I) - it is the interface between the cooperating service providers on the network, such as transit management, emergency management, etc. It allows support of all ITS services across all areas served by the combined ITS domains. This is generally provided by a landline interface using various network backbones, such as Frame Relay or X.25, to link the ITS network to some external network. Differences in protocols between the two networks would be provided by Network Gateways.

Network Entities There are four basic elements of the Network Layer Reference model. These elements are connected by the A, E, and I interfaces described earlier. There may be multiple instances of each network entity connected by multiple instances of the A, E, and I interfaces. The two basic elements of the network are the End System (ES) and the Intermediate System (IS). In Internet terminology, the ESs are host computers and the ISs are routers. An ES represents the actual network user systems that wishes to exchange information with some other ES, be it a fixed or mobile. ISs relay data packets between ESs, and are responsible for routing them toward their intended destination in an efficient manner. The purpose of the network is to allow data to be transmitted. ES's are abstractions of the real network service users, such as freight and fleet management applications, toll administration, emergency management, transit management, etc. There are two types of ESs in the network. A Fixed-End System (F-ES) is traditionally a data application system or internal network support and service application system. Their location is fixed, and traditional routing is possible based on a network address, implying location. A Mobile-End System (M-ES) on the other hand, changes physical location over time. Communication with the network is gained through a large number of fixed Roadside Systems (RSs) within the network which provide a communication link between the network and the M-ES. Network access may be continuous or intermittent, depending on die coverage provided by the RSs. It is possible for more than one application to reside on an M-ES. It is only necessary that the proper addressing and routing between end system applications exist in the network. It is the responsibility of the protocols running on the network elements to ensure that data is multiplexed correctly between these applications. Methods for providing support for multiple applications using a single DSRC link are available using traditional computer communications techniques such as a Socket interface.

Mobility Management

In the ITS Network, vehicles or M-ESs are highly mobile. The RS used for vehicle to roadside communication at one instant in time will likely not be the RS used at a later instant in time. Communication from the vehicle to roadside is less of a problem that of the roadside to vehicle direction. In order for the network to maintain communication with an M-ES, there is a need for a mobility management function to maintain knowledge of where an M-ES is within the network, allowing data destined for a vehicle to arrive in a reliable and timely manner through the RS serving that M-ES.

This mobility management function is concerned with the maintenance of a location information database and the routing of Protocol Data Units (PDUs) based on this information. Each M-ES in the network is identified by a distinct Network Entity Identifier (NEI) or address which is used to route messages to the M-ES, however the network must be aware of the M-ES location in order to route information to it. This can be done by maintaining special Mobile Data Intermediate Systems (MD-IS) within the network which provide routing functions within the network based on the additional knowledge of d e current location of the M-ES. They provide, in a sense, a relay function. When a vehicle is being served by its Home MD-IS, that MD-IS can maintain an awareness of the vehicle location by having the vehicle announce its presence at every new RS. W en a vehicle is being served by a different MD-IS, its home MD-IS is notified of the vehic iEs new serving MD-IS location. Messages destined for the vehicle are always sent to the vehicle_£s home MD-IS first. If the serving MD-IS is not the same as the home MD-IS, the home MD-IS forwards the data to the serving MD-IS where it is then delivered to the vehicle. In the case of data sent from the M-ES to some F-ES in the network, normal routing procedures apply since there is no need to treat this in a special manner. This mechanism provides a simple yet reliable means of managing mobility within the network. One key advantage is that the location information resides only at the MD-IS and does not have to be made known to all of the routers in the network. This is not only simple in a logistical sense, but it does not require any additional memory in the routers (ISs) for the routing tables.

Security In addition to being able to support mobility of the M-ESs, the network must be able to support a number of other important features. These features include:

1) Authentication - the network must be able to authenticate users of the network services to prevent fraud and other misuses.

2) Content Security - some form of encryption must be provided to ensure that user data is protected over all links between elements of the networks.

3) Location Security - the network must hide the location of M-ESs, except from applications authorized to access this information.

There are many mechanisms available for providing authentication and content security, such as the Diffie-Hellman key exchange algorithm and the Federal Data Encryption Standard (DES). These can be provided within the network as a network service, or by the cooperating end to end applications. Location security may be provided by ensuring access security to the location tables in the MD-IS.

Communication Architecture The communications model used for the ITS Architecture is the OSI Network

Model. This provides a model for end to end applications to communicate. The seven layers within tiiis model are:

1) Application Layer;

2) Presentation Layer; 3) Session Layer; 4) Transport Layer;

5) Network Layer;

6) Data Link Layer; and

7) Physical Layer. These layers are described in detail elsewhere. Various open protocols and standards can be used within this model to provide the services required by the network, with these protocols being resident within different elements of the network architecture. For example, the RS would typically only support the Data Link and Physical layers of the protocol stack. Due to the bursty nature of most data intended to be sent to and received from a vehicle, a connectionless network protocol is used. With such a protocol, the network routes each packet individually based on the destination address carried in the packet and knowledge of the current network topology. One such protocol is the Internet Protocol (IP), as based on the Internet Transmission Control Protocol/Internet Protocol (TCP/IP). TCP is a Transport Layer protocol, and IP is a Network Layer protocol. Connection oriented services may be provide by end to end protocols operating above the Network layer, such as TCP. As long as the network supports the Network Layer and below, the communicating end systems can be responsible for providing the Transport Layer and above. This communication architecture running on a Frame Relay network backbone is shown in Figure 3. In this network realization, the Frame Relay backbone is used to connect the RSs to the ISs within the network, and may also be used for IS to IS interconnection.

The advantage of this type of architecture is that only the M-ES and RS represent special functional elements; all other elements are represented by presently available off the shelf hardware based on existing open standards. This significantly reduces the overall system development cost, and drastically reduces the deployment time since little new development is required. It also allows relatively easy interconnection with existing networks and network backbones.

There may be more than one type of RS in the network. The RS supports only the Data Link and Physical Layers of the protocol stack required to support the DSRC link, and essentially encapsulates IP packets exchanged between an M-ES and an F-ES. Since the IP packets are encapsulated, many different types of Vehicle to Roadside Subsystem interfaces can be supported which provide specific types of encapsulation to deal with die nature of the interface, be it acoustic, radio frequency, etc. The actual packets exchanged between the network layers at the M-ES and d e F-ES remain IP packets. It should be noted diat this architecture also allows for communications between one M-ES and anod er M-ES, not just between an M-ES and an F-ES.

Acoustic DSRC Link For Vehicle/roadside Communications One of the major challenges for ITS is to provide DSRC functionality between the Roadside Subsystem and the Vehicle Subsystem. The need for short range is to ensure that a high overall system bandwidth can be achieved. This concept is analogous to that used in cellular radio systems where cell splitting is used to reduce the size of a cell and provide more overall capacity as measured in terms of subscribers per unit area. The technologies available for DSRC use include radio, optical, and acoustic communication means.

Recent advances in Digital Signal Processing (DSP) chips has made it possible to implement advanced signal processing algorithms which were previously not possible due to the high system cost. Advances in chip fabrication technologies and the applicability of these devices in a wide range of applications (wireless voice and data communications, multimedia, etc.) have resulted in very low cost devices and extremely fast processing speeds (50 million instructions per second and up). What would have been impossible to implement 20 years ago is very easy to implement today, again using off the shelf technology. In an exemplary embodiment, a DSP based acoustic processing system (the

Sonem 2000 system of the applicant, Sonic Systems) provides the DSRC link functionality. The system uses a bi-directional acoustic link between d e roadside and the vehicle. The M-ES is equipped with an acoustic transmitter and receiver which operates in a packet switched mode to exchange data with a similarly equipped RS. These packets consist of framing information, control and addressing information, user information, and error correction/detection information. This framing provides the data link layer part of the protocol described in Figure 3 , which performs the IP packet encapsulation between the M-ES and RS. Since an acoustic communication link, much me same as for RF and optical links, is a noisy channel widi error rates much higher than experienced in landline communications (the average bit error rate is typically 0.001 or higher), suitable error correction and detection measures are used to provide an effectively error free link between the Network layers which reside on top of the Data Link Layer. By adding parity information to the DSRC packets, it is possible for a packet received in error to be corrected at the receiving location and the validity of diat corrected packet to be determined to a very high degree of reliability.

The RS interface to the network infrastructure supports a variety of physical layer standards. In an exemplary embodiment, this layer is implemented in firmware on the DSP chip, interfaced through a Direct Access Arrangement (DAA) to a dedicated land-line interface. Various standards may be supported such as Bell 212A, V.23, V.22, V.22bis, V.21ter, V.29, V.34, etc. Other modem protocols are easily realized in the DSP chip by simply adding software. The RS also provides NEMA standard preempt outputs to a local traffic light controller for siren detection functionality.

Details Of The Data Link Format In an exemplary embodiment, the Physical Layer uses an antipodal Gaussian

Minimum Shift Keying (GMSK) signaling scheme to provide data rates of between 25 bits per second to 250 bits per second between the vehicle and the roadside. The carrier frequency can be in the audible or inaudible range, ranging from 1000 Hertz to 30 kilohertz. In an exemplary embodiment, the peak deviation is 500 Hertz. The link layer provides error correction/detection, packet sequencing, and control functions, similar to High level Data Link Control (HDLC). The data link layer packets, depicted graphically in Figure 4, consist of a variable length packet widi the following fields:

1) preamble; 2) frame synchronization word; 3) header field;

4) data field; and

5) parity field.

In an exemplary embodiment, the error correction scheme used is a rate one-half block code, and the error detection scheme is based on a 32-bit Cyclic Redundancy Check (CRC). The protocol used between the M-ES and the network, for example TCP/IP, is encapsulated by this DSRC link layer protocol for transmission over the A- interface. Protocols other d an TCP/IP are supported, however the same packet encapsulation is performed over the DSRC.

Nature of the Acoustic Link

Acoustic communication links are ideal for short range communications, with ranges typically being on the order of 1000 feet or less. One of the major problems faced by such a system is that of ambient noise due to traffic, construction, aircraft, etc. This noise can create errors in me packets exchanged across the A-interface, with the errors ranging from single bit random errors to large error bursts consisting of several bits. To combat these types of errors, a combination of burst error correcting codes and interleaving are used to provide error correction for both types of errors. Packets which contain errors beyond the error correction capability of the coding are simply retransmitted. This method is quite common in packet switched communication systems.

Of critical importance to applications is the reliability of the data exchanged across the link. This can be expressed as the probability of undetected error, which is the probability that a packet was received by an end system with an error in it but with the link layer protocol indicating erroneously that it is correct. Using a CRC-32 ensures that this probability is less than 2.3 x 10-10. This compares with the probability of undetected error for an RF link of typically 2.8 x 10-8. Additional protection can be applied by the end system applications if needed.

The signaling scheme used in the acoustic DSRC allows reliable packet communication in an environment where the carrier to noise ratio is about -2 decibels (dB). This stringent performance requirement arises due to the intensity of normal background noise in the vicinity of roadsides. Typical sound pressure level (SPL) in the vicinity of a 4-lane freeway range from 80 dB to 90 dB SPL referenced to 0.0002 microBars pressure. The sound level in the vicinity of airports has been measured to be as high as 95 dB SPL. Testing of this acoustic DSRC has been used for siren detection up to a distance of 1 mile when die ambient sound level was about 75 dB SPL. This level of performance would not be possible without the use of a DSP based detector.

A One-Way DSRC A one-way DSRC is one in which information is exchanged between a vehicle and the roadside or the roadside and the vehicle, but not in both directions. It is generally done using a simplex or half-duplex mode of operation.

Using a one-way packet based DSRC from the vehicle to roadside, information about the vehicle and the nature of the request can be made to the RS. Each packet contains the unique address or NEI of the vehicle making the request, and the data field may contain a request to a traffic control application. This information can be routed to a traffic light controller directly or into the ITS network using the network interface on the RS. This has immediate application as follows:

1) In die case of emergency vehicles, the unique address in the packet plus the information in the data field allow the traffic management system to immediately identify die vehicle as an emergency services vehicle and give it highest priority. The information in the data field could contain a request for preemptive straight through passage, preemptive right turn passage, preemptive left turn passage, etc.

2) In die case of a transit vehicle, the unique address in the packet plus the information in the data field allow die traffic management system to immediately identify die vehicle as a transit services vehicle and give it priority, but not as high as that given to an emergency vehicle. The request would be sent via the network interface on the SONEM-2000 to the transit management application through the ITS network.

3) In the case of a commercial vehicle, the unique address in the packet plus the information in the data field allow die traffic management system to immediately identify the vehicle as a freight and fleet vehicle. It most likely would not be given priority as far as traffic signaling goes, but would be utilized for such operations as Weigh In Motion (WIM).

In addition to an acoustic DSRC communications system, the device is also capable of detecting emergency vehicle sirens and issuing a preempt request signal. This is a basic one-way DSRC in which the vehicle siren acts as a vehicle based transmitter, and the SONEM-2000 acts as a roadside receiver. The preempt can be directed to a traffic light controller at the roadside, or to a traffic management application running on an F-ES in the network (most likely at a central traffic management and control center). This allows emergency vehicles approaching an intersection to be granted a green light on approach to the intersection and a red light to be given to all other directions of approach. Such a system can reduce the response time of an emergency vehicle, and reduce die risk of collisions with odier vehicles at the intersection. This system represents the simplest form of one-way acoustic DSRC. The use of a DSP based detector for this function allows advanced signal processing algorithms to be implemented which would be eidier very expensive or impossible using odier means. Once a siren has been identified by d e signal processing algoridim and it is determined tiiat the vehicle is within d e detection range, a preempt is issued in favor of the approaching emergency vehicle. Although sirens are intended to sound die same, in practice they are slightly different in their characteristics. This often prevents sirens from being reliably and uniquely identified. This problem is solved by using signal coding techniques to assign each siren on a vehicle or within a group of vehicles a unique code or key. An emergency vehicle equipped wid a siren which sends diis coded siren sound can only obtain a preempt from a roadside unit which has been programmed to respond to that code. The SONEM-2000 maintains a list of codes which allow:

1) vehicles belonging to the recognized groups to obtain a preempt; and

2) vehicles to request specific actions from a traffic light controller The use of advanced signal processing algorithms and a DSP processor has provided die ability to detect sirens in conditions where the background sound noise level exceeds die actual siren sound level. Since die DSP chip processes the received signals in exactly the same manner time after time and regardless of the environmental conditions, the performance has been found to be highly consistent.

A Two- Way DSRC

A two-way DSRC is one in which information can be exchanged from vehicle to roadside, and vice versa. This may occur in a simplex, half-duplex, or full duplex mode of operation.

Using a two way packet based DSRC, other applications at the Center Subsystem can be performed. These include Toll Administration, Commercial Vehicle Administration, Incident Management, etc. In this case, packets are sent from the roadside to the vehicle as well as die from the vehicle to the roadside. One interesting aspect of me two-way communication system applied to emergency vehicles is that an accurate ranging function can now be performed on vehicles as they approach an intersection. A loudspeaker at the intersection can send a packet to the vehicle and have die vehicle immediately resend that packet back to die intersection. By measuring the round trip time for that packet (called a PING), d e RS can accurately determine the distance of me vehicle from the intersection. Using successive PINGs, the speed can also be measured. Using this information, the RS can issue a preempt at an accurate distance, or it can vary the timing to compensate for a vehicle.tEs speed (i.e. it can issue it later than normal if the vehicle is approaching the intersection slowly, thereby ininimizing the disruption of normal traffic flow patterns).

In both the one way and two way acoustic DSRC systems, many M-ESs in the vicinity of the RS can exchange data widi die appropriate applications at the Center Subsystem and ensure that die data reaches the correct destination. This is assured by the Transport and Application Layers in die protocol stack between die communicating systems. In this way, a vehicle can simultaneously support several applications at die same time. For example, the Toll Administration and Freight and Fleet Management applications could exchange information with a vehicle using the same RS in die network. The network simply serves as the transport mechanism for the information exchanged between both of die applications.

An example of the protocol stack required for the vehicle subsystem is shown in Figure 5. This stack allows multiple applications to be supported using a Socket Interface at the Session layer. In this way, many applications can utilize the same underlying stack elements to perform the required communications functions.

A transit application using multiple applications plus an external network interface is shown in Figure 6. In the vehicle, diere is support for the following;

1) Fare Collection - diis application provides fare collection information to a transit operators accounting computer as fares are collected along die transit routes.

2) Passenger Count - this application provides passenger count information to the transit management computers in real-time.

3) Vehicle Sensor Monitoring - this application acquires performance data and status from various mechanical and electrical systems on the vehicle and reports these at regular intervals or whenever operating limits are exceeded. This includes such information as engine temperature, exhaust gas temperature, brake temperature, rear axle temperature, fuel consumption, etc.

4) Traffic Light Control - this application requests preempts at intersections with traffic light control systems to obtain a priority passage at that intersection. 5) Traffic Advisories - this application sends messages to the vehicle regarding conditions ahead on die roadway. Indexes to messages in a stored dictionary are sent to a vehicle and displayed visually to die driver and also enunciated verbally using a voice playback system.

6) External Services - this application accesses odier networks to obtain services that are of a much higher bandwiddi and wider area nature than ie DSRC. In this example, a wireless RF link using die CDPD network or the Circuit Switched CDPD network is shown. If for example the Vehicle Sensor Monitor signaled a fault condition, the transit operator could access the vehicle using the wide area RF network and run diagnostics on die vehicle in real-time. Decisions could be made to keep d e vehicle in service or return to the service yard for repair. Mobility Management-Continued

The presence of Roadside systems can be made known to nearby vehicles by occasional broadcasts from the Roadside system to query any nearby vehicles (M-ESs). This broadcast also contains a unique RS identifier, allowing the M-ES to determine if it has changed location. If a vehicle has any information to send, it does so after the broadcast message. If the vehicle determines tiiat it has changed location, die vehicle can respond to the first broadcast it hears from an RS simply to announce its presence at that location to network, thus allowing the mobility management function of die network to determine the location of the M-ES. If the network has any information to send to the M-ES, it routes that information to the M-ES at the location where it announced itself and sends an acknowledgment to die application indicating mat die M-ES has in fact received the message. This provides a Store And Forward functionality in the network for service provider applications.

It will be appreciated by diose of ordinary skill in the art that die invention can be embodied in odier specific forms without departing from the spirit or essential character thereof. The presently disclosed embodiments are therefore considered in all respects to be illustrative and not restrictive. The scope of the invention is indicated by die appended claims rather than the foregoing description, and all changes which come within the meaning and range of equivalents thereof are intended to be embraced merein.

Claims

Claims:

1. A wide area network including an acoustic digital short range communications link, the network comprising: a plurality of Mobile End Systems; a plurality of Roadside Systems; a link between the Mobile End Systems and die Roadside Systems including an acoustic physical layer link; wherein the acoustic physical layer link between the Mobile End Systems and the Roadside Systems is a full duplex or half duplex bidirectional link, and data link layer formatting of the acoustic physical layer link supports packet switched acoustic data communications.

2. The apparatus of Claim 1, wherein the data link layer format provides error correction and error detection across the acoustic link.

3. The apparatus of Claim 2, wherein data link layer packets contain header information including packet number sequencing and control information.

4. The apparatus of Claim 2, wherein data link layer packets contain address information including a source address and a destination address.

5. The apparatus of Claim 1, further comprising means for sending an End System Query packet to all Mobile End Systems in the vicinity of a Roadside System.

6. The apparatus of Claim 5, wherein a Mobile End System responds to the End System Query with an acknowledgment packet which contains die address of the Mobile End System.

7. The apparatus of Claim 6, wherein a Roadside System measures Round

Trip Time for the response to the End System Query and determines a distance from the Roadside System to die Mobile End System using die Round Trip Time and die speed of sound.

8. The apparatus of Claim 7, wherein the Roadside System uses multiple

End System Queries to determine the speed of approach of the Mobile End System.

9. The apparatus of Claim 7, wherein the Roadside System uses multiple End System Queries and increasing, fixed, or decreasing round trip times to determine if me Mobile End System is going away from, sitting stationary, or coming towards the Roadside System, respectively.

10. The apparatus of Claim 1 , further comprising one or more Mobile Data Intermediate Systems, wherein: each Mobile End System has a home coverage area and is linked to a Home Serving Mobile Data Intermediate System; and a Mobile End System operating outside of its home coverage area is linked to a

Serving Mobile Data Intermediate System, and die Serving Mobile Data Intermediate System notifies die Home Serving Mobile Data Intermediate System of die location of the Mobile End System.

11. The apparatus of Claim 10, wherein packets destined from within die network to roaming Mobile End Systems are first sent to the Home Mobile Data Intermediate System and dien rerouted die Mobile End System via die Serving Mobile Data Intermediate System.

12. The apparatus of Claim 11, wherein packets destined from any Mobile

End System to any odier Mobile End System in die network are directed using standard routing procedures to their intended destination.