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)

Applications Claiming Priority (3)

Publications (2)

Family

ID=7814137

Family Applications (1)

Country Status (7)

Cited By (1)

Families Citing this family (54)

Family Cites Families (8)

• 1996
  • 1996-12-10 DE DE19651143A patent/DE19651143B4/de not_active Expired - Lifetime
• 1997
  • 1997-12-10 ES ES97952712T patent/ES2183230T3/es not_active Expired - Lifetime
  • 1997-12-10 AT AT97952712T patent/ATE223607T1/de not_active IP Right Cessation
  • 1997-12-10 WO PCT/DE1997/002871 patent/WO1998026395A1/de active IP Right Grant
  • 1997-12-10 EP EP97952712A patent/EP0883871B1/de not_active Revoked
  • 1997-12-10 AU AU56506/98A patent/AU5650698A/en not_active Abandoned
  • 1997-12-10 DE DE59708132T patent/DE59708132D1/de not_active Revoked
  • 1997-12-10 DK DK97952712T patent/DK0883871T3/da active

Also Published As

Similar Documents

Legal Events