Dansk iværksætter tager patent på roadpricing

7/27/2019 Dansk ivrkstter tager patent p roadpricing

1/32

Note: Within nine months of the publication of the mention of the grant of the European patent in the European PatentBulletin, any person may give notice to the European Patent Office of opposition to that patent, in accordance with theImplementing Regulations. Notice of opposition shall not be deemed to have been filed until the opposition fee has beenpaid. (Art. 99(1) European Patent Convention).

Printed by Jouve, 75001 PARIS (FR)

(19)

EP

1

94

1

462B1

*EP001941462B1*(11) EP 1 941 462 B1

(12) EUROPEAN PATENT SPECIFICATION

(45) Date of publication and mention

of the grant of the patent:17.07.2013 Bulletin 2013/29

(21) Application number: 06791477.0

(22) Date of filing: 20.10.2006

(51) Int Cl.:

G07B 15/00(2011.01)

(86) International application number:PCT/DK2006/000589

(87) International publication number:WO 2007/045250 (26.04.2007 Gazette 2007/17)

(54) AUTOMATIC PAYMENT AND/OR REGISTRATION OF TRAFFIC RELATED FEES

AUTOMATISCHE BEZAHLUNG UND/ODER REGISTRATION VON VERKEHRSBEZOGENENGEBHREN

PAIEMENT ET/OU ENREGISTREMENT AUTOMATIQUES DE TAXES LIEES A LA CIRCULATION

ROUTIERE

(84) Designated Contracting States:AT BE BG CH CY CZ DE DK EE ES FI FR GB GR

HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI

SK TR

(30) Priority: 20.10.2005 US 728308 P

(43) Date of publication of application:09.07.2008 Bulletin 2008/28

(60) Divisional application:12180615.2 / 2 530 653

(73) Proprietor: Cartime Technologies A/S2000 Frederiksberg (DK)

(72) Inventor: HAANING HOJ, lb2000 Frederiksberg (DK)

(74) Representative: Inspicos A/SKogle All 2

P.O. Box 45

2970 Hrsholm (DK)

(56) References cited:EP-A- 0 952 557 EP-A- 1 050 853

WO-A-97/13222 WO-A1-03/069366US-A- 5 574 648 US-A- 5 638 077

US-A1- 2004 153 401 US-A1- 2005 131 636

US-A1- 2005 134 440 US-B1- 6 243 026

US-B1- 6 680 694


2/32

EP 1 941 462 B1

2

5

10

15

20

25

30

35

40

45

50

55

Description

FIELD OF THE INVENTION

[0001] The present invention relates to a system, amethod and a mobile unit/mobile device for accurately

determining the position of a portable or movable unit,such as for example a vehicle. The present inventionfurther relates to automatic payment or registration oftraffic-related fees or taxes, such as for example parkingfees or road taxes.

BACKGROUND OF THE INVENTION

[0002] US patent application 2002/0143611 disclosesa system and a method for performing vehicle paymenttransactions. The system of US 2002/0143611 includesa vehicle with a location determining component and acommunication component, and a server with a commu-

nication component, a vehicle location identifying com-ponent, and a transaction completing component. Thelocation determining component determines the locationof the vehicle, and the vehicle communication componentsends the determined vehicle location information to theserver. The server communication component receivesthe determined vehicle location information from the ve-hicle. The vehicle location identifying component deter-mines if the sent vehicle location locates the vehicle in apay location. If the vehicle location identifying componentdetermines that the vehicle is located in a pay location,the transaction completing component completes a pay-ment transaction.[0003] The location determining component of US2002/0143611 is disclosed as being a stand-alone GPSreceiver. For example, in paragraphs 15, 16 and 20 it isstated that the location of the vehicle is determined viaGPS coordinates.[0004] It is a drawback of the system disclosed in US2002/0143611 that the determining of the vehicles posi-tion only leads to an accuracy of around 3-20 metersbecause only uncorrected GPS coordinates are used.For location determination in relation to for example au-tomatic payment of vehicle parking fees an accuracy of3-20 meters is insufficient in that at borderlines between

two neighbouring parking zones having different parkingfee levels it becomes impossible to determine in whichof such neighbouring zones the vehicle is actually locat-ed. Also, it becomes very difficult to determine whethera vehicle is parked inside or outside a parking area incase the vehicle is parked in an outermost parking boothof the parking area. As a consequence, if the position ofthe vehicle cannot be correctly determined an associatedparking fee cannot be correctly determined and therebycorrectly paid.[0005] Thus, there is a potential risk that the actuallocation of a vehicle is wrongly determined when onlyuncorrected GPS coordinates are applied.[0006] In order to be able to determine the position of

a vehicle with sufficient accuracy the position of the ve-hicle must be determinable with an accuracy of aroundhalf of the vehicle width. This implies that the position ofa vehicle must be determinable with a static horizontalaccuracy approaching half of the width of a standard ve-hicle.

[0007] Ordinary GPS is based on making observationsof the GPS signals at the (client) receiver and performinga number of mathematical operations on the data throughdigital signal processing to achieve a position estimate.It is known and recognized by those familiar with GPSand satellite navigation in general, that the attainable ac-curacy of the position estimates achievable throughstand alone GPS receivers (or any other stand alone sat-ellite navigation receiver) is limited, and that severalmethods exist to introduce measures to obtain a betteraccuracy than that provided by a GPS receiver alone.[0008] The accuracy of the position estimate that isattainable in a basic stand alone GPS receiver is largely

limited by the errors that are imposed on the GPS signals.It is also recognized that the level of complexity and thesophistication of the digital signal processing employedin the receiver influences the attainable accuracy to agreat extent, ie. an advanced, expensive receiver is ex-pected to perform better that a simple, cheap receivergiven the same operating conditions. It is well establishedthat a number of methods can be employed to obtainposition estimates with better accuracy, such as DGPS(Differential GPS) and SBAS (Satellite Based Augmen-tation Systems).[0009] A system and method for automatic chargingfor vehicle parking is suggested in EP 0 952 557 A. InEP 0 952 557 A DGPS is presented as the means forobtaining sufficient accuracy.[0010] The principle of DGPS is to use differences ofGPS observables rather than the absolute observationsthemselves. The differences are obtained by subtractingdifferential corrections from the observations made at theclient receiver. The differential corrections are made ata differential reference station (also called a DGPS bea-con) and the corrections are disseminated to the clientreceiver(s) typically through wireless communications,broadcasted as a local radio signal (typically at a longwave frequency around 300 kHz). A side effect of using

differences of GPS observations to compute the clientreceiver position is that instead of the absolute position,the position of the receiver relative to the reference sta-tion (i.e. a so-called baseline vector between the refer-ence station and the client receiver) is found.[0011] The underlying idea behind DGPS is that theerror that limits the attainable accuracy is - to some de-gree - present in the GPS signals at both the referencestation and the client receiver (mathematically, the errorsare correlated). This means that when differences areformed, the errors that are common to both the referencestation and the client receiver is cancelled out by sub-traction. DGPS therefore relies on the assumption that

the errors at the reference station and the client receiver

1 2


3/32

EP 1 941 462 B1

3

5

10

15

20

25

30

35

40

45

50

55

are the same.[0012] This assumption of course is only entirely truewhen the client receiver is located at the same geograph-ical location as the reference station. The errors are high-ly correlated when the receivers are in close proximity,and in this case the application of differential corrections

can result in a dramatically improved positioning accu-racy. However this improvement deteriorates as the ge-ographical separation between the reference station andthe client receiver is increased (and the spatial correlationdecreases) and when the distance between the two ex-ceeds a few tens of kilometres the beneficial effect issignificantly reduced.[0013] The predominant errors that are cancelled thisway are those imposed by the ionosphere in that the sat-ellite signals are distorted in a somewhat systematicmanner when the signals pass through the ionosphereand the troposphere - the first of the two being the mostsignificant. Both error sources can vary locally over short

time spans mainly due to ionospheric scintillations andtropospheric variations, such as air humidity, so the com-monality of GPS errors that can be cancelled with DGPScan vary greatly when the distance between the refer-ence station and the client receiver is increased.[0014] Thus, to obtain efficient differential corrections,a network of reference stations is required to provide localcoverage. This in turn means that the reference stationsneed to be considered as part of the local infrastructurefor any system that depends on DGPS for proper oper-ation. The higher the requirement for positioning accu-racy, the finer the grid of reference stations needs to be.[0015] Thus, this EP 0 952 557 A suggests positioncorrection by use of DGPS the available position accu-racy is strongly dependent on the denseness of the ref-erence stations. Also, it is a disadvantage of DGPS thatthe available position accuracy may vary from one geo-graphical area to another geographical area.[0016] In contrast to DGPS, the idea behind SBAS isto employ a number of satellite monitoring stations whichcompute augmentation data that can be disseminatedthrough satellites rather than local reference stations toreach users in a much wider region. One of the mainpurposes of SBAS is to obviate the need for a networkof local reference stations. Thus, using SBAS will mean

