EP0883871B1 - Method and device of traffic information - Google Patents

Abstract

Disclosed is a traffic information method, whereby, on request and/or automatically, data are transmitted between a central control unit and a mobile subscriber unit. Also disclosed is a traffic information system, according to which at least one central control unit and at least a plurality of mobile subscriber units are provided.

Description

The invention relates to a method and an arrangement for traffic information according to the Preamble of the independent claims.

Due to the steadily growing volume of traffic, the need for high quality Systems for traffic information and traffic management are becoming increasingly urgent. Surrender However, the problems arise as the user always has current information available can be provided, which also offer a high level of user comfort.

WO-A-96/11381 relates to a device for guiding people. The facility comprises a navigation unit which has a receiving device for wirelessly transmitted Has information for recognizing the current geographic position, a Communication unit, which is an input unit in particular for entering a target position and an output unit, in particular for output of route guidance information. Furthermore, a central computer for route planning is provided, which has a memory has at least one digitized road map and that with the navigation unit is technically connectable via the communication unit. The computer transmits the calculated route information to the navigation unit. The possibility of one Traffic information is only addressed in passing.

EP 0 317 181 relates primarily to a route planning and destination guidance system, with a Computer center is provided, in which, among other things, information about the current Traffic situation can be saved. This traffic data is used for route planning and guidance used. However, this document contains no information that a Independent traffic information system for the individual information of the Road user is present.

The object of the invention is to provide a method and an arrangement for To propose traffic information for mobile participants that is always up-to-date for the participant Provides information and at the same time offers a high level of user comfort.

This object is achieved by the features of the independent claims. Further possible embodiments of the invention are the dependent ones Claims specified.

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 Device-side queries that are carried out device-based or person-based can. The data transfers can be for information acquisition purposes and / or Information transfer purposes as well as for updating information carried out become.

The present traffic information service can be used in particular in the Service variants "interactive VINFO" (via targeted SMS short messages and / or Telephony) and "collective VINFO" (via SMS short message broadcasting CB).

The interactive traffic information service (VINFO) enables the customer to use his customized retrieval of current and reliable requirements Traffic information. The customer can get traffic information in particular to a geometric selection area or explicitly to a route Request. The traffic information is preferably in a central office customized filtering. The traffic information is then sent via SMS short messages targeted transfer to the end device (output via display) or in an audio text system imported (for audio output via a telephony voice channel e.g. in GSM).

The collective VINFO service is functionally and in terms of content the same as the interactive VINFO service, however, the filtering takes place in the terminal. The output of Traffic information via the audio text system is not supported.

Traffic information can be collected, processed and from different sources individually compiled for the individual customer.

In addition to official traffic information providers such as traffic information centers and State registration offices can use private suppliers (mobile traffic jams, etc.). Additionally or alternatively, a stationary registration system on motorways (BAB) be built with the help of sensors, the traffic density and traffic flow certainly. In addition, mobile traffic data acquisition can be carried out via the vehicles of the VINFO customers provide the most comprehensive and detailed traffic information. Next The BAB network thus also receives precise information about the subordinate Road network available.

The data stocks held at the head office are thus quickly retrieved Is a multiple of the traffic data available today. The task of the VINFO service It is therefore only with the help of suitable filter mechanisms that the customer is To provide traffic information that affects him directly. The "showering of the Customers with traffic information "are thus avoided.

2.1 Overview of the services offered

• Umkreisbezogene VINFO (vom EG parametriert)
• Umkreisbezogene VINFO (von Zentrale parametriert)
• Kreissegmentbezogene VINFO
• Zielgerichtete VINFO
• Streckenbezogene VINFO

Basically, information about a geometric area or explicitly about a route can be queried. The following service requests are described in this document:

• Radius-related VINFO (parameterized by the EC)
• Radius-related VINFO (parameterized by the control center)
• Circle segment related VINFO
• Targeted VINFO
• Route-related VINFO

A basic description of service requests can be found on the following pages. A detailed description of the processes is the provider-specific service specifications refer to.

The following two sections provide an overview of the different types of service.

2.1.1 Supported services alternative 1

2.1.2 Supported services alternative 2

In this specification, only those in the "Service level" column are mentioned names used.

In addition, the service variant VINFO related to the compass direction can be offered, which is implemented as a special case of radius-related VINFO (parameterized by the control center) and is described in Chap. 2.1.4 and 4.3 is described.

The customer should have the choice of all VINFO variants, one-off traffic information to request or to be provided with automatic updates of traffic information (see Cape. 4.1).

The traffic information and the VINFO variants are described in the following chapters briefly described. A detailed description of the interactive service variants can be found Chapter 3. The collective service variants are described in Chap. 5 described.

2.1.3 Traffic information

Messages about the traffic situation in the selection area selected by the customer provided as traffic information (TINFO).

All traffic information consists of the event itself (eg "5 km traffic jam") and the location of the event (eg "on the A 3 Cologne to Frankfurt between AS Köln-Königsforst and AS Lohmar"). Optionally, the cause (e.g. "due to accident") and information ("Please drive on the right lane"), duration of the event (e.g. "for 2 h"), diversion notice (e.g. "Please use the U 45 "from the Köln-Königsforst AS), as well as additional location information (e.g." Start of traffic jam 3 km to the Köln-Königsforst AS ").

The information available at the head office on a traffic disruption (cause (s), note (s), recommended diversion (s) etc.) will be delivered to the customer in full.

• Priorität 4 -> Klasse 4: Warnmeldungen (z. B. Geisterfahrer, verlorene Ladung)
• Priorität 3 -> Klasse 3: Verkehrsinfos mit Fernwirkung
• Priorität 2 -> Klasse 2: Verkehrsinfos mit Mittelwirkung
• Priorität 1 -> Klasse 1: Verkehrsinfos mit Nahwirkung

The traffic information is encoded using event codes / geo codes. AL-C event codes and TMC location codes are not supported by T-Mobil as part of this protocol version.
All traffic information is divided into four classes based on priority (see section 4.7.1):

• Priority 4 -> Class 4: Warning messages (e.g. ghost driver, lost cargo)
• Priority 3 -> Class 3: Traffic information with long-range effects
• Priority 2 -> Class 2: Traffic information with a medium impact
• Priority 1 -> Class 1: Local traffic information

Each traffic information is assigned to a class by the traffic department at the headquarters. Traffic information with long-range effects is typically larger traffic jams on motorway and federal highways. Traffic information with a medium impact is typically medium traffic jams on the federal and state level State roads. Local traffic information is typically small traffic jams that occur impact only locally. So z. B. A 1 km long traffic jam on a class 1 motorway assigned if this only has local effects.

Warning messages have the highest priority 4 and are to be displayed by the end device immediately . Other services (such as the navigation service) must be interrupted when a warning message arrives.

In the interactive VINFO service, priorities 1 to 3 are not evaluated by the terminal. Traffic information of these classes will be on the central side according to the selected VINFO variant filtered (see chap. 2.1.4 to 2.1.6). With the VINFO service via CB, all priorities evaluated (see Chapter 5).

When making a VINFO request, the customer can choose whether to only receive traffic information on the long-distance network or on all roads . The long-distance route network consists of the BAB, the recommended detour routes and the federal highways. The default setting is the distance network. This prevents the customer from being overwhelmed with irrelevant traffic information and high communication costs are avoided, especially with audiotext.

If the customer explicitly chooses "Traffic information on all roads", he also receives traffic information via the subordinate road network. The exception to this filter method is the route-related VINFO variant, in which the customer always receives all traffic information for the selected route.

If the customer chooses Display as the output medium, the traffic information is sent via SMS Transfer terminal. The traffic information should be stored in a non-volatile list in the terminal become. This means that the traffic information is still present after brief breaks in the journey.

Traffic information should be deleted after the maximum storage period (vig_t112, see Chapter 3.3). The expiry time of traffic information with the VINFO-CB service is not identical to this storage period.

• Sortierung nach Aktualität (detaillierte Beschreibung siehe Kap. 4.9)
• Sortierung nach Fahrtrichtung/AbstandEs sollte eine Sortierung der Liste nach in Fahrtrichtung nächstgelegenen Verkehrsinformationen möglich sein. Durch diese Sortierung werden dem Kunden die Verkehrsinfos in der Reihenfolge angezeigt, in der sie ihn betreffen.
• Sortierung nach StraßenklassenEs sollte eine Sortierung der Liste nach Straßenklassen (z. B. absteigend von BAB bis Gemeindestraße) möglich sein.

Sorting procedures for the presentation of the list of traffic information must be provided in the terminal (see also section 4.9). The following sorting procedures should at least be available:

• Sorting according to topicality (detailed description see chapter 4.9)
• Sorting by direction of travel / distance It should be possible to sort the list according to traffic information closest to the direction of travel. This sorting shows the customer the traffic information in the order in which it affects him.
• Sorting by street class It should be possible to sort the list by street class (e.g. descending from BAB to Gemeindestraße).

If the customer chooses the audio text system as the output mode, the traffic information is set in the audio text system. In addition, the traffic information is always sent to the end device via SMS. In order to enable a synchronous output of the traffic information via the display and the audio text system, the TINFO Speech Message contains all traffic information relevant to the customer in the sorting order as it is done with the audio text output. In the case of a VINFO request with display and audio output, the traffic information in the terminal must be sorted according to the TINFO Speech Message. The sorting set by the customer on the end device must be suppressed when audio text is output.

The data structure of the traffic information is in Chap. 4.7 and in ADP TINFO.

2.1.4 Brief description of radius-related VINFO (parameterized by the control center)

The service variant perimeter-related VINFO (parameterized by the control center) is used for the query of traffic information from a circular selection area around the starting position (current position or explicitly selected start position). As an explicitly selected starting position any coordinates are allowed in the specified format. The start selection is made for example cities from the geocode list or addresses from the personal address book. When selecting from the geocode list, the geocode is in the appropriate coordinates convert.

• Lokale Verkehrsinformationen (kleines Kreisgebiet/Sektor)
• Regionale Verkehrsinformationen (mittleres Kreisgebiet/Sektor)
• Überregionale Verkehrsinformationen (großes Kreisgebiet/Sektor)

With VINFO, the user has the following three options with regard to the size of the circumference:

• Local traffic information (small district / sector)
• Regional traffic information (middle district / sector)
• National traffic information (large district area / sector)

With the default setting "Traffic information to long-distance network" the customer receives within the selection area only traffic information via the long-distance network (BAB, recommended detour routes and federal highways).

• bei VINFO lokal:   Verkehrsinfos zu den Klassen 1 bis 4 innerhalb Kreis/Sektor "Iokal",
• bei VINFO regional:   Verkehrsinfos zu den Klassen 1 bis 4 innerhalb Kreis/Sektor "Iokal", Verkehrsinfos zu den Klassen 2 bis 4 außerhalb Kreis/Sektor"Iokal" und innerhalb Kreis/Sektor "regional"
• bei VINFO überregional:   Verkehrsinfos zu den Klassen 1 bis 4 innerhalb Kreis/Sektor "Iokal", Verkehrsinfos zu den Klassen 2 bis 4 außerhalb Kreis/Sektor"Iokal" und innerhalb Kreis/Sektor"regional", Verkehrsinfos zu den Klassen 3 und 4 außerhalb Kreis/Sektor "regional" und innerhalb Kreis/Sektor "überregional"

If the customer selects "Traffic information on all streets", he receives the following information:

• at VINFO local: traffic information for classes 1 to 4 within district / sector "Iokal",
• at VINFO regional: traffic information for classes 1 to 4 within district / sector "Iokal", traffic information for classes 2 to 4 outside district / sector "Iokal" and within district / sector "regional"
• at VINFO supraregional: traffic information for classes 1 to 4 within district / sector "Iokal", traffic information for classes 2 to 4 outside district / sector "Iokal" and within district / sector "regional", traffic information for classes 3 and 4 outside District / sector "regional" and within district / sector "national"

The determination of the corresponding circle radii for "Kreis local" (r_loc), "Kreis regional" (r_reg) and "Kreis überregional" (r_überreg) as well as the opening angle of the sector at VINFO are based on the cardinal direction. The traffic infrastructure at the starting position is taken into account. The following values can be used as guidelines for the radii : infrastructure Local district (r_loc) Regional district (r_reg) District supraregional (r_überreg) conurbation 5 km 25 km 50 km urban areas 15 km 35 km 75 km rural areas 25 km 45 km 100 km

