EP2709071A1 - Method, wireless beacon and onboard unit for generating parking fees transactions - Google Patents

Abstract

The method involves performing radio polling of the identifier of a road-side radio-beacon (7) as current identifier. The parking charge transaction for the identifier is generated, when the current identifier is similar to the stored old identifier. The current identifier is stored as the old identifier. The parking charge transaction is sent by the radio-beacon over radio to an onboard unit (5) of a vehicle (1). Independent claims are included for the following: (1) a radio-beacon for producing parking charge transaction for vehicle; and (2) an onboard unit for vehicle.

Description

The present invention relates to a method for generating a parking fee transaction for a vehicle having an onboard unit with an identifier. The invention further relates to a radio beacon and an onboard unit for carrying out this method.

Onboard units (OBUs) are electronic devices that are carried by vehicles in order to be able to identify the vehicles wirelessly by radio, for example, for charging tolls in electronic road toll systems. OBUs may be in the form of active or passive radio transponders, radio frequency identification (RFID) chips, near field communication (NFC) chips, dedicated short range communication (DSRC) transceivers, WAVE (wireless access in vehicular environments), and WLAN Nodes (wireless local area networks) and so on. The invention sets itself the goal of making such OBUs usable for the settlement of parking fees.

• Funkabfragen der Kennung von einer straßenseitigen Funkbake aus als aktuelle Kennung;
• wenn die aktuelle Kennung einer gespeicherten alten Kennung gleicht, Erzeugen einer Parkgebührentransaktion für die Kennung;
• Speichern der aktuellen Kennung als alte Kennung;
• Abwarten einer vorgegebenen Zeitspanne;

This object is achieved in a first aspect of the invention with a method for generating a parking fee transaction for a vehicle having an on-board unit with an identifier,
comprising the steps:

• Radio polling the identifier from a roadside radio beacon as the current identifier;
• if the current identifier equals a stored old identifier, generating a parking fee transaction for the identifier;
• Saving the current identifier as an old identifier;
• Waiting for a predetermined period of time;

Repeat the above steps.

The invention is based on the recognition that by comparing the funkabfragbaren at a certain time identifiers located in the radio coverage of the beacon OBUs with identifiers interrogated at an earlier point in time can identify those identifiers and thus OBUs and their vehicles which were present at both times in the radio coverage area and therefore have parked there with high probability. In this way, an astonishingly simple method for generating parking fee transactions, scalable to any number of parking spaces in the radio coverage area of a radio beacon, is created.

According to a preferred embodiment of the invention, a position of the on-board unit is funkabgefragt with the identifier and the parking fee transaction is only generated if in addition to said identity identity, the position is within a predetermined range. As a result, radio coverage of the radio beacon can be intercepted, i. if the parking area is smaller than the radio coverage area of the radio beacon.

Preferably, a status of the on-board unit is funkabgefragt with the identifier and the parking fee transaction is only generated if in addition to the identity of identity mentioned also the status is equal to a predetermined value. As a result, it can be ensured that parking fee transactions are generated only for those OBUs which have set a corresponding "parking status". For example, OBUs of vehicles that are only temporarily in the radio coverage area of the beacon because they are temporarily stuck in traffic along with parked cars can be ignored; conversely, by deliberately setting the park status on a user's OBU, a user may indicate that he now parks and wants to pay parking fees.

The parking fee transactions generated can be further processed and billed in a variety of ways. In a first preferred embodiment, the parking fee transactions are sent by the radio beacon via radio to the onboard unit and charged there, for example, as a debit transaction to a credit held in the onboard unit (an "electronic purse"). According to an alternative preferred embodiment, the generated parking fee transactions sent from the radio beacon to a central office, for example, a toll center of a road toll system, a bank computer, a credit card accounting center, etc. and there charged to a bank, credit or debit account of the user assigned to the OBU identifier.

The method according to the invention operates in steps of the predetermined waiting time period and can accordingly charge park stays in these time units. It is advantageous if the predetermined period of time is 1 to 30 minutes, preferably 5 to 20 minutes, particularly preferably 10 minutes, whereby short stays less than 10 minutes remain toll-free and sufficient time accuracy is achieved for longer stays.