independence from local infrastructure.[0017] The principle of SBAS is to use a number ofstrategically located RIMS stations (Ranging and Integ-rity Monitor Stations) to observe the GPS constellation.The RIMS receive the GPS signals and compare the po-sition estimates that can be determined from the GPSobservables with the known locations of the RIMS. Thisis used to form corrections that are sent from the RIMSto a Central Processing Centre. In the EGNOS system,the data is collected in the Mission Control Centre whereit is used to compute (1) Long term errors of the satelliteorbits, (2) Short term and long term errors of the satelliteclocks, (3) Ionospheric correction grids and (4) Integrity

information. These are combined to form the EGNOS

augmentation data set.[0018] With regards to increasing positioning accura-cy, the ionospheric correction grids are the most impor-tant feature. The continuous stream of observations bythe RIMS network is used to form a map of the TEC(Total Electron Content) in the ionosphere for the area

covered by the RIMS stations (which for EGNOS is all ofEurope). TEC is the number of electrons in a column ofone meter-squared cross-section along a signal paththrough the ionosphere, and this accurately describesthe error that the ionosphere imposes on the GPS signal.[0019] The TEC maps are sent to the geostationarySBAS satellites which retransmit them to provide the cli-ent receivers with the information they need to performthe correction of the ionospheric effects. Using the TECmap the client GPS receivers can calculate the piercepoint, i.e. the point where the GPS satellite signal pen-etrates the ionosphere, and delay of the signal of eachsatellite used for position calculation and then correct the

data for higher accuracy in the position determination.[0020] In SBAS the monitor stations do not provide sin-gle isolated corrections, but data from all stations togeth-er are combined to calculate a correction map for a widearea. Every single receiver then corrects its own positionitself by use of this data. In that way, the accuracy thatcan be achieved is even better than with DGPS, exceptfor cases where the client receiver is very close to a ref-erence station, where DGPS may outperform SBAS.[0021] In conclusion, the key to SBAS is that the cor-rections that are applied are computed based on the cli-ent receiver position and that this is independent of wherethe monitor stations are located. This provides a widecoverage independent of local infrastructure. A TEC mapis not provided in conventional DGPS based on differen-tial reference stations, so in DGPS the reduction of theionospheric errors depend solely on closeness to a ref-erence station. Unlike DGPS, SBAS can be expected toperform consistently throughout a wide area independentof reference stations.[0022] Due to the radio frequencies used in DGPS andSBAS systems, the practical implementation of DGPSand SBAS differs in a fundamental way. DGPS uses longwave radio transmissions around 300 kHz, which isequivalent to wavelengths of around 1 km, whereas GPS

uses the UHF radio frequency 1575.42 MHz for the GPSL1 carrier, which is equivalent to a wavelength of only19.029 cm. This implies that it is not practically feasibleto receive the DGPS signal with a normal GPS patchantenna since the geometry and physical size of the GPSantenna is determined from a certain fraction of the19.029 cm wavelength which again is determined by thedielectric characteristics of the ceramic materials usedin the antenna.[0023] The GPS frequency allows the use of cheap,compact low-profile antennas such as ceramic microstrippatch antennas, whereas the DGPS signal with its wave-length being approximately 5000 times longer requires

a significantly different antenna technology, namely a

3 4


4/32

EP 1 941 462 B1

4

5

10

15

20

25

30

35

40

45

50

55

much larger, more expensive and bulky whip or ferritecore coil based antenna.[0024] SBAS signals on the other hand are broadcast-ed on the same carrier frequency as the GPS signals,thus allowing the same GPS antenna and radio front-endto be used for SBAS reception. Thus, using DPGS will

result in a much more heterogeneous receiver hardwarearchitecture that is more complex and more expensivethan that of SBAS based receivers.[0025] It may be seen as an object of the present in-vention to provide a cost efficient system and a methodfor determining the position of a movable unit, such as avehicle, with a static horizontal accuracy approachinghalf of the width of a standard vehicle.[0026] It is a further object of the present invention toprovide a system and a method which is an essentiallyself contained system and method being essentially in-dependent of local infrastructures. The only local infra-structure required is cellular network coverage which is

readily available where operation of the system is de-sired.[0027] It is a still further object of the present inventionto provide a system and a method which in combinationwith the determination of the position of for example avehicle also offers automatic payment or registration ofposition traffic-related fees, such as parking fees.[0028] It is a still further object of the present inventionto provide a system and a method which is easy to main-tain and update when required.

SUMMARY OF THE INVENTION

[0029] In its most general aspect the present inventionrelates to a system or a method for automatic paymentor automatic registration of traffic related fees for vehi-cles, such as parking fees. In order to pay or registertraffic related fees in an acceptable manner the preciseposition of the vehicle must be determinable. Also, forobtaining the relevant approvals from various traffic orlegal authorities for such system and method the positionof the vehicle must be determinable with an accuracyapproaching half of the width of a standard vehicle.[0030] In the above context automatic payment shouldbe taken to mean a financial transaction performed im-

mediately after a given event has occurred. For example,a financial transaction in form of payment of a parkingfee may immediately follow the removing of a vehiclefrom a parking lot. The amount to be paid may dependon the position of the parking lot and the time the vehiclehas been parked at the specific location. The paymentmay be performed by drawing the amount from the ve-hicle owners bank account.[0031] By automatic registration is meant that theabove-mentioned financial transaction may not immedi-ately follow a given event. Payment of for example park-ing fees may be accumulated over a period of time, forexample a month, as it is known from credit card arrange-

ments. Thus, the accumulated parking fees are billed

once a month, typically at the end of a month, and thetotal sum to be paid is drawn from the owners bank ac-count.[0032] The above-mentioned objects are compliedwith by providing, in a first aspect, a system for automaticpayment of parking fees, cf. claim 1.

[0033] The accuracy the corrected position of the ve-hicle may be better than 1 meter, such as around 0.8meters.[0034] The determining means for determining whenthe vehicle is in a parked state may further comprise aprocessor means being adapted to determine when thevehicle is in a parked state, said determination being atleast partly based on a number of position observablesprovided by the receiver.[0035] The determining means for determining whenthe vehicle is in a parked state may further comprise sen-sor means being adapted to determine when the vehicleis in the parked state and/or adapted to determine a state

of a motor of the vehicle. Such additional sensor mayinclude a vibration sensor or sensors, an accelerometeror accelerometers, a sensor or sensors for monitoringthe position of the ignition key of the vehicle etc. Outputsignals form such sensors may be provided via a wire orwirelessly, such as for example Bluetooth.[0036] The processor means may further be adaptedto determine when the vehicle is in a non-parked state,said determination being at least partly based on anumber of position observables provided by the receiver.This determination may in addition be determined usingan additional sensor or sensors, such as a vibration sen-sor or sensors, an accelerometer or accelerometers, asensor or sensors for monitoring the position of the igni-tion key of the vehicle etc.[0037] The satellite-based navigation system receivermay comprise a GPS receiver or a GALILEO receiver.The communication means of each of the plurality of mo-bile units may be adapted to communicate via a cellularnetwork, such as GSM, GPRS, EDGE, iDEN, D-AMPS;PDC, W-CDMA, CDMA2000 or TD-SCDMA.[0038] The processor means of the plurality of mobileunits may form part of processor means of the commu-nication means of the mobile units. In this way a separateprocessor is saved.

[0039] The communication means of the base unit maybe adapted to communicate with the plurality of mobileunits via an Internet Service Provider.[0040] The base unit may comprise one or more baseunits optionally positioned at different physical locations.In fact, the base unit may preferably be implemented asa redundant unit comprising a number of essentially iden-tical base units optionally positioned at different physicallocations. By implementing a redundant system the riskof system brake down or failure is significantly reduced.The base unit may comprise a plurality of data bases,wherein a first data base comprises information relatingparking areas where parking fees are to be paid, and

wherein a second data base comprises position correc-

5 6


5/32

EP 1 941 462 B1

5

5

10

15

20

25

30

35

40

45

50

55

tion signals to be applied to position observables gener-ated by mobile units, and wherein a third data base com-prises user account related information. The base unitmay be operatively connected to a plurality of externalservice providers, such as a payment service provider,a redundant service providing position correction signals

etc.[0041] In a second aspect, the present invention re-lates to a method for automatic payment of parking feesaccording to claim 13.[0042] Again, the accuracy the corrected position ofthe vehicle may be better than 1 meter, such as around0.8 meters.[0043] The method may further comprise the step oftransmitting a message to the mobile unit in case the firstposition of the vehicle falls outside a predeterminedrange from a parking area, said message informing theuser of the vehicle that parking is free of charge.[0044] The step of calculating a corrected position of

