WO1998026395A1 - Verfahren und anordnung zur verkehrsinformation - Google Patents

Verfahren und anordnung zur verkehrsinformation Download PDF

Info

Publication number
WO1998026395A1
WO1998026395A1 PCT/DE1997/002871 DE9702871W WO9826395A1 WO 1998026395 A1 WO1998026395 A1 WO 1998026395A1 DE 9702871 W DE9702871 W DE 9702871W WO 9826395 A1 WO9826395 A1 WO 9826395A1
Authority
WO
WIPO (PCT)
Prior art keywords
traffic information
vinfo
traffic
message
tinfo
Prior art date
Application number
PCT/DE1997/002871
Other languages
English (en)
French (fr)
Other versions
WO1998026395B1 (de
Inventor
Rolf Beyer
Oliver LÖHMER
Stephan Knechtges
Original Assignee
Detemobil
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=7814137&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO1998026395(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Detemobil filed Critical Detemobil
Priority to AU56506/98A priority Critical patent/AU5650698A/en
Priority to AT97952712T priority patent/ATE223607T1/de
Priority to DK97952712T priority patent/DK0883871T3/da
Priority to DE59708132T priority patent/DE59708132D1/de
Priority to EP97952712A priority patent/EP0883871B1/de
Publication of WO1998026395A1 publication Critical patent/WO1998026395A1/de
Publication of WO1998026395B1 publication Critical patent/WO1998026395B1/de

Links

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/091—Traffic information broadcasting
    • G08G1/092—Coding or decoding of the information
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/091—Traffic information broadcasting
    • G08G1/093—Data selection, e.g. prioritizing information, managing message queues, selecting the information to be output

Definitions

  • data can be related to various output parameters, e.g. Location, start or destination information or route information of the trip, central or terminal-side queries that can be carried out with the aid of devices or people.
  • the data transmissions can be carried out for information acquisition purposes and / or for information transmission purposes as well as for information update.
  • the present traffic information service can be offered in particular in the service versions “interactive VINFO” (via targeted SMS short messages and / or telephony) and “collective VINFO” (via SMS short message broadcasting CB).
  • the interactive traffic information service enables the customer to call up current and reliable information on traffic events tailored to his individual needs.
  • the customer can request traffic information, in particular about a geometric selection area or explicitly about a route.
  • the traffic information is preferably filtered in a customer-specific center.
  • the traffic information is then sent to the end device via SMS short messages (output via display) or imported into an audio text system (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, but the filtering takes place in the end device.
  • the output of traffic information via the audiotext system is not supported.
  • Traffic information can be collected from various sources, processed and compiled individually for the individual customer.
  • a stationary detection system on motorways can be set up, which uses sensors to determine the traffic density and flow.
  • mobile traffic data acquisition via VINFO customers' vehicles can provide the most comprehensive and detailed traffic information.
  • precise information about the subordinate road network will also be available.
  • VINFO perimeter (parameterized by the EC)
  • the customer should have the choice of requesting traffic information once or being provided with automatic updates of traffic information (see Section 4.1).
  • TINFO traffic information
  • 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 GmbH-Königsforst and AS Lohmar”).
  • cause e.g. "due to accident”
  • information e.g. "Please drive in the right lane”
  • duration of the event e.g. "for 2 h”
  • diversion note e.g. "Please use the U 45 "from the ASchen-Königsforst, as well as additional location information (e.g.” Start of traffic jam 3 km to the AS GmbH-Königsforst ").
  • the information available at the head office on a traffic disruption (cause (s), notice (s), diversion recommendation (s) etc.) is sent to the customer in full.
  • 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.
  • Priority 4 -> Class 4 warning messages e.g. ghost driver, lost cargo
  • 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. Medium-impact traffic information is typically medium-sized traffic jams on federal and state roads. Local traffic information is typically small traffic jams that only have a local impact. So z. B. A traffic jam of 1 km in length can be assigned to a class 1 motorway 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
  • priorities 1 to 3 are not evaluated by the terminal. Traffic information of these classes is filtered centrally according to the selected VINFO variant (see chapters 2.1.4 to 2.1.6). With the VINFO service via CB, all priorities are evaluated (see Chapter 5).
  • 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 long-distance network. This avoids "overwhelming the customer" with irrelevant traffic information and avoids high communication costs, especially for audio text.
  • the traffic information is sent to the end device via SMS.
  • the traffic information should be stored in a non-volatile list in the terminal. 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.
  • 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:
  • the list should be sorted 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.
  • the traffic information is set in the audio text system.
  • the traffic information is always sent to the end device via SMS.
  • the TINFO Speech Message contains all traffic information relevant to the customer in the sorting order that is used for the 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 outputting audio text.
  • the data structure of the traffic information is in Chap. 4.7 and in ADP TINFO.
  • the VINFO service variant (parameterized by the control center) is used to query traffic information from a circular selection area around the start position (current position or explicitly selected start position). Any coordinates in the specified format are permitted as the explicitly selected start position.
  • the start selection is made, for example, via cities from the geocode list or addresses from the personal address book. When selecting from the list of geocodes, the geocode must be converted into the corresponding coordinates.
  • VINFO the user has the following three options with regard to the size of the circumference:
  • VINFO local traffic information for classes 1 to 4 within district / sector
  • Traffic information to r_loc to r_reg traffic information Kl.2 - 4 long-distance network r_reg to r_überreg traffic information Kl. 3 - 4
  • 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.
  • cardinal direction-related VINFO cardinal direction-related VINFO
  • the customer has 8 possible alternatives (N, NO, E, SO, S, SW, W, NW).
  • VINFO service variant related to the cardinal direction is planned on the central side, 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.
  • VINFO related to the compass direction default setting "long-distance network"
  • the customer chooses the service-oriented VINFO, he receives traffic information from a selection area that contains the start position (current position or explicitly selected start position) and the selected destination. 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.
  • the control center also filters within the selection area according to classes of traffic information.
  • the customer receives traffic information from classes 1 to 4 in its immediate vicinity ("local" circle, see Section 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.
  • VINFO service variant 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.
  • the route can be a manually entered sequence of roads or a route stored in the terminal.
  • the identifier and number of the street or several streets 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. Schotiere No) is not supported.
  • start position current position or explicitly selected start position
  • 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.
  • VINFO route-related all traffic information for the selected roads is selected within a rectangular selection area that contains the start and destination positions.
  • the customer should be able to select a route stored in the end device (see service specification navigation service orientation guide).
  • This route is to be converted into a sequence of streets with start and destination positions and can therefore be transmitted with the same VINFO request as for the manually entered route (see Section 4.6).
  • VINFO route-related the customer receives traffic information of all classes 1 to 4 for the selected route. There is no filtering by long-distance network or similar.
  • 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.
  • Terminal interacting with the central, usually mobile system for handling telematics services
  • Event code Clear definition and identification of events, original items and information for traffic information reports (see specification of the same name)
  • Geo code Clear definition and identification of a geographical object using coordinates (see specification)
  • VTG traffic telematics (terminal) device (see terminal) • Central system provided by the service provider for handling telematics services.
  • TINFO ADP Traffic Information
  • the transport frame for the message types is defined in:
  • the current version numbers of the listed documents are passed on to the partners of the service providers with each change.
  • the transport protocol is used as follows to use the interactive traffic information service:
  • the transport frame supports the sending of user data across several short messages.
  • the procedure is specified in the "Transport Protocol” document. ⁇ l
  • Service identifiers are unique address information assigned by the control center for routing between the communication interface and the applications. These are transferred in 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 is restricted. Service identifiers are assigned to identify the services offered. The service identifiers are listed in the separate service specifications.
  • the following service identifiers are used for the traffic information service: interactive VINFO service
  • Initiative Flag 1 (Initiative) marks the first transaction in the chain, the order.
  • the Initiative Flag 1 (Initiative).
  • Protocol Discriminator and Message Type can be found in the document "Message Type Numbering".
  • the bulk flag is always set to 0.
  • T-Mobile 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.
  • changes to the basic specification are indicated by non-italic, bold font and by a gray background.
  • VIG_Ctrl1 is broken down in the following table:
  • VIG_Ctrl2 is broken down in the following table:
  • Chapter 4 describes the request process for output on a display (basic process). The procedure for the audio text output is separately in Chap. 4.1.6.
  • the customer selects the desired VINFO variant on the end device.
  • the terminal then sends the corresponding TINFO request message and receives a traffic information message, TINFO deletion message or text message from the control center. In the event of an error, a corresponding error message is transmitted to the terminal.
  • the version numbers of this traffic information are transmitted to the control center with the corresponding TINFO request message for all VINFO variants.
  • the head office only sends back new or updated traffic information (with the Traffic Information Message) or sends back the version numbers of the TINFOs to be deleted with the TINFO Deletion Message.
  • 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).
  • the end device 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.
  • the IE update duration (see ADP TINFO, section 5.5) of the corresponding message is set to "no update" (0x0).
  • the terminal periodically sends requests for traffic information with the corresponding TINFO request message.
  • the IE update duration is set to "no update" (OxO).
  • the control center responds once to each request with the corresponding response message.
  • Update-Timer is started trigger any TINFO request message
  • Traffic Information Message new or changed TIN or FOs
  • the end device sends the corresponding TINFO request message, the IE update duration being set to the update duration.
  • the head office transmits the traffic information and its updates within the update duration.
  • Event Code / Geo Code Only Event Code / Geo Code is supported as the output format by default. If the terminal cannot interpret an event code / geo code, a translation into plain text is requested. The exact procedure is described in the separate service specifications.
  • the update of traffic information is a combination of a device-controlled update (see Section 4.1.2) and a central-controlled update (see Section 4.1.3).
  • the customer should choose "Update traffic information" by entering "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. if the destination is reached early).
  • the terminal In update mode, the terminal periodically makes requests for 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 defines the time request period of the end device. If the vehicle has covered a distance within a period of time that exceeds the threshold vig_up_dist (see Section 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 threshold for the distance covered is determined by vig_up_dist (default value 50 km).
  • the threshold value is a recommendation and should be freely selectable within the range.
  • the IE update duration is set to "000001". (This code is not interpreted by the control center as an update of 30 min, as described in the ADP TINFO.)
  • the head office answers each of the periodic VINFO requests immediately with the corresponding reply message.
  • the VINFO request is flagged in the head office for a booking time (greater than or equal to the maximum request period vig_up_per_max). If there are important changes to the traffic situation in the relevant selection area before the booking timer expires (e.g. the emergence of a new traffic jam due to an accident) or if there is a warning message for the area in question (e.g. ghost driver), the head office will send traffic information on its own initiative Message or TINFO deletion message.
  • the terminal evaluates the messages initiated at the center and displays the traffic information.
  • VINFO request is deleted from the head office. This completes the order on the central side. Hits a new periodic VINFO request with an update te-duration code 000001 in the head office, this request is noted again and a new booking timer is started.
  • the terminal device sends the version numbers of known, valid traffic information with each of the periodic VINFO requests.
  • the version numbers known to the terminal are noted in the head office for the time of the booking timer.
  • the head office only transmits new or updated traffic information.
  • the combination of a device-controlled update and a centrally 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.
  • 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 uniform for the different VINFO variants.
  • the traffic information is transmitted to the end device via SMS, as in the basic display output procedure.
  • the output mode of the corresponding TINFO request message is therefore always set to "data and speech" when audio text is output.
  • the request process for the output of audio text is thus an extension of the basic process of display output (see chapters 4.1.1 to 4.1.5).
  • the control center After receiving a corresponding TINFO request message, the control center sends a TINFO speech message in addition to the traffic information message and TINFO deletion message to indicate that traffic information is available in the audio text system.
  • the terminal now also sets up a Speech Connection (MO) to enable traffic information to be listened to.
  • MO Speech Connection
  • the TINFO Speech Message always contains 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 outputting audio text.
  • 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 aNe traffic information relevant to the customer in the current sorting (analogous to the T-Traffic update: important message with the Traffic Information Message, aNe relevant traffic information in the current sorting with the TINFO Speech Message).
  • a text message with IE status 03h (no traffic news) or 04h (Situation on roads has not changed) is transmitted.
  • the automatic establishment of a voice connection from the end device should not apply after receipt of the text message with IE status 03h or 04h.
  • the request process for audio text output for the T-Mobile update results from the extension of the basic process (Section 4.1.5) to include the transmission of the 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 worthy of notification from a circular selection area with a range from vig250_circle_min km to vig250_circle_max km (see Section 3.3).
  • the parameters radius and reference point are to be transmitted to the service provider.
  • Table 4-1 VINFO parameters related to the circuit (parameterized by the terminal)
  • the customer receives traffic information from a circular or sector-shaped selection area. If a cardinal direction is specified, traffic information is selected from a sector aligned with this cardinal direction. If no direction is given, traffic information is selected from a circular area.
  • the customer has three choices
  • a start position can be entered.
  • the customer selects one of the local / regional / national variants.
  • the customer is asked to confirm the current position as the start 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.
  • VINFO direction-related the customer selects a direction (8 possible alternatives: N, NO, E, SO, S, SW, W, NW).
  • the default setting is "Traffic information on long-distance network”. Alternatively, the customer can select "Traffic information on all roads”.
  • 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.
  • the end device compiles the Relative Regional TINFO Request Message (see Chapter 4.3.1) and transmits it to the head office.
  • the head office 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).
  • the control center transmits the filtered 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).
  • the traffic information is sorted and displayed by the end device according to the selected sorting method (see section 4.9).
  • the list of traffic information is saved in the terminal.
  • the head office notes the VINFO request and sends a traffic information message or TINFO deletion message on submission 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. 3ß 4.3.1 Coding of 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:
  • VINFO based on a segment of a circle
  • the customer receives traffic information from a selection area in the form of a segment 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.
  • the opening angle of the selection area is determined by the basic settings of the end device (e.g. 30 °) and lies between vig250_phi_min and vig250_phi_max.
  • the opening angle can be set in 1 "steps.
  • the customer receives traffic information from a selection area that contains the current position and the target position. To do this, the customer enters the target position.
  • the exact definition of the geometry and orientation of the selection area is done at the headquarters.
  • a start position can be entered. If the start position is not used, it must be set to 0.
  • TINFO Deletion Message deleted TINFOs The choice of the targeted VINFO service variant is typically carried out as follows:
  • the customer selects the destination from the geocode city list stored in the end device or from his personal address book.
  • the address book When selecting from the address book, the coordinates of the address are to be converted into the corresponding geocode.
  • the customer is asked to confirm the current position as the start 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 must be converted into the corresponding geocode.
  • the default setting is "Traffic information on long-distance network”. Alternatively, the customer can select "Traffic information on all roads”.
  • the customer is given the option of requesting an automatic update of the traffic information.
  • a switch "Update mode on / off" or the entry of a duration for the update mode is offered.
  • the update mode can be deactivated manually at any time.
  • the end device compiles the Extended TINFO Request Message (see Chapter 4.5.1) and transmits it to the control center.
  • the head office 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).
  • the control center transmits the filtered 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).
  • the traffic information is sorted and displayed by the end device according to the selected sorting method (see section 4.9).
  • the list of traffic information is saved in the terminal.
  • the head office notes the VINFO request and sends a traffic information message or TINFO deletion message on submission 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. 2M 4.5.1 Coding of the Extended TINFO Request Message with VINFO targeted
  • the Extended TINFO Request Message (see Chapter 3.2, ADP TINFO) is encoded in a targeted manner at VINFO as follows:
  • the customer receives traffic information on a selected route.
  • the route can be a street or a series of streets.
  • 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.
  • 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.
  • the route variant VINFO is typically selected as follows:
  • the customer selects between the variants "Manual entry of a route” and “Selection of a saved route”.
  • the customer selects the destination from the geocode city list stored in the end device or from his personal address book.
  • the coordinates of the address must be converted into the corresponding geocode.
  • the customer is asked to confirm the current position as the start 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. Enter the street (s)
  • the customer is asked 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.
  • the customer is given the option of requesting an automatic update of the traffic information.
  • a switch "Update mode on / off" or the entry of a duration for the update mode is offered.
  • the update mode can be deactivated manually at any time.
  • the end device compiles the Extended TINFO Request Message (see Chapter 4.6.1) and transmits it to the control center.
  • the head office After receiving the VINFO request, the head office filters out 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 according to the long-distance network or similar).
  • the control center transmits the filtered 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).
  • the traffic information is sorted and displayed by the end device according to the selected sorting method (see section 4.9).
  • the list of traffic information is saved in the terminal.
  • the head office notes the VINFO request and sends a traffic information message or TINFO deletion message on submission 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.
  • the VINFO encodes the Extended TINFO Request Message (see Chapter 3.2, ADP TINFO) as follows:
  • the traffic information that is sent to the end device with the Traffic Information Message consists 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), Agreement Speed (mean speed at the location of the event) and Event position (exact Position of the event).
  • 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 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, further 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):
  • 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 refer to the first event block.
  • a TINFO always describes only one traffic disruption. Accordingly, the optional blocks deliver cause, hint, duration, bypass, average Speed and event position Additional information on the traffic disruption and thus always reference the first event block.
  • General information type block 1 according to ADP TINFO
  • Duration period of validity of the traffic information, e.g. estimated lifespan of an event; the period of validity 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), redirection notice
  • Geocodes Location information for traffic information is transmitted by geocodes.
  • the structure of the geo-code tables that are to be stored in the terminal is described in detail in the document “Geo-Codes: Description of the Contents and Structure of the Terminal Tables”.
  • the geo-code table will initially be created for the area of Germany (the procedure can, however, be applied across Europe) and will cover all federal highways and federal highways that directly connect interrupted highways (road nodes) in the first implementation stage.
  • the German trunk road core network is thus described by geocodes.
  • at least all important cities are geocoded.
  • the geo-code table contains:
  • Geo-Code-Tvp e.g. junction, motorway junction, motorway triangle, border crossing, city
  • Event codes free text in exceptional cases
  • Event Codes The following main groups of event codes are defined in the “Event Codes” document (these can denote events, causes, notices or redirection notices):
  • Weather e.g. black ice, frosty frost, fog
  • the main groups can be used to label the message accordingly when presenting the traffic information (eg "Warning: black ice”).
  • traffic information eg "Warning: black ice”
  • Many event codes are assigned quantifiers with which, for example, the length of a traffic jam or the duration A traffic report can be coded in the ADP TINFO, however, only in block 3 (event) and block 7 (bypass) quantifiers can be set.Notes and causes, which are provided with quantification, are therefore coded as optional (additional) block 3 (event) (e.g. "waiting time 2h").
  • Type 1 km e.g. B. 6 km traffic jam
  • Type 5 phrases e.g. "short term”, “partial”, “in parts”, etc.
  • Type 8 is reserved for diversion quantifiers (see section 4.7.7).
  • Type 6 is reserved for Mannesmann Autocom.
  • the transmission of the average speed for a section of the route does not take place via event code and quantifier, but via block 8 (average speed).
  • Example 1 A3, Cologne to Frankfurt, between AK Bonn / Siegburg and AS Siebengebirge
  • This block is used to identify a traffic report. It sets the priority and uses the Bypass Information flag to provide information about the existence of a redirection recommendation from the service provider.
  • the block contains
  • TINFO 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
  • the parameter A2VIG2 controls the meaning of the bypass information flag.
  • T-Mobil does not support the query of redirection recommendations via the bypass request message. Rather, if the Bypass Information flag is set, it is recommended that the navigation service Orientation Guide perform a route calculation for a detour route (only possible for end devices that also support navigation services).
  • This block defines the location of the traffic information.
  • the location can be encoded in different ways. If the event is between two defined points (e.g. AS GmbH-Süd and AS-Köln-Poll), the IE First Intersection and Last Intersection are set with the corresponding geocodes. Only the standard location block (see chapter 4.2.1, ADP) is supported, not the special location block (see chapter 4.2.2, ADP).
  • coding is as follows:
  • the additional information can be transmitted at what distance from the IE first intersection the event is (eg traffic jam "10 km” to AK Bonn / Siegburg ").
  • Event Type 1 Event codes or text stored in the end device
  • Event Type 2 Event Type 2
  • Events that are stored in the event code list are described by the event code, otherwise plain text. Events that can be quantified are described using the quantifiers, 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 hints / causes, which, however, must be set with block 3 (event) due to the quantifier (e.g. waiting time 2h).
  • coding is as follows:
  • Type 1 1 traffic jam ($ 080) 5 km
  • coding is as follows:
  • 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.
  • coding is as follows:
  • T-Traffic 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 p.m. to 4 p.m.).
  • Block 6 (duration) refers to the 1st event block. It therefore only occurs once in TINFO.
  • a diversion notice can be set in this block.
  • Forwarding instructions are supported as event codes (for forwarding instructions) or as plain text.
  • Location information is supported as geo code or via IE Street. S
  • the bypass block can exist regardless of the bypass flag.
  • the bypass block is used in particular to transmit the official diversions, coded using the event codes from the diversion main group (coding example see below).
  • the building block Additional Information is used to set the quantifiers for diversion notices coded by event codes.
  • the order of the set quantifiers corresponds to the order of the placeholders in the event code list (see example).
  • Block 8 (Average Speed) refers to the 1st event block. It therefore only occurs once in TINFO.
  • Block 9 (event position) refers to the 1st event block. It therefore only occurs once in TINFO.
  • the block FCD flag is not supported.
  • the end block shows the end of the TINFO.
  • the end device If the end device cannot decode parts of traffic information (event code / geo code that is not contained in the event code / geo code table of the end device), it requests a translation of the unknown code (s) into plain text.
  • the end device sends a TINFO Code Request Message (see Chapter 3.6, ADP TINFO) to the control center.
  • a translation block is set for each unknown code. Only 0 (event code) and 1 (geo code) are supported as source format. Only 0 (text) is supported as the destination format.
  • the control center sends back the translation of the code (s) with the TINFO Code Message (see Chapter 2.2, ADP TINFO).
  • An explanation block is set for each translated code. Only 0 (event code) and 1 (geo code) are supported as source format. Only 0 (text) is supported as the destination format.
  • VINFO output media audio text or display as well as audio text and display (simultaneously).
  • the audio text output by the head office offers the customer the advantage of listening to the desired information while driving, without having to take his eyes off the traffic.
  • the simultaneous output via audio text and display can also be useful for the customer (e.g. for more precise scrolling through the messages), especially from the point of view of the automatic storage of relevant, current messages in the end device.
  • 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 Section 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 the traffic information on the display.
  • the output medium audio text / display or audio text and display should be adjustable by the customer in the event of a VINFO request (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 lead to e.g. the first entry (destination etc.) must be repeated. "Audiotext" is proposed as the default for cases in which there is no separate, large display.
  • control center also sends all messages via SMS (even if the customer selects audio text alone), so that a complete, up-to-date list of traffic reports is always available in the terminal and the customer after a short absence when changing from audio text to display or when switching on the terminal List is immediately available without a new VINFO request.
  • T-Mobil proposes the following procedure for a corresponding user menu to sort the traffic information and its updates in the terminal:
  • 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 (e.g. if he wants to make sure).
  • the customer With audio output, the customer establishes a voice connection via the menu item.
  • 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.
  • Warning messages always have the highest priority and must be displayed or given priority. A warning tone or the like would be sensible.
  • the traffic information transmitted to the terminal device should be presented to the customer in the clearest possible form on the display of the terminal device, so that it can be detected as quickly as possible and to minimize a possible distraction effect.
  • Each traffic information is made up of a number of blocks (see section 4.7).
  • the display capacity of a display is naturally limited.
  • the full wording of the event codes / geo codes need not necessarily be shown; rather, the implementation in meaningful abbreviations is expressly suggested.
  • the corresponding rules and symbols for abbreviations are to be implemented for specific devices.
  • an automatic mode should support the 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 special characters e.g. +, -, * , #, ⁇ ,>, etc. should also be displayed.
  • a key press should at the same time trigger the background lighting of the display for a certain period of time (at least reading one page).
  • the cover of the display should be non-reflecting, so that the information can be read easily even when the device is at an angle. Graphics capability is not required to display traffic information (unlike with the navigation service, orientation aid).
  • the output of traffic information via audio text is more advantageous and safer than reading from the display. If the customer uses the update (Chapter 4.1.5) for longer journeys, for example, the selected traffic information for his route is given to him.
  • T-Mobil's central audiotext system supports rapid 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 must be supported by the terminal.
  • DTMF tone dialing
  • the user should be able to jump back and forth between individual messages and the different menu levels with only one device command if possible (e.g. via skip switch or cursor cross).
  • a remote control from the steering wheel can only be welcomed from the point of view of traffic safety.
  • the VINFO Cell Broadcast Sub-Service is a broadcast service in which all traffic information within a radius of at least vig100_r_max km is transmitted via cell broadcast in the GSM network.
  • the traffic information is sent cyclically in a time grid of less than 15 minutes as a VINFO data telegram "Traffic Information Message" - Message Type 0x01, Protocol Discriminator 0x03 -.
  • VINFO data telegram "Traffic Information Message" - Message Type 0x01, Protocol Discriminator 0x03 -.
  • the individual messages are based on their version number (ID + Time Stap) clearly identifiable (same identifier for interactive and collective service).
  • the data can be encrypted in cell broadcast mode.
  • the type of encryption is determined in the CAS framework for cell broadcast operation in which the user data is embedded.
  • the customer should use the VINFO service via cell broadcast in the same way as the interactive VINFO service. For this reason, the selection criteria for circle-related VINFO, cardinal direction-related VINFO, targeted VINFO and route-related VINFO should also be supported.
  • the menu structure should be identical to that of the interactive VINFO services.
  • the corresponding area filters for VINFO CB must be implemented on the end device side. 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, for querying messages that are outside the current CB-VINFO coverage area and for translating non-decodable messages (see Section 5.4).
  • Each traffic report is assigned an expiry time.
  • the expiry time begins with the receipt of the data telegram in which the traffic report occurs. After the expiry of the expiry date, the traffic announcement becomes invalid and must be deleted.
  • the service provider constantly sends the current traffic events for the broadcasting area via cell broadcast.
  • Traffic announcement has priority 1 (OxOO)
  • Traffic announcement has priority 2 (0x01)
  • Traffic announcement has priority 3 (0x02)
  • Traffic announcement has priority 4 (0x03)
  • All existing messages (priority classes 1 to 4, all road classes) for a range of at least vig_100_r_max km (radius) are distributed via CB based on the current vehicle position. 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.
  • the messages are decoded using the reference tables (event and geo codes).
  • 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 the current CB-VINFO coverage area, and to translate non-decodable messages.
  • the traffic reports queried interactively from the CB mode are treated like regular CB reports with regard to priority, expiry time, etc.
  • the timers T1 10 and T111 are used to control the CB emulation.
  • T1 10 is reset and received again when each CB data telegram is received. If T1 10 reaches its maximum value VIG_T110 without another CB data telegram having been 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.
  • n 1 ... VIG_T1 1 1 / VIG_T1 10.
  • 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 must be mapped to the query 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.
  • 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.
  • the size of the selection areas to be set in CB is only limited by the current parameterization (see chapter 3.3 for value ranges).
  • T-Mobil will initially broadcast all traffic information with a "long-distance effect" nationwide, with the repetition frequency increasing as the distance to the event location increases. Therefore, even for long travel distances, no interactive request to supplement the CB information is necessary and permitted.
  • vig250_circle_min vig250_circle_med
  • 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 rjoc (value see above, section 5.5, VINFO related to the radius) Radius of the sector r_seg: according to customer choice "local, regional, supra-regional", (value see above, section 5.5, VINFO related to the area)
  • Opening angle phi adjustable by the customer within the range between vig250__phi_min and vig250_phi_max.
  • Opening angle phi adjustable by the customer within the range between vig250_phi_min and vig250_phi_max. 3
  • the data communication between the terminal and the control center is handled by the short message service available in GSM.
  • the short message services SMS-MT (TS 21) and SMS-MO (TS 22) will be required for this.
  • the SMS Cell Broadcast service must be supported.
  • the end device must have a location component (GPS receiver).
  • the location accuracy must be ⁇ 250 m on average.
  • the terminal must be able to store at least 200 traffic information for the VINFO service.
  • the traffic information is to be stored in a non-volatile memory, e.g. B. to be present after short breaks.
  • the geocode table stored in the end device should be able to be used to enter start and target positions.
  • a notebook with at least 50 entries should exist in the end device, from which, among other things, the address description can also be adopted.
  • the end device should have a text display and a convenient input option .
  • the customer has the option of requesting traffic information for a route stored in the end device (see Section 2.1.6), which was calculated as part of the navigation service orientation aid and transmitted to the end device.
  • the route is transmitted to the control center with the Extended TINFO Request Message as a route-related VINFO request.
  • 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).
  • the street name and the geocodes of the I ' s first intersection and last intersection are to be evaluated from block 2 (location) of TINFO.