In addition, the customer should have the option of further filtering by specifying a cardinal point (cardinal direction-related VINFO) . In this case, he receives traffic information from a sector-shaped selection area. When choosing the cardinal direction, the customer has 8 possible alternatives (N, NO, E, SO, S, SW, W, NW).

On the central side, an expansion of the VINFO service variant related to the cardinal direction is planned, which allows an additional selection of traffic information in the selected cardinal direction. This direction selection is transparent to the end device and does not require any software changes in the end device.

2.1.5 Brief description of targeted VINFO

If the customer chooses the targeted VINFO service variant, he receives traffic information a selection area that selects the start position (current position or explicitly Start position) and contains the selected destination. In the start and destination selection are any Geocodes allowed (e.g. cities from the geocode list and addresses from the personal Directory). When selecting from the address book, the address coordinates are in the corresponding Convert geocode.

With the default setting "Traffic information to long-distance network" the customer receives within of the section area only traffic information via the long-distance network (BAB, recommended detour routes and federal highways).

If the customer selects "Traffic information on all streets", the head office filters within the selection area additionally according to classes of traffic information. The customer receives traffic information classes 1 to 4 in its immediate vicinity ("Iokal" district, see Chapter 2.1.4) and with increasing distance from the current reference point higher-class traffic information.

The size and orientation of the selection area are determined at the headquarters.

An expansion of the VINFO service variant is planned on the central side, which allows an additional selection of traffic information in the target direction. This direction selection is transparent to the end device and does not require any software changes in the end device.

2.1.6 Brief description of route-related VINFO

If the customer selects the route-based VINFO service variant, he receives traffic information over selected sections of the route. The route can be a manually entered one Be a series of streets or a route stored in the end device.

For the manually entered route, the identifier and number of the street or several streets (maximum 5 streets, see chapter 2.3, parameter vig250_street_max) must be specified (e.g. A 59, A 565, A3). The customer is asked to enter the selected streets in order of passage. The entry of streets in free text (e.g. Kölnstraße) is not supported.
In addition, the start position (current position or explicitly selected start position) and the target position are selected. All geocodes are permitted for the start and destination selection (e.g. cities from the geocode list and addresses from the personal address book). When selecting from the address book, the address coordinates are to be converted into the corresponding geocode.

With VINFO, route-related are within a rectangular selection area, the Start and destination position contains, all traffic information for the selected streets selected.

Alternatively, the customer should use a route stored in the end device (see service specification Navigation service orientation guide). This route is a series of Revaluate streets with start and destination positions and can therefore use the same VINFO request as with the manually entered route (see section 4.6).

With VINFO route-related, the customer receives traffic information of all classes 1 to 4 for the selected route. There is no filtering according to the distance network or similar.

An expansion of the VINFO service variant on a route-specific basis is planned on the central side, allowing additional selection of traffic information in the direction of travel. This direction selection is transparent to the end device and does not require any software changes in the end device.

2.2 Definitions of terms

• ADP   Application Data Protocol
• CAS   Conditional Access and Security Protocol
• Datentelegramm   zwischen zwei Systemen ausgetauschte digitale Nachricht
• Endgerät (EG)   mit der Zentrale interagierendes, in der Regel mobiles System zur Abwicklung von Telematikdiensten
• Event-Code   Eindeutige Festlegung und Identifikation von Ereignissen, Ur Sachen und Hinweisen für Verkehrsinformationsmeldungen (vgl. gleichnamige Spezifikation)
• Geo-Code   Eindeutige Festlegung und Identifikation eines geographischen Objektes durch Koordinaten (vgl. Spezifikation)
• VTG   Verkehrstelematik-(End-)Gerät (siehe Endgerät)
• Zentrale   vom Diensteanbieter bereitgestelltes System zur Abwicklung von Telematikdiensten.

The following terms are clearly defined for this document:

• ADP Application Data Protocol
• CAS Conditional Access and Security Protocol
• Data telegram digital message exchanged between two systems
• Terminal (EG) with the central interacting, usually mobile system for handling telematics services
• Event code Clear definition and identification of events, original items and information for traffic information messages (cf. specification of the same name)
• Geo-Code Clear definition and identification of a geographical object using coordinates (see specification)
• VTG traffic telematics (end) device (see end device)
• Central system provided by the service provider for handling telematics services.

2.3 About the documents

• Dienstespezifikation Interne Dienste
• Conditional Access and Security Protocol
• Key Management and Security

Cross-service specifications required to understand this specification:

• Service specification Internal services
• Conditional Access and Security Protocol
• Key management and security

• ADP Traffic Information (TINFO)
• ADP Message Types of General Interest

The message types listed can be found in the documents:

• ADP Traffic Information (TINFO)
• ADP Message Types of General Interest

• Coding of Text and Transparent Data
• Address Coding
• Coding of Extended Location Message
• Coding of Absolute Time
• Area and Location Coding
• Event-Codes
• Geo-Codes

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

• Coding of Text and Transparent Data
• Address coding
• Coding of Extended Location Message
• Coding of absolute time
• Area and location coding
• Event Codes
• Geo codes

• Transport Protocol

The transport frame for the message types is defined in:

• Transport Protocol

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

3 General procedures 3.1 Transport protocol - handling

The transport protocol is used as follows to use the interactive traffic information service:

The transport frame supports the sending of user data via several short messages time. The procedure is specified in the "Transport Protocol" document.

No special transport protocol is used to receive messages via cell broadcast used. Rather, the service identifier (see Chapter 3.1.1) is derived from the cell broadcast Message ID derived. The length of the user data is transferred in the CAS protocol.

The full range of functions of the CAS layer described in the "CAS Protocol" document is to implement and support on the terminal side.

3.1.1 Service identifier

Service identifiers are unique address information issued by the head office Routing between the communication interface and the applications. These are in the Transfer the Application ID field 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 be restricted. To identify the services offered Assign service identifiers. The service identifiers are in the separate service specifications listed.

The following service identifiers are used for the traffic information service:

interactive VINFO service

Service ID B0h VINFO perimeter (parameterized by the control center) / directional Service ID B1h VINFO targeted Service ID 13h VINFO route-related Service ID B2h TINFO Code Request Message

CB activation / interactive request from CB Case a: CB not available

Service ID B3h VINFO perimeter (parameterized by the control center) / directional Service ID B4h VINFO targeted Service ID B5h VINFO route-related

Case b: With "Telephony" or "Selection area larger than vig100 r max"

Service ID B6h VINFO perimeter (parameterized by the control center) / directional Service ID B7h VINFO targeted Service ID B8h VINFO route-related

3.1.2 Order identification and assignment of answers

• Initiative Flag
• Context Number im Transport-Layer.

Transactions are assigned using the two fields:

• Initiative Flag
• Context number in the transport layer.

The traffic telematics terminal assigns a freely selectable context on behalf of the head office Number (restriction: MSB = 1). With Initiative Flag = 1 (Initiative) is the first transaction the chain, the order.

If there is a response to the traffic telematics terminal, its context number is again set. The initiative flag is set to 0 for all associated answers. So that the Client clearly assign the answer to the order placed.

The center assigns a freely selectable context for messages not initiated by the terminal Number (restriction: MSB = 0). The Initiative Flag = 1 (Initiative).

3.2 Coding of the communication header of the ADPs used

The values for Protocol Discriminator and Message Type are in the document "Message Type Numberng ". The bulk flag is always set to 0.

3.3 Parameters of the communication processes

The parameters and timer values relevant for the traffic information services are as follows listed. The storage and updating of the parameters in the terminal is done in the Telematics service specification "Internal Services" explained.

The following table has been expanded to include the last column (T-Mobile) compared to the basic specification. "V" denotes parameters used by T-Mobil, "nv" not used. In addition, changes to the basic specification are indicated by non-italic, bold font and by a gray background. ID parameter Function / definition Unit Defaul t Range Reso lutio n T-Mobile 0 VIG_K101 Storage duration of a CB traffic report priority 1 min 5 0 - 60 5 v 1 VIG_K102 Storage duration of a GB traffic announcement Priority 2 min 10 0 - 60 5 v 2 VIG_K103 Storage duration of a CB traffic report priority 3 min 15 0 - 60 5 v 3 VIG_K104 Storage time of a CB traffic report Priority 4 min 20 0 - 60 5 v 4 VIG_T109 maximum waiting time for a response from the service center sec 180 0 - 600 5 v 5 VIG_T110 Waiting time between the absence of traffic reports via cell broadcast and the extension of the decay time of a traffic report sec 300 60-600 10 v 6 VIG_T111 Storage period for messages received in the CB if the CB is temporarily or locally unavailable min 30 0 - 60 5 v 7 VIG_T112 Max. Storage time of interactively queried messages min 120 30-120 5 v 8th VIG_T113 Max. Waiting time of the end device between 2 SMSs of a response from the central sec 300 0 - 400 5 v 9 vig100_r_ max Max. Radius of the broadcasting area in the VIG100 sub-service km 300 1-300 1 v 10 vig250_ circle_max maximum radius of a radius info,
r overreg km 75 10-500 10 v 11 vig250_ circle_min minimum radius of a radius information,
r loc km 15 1-250 1 v 12 vig250_dir_ max maximum angle for the alignment of a segment of a circle counterclockwise to the north Degree 359 0-359 1 nv 13 vig250_dir_ min minimum angle for the alignment of a circular segment information to the north in a clockwise direction Degree 0 0-359 1 nv 14 vig250_dist_max maximum range of a segment information km 100 10-500 10 nv 15 vig250_dist_min Minimum range of a circle segment information km 1 1-500 1 nv 16 vig250_phi_ max maximum opening angle of a circular segment info Degree 180 1-180 1 v 17 vig250_phi_min Minimum opening angle of a segment information Degree 30 1-180 1 v 18 vig250_r_max maximum radius of a circle segment info km 50 1-250 1 nv 19 vig250_r_min minimum radius of a circular segment info km 1 0-250 1 nv 20 vig250_street_ max maximum number of streets for which street information can be requested. 5 0-15 1 v 21-25 reserved reserved for Mannesmann Autocom GmbH nv 26 vig_up_per_max Maximum request period for T-Mobil update of traffic information min 15 0-60 5 v 27 vig_up_dist Threshold value for the distance traveled when T-Mobil updates traffic information km 50 10-500 10 v 28 vig_cb_req1_max Maximum number of interactive requests from CB for telephony 10 0-500 1 v 29 vig_cb_req2_max maximum number of interactive requests from CB if no CB reception 10 0-500 1 v 30 vig250_ circle_med r_reg km 35 1-250 1 v 31-60 reserved reserved nv 61 VIG_Ctrl1 Sequential control bit flags Flag 16 bits v 62 VIG_Ctrl2 Sequential control bit flags Flag 16 bits v 63 VIG_Ctrl3 Sequential control bit flags Flag 16 bits nv

3.4 Sequence control

Three 16-bit switches are available for parameterizing the processes (see chapter 2.5: VIG_Ctrl 1 - 3) Available, which are documented as follows.

• 0 = feature not supported / off
• 1 = feature supported / on

Meaning of the bits:

• 0 = feature not supported / off
• 1 = feature supported / on

VIG_Ctrl1 is broken down in the following table: Bit no Abbrev. description T-Mobile default 1 A1VIG1 Activation of cell broadcast VINFO 0 2 A1VIG2 centrally controlled update (via IE update duration) is supported 1 3 A1VIG3 VINFO ptp also sends the control center independently of an initiative by the end device 1 4 A1VIG4 Control center supports VINFO related to the surrounding area (parameterized by the EC) 0 5 A1VIG5 Central unit supports VINFO related to the surrounding area (parameterized by central unit) 1 6 A1VIG6 Head office supports VINFO related to district segments 0 7 A1VIG7 Head office supports targeted VINFO 1 8th A1VIG8 Head office supports route-related VINFO 1 9 A1VIG9 Head office supports start and finish point for route-related VINFO 1 10 A1VIG10 Head office supports selection area for route-related VINFO 0 11 A1VIG11 Head Office supports Mode Speech (audio text) 1 12 A1VIG12 Central supports output format text 1 13 A1VIG13 The head office supports TINFO Text Request Message 0 14 A1VIG14 The head office supports TINFO Code Request Message 1 15 A1VIG15 Central supports bypass request message 0 16 A1VIG16 reserved