the vehicle may involve applying SBAS corrections to thefirst position of the vehicle, said first position of the vehiclebeing represented by at least one set of GPS observablesor GPS coordinates.[0045] In a first embodiment, the step of calculating acorrected position of the vehicle involves applying EG-NOS corrections to the first position of the vehicle, saidfirst position of the vehicle being represented by at leastone set of GPS observables or GPS coordinates. At leasttwo ways exist of using EGNOS augmentation data toachieve a better GPS position estimate. The EGNOSaugmentation data can be used to form a correction toan already computed GPS position estimate, or the EG-NOS augmentation data can be applied directly to theGPS observations/observables to correct these prior tocomputation of the GPS position estimate. The latter ofthe two is advantageous since it provides a better overallaugmentation, resulting in a more efficient correctionwhich leads to a more accurate GPS position estimate.[0046] In a second embodiment, the step of calculatinga corrected position of the vehicle involves applyingWAAS corrections to the first position of the vehicle, saidfirst position of the vehicle being represented by at leastone set of GPS observables or GPS coordinates.[0047] Finally, in a third embodiment, the step of cal-

culating a corrected position of the vehicle involves ap-plying MSAS corrections to the first position of the vehi-cle, said first position of the vehicle being representedby at least one set of GPS observables or GPS coordi-nates.[0048] The method according to the secondaspect ofthe present invention may further comprise the step oftransmitting a message to the mobile unit in case thecalculated corrected position of the vehicle falls outsidea predetermined range from a parking area, said mes-sage informing the user of the vehicle that parking is freeof charge.[0049] In case the calculated corrected position falls

within a predetermined range from a registered parking

area the method may further comprise the steps of ver-ifying that the mobile unit positioned at the calculatedcorrected position has an associated valid user account,and transmitting a message to the mobile unit, said mes-sage informing the user of the vehicle whether a validuser account has been identified or not.

[0050] In case a valid user account is identified themethod may comprise the step of displaying, on the mo-bile unit or on an associated display means, that parkingis being paid for. This information may be displayed in amanner so that parking attendants may see that a parkingfee is actually being paid for. In addition, a parking feeper time unit may be displayed on the mobile unit or onthe associated display means.[0051] The method may further comprise the steps ofdetermining, in the mobile unit, when the vehicle is nolonger in a parked state, and transmitting said determi-nation to the base unit. The step of determining that thevehicle is no longer in a parked state may comprise that

a status of a motor of the vehicle is determined and/orposition observables are processed. In addition to this,output signals from for example a vibration sensor, anaccelerometer etc. may be applied.[0052] The method may further comprise the steps ofcalculating, in the base unit, the time the vehicle has beenparked, calculating an associated parking fee, and trans-mitting a message to the mobile unit, said message in-forming the user of the vehicle of the parking fee to bepaid. The parking fee to be paid may be displayed on themobile unit or on the associated display means.[0053] The financial transaction may comprise the stepof drawing an amount corresponding to the calculatedparking fee from an account of an individual registeredas the owner of the mobile unit, and deposit this amounton an account of the parking area proprietor.[0054] Alternatively, the financial transaction maycomprise the step of registering an amount correspond-ing to the calculated parking fee, and storing this regis-tering amount to enable a later deposit of an amount cor-responding to accumulated registered amounts, said de-posit being to an account of the parking area proprietor.According to this embodiment, an accumulated amountcorresponding to accumulated parking fees may bedrawn, for example once a month, from an account of an

individual registered as the owner of the mobile unit, anddeposited on an account of the parking area proprietor.[0055] Alternatively, the financial transaction maycomprise the step of drawing an amount correspondingto the calculated parking fee from a prepaid amount paidby an individual registered as the owner of the mobile unit.

BRIEF DESCRIPTION OF THE INVENTION

[0056] The present invention will now be explained ingreater details with reference to the accompanying fig-ures, within

Fig. 1 shows a high level system schematic overview

7 8


6/32

EP 1 941 462 B1

6

5

10

15

20

25

30

35

40

45

50

55

illustration of the system according to the presentinvention,

Fig. 2 shows a parking lot with vehicle,

Fig. 3 shows an overall block diagram of the system

according to the present invention,

Fig. 4 illustrates the communication flow during atraffic related event,

Fig. 5 illustrates the decision flow during a traffic re-lated event,

Fig. 6 shows a parking lot presented in compact,simplified form by a circular approximation.

[0057] While the invention is susceptible to variousmodifications and alternative forms, specific embodi-

ments have been shown by way of example in the draw-ings and will be described in detail herein. It should beunderstood, however, that the invention is not intendedto be limited to the particular forms disclosed. Rather,the invention is to cover all modifications, equivalents,and alternatives falling within the spirit and scope of theinvention as defined by the appended claims.

DETAILED DESCRIPTION OF THE INVENTION

[0058] As already mentioned the present invention re-lates, in its most general aspect, to a system or a methodfor automatic payment or automatic registration of trafficrelated fees for vehicles. Such traffic related fees maybe parking fees. In order to pay or register traffic relatedfees in an acceptable manner the precise position of thevehicle must be determinable. Also, for obtaining the rel-evant approvals from various traffic or legal authoritiesfor such system and method the position of the vehiclemust be determinable with an accuracy better than ap-proximately half of the width of a typical vehicle. Thepresent invention aims at determining the horizontal po-sition of a vehicle with an accuracy around 0.8 meters.[0059] In order to achieve the above-mentioned accu-racy, position information from various systems, such as

GPS, GALILEO and EGNOS, are required. For example,GPS is applied to determine the position of the vehiclewith an accuracy in the range 3-20 metres. Such accu-racy is insufficient and a correction value provided byEGNOS is applied to increase the accuracy to around0.8 metres. When the position of the vehicle has beendetermined the time the vehicle has been parked mustbe determined. In this way corresponding sets of datarelating to "vehicle position" and "parking time" are ob-tained. The device according to the present invention isin communication with an, compared to the device andthereby also the vehicle in which i t is mounted, externalserver where corresponding sets of data relating "vehicle

position", "parking time" and "parking fees" are stored.

Thus, when "vehicle position" and "parking time" are de-termined and communicated to the server the associated"parking fee" to be paid is easily determinable.[0060] When the "parking fee" to be paid has been de-termined a payment transaction may be initiated auto-matically whereby the determined "parking fee" is imme-

diately drawn from the owners bank account. Alternative-ly, "parking fees" to be paid can be accumulated over acertain period of time, say for example a month, anddrawn from the owners account ones a month, for exam-ple near the end of each month. Evidently, other timeintervals, longer or shorter than one month, may also beused. Also, the bank account where a "parking fee" oraccumulated "parking fees" are to be drawn from maynot necessarily belong to the user or driver of the vehicle.[0061] Even though the above-mentioned descriptionrelates to payment of parking fees the overall principlesof the systems, methods and mobile units according tothe present invention also apply to automatic payment

of other types of traffic related fees, such as road taxes,bridge fees etc.. Thus, by applying the over all principlesof the present invention it may be determined when avehicle enters a road section, for example a high way, abridge etc., where road taxes are to be paid.[0062] In the following, the system and method accord-ing to the present invention will be described with refer-ence to automatic payment of parking fees, but as pre-viously mentioned the scenario could as well be relatedto automatic payment of any traffic related fee, such asfor example road taxes.[0063] It is envisioned that the system must be able tosupport a large number of concurrent users, eventuallynumbered in the millions, so it is of vital importance thatthe cost price of each end-user product is cheap to man-ufacture. It is of equal importance that the daily systemoperation and maintenance (such as parking area up-dates) can take place without access to the end-usersproducts due to their sheer volume. This dictates theneed for a client-server system architecture and that theclient is kept as simple as possible. Such system is de-picted in Fig. 1 where a plurality of clients, here vehicles,communicate with a central server.[0064] A simple parking lot with a vehicle parked in aparking booth is depicted in Fig. 2. In order to determine

in which parking booth the vehicle is parked, or to deter-mine if the vehicle is parked in an outermost parkingbooth, as depicted in Fig. 2, or outside the parking lot,the position of the vehicle needs to be determinable withan accuracy approaching half the width of the vehicle. Ifsuch accuracy is achieved it may be determined in whichof a plurality of neighbouring and abutting parking boothsthe vehicle is positioned.[0065] Referring now to Fig. 3 each customer purchas-es a mobile unit (A) - a client - as well as a service thatprovides automated access to a central unit (C) - theserver. Each customer is registered in an account systemon the server where he has a subscription associated to

his identity and the identity of his product. Each client is

9 10


7/32

EP 1 941 462 B1

7

5

10

15

20

25

30

35

40

45

50

55