In a second aspect, the invention provides a radio beacon for generating a parking fee transaction for a vehicle having an on-board unit with an identifier, wherein the radio beacon has a radio coverage area covering at least one parking lot and is configured to:
to request the identifier of an on-board unit in its radio coverage area as the current identifier,
if the current identifier is similar to a stored old identifier, generating a parking fee transaction for that identifier,
save the current ID as an old ID, and
repeat these steps after a predetermined period of time.

In an advantageous manner, the radio beacon is configured to also request a position of the onboard unit with the identifier and to generate the parking fee transaction only if, in addition to the identity of identity mentioned above, the position lies within a predetermined range.

Preferably, the radio beacon is configured to also request a status of the onboard unit with the identifier and to generate the parking fee transaction only if, in addition to the identity of identity mentioned, the status also equals a predetermined value.

It is particularly favorable if the radio beacon has a radio coverage area which covers at least two parking spaces and is designed to
to request the identifiers of all on-board units in their radio coverage area as current identifiers,
for each current identifier, which is similar to a stored old identifier, to generate a parking fee transaction,
save the current identifiers as old identifiers, and
to repeat these steps after the given period of time.

In this case, the radio beacon can calculate a parking lot occupancy status from a comparison of the number of current identifiers and number of parking spaces in its radio coverage area.

With regard to the advantages of the radio beacon according to the invention, reference is made to the above comments on the method.

In a third aspect, the invention provides an on-board unit for a vehicle, having a unique identifier, a stored variable status, and a transceiver for communicating the identifier and status to a radio beacon of a beacon, which onboard unit is characterized by having a first operating mode and a second operating mode between which it is switchable by means of a switch, the status indicating the respective operating mode of the onboard unit.

The on-board unit of the invention is therefore particularly suitable for those embodiments of the method and the radio beacon in which they take into account a set status in the OBU and generate parking fee transactions only for those OBUs for which the user has set the park mode or parking status ,

The on-board unit is preferably equipped with a position-determining device for determining its current position and is designed to transmit its position to a radio query of the radio beacon.

According to a particularly preferred embodiment of the invention, the on-board unit may be equipped with a motion sensor which switches over to a threshold value exceeding movement of the onboard unit this in the first operating mode and / or at a minimum time exceeding the absence of movement of the onboard unit this switches to the second operating mode. Thereby, an automatic, motion-controlled switching between the two operating modes, namely the first (toll) operating mode for movement and the second (parking) mode of operation for standstill for a long time can be achieved.

The on-board unit toll mode of operation in which it communicates with toll-beacons on its way, for example as conventional toll-road OBUs, can be exploited according to the invention for a parking-fee transaction via the infrastructure of the road toll system obtained in the park operating mode from a park radio beacon settle. After leaving the parking mode and the radio coverage area of the park radio beacon, for example, the OBU sends the parking fee transaction to the first toll radio beacon that it encounters on its way so as to settle the parking fee via the charging system of the toll radio beacons.

It is particularly favorable if the on-board unit has a power-saving third operating mode in which it temporarily expires in the second operating mode after receiving a radio query or parking fee transaction. Since the radio interrogations of a park radio beacon are comparatively rare, e.g. every 10 minutes, the on-board unit can save a considerable amount of power in this way.

• Fig. 1 die Kommunikation einer Onboard-Unit im Maut-Betriebsmodus mit Maut-Funkbaken auf ihrem Weg auf einer Straße schematisch im Überblick;
• Fig. 2 die Kommunikation von Onbard-Units im Park-Betriebsmodus mit einer Park-Funkbake beim Parken schematisch im Überblick;
• Fig. 3 ein Blockschaltbild und Fig. 4 eine Vorderansicht einer beispielhaften Onboard-Unit gemäß der Erfindung;
• Fig. 5 ein Zustandsdiagramm des in einer Onboard-Unit ablaufenden Teils des erfindungsgemäßen Verfahrens; und
• Fig. 6 ein Flussdiagramm des in einer Park-Funkbake ablaufenden Teils des erfindungsgemäßen Verfahrens.

The invention will be explained in more detail with reference to an embodiment shown in the accompanying drawings. In the drawings shows:

• Fig. 1 a schematic overview of the communication of an on-board unit in toll mode with toll beacons on their way on a road;
• Fig. 2 the communication of Onbard units in park mode of operation with a parking beacon during parking schematic overview;
• Fig. 3 a block diagram and Fig. 4 a front view of an exemplary on-board unit according to the invention;
• Fig. 5 a state diagram of running in an onboard unit part of the method according to the invention; and
• Fig. 6 a flowchart of running in a park radio beacon part of the method according to the invention.

In Fig. 1 a vehicle 1 moves on a road 2 at a speed and direction 3 and in Fig. 2 park several vehicles 1 each on a parking lot 4 of the road 2. The road 2 may be any traffic or parking space, such as a highway, highway or a whole road network in Fig. 1 or a parking strip, a large parking area or a parking garage in Fig. 2 ; All this is understood here by the generic term "road" 2.

The vehicles 1 are each equipped with an onboard unit (OBU) 5, which can handle wireless roadside units (RSUs) 6, 7 radio communications 8. The OBUs 5 may be stand-alone devices or components of the vehicle electronics. The radio communications 8 are dedicated short range communications (DSRC) communications, preferably according to the standards CEN-DSRC, ITS-G5, IEEE 802.11p, WAVE, WLAN, RFID, NFC or the like. The radio beacons 6, 7 thereby each have a locally limited radio coverage area 9, 10.

In the Fig. 1 and 2 Two different types of radio beacons 6, 7 and application scenarios of the described components are shown: The radio beacons 6 of Fig. 1 are tolling roadside units (T-RSUs) geographically distributed along the road 2. The toll radio beacons 6 request, with the aid of periodically radiated radio interrogations 11, all the OBUs 5 passing through them for radio communication 8, as illustrated by the exemplary answer 12. Due to the possibly high speed of the vehicles 1 do not "miss" any passing OBU 5, the radio interrogations 11 of the toll beacons 6 are broadcast in relatively short time intervals, for example every 100 ms. For example, so-called WSA messages (wave service announcements) and, in the CEN-DSRC standard, so-called BST messages (beacon service tables) are used for the radio queries 11 in the WAVE standard.

A successful radio communication 8 with a passing OBU 5 proves that the OBU 5 is located in the local radio coverage area 9 of the toll radio beacon 6, whereby the use of the location of the toll radio beacon 6 can be charged ("marred"). The exploited locality may, for example, driving on a piece of road, entering a certain area ("city toll") or the like. be.

In the park scenario of Fig. 2 On the other hand, "parking" roadside units (P-RSUs) 7 are used which, with a radio interrogation 11, for example a WSA or BST message, prompt all OBUs 5 in their radio coverage area 10 for reply messages 12 in order to use them parking lots 4, as discussed in detail below. A park radio beacon 7 can be responsible for one or more parking spaces 4, which together form a parking area P.

As parked vehicles 1 rest, a park radio beacon 7 can transmit its radio interrogations 11 at much greater intervals ΔT than the toll radio beacon 6 of FIG Fig. 1 for example, every 10 minutes, which simultaneously defines the time resolution of parking time accounting.

The radio coverage area 10 of the park radio beacon 7 can be adapted to the spatial extent of the parking spaces 4 by optional measures, for example directional antennas, in order to avoid responses 12 of OBUs 5 from non-parking, eg passing vehicles 1. Alternatively or additionally, the OBUs 5 of the vehicles 1 in different, the scenarios of Fig. 1 and 2 each adapted operating modes are offset, namely, a first tolling mode (TM) for reply 12 to radio polls 11 of toll beacons 6, and a second parking mode (PM) for answer 12 to radio polls 11 of park radio beacons 7. Optional For example, the radio beacons 6, 7 in the radio inquiries 11 can each emit a beacon identifier indicating whether it is a toll radio beacon 6 or a park radio beacon 7. For example, the beacon identifier may be specified as the service of the beacon as part of a WSA or BST message.