VIG_Ctrl2 is broken down in the following table: Bit no Abbrev. description T-Mobile default 1 A2VIG1 Control center supports FCD flag (TINFO block 10) 0 2 A2VIG2 A2VIG 18 controls the meaning of the bypass flag (TINFO Block 1): A2VIG18 = 0: control panel recommends redirection request via bypass request message, A2VIG18 = 1: control panel recommends redirection request via navigation service orientation aid 1 3 A2VIG3 Central supports interactive inquiry at CB if the selection area is larger than vig100_r_max 1 4 A2VIG4 reserved 5 A2VIG5 reserved 6 A2VIG6 reserved 7 A2VIG7 reserved 8th A2VIG8 reserved 9 A2VIG9 reserved 10 A2VIG10 reserved 11 A2VIG11 reserved 12 A2VIG12 reserved 13 A2VIG13 reserved 14 A2VIG14 reserved 15 A2VIG15 reserved 16 A2VIG16 reserved

3.5 Coding of text

All text elements within the traffic information services use the following format:

4 Description of the interactive VINFO service 4.1 Inquiry process when using the VINFO services

Throughout Chapter 4, the request flow for output is shown on a display (Basic sequence) described. The procedure for the audio text output is separately in Chap. 4.1.6 described.

The request process when using the various VINFO service variants is uniform.

The customer selects the desired VINFO variant on the end device. The terminal sends then the corresponding TINFO request message and receives from the head office as Answer a Traffic Information Message, TINFO Deletion Message or Text Message. in the If an error occurs, a corresponding error message is transmitted to the end device.

If there is valid traffic information in the end device, all VINFO variants will the version numbers of this traffic information with the corresponding TINFO request Transfer message to the control center. The head office only sends new or updated traffic information back (with the Traffic Information Message) or send with the TINFO Deletion Message returns the version numbers of the TINFOs to be deleted.

There is no traffic information or no new or updated traffic information at the head office for the customer, a text message with IE status 03h (no traffic news) or 04h (Situation on roads has not changed).

With all VINFO variants, the customer should be able to request the traffic information once or with an automatic update. The two update variants of device-controlled update (see Chapter 4.1.2) and central-controlled update (see Chapter 4.1.3) are not supported by T-Mobil in its pure form. The T-Mobile update of traffic information is a combination of device-controlled and central-controlled updates (see Chapter 4.1.5).

4.1.1 One-time request for traffic information

When traffic information is called up once, the end device sends the corresponding TINFO Request Message (see ADP TINFO, Chapter 3) to the head office. For the one-time query, the IE update duration (see ADP TINFO, chapter 5.5) of the corresponding message is set to "no update" (0x0). After a response message has been delivered once, the order for the head office is completely processed.

4.1.2 Device-controlled update of traffic information

In the variant of terminal-controlled update of traffic information, the terminal periodically sends requests for traffic information with the corresponding TINFO request message. The IE update duration is set to "no update" (0x0). The head office replies to each request once with the corresponding reply message.

4.1.3 Centralized update of traffic information

In the case of the centrally controlled update of traffic information, the end device sends the corresponding TINFO request message, whereby the IE update duration is set to the update duration. The head office transmits the traffic information and its updates within the update duration.

4.1.4 Output format

Only Event Code / Geo Code is supported as the output format by default. Can the If the terminal device does not interpret an event code / geo code, a translation into plain text is carried out requested. The exact procedure is described in the separate service specifications.

AL-C event codes and TMC location codes are not supported by T-Mobil as part of this protocol version.

The treatment of non-decodable traffic information is described in Chap. 4.7.12 described.

4.1.5 Update of traffic information

The update of traffic information is a combination of device-controlled updates (see chapter 4.1.2) and centrally controlled update (see chapter 4.1.3).

Choosing "Update traffic information" should be entered by the customer via "Update mode on / off "or by entering a duration for the update mode. The update mode must be able to be deactivated by the customer at any time (e.g. early Reaching the goal).

In the update mode, the terminal periodically queries traffic information with the corresponding TINFO request message. The request frequency is controlled by a Time trigger and a path length trigger. The time trigger sets the time request period of the Terminal fixed. Has the vehicle covered a distance within a period of time that the Threshold exceeds vig_up_dist (see Chapter 3.3), a new request is triggered. In this case, both the time and distance counters must then be reset to 0.

The maximum request period is determined by vig_up_per_max (default value 15 min). The The threshold for the distance covered is determined by vig_up_dist (default value 50 km). The threshold value is a recommendation and should be free within the range be selectable.

With each request, the IE update duration is set to "000001". (The control center does not interpret this code as an update of 30 minutes as described in the ADP TINFO.)

The head office answers each of the periodic VINFO inquiries directly with the corresponding one Reply. In addition, initiated by update duration code 000001, the VINFO request at headquarters for a booking time (greater than or equal to the maximum Request period vig_up_per_max) noted. Surrender before the booking timer expires important changes in the traffic situation in the relevant selection area (e.g. the emergence of a new traffic jam due to an accident) or there is a warning for the relevant area in front (e.g. ghost driver), the head office sends a traffic initiative Information Message or TINFO Deletion Message. The terminal evaluates the central side initiated messages and displays the traffic information.

After the booking timer has expired, the VINFO request is deleted from the head office. So that is the order is completed on the central side. Receives a new periodic VINFO request with an update duration code 000001 in the head office, this request is noted again and on new booking timer started.

The terminal sends the version numbers for each of the periodic VINFO requests already known, valid traffic information. The version numbers known to the terminal are noted in the head office for the time of the booking timer. The headquarters only transmits new or updated traffic information.

The combination of a device-controlled update and a central-controlled update takes advantage of both methods: With every periodic request, the current vehicle position is transmitted, on the basis of which the correspondingly updated selection area is recalculated in the control center. The filtering of traffic information is updated periodically, which is why no superfluous information is transmitted to the end device. The reservation of the VINFO request in the head office ensures that important traffic information reaches the customer even between the periodic requests from the end device.

4.1.6 Inquiry process for audio text output

With audio text output, the MSISDN must always be transmitted when the GSM voice connection (MO) is established .

The request process when using the audio text system as output medium is for the different VINFO variants uniform.

In addition to providing the traffic information in the audio text system, the traffic information As with the basic process, display output is sent to the end device via SMS. The output mode the corresponding TINFO request message is therefore always used for audio text output set to data and speech ".

The query process for the output of audio text is thus an extension of the basic process Display output (see chapters 4.1.1 to 4.1.5).

After receiving a corresponding TINFO request message, the control center sends a response in addition to the Traffic Information Message and TINFO Deletion Message, there is also a TINFO Speech Message to indicate that traffic information is available in the audio text system. The The terminal now also sets up a Speech Connection (MO) to listen to the traffic information to enable.

The TINFO Speech Message always contains all traffic information selected for the customer in the sorting order as it occurs with the voice server output. After a VINFO request with display and audio text output, the traffic information in the terminal must be sorted according to the TINFO Speech Message. The sorting set by the customer on the end device must be suppressed when audio text is output.

If the terminal sends version numbers of traffic information known to it to the head office, it receives, as described in Chap. 4.1, with the Traffic Information Message only the new or updated traffic information and with the TINFO Deletion Message back the traffic information to be deleted. The TINFO Speech Message shows all traffic information relevant to the customer in the current sorting (analogous to the T-Traffic update; important message with the Traffic Information Message, all relevant traffic information in current sorting with the TINFO Speech Message).

There is no traffic information or no new or updated traffic information at the head office for the customer, a text message with IE status 03h (no traffic news) or 04h (Situation on roads has not changed). The transmitted at the same time TINFO Speech Message does not contain any traffic information for status 03h (IE Number of Items = 0) or with status 04h the old, still valid traffic information in current sorting. The Automatic establishment of a voice connection from the terminal should be received after receiving the text message with IE status 03h or 04h no longer apply.

The request flow for audio text output for the T-Mobile update is accordingly by extending the basic process (Section 4.1.5) to include the transmission of TINFO Speech Message from the head office and the establishment of the Speech Connection (MO) by the end device.

4.2 VINFO per circle (parameterized by the end device)

The service variant VINFO per-circle (parameterized by the terminal) is not supported by T-Mobil.

The request perimeter information (parameterized by the end device) allows you to query traffic events worth reporting from a circular selection area with a range from vig250_circle_min km to vig250_circle_max km (see Section 3.3). Protocol: TINFO Update Request Message IE Message Type: 0x04 IE Protocol Discriminator: 0x03 Service ID 0x11

When requesting a radius, the parameters radius and reference point are to be transmitted to the service provider.

4.3 VINFO per circle (parameterized by the control center)

With the VINFO service, the customer receives traffic information related to the area (parameterized by the control center) from a circular or sector-shaped selection area. Will be a compass direction are given, traffic information from a direction in this direction selected sector selected. If no direction is given, then Traffic information selected from a circular area.

• Lokale Verkehrsinformationen,
• Regionale Verkehrsinformationen,
• Überregionale Verkehrsinformationen.

The customer has three choices

• Local traffic information,
• Regional traffic information,
• National traffic information.

As an alternative to the current position, a start position can be entered. Protocol: Relative Regional TINFO Request Message IE Message Type: 0x0E IE Protocol Discriminator: 0x03 Service ID 0xB0

1. Auswahl lokal / regional / überreqional Der Kunde wählt eine der Varianten lokal / regional / überregional aus.

2. Auswahl der Startposition Der Kunde wird aufgefordert, die aktuelle Position als Startposition zu bestätigen. Bestätigt er dies nicht, so wird er zur Auswahl einer Startposition aus der Geocode-Städteliste bzw. aus seinem persönlichen Adreßbuch aufgefordert. Bei Auswahl aus der Geocode-Städteliste ist der Geocode in die entsprechenden Koordinaten umzuwandeln.

3. Auswahl einer Himmelsrichtung bei VINFO himmelsrichtungsbezogen Bei VINFO Himmelsrichtungsbezogen wählt der Kunde eine Himmelsrichtung aus (8 mögliche Alternativen: N, NO, O, SO, S, SW, W, NW).

4. Auswahl "Verkehrsinfos zum Fernstreckennetz" / "Verkehrsinfos zu allen Straßen" Die Defaulteinstellung ist "Verkehrsinfos zum Fernstreckennetz". Alternativ kann der Kunde "Verkehrsinfos zu allen Straßen" auswählen.

5. Auswahl Update von Verkehrsinfos Der Kunde erhält die Möglichkeit, einen automatischen Update der Verkehrsinfos anzufordern. Dazu wird ihm ein Schalter "Update-Modus ein/aus" bzw. die Eingabe einer Dauer für den Update-Modus angeboten. Der Update-Modus ist jederzeit manuell deaktivierbar.

6. Übertragung der VINFO-Anfrage Das Endgerät stellt die Relative Regional TINFO Request Message zusammen (siehe Kap. 4.3.1) und überträgt sie zur Zentrale.

7. Filterung der Verkehrsinfos Nach Erhalt der VINFO-Anfrage bestimmt die Zentrale das Selektionsgebiet. Innerhalb des Selektionsgebiets werden die Verkehrsinfos herausgefiltert. Zusätzlich wird der Filter "Fernstreckennetz" / "alle Straßen" verwendet (siehe Kap. 2.1.4).

8. Übertragung der Verkehrsinfos Die Zentrale überträgt die ausgefilterten Verkehrsinfos mit der Traffic Information Message (Kodierung siehe Kap. 4.7). Liegen keine Verkehrsinfos vor bzw. können keine Verkehrsinfos übertragen werden (Überlast, Ausfall von Zentralenkomponenten, etc.), wird der Kunde durch Übertragung der Text Message informiert (Kodierung siehe Kap. 2.7, ADP TINFO). Die Zentrale sendet die TINFO Deletion Message, um ungültige Verkehrsinfos im Endgerät zu löschen (Kodierung siehe Kap. 2.4, ADP TINFO).