given a unique identification number during manufactur-ing.[0066] The system comprises a single central unit, alarge number of mobile units and a number of externalservice providers (B, Eand F).Also a GPS (Global Po-sitioning System) receiver that is EGNOS (European Ge-

ostationary Navigation Overlay Service) compliant is em-ployed (D).[0067] The block diagram of Fig. 3 comprises the fol-lowing main blocks:

AMobile unit: An end-user module with a unique idcode located in the customers vehicle. The mobileunit is made location aware via GPS.

BMNO (Mobile Network Operator) and ISP (InternetService Provider): The infrastructure necessary forthe mobile units to communicate with "the rest of theworld". The mobile units establish wireless connec-

tions to the cellular phone networks of the MNOs andthe MNOs pass communication on to an ISP. TheISP routes the information to/from internet which ineffect enables the mobile units to communicate withthe server through internet.

CCentral unit: The server handles the communica-tion to all the mobile units. The server contains allinformation about parking areas and fees associatedwith parking so this information can be easily updat-ed without access to all the clients. The server alsohandles all transactions. The accessibility of theserver is vital for the proposed system to work so itis of utmost importance that this is implemented ina robust way and with a number of redundant phys-ical units to maximize system robustness and up-time.

DAn EGNOS compliant GPS receiver: One of themeans of obtaining EGNOS corrections which willbe needed to ensure proper operation of the system.

ESISNET: An internet based service that ESA (Eu-ropean Space Agency) is providing. This is one ofthe means of obtaining the EGNOS corrections

needed to ensure proper operation of the system.

FPSP (Payment Service Provider): A service - suchas the Danish PBS (Pengeinstitutternes Betal-ingsservice) - that enables the operator to performfinancial transactions to all the P-area owners.

[0068] If desired, it is possible to encrypt the data trafficbetween the clients and the server. Well known methodsfor applying cryptography exists, and any appropriatemethod that is convenient could be employed. For in-stance, cryptographic protocols such as SSL (SecureSockets Layer) and its successor, TLS (Transport Layer

Security) are well known methods to provide secure com-

munications on the internet for a number of things suchas web browsing, e-mail, and other data transfers. SSLand TLS run on layers beneath application protocols(such as HTTP, FTP, SMTP and NNTP) and above theTCP or UDP transport protocol, which form part of theTCP/IP protocol suite. They can add security to any pro-

tocol that uses reliable connections (such as TCP), andhas found widespread use with HTTP to form HTTPS.Current implementations of SSL/TLS are based on meth-ods such as RSA (Rivest, Shamir and Adleman), TripleDES (Triple Data Encryption Standard) and AES (Ad-vanced Encryption Standard), so they are generally con-sidered to be very secure.[0069] The general principle of operation of the systemdepicted in Fig. 3 is as follows:[0070] The mobile unit uses GPS to detect when park-ing is taking place. The mobile unit main computer soft-ware does this simply by monitoring the continuousstream of position estimates from the GPS module and

detecting when a sufficient amount of GPS data suggestthat the vehicle is no longer moving but parked. Othermeans of confirming that the vehicle is parked (such asignition key state, accelerometer measurements, etc.)may be incorporated as well. The mobile unit uses theGSM/GPRS modem to connect and signal this to theserver.[0071] The server responds by applying the latest setof EGNOS corrections to the GPS position given by themobile unit to obtain a corrected position estimate whichhas a higher degree of accuracy. This corrected positionestimate is compared to the location and boundaries ofthe registered parking areas that are associated withparking fees and determines if the parked vehicle is lo-cated inside a payment zone.[0072] If this is the case the server makes a log entryfor the given mobile unit identification code indicating thata parking event has commenced. If the user has an ac-count and a valid subscription to the service, a transactionis prepared and the server signals back to the mobile unitthat the parking event is registered and it is taking placewithin a payment area. This is also indicated on the ex-ternally visible part of the mobile unit so that any parkingattendant at the parking area can verify that the vehicleis parked legally and that payment will occur.

[0073] When the vehicle is moved the mobile unit de-tects this and the server is contacted again. The servercomputes the duration of the parking event, comparesthis to the potentially time dependant parking fee tablefor the given parking area and finally computes the totalparking fee. The server completes the payment by per-forming the transaction which transfers the fee from theusers account to the owner of the parking area. The serv-er also signals to the mobile unit that payment for theparking has indeed taken place and displays to the userhow much was paid. The overall communication flow dur-ing a parking event is illustrated in Fig. 4.[0074] The system depicted in Fig. 3 comprises a

number sub-modules - the functionality of these sub-

11 12


8/32

EP 1 941 462 B1

8

5

10

15

20

25

30

35

40

45

50

55

modules will be explained in the following:

1 A GPS receiver. Must provide accurate positionestimates even in urban areas.

2 A GSM (Global System for Mobile Communica-

tions) modem with GPRS (General Packet RadioService) transmit/receive facilities for data commu-nication.

3 An embedded computer with system softwarewhich governs decision-making in the mobile unit.Rather than implementing this control software in aseparate microprocessor the required software is im-plemented directly in the GSM modem which typi-cally has some free microprocessor resources forapplication programming.

4 A number of mobile network operators whos ag-

gregated GSM, 3G or EDGE network covers the areawithin which service coverage is wanted.

5 The operators typically also function as internetservice providers so they will be able to perform thebridging of data between the mobile units on theGSM network and internet.

6 The central system software which governs andcoordinates all the operations at the server side ofthe communication that takes place between thecentral unit and the clients. The system software con-tains all required functions to compute parking feesbased on parking location and duration information,it handles all the information exchange with the pay-ment service provider and it performs the EGNOScorrections on mobile unit GPS position estimatesto ensure that sufficiently accurate positions areused. The system software makes use of a numberof databases for these purposes.

7 A database which contains information about thephysical location and boundaries of the parking ar-eas that are covered by the provided service. Thedatabase also contains parking fees, information

about when the fees are applicable as well as infor-mation about to whom payment transactions shouldbe made to for the different parking areas.

8 A database that contains all the navigation datamessages disseminated in EGNOS.

9 A database with customer specific informationsuch as account data associated with each mobileunits unique identification code, logged activities andother statistics.

10 A GPS/EGNOS receiver used to monitor the ge-

ostationary EGNOS satellites. The receiver is

equipped with a high gain antenna and this antennais to be located at a high elevation point comparedto the physical surroundings to ensure good recep-tion conditions. By continuously monitoring the EG-NOS satellites, the EGNOS message database(point "8") can be held constantly updated with the

most recent set of correction data.

11 An internet based service called SISNET (Signal-In-Space through the interNET) provided by ESA.SISNET provides users access to the same EGNOSmessages that are disseminated through the geosta-tionary satellites. This ensures a redundant supplyof EGNOS data.

12 An internet based service, such as the one pro-vided by the Danish PBS, which enables one to per-form financial transactions to the owner of the cov-ered parking areas.

[0075] In Fig. 3 a plurality of communication channelsbetween the various modules and sub-modules are de-picted. The following is a description of the these com-munication channels:

21 A wireless transmission from the satellites inGPS and the GPS receiver in block (A).Protocol: Specified in the USCG (U.S. Coast Guard)Navigation Center "Interface Control Document(ICD-GPS-200c)" p.t. version IRN-200C-004.

22A serial RS-232 connection between the GPSmodule and the main computer software. Protocol:"NMEA-0183" for GPS specific data.

23A wireless connection between the mobile unitsand the mobile network operators. Protocol: TCP/IPformatted data sent via GPRS packets over GSM.

24A flat rate commercial DSL (Digital SubscriberLine) connection (or equivalent) between the internetservice provider and the central server. Protocol:TCP/IP formatted data sent via internet.

25A TCP (Transmission Control Protocol) port con-nection between the server main application soft-ware and a database (for parking area information),such as a MySQL database (or other suitable data-base). Protocol: Proprietary commands defined byoperator that adheres to the SQL standard.

26A TCP port connection between the server mainapplication software and a database (for EGNOS da-ta messages), such as a MySQL database (or othersuitable database). Protocol: Proprietary commandsdefined by operator that adheres to the SQL stand-ard.

13 14


9/32

EP 1 941 462 B1

9

5

10

15

20

25

30

35

40

45

50

55

27A TCP port connection between the server mainapplication software and a database (for customerspecific information), such as a PostgreSQL data-base (or other suitable database). Protocol: Propri-etary commands defined by operator that adheresto the SQL standard.

28A serial RS-232 connection between the GPS/EGNOS receiver and the central server. Protocol:"NMEA-0183" for GPS specific data.

29A flat rate commercial DSL connection (or equiv-alent) between the central server and the ESA SIS-NET Data Server. Protocol: TCP/IP formatted datathat adheres to the SISNET standard specified byESA.

30A flat rate commercial DSL connection (or equiv-alent) between the central server and the payment