Abstract

Beschrieben wird ein Verfahren zur Verkehrsinformation, wobei auf Anfrage und/oder automatisch Daten zwischen einer Zentraleinheit und einer mobilen Teilnehmereinheit übertragen werden. Weiter wird eine Anordnung zur Verkehrsinformation beschrieben, wobei mindestens eine Zentraleinheit sowie mindestens mehrere mobile Teilnehmereinheiten vorgesehen sind.

Description

2 Einleitung
Verfahren und Anordnung zur Verkehrsinformation
Durch das stetig wachsende Verkehresaufkommen wird der Bedarf an hochwertigen Systemen zur Verkehrsinformation und Verkehrsleitung immer dringlicher. Dabei ergeben sich jedoch die Probleme, wie dem Benutzer stets aktuelle Informationen zur Verfügung gestellt werden können, die ihm gleichzeitig einen hohen Benutzerkomfort bieten.
Diese Problematik wird gelöst durch die Merkmale der Patentansprüche 1 und 2. Weitere mögliche Ausgestaltungsformen der Erfindung sind der nachfolgenden Beschreibung entnehmbar. Insbesondere können Daten auf verschiedenste Ausgangsparameter bezogen werden, z.B. Orts-, Start- oder Zielinformationen bzw. Streckeninformationen der Fahrt, zentrale- oder endgeräteseitige Abfragen, die gerätegestützt oder personengestützt durchgeführt werden können. Die Datenübertragungen können zu Informationserfassungszwecken und/oder zu Informationsübertragungszwecken wie auch zur Informationsaktualisierung durchgeführt werden.
Der vorliegende Verkehrsinformationsdienst kann insbesondere in den Diensteausprägungen „interaktive VINFO" (über gezielte SMS-Kurznachrichten und/oder Telefonie) und „kollektive VINFO" (über SMS-Kurznachrichten-Rundfunk CB) angeboten.
Der interaktive Verkehrsinformationdienst (VINFO) ermöglicht dem Kunden ein auf seine individuellen Bedürfnisse zugeschnittenes Abrufen von aktuellen und zuverlässigen Informationen zum Verkehrsgeschehen. Der Kunde kann Verkehrsinformationen insbesondere zu einem geometrischen Selektionsgebiet oder explizit zu einer Strecke anfordern. Die Verkehrsinformationen werden vorzugsweise in einer Zentrale kundenindividuell gefiltert. Anschließend werden die Verkehrsinfos per SMS-Kurznachrichten gezielt zum Endgerät übertragen (Ausgabe über Display) bzw. in ein Audiotext-System eingespielt (bei Audio-Ausgabe über einen Telefonie-Sprachkanal z.B. in GSM).
Der kollektive VINFO-Dienst ist funktional und inhaltlich gleich wie der interaktive VINFO- Dienst, jedoch findet die Filterung im Endgerät statt. Die Ausgabe von Verkehrsinformationen über das Audiotext-System wird nicht unterstützt.
Verkehrsinformationen können aus unterschiedlichen Quellen gesammelt, aufbereitet und individuell für die einzelnen Kunden zusammengestellt werden.
Neben offiziellen Verkehrsinformationslieferanten wie Verkehrsinformationszentralen und Landesmeldestellen kann auf private Lieferanten (mobile Staumelder, etc.) zurückgegriffen. Zusätzlich oder alternativ kann ein stationäres Erfassungssystem auf Autobahnen (BAB) errichtet werden, das mit Hilfe von Sensoren die Verkehrsdichte und den Verkehrsfluß bestimmt. Darüber hinaus kann die mobile Verkehrsdatenerfassung über die Fahrzeuge der VINFO-Kunden die umfassendsten und detailliertesten Verkehrsinformationen liefern. Neben dem BAB-Netz werden damit auch präzise Informationen über das nachgeordnete Straßennetz vorliegen.
Die in der Zentrale vorgehaltenen Datenbestände werden damit in kürzester Zeit ein Vielfaches der heute vorhandenen Verkehrsdaten betragen. Aufgabe des VINFO-Dienstes ist es daher, den Kunden mit Hilfe geeigneter Filtermechanismen nur mit den Verkehrsinformationen zu versorgen, die ihn direkt betreffen. Das „Überschütten des Kunden mit Verkehrsinfos" wird somit vermieden. • 2.1 Übersicht über die angebotenen Dienste
Grundsätzlich können Informationen zu einem geometrischen Gebiet oder explizit zu einer Strecke abgefragt werden. In diesem Dokument werden folgende Diensteanfragen beschrieben:
• Umkreisbezogene VINFO (vom EG parametriert)
• Umkreisbezogene VINFO (von Zentrale parametriert)
• Kreissegmentbezogene VINFO
• Zielgerichtete VINFO
• Streckenbezogene VINFO
Eine grundsätzliche Beschreibung der Diensteanfragen findet sich auf den folgenden Seiten. Eine detaillierte Beschreibung der Abläufe ist den anbieterspezifischen Dienstespezifikationen zu entnehmen.
Die beiden folgenden Abschnitte geben einen Überblick über die verschiedenen Diensteausprägungen.
2.1.1 Unterstützte Dienste Alternative 1
Anfra e Art Diensteaus rä unc Interne Bezeichnun
Figure imgf000004_0001
2.1.2 Unterstützte Dienste Alternative 2
Anfraαe Art Diensteausoräαunc Interne Bezeichnunc
Figure imgf000004_0002
In der vorliegenden Spezifikation werden ausschließlich die in der Spalte „Diensteausprägung" genannten Bezeichnungen verwendet.
Zusätzlich kann die Dienstevariante Himmelsrichtungsbezogene VINFO geboten werden die als Spezialfall von Umkreisbezogene VINFO (von Zentrale parametriert) realisiert und in den Kap. 2.1.4 und 4.3 beschrieben wird.
Der Kunde soll bei allen VINFO-Varianten die Auswahl haben, Verkehrsinformationen einmalig anzufordern oder mit automatischen Updates von Verkehrsinfos versorgt zu werden (siehe Kap. 4.1).
In den nachfolgenden Kapiteln werden die Verkehrsinformationen sowie die VINFO-Varianten kurz beschrieben. Eine ausführliche Beschreibung der interaktiven Dienstevarianten findet sich in Kapitel 3. Die kollektiven Dienstevarianten werden in Kap. 5 beschrieben.
2.1.3 Verkehrsinformationen
Meldungen über die Verkehrslage in dem vom Kunden ausgewählten Selektionsgebiet werden als Verkehrsinformationen (TINFO) bereitgestellt.
Jede Verkehrsinformation besteht aus dem Ereignis selbst (z. B. „5 km Stau") sowie dem Ort des Ereignisses (z. B. „auf der A 3 Köln nach Frankfurt zwischen AS Köln-Königsforst und AS Lohmar"). Optional können Ursache (z. B. „wegen Unfall") und Hinweise („Bitte fahren Sie auf der rechten Spur"), Dauer des Ereignisses (z. B. „für 2 h") , Umleitunαshinweis (z. B. „Bitte benutzen Sie ab AS Köln-Königsforst die U 45"), sowie zusätzliche Ortsangaben (z. B. „Staubeginn 3 km nach AS Köln-Königsforst") enthalten sein.
Die in der Zentrale vorliegenden Infos zu einer Verkehrsstörung (Ursache(n), Hinweis(e), Um- leitungsempfehiung(en) etc.) werden dem Kunden vollständig zugestellt.
Die Kodierung der Verkehrsinformationen erfolgt über Event Codes / Geo Codes. ALERT-C- Event Codes und TMC Location Codes werden von T-Mobil im Rahmen dieser Protokollversion nicht unterstützt.
Alle Verkehrsinformationen sind anhand der Priorität (siehe Kap. 4.7.1 ) in vier Klassen unterteilt:
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
Jede Verkehrsinformation wird von der Verkehrsredaktion in der Zentrale einer Klasse zugeordnet. Verkehrsinfos mit Fernwirkung sind typischerweise größere Staus auf BAB und Bundesstraßen. Verkehrsinfos mit Mittelwirkung sind typischerweise mittlere Staus auf Bundesund Landesstraßen. Verkehrsinfos mit Nahwirkung sind typischerweise kleine Staus, die sich nur lokal auswirken. Damit kann z. B. ein Stau von 1 km Länge auf einer BAB der Klasse 1 zugeordnet sein, falls dieser nur lokale Auswirkungen hat.
Warnmeldungen haben die höchste Priorität 4 und sind vom Endgerät sofort zur Anzeige zu bringen. Andere Dienste (wie z. B. der Navigationsdienst) sind beim Eintreffen einer Warnmeldung zu unterbrechen. Beim interaktiven VINFO-Dienst werden die Prioritäten 1 bis 3 vom Endgerät nicht ausgewertet. Verkehrsinfos dieser Klassen werden entsprechend der gewählten VINFO-Variante zen- tralseitig gefiltert (siehe Kap. 2.1.4 bis 2.1.6). Beim VINFO-Dienst über CB werden alle Prioritäten ausgewertet (siehe Kap.5).
Bei der VINFO-Anfrage kann der Kunde wählen, ob er Verkehrsinformationen nur zum Fernstreckennetz oder für alle Straßen erhält. Das Fernstreckennetz besteht aus den BAB, den empfohlenen Umleitungstrecken und den Bundesstraßen. Defaulteinstellung ist das Fernstreckennetz. Damit wird „das Überschütten des Kunden" mit nicht relevanten Verkehrsinfos vermieden und insbesesondere bei Audiotext hohe Kommunikationskosten vermieden.
Wählt der Kunde explizit „ Verkehrsinfos zu allen Straßen", so erhält er auch Verkehrsinfos über das nachgeordnete Straßennetz. Ausnahme bei diesem Filterverfahren ist die Variante Streckenbezogene VINFO, bei der der Kunde immer alle Verkehrsinfos zu der ausgewählten Strecke erhält.
Wählt der Kunde Display als Ausgabemedium, so werden die Verkehrsinfos per SMS ans Endgerät übertragen. Die Verkehrsinfos sollten in einer Liste im Endgerät nichtflüchtig abgelegt werden. Damit sind die Verkehrsinfos nach kurzzeitigen Fahrtunterbrechungen noch präsent.
Verkehrsinfos sollten nach Ablauf der maximalen Speicherdauer (vig_t112, siehe Kap. 3.3) gelöscht werden. Die Verfallszeit von Verkehrsinformationen beim VINFO-CB-Dienst ist nicht identisch mit dieser Speicherdauer.
Im Endgerät sind Sortierverfahren für die Präsentation der Liste von Verkehrsinformationen vorzusehen (siehe auch Kap. 4.9). Folgende Sortierverfahren sollten mindestens verfügbar sein:
- Sortierung nach Aktualität (detaillierte Beschreibung siehe Kap. 4.9)
- Sortierung nach Fahrtrichtung/Abstand
Es 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ßenklassen
Es sollte eine Sortierung der Liste nach Straßenklassen (z. B. absteigend von BAB bis Gemeindestraße) möglich sein.
Wählt der Kunde das Audiotext-System als Ausgabemodus, so werden die Verkehrsinfos im Audiotextsystem eingestellt. Zusätzlich werden die Verkehrsinfos immer per SMS ans Endgerät übertragen. Um eine synchrone Ausgabe der Verkehrsinfos über Display und Audiotext- System zu ermöglichen, enthält die TINFO Speech Message alle für den Kunden relevanten Verkehrsinfos in der Sortierreihenfolge, wie sie bei der Audiotext-Ausgabe erfolgt. Bei einer VINFO-Anfrage mit Display- und Audio-Ausgabe sind die Verkehrsinfos im Endgerät gemäß der TINFO Speech Message zu sortieren. Die vom Kunden am Endgerät eingestellte Sortierung ist bei Audiotext-Ausgabe zu unterdrücken.
Die Datenstruktur der Verkehrsinfos ist in Kap. 4.7 sowie im ADP TINFO beschrieben.
2.1.4 Kurzbeschreibung Umkreisbezogene VINFO (von Zentrale parametriert) Die Dienstevariante Umkreisbezogene VINFO (von Zentrale parametriert) dient der Abfrage von Verkehrsinformationen aus einem kreisförmigen Selektionsgebiet um die Startposition (aktuelle Position bzw. explizit ausgewählte Startposition). Als explizit ausgewählte Startposition sind jegliche Koordinaten im vorgegebenen Format zugelassen. Die Startauswahl erfolgt beispielsweise über Städte aus der Geocodeliste oder Adressen aus dem persönlichen Adreßbuch. Bei Auswahl aus der Geocodeliste ist der Geocode in die entsprechenden Koordinaten umzuwandeln.
Der Nutzer hat bei VINFO umkreisbezogen und VINFO himmelsrichtungsbezogen folgende drei Auswahlmöglichkeiten bzgl. der Größe des Umkreises:
- Lokale Verkehrsinformationen (kleines Kreisgebiet/Sektor)
- Regionale Verkehrsinformationen (mittleres Kreisgebiet/Sektor)
- Überregionale Verkehrsinformationen (großes Kreisgebiet/Sektor)
Bei der Defaulteinstellung „Verkehrsinfos zum Fernstreckennetz" erhält der Kunde innerhalb des Selektionsgebiets nur Verkehrsinfos über das Fernstreckennetz (BAB, empfohlene Umleitungstrecken und Bundesstraßen).
Wählt der Kunde „Verkehrsinfos zu allen Straßen", so erhält er folgende Informationen:
- bei VINFO lokal: Verkehrsinfos zu den Klassen 1 bis 4 innerhalb Kreis/Sektor
„lokal",
- bei VINFO regional: Verkehrsinfos zu den Klassen 1 bis 4 innerhalb Kreis/Sektor „lokal", Verkehrsinfos zu den Klassen 2 bis 4 außerhalb Kreis/Sektor„lokal" und innerhalb Kreis/Sektor „regional"
- bei VINFO überregional: Verkehrsinfos zu den Klassen 1 bis 4 innerhalb Kreis/Sektor
„lokal", Verkehrsinfos zu den Klassen 2 bis 4 außerhalb Kreis/Sektor„lokal" und innerhalb Kreis/Sektor„regional", Verkehrsinfos zu den Klassen 3 und 4 außerhalb Kreis/Sektor „regional" und innerhalb Kreis/Sektor „überregional"
Die Festlegung der entsprechenden Kreisradien für „Kreis lokal" (rjoc), „Kreis regional" (r_reg) und „Kreis überregional" (r_überreg) sowie des Öffnungswinkels des Sektors bei VINFO himmelsrichtungsbezogen erfolgt in der Zentrale. Dabei wird die Verkehrsinfrastruktur an der Startposition berücksichtigt. Als Richtwerte für die Radien können folgende Werte angenommen werden:
Figure imgf000007_0001
Defaulteinstellung "Fernstreckennetz" Einstellung "alle Straßen"
loka *l > \ lokal /- %<
"•/' l Verkehrsinfos
Verkehrsinfos zum 1 - 4 Femstreckennetz ') 1 der Klassen 1 - 4
regional regional
Verkehrsinfos zum Bis r_loc Verkehrsinfos Kl. 1 - 4, Fernstreckennetz r_loc bis r_reg Verkehrsinfos Kl. 2 - 4
Figure imgf000008_0002
Figure imgf000008_0001
überregional
Bis r_loc Verkehrsinfos Kl. 1 - 4,
Verkehrsinfos zum r_loc bis r_reg Verkehrsinfos Kl.2 - 4, Fernstreckennetz r_reg bis r_überreg Verkehrsinfos Kl. 3 - 4
Figure imgf000008_0004
Figure imgf000008_0003
(Mögliche Geometrien der kreisförmigen Selektionsgebiete bei VINFO umkreisbezogen (von Zentrale param etriert))
Zusätzlich sollte der Kunde durch Angabe einer Himmelsrichtung (Himmelsrichtungsbezogene VINFO) die Möglichkeit zur weiteren Filterung haben. In diesem Fall erhält er Verkehrsinformationen aus einem sektorförmigen Selektionsgebiet. Bei der Auswahl der Himmelsrichtung hat der Kunde 8 mögliche Alternativen (N, NO, O, SO, S, SW, W, NW).
Zentralseitig ist eine Erweiterung der Dienstevariante VINFO himmelsrichtungsbezogen geplant, die eine zusätzliche Selektion der Verkehrsinfos in gewählter Himmelsrichtung erlaubt. Diese Richtungsselektion ist für das Endgerät transparent und erfordert keine SW-Änderung im Endgerät.
VINFO himmelsrichtungsbezogen, Defaulteinstellung " Fernstreckennetz "
Figure imgf000008_0005
Süd (Beispiel für ein sektorförmiges Selektionsgebiet)
2.1.5 Kurzbeschreibung Zielgerichtete VINFO Wählt der Kunde die Dienstevariante Zielgerichtete VINFO, so erhält er Verkehrsinfos aus einem Selektionsgebiet, das die Startposition (aktuelle Position bzw. explizit ausgewählte Startposition) und das ausgewählte Ziel enthält. Bei der Start- und Zielauswahl sind jegliche Geocodes zugelassen (z. B. Städte aus der Geocodeliste sowie Adressen aus dem persönlichen Adreßbuch). Bei Auswahl aus dem Adreßbuch sind die Adreßkoordinaten in den entsprechenden Geocode umzuwandeln.
Bei der Defaulteinstellung „Verkehrsinfos zum Femstreckennetz" erhält der Kunde innerhalb des Selektionsgebiets nur Verkehrsinfos über das Fernstreckennetz (BAB, empfohlene Umleitungstrecken und Bundesstraßen).
Wählt der Kunde „Verkehrsinfos zu allen Straßen", so filtert die Zentrale innerhalb des Selektionsgebiets zusätzlich nach Klassen von Verkehrsinformationen. Der Kunde erhält Verkehrsinfos der Klassen 1 bis 4 in seiner unmittelbaren Umgebung (Kreis „lokal", siehe Kap. 2.1.4) und mit zunehmendem Abstand vom aktuellen Bezugspunkt höherklassige Verkehrsinfos.
Größe und Ausrichtung des Selektionsgebiets werden in der Zentrale festgelegt.
Zentralseitig ist eine Erweiterung der Dienstevariante VINFO zielgerichtet geplant, die eine zusätzliche Selektion der Verkehrsinfos in Zielrichtung erlaubt. Diese Richtungsselektion ist für das Endgerät transparent und erfordert keine SW-Änderung im Endgerät.
Defaulteinstellung " Fernstreckennetz "
Verkehrsinfos zum Fernstreckennetz
Figure imgf000009_0001
Einstellung "alle Straßen"
Verkehrsinfos der Klassen:
1 - 4 innerhalb Kreis "lokal"
2 - 4 außerhalb Kreis "lokal" und innerhalb Sektor "regional" 3 - 4 außerhalb Sektor "regional"
Figure imgf000009_0002
und innerhalb Sektor "überregional"
(Beispiele für Selektionsgebiete bei Zielgerichteter VINFO) δ
2.1.6 Kurzbeschreibung Strecken bezogene VINFO
Wählt der Kunde die Dienstevariante Streckenbezogene VINFO, so erhält er Verkehrsinformationen über ausgewählte Streckenabschnitte. Die Strecke kann eine manuell eingegebene Folge von Straßen oder eine im Endgerät abgelegte Route sein.
Bei der manuell eingegebenen Strecke ist die Kennung und Nummer der Straße bzw. mehrerer Straßen (maximal 5 Straßen, siehe Kap. 2.3, Parameter vig250_street_max) anzugeben (z. B. A 59, A 565, A3). Der Kunde wird aufgefordert, die ausgewählten Straßen in Durchfahrtreihenfolge einzugeben. Die Eingabe von Straßen in Freitext (z. B. Kölnstraße) wird nicht unterstützt.
Zusätzlich wird die Startposition (aktuelle Position bzw. explizit ausgewählte Startposition) und die Zielposition ausgewählt. Bei der Start- und Zielauswahl sind jegliche Geocodes zugelassen (z. B. Städte aus der Geocodeliste sowie Adressen aus dem persönlichen Adreßbuch). Bei Auswahl aus dem Adreßbuch sind die Adreßkoordinaten in den entsprechenden Geocode umzuwandeln.
Bei VINFO streckenbezogen werden innerhalb eines rechteckförmigen Selektionsgebiets, das Start- und Zielposition enthält, alle Verkehrsinfos zu den ausgewählten Straßen selektiert.
Alternativ sollte der Kunde eine im Endgerät gespeicherte Route (siehe Dienstespezifikation Navigationsdienst Orientierungshilfe) auswählen können. Diese Route ist in eine Folge von Straßen mit Start- und Zielposition umzuwerten und kann damit mit derselben VINFO-Anfrage wie bei der manuell eingegebenen Strecke übertragen werden (siehe Kap. 4.6).
Bei VINFO streckenbezogenen erhält der Kunde die Verkehrsinformationen aller Klassen 1 bis 4 zu der ausgewählten Strecke. Es erfolgt keine Filterung nach Fernstreckennetz o. ä.
Zentralseitig ist eine Erweiterung der Dienstevariante VINFO streckenbezogen geplant, die eine zusätzliche Selektion der Verkehrsinfos in Fahrtrichtung erlaubt. Diese Richtungsselektion ist für das Endgerät transparent und erfordert keine SW-Änderung im Endgerät.
Figure imgf000010_0001
(Beispiel für ein Selektionsgebiet bei VINFO streckenbezogen) 2.2 Begriffsdefinitionen
Folgende Begriffe sind für dieses Dokument eindeutig festgelegt:
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.
2.3 Über die Dokumente
Diensteübergreifende Spezifikationen, die für das Verständnis der vorliegenden Spezifikation erforderlich sind:
• Dienstespezifikation Interne Dienste
• Conditional Access and Security Protocol
• Key Management and Security
Die aufgeführten Message Types finden sich in den Dokumenten:
• ADP Traffic Information (TINFO)
• ADP Message Types of General Interest
Richtlinien für die Codierung spezieller Datentypen finden sich in folgenden Dokumenten:
• Codin g of Text and Transparent Data
• Address Coding
• Coding of Extended Location Message
• Coding of Absolute Time
• Area and Location Coding Λ O
• Event-Codes
• Geo-Codes
Der Transportrahmen für die Message Types ist festgelegt in:
• Transport Protocol
Die jeweils aktuellen Versionsnummern der aufgeführten Dokumente werden bei jeder Änderung an die Partner der Diensteanbieter weitergegeben.
-M
3 Allgemeine Abläufe
3.1 Transportprotokoll - Handling
Zur Nutzung des interaktiven Verkehrsinformations-Dienstes wird das Transportprotokoll wie folgt verwendet:
Figure imgf000013_0001
Der Transportrahmen unterstützt das Versenden von Nutzdaten über mehrere Short- Messages hinweg. Das Verfahren ist im Dokument „Transport Protocol" festgelegt. λl
Für den Empfang der Meldungen über Cell-Broadcast wird kein spezielles Transport Protokoll verwendet. Vielmehr wird die Dienstekennung (siehe Kapitel 3.1.1) aus der Cell Broadcast Message ID abgeleitet. Die Länge der Nutzdaten wird im CAS-Protokoll übertragen.
Der volle Funktionsumfang des im Dokument „CAS Protocol" beschriebenen CAS-Layers ist endgeräteseitig zu implementieren und zu unterstützen.
3.1.1 Dienstekennung
Dienstekennungen sind eindeutige, von der Zentrale vergebene Adressinformationen zum Routing zwischen dem Kommunikationsinterface und den Applikationen. Diese werden im Feld Application ID im Transport-Layer übertragen.
Die Diensteanbieter können innerhalb der definierten Abläufe eigenständige Dienste definieren. Diese können beispielsweise dadurch gekennzeichnet sein, daß die übermittelten Informationsinhalte eingeschränkt werden. Zu Identifizierung der angebotenen Dienste werden Dienstekennungen vergeben. Die Dienstekennungen sind in den separaten Dienstespezifikationen aufgeführt.
Folgende Dienstekennungen werden für den Verkehrsinformationsdienst verwendet: interaktiver VINFO-Dienst
Service ID BOh VINFO umkreisbezogen (von Zentrale parametriert) / himmelsrichtungsbezogen Service ID B1 h VINFO zielgerichtet
Service ID 13h VINFO streckenbezogen
Service ID B2h TINFO Code Request Message
CB-Freischaltung / interaktive Anfrage aus CB
Fall a: CB nicht verfügbar
Service ID B3h VINFO umkreisbezogen (von Zentrale parametriert) / himmelsrichtungsbezogen Service ID B4h VINFO zielgerichtet
Service ID B5h VINFO streckenbezogen
Fall b: Bei „Telefonie" bzw. „Selektionsαebiet größer als viαlOO r max" Service ID B6h VINFO umkreisbezogen (von Zentrale parametriert) / himmelsrichtungsbezogen Service ID B7h VINFO zielgerichtet
Service ID B8h VINFO streckenbezogen 3.1.2 Auftragsidentifikation und Zuordnung der Antworten
Die Zuordnung von Transaktionen erfolgt über die beiden Felder:
• Initiative Flag
• Context Number im Transport-Layer.
Im Auftrag an die Zentrale vergibt das Verkehrstelematik-Endgerät eine frei wählbare Context Number (Einschränkung: MSB = 1). Mit Initiative Flag = 1 (Initiative) wird die erste Transaktion der Kette, der Auftrag, gekennzeichnet.
Erfolgt eine Antwort an das Verkehrstelematik-Endgerät wird wieder dessen Context Number gesetzt. Das Initiative Flag wird bei allen zugehörigen Antworten auf 0 gesetzt. Damit kann der Auftraggeber die Antwort eindeutig dem erteilten Auftrag zuordnen.
Bei nicht vom Endgerät initiierten Messages vergibt die Zentrale eine frei wählbare Context Number (Einschränkung: MSB = 0). Das Initiative Flag = 1 (Initiative).
3.2 Codierung des Communication Headers der verwendeten ADPs
Die Werte für Protocol Discriminator und Message Type sind dem Dokument „Message Type Numbering" zu entnehmen. Das Bulk Flag wird stets auf 0 gesetzt.
3.3 Parameter der Kommunikationsabläufe
Die für die Verkehrsinformationsdienste relevanten Parameter und Timerwerte sind nachfolgend aufgeführt. Die Hinterlegung und das Updaten der Parameter im Endgerät wird in der Telematikdienstespezifikation „Interne Dienste" erläutert.
Die folgende Tabelle ist gegenüber der Basisspezifikation um die letzte Spalte (T-Mobil) erweitert worden. Dabei kennzeichnet „v" von T-Mobil verwendete, „nv" nicht verwendete Parameter. Ferner werden Änderungen gegenüber der Basisspezifikation durch nicht kursive, fette Schrift sowie durch graue Hinterlegung gekennzeichnet.
Figure imgf000016_0001
Λς
Figure imgf000017_0001
Figure imgf000018_0001
A I
3.4 Ablaufsteuerung
Zur Parametrierung der Abläufe stehen drei 16 Bit-Switches (vgl. Kap. 2.5: VIG_Ctrl 1 - 3) zur Verfügung, die wie folgt belegt sind.
Bedeutung der Bits:
• 0 = feature not supported / off
• 1 = feature supported / on
VIG_Ctrl1 ist in folgender Tabelle aufgeschlüsselt:
Figure imgf000019_0001
Λ %
VIG_Ctrl2 ist in folgender Tabelle aufgeschlüsselt:
Figure imgf000020_0001
3.5 Codierung von Text
Alle Textelemente innerhalb der Verkehrsinformationsdienste verwenden folgendes Format:
Information Element Type Length (bits) iiimEmi
Figure imgf000020_0002
4 Beschreibung des interaktiven VINFO-Dienstes
4.1 Anfrageablauf bei Nutzung der VINFO-Dienste
Im gesamten Kapitel 4 wird der Anfrageablauf für die Ausgabe auf einem Display (Grundablauf) beschrieben. Der Ablauf für die Audiotext-Ausgabe ist separat in Kap. 4.1.6 beschrieben.
Der Anfrageablauf bei Nutzung der verschiedenen VINFO-Dienstevarianten ist einheitlich.
Der Kunde wählt am Endgerät die gewünschte VINFO-Variante aus. Das Endgerät sendet daraufhin die entsprechende TINFO Request Message ab und erhält von der Zentrale als Antwort eine Traffic Information Message, TINFO Deletion Message oder Text Message. Im Fehlerfall wird eine entsprechende Error-Message ans Endgerät übertragen.
Liegen im Endgerät gültige Verkehrsinformationen vor, so werden bei allen VINFO-Varianten die Versionsnummern dieser Verkehrsinformationen mit der entsprechenden TINFO Request Message an die Zentrale übertragen. Die Zentrale schickt nur neue oder aktualisierte Verkehrsinformationen zurück (mit der Traffic Information Message) bzw. schickt mit der TINFO Deletion Message die Versionsnummern zu löschender TINFOs zurück.
Liegen in der Zentrale keine Verkehrsinformationen bzw. keine neuen oder aktualisierten Verkehrsinformationen für den Kunden vor, wird eine Text Message mit IE Status 03h (no traffic news) bzw. 04h (Situation on roads has not changed) übermittelt.
Der Kunde sollte bei allen VINFO-Varianten die Möglichkeit haben, die Verkehrsinformationen einmalig oder mit einem automatischen Update anzufordern. Die beiden Update- Varianten Endgerätegesteuerter Update (siehe Kap. 4.1.2) und Zentralgesteuerter Update (siehe Kap. 4.1.3) werden von T-Mobil in der reinen Form nicht unterstützt. Der T-Mobil-Update von Verkehrsinformationen ist eine Kombination aus Endgerätegesteuertem und Zentralgesteuertem Update (siehe Kap. 4.1.5).
4.1.1 Einmalige Anfrage von Verkehrsinformationen
Beim einmaligen Abruf von Verkehrsinformationen sendet das Endgerät die entsprechende TINFO Request Message (vgl. ADP TINFO, Kap. 3) an die Zentrale. Bei der einmaligen Abfrage ist das IE Update Duration (siehe ADP TINFO, Kap. 5.5) der entsprechenden Message auf „no update" (0x0) gesetzt. Nach einmaliger Zustellung einer Antwortnachricht ist der Auftrag für die Zentrale vollständig abgearbeitet.
Figure imgf000022_0001
1Λ
4.1.2 Endgerätegesteuerter Update von Verkehrsinformationen
Bei der Variante endgerätegesteuerter Update von Verkehrsinformationen sendet das Endgerät periodisch Anfragen nach Verkehrsinformationen mit der entsprechenden TINFO Request Message. Das IE Update Duration wird dabei auf „no update" (OxO) gesetzt. Die Zentrale antwortet auf jede Anfrage einmalig mit der entsprechenden Antwortnachricht.
Onboard Unit Service Center
Update-Timer is started Trigger beliebige TINFO Request Message
Traffic Information Message new or changed TIN- or FOs
Text Message
TINFO Deletion Message deleted TINFOs
Trigger beliebige TINFO Request Message
Traffic Information Message new or changed TINor FOs
Text Message
TINFO Deletion Message deleted TINFOs
...
Timer is stopped
V
4.1.3 Zentralgesteuerter Update von Verkehrsinformationen
Bei der Variante zentralgesteuerter Update von Verkehrsinformationen sendet das Endgerät die entsprechende TINFO Request Message, wobei das IE Update Duration auf die Update- Dauer gesetzt wird. Die Zentrale überträgt die Verkehrsinformationen sowie deren Aktualisierungen innerhalb der Update-Dauer.
Figure imgf000024_0001
4.1.4 Ausgabeformat
Als Ausgabeformat wird standardmäßig nur Event Code/Geo Code unterstützt. Kann das Endgerät einen Event Code/Geo Code nicht interpretieren, so wird eine Übersetzung in Klartext angefordert. Der genaue Ablauf ist in den separaten Dienstespezifikationen beschrieben.
ALERT-C-Event Codes und TMC Location Codes werden von T-Mobil im Rahmen dieser Protokollversion nicht unterstützt.
Die Behandlung nicht dekodierbarer Verkehrsinfos ist in Kap. 4.7.12 beschrieben.
4.1.5 Update von Verkehrsinformationen
Der Update von Verkehrsinformationen ist eine Kombination von Endgerätegesteuertem Update (siehe Kap. 4.1.2) und Zentralgesteuertem Update (siehe Kap. 4.1.3).
Die Wahl „Update von Verkehrsinformationen" sollte der Kunde über die Eingabe „Update- Modus ein/aus" bzw. über die Eingabe einer Dauer für den Update-Modus treffen. Der Update-Modus muß zu jeder Zeit vom Kunden deaktiviert werden können (z. B. bei frühzeitigem Erreichen des Ziels).
Im Update-Modus stellt das Endgerät periodisch Anfragen nach Verkehrsinformationen mit der entsprechenden TINFO Request Message. Die Anfragefrequenz wird gesteuert durch einen Zeittrigger und einen Weglängentrigger. Der Zeittrigger legt die zeitliche Anfrageperiode des Endgeräts fest. Hat das Kfz innerhalb einer Zeitperiode eine Weglänge zurückgelegt, die den Schwellwert vig_up_dist (siehe Kap. 3.3) überschreitet, so wird eine neue Anfrage ausgelöst. In diesem Fall sind anschließend sowohl Zeit- als auch Streckenzähler erneut auf 0 zu setzen.
Die maximale Anfrageperiode wird durch vig_up_per_max (Defaultwert 15 min) festgelegt. Der Schwellwert für zurückgelegte Weglänge wird durch vig_up_dist (Defaultwert 50 km) bestimmt. Der Schwellwert ist als Empfehlung zu werten und sollte innerhalb des Bereiches frei wählbar sein.
Bei jeder Anfrage wird das IE Update Duration auf „000001" gesetzt. (Dieser Code wird von der Zentrale nicht als Update von 30 min, wie im ADP TINFO beschrieben, interpretiert.)
Die Zentrale beantwortet jede der periodischen VINFO-Anfragen unmittelbar mit der entsprechenden Antwortnachricht. Zusätzlich wird, initiiert durch den Update-Duration-Code 000001 , die VINFO-Anfrage in der Zentrale für eine Buchungszeit (größer oder gleich der maximalen Anfrageperiode vig_up_per_max) vorgemerkt. Ergeben sich vor Ablauf des Buchungstimers wichtige Änderungen der Verkehrslage in dem betreffenden Selektionsgebiet (beispielsweise die Entstehung eines neuen Staus aufgrund eines Unfalls) oder liegt eine Warnmeldung für das betreffende Gebiet vor (z. B. Geisterfahrer), so sendet die Zentrale initiativ eine Traffic Information Message oder TINFO Deletion Message. Das Endgerät wertet die zentralseitig initiierten Messages aus und bringt die Verkehrsinformationen zur Anzeige.
Nach Ablauf des Buchungstimers wird die VINFO-Anfrage in der Zentrale gelöscht. Damit ist zentralseitig der Auftrag beendet. Trifft eine neue periodische VINFO-Anfrage mit einem Upda- te-Duration-Code 000001 in der Zentrale ein, wird diese Anfrage erneut vorgemerkt und ein neuer Buchungstimer gestartet.
Das Endgerät schickt bei jeder der periodischen VINFO-Anfragen die Versionsnummern schon bekannter, gültiger Verkehrsinformationen mit. Die dem Endgerät bekannten Versionsnummern werden für die Zeit des Buchungstimers in der Zentrale vorgemerkt. Die Zentrale überträgt nur neue oder aktualisierte Verkehrsinformationen.
Die Kombination aus endgerätegesteuertem Update und zentralgesteuertem Update nutzt die Vorteile beider Verfahren: Bei jeder periodischen Anfrage wird die aktuelle Fahrzeugposition übertragen, auf deren Grundlage in der Zentrale das entsprechend aktualisierte Selektionsgebiet neu berechnet wird. Die Filterung von Verkehrsinfos wird damit periodisch aktualisiert, weshalb keine überflüssigen Informationen an das Endgerät übertragen werden. Durch das Vormerken der VINFO-Anfrage in der Zentrale wird sichergestellt, daß wichtige Verkehrsinfos den Kunden auch zwischen den periodischen Anfragen des Endgeräts erreichen.
zs
Figure imgf000027_0001
(Anfrageablauf beim Update von Verkehrsinfos) 4.1.6 Anfrageablauf bei Audiotext-Ausgabe
Bei Audiotext-Ausgabe ist beim Aufbau der GSM-Sprachverbindung (MO) immer die MSISDN zu übertragen.
Der Anfrageablauf bei Nutzung des Audiotext-Systems als Ausgabemedium ist für die verschiedenen VINFO-Varianten einheitlich.
Zusätzlich zur Bereitstellung der Verkehrsinfos im Audiotext-System werden die Verkehrsinfos wie beim Grundablauf Display-Ausgabe per SMS zum Endgerät übertragen. Der Ausgabemodus der entsprechenden TINFO Request Message wird daher bei Audiotextausgabe immer auf „data and speech" gesetzt.
Damit ist der Anfrageablauf bei der Audiotext-Ausgabe eine Erweiterung des Grundablaufs Display-Ausgabe (siehe Kap. 4.1.1 bis 4.1.5).
Nach Erhalt einer entsprechenden TINFO Request Message sendet die Zentrale als Antwort neben der Traffic Information Message und TINFO Deletion Message zusätzlich eine TINFO Speech Message, um anzuzeigen, daß Verkehrsinfos im Audiotext-System bereitliegen. Das Endgerät baut nun zusätzlich eine Speech Connection (MO) auf, um das Abhören der Verkehrsinfos zu ermöglichen.
Die TINFO Speech Message enthält immer aüe für den Kunden selektierten Verkehrsinfos in der Sortierreihenfolge, wie sie bei der Voice Server-Ausgabe erfolgt. Nach einer VINFO- Anfrage mit Display- und Audiotext-Ausgabe sind die Verkehrsinfos im Endgerät gemäß der TINFO Speech Message zu sortieren. Die vom Kunden am Endgerät eingestellte Sortierung ist bei Audiotext-Ausgabe zu unterdrücken.
Schickt das Endgerät Versionsnummern ihm bekannter Verkehrsinfos an die Zentrale, so erhält es, wie in Kap. 4.1 beschrieben, mit der Traffic Information Message nur die neuen oder aktualisierten Verkehrsinfos und mit der TINFO Deletion Message die zu löschenden Verkehrsinfos zurück. In der TINFO Speech Message werden aNe für den Kunden relevanten Verkehrsinfos in aktueller Sortierung angezeigt (analog beim T-Traffic-Update: wichtige Meldung mit der Traffic Information Message, aNe relevanten Verkehrsinfos in aktueller Sortierung mit der TINFO Speech Message).
Liegen in der Zentrale keine Verkehrsinformationen bzw. keine neuen oder aktualisierten Verkehrsinformationen für den Kunden vor, wird eine Text Message mit IE Status 03h (no traffic news) bzw. 04h (Situation on roads has not changed) übermittelt. Die gleichzeitig übertragene TINFO Speech Message enthält bei Status 03h keine Verkehrsinfos (IE Number of ltems=0) bzw. bei Status 04h die alten, weiterhin gültigen Verkehrsinfos in aktueller Sortierung. Der automatische Aufbau einer Sprachverbindung vom Endgerät sollte nach Erhalt der Text Message mit IE Status 03h bzw. 04h entfallen.
Der Anfrageablauf bei Audiotext-Ausgabe für den T-Mobil-Update ergibt sich entsprechend durch Erweiterung des Grundablaufs (Kap. 4.1.5) um die Übertragung der TINFO Speech Message von der Zentrale sowie den Aufbau der Speech Connection (MO) durch das Endgerät. 4.2 VINFO umkreisbezogen (vom Endgerät parametriert)
Die Dienstevariante VINFO umkreisbezogen (vom Endgerät parametriert) wird von T-Mobil nicht unterstützt.
Die Anfrage Umkreis-Info (vom Endgerät parametriert) erlaubt die Abfrage von meldungswürdigen Verkehrsereignissen aus einem kreisförmigen Selektionsgebiet mit einer Reichweite von vig250_circle_min km bis vig250_circle_max km (vgl. Kap. 3.3).
Protokoll: TINFO Update Request Message
IE Message Type: 0x04
IE Protocol Discriminator: 0x03
Service ID 0x11
Bei der Anfrage für einen Umkreis sind die Parameter Radius und Bezugspunkt an den Diensteanbieter zu übertragen.
Figure imgf000029_0001
Tabelle 4-1: Parameter derVINFO umkreisbezogen (vom Endgerät parametriert)
Figure imgf000029_0002
τs
4.3 VINFO umkreisbezogen (von Zentrale parametriert)
Beim VINFO-Dienst umkreisbezogen (von Zentrale parametriert) erhält der Kunde Verkehrsinformationen aus einem kreisförmigen bzw. sektorförmigen Selektionsgebiet. Wird eine Himmelsrichtung angegeben, so werden Verkehrsinformationen aus einem nach dieser Himmelsrichtung ausgerichteten Sektor selektiert. Wird keine Himmelsrichtung angegeben, so werden Verkehrsinformationen aus einem kreisförmigen Gebiet selektiert.
Der Kunde hat die drei Auswahlmöglichkeiten
- Lokale Verkehrsinformationen,
- Regionale Verkehrsinformationen,
- Überregionale Verkehrsinformationen.
Alternativ zur aktuellen Position kann eine Startposition eingegeben werden.
Protokoll: Relative Regional TINFO Request Message
IE Message Type: OxOE
IE Protocol Discriminator: 0x03
Service ID OxBO
Figure imgf000030_0001
Die Wahl der Dienstevariante Umkreisbezogene VINFO (von Zentrale parametriert) bzw. Himmelsrichtungsbezogene VINFO erfolgt typischerweise nach folgendem Ablauf:
1. Auswahl lokal / regional / überregional
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. A
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. 3ß 4.3.1 Kodierung der Relative Regional TINFO Request Message
Die Relative Regional TINFO Request Message (siehe Kap. 3.4, ADP TINFO) wird bei VINFO umkreisbezogen (von Zentrale parametriert) bzw. bei VINFO himmelsrichtungsbezogen wie folgt kodiert:
Figure imgf000032_0001
Figure imgf000033_0001
4.4 VINFO kreissegmentbezogen
Bei kreissegmentbezogener VINFO erhält der Kunde Verkehrsinformationen aus einem kreis- segmentförmigen Selektionsgebiet mit einer Reichweite von bis zu vig250_dist_max km. Das Kreissegment wird ergänzt durch einen Umkreis von maximal vig250_r_max km Radius um die aktuelle Position. Die Ausrichtung des Kreissegments ergibt sich durch Angabe des Richtungswinkels.
Protokoll: TINFO Update Request Message
IE Message Type: 0x04
IE Protocol Discriminator: 0x03
Service ID 0x10
Der Öffnungswinkel des Selektionsgebietes wird durch die Grundeinstellungen des Endgerätes festgelegt (z.B. 30°) und liegt zwischen vig250_phi_min und vig250_phi_max. Der Öffnungswinkel kann in 1 "-Schritten eingestellt werden.
Die Parameter auf einen Blick
Figure imgf000033_0002
Figure imgf000034_0001
4.5 VINFO zielgerichtet
Beim zielgerichteten VINFO-Dienst erhält der Kunde Verkehrsinformationen aus einem Selektionsgebiet, daß die aktuelle Position sowie die Zielposition enthält. Dazu wird vom Kunden die Zielposition eingegeben. Die genaue Festlegung der Geometrie und Ausrichtung des Selektionsgebiets erfolgt in der Zentrale.
Alternativ zur aktuellen Position kann eine Startposition eingegeben werden. Wird die Startposition nicht verwendet, so ist sie auf 0 zu setzen.
Protokoll: Extended TINFO Request Message
IE Message Type: 0x03
IE Protocol Discriminator: 0x03
Service ID OxB1
Onboard Unit Service Center
Extended TINFO Request Message
Traffic Information Message new or changed TINor FOs
Text Message
TINFO Deletion Message deleted TINFOs Die Wahl der Dienstevariante Zielgerichtete VINFO erfolgt typischerweise nach folgendem Ablauf:
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 Fern st recken netz" / „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 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.
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. 2M 4.5.1 Kodierung der Extended TINFO Request Message bei VINFO zielgerichtet
Die Extended TINFO Request Message (siehe Kap. 3.2, ADP TINFO) wird bei VINFO zielgerichtet wie folgt kodiert:
Figure imgf000036_0001
3 τ
Figure imgf000037_0001
4.6 VINFO streckenbezogen
Beim VINFO-Dienst streckenbezogen erhält der Kunde Verkehrsinformationen über eine ausgewählte Strecke. Die Strecke kann eine Straße oder eine Folge von Straßen sein.
Beim IE Street wird nur Location Type 001 (street) und Street Type 0 - 6 unterstützt. (Text wird generell nicht unterstützt.)
Alternativ zur aktuellen Position kann eine Startposition eingegeben werden. Wird die Startposition nicht verwendet, so ist sie auf 0 zu setzen. Wird die Zielposition nicht verwendet, so ist sie auf 0 zu setzen.
Protokoll: Extended TINFO Request Message
IE Message Type: 0x03
IE Protocol Discriminator: 0x03
Service ID 0x13 3G
Figure imgf000038_0001
Bei VINFO streckenbezogen sollte der Kunde zusätzlich die Möglichkeit haben, eine im Endgerät gespeicherte Route auszuwählen. Die Routenbeschreibung enthält im Block Waypoint die Ortsbezeichnung, welche ensprechend Kap. 3.4, ADP Navigation Services, eine Straßenbeschreibung (Kennung und Nummer, Freitext wird nicht unterstützt) enthält, welche als Straßenbeschreibung in das IE Street der Extended TINFO Request Message (siehe Kap. 3.2, ADP TINFO) gesetzt wird. Straßen des nachgeordneten Netzes sollten zunächst nicht berücksichtigt werden. Zusätzlich ist eine Start- und Zielposition aus der Routenbeschreibung zu extrahieren. Jeder Geocode ist hierfür zulässig. Damit kann die VINFO-Anfrage für die Route gleich der Anfrage über die manuell eingegebene Strecke erfolgen und wird von der Zentrale nicht differenziert behandelt. Besteht die Route aus mehr als 15 Straßenabschnitten, so ist die Route in mehrere Teilstrecken mit entsprechenden Start- und Zielpositionen zu zerlegen. Für jede Teilstrecke ist eine separate Anfrage mit neuer Context-Nummer (siehe Kap. 3.1) zu stellen. Eine Aufteilung auf mehr als 4 Teilstrecken sollte vermieden werden.
Die Wahl der Dienstevariante Streckenbezogene VINFO erfolgt typischerweise nach folgendem Ablauf:
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.
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 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 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 Fern st recken netz 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.
4.6.1 Kodierung der Extended TINFO Request Message bei VINFO streckenbezogen
Die Extended TINFO Request Message (siehe Kap. 3.2, ADP TINFO) wird bei VINFO strek- kenbezogen wie folgt kodiert:
Figure imgf000040_0001
Figure imgf000041_0001
4.7 Kodierung der Verkehrsinformationen (Traffic Information Message)
Die Verkehrsinformationen, die mit der Traffic Information Message an das Endgerät geschickt werden, bestehen aus maximal 11 Blöcken (siehe Kap. 4, ADP). (s. Erklärung unten)
Die Basis-TINFO enthält die Blöcke General Information (Allgemeine Info), Location (Ort des Ereignisses), Event (Ereignis) und End (Ende).
Die Basis-TINFO kann optional um die Blöcke Cause (Ursache des Ereignisses), Hint (Verkehrshinweis), Duration (Dauer des Ereignisses), Bypass (Umleitungsempfehlung), Aver- age Speed (Mittlere Geschwindigkeit am Ort des Ereignisses) und Event position (Genaue Position des Ereignisses) erweitert werden.
Der Block FCD (Steuerung von FCD über TINFO) wird nicht unterstützt.
Eine TINFO kann aus 11 verschiedenen Typen von Blöcken bestehen, von denen einige immer vorhanden sind (mandatory, nachfolgend fett dargestellt) und andere optional. Die Reihenfolge der 11 Blocktypen (von Block 1 General Information bis Block 11 End) ist durch die Blocknumerierung festgelegt. Optionale Blöcke können mehrfach vorhanden sein und werden durch einen 4-Bit Header eingeleitet (z. B. tritt bei 2 Hinweisen der Block 5 (Hint) zweimal hintereinander auf). Eine Besonderheit ist der Block 3 (Event): der erste Event Block ist mandatory und hat keinen Header, optional können weitere Event Blöcke folgen, die mit einem Header eingeleitet werden. (Dadurch kann eine TINFO in Ausnahmefällen auch aus mehr als 11 Blöcken bestehen):
Der erste Event Block beschreibt immer die Verkehrsstörung selber, lokalisiert durch den Location Block. Optionale weitere Event Blocks liefern ausschließlich Zusatzinformationen (Beispiel: „2h Wartezeit") zu der Verkehrsstörung und beziehen sich damit auf den ersten Event Block. Eine TINFO beschreibt immer nur eine Verkehrsstörung. Dementsprechend liefern die optionalen Blöcke Cause, Hint, Duration, Bypass, Average Speed und Event Position Zusatzinformationen zu der Verkehrsstörung und referenzieren damit immer den ersten Event Block. 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
Die genaue Codierung der TINFO ist detailliert im ADP TINFO beschrieben. Im Regefall wird jeder Block maximal einmal vorhanden sein (Ausnahme Event, s. u.).
Übersicht über die Codierung der Verkehrsinformationen mittels Geo- und Event-Codes:
Ortsinformationen für Verkehrsinformationen werden durch Geocodes übertragen. Die Struktur der Geo-Code-Tabellen, die im Endgerät abzulegen sind, ist im Dokument „Geo-Codes: Inhalts- und Strukturbeschreibung der Endgerätetabellen" detailliert beschrieben.
Die Geo-Code-Tabelle wird zunächst für das Gebiet Deutschland erstellt (das Verfahren ist allerdings europaweit anwendbar) und wird in der ersten Realisierungsstufe alle Bundesautobahnen sowie Bundesstraßen abdecken, die unterbrochene Autobahnen direkt verbinden (Straßenknoten). Damit ist das deutsche Fernstraßenkernnetz durch Geocodes beschrieben. Zusätzlich werden zumindest alle wichtigen Städte geocodiert.
Die Geo-Code-Tabelle enthält:
• den Geo-Code
• den Geo-Code-Tvp (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 Drt", z. B. A2 „Dortmund", „Hannover", die Richtungsinformation wird gemäß ADP TINFO zusätzlich übertragen)
Die Information „A3, Autobahnkreuz Bielefeld" ist dementsprechend codiert durch den Geo- code-Typ „Autobahnkreuz", die Straße „A3", (evtl. Referenz-Geocodes), den amtlichen Nummern sowie den Fernzielen „Dortmund" und „Hannover" (siehe Beispiel in Dokument Geo- Codes, Kap. 3.1).
Die Umrechnung des Geo-Codes in geographische Koordinaten (WGS84) sowie die Umkehrung ist möglich.
Die Beschreibung von Ereignissen, Ursachen, Hinweisen und Umleitungshinweisen erfolgt im Regelfall über Event-Codes (in Ausnahmefällen Freitext), die im Dokument „Event-Codes" detailliert beschrieben sind. Folgende Hauptgruppen von Event Codes sind im Dokument „Event Codes" festgelegt (diese können sowohl Ereignisse, Ursachen, Hinweise oder Umleitungshinweisen bezeichnen):
• 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.
Die Hauptgruppen können dazu genutzt werden, bei der Präsentation der Verkehrsinformation die Meldung entsprechend zu bezeichnen (z. B. „Warnung: Glatteis"). Vielen Event Codes sind Quantifier zugeordnet, mit denen z. B. die Länge eines Staus oder die zeitliche Dauer einer Verkehrsmeldung codiert werden. Allerdings können im ADP TINFO nur beim Block 3 (Event) und Block 7 (Bypass) Quantifier gesetzt werden. Hinweise und Ursachen, die mit Quantifiem versehen sind, sind daher als optionaler (zusätzlicher) Block 3 (Event) codiert (z. B. „Wartezeit 2h").
Folgende Quantifiertypen wurden festgelegt:
Typ 1 km, z. B. 6 km Stau
Typ 2 h
Typ 3 m
Typ 4 %
Typ 5 Phrases (z. B. „kurzfristig", „teilweise", „streckenweise", etc.)
Typ 6 min
Der Typ 8 ist für Umleitungs-Quantifier reserviert (s. Kapitel 4.7.7). Typ 6 ist reserviert für Mannesmann Autocom.
Die Übertragung der durchschnittlichen Geschwindigkeit für einen Streckenabschnitt erfolgt nicht durch Event-Code und Quantifier, sondern mittels Block 8 (Average Speed).
Nachfolgend wird an Beispielen die Codierung einer Verkehrsmeldung in den einzelnen Blökken erläutert:
1. Beispiel: A3, Köln nach Frankfurt, zwischen AK Bonn/Siegburg und AS Siebengebirge
5 km Stau wegen Unfall
2. Beispiel: wie 1., zusätzlich „Bitte benutzen Sie ab Bonn die U 123"
3. Beispiel: wie 1., zusätzlich „der Verkehr wird über den Standstreifen geleitet" und „Wartezeit 2h"
4. Beispiel: streckenweise Nebel im Raum Köln
4.7.1 Block 1 (General Information), mandatory
Dieser Block dient der Identifikation einer Verkehrsmeldung. Er legt die Priorität fest und gibt mit dem Flag Bypass Information Auskunft über das Vorliegen einer Umleitungsempfehlung beim Diensteanbieter. Der Block enthält
• 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.
Priorität der TINFO:
Die Prioritäten sind wie folgt festgelegt:
• 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
Beim interaktiven VINFO-Dienst ist ausschließlich die Priorität 4 auszuwerten (sofortige Anzeige der Warnmeldung mit Warnton o. ä.). Bei VINFO über CB sind auch die anderen Prioritäten auszuwerten (siehe Kap. 5.3).
Der Parameter A2VIG2 steuert die Bedeutung des Flags Bypass Information. T-Mobil unterstützt nicht die Abfrage von Umleitungsempfehlungen über die Bypass Request Message. Vielmehr wird bei gesetztem Flag Bypass Information empfohlen, mittels des Navigationsdienstes Orientierungshilfe eine Routenberechnung für eine Umleitungsroute durchführen zu lassen (nur möglich bei Endgeräten, die auch Navigationsdienste unterstützen).
4.7.2 Block 2 (Location), mandatory
Dieser Block legt den Ort der Verkehrsinformation fest.
Der Ort kann auf verschiedene Arten codiert werden. Befindet sich das Ereignis zwischen zwei definierten Punkten (z. B. AS Köln-Süd und AS-Köln-Poll), so werden die IE First Intersection und Last Intersection mit den entsprechenden Geocodes gesetzt. Es wird nur der Standard Location Block (siehe Kap. 4.2.1, ADP) unterstützt, nicht jedoch der Special Location Block (siehe Kap. 4.2.2, ADP).
Innerhalb des Standard-Information-Blocks werden folgende Informationen übertragen:
• 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)
Im Beispiel wird wie folgt codiert:
Beispiel Straße Richtung Geo-Code Anfang Geo-Code Ende
1 A3 01 AK Bonn/Siegburg AS Siebengebirge
2 wie Beispiel 1
3 wie Beispiel 1
4 s. unten 00 Köln (s. unten) Köln (s. unten) Ist der Ort des Ereignisses durch eine Ortsangabe eindeutig beschrieben (z. B. bei Verkehrsmeldungen für Großräume), dann wird der gleiche Geo-Code für Anfang und Ende des Ereignisses übertragen. Für das IE Straße gilt in diesem Fall folgende Vereinbarung: Straßentyp Text (15), das Textfeld ist leer.
Die zusätzlichen Informationen in der Meldung von „Köln" nach „Frankfurt" sind aus der Geo- Code-Tabelle des Endgeräts zu entnehmen („Von_Ort", „NachJDrt").
Mittels des Blocks 9 (Event Position) kann die zusätzliche Information übertragen werden, in welchem Abstand vom IE first intersection das Ereignis liegt (z . B. Stau „10 km" nach AK Bonn/Siegburg").
4.7.3 Block 3 (Event), mandatory
Dieser Block beschreibt das oder die Ereignis(se) (siehe Kap. 4.3, ADP). Es wird der Event Type 1 (im Endgerät gespeicherte Event-Codes oder Text) unterstützt, nicht jedoch der Event Type 2 (AlertC-Codes).
Ereignisse, die in der Event Code Liste abgelegt sind, werden durch den Event Code beschrieben, sonst Klartext. Ereignisse, die sich quantifizieren lassen, werden mit Hilfe der Quantifier beschrieben, sonst ohne.
Eine TINFO enthält immer den ersten Event Block, optional mehrere. Die optionalen Event Blocks liefern Zusatzinfos zu der Verkehrsstörung und können Hinweise/Ursachen sein, welche jedoch wegen des Quantifiers mit dem Block 3 (Event) gesetzt werden müssen (z. B. Wartezeit 2h).
Im Beispiel wird wie folgt codiert:
Beispiel Event-Header Event-Type Code-Flag Event-Code Quantifier
1 entfällt Type 1 1 Stau ($080) 5 km
2 wie Beispiel 1
3 wie Beispiel 1 (Stau), zusätzlich optionaler Event Block:
0001 Type l 1 Wartezeit ($210) 2h
4 entfällt Type 1 1 Nebel streckenweise
4.7.4 Block 4 (Cause), optional
Dieser Block beschreibt die Ursache des Ereignisses (siehe Kap. 4.4, ADP). Es wird der Cause Type 1 (im Endgerät gespeicherte Event Codes oder Text) unterstützt, nicht jedoch der Cause Type 2 (AlertC-Codes).
Ursachen, die in der Event Code Liste abgelegt sind, werden durch den Event Code beschrieben, sonst Klartext.
Einem Cause Block kann kein Quantifier zugeordnet werden. Ursachen mit Quantifier werden als optionaler Event Block codiert (siehe Kap. 4.7). <f
Im Beispiel wird wie folgt codiert:
Beispiel Cause-Header Cause-Type Code-Flag Event-Code
1 0010 Type 1 1 Unfall ($0a5) 2 wie Beispiel 1 3 wie Beispiel 1 4 kein Cause-Block
4.7.5 Block 5 (Hint), optional
In diesem Block können ein oder mehrere Hinweise zu der Verkehrsinformation gegeben werden. Es wird nur der Hint Type 1 (im Endgerät gespeicherte Event Codes oder Text) unterstützt.
Hinweise, die in der Event Code Liste abgelegt sind, werden durch den Event Code beschrieben, sonst Klartext
Einem Hint Block kann kein Quantifier zugeordnet werden. Hinweise mit Quantifier werden als optionaler Event Block codiert (siehe Kap. 4.7).
Im Beispiel wird wie folgt codiert:
Beispiel Hint-Header Hint-Tvpe Code-Flao Event-Code
1 kein Hint-Block 2 kein Hint-Block 3 0011 Type 1 1 „der Verkehr wird über den Standstreifen geleitet" ($28a) kein Hint-Block
4.7.6 Block 6 (Duration), optional
In diesem Block kann die Zeitdauer, für die die Verkehrsinformation gilt, gesetzt werden. Es werden alle drei Duration Types unterstützt.
Dieser Block wird von T-Traffic benutzt, um die Gültigkeitsdauer der Verkehrsmeldung anzugeben. Die angegebene Duration bezieht sich immer auf ein Ereignis (z.B. Demonstration von 14:00 Uhr bis 16:00 Uhr).
Der Block 6 (Duration) bezieht sich auf den 1. Event Block. Er tritt daher in der TINFO nur höchstens einmal auf.
4.7.7 Block 7 (Bypass), optional
In diesem Block kann ein Umleitungshinweis gesetzt werden. Umleitungshinweise werden als Event Codes (für Umleitungshinweise) oder als Klartext unterstützt. Ortsangaben werden als Geo Code oder über das IE Street unterstützt. S
Es werden keine Umleitungsrouten unterstützt, d.h. das IE Presence of IE des Building Blocks Bypass Route ist 0.
Der Bypass-Block kann unabhängig vom Bypass-Flag vorhanden sein. Mittels des Bypass- Blocks werden insbesondere die offiziellen Umleitungen, codiert mittels der Event-Codes aus der Hauptgruppe Umleitung, übertragen (Codierungsbeispiel s. unten).
4.7.7.1 Building Block Additional Location
Der Building Block Additional Location bestimmt das Format und den oder die Orte. Für den Umleitungshinweis werden unterstützt: Location Type = 000 Geo Code, 001 Text, 011 Street sowie 100 Differential Geo Code, (siehe Kap. 5.10, ADP). Bei Differential Geo Code bezieht sich der differentielle Geo Code auf den ersten Geo Code im Building Block.
Für Geo Code bzw. Differential Geo Code siehe Kap. 5.8, ADP. Für Street siehe Kap. 5.7, ADP. Zur Codierung von Text siehe „Coding of text and transparent data".
Mittels des Building Block Additional Information werden die Quantifier für durch Event-Codes codierte Umleitunghinweise gesetzt. Die Reihenfolge der gesetzten Quantifier entspricht der Reihenfolge der Platzhalter in der Event-Code-Liste (s. Beispiel).
Die Umleitungsempfehlung aus Beispiel 2 („Bitte benutzen Sie ab AK Bonn/Siegburg die U 123) wird folgendermaßen codiert:
Bypass Header 0101
Bypass Hint/Presence of IE 1
Flag Code/Text 1 (Event-Code)
Hint Bitte benutzen Sie ab $ die $($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 (Umleitungsstrecke), Street Number 123 Bypass Route/Presence of IE 0
4.7.8 Block 8 (A verage Speed), optional
Mit diesem Block kann die mittlere Geschwindigkeit am Ort des Ereignisses angegeben werden.
Der Block 8 (Average Speed) bezieht sich auf den 1. Event Block. Er tritt daher in der TINFO nur höchstens einmal auf.
4.7.9 Block 9 (Event Position), optional
Mit diesem Block kann der Abstand des Events von dem in „first intersection" angegebenen Ort (siehe Kap. 4.7.2) angegeben werden. Der Block 9 (Event Position) bezieht sich auf den 1. Event Block. Er tritt daher in der TINFO nur höchstens einmal auf.
4.7.10 Block 10 (FCD-Flag), wird nicht unterstützt
Der Block FCD-Flag wird nicht unterstützt.
4.7.11 Block 11 (End), mandatory
Der End Block zeigt das Ende der TINFO an.
4.7.12 Behandlung nicht dekodierbarer Verkehrsinfos
Kann das Endgerät Teile einer Verkehrsinfo nicht dekodieren (Event Code/Geo-Code, der in der Event Code/Geo Code-Tabelle des Endgeräts nicht enthalten ist), so fordert es eine Übersetzung des/der unbekannten Codes in Klartext an.
Das Endgerät sendet dazu eine TINFO Code Request Message (siehe Kap. 3.6, ADP TINFO) an die Zentrale. Für jeden unbekannten Code wird jeweils ein Translation Block gesetzt. Als Source Format wird nur 0 (Event Code) und 1 (Geo Code) unterstützt. Als Destination Format wird nur 0 (Text) unterstützt.
Die Zentrale schickt die Übersetzung des/der Codes mit der TINFO Code Message (siehe Kap. 2.2, ADP TINFO) zurück. Für jeden übersetzten Code wird jeweils ein Explanation Block gesetzt. Als Source Format wird nur 0 (Event Code) und 1 (Geo Code) unterstützt. Als Destination Format wird nur 0 (Text) unterstützt.
4.8 Fehlerbehandlung
Siehe Dokumente:
• „Message Type of General Interest", Kap. 4 General Error Message,
• „Diensteübergreifende Fehlerbehandlung".
4.9 Präsentation von Verkehrsinformationen
Grundsätzlich muß der Kunde zwischen den VINFO-Ausgabemedien Audiotext oder Display sowie Audiotext und Display (gleichzeitig) wählen können.
Bei der Fahrtvorbereitung oder bei Aufenthalt in einem dem Kunden nicht bekannten Gebiet kann es für ihn hilfreich sein, die übermittelten Informationen nur auf dem Display zu lesen und abzuspeichern (z.B. zur Planung von Alternativen). Während der Fahrt bietet die Audiotext-Ausgabe durch die Zentrale dem Kunden im Interesse der Verkehrsssicherheit den Vorteil, die gewünschten Informationen anzuhören, ohne den Blick vom Verkehrsgeschehen abwenden zu müssen.
Auch die gleichzeitige Ausgabe per Audiotext und Display kann für den Kunden sinnvoll sein (z.B. zum genaueren Nachblättern der Meldungen), insbesondere unter dem Gesichtspunkt der automatischen Speicherung relevanter, aktueller Meldungen im Endgerät. Als besonders kundenfreundlich regt T-Mobil hierbei die synchrone Ausgabe der Meldungen über Audiotext und Display an. Dies ist im Endgerät realisierbar durch Auswertung der TINFO Speech Message, die bei Audio-Ausgabe von der Zentrale übertragen wird (siehe Kap. 4.1.6). Die TINFO Speech Message liefert Reihenfolge und Länge der im Audiotext-System eingestellten Verkehrsinfos, wodurch die synchrone Ausgabe der Verkehrsinfos auf dem Display ermöglicht wird.
Das Ausgabemedium Audiotext / Display bzw. Audiotext und Display sollte bei einer VINFO- Anfrage vom Kunden einstellbar sein (evtl. durch die Grundeinstellungen). Im Update-Modus sollte ein Wechsel des Ausgabemediums per Menüpunkt jederzeit möglich sein und nicht dazu führen, daß z.B. die Ersteingabe (Ziel u.a.) wiederholt werden muß. Als Default wird „Audiotext" für die Fälle vorgeschlagen, in denen kein abgesetztes, großes Display vorhanden ist.
Die Zentrale sendet in jedem Fall alle Meldungen auch per SMS (auch bei Kundenauswahl Audiotext allein), damit im Endgerät stets eine vollständige, aktuelle Liste der Verkehrsmeldungen vorhanden ist und der Kunde bei Wechsel von Audiotext zu Display oder bei Einschalten des Endgerätes nach kurzer Abwesenheit diese Liste ohne erneute VINFO-Anfrage sofort verfügbar hat.
Untersuchungen haben gezeigt, daß - gleiche Bedienerfreundlichkeit vorausgesetzt - der Sprachausgabe überwiegend der Vorzug gegeben wird (sofern nicht ein integriertes Anzeigesystem im Fahrerblickfeld vorgerüstet ist).
Mit der privatwirtschaftlichen Erfassung der Verkehrsdaten werden Menge sowie Änderungsgeschwindigkeit der Verkehrsinformationen (und deren Verläßlichkeit!) im Vergleich zu heute deutlich ansteigen. Der Kunde wird dies als nützliche Neuerung aber nur dann empfinden, wenn er nicht mit unnötigen Verkehrsinformationen belästigt wird. Dazu dient einerseits die Selektion bei der Anfrage durch Auswahl einer VINFO-Variante (umkreisbezogen, himmelsrichtungsbezogen, zielgerichtet oder streckenbezogen). Zusätzlich sollten die dem Kunden übertragenen Verkehrsinfos bei der Präsentation geeignet sortiert werden. Eine unkomplizierte Benutzerführung zur Sortierung ist daher von entscheidender Bedeutung.
Zur Sortierung der im Endgerät vorliegenden Verkehrsinfos und deren Updates schlägt T- Mobil folgendes Vorgehen für ein entsprechendes Nutzermenü vor:
I. Sortierung nach Aktualität: automatische Ausgabe (nach Erhalt einer Traffic Information Message. Text Message oder TINFO Speech Message):
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.a.) 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. S 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. manueller Aufruf:
Zusätzlich sollte der Kunde die Liste aller vorliegenden Verkehrsinfos durch manuellen Aufruf per Display aus dem Endgerätepeicher erhalten können (z.B. wenn er sich vergewissern will). Bei Audio-Ausgabe baut der Kunde per Menüpunkt eine Sprachverbindung auf. Im Audiotext-System wird zwischen „table 1 " mit den neuen und geänderten Meldungen und „table 2" mit den übrigen (unveränderten) Meldungen unterschieden. Der Ablauf der Anfrage entspricht der D1 - Mobilbox-Anfrage.
II. Sortierung nach Fahrtrichtung/Abstand
Bei der Display-Ausgabe 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 Bei der Audiotext-Ausgabe ist diese Sortierung nicht möglich.
III. Sortierung nach Straßenklassen
Bei der Display-Ausgabe sollte eine Sortierung der Liste mit Verkehrsinformationen nach Straßenklassen (z. B. absteigend von BAB bis Gemeindestraße) möglich sein.
Warnmeldungen haben stets höchste Priorität und müssen bevorzugt angezeigt bzw. zugesprochen werden. Dabei wäre ein Warnton o.a. sinnvoll.
4.9.1 Display
Die ans Endgerät übertragenen Verkehrsinformationen sollen dem Kunden auf dem Display des Endgerätes in möglichst übersichtlicher Form präsentiert werden, um so für ihn möglichst schnell erfaßbar zu sein und einen eventuellen Ablenkungseffekt zu minimieren.
Jede Verkehrsinformation setzt sich aus einer Anzahl von Blöcken zusammen (siehe Kap. 4.7). Die Darstellungskapazität eines Displays ist naturgemäß eingeschränkt. Zum eindeutigen Verständnis einer Verkehrsinformation muß jedoch nicht unbedingt der vollständige Wortlaut der Event Codes/Geo Codes dargestellt werden; vielmehr wird die Umsetzung in sinnvolle Abkürzungen ausdrücklich angeregt. Die entsprechenden Regeln und Zeichen für Abkürzungen sind endgerätespezifisch zu realisieren.
Eine abgekürzte Verkehrsinformation wie in Beispiel 2 (siehe Kap. 4.7) könnte auf dem Display folgendermaßen aussehen:
A3 Köln > Frankf./M. zw. AK BN u. Siebeng. 5 km Stau wg. Unfall 2 h Wartez. » U 123
Je nach Anzahl der vorliegenden Nachrichten zum betreffenden Streckenabschnitt liegen mehrere solcher Meldungen vor, die nacheinander zur Anzeige kommen sollen. Daher sollte eine Scroll-Funktion vorgesehen werden, die (zeilen- oder) seitenweises Scrollen bzw. Hin und Herspringen zwischen einzelnen Meldungen zuläßt. Zusätzlich sollte ein Automatikmodus das bequeme Ablesen aller Meldungen nacheinander unterstützen (z.B. automatischer Seitenwechsel nach 10 Sek.).
Zusatzbefehle bzw. weitere Menüfunktionen, wie z. B. das Abspeichern einzelner Nachrichten oder Strecken, sollen ebenfalls auf dem Display dargestellt werden. Ebenfalls sollten gängige Sonderzeichen (z.B. +, -, *, #, <, >, etc.) darstellbar sein.
Um das Ablesen der Informationen auch bei Dämmerung oder Dunkelheit zu ermöglichen, sollte ein Tastendruck gleichzeitig die Hintergrundbeleuchtung des Displays für einen bestimmten Zeitraum auslösen (mindestens Ablesen einer Seite).
Die Abdeckung des Displays sollte spiegelfrei sein, so daß die Informationen auch bei Schrägstehen des Gerätes problemlos abgelesen werden können. Für die Anzeige von Verkehrsinformationen ist Grafikfähigkeit nicht erforderlich (anders beim Navigationsdienst Orientierungshilfe).
4.9.2 Audiotext-System
In vielen Situationen ist die Ausgabe der Verkehrsinfos per Audiotext vorteilhafter und sicherer als das Ablesen vom Display. Nutzt der Kunde z.B. bei längeren Fahrten den Update (Kap. 4.1.5), werden ihm die von ihm selektierten Verkehrsinfos für seine Fahrtstrecke zugesprochen.
D Nachdem die Zentrale Verkehrsinformationen für den Kunden in das Audiotext-System eingestellt hat, sendet sie die TINFO Speech Message an das Endgerät, das daraufhin automatisch eine Sprachverbindung zum Audiotext-System aufbaut. Das zentrale Audiotext-System der T- Mobil unterstützt das rasche Scrollen zum Überspringen oder Wiederholen von Verkehrsinfos in besonderer Weise, um die Kundenakzeptanz zu erhöhen.
Das Audiotext-System wird über Tonwahlverfahren gesteuert (DTMF), das vom Endgerät unterstützt werden muß. Der Nutzer soll mit möglichst nur einem Endgerätebefehl die Möglichkeit zum Vor- und Zurückspringen zwischen einzelnen Nachrichten sowie den verschiedenen Menüebenen haben (z.B. über Skip-Schalter bzw. Cursor-Kreuz). Eine Fernbedienung vom Lenkrad aus kann unter dem Gesichtspunkt der Verkehrssicherheit nur begrüßt werden.
5 Beschreibung des VINFO-Dienstes über Cell Broadcast
5.1 Einleitung
Der VINFO Cell Broadcast Subdienst ist ein Broadcast Dienst, bei dem alle Verkehrsinformationen in einem Umkreis von mindestens vig100_r_max km via Cell Broadcast im GSM Netz übertragen werden. Die Verkehrsinformationen werden zyklisch in einem Zeitraster kleiner 15 Minuten als VINFO Datentelegramm „Traffic Information Message" - Message Type 0x01, Protocol Discriminator 0x03 - versendet. Dabei können innerhalb eines Datentelegramms mehrere Verkehrsmeldungen übertragen werden. Die einzelnen Meldungen sind anhand ihrer Versionsnummer (ID+Time Stap) eindeutig identifizierbar (gleiche Kennung bei interaktivem und kollektivem Dienst).
Um eine unberechtigte Nutzung zu unterbinden, können die Daten im Cell Broadcast Betrieb verschlüsselt sein. Die Art der Verschlüsselung wird im CAS-Rahmen für den Cell Broadcast Betrieb bestimmt, in den die Nutzdaten eingebettet sind.
Die Nutzung des VINFO-Dienstes über Cell-Broadcast soll für den Kunden gleichartig wie die des interaktiven VINFO-Dienstes erfolgen. Daher sollten auch hier die Selektionskriterien umkreisbezogene VINFO, himmelsrichtungsbezogene VINFO, zielgerichtete VINFO und strek- kenbezogene VINFO unterstützt werden. Die Menüstruktur sollte identisch wie bei den interaktiven VINFO-Diensten sein. Die entsprechenden Gebietsfilter sind für VINFO CB endgeräte- seitig zu realisieren. Empfehlungen für deren Parametrisierung sind in Kapitel 5.5 zusammengestellt. Darüber hinaus sollte die Filterung nach „Fernstreckennetz" bzw. „alle Straßen" realisiert werden (siehe Kap. 2.1.4 bis 2.1.6).
Der interaktive VINFO-Dienst wird als Rückfallösung bei unterbrochenem CB-Empfang, zur Abfrage von Meldungen, die außerhalb des aktuellen CB-VINFO-Versorgungsbereichs liegen, und zur Übersetzung nicht dekodierbarer Nachrichten genutzt (s. Kapitel 5.4).
5.2 Gültigkeit von Verkehrsmeldungen
Jeder Verkehrsmeldung ist eine Verfallszeit zugeteilt. Die Verfallszeit beginnt mit Empfang des Datentelegramms in dem die Verkehrsmeldung auftritt. Nach Ablauf der Verfallszeit verliert die Verkehrsmeldung ihre Gültigkeit und ist zu löschen.
5.3 Der Ablauf
Der Diensteanbieter sendet permanent via Cell Broadcast die aktuellen Verkehrsereignisse für das Ausstrahlungsgebiet.
Nach dem Empfang einer Cell Broadcast Seite muß das in ihr enthaltene Datentelegramm mit Hilfe des Diensteschlüssels dechiffriert werden - siehe Interne Dienste und Key Management. Die einzelnen Verkehrsmeldungen innerhalb des dechiffrierten Datentelegramms werden se¬ pariert. Auf sie sind folgende Regeln anzuwenden. 51 Regeln:
1 Vorbedingung:
Verkehrsmeldung hat Priorität 1 (OxOO)
Aktion:
Füge die Verkehrsmeldung in die Verkehrsinformation ein.
Setze die Verfallszeit der Verkehrsmeldung auf die definierte Zeit vig_k101.
2 Vorbedingung:
Verkehrsmeldung hat Priorität 2 (0x01)
Aktion:
Füge die Verkehrsmeldung in die Verkehrsinformation ein.
Setze die Verfallszeit der Verkehrsmeldung auf die definierte Zeit vig_k102.
3 Vorbedingung:
Verkehrsmeldung hat Priorität 3 (0x02)
Aktion:
Füge die Verkehrsmeldung in die Verkehrsinformation ein.
Setze die Verfallszeit der Verkehrsmeldung auf die definierte Zeit vig_k103.
4 Vorbedingung:
Verkehrsmeldung hat Priorität 4 (0x03)
Aktion:
Füge die Verkehrsmeldung in die Verkehrsinformation ein.
Setze die Verfallszeit der Verkehrsmeldung auf die definierte Zeit vig_k104.
5 Vorbedingung:
Alle empfangenen Verkehrsmeldungen haben als Ereignis 0x223
Aktion:
Lösche alle Verkehrsmeldungen aus der Verkehrsinformation
6 Vorbedingung:
Die Verfallszeit einer Verkehrsmeldung läuft ab und seit definierter Zeit vig_t110 wurden keine Verkehrsmeldungen via Cell Broadcast empfangen
Aktion:
Setze die Verfallszeit der im Cell Broadcast Betrieb empfangenen Verkehrsmeldung unabhängig von ihrer Priorität einmalig auf den Wert vig_J111. $>3
Werden bereits bekannte bzw. aktualisierte Verkehrsmeldungen (gleiche Meldungs-ID) aufgrund der zyklischen Ausstrahlung wiederholt empfangen, ist die zugehörige Verfallszeit wieder auf den Wert vig_k101 bis vigj<104 zu setzen. Der zugehörige Ablauf ist in Abb. 6-3 in Kapitel 7 dargestellt.
Über CB werden alle vorliegenden Meldungen (Prioritätenklassen 1 bis 4, alle Straßenklassen) für eine Reichweite von mindestens vig_100_r_max km (Radius) bezogen auf die aktuelle Fahrzeugposition verteilt. Folgende Kriterien sind zur Beurteilung ihrer Relevanz für eine Ausgabe auszuwerten: Ereignisort innerhalb des Selektionsgebiets, Prioritätenklasse, Gültigkeitszeitraum, Straßenklasse, Status: neu, aktualisiert, gelöscht, alt. Die Dekodierung der Meldungen erfolgt wie beim interaktiven VINFO-Dienst mit Hilfe der Referenztabellen (Event- und Geo-Codes).
Transaktionen via Cell Broadcast:
Service Center
Traffic Information Message
Traffic Information Message
Figure imgf000055_0001
5.4 Verknüpfung mit interaktiven VINFO-Diensten
Der interaktive VINFO-Dienst wird als Rückfallösung bei unterbrochenem CB-Empfang, z. B. während einer GSM-Sprachverbindung, zur Abfrage von Meldungen, die außerhalb des aktuellen CB-VINFO-Versorgungsbereichs liegen, und zur Übersetzung nicht dekodierbarer Nachrichten genutzt. Die aus dem CB-Mode interaktiv abgefragten Verkehrsmeldungen werden bezüglich Priorität, Verfallszeit, etc. wie reguläre CB-Meldungen behandelt.
5.4.1 Kein CB-Empfang
Zur Steuerung der CB-Emulation werden die Timer T1 10 und T111 (s. Abb 6-3 in Kapitel 7) genutzt. T1 10 wird beim Empfang jedes CB-Datentelegramms zurückgesetzt und erneut gestartet. Erreicht T1 10 seinen Maximalwert VIG_T110, ohne daß ein weiteres CB-Datentele- gramm empfangen wurde, werden die Verfallszeiten aller gespeicherten Verkehrsmeldungen unabhängig von ihrer Priorität einheitlich und einmalig auf VIG_T111 gesetzt. Für diesen Fall prüft das Endgerät, ob eine GSM-Sprach- oder Datenverbindung besteht.
Fall a): Kein CB-Empfang wegen bestehender GSM-Verbindung
Der Kunde erhält eine Meldung darüber, daß seit n * VIG_T1 10 (n = 1 ... VIG_T1 1 1/VIG_T1 10) 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_T1 10 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üobarkeit 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. SS- Für beide Fälle a) und b) gilt, daß nach Erreichen des jeweiligen Maximalwertes (vig_cb_req1_max bzw. vig_cb_req2jnax) interaktive Abfragen nur noch über die Service IDs 10h bis 14h (siehe Kapitel 3.1.1 ) zulässig sind.
5.4.2 Selektionsgebiet größer als CB-Gebiet
Grundsätzlich sind die in CB einzustellenden Selektionsgebiete in ihrer Größe nur durch die aktuelle Parametrierung (s. Kapitel 3.3 für Wertebereiche) beschränkt. T-Mobil wird zunächst alle Verkehrsinformationen mit „Fernwirkung" bundesweit ausstrahlen, wobei die Wiederholfrequenz mit abnehmender Entfernung zum Ereignisort erhöht wird. Daher ist auch für große Reiseentfernungen zunächst keine interaktive Anfrage zur Ergänzung der CB-Information nötig und zulässig.
Wird es aus Kapazitätsgründen notwendig, eine Regionalisierung der CB-Inhalte vorzunehmen, werden alle Verkehrsinformationen in einem Umkreis von mindestens vig100_r_max km übertragen. Zusätzlich werden ausgewählte Meldungen der Klasse 3 ausgestrahlt. Wünscht der Kunde eine vollständige Versorgung mit Verkehrsinformationen über den versorgten Bereich hinaus, kann er eine interaktive VINFO-Abfrage durchführen Dabei sind die gewählten Selektionsgebiete und -parameter auf die Anfragetypen umkreis-, himmelsrichtungs-, strek- kenbezogen bzw. zielgerichtet abzubilden. Empfehlungen für die entsprechenden Parameter sind in Kapitel 5.5 zusammengestellt. Auch hier werden wie im Rahmen der CB-Emulation nur einmalige Anfragen unterstützt. Nicht unterstützt werden Anfragen mit Sprachausgabe. Die Freischaltung dieser interaktiven Abfrage erfolgt über VIG_Ctrl2, A2VIG3 (siehe Kapitel 3.4).
5.4.3 Nicht dekodierbare Meldung
Erhält das Endgerät über den CB-VINFO-Dienst Meldungen, die mit den verfügbaren Referenzlisten (Event Codes, Geo Codes) nicht dekodierbar sind, kann mit der TINFO Code Request Message, entsprechend des in Kapitel 4.7.12 beschriebenen Ablaufs eine Übersetzung angefordert werden.
5.5 Parameter für den CB-Dienst
VINFO umkreisbezogen
Figure imgf000057_0001
Die Nutzung der Parameter vig250_circle_min, vig250_circle_med, vig250_circle_max ist abweichend von der Funktionsdefinition in Kapitel 3.3. Die Defaulteinstellungen der Parameter sind fest und durch den Kunden nicht zu beeinflussen. b
VINFO himmelsrichtungsbezogen
Figure imgf000058_0001
Radius des Umkreises = rjoc (Wert siehe oben Kap. 5.5, VINFO umkreisbezogen) Radius des Sektors r_seg: entsprechend Wahl des Kunden „lokal, regional, überregional", (Wert siehe oben Kap. 5.5, VINFO umkreisbezogen)
Himmelsrichtung gemäß Wahl des Kunden (8 Alternativen N, NO, O, SO, S, SW, W, NW)
Öffnungswinkel phi: vom Kunden einstellbar innerhalb des Bereichs zwischen vig250__phi_min und vig250_phi_max.
VINFO zielgerichtet
Figure imgf000058_0002
Radius des Umkreises = rjoc (Wert siehe oben Kap. 5.5, VINFO umkreisbezogen). Radius des Sektors = dist (Abstand Start-Ziel)
Öffnungswinkel phi: vom Kunden einstellbar innerhalb des Bereichs zwischen vig250_phi_min und vig250_phi_max. 3
6 Anforderungen an die Endgeräte
6.1.1 Kommunikation
Die Daten-Kommunikation zwischen dem Endgerät und der Zentrale wird durch den im GSM zur Verfügung stehenden Kurznachrichtendienst abgewickelt. Dazu werden die Kurznachrichtendienste SMS-MT (TS 21) und SMS-MO (TS 22) benötigt werden.
Zur Abwicklung des kollektiven VINFO-Dienstes muß der SMS Cell Broadcast Dienst unterstützt werden.
6.1.2 Ortung
Das Endgerät muß über eine Ortungskomponente (GPS-Empfänger) verfügen. Der Ortungsgenauigkeit muß im Mittel < 250 m sein.
6.1.3 Speicher
Für den VINFO-Dienst muß das Endgerät mindestens 200 Verkehrsinformationen speichern können.
Die Verkehrsinformationen sind nichtflüchig zu speichern, um z. B. nach kurzzeitigen Fahrtunterbrechungen noch präsent zu sein.
Die im Endgerät gespeicherte Geocode-Tabelle sollte zur Eingabe von Start- und Zielpositionen genutzt werden können.
Um die Eingabe von Start- und Zielpunkten zu erleichtern, sollte im Endgerät ein Notizbuch mit mind. 50 Einträgen existieren, aus dem u.a. auch die Adreßbeschreibung übernommen werden kann.
6.1.4 MMI
Das Endgerät sollte über ein Text-Display und über eine komfortable Eingabemöglichkeit ver¬ fügen.
Empfehlung für das Display: 4 Zeilen, 20 Zeichen/Zeile
Es wird empfohlen, bei kostengünstiger Realisierbarkeit künftig eine einfache Sprachausgabe einzurichten. 53
7 Verkehrsmeldungsverwaltung - Realisierungsvorschlag
Verkehrsmeldungsverwaltung mit Buchung
Figure imgf000060_0001
Abbildung 6-7; Verkehrsmeldungsverwaltung mit Buchung b'°l
Verkehrsmeldungsverwaituiig PoSnt-to-Point
Figure imgf000061_0001
Abbildung 6-2: Verkehrsmeldungsverwaltung Point-to-Point
Ver ehrs eldur*gsverwalturtg Cell Broadcast
Figure imgf000062_0001
parallele Bearbeitung
Figure imgf000062_0002
Abbildung 6-3: Verkehrsmeldungsverwaltung bei CB 8 Verbindung des VINFO-Dienstes zum Navigationsdienst
Folgende Verbindungen des Verkehrsinformationsdienstes zum Navigationsdienst Orientierungshilfe sind vorgesehen:
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 lE'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.