It goes without saying that the toll radio beacons 6 and parking radio beacons 7 can also be realized by one and the same physical unit which, alternately or simultaneously, performs the functions of a toll and a parking radio beacon 6, 7. Thus such a combined unit 6, 7 can be e.g. consecutively at short intervals radio interrogations 11 with beacon identification of a toll radio beacon and at longer intervals ΔT, i. occasionally "interspersed", send radio queries 11 with beacon ID of a park radio beacon 7. Such a radio beacon 6, 7 is then responsible, for example, both for the Vermauten a street piece of the road 2 and the charging of a parking area P.

Depending on the operating mode TM or PM in which an OBU 5 is located, and depending on the beacon ID received, the OBU 5 may e.g. only toll beacons 6 respond when in the toll mode TM, or only park beacons 7 when in the park mode PM.

The operating mode of an OBU 5 can also be coded as a data message (status) st and sent in the response 12. A beacon 6, 7 can evaluate the status st received in a response 12 accordingly, so that toll beacons 6 congested only the passages of OBUs 5 whose status st = "TM" and park beacons 7 only the parking of such OBUs 5 fees whose status is st = "PM". Furthermore, the OBUs 5 may also each measure their own positions p and send them to the park radio beacons 7, which receive the received positions p with their respective parking areas P and only the parking of such OBUs 5 fees whose positions p fall in their respective parking area P. This will now be with reference to the Fig. 3 - 6 explained in more detail.

Fig. 3 shows an exemplary block diagram, Fig. 4 an exemplary exterior view and Fig. 5 an exemplary state diagram of an OBU 5, which between (at least) two operating modes TM and PM according to the application scenarios of Fig. 1 and 2 is switchable. According to Fig. 3 For this purpose, an OBU 5 has a transceiver 13 (eg according to one of the DSRC standards mentioned) for carrying out the radio communications 8, a microprocessor 14 controlling the transceiver 13, a memory 15, an input device 16 and an output device 17. The input and output devices 16, 17 can also be realized in other ways than by the illustrated keyboard and screen output, for example, by voice input and output, sensors, cues, etc. The input and output devices 16, 17 can also be physically separated Components such as car radios, navigation devices, smart phones, PDAs, tablets etc. formed and wired or wireless, eg via NFC, Bluetooth ^® , WLAN or infrared, be connected to the microprocessor 14.

Optionally, the OBU 5 may also include a motion sensor 18 in the form of e.g. a satellite navigation receiver for a global navigation satellite system (GNSS) such as GPS, GLONASS, GALILEO, etc .; Instead of a GNSS receiver, any other type of motion sensor 18 could be used, for example an inertial measurement unit (IMU) or a sensor connected to components of the vehicle 1, for example a connection to the speedometer or engine of the vehicle 1.

In the simplest case, the motion sensor 18 may also be a mere connection to the vehicle electronics, for example the ignition lock of the vehicle, so that, for example, the key position (motor running - does not run) indicates the (probable) movement or parking status of the vehicle.

The OBU 5 may optionally be further equipped with a position-determining device 18 ', which is capable of determining the current position p of the OBU 5 - on interrogation, periodically or continuously. The position determiner 18 'may operate in any manner known in the art, e.g. by means of radio-triangulation in a network of geographically distributed radio stations, e.g. may be formed by the radio beacons 6, 7 itself or base stations of a mobile network, or by means of evaluation of the cell identifiers of a cellular mobile network, etc., etc. Preferably, the position determining means 18 'is a satellite navigation receiver for position determination in a GNSS and in particular by the same GNSS receiver be formed, which is used for the motion sensor 18.

The memory 15 of the OBU 5 contains - in addition to the appropriate application and control programs and data - a unique identifier id the OBU 5, which is set and stored for example in the output or user-specific initialization of the OBU 5 and the OBU 5 and / or their User and / or the vehicle 1 and / or a billing account of the user uniquely identified. The OBU identifier id is sent in each response message 12 from the OBU 5 to a radio beacon 6, 7 in order to uniquely identify the OBU 5 with respect to the radio beacon 6, 7.