service provider(s) used to carry out the financialtransactions. Protocol: TCP/IP formatted data thatadheres to the standard specified by the paymentservice provider(s) used.

[0076] The DSL connections 24, 29 and 30 mayvery well be a shared connection to the local ISP. Fur-thermore, the system architecture illustrated in Fig. 3does not show the proposed redundant server setup. Itwill however mainly consist of block (C) being duplicateda number of times as well as some added network mon-itoring and switching equipment. The duplicated centralunit (C) can be positioned at different physical locationso as to minimize the risk of system failure or brake downin case of for example power failure, fire etc..[0077] Fig. 5 illustrates the decision flow that takesplace when a parking event occurs. When the systemaccording to the present invention is initialized the serveris idle and the client is busy waiting, polling the state ofthe vehicle ignition key. It will remain doing so until theignition key is switched off.[0078] When the vehicle ignition key is switched off,the client main system software simply waits a specifiedperiod of time, say for instance 5 seconds, collecting GPSposition updates during this waiting period. After the wait-

ing period the client system software computes the bestaverage of the position updates and evaluates this todetermine if the vehicle is moving or stationary. If it ismoving, if for instance the vehicle is towed or otherwisebeing transported, and thus not parked, the client returnsto its initial busy waiting loop. If the vehicle is stationaryand the "ignition key off" precondition was met the vehicleis defined as parked.[0079] If the vehicle was found to be parked, the clientsignals to the central server that the user vehicle isparked. It transfers the time of the parking event and theunique identification number of the client product so thatthe server is aware of who should pay for the parking if

it turns out to be in a toll location. The client also transfers

the averaged vehicle position as well as a number of rawGPS observables to allow the server to perform postprocessing of some selected GPS data.[0080] The server responds by initiating a control se-quence that will take care of the appropriate server-sidedata processing for the remainder of this particular park-

ing event. The primary task is to determine whether thevehicle is parking in - or in the vicinity of - a toll parkingarea. For practical reasons this check must initially be assimple as possible in order to quickly abort any furtherprocessing if the vehicle is not in or near any toll parkingareas. This initial check is required since the number ofreported tentative parking events from the sum of theclients may potentially be very large, numbering in themillions pr day. This is elaborated further in the followingdescription of the central server software.[0081] If the vehicle is found to be parked outside anyknown registered payment areas the client is notified thatparking is taking place free of charge, or at least not found

in the database, and the data processing sequence issimply aborted. If, on the other hand, it appears that thevehicle was parked in or near a payment area, a furthercheck is made on the server. The raw GPS observablesare used with the latest set of EGNOS corrections to ob-tain an augmented/enhanced position estimate with in-creased accuracy. This enhanced position estimate isused to thoroughly check if the vehicle is parked in a payarea.[0082] Again, if it is found that the vehicle is parkedoutside a registered payment area it is indicated to theuser that parking is taking place free of charge and thedata processing is aborted. If it is determined that thevehicle indeed is parked within a pay area, the serverproceeds to check if the user has a valid customer ac-count with an active subscription. If this is not the case,if for instance the customers subscription is expired orthe account has been overdrawn, the server will be un-able to perform payment on behalf of the user so an errormessage is issued to the user informing him of this. Thiserror message may be supplemented with advice to parkin a nearby non-toll area or suggest him to pay manuallyfor the parking event. Optionally it may be entered intothe user database log on the server that the particularuser had performed an unsuccessful parking event as

well as the reason this was so. Again, this will terminatethe data processing sequence since the system will notbe able to perform the payment service for the customer.[0083] If the customer is found to have an active ac-count with a valid subscription the server makes a logentry with the parking event (location, time and user id,etc.) so that it will be able to determine the duration ofthe parking event when it is terminated, i.e. the usermoves the vehicle.[0084] The server signals to the client that the parkingevent is registered, that it is taking place within a toll areaand confirms that the customer has a valid account withan active subscription. This confirms to the user that pay-

ment will occur so the user knows he can safely leave

15 16


10/32

EP 1 941 462 B1

10

5

10

15

20

25

30

35

40

45

50

55

the vehicle without fear of being incorrectly fined for park-ing without paying. Additionally it may inform the userwhat the current parking fee pr. time unit is at the presentlocation (perhaps even including additional rates if theparking area operates with multiple rates as function oftime). Naturally, it is also signalled on a display that is

visible from outside of the vehicle so any parking attend-ant that checks the vehicle is informed that the owner ofthe vehicle will indeed pay for parking through an ap-proved means of automatic payment.[0085] This ends the first half of the data processingcontrol sequence, the server suspends the thread thattakes care of the particular customer id until further noticeand the client is left busy waiting, polling the state of theignition key of the vehicle (which it would continue to dountil the ignition is turned on).[0086] When the user starts his vehicle the same pro-cedure is used at the client to determine whether thevehicle is still parked as when the system originally left

the initialization state. The client software waits for a pe-riod of time, collecting GPS position updates. When asignificant amount of GPS data suggests that the vehicleis no longer parked, the server is contacted and the clientsignals that the parking event with the associated productid is terminated.[0087] The server responds by reactivating the sus-pended thread taking care of this particular product id,resuming the control sequence thus finalizing the dataprocessing. The server software computes the durationof the parking event and calculates the total parking fee,taking into account that the parking event may havespanned multiple time zones with different parking fees.The server executes the payment transaction, using aninternet based payment gateway, transferring the appro-priate amount from the customers account to the propri-etor of the toll parking area that was used. Alternative,amounts relating to a number of parking events within agiven time period, for example a month, can be accumu-lated in the served. The server then executes a singlepayment transaction once a month for a given costumeraccount.[0088] The server updates the user log with the activ-ities carried out to enable subsequent statistical analysisof the user database to monitor (and optimize) the oper-

ation of the system. The server signals to the client thatthe payment transaction has taken place, displays thefee transferred and optionally displays the customers ac-count status information. This concludes the dataprocessing sequence for the parking event, the servercloses the thread for the particular product id and theclient is left busy waiting, polling the state of the vehicleignition key again.[0089] Everything should occur during the leastamount of time that is practically possible. The usershould have near-instantaneous feedback and not haveto wait for lengthy durations of time for system responses.It would be desirable to have the system respond and

confirm to the user within 10 seconds from the ignition

key being switched off that parking is correctly registered.Likewise it would be desirable to have the system re-spond within 10 seconds from the ignition being switchedon (and the vehicle moved) that the payment transactionhas occurred and what the total amount that was trans-ferred was.

[0090] The following is a description of the primaryfunctions, requirement and design parameters, notesand considerations for the sub modules of the proposedsystem architecture depicted in Fig. 3:

1 Client GPS

Function:

[0091] The GPS receiver may for example use theGPS L1 C/A code signal @ 1575.42 MHz. As an alter-native, perhaps for future system generations, other sat-ellite based navigation systems, such as Galileo, would

also be viable. The receiver will use a low profile patchantenna for practical installation purposes. It performscontinuous tracking of the visible GPS satellite signals(up to a maximum of 12 satellites simultaneously) andcomputes m position estimate updates pr second (forinstance 5 pr second). Position updates are passed tothe mobile unit main computer software. The GPS re-ceiver itself does not perform evaluation of whether GPSpositions indicate a stationary or moving vehicle.

Requirements:

[0092] The GPS module is cost sensitive since it islocated in the mobile unit. This makes it a severe chal-lenge to find commercially off-the-shelf (COTS) GPSmodules that are applicable.[0093] The primary requirement for the GPS moduleis to provide sufficiently accurate position estimates tomaintain proper system operation. It is desirable to obtainan accuracy of less than 1.0 m independent of the mobileunits local environment and reception conditions. Thisrequirement is coupled to the size of a "standard" parkingbooth and the size of the vehicles that are expected toemploy the system and method according to the presentinvention. The accuracy of the GPS receiver is expected

to be vital to ensure that the product can be approvedlegally as valid means of payment for parking.[0094] It is highly unlikely that a standard GPS L1 C/Acode stand-alone receiver will be able to meet this re-quirement. Even relatively high quality single frequencystand-alone GPS modules that are orders of magnitudetoo expensive to have any relevance for the implemen-tation of the present invention are not likely to meet therequirement. Therefore augmentation of some kind isdefinitely required. Early EGNOS tests made with ESTB(EGNOS System Test Bed) indicated that a GPS L1 C/Acode receiver could be modified to provide position esti-mates with an accuracy of about 0.8 m when employing

the corrections provided by the EGNOS augmentation

17 18


11/32

EP 1 941 462 B1

11

5

10

15

20

25

30

35

40

45

50

55

system. Results such as these were obtained in signalreception conditions where the environment offered a vir-tually multipath free signal scenario. Multipath interfer-ence is caused when the GPS signals bounce of nearbyobjects causing the satellite signal to arrive at the antennathrough routes other than the direct line of sight. This

