EP0883872A1

EP0883872A1 - Information method and device for mobile subscribers

Info

Publication number: EP0883872A1
Application number: EP97952715A
Authority: EP
Inventors: Bernd Günther; Henning Weise
Original assignee: Deutsche Telekom AG; DeTeMobil Deutsche Telekom Mobilnet GmbH
Current assignee: Telekom Deutschland GmbH
Priority date: 1996-12-10
Filing date: 1997-12-10
Publication date: 1998-12-16
Anticipated expiration: 2017-12-10
Also published as: DE19651146A1; AU5650798A; EP0883872B1; ATE217434T1; WO1998026396A1; DE59707219D1

Abstract

Disclosed is an information method for mobile subscribers, whereby, on request and/or automatically, data are transmitted between a central control unit and a mobile subscriber unit. Also disclosed is an information device for mobile subscribers, encompassing at least one central control unit and a plurality of mobile subscriber units.

Description

Method and arrangement for informing mobile participants

Due to the constantly growing volume of traffic, the need for high-quality systems for traffic information and traffic management is becoming ever more urgent. However, this gives rise to the problems of how the user can always be provided with up-to-date information which at the same time offers him a high level of user comfort.

This problem is solved by the features of claims 1 and 2. Further possible embodiments of the invention can be found in the following description. In particular, 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. The data transfers can too

Information acquisition purposes and / or for information transmission purposes as well as for updating information.

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

CORRECTED SHEET (RULE 91) ISA / EP a system with GPS is described as an example). It is therefore generally not possible to take turn instructions such as e.g. at a specific location (maneuver point). B. "now turn right" because, due to the limited positioning accuracy, it is often not possible to determine the exact position of the vehicle (especially with GPS approx. 10m).

Therefore, the driver must be made aware of upcoming maneuvers in good time. As a maneuver hint, it is not sufficient to simply specify the maneuver to be carried out immediately (e.g. "turn right"), but the user must be informed of the intersection topography at the maneuver point by means of an abstract representation (signposts) (see Fig. 1). The appendix contains a proposal for such signage symbols.

When generating the route, the central unit (T-Traffic control center) 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. In the route evaluation, 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.

CORRECTED SHEET (RULE 91) ISA / EP 1.1 Brief description of orientation aid

The orientation guide has the following basic sequence:

1. Route request to the head office

2. Route calculation and preparation, transmission of the complete route to the end device

3. Processing the route in the terminal

see Fig. 2

The customer asks for the route

• his starting position (usually the current position),

• the target position and

• of optimization criteria (e.g. shortest or fastest route)

at the headquarters.

In addition, 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).

The route request to the head office can be made via

• Entry of destination directly on the end device: the customer enters the necessary information for route calculation on the ground floor or retrieves it from an existing destination memory in the end device.

• Telephony: the control center (operator) determines the above information for route calculation in dialog with the customer

CORRECTED SHEET (RULE 91) ISA / EP At the head office, 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. When the route is transferred to the vehicle, the request for the head office ends.

The route information contains

• a textual route description for the user to provide an overview of the planned route,

• the calculated total distance to the destination and the travel time to the destination taking into account the current traffic situation as well

• a list of route points with associated icons for navigation while driving.

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

1. Switch to a compass mode in which the direction and distance to the next waypoint on the route is shown on the screen, or

2. offer the customer the opportunity to make a new route request.

CORRECTED SHEET (RULE 91) ISA / EP 1.2 Brief description of route evaluation

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). For this purpose, 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).

1.3 Overview of the documents

In this document, 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.

Cross-service specifications required to understand this specification:

• Internal services - terminal-side description of the service flow

The following documents are also required to understand this specification:

• Requirements for the logical structure of a localization pearl chain for point localization

• Description of cross-service error handling

CORRECTED SHEET (RULE 91) ISA / EP The message types listed can be found in the documents:

• Application Data Protocol Navigation Services

• ADP Message Types of General Interest

Guidelines for the coding of special data types can be found in the following documents:

• Address coding

• Coding of text and transparent data

• Coding of Extended Location Message

• Area and location coding

• Coding of absolute time

The transport frame for the message types is defined in:

• Transport Protocol

Data protection and data security procedures are defined in the documents "Conditional Access and Security (CAS)":

• CAS Protocol

• ADP key management

• Key Management and Security service description