9. Präsentation der Verkehrsinfos Die Verkehrsinfos werden vom Endgerät entsprechend dem gewählten Sortierverfahren sortiert und zur Anzeige gebracht (siehe Kap. 4.9). Die Liste der Verkehrsinformationen wird im Endgerät gespeichert.

10.Update von Verkehrsinfos Bei einem Update-Duration-Code von 000001 merkt die Zentrale die VINFO-Anfrage vor und schickt bei Vorlage von wichtigen Warn- und Verkehrsmeldungen initiativ eine Traffic Information Message oder TINFO Deletion Message. Das Endgerät stellt, gesteuert durch Zeit- und Weglängentrigger, neue VINFO-Anfragen (siehe Kap. 4.1.5). Der Ablauf wird ab Punkt 6 erneut angestoßen.

The choice of the service variant perimeter-related VINFO (parameterized by the control center) or cardinal direction-related VINFO typically follows the following procedure:

1. Local / regional / national selection The customer selects one of the local / regional / national variants.

2. Selection of the starting position The customer is asked to confirm the current position as the starting position. If he does not confirm this, he will be asked to select a starting position from the Geocode city list or from his personal address book. When selecting from the Geocode city list, the geocode must be converted into the corresponding coordinates.

3. Selection of a cardinal direction with VINFO cardinal direction-related With VINFO cardinal direction-related, the customer selects a cardinal direction (8 possible alternatives: N, NO, E, SO, S, SW, W, NW).

4. Select "Traffic information on long-distance network" / "Traffic information on all roads" The default setting is "Traffic information on long-distance network". Alternatively, the customer can select "Traffic information on all streets".

5. Selection of update of traffic information The customer is given the option of requesting an automatic update of the traffic information. For this purpose, he is offered a switch "Update mode on / off" or the entry of a duration for the update mode. The update mode can be deactivated manually at any time.

6. Transmission of the VINFO request The end device compiles the Relative Regional TINFO Request Message (see Chapter 4.3.1) and transmits it to the head office.

7. Filtering of traffic information After receiving the VINFO request, the head office determines the selection area. The traffic information is filtered out within the selection area. In addition, the "Long-distance network" / "All roads" filter is used (see Section 2.1.4).

8. Transmission of traffic information The control center transmits the filtered out traffic information with the Traffic Information Message (coding see section 4.7). If there is no traffic information or no traffic information can be transmitted (overload, failure of central components, etc.), the customer is informed by transmitting the text message (coding, see Section 2.7, ADP TINFO). The control center sends the TINFO deletion message in order to delete invalid traffic information in the end device (for coding, see Chapter 2.4, ADP TINFO).

9. Presentation of the traffic information The traffic information is sorted and displayed by the end device according to the selected sorting method (see Chapter 4.9). The list of traffic information is saved in the terminal.

10. Update of traffic information With an update duration code of 000001, the head office notes the VINFO request and sends a traffic information message or TINFO deletion message on presentation of important warning and traffic reports. Controlled by time and distance triggers, the end device makes new VINFO requests (see Chapter 4.1.5). The process is started again from point 6.

4.3.1 Coding the Relative Regional TINFO Request Message

The Relative Regional TINFO Request Message (see chapter 3.4, ADP TINFO) is encoded with VINFO (parameterized by the control center) or with VINFO according to the cardinal direction as follows:

4.4 VINFO related to the circle segment

With VINFO based on a segment of a circle, the customer receives traffic information from a selection area in the form of a segment of a circle with a range of up to vig250_dist_max km. The circle segment is supplemented by a maximum radius of vig250_r_max km radius around the current position. The orientation of the segment of the circle is determined by specifying the direction angle. protocol TINFO Update Request Message IE message type 0x04 IE Protocol Discriminator 0x03 Service ID 0x10

The opening angle of the selection area is determined by the basic settings of the end device fixed (e.g. 30 °) and lies between vig250_phi_min and vig250_phi_max. The opening angle can be set in 1 ° steps.

The parameters at a glance

4.5 VINFO targeted

With the targeted VINFO service, the customer receives traffic information from a selection area, that contains the current position as well as the target position. For this, the customer Target position entered. The exact definition of the geometry and orientation of the selection area takes place at the headquarters.

As an alternative to the current position, a start position can be entered. If the start position is not used, it must be set to 0. protocol Extended TINFO Request Message IE message type 0x03 IE Protocol Discriminator 0x03 Service ID 0xB1

1. Auswahl des Ziels Der Kunde wählt das Ziel aus der im Endgerät hinterlegten Geocode-Städteliste bzw. aus seinem persönlichen Adreßbuch aus. Bei Auswahl aus dem Adreßbuch sind die Koordinaten der Adresse in den entsprechenden Geocode umzuwandeln.

2. Auswahl der Startposition Der Kunde wird aufgefordert, die aktuelle Position als Startposition zu bestätigen. Bestätigt er dies nicht, so wird er zur Auswahl einer Startposition aus der Geocode-Städteliste bzw. aus seinem persönlichen Adreßbuch aufgefordert. Bei Auswahl aus dem Adreßbuch sind die Koordinaten der Adresse in den entsprechenden Geocode umzuwandeln.

3. Auswahl "Verkehrsinfos zum Fernstreckennetz" / "Verkehrsinfos zu allen Straßen" Die Defaulteinstellung ist "Verkehrsinfos zum Fernstreckennetz". Alternativ kann der Kunde "Verkehrsinfos zu allen Straßen" auswählen.

4. Auswahl Update von Verkehrsinfos Der Kunde erhält die Möglichkeit, einen automatischen Update der Verkehrsinfos anzufordem. Dazu wird ihm ein Schalter "Update-Modus ein/aus" bzw. die Eingabe einer Dauer für den Update-Modus angeboten. Der Update-Modus ist jederzeit manuell deaktivierbar.

5. Übertragung der VINFO-Anfrage Das Endgerät stellt die Extended TINFO Request Message zusammen (siehe Kap. 4.5.1) und überträgt sie zur Zentrale.

6. Filterung der Verkehrsinfos Nach Erhalt der VINFO-Anfrage bestimmt die Zentrale aus Start- und Zielposition das Selektionsgebiet. Innerhalb des Selektionsgebiets werden die Verkehrsinfos herausgefiltert. Zusätzlich wird der Filter "Fernstreckennetz" / "alle Straßen" verwendet (siehe Kap. 2.1.5).

7. Übertragung der Verkehrsinfos Die Zentrale überträgt die ausgefilterten Verkehrsinfos mit der Traffic Information Message (Kodierung siehe Kap. 4.7). Liegen keine Verkehrsinfos vor bzw. können keine Verkehrsinfos übertragen werden (Überlast, Ausfall von Zentralenkomponenten, etc.), wird der Kunde durch Übertragung der Text Message informiert (Kodierung siehe Kap. 2.7, ADP TINFO).
Die Zentrale sendet die TINFO Deletion Message, um ungültige Verkehrsinfos im Endgerät zu löschen (Kodierung siehe Kap. 2.4, ADP TINFO).

8. Präsentation der Verkehrsinfos Die Verkehrsinfos werden vom Endgerät entsprechend dem gewählten Sortierverfahren sortiert und zur Anzeige gebracht (siehe Kap. 4.9). Die Liste der Verkehrsinformationen wird im Endgerät gespeichert.

9. Update von Verkehrsinfos Bei einem Update-Duration-Code von 000001 merkt die Zentrale die VINFO-Anfrage vor und schickt bei Vorlage von wichtigen Warn- und Verkehrsmeldungen initiativ eine Traffic Information Message oder TINFO Deletion Message. Das Endgerät stellt, gesteuert durch Zeit- und Weglängentrigger, neue VINFO-Anfragen (siehe Kap. 4.1.5). Der Ablauf wird ab Punkt 6 erneut angestoßen.

The choice of the targeted VINFO service variant is typically carried out as follows:

1. Selection of the destination The customer selects the destination from the geocode city list stored in the end device or from his personal address book. When selecting from the address book, the coordinates of the address are to be converted into the corresponding geocode.

2. Selection of the starting position The customer is asked to confirm the current position as the starting position. If he does not confirm this, he will be asked to select a starting position from the Geocode city list or from his personal address book. When selecting from the address book, the coordinates of the address are to be converted into the corresponding geocode.

3. Select "Traffic information on long-distance network" / "Traffic information on all roads" The default setting is "Traffic information on long-distance network". Alternatively, the customer can select "Traffic information on all streets".

4. Selection of update of traffic information The customer is given the opportunity to request an automatic update of the traffic information. For this purpose, he is offered a switch "Update mode on / off" or the entry of a duration for the update mode. The update mode can be deactivated manually at any time.

5. Transmission of the VINFO request The end device compiles the Extended TINFO Request Message (see Chapter 4.5.1) and transmits it to the control center.

6. Filtering of traffic information After receiving the VINFO request, the head office determines the selection area from the start and target position. The traffic information is filtered out within the selection area. In addition, the "Long-distance network" / "All roads" filter is used (see Section 2.1.5).

7. Transmission of traffic information The control center transmits the filtered out traffic information with the Traffic Information Message (coding see section 4.7). If there is no traffic information or no traffic information can be transmitted (overload, failure of central components, etc.), the customer is informed by transmitting the text message (coding, see Section 2.7, ADP TINFO).
The control center sends the TINFO deletion message in order to delete invalid traffic information in the end device (for coding, see Chapter 2.4, ADP TINFO).

8. Presentation of the traffic information The traffic information is sorted by the terminal device according to the selected sorting method and displayed (see chap. 4.9). The list of traffic information is saved in the terminal.

9. Update of traffic information With an update duration code of 000001, the head office notes the VINFO request and sends a traffic information message or TINFO deletion message on presentation of important warning and traffic reports. Controlled by time and distance triggers, the end device makes new VINFO requests (see Chapter 4.1.5). The process is started again from point 6.

4.5.1 Coding of the Extended TINFO Request Message with VINFO in a targeted manner

The Extended TINFO Request Message (see Chapter 3.2, ADP TINFO) is encoded in a targeted manner at VINFO as follows:

4.6 VINFO route-related

With the VINFO service, the customer receives traffic information about a selected route Route. The route can be a street or a series of streets.

For IE Street only Location Type 001 (street) and Street Type 0 - 6 are supported. (Text is generally not supported.)

As an alternative to the current position, a start position can be entered. If the start position is not used, it must be set to 0. If the target position is not used, it must be set to 0. protocol Extended TINFO Request Message IE message type 0x03 IE Protocol Discriminator 0x03 Service ID 0x13

With VINFO route-related, the customer should also be able to select a route stored in the end device. The route description contains the place name in the block Waypoint, which corresponds to Chap. 3.4, ADP Navigation Services, contains a street description (identifier and number, free text is not supported), which is set as a street description in the IE Street of the Extended TINFO Request Message (see Chapter 3.2, ADP TINFO). Streets of the subordinate network should initially not be taken into account. In addition, a start and destination position must be extracted from the route description. Any geocode is allowed for this. This means that the VINFO request for the route can be the same as the request for the manually entered route and is not handled differently by the head office. If the route consists of more than 15 road sections, the route must be broken down into several sections with corresponding start and destination positions. A separate request with a new context number (see Section 3.1) must be made for each section. A division over more than 4 sections should be avoided.

1. Auswahl: Manuelle Eingabe einer Strecke/Wahl einer gespeicherten Route Der Kunde wählt zwischen den Varianten "Manuelle Eingabe einer Strecke" und "Wahl einer gespeicherten Route" aus.Wählt der Kunde "Manuelle Eingabe einer Strecke", so ist der weitere Ablauf ab Punkt 2 beschrieben.Wählt er "Wahl einer gespeicherten Route", so werden ihm die Routengrobbeschreibungen (Route Briefing, siehe ADP Navigation Services) aller gespeicherten Routen angezeigt (siehe Dienstespezifikation Navigationsdienst Orientierungshilfe). Der Kunde wählt eine Route aus. Das Endgerät wertet die Route in eine Folge von Straßen inklusive Startposition und Zielposition um (weiterer Ablauf ab Punkt 5).