causes a detrimental effect on the GPS receiver signalprocessing and deteriorates the performance of the re-ceiver. While typical commercially available low costGPS L1 C/A code stand-alone modules tend to have anaccuracy in the 3-10 m range in optimum conditions (mul-tipath free environments), multipath interference maylower positioning performance to the 5-20 m range.[0095] To achieve a 1.0 m (or better) accuracy in urbanenvironments, where multipath interference is to be ex-pected due to surrounding buildings, the GPS receivermust employ efficient means of suppressing the effect ofmultipath as well as employing EGNOS corrections. Cur-rently multipath in satellite based navigation systems

constitutes a major research area that include a greatnumber of challenges. As of now there has not been es-tablished a simple, universal, well defined way of totallyremoving the effect of multipath. However a number ofmethods have been proposed by the research commu-nity, each with varying degree of effectiveness. It is es-tablished that multipath mitigation will require digital sig-nal processing and that certain components of the GPSreceiver has to support this - in particular the RF radiofront end must have a relatively wide bandwidth of atleast around 12-15 MHz for the signal processing to beeffective.[0096] The requirement that the desirable accuracyshould also be reached in urban environments influencesthe way the EGNOS corrections are obtained. It is highlyunlikely that surrounding buildings will permit a clear viewto the EGNOS satellites in general in urban environments(this is elaborated further in the "10 GPS/EGNOS" sec-tion below). It is therefore proposed that EGNOS correc-tions are obtained centrally rather than having the clientsthemselves try to receive the EGNOS signals.[0097] This leaves the system architecture choice ofwhether to (1) disseminate the EGNOS augmentationdata from the server to all the clients or to (2) gather theappropriate raw GPS observables from the clients and

transfer these to the server and apply the augmentationdata centrally. It appears option number two is advanta-geous since it is likely to limit the amount of data that hasto be transferred to/from the clients through the wirelessconnections. As a rough overview of the amount of datato be transferred in each case (just the GPS posit ioningdata is considered here, not the overhead to communi-cate client id, system status, handshakes, etc.) can becompared. A complete set of EGNOS corrections fromthe three EGNOS satellites consists of three sets of 17messages which each consists of 33 bytes, thus totalling3x17x33 = 1683 bytes. A set of raw observables consist-ing of 12 pseudoranges (assumed packed into 4 byte

representations) occupy only 12x4 = 48 bytes though a

few other parameters such as a receiver time stampshould also be transferred.[0098] Exploiting this gives rise to an additional re-quirement for the GPS receiver at the client: It must beable to supply the raw GPS observables (pseudoranges)to the central server.

[0099] Some secondary requirements: The power con-sumption or the physical size of the receiver is not toocritical. It is expected that these requirements will easilybe met. However the antenna should be physically locat-ed so that it has the best possible clear unobstructedview of the sky. It is acknowledged that car manufacturersare very likely to want to have the final say in matterssuch as physical arrangement and placing of the antennaif the product is to be factory installed in cars.[0100] Overall the client GPS receiver is a critical com-ponent, both regarding the attainable performance andwith respect to the unit cost price of the modules. Thepresented system is likely to require a custom made GPS

module tailored to match the requirements of the appli-cation

2 GSM Modem

Function:

[0101] The primary purpose of the GSM modem is toallow GPRS data packets to be sent to/from the mobileunit, thus providing internet connectivity. Also, other mo-bile phone systems, such as the various 3G systems,may be viable as well. As a side effect of employing aGSM modem in the mobile unit, a partially available em-bedded microprocessor is provided as well. Due to costissues it is highly desirable not to have to implement aseparate microprocessor to handle the decision makingsystem software in the mobile unit, so this task could beimplemented in software directly on the GSM modem.

Requirements:

[0102] The amounts of data to be transferred duringnormal client-server communication are expected to bequite limited, perhaps to as little as a few hundred bytespr parking event. This is of course influenced if value

added services are attached to the core service. It mayin fact be possible to implement this communicationthrough SMS (Short Message Service) traffic. It is ex-pected that GPRS traffic on the other hand will operatewith sufficiently low latency to suit the requirements dic-tated by the overall operation of the system. With realisticGPRS data transfer rates around 30-80 kbit/s transferdurations should not pose a problem.[0103] Thus, any modern GSM modem should be suf-ficient to handle the data transfers in an adequate fash-ion. Voice transfer is not required so a great number ofcommercially available GSM modems will be overkill forthe current application. The GSM modem is cost sensi-

tive since it is located in the mobile unit. It may prove to

19 20


12/32

EP 1 941 462 B1

12

5

10

15

20

25

30

35

40

45

50

55

be a challenge to find sufficiently cheap modules - espe-cially COTS (such as the Siemens cellular engine MC35ior equivalent) - so a cheap, stripped down version of anexisting GSM modem design, custom made for this ap-plication could be required.

3 Main Computer Software

Function:

[0104] The primary purposes of the client system soft-ware are to monitor the stream of GPS position updatesto determine if the vehicle is stationary whenever the ig-nition key has been turned off and again when it has beenturned on, and to initiate and handle communication withthe server when the vehicle is found to be parked - orwhen it is terminating a parking event.

Requirements:

[0105] The key to ensure reliable and proper operationof the system is the ability to determine whether the ve-hicle is parked or not (and where) in a robust, trustworthymanner. This requires high accuracy position estimatesand the proper evaluation and decision logic. It is pro-posed that the evaluation is based on a number of posi-tion updates, such as for instance the last 25 updateswhich would correspond to 5 seconds worth of data if theGPS module was configured to provide 5 updates pr sec-ond. The client software performs a statistical hypothesistest based on some defined confidence level to deter-mine if there is sufficient statistically significant data sug-gesting that the vehicle is stationary, and thus parked.Such a procedure would ensure a well defined behaviourwith a fixed and known low probability of false positivesi.e. cases where the vehicle is assessed to be parkedeven though it is not assuming the GPS module operatesas taken for granted in the statistics. Features such asoutlier rejection should be considered as well. If externalsensors, such as accelerometers, etc., are employed,measurements from these should be correlated with theGPS position updates as well.[0106] Notes on errors in statistical hypothesis testing:

- False positive (type I error) - assessing a vehicle tobe parked when it is really not.

- False negative (type II error) - failing to assess avehicle as parked even though it really is. If a falsenegative occur, a parked vehicle is not charged afee for parking. This of course is not desirable sincethe proprietor of the parking area lose out on theparking fee he was entitled to. Though undesirable,the consequence of this is small if the error happensrarely. The system should be tuned to an appropri-ately low rate of false negatives, since a missed cus-tomer parking event could potentially cost the owner

of the vehicle a parking fine which by all rights, the

operator is likely to hear about and be asked to re-imburse.

[0107] A false positive on the other hand would meanthat a vehicle was falsely assessed to be parked and thatthe owner is potentially wrongfully charged for a parking

that he did not perform. Such errors could cause the userto lose confidence in the product and should certainly beavoided.[0108] The remaining functions are; to signal to theserver whenever a parking event is taking place, sendingraw GPS observables to the server and awaiting evalu-ation of whether the parking event is taking place withina pay zone, provide visible indication to both the parkingattendant (externally visible display) and the user wheth-er parking is taking place within a pay zone and whetherthe server has found a valid account to pay for the parking- conversely display an error message if the latter is notthe case, signalling to the server when a parking event

is terminated and displaying parking rates and total feeswhen so informed by the server. These are all very simpletasks that should not pose any problems.[0109] This embedded client software must co-existwith the software that is executed on the GSM modem.It should be coded for maximum efficiency to ensure min-imal resource consumption and smallest possible foot-print (memory requirements) but this should not be aproblem since the functions of the client are really quitesimple.[0110] Although the client system software performs avital role, the same is true for the remainder of the systemmodules. With regards to performance only the processof robustly assessing whether the vehicle is parked ornot requires special attention.

4 Mobile Network Operator

Function:

[0111] The sole function of the mobile network operatoris to provide network coverage for the area of operation.This is a well established standard service that is alreadyoffered, so this is deemed unlikely to cause complica-tions.

Requirements:

[0112] Care should be taken in finding the best sub-scription types (which would probably just be the cheap-est service that has sufficient guarantee that GPRS trafficwill indeed reach its destination) and the MNOs that havethese available. Since it is probably unlikely that any sin-gle operator will have coverage for the desired region ofoperation, roaming agreements should be made to reachthe appropriate network coverage.

21 22


13/32

EP 1 941 462 B1

13

5

10

15

20

25

30

35

40

45

50

55

5 Internet Service Provider

Function:

[0113] Again, the sole function of the internet serviceprovider is to facilitate the clients access to the internet