The numbering of telegram types corresponds to the document:

Message Type Numbering

The current version numbers of the listed documents are passed on to our partners with every change.

CORRECTED SHEET (RULE 91) ISA / EP 2 General processes

2.1 Definitions of terms

The following terms are clearly defined for this document. • active acknowledgment active confirmation that the user has received a message

ADP Application Data Protocol • Geo-Code Clear definition and identification of a geographical object using coordinates

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)

The message types with their contents are described as follows:

CORRECTED SHEET (RULE 91) ISA / EP Information Element Type Length [bits] Content

Description of the field content Definition Length of the definition of the content for e.g. Protocol Discriminator or the field type field Use of the services Position MF: in number of bits

Mandatory, fix for MF or length OF

MV:

Mandatory, var. Variable length for MV or

OF: OV

Optional, fix length

OV:

Optional, variable length

CORRECTED SHEET (RULE 91) ISA / EP 2.2 Transport protocol - handling

The transport protocol is used as follows to use the orientation aid and route evaluation services:

CORRECTED SHEET (RULE 91) ISA / EP

The framework supports the sending of several short messages.

All functions, procedures and processes defined in the CAS Protocol document must be supported on the terminal device.

CORRECTED SHEET (RULE 91) ISA / EP 2.2.1 Service identifier

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.

The following application IDs are assigned:

Application ID 31 h Orientation guide: digital request

Application ID 32h Orientation guide: Operator request

Application ID 33 h route evaluation

2.2.2 Assignment of answers to an inquiry

Transactions are assigned using the two fields:

• Flaα initiative

• Context number

in the transport layer

The traffic telematics terminal assigns a freely selectable context number (restriction: MSB = 1) on behalf of the head office. Initiative Flaα = 1 (initiative) marks the first transaction in the chain, the order.

If there is a response to the traffic telematics terminal, its context number is set again. The Flaα initiative is set to 0 for all associated answers so that the client can clearly assign the answer to the order placed.

If route messages are not initiated by the terminal, the control center assigns a freely selectable context number (restriction: MSB = 0). The initiative Flao = 1 (initiative).

CORRECTED SHEET (RULE 91) ISA / EP 2.3 Coding of text

All text elements within the navigation services use the following format:

2.4 Coding of the communication header of the ADPs used

The values for Protocol Discriminator and Message Type can be found in the document "Message Type Numbering". The bulk flag is always set to 0.

2.5 Time control of the communication processes

The timers relevant for the navigation services are listed below.

CORRECTED SHEET (RULE 91) ISA / EP

2.6 Management of service addresses

2.6.1 Orientation guide

The storage and updating of the service addresses in the terminal is explained in the telematics service specification internal services.

For the orientation aid service, the terminal must support the full functionality of the internal services with regard to address management.

2.6.2 Route evaluation

For the route evaluation service, the terminal must support the full functionality of the internal services with regard to address management.

2.7 Service parameters

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.

2.7.1 Processes

32-bit switches are available for parameterizing the processes, which are assigned as follows (0: not supported by the control center, 1: supported by the control center):

CORRECTED SHEET (RULE 91) ISA / EP

2.7.2 Functions

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.

CORRECTED SHEET (RULE 91) ISA / EP

CORRECTED SHEET (RULE 91) ISA / EP 3 Description of the services

3.1 Orientation guide

The orientation guide has the following basic sequence:

1. Route request (in the event of an error, an error message follows)

2. Route calculation and preparation in the control center / transmission to the end device (route message)

3. Processing the route in the terminal

In addition, it will be possible in the future for the customer to 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.

3.1.1 Route request

The route request to the headquarters can be done via

• Destination input directly on the end device: the customer enters the necessary information for route calculation on the ground floor (especially address information)

• Operator (voice connection): the operator determines the above information for route calculation in dialog with the customer

As part of the route request, the following information must be provided or automatically generated by the end device:

CORRECTED SHEET (RULE 91) ISA / EP Starting point / address (usually generated automatically by the end device: current position): localization pearl string or postal address description (mandatory)

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.