2. Auswahl des Ziels Der Kunde wählt das Ziel aus der im Endgerät hinterlegten Geocode-Städteliste bzw. aus seinem persönlichen Adreßbuch aus. Bei Auswahl aus dem Adreßbuch sind die Koordinaten der Adresse in den entsprechenden Geocode umzuwandeln.

3. Auswahl der Startposition Der Kunde wird aufgefordert, die aktuelle Position als Startposition zu bestätigen. Bestätigt er dies nicht, so wird er zur Auswahl einer Startposition aus der Geocode-Städteliste bzw. aus seinem persönlichen Adreßbuch aufgefordert. Bei Auswahl aus dem Adreßbuch sind die Koordinaten der Adresse in den entsprechenden Geocode umzuwandeln.

4. Eingabe der Straße(n) Der Kunde wird aufgefordert, die Straße bzw. die Straßen (maximal 5 Straßen, siehe Parameter vig250_street_max) in Durchfahrtreihenfolge einzugeben. Für jede Straße ist Kennung und Nummer anzugeben (z. B. A 59). Die Eingabe einer Straße in Freitext wird nicht unterstützt.

5. Auswahl Update von Verkehrsinfos Der Kunde erhält die Möglichkeit, einen automatischen Update der Verkehrsinfos anzufordem. Dazu wird ihm ein Schalter "Update-Modus ein/aus" bzw. die Eingabe einer Dauer für den Update-Modus angeboten. Der Update-Modus ist jederzeit manuell deaktivierbar.

6. Übertragung der VINFO-Anfrage Das Endgerät stellt die Extended TINFO Request Message zusammen (siehe Kap. 4.6.1) und überträgt sie zur Zentrale.

7. Filterung der Verkehrsinfos Nach Erhalt der VINFO-Anfrage filtert die Zentrale die Verkehrsinfos auf der Strecke in Fahrtrichtung heraus. Der Kunde erhält für die gewählte Strecke Verkehrsinformationen aller Klassen (keine Filterung nach Fernstreckennetz o. ä.).

8. Übertragung der Verkehrsinfos Die Zentrale überträgt die ausgefilterten Verkehrsinfos mit der Traffic Information Message (Kodierung siehe Kap. 4.7). Liegen keine Verkehrsinfos vor bzw. können keine Verkehrsinfos übertragen werden (Überlast, Ausfall von Zentralenkomponenten, etc.), wird der Kunde durch Übertragung der Text Message informiert (Kodierung siehe Kap. 2.7, ADP TINFO). Die Zentrale sendet die TINFO Deletion Message, um ungültige Verkehrsinfos im Endgerät zu löschen (Kodierung siehe Kap. 2.4, ADP TINFO).

9. Präsentation der Verkehrsinfos Die Verkehrsinfos werden vom Endgerät entsprechend dem gewählten Sortierverfahren sortiert und zur Anzeige gebracht (siehe Kap. 4.9). Die Liste der Verkehrsinformationen wird im Endgerät gespeichert.

10.Update von Verkehrsinfos Bei einem Update-Duration-Code von 000001 merkt die Zentrale die VINFO-Anfrage vor und schickt bei Vorlage von wichtigen Warn- und Verkehrsmeldungen initiativ eine Traffic Information Message oder TINFO Deletion Message. Das Endgerät stellt, gesteuert durch Zeit- und Weglängentrigger, neue VINFO-Anfragen (siehe Kap. 4.1.5). Der Ablauf wird ab Punkt 6 erneut angestoßen.

The route variant VINFO is typically selected as follows:

1. Selection: Manual entry of a route / selection of a saved route The customer selects between the variants "Manual entry of a route" and "Selection of a saved route". If the customer selects "Manual entry of a route", the rest of the procedure is finished Point 2. If he chooses "Select a saved route", the rough route descriptions (route briefing, see ADP Navigation Services) of all saved routes are displayed (see service specification navigation service orientation aid). The customer selects a route. The end device evaluates the route into a sequence of streets, including the starting position and destination (further procedure from point 5).

2. Selection of the destination The customer selects the destination from the geocode city list stored in the end device or from his personal address book. When selecting from the address book, the coordinates of the address are to be converted into the corresponding geocode.

3. Selection of the starting position The customer is asked to confirm the current position as the starting position. If he does not confirm this, he will be asked to select a starting position from the Geocode city list or from his personal address book. When selecting from the address book, the coordinates of the address are to be converted into the corresponding geocode.

4. Entering the street (s) The customer is requested to enter the street or streets (maximum 5 streets, see parameter vig250_street_max) in the order of passage. The identifier and number must be specified for each street (e.g. A 59). Entering a street in free text is not supported.

5. Selection of traffic information updates The customer is given the option of requesting an automatic update of traffic information. For this purpose, he is offered a switch "Update mode on / off" or the entry of a duration for the update mode. The update mode can be deactivated manually at any time.

6. Transmission of the VINFO request The end device compiles the Extended TINFO Request Message (see Chapter 4.6.1) and transmits it to the control center.

7. Filtering the traffic information After receiving the VINFO request, the head office filters the traffic information on the route in the direction of travel. The customer receives traffic information of all classes for the selected route (no filtering by long-distance network or similar).

8. Transmission of traffic information The control center transmits the filtered out traffic information with the Traffic Information Message (coding see section 4.7). If there is no traffic information or no traffic information can be transmitted (overload, failure of central components, etc.), the customer is informed by transmitting the text message (coding, see Section 2.7, ADP TINFO). The control center sends the TINFO deletion message in order to delete invalid traffic information in the end device (for coding, see Chapter 2.4, ADP TINFO).

9. Presentation of the traffic information The traffic information is sorted and displayed by the end device according to the selected sorting method (see Chapter 4.9). The list of traffic information is saved in the terminal.

10. Update of traffic information With an update duration code of 000001, the head office notes the VINFO request and sends a traffic information message or TINFO deletion message on presentation of important warning and traffic reports. Controlled by time and distance triggers, the end device makes new VINFO requests (see Chapter 4.1.5). The process is started again from point 6.

4.6.1 Coding of the Extended TINFO Request Message with VINFO route-related

The extended TINFO request message (see chapter 3.2, ADP TINFO) is coded at VINFO as follows:

4.7 Coding of traffic information (Traffic Information Message)

The traffic information sent to the terminal with the Traffic Information Message consist of a maximum of 11 blocks (see Chapter 4, ADP). (see explanation below)

The basic TINFO contains the blocks General Information, Location (Event), Event (Event) and End.
The basic TINFO can optionally include the blocks Cause (cause of the event), Hint (traffic information), Duration (duration of the event), Bypass (diversion recommendation), Average Speed (mean speed at the location of the event) and Event position (exact position of the Event) can be expanded.

The block FCD (control of FCD via TINFO) is not supported.

A TINFO can consist of 11 different types of blocks, some of which are always present (mandatory, shown below in bold) and others optional. The order of the 11 block types (from block 1 general information to block 11 end) is determined by the block numbering. Optional blocks can exist several times and are initiated by a 4-bit header (e.g. block 2 (hint) occurs twice in succession if there are two notices). A special feature is block 3 (event): the first event block is mandatory and has no header, optionally other event blocks can follow, which are introduced with a header. (This means that in exceptional cases a TINFO can also consist of more than 11 blocks):

• General Information (Typ Block 1 gem. ADP TINFO)
• Location (Typ Block 2 gem. ADP TINFO), Ort des Ereignisses, nur einmal vorhanden
• Event (Typ Block 3 gem. ADP TINFO), Ereignis
• weitere Events (Zusatzinfos, ebenfalls Typ Block 3 gem. ADP TINFO)
• Cause (Typ Block 4), Ursache
• Hint (Typ Block 5), Hinweis
• Duration (Typ Block 6), Gültigkeitsdauer der Verkehrsinformation, z.B. geschätzte Lebensdauer eines Ereignisses; die Gültigkeitsdauer ist nicht identisch mit der Speicherdauer bei ptp bzw. der Verfallszeit der TINFO's im Cell Broadcast)
• Bypass (Typ Block 7), Umleitungshinweis
• Average Speed (Typ Block 8), mittlere Geschwindigkeit am Ort des Ereignisses
• Event Position (Typ Block 9), genaue Position des Ereignisses
• FCD-Flag (Block Typ 10), dient der FCD-Steuerung und wird nicht unterstützt
• End (Block Typ 11), definiert das Ende der TINFO

The first event block always describes the traffic disruption itself, localized by the location block. Optional additional event blocks only provide additional information (example: "2h waiting time") about the traffic disruption and thus relate to the first event block. A TINFO describes only one traffic disruption. Accordingly, the optional blocks Cause, Hint, Duration, Bypass, Average Speed and Event Position provide additional information about the traffic disruption and thus always reference the first event block.

• General information (type block 1 according to ADP TINFO)
• Location (type block 2 according to ADP TINFO), location of the event, only available once
• Event (type block 3 according to ADP TINFO), event
• further events (additional information, also type block 3 according to ADP TINFO)
• Cause (type block 4), cause
• Hint (type block 5), note
• Duration (type block 6), period of validity of the traffic information, eg estimated lifespan of an event; the validity period is not identical to the storage period with ptp or the expiry time of the TINFO's in the cell broadcast)
• Bypass (type block 7), diversion notice
• Average speed (type block 8), average speed at the location of the event
• Event position (type block 9), exact position of the event
• FCD flag (block type 10), is used for FCD control and is not supported
• End (block type 11), defines the end of the TINFO

The exact coding of the TINFO is described in detail in the ADP TINFO. As a rule , each block will be present at most once (exception event, see below).

Overview of the coding of traffic information using geo and event codes:

Location information for traffic information is transmitted by geocodes. The structure of the geo-code tables to be stored in the end device is in the document "Geo-Codes: Content and structure description of the terminal tables "described in detail.

The geo-code table is first created for the Germany area (the procedure is however applicable across Europe) and will become all federal highways in the first implementation stage as well as cover federal highways that directly connect interrupted highways (Road node). The German trunk road core network is thus described by geocodes. In addition, at least all important cities are geocoded.

• den Geo-Code
• den Geo-Code-Typ (z. B. Anschlußstelle, Autobahnkreuz, Autobahndreieck, Grenzübergang, Stadt)
• die referenzierte Straße (A3, B8)
• den Namen (z. B. Beuel, Köln)
• bei Autobahnanschlußstellen/-kreuzen/-dreiecken die Nummer der Ausfahrt gemäß der offziellen Verzeichnisse (für beide Fahrtrichtungen)
• der Name der Fernziele für das Autobahnteilstück ("Von_Ort" und "Nach_Ort", z. B. A2 "Dortmund", "Hannover", die Richtungsinformation wird gemäß ADP TINFO zusätzlich übertragen)

The geo-code table contains:

• the geo code
• the geo-code type (e.g. junction, motorway junction, motorway triangle, border crossing, city)
• the referenced street (A3, B8)
• the name (e.g. Beuel, Cologne)
• at motorway junctions / crosses / triangles the number of the exit according to the official directories (for both directions of travel)
• the name of the long-distance destinations for the motorway section ("Von_Ort" and "Nach_Ort", e.g. A2 "Dortmund", "Hannover", the directional information is also transmitted according to ADP TINFO)

The information "A3, Autobahnkreuz Bielefeld" is accordingly encoded by the geocode type "Autobahnkreuz", the street "A3", (possibly reference geocodes), the official numbers as well as the long-distance destinations "Dortmund" and "Hannover" (see example in document Geo-Codes, Cape. 3.1).

The conversion of the geo-code into geographic coordinates (WGS84) as well as the inversion is possible.

Events, causes, instructions and redirection instructions are described in the Normally about event codes (in exceptional cases free text), which are described in the document "Event Codes" are described in detail.

• Behinderung (z. B. Stau, hohes Verkehrsaufkommen, Unfall)
• Wetter (z. B. Glatteis, Reifglätte, Nebel)
• Gefahr (z. B. brennendes Fahrzeug, Personen auf der Fahrbahn)
• Sonstige (Ausfall der Notrufsäulen, Messe, Sportveranstaltung)
• Umleitung (z. B. Verkehrsteilnehmer werden gebeten, den orangefarbenen Pfeilen zu folgen), diese Event-Typen werder nur im Block 7, Bypass, genutzt.