Claims

1 PatentansprücheVerfahren und Anordnung zur Verkehrsinformation
1. Verfahren zur Verkehrsinformation, wobei auf Anfrage und/oder automatisch Daten zwischen einer Zentraleinheit und einer mobilen Teilnehmereinheit übertragen werden.
2. Anordnung zur Verkehrsinformation, wobei mindestens eine Zentraleinheit sowie mindestens mehrere mobile Teilnehmereinheiten vorgesehen sind.
PCT/DE1997/002871 1996-12-10 1997-12-10 Verfahren und anordnung zur verkehrsinformation WO1998026395A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
AU56506/98A AU5650698A (en) 1996-12-10 1997-12-10 Method and device of traffic information
AT97952712T ATE223607T1 (de) 1996-12-10 1997-12-10 Verfahren und anordnung zur verkehrsinformation
DK97952712T DK0883871T3 (da) 1996-12-10 1997-12-10 Fremgangsmåde og indretning til trafikinformation
DE59708132T DE59708132D1 (de) 1996-12-10 1997-12-10 Verfahren und anordnung zur verkehrsinformation
EP97952712A EP0883871B1 (de) 1996-12-10 1997-12-10 Verfahren und anordnung zur verkehrsinformation

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE19651143A DE19651143B4 (de) 1996-12-10 1996-12-10 Verfahren und Anordnung zur Verkehrsinformation
DE19651143.7 1996-12-10