CORRECTED SHEET (RULE 91) ISA / EP • The criteria for route calculation (the support of the individual criteria can be parameterized, see chapter see chapter 2.7:

- fastest route taking into account the current traffic situation (recommended as default for the end device),

- fastest route without taking into account the current traffic situation,

- shortest route (without taking into account the current traffic situation),

- User-defined (based on criteria stored in the head office; the criteria are stored via Customer Care, not via the device J, as well as the additional options

- preference for highways,

- minimization of local passages,

- no roads with tolls

• as well as up to 6 additional addresses which, depending on the customer's choice, must either be approached (via points) or not permitted (avoid points): geographic coordinates and / or postal address description (the number of possible addresses can be parameterized, see chapter 2.7)). With via points, the addresses are traversed in the specified order, i.e. no traveling salesman problem is solved.

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).

In the Route_Request__Message, the following additional user-specific information is transmitted to the headquarters:

• User phone number (optional):

This field must then be filled in with the phone number of the recipient of the route if the route request is initiated externally.

CORRECTED SHEET (RULE 91) ISA / EP Information about the end device (must be transmitted, the information about the location is evaluated)

as well as information about the vehicle in future service versions.

CORRECTED SHEET (RULE 91) ISA / EP 3.1.1.1 Entering a destination on the end device

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:

• Storage of an address received within a route message (including geographic coordinates)

• Storage of an address received by an information service (service provider POl)

• 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.

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.

If the address or individual details are not clear, the error message is transmitted to the vehicle. This can contain selection lists. The support of the error message depends on the service provider.

The following address requests are accepted:

1. Geographic coordinates (all other specified fields are ignored at the central site)

CORRECTED SHEET (RULE 91) ISA / EP 2. Geo-Codes (all other fields are ignored at the central site)

3. 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.

4. 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).

5. 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.

6. 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.

7. Choice of location only (default see below)

8. Complete telephone number: Area code and participant number must be handed over. The country code is optional.

The following options are permitted for the location selection:

• only place name (default: center of the place)

• Postcode only (default: center of the postcode district)

• Telephone area code only (default: center of the area code area)

• Place name and telephone area code or post code

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.

CORRECTED SHEET (RULE 91) ISA / EP The "Additional Information" and the "Country" field are always ignored in the address request. If the "State" field is empty, Germany (D) is taken as the country.

The following requirements apply to the individual IEs:

• Geographic coordinates according to the digital map in the headquarters. If coordinates are only given, the start and finish may differ from the customer's request due to the inaccuracies.

• 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.

• Street names: Street types BAB, Bundesstraße, Landstraße, Staatsstraße, Kreisstraße, Europastraße with number and any additional designation (a, b, n, r), z. B. B55n (see ADP).

• Street names according to the official location-dependent street directory.

• Postcodes according to the postcode directory of the Deutsche Bundespost.

• 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.

• State according to the list of international license plates.

• Telephone number: Area code only (country code is Kannfeld, default: Germany).

In the following cases, an error message "start / destination / additional address not identified" follows (the corresponding bit in the error message is set):

• simultaneous indication of geographic coordinates and geo-code

• simultaneous specification of geographic coordinates and service provider POl

• Geographical coordinates, geo codes or service provider POIs that cannot be interpreted

• Telephone area code or postcode that cannot be interpreted

CORRECTED SHEET (RULE 91) ISA / EP • Uninterpreted full telephone number

In addition, the control center can set the "start / desination / additional address ambiguous" bit for the address concerned. In this case, 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).

If the address information regarding the choice of location, a MAP-POI, or a street name is not clear, 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 ):

• Place name: selection list with max. 5 alternatives

• Street name: selection list with max. 5 alternatives

• MAP POI: selection list with max. 5 alternatives

The coding of the individual I's is described in detail in the ADP for the navigation services.

CORRECTED SHEET (RULE 91) ISA / EP 3.1.1.2 Request via operator (Speech Connection)

There are two basic cases when requesting an operator:

1. With the operator request, a Route_Reqυest_Message is sent that contains at least the start position.

2. 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 first case of an operator request with transmission of a Route_Message is described below. This should be viewed as a separate service that receives a separate service identifier.

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.

The possible processes for establishing the voice connection are shown in Section 3.3.2. Receiving an error message interrupts the establishment of the voice connection if it has not yet been established (with the timer-based procedure).

There are preferably the following additional requirements for the request:

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.

CORRECTED SHEET (RULE 91) ISA / EP During the voice connection, the operator in dialogue with the customer determines the missing information until there are clear addresses for the destination and possible via and avoid points.