The memory 15 may further include the status st indicating the operating mode TM or PM of the OBU 5 for the corresponding scenario of FIG Fig. 1 or 2 indicates. The status st can be changed or set both as a function of a movement (or non-movement) of the OBU 5 measured by the motion sensor 16 and by a user selection via the input device 16. The input device 16 can, for example, a latchable button 16 '( Fig. 4 ), which is labeled "PM" for "Park Mode" PM and by pressing and locking, the OBU 5 switches to the park operating mode PM and sets the status st to the value "PM". By loosening or disengaging the key 16 ', the OBU 5 is switched back into the toll mode TM and the status st is set to the value "TM". The output device 17 can optionally output corresponding notification and / or confirmation messages.

Fig. 5 shows some of the possible operating states of the OBU 5 again in detail in the form of a state diagram (state transition diagram). From the toll mode TM, the OBU 5 can be placed in the park mode of operation PM by depressing the button 16 'and / or if the motion sensor 18 detects no movement of the OBU 5 for a minimum period of, for example, 5 minutes. By releasing the key 16 'and / or detected by the motion sensor 18 movement of the OBU 5, this can be put back from the park operating mode PM back into the toll mode TM.

In the park mode of operation PM, the OBU 5 may temporarily go into a sleep mode, as soon as it has received a radio interrogation 11 of a park radio beacon 7 and has responded with an answer 12. The OBU 5 may wake up from the sleep mode after a predetermined period of time Δt and return to the park mode PM. The time interval .DELTA.t is preferably shorter than the time period .DELTA.T which lies between successive radio requests 11 of a park radio beacon 7. Alternatively or additionally, the OBU 5 could also be woken up again by receiving a next radio interrogation 11.

Fig. 6 shows that in a park radio beacon 7 in conjunction with the OBU 5 of Fig. 3-5 ongoing processes for generating parking fee transactions in the application scenario of Fig. 2 ,

In a first step 19, a radio poll 11 is sent by the park radio beacon 7 to request the OBUs 5 in its radio coverage area 10 for responses 12. In step 20, the responses arriving from the OBUs 5 become 12 each response 12 contains at least the respective identifier id _{i of} the OBU 5 with the index i and optionally its status st _i and / or its position p _i determined by the position determination device 18 '. The received identifiers id _i , stati st _i and positions p _i are temporarily stored as the current record set _curr in the park radio beacon 7.

Id _i running loop 21 is then within one of all received identifiers checks whether the current status st _i is set to parking mode of operation "PM" or not, see decision 22. The decision 22 may additionally (or alternatively) be verified, whether the respective position p _i - if it has been transmitted - in a given geographical area, u.zw. the parking area P of the park radio beacon 7, falls or not. If all the conditions checked in decision 22 are not met (branch "n" of FIG. 22), subsequent steps 23 and 24 are skipped and loop 21 is continued or exited upon exiting to step 25. If, on the other hand, all the conditions are satisfied, ie here: st _i = PM and p _i ∈ P (branch "y" of FIG. 22), a further decision 23 checks whether the respective identifier id _{i of} a previously stored "old" identifier id _{i, last} , that is, in a record set _last {id _{i, last} } of old identifiers id _{i, last} occurs or not. These "old" identifiers id _{i, last} were determined in an earlier process run and stored in the record set _last , as explained below.

If the respective current identifier id _i does not correspond to an old identifier id _{i, last} , ie does not occur in the record set _load (branch "n" of 23), the loop 21 is continued or exited after its completion to step 25; If so (branch "y" of FIG. 23), the process branches to step 24, in which a parking fee transaction ta (id _i ) is generated for the current identifier id _i , as explained in more detail later.

After the step 24, the loop 21 is continued or after its completion, moved to step 25.

In step 25, the current identifiers id _i determined in step 20 are then re-stored as "old" identifiers id _{i, last} , ie the current data _{setset curr is stored} as (now) "old" data set set _last .

Subsequently, in step 26, the predetermined period .DELTA.T is waited, which lies between the individual radio queries 11 of the park radio beacon 7, and then the procedure repeated (loop 27).

