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

Verfahren und anordnung zur information mobiler teilnehmer

Info

Publication number
EP0883872A1
EP0883872A1 EP97952715A EP97952715A EP0883872A1 EP 0883872 A1 EP0883872 A1 EP 0883872A1 EP 97952715 A EP97952715 A EP 97952715A EP 97952715 A EP97952715 A EP 97952715A EP 0883872 A1 EP0883872 A1 EP 0883872A1
Authority
EP
European Patent Office
Prior art keywords
route
message
information
request
service
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.)
Granted
Application number
EP97952715A
Other languages
English (en)
French (fr)
Other versions
EP0883872B1 (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

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

  • data can be related to various output parameters, e.g. Location, start or destination information or route information of the trip, central or terminal-side queries that can be carried out with the aid of devices or people.
  • output parameters e.g. Location, start or destination information or route information of the trip, central or terminal-side queries that can be carried out with the aid of devices or people.
  • the data transfers can too
  • the navigation services support the customer when driving to his destination on a route.
  • the route is calculated taking the current traffic situation into account in the service center.
  • the orientation guide described in this document is a simple navigation service that guides customers to their destination with limited wrong way detection and feedback.
  • the route is preferably presented in the terminal using a rough route description and can in particular be represented by icons (route symbols), by means of which the customer is guided to the destination.
  • the orientation aid preferably has a restricted mistrack detection. A targeted return to the route can be supported.
  • the Orientation Aid service is intended in particular for end devices that have no stored location or street data such as a digital map in the vehicle, but only with location determination devices such as are equipped with GPS (in the following is mostly
  • the central unit takes into account the information transmitted by the terminal about the location function of the terminal (e.g. pure GPS or additional dead reckoning). This ensures that a functional orientation aid - albeit of a lower quality - is possible even with terminal devices without dead reckoning.
  • the route evaluation service is also described in this document.
  • a route known in the terminal is transmitted from the terminal to the control center.
  • the travel time for this route is estimated on the basis of the current traffic situation and transmitted to the terminal.
  • the orientation guide has the following basic sequence:
  • the customer asks for the route
  • optimization criteria e.g. shortest or fastest route
  • points that should be approached on the route (via points) or points that should not be approached (avoid points) can also be specified.
  • Various forms are supported for entering the destination address (e.g. city and street, POI: e.g. airport, train station).
  • POI e.g. airport, train station
  • the route request to the head office can be made via
  • control center determines the above information for route calculation in dialog with the customer
  • CORRECTED SHEET (RULE 91) ISA / EP
  • the customer information is first checked for correctness, completeness and uniqueness when the route is requested with a destination request directly on the end device. Possibly. an error message is sent to the vehicle. If the user request cannot be clearly interpreted in the case of incomplete address information, a selection list is sent to the vehicle with the error message, with which the request can be specified.
  • the route is prepared at the headquarters.
  • the route information is sent to the vehicle using the Route_Message.
  • the request for the head office ends.
  • the route information contains
  • the list of waypoints is processed locally in the end device.
  • the order of the waypoints on the route is 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 has to be carried out, this is indicated by a corresponding icon.
  • Wrong journeys are recognized when the customer leaves a predetermined corridor, the width of which is loaded into the terminal along with the route description.
  • the terminal can then be
  • This service enables the evaluation of a route present in the terminal with regard to the travel time to be expected on the basis of the current traffic situation (see FIG. 3).
  • the route description (of the route to be calculated) is transferred to the head office (Travel_Time_-Request_Message).
  • the route is described in the form of guidance points as with the orientation aid or the route guidance.
  • the head office estimates the travel time for this route based on the current traffic situation and transfers it to the end device (Travel_Time_Message).
  • the individual services are described functionally and the concrete processes based on the ADPs are shown.
  • 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.
  • the definition of the individual service parameters is the task of the respective service provider. This basic specification specifies the total scope of the functions and processes to be supported by the first-generation end devices. In addition, these processes and functions can be specified in more detail by the respective service providers in separate documents.
  • the transport frame for the message types is defined in:
  • Compass mode / pure terminal-side function in which an arrow on the homing display points in the direction of a geographic coordinate (usually with additional indication of the distance in a straight line)
  • variable length
  • the transport protocol is used as follows to use the orientation aid and route evaluation services:
  • the framework supports the sending of several short messages.
  • Application IDs are unique service identifiers assigned by the head office. These are transferred in the Fe / o ⁇ pplication ID in the transport layer.
  • the service providers can define independent services within the defined processes. These can be characterized, for example, in that the information content transmitted is restricted. Service identifiers are assigned to identify the services offered.
  • Initiative Fla ⁇ 1 (initiative) marks the first transaction in the chain, the order.
  • the initiative Flao 1 (initiative).
  • Protocol Discriminator and Message Type can be found in the document "Message Type Numbering".
  • the bulk flag is always set to 0.
  • the terminal For the orientation aid service, the terminal must support the full functionality of the internal services with regard to address management.
  • the terminal For the route evaluation service, the terminal must support the full functionality of the internal services with regard to address management.
  • All service parameters for navigation services are listed below.
  • the service parameters currently supported by the control center are loaded into the terminal device by internal services. Processes or functions that cannot be parameterized are a binding part of the standard and are supported by all control centers.
  • 64-bit switches are available to parameterize the functions and are assigned as follows. All of the functions listed are to be supported by the end device and are parameterized in a provider-specific manner via the internal services.
  • the orientation guide has the following basic sequence:
  • the customer may use the operator or e.g. B. initiates an online service to calculate a route (also with a time delay), so that the terminal then receives a route description without initiating a route request. In this case, the process begins immediately with the processing of the route in the terminal.
  • the end devices must support this processing of "foreign", i.e. route messages initiated by third parties.
  • the route request to the headquarters can be done via
  • the following information must be provided or automatically generated by the end device:
  • Destination address Geographical coordinate and / or postal address description (may only be missing if there is an operator request)
  • Desired departure time or desired arrival time this information is taken into account when calculating the route based on the current traffic situation (the support of this functionality can be parameterized, see chapter 2.7).
  • the "desired departure time" transmitted from the terminal to the control center is initially ignored by T-Traffic.
  • Via points can be used to exclude or correct unwanted routes. 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 its geographic coordinate (see below).
  • This field must then be filled in with the phone number of the recipient of the route if the route request is initiated externally.
  • the customer When entering the destination on the terminal, the customer enters the addresses for the destination and all desired Viapoints on the terminal or selects them from an address memory of the terminal, if available.
  • the address memory (address book) should be filled in the following ways:
  • Position storage The customer can save his current position (geographic coordinate), supplemented by additional address information, in the address book (eg home address) on the end device.
  • address book eg home address
  • the addresses are transmitted to the head office using the Route_Request_Message and checked there for correctness, completeness and uniqueness. If the address information is incomplete, an error message is displayed, which if possible contains an address selection list for the addresses in question.
  • the customer can then select the desired address and use it to initiate a new route request. It can be set by means of a parameter whether the control center fundamentally supports the return of selection lists (see chapter 2.7). All fields provided in the ADP for the specification and transmission of address information are to be supported on the terminal side. The service provider must specify which combinations and subsets are supported centrally.
  • the error message is transmitted to the vehicle. This can contain selection lists. The support of the error message depends on the service provider.
  • Service provider POl the complete address information received when an address is queried via information services must be transmitted (exception: "additional information” and "country”). Service provider POl can be loaded into the end device via information services (see chapter 3.2.2) and saved in the address book if necessary.
  • MAP POI with location selection (street description and POI name are ignored): If there are several POIs in question, the closest POI is selected (a selection list may also be transferred).
  • MAP-POI without location selection The control center selects the nearest POI of this type as a default (based on the start address also transmitted). Street description and POI name are ignored.
  • Place selection and street name The street name must either be transmitted as "Street Identification” or as "Street Name incl. House Number”. If both are transmitted, the street identification is ignored. It is recommended not to use street identification for an address request.
  • the postcode and telephone number must not be passed at the same time, otherwise an error message will appear. The same applies if the place name and postal code or telephone number are contradictory.
  • Place names after the official place name If there are several places with the same official name, the postcode or area code is used for identification. Place names and names of motorway junctions can be passed with a hyphen (e.g. Cologne-Lindenthal, Bonn-Bad Godesberg). If only the names of the suburbs are used in national language (e.g. Wattenscheid, Bad Godesberg), these are also accepted by the head office.
  • hyphen e.g. Cologne-Lindenthal, Bonn-Bad Godesberg.
  • POI type MAP-POI's center, train station, airport as they are shown in the digital map of the headquarters.
  • Service provider POIs are described as part of the information services.
  • Telephone number Area code only (country code is Kannfeld, default: Germany).
  • control center can set the "start / desination / additional address ambiguous" bit for the address concerned.
  • a selection list field follows in the address description, in which an explanation of the error is given in free text in the "Additional Information" field. If a complete telephone number cannot be clearly interpreted, the telephone number is returned with the digits that could be interpreted (example: 0228-5201900 is transferred, the control center can interpret the number up to 02285201 and returns this number).
  • selection lists are transferred to the vehicle with the error message according to the following criteria, whereby the selection list only contains the IUs to be specified (ie no complete address fields, exceptions are mentioned ):
  • a Route_Req ⁇ est_Message is sent that contains at least the start position.
  • the customer dials the operator directly (also possible via other telephones). In this case, he must also inform the operator of his starting position.
  • the end device receives a Route_Message that it has not initiated and interprets it.
  • the request telegram is not subject to any special restrictions. It is recommended to save the start address and the criteria selected by the customer for route calculation in the end device and to transfer them to the control center.
  • Receiving an error message interrupts the establishment of the voice connection if it has not yet been established (with the timer-based procedure).
  • the desired operator request is also identified in the message by the fact that no destination address is 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 IU's except for the destination address. It is recommended to save the criteria selected by the customer for route calculation in the end device and to transfer them to the control center.
  • the control center After the route has been calculated, the control center then sends the route (Route_Message) to the vehicle.
  • the route is created on the basis of the transmitted information based on the current traffic situation and coded in the Route_Message.
  • the Route_Message is then transferred to the vehicle.
  • a detailed rough route description can be generated for devices with a digital map (navigation systems).
  • the list of route symbols in the navigation systems should be reduced to a level that is necessary for a vehicle-autonomous route fine calculation based on them.
  • the Route_Message can contain the following information:
  • the travel time to the destination is rounded, i.e. the control center 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:
  • Breaks should be taken into account when updating the calculated arrival time while driving (detection by switching off the device).
  • the list of waypoints denotes maneuvering 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 traveled is determined by the order of the waypoints in the list.
  • the positioning of the waypoints can be handled differently depending on the service provider. This is particularly the case for the first or last waypoint in a waypoint list.
  • the code contained in the IE "Type of Starting Point” or “Type of Destination” must also be observed when interpreting them. The exact definitions are made in the service provider specific additional specifications.
  • start and destination addresses are always only transmitted with the following information, whereby individual optional fields are not transmitted if they were already included in the request with the same content:
  • the terminal should then switch to compass mode, with the compass arrow pointing to the first waypoint.
  • the "capture area" type is not supported for guidance.
  • the center of the town is chosen as the reference point or, for POIs, the next possible coordinate
  • a coordinate located nearby is also assigned on the central side.
  • processing of the route should begin, i.e. there is no need to wait until the complete route arrives at the terminal.
  • the rough textual description of the route contains essential milestones of the route, which give the user an overview of the route to be traveled (e.g. travel from Bonn to Düsseldorf: A555 to Kreuzchen Süd, A4 todorfchen Ost, A 1 to funnelchen 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 individual waypoints have the following content:
  • the place name The place name is usually transmitted.
  • the motorway exits are coded with geo-codes.
  • the terminal can take the information about the next exit and the distance to it from the geo-code table and display it.
  • the corridor width together with the length of the air line to the next waypoint (calculated from the WGS-84 coordinates) defines a rectangular reference area. This reference area is used to identify incorrect journeys. If the customer leaves the reference area, the wrong journey is recognized. In addition, the reference area can be used to select route-relevant traffic information (see Chapter 3.2.1).
  • the number of intersections to the next maneuver point and the distance to the next intersection If it makes sense due to the course of the road, the number of intersections to the next maneuver point is transmitted. In connection with the next maneuvering point, this enables the customer to be given additional information (eg "6th intersection on the left").
  • the geographic coordinates are set depending on the type of intersection and the link flag set.
  • the meaning of the coordinates is defined in detail in the service specification of the provider.
  • the geographic coordinates are preferably assigned according to the following rules:
  • both waypoints contain an icon code of the star type.
  • the screen display should be in an icon.
  • the exit street of the 1st waypoint is to be combined with the entry street of the 2nd waypoint.
  • the appendix contains a suggestion for possible icon displays and suitable display behavior.
  • a change in the waypoint pointed to by the arrow should be explicitly acknowledged by the user.
  • the user can switch between the waypoints in compass mode.
  • the user should only be informed of an incorrect travel if the position has moved a long distance outside the corridor. This allows inaccuracies in the GPS to be taken into account or suppressed.
  • T-Traffic traffic reports preferably contain this street name (e.g. A555, B236). This makes it possible to filter out traffic reports that relate to roads that are on the route from the totality of the traffic reports available to the terminal (e.g. in the case of a circle-related or targeted Vl service, cell broadcast).
  • the terminal device receives a geo code that cannot be interpreted in the rough route description, this can be translated into plain text using the TINFO message TINFO_Code_Request_Message (see ADP TINFO).
  • Traffic announcements contain a redirection flag ("bypass flag"). If a traffic announcement is received on the route with the redirection flag set, the customer should be given the opportunity to make a new route request (combined with a travel time request) by displaying the traffic announcement (see also chapter 3.4).
  • the proposed use of the route information provided within the navigation service and the reference area in connection with the traffic information service is a pure terminal feature, which is made possible by the compatibility of the services shown.
  • Each service provider can freely assign numbers for individual POI types within the framework of the service provider POIs (e.g. petrol stations, ATMs).
  • POIs e.g. petrol stations, ATMs.
  • no numbering of service provider POIs is initially defined. If service provider POIs are to be used for the navigation service, then the full address of the desired POIs must be loaded from the central office by using an information service. This address can then be used for a destination request. The complete address information received from the control center should always be transferred to the service provider POl in order to avoid ambiguities (see also chapter 3.1.1.1).
  • the service specification and the associated ADP for the information services describe how a service provider POI can be loaded.
  • the request to the central office only receives the Route Request Message (no operator, see Fig. 5).
  • the information from the route message (at least the starting position) and from the dialog with the operator are to be merged centrally.
  • a timer-based synchronization mechanism must ensure 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 from the user.
  • a route description (a calculated route) is transferred to the head office (Travel_Time_Request_Message).
  • the route is described in the form of guidance points as with the orientation aid or the route guidance.
  • the head office estimates the travel time for this route based on the current traffic situation and transfers it to the end device (Travel_Time_Message).
  • the Travel_Time_Request_Message has the following content:
  • intersections are coded in the same way as when entering the address on the end device when the route request is described.
  • a transmitted telephone number is integrated by the head office as the destination address of the Travel_Time_Estimation. This field is to be filled in with the recipient's telephone number of the route in particular if the route is to be sent to a different terminal than the sending terminal.
  • the service-specific error messages are defined in the ADP.
  • Cross-service errors e.g. communication errors
  • Description of cross-service error handling are shown in the document "Description of cross-service error handling".
  • the data communication between the terminal and the control center is handled by the short message service available in GSM.
  • the cell broadcast is not required for the navigation services, so that only short message services SMS-MT (TS 21) and SMS-MO (TS 22) are required for handling the services.
  • SMS-MT short message services
  • SMS-MO SMS-MO
  • TS 11 The voice service (TS 11) must be supported in order to continue to enable operator requests.
  • the end device should have dead reckoning.
  • the end device may only send a localization pearl chain to the headquarters as the start address if a sufficiently precise localization is guaranteed.
  • the location accuracy with coupler navigation must be ⁇ 50 m on average.
  • the accuracy of dead reckoning navigation should not exceed 5% of the distance covered when driving slowly in the city (30 - 50 km / h) and 3% of the distance covered when driving at medium speed (70 - 90 km / h), 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.
  • 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. To make it easier to enter destinations, a notebook with at least 50 entries should exist in the end device, from which, among other things, the target description can also be adopted.
  • the waypoint memory should be designed dynamically so that no memory for the street name is kept free for waypoints that are transmitted without a street name.
  • 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 (in particular, switch to the next signpost point).
  • the orientation aid service is intended for devices that are preferably equipped with GPS without a digital map in the vehicle. It is therefore not possible, as is the case with navigation systems, at the maneuvering point of turning instructions such as. B. "turn right now” because the limited positioning accuracy does not allow the exact determination of the vehicle position (approx. 10m).
  • the driver must be made aware of upcoming maneuvers in good time. As a maneuver tip, it is not sufficient to simply state the maneuver to be carried out immediately (e.g. turn right), but the user must be informed in advance of the intersection topography at the maneuver point by means of an abstract representation.
  • the route guide symbol should be removed from the screen approx. 50m (without dead reckoning navigation 100m) after reaching the geographic coordinates of the route guide symbol (if the link flag is set, 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

Verfahren und Anordnung zur Information mobiler Teilnehmer
Durch das stetig wachsende Verkehresaufkommen 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.
Diese Problematik wird gelöst durch die Merkmale der Patentansprüche 1 und 2. Weitere mögliche Ausgestaltungsformen der Erfindung sind der nachfolgenden Beschreibung entnehmbar. 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 eigeschrä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 ausgestatten sind (im folgenden wird meist
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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 Engerät übertragen.
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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
• Zieleinαabe direkt am Endαerä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
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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 Routenαrobbeschreibuno zur Übersicht über die geplante Route durch den Benutzer,
• die berechnete Gesamtentfernunα zum Zielort und die Reisezeit zum Zielort unter Berücksichtigung der aktuellen Verkehrslage sowie
• eine Liste von Weαepunkten 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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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 derADP's dargestellt. Die Codierung derADP'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 Diensteanbietern 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
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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/ reine endgeräteseitige Funktion, bei derein Pfeil auf dem Homing Display in Richtung einer geographischen Koordinate zeigt (meist mit zusätzlicher Angabe der Entfernung in der Luftlinie)
ie Message Types mit ihren Inhalten werden wie folgt beschrieben:
BERICHTIGTES BLATT (REGEL 91) ISA/EP Information Element Type Length [bits] Content
Beschreibung des Feldinhaltes Festlegung Länge des Festlegung des Inhaltes zur z.B.:Protocol Discriminator oder des Feldtyps Feldes Nutzung der Dienste Position MF: in Anzahl Bits
Mandatory, Fix bei MF oder length OF
MV:
Mandatory, var. Variable length bei MV oder
OF: OV
Optional, Fix length
OV:
Optional, Variable length
BERICHTIGTES BLATT (REGEL 91) ISA/EP 2.2 Transportprotokoll - Handling
Zur Nutzung der Dienste Orientierungshilfe und Routenbewertung wird das Transportprotokoll wie folgt verwendet:
BERICHTIGTES BLATT (REGEL 91) ISA/EP
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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP 2.2.1 Dienstekennung
Application ID's sind eindeutige, von der Zentrale vergebene Dienstekennungen. Diese werden im Fe/oΑpplication 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 Flaα
• 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 Flaα = 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 Flaα 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 Flao = 1 (initiative).
BERICHTIGTES BLATT (REGEL 91) ISA/EP 2.3 Codierung von Text
Alle Text Elemente innerhalb der Navigationsdienste verwenden folgendes Format:
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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP
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):
BERICHTIGTES BLATT (REGEL 91) ISA/EP
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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP
BERICHTIGTES BLATT (REGEL 91) ISA/EP
BERICHTIGTES BLATT (REGEL 91) ISA/EP
BERICHTIGTES BLATT (REGEL 91) ISA/EP 3 Beschreibung der Dienste
3.1 Orientierungshilfe
Die Orientierungshilfe hat folgenden Basisablauf:
1. Routenanfrage (im Fehledall 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 oderz. 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 edolgen ü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:
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP • 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ätJ, 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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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- POl)
• 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)
BERICHTIGTES BLATT (REGEL 91) ISA/EP 2. Geo-Codes (alle anderen Felder werden zentraleseitig ignoriert)
3. Service-Provider-POl: die vollständige bei einer Adreßabfrage über Auskunftsdienste erhaltene Adreßinformation muß übertragen werden (Ausnahme: „additional information" und „country"). Service-Provider-POl 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 POl'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 Teilnehmemummer 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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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 lE'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ßstelien 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-POl
• nicht interpretierbare geographische Koordinaten, Geo-Codes oder Service-Provider-POl
• nicht interpretierbare Telefonortsvorwahl oder Postleitzahl
BERICHTIGTES BLATT (REGEL 91) ISA/EP • 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 lE'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 lE's ist im ADP zu den Navigationsdiensten detailliert beschrieben.
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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_Reqυest_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 lE'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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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 Gesamtentfernung zum Zielort (Routenlänoe) 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:
Bei der Aktualisierung der berechneten Ankunftszeit während der Fahrt sollten Pausen berücksichtigt werden (Erkennung durch Abschaltung des Gerätes).
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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överounkte. 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
BERICHTIGTES BLATT (REGEL 91) ISA/EP • 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, A 1 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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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 Entfernung dahin entnehmen und zur Anzeige bringen.
• eine abstrahierte Darstellung (Icons) 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 flaα= 1) darauf, daß 2 Manöver so dicht aufeinander folgen, daß sie zusammengefaßt Das link f,aα w'rcl'm
ISA/EP 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).
» σV'e 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 Korridorbreite. 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 routen relevanten 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:
BERICHTIGTES BLATT (REGEL 91) ISA/EP
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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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/Individuaiisierung 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-Verkehrsmelduπgen 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 Vl-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
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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-POl ü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-POl geladen werden kann.
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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 ErrorJMessage 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 ge wertet.
3.3.1 Digital Request
Die Anfrage an die Zentrale ertolgt nur die Route Request Message (kein Operator, s. Fig. 5).
Folgende Timer werden verwendet:
• TNA Va (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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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:
• TNA Va (wird mit Absenden der Route_Request__Message gestartet)
• TNA Vb (wird mit Empfang der Delivery Notification für die Route_Request_Message gestartet)
• TNA Vc (wird mit Empfang der Delivery 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 erioigen.
3.4 Routenbewertung
Bei der Routenbewertung wird eine Routenbeschreibung (einer berechneten 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).
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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 inteφretiert. 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:
• TNA Vd (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 lE'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.
BERICHTIGTES BLATT (REGEL 91) ISA/EP Soweit in diesem Dokument keine zusätzlichen Erläuterungen gegeben werden, sind dienstespezifische Fehlermeldungen folgendermaßen zu interpretieren:
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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
BERICHTIGTES BLATT (REGEL 91) ISA/EP
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 Lokalisierungsperlenkette an die Zentrale senden, wenn eine hinreichend genaue Lokalisierung garantiert ist. Um bei Einschaltung des
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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).
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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 Kreuzungstopogräphie 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).
BERICHTIGTES BLATT (REGEL 91) ISA/EP 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
BERICHTIGTES BLATT (REGEL 91) ISA/EP

Claims

Patentansprüche:
1. Verfahren zur Information mobiler Teilnehmer, wobei auf Anfrage und/oder automatisch Daten zwischen einer Zentraleinheit und einer mobilen Teilnehmereinheit übertragen werden.
2. Anordnung zur Information mobiler Teilnehmer, wobei mindestens eine Zentraleinheit sowie mindestens mehrere mobile Teilnehmereinheiten vorgesehen sind.
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
DE19651146A DE19651146A1 (de) 1996-12-10 1996-12-10 Verfahren und Anordnung zur Information mobiler Teilnehmer
DE19651146 1996-12-10
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 true EP0883872A1 (de) 1998-12-16
EP0883872B1 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
ATE454687T1 (de) * 1998-11-23 2010-01-15 Integrated Transp Information System zur momentan-verkehrsüberwachung
DE19906863A1 (de) * 1999-02-18 2000-10-19 Nokia Mobile Phones Ltd Verfahren zur Navigation eines Objekts
EP1106965B1 (de) * 1999-06-22 2007-08-22 Mitsubishi Denki Kabushiki Kaisha Mobilendgerät und server in einem navigationssystem
DE19937372A1 (de) 1999-08-12 2001-02-15 Bosch Gmbh Robert Verfahren zur Anforderung und zur Verarbeitung von Verkehrsmeldungen
DE19937370A1 (de) * 1999-08-12 2001-02-15 Bosch Gmbh Robert Verfahren zur Anforderung und zur Überarbeitung von Verkehrsmeldungen
WO2001029514A1 (en) 1999-10-19 2001-04-26 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
DE10105897A1 (de) 2001-02-09 2002-08-14 Bosch Gmbh Robert Verfahren zum Austauschen von Navigationsinformationen
DE10105898A1 (de) * 2001-02-09 2002-08-14 Bosch Gmbh Robert Verfahren zum Übergeben von Zielführungselementen, Fahrzeugnavigationsgerät und Zentrale
AU2321102A (en) 2001-03-12 2002-09-19 Magellan Dis, Inc. Off-board navigation system with personalized navigation database
US7853404B2 (en) 2001-04-03 2010-12-14 Mitac International Corporation Vehicle docking station for portable handheld computing device
DE10128409B4 (de) * 2001-06-12 2007-05-31 Harman Becker Automotive Systems Gmbh Navigationssystem
AU2003223090A1 (en) 2002-04-30 2003-11-17 Telmap Ltd. Template-based map distribution system
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
KR20060119739A (ko) * 2005-05-18 2006-11-24 엘지전자 주식회사 구간 통과시간에 대한 예측정보를 제공하고 이를 이용하는방법 및 장치
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
KR20060119746A (ko) 2005-05-18 2006-11-24 엘지전자 주식회사 교통상태에 대한 정보를 제공하고 이를 이용하는 방법 및장치
EP2216762B1 (de) * 2005-05-18 2011-05-11 Lg Electronics Inc. Bereitstellung von Verkehrsinformation in Bezug auf die Vorhersage eines Staustatus und Verwendung davon
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
WO2014045146A1 (en) 2012-09-23 2014-03-27 Telmap Ltd 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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9826396A1 *

Also Published As

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

Similar Documents

Publication Publication Date Title
EP0883872B1 (de) Verfahren und anordnung zur information mobiler teilnehmer
EP0883871B1 (de) Verfahren und anordnung zur verkehrsinformation
EP1186865B1 (de) Verfahren zur Bestimmung einer Fahrtroute eines Fahrzeugs
EP1206766B1 (de) Ortsbezogene wap-staukarte durch verknüpfung von kartenausschnitten in einer verkehrsinformationszentrale
EP1198696B1 (de) Verfahren und vorrichtung zur übermittlung von navigations-informationen von einer datenzentrale an ein fahrzeug-basiertes navigationssystem
DE69925779T2 (de) Routensuchvorrichtung
EP1255964B1 (de) Navigationsverfahren mit dynamischer zielauswahl und navigationsgerät
EP1062481B1 (de) Verfahren zur ausgabe von verkehrsinformationen
DE102010006702A1 (de) Verfahren und Vorrichtung zur Berechnung alternativer Routen in einem Navigationssystem
EP1360458B1 (de) Verfahren zum austauschen von navigationsinformationen
EP0979987A2 (de) Verfahren zum Bestimmen einer Route von einem Ausgangspunkt zu einem Zielpunkt
WO2007062899A1 (de) Vorrichtung und verfahren zur ausgabe von zielführungsinformationen eines navigationssystems
DE10354218A1 (de) Verfahren zur Auswahl und Aufbereitung von Verkehrsinformationen
EP1342221A1 (de) Verfahren zum automatischen löschen einer verkehrsmeldung
DE10009727A1 (de) Navigationseinheit für ein Kraftfahrzeug
DE102015200081A1 (de) Bereitstellen von Navigationshinweisen in einem Fahrzeug
EP2205942B1 (de) Navigationssystem und verfahren zur routenermittlung
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
EP1714261B1 (de) Verfahren zur decodierung, codierung und übertragung von fahrtroutendaten und navigationsvorrichtung
DE19861486B4 (de) Datenvorrichtung für ein Kraftfahrzeug
WO2004094953A1 (de) Verfahren zur fahrroutenplanung

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