After the route has been calculated, the control center then sends the route (Route_Message) to the vehicle.

3.1.2 Route calculation and preparation

In the control center, 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.

When calculating the route and preparing the route, the information on the location that is transmitted when the route is requested is taken into account at the central site. A distinction is first made between terminal devices with pure GPS and terminal devices with additional dead reckoning.

For end devices with pure GPS, certain road classes or even individual roads are excluded for route calculation. This can lead to detours. Basically, a positioning accuracy of approx. 100 m is assumed for these end devices.

In addition, a more detailed rough route description is generated for devices with pure GPS.

After consultation with the manufacturers, 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.

CORRECTED SHEET (RULE 91) ISA / EP 3.1.3 Processing the route in the end device

The Route_Message can contain the following information:

• A textual rough route description to provide an overview of the planned route by the user (route briefing)

• The calculated travel time to the destination and the total distance to the destination (route length) taking into account the current traffic situation.

• A list of waypoints with associated icons for navigation while driving

There will be special cases where the route description remains empty or no waypoints are included.

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).

CORRECTED SHEET (RULE 91) ISA / EP In addition, it is recommended to inform the user of this when the actual travel time of the transferred, previously completed travel time of more than 30% and at least 10 minutes is exceeded and to offer him the option of a new route request.

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 outline of the guidance is as follows:

1. The rough textual route description is displayed and acknowledged by the customer.

2. An arrow points towards the first waypoint (compass mode). The distance (beeline) to this waypoint is also shown.

3. When the waypoint is reached, it is marked as passed and the next waypoint is displayed with the current distance to this waypoint (route).

4. After passing the last waypoint this will be shown to the customer. At the same time, an arrow points in the direction of the destination (with distance as the crow flies; compass mode).

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.

The 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:

• Geographic coordinate

• if POI: POI type and POI name

CORRECTED SHEET (RULE 91) ISA / EP • Street description (not for map POIs)

• Place name

If the first waypoint is not identical to the start address, this is also communicated by specifying the type of the start waypoint. 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.

If an exact geographical coordinate cannot be assigned to the destination address on the digital map in the head office, the assignment to a coordinate is carried out on the central side according to the following principle (specified in the type of the destination address):

1. The center of the town is chosen as the reference point or, for POIs, the next possible coordinate

2. If the point cannot be reached (eg in a pedestrian zone), a coordinate located nearby is also assigned on the central side.

As soon as the telegram with the 1st waypoint is received, 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 Kreuz Köln Süd, A4 to Kreuz Köln Ost, A 1 to Kreuz Köln Nord, A57 to Kreuz Kaarst). The milestones are transmitted either as text or as geo-code. A mix of text and geo-codes is possible.

CORRECTED SHEET (RULE 91) ISA / EP 3.1.3.1 Contents of the waypoints

The individual waypoints have the following content:

• geographic coordinate of the waypoint (WGS84)

• optional the official street name: for the street into which you want to turn (usually specified)

• The place name: The place name is usually transmitted.

• a flag, which is set when the route runs to the next maneuver point on highways or highway-like roads. The flag set indicates that the next maneuver should be signaled early.

If the flag is set, 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.

• an abstract representation (icons) of the intersection. There are 4 different types of crossings

- no intersection (the change of a street or place name is transferred)

- Star-shaped intersection with up to 8 possible entrances / exits

- Roundabout with up to 8 entrances / exits

- Motorway exits with up to four departure options per direction of departure. All representations refer to the direction of travel according to the route description. The respective exit road is marked. A turning maneuver is marked in the star-shaped intersection as a star with the code entry road = exit road. The star and circle intersection types can be displayed as a "moving map". This can include information about the angle between the direction of travel (= entrance road), exit road and towards the north.

• a note (if link flaα = 1) that 2 maneuvers follow each other so closely that they are combined ^{The link f, aα w} ' ^rcl ' ^m

ISA / EP first of the two waypoints to be combined. Two consecutive waypoints with the link flag set are not permitted.

»The estimated travel time to the next waypoint (will not be transmitted if the link flag is set in the same waypoint).

»ΣV ^' e path length to the following waypoint (is only transmitted if the link flag is set in the same waypoint).

> an optional action note that contains supporting information on the maneuver in text form (e.g. towards Cologne, attention: tight curve).