At the next repetition in the loop 27, the previously determined current identifiers id _i now represent the "old" identifiers id _{i, last} , and if "new" current identities id _{i are} determined again in step 20, these can then be determined in step 23 with the "old" identifiers id _{i, last} from the last record set _last . As a result, it is checked in each loop pass 27 whether an OBU identifier id _i determined by a park radio beacon 7 on the basis of a radio query 11 has already been present at a radio poll 11 past the time interval ΔT or not; if yes, a vehicle 1 with an OBU 5 of this identifier id _{i has} apparently spent at least the time interval .DELTA.T in the radio coverage area 10 of the park radio beacon 7, so that for the parking over the period .DELTA.T a corresponding parking fee transaction ta (id _i ) for the OBU Identifier id _i may be generated (step 24).

The parking fee transactions ta (id _i ) generated in step 24 can be billed by the radio beacon 7 itself, for example by loading a user account carried in the radio beacon 7 with it. Alternatively, the parking fee transactions ta (id _i ) may be forwarded from the radio beacon 7 to a remote center (not shown) which carries user accounts, toll accounts, bank accounts, credit accounts, etc. among the identities id _i such that the parking fee transactions ta (id _i ) there a corresponding billing account can be charged. However, it is also possible for the generated parking fee transaction (s) ta (id _i ) from the radio beacon 7 to be sent back to the OBU 5 with the identifier id _i , where it is stored in the OBU 5 charged billing account (an "electronic purse") is / are charged.

Another possibility is that the parking fee transaction (s) ta (id _i ) returned from the park radio beacon 7 to the OBU 5 are temporarily stored in the OBU 5 and then when the OBU 5 returns to the toll mode TM returns from the OBU 5 to a toll-beacon 6 on its way to set off, as if it were a toll payment transaction. Fig. 5 for this purpose shows a corresponding operating mode "post ta" in which the OBU 5 temporarily enters after returning from the parking operating mode PM and waits for the next toll radio beacon 6 on its way to process the parking fee transaction (s) ta (id _i ), after which it returns to the "normal" toll mode TM.

It is understood that in Fig. 6 shown sequences can be modified according to known in the art programming methods accordingly. Thus, for example, the decision 22 could be omitted or taken into the step 20 and checked there, whether the status st _{i of} an identifier id _i is "PM" and / or the position p _{i of} an identifier id _i falls within the range P, where then only such identifiers id _i are stored as actual identifiers in the current data set set _curr whose status st _i = "PM" or position p _i ∈ P. Also, the loop 21 could be implemented differently and, for example, immediately after receiving a response 12 for an identifier id _i, steps 22-24 and 23-24, respectively, could be performed if this is done so rapidly computationally that between successive incoming responses 12 can be performed. It should be noted that, according to some DSRC standards, the responses 12 from multiple OBUs 5 that replicate to a common radio interrogation 11 are variably time-spanned to avoid collisions of responses 12 so that there is quite enough time between responses 12 Steps 22 - 24 or 23 - 24 may remain.

A park radio beacon 7, in whose radio coverage area 10 several parking spaces 4 fall, receives by the answers 12 of the OBUs 5 in step 20 at the same time a complete overview of the occupancy status of the parking lots 4 in their parking area P. This only needs the number of in Step 20 identifiers id _i to compare with the number of parking spaces 4 in the area P to get a proportionate or percentage utilization of their parking 4, for example, "80%" if 4 of 5 parking spaces are occupied, etc., etc. The Parking occupied status determined in this way can be sent, for example, to a parking management center.

The invention is therefore not limited to the illustrated embodiments, but includes all variants and modifications that fall within the scope of the appended claims.

Claims (17)