Publications (2)

Publication Number Publication Date
WO1998026395A1 true WO1998026395A1 (de) 1998-06-18
WO1998026395B1 WO1998026395B1 (de) 1998-08-13

Family

ID=7814137

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE1997/002871 WO1998026395A1 (de) 1996-12-10 1997-12-10 Verfahren und anordnung zur verkehrsinformation

Country Status (7)

Country Link
EP (1) EP0883871B1 (de)
AT (1) ATE223607T1 (de)
AU (1) AU5650698A (de)
DE (2) DE19651143B4 (de)
DK (1) DK0883871T3 (de)
ES (1) ES2183230T3 (de)
WO (1) WO1998026395A1 (de)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000033278A1 (de) * 1998-11-30 2000-06-08 Robert Bosch Gmbh Verfahren zur anforderung und zur verarbeitung von verkehrsinformationen
DE10002918C2 (de) * 2000-01-19 2003-06-18 Ddg Ges Fuer Verkehrsdaten Mbh Stabile Zuordnung von Verkehrsmeldungen und deren Ursache repräsentierenden Zusatzinformationen
EP1576561A2 (de) * 1998-11-23 2005-09-21 Integrated Transport Information Services Limited System zur überwachung der momentanen verkehrslage
EP1619641A2 (de) * 2004-07-23 2006-01-25 Robert Bosch Gmbh Verfahren zur Übermittlung von Verkehrsmeldungen
EP1886292A1 (de) * 2005-05-18 2008-02-13 Lg Electronics Inc. Bereitstellung von verkehrsinformationen, ein­schliesslich einer vorhersage der reisezeit zum überqueren einer verbindung und verwendung dieser
EP2124211A1 (de) * 2005-05-18 2009-11-25 Lg Electronics Inc. Bereitstellung von Verkehrsinformationen über die Geschwindigkeitsvorhersage einer Verbindung
EP2124210A1 (de) * 2005-05-18 2009-11-25 Lg Electronics Inc. Bereitstellung von Verkehrsinformationen mit Unterverknüpfungen von Verknüpfungen
US7729335B2 (en) 2005-05-18 2010-06-01 Lg Electronics Inc. Providing traffic information relating to a prediction of congestion status and using the same
EP2216762A3 (de) * 2005-05-18 2010-10-06 Lg Electronics Inc. Bereitstellung von Verkehrsinformation in Bezug auf die Vorhersage eines Staustatus und Verwendung davon
US8538498B2 (en) 1998-12-23 2013-09-17 Silver State Intellectual Technologies, Inc. Technique for effective communications with, and provision of global positioning system (GPS) based advertising information to, automobiles
US9026114B2 (en) 2004-07-09 2015-05-05 INRX Global Services Limited System and method for geographically locating a cellular phone
US9185068B2 (en) 2000-07-28 2015-11-10 Silver State Intellectual Technologies, Inc. Technique for effective organization and communication of information
US9324232B2 (en) 2000-08-28 2016-04-26 INRX Gloabal Services Limited Method and system for modeling and processing vehicular traffic data and information and applying thereof
US9418545B2 (en) 2011-06-29 2016-08-16 Inrix Holding Limited Method and system for collecting traffic data
US9798985B2 (en) 2009-02-02 2017-10-24 Inrix Holdings Limited Apparatus and methods for providing journey information
US9983015B2 (en) 1999-10-19 2018-05-29 Silver State Intellectual Technologies, Inc. Technique for effective navigation based on user preferences
USRE47239E1 (en) 2005-05-18 2019-02-12 Lg Electronics Inc. Method and apparatus for providing transportation status information and using it

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19843203A1 (de) * 1998-09-14 2000-03-16 Mannesmann Ag Verfahren zur benutzerindividuellen Auswahl und Sendung von Verkehrsinformationen von einer Verkehrszentrale an einen Benutzer und Verkehrsinformationszentrale
DE19852860A1 (de) * 1998-11-09 2000-05-25 Mannesmann Ag Informationsdienst in zellularen Mobilfunknetzen basierend auf SMS-MO/SMS-MT/SMS-CB-Einrichtungen und Positionsdaten
DE19857782C2 (de) * 1998-12-04 2001-01-11 Mannesmann Ag Verfahren zum Übertragen von Tabelleninformationen von einer Zentrale an ein Endgerät über einen Übertragungskanal und Zentrale zum Durchführen des Verfahrens
DE19903648A1 (de) * 1999-01-29 2000-08-03 Bosch Gmbh Robert Verfahren zum Erzeugen von Präsentationsdaten aus einem dynamischen Datenbestand
DE19911674C2 (de) * 1999-03-09 2002-05-23 Mannesmann Ag Broadcast-Point-to-Point-Informationsverfahren
DE19930796A1 (de) 1999-07-03 2001-01-11 Bosch Gmbh Robert Verfahren und Vorrichtung zur Übermittlung von Navigationsinformationen von einer Datenzentrale an ein fahrzeugbasiertes Navigationssystem
DE19937370A1 (de) * 1999-08-12 2001-02-15 Bosch Gmbh Robert Verfahren zur Anforderung und zur Überarbeitung von Verkehrsmeldungen
DE19937372A1 (de) * 1999-08-12 2001-02-15 Bosch Gmbh Robert Verfahren zur Anforderung und zur Verarbeitung von Verkehrsmeldungen
DE19938454A1 (de) * 1999-08-13 2001-02-22 Tenovis Gmbh & Co Kg Verfahren und Kommunikationssystem zur optimierten Steuerung einer Vielzahl von mobilen Stationen zu Zielorten
DE19939625A1 (de) * 1999-08-20 2001-02-22 Nokia Mobile Phones Ltd Verfahren zum Abrufen von Informationen aus einem Informationsnetzwerk
DE19946162A1 (de) * 1999-09-27 2001-04-05 Siemens Ag Anordnung und Verfahren zur Zielführung unter Nutzung eines Kommunikationsnetzes, insbesondere eines Mobilfunknetzes
DE10007326A1 (de) * 2000-02-17 2001-08-23 Tegaron Telematics Gmbh Warndienst bei Telematikanwendungen
GB2360588B (en) * 2000-03-23 2004-04-07 Yeoman Group Plc Navigation system
GB0011797D0 (en) 2000-05-16 2000-07-05 Yeoman Group Plc Improved vehicle routeing
US6804524B1 (en) * 2000-11-21 2004-10-12 Openwave Systems Inc. System and method for the acquisition of automobile traffic data through wireless networks
US6463382B1 (en) * 2001-02-26 2002-10-08 Motorola, Inc. Method of optimizing traffic content
US20040036611A1 (en) * 2001-03-30 2004-02-26 Kidney Nancy G. Notification service on transportation network
US6587780B2 (en) * 2001-04-09 2003-07-01 Koninklijke Philips Electronics N.V. System and method for disseminating traffic information
GB0110890D0 (en) * 2001-05-04 2001-06-27 Trafficmaster Plc A system
DE10128409B4 (de) * 2001-06-12 2007-05-31 Harman Becker Automotive Systems Gmbh Navigationssystem
US6650252B2 (en) 2001-08-28 2003-11-18 Delphi Technologies, Inc. Vehicle warning system and method
JP2003075178A (ja) 2001-09-03 2003-03-12 Pioneer Electronic Corp 通信ナビゲーションシステム及び方法、地図情報提供通信センタ装置、通信ナビゲーション端末並びにコンピュータプログラム
JP4475851B2 (ja) * 2001-10-30 2010-06-09 パイオニア株式会社 道路状況データ提供システム
FR2837950B1 (fr) * 2002-03-29 2005-03-04 France Telecom Procede et systeme de notification d'evenements concernant un moyen de transport
US6691028B2 (en) 2002-06-07 2004-02-10 Motorola, Inc. Server-based navigation system and method of operating same
JP4625233B2 (ja) * 2002-09-13 2011-02-02 パイオニア株式会社 情報通信システム、情報通信方法及びコンピュータプログラム
EP1420380A1 (de) * 2002-11-18 2004-05-19 Owasys Advanced Wireless Devices, S.L.L. Navigationsvorrichtung und Verfahren
DE10312502A1 (de) * 2003-03-14 2004-09-23 DDG GESELLSCHAFT FüR VERKEHRSDATEN MBH Verfahren zur Bereitstellung von Verkehrsinformationen
FR2852775B1 (fr) * 2003-03-18 2005-06-24 Peugeot Citroen Automobiles Sa Systeme de transmission d'informations a destination d'un vehicule automobile
DE102004017091B4 (de) * 2004-04-07 2013-01-10 Audi Ag Verfahren zum Betrieb eines Navigationssystems für ein Kraftfahrzeug
JP4396380B2 (ja) 2004-04-26 2010-01-13 アイシン・エィ・ダブリュ株式会社 交通情報の送信装置及び送信方法
CN101154318B (zh) 2006-09-05 2010-09-22 株式会社查纳位资讯情报 交通信息收集/配送方法及系统、中心装置及车载终端装置
JP4905044B2 (ja) 2006-10-13 2012-03-28 アイシン・エィ・ダブリュ株式会社 交通情報配信装置
JP4652307B2 (ja) * 2006-10-18 2011-03-16 アイシン・エィ・ダブリュ株式会社 交通情報配信装置
DE102006051228A1 (de) * 2006-10-31 2008-05-08 Deutsche Telekom Ag Verfahren zur fernunterstützten Navigation
JP5052550B2 (ja) 2009-03-11 2012-10-17 アイシン・エィ・ダブリュ株式会社 交通情報管理装置、交通情報管理方法および交通情報管理プログラム
DE102014222524A1 (de) * 2014-11-05 2016-05-12 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Verringerung der Unfallgefahr durch Geisterfahrer
WO2016190843A1 (en) * 2015-05-22 2016-12-01 Here Global B.V. Telecom backup for radio data service (rds)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0317181A2 (de) * 1987-11-10 1989-05-24 Siemens Plessey Controls Limited Zielführungs- und Streckenauswahlsysteme für Kraftfahrzeuge
US5471205A (en) * 1994-08-31 1995-11-28 Izawa; Michio Map displaying method
WO1996011381A1 (de) * 1994-10-07 1996-04-18 Mannesmann Aktiengesellschaft Einrichtung zur zielführung von personen

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5164904A (en) * 1990-07-26 1992-11-17 Farradyne Systems, Inc. In-vehicle traffic congestion information system
DE4230294A1 (de) * 1992-09-10 1994-03-17 Bosch Gmbh Robert Verfahren zur Auswahl routenrelevante Meldungen bei RDS Radios
DE19604084A1 (de) * 1995-03-23 1996-10-02 Deutsche Telekom Mobil Verfahren und Einrichtung zur Ermittlung von Dynamischen Verkehrsinformationen
DE19547574A1 (de) * 1995-04-06 1996-10-10 Deutsche Telekom Mobil Verfahren für ein Fahrzeugleit- und Informationssystem
DE19520148A1 (de) * 1995-06-01 1996-12-05 Opel Adam Ag Verfahren und elektronische Einrichtung zur Vermittlung regional gültiger Funk-Informationen an einen Fahrer bzw. an Insassen eines Kraftfahrzeugs

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0317181A2 (de) * 1987-11-10 1989-05-24 Siemens Plessey Controls Limited Zielführungs- und Streckenauswahlsysteme für Kraftfahrzeuge
US5471205A (en) * 1994-08-31 1995-11-28 Izawa; Michio Map displaying method
WO1996011381A1 (de) * 1994-10-07 1996-04-18 Mannesmann Aktiengesellschaft Einrichtung zur zielführung von personen