The following main groups of event codes are defined in the "Event Codes" document (these can denote events, causes, notices or redirection notices):

• Disability (e.g. traffic jam, high traffic, accident)
• Weather (e.g. black ice, frosty frost, fog)
• Danger (e.g. burning vehicle, people on the road)
• Other (failure of the emergency call pillars, trade fair, sporting event)
• Detour (e.g. road users are asked to follow the orange arrows), these event types are only used in block 7, bypass.

The main groups can be used to label the message accordingly when presenting the traffic information (eg "Warning: black ice").
Many event codes are assigned quantifiers with which e.g. B. the length of a traffic jam or the duration of a traffic announcement. However, the ADP TINFO can only be used for block 3 (event) and block 7 (bypass) quantifiers. Notes and causes that are provided with quantifiers are therefore coded as optional (additional) block 3 (event) (eg "waiting time 2h").

The following quantification types have been defined: Type 1 km, e.g. B. 6 km traffic jam Type 2 H Type 3 m Type 4 % Type 5 Phrases (e.g. "short-term", "partial", "sometimes", etc.) Type 6 min

Type 8 is reserved for diversion quantifiers (see section 4.7.7). Type 6 is reserved for Mannesmann Autocom.

The average speed for a section of the route is transmitted not by event code and quantifier, but by means of block 8 (average speed).

The coding of a traffic message in the individual blocks is explained below using examples: 1st example: A3, Cologne to Frankfurt, between AK Bonn / Siegburg and AS Siebengebirge 5 km traffic jam due to accident 2nd example: as 1st, additionally "Please use the U 123 from Bonn" 3rd example: as 1st, additionally "the traffic is directed over the hard shoulder" and "waiting time 2h" 4. Example: in places fog in the Cologne area

4.7.1 Block 1 (General Information), mandatory

This block is used to identify a traffic report. He sets the priority and gives with the Bypass Information flag information about the existence of a diversion recommendation at the service provider.

• den Typ des verwendeten TINFO-Frames (immer Typ 1)
• die Priorität der TINFO
• eine Version der Verkehrsmeldung (TINFO Version), die Version enthält eine ID für die Verkehrsmeldung, welche für die gesamte Lebensdauer der Meldung identisch ist, sowie einen Time-Stamp, der den Zeitpunkt der letzten Aktualisierung der Meldung enthält
• ein Flag Bypass Information, mit dem angezeigt wird, daß für die TINFO in der Zentrale eine Umleitungsempfehlung vorliegt.

The block contains

• the type of the TINFO frame used (always type 1)
• the priority of TINFO
• a version of the traffic report (TINFO version), the version contains an ID for the traffic report, which is identical for the entire life of the report, and a time stamp which contains the time of the last update of the report
• a bypass information flag , which indicates that there is a redirection recommendation for the TINFO in the central office.

TINFO priority:

• Priorität 4 -> Klasse 4: Warnmeldungen (z. B. Geisterfahrer, verlorene Ladung)
• Priorität 3 -> Klasse 3: Verkehrsinfos mit Fernwirkung
• Priorität 2 -> Klasse 2: Verkehrsinfos mit Mittelwirkung
• Priorität 1 -> Klasse 1: Verkehrsinfos mit Nahwirkung

The priorities are as follows:

• Priority 4 -> Class 4: Warning messages (e.g. ghost driver, lost cargo)
• Priority 3 -> Class 3: Traffic information with long-range effects
• Priority 2 -> Class 2: Traffic information with a medium impact
• Priority 1 -> Class 1: Local traffic information

With the interactive VINFO service only priority 4 is to be evaluated (immediate display the warning message with warning tone or similar). With VINFO over CB, the other priorities are also to be evaluated (see Chap.5.3).

The parameter A2VIG2 controls the meaning of the bypass information flag. T-Mobil supports not the query of redirection recommendations via the bypass request message. Rather, if the bypass flag is set, information is recommended using the navigation service Orientation guide to perform a route calculation for a detour route (only possible with end devices that also support navigation services).

4.7.2 Block 2 (Location), mandatory This block defines the location of the traffic information.

The location can be encoded in different ways. The event is between two defined points (e.g. AS Köln-Süd and AS-Köln-Poll), then the IE First Intersection and last intersection with the corresponding geocodes. It just becomes the standard Location block (see chapter 4.2.1, ADP) supports, but not the special location block (see chapter 4.2.2, ADP).

• die betroffene Straße
• die Richtungsinformation, welche beschreibt, in welcher Richtung zwischen dem übertragenen Anfang und Ende der Störung das Ereignis liegt
• die Geo-Codes für den Ort der Störung (Anfang und Ende)

The following information is transmitted within the standard information block:

• the affected street
• the direction information, which describes in which direction the event lies between the transmitted start and end of the fault
• the geo-codes for the location of the fault (beginning and end)

In the example, coding is as follows: example road direction Geo code beginning Geo code end 1 A3 01 AK Bonn / Siegburg AS Siebengebirge 2 like example 1 3 like example 1 4 s. below 00 Cologne (see below) Cologne (see below)

If the location of the event is clearly described by a location (e.g. for traffic reports for large areas), the same geo-code is transmitted for the beginning and end of the event. In this case, the following agreement applies to the IE street: Street type text (15), the text field is empty.

The additional information in the message from "Cologne" to "Frankfurt" is from the geo-code table the terminal device ("From_location", "To_location").