Method for generating a parking fee transaction (ta) for a vehicle (1) having an on-board unit (5) with an identifier (id),
comprising the steps: Radio polling the identifier (id) from a roadside radio beacon (7) as the current identifier (id _i ); if the current identifier (id _i ) is similar to a stored old identifier (id _{i, last} ), generating a parking fee transaction (ta) for the identifier (id); - Save the current identifier (id _i , set _curr ) as an old identifier (id _{i, last} , set _last ); - waiting for a predetermined period of time (ΔT); Repeat the above steps. A method according to claim 1, characterized in that with the identifier (id _i ) and a position (p _i ) of the onboard unit (5) funkabgefragt and the parking fee transaction (TA) is only generated when in addition to said identity identity position ( p _i ) is within a predetermined range (P). A method according to claim 1 or 2, characterized in that with the identifier (id _i ) and a status (st _i ) of the onboard unit (5) funkabgefragt and the parking fee transaction (ta) is only generated if in addition to said identity identities also the status (st _i ) equals a predetermined value (PM). Method according to one of Claims 1 to 3, characterized in that the parking fee transaction (ta) is sent by radio beacon (7) to the on-board unit (5) via radio. Method according to one of Claims 1 to 4, characterized in that the parking fee transaction (ta) is sent by the radio beacon (7) to a control center. Method according to one of claims 1 to 5, characterized in that the predetermined period of time (ΔT) 1 to 30 min, preferably 5 to 20 minutes, particularly preferably 10 minutes. Radio beacon for generating a parking fee transaction (ta) for a vehicle (1) having an on-board unit (5) with an identifier (id), wherein the radio beacon (7) has a radio coverage area (10) covering at least one parking space (4) and is trained
to request the identifier (id) of an on-board unit (5) in its radio coverage area (10) as the current identifier (id _i ),
if the current identifier (id _i ) is similar to a stored old identifier (id _{i, last} ), generating a parking fee transaction (ta) for that identifier (id _i ),
_store the current identifier (id _i , set _curr ) as an old identifier (id _{i, last} , set _last ), and
repeat these steps after a predetermined period of time (ΔT). Radio beacon according to claim 7, characterized in that the radio beacon (7) is adapted to funkabefragen the identifier (id _i ) and a position (p _i ) of the onboard unit and the parking fee transaction (ta) only to generate, if in addition for said identification equality, the position (p _i ) is in a predetermined range (P). Radio beacon according to claim 7 or 8, characterized in that the radio beacon (7) is adapted to request with the identifier (id _i ) and a status (st _i ) of the onboard unit (5) funk and the parking fee transaction (ta) only then to generate, if in addition to the said identification equality and the status (st _i ) a predetermined value (PM) is similar. Radio beacon according to one of claims 7 to 9, characterized in that the radio beacon (7) has a radio coverage area (10) covering at least two parking spaces (4), and is designed to
to request the identifiers (id _i ) of all on-board units (5) located in their radio coverage area (10) as current identifiers (id _i ),
for each current identifier (id _i ), which is similar to a stored old identifier (id _{i, last} ), to generate a parking fee transaction (ta),
_store the current identifiers (id _i , set _curr ) as old identifiers (id _{i, last} , set _last ), and
repeat these steps after the specified period of time (ΔT). Radio beacon according to claim 10, characterized in that the radio beacon (7) from a comparison of the number of current identifiers (id _i ) and number of parking lots (4) in their radio coverage area (10) calculated a parking lot occupancy status. On-board unit for a vehicle, having a unique identifier (id), a stored variable status (st) and a transceiver (13) for communicating (12) the identifier (id) and the status (st) to a radio query (11) a radio beacon (7), characterized in that the onboard unit (5) has a first operating mode (TM) and a second operating mode (PM), between which it can be switched by means of a switch (16 '), the status (st ) indicates the respective operating mode of the on-board unit (5). On-board unit according to claim 12, characterized in that it is equipped with a position-determining device (18 ') for determining its current position (p _i ) and adapted to a radio query (11) of the radio beacon (7) back their position (p _i ) to submit. On-board unit according to claim 12 or 13, characterized in that it is equipped with a motion sensor (18), which switches in a threshold value exceeding movement of the onboard unit (5) in the first operating mode (TM). On-board unit according to one of claims 12 to 14, characterized in that it is equipped with a motion sensor (18), which at a minimum period of time (.DELTA.T) exceeding a movement of the onboard unit (5) this in the second operating mode ( PM) switches. Onboard unit according to one of Claims 12 to 15, characterized in that it is designed to transmit a parking fee transaction (ta) received by a radio beacon (7) in the second operating mode (PM) to a further radio beacon (6) in the first operating mode (TM) ) to send. On-board unit according to one of claims 12 to 16, characterized in that it has a power-saving third operating mode (sleep) in which it temporarily expires in the second operating mode (PM) after receiving a radio interrogation (11) or parking fee transaction (ta).

Images