for the area of operation.

Requirements:

[0114] The GPRS packets should simply be routed to/from internet through stable routing nodes that have re-liable operation and high uptime, which is expected to bea trivial task for any well established ISP.

6 Central Server Software

Function:

[0115] The primary tasks of the central server systemsoftware are to receive transmissions from the mobileunits, process the supplied information and initiate theproper action on the server based on the data from themobile unit and the state of the corresponding users ac-count as well as signal appropriate messages back tothe mobile unit.[0116] Primary actions on the server include initiatingdatabase information extractions, performing EGNOScorrection of supplied GPS positions and correspondingraw observables, performing a two-step verification ofwhether the mobile unit is located in payment areas, per-forming customer account verifications, computing park-ing fees, performing the payment transactions, updatingthe user log with statistics, and making sure that the EG-NOS database is continuously updated from two inde-pendent sources. Also the server should provide func-tions for updating the P-area database, updating the Userdatabase and perform statistical analysis on the informa-tion in the user log.

Requirements:

[0117] The application software should be implement-ed in a flexible, scalable way to accommodate a large

fleet of distributed clients. Whereas the embedded clientsoftware is optimized for minimum footprint to run on alow resource platform, the server-side software can ex-ploit the computational power of large commercially avail-able computers without any significant increase in overallsystem cost. Still a very large number of requests couldpotentially occur simultaneously so the software shouldbe designed and implemented with strict performanceoptimization. This will affect both the application softwarearchitecture and the underlying databases.[0118] An obvious choice of platform could be a dis-tributed, redundant Linux server park running cheap (orfree) operating systems with cheap (or free) databases.

The application software could be multi-threaded for scal-

ability and the databases should be structured to allowa large number of simultaneous requests.[0119] As a consequence of the system architectureand the information and decision flow in the system,whenever a vehicle equipped with the client product hasthe ignition key switched off and the vehicle is stationary,

this event (a tentative parking event) will trigger that theserver is contacted with information (GPS info, etc.) fromthe client. Thus, it is to be expected, that once the systemis deployed in a widespread fashion, a very large numberof requests will be sent to the server every day - even forcars that were not parked in pay areas and thus do notneed any servicing.[0120] It would be prudent to effectively reduce theprocessing load on the server by quickly filtering out suchrequests that do not require any servicing, thus a fastinitial geographic search procedure is needed to deter-mine whether a parked vehicle is close to or within a payzone. This is not necessarily a trivial task due to the po-

tentially complex geographical layouts (shapes) of thetoll parking areas and the sheer number of parking areasthat may be registered in the system. A simple and veryefficient rough-sort evaluation scheme, based on circularapproximations to parking areas is proposed to performthis initial check.[0121] Assume that a parking area is surveyed and thelocation of all outer points of the area are measured sothat the (linear) boundaries between points define thephysical extent of the closed area. Simple shaped areascould be defined by three or four points, while complexshaped areas could require any number of points. Allparking areas are entered into the database in their entireform with all registered boundary point as well as circularapproximations of the parking area mapped onto a tan-gential plane (2D) of the region, thus reduced to only twoparameters (1) the geographic mean of all boundarypoints, and (2) the distance from the center to the pointthat lies furthest from the center.[0122] This would allow a quick evaluation of whethera vehicle is in - or in the immediate vicinity of - a registeredparking area based on the simple relation between planardistance of two points (the mean parking area centerlocation and parked vehicle location) and compare theradius of the circular parking area approximation to the

distance between the two points. If the distance betweenthe two points is less than the circle radius, the vehicleis defined as in or near the parking area.[0123] Referring now to Fig. 6 P1 is an example of asomewhat complex shaped parking area. The polygonA defines the outer boundaries of the parking lot in itsentire form. The cross C marks the center (geographicmean) of the parking lot, found by averaging the x and ycoordinates respectively for points which constitute pol-ygon A. P2 shows the same parking area as in P1 aswell as the circular approximation B, using the point Cas center, and having a radius corresponding to the dis-tance between the center and the point on polygon A that

lies the furthest from the center.

23 24


14/32

EP 1 941 462 B1

14

5

10

15

20

25

30

35

40

45

50

55

[0124] Naturally, a thorough subsequent evaluationshould be carried out to determine accurately if the ve-hicle is located inside the potentially complex shapedparking area if the initial evaluation turned out to be true.This could be based on partially dividing the complexareas into simple shapes (ultimately reduced to just tri-

angles) or whatever method is deemed appropriate.[0125] The tasks of performing database informationextraction or entering new information into a databaseare rather simple since the databases are equipped withdatabase managers that provide high level functions forinteraction with the database. It is proposed that relation-al database models that follows a SQL (Structured QueryLanguage) implementation are considered.[0126] Utilizing the respective database managers it isa simple matter to extract the latest EGNOS augmenta-tion data to correct at set of GPS observations, extractingcustomer account information to verify if a client requestis associated with a valid service subscription or to extract

information about geographical location and boundariesof parking areas since simple macro functions can beassembled to search (querying) the databases for therequired information.[0127] Likewise, it should pose no problem to applythe EGNOS augmentation data to the GPS observationssince known algorithms exist for the purpose. When theduration of parking events are computed (by comparingstart and end time stamps for the events) and informationabout the applicable parking rates for the given locationis extracted from the database, it is a trivial task to com-pute the total fee for the parking event. And when thetotal fee for a parking event is found, the customers in-formation is extracted from the database it is simple toperform the payment transactions to the parking areaproprietors using the payment service providers.[0128] Overall the server is a highly critical component.The system operation relies entirely on a functioning sys-tem server since the clients will be unable to provide anyservice without the server. This makes it an absolute ne-cessity that the server is implemented as a redundantserver park rather than a single unit, so a single point offailure is avoided. This entails duplicating system com-ponents (servers and databases) a number of times,making sure that they are actually independent and re-

dundant (so for instance they are located at differentphysical locations) on every level so that client commu-nications will be routed to the appropriate servers no mat-ter what the server system state is.[0129] The server(s) and the server software must bescalable to accommodate a large (and growing) numberof distributed clients. This is practically achievable usingmultithreading software techniques and practices thatare well established.

7 P-area Database

Function:

[0130] The purpose of the parking area database is toverify whether a parked car is located within a payment

area and to determine how much the fee is for a givenparking in the area.

Requirements:

[0131] Each individual parking area that is associatedwith a parking fee exists as a separate entry in the data-base. Each entry could possibly consist of a list of GPScoordinates forming the outer boundary of the parkingarea, its geometric average point, the maximum physicalextent of the area in any direction from the average centerpoint (as well as other parameters) to facilitate a veryquick and easy check to see if mobile unit GPS coordi-

nates lie within a particular parking area.[0132] It is envisioned that any given parking area eas-ily can be mapped using a geodetic GPS survey receiverstrategically placed at the outer extremes of the parkingarea. The database entries should have a table of parkingfees (as function of time) associated with it as well as therequired information to perform payments to the propri-etors of the parking areas. The accuracy of the parkingarea registration should at least be comparable to (orpreferably better than) the target accuracy of the mobileunit GPS module.[0133] There exists a number of free (or cheap) SQLdatabases of which a great deal could be used for thevarious database purposes in the proposed system. Twovery obvious candidates are the MySQL and PostgreSQLdatabases. MySQL is available as free software underthe GNU GPL (General Public License), but is also avail-able under traditional proprietary licensing arrangementsfor cases where the intended use is incompatible withthe GPL. PostgreSQL is released under a flexible BSD-style license (Berkeley Software Distribution).[0134] Summarized simplistically, MySQL was builtwith speed as the primary feature, PostgreSQL was builtwith more robust features like triggers, but lacked thespeed of MySQL. As both are maturing, they are moving

towards the other. MySQL 5 adds triggers and storedprocedures, while PostgreSQL is focused on improvingperformance.[0135] MySQL is used by huge internet information ar-chives, such as Wikipedia, who currently services morethan 200 million queries and 1.2 million updates per daywith peak loads of 11,000 queries pr second. There iscurrently more than 6 million instances of MySQL world-wide, so the free database has undergone substantialtesting and debugging. PostgreSQL may perhaps havean advantage over MySQL when it comes to ensuringatomic, consistent and isolated operations which makesit ideal for transactions. Atomic operations are composite

operations carried out on the database as a seemingly

25 26


15/32

EP 1 941 462 B1

15

5

10

15

20

25

30

35

40

45

50

55

single occurrence (so that part of the composite operationcan not be executed without all of the composite oper-ation is carried out). PostgreSQL also supports in-builtfunctions so complex high level user defined operationscan be executed directly in the database manager.[0136] The parking area database is probably best im-

plemented with MySQL. The primary focus when imple-menting this database should be on accessibility andspeed. A parking area database based on MySQL willeasily handle the information amount required to coverall the parking areas that will be included even in majorregions of operation.