> optional specification of a corridor width. 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).

Optionally, 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:

CORRECTED SHEET (RULE 91) ISA / EP

If the link flag is set, the intersection type of the first waypoint is decisive for the interpretation rule.

If the link flag is set and the star intersection type, 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.

If the type of intersection when the link flag is of the roundabout or motorway exit type, then no icon coding is transmitted in the second waypoint, but a second geographical coordinate is given to support the icon display in the terminal (see above).

The appendix contains a suggestion for possible icon displays and suitable display behavior.

CORRECTED SHEET (RULE 91) ISA / EP False drives

If incorrect journeys are recognized because the reference area spanned by the corridor width has been left, the user must be informed. The terminal should now give the user the opportunity to start a new route request related to the same destination. You should also switch to compass mode, with the arrow pointing to the nearest waypoint.

A change in the waypoint pointed to by the arrow (because another waypoint becomes the next waypoint) should be explicitly acknowledged by the user. Ideally, 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.

3.2 Connection to other services

3.2.1 Traffic information service

The IE "Street Identification", which is used in the services traffic information and navigation / orientation aid, allows new traffic disturbances occurring during the journey to be taken into account in relation to the current route. Further clarification / individualization takes place via the evaluation of the geo codes relative to current position or to the waypoints and the associated corridor information.

The street names used for the navigation services and in the traffic information services are identical. 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).

In addition, by using the reference area spanned by the wrong-way corridor and the waypoints, it is possible to eliminate the traffic reports, which are not

CORRECTED SHEET (RULE 91) ISA / EP lying on the route. This is done by only selecting traffic reports for which the geo-codes are in the reference area in addition to the street name (see Fig. 4). The rectangular side spanned by the distance of the waypoints should be extended by 1 km on both sides to ensure that the intersection of the corridors leads to a selection of all traffic information relating to the route.

If, in exceptional cases, 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.

3.2.2 Information service

Each service provider can freely assign numbers for individual POI types within the framework of the service provider POIs (e.g. petrol stations, ATMs).

In the context of navigation services, 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.

CORRECTED SHEET (RULE 91) ISA / EP 3.3 Communication processes

All bidirectional communication processes are shown in the ADP of the navigation services.

An inquiry is considered completed by the head office if the desired response (Route_Message, Travel_Time_Estimation) or the ErrorJMessage has been sent. If the Error_Message contains a selection list, with the help of which the customer can specify his request, then a subsequent request with a unique address will still be evaluated as a completely new process.

3.3.1 Digital request

The request to the central office only receives the Route Request Message (no operator, see Fig. 5).

The following timers are used:

• TNA Va (starts with receipt of the delivery notification)

When the route message or the error message is sent, the process is ended centrally.

3.3.2 Operator-assisted requests

An operator request within the meaning of this specification is always started with a route request message. Operator requests without a Route Request Message (see Chapter 3.1.1.2) are to be treated like requests initiated by third parties.

In the case of an operator request with a route message, 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.

CORRECTED SHEET (RULE 91) ISA / EP 3.3.2.1 Timer-based (MO)

After a timer has expired, the terminal sets up the voice connection to the operator (FIG. 6).

The following timers are used:

• TNA Va (is started by sending the Route_Request__Message)

• TNA Vb (starts with receipt of the delivery notification for the Route_Request_Message)

• TNA Vc (starts with receipt of the delivery notification for the Route_Request_Message)

3.3.3 Route messages initiated by others

In addition to the communication processes shown, the terminal must be able to process Route_Messages that it did not initiate (FIG. 7). Such 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.

3.4 Route evaluation

When evaluating the route, 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.

CORRECTED SHEET (RULE 91) ISA / EP The process is as follows (see Fig. 8, see also ADP navigation services):

The Travel_Time_Request_Message has the following content:

• number of route guidance points for route description,

• Geographic coordinates and / or official street name / street name, intersections are coded in the same way as when entering the address on the end device when the route request is described.

• Rough cardinal direction, which is driven after reaching the waypoint (not at the destination waypoint).

• Optional user-specific information (telephone number; details about the end device are ignored). 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 following timers are used:

• TNA Vd (started with sending the Travel Time Request Message)

When the Travel Time Message or the Error Message is sent, the process is ended centrally.

3.5 Error handling