The additional information can be transmitted in block 9 (event position) in what distance from the IE first intersection the event is (e.g. traffic jam "10 km" to AK Bonn / Siegburg ").

4.7.3 Block 3 (event), mandatory

This block describes the event (s) (see Chapter 4.3, ADP). It will be the event Type 1 (event codes or text stored in the end device) is supported, but not the event Type 2 (AlertC codes).

Events that are stored in the event code list are described by the event code, otherwise plain text. Events that can be quantified are recorded using the Quantifier described, otherwise without.

A TINFO always contains the first event block, optionally several. The optional event blocks provide additional information about the traffic disruption and can be indications / causes, which, however, must be set with block 3 (event) due to the quantifier (e.g. waiting time 2h).

In the example, coding is as follows: example Event Header Event Type Code flag Event Code quantifier 1 deleted Type 1 1 Traffic jam ($ 080) 5 km 2 like example 1 3 as example 1 (traffic jam), additional optional Event block: 0001 Type 1 1 Waiting time ($ 210) 2h 4 deleted Type 1 1 fog in parts

4.7.4 Block 4 (cause), optional

This block describes the cause of the event (see Chapter 4.4, ADP). It will be the cause Type 1 (event codes or text stored in the end device) is supported, but not the Cause Type 2 (AlertC codes).

Causes that are stored in the event code list are described by the event code, otherwise plain text.

No quantifier can be assigned to a cause block. Causes with quantifier Coded as an optional event block (see section 4.7).

In the example, coding is as follows: example Cause header Cause Tvpe Gode flag Event Code 1 0010 Type 1 1 Accident ($ 0a5) 2 like example 1 3 like example 1 4 no cause block

4.7.5 Block 5 (Hint), optional

In this block, one or more information about the traffic information can be given. Only the Hint Type 1 (event codes or text stored in the end device) is supported.

Notes that are stored in the event code list are described by the event code, otherwise plain text

No quantifier can be assigned to a hint block. Notes with quantifier are as optional event block coded (see chapter 4.7).

In the example, coding is as follows: example Hint header Hint-Type Code flag Event Code 1 no hint block 2 no hint block 3 0011 Type 1 1 "the traffic is over on the hard shoulder "($ 28a) 4 no hint block

4.7.6 Block 6 (duration), optional

In this block the time period for which the traffic information applies can be set. It all three duration types are supported.

This block is used by T-Traffic to indicate the period of validity of the traffic announcement. The specified duration always refers to an event (e.g. demonstration from 2:00 p.m. to 4:00 p.m.).
Block 6 (duration) refers to the 1st event block. It therefore only occurs once in TINFO.

4.7.7 Block 7 (bypass), optional

A diversion notice can be set in this block. Redirection notices are as Event codes (for redirection notices) or as plain text supported. Locations are as Geo code or supported via IE Street.

No detour routes are supported, i.e. the IE Presence of IE of the building block Bypass route is 0.

The bypass block can exist regardless of the bypass flag. Using the bypass block In particular, the official diversions are encoded using the event codes the main group diversion (coding example see below).

4.7.7.1 Building Block Additional Location

The Building Block Additional Location determines the format and the location (s). For the Redirection information is supported: Location Type = 000 Geo Code, 001 Text, 011 Street and 100 differential geo codes. (see chap. 5. 10, ADP). In the case of differential geo code the differential geo code on the first geo code in the building block.

For geo code or differential geo code see chap. 5.8, ADP. For street see chap. 5.7 ADP. For the coding of text see "Coding of text and transparent data".

Using the Building Block Additional Information, the quantifiers for through event codes Coded forwarding notices set. The order of the set quantifiers corresponds to Order of the placeholders in the event code list (see example).

The diversion recommendation from Example 2 ("Please use the U 123 from AK Bonn / Siegburg) is coded as follows: Bypass header 0101 Bypass Hint / Presence of IE 1 Flag code / text 1 (event code) Hint Please use from $ the $ ($ 295) Number of addition locations 2 Additional location 1 Type Geo-Code (000), Geo-Code AK Bonn / Siegburg Additional location 2 Type Street (011) Street Type 5 (detour route), Street Number 123 Bypass Route / Presence of IE 0

4.7.8 Block 8 (A verage Speed), optional

With this block the average speed at the location of the event can be specified.

Block 8 (Average Speed) refers to the 1st event block. He therefore occurs in the TINFO only once at most.

4.7.9 Block 9 (Event Position), optional

With this block, the distance of the event from that specified in "first intersection" can be Location (see chap. 4.7.2).

Block 9 (event position) refers to the 1st event block. He therefore occurs in the TINFO only once at most.

4.7.10 Block 10 (FCD flag), is not supported

The block FCD flag is not supported.

4.7.11 Block 11 (End), mandatory

The end block shows the end of the TINFO.

4.7.12 Treatment of non-decodable traffic information

If the end device cannot decode parts of traffic information (event code / geo code that is in the event code / geo code table of the end device is not included), it requests a translation of the unknown code (s) in plain text.

The end device sends a TINFO Code Request Message (see Chapter 3.6, ADP TINFO) to the headquarters. A translation block is set for each unknown code. As Source format is only supported 0 (event code) and 1 (geo code). As a destination format only 0 (text) is supported.

The head office sends the translation of the code (s) with the TINFO Code Message (see Cape. 2.2, ADP TINFO). An explanation block is created for each translated code set. Only 0 (event code) and 1 (geo code) are supported as source format. As a destination Format is only supported 0 (text).

4.8 Error treatment

• "Message Type of General Interest", Kap. 4 General Error Message,
• "Diensteübergreifende Fehlerbehandlung".

See documents:

• "Message Type of General Interest", chap. 4 General Error Message,
• "Cross-service error handling".

4.9 Presentation of traffic information

Basically, the customer must switch between the VINFO output media audio text or display as well as audio text and display (at the same time).

When preparing for a trip or staying in an area not known to the customer it may be helpful for him to read the transmitted information only on the display and save (e.g. for planning alternatives).

During the journey, the audiotext output by the head office offers the customer in the interest traffic safety the advantage of listening to the information you want without Having to look away from the traffic.

The simultaneous output via audio text and display can also make sense for the customer (e.g. for more precise scrolling through the messages), especially from the point of view the automatic storage of relevant, current messages in the end device. As special In a customer-friendly manner, T-Mobil encourages the synchronous output of messages via audio text and display. This can be implemented in the end device by evaluating the TINFO Speech Message, which is transmitted by the control center when audio is output (see Chapter 4.1.6). The TINFO Speech Message provides the sequence and length of the traffic information set in the audio text system, which enables the synchronous output of traffic information on the display becomes.

The output medium audio text / display or audio text and display should be used for a VINFO request can be set by the customer (possibly through the basic settings). In update mode it should be possible to change the output medium at any time via the menu item and not to do so cause e.g. the first entry (destination etc.) must be repeated. "Audio text" is the default suggested for cases where there is no separate, large display.

In any case, the head office also sends all messages via SMS (even when selecting customers Audiotext alone), so that a complete, current list of traffic reports is always on the end device is available and the customer when switching from audio text to display or when switching on of the end device after a short absence, this list immediately without a new VINFO request has available.

Studies have shown that - provided the same ease of use - the Preference is given to speech output (unless an integrated display system is prepared in the driver's field of vision).

With the private collection of traffic data, the quantity and the rate of change of traffic information (and its reliability!) compared to today increase significantly. The customer will only find this a useful innovation, if he is not bothered with unnecessary traffic information. On the one hand, the Selection when making an inquiry by selecting a VINFO variant (perimeter, related to the compass, targeted or route-related). In addition, the customer should transmitted traffic information can be sorted appropriately during the presentation. An uncomplicated one User guidance for sorting is therefore crucial.

T-Mobil suggests sorting the traffic information available in the end device and its updates the following procedure for a corresponding user menu:

I. Sorting according to topicality:

1. neue VINFO ...z.B. mit dem Zusatz "neu"

2. geänderte VINFO...z.B. mit dem Zusatz "aktuell" oder "jetzt"

3. allgemeine Textnachrichten ("keine neuen Meldungen", "unverändert" o.ä.)

Ergibt der Update keinerlei neue Meldungen, sollte trotzdem eine Funktionsmeldung als allgemeine Textnachricht angezeigt werden, um das Kundenvertrauen in die Funktion von Endgerät und Dienst zu stärken. Demgegenüber erscheint es unter Kostengesichtspunkten nicht vertretbar, im Falle der Audio-Ausgabe für den gleichen Zweck automatisch eine Sprachverbindung zum Audiotext-System herzustellen. Hier sollte die vertrauensbildende Meldung lediglich per SMS / Display erfolgen oder darauf verzichtet werden. Automatic output (after receiving a Traffic Information Message, Text Message or TINFO Speech Message) :

1. new VINFO ... eg with the addition "new"

2. changed VINFO ... eg with the addition "current" or "now"

3. general text messages ("no new messages", "unchanged" or similar)

If the update does not result in any new messages, a function message should still be displayed as a general text message in order to strengthen customer confidence in the function of the end device and service. In contrast, it does not appear to be justifiable from a cost point of view to automatically establish a voice connection to the audio text system in the case of audio output for the same purpose. Here, the confidence-building message should only be sent via SMS / display or should be avoided.

Manual call : In addition, the customer should be able to get the list of all available traffic information from the end device memory by manually calling it up on the display (eg if he wants to make sure). With audio output, the customer establishes a voice connection via the menu item. In the audio text system, a distinction is made between "table 1" with the new and changed messages and "table 2" with the other (unchanged) messages. The sequence of the request corresponds to the D1 - Mobilbox request.

II. Sorting by direction of travel / distance

When displaying the display, the list should be sorted according to the closest in the direction of travel Traffic information may be possible. With this sorting the Customers are shown the traffic information in the order in which they affect him This sorting is not possible for audio text output.

III. Sorting by street class

When displaying the display, the list of traffic information should be sorted according to street classes (e.g. descending from BAB to Gemeindestraße).

Warning messages always have the highest priority and must be displayed or given priority. A warning tone or the like would be meaningful.

4.9.1 Display

The traffic information transmitted to the end device is to be shown to the customer on the display of the end device are presented in the clearest possible form, so as possible for him be easy to grasp and minimize any distraction effect.

Every traffic information consists of a number of blocks (see Chap. 4.7). The display capacity of a display is naturally limited. For the clear Understanding traffic information does not necessarily mean the full text the event codes / geo codes are displayed; rather, the implementation becomes meaningful Abbreviations expressly suggested. The corresponding rules and symbols for abbreviations are to be implemented specific to the end device.

A3 Köln > Frankf./M.

zw. AK BN u. Siebeng.

5 km Stau wg. Unfall

2 h Wartez. » U 123

An abbreviated traffic information like in example 2 (see chapter 4.7) could look like this on the display:

A3 Cologne> Frankf./M.

between AK BN u. Siebeng.

5 km traffic jam accident

2 h waiting »U 123

Depending on the number of messages available for the route section concerned several such messages that should be displayed one after the other. Therefore should a scroil function can be provided, the (line or) page-by-page scrolling or back and forth Jumping between individual messages allows. In addition, an automatic mode should Support convenient reading of all messages one after the other (e.g. automatic page change after 10 seconds).

Additional commands or other menu functions, such as B. saving individual messages or routes should also be shown on the display. Common should also Special characters (e.g. +, -, *, #, <,>, etc.) can be displayed.

To enable the information to be read even at dusk or in the dark, should a button press simultaneously the backlight of the display for a particular Trigger period (at least read a page).

The cover of the display should be mirror-free, so that the information is also at The device can be read at an angle. For displaying traffic information graphic skills are not required (different with the navigation service orientation aid).

4.9.2 Audio text system

In many situations, the output of traffic information via audio text is more advantageous and safer than reading from the display. If the customer uses e.g. for longer journeys the update (chap. 4.1.5), the traffic information selected by him for his route is awarded to him.

After the central traffic information set for the customer in the audiotext system it sends the TINFO Speech Message to the end device, which then automatically establishes a voice connection to the audio text system. T-Mobil's central audio text system supports fast scrolling to skip or repeat traffic information in a special way to increase customer acceptance.

The audio text system is controlled via tone dialing (DTMF), which is supported by the end device must become. The user should have the possibility with only one device command to jump back and forth between individual messages and the different ones Have menu levels (e.g. via skip switch or cursor cross). A remote control from Steering wheel off can only be welcomed from the point of view of traffic safety.

5 Description of the VINFO service via cell broadcast 5.1 Introduction

The VINFO Cell Broadcast Subservice is a broadcast service in which all traffic information within a radius of at least vig100_r_max km via cell broadcast in the GSM network be transmitted. The traffic information is cyclically reduced to less than 15 Minutes as VINFO data telegram "Traffic Information Message" - Message Type 0x01, Protocol Discriminator 0x03 - sent. You can do this within a data telegram several traffic reports are transmitted. The individual messages are based on their Version number (ID + Time Stap) can be clearly identified (same identifier for interactive and collective service).

In order to prevent unauthorized use, the data can be operated in cell broadcast mode be encrypted. The type of encryption is used in the CAS framework for cell broadcast Operation determined in which the user data are embedded.

The use of the VINFO service via cell broadcast should be the same for the customer as that of the interactive VINFO service. Therefore, the selection criteria should also be related to the environment VINFO, cardinal direction-related VINFO, targeted VINFO and route-related VINFO are supported. The menu structure should be identical to that of the interactive ones VINFO services. The corresponding area filters for VINFO CB are on the terminal side to realize. Recommendations for their parameterization are summarized in Section 5.5. In addition, the filtering according to "long-distance network" or "all roads" should be implemented (see chapters 2.1.4 to 2.1.6).

The interactive VINFO service is used as a fallback solution when CB reception is interrupted Query of messages that are outside the current CB-VINFO coverage area and used to translate messages that cannot be decoded (see Section 5.4).

5.2 Validity of traffic reports

Each traffic report is assigned an expiry time. The expiry time begins on receipt of the Data telegram in which the traffic report occurs. After the expiration time, the Traffic announcement is valid and must be deleted.

5.3 The process

The service provider permanently sends the current traffic events for via cell broadcast the broadcasting area.

After receiving a cell broadcast page, the data telegram contained in it must be included Decrypted using the service key - see Internal Services and Key Management. The individual traffic reports within the decrypted data telegram are separated. The following rules apply to them.

Regulate:

1 Precondition: traffic announcement has priority 1 (0x00)
Action:
Paste the traffic announcement into the traffic information.
Set the expiry time of the traffic report to the defined time vig_k101.

2 prerequisite:
Traffic announcement has priority 2 (0x01)
Action:
Paste the traffic announcement into the traffic information.
Set the expiry time of the traffic report to the defined time vig_k102.

3 prerequisite:
Traffic announcement has priority 3 (0x02)
Action:
Paste the traffic announcement into the traffic information.
Set the expiry time of the traffic report to the defined time vig_k103.

4 prerequisite:
Traffic announcement has priority 4 (0x03)
Action:
Paste the traffic announcement into the traffic information.
Set the expiry time of the traffic report to the defined time vig_k104.

5 precondition:
All received traffic reports have event 0x223
Action:
Delete all traffic reports from the traffic information

6 precondition:
The expiry time of a traffic announcement expires and no traffic announcements have been received via cell broadcast since the defined time vig_t110
Action:
Set the expiry time of the traffic report received in cell broadcast mode to the value vig_t1 11 regardless of its priority.

Are already known or updated traffic reports (same message ID) due the cyclical broadcast received repeatedly, the associated expiry time is again to set the value vig_k101 to vig_k104. The associated process is shown in Fig. 6-3 in Chapter 7 shown.

All existing messages (priority classes 1 to 4, all road classes) for a range of at least vig_100_r_max km (radius) related to the current vehicle position are distributed via CB. The following criteria are to be evaluated to assess their relevance for an issue: event location within the selection area, priority class, validity period, street class, status: new, updated, deleted, old. As with the interactive VINFO service, the messages are decoded using the reference tables (event and geo codes).

5.4 Linking to interactive VINFO services

The interactive VINFO service is used as a fallback solution when CB reception is interrupted, e.g. B. during a GSM voice connection, to query messages that are outside of the current one CB-VINFO coverage area, and non-decodable for translation Messages used. The traffic reports queried interactively from the CB mode are treated as regular CB messages in terms of priority, expiry time, etc.

5.4.1 No CB reception

Fall a): Kein CB-Empfang wegen bestehender GSM-Verbindung Der Kunde erhält eine Meldung darüber, daß seit n * VIG_T110 (n = 1 ... VIG_T111/VIG_T110) keine neuen Verkehrsinformationen empfangen wurden und die Möglichkeit zur Abfrage per interaktivem VINFO-Dienst besteht. Macht er von dieser keinen Gebrauch, wird die Meldung maximal n= VIG_T111/VIG_T110 wiederholt. Anschließend bekommt der Kunde den Hinweis, daß keine gültigen Verkehrsinformationen mehr vorliegen.Wünscht der Kunde die Abfrage über den interaktiven Dienst, wird der Zähler vig_cb_req1 um 1 erhöht. Dieser Ablauf kann bis zum Erreichen der Wertes vig_cb_req1_max (s. Kapitel 3.3) wiederholt werden. Der Zähler wird nach 24 h zurückgesetzt. Ist der Maximalwert vig_cb_req1_max noch nicht erreicht, wird die interaktive Abfrage durchgeführt. Dabei sind die gewählten Selektionsgebiete und - parameter auf die Anfragetypen umkreis-, himmelsrichtungs-, streckenbezogen bzw. zielgerichtet abzubilden. Empfehlungen für die entsprechenden Parameter sind in Kapitel 5.5 zusammengestellt. Es werden im Rahmen der CB-Emulation nur einmalige Anfragen unterstützt. Die Zentrale stellt über den Zeitraum VIG_T110 die Versorgung mit besonders wichtigen VINFO's sicher. Nicht unterstützt werden Anfragen mit Sprachausgabe.

Fall b): Kein CB-Empfang wegen temporärer/lokaler Nichtverfügbarkeit des Dienstes Zunächst wird der Zähler vig_cb_req2 um 1 erhöht. Dieser Ablauf kann bis zum Erreichen der Wertes vig_cb_req2_max (s. Kapitel 3.3) wiederholt werden. Der Zähler wird nach 24 h zurückgesetzt. Ist der Maximalwert vig_cb_req2_max noch nicht erreicht, wird die interaktive Abfrage durchgeführt. Dabei sind die gewählten Selektionsgebiete und -parameter auf die Anfragetypen umkreis-, himmelsrichtungs-, streckenbezogen bzw. zielgerichtet abzubilden. Empfehlungen für die entsprechenden Parameter sind in Kapitel 5.5 zusammengestellt. Es werden im Rahmen der CB-Emulation nur einmalige Anfragen unterstützt. Die Zentrale stellt über den Zeitraum VIG_T110 die Versorgung mit besonders wichtigen VINFO's sicher. Nicht unterstützt werden Anfragen mit Sprachausgabe.

The timers T110 and T111 (see Fig. 6-3 in chapter 7) are used to control the CB emulation. T110 is reset and restarted when each CB data telegram is received. If T110 reaches its maximum value VIG_T110 without another CB data telegram being received, the expiry times of all stored traffic reports are set to VIG_T111 uniformly and once, regardless of their priority. In this case, the terminal checks whether there is a GSM voice or data connection.

Case a): No CB reception due to existing GSM connection The customer receives a message that no new traffic information has been received since n * VIG_T110 (n = 1 ... VIG_T111 / VIG_T110) and the option of querying via interactive VINFO- Service exists. If he does not use this, the message is repeated a maximum of n = VIG_T111 / VIG_T110. The customer then receives the message that there is no longer any valid traffic information. If the customer requests the query via the interactive service, the counter vig_cb_req1 is increased by 1. This process can be repeated until the value vig_cb_req1_max is reached (see chapter 3.3). The counter is reset after 24 hours. If the maximum value vig_cb_req1_max has not yet been reached, the interactive query is carried out. The selected selection areas and parameters are to be mapped to the request types in a circle-related, compass-oriented, route-related or targeted manner. Recommendations for the corresponding parameters are summarized in Section 5.5. Only one-time requests are supported as part of the CB emulation. The head office ensures the supply of particularly important VINFOs over the period VIG_T110. Requests with voice output are not supported.

Case b): No CB reception due to temporary / local unavailability of the service First the counter vig_cb_req2 is increased by 1. This process can be repeated until the value vig_cb_req2_max is reached (see chapter 3.3). The counter is reset after 24 hours. If the maximum value vig_cb_req2_max has not yet been reached, the interactive query is carried out. The selected selection areas and parameters are to be mapped to the request types in a circle-related, cardinal-directional, route-related or targeted manner. Recommendations for the corresponding parameters are summarized in Section 5.5. Only one-time requests are supported as part of the CB emulation. The head office ensures the supply of particularly important VINFOs over the period VIG_T110. Requests with voice output are not supported.