Cited By (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1959413A1 (de) * 1998-11-23 2008-08-20 Integrated Transport Information Services Limited System zur sofortigen Verkehrsüberwachung
EP2009606A3 (de) * 1998-11-23 2009-09-23 Integrated Transport Information Services Limited System zur sofortigen Verkehrsüberwachung
EP1576561A2 (de) * 1998-11-23 2005-09-21 Integrated Transport Information Services Limited System zur überwachung der momentanen verkehrslage
EP1576561A4 (de) * 1998-11-23 2005-12-21 Integrated Transp Information System zur überwachung der momentanen verkehrslage
EP2009609A3 (de) * 1998-11-23 2009-09-23 Integrated Transport Information Services Limited System zur sofortigen Verkehrsüberwachung
EP2009607A3 (de) * 1998-11-23 2009-09-23 Integrated Transport Information Services Limited System zur sofortigen Verkehrsüberwachung
EP2009608A3 (de) * 1998-11-23 2009-09-23 Integrated Transport Information Services Limited System zur sofortigen Verkehrsüberwachung
EP2009607A2 (de) * 1998-11-23 2008-12-31 Integrated Transport Information Services Limited System zur sofortigen Verkehrsüberwachung
EP1901258A1 (de) * 1998-11-23 2008-03-19 Integrated Transport Information Services Limited System zur sofortigen Verkehrsüberwachung
EP1959412A1 (de) 1998-11-23 2008-08-20 Integrated Transport Information Services Limited System zur sofortigen Verkehrsüberwachung
EP1959411A1 (de) * 1998-11-23 2008-08-20 Integrated Transport Information Services Limited System zur sofortigen Verkehrsüberwachung
WO2000033278A1 (de) * 1998-11-30 2000-06-08 Robert Bosch Gmbh Verfahren zur anforderung und zur verarbeitung von verkehrsinformationen
US7072676B1 (en) 1998-11-30 2006-07-04 Robert Bosch Gmbh Method and wireless transceiver for requesting and processing information
US8538498B2 (en) 1998-12-23 2013-09-17 Silver State Intellectual Technologies, Inc. Technique for effective communications with, and provision of global positioning system (GPS) based advertising information to, automobiles
US9495872B2 (en) 1998-12-23 2016-11-15 Silver State Intellectual Technologies, Inc. System and method for effective communication of location and other information about automobiles
US9990848B2 (en) 1998-12-23 2018-06-05 Silver State Intellectual Technologies, Inc. System and method for effective communication of location and other information about automobiles
US9983015B2 (en) 1999-10-19 2018-05-29 Silver State Intellectual Technologies, Inc. Technique for effective navigation based on user preferences
DE10002918C2 (de) * 2000-01-19 2003-06-18 Ddg Ges Fuer Verkehrsdaten Mbh Stabile Zuordnung von Verkehrsmeldungen und deren Ursache repräsentierenden Zusatzinformationen
US9185068B2 (en) 2000-07-28 2015-11-10 Silver State Intellectual Technologies, Inc. Technique for effective organization and communication of information
US9552725B2 (en) 2000-08-28 2017-01-24 Inrix Global Services Limited Method and system for modeling and processing vehicular traffic data and information and applying thereof
US9324232B2 (en) 2000-08-28 2016-04-26 INRX Gloabal Services Limited Method and system for modeling and processing vehicular traffic data and information and applying thereof
US9026114B2 (en) 2004-07-09 2015-05-05 INRX Global Services Limited System and method for geographically locating a cellular phone
US9155060B2 (en) 2004-07-09 2015-10-06 INRX Global Services Limited System and method for geographically locating a cellular phone
EP1619641A2 (de) * 2004-07-23 2006-01-25 Robert Bosch Gmbh Verfahren zur Übermittlung von Verkehrsmeldungen
EP1619641A3 (de) * 2004-07-23 2007-07-25 Robert Bosch Gmbh Verfahren zur Übermittlung von Verkehrsmeldungen
EP2216762A3 (de) * 2005-05-18 2010-10-06 Lg Electronics Inc. Bereitstellung von Verkehrsinformation in Bezug auf die Vorhersage eines Staustatus und Verwendung davon
EP2124211A1 (de) * 2005-05-18 2009-11-25 Lg Electronics Inc. Bereitstellung von Verkehrsinformationen über die Geschwindigkeitsvorhersage einer Verbindung
EP1886292A4 (de) * 2005-05-18 2008-08-27 Lg Electronics Inc Bereitstellung von verkehrsinformationen, ein­schliesslich einer vorhersage der reisezeit zum überqueren einer verbindung und verwendung dieser
EP2124210A1 (de) * 2005-05-18 2009-11-25 Lg Electronics Inc. Bereitstellung von Verkehrsinformationen mit Unterverknüpfungen von Verknüpfungen
EP1886292A1 (de) * 2005-05-18 2008-02-13 Lg Electronics Inc. Bereitstellung von verkehrsinformationen, ein­schliesslich einer vorhersage der reisezeit zum überqueren einer verbindung und verwendung dieser
EP2216763A3 (de) * 2005-05-18 2010-10-06 Lg Electronics Inc. Bereitstellung von Verkehrsinformationen mit Unterverknüpfungen von Verknüpfungen
EP2216763A2 (de) 2005-05-18 2010-08-11 Lg Electronics Inc. Bereitstellung von Verkehrsinformationen mit Unterverknüpfungen von Verknüpfungen
US7729335B2 (en) 2005-05-18 2010-06-01 Lg Electronics Inc. Providing traffic information relating to a prediction of congestion status and using the same
USRE47239E1 (en) 2005-05-18 2019-02-12 Lg Electronics Inc. Method and apparatus for providing transportation status information and using it
US9798985B2 (en) 2009-02-02 2017-10-24 Inrix Holdings Limited Apparatus and methods for providing journey information
US9418545B2 (en) 2011-06-29 2016-08-16 Inrix Holding Limited Method and system for collecting traffic data

Also Published As

Publication number Publication date
EP0883871A2 (de) 1998-12-16
DE19651143B4 (de) 2013-07-25
DK0883871T3 (da) 2003-01-06
DE59708132D1 (de) 2002-10-10
DE19651143A1 (de) 1998-06-18
ES2183230T3 (es) 2003-03-16
EP0883871B1 (de) 2002-09-04
ATE223607T1 (de) 2002-09-15
AU5650698A (en) 1998-07-03

Similar Documents

Publication Publication Date Title
EP0883871B1 (de) Verfahren und anordnung zur verkehrsinformation
DE69831952T2 (de) System zur bereitstellung gezielter internet-information an mobilen agenten
DE69928484T2 (de) Verfahren und Vorrichtung zum Verwenden von Echtzeitverkehrsfunkmeldungen mit Navigationssystemen
EP0815547B1 (de) Verfahren und einrichtung zur ermittlung von dynamischen verkehrsinformationen
DE10041099C2 (de) Verfahren zur Übertragung von Datenpaketen zwischen Kraftfahrzeugen
EP0782743B1 (de) Verfahren und vorrichtung zum auffinden eines verfügbaren parkplatzes oder parkhauses
EP1079353A2 (de) Verfahren zur Anforderung und zur Verarbeitung von Verkehrsmeldungen
WO2001015117A1 (de) Ortsbezogene wap-staukarte durch verknüpfung von kartenausschnitten in einer verkehrsinformationszentrale
EP0883872A1 (de) Verfahren und anordnung zur information mobiler teilnehmer
EP0769180A1 (de) Einrichtung zur aufbereitung und ausgabe von informationen für einen fahrzeugführer
DE19604084A1 (de) Verfahren und Einrichtung zur Ermittlung von Dynamischen Verkehrsinformationen
EP1062481B1 (de) Verfahren zur ausgabe von verkehrsinformationen
EP1460599B1 (de) Datenbasis zur Codierung oder Decodierung von Verkehrsmeldungen und Verfahren zur Übertragung codierter Verkehrsmeldungen
EP1338867A1 (de) Verkehrsdaten-Informationssystem
WO1989002142A1 (en) Improved road traffic-control system
EP0790591A1 (de) Ortsdatenbank für die Ermittlung von Routen innerhalb eines Verkehrswegennetzes
EP0896314B1 (de) Navigationssystem für ein Kraftfahrzeug
EP1079354A2 (de) Verfahren zum Abrufen von Informationen aus einem Informationsnetzwerk
EP1141911B1 (de) Einrichtung zur übertragung von fahrtroutenempfehlungen und empfänger
EP1057157B1 (de) Verkehrsleitsystem
DE19810126A1 (de) Verfahren zur rechnergestützten Routenfindung für Fahrzeugführer
EP1076325B1 (de) Verfahren zur Anforderung und zur Verarbeitung von Verkehrsmeldungen
EP1714261B1 (de) Verfahren zur decodierung, codierung und übertragung von fahrtroutendaten und navigationsvorrichtung
EP1657691A1 (de) Verfahren und System zur Ermittlung von Verkehrsinformationen
DE102020114100A1 (de) Verfahren zum Vernetzen von unterschiedlichen Navigationsdiensten sowie Servereinrichtung und System mit einer solchen Servereinrichtung und mit einem Kraftfahrzeug

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CZ DK EE ES FI GB GE GH HU IL IS JP KE KG KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZW AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SZ UG ZW AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

WWE Wipo information: entry into national phase

Ref document number: 1997952712

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 1997952712

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 1997952712

Country of ref document: EP