8 EGNOS Database

Function:

[0137] The purpose of the EGNOS database is simplyto hold the EGNOS augmentation data used to correct

the GPS position estimates.

Requirements:

[0138] The database should constantly be updated tohold the most current EGNOS data messages. This is avery simple task using the SISNET and the EGNOS/GPSreceiver as data sources.[0139] The EGNOS messages themselves are rathercompact - consisting (at the moment) only of 17 messag-es, each occupying 33 bytes, pr EGNOS satellite - so thesize of the database will be very limited.[0140] The EGNOS database is easily implementedwith MySQL. The primary focus when implementing thisdatabase should be on accessibility and speed.

9 User Database

Function:

[0141] The purpose of the user database is to hold allthe user account and subscription information as well asa log of historic events.

Requirements:

[0142] The database will contain vital user info (suchas account and subscription info, current state of the us-ers vehicle, temporary transaction data, logged info anduser statistics, etc.) and will serve as the basis for per-forming payment transactions. It is critical that the data-base is kept consistent at all times so user informationis never corrupted.[0143] The user information database is probably bestimplemented with PostgreSQL. The primary focus of thisdatabase and the methods implemented to access thedatabase should be on consistency since it is used fortransactions.

10 GPS/EGNOS Receiver

Function:

[0144] The purpose of the centrally located GPS/EG-NOS receiver is to provide a source of EGNOS augmen-

tation data.

Requirements:

[0145] An EGNOS compliant GPS receiver under con-trol of the operator should be located near the centralserver. The EGNOS satellites are placed in geostationaryorbits (above the equator) to provide a wide coveragearea. This means that when seen from Earth the satelliteswill have quite low elevation angles above the horizonwhen observed from high latitudes such as northern Eu-rope (in Denmark for instance at 56 deg north the ele-vation angle to the highest EGNOS satellite is about 7.5

above the horizon). Therefore it is vital to place the an-tenna for this receiver at a high altitude point in unob-structed view of the EGNOS satellites (such as at the topof a tall building). It is also advised to use a high gaindirectional dish antenna to maximize receiver signal-to-noise ratio, particularly for the EGNOS data messagedemodulation process.[0146] Augmentation systems such as EGNOS, thatrely on satellite based corrections are generally referredto at SBAS (Satellite Based Augmentation System). EG-NOS is an augmentation system that covers operationin the European and African region. Equivalent to this,the American region is covered by the WAAS (Wide AreaAugmentation System) system and Japan and the east-ern Asian region is covered by MSAS (Multi-FunctionalSatellite Augmentation System).[0147] The three SBAS systems all adhere to the samesignal specification, "RTCA MOPS DO 229C" (http://www.rtca.org/downloads/ListofAvailableDocsWEBAUG_2005.htm). The RTCA(Radio Technical Commission for Aeronautics), devel-ops standards related to FAA (Federal Aviation Admin-istration) which is an agency of the United States Depart-ment of Transportation with authority to regulate andoversee all aspects of civil aviation in the U.S.

[0148] The EGNOS/GPS receiver could be one of anumber of commercially available suited receivers, aslong as the receiver is capable of providing the raw EG-NOS messages for the database. Alternatively, a modi-fied version of the client GPS receiver could be used (i.e.EGNOS reception support has to be included in this ver-sion of the client receiver).

11 SISNET

Function:

[0149] The purpose of the SISNET connection is to

provide a redundant source of the EGNOS data.

27 28


16/32

EP 1 941 462 B1

16

5

10

15

20

25

30

35

40

45

50

55

Requirements:

[0150] SISNET is available both as a free service andas a commercial service. The free service is provided asis without any guarantees, the commercial service is pro-vided with some access and availability guarantees. It is

advised that the operator subscribe to the commercialservice to ensure proper EGNOS data message recep-tion.[0151] Currently ESA uses a proprietary application-layer protocol called DS2DC, explained in detail intheSISNET User Interface Document (available athttp://esamultimedia.esa.int/docs/egnos/estb/Publica-tions/SISNET/SISNET_UID_3_1.pdf)[0152] Implementing the required software to connectto the SISNET data server and continuously downloadingmessages to update the EGNOS database is a ratherstraight forward task based on the protocol specification.It is expected to be non-critical to reach the desired per-

formance.

12 Payment Service Provider

Function:

[0153] The purpose of the payment service provider isto act as a payment gateway that facilitates financialtransactions over the internet.

Requirements:

[0154] Service providers such as the Danish PBSseems like obvious candidates. Care should be taken tosurvey the marked and compare service conditions ofthe potential candidates. Similar to the mobile networkoperator/internet service provider, a special deal shouldbe made with the chosen payment service provider sincepotentially a very large number of transactions will bemade on a daily basis (which should bring transactioncost pr occurrence down). It is expected to be non-criticalto reach the desired performance.[0155] The above-mentioned system description takesits origin in a position determining arrangement applyingGPS/EGNOS. The following is a short description of how

future technological developments may affect the abovedescribed system architecture and the features and func-tions provided by the system.

1 Client GPS

[0156] The European satellite navigation system Gal-ileo is currently under development. It is generally ex-pected that Galileo will outperform (or at least match)GPS as we know it today in all aspects. The Galileoproject has been subjected to numerous significant de-lays and is not expected to have a fully deployed satelliteconstellation before perhaps the year 2010.[0157] As a more or less direct response to this devel-

opment, GPS is undergoing modernizations to provideusers with better performing positioning signals. Current-ly the GPS IIR-M satellites (modernized versions of thecurrent block IIR satellites) are being deployed and de-tailed specifications have been drafted for the followinggeneration, GPS IIF. A completely revised generation

of GPS, called GPS-III is also undergoing initial analysisat the moment.[0158] It is likely that future high performance satellitenavigation receivers will be designed to take advantageof a combination of the available signals. It is howevernot clear at the moment if SBAS augmentation data suchas those provided by EGNOS will be an integral part ofthe future navigation systems or whether these will stillbe provided by separate augmentation systems. It isclear that receivers that combine data from several sys-tems will generally be more expensive than those basedon single systems, particularly the number of carrier fre-quencies dictate this.

[0159] Systems that do not contain the EGNOS-styleaugmentation data as an integral part may still signifi-cantly benefit of the principle of collecting raw GPS ob-servables (or equivalent satellite navigation signals ingeneral) at the client and sending these to the server forsubsequent SBAS augmentation and correction for high-er positioning accuracy. Since GPS in its present form islikely to be around for a number of years to come it ishighly unlikely that the principle of collecting and applyingthe augmentation corrections centrally will become ob-solete any time soon.

2 GSM Modem

[0160] While GSM is considered a 2G (second gener-ation) mobile phone system, GPRS is often described asa "2.5G" system. 3G systems are currently being de-ployed, but so far has only reached full coverage in Den-mark in densely populated urban areas and cities andalong certain highway segments. Deployment may havedifferent status in other European countries.[0161] The primary requirement of the wireless accesstechnology used in the system is the coverage, sincedata transfer rates are easily suff icient in even 2.5G net-works due to the quite limited amounts of data to be trans-

ferred in typical operation.[0162] With present coverage, 3G is probably highlyunsuitable for the proposed system. This may of coursechange once the coverage is more complete. Also, de-pending on the future features and services that are de-sired by the system, 3G/4G mobile phone networks mayprove advantageous if the features/services require largeand fast data transfers between the clients and the serv-er.

3 Main Computer Software

[0163] The basic role of the system software in the cli-

ent is unlikely to change in future versions of the system.

29 30


17/32

EP 1 941 462 B1

17

5

10

15

20

25

30

35

40

45

50

55

The client application software may however be expand-ed to support any number of possible augmentations.For instance more advanced user input/output and/or dis-play capabilities may readily be included if future desiredfeatures/services requires this. Any number of sensorsand transducers may be included as well, for instance

vehicle alarm sensors.

4 Mobile Network Operator

[0164] See item 2 above. The role of the mobile net-work operator is likely to remain largely unchanged as aresult of employing future mobile system technologies.The single primary function will still be to provide wirelessaccess coverage for the distributed clients in the area ofoperation.

5 Internet Service Provider

[0165] Like the network operator, the role of the inter-net service provider is likely to remain unchanged.

6 Central Server Software

[0166] Additional features/services in a future systemmay readily be implemented by adding the relevant dataprocessing modules in the central server. The server ar-chitecture can easily be expanded with additional serversto provide the desired functions.

7 P-area Database

[0167] Additional databases may be included to facil-itate new features or services such as a variety of differentroad pricing schemes. Any number of additional data-bases can be incorporated.

8 EGNOS Database

[0168] See item 1 above. Even though Galileo ma

Documents

Dansk iværksætter tager patent på roadpricing