The service-specific error messages are defined in the ADP. Cross-service errors (e.g. communication errors) are shown in the document "Description of cross-service error handling".

CORRECTED SHEET (RULE 91) ISA / EP If no additional explanations are given in this document, service-specific error messages are to be interpreted as follows:

CORRECTED SHEET (RULE 91) ISA / EP Error Type Explanation / meaning input error s. Cross-Service Error Handling Document

Server timed out p. Cross-Service Error Handling Document

Server error s. Cross-Service Error Handling Document

Server overloaded s. Document "Description of cross-service error handling" on treatment If a quick response to the request is not possible due to the current overload of the server, this error message will be sent. The calculated route will be forwarded at a later time. Start not identified see chapter 3.1.1.1 destination not identified see chapter 3.1.1.1 start ambiguous see chapter 3.1.1.1 destination ambiguous see chapter 3.1.1.1 route not identified It was not possible to calculate a route based on the criteria passed in. further requests not possible see document "Description of the cross-service Error handling "additional destination 1 not identified s. Chapter 3.1.1.1 additional destination 2 not identified s. Chapter 3.1.1.1 additional destination 3 not identified s. Chapter 3.1.1.1 additional destination 4 not identified s. Chapter 3.1.1.1 additional destination 5 not identified s. Chapter 3.1.1.1

CORRECTED SHEET (RULE 91) ISA / EP

4 Requirements for the end devices

4.1 Communication

The data communication between the terminal and the control center is handled by the short message service available in GSM. In contrast to other VT services, 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. The voice service (TS 11) must be supported in order to continue to enable operator requests.

4.2 Location

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. To switch on the

CORRECTED SHEET (RULE 91) ISA / EP To enable a quick initialization or target request to the terminal, the last track before switching off should always be stored in the device.

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.

4.3 MMI

The end device must have a graphic display with the possibility of graphic and text display, as well as a convenient input option. In addition, a voice output of the maneuvers is desirable.

Recommendation: dot matrix min 128x112 min. 4 lines, min. 20 characters / line

4.4 Storage

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.

If the end device cannot save all waypoints due to a lack of storage space, all waypoints that could no longer be saved should be discarded except for the destination address. The customer must be informed that waypoints have been discarded. After reaching the last saved waypoint of the route is in the

CORRECTED SHEET (RULE 91) ISA / EP Switch compass mode to the target. It is recommended to also give the customer the opportunity to make a new route request to the destination in good time before reaching the last saved waypoint.

4.5 Other requirements

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).

CORRECTED SHEET (RULE 91) ISA / EP 4.6 Suggestions for signage symbols

As already explained in the introduction, 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).

Therefore, 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.

In the case of maneuvers or complex intersections that follow one after the other, these must be presented to the user at the same time (i.e. in a symbol), since this corresponds to his perception of the maneuver in reality and his ability to react. The combination of two icons into one symbol is indicated by the link flag.

The following suggestions are made for the latest time that the signpost symbol is displayed (the display should be accompanied by an acoustic warning):

with dead reckoning without dead reckoning

Motorway: 1,500 m 1,500 m

Country road 500 m 500 m

City (without city motorways) 50 m 100 m

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).

CORRECTED SHEET (RULE 91) ISA / EP The proposed routing symbolism is based on four types of intersection, three of which are coded as basic types and transmitted to the vehicle:

1. Star-shaped junction

2nd circular anchor (roundabout)

3. Autobahn exit / Füßler (fork)

By using the link flag in the "junction" type, the additional type

4. Double crossing / offset

shown.

In the following, suggestions for the screen display of the individual intersection types are made. The display is based on a display with at least 128 x 112 pixels.

In addition, the distance to the first maneuvering point and the name of the street into which you should turn should be displayed.

1. Star-shaped junction. Fig.9a

2. Roundabout s. Fig. 9b

3. Autobahn exit Füßler (fork) s. Fig. 9c

4. Double crossing / offset (from junction with link flag)

Straight ahead intersections s. Fig. 9d

oblique offset s. Fig. 9e

right-angled offset s. Fig. 9f

CORRECTED SHEET (RULE 91) ISA / EP

Claims

Claims:

1. A method for informing mobile subscribers, data being transmitted between a central unit and a mobile subscriber unit on request and / or automatically.

2. Arrangement for the information of mobile subscribers, at least one central unit and at least several mobile subscriber units being provided.