EP0883871B1 - Verfahren und anordnung zur verkehrsinformation - Google Patents

Verfahren und anordnung zur verkehrsinformation Download PDF

Info

Publication number
EP0883871B1
EP0883871B1 EP97952712A EP97952712A EP0883871B1 EP 0883871 B1 EP0883871 B1 EP 0883871B1 EP 97952712 A EP97952712 A EP 97952712A EP 97952712 A EP97952712 A EP 97952712A EP 0883871 B1 EP0883871 B1 EP 0883871B1
Authority
EP
European Patent Office
Prior art keywords
traffic information
vinfo
traffic
information
tinfo
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Revoked
Application number
EP97952712A
Other languages
English (en)
French (fr)
Other versions
EP0883871A2 (de
Inventor
Rolf Beyer
Oliver LÖHMER
Stephan Knechtges
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telekom Deutschland GmbH
Original Assignee
T Mobile Deutschland GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
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=EP0883871(B1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by T Mobile Deutschland GmbH filed Critical T Mobile Deutschland GmbH
Publication of EP0883871A2 publication Critical patent/EP0883871A2/de
Application granted granted Critical
Publication of EP0883871B1 publication Critical patent/EP0883871B1/de
Anticipated expiration legal-status Critical
Revoked legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/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

  • the invention relates to a method and an arrangement for traffic information according to the Preamble of the independent claims.
  • WO-A-96/11381 relates to a device for guiding people.
  • the facility comprises a navigation unit which has a receiving device for wirelessly transmitted Has information for recognizing the current geographic position, a Communication unit, which is an input unit in particular for entering a target position and an output unit, in particular for output of route guidance information.
  • a central computer for route planning is provided, which has a memory has at least one digitized road map and that with the navigation unit is technically connectable via the communication unit. The computer transmits the calculated route information to the navigation unit. The possibility of one Traffic information is only addressed in passing.
  • EP 0 317 181 relates primarily to a route planning and destination guidance system, with a Computer center is provided, in which, among other things, information about the current Traffic situation can be saved. This traffic data is used for route planning and guidance used. However, this document contains no information that a Independent traffic information system for the individual information of the Road user is present.
  • the object of the invention is to provide a method and an arrangement for To propose traffic information for mobile participants that is always up-to-date for the participant Provides information and at the same time offers a high level of user comfort.
  • data can be related to various output parameters, e.g. Location, start or destination information or route information of the trip, central or Device-side queries that are carried out device-based or person-based can.
  • the data transfers can be for information acquisition purposes and / or Information transfer purposes as well as for updating information carried out become.
  • the present traffic information service can be used in particular in the Service variants "interactive VINFO” (via targeted SMS short messages and / or Telephony) and “collective VINFO” (via SMS short message broadcasting CB).
  • the interactive traffic information service enables the customer to use his customized retrieval of current and reliable requirements Traffic information.
  • the customer can get traffic information in particular to a geometric selection area or explicitly to a route Request.
  • the traffic information is preferably in a central office customized filtering.
  • the traffic information is then sent via SMS short messages targeted transfer to the end device (output via display) or in an audio text system imported (for audio output via a telephony voice channel e.g. in GSM).
  • the collective VINFO service is functionally and in terms of content the same as the interactive VINFO service, however, the filtering takes place in the terminal.
  • the output of Traffic information via the audio text system is not supported.
  • Traffic information can be collected, processed and from different sources individually compiled for the individual customer.
  • VINFO related to the compass direction can be offered, which is implemented as a special case of radius-related VINFO (parameterized by the control center) and is described in Chap. 2.1.4 and 4.3 is described.
  • the customer should have the choice of all VINFO variants, one-off traffic information to request or to be provided with automatic updates of traffic information (see Cape. 4.1).
  • the traffic information and the VINFO variants are described in the following chapters briefly described. A detailed description of the interactive service variants can be found Chapter 3. The collective service variants are described in Chap. 5 described.
  • 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”).
  • the cause e.g. "due to accident”
  • information e.g. "Please drive on the right lane”
  • duration of the event e.g. "for 2 h”
  • diversion notice e.g. "Please use the U 45 "from thechen-Königsforst AS
  • additional location information e.g. Start of traffic jam 3 km to thechen-Königsforst AS ").
  • Each traffic information is assigned to a class by the traffic department at the headquarters.
  • Traffic information with long-range effects is typically larger traffic jams on motorway and federal highways.
  • Traffic information with a medium impact is typically medium traffic jams on the federal and state level State roads.
  • Local traffic information is typically small traffic jams that occur impact only locally. So z. B. A 1 km long traffic jam on a class 1 motorway assigned if this only has local effects.
  • Warning messages have the highest priority 4 and are to be displayed by the end device immediately .
  • Other services (such as the navigation service) must be interrupted when a warning message arrives.
  • priorities 1 to 3 are not evaluated by the terminal. Traffic information of these classes will be on the central side according to the selected VINFO variant filtered (see chap. 2.1.4 to 2.1.6). With the VINFO service via CB, all priorities evaluated (see Chapter 5).
  • the customer can choose whether to only receive traffic information on the long-distance network or on all roads .
  • the long-distance route network consists of the BAB, the recommended detour routes and the federal highways.
  • the default setting is the distance network. This prevents the customer from being overwhelmed with irrelevant traffic information and high communication costs are avoided, especially with audiotext.
  • the traffic information is sent via SMS Transfer terminal.
  • the traffic information should be stored in a non-volatile list in the terminal become. This means that the traffic information is still present after brief breaks in the journey.
  • Traffic information should be deleted after the maximum storage period (vig_t112, see Chapter 3.3).
  • the expiry time of traffic information with the VINFO-CB service is not identical to this storage period.
  • 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 as it is done with 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 audio text is output.
  • the data structure of the traffic information is in Chap. 4.7 and in ADP TINFO.
  • the service variant perimeter-related VINFO (parameterized by the control center) is used for the query of traffic information from a circular selection area around the starting position (current position or explicitly selected start position).
  • starting position current position or explicitly selected start position
  • any coordinates are allowed in the specified format.
  • the start selection is made for example cities from the geocode list or addresses from the personal address book.
  • the geocode is in the appropriate coordinates convert.
  • the customer should have the option of further filtering by specifying a cardinal point (cardinal direction-related VINFO) .
  • cardinal direction-related VINFO cardinal direction-related VINFO
  • the customer receives traffic information from a sector-shaped selection area.
  • the customer has 8 possible alternatives (N, NO, E, SO, S, SW, W, NW).
  • VINFO service variant related to the cardinal direction is planned, which allows an additional selection of traffic information in the selected cardinal direction.
  • This direction selection is transparent to the end device and does not require any software changes in the end device.
  • the customer chooses the targeted VINFO service variant, he receives traffic information a selection area that selects the start position (current position or explicitly Start position) and contains the selected destination.
  • start and destination selection are any Geocodes allowed (e.g. cities from the geocode list and addresses from the personal Directory).
  • Geocodes allowed (e.g. cities from the geocode list and addresses from the personal Directory).
  • the head office filters within the selection area additionally according to classes of traffic information.
  • the customer receives traffic information classes 1 to 4 in its immediate vicinity ("Iokal” district, see Chapter 2.1.4) and with increasing distance from the current reference point higher-class traffic information.
  • the size and orientation of the selection area are determined at the headquarters.
  • 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 one Be a series of streets or a route stored in the end device.
  • 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.chen Avenue
  • the start position current position or explicitly selected start position
  • the target position are selected. All geocodes are permitted for the start and destination selection (e.g. cities from the geocode list and addresses from the personal address book). When selecting from the address book, the address coordinates are to be converted into the corresponding geocode.
  • the Start and destination position contains, all traffic information for the selected streets selected.
  • the customer should use a route stored in the end device (see service specification Navigation service orientation guide).
  • This route is a series of Revaluate streets with start and destination positions and can therefore use the same VINFO request as with the manually entered route (see section 4.6).
  • VINFO route-related the customer receives traffic information of all classes 1 to 4 for the selected route. There is no filtering according to the distance network or similar.
  • 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.
  • the current version numbers of the listed documents are updated with every change passed on to the partners of the service providers.
  • the transport protocol is used as follows to use the interactive traffic information service:
  • the transport frame supports the sending of user data via several short messages time.
  • the procedure is specified in the "Transport Protocol" document.
  • Service identifiers are unique address information issued by the head office Routing between the communication interface and the applications. These are in the Transfer the Application ID field in the transport layer.
  • the service providers can define independent services within the defined processes. These can be characterized, for example, in that the information content transmitted be restricted. To identify the services offered Assign service identifiers. The service identifiers are in the separate service specifications listed.
  • the following service identifiers are used for the traffic information service:
  • Service ID B3h VINFO perimeter (parameterized by the control center) / directional Service ID B4h VINFO targeted Service ID B5h VINFO route-related
  • Service ID B6h VINFO perimeter (parameterized by the control center) / directional Service ID B7h VINFO targeted Service ID B8h VINFO route-related
  • Initiative Flag 1 (Initiative) is the first transaction the chain, the order.
  • the Initiative Flag 1 (Initiative).
  • Protocol Discriminator and Message Type are in the document "Message Type Numberng ".
  • the bulk flag is always set to 0.
  • the parameters and timer values relevant for the traffic information services are as follows listed.
  • the storage and updating of the parameters in the terminal is done in the Telematics service specification "Internal Services" explained.
  • 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_up_per_max Maximum request period for T-Mobil update of traffic information min 15 0-60 5 v 27 vig_up_dist Threshold value for the distance traveled when T-Mobil updates traffic information km 50 10-500 10 v 28 vig_cb_req1_max Maximum number of interactive requests from CB for telephony 10 0-500 1 v 29 vig_cb_req2_max maximum number of interactive requests from CB if no CB reception 10 0-500 1 v 30 vig250_ circle_med r_reg km 35 1-250 1 v 31-60 reserved reserved nv 61 VIG_Ctrl1 Sequential control bit flags Flag 16 bits v 62 VIG_Ctrl2 Sequential control bit flags Flag 16 bits v 63 VIG_Ctrl3 Sequential control bit flags Flag 16 bits nv
  • VIG_Ctrl1 is broken down in the following table: Bit no Abbrev. description T-Mobile default 1 A1VIG1 Activation of cell broadcast VINFO 0 2 A1VIG2 centrally controlled update (via IE update duration) is supported 1 3 A1VIG3 VINFO ptp also sends the control center independently of an initiative by the end device 1 4 A1VIG4 Control center supports VINFO related to the surrounding area (parameterized by the EC) 0 5 A1VIG5 Central unit supports VINFO related to the surrounding area (parameterized by central unit) 1 6 A1VIG6 Head office supports VINFO related to district segments 0 7 A1VIG7 Head office supports targeted VINFO 1 8th A1VIG8 Head office supports route-related VINFO 1 9 A1VIG9 Head office supports start and finish point for route-related VINFO 1 10 A1VIG10 Head office supports selection area for route-related VINFO 0 11 A1VIG11 Head Office supports Mode Speech (audio text) 1 12 A1VIG12 Central supports output format text
  • the customer selects the desired VINFO variant on the end device.
  • the terminal sends then the corresponding TINFO request message and receives from the head office as Answer a Traffic Information Message, TINFO Deletion Message or Text Message. in the If an error occurs, a corresponding error message is transmitted to the end device.
  • 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, chapter 5.5) of the corresponding message is set to "no update" (0x0). After a response message has been delivered once, the order for the head office is completely processed.
  • the terminal periodically sends requests for traffic information with the corresponding TINFO request message.
  • the IE update duration is set to "no update" (0x0).
  • the head office replies to each request once with the corresponding reply message.
  • the end device sends the corresponding TINFO request message, whereby the IE update duration is set to the update duration.
  • the head office transmits the traffic information and its updates within the update duration.
  • Event Code / Geo Code Only Event Code / Geo Code is supported as the output format by default. Can the If the terminal device does not interpret an event code / geo code, a translation into plain text is carried out requested. The exact procedure is described in the separate service specifications.
  • the update of traffic information is a combination of device-controlled updates (see chapter 4.1.2) and centrally controlled update (see chapter 4.1.3).
  • Update traffic information should be entered by the customer via "Update mode on / off "or by entering a duration for the update mode.
  • the update mode must be able to be deactivated by the customer at any time (e.g. early Reaching the goal).
  • the terminal In the update mode, the terminal periodically queries traffic information with the corresponding TINFO request message.
  • the request frequency is controlled by a Time trigger and a path length trigger.
  • the time trigger sets the time request period of the Terminal fixed. Has the vehicle covered a distance within a period of time that the Threshold exceeds vig_up_dist (see Chapter 3.3), a new request is triggered. In this case, both the time and distance counters must then be reset to 0.
  • the maximum request period is determined by vig_up_per_max (default value 15 min).
  • the The threshold for the distance covered is determined by vig_up_dist (default value 50 km).
  • the threshold value is a recommendation and should be free within the range be selectable.
  • the IE update duration is set to "000001". (The control center does not interpret this code as an update of 30 minutes as described in the ADP TINFO.)
  • the head office answers each of the periodic VINFO inquiries directly with the corresponding one Reply.
  • the VINFO request at headquarters for a booking time (greater than or equal to the maximum Request period vig_up_per_max) noted.
  • the head office sends a traffic initiative Information Message or TINFO Deletion Message.
  • the terminal evaluates the central side initiated messages and displays the traffic information.
  • VINFO request is deleted from the head office. So that is the order is completed on the central side. Receives a new periodic VINFO request with an update duration code 000001 in the head office, this request is noted again and on new booking timer started.
  • the terminal sends the version numbers for each of the periodic VINFO requests already known, valid traffic information.
  • the version numbers known to the terminal are noted in the head office for the time of the booking timer.
  • the headquarters only transmits new or updated traffic information.
  • the combination of a device-controlled update and a central-controlled update takes advantage of both methods: With every periodic request, the current vehicle position is transmitted, on the basis of which the correspondingly updated selection area is recalculated in the control center. The filtering of traffic information is updated periodically, which is why no superfluous information is transmitted to the end device. The reservation of the VINFO request in the head office ensures that important traffic information reaches the customer even between the periodic requests from the end device.
  • the MSISDN must always be transmitted when the GSM voice connection (MO) is established .
  • the request process when using the audio text system as output medium is for the different VINFO variants uniform.
  • the traffic information As with the basic process, display output is sent to the end device via SMS.
  • the output mode the corresponding TINFO request message is therefore always used for audio text output set to data and speech ".
  • the query process for the output of audio text is thus an extension of the basic process Display output (see chapters 4.1.1 to 4.1.5).
  • the control center After receiving a corresponding TINFO request message, the control center sends a response in addition to the Traffic Information Message and TINFO Deletion Message, there is also a TINFO Speech Message to indicate that traffic information is available in the audio text system.
  • the terminal now also sets up a Speech Connection (MO) to listen to the traffic information to enable.
  • MO Speech Connection
  • the TINFO Speech Message always contains all traffic information selected for the customer in the sorting order as it occurs with the voice server output. After a VINFO request with display and audio text output, the traffic information in the terminal must be sorted according to the TINFO Speech Message. The sorting set by the customer on the end device must be suppressed when audio text is output.
  • the terminal sends version numbers of traffic information known to it to the head office, it receives, as described in Chap. 4.1, with the Traffic Information Message only the new or updated traffic information and with the TINFO Deletion Message back the traffic information to be deleted.
  • the TINFO Speech Message shows all traffic information relevant to the customer in the current sorting (analogous to the T-Traffic update; important message with the Traffic Information Message, all relevant traffic information in current sorting with the TINFO Speech Message).
  • the Automatic establishment of a voice connection from the terminal should be received after receiving the text message with IE status 03h or 04h no longer apply.
  • the request flow for audio text output for the T-Mobile update is accordingly by extending the basic process (Section 4.1.5) to include the transmission of TINFO Speech Message from the head office and the establishment of the Speech Connection (MO) by the end device.
  • the service variant VINFO per-circle (parameterized by the terminal) is not supported by T-Mobil.
  • the request perimeter information (parameterized by the end device) allows you to query traffic events worth reporting from a circular selection area with a range from vig250_circle_min km to vig250_circle_max km (see Section 3.3).
  • the parameters radius and reference point are to be transmitted to the service provider.
  • the customer receives traffic information related to the area (parameterized by the control center) from a circular or sector-shaped selection area. Will be a compass direction are given, traffic information from a direction in this direction selected sector selected. If no direction is given, then Traffic information selected from a circular area.
  • Protocol Relative Regional TINFO Request Message IE Message Type: 0x0E IE Protocol Discriminator: 0x03 Service ID 0xB0
  • 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 of a circle with a range of up to vig250_dist_max km.
  • the circle segment is supplemented by a maximum radius of vig250_r_max km radius around the current position.
  • the orientation of the segment of the circle is determined by specifying the direction angle.
  • the opening angle of the selection area is determined by the basic settings of the end device fixed (e.g. 30 °) and lies between vig250_phi_min and vig250_phi_max.
  • the opening angle can be set in 1 ° steps.
  • the customer receives traffic information from a selection area, that contains the current position as well as the target position. For this, the customer Target position entered.
  • the exact definition of the geometry and orientation of the selection area takes place at the headquarters.
  • a start position can be entered. If the start position is not used, it must be set to 0. protocol Extended TINFO Request Message IE message type 0x03 IE Protocol Discriminator 0x03 Service ID 0xB1
  • 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 about a selected route 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. protocol Extended TINFO Request Message IE message type 0x03 IE Protocol Discriminator 0x03 Service ID 0x13
  • 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 extended TINFO request message (see chapter 3.2, ADP TINFO) is coded at VINFO as follows:
  • the traffic information sent to the terminal with the Traffic Information Message consist of a maximum of 11 blocks (see Chapter 4, ADP). (see explanation below)
  • the basic TINFO contains the blocks General Information, Location (Event), Event (Event) and End.
  • the basic TINFO can optionally include the blocks Cause (cause of the event), Hint (traffic information), Duration (duration of the event), Bypass (diversion recommendation), Average Speed (mean speed at the location of the event) and Event position (exact position of the Event) can be expanded.
  • the block FCD (control of FCD via TINFO) is not supported.
  • a TINFO can consist of 11 different types of blocks, some of which are always present (mandatory, shown below in bold) and others optional.
  • the order of the 11 block types is determined by the block numbering.
  • Optional blocks can exist several times and are initiated by a 4-bit header (e.g. block 2 (hint) occurs twice in succession if there are two notices).
  • a special feature is block 3 (event): the first event block is mandatory and has no header, optionally other event blocks can follow, which are introduced with a header. (This means that in exceptional cases a TINFO can also consist of more than 11 blocks):
  • Geo-Codes Content and structure description of the terminal tables "described in detail.
  • the geo-code table is first created for the Germany area (the procedure is however applicable across Europe) and will become all federal highways in the first implementation stage as well as cover federal highways that directly connect interrupted highways (Road node).
  • the German trunk road core network is thus described by geocodes.
  • at least all important cities are geocoded.
  • Event Codes In exceptional cases free text
  • 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 e.g. B. the length of a traffic jam or the duration of a traffic announcement.
  • the ADP TINFO can only be used for block 3 (event) and block 7 (bypass) quantifiers. Notes and causes that are provided with quantifiers are therefore coded as optional (additional) block 3 (event) (eg "waiting time 2h").
  • Type 1 km e.g. B. 6 km traffic jam
  • Type 2 H
  • Type 3 m
  • Type 4 %
  • Type 5 Phrases (e.g. "short-term”, “partial”, “sometimes”, etc.)
  • Type 6 min e.g. "short-term”, “partial”, “sometimes”, etc.)
  • Type 8 is reserved for diversion quantifiers (see section 4.7.7).
  • Type 6 is reserved for Mannesmann Autocom.
  • the average speed for a section of the route is transmitted not by event code and quantifier, but by means of block 8 (average speed).
  • This block is used to identify a traffic report. He sets the priority and gives with the Bypass Information flag information about the existence of a diversion recommendation at the service provider.
  • the parameter A2VIG2 controls the meaning of the bypass information flag.
  • T-Mobil supports not the query of redirection recommendations via the bypass request message. Rather, if the bypass flag is set, information is recommended using the navigation service Orientation guide to perform a route calculation for a detour route (only possible with end devices that also support navigation services).
  • This block defines the location of the traffic information.
  • the location can be encoded in different ways.
  • the event is between two defined points (e.g. AS GmbH-Süd and AS-Köln-Poll), then the IE First Intersection and last intersection with the corresponding geocodes. It just becomes the standard Location block (see chapter 4.2.1, ADP) supports, but not the special location block (see chapter 4.2.2, ADP).
  • coding is as follows: example road direction Geo code beginning Geo code end 1 A3 01 AK Bonn / Siegburg AS Siebengebirge 2 like example 1 3 like example 1 4 s. below 00 Cologne (see below) Cologne (see below)
  • the same geo-code is transmitted for the beginning and end of the event.
  • the following agreement applies to the IE street: Street type text (15), the text field is empty.
  • the additional information can be transmitted in block 9 (event position) in what distance from the IE first intersection the event is (e.g. traffic jam "10 km” to AK Bonn / Siegburg ").
  • Event codes (event codes or text stored in the end device) is supported, but not the event Type 2 (AlertC codes).
  • Events that are stored in the event code list are described by the event code, otherwise plain text. Events that can be quantified are recorded using the Quantifier described, otherwise without.
  • a TINFO always contains the first event block, optionally several.
  • the optional event blocks provide additional information about the traffic disruption and can be indications / causes, which, however, must be set with block 3 (event) due to the quantifier (e.g. waiting time 2h).
  • coding is as follows: example Event Header Event Type Code flag Event Code quantifier 1 deleted Type 1 1 Traffic jam ($ 080) 5 km 2 like example 1 3 as example 1 (traffic jam), additional optional Event block: 0001 Type 1 1 Waiting time ($ 210) 2h 4 deleted Type 1 1 fog in parts
  • This block describes the cause of the event (see Chapter 4.4, ADP). It will be the cause Type 1 (event codes or text stored in the end device) is supported, but not the Cause Type 2 (AlertC codes).
  • coding is as follows: example Cause header Cause Tvpe Gode flag Event Code 1 0010 Type 1 1 Accident ($ 0a5) 2 like example 1 3 like example 1 4 no cause block
  • 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: example Hint header Hint-Type Code flag Event Code 1 no hint block 2 no hint block 3 0011 Type 1 1 "the traffic is over on the hard shoulder "($ 28a) 4 no hint block
  • time period for which the traffic information applies can be set. It all three duration types are supported.
  • This block is used by T-Traffic to indicate the period of validity of the traffic announcement.
  • the specified duration always refers to an event (e.g. demonstration from 2:00 p.m. to 4:00 p.m.).
  • Block 6 (duration) refers to the 1st event block. It therefore only occurs once in TINFO.
  • a diversion notice can be set in this block. Redirection notices are as Event codes (for redirection notices) or as plain text supported. Locations are as Geo code or supported via IE Street.
  • the bypass block can exist regardless of the bypass flag.
  • the official diversions are encoded using the event codes the main group diversion (coding example see below).
  • the quantifiers for through event codes Coded forwarding notices set.
  • the order of the set quantifiers corresponds to Order of the placeholders in the event code list (see example).
  • the diversion recommendation from Example 2 ("Please use the U 123 from AK Bonn / Siegburg) is coded as follows: Bypass header 0101 Bypass Hint / Presence of IE 1 Flag code / text 1 (event code) Hint Please use from $ the $ ($ 295) Number of addition locations 2 Additional location 1 Type Geo-Code (000), Geo-Code AK Bonn / Siegburg Additional location 2 Type Street (011) Street Type 5 (detour route), Street Number 123 Bypass Route / Presence of IE 0
  • Block 8 (Average Speed) refers to the 1st event block. He therefore occurs in the TINFO only once at most.
  • the distance of the event from that specified in "first intersection” can be Location (see chap. 4.7.2).
  • Block 9 refers to the 1st event block. He therefore occurs in the TINFO only once at most.
  • 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 in the event code / geo code table of the end device is not included), it requests a translation of the unknown code (s) in plain text.
  • the end device sends a TINFO Code Request Message (see Chapter 3.6, ADP TINFO) to the headquarters.
  • a translation block is set for each unknown code.
  • Source format is only supported 0 (event code) and 1 (geo code).
  • destination format only 0 (text) is supported.
  • the head office sends the translation of the code (s) with the TINFO Code Message (see Cape. 2.2, ADP TINFO).
  • TINFO Code Message see Cape. 2.2, ADP TINFO.
  • An explanation block is created for each translated code set. Only 0 (event code) and 1 (geo code) are supported as source format. As a destination Format is only supported 0 (text).
  • the customer must switch between the VINFO output media audio text or display as well as audio text and display (at the same time).
  • the audiotext output by the head office offers the customer in the interest traffic safety the advantage of listening to the information you want without Having to look away from the traffic.
  • the simultaneous output via audio text and display can also make sense for the customer (e.g. for more precise scrolling through the messages), especially from the point of view the automatic storage of relevant, current messages in the end device.
  • T-Mobil encourages the synchronous output of messages via audio text and display. This can be implemented in the end device by evaluating the TINFO Speech Message, which is transmitted by the control center when audio is output (see Chapter 4.1.6).
  • the TINFO Speech Message provides the sequence and length of the traffic information set in the audio text system, which enables the synchronous output of traffic information on the display becomes.
  • the output medium audio text / display or audio text and display should be used for a VINFO request can be set by the customer (possibly through the basic settings). In update mode it should be possible to change the output medium at any time via the menu item and not to do so cause e.g. the first entry (destination etc.) must be repeated. "Audio text" is the default suggested for cases where there is no separate, large display.
  • the head office also sends all messages via SMS (even when selecting customers Audiotext alone), so that a complete, current list of traffic reports is always on the end device is available and the customer when switching from audio text to display or when switching on of the end device after a short absence, this list immediately without a new VINFO request has available.
  • T-Mobil suggests sorting the traffic information available in the end device and its updates the following procedure for a corresponding user menu:
  • the list When displaying the display, the list should be sorted according to the closest in the direction of travel Traffic information may be possible. With this sorting the Customers are shown the traffic information in the order in which they affect him This sorting is not possible for audio text output.
  • the list of traffic information should be sorted according to street classes (e.g. descending from BAB toLite No.).
  • Warning messages always have the highest priority and must be displayed or given priority. A warning tone or the like would be meaningful.
  • the traffic information transmitted to the end device is to be shown to the customer on the display of the end device are presented in the clearest possible form, so as possible for him be easy to grasp and minimize any distraction effect.
  • Every traffic information consists of a number of blocks (see Chap. 4.7).
  • the display capacity of a display is naturally limited.
  • For the clear Understanding traffic information does not necessarily mean the full text the event codes / geo codes are displayed; rather, the implementation becomes meaningful Abbreviations expressly suggested.
  • the corresponding rules and symbols for abbreviations are to be implemented specific to the end device.
  • an automatic mode should Support convenient reading of all messages one after the other (e.g. automatic page change after 10 seconds).
  • the cover of the display should be mirror-free, so that the information is also at The device can be read at an angle.
  • For displaying traffic information graphic skills are not required (different with the navigation service orientation aid).
  • the output of traffic information via audio text is more advantageous and safer than reading from the display. If the customer uses e.g. for longer journeys the update (chap. 4.1.5), the traffic information selected by him for his route is awarded to him.
  • T-Mobil's central audio text system supports fast scrolling to skip or repeat traffic information in a special way to increase customer acceptance.
  • the audio text system is controlled via tone dialing (DTMF), which is supported by the end device must become.
  • DTMF tone dialing
  • the user should have the possibility with only one device command to jump back and forth between individual messages and the different ones Have menu levels (e.g. via skip switch or cursor cross).
  • a remote control from Steering wheel off can only be welcomed from the point of view of traffic safety.
  • the VINFO Cell Broadcast Subservice is a broadcast service in which all traffic information within a radius of at least vig100_r_max km via cell broadcast in the GSM network be transmitted.
  • the traffic information is cyclically reduced to less than 15 Minutes as VINFO data telegram "Traffic Information Message" - Message Type 0x01, Protocol Discriminator 0x03 - sent. You can do this within a data telegram several traffic reports are transmitted.
  • the individual messages are based on their Version number (ID + Time Stap) can be clearly identified (same identifier for interactive and collective service).
  • the data can be operated in cell broadcast mode be encrypted.
  • the type of encryption is used in the CAS framework for cell broadcast Operation determined in which the user data are embedded.
  • VINFO service via cell broadcast should be the same for the customer as that of the interactive VINFO service. Therefore, the selection criteria should also be related to the environment VINFO, cardinal direction-related VINFO, targeted VINFO and route-related VINFO are supported.
  • the menu structure should be identical to that of the interactive ones VINFO services.
  • the corresponding area filters for VINFO CB are on the terminal side to realize. Recommendations for their parameterization are summarized in Section 5.5. In addition, the filtering according to "long-distance network" or "all roads” should be implemented (see chapters 2.1.4 to 2.1.6).
  • the interactive VINFO service is used as a fallback solution when CB reception is interrupted Query of messages that are outside the current CB-VINFO coverage area and used to translate messages that cannot be decoded (see Section 5.4).
  • Each traffic report is assigned an expiry time.
  • the expiry time begins on receipt of the Data telegram in which the traffic report occurs. After the expiration time, the Traffic announcement is valid and must be deleted.
  • the service provider permanently sends the current traffic events for via cell broadcast the broadcasting area.
  • the data telegram contained in it After receiving a cell broadcast page, the data telegram contained in it must be included Decrypted using the service key - see Internal Services and Key Management. The individual traffic reports within the decrypted data telegram are separated. The following rules apply to them.
  • All existing messages for a range of at least vig_100_r_max km (radius) related to the current vehicle position are distributed via CB.
  • the following criteria are to be evaluated to assess their relevance for an issue: event location within the selection area, priority class, validity period, street class, status: new, updated, deleted, old.
  • 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 of the current one CB-VINFO coverage area, and non-decodable for translation Messages used.
  • the traffic reports queried interactively from the CB mode are treated as regular CB messages in terms of priority, expiry time, etc.
  • the size of the selection areas to be set in CB is only possible through the current parameterization (see chapter 3.3 for value ranges) limited.
  • T-Mobil is initially broadcast all traffic information with "long-distance effect" nationwide, with the repetition frequency is increased with decreasing distance to the event location. Therefore, it is also great Travel distances initially do not require an interactive request to supplement the CB information and allowed.
  • VINFO query is activated via VIG_Ctrl2, A2VIG3 (see Chapter 3.4).
  • the end device receives messages via the CB-VINFO service with the available reference lists (Event Codes, Geo Codes) are not decodable, can be done with the TINFO Code Request Message, a translation according to the procedure described in section 4.7.12 be requested.
  • Event Codes Geo Codes
  • 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 r_loc (for value, see section 5.5 above, VINFO per circle) Radius of the sector r_seg: according to customer choice "local, regional, national", (For value, see section 5.5 above, VINFO per circle)
  • 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_pni_max.
  • the data communication between the terminal and the control center is carried out by the GSM available short message service.
  • the short message services SMS-MT (TS 21) and SMS-MO (TS 22) are required.
  • the end device must have a location component (GPS receiver).
  • the location accuracy must be ⁇ 250 m on average.
  • the terminal For the VINFO service, the terminal must at least 200 Save traffic information can.
  • the traffic information is to be stored in a non-volatile memory, e.g. B. after brief breaks in the journey to still be present.
  • the geocode table stored in the end device should be used to enter start and target positions can be used.
  • a notebook In order to facilitate the entry of start and destination points, a notebook should be in the end device with at least 50 entries, from which u.a. also the address description adopted can be.
  • the end device should have a text display and a convenient input option.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Traffic Control Systems (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)

Description

Die Erfindung betrifft ein Verfahren und eine Anordnung zur Verkehrsinformation nach dem Oberbegriff der unabhängigen Patentansprüche.
Durch das stetig wachsende Verkehrsaufkommen wird der Bedarf an hochwertigen Systemen zur Verkehrsinformation und Verkehrsleitung immer dringlicher. Dabei ergeben sich jedoch die Probleme, wie dem Benutzer stets aktuelle Informationen zur Verfügung gestellt werden können, die ihm gleichzeitig einen hohen Benutzerkomfort bieten.
Die WO-A-96/11381 betrifft eine Einrichtung zur Zielführung von Personen. Die Einrichtung umfasst eine Navigationseinheit, die eine Empfangseinrichtung für drahtlos übermittelte Informationen zur Erkennung der aktuellen geographischen Position aufweist, eine Kommunikationseinheit, die eine Eingabeeinheit insbesondere zur Eingabe einer Zielposition und eine Ausgabeeinheit, insbesondere zur Ausgabe von Wegführungsinformation umfaßt. Ferner ist ein zentraler Rechner zur Routenplanung vorgesehen, der einen Speicher mit mindestens einer digitalisierten Straßenkarte aufweist und der mit der Navigationseinheit über die Kommunikationseinheit datentechnisch verbindbar ist. Der Rechner übermittelt die berechneten Routeninformationen an die Navigationseinheit. Die Möglichkeit einer Verkehrsinformation ist nur am Rande angesprochen.
Die EP 0 317 181 betrifft primär ein Routenplanungs- und Zielführungssystem, wobei ein Computercenter vorgesehen ist, in welchem unter anderem Informationen über die aktuelle Verkehrslage gespeichert werden. Diese Verkehrsdaten werden zur Routenplanung und zielführung verwendet. Diese Druckschrift enthält jedoch keine Hinweise, daß ein eigenständiges Verkehrs-Informationssystem zur individuellen Information des Verkehrsteilnehmers vorhanden ist.
Die Aufgabe der Erfindung besteht darin, ein Verfahren und eine Anordnung zur Verkehrsinformation mobiler Teilnehmer vorzuschlagen, das dem Teilnehmer stets aktuelle Informationen zur Verfügung stellt und ihm gleichzeitig einen hohen Benutzerkomfort bietet.
Diese Aufgabe wird gelöst durch die Merkmale der unabhängigen Patentansprüche. Weitere mögliche Ausgestaltungsformen der Erfindung sind den abhängigen Patentansprüchen angegeben.
Insbesondere können Daten auf verschiedenste Ausgangsparameter bezogen werden, z.B. Orts-, Start- oder Zielinformationen bzw. Streckeninformationen der Fahrt, zentrale- oder endgeräteseitige Abfragen, die gerätegestützt oder personengestützt durchgeführt werden können. Die Datenübertragungen können zu Informationserfassungszwecken und/oder zu Informationsübertragungszwecken wie auch zur Informationsaktualisierung durchgeführt werden.
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 werden. 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
Figure 00030001
2.1.2 Unterstützte Dienste Alternative 2
Figure 00030002
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") , Umleitungshinweis (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), Umleitungsempfehlung (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 zentralseitig 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 Femstreckennetz. Damit werden das Überschütten des Kunden" mit nicht relevanten Verkehrsinfos vermieden und insbesondere 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.
Verkehrsintos 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/AbstandEs sollte eine Sortierung der Liste nach in Fahrtrichtung nächstgelegenen Verkehrsinformationen möglich sein. Durch diese Sortierung werden dem Kunden die Verkehrsinfos in der Reihenfolge angezeigt, in der sie ihn betreffen.
  • Sortierung nach StraßenklassenEs sollte eine Sortierung der Liste nach Straßenklassen (z. B. absteigend von BAB bis Gemeindestraße) möglich sein.
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 pararnetriert) 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 "Iokal",
  • bei VINFO regional:   Verkehrsinfos zu den Klassen 1 bis 4 innerhalb Kreis/Sektor "Iokal", Verkehrsinfos zu den Klassen 2 bis 4 außerhalb Kreis/Sektor"Iokal" und innerhalb Kreis/Sektor "regional"
  • bei VINFO überregional:   Verkehrsinfos zu den Klassen 1 bis 4 innerhalb Kreis/Sektor "Iokal", Verkehrsinfos zu den Klassen 2 bis 4 außerhalb Kreis/Sektor"Iokal" und innerhalb Kreis/Sektor"regional", Verkehrsinfos zu den Klassen 3 und 4 außerhalb Kreis/Sektor "regional" und innerhalb Kreis/Sektor "überregional"
Die Festlegung der entsprechenden Kreisradien für "Kreis lokal" (r_loc), "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:
Infrastruktur Kreis lokal (r_loc) Kreis regional (r_reg) Kreis überregional (r_überreg)
Ballungsraum 5 km 25 km 50 km
urbane Gebiete 15 km 35 km 75 km
ländliche Gebiete 25 km 45 km 100 km
Figure 00070001
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.
Figure 00070002
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 Fernstreckennetz" erhält der Kunde innerhalb des Setektionsgebiets 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 "Iokal", 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.
Figure 00080001
2.1.6 Kurzbeschreibung Streckenbezogene 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 Femstreckennetz 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 00090001
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:
  • Coding of Text and Transparent Data
  • Address Coding
  • Coding of Extended Location Message
  • Coding of Absolute Time
  • Area and Location Coding
  • Event-Codes
  • Geo-Codes
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.
3 Allgemeine Abläufe 3.1 Transportprotokoll - Handling
Zur Nutzung des interaktiven Verkehrsinformations-Dienstes wird das Transportprotokoll wie folgt verwendet:
Figure 00120001
Der Transportrahmen unterstützt das Versenden von Nutzdaten über mehrere Short-Messages hinweg. Das Verfahren ist im Dokument "Transport Protocol" festgelegt.
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 B0h VINFO umkreisbezogen (von Zentrale parametriert) / himmelsrichtungsbezogen
Service ID B1h 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. "Selektionsgebiet größer als vig100 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 Numberng" 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.
ID Parameter Function / Definition Unit Defaul t Range Reso lutio n T-Mobil
0 VIG_K101 Speicherdauer einer CB-Verkehrsmeldung Prio 1 min 5 0 - 60 5 v
1 VIG_K102 Speicherdauer einer GB-Verkehrsmeldung Prio 2 min 10 0 - 60 5 v
2 VIG_K103 Speicherdauer einer CB-Verkehrsmeldung Prio 3 min 15 0 - 60 5 v
3 VIG_K104 Speicherdauer einer CB-Verkehrsmeldung Prio 4 min 20 0 - 60 5 v
4 VIG_T109 maximale Wartezeit für eine Antwort von der Dienste-Zentrale sec 180 0 - 600 5 v
5 VIG_T110 Wartezeit zwischen dem Ausbleiben von Verkehrsmeldungen via Cell Broadcast und der Verlängerung der Zerfallszeit einer Verkehrsmeldung sec 300 60 - 600 10 v
6 VIG_T111 Speicherungsdauer für im CB empfangene Meldungen bei temporärer oder lokaler Nichtverfügbarkeit des CB min 30 0 - 60 5 v
7 VIG_T112 Max. Speicherungsdauer interaktiv abgefragter Meldungen min 120 30 - 120 5 v
8 VIG_T113 Max. Wartezeit des Endgerätes zwischen 2 SMSen einer Antwort der Zentrale sec 300 0 - 400 5 v
9 vig100_r_ max max. Radius des Ausstrahlungsgebietes im VIG100 Subdienst km 300 1-300 1 v
10 vig250_ circle_max maximaler Radius einer Umkreis-Info,
r überreg 		km 75 10-500 10 v
11 vig250_ circle_min minimaler Radius einer Umkreis-Info,
r loc 		km 15 1-250 1 v
12 vig250_dir_ max maximaler Winkel für die Ausrichtung einer Kreissegment-Infogegen Norden im Uhrzeigersinn grad 359 0-359 1 nv
13 vig250_dir_ min minimaler Winkel für die Ausrichtung einer Kreissegment-Info gegen Norden im Uhrzeigersinn grad 0 0-359 1 nv
14 vig250_dist_max maximale Reichweite einer Kreissegment-Info km 100 10-500 10 nv
15 vig250_dist_min minimale Reichweite einer Kreissegment-Info km 1 1-500 1 nv
16 vig250_phi_ max maximaler Öffnungswinkel einer Kreissegment-Info grad 180 1-180 1 v
17 vig250_phi_min minimaler Öffnungswinkel einer Kreissegment-Info grad 30 1-180 1 v
18 vig250_r_max maximaler Radius einer Kreissegment-Info km 50 1-250 1 nv
19 vig250_r_min minimaler Radius einer Kreissegment-Info km 1 0-250 1 nv
20 vig250_street_ max maximale Anzahl von Straßen, für die eine Straßen-Info abgefragt werden kann. 5 0-15 1 v
21-25 reserved reserved for Mannesmann Autocom GmbH nv
26 vig_up_per_max maximale Anfrageperiode bei T-Mobil-Update von Ver- kehrsinfos min 15 0-60 5 v
27 vig_up_dist Schwellwert für zurückgelegte Weglänge bei T-Mobil-Update von Verkehrsinfos km 50 10-500 10 v
28 vig_cb_req1_max maximale Anzahl von interaktiven Anfragen aus CB bei Telefonie 10 0-500 1 v
29 vig_cb_req2_max maximale Anzahl von interaktiven Anfragen aus CB, falls kein CB-Empfang 10 0-500 1 v
30 vig250_ circle_med r_reg km 35 1-250 1 v
31-60 reserved reserved nv
61 VIG_Ctrl1 Bit-Flags zur Ablaufsteuerung Flag 16 bits v
62 VIG_Ctrl2 Bit-Flags zur Ablaufsteuerung Flag 16 bits v
63 VIG_Ctrl3 Bit-Flags zur Ablaufsteuerung Flag 16 bits nv
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:
Bit No Abbrev. Description T-Mobil- Default
1 A1VIG1 Aktivierung Cell Broadcast VINFO 0
2 A1VIG2 zentralgesteuerter Update (über IE Update Duration) wird unterstützt 1
3 A1VIG3 Zentrale sendet VINFO ptp auch unabhängig von einer Initiative des Endgeräts 1
4 A1VIG4 Zentrale unterstützt umkreisbezogene VINFO (vom EG parametriert) 0
5 A1VIG5 Zentrale unterstützt umkreisbezogene VINFO (von Zentrale parametriert) 1
6 A1VIG6 Zentrale unterstützt kreissegmentbezogene VINFO 0
7 A1VIG7 Zentrale unterstützt zielgerichtete VINFO 1
8 A1VIG8 Zentrale unterstützt streckenbezogene VINFO 1
9 A1VIG9 Zentrale unterstützt Start-, Zielpunkt bei strekkenbezogener VINFO 1
10 A1VIG10 Zentrale unterstützt Selektionsgebiet bei strekkenbezogener VINFO 0
11 A1VIG11 Zentrale unterstützt Mode Speech (Audiotext) 1
12 A1VIG12 Zentrale unterstützt Ausgabeformat Text 1
13 A1VIG13 Zentrale unterstützt TINFO Text Request Message 0
14 A1VIG14 Zentrale unterstützt TINFO Code Request Message 1
15 A1VIG15 Zentrale unterstützt Bypass Request Message 0
16 A1VIG16 reserved
VIG_Ctrl2 ist in folgender Tabelle aufgeschlüsselt:
Bit No Abbrev. Description T-Mobil- Default
1 A2VIG1 Zentrale unterstützt FCD-Flag (TINFO Block 10) 0
2 A2VIG2 A2VIG 18 steuert Bedeutung des Bypass Flags (TINFO Block 1): A2VIG18 = 0: Zentrale empfiehlt Umleitungsanforderung über Bypass Request Message, A2VIG18 = 1: Zentrale empfiehlt Umleitungsanforderung über Navigationsdienst Orientierungshilfe 1
3 A2VIG3 Zentrale unterstützt interaktive Anfrage bei CB, falls Selektionsgebiet größer als vig100_r_max 1
4 A2VIG4 reserved
5 A2VIG5 reserved
6 A2VIG6 reserved
7 A2VIG7 reserved
8 A2VIG8 reserved
9 A2VIG9 reserved
10 A2VIG10 reserved
11 A2VIG11 reserved
12 A2VIG12 reserved
13 A2VIG13 reserved
14 A2VIG14 reserved
15 A2VIG15 reserved
16 A2VIG16 reserved
3.5 Codierung von Text
Alle Textelemente innerhalb der Verkehrsinformationsdienste verwenden folgendes Format:
Figure 00190001
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 00210001
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" (0x0) gesetzt. Die Zentrale antwortet auf jede Anfrage einmalig mit der entsprechenden Antwortnachricht.
Figure 00220001
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 00230001
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 Update-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.
Figure 00260001
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 alle 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 alle für den Kunden relevanten Verkehrsinfos in aktueller Sortierung angezeigt (analog beim T-Traffic-Update; wichtige Meldung mit der Traffic Information Message, alle 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 Items=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 00280001
Figure 00280002
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: 0x0E
IE Protocol Discriminator: 0x03
Service ID 0xB0
Figure 00290001
Die Wahl der Dienstevariante Umkreisbezogene VINFO (von Zentrale parametriert) bzw. Himmelsrichtungsbezogene VINFO erfolgt typischerweise nach folgendem Ablauf:
  • 1. Auswahl lokal / regional / überreqional Der Kunde wählt eine der Varianten lokal / regional / überregional aus.
  • 2. Auswahl der Startposition Der Kunde wird aufgefordert, die aktuelle Position als Startposition zu bestätigen. Bestätigt er dies nicht, so wird er zur Auswahl einer Startposition aus der Geocode-Städteliste bzw. aus seinem persönlichen Adreßbuch aufgefordert. Bei Auswahl aus der Geocode-Städteliste ist der Geocode in die entsprechenden Koordinaten umzuwandeln.
  • 3. Auswahl einer Himmelsrichtung bei VINFO himmelsrichtungsbezogen Bei VINFO Himmelsrichtungsbezogen wählt der Kunde eine Himmelsrichtung aus (8 mögliche Alternativen: N, NO, O, SO, S, SW, W, NW).
  • 4. Auswahl "Verkehrsinfos zum Fernstreckennetz" / "Verkehrsinfos zu allen Straßen" Die Defaulteinstellung ist "Verkehrsinfos zum Fernstreckennetz". Alternativ kann der Kunde "Verkehrsinfos zu allen Straßen" auswählen.
  • 5. Auswahl Update von Verkehrsinfos Der Kunde erhält die Möglichkeit, einen automatischen Update der Verkehrsinfos anzufordern. Dazu wird ihm ein Schalter "Update-Modus ein/aus" bzw. die Eingabe einer Dauer für den Update-Modus angeboten. Der Update-Modus ist jederzeit manuell deaktivierbar.
  • 6. Übertragung der VINFO-Anfrage Das Endgerät stellt die Relative Regional TINFO Request Message zusammen (siehe Kap. 4.3.1) und überträgt sie zur Zentrale.
  • 7. Filterung der Verkehrsinfos Nach Erhalt der VINFO-Anfrage bestimmt die Zentrale das Selektionsgebiet. Innerhalb des Selektionsgebiets werden die Verkehrsinfos herausgefiltert. Zusätzlich wird der Filter "Fernstreckennetz" / "alle Straßen" verwendet (siehe Kap. 2.1.4).
  • 8. Übertragung der Verkehrsinfos Die Zentrale überträgt die ausgefilterten Verkehrsinfos mit der Traffic Information Message (Kodierung siehe Kap. 4.7). Liegen keine Verkehrsinfos vor bzw. können keine Verkehrsinfos übertragen werden (Überlast, Ausfall von Zentralenkomponenten, etc.), wird der Kunde durch Übertragung der Text Message informiert (Kodierung siehe Kap. 2.7, ADP TINFO). Die Zentrale sendet die TINFO Deletion Message, um ungültige Verkehrsinfos im Endgerät zu löschen (Kodierung siehe Kap. 2.4, ADP TINFO).
  • 9. Präsentation der Verkehrsinfos Die Verkehrsinfos werden vom Endgerät entsprechend dem gewählten Sortierverfahren sortiert und zur Anzeige gebracht (siehe Kap. 4.9). Die Liste der Verkehrsinformationen wird im Endgerät gespeichert.
  • 10.Update von Verkehrsinfos Bei einem Update-Duration-Code von 000001 merkt die Zentrale die VINFO-Anfrage vor und schickt bei Vorlage von wichtigen Warn- und Verkehrsmeldungen initiativ eine Traffic Information Message oder TINFO Deletion Message. Das Endgerät stellt, gesteuert durch Zeit- und Weglängentrigger, neue VINFO-Anfragen (siehe Kap. 4.1.5). Der Ablauf wird ab Punkt 6 erneut angestoßen.
    • 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 00310001
    Figure 00320001
    4.4 VINFO kreissegmentbezogen
    Bei kreissegmentbezogener VINFO erhält der Kunde Verkehrsinformationen aus einem kreissegmentfö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 00320002
    Figure 00330001
    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 0xB1
    Figure 00330002
    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 Fernstreckennetz" / "Verkehrsinfos zu allen Straßen" Die Defaulteinstellung ist "Verkehrsinfos zum Fernstreckennetz". Alternativ kann der Kunde "Verkehrsinfos zu allen Straßen" auswählen.
  • 4. Auswahl Update von Verkehrsinfos Der Kunde erhält die Möglichkeit, einen automatischen Update der Verkehrsinfos anzufordem. Dazu wird ihm ein Schalter "Update-Modus ein/aus" bzw. die Eingabe einer Dauer für den Update-Modus angeboten. Der Update-Modus ist jederzeit manuell deaktivierbar.
  • 5. Übertragung der VINFO-Anfrage Das Endgerät stellt die Extended TINFO Request Message zusammen (siehe Kap. 4.5.1) und überträgt sie zur Zentrale.
  • 6. Filterung der Verkehrsinfos Nach Erhalt der VINFO-Anfrage bestimmt die Zentrale aus Start- und Zielposition das Selektionsgebiet. Innerhalb des Selektionsgebiets werden die Verkehrsinfos herausgefiltert. Zusätzlich wird der Filter "Fernstreckennetz" / "alle Straßen" verwendet (siehe Kap. 2.1.5).
  • 7. Übertragung der Verkehrsinfos Die Zentrale überträgt die ausgefilterten Verkehrsinfos mit der Traffic Information Message (Kodierung siehe Kap. 4.7). Liegen keine Verkehrsinfos vor bzw. können keine Verkehrsinfos übertragen werden (Überlast, Ausfall von Zentralenkomponenten, etc.), wird der Kunde durch Übertragung der Text Message informiert (Kodierung siehe Kap. 2.7, ADP TINFO).
    Die Zentrale sendet die TINFO Deletion Message, um ungültige Verkehrsinfos im Endgerät zu löschen (Kodierung siehe Kap. 2.4, ADP TINFO).
  • 8. Präsentation der Verkehrsinfos Die Verkehrsinfos werden vom Endgerät entsprechend dem gewählten Sortierverfahren sortiert und zur Anzeige gebracht (siehe Kap. 4.9). Die Liste der Verkehrsinformationen wird im Endgerät gespeichert.
  • 9. Update von Verkehrsinfos Bei einem Update-Duration-Code von 000001 merkt die Zentrale die VINFO-Anfrage vor und schickt bei Vorlage von wichtigen Warn- und Verkehrsmeldungen initiativ eine Traffic Information Message oder TINFO Deletion Message. Das Endgerät stellt, gesteuert durch Zeit- und Weglängentrigger, neue VINFO-Anfragen (siehe Kap. 4.1.5). Der Ablauf wird ab Punkt 6 erneut angestoßen.
    • 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 00350001
    Figure 00360001
    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
    Figure 00370001
    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.
  • 3. Auswahl der Startposition Der Kunde wird aufgefordert, die aktuelle Position als Startposition zu bestätigen. Bestätigt er dies nicht, so wird er zur Auswahl einer Startposition aus der Geocode-Städteliste bzw. aus seinem persönlichen Adreßbuch aufgefordert. Bei Auswahl aus dem Adreßbuch sind die Koordinaten der Adresse in den entsprechenden Geocode umzuwandeln.
  • 4. Eingabe der Straße(n) Der Kunde wird aufgefordert, die Straße bzw. die Straßen (maximal 5 Straßen, siehe Parameter vig250_street_max) in Durchfahrtreihenfolge einzugeben. Für jede Straße ist Kennung und Nummer anzugeben (z. B. A 59). Die Eingabe einer Straße in Freitext wird nicht unterstützt.
  • 5. Auswahl Update von Verkehrsinfos Der Kunde erhält die Möglichkeit, einen automatischen Update der Verkehrsinfos anzufordem. Dazu wird ihm ein Schalter "Update-Modus ein/aus" bzw. die Eingabe einer Dauer für den Update-Modus angeboten. Der Update-Modus ist jederzeit manuell deaktivierbar.
  • 6. Übertragung der VINFO-Anfrage Das Endgerät stellt die Extended TINFO Request Message zusammen (siehe Kap. 4.6.1) und überträgt sie zur Zentrale.
  • 7. Filterung der Verkehrsinfos Nach Erhalt der VINFO-Anfrage filtert die Zentrale die Verkehrsinfos auf der Strecke in Fahrtrichtung heraus. Der Kunde erhält für die gewählte Strecke Verkehrsinformationen aller Klassen (keine Filterung nach Fernstreckennetz o. ä.).
  • 8. Übertragung der Verkehrsinfos Die Zentrale überträgt die ausgefilterten Verkehrsinfos mit der Traffic Information Message (Kodierung siehe Kap. 4.7). Liegen keine Verkehrsinfos vor bzw. können keine Verkehrsinfos übertragen werden (Überlast, Ausfall von Zentralenkomponenten, etc.), wird der Kunde durch Übertragung der Text Message informiert (Kodierung siehe Kap. 2.7, ADP TINFO). Die Zentrale sendet die TINFO Deletion Message, um ungültige Verkehrsinfos im Endgerät zu löschen (Kodierung siehe Kap. 2.4, ADP TINFO).
  • 9. Präsentation der Verkehrsinfos Die Verkehrsinfos werden vom Endgerät entsprechend dem gewählten Sortierverfahren sortiert und zur Anzeige gebracht (siehe Kap. 4.9). Die Liste der Verkehrsinformationen wird im Endgerät gespeichert.
  • 10.Update von Verkehrsinfos Bei einem Update-Duration-Code von 000001 merkt die Zentrale die VINFO-Anfrage vor und schickt bei Vorlage von wichtigen Warn- und Verkehrsmeldungen initiativ eine Traffic Information Message oder TINFO Deletion Message. Das Endgerät stellt, gesteuert durch Zeit- und Weglängentrigger, neue VINFO-Anfragen (siehe Kap. 4.1.5). Der Ablauf wird ab Punkt 6 erneut angestoßen.
    • 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 strekkenbezogen wie folgt kodiert:
    Figure 00390001
    Figure 00400001
    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), Average 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-Typ (z. B. Anschlußstelle, Autobahnkreuz, Autobahndreieck, Grenzübergang, Stadt)
    • die referenzierte Straße (A3, B8)
    • den Namen (z. B. Beuel, Köln)
    • bei Autobahnanschlußstellen/-kreuzen/-dreiecken die Nummer der Ausfahrt gemäß der offziellen Verzeichnisse (für beide Fahrtrichtungen)
    • der Name der Fernziele für das Autobahnteilstück ("Von_Ort" und "Nach_Ort", z. B. A2 "Dortmund", "Hannover", die Richtungsinformation wird gemäß ADP TINFO zusätzlich übertragen)
    Die Information "A3, Autobahnkreuz Bielefeld" ist dementsprechend codiert durch den Geocode-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 Quantifiern 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", "Nach_Ort").
    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 1 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).
    Im Beispiel wird wie folgt codiert:
    Beispiel Cause-Header Cause-Tvpe Gode-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-Type Code-Flag Event-Code
    1 kein Hint-Block
    2 kein Hint-Block
    3 0011 Type 1 1 "der Verkehr wird über
    den Standstreifen geleitet" ($28a)
    4 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.
    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 Fehierbehandlung
    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.ä.) 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.ä.)
    • Ergibt der Update keinerlei neue Meldungen, sollte trotzdem eine Funktionsmeldung als allgemeine Textnachricht angezeigt werden, um das Kundenvertrauen in die Funktion von Endgerät und Dienst zu stärken. Demgegenüber erscheint es unter Kostengesichtspunkten nicht vertretbar, im Falle der Audio-Ausgabe für den gleichen Zweck automatisch eine Sprachverbindung zum Audiotext-System herzustellen. Hier sollte die vertrauensbildende Meldung lediglich per SMS / Display erfolgen oder darauf verzichtet werden.
  • 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.ä. 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 Scroil-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.
    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 strekkenbezogene 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äteseitig 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 separiert. Auf sie sind folgende Regeln anzuwenden.
    Regeln:
  • 1 Vorbedingung: Verkehrsmeldung hat Priorität 1 (0x00)
    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_t1 11.
    • 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 vig_k104 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).
    Figure 00540001
    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 T110 und T111(s. Abb 6-3 in Kapitel 7) genutzt. T110 wird beim Empfang jedes CB-Datentelegramms zurückgesetzt und erneut gestartet. Erreicht T110 seinen Maximalwert VIG_T110, ohne daß ein weiteres CB-Datentelegramm 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_T110 (n = 1 ... VIG_T111/VIG_T110) keine neuen Verkehrsinformationen empfangen wurden und die Möglichkeit zur Abfrage per interaktivem VINFO-Dienst besteht. Macht er von dieser keinen Gebrauch, wird die Meldung maximal n= VIG_T111/VIG_T110 wiederholt. Anschließend bekommt der Kunde den Hinweis, daß keine gültigen Verkehrsinformationen mehr vorliegen.Wünscht der Kunde die Abfrage über den interaktiven Dienst, wird der Zähler vig_cb_req1 um 1 erhöht. Dieser Ablauf kann bis zum Erreichen der Wertes vig_cb_req1_max (s. Kapitel 3.3) wiederholt werden. Der Zähler wird nach 24 h zurückgesetzt. Ist der Maximalwert vig_cb_req1_max noch nicht erreicht, wird die interaktive Abfrage durchgeführt. Dabei sind die gewählten Selektionsgebiete und - parameter auf die Anfragetypen umkreis-, himmelsrichtungs-, streckenbezogen bzw. zielgerichtet abzubilden. Empfehlungen für die entsprechenden Parameter sind in Kapitel 5.5 zusammengestellt. Es werden im Rahmen der CB-Emulation nur einmalige Anfragen unterstützt. Die Zentrale stellt über den Zeitraum VIG_T110 die Versorgung mit besonders wichtigen VINFO's sicher. Nicht unterstützt werden Anfragen mit Sprachausgabe.
  • Fall b): Kein CB-Empfang wegen temporärer/lokaler Nichtverfügbarkeit des Dienstes Zunächst wird der Zähler vig_cb_req2 um 1 erhöht. Dieser Ablauf kann bis zum Erreichen der Wertes vig_cb_req2_max (s. Kapitel 3.3) wiederholt werden. Der Zähler wird nach 24 h zurückgesetzt. Ist der Maximalwert vig_cb_req2_max noch nicht erreicht, wird die interaktive Abfrage durchgeführt. Dabei sind die gewählten Selektionsgebiete und -parameter auf die Anfragetypen umkreis-, himmelsrichtungs-, streckenbezogen bzw. zielgerichtet abzubilden. Empfehlungen für die entsprechenden Parameter sind in Kapitel 5.5 zusammengestellt. Es werden im Rahmen der CB-Emulation nur einmalige Anfragen unterstützt. Die Zentrale stellt über den Zeitraum VIG_T110 die Versorgung mit besonders wichtigen VINFO's sicher. Nicht unterstützt werden Anfragen mit Sprachausgabe.
    • Für beide Fälle a) und b) gilt, daß nach Erreichen des jeweiligen Maximalwertes (vig_cb_req1_max bzw. vig_cb_req2_max) 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 Setektionsgebiete und -parameter auf die Anfragetypen umkreis-, himmelsrichtungs-, strekkenbezogen 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
    Umkreisradius Wert
    r_loc vig250_circle_min
    r_reg vig250_circle_med
    r_überreg vig250_circle_max
    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.
    Figure 00570001
    Radius des Umkreises = r_loc (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.
    Figure 00570002
    Radius des Umkreises = r_loc (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_pni_max.
    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 verfügen.
    Empfehlung für das Display: 4 Zeilen, 20 Zeichen/Zeile
    Es wird empfohlen, bei kostengünstiger Realisierbarkeit künftig eine einfache Sprachausgabe einzurichten.
    7 Verkehrsmeldungsverwaltung - Realisierungsvorschlag
    Figure 00590001
    Figure 00600001
    Figure 00610001
    Figure 00610002
    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 IE's first intersection und last intersection auszuwerten. Um festzustellen, ob die Route von einer vorliegenden Verkehrsinformation betroffen ist, sind alle Anschlußstellen, Kreuze und Dreiecke der referenzierten Straße, deren Geocodes zwischen den im IE first intersection und IE last intersection angegebenen Orten liegen, zu identifizieren. Die Selektion ist anhand der Straßenbezeichnung (siehe Kap. 3.2.2, Geo-Codes) sowie der Nummer (siehe Kap. 3.2.6, Geo-Codes) durchzuführen. Liegen ein oder mehrere der selektierten Geocodes innerhalb einer der Korridore der Routenbeschreibung, sollte die Verkehrsinformation als relevant betrachtet und dem Kunden zur Anzeige gebracht werden.

    • Claims (22)

    1. Verfahren zur Verkehrsinformation, wobei auf Anfrage oder automatisch Daten zwischen einer Zentraleinheit und einer mobilen Teilnehmereinheit übertragen werden, wobei die Daten Verkehrsinformationen beinhalten, die aufbereitet und auf Anfrage oder automatisch durch die mobile Teilnehmereinheit an den Teilnehmer ausgegeben werden,
      dadurch gekennzeichnet, dass die Verkehrsinformationen in der Zentraleinheit und/oder der mobilen Teilnehmereinheit anhand eines vom Teilnehmer ausgewählten geometrischen Selektionsgebietes oder eines vom Teilnehmer ausgewählten Streckenabschnitts teilnehmerindividuell gefiltert werden, wobei die Verkehrsinformationen je nach ihrer Priorität einer Klasse zugeordnet werden und ebenfalls eine Filterung anhand der Klassenzuordnung erfolgt.
    2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Aufbereitung und Bereitstellung der Verkehrsinformationen auf die individuellen Bedürfnisse des Teilnehmers zugeschnitten wird.
    3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Größe des Selektionsgebiets vom Teilnehmer definierbar ist.
    4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die Übertragung der Daten zu Informationserfassungszwecken und/oder Informationsübertragungszwecken und/oder zur Informationsaktualisierung durchgeführt wird.
    5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß die Daten auf verschiedenste Ausgangsparameter bezogen werden, wie Orts-, Start- oder Zielinformationen, Streckeninformationen der Fahrt, zentrale- oder endgeräteseitige Abfragen, die gerätegestützt oder personengestützt durchgeführt werden.
    6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß die Übertragung der Daten über ein GSM-Mobilfunknetz erfolgt.
    7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß die Daten über den Kurznachrichtendienst SMS des GSM-Mobilfunknetzes übertragen werden.
    8. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß die Daten über den Telefoniedienst übertragen werden.
    9. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß die Daten in Form einer Broadcastnachricht CB übertragen werden.
    10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß Verkehrsinformationen aus unterschiedlichen Quellen gesammelt, aufbereitet und individuell für die einzelnen Teilnehmer zusammengestellt werden.
    11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, daß als Quellen für die Verkehrsinformationen Verkehrsinformationszentralen, Landesmeldestellen, Staumelder verwendet werden.
    12. Verfahren nach Anspruch 10, dadurch gekennzeichnet, daß als Quelle für die Verkehrsinformationen stationäre Erfassungssysteme verwendet werden.
    13. Verfahren nach Anspruch 10, dadurch gekennzeichnet, daß als Quelle für die Verkehrsinformationen die Teilnehmer des Verkehrsinformationssystems selbst verwendet werden.
    14. Verfahren nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, daß die Verkehrsinformationen in der mobilen Teilnehmereinheit nach Aktualität, Fahrtrichtung/Abstand und Strassenklassen sortiert werden.
    15. Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, daß die Daten dem Teilnehmer graphisch und/oder akustisch mitgeteilt werden.
    16. Verfahren nach einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, daß eine Standortbestimmung des Teilnehmers durch eine Ortungskomponente erfolgt.
    17. Anordnung zur Verkehrsinformation, wobei mindestens eine Zentraleinheit sowie mindestens eine mobile Teilnehmereinheit vorgesehen sind, wobei ein mobiles Kommunikationssystem vorgesehen ist, über das auf Anfrage oder automatisch Verkehrsinformationen zwischen der Zentraleinheit und der mobilen Teilnehmereinheit übertragen werden,
      dadurch gekennzeichnet, dass in der Zentraleinheit und/oder der mobilen Teilnehmereinheit Mittel vorhanden sind, durch welche die Verkehrsinformationen anhand eines vom Teilnehmer ausgewählten geometrischen Selektionsgebietes oder eines vom Teilnehmer ausgewählten Streckenabschnitts teilnehmerindividuell gefiltert werden, wobei die Verkehrsinformationen je nach ihrer Priorität einer Klasse zugeordnet werden und ebenfalls eine Filterung anhand der Klassenzuordnung erfolgt.
    18. Anordnung nach Anspruch 17, dadurch gekennzeichnet, daß das mobile Kommunikationssystem ein GSM-kompatibles Mobilfunksystem ist.
    19. Anordnung nach Anspruch 17 oder 18, dadurch gekennzeichnet, daß die mobile Teilnehmereinheit ein Endgerät des GSM-Mobilfunksystems beinhaltet.
    20. Anordnung nach einem der Ansprüche 17 bis 19, dadurch gekennzeichnet, daß in der mobilen Teilnehmereinheit eine Ortungskomponente enthalten ist.
    21. Anordnung nach Anspruch 20, dadurch gekennzeichnet, daß die Ortungskomponente ein GPS-Empfänger ist.
    22. Anordnung nach einem der Ansprüche 17 bis 21, dadurch gekennzeichnet, daß die mobile Teilnehmereinheit ferner eine Datenverarbeitungseinrichtung, eine Speichereinrichtung, eine Eingabeeinheit und eine Ausgabeeinheit umfasst.
    EP97952712A 1996-12-10 1997-12-10 Verfahren und anordnung zur verkehrsinformation Revoked EP0883871B1 (de)

    Applications Claiming Priority (3)

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

    Publications (2)

    Publication Number Publication Date
    EP0883871A2 EP0883871A2 (de) 1998-12-16
    EP0883871B1 true EP0883871B1 (de) 2002-09-04

    Family

    ID=7814137

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    EP97952712A Revoked EP0883871B1 (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 (1)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    DE102004017091A1 (de) * 2004-04-07 2005-10-27 Audi Ag Verfahren zum Betrieb eines Navigationssystems für ein Kraftfahrzeug

    Families Citing this family (54)

    * 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
    EP2009608A3 (de) * 1998-11-23 2009-09-23 Integrated Transport Information Services Limited System zur sofortigen Verkehrsüberwachung
    DE19855230A1 (de) * 1998-11-30 2000-05-31 Bosch Gmbh Robert Verfahren und Funksendeempfänger zur Anforderung und zur Verarbeitung von Informationen
    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
    US6754485B1 (en) 1998-12-23 2004-06-22 American Calcar Inc. Technique for effectively providing maintenance and information to vehicles
    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
    JP2003529054A (ja) 1999-10-19 2003-09-30 アメリカン カルカー インコーポレイティド ユーザの嗜好に基づいた効果的なナビゲーション技術
    DE10002918C2 (de) * 2000-01-19 2003-06-18 Ddg Ges Fuer Verkehrsdaten Mbh Stabile Zuordnung von Verkehrsmeldungen und deren Ursache repräsentierenden Zusatzinformationen
    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
    US8126960B2 (en) 2000-07-28 2012-02-28 Silver State Intellectual Technologies, Inc. Technique for effective organization and communication of information
    US6587781B2 (en) 2000-08-28 2003-07-01 Estimotion, Inc. Method and system for modeling and processing vehicular traffic data and information and applying thereof
    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
    JP4396380B2 (ja) * 2004-04-26 2010-01-13 アイシン・エィ・ダブリュ株式会社 交通情報の送信装置及び送信方法
    US7620402B2 (en) 2004-07-09 2009-11-17 Itis Uk Limited System and method for geographically locating a mobile device
    DE102004035897A1 (de) * 2004-07-23 2006-03-16 Robert Bosch Gmbh Verfahren zur Übermittlung von Verkehrsmeldungen
    KR20060119739A (ko) * 2005-05-18 2006-11-24 엘지전자 주식회사 구간 통과시간에 대한 예측정보를 제공하고 이를 이용하는방법 및 장치
    DE602006016025D1 (de) * 2005-05-18 2010-09-16 Lg Electronics Inc Bereitstellung von Verkehrsinformationen in Bezug auf einen Stautrend
    KR20060119743A (ko) * 2005-05-18 2006-11-24 엘지전자 주식회사 구간 속도에 대한 예측정보를 제공하고 이를 이용하는 방법및 장치
    US7729335B2 (en) 2005-05-18 2010-06-01 Lg Electronics Inc. Providing traffic information relating to a prediction of congestion status and using the same
    KR20060119746A (ko) 2005-05-18 2006-11-24 엘지전자 주식회사 교통상태에 대한 정보를 제공하고 이를 이용하는 방법 및장치
    EP2216763B1 (de) 2005-05-18 2011-12-28 Lg Electronics Inc. Bereitstellung von Verkehrsinformationen mit Unterverknüpfungen von Verknüpfungen
    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
    GB0901588D0 (en) 2009-02-02 2009-03-11 Itis Holdings Plc Apparatus and methods for providing journey information
    JP5052550B2 (ja) * 2009-03-11 2012-10-17 アイシン・エィ・ダブリュ株式会社 交通情報管理装置、交通情報管理方法および交通情報管理プログラム
    GB2492369B (en) 2011-06-29 2014-04-02 Itis Holdings Plc Method and system for collecting traffic data
    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)

    Family Cites Families (8)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    GB8726312D0 (en) * 1987-11-10 1987-12-16 Plessey Co Plc Road vehicle route selection & guidance
    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
    US5471205A (en) * 1994-08-31 1995-11-28 Izawa; Michio Map displaying method
    DE19521929A1 (de) * 1994-10-07 1996-04-11 Mannesmann Ag Einrichtung zur Zielführung von Personen
    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

    Cited By (2)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    DE102004017091A1 (de) * 2004-04-07 2005-10-27 Audi Ag Verfahren zum Betrieb eines Navigationssystems für ein Kraftfahrzeug
    DE102004017091B4 (de) * 2004-04-07 2013-01-10 Audi Ag Verfahren zum Betrieb eines Navigationssystems für ein Kraftfahrzeug

    Also Published As

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

    Similar Documents

    Publication Publication Date Title
    EP0883871B1 (de) Verfahren und anordnung zur verkehrsinformation
    EP0883872B1 (de) Verfahren und anordnung zur information mobiler teilnehmer
    DE69831952T2 (de) System zur bereitstellung gezielter internet-information an mobilen agenten
    EP0815547B1 (de) Verfahren und einrichtung zur ermittlung von dynamischen verkehrsinformationen
    DE69720188T2 (de) Routenauswahlsystem für wandernde personen
    EP1206766B1 (de) Ortsbezogene wap-staukarte durch verknüpfung von kartenausschnitten in einer verkehrsinformationszentrale
    DE69928484T2 (de) Verfahren und Vorrichtung zum Verwenden von Echtzeitverkehrsfunkmeldungen mit Navigationssystemen
    EP1079353A2 (de) Verfahren zur Anforderung und zur Verarbeitung von Verkehrsmeldungen
    EP0769180A1 (de) Einrichtung zur aufbereitung und ausgabe von informationen für einen fahrzeugführer
    EP0939945B1 (de) Verfahren zur auswahl und filterung von verkehrsinformationen
    DE19604084A1 (de) Verfahren und Einrichtung zur Ermittlung von Dynamischen Verkehrsinformationen
    EP1062481A1 (de) Verfahren zur ausgabe von verkehrsinformationen
    EP1460599B1 (de) Datenbasis zur Codierung oder Decodierung von Verkehrsmeldungen und Verfahren zur Übertragung codierter Verkehrsmeldungen
    DE10128517A1 (de) Verfahren zum Erzeugen von Navigationsdaten für eine Routenführung sowie Navigationssystem
    EP0896314B1 (de) Navigationssystem für ein Kraftfahrzeug
    WO1989002142A1 (fr) Systeme permettant une utilisation amelioree de voies de transport existantes
    DE19843203A1 (de) Verfahren zur benutzerindividuellen Auswahl und Sendung von Verkehrsinformationen von einer Verkehrszentrale an einen Benutzer und Verkehrsinformationszentrale
    EP1079354A2 (de) Verfahren zum Abrufen von Informationen aus einem Informationsnetzwerk
    EP1141911B1 (de) Einrichtung zur übertragung von fahrtroutenempfehlungen und empfänger
    CH690347A5 (de) Einrichtung zur Informationsubertragung in einem beweglichen Nahbereichskommunikationssystem.
    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
    DE102020114100A1 (de) Verfahren zum Vernetzen von unterschiedlichen Navigationsdiensten sowie Servereinrichtung und System mit einer solchen Servereinrichtung und mit einem Kraftfahrzeug
    EP1370833A1 (de) Verfahren und einrichtungen zum bereitstellen von informationsdaten

    Legal Events

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

    Free format text: ORIGINAL CODE: 0009012

    17P Request for examination filed

    Effective date: 19980824

    AK Designated contracting states

    Kind code of ref document: A2

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

    17Q First examination report despatched

    Effective date: 20000817

    GRAG Despatch of communication of intention to grant

    Free format text: ORIGINAL CODE: EPIDOS AGRA

    GRAG Despatch of communication of intention to grant

    Free format text: ORIGINAL CODE: EPIDOS AGRA

    GRAG Despatch of communication of intention to grant

    Free format text: ORIGINAL CODE: EPIDOS AGRA

    GRAH Despatch of communication of intention to grant a patent

    Free format text: ORIGINAL CODE: EPIDOS IGRA

    RIN1 Information on inventor provided before grant (corrected)

    Inventor name: KNECHTGES, STEPHAN

    Inventor name: LOEHMER, OLIVER

    Inventor name: BEYER, ROLF

    GRAH Despatch of communication of intention to grant a patent

    Free format text: ORIGINAL CODE: EPIDOS IGRA

    GRAA (expected) grant

    Free format text: ORIGINAL CODE: 0009210

    RAP1 Party data changed (applicant data changed or rights of an application transferred)

    Owner name: T-MOBILE DEUTSCHLAND GMBH

    AK Designated contracting states

    Kind code of ref document: B1

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

    REF Corresponds to:

    Ref document number: 223607

    Country of ref document: AT

    Date of ref document: 20020915

    Kind code of ref document: T

    REG Reference to a national code

    Ref country code: GB

    Ref legal event code: FG4D

    Free format text: NOT ENGLISH

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: EP

    REF Corresponds to:

    Ref document number: 59708132

    Country of ref document: DE

    Date of ref document: 20021010

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: NV

    Representative=s name: LUCHS & PARTNER PATENTANWAELTE

    REG Reference to a national code

    Ref country code: DK

    Ref legal event code: T3

    NLR4 Nl: receipt of corrected translation in the netherlands language at the initiative of the proprietor of the patent
    GBT Gb: translation of ep patent filed (gb section 77(6)(a)/1977)

    Effective date: 20030109

    REG Reference to a national code

    Ref country code: ES

    Ref legal event code: FG2A

    Ref document number: 2183230

    Country of ref document: ES

    Kind code of ref document: T3

    ET Fr: translation filed
    PLBI Opposition filed

    Free format text: ORIGINAL CODE: 0009260

    PLBQ Unpublished change to opponent data

    Free format text: ORIGINAL CODE: EPIDOS OPPO

    PLBQ Unpublished change to opponent data

    Free format text: ORIGINAL CODE: EPIDOS OPPO

    PLBI Opposition filed

    Free format text: ORIGINAL CODE: 0009260

    PLAX Notice of opposition and request to file observation + time limit sent

    Free format text: ORIGINAL CODE: EPIDOSNOBS2

    26 Opposition filed

    Opponent name: VODAFONE HOLDING GMBH

    Effective date: 20030603

    26 Opposition filed

    Opponent name: HARMAN/BECKER AUTOMOTIVE SYSTEMS GMBH

    Effective date: 20030604

    Opponent name: VODAFONE HOLDING GMBH

    Effective date: 20030603

    NLR1 Nl: opposition has been filed with the epo

    Opponent name: HARMAN/BECKER AUTOMOTIVE SYSTEMS GMBH

    Opponent name: VODAFONE HOLDING GMBH

    PLAX Notice of opposition and request to file observation + time limit sent

    Free format text: ORIGINAL CODE: EPIDOSNOBS2

    PLBB Reply of patent proprietor to notice(s) of opposition received

    Free format text: ORIGINAL CODE: EPIDOSNOBS3

    RDAF Communication despatched that patent is revoked

    Free format text: ORIGINAL CODE: EPIDOSNREV1

    APBP Date of receipt of notice of appeal recorded

    Free format text: ORIGINAL CODE: EPIDOSNNOA2O

    APAH Appeal reference modified

    Free format text: ORIGINAL CODE: EPIDOSCREFNO

    APBQ Date of receipt of statement of grounds of appeal recorded

    Free format text: ORIGINAL CODE: EPIDOSNNOA3O

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

    Ref country code: NL

    Payment date: 20081219

    Year of fee payment: 12

    Ref country code: LU

    Payment date: 20081223

    Year of fee payment: 12

    Ref country code: DK

    Payment date: 20081219

    Year of fee payment: 12

    Ref country code: CH

    Payment date: 20081222

    Year of fee payment: 12

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

    Ref country code: ES

    Payment date: 20081219

    Year of fee payment: 12

    Ref country code: AT

    Payment date: 20081218

    Year of fee payment: 12

    APBU Appeal procedure closed

    Free format text: ORIGINAL CODE: EPIDOSNNOA9O

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

    Ref country code: IT

    Payment date: 20081223

    Year of fee payment: 12

    Ref country code: SE

    Payment date: 20081222

    Year of fee payment: 12

    RDAG Patent revoked

    Free format text: ORIGINAL CODE: 0009271

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

    Free format text: STATUS: PATENT REVOKED

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

    Ref country code: FR

    Payment date: 20081216

    Year of fee payment: 12

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: PL

    27W Patent revoked

    Effective date: 20090204

    GBPR Gb: patent revoked under art. 102 of the ep convention designating the uk as contracting state

    Effective date: 20090204

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

    Ref country code: DE

    Payment date: 20090225

    Year of fee payment: 12

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

    Ref country code: GB

    Payment date: 20081219

    Year of fee payment: 12

    NLR2 Nl: decision of opposition

    Effective date: 20090204

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

    Ref country code: BE

    Payment date: 20090107

    Year of fee payment: 12

    REG Reference to a national code

    Ref country code: SE

    Ref legal event code: ECNC