For both cases a) and b) it applies that after reaching the respective maximum value (vig_cb_req1_max or vig_cb_req2_max) interactive queries only via the service IDs 10h to 14h (see chapter 3.1.1) are permitted.

5.4.2 Selection area larger than CB area

Basically, the size of the selection areas to be set in CB is only possible through the current parameterization (see chapter 3.3 for value ranges) limited. T-Mobil is initially broadcast all traffic information with "long-distance effect" nationwide, with the repetition frequency is increased with decreasing distance to the event location. Therefore, it is also great Travel distances initially do not require an interactive request to supplement the CB information and allowed.

If it becomes necessary for capacity reasons to regionalize the CB content, all traffic information is within a radius of at least vig100_r_max km transfer. In addition, selected class 3 messages are broadcast. wishes the customer has a complete supply of traffic information about the supplied area In addition, he can carry out an interactive VINFO query. The selected ones are Setting areas and parameters related to the request types perimeter, cardinal, route-related or to map them in a targeted manner. Recommendations for the corresponding parameters are compiled in chapter 5.5. Again, as in the context of CB emulation only one-time requests supported. Requests with voice output are not supported. The This interactive query is activated via VIG_Ctrl2, A2VIG3 (see Chapter 3.4).

5.4.3 Not decodable message

The end device receives messages via the CB-VINFO service with the available reference lists (Event Codes, Geo Codes) are not decodable, can be done with the TINFO Code Request Message, a translation according to the procedure described in section 4.7.12 be requested.

5.5 Parameters for the CB service VINFO per circle

circumradius value r_loc vig250_circle_min r_reg vig250_circle_med r_überreg vig250_circle_max

The use of the parameters vig250_circle_min, vig250_circle_med, vig250_circle_max differs from the function definition in chapter 3.3. The default settings of the parameters are fixed and cannot be influenced by the customer.

Radius of the perimeter = r_loc (for value, see section 5.5 above, VINFO per circle) Radius of the sector r_seg: according to customer choice "local, regional, national", (For value, see section 5.5 above, VINFO per circle)

Direction according to the customer's choice (8 alternatives N, NO, O, SO, S, SW, W, NW)

Opening angle phi: adjustable by the customer within the range between vig250_phi_min and vig250_phi_max.

Radius of the perimeter = r_loc (for value, see section 5.5 above, VINFO per circle). Radius of the sector = dist (distance from start to finish)

Opening angle phi: adjustable by the customer within the range between vig250_phi_min and vig250_pni_max.

6 Requirements for the end devices 6.1.1 Communication

The data communication between the terminal and the control center is carried out by the GSM available short message service. To do this, the short message services SMS-MT (TS 21) and SMS-MO (TS 22) are required.

To handle the collective VINFO service, the SMS cell broadcast service must be supported become.

6.1.2 Location

The end device must have a location component (GPS receiver).

The location accuracy must be <250 m on average.

6.1.3 Storage

For the VINFO service, the terminal must at least 200 Save traffic information can.

The traffic information is to be stored in a non-volatile memory, e.g. B. after brief breaks in the journey to still be present.

The geocode table stored in the end device should be used to enter start and target positions can be used.

In order to facilitate the entry of start and destination points, a notebook should be in the end device with at least 50 entries, from which u.a. also the address description adopted can be.

6.1.4 MMI

The end device should have a text display and a convenient input option.

Recommendation for the display: 4 lines, 20 characters / line

It is recommended that, in the future, simple voice output should be possible at low cost to set up.

7 Traffic management - proposal for implementation

8 Connection of the VINFO service to the navigation service

1. Bei der VINFO-Variante streckenbezogen hat der Kunde die Möglichkeit, Verkehrsinfos für eine im Endgerät abgelegte Route anzufordern (siehe Kap. 2.1.6), die im Rahmen des Navigationsdienstes Orientierungshilfe zentralseitig berechnet und zum Endgerät übertragen wurde. Die Route wird mit der Extended TINFO Request Message als streckenbezogene VINFO-Anfrage zur Zentrale übertragen.

2. Für die VINFO-Varianten umkreisbezogen, himmelsrichtungsbezogen, zielgerichtet und streckenbezogen sowie für den VINFO-Dienst über CB ist im Endgerät neben den Sortierverfahren nach Aktualität, Fahrtrichtung/Abstand und Straßenklasse eine Zuordnungsfunktion der Verkehrsinfos zur aktuellen Route vorzusehen. Der Bezug wird über die Straßenbezeichnungen und die Korridorgeometrien der Routenbeschreibung hergestellt (siehe Kap. 3.2.1, Dienstespezifikation Navigationdienst Orientierungshilfe). Dazu sind aus dem Block 2 (Location) der TINFO die Straßenbezeichnung sowie die Geocodes der IE's first intersection und last intersection auszuwerten. Um festzustellen, ob die Route von einer vorliegenden Verkehrsinformation betroffen ist, sind alle Anschlußstellen, Kreuze und Dreiecke der referenzierten Straße, deren Geocodes zwischen den im IE first intersection und IE last intersection angegebenen Orten liegen, zu identifizieren. Die Selektion ist anhand der Straßenbezeichnung (siehe Kap. 3.2.2, Geo-Codes) sowie der Nummer (siehe Kap. 3.2.6, Geo-Codes) durchzuführen. Liegen ein oder mehrere der selektierten Geocodes innerhalb einer der Korridore der Routenbeschreibung, sollte die Verkehrsinformation als relevant betrachtet und dem Kunden zur Anzeige gebracht werden.

The following connections between the traffic information service and the navigation service for guidance are provided:

1. With the VINFO route-related variant, the customer has the option of requesting traffic information for a route stored in the terminal (see Section 2.1.6), which was calculated as part of the navigation service for orientation assistance and transmitted to the terminal. The route is transmitted to the control center with the Extended TINFO Request Message as a route-related VINFO request.

2. For the VINFO variants related to the surrounding area, the direction of the compass, targeted and route-related as well as for the VINFO service via CB, in addition to the sorting procedure according to topicality, direction of travel / distance and road class, an assignment function of the traffic information to the current route must be provided in the end device. The reference is made via the street names and the corridor geometries of the route description (see chapter 3.2.1, service specification navigation service orientation aid). For this purpose, the street name and the geocodes of the IE's first intersection and last intersection must be evaluated from block 2 (location) of TINFO. In order to determine whether the route is affected by existing traffic information, all junctions, crosses and triangles of the referenced road, whose geocodes lie between the locations specified in the IE first intersection and IE last intersection, must be identified. The selection is to be made based on the street name (see Chapter 3.2.2, Geo-Codes) and the number (see Chapter 3.2.6, Geo-Codes). If one or more of the selected geocodes are within one of the corridors of the route description, the traffic information should be considered relevant and displayed to the customer.

Claims (22)

1. Traffic information method whereby data are transmitted on request or automatically between a central control unit and a mobile subscriber unit, where the data contain traffic information which is edited and output on request or automatically by the mobile subscriber unit to the subscriber, characterized in that the traffic information is filtered at the central control unit and/or in the mobile subscriber unit to suit the individual subscriber, on the basis of a geometrical selection region selected by the subscriber or a route section selected by the subscriber, the traffic information being classed according to priority and also filtered on the basis of its classification.
2. Method according to Claim 1, characterized in that the editing and provision of the traffic information are tailored to the individual needs of the subscriber.
3. Method according to Claim 1, characterized in that the size of the selection region is definable by the subscriber.
4. Method according to any one of Claims 1 to 3, characterized in that the data are transmitted for information-gathering and/or information-transmission purposes and/or for information updating.
5. Method according to any one of Claims 1 to 4, characterized in that the data are related to the widest variety of initial parameters such as location, starting-point or destination information, journey route information, or inquiries originated at the central unit or terminal, by devices or persons.
6. Method according to any one of Claims 1 to 5, characterized in that the data are transmitted via a GSM mobile radio network.
7. Method according to any one of Claims 1 to 6, characterized in that the data are transmitted via the short message service (SMS) of the GSM mobile radio network.
8. Method according to any one of Claims 1 to 6, characterized in that the data are transmitted via the telephone service.
9. Method according to any one of Claims 1 to 6, characterized in that the data are transmitted in the form of a CB broadcast message.
10. Method according to any one of Claims 1 to 9, characterized in that traffic information from different sources is collected, edited and individually compiled for the particular subscriber.
11. Method according to Claim 10, characterized in that traffic information centres, provincial reporting points and traffic congestion spotters are used as sources for the traffic information.
12. Method according to Claim 10, characterized in that fixed detection systems are used as source for the traffic information.
13. Method according to Claim 10, characterized in that the subscribers of the traffic information system itself are used as source for the traffic information.
14. Method according to any one of Claims 1 to 13, characterized in that the traffic information is sorted in the mobile subscriber unit by recency, driving-direction/proximity and road classes.
15. Method according to any one of Claims 1 to 14, characterized in that the data are communicated to the subscriber visually and/or audibly.
16. Method according to any one of Claims 1 to 15, characterized in that the subscriber's location is pinpointed by a position-fixing component.
17. Traffic information arrangement wherein at least one central control unit and at least one mobile subscriber unit are provided, wherein a mobile communication system is provided by which traffic information is transmitted on request or automatically between the central control unit and the mobile subscriber unit, characterized in that means are provided at the central control unit and/or in the mobile subscriber unit whereby the traffic information is filtered to suit the individual subscriber, on the basis of a geometrical selection region selected by the subscriber or a route section selected by the subscriber, the traffic information being classed according to priority and also filtered on the basis of its classification.
18. Arrangement according to Claim 17, characterized in that the mobile communication system is a GSM-compatible mobile radio system.
19. Arrangement according to Claim 17 or Claim 18, characterized in that the mobile subscriber unit contains a terminal device of the GSM mobile radio system.
20. Arrangement according to any one of Claims 17 to 19, characterized in that a position-fixing component is included in the mobile subscriber unit.
21. Arrangement according to Claim 20, characterized in that the position-fixing component is a GPS receiver.
22. Arrangement according to any one of Claims 17 to 21, characterized in that the mobile subscriber unit also comprises a data processing facility, a memory, an input unit and an output unit.