EP0883872B1 - Verfahren und anordnung zur information mobiler teilnehmer - Google Patents

Verfahren und anordnung zur information mobiler teilnehmer Download PDF

Info

Publication number
EP0883872B1
EP0883872B1 EP97952715A EP97952715A EP0883872B1 EP 0883872 B1 EP0883872 B1 EP 0883872B1 EP 97952715 A EP97952715 A EP 97952715A EP 97952715 A EP97952715 A EP 97952715A EP 0883872 B1 EP0883872 B1 EP 0883872B1
Authority
EP
European Patent Office
Prior art keywords
route
request
message
der
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
EP97952715A
Other languages
English (en)
French (fr)
Other versions
EP0883872A1 (de
Inventor
Bernd Günther
Henning Weise
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telekom Deutschland GmbH
Original Assignee
Deutsche Telekom AG
DeTeMobil Deutsche Telekom Mobilnet GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Deutsche Telekom AG, DeTeMobil Deutsche Telekom Mobilnet GmbH filed Critical Deutsche Telekom AG
Publication of EP0883872A1 publication Critical patent/EP0883872A1/de
Application granted granted Critical
Publication of EP0883872B1 publication Critical patent/EP0883872B1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0968—Systems involving transmission of navigation instructions to the vehicle
    • G08G1/096805—Systems involving transmission of navigation instructions to the vehicle where the transmitted instructions are used to compute a route
    • G08G1/096811—Systems involving transmission of navigation instructions to the vehicle where the transmitted instructions are used to compute a route where the route is computed offboard
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0968—Systems involving transmission of navigation instructions to the vehicle
    • G08G1/096833—Systems involving transmission of navigation instructions to the vehicle where different aspects are considered when computing the route
    • G08G1/096838—Systems involving transmission of navigation instructions to the vehicle where different aspects are considered when computing the route where the user preferences are taken into account or the user selects one route out of a plurality
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0968—Systems involving transmission of navigation instructions to the vehicle
    • G08G1/096855—Systems involving transmission of navigation instructions to the vehicle where the output is provided in a suitable form to the driver
    • G08G1/096861—Systems involving transmission of navigation instructions to the vehicle where the output is provided in a suitable form to the driver where the immediate route instructions are output to the driver, e.g. arrow signs for next turn
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0968—Systems involving transmission of navigation instructions to the vehicle
    • G08G1/096877—Systems involving transmission of navigation instructions to the vehicle where the input to the navigation device is provided by a suitable I/O arrangement
    • G08G1/096883—Systems involving transmission of navigation instructions to the vehicle where the input to the navigation device is provided by a suitable I/O arrangement where input information is obtained using a mobile device, e.g. a mobile phone, a PDA

Definitions

  • the invention relates to a method and an arrangement for route information mobile Participant according to the preamble of claim 1.
  • WO-A-90/02391 describes a route guidance system for determining a route between two given geographic locations.
  • the location information is provided by a User fed a central data processing system, which from this data generates a route description and makes it available to the user.
  • This system is not for mobile use, i.e. a mobile user.
  • WO-A-96/11381 relates to a device for guiding people.
  • the facility comprises a navigation unit which has a receiving device for wirelessly transmitted Has information for recognizing the current geographic position, a Communication unit, which is an input unit in particular for entering a target position and an output unit, in particular for output of route guidance information.
  • a central computer for route planning is also provided, which has a memory has at least one digitized road map and that with the navigation unit is technically connectable via the communication unit. The computer transmits the calculated route information to the navigation unit.
  • the current position can be shown on a map and it can Route directions are issued.
  • WO-A-96/00373 relates to an electronic navigation system in which starting from a subscriber unit makes a route request to a central unit in which Central unit a route calculation and preparation of the data and the complete route information is transmitted to the subscriber unit in which one The route is processed.
  • the object of the invention is to provide a method and an arrangement for To propose route information of mobile participants that is always current to the participant Provides information and at the same time offers a high level of user comfort.
  • data can be related to a wide variety of output parameters e.g. Location, start or destination information or route information of the trip, Central or terminal-side queries that are device-based or person-based can be carried out.
  • the data transfers can too Information acquisition purposes and / or for information transmission purposes as well be carried out to update information.
  • the navigation services support the customer on their way to their destination Route.
  • the route is calculated taking into account the current traffic situation in the service center.
  • the orientation guide described in this document is a simple navigation service, the customer with limited wrong way detection and return to his destination leads.
  • the route is preferably presented in the terminal by means of a Rough route description and can be represented in particular by icons (signposts) are used to guide the customer to their destination.
  • the orientation aid has preferably a restricted mistrack detection. A targeted return to the Route can be supported
  • the Orientation Aid service is intended in particular for devices that do not stored location or street data like a digital map in the vehicle, but only with Positioning devices such as are equipped with GPS (in the following is mostly a system with GPS is described as an example). It is therefore usually not possible to be exact at a certain location (maneuver point) turn instructions such as B. "turn right now” to give, because due to the limited positioning accuracy often the necessary exact determination of the vehicle position (especially with GPS approx. 10m) not is possible.
  • the central unit takes into account the route generated by the Terminal transmitted information about the location function of the terminal (e.g. pure GPS or additional dead reckoning). This ensures that even with end devices a functional orientation aid without dead reckoning - albeit of lower quality - becomes possible.
  • the route evaluation service is also described in this document.
  • the Route evaluation becomes a route known in the terminal from the terminal to the head office transfer.
  • the route is based on the current traffic situation Estimated travel time and transferred to the terminal.
  • Various forms are supported for entering the destination address (e.g. city and street, POI: e.g. B. airport, train station).
  • POI e.g. B. airport, train station
  • the route request is followed by a destination request directly on the end device
  • the customer information is checked for correctness, completeness and uniqueness. Possibly. an error message is sent to the vehicle.
  • the user request is incomplete If the address information is not clearly interpreted, the error message will result in a Selection list delivered to the vehicle with which the request can be specified.
  • the route is prepared at the headquarters. With the Route_Message the Route information sent to the vehicle. With the transfer of the route into the vehicle is for the head office ended the request.
  • the list of waypoints is processed locally in the end device.
  • the order of Waypoints on the route are given by the order of their appearance in the list.
  • the route is processed sequentially according to the waypoint list, whereby for each Intersection at which a turning maneuver must be carried out, this by an appropriate Icon is displayed.
  • Wrong journeys are recognized when the customer enters a given corridor whose width the route description is loaded into the terminal.
  • This service enables the evaluation of a route existing in the terminal with regard to the travel time to be expected on the basis of the current traffic situation (see FIG. 3). For this, the Transfer the route description (of the route to be calculated) to the head office (Travel_Time_-Request_Message). The route becomes the same as for orientation aid or route guidance described in the form of guidance points.
  • the head office estimates the travel time for this route based on the current traffic situation and transfers this to the end device (Travel_Time_Message).
  • the individual services are described functionally and the specific ones Processes shown based on the ADP's.
  • the coding of the ADPs is explained.
  • the services can be parameterized with regard to certain processes and functions.
  • the defined Service parameters are listed in this document. Determining the individual Service parameterization is the task of the respective service provider. This basic specification sets the total scope of those to be supported by first generation devices Functions and processes. In addition, these processes and functions can be performed by respective service providers are specified in more detail in separate documents.
  • Mailbox flag MF 1 0 no messages in the mailbox 1: There are messages in the mailbox Debit Info MF 4 0: not supported in this version Length user data MF 9 Number (in bytes) of the user data transmitted within the message (CAS header + ADPU)
  • the framework supports the sending of several short messages.
  • Application IDs are unique service identifiers assigned by the head office. This are transferred in the Application ID field in the transport layer.
  • the service providers can operate independent services within the defined processes define. These can, for example, be characterized in that the transmitted Information content can be restricted. To identify the services offered Assign service identifiers.
  • the Initiative Flag 1 (initiative).
  • Protocol Discriminator and Message Type are in the document "Message Type Numbering ".
  • the bulk flag is always set to 0
  • the timers relevant for the navigation services are listed below. description function unit value range resolution default TNAVa Waiting state for reply of a route message or an error message sec 0-300 30 90 TNAVb Waiting for the first call to the call center sec 0 - 60 5 10 TNAVc Max. Duration of access to the operator at the call center min 0 - 15 1 5 TNAVd Waiting for an answer sec 0-300 30 90 Travel time message
  • the terminal For the orientation aid service, the terminal must have the full address management Support functionality of internal services.
  • the terminal For the route evaluation service, the terminal must have the full address management Support functionality of internal services.
  • the switch determines whether the entry of complete telephone numbers is also permitted.
  • Address_request_ambigious_addresses_selection_list Commentary Selection lists are returned for address inquiries 35 1
  • one Online service initiates a route calculation (also with a time delay) so that the terminal then receives a route description without initiating a route request. In this case it starts the process immediately with the processing of the route in the terminal.
  • the end devices must process this processing from "foreign", i.e. route initiated by third parties Support messages.
  • Via points can be used to exclude or close unwanted routes correct. Avoidance points are initially not supported.
  • the head office checks the information received for correctness, completeness and uniqueness and assigns the address or addresses a geographic coordinate or their geographic Coordinate to (see below).
  • the customer When entering the destination on the end device, the customer provides the addresses for the destination and all desired Viapoints on the end device or select them from an existing one Address memory of the terminal.
  • the addresses are transmitted to the head office via the Route_Request_Message and there checked for correctness, completeness and uniqueness. In the event of incomplete address details there is an error message, which if possible an address selection list for the questionable Contains addresses.
  • the customer can then select the desired address and with it initiate a new route request. It can be set by a parameter whether the control center fundamentally supports the return of selection lists (see Chapter 2.7). All in the ADP provided fields for the specification and transmission of address information are support on the terminal side. Which combinations and subsets on the central side support is to be specified specifically for the service provider.
  • the error message is transmitted to the vehicle. This can contain selection lists. The support of the error message depends on the service provider.
  • Postal code and telephone number may not be passed at the same time, otherwise there is an error message. The same applies if the place name and postal code or telephone number are contradictory.
  • control center can use the bit "start / desination / additional address ambiguous ".
  • a selection list field follows within the Address description, in which an error declaration in free text in the "Additional Information" field is specified. If a complete telephone number cannot be clearly interpreted, then returned the phone number with the digits that could be interpreted (Example: 0228-5201900 is transferred, the control center can dial the number up to 02285201 interpret and return this number).
  • the coding of the individual IE's is detailed in the ADP for the navigation services described.
  • the request telegram is not subject to any special restrictions. It is recommended that Starting address and the criteria selected by the customer for route calculation in the end device to save and transfer to the control center.
  • the desired operator request is also identified in the message by that no destination address is also transmitted.
  • the message must contain the start address (pearl necklace or postal address description). If desired, the criteria for route calculation can already be transferred with the request.
  • the message can also contain all other IE's except for the destination address. It's closed recommend that the criteria selected by the customer for route calculation in the end device save and transfer to the central office.
  • the operator determines the in dialogue with the customer missing information until there are unique addresses for the destination as well possible via and avoid points.
  • the center then sends the route after the route has been calculated (Route_Message) into the vehicle.
  • the route is based on the transmitted information based on the current Traffic situation created and coded in the Route_Message. Then the Transfer Route_Message to the vehicle.
  • the central one When calculating the route and preparing the route, the central one is used for the Route request with transmitted information about the location considered. In doing so first a terminal with pure GPS and terminals with additional coupling navigation distinguished.
  • the travel time to the destination is transmitted in a rounded manner, ie the head office rounds the calculated travel time (e.g. 37 minutes or 3 hours, 31 minutes) to a reasonable value, which depends on the accuracy of the calculation (e.g. 40 minutes; 3 hours, 30 minutes). If an arrival time is calculated in the end device from the travel time to the destination by addition to the actual time and displayed to the customer, then an additional rounding should also take place here. A suggestion is made in the table below: Travel time to the destination Proposed resolution up to 30 minutes 5 minutes up to 90 minutes 10 mins greater than 90 minutes 15 minutes
  • the list of waypoints denotes maneuver points. They are placed in places where the driver is likely to need information in order to be able to follow the route (turn, classify, name changes of streets, etc.).
  • the order in which the waypoints are to be driven is by the order of the Waypoints specified in the list.
  • the waypoints can be positioned to be handled differently depending on the service provider. This is especially for the first or last waypoint in a waypoint list. In their interpretation is also the code contained in the IE "Type of Starting Point” or "Type of Destination” to consider. The exact definitions are specific to the service provider Additional specifications made.
  • the terminal should then be in compass mode switch, with the compass arrow pointing to the first waypoint.
  • the type "capture area" is not supported for guidance.
  • the rough textual description of the route contains essential milestones of the route Provide users with an overview of the route to be traveled (e.g. drive from Bonn to Düsseldorf: A555 to Kreuzchen Süd, A4 todorfchen Ost, A1 to Stammchen Nord, A57 to Buch Kaarst).
  • the milestones are transmitted either as text or as geo-code. A mix of text and geo-codes is possible.
  • the geographic coordinates are dependent on the type of intersection and set link flag set.
  • the meaning of the coordinates is specified in the service specification of the Provider specified in detail.
  • the geographic coordinates are preferably assigned according to the following rules: mating type link flag unset link fiag set 1st waypoint 2nd waypoint star Center of the junction Center of the junction 1st intersection Center of the junction 2nd intersection roundabout traffic Entry point of the roundabout Entry point into the roundabout Exit point from the roundabout Motorway exit / fork Start of the turning lane for simple exits, for complex exits the actual exit lane % %
  • both waypoints contain an icon coding of the star type.
  • the screen display should be in an icon.
  • the Exit street of the 1st waypoint is closed with the entrance street of the 2nd waypoint combine.
  • Wrong journeys are recognized because the reference area spanned by the corridor width the user must be informed.
  • the terminal should now give the user the Give the possibility to start a new route request related to the same destination. additionally should be switched to compass mode, with the arrow pointing to the closest one Waypoint shows.
  • a change in the waypoint pointed by the arrow should be explicitly acknowledged by the user.
  • the user can switch between waypoints in compass mode.
  • the user should only be informed of an incorrect drive when the position is above moved a greater distance outside the corridor. This can cause inaccuracies in the GPS are taken into account or suppressed.
  • the further one Clarification / individualization takes place via the evaluation of the geo codes relative to the current position or to the waypoints and the associated corridor information.
  • T-Traffic traffic reports preferably contain these Street name (e.g. A555, B236). This makes it possible to record traffic reports refer to roads that are on the route from the total of the terminal filter out existing traffic reports (e.g. in the case of or targeted VI service, cell broadcast).
  • the terminal device should not include one in the rough route description receive interpretable geo-code, then this can be done using the TINFO message TINFO_Code_Request_Message can be translated into plain text (see ADP TINFO).
  • Traffic announcements contain a bypass flag. Will a traffic announcement Received on the route with the redirection flag set, should the customer with the display the traffic announcement the possibility of a new route request (combined with a travel Time request) (see also chapter 3.4).
  • Each service provider can freely assign numbers for service provider POIs Assign individual POI types (e.g. petrol stations, ATMs).
  • individual POI types e.g. petrol stations, ATMs.
  • service provider POIs are not initially numbered established. If service provider POIs are to be used for the navigation service, then the complete address of the desired one must be used by using an information service POIs can be loaded from the head office. This address can then be used for a destination request be used. It should always be the complete address information received from the central office to the service provider POI to avoid ambiguity (see also Chapter 3.1.1.1).
  • the request to the control center is only the route request message (no operator, see Fig. 5).
  • the information is off at the central site the route message (at least the starting position) and from the dialog with the operator merge. It must be through a timer-based synchronization mechanism be sure that the Route_Message is available to the operator at the start of the call.
  • the terminal After a timer has expired, the terminal sets up the voice connection to the operator (FIG. 6).
  • Route_Messages that it did not initiate (FIG. 7).
  • Route_Messages can e.g. B. Online services have been initiated via other media).
  • the route message should never be presented without an active acknowledgment by the user.
  • a route description (a calculated route) is included in the route evaluation Transfer headquarters (Travel_Time_Request_Message).
  • the Rolute is like the Orientation aid or route guidance described in the form of guidance points.
  • the head office estimates the travel time for this route based on the current traffic situation and transfers this to the end device (Travel_Time_Message).
  • the coding of the individual IE'S is detailed in the ADP for the navigation services described.
  • the service-specific error messages are defined in the ADP.
  • Services Cross Errors e.g. communication errors
  • Description of the cross-service error handling is described in the document "Description of the cross-service error handling ".
  • Cross-Service Error Handling Description Document additional destination 1 not identified s. Chapter 3.1.1.1 additional destination 2 not identified s. Chapter 3.1.1.1 additional destination 3 not identified s. Chapter 3.1.1.1 additional destination 4 not identified s. Chapter 3.1.1.1 additional destination 5 not identified s. Chapter 3.1.1.1 additional destination 6 not identified s. Chapter 3.1.1.1 additional destination 1 ambiguous s. Chapter 3.1.1.1 additional destination 2 ambiguous s. Chapter 3.1.1.1 additional destination 3 ambiguous s. Chapter 3.1.1.1 additional destination 4 ambiguous s. Chapter 3.1.1.1 additional destination 5 ambiguous s. Chapter 3.1.1.1 additional destination 6 ambiguous s. Chapter 3.1.1.1 phone call not completed s.
  • the data communication between the terminal and the control center is carried out by the GSM available short message service. Unlike other VT services Cell broadcast is not required for navigation services, so only Short message services SMS-MT (TS 21) and SMS-MO (TS 22) for handling the Services are needed. In order to continue to allow operator requests, the voice service (TS 11) are supported.
  • GSM Global System for Mobile communications
  • the end device should have dead reckoning.
  • the location accuracy with coupler navigation must be ⁇ 50 m on average.
  • the accuracy of the Dead reckoning should be 5% of the distance traveled when driving slowly around town (30 - 50 km / h) Distance and when driving at medium speed (70 - 90 km / h) 3% of the distance traveled Do not exceed the distance, with a maximum GPS shadowing distance of 1000 meters is taken as a basis.
  • the GPS signal acquisition times should be in the range of 1 to 2 seconds.
  • the end device must have a graphic display with the possibility of graphic and text display, as well as a convenient input option. In addition, a voice output of the maneuvers is desirable.
  • Recommendation dot matrix min 128x112 minute 4 lines, min. 20 characters / line
  • the device should be able to store at least 40 waypoints for orientation. Ideally, 100 waypoints that can be saved should be provided for a route. Around A notebook with at least 50 entries should make it easier to enter destinations exist from which i.a. the target description can also be adopted.
  • the waypoint memory should be designed dynamically so that for example at waypoints, which are transmitted without street names, no memory for the street name is kept free.
  • a destination entry should also be possible with the help of geo-coding.
  • the display of instructions should be announced by an acoustic signal.
  • the user should be able to scroll between the signpost symbols can (especially switch to the next waypoint).
  • the orientation aid service is intended for end devices, which are preferably equipped with GPS without a digital map in the vehicle. That is why not possible, as with navigation systems at the maneuvering point, turn instructions such as B. turn right now "because of the limited Positioning accuracy the necessary exact determination of the vehicle position (about 10m exactly) is not feasible.
  • the signpost symbol should be approx. 50m (without dead reckoning 100m) after reaching the geographical coordinates of the signpost icon are removed from the screen (at link flag after reaching the second geographic coordinate).
  • the display is based on a display with at least 128 x 112 pixels.

Landscapes

  • Engineering & Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Navigation (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

Die Erfindung betrifft ein Verfahren und eine Anordnung zur Routeninformation mobiler Teilnehmer nach dem Oberbegriff des Patentanspruchs 1.
Durch das stetig wachsende Verkehrsaufkommen wird der Bedarf an hochwertigen Systemen zur Verkehrsinformation und Verkehrsleitung immer dringlicher. Dabei ergeben sich jedoch die Probleme, wie dem Benutzer stets aktuelle Informationen zur Verfügung gestellt werden können, die ihm gleichzeitig einen hohen Benutzerkomfort bieten.
Die WO-A-90/02391 beschreibt ein Zielführungssystem zur Bestimmung einer Route zwischen zwei gegebenen geographischen Orten. Die Ortsinformationen werden von einem Benutzer einem zentralen Datenverarbeitungssystem zugeführt, welches aus diesen Daten eine Routenbeschreibung generiert und dem Benutzer zur Verfügung stellt. Dieses System ist nicht für einen mobilen Einsatz, d.h. einen mobilen Benutzer, konzipiert.
Die WO-A-96/11381 betrifft eine Einrichtung zur Zielführung von Personen. Die Einrichtung umfasst eine Navigationseinheit, die eine Empfangseinrichtung für drahtlos übermittelte Informationen zur Erkennung der aktuellen geographischen Position aufweist, eine Kommunikationseinheit, die eine Eingabeeinheit insbesondere zur Eingabe einer Zielposition und eine Ausgabeeinheit, insbesondere zur Ausgabe von Wegführungsinformation umfaßt. Femer ist ein zentraler Rechner zur Routenplanung vorgesehen, der einen Speicher mit mindestens einer digitalisierten Straßenkarte aufweist und der mit der Navigationseinheit über die Kommunikationseinheit datentechnisch verbindbar ist. Der Rechner übermittelt die berechneten Routeninformationen an die Navigationseinheit. In der Navigationseinheit kann die aktuelle Position in einer Umgebungskarte dargestellt werden und es können Wegroutenhinweise ausgegeben werden.
Die WO-A-96/00373 betrifft ein elektronisches Navigationssystem, bei dem ausgehend von einer Teilnehmereinheit eine Routenanfrage an eine Zentraleinheit erfolgt, in der Zentraleinheit eine Routenberechnung und Aufbereitung der Daten erfolgt und die vollständige Routeninformationen in die Teilnehmereinheit übertragen werden, in der eine Abarbeitung der Route erfolgt.
Die Aufgabe der Erfindung besteht darin, ein Verfahren und eine Anordnung zur Routeninformation mobiler Teilnehmer vorzuschlagen, das dem Teilnehmer stets aktuelle Informationen zur Verfügung stellt und ihm gleichzeitig einen hohen Benutzerkomfort bietet.
Diese Aufgabe wird gelöst durch die Merkmale des Patentanspruchs 1.
Weitere mögliche Ausgestaltungsformen der Erfindung sind in den abhängigen Patentansprüchen angegeben.
Insbesondere können Daten auf verschiedenste Ausgangsparameter bezogen werden, z.B. Orts-, Start- oder Zielinformationen bzw. Streckeninformationen der Fahrt, zentrale- oder endgeräteseitige Abfragen, die gerätegestützt oder personengestützt durchgeführt werden können. Die Datenübertragungen können zu Informationserfassungszwecken und/oder zu Informationsübertragungszwecken wie auch zur Informationsaktualisierung durchgeführt werden.
Die Navigationsdienste unterstützen den Kunden bei der Fahrt zu seinem Ziel auf einer Route. Die Routenberechnung erfolgt unter Berücksichtigung der aktuellen Verkehrslage in der Dienstezentrale.
Die in diesem Dokument beschriebene Orientierungshilfe ist ein einfacher Navigationsdienst, der den Kunden mit eingeschränkter Falschfahrterkennung und Rückführung zu seinem Ziel führt.
Die Präsentation der Route im Endgerät erfolgt bevorzugt mittels einer Routengrobbeschreibung und kann insbesondere durch Icons (Wegeleitsymbole) dargestellt werden, anhand derer der Kunde zum Ziel geführt wird. Die Orientierungshilfe hat vorzugsweise eine eingeschränkte Fehlfahrtenerkennung. Eine gezielte Rückführung auf die Route kann unterstützt werden
Der Dienst Orientierungshilfe ist insbesondere für Endgeräte gedacht, welche ohne gespeicherte Orts- oder Straßendaten wie eine digitale Karte im Fahrzeug, sondern nur mit Ortsbestimmungseinrichtungen wie z.B. mit GPS ausgestaltet sind (im folgenden wird meist beispielhaft ein System mit GPS beschrieben). Es ist deshalb in der Regel nicht möglich, exakt an einem bestimmten Ort (Manöverpunkt) Abbiegehinweise wie z. B. "jetzt rechts abbiegen" zu geben, da aufgrund der eingeschränkten Positionierungsgenauigkeit oft die dazu nötige exakte Feststellung der Fahrzeugposition (insbesondere bei GPS ca. 10m genau) nicht möglich ist.
Deshalb muß der Fahrer frühzeitig auf bevorstehende Manöver aufmerksam gemacht werden. Als Manöverhinweis reicht es nicht aus, nur das unmittelbar auszuführende Manöver anzugeben (z. B. "rechts abbiegen"), sondern der Nutzer muß mittels einer abstrahierten Darstellung (Wegeleitsymbole) über die Kreuzungstopographie am Manöverpunkt informiert werden (s. Fig. 1). Der Anhang enthält einen Vorschlag für eine solche Wegeleitsymbolik.
Die Zentraleinheit (T-Traffic-Zentrale) berücksichtigt bei der Generierung der Route die vom Endgerät übertragene Information über die Ortungsfunktion des Endgerätes (z.B. reines GPS oder zusätzliche Koppelnavigation). Dadurch wird sichergestellt, daß auch mit Endgeräten ohne Koppelnavigation eine funktionsfähige Orientierungshilfe - wenn auch geringerer Qualität - möglich wird.
Zusätzlich wird in diesem Dokument der Dienst Routenbewertung beschrieben. Bei der Routenbewertung wird eine im Endgerät bekannte Route vom Endgerät in die Zentrale übertragen. In der Zentrale wird für diese Route auf Basis der aktuellen Verkehrslage die Reisezeit abgeschätzt und zum Endgerät übertragen.
1.1 Kurzbeschreibung Orientierungshilfe
Die Orientierungshilfe hat folgenden Basisablauf:
  • 1. Routenanfrage an die Zentrale
  • 2. Routenberechnung und -aufbereitung, Übertragung der vollständigen Route ins Endgerät
  • 3. Abarbeitung der Route im Endgerät
    • siehe Fig. 2
    Der Kunde fragt die Route unter Angabe
    • seiner Startposition (im Regelfall die aktuelle Position),
    • der Zielposition und
    • von Optimierungskriterien (z. B. kürzeste oder schnellste Route)
    in der Zentrale ab.
    Zusätzlich können Punkte, die auf der Route angefahren werden sollen (Via-Punkte). oder Punkte, die nicht angefahren werden sollen (Meide-Punkte), mit angegeben werden.
    Zur Eingabe der Zieladresse werden verschiedene Formen unterstützt (z. B. Stadt und Straße, POI: z. B. Flughafen, Bahnhof).
    Die Routenanfrage an die Zentrale kann erfolgen über
    • Zieleingabe direkt am Endgerät: der Kunde gibt die notwendigen Informationen zur Routenberechnung am EG ein, bzw. ruft sie aus einem vorhandenen Zielespeicher im Endgerät ab.
    • Telefonie: hierbei ermittelt die Zentrale (Operator) die oben genannten Informationen zur Routenberechnung im Dialog mit dem Kunden
    In der Zentrale werden bei der Routenanfrage mit einer Zielanfrage direkt am Endgerät zunächst die Kundenangaben auf Korrektheit, Vollständigkeit und Eindeutigkeit überprüft. Ggf. wird eine Fehlermeldung zum Fahrzeug gesandt. ist die Benutzeranfrage bei unvollständigen Adreßangaben nicht eindeutig zu interpretieren, so wird mit der Fehlermeldung eine Auswahlliste ins Fahrzeug zugestellt, mit der die Anfrage präzisiert werden kann.
    Die Route wird in der Zentrale aufbereitet. Mittels der Route_Message wird die Routeninformation ins Fahrzeug gesandt. Mit der Übertragung der Route ins Fahrzeug ist für die Zentrale die Anfrage beendet.
    Die Routeninformation enthält
    • eine textuelle Routengrobbeschreibung zur Übersicht über die geplante Route durch den Benutzer,
    • die berechnete Gesamtentfernung zum Zielort und die Reisezeit zum Zielort unter Berücksichtigung der aktuellen Verkehrslage sowie
    • eine Liste von Wegepunkten mit zugeordneten Icons zur Navigation während der Fahrt.
    Die Abarbeitung der Liste der Wegepunkte erfolgt lokal im Endgerät. Die Reihenfolge der Wegepunkte auf der Route ist durch die Reihenfolge ihres Auftretens in der Liste gegeben.
    Die Route wird entsprechend der Wegepunktliste sequentiell abgearbeitet, wobei für jede Kreuzung, an der ein Abbiegemanöver durchgeführt werden muß, dieses durch ein entsprechendes Icon angezeigt wird.
    Fehlfahrten werden erkannt, wenn der Kunde einen vorgegebenen Korridor, dessen Breite mit der Routenbeschreibung ins Endgerät geladen wird, verläßt.
    Das Endgerät kann dann
  • 1. in einen Kompaß-Mode umschalten, in dem auf dem Bildschirm die Richtung und Entfernung zum nächsten Wegepunkt auf der Route angezeigt wird, oder
  • 2. dem Kunden die Möglichkeit zu einer neuen Routenanfrage bieten.
    • 1.2 Kurzbeschreibung Routenbewertung
    Dieser Dienst ermöglicht die Bewertung einer im Endgerät vorhandenen Route bezüglich der aufgrund der aktuellen Verkehrslage zu erwartenden Reisezeit (s. Fig. 3). Dazu wird die Routenbeschreibung (der zu berechnenden Route) in die Zentrale übertragen (Travel_Time_-Request_Message). Die Route wird dabei wie bei der Orientierungshilfe oder der Zielführung in Form von Wegeleitpunkten beschrieben.
    Die Zentrale schätzt die Reisezeit für diese Route aufgrund der aktuellen Verkehrslage und überträgt diese in das Endgerät (Travel_Time_Message).
    1.3 Übersicht über die Dokumente
    In diesem Dokument werden die einzelnen Dienste funktional beschrieben und die konkreten Abläufe auf Basis der ADP's dargestellt. Die Codierung der ADP's wird erläutert. Die Dienste sind bezüglich gewisser Abläufe und Funktionen parametrierbar. Die definierten Diensteparameter werden in diesem Dokument aufgelistet. Die Festlegung der individuellen Diensteparametrierung ist Aufgabe der jeweiligen Diensteanbieter. Diese Basisspezifikation legt den Gesamtumfang der von den Endgeräten der ersten Generation zu unterstützenden Funktionen und Abläufen fest. Zusätzlich können diese Abläufe und Funktionen von den jeweiligen Diensteanbietem in eigenständigen Dokumenten detaillierter spezifiziert werden.
    Diensteübergreifende Spezifikationen, die für das Verständnis der vorliegenden Spezifikation erforderlich sind:
    • Interne Dienste - Endgeräteseitige Beschreibung des Dienstablaufs
    Folgende Dokumente werden für das Verständnis der vorliegenden Spezifikation ebenfalls benötigt:
    • Anforderungen an den logischen Aufbau einer Lokalisierungsperlenkette für eine Punktlokalisierung
    • Beschreibung der diensteübergreifenden Fehlerbehandlung
    Die aufgeführten Message Types finden sich in den Dokumenten:
    • Application Data Protocol Navigation Services
    • ADP Message Types of General Interest
    Richtlinien für die Codierung spezieller Datentypen finden sich in folgenden Dokumenten:
    • Address Coding
    • Coding of Text and Transparent Data
    • Coding of Extended Location Message
    • Area and Location Coding
    • Coding of Absolute Time
    Der Transportrahmen für die Message Types ist festgelegt in:
    • Transport Protocol
    Verfahren zum Datenschutz und zur Datensicherheit sind in den Dolumenten "Conditional Access and Security (CAS)" festgelegt:
    • CAS Protocol
    • ADP Key Management
    • Dienstebeschreibung Key Management and Security
    Die Numerierung von Telegrammtypen entspricht dem Dokument:
    • Message Type Numbering
    Die jeweils aktuellen Versionsnummern der aufgeführten Dokumente werden bei jeder Änderung an unsere Partner weitergegeben.
    2 Allgemeine Abläufe 2.1 Begriffsdefinitionen
    Folgende Begriffe sind für dieses Dokument eindeutig festgelegt:
    • aktive Quittung   aktive Bestätigung des Erhalts einer Message durch den Nutzer
    • ADP   Application Data Protocol
    • Geo-Code   Eindeutige Festlegung und Identifikation eines geographischen Objektes durch Koordinaten
    • Kompaßmode/Homing   reine endgeräteseitige Funktion, bei der ein Pfeil auf dem Display in Richtung einer geographischen Koordinate zeigt (meist mit zusätzlicher Angabe der Entfernung in der Luftlinie)
    Die Message Types mit ihren Inhalten werden wie folgt beschrieben:
    Information Element Type Length [bits] Content
    Beschreibung des Feldinhaltes
    z.B.:Protocol Discriminator oder Position    		 Festlegung des Feldtyps
    MF:
    Mandatory, Fix length
    MV:
    Mandatory, Variable length
    OF:
    Optional. Fix length
    OV:
    Optional, Variable length    		 Länge des Feldes
    in Anzahl Bits bei MF oder OF
    var.
    bei MV oder OV    		 Festlegung des Inhaltes zur Nutzung der Dienste
    2.2 Transportprotokoll - Handling
    Zur Nutzung der Dienste Orientierungshilfe und Routenbewertung wird das Transportprotokoll wie folgt verwendet:
    Information Element Type Lenght (bits) Content
    Transport Protocol Discriminator MF 8 00000001
    Application ID MF 8 s. Kap. 2.2.1
    ADP Version MF 7 0000001 (V 1.0)
    Initiative Flag MF 1 1: bei Route Request Message und Travel Time Request Message, bei der Route Message nur, wenn diese von der Zentrale initiiert wurde
    0: bei allen nachfolgenden Messages
    Context Number MF 8 MSB = 1: vom Endgerät vergeben
    MSB = 0: von der Zentrale vergeben bei von der Zentrale initiierter Route Message
    Total Number of Packets MF 5 Anzahl = X - 1 ⇒ Wertebereich 1 ... 32
    Index of Actual Packet MF 5 Index = 0 - (X-1) ⇒ Wertebereich 1 ... 32
    Mailbox-Flag MF 1 0: keine Nachrichten in der Mailbox
    1: Nachrichten in der Mailbox vorhanden
    Debit-Info MF 4 0: nicht unterstützt in dieser Version
    Length User Data MF 9 Anzahl (in Byte) der innerhalb der Nachricht übertragenen Nutzdaten (CAS header+ ADPU)
    Der Rahmen unterstützt das Versenden von mehreren Short-Messages.
    Alle innerhalb des Dokuments CAS Protocol definierten Funktionen, Verfahren und Abläufe sind endgeräteseitig zu unterstützen.
    2.2.1 Dienstekennung
    Application ID's sind eindeutige, von der Zentrale vergebene Dienstekennungen. Diese werden im Feld Application ID im Transport-Layer übertragen.
    Die Diensteanbieter können innerhalb der definierten Abläufe eigenständige Dienste definieren. Diese können beispielsweise dadurch gekennzeichnet sein, daß die übermittelten Informationsinhalte eingeschränkt werden. Zu Identifizierung der angebotenen Dienste werden Dienstekennungen vergeben.
    Folgende Application-ID werden vergeben:
    Application ID 31 h
    Orientierungshilfe: Digital Request
    Application ID 32h
    Orientierungshilfe: Operator Request
    Application ID 33 h
    Routenbewertung
    2.2.2 Zuordnung von Antworten zu einer Anfrage
    Die Zuordnung von Transaktionen erfolgt über die beiden Felder :
    • Initiative Flag
    • Context Number
    im Transport-Layer
    im Auftrag an die Zentrale vergibt das Verkehrstelematik-Endgerät eine frei wählbare Context Number (Einschränkung: MSB = 1). Mit Initiative Flag = 1 (initiative) wird die erste Transaktion der Kette, der Auftrag, gekennzeichnet.
    Erfolgt eine Antwort an das Verkehrstelematik-Endgerät wird wieder dessen Context Number gesetzt. Das Initiative Flag wird bei allen zugehörigen Antworten auf 0 gesetzt.Damit kann der Auftraggeber die Antwort eindeutig dem erteilten Auftrag zuordnen.
    Bei nicht vom Endgerät initiierten Route Messages vergibt die Zentrale eine frei wählbare Context Number (Einschränkung: MSB = 0). Das Initiative Flag = 1 (initiative).
    2.3 Codierung von Text
    Alle Text Elemente innerhalb der Navigationsdienste verwenden folgendes Format:
    Information Element Type Length (bits) Content
    Text Representation MF 2 zulässige Werte:
    1: Text: 6 bits per character
    2: Text ISO 8859-1 (8 bits per character)
    Length OF 10 Länge des Textes in Anzahl Buchstaben, incl. Steuerzeichen
    Text/Data OV N × 8 Text
    2.4 Codierung des Communication Headers der verwendeten ADPs
    Die Werte für Protocol Discriminator und Message Type sind dem Dokument "Message Type Numbering" zu entnehmen. Das Bulk Flag wird stets auf 0 gesetzt
    2.5 Zeitsteuerung der Kommunikationsabläufe
    Die für die Navigationsdienste relevanten Timer sind nachfolgend aufgeführt.
    Bezeichnung Funktion Einheit Wertebereich Auflösung Default
    TNAVa Wartezustand auf Antwort einer Route Message bzw. einer Error Message sec 0 - 300 30 90
    TNAVb Warten auf ersten Anrufversuch beim Call-Center sec 0 - 60 5 10
    TNAVc Max. Zugangsdauer zum Operator beim Call-Center min 0 - 15 1 5
    TNAVd Wartezustand auf Antwort einer sec 0 - 300 30 90
    Travel Time Message
    2.6 Verwaltung von Diensteadressen 2.6.1 Orientierungshilfe
    Die Hinterlegung und das Updaten der Diensteadressen im Endgerät wird in der Telematikdienstespezifikation Interne Dienste erläutert.
    Für den Dienst Orientierungshilfe muß das Endgerät bzgl. der Adreßverwaltung die volle Funktionalität der internen Dienste unterstützen.
    2.6.2 Routenbewertung
    Die Hinterlegung und das Updaten der Diensteadressen im Endgerät wird in der Telematikdienstespezifikation Interne Dienste erläutert
    Für den Dienst Routenbewertung muß das Endgerät bzgl. der Adreßverwaltung die volle Funktionalität der internen Dienste unterstützen.
    2.7 Diensteparameter
    Nachfolgend sind alle Diensteparameter für Navigationsdienste aufgelistet. Die von der Zentrale aktuell unterstützten Diensteparameter werden durch Interne Dienste in das Endgerät geladen. Nicht parametrierbare Abläufe oder Funktionen sind verbindlicher Teil des Standards und werden von allen Zentralen unterstützt.
    2.7.1 Abläufe
    Zur Parametrierung der Abläufe stehen 32 Bit-Switches zur Verfügung, die wie folgt belegt sind (0: nicht unterstützt durch Zentrale, 1: unterstützt durch Zentrale):
    Ablauf gem. ADP Switch Default
    Route_Description_Digital Request 1 1
    Route_Description_Operator Aided Request_Timer_Based 2 1
    Travel_Time_Estimation 3 0
    reserved 4 - 32
    2.7.2 Funktionen
    Zur Parametrierung der Funktionen stehen 64 Bit-Switches zur Verfügung, die wie folgt belegt sind. Alle aufgeführten Funktionen sind endgeräteseitig zu unterstützen und werden über die internen Dienste anbieterspezifisch parametrisiert.
    Funktion gem. ADP Switch Default
    Route_Request_Message_Starting/Arrival_Time_starting_time
    Kommentar: Zentrale unterstützt als Start-Zeit eine andere Zeit als Ist-Zeit     		1 0
    Route_Request_Message_Starting/Arrival_Time_arrival_time
    Kommentar: Zentrale unterstützt die Angabe einer gewünschten Ankunftszeit     		2 0
    Route_Request_Message_Rouling_Criteria_fastest 3 1
    Route_Request_Message_Routing_Criteria_fastest_without_TINFO 4 0
    Route_Request_Message_Routing_Criteria_shortest 5 1
    Route_Request_Message_Routing_Criteria_user_defined 6 0
    reserved 7-18
    Route_Request_Message_Routing_Switches_main_roads_preferred 19 0
    Route_Request_Message_Routing_Switches_minimize_villages 20 0
    Route_Request_Message_Routing_Switches_no_toll_roads 21 0
    Route_Request_Message_Avoid_Location
    Kommentar: Meidepunkte werden unterstützt     		22 0
    reserved 23-26
    Route_Request_Message_Number_of_Destinations_final_plus_1 27 1
    Route_Request_Message_Number_of_Destinations_final_plus_2 28 0
    Route_Request_Message_Number_of_Destinations_final_plus_3 29 0
    Route_Request_Message_Number_of_Destinations_final_plus_4 30 0
    Route_Request_Message_Number_of_Destinations_final_plus_5 31 0
    Route_Request_Message_Number_of_Destinations_final_plus_6 32 0
    Address_Kind_of_POI_Service_Provider_POI Kommentar: Service-Provider-POI werden unterstützt 33 1
    Address_request_phone_numbers_accepted
    Kommentar: Telefonnummern bei Adressanfrage werden unterstützt     		34 0
    Es wird die Nutzung der Ortsvorwahl für eine Ortsauswahl unterstützt. Mit dem Switch wird von festgelegt, ob zusätzlich auch die Eingabe vollständiger Telefonummern zulässig ist.
    Address_request_ambigious_addresses_selection_list
    Kommentatar: Bei Adressanfragen werden Auswahllisten zurückgegeben     		35 1
    Address_request_Geo_Codes_accepted
    Kommentar: Geo Codes bei Adressanfrage werden unterstützt     		36 0
    reserved 37-64
    3 Beschreibung der Dienste 3.1 Orientierungshilfe
    Die Orientierungshilfe hat folgenden Basisablauf:
  • 1. Routenanfrage (im Fehlerfall folgt eine Error Message)
  • 2. Routenberechnung und Aufbereitung in der Zentrale/Übertragung ins Endgerät (Route Message)
  • 3. Abarbeitung der Route im Endgerät
    • Zusätzlich wird es zukünftig möglich sein, daß der Kunde über den Operator oder z. B. einen Online-Dienst eine Routenberechnung (auch zeitversetzt) initiert, so daß dann das Endgerät ohne Initiierung einer Routenanfrage eine Routenbeschreibung erhält. In diesem Fall beginnt der Ablauf sofort mit der Abarbeitung der Route im Endgerät.
    Die Endgeräte müssen diese Verarbeitung von "fremd-", d.h. von Dritten initiierten Route Messages unterstützen.
    3.1.1 Routenanfrage
    Die Routenanfrage an die Zentrale kann erfolgen über
    • Zieleingabe direkt am Endgerät: der Kunde gibt die notwendigen Informationen zur Routenberechnung am EG ein (insbesondere Adressinformationen)
    • Operator (Sprachverbindung): hierbei ermittelt der Operator die oben genannten Informationen zur Routenberechnung im Dialog mit dem Kunden
    Im Rahmen der Routenanfrage müssen folgende Informationen angegeben werden bzw. werden vom Endgerät automatisch generiert:
    • Startpunkt/Adresse (Generierung im Regelfall automatisch durch das Endgerät: aktuelle Position): Lokalisierungs-Perlenkette oder postalische Adressebeschreibung (mandatory)
    • Zieladresse: Geographische Koordinate und/oder postalische Adressbeschreibung (darf nur bei einer Operatoranfrage fehlen)
    • gewünschte Abfahrtzeit oder gewünschte Ankunftszeit, diese Informationen werden bei der Routenberechnung auf Basis der aktuellen Verkehrslage mit berücksichtigt (die Unterstützung dieser Funktionalität ist parametrierbar, s. Kapitel 2.7).
    Die vom Endgerät zur Zentrale übertragene "gewünschte Abfahrtzeit" wird von T-Traffic zunächst ignoriert.
    • die Kriterien zur Routenberechnung (die Unterstützung der einzelnen Kriterien ist parametrierbar, s. Kapitel s. Kapitel 2.7:
      • schnellste Route mit Berücksichtigung der aktuellen Verkehrslage (wird als Default-Vorgabe für das Endgerät empfohlen),
      • schnellste Route ohne Berücksichtigung der aktuellen Verkehrslage,
      • kürzeste Route (ohne Berücksichtigung der aktuellen Verkehrslage),
      • benutzerdefiniert (anhand von in der Zentrale hinterlegten Kriterien; die Kriterien-Hinterlegung erfolgt über Customer Care, nicht über das Endgerät),
        sowie den zusätzlichen Wahlmöglichkeiten
      • Bevorzugung von Fernstraßen,
      • Minimierung von Ortsdurchfahrten,
      • keine Straßen mit Maut-Pflicht
    • sowie bis zu 6 zusätzlichen Adressen, die je nach Wahl des Kunden entweder angefahren werden müssen (Via-Punkte) oder nicht angefahren werden dürfen (Meide-Punkte): Geographische Koordinate und/oder postalische Adressbeschreibung (die Anzahl der möglichen Adressen ist parametrierbar, siehe s. Kapitel 2.7)). Bei Via-Punkten werden die Adressen in der vorgegebenen Reihenfolge abgefahren, d.h. es wird kein Traveling Salesman-Problem gelöst.
    Via-Punkte können dazu verwandt werden, unerwünschte Routen auszuschließen bzw. zu korrigieren. Meidepunkte werden zunächst nicht unterstützt.
    Die Zentrale prüft die erhaltenen Angaben auf Korrektheit, Vollständigkeit und Eindeutigkeit und weist der Adresse bzw. den Adressen eine geografische Koordinate bzw. ihre geographische Koordinate zu (s. unten).
    In der Route_Request_Message werden folgende zusätzlichen benutzerspezifischen Informationen zur Zentrale übertragen:
    • Telefonnummer des Benutzers (optional):Dieses Feld ist dann mit der Telefonnummer des Empfängers der Route auszufüllen, wenn die Routenanfrage fremdinitiiert wird.
    • Informationen über das Endgerät (muß übertragen werden, ausgewertet wird die Information über die Ortung)
    • sowie in zukünftigen Diensteausprägungen Informationen über das Fahrzeug.
    3.1.1.1 Zieleingabe am Endgerät
    Bei der Zieleingabe am Endgerät gibt der Kunde die Adressen für den Zielort und alle gewünschten Viapunkte am Endgerät ein oder wählt sie aus einem ggf. vorhanden Adressenspeicher des Endgerätes aus.
    Der Adressspeicher (Adressbuch) sollte über folgende Wege gefüllt werden können:
    • Abspeicherung einer innerhalb einer Route-Message erhaltenen Adresse (inklusive geographischer Koordinaten)
    • Abspeicherung einer durch einen Auskunftsdienst erhaltenen Adresse (Service-Provider-POI)
    • Positionsspeicherung: Der Kunde kann am Endgerät seine aktuelle Position (geographische Koordinate), ergänzt um zusätzliche Adressinformationen, im Adreßbuch speichern (z. B. Heimatadresse).
    Die Adressen werden mittels der Route_Request_Message zur Zentrale übertragen und dort auf Korrektheit, Vollständigkeit und Eindeutigkeit geprüft. Bei unvollständigen Adressangaben erfolgt eine Fehlermeldung, die falls möglich eine Adressauswahlliste für die fraglichen Adressen enthält. Der Kunde kann dann die gewünschte Adresse auswählen und mit dieser eine neue Routenanfrage initiieren. Es ist durch einen Parameter einstellbar, ob die Zentrale die Rückgabe von Auswahllisten grundsätzlich unterstützt (s. Kapitel 2.7). Sämtliche im ADP vorgesehenen Felder für die Angabe und Übermittlung von Adressinformation sind endgeräteseitig zu unterstützen. Welche Kombinationen und Untermengen zentralseitig unterstützt werden, ist diensteanbieter spezifisch festzulegen.
    Sind die Adresse oder einzelne Angaben nicht eindeutig, wird die Fehlermeldung zum Fahrzeug übertragen. Diese kann Auswahllisten enthalten. Die Unterstützung der Fehlermeldung ist abhängig vom Diensteanbieter.
    Folgende Adreßanfragen werden akzeptiert:
  • 1. geographische Koordinaten (alle anderen angegebenen Felder werden zentraleseitig ignoriert)
  • 2. Geo-Codes (alle anderen Felder werden zentraleseitig ignoriert)
  • 3. Service-Provider-POI: die vollständige bei einer Adreßabfrage über Auskunftsdienste erhaltene Adreßinformation muß übertragen werden (Ausnahme: "additional information" und "country"). Service-Provider-POI können über Auskunftsdienste (s. Kapitel 3.2.2) ins Endgerät geladen und ggf. im Adreßbuch gespeichert werden.
  • 4. MAP-POI mit Ortswahl (Straßenbeschreibung und POI-Name wird ignoriert): Bei mehreren in Frage kommenden POI's wird der nächstliegende POI ausgewählt (ggf. wird auch eine Auswahlliste übertragen).
  • 5. MAP-POI ohne Ortswahl: Die Zentrale wählt als Default den nächstliegenden POI dieses Typs aus (bezogen auf die mitübertragene Startadresse). Straßenbeschreibung und POI-Name werden ignoriert.
  • 6. Ortswahl und Straßenname: Der Straßenname muß entweder als "Street Identification" oder als "Street Name incl. House Number" übertragen werden. Werden beide übertragen, wird die Street Identification ignoriert. Es wird empfohlen, die Street Identification nicht für eine Adreßanfrage zu verwenden.
  • 7. nur Ortswahl (Default s.u.)
  • 8. vollständige Telefonnummer: Ortsvorwahl und Teilnehrnernummer müssen übergeben werden. Die Landeskennziffer ist optional.
    • Für die Ortswahl sind folgende Möglichkeiten zugelassen:
    • nur Ortsname (Default: Ortsmittelpunkt)
    • nur Postleitzahl (Default: Zentrum des PLZ-Bezirks)
    • nur Telefon-Ortsvorwahl (Default: Zentrum des Ortsvorwahlbereiches)
    • Ortsname und Telefon-Ortsvorwahl oder Postleitzahl
    Postleitzahl und Telefonnummer dürfen nicht gleichzeitig übergeben werden, ansonsten erfolgt eine Fehlermeldung. Gleiches gilt, falls Ortsname und Postleitzahl oder Telefonnummer widerspüchlich sind.
    Die "Additional Information" sowie das Feld "Country" wird bei der Adreßanfrage immer ignoriert. Ist das Feld "Staat" leer, so wird als Land Deutschland (D) genommen.
    Für die einzelnen IE's gelten folgende Anforderungen:
    • geographische Koordinaten nach der Digitalen Karte in der Zentrale. Bei bloßer Angabe von Koordinaten können Start und Ziel im Rahmen der Ungenauigkeiten vom Kundenwunsch abweichen.
    • Ortsnamen nach dem offiziellen Ortsnamen. Gibt es mehrere Orte gleichen offiziellen Namens, wird zur Identifizierung die Postleitzahl oder die Ortsvorwahl herangezogen. Ortsnamen sowie Namen von Autobahnanschlußstellen können mit Bindestrich übergeben werden (z. B. Köln-Lindenthal, Bonn-Bad Godesberg). Werden im überregionalen Sprachgebrauch auch nur die Namen der Vororte verwendet (z. B. Wattenscheid, Bad Godesberg), werden auch diese von der Zentrale akzeptiert.
    • Straßenbezeichnungen: Straßentypen BAB, Bundesstraße, Landstraße, Staatsstraße, Kreisstraße, Europastraße mit Nummer und eventueller zusätzlicher Bezeichnung (a,b,n,r), z. B. B55n (s. ADP).
    • Straßennamen nach dem offiziellen ortsabhängigen Straßenverzeichnis.
    • Postleitzahlen nach dem Postleitzahlenverzeichnis der Deutschen Bundespost.
    • POI-Typ: MAP-POI's Zentrum, Bahnhof, Flughafen so wie sie in der Digitalen Karte der Zentrale verzeichnet sind. Service-Provider-POI's werden im Rahmen der Auskunftsdienste beschrieben.
    • Staat nach Liste der internationalen Kfz-Zeichen.
    • Telefonummer: nur Vorwahl (Länderkennziffer ist Kannfeld, default: Deutschland).
    In folgenden Fällen folgt eine Fehlermeldung "start/destination/additional adress not identified" (das entsprechende Bit in der Error Message ist gesetzt):
    • gleichzeitig Angabe geographischer Koordinaten und Geo-Code
    • gleichzeitig Angabe geographischer Koordinaten und Service-Provider-POI
    • nicht interpretierbare geographische Koordinaten, Geo-Codes oder Service-Provider-POI
    • nicht interpretierbare Telefonortsvorwahl oder Postleitzahl
    • nicht interpretierbare vollständige Telefonnummer
    Zusätzlich kann von der Zentrale für die betroffene Adresse das Bit "start/desination/additional adress ambiguous" gesetzt werden. In diesem Fall folgt ein Auswahllistenfeld innerhalb der Adreßbeschreibung, in dem im Feld "Additional Information" eine Fehlererklärung in Freitext angegeben wird. Ist eine vollständige Telefonnummer nicht eindeutig interpretierbar, dann wird die Telefonnummer mit denjenigen Stellen zurückgegeben, die interpretiert werden konnten (Beispiel: 0228-5201900 wird übergeben, die Zentrale kann die Nummer bis 02285201 interpretieren und gibt diese Nummer zurück).
    Ist die Adresseangabe bezüglich der Ortswahl, eines MAP-POI's, oder eines Straßennamens nicht eindeutig, werden Auswahllisten nach folgenden Kriterien mit der Fehlermeldung zum Fahrzeug übertragen, wobei in der Auswahliste nur die zu konkretisierenden IE's enthalten sind (d.h. keine vollständigen Adressfelder, Ausnahmen sind genannt):
    • Ortsname: Auswahlliste mit max. 5 Alternativen
    • Straßenname: Auswahlliste mit max. 5 Alternativen
    • MAP-POI: Auswahlliste mit max. 5 Alternativen
    Die Codierung der einzelnen IE's ist im ADP zu den Navigationsdiensten detailliert beschrieben.
    3.1.1.2 Anfrage über Operator (Speech Connection)
    Bei der Anfrage über Operator sind grundsätzlich zwei Fälle zu unterscheiden:
  • 1. Es wird mit der Operatoranfrage eine Route_Request_Message versandt, die zumindest die Startposition enthält.
  • 2. Der Kunde wählt direkt den Operator an (auch über andere Telefone möglich). In diesem Fall muß er dem Operator auch seine Startposition mitteilen. Das Endgerät erhält eine nicht von ihm initiierte_Route_Message und interpretiert diese.
    • Nachfolgend wird der erste Fall einer Operator-Anfrage mit Übertragung einer Route_Message beschrieben. Dies ist als eigener Dienst zu betrachten, der eine separate Dienstekennung erhält.
    Das Anfragetelegramm unterliegt keinen speziellen Einschränkungen. Es ist zu empfehlen, die Startadresse sowie die vom Kunden gewählten Kriterien zur Routenberechnung im Endgerät zu speichern und mit in die Zentrale zu übertragen.
    Die möglichen Abläufe für den Aufbau der Sprachverbindung sind im Kapitel 3.3.2 dargestellt. Der Erhalt einer Fehlermeldung unterbricht den Aufbau der Sprachverbindung, sofern diese noch nicht aufgebaut wurde (beim Timer-basierten Ablauf).
    Es bestehen bevorzugt folgende zusätzlichen Anforderungen an die Anfrage:
    Die gewünschte Operator-Anfrage wird in der Message zusätzlich dadurch gekennzeichnet, daß keine Zieladresse mit übertragen wird.
    Die Message muß die Start-Adresse (Perlenkette oder postalische Adressbeschreibung) beinhalten. Falls gewünscht, können die Kriterien zur Routenberechnung bereits mit der Anfrage übertragen werden.
    Die Message kann zusätzlich bis auf die Zieladresse alle weiteren IE's enthalten. Es ist zu empfehlen, die vom Kunden gewählten Kriterien zur Routenberechnung im Endgerät zu speichern und mit in die Zentrale zu übertragen.
    Während der Sprachverbindung ermittelt der Operator im Dialog mit dem Kunden die noch fehlenden Informationen bis zum Vorliegen eindeutiger Adressen für das Ziel sowie eventueller Via- und Meidepunkte.
    Anschließend sendet die Zentrale nach erfolgter Routenberechnung die Route (Route_Message) ins Fahrzeug.
    3.1.2 Routenberechnung und Aufbereitung
    In der Zentrale wird die Route anhand der übermittelten Informationen auf Basis der aktuellen Verkehrslage erstellt und in die Route_Message codiert. Anschließend wird die Route_Message zum Fahrzeug übertragen.
    Bei der Berechnung der Route und der Routenaufbereitung wird die zentraleseitig die bei der Routenanfrage mitübertragene Information über die Ortung berücksichtigt. Dabei werden zunächst Endgerät mit reinem GPS und Endgeräte mit zusätzlicher Koppelnavigation unterschieden.
    Für Endgeräte mit reinem GPS werden für die Routenberechnung bestimmte Straßenklassen oder sogar einzelne Straßen ausgeschlossen. Dies kann zu Umwegen führen. Grundsätzlich wird bei diesen Endgeräten von einer Positionierungsgenauigkeit von ca. 100 m ausgegangen.
    Zusätzlich wird bei Endgeräten mit reinem GPS eine ausführlichere Routengrobbeschreibung generiert.
    Nach Absprache mit den Herstellern kann bei Geräten mit Digitaler Karte (Navigationssysteme) eine ausführliche Routengrobbeschreibung generiert werden. Die Liste der Wegeleitsymbole sollte bei den Navigationssystemen auf ein Maß reduziert werden, welches für eine darauf basierende fahrzeugautonome Routenfeinberechnung notwendig ist.
    3.1.3 Abarbeitung der Route im Endgerät
    Die Route_Message kann folgende Informationen enthalten:
    • eine textuelle Routengrobbeschreibung zur Übersicht über die geplante Route durch den Benutzer (Route Briefing)
    • die berechnete Reisezeit zum Zielort und die Gesamtentfemung zum Zielort (Routenlänge) unter Berücksichtigung der aktuellen Verkehrslage.
    • eine Liste von Wegepunkten mit zugeordneten Icons zur Navigation während der Fahrt
    Es wird Sonderfälle geben, wo die Routenbeschreibung leer bleibt oder keine Wegepunkte enthalten sind.
    Die Reisezeit zum Zielort wird gerundet übertragen, d.h. die Zentrale rundet die berechnete Reisezeit (z. B. 37 Minuten oder 3 Stunden, 31 Minuten) auf einen sinnvollen Wert, welcher von der Berechnungsgenauigkeit abhängt (z. B. 40 Minuten; 3 Stunden, 30 Minuten). Wird im Endgerät aus der Reisezeit zum Zielort durch Adition zur Ist-Zeit eine Ankunftszeit errechnet und dem Kunden angezeigt, dann sollte hier ebenfalls eine zusätzliche Rundung erfolgen. In der nachfolgenden Tabelle wird dazu ein Vorschlag unterbreitet:
    Reisezeit zum Zielort Vorgeschlagene Auflösung
    bis 30 Minuten 5 Minuten
    bis 90 Minuten 10 Minuten
    größer 90 Minuten 15 Minuten
    Bei der Aktualisierung der berechneten Ankunftszeit während der Fahrt sollten Pausen berücksichtigt werden (Erkennung durch Abschaltung des Gerätes).
    Zusätzlich wird empfohlen, bei Überschreitung der Ist-Reisezeit von der übertragenen, bisher absolvierten Reisezeit von mehr als 30 % und mindestens 10 Minuten den Benutzer darüber zu informieren und ihm die Möglichkeit einer erneuten Routenanfrage zu bieten.
    Die Liste von Wegepunkten bezeichnet Manöverpunkte. Sie werden an Stellen gesetzt, wo der Fahrer voraussichtlich Hinweise benötigt, um dem Routenverlauf folgen zu können (abbiegen, einordnen, Namensänderungen von Straßen, etc.).
    Der grobe Ablauf der Orientierungshilfe ist der folgende:
  • 1. Die textuelle Routengrobbeschreibung wird angezeigt und vom Kunden quittiert.
  • 2. Ein Pfeil zeigt in Richtung auf den ersten Wegepunkt (Kompaßmode). Zusätzlich wird die Entfernung (Luftlinie) zu diesem Wegepunkt mit angezeigt.
  • 3. Wird der Wegepunkt erreicht, wird dieser als passiert markiert und der nächste Wegepunkt wird mit der aktuellen Entfernung zu diesem Wegepunkt (Fahrstrecke) angezeigt.
  • 4. Nach dem Passieren des letzten Wegepunktes wird dies dem Kunden angezeigt. Gleichzeitig zeigt ein Pfeil in Richtung des Zielortes (mit Entfernungsangabe in Luftlinie; Kompaßmode).
    • Die Reihenfolge, in der die Wegepunkte abzufahren sind, ist durch die Reihenfolge der Wegepunkte in der Liste vorgegeben. Die Positionierung der Wegepunkte kann diensteanbieterspezifisch unterschiedlich gehandhabt werden. Dies ist inbesondere für den jeweils ersten bzw. letzten Wegepunkt einer Wegepunkteliste der Fall. Bei ihrer Interpretation ist auch jeweils der im IE "Type of Starting Point" bzw. "Type of Destination" enthaltene Code zu beachten. Die genauen Festlegungen werden in den Diensteanbieter spezifischen Zusatzspezifikationen getroffen.
    Die Start- und Zieladressen werden immer nur mit folgenden Informationen übertragen, wobei eine Übertragung einzelner, optionaler Felder unterbleibt, wenn sie bereits mit gleichem Inhalt in der Anfrage enthalten waren:
    • Geographische Koordinate
    • wenn POI: POI-Typ und POI-Name
    • Straßenbeschreibung (nicht bei Map-POI's)
    • Ortsbezeichnung
    Ist der erste Wegepunkt nicht identisch zur Startadresse, dann wird dies mit Angabe des Typs des Startwegepunktes zusätzlich mitgeteilt. Das Endgerät sollte dann in den Kompaßmode schalten, wobei der Kompaßpfeil auf den ersten Wegepunkt zeigen sollte. Der Typ "capture area" wird für die Orientierungshilfe nicht unterstützt.
    Kann der Zieladresse auf der Digitalen Karte in der Zentrale keine exakte geographische Koordinate zugeordnet werden, dann erfolgt zentraleseitig die Zuordnung zu einer Koordinate nach folgendem Prinzip (Angabe im Typ der Zieladresse):
  • 1. Die Ortsmitte wird als Bezugspunkt gewählt bzw. bei POI's die nächst mögliche Koordinate
  • 2. Ist der Punkt nicht erreichbar (z. B. in einer Fußgängerzone), dann wird zentraleseitig ebenfalls eine in der Nähe liegende Koordinate zugeordnet.
    • Mit dem Erhalt des Telegramms mit dem 1. Wegepunkt sollte sofort mit der Abarbeitung der Route begonnen werden, d.h. es muß nicht abgewartet werden, bis die vollständige Route im Endgerät eintrifft.
    Die textuelle Routengrobbeschreibung enthält wesentliche Meilensteine der Route, die dem Benutzer einen Überblick über die zu fahrende Route geben (z. B. Fahrt von Bonn nach Düsseldorf: A555 bis Kreuz Köln Süd, A4 bis Kreuz Köln Ost, A1 bis Kreuz Köln Nord, A57 bis Kreuz Kaarst). Die Übertragung der Meilensteine erfolgt entweder als Text oder als Geo-Code. Eine Mischung von Text und Geo-Codes ist möglich.
    3.1.3.1 Inhalte der Wegepunkte
    Die einzelnen Wegepunkte haben folgende Inhalte:
    • geographische Koordinate des Wegepunktes (WGS84)
    • optional die offizielle Straßenbezeichnung: für die Straße, in die abgebogen werden soll (wird im Regelfall angegeben)
    • der Ortsname: Der Ortsname wird im Regelfall übertragen.
    • eine Flag, welches gesetzt ist, wenn die Route bis zum nächsten Manöverpunkt auf Autobahnen bzw. autobahnähnlichen Straßen verläuft. Das gesetzte Flag gibt den Hinweis darauf, daß eine frühzeitige Signalisierung des nächsten Manövers vorgenommen werden sollte.
    Bei gesetztem Flag sind die Ausfahrten der Autobahn mit Geo-Codes codiert. Das Endgerät kann dem Geo-Code-Tabel die Information über die nächste Ausfahrt sowie die Entfemung dahin entnehmen und zur Anzeige bringen.
    • eine abstrahierte Darstellung (lcons) der Kreuzung. Dabei werden 4 verschiedene Kreuzungstypen unterschieden
      • keine Kreuzung (der Wechsel eines Straßen- oder Ortsnamens wird übertragen)
      • sternförmige Kreuzung mit bis zu 8 möglichen Ein-/Ausfahrten
      • Kreisverkehr mit bis zu 8 Ein-/Ausfahrten
      • Autobahnausfahrten mit bis zu vier Abfahrtsmöglichkeiten pro Abfahrtsrichtung. Alle Darstellungen beziehen sich auf die Fahrtrichtung entsprechend der Routenbeschreibung. Die jeweilige Ausfahrtstraße ist gekennzeichnet. Ein Wendemanöver wird in der sternförmigen Kreuzung als Stern mit der Codierung Einfahrtsstraße = Ausfahrtstraße gekennzeichnet. Die Kreuzungstypen Stern und Kreis können als "Moving Map" dargestellt werden. Dazu können Angaben zum Winkel zwischen Fahrtrichtung (= Einfahrtsstraße), Ausfahrtsstraße und gegen Norden enthalten sein.
    • ein Hinweis (wenn link flag= 1) darauf, daß 2 Manöver so dicht aufeinander folgen, daß sie zusammengefaßt und als eine Anweisung ausgegeben werdeg sollten. Das link flag wird im ersten der beiden zusammenzufassenden Wegepunkte gesetzt. Zwei aufeinanderfolgende Wegepunkte mit gesetztem link flag sind nicht zulässig.
    • die geschätzte Fahrzeit zum nachfolgenden Wegepunkt (wird nur dann nicht übertragen, wenn im selben Wegepunkt das Link-Flag gesetzt ist).
    • die Weglänge zum nachfolgenden Wegepunkt (wird nur dann nicht übertragen, wenn im selben Wegepunkt das Link-Flag gesetzt ist).
    • ein optionaler Aktionshinweis, der unterstützende Informationen zum Manöver in Textform enthält (z.B. Richtung Köln, Achtung: Enge Kurve).
    • optional die Angabe einer Korrridorbreite. Die Korridorbreite definiert zusammen mit der Länge der Luftlinie zum nächsten Wegpunkt (zu errechnen aus den WGS-84-Koordinaten) ein rechteckiges Bezugsgebiet. Dieses Bezugsgebiet wird zur Fehlfahrtenerkennung verwendet. Verläßt der Kunde das Bezugsgebiet, wird die Fehlfahrt erkannt Zusätzlich kann das Bezugsgebiet zur Selektion von routenrelevanten Verkehrsinformationen eingesetzt werden (s. Kapitel 3.2.1).
    • optional die Anzahl der Kreuzungen bis zum nachfolgenden Manöverpunkt sowie die Entfernung zur nächsten Kreuzung: Wenn es aufgrund des Straßenverlaufs sinnvoll erscheint, wird die Anzahl der Kreuzungen bis zum nächsten Manöverpunkt übertragen. Dies ermöglich es in Verbindung mit dem nächsten Manöverpunkt, dem Kunden eine zusätzliche Information zu geben (z. B. "6. Kreuzung links").
    Die geographischen Koordinaten werden in Abhängigkeit vom Kreuzungstyp und gesetztem link flag gesetzt. Die Bedeutung der Koordinaten wird in der Dienstespezifikation des Anbieters im Detail festgelegt.
    Es werden bevorzugt die geographischen Koordinaten nach folgenden Regeln vergeben:
    Kreuzungstyp link flag ungesetzt link fiag gesetzt
    1. Wegepunkt 2. Wegepunkt
    Stern Kreuzungsmittelpunkt Kreuzungsmittelpunkt
    1. Kreuzung    		 Kreuzungsmittelpunkt
    2. Kreuzung
    Kreisverkehr Einfahrtspunkt des Kreisverkehrs Einfahrtspunkt in den Kreisverkehr Ausfahrpunkt aus dem Kreisverkehr
    Autobahnausfahrt/ Gabel Beginn der Abbiegespur bei einfachen Ausfahrten, bei komplexen Ausfahrten Beginn der eigentlichen Ausfahrspur % %
    Wird das Link-Flag gesetzt, ist der Kreuzungstyp des ersten Wegepunktes ausschlaggebend für die Interpretationsvorschrift.
    Bei gesetztem link flag und dem Kreuzungstyp Stern enthalten beide Wegepunkte eine Icon-Codierung vom Typ Stern. Die Bildschirmdarstellung sollte in einem Icon erfolgen. Die Ausfahrtstraße des 1. Wegepunktes ist dazu mit der Einfahrtstraße des 2. Wegepunktes zu kombinieren.
    Ist der Kreuzungstyp bei gesetztem link flag vom Typ Kreisverkehr oder Autobahnausfahrt, dann wird im zweiten Wegepunkt keine Icon-Codierung übertragen, sondern es wird eine zweite geographische Koordinate zur Unterstützung der Icon-Anzeige im Endgerät angegeben (s. oben).
    Im Anhang ist ein Vorschlag für mögliche Icon-Darstellungen sowie für ein geeignetes Anzeigeverhalten enthalten.
    Fehlfahrten
    Werden Fehlfahrten erkannt, weil das durch die Korridorbreite aufgespannte Bezugsgebiet verlassen wurde, ist der Benutzer zu informieren. Das Endgerät sollte nun dem Benutzer die Möglichkeit geben, eine neue Routenanfrage bezogen auf das gleiche Ziel zu starten. Zusätzlich sollte in den Kompaßmode geschaltet werden, wobei der Pfeil auf den nächstliegenden Wegepunkt zeigt.
    Eine Änderung des Wegepunktes, auf den der Pfeil zeigt (weil ein anderer Wegepunkt zum nächsten Wegepunkt wird) sollte vom Benutzer ausdrücklich quittiert werden. Idealerweise kann der Benutzer im Kompaßmode zwischen den Wegepunkten umschalten.
    Eine Fehlfahrt sollte erst dann dem Benutzer angezeigt werden, wenn sich die Position über eine größere Distanz außerhalb des Korridors bewegt. Dadurch können Ungenauigkeiten des GPS berücksichtigt bzw. unterdrückt werden.
    3.2 Verbindung zu anderen Diensten 3.2.1 Verkehrsinformationsdienst
    Das IE "Street Identification", welches in den Diensten Verkehrsinformation und Navigation/Orientierungshilfe Verwendung findet, ermöglicht die Berücksichtigung neuer, während der Fahrt autretender Vekehrsstörungen in Bezug auf die aktuelle Route. Die weitere Präzisierung/Individualisierung erfolgt über die Auswertung der Geo Codes relativ zur aktuellen Position, bzw. zu den Wegepunkten und über die zugehörige Korridorinformation.
    Die für die Navigationsdienste und in den Verkehrsinformationsdiensten verwendeten Straßenbezeichungen sind identisch. T-Traffic-Verkehrsmeldungen enthalten bevorzugt diese Straßenbezeichnung (z. B. A555, B236). Dadurch ist möglich, Verkehrsmeldungen, welche sich auf Straßen beziehen, die auf der Route liegen, aus der Gesamtheit der dem Endgerät vorliegenden Verkehrsmeldungen auszufiltern (z.B. bei umkreisbezogenem oder zielgerichtetem VI-Dienst, Cell Broadcast).
    Zusätzlich ist es unter Ausnutzung des durch den Fehlfahrtenkorridor und der Wegepunkte aufgespannten Bezugsgebietes möglich, die Verkehrsmeldungen zu eliminieren, welche nicht auf der Route liegen. Dieses geschieht dadurch, daß nur Verkehrsmeldungen selektiert werden, bei denen zusätzlich zur Straßenbezeichnung auch die Geo-Codes im Bezugsgebiet liegen (s. Fig. 4). Die durch den Abstand der Wegepunkte aufgespannte Rechteckseite sollte zu beiden Seiten um 1km verlängert werden, um sicherzustellen, daß die Überschneidung der Korridore zu einer Selektion aller die Route betreffenden Verkehrsinformationen führt.
    Sollte das Endgerät in Ausnahmefällen in der Routengrobbeschreibung einen nicht interpretierbaren Geo-Code erhalten, dann kann dieser mittels der TINFO-Message TINFO_Code_Request_Message in Klartext übersetzt werden (s. ADP TINFO).
    Verkehrsmeldungen enthalten ein Umleitungsflag ("bypass flag"). Wird eine Verkehrsmeldung auf der Route mit gesetztem Umleitungsflag empfangen, sollte dem Kunden mit der Anzeige der Verkehrsmeldung die Möglichkeit eine neuen Routenanfrage (kombiniert mit einem Travel Time Request) gegeben werden (s. auch Kapitel 3.4).
    Die vorgeschlagene Nutzung der innerhalb des Navigationsdienstes bereitgestellten Routeninformation und des Bezugsbereiches in Verbindung mit dem Verkehrsinformationsdienst ist ein reines Endgeräte-Feature, welches durch die dargestelle Kompatibilität der Dienste ermöglicht wird.
    3.2.2 Auskunftsdienst
    Jeder Dienste-Anbieter kann im Rahmen der Service-Provider-POI's frei Nummern für einzelne POI-Typen vergeben (z. B. Tankstellen, Geldautomaten).
    Im Rahmen der Navigationsdienste wird zunächst keine Nummerierung von Service-Provider-POI's festgelegt. Sollen Service-Provider-POI's für den Navigationsdienst genutzt werden, dann muß durch Nutzung eines Auskunftsdienstes die vollständige Adresse des gewünschten POI's aus der Zentrale geladen werden. Diese Adresse kann dann bei einer Zielanfrage genutzt werden. Es sollte immer die vollständige von der Zentrale erhaltene Adreßinformation zum Service-Provider-POI übertragen werden, um Mehrdeutigkeiten auszuschließen (s. auch Kapitel 3.1.1.1).
    In der Dienstespezifikation und dem zugehörigen ADP zu den Auskunftsdiensten ist beschrieben, wie ein Service-Provider-POI geladen werden kann.
    3.3 Kommunikationsabläufe
    Alle bidirektionalen Kommunikationsabläufe sind im ADP der Navigationsdienste dargestellt.
    Eine Anfrage gilt seitens der Zentrale als abgeschlossen, wenn die gewünschte Antwort (Route_Message, Travel_Time_Estimation) oder die Error_Message versandt wurde. Enthält die Error_Message eine Auswahlliste, mit deren Hilfe der Kunde seine Anfrage konkretisieren kann, dann wird eine nachfolgende Anfrage mit eindeutiger Adresse trotzdem als vollständig neuer Ablauf gewertet.
    3.3.1 Digital Request
    Die Anfrage an die Zentrale erfolgt nur die Route Request Message (kein Operator, s. Fig. 5).
    Folgende Timer werden verwendet:
    • TNAVa (wird mit Empfang der Delivery Notification gestartet)
    Mit dem Absenden der Route Message oder der Error Message ist zentraleseitig der Ablauf beendet.
    3.3.2 Operatorgestützte Anfragen
    Eine Operator-Anfrage im Sinne dieser Spezifikation wird immer mit einer Route Request Message begonnen. Operator-Anfragen ohne Route Request Message (s. Kapitel 3.1.1.2) sind wie fremd-initiierte Anfragen zu behandeln.
    Bei einer Operator-Anfrage mit einer Route Message sind zentraleseitig die Informationen aus der Route Message (zumindest Startposition) und aus dem Dialog mit dem Operator zusammenzuführen. Dabei muß durch einen Timer-basierten Synchronisationsmechanismus sichergestellt sein, daß die Route_Message dem Operator zu Gesprächsbeginn vorliegt.
    3.3.2.1 Timer-basiert (MO)
    Nach Ablauf eines Timers baut das Endgerät die Sprachverbindung zum Operator auf (Fig. 6).
    Folgende Timer werden verwendet:
    • TNAVa (wird mit Absenden der Route_Request_Message gestartet)
    • TNAVb (wird mit Empfang der Delivery Notification für die Route_Request_Message gestartet)
    • TNA Vc (wird mit Empfang der Delively Notification für die Route_Request_Message gestartet)
    Mit dem Absenden der Route Message oder der Error Message ist zentraleseitig der Ablauf beendet.
    3.3.3 Fremd-Initiierte Route Messages
    Zusätzlich zu den dargestellten Kommunikationsabläufen muß das Endgerät in der Lage sein, von ihm nicht initierte Route_Messages zu verarbeiten (Fig. 7). Solche Route_Messages können z. B. über andere Medien Online-Dienste initiiert worden sein). Die Präsentation der Route-Message sollte nie ohne aktive Quittung durch den Benutzer erfolgen.
    3.4 Routenbewertung
    Bei der Routenbewertung wird eine Routenbeschreibung (einer berechneten Route) in die Zentrale übertragen (Travel_Time_Request_Message). Die Rolute wird dabei wie bei der Orientierungshilfe oder der Zielführung in Form von Wegeleitpunkten beschrieben.
    Die Zentrale schätzt die Reisezeit für diese Route aufgrund der aktuellen Verkehrslage und überträgt diese in das Endgerät (Travel_Time_Message).
    Der Ablauf ist wie folgt (vgl. Fig. 8, s. auch ADP Navigationsdienste):
    Die Travel_Time_Request_Message hat folgende Inhalte:
    • Anzahl der Wegeleitpunkte zur Routenbeschreibung,
    • Geogaphische Koordinate und/oder offizielle Straßenbezeichung/Straßenname, Kreuzungen werden dabei genauso wie bei der Adresseingabe am Endgerät bei der Routenanfrage beschrieben codiert.
    • Grobe Himmelsrichtung, die nach dem Erreichen des Wegepunktes gefahren wird (nicht beim Zielwegepunkt).
    • optional benutzerspezifische Informationen (Telefonnummer; Angaben zum Endgerät werden ignoriert). Von der Zentrale wird eine übertragene Telefonnummer als die Zieladresse der Travel_Time_Estimation interpretiert. Dieses Feld ist insbesondere dann mit der Empfängertelefonnummer der Route auszufüllen, wenn die Route an ein anderes Endgerät als das absendende Endgerät gesendet werden soll.
    Folgende Timer werden verwendet:
    • TNAVd (wird mit Absenden der Travel Time Request Message gestartet)
    Mit dem Absenden der Travel Time Message oder der Error Message ist zentraleseitig der Ablauf beendet.
    Die Codierung der einzelnen IE'S ist im ADP zu den Navigationsdiensten detailliert beschrieben.
    3.5 Fehlerbehandlung
    Die dienstespezifischen Fehlermeldungen sind im ADP festgelegt. Diensteübergreifende Fehler (z.B. Kommunikationsfehler) werden im Dokument "Beschreibung der diensteübergreifenden Fehlerbehandlung" dargestellt.
    Soweit in diesem Dokument keine zusätzlichen Erläuterungen gegeben werden, sind dienstespezifische Fehlermeldungen folgendermaßen zu interpretieren:
    Error Type Erläuterung/Bedeutung
    input error s. Dokument "Beschreibung der diensteübergreifenden Fehlerbehandlung"
    server timed out s. Dokument "Beschreibung der diensteübergreifenden Fehlerbehandlung"
    server error s. Dokument "Beschreibung der diensteübergreifenden Fehlerbehandlung"
    server overloaded s. Dokument "Beschreibung der diensteübergreifenden Fehlerbehandlung"
    on treatment Ist eine zügige Beantwortung der Anfrage wegen momentaner Überlastung des Servers nicht möglich, dann wird diese Fehlermeldung übersandt. Die berechnete Route wird zu einem späteren Zeitpunkt nachgeschickt.
    start not identified s. Kapitel 3.1.1.1
    destination not identified s. Kapitel 3.1.1.1
    start ambiguous s. Kapitel 3.1.1.1
    destination ambiguous s. Kapitel 3.1.1.1
    route not identified Die Berechnung einer Route auf Basis der übergebenen Kriterien war nicht möglich.
    further requests not possible s. Dokument "Beschreibung der diensteübergreifenden Fehlerbehandlung"
    additional destination 1 not identified s. Kapitel 3.1.1.1
    additional destination 2 not identified s. Kapitel 3.1.1.1
    additional destination 3 not identified s. Kapitel 3.1.1.1
    additional destination 4 not identified s. Kapitel 3.1.1.1
    additional destination 5 not identified s. Kapitel 3.1.1.1
    additional destination 6 not identified s. Kapitel 3.1.1.1
    additional destination 1 ambiguous s. Kapitel 3.1.1.1
    additional destination 2 ambiguous s. Kapitel 3.1.1.1
    additional destination 3 ambiguous s. Kapitel 3.1.1.1
    additional destination 4 ambiguous s. Kapitel 3.1.1.1
    additional destination 5 ambiguous s. Kapitel 3.1.1.1
    additional destination 6 ambiguous s. Kapitel 3.1.1.1
    phone call not completed s. Dokument "Beschreibung der diensteübergreifenden Fehlerbehandlung"
    order ignored: previous order is still being processed s. Dokument "Beschreibung der diensteübergreifenden Fehlerbehandlung"
    4 Anforderungen an die Endgeräte 4.1 Kommunikation
    Die Daten-Kommunikation zwischen dem Endgerät und der Zentrale wird durch den im GSM zur Verfügung stehenden Kurznachrichtendienst abgewickelt. Im Gegensatz zu anderen VT-Diensten wird bei den Navigationsdiensten der Cell Broadcast nicht benötigt, so daß nur Kurznachrichtendienste SMS-MT (TS 21) und SMS-MO (TS 22) für die Abwicklung der Dienste benötigt werden. Um den Benutzer weiterhin Operator-Anfragen zu ermöglichen, muß der Sprachdienst (TS 11) unterstützt werden.
    4.2 Ortung
    Das Endgerät sollte über Koppelnavigation verfügen.
    Das Endgerät darf erst dann als Startadresse eine Lokalisierungsperienkette an die Zentrale senden, wenn eine hinreichend genaue Lokalisierung garantiert ist. Um bei Einschaltung des Endgerätes eine schnelle Initialisierung bzw. Zielanfrage zu ermöglichen, sollte immer die letzte Spur vor dem Abschalten im Gerät gespeichert sein.
    Der Ortungsgenauigkeit mit Kopplenavigation muß im Mittel <50 m sein. Die Genauigkeit der Koppelnavigation sollte bei langsamer Stadtfahrt (30 - 50 km/h) 5% der zurückgelegten Distanz und bei Fahrten mit mittlerer Geschwindigkeit (70 - 90 km/h) 3 % der zurückgelegten Distanz nicht überschreiten, wobei eine maximale GPS-Abschattungsdistanz von 1000 Meter zugrundegelegt wird.
    Die GPS-Signalreakquisitionszeiten sollten im Bereich von 1 bis 2 Sekunden liegen.
    4.3 MMI
    Das Endgerät muß über ein Grafik-Display mit der Möglichkeit zur Graphik- und Textdarstellung, sowie eine komfortable Eingabemöglichkeit verfügen. Zusätzlich ist eine Sprachausgabe der Manöver wünschenswert.
    Empfehlung: Punktmatrix min 128x112
       min. 4 Zeilen, min. 20 Zeichen/Zeile
    4.4 Speicher
    Für die Orientierungshilfe sollte das Endgerät mindestens 40 Wegepunkte speichern können. Es sollten idealerweise speicherbare 100 Wegepunkte für eine Route vorgesehen werden. Um die Eingabe von Zielen zu erleichtern, sollte im Endgerät ein Notizbuch mit mind. 50 Einträgen existieren, aus dem u.a. auch die Zielbeschreibung übernommen werden kann.
    Der Wegepunktspeicher sollte dynamisch ausgelegt sein, damit beispielsweise bei Wegepunkten, welche ohne Straßennamen übertragen werden, kein Speicher für den Straßennamen freigehalten wird.
    Kann das Endgerät wegen fehlenden Speicherplatzes nicht alle Wegepunkte speichern, dann sollten bis auf die Zieladresse alle Wegepunkte verworfen werden, die nicht mehr gespeichert werden konnten. Der Kunde ist darüber zu informieren, daß Wegepunkte verworfen worden sind. Nach Erreichen des letzten noch gespeicherten Wegepunktes der Route ist in den Kompaßmode auf das Ziel zu schalten. Es wird empfohlen, zusätzlich dem Kunden rechtzeitig vor dem Erreichen des letzten noch gespeicherten Wegepunktes die Möglichkeit zu geben, eine neue Routenanfrage zum Ziel zu stellen.
    4.5 Sonstige Anforderungen
    Eine Zieleingabe sollte ebenfalls mit Hilfe der Geo-Codierung möglich sein.
    Die Anzeige von Hinweisen sollte durch ein akustisches Signal angekündigt werden.
    Der Benutzer sollte die Möglichkeit haben, zwischen den Wegeleitsymbolen scrollen zu können (insbes. weiterschalten auf den nächsten Wegeleitpunkt).
    4.6 Vorschläge zur Wegeleitsymbolik
    Wie bereits in der Einleitung dargelegt, ist der Dienst Orientierungshilfe für Endgeräte gedacht, welche ohne Digitale Karte im Fahrzeug bevorzugt mit GPS ausgestattet sind. Es ist deshalb nicht möglich, wie bei Navigationssystemen exakt am Manöverpunkt Abbiegehinweise wie z. B. ,jetzt rechts abbiegen" zu geben, da aufgrund der eingeschränkten Positionierungsgenauigkeit die dazu nötige exakte Feststellung der Fahrzeugposition (ca. 10m genau) nicht realisierbar ist.
    Deshalb muß der Fahrer frühzeitig auf bevorstehende Manöver aufmerksam gemacht werden. Als Manöverhinweis reicht es nicht aus, nur das unmittelbar auszuführende Manöver anzugeben (z. B. rechts abbiegen), sondern der Nutzer muß frühzeitig mittels einer abstrahierten Darstellung über die Kreuzungstopographie am Manöverpunkt informiert werden.
    Bei kurz hintereinander folgenden Manövern oder komplexen Kreuzungen müssen diese dem Nutzer gleichzeitig (d.h. in einem Symbol) dargestellt werden, da dieses seiner Wahrnehmung des Manövers in der Realität und seiner Reaktionsmöglichkeit entspricht. Die Zusammenfassung von zwei Icons zu einem Symbol wird durch das link flag angezeigt.
    Für den spätesten Zeitpunkt der Anzeige des Wegeleitsymbols werden folgende Vorschläge gemacht (die Anzeige sollte durch die Ausgabe einer akustischen Warnung begleitet werden):
    mit Koppelnavigation ohne Koppelnavigation
    Autobahn: 1.500 m 1.500 m
    Landstraße 500 m 500 m
    Stadt (ohne Stadtautobahnen) 50 m 100 m
    Das Wegeleitsymbol sollte ca. 50m (ohne Koppelnavigation 100m) nach dem Erreichen der geographischen Koordinaten des Wegeleitsymbols vom Bildschirm entfernt werden (bei gesetztem link flag nach Erreichen der zweiten geographischen Koordinate).
    Die vorgeschlagene Wegeleitsymbolik beruht auf vier Kreuzungstypen, von denen drei als Grundtypen codiert zum Fahrzeug übertragen werden:
  • 1. Sternförmige Kreuzung (junction)
  • 2. Kreisverker (roundabout)
  • 3. Autobahnausfahrt/Füßler (fork) Durch Einsatz des link flags beim Typ "junction" wird der zusätzliche Typ
  • 4. Doppelkreuzung/Versatz
    • dargestellt.
    Nachfolgend werden Vorschläge für die Bildschirmdarstellung der einzelnen Kreuzungstypen gemacht. Die Darstellung beruht auf einem Display mit mindestens 128 x 112 Pixeln.
    Zusätzlich sollte die Entfernung zum 1. Manöverpunkt, sowie der Name der Straße, in die abzubiegen ist, angezeigt werden.
  • 1. Sternförmige Kreuzung (junction) s. Fig. 9a
  • 2. Kreisverkehr (roundabout) s. Fig. 9b
  • 3. Autobahnausfahrt/Füßler (fork) s. Fig. 9c
  • 4. Doppelkreuzung/Versatz (aus junction mit link flag)
    • Geradeaus aufeinanderfolgende Kreuzungen s. Fig. 9d
    schräger Versatz s. Fig. 9e
    rechtwinkliger Versatz s. Fig. 9f

    Claims (11)

    1. Verfahren zur Routeninformation mobiler Teilnehmer, wobei auf Anfrage oder automatisch Daten zwischen einer Zentraleinheit und einer mobilen Teilnehmereinheit übertragen werden, wobei seitens der Teilnehmereinheit eine Routenanfrage an die Zentraleinheit erfolgt, in der Zentraleinheit eine Routenberechnung und Aufbereitung der Daten erfolgt und die vollständige Routeninformation in die Teilnehmereinheit übertragen wird, in der eine Abarbeitung der Routeninformation erfolgt,
      wobei die Routeninformation in der Teilnehmereinheit mittels einer Eingabe/Ausgabeeinheit in Form einer textuellen Routengrobbeschreibung und einer berechneten Gesamtentfernung und Reisezeit zum Zielort unter Berücksichtigung der aktuellen Verkehrslage ausgegeben wird und eine Liste von Wegepunkten umfasst, die Manöverpunkte bezeichnen, mit deren Hilfe der mobile Teilnehmer frühzeitig auf bevorstehende Manöver aufmerksam gemacht wird, wobei er mittels einer abstrahierten Darstellung von Wegeleitsymbolen über die Kreuzungstopographie und am Manöverpunkt auszuführende Manöver informiert wird, dadurch gekennzeichnet, daß zwischen den einzelnen Wegepunkten ein Bezugsgebiet mit einer bestimmten Korridorbreite definiert wird, welches zur Fehlfahrtenerkennung und zur Selektion von routenrelevanten Verkehrsinformationen dient.
    2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Routenanfrage über Eingabe an der Teilnehmereinheit oder mittels Sprachverbindung mit einem Operator erfolgt.
    3. Verfahren nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass in der Zentraleinheit die Routenberechnung basierend auf einer Routenanfrage anhand folgender Daten durchgeführt wird: Startpunkt, Zieladresse und gewünschte Abfahrtszeit oder Ankunftszeit.
    4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Liste der Wegepunkte mit folgenden Inhalten übertragen wird:
      die geographische Koordinate des Wegepunktes;
      den Ortsnamen;
      eine abstrahierte Darstellung der Kreuzung in Form einer Wegeleitsymbolik; und
      ein oder mehrere Hinweisflags.
    5. Verfahren nach einem der Ansprüche 3 oder 4, dadurch gekennzeichnet, dass anhand der Wegeleitsymbolik vier mögliche Kreuzungstypen durch die Eingabe-/Ausgabeeinheit darstellbar sind:
      Sternförmige Kreuzung;
      Kreisverkehr;
      Autobahnausfahrt/Füßler; und
      Doppelkreuzung/Versatz.
    6. Verfahren nach einem der Ansprüche 1, 3 bis 5, dadurch gekennzeichnet, dass die Liste der Wegepunkte mit folgenden weiteren Inhalten übertragen wird:
      die offizielle Straßenbezeichnung der Straße, in die abgebogen werden soll;
      die geschätzte Fahrzeit zum nachfolgenden Wegepunkt;
      die Weglänge zum nachfolgenden Wegepunkt;
      ein Aktionshinweis;
      die Korridorbreite zur Definition eines Bezugsgebiets; und
      die Anzahl der Kreuzungen bis zum nachfolgenden Manöverpunkt sowie die Entfernung zur nachfolgenden Kreuzung.
    7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass in Form eines zusätzlichen Dienstes eine Bewertung einer beliebigen in der Teilnehmereinheit vorhandenen und an die Zentraleinheit übertragenen Route bezüglich der aufgrund der aktuellen Verkehrslage zur erwartenden Reisezeit erfolgt, wobei die ermittelte Reisezeit an die Teilnehmereinheit übertragen wird.
    8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Kommunikation zwischen der Teilnehmereinheit und der Zentraleinheit über den Kurznachrichtendienst eines GSM-Kommunikationsnetzes durchgeführt wird.
    9. Verfahren nach einem der Ansprüche 1- 7, dadurch gekennzeichnet, dass zur Ortsbestimmung der Teilnehmereinheit eine GPS-Empfangseinrichtung verwendet wird.
    10. Verfahren nach einem der Ansprüche 1-8 , dadurch gekennzeichnet, dass eine Ein/Ausgabeeinheit in Form eines Grafik-Displays verwendet wird.
    11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass eine Ein/Ausgabeeinheit mit einer Sprachausgabeeinrichtung verwendet wird,.
    EP97952715A 1996-12-10 1997-12-10 Verfahren und anordnung zur information mobiler teilnehmer Expired - Lifetime EP0883872B1 (de)

    Applications Claiming Priority (3)

    Application Number Priority Date Filing Date Title
    DE19651146 1996-12-10
    DE19651146A DE19651146A1 (de) 1996-12-10 1996-12-10 Verfahren und Anordnung zur Information mobiler Teilnehmer
    PCT/DE1997/002884 WO1998026396A1 (de) 1996-12-10 1997-12-10 Verfahren und anordnung zur information mobiler teilnehmer

    Publications (2)

    Publication Number Publication Date
    EP0883872A1 EP0883872A1 (de) 1998-12-16
    EP0883872B1 true EP0883872B1 (de) 2002-05-08

    Family

    ID=7814139

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    EP97952715A Expired - Lifetime EP0883872B1 (de) 1996-12-10 1997-12-10 Verfahren und anordnung zur information mobiler teilnehmer

    Country Status (5)

    Country Link
    EP (1) EP0883872B1 (de)
    AT (1) ATE217434T1 (de)
    AU (1) AU5650798A (de)
    DE (2) DE19651146A1 (de)
    WO (1) WO1998026396A1 (de)

    Families Citing this family (29)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    DE19816585B4 (de) * 1998-04-08 2004-08-12 Atx Europe Gmbh Verfahren zur Routeninformation eines Endgerät-Benutzers durch Übermittlung von Routeninformationen von einer Zentrale an das Endgerät
    ES2323908T3 (es) * 1998-11-23 2009-07-27 Integrated Transport Information Services Limited Sistema instantaneo de supervision de trafico.
    DE19906863A1 (de) 1999-02-18 2000-10-19 Nokia Mobile Phones Ltd Verfahren zur Navigation eines Objekts
    WO2000079218A1 (fr) * 1999-06-22 2000-12-28 Mitsubishi Denki Kabushiki Kaisha Poste mobile et serveur d'un systeme de navigation
    DE19937370A1 (de) * 1999-08-12 2001-02-15 Bosch Gmbh Robert Verfahren zur Anforderung und zur Überarbeitung von Verkehrsmeldungen
    DE19937372A1 (de) 1999-08-12 2001-02-15 Bosch Gmbh Robert Verfahren zur Anforderung und zur Verarbeitung von Verkehrsmeldungen
    AU2115601A (en) 1999-10-19 2001-04-30 Magellan Dis, Inc. Portable vehicle navigation system
    DE10014806C2 (de) * 2000-03-27 2003-11-27 Tegaron Telematics Gmbh Verfahren zur Off-Board-Navigation eines Fahrzeug
    DE10030805A1 (de) * 2000-06-29 2002-01-10 Nokia Mobile Phones Ltd Verfahren und Mobilstation zur Wegführung
    US6587781B2 (en) 2000-08-28 2003-07-01 Estimotion, Inc. Method and system for modeling and processing vehicular traffic data and information and applying thereof
    DE10105898A1 (de) * 2001-02-09 2002-08-14 Bosch Gmbh Robert Verfahren zum Übergeben von Zielführungselementen, Fahrzeugnavigationsgerät und Zentrale
    DE10105897A1 (de) 2001-02-09 2002-08-14 Bosch Gmbh Robert Verfahren zum Austauschen von Navigationsinformationen
    DE60202800T2 (de) * 2001-03-12 2006-02-09 Magellan Dis Inc., Rochester Hills Off-Board-Navigationssystem mit personalisierter Navigations-Datenbank
    EP1386303A1 (de) 2001-04-03 2004-02-04 Magellan Dis Inc. Fahrzeugnavigationssystem mit tragbarem personal computer
    DE10128409B4 (de) * 2001-06-12 2007-05-31 Harman Becker Automotive Systems Gmbh Navigationssystem
    EP2463627B1 (de) 2002-04-30 2017-07-19 Intel Corporation Navigationssystem, welches Korridorkarten verwendet
    TW588292B (en) * 2003-02-21 2004-05-21 Sin Etke Technology Co Ltd Simplified navigation guidance method and system thereof
    TWI220508B (en) * 2003-05-02 2004-08-21 Sin Etke Technology Co Ltd Easy vehicle navigation method and system
    DE10322558A1 (de) * 2003-05-20 2004-12-09 Robert Bosch Gmbh Verfahren und System zum Zuordnen von Diensteanbietern zu Telematikendgeräten
    US7620402B2 (en) 2004-07-09 2009-11-17 Itis Uk Limited System and method for geographically locating a mobile device
    US7251561B2 (en) 2004-07-28 2007-07-31 Telmap Ltd. Selective download of corridor map data
    KR20060119746A (ko) 2005-05-18 2006-11-24 엘지전자 주식회사 교통상태에 대한 정보를 제공하고 이를 이용하는 방법 및장치
    DE602006016025D1 (de) * 2005-05-18 2010-09-16 Lg Electronics Inc Bereitstellung von Verkehrsinformationen in Bezug auf einen Stautrend
    US7729335B2 (en) 2005-05-18 2010-06-01 Lg Electronics Inc. Providing traffic information relating to a prediction of congestion status and using the same
    KR20060119739A (ko) 2005-05-18 2006-11-24 엘지전자 주식회사 구간 통과시간에 대한 예측정보를 제공하고 이를 이용하는방법 및 장치
    DE102008033907A1 (de) * 2008-07-18 2010-01-21 Deutsche Post Ag Verfahren und Vorrichtung zum Bereitstellen von Navigationsdaten, Navigationsgerät
    GB0901588D0 (en) 2009-02-02 2009-03-11 Itis Holdings Plc Apparatus and methods for providing journey information
    GB2492369B (en) 2011-06-29 2014-04-02 Itis Holdings Plc Method and system for collecting traffic data
    US9141975B2 (en) 2012-09-23 2015-09-22 Intel Corporation Inferring user risk profile from travel patterns

    Family Cites Families (3)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US4954958A (en) * 1988-08-19 1990-09-04 Hacowie Corporation Directional information system
    US5543789A (en) * 1994-06-24 1996-08-06 Shields Enterprises, Inc. Computerized navigation system
    DE19521929A1 (de) * 1994-10-07 1996-04-11 Mannesmann Ag Einrichtung zur Zielführung von Personen

    Also Published As

    Publication number Publication date
    DE19651146A1 (de) 1998-06-25
    AU5650798A (en) 1998-07-03
    EP0883872A1 (de) 1998-12-16
    ATE217434T1 (de) 2002-05-15
    WO1998026396A1 (de) 1998-06-18
    DE59707219D1 (de) 2002-06-13

    Similar Documents

    Publication Publication Date Title
    EP0883872B1 (de) Verfahren und anordnung zur information mobiler teilnehmer
    EP0883871B1 (de) Verfahren und anordnung zur verkehrsinformation
    EP1030166B1 (de) Verfahren zur Navigation eines Objekts
    EP1186865B1 (de) Verfahren zur Bestimmung einer Fahrtroute eines Fahrzeugs
    EP1198696B1 (de) Verfahren und vorrichtung zur übermittlung von navigations-informationen von einer datenzentrale an ein fahrzeug-basiertes navigationssystem
    EP0752692B1 (de) Verfahren und System zur Aktualisierung von digitalen Strassenkarten
    EP0890080B1 (de) Verfahren zur routenplanung und zielführung von fahrzeugen
    DE2925656C2 (de)
    EP1062481B1 (de) Verfahren zur ausgabe von verkehrsinformationen
    EP1255964B1 (de) Navigationsverfahren mit dynamischer zielauswahl und navigationsgerät
    WO2001015117A1 (de) Ortsbezogene wap-staukarte durch verknüpfung von kartenausschnitten in einer verkehrsinformationszentrale
    WO1998057125A1 (de) Verfahren und vorrichtung zum erzeugen, verschmelzen und aktualisieren von zielführungsdaten
    EP1360458A1 (de) Verfahren zum austauschen von navigationsinformationen
    DE102015200081A1 (de) Bereitstellen von Navigationshinweisen in einem Fahrzeug
    EP1342221A1 (de) Verfahren zum automatischen löschen einer verkehrsmeldung
    EP1120632A1 (de) Verfahren zur zielorientierten Personenführung
    EP2205942B1 (de) Navigationssystem und verfahren zur routenermittlung
    DE10323936A1 (de) Navigationssystem und-Verfahren
    DE102017216124A1 (de) Verfahren zur Erzeugung einer Verkehrsleitinformation und Verkehrsleitsystem
    DE10052934A1 (de) Verfahren zur Bestimmung eines Weges zwischen einem Ausgangspunkt und einem Endpunkt eines Netzes, wie beispielsweise Straßennetzes
    EP1255092B1 (de) Vorrichtung und Verfahren zur Informationsanzeige in einem Fahrzeug
    DE19750777B4 (de) Verfahren zur Übertragung von einer Route eines Fahrzeuges in einem Verkehrsnetz betreffenden Routeninformationen zwischen einer Verkehrszentrale und einem Endgerät in einem Fahrzeug, eine Verkehrszentrale und ein Endgerät
    DE10024183A1 (de) Verfahren zur Zielführung einer Person in Stadtgebieten mittels eines WAP-fähigen Mobilfunknetzes
    EP1714261B1 (de) Verfahren zur decodierung, codierung und übertragung von fahrtroutendaten und navigationsvorrichtung

    Legal Events

    Date Code Title Description
    PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

    Free format text: ORIGINAL CODE: 0009012

    17P Request for examination filed

    Effective date: 19980804

    AK Designated contracting states

    Kind code of ref document: A1

    Designated state(s): AT BE CH DE DK ES FI FR GB IT LI LU NL SE

    17Q First examination report despatched

    Effective date: 20000816

    GRAG Despatch of communication of intention to grant

    Free format text: ORIGINAL CODE: EPIDOS AGRA

    GRAG Despatch of communication of intention to grant

    Free format text: ORIGINAL CODE: EPIDOS AGRA

    GRAH Despatch of communication of intention to grant a patent

    Free format text: ORIGINAL CODE: EPIDOS IGRA

    REG Reference to a national code

    Ref country code: GB

    Ref legal event code: IF02

    GRAH Despatch of communication of intention to grant a patent

    Free format text: ORIGINAL CODE: EPIDOS IGRA

    GRAA (expected) grant

    Free format text: ORIGINAL CODE: 0009210

    AK Designated contracting states

    Kind code of ref document: B1

    Designated state(s): AT BE CH DE DK ES FI FR GB IT LI LU NL SE

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: FI

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20020508

    REF Corresponds to:

    Ref document number: 217434

    Country of ref document: AT

    Date of ref document: 20020515

    Kind code of ref document: T

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: EP

    REF Corresponds to:

    Ref document number: 59707219

    Country of ref document: DE

    Date of ref document: 20020613

    RAP2 Party data changed (patent owner data changed or rights of a patent transferred)

    Owner name: T-MOBILE DEUTSCHLAND GMBH

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: SE

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20020808

    Ref country code: DK

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20020808

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: NV

    Representative=s name: PATENTANWALTSBUERO JEAN HUNZIKER

    NLT2 Nl: modifications (of names), taken from the european patent patent bulletin

    Owner name: T-MOBILE DEUTSCHLAND GMBH

    GBT Gb: translation of ep patent filed (gb section 77(6)(a)/1977)

    Effective date: 20020812

    ET Fr: translation filed
    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: ES

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20021128

    BECN Be: change of holder's name

    Effective date: 20020508

    NLT1 Nl: modifications of names registered in virtue of documents presented to the patent office pursuant to art. 16 a, paragraph 1

    Owner name: T-MOBILE DEUTSCHLAND GMBH

    PLBE No opposition filed within time limit

    Free format text: ORIGINAL CODE: 0009261

    STAA Information on the status of an ep patent application or granted ep patent

    Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

    26N No opposition filed

    Effective date: 20030211

    REG Reference to a national code

    Ref country code: FR

    Ref legal event code: PLFP

    Year of fee payment: 19

    REG Reference to a national code

    Ref country code: FR

    Ref legal event code: PLFP

    Year of fee payment: 20

    PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

    Ref country code: LU

    Payment date: 20161221

    Year of fee payment: 20

    Ref country code: NL

    Payment date: 20161221

    Year of fee payment: 20

    Ref country code: GB

    Payment date: 20161222

    Year of fee payment: 20

    Ref country code: CH

    Payment date: 20161222

    Year of fee payment: 20

    PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

    Ref country code: AT

    Payment date: 20161219

    Year of fee payment: 20

    Ref country code: BE

    Payment date: 20161221

    Year of fee payment: 20

    Ref country code: FR

    Payment date: 20161221

    Year of fee payment: 20

    Ref country code: IT

    Payment date: 20161220

    Year of fee payment: 20

    PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

    Ref country code: DE

    Payment date: 20161220

    Year of fee payment: 20

    REG Reference to a national code

    Ref country code: DE

    Ref legal event code: R071

    Ref document number: 59707219

    Country of ref document: DE

    REG Reference to a national code

    Ref country code: NL

    Ref legal event code: MK

    Effective date: 20171209

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: PL

    REG Reference to a national code

    Ref country code: GB

    Ref legal event code: PE20

    Expiry date: 20171209

    REG Reference to a national code

    Ref country code: AT

    Ref legal event code: MK07

    Ref document number: 217434

    Country of ref document: AT

    Kind code of ref document: T

    Effective date: 20171210

    REG Reference to a national code

    Ref country code: BE

    Ref legal event code: MK

    Effective date: 20171210

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: GB

    Free format text: LAPSE BECAUSE OF EXPIRATION OF PROTECTION

    Effective date